Really? Do you get compile time deterministic memory management while being much more high level than Go?
There are trade-offs, rust makes one, use it if it makes sense but these comparisons are just pointless. This whole thread is filled with such arguments. Sure use OCaml, Haskell, Go whatever suits your needs. But let's not pretend that they achieve at compile time what rust does.
Somebody is complaining about compile time, somebody says GC alternatives exist. No, if you are getting into Rust you pretty much know the trade offs. It's on you if you choose Rust somewhere where a GC, REPL providing alternative would have been enough. The miracle of Rust to me is that I usually find Rust high level enough to not have to bother with the alternatives most of the time. I would write my UIs in flutter and my web frontends in TS. I am under no illusion that a GC language would not be more productive in most cases.
> Sure use OCaml, Haskell, Go whatever suits your needs. But let's not pretend that they achieve at compile time what rust does.
Are you talking specifically about the memory use of rustc vs. ocamlopt? Or do you mean that rustc is faster than ocamlopt at compiling a similar program? Or are you saying that rustc does more work than ocamlopt because of the borrow checker?
Rob Pike did intend Go to be a C++ replacement for some use cases:
I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care.
Rust is its own thing that may share some niches with cpp, but it does not replace it. I would really have to care about memory safety a lot to pick Rust over Zig (for example) as a cpp alternative, but then if I really care about memory safety I might pick something other than Rust as well. When it comes to performance, you will probably end up needing unsafe anyway, which raises the question of why you should write an entire application in Rust as opposed to mixing a simpler and slower safe language with a simpler unsafe language for performance.
When I write Rust code most of my errors typically get caught by my language server. Unfortunately, this doesn't help much with making builds faster, though it may reduce the number I may have to do.
…perhaps you lack experience of a time where fixing bugs that cannot be effectively discovered using tools available in other languages took less time than the equivalent code in Rust would take to compile?
Yet all the tools that exist still don't prevent memory safety bugs found regularly in pretty much any C codebase. Using safe rust will be a productivity boon because of its type system, crate ecosystem and memory safety.
> Yet all the tools that exist still don't prevent memory safety bugs found regularly in pretty much any C codebase.
They can help, but I am well aware of which kinds of bugs existing C tooling cannot catch. I still take issue with your opinion, which hold through this thread, that claims that productivity gains from not having to track these down necessarily outweighs Rust's compile times.
