Right, but it's only recently that better alternatives have become widely available. Previously your options were:
- Something like Java/C#, but that would have required users of the tool to manage a second toolchain / runtime just for developer tools - quite a hard sell for widespread adoption
- C/C++ which are quite hard to learn (and use correctly once learnt) for users of interpreted languages which ends up being a barrier to their use.
Now we have Go and Rust which are fast, compile to a single binary, and are much easier to learn than C/C++, which is leading to a whole new generation of tools.
The main problem I had when I tried to learn C++ was getting started with the build system. I could compile a single source file easily enough but adding others, and especially integrating with 3rd party libraries was difficult. And there was extra pain if I wanted it to work portably across platforms. Whereas with Rust, building is a simple `cargo build`. And integrating libraries is as simple as adding a line to the manifest file.
The borrow checker wasn't trivial to learn, but I could at least bash my head against the compiler, and be pretty sure that once it compiled my code was correct. With C++ it is much harder to get that feedback while learning as it's very easy to compile something that segfaults, crashes, or has Undefined Behaviour.
It's more that, after years of programming in C++, when I run a program I'm still not confident it's not going to have major bugs, and if a bug shows up, I know I'll be in for a world of pain trying to track it down.
After a few months of coding in Rust, I stopped having that problem altogether. I still ran into bugs, mind you, but solving them usually became painless.
Really? Since about c++14, the number of memory errors I've experienced in practice is asymptomatically trending towards 0. When they do come up, it's usually in some awkward C library that has been badly wrapped, and would likely necessitate unsafe in rust anyway. I genuinely can't remember the last time I introduced a memory stomp, use after free, double delete or slicing issue in a modern c++ Codebase.
It's not about memory safety, exactly. It's hard to convey the difference in how I experienced coding in Rust vs in C++/JS/Python/etc.
The big thing is that the absence of shared mutability means you can be very confident that when you "have" a reference to a thing, you "own" it, and it's not going to change value under you. When a bug came up in a C++ codebase I often felt like it could come from anywhere. In Rust the suspect list was much shorter, which made for a more tranquil debug experience.
(I'm told this is also the experience of people writing Haskell, but I've never managed to read any Haskell code, so Rust it is for me.)
TBF, when a 1.0 is released doesn't mean it's viable right way for things like this. It takes a certain level of market adoption and ecosystem buy-in first.
Also, Zig still isn't 1.0 so if we're measuring languages from when they first became public, I believe those others in your list are much older as well.
Sure, but when these languages first came out they didn't have anything like the library ecosystems they have today. In 2023, you can add a JavaScript or CSS parser to your app with a single line of code. Back then you'd have had to write your own.
- Something like Java/C#, but that would have required users of the tool to manage a second toolchain / runtime just for developer tools - quite a hard sell for widespread adoption
- C/C++ which are quite hard to learn (and use correctly once learnt) for users of interpreted languages which ends up being a barrier to their use.
Now we have Go and Rust which are fast, compile to a single binary, and are much easier to learn than C/C++, which is leading to a whole new generation of tools.