Its true that rust needs to be easier to learn. I found it quite hard to learn (still learning), and Ive also seen other experienced programmers have a hard time with rust.
I hope it suceeds though. I’d be happy to leave buffer overruns and dangling pointers behind. I do wonder though, if go will win this race, as it’s mich easier to learn and for many, GC is just fine.
Yes, GC is fine for many people. They can continue to use GC’d languages. The (imo) biggest advancement in the state of the art with Rust is that it brings the safety that users of GC languages have enjoyed for years to a space that’s never had that safety before. Obviously, Rust is the not the first languages to try and bring that safety, but it is (again, imo) the most successful.
GC isn’t about safety, It’s about convenience: you could in theory leak all memory you’ve ever allocated until your process halts, and that won’t violate any basic language abstractions, but of course that’s utterly unhelpful behavior. OTOH, ownership is about safety: using a file that has already been closed is wrong, and a high-level language ought to prevent it.
So there doesn’t have to be a distinction between “GC’d languages” and “languages with ownership”: a language can be both convenient and safe! I’d absolutely love a language where strings, lists, trees, etc. are GC’d (as usual); and files, sockets, etc. are deterministically closed (as in Rust).
I think it’s deeply misguided to view these two languages as being in any kind of competition with each other. Go’s primary use-case is highly threaded network servers where a thick green thread runtime and low-latency GC is ideal. Rust’s primary use-case is bare-metal programming where any kind of runtime or GC would get in the way/be nearly impossible to use.
It’s like wondering whether your chisel will “win the race” against your plane. Different tools for different tasks.
Sorry. I didnt mean to imply direct competition as such. What I meant was, these two languages are often bagged together as the “new systems languages”.
I’d speculate that, in the broad realm of ‘modern systems programming’, for many tasks it doesnt matter if the language is bare metal or not, or uses gc or not. In those cases I’d expect ease of use to prevail.
Of course some domains, like perhaps device drivers, would be better suited to a bare metal language like rust.
Would you agree?
EDIT: And yes. Horses for courses. Absolutely.