[flagged]
That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25 years.
In Safe Rust, data races can't happen because you can only share stuff between threads if they are either synchronized or read only - attempting to share data that can't be accessed by many threads results in a compile time error.
Also: Java depends heavily on the GC to have memory safety. There are probably some kernels that manage memory with GCs, but for most of them it's not appropriate.
And even for projects that are written in a language that uses a GC (like written in Python, or Java, or C#), having two GCs in the same project, sharing data between each other, is kind of catastrophic. Because of this, a project in a high level language either uses libraries written in the same language (or at least the same runtime), or languages written in C or C++. So Python programs use Python libraries or C libraries, C# programs use C#/.NET libraries or C libraries. But it's uncommon to use a Python library in a C# project, or a C# library in a Python project.
Just like C, Rust fills the niche of writing libraries that can be used in many ecosystems. Right now some Rust libraries are used in Javascript projects (either on node or on the web, with wasm), for example.
- Java had a pretty slow startup time, which makes it a poor fit for many CLI applications and similar
- Java has historically had pretty poor support for interoperating with c libraries (although this is improving with project panama)
- Rust has a richer, more powerful type system than Java (although scala's is more comparable)
- Rust's affine types (lifetimes) actually prevent certain types of bugs that occur in languages like Java as well. Things like using a connection or file handle after it is closed, forgetting to release a lock, not properly synchronizing access to memory between multiple threads, etc.
[1] https://github.com/capnproto/capnproto/blob/v2/kjdoc/tour.md
For many people, the most interesting aspect of Rust is that it builds into its type system a set of rules that makes it much more practical to avoid memory safety issues or concurrency issues--lifetimes and Send/Sync are an absolute godsend for such programming, especially because it means you get the compiler to kick you in the face when you screw it up. Rather famously, Mozilla attempted a couple of parallel layout engines in C++ but their attempts all failed, because it just wasn't feasible to shake out all of the concurrency issues; their first attempt at doing so in Rust had none of those issues. It's not that the rules are complicated or hard to follow, it's that in large codebases, the invariants you need to uphold are described only in comments and can be easy to forget.
A language that makes it impossible to introduce 70% of the security bugs is appealing.
So why Rust then?
The interesting combination rust brings is a memory safe language that can compete with C and C++ for the speed crown.
[1] https://labs.oracle.com/pls/apex/f?p=LABS:0:3891254133275:AP...
In those cases we don't have a particular investment in C/C++, we don't know the differences between gcc or clang, we are used to package managers, don't manage header files, and things like comfy error messages and "if it compiles it's reasonably safe tm" are better than... Not having those things.
Meanwhile, outside of things like CUDA interop I don't know what the compelling case for C/C++ even is for someone who isn't invested.
This is not how learning programming languages works
I wish rust had overloading and specialization though.
> I personally invested a lot of time and effort into learning C/C++ and the only new language with enough difference to come along that was worth learning was Python imho. Not sure what significant differences Rust brings that warrant throwing all that knowledge away and starting again.
Ive written a little c++ professionally along with rust. I really don't think rust is that hard to learn. Especially compared to c++, I'd be embarrassed to tell people i "know" c++ despite using it a bit. there's so much to writing c++.
I think you would be a competent rust programmer in a couple weeks, have a pretty good grasp on the language and be able to pretty much contribute to any in progress project.
You could spend a weekend going through the rust book and have a good idea of the language. I dont think I could say that to anyone about any c++ book lol
This is a very important point if the tool is used by millions of people. All you need to do is waste a few 10s of seconds with some weird quirk that doesn’t act as expected, and BAM, collectively easily a year of human life was wasted.
Avoid surprising behavior.
when did that happen?
i thought it would take a long time for colleges to include rust as it has a high learning curve
The two most important/ prestigious universities here, Oxford and Cambridge as I understand it both teach an ML as First Language, teaching Rust would arguably qualify (Rust is basically an ML but with spelling familiar to a C or Java programmer) but with the caveat that one reason they teach an ML first (and indeed so did the place where I got my degree) is that some of the 18 year olds in your class know C or Java or indeed Python, but they almost certainly do not know Ocaml or SML or whatever - whereas they might know Rust.
And that sort of gets to where your parent was thinking. On the whole it's not that university (or "college") teaches Rust, but that because Rust is a good first language some people will have just acquired Rust anyway. I came to Rust as somebody with decades of C and Java and some Python, Go, and a long list of languages, but today plenty of learners just pick up Rust themselves.
In addition, you can't overflow a buffer nor unintentionally read outside the bounds of an array, that will cause a runtime panic and abort the program.
Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm.
Even the most novice Rust programmer who stays in the guardrails will produce programs free of these sorts of memory safety bugs. The same cannot be said about C or C++ programs.
Aren't most of these issues caught in C++ code by static code analysis tools, and even just flipping switches on C++ compilers? I mean, check out tools like cppcheck and address sanitizer. They exist for ages.
Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.
(What's more, Rust is substantially nicer to use than C++. The language, package manager, and compiler are all so much more straightforward than C++ that I would use it for that alone)
I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. I’ve no experience with either language and I can safely say I’d have no idea which switches to “just flip” in the compiler and what tools I should look up to write safe C++ code.
I do know that “Learn Language X” books do not include this information so as to not overwhelm the novice.
That blend of comments is at best grasping at straws. How long do you think a developer stays a "novice"? Does Rust have any problem that prevents developers from learning and improving their skills as fast as any other developers do? Are all Rust projects maintained by novice and junior devs where no one at all can claim to have any senior level skills?
If that's the best argument, that's not an argument at all.
Look, I’m not the one making these arguments, I’m just pointing out that all your objections seem to have been answered already. If you have a counter argument that shows Rust, as practiced, is no safer than C++, then I’d like to see it.
That is a strange takeaway from my post. Of course people care, but the difference is that one language and its toolchain was designed and built specifically to avoid these bugs and one wasn't.
I have been writing C++ professionally since around 2000-2001, and have been working with Rust for about 18 months. For single threaded code, the code I write in both is about equivalent in terms of robustness and stability, but for anything multithreaded, I trust my Rust code's correctness substantially more, even with all the checkers and sanitizers enabled on my C++ codebase.
Would I choose Rust for everything? Hell no, for evolutionary and fast moving code bases like in games, C++ is plenty good enough.
For anything systems related that requires parallelism and robustness, I will 100% stick with Rust.
What definition of "doesn't" do you adhere to? Because there are use-after-free CVEs from Rust code.
https://github.com/Forestryks/process-sync-rs/issues/3
One could say "Rust doesn't stop you from calling out into unsafe C code, so it's still possible to produce memory vulnerabilities in Rust", and it would be true, but it kind of misses the point and only really bolsters the Rust people when they say they want to rewrite everything in Rust.
In Rust, an API with a rule such as "you must check that the mutex is unlocked before you can destroy it" would be implemented using the type system in such a way as to make it impossible to drop it without checking its state. This is something that is not possible to do in C and cumbersome to do in C++.
Feel free to pick an example that tickles your fancy.
But another is that the kind of things even reported is different. There's a case a while back where C++ and Rust have identical APIs which make an identical promise. The obvious way to implement that API on popular platforms introduces a TOCTOU race, and so that race was present in Rust's stdlib and in all three popular C++ standard library implementations. Rust reported the TOCTOU race and its fix, there's a CVE number. The three C++ libraries just decided it's a QOI issue and silently made equivalent changes over the next few months or years.
In C++ the argument goes like this: C++ says that if any other programs are running on your computer, all filesystem access is Undefined Behaviour. Simply do not run more than one program per computer, then there's no TOCTOU race, no bug. Rust says duh, obviously multi-processing has been a thing since the 1960s so we have to assume other programs may be running, the TOCTOU race is a bug and must be fixed.