6 ms·
Slower compile times are a small price to pay for memory safety and much higher productivity.
by rapsey 4y ago
Slower compile times are a small price to pay for memory safety and much higher productivity.
- saagarjha 4y agoSlow compile times can reduce productivity.
- rapsey 4y agoNot nearly as much as chasing bugs that do not happen in Rust.
- saagarjha 4y agoThat would depend on what you're doing, of course :)
- rapsey 4y agoNo not at all.
- saagarjha 4y ago…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?
- rapsey 4y agoYet 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.
- saagarjha 4y ago> 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.
- Shinmon 4y agoMost of the errors can already be caught by running `cargo check` which is substantially faster than rust. Coming from C++ rust's compile times don't feel extraordinarily long.
- pjmlp 4y agoNot an issue on other safer languages, currently on Rust it is mostly having the focus elsewhere.
- incrudible 4y agoYou can get memory safety and much faster compile times in many other languages, so that is not a valid argument on its own.
- candiddevmike 4y agoI get those with Go and I have blazing fast compile times too.
- eklavya 4y agoReally? 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.
- nequo 4y ago> 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?
- rapsey 4y agoGo is not a C/C++ replacement. Rust is.
- incrudible 4y agoRust 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.