> My current take on this is to view Jai/Zig/Odin/etc. as attempted C forks, quite often motivated by hubris and coming with the usual inconvenience of forks, a lot of wasteful/redundant efforts put into small islands, each ruled by their own "benevolent" kings.

Didn't Rust do the same thing? We only call efforts wasteful until they become mainstream, then in retrospect we call it excitement driven prudence.

Anyway, is there an "Odin for C programmers" short guide, so I can learn it more quickly?

Rust is a bit different, more like a C++ replacement and heavily focused on so-called memory safety, but with IMO many bad design decisions, while I consider Zig/Jai/Odin as merely "meh" I think that Rust is bad.

Can you comment you some of these decisions in Rust that you feel are bad? I enjoy the language and have done quite a bit of work with it so I might be blinded/biased. I feel some warts here and there (async fns, anyone?), but overall the thing works and `cargo` is really a blessing.

Horrendous compilation time. Unnecessary complexity everywhere, basically C++ but worse.

There's a lot less complexity in Rust than C++. Compilation times are mostly due to lack of compiled code reuse, which is bad but not unsolvable.

> There's a lot less complexity in Rust than C++.

Eh, I don't know, I don't think so absolutely. I think in the general "application" paths yes there's less complexity but as a language overall, no.

The thing is Rust has all the same capabilities of C++, that is to say, everything. With that same strong emphasis on free abstractions - meaning, abstractions that do not cost anything more than if you wrote the implementation yourself.

Templates and stuff are a rabbit hole but if you go down the path of procedural macros and generics in Rust it's more of the same. It gets crazy, wild, and super complex. But most people don't have to worry about that, because these sort of "squeeze every last bit of juice" features are most useful for library authors.

What about Rust's memory safety story justifies the "so-called" qualifier?

To be clear, the design is pretty solid. But the marketing and storytelling around it is BS.

This should be called hardening and the whole "unsafe" thing is also detrimental. Computer security and exploits is a highly complex topic, there are no silver bullets. Rust code is safer to some extent, but not "safe" from bugs and exploits.

> the problems they try to solve are not painful enough.

The lack of safety is not painful enough? There is an entire industry (i.e. job sector, training, expertise) that evolved to try to thwart bad actors abusing unsafe languages.

But neither Zig nor Odin solve this problem. The only serious attempt is Rust.

Rust is super heavy handed in how it does it.

See. Rust fans are often naïve believers in silver bullet solutions.

Computer security and exploitation is a complex and difficult topic.

Bad actors are looking for vulnerabilities to build exploits, some are related to memory corruption but many of the most sophisticated ones are not.

All programs are potentially unsafe, regardless of the language. Using a language like Rust can help to some extent, but it won't be sufficient if the programmer is too ignorant about code hardening.

You can't replace experts with the flip of a switch.

C replacement languages have been a thing for decades, since 1978 if we don't count its predecessors, unfortunately UNIX/C is hard to beat, thankfully there is also Typescript for C, aka C++.

I am similarly sceptical, but that's not to say these new languages cannot teach us much. I don't know if Zig or Rust would ever become as popular as C++ -- the odds are certainly stacked against them -- but they both have novel approaches that could, perhaps, introduce some ideas into programming that one day may make an impact.

I feel many of your sentiments, and suspect that many C successors fail, because they don't want to just look like an evolution of C in the same way C with Classes did.

No one is out here building C with Safety.

WG14 could design such an evolutionary path, it has been obvious since 1980's, however they clearly aren't interested.

Yeah, it's really disappointing. I think the general attitude is to use calls to functions that are safe and to use instrumentation, which I get, but it results in these piecemeal fixes over the years.

If only such functions would exist, instead of pointer + length.

Odin just hasn't been in the same league performance wise as rust, c, c++, zig. For these types of languages it's important.