- Instant boot time. Because rust is statically compiled, there's no runtime startup or anything involved with it. From dead to alive is pretty much instant.
- Low memory footprint. Because rust does not use a GC, it doesn't need all the bits and pieces of memory storage that modern GCs require. The memory allocated is (close to) the minimal memory needed to run the application. Further, due to it's low level nature, it's a lot easier to avoid heap allocations all together and instead focus on stack allocations.
- It's safe to deploy and expose to the internet. You'd be a fool to setup a public facing C++/or C application. That memory model is simply too expensive to safely do even if you did want all the benefits of using a system language. Not so with rust. Client facing rust services or even just backends that may see client data are safe to push out.
- It's fast. Rust has no startup or warmup time. From boot it is running just as fast as it ever will be. This means you don't have to have a warmup period or periods of slow runtime as you scale out rust applications. That consistent performance is easy to plan for. That speed and low memory usage have the added bonus of making rust really good if you are trying to optimize operation costs. You can use smaller or less instances to get the same amount of work done.
- The model model not only makes memory safe, it prevents different types of concurrency bugs. While rust won't prevent ALL classes of concurrency issues, it will prevent several of them. That makes it easier to write parallel applications.
Certainly, if none of those things are issues for you, then there's no reason to give rust a second glance. However, I personally see rust as super exciting because of all of those aspects.
> The model model not only makes memory safe, it prevents different types of concurrency bugs. While rust won't prevent ALL classes of concurrency issues, it will prevent several of them. That makes it easier to write parallel applications.
Bringing data to this discussion, many of the big tech companies have found that ~70% of CVEs are due to memory bugs (free after use, double free, etc.)[0], and these are prevented by Rust's model.
> Instant boot time. Because rust is statically compiled, there's no runtime startup or anything involved with it. From dead to alive is pretty much instant.
Dynamic linkage is not the slow part of application startup. The slow part (for applications which are slow) is almost always the gathering of non-compiled assets from disk.
IMO, the lack of dynamic linkage is Rust's #2 weak point, second only to slow build times.
Sorry, that wasn't a dynamic linking dig, but more of a JIT dig.
I agree that rust would be better with dynamic linking. It sucks that you have to build everything when you build one thing :(.
The issue I was specifically thinking of is how slow an untuned JVM can be for startup times and to get to peak performance (It HAS gotten better, but is nowhere near as fast as rust or even python). The default for these JITed languages is to pass everything through a non-optimized code path and only optimize later when the various methods are exercised enough.
Rust has an advantage here in that it doesn't do any sort of runtime analysis to improve performance. It simply is as fast as it always will be.
You can use dynamic linking with Rust. You just have to stick to the C ABI when interfacing w/ shared objects, because there is no stable Rust-specific ABI.
A Rust artifact being used as a dynamically loaded library within a Ruby process via a C ABI is one of the very first, if not maybe first ever, production uses of Rust. You've been able to do this for a long time.
That being said, it is not simple to say, take a binary Rust Cargo project and say "please dynamically link all the crates it uses" or something like that. But if you want a dynamic library to be used by something else? First-class support for that use case exists.
Realistically, three of those 5 points are non-issues for C/C++ devs. The last is only relevant for certain types of workload. So you’re left with one real killer-feature of Rust: the safety. It’s a massive feature that cascades very well into pretty much anything you do... but it’s also one feature really - the benefits of which might not be particularly relevant on large established projects who have probably addressed that problem a long time ago (in their own ad-hoc ways). So the cost-benefit analysis of moving an existing codebase from C/C++ to Rust is not exactly a slam-dunk.
For greenfield, though, my feeling is that one should justify why not using Rust, at this point (when building stuff that was previously the realm of C/C++, of course). If it’s just because of unfamiliarity and initial slow speed of development (as people learn it), it becomes an issue of institutional laziness more than a technical choice.
> the benefits of which might not be particularly relevant on large established projects who have probably addressed that problem a long time ago
It's quite the opposite: the larger a C/C++ project gets, the more problem you are starting to have with safety. Securing and modifying millions of lines of C/C++ code (especially if it's multi-threaded) is a nightmare, and actually impossible, where people are afraid to refactor old code because all the ownership uncertanities.
Rust changes a global ownership tracking problem to a local one.
But if you can’t have a Big Rewrite, you’re looking at meshing Rust and C/C++ - a suboptimal situation for any language, regardless of ease of technical integration, because of the organizational overhead (now you need to hire developers proficient in both C and Rust, rather than just one of them, and have two sets of standards, two sets of onboarding procedures, etc).
To clarify, I’m not arguing that Rust is bad or inferior (to the contrary!), just that the incentives for established projects to move on from C/C++, from a strategic perspective, might not look that massive if they’re only gaining in safety.
Big companies already use microservices to separate programs (and be sane with memory ownership), so the logical way to move to Rust is to write new microservices in Rust.
> addressed that problem a long time ago (in their own ad-hoc ways)
I think it's becoming increasingly clear that "addressing the problem" in C and C++ means fixing all the memory safety issues you know about. Sqlite is the posterchild of careful testing in a C codebase, and they had a serious CVE last year. Realistically, the vast majority of C and C++ projects have more bugs than that, even if they're staffed by experts who take security seriously.
But I agree with you about the cost-benefit analysis. It's not very often that security issues destroy an entire company, and trying to rewrite a large codebase might be existentially riskier more often than not.
I think the more interesting cost benefit isn't moving from C++ to rust. Rather it is moving from Java or Python or Ruby or Perl to Rust.
You'd pretty much never make the move from Java -> C++ because of the lack of safety. But you may want to do it because of the other non-safety features.
That is where Rust is interesting and competitive. It's the performance and memory footprint of C++ with the memory safety of Java.
