> ease of programming != ease of making undetected mistakes
Disagree. GCed languages prevent the majority of errors the higher complexity of Rust unloads on the programmer to solve by wrestling with its syntax.
So this is only a plus for Rust, if the small performance advantage over, say, Go, actually matters in an application, which is rarely ever the case in most software written.
I'm actually a really big fan of affine types and adts with great pattern matching. The performance is nice too, but I stayed for all the other nice bits that are put together really well (except async, but eventually...).
Rust has been my favorite language by far to refactor in.
Forcing Rust into a domain where a GC'd language is more than enough offers absolutely zero advantages (yes, you'll have no memory safety issues, but neither you would have had you used Python or Java or Go or whatever), and it's the kind of obnoxious overzealousness that I'm denouncing.
If you're using Rust to write web services you're just wasting your time, I agree with that.
But if the alternative would be C or C++, Rust is at least worth consideration. Ironically, those are domains where you'll have to use a lot of unsafe and/or limit yourself to a subset of Rust, but it's still a nice incremental improvement.
> Forcing Rust into a domain where a GC'd language is more than enough offers absolutely zero advantages (yes, you'll have no memory safety issues, but neither you would have had you used Python or Java or Go or whatever), and it's the kind of obnoxious overzealousness that I'm denouncing.
It is refreshing to see that other people share this point of view. I guess we are not disagreeing after all.
> GCed languages prevent the majority of errors the higher complexity of Rust unloads on the programmer to solve by wrestling with its syntax.
The other value that Rust adds, that you're ignoring, is control over mutable/immutable access. In Rust, to share data between threads of execution, you have to grab a lock or such. In many other languages, like Go, the lock is advisory not mandatory, and nothing prevents two threads from writing to the same struct field concurrently.
I personally think I'd really enjoy a "GC'ed Rust" for many uses. I wish GC was a Rust feature crates could opt in to, and then the embedded & high performance crowd could avoid that like no_std works today.
Yup, and if you actually meet a use-case where Rust has a major performance advantage above Go, typically you’re already too deep into the low-level details of optimization that you’ll constantly fight with the borrow checker or just scatter unsafe all over your code.
This is just not true. The experience is typical if you know how to solve your problem in a GCed language and the solution is to solve problems the Rust way, primarily by using handles (and/or arenas) instead of references.
Disagree. GCed languages prevent the majority of errors the higher complexity of Rust unloads on the programmer to solve by wrestling with its syntax.
So this is only a plus for Rust, if the small performance advantage over, say, Go, actually matters in an application, which is rarely ever the case in most software written.