Yes there is much more mental load you pay upfront during development but once you get code working and satisfy the borrow checker you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency.
I understand that, I posted my response becasue the OC was presenting Rust as a replacement for Go but they are very different languages with different tradeoffs
Actually, the Go team even bills Go as a systems language. I think if you're going to consider Go, you should also consider what you could get with Rust.
Sure the upfront investment in Rust higher, Go is almost too small, but the upfront cost of Rust is amortized via the hours you save with all the abstractions and performance you get right out of the box.
I would say if one can write OSes, device drivers, debuggers, compilers, target bare metal deployments on language X, then it is a systems language, regardless of what label people put on it.
The problem with that is it's a narrowing of the 'historical' use of the term and just confuses things further. The Go (and now Rust, it seems) people are right to move away from it.
> you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency.
I agree, but I think many people assume that this is the only benefit achieved. The presence of the borrow checker and rigorous memory safety requirements allows the compiler to take substantially more advantageous paths in allocation/deallocation compared to e.g. C. The benefit attained is similar to the benefit of switching from C to very well memory-managed C++, except it comes by default.
This is a significant advantage even in code that is not concurrent at all. I feel like it's a shortcoming of Rust's marketing, if anything, that the safety restrictions are often pitched only in context of thread-safety rather than memory-usage-optimization.
Yes I agree with those points as well...because Rust is now able to statically have such guarantees, this additional knowledge allows for some great optimizations under the good.
This is the trade off.