Cro: Maintain it With Zig

>> Their error handling mechanism also relies on the compiler being able to assign unique IDs to errors that may well differ between compiles. I'm not sure how well this scales either. Who knows, maybe it's fine, but maybe they are just kicking the can down the road on these hard problems.

I think this is a concern for them too. When speaking about inferred error sets (which is not the same as auto code assignment), this comes up:

<<
When a function has an inferred error set, that function becomes generic and thus it becomes trickier to do certain things with it, such as obtain a function pointer, or have an error set that is consistent across different build targets. Additionally, inferred error sets are incompatible with recursion.

In these situations, it is recommended to use an explicit error set. You can generally start with an empty error set and let compile errors guide you toward completing the set.

These limitations may be overcome in a future version of Zig.
>>

What I am not sure about is if "explicit error set"s allow you to assign the error codes by hand. I would assume you can, since error sets are just special enums.

Other than that, I find it great making the compiler aware of returned errors. In general, Zig looks very promising to me, and I would like to start using it in embedded, as soon as time permits (I normally have to work with 32kB/64kB chips, and things like Zig "comptime" may help with some optimizations better than endless macros)