So I second the advise for non-trivial projects, they give a much better idea of the upsides and downsides of rust.
Also, the two aren’t necessarily mutually exclusive. Many people learning the language have reported being surprised by the way Rust seems to make "doing things right" the path of least effort, and this applies to best practices in general, not just memory safety.
Top doc comment: The same license info that's in every file. Not helpful for describing what the module does and how it fits in with the rest of the project.
Many features gained a lot of adoption accross languages over the last two decades, like anonymous functions (with convinient arrow syntax), explicit option types instead of implicit null/undefined, match constructs, well-integrated library management, for(each) loops using iterators instead of indices, map/reduce functional iterators, etc. Rust has the advantage of being able to make these core parts of the language and standard library, resulting in an overall more expressive language.
And in rust's view these features should not only be used to make coding more convinient, but also to encode intent and make undesirable things impossible. This is reflected in the standard library (for example it's impossible to access the data protected by a mutex without locking it), and the philosophy is copied by the ecosystem.
Build tooling for the C/C++ ecosystem is a mess.
https://bevyengine.org/learn/book/getting-started/setup/
The early setup docs offer ways to improve compile speeds. Some help all Rust projects (change your linker) and others are specific to Bevy (enable dynamic linking if you're not on Windows).
Yes, it's a little jarring for an intro to game development with Rust to start with, “first, change a bunch of things so your compile speeds don't suck by default”. But I appreciated it because it helps you evaluate Bevy properly (it's as fast as it'll get from that point) and it also made my non-game Rust project workflows faster.
Bevy also sets expectations well about the initial slow-ish build (“This will take some time as you are essentially building an engine from scratch. You will only need to do a full rebuild once. Every build after this one will be fast!”).
With the dynamic link feature it takes about 1s to compile + link and Bevy is very much a nontrivial runtime/library that makes use of lots of Rust features.
EDIT: I checked just now and it takes one second to `cargo check` the shallowest crate in our workspace, and six to check the deepest.
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.
Coming from C++ rust's compile times don't feel extraordinarily long.
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.
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?
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.
I’ve found this to be highly dependent on the hardware you are using. On my 2015 MacBook Pro, Rust was slow enough to be annoying. On my new M1 Pro MacBook (which is ~9x faster), it’s fast enough for me not to notice compile times.
How slow is "unacceptably" slow?
Personally I do not find this to be an issue the vast majority of the time. Especially in combination with cargo watch which can automatically run a check/build/tests/... whenever a change is made.
I would argue that it's not as bad as it's made out to be, especially if you're not doing full recompiles and using it on modern (2019+) hardware; but it is a noticeable difference in similar large codebases.
That's fair. My comment was mostly about performance.
Additionally thanks to heavy reliance on binary libraries, when starting a new project, we only need to compile our own code.
I know this from observing a ~90s difference between debug and release builds, of a large (mostly auto-generated) crate that had a couple of thousand `#[derive(serde::*)]`s. [1]
This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even if it is a problem, users can opt in to compiling just the proc macros in release mode. [2]
Oh that's interesting. But note that it's an issue caused by (from the perspective of the language) user code being slow, and also only if you compile in debug mode. You probably don't want to unconditionally compile proc macros in release mode, as most times they probably don't get invoked thousands of times. Ideally you would probably a) invoke macros in a parallel fashion, with multiple expansion threads, and b) maybe have rustc signal to cargo somehow that there are tons of invocations of a specific macro and that it might make more sense to recompile the proc macro with optimizations turned on.