@simon_brooke most of the time i read posts like these and end up disappointed by obvious bias, a lack of depth, or a misunderstanding of some parts of a language or another.

This is true for articles 2. 3. and 4. in your list, but i found 1. to be a surprisingly good comparison. Its higher level, not falling into the trap of comparing individual features which are often different enough they probably shouldn't be compared. Thank you for sharing it.

@simon_brooke as for my own thoughts: I think Zig is interesting, especially for those coming from C, and it might even be the correct choice depending on your project. However, i still highly recommend spending some time learning Rust, if its at all interesting to you and you can manage finding the time and energy for it. Even if you don't end up using it (much), a common statement to hear from people who have learnt Rust and for whatever reason use a different language is "Learning it made me a better programmer in other languages" - its compiler and common patterns teaches a certain way of thinking about code and what to pay attention to thats surprisingly valuable.

Its also the kind of thing where its inherent structure, constraints, and patterns can really click with some people, especially those who excell at recognizing abstract patterns and transferring them to related areas.

@laund I think Rust is the wrong choice for the post-scarcity software environment *because* a lot of what I need to do explicitly in PSSE is to manage memory, to assign processes to processors, and to copy data structures to the processors that need them. I need to be able to do all that explicitly, and Rust wants to do it implicitly. I fear that Rust's memory management and my memory management would end up fighting with each other.

Zig's 'do it yourself' attitude feels like a better fit.

@simon_brooke @laund

Hm. I think Rust requires/allows you to be explicit about memory management and the higher-level abstractions like lifetimes, Sync/Send, are to prevent you from carelessly doing a lot of it wrong. But they are only abstractions to provide guarantees for the compiler. How you implement them at the base level (inside an unsafe { } if necessary) is up to you.