Zig makes handling error easy but makes retaining error information hard. The result is that Zig developers either write more code than other languages to store diagnostic information, or just simply discard diagnostic information. The second makes it much harder to debug because the useful error information is discarded.

About the TigerStyle, it's worth noting that TigerBeetle doesn't even support variable-sized string type. You can store fixed-sized data, such as a string that's at most 32 bytes. What if the order information contains string longer than 32 bytes? Then you need to store that string in antoher database. TigerBeetle is not a general database. Static memory allocation doesn't fit most applicaitons.

The fallable allocation is useful in embedded system and OS development etc., but useless in common application programming, because OOM results in crash rather than failed allocaiton.

But the determinism isn't the real distinction. LLM inference can be made deterministic (temparaute zero, etc.). And multi-threaded compiler can be non-dterministic.

And human developers are also non-deterministic. There is always the nondeterminism even before AI.

I think the real difference is how leaky the abstraction is. If you just need to understand language instead of compiler internal to write correct code, the compiler is non-leaky abstrction. If you rely on compiler to do auto SIMD optimization, and have to do hacks to trigger the optimization, compiler is leaky abstraction.

For AI, if you don't ever need to read the code and AI writes perfectly bug-free program that perfectly follows instruction, then AI is a non-leaky abstraction, but that's not the case for now. To make code maintainable and debuggable you still need to read the code if the project is complex enough.

> If your machine runs out of memory, reversed[i] will cause a segfault upon being accessed. In order to avoid unhelpful segfaults, the program should check for a null pointer and gracefully exit if one is found

If overcommit is enabled (often by default), malloc will not return null when machine runs out of memory. malloc will still return null if input argument is invalid (e.g. too large).

In Rust when receivers all drop, the producer will error instead of blocking, so Rust is better in this aspect.

The Type thing is affine type similar to Rust ownership. The array in-place mutation relies on affinity to avoid deep copying. The Data thing is reference-counted if shared, like Rust Arc. The parallel invocation is similar to Rust's rayon::join .

About the proof system, I am not familar with formal verification, but it's obvious that the translation from business requirement to proof target still requires coding and can contain bugs. Even if proof is fully correct, if proof target deviates to business requirement then it still have a bug

Static memory allocation requires hardcoding an upper limit of size of everything. For example, if you limit each string to be at most 256 bytes, then a string with only 10 bytes will waste 246 bytes of memory.

If you limit string length to 32 bytes it will waste fewer memory but when a string longer than 32 bytes comes it cannot handle.

Because you weren’t suffering from too much work, you were suffering from too little truly important work.

https://github.com/rue-language/rue/blob/trunk/docs/designs/...

No silver bullet again

Sometimes some configuration is wrong and it behave wrongly but you don't know which configuration.

Sometimes it relies on another software installed on system and if you installed the incompatible version it malfunctions without telling you incompatibility.

Sometimes the IDE itself has random bugs.

A lot of time is spent workarounding IDE issues