[flagged]
Rust has modern tooling, great IDE support and a language server, nice dependency management, cargo and I could go on. Writing rust makes it imo much easier to structure your code and project as well.
I just recently had to build a medium sized C project. The Makefile alone was at least 700 lines long. In my opinion I also just don't see younger people and newcomers putting up with that when there's a shiny new alternative. And if you want to sustain you have to attract new people and potential maintainers.
Other than that, I agree that the rewriting is mostly not warranted. The thing is, it is about people and not really about code or programming language. If your entire team knows C well and will be able to maintain that project for years to come, it'd be weird to rewrite it all.
You should not. Simple as that. Odds are very good there already is a project that does what you want and you should join or buy that. If you start a new project you have a lot of effort to be just as good as the previous one, and those projects are not standing still.
Okay, maybe it makes sense to start a new game. However you should use an existing game engine not build your own. A few other things like that exist.
Even if your embedded development is targeting a hosted platform with libstd available, whether you link libc will depend on whether you use libc. Thanks to its stable syscall ABI, you don't have to link anything on Linux. But most other similarly situated operating systems require you to link something, whether it be USER32.DLL/KERNEL32.DLL on Windows, libSystem*.dylib on macOS, or yes, libc*.so on (most of?) the BSDs and other UNIX systems. And when libc is not required by the platform, but you do need some of its functionality (either out of convenience or cross-platform compatibility), you can statically link it (including MSVCRT on Windows).
Especially when the "Rust culture" suggests building safe abstractions on top of unsafe building blocks, which tends to keep the unsafe code pretty well-contained to a small section of the codebase. There's plenty of Rust frameworks for microcontroller programming (embassy, etc.) that don't involve much if any unsafe Rust at all.
Kernel is about 3% unsafe code last I checked, which was just a few months ago.
Had no issues using DMA or anything else.
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html : "You can take five actions in unsafe Rust that you can’t in safe Rust .. it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked .. by requiring these five unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs."
There is some rust code out there that is more than 50% unsafe though.
Also, what’s wrong with the syntax? I hear a lot that people find the syntax ugly but I never understood what’s so fundamentally different about it compared to any other mainstream Algol-based language
It's a very productive language once you're experienced.
I'm one of those people who (initially) didn't care about memory safety at all and just wanted a more productive C++, and for me it delivers on that perfectly. Nowadays I even use Rust for scripting, because with the right libraries it's just as productive for me as Ruby and Python can be while being orders of magnitude faster.
I always find it funny when I see the "fighting with the borrow checker" meme, or as you say - "people spend fighting the Rust compiler for a project", where people complain how extremely unproductive Rust is. This is very much true, if you're a beginner. It's a language with a very high skill ceiling (similar to C++).
So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python.
I'd love to see a seasoned Python developer and a seasoned Rust developer comparing the time they spend to solve e.g. Advent of Code. I bet the Python dev would solve it at least ten times faster (developer time, not execution time).
Yes. Once you're experienced enough you naturally start writing code which satisfies the borrow checker and you never really have to think about it. At least that's how it is for me.
> Because that would be a prerequisite for it to be as productive as Python.
It's not that hard to be more productive than Python for a lot of tasks, simply because Python isn't actually the most productive language in a lot of cases, it's just the most well known/most popular. (:
I do a lot of data processing in my scripts, and for many years my default was to use Ruby. The nice thing about Ruby is that things which take 3~4 lines of Python usually only take 1 line of Ruby and are significantly more convenient to do (e.g. it has proper map/filter/etc., nice multiline lambdas, regex matching is integrated into the language, shelling out to other processes is convenient and easy, etc.), which translates into significant productivity savings when you just want to whip up a script as fast as possible.
So some time ago I started writing my scripts in Rust instead of Ruby (because I often deal with multi-gigabyte files, so the slowness of Ruby started to be a problem; otherwise I would have kept using Ruby). And I've made myself a small custom library that essentially allows me to use Ruby-like APIs in Rust, and it's remarkable how well that actually worked. I can essentially write Ruby-flavored Rust, with Ruby-like productivity, but get Rust-like performance.
The above is not perfect. I do sometimes mess up, but it is rare, and that is C++ so I don't get tools/the language helping me.
We are actually looking at a different option: break up our processes and use IPC. There are architecture reasons to do this, but that means the IPC is something we can define and so some of those processes would be all new code that could then be written in rust. Others of them would be small enough that it is feasable to rewrite in rust without blowing the schedule/budget. However that still leave the vast majority of our code as C++ for the foreseeable future.
To be more productive than Python? I almost never have to worry about lifetimes or the borrow checker. And even when I do, I'm still more productive.
I simply don't believe this anymore, based on the number of buffer overflow and memory corruption CVEs coming out of even mature C codebases every year
Also this is a good read from AFL creator lcamtuf: https://lcamtuf.substack.com/p/a-reactionary-take-on-memory-...
To be clear, this isn't time you've spent yourself. You're saying this based on hearsay that other people are struggling with this.
Not that I'd convince you, but this is mostly an issue that beginners face. Folks who can get past that hump enjoy a plateau of productivity.
The times that you do fight the compiler it will suggest the right thing (add clone, add &, add *, import a type or trait).
What insights do you have that makes you more qualified than all these organizations combined? What are they all missing?
This is a perfectly level-headed submission about trying out Rust in some corner of the Linux Kernel. Which you then take as an opportunity to go on this rant... I’ll let people read my conclusion between the lines.
Empirical evidence from the largest software firms in the world who do research on objective metrics on software defects show that there's no such thing as secure C and that Rust is slightly more productive.
I don't think that's true at all. For one, Go has data races, which lead to undefined behavior and memory corruption. For example, appending to the same slice from multiple threads will corrupt its metadata and can lead to out-of-bounds reads and writes.
True, but why should we be optimizing for the first week experience? Your career lasts 40 years.
> Golang has even better memory safety guarantees than Rust
That is not true. What specific example did you have in mind? As an example of something Rust can enforce that Go can’t is not mutating something that’s shared between threads without acquiring the proper lock.
> Furthermore its compiled statically and more suitable for distribution and horizontal scaling.
Rust can be statically linked just like Go can. Not sure what else you think makes it less suitable for distribution and horizontal scaling. There are certainly lots of companies distributing Rust programs and horizontally scaling them so this seems empirically false.
> I am learning Rust myself and I just don’t understand why it’s being pushed so hard.
Because it has a lot of nice features that make a lot of people like it - memory safety without GC, prevention of data races, algebraic data types, etc. No other mainstream compiled languages has this set of features. There’s no conspiracy to “push” Rust. The push is organic. People just like it.
That isn't a fact, that's an opinion. A pearl-clutching, panicky, fact-free opinion framed in terms of "control" which raises questions about who you think should be "controlling" those uppity people who are doing things you don't like.
Seriously - an explosion can be out of control, but other people aren't supposed to be in your control in the first place, right? That's basic freedoms and so on. How is your position any different to any other entrenched social / power structure attempting to control people who want things to change?
What I’ve seen outside these subthreads is just people discussing Rust in the Kernel. No zealotry side-topics about how Rust should be used in place of C or C++ or other such advocacy side-topics.
It’s just embarrasing at this point.
> Creating an entire language to prevent such bugs is excessive, especially given the current state of software security.
I'm having a hard time reconciling those 2 statements. I can imagine any 1 person having one or the other of those opinions, but not both at the same time.
> Meanwhile, the vast majority of security issues (around 98%) come from basic human errors, such as reusing passwords or falling for phishing, not sophisticated zero-days exploiting memory corruption.
We're not limited to doing just one thing, you know. Some people are working on improving the authentication space. Others are working on making it easier for developers to write safe code. Both of those can progress at the same time.
That aside, any solution that involves tooling people have to opt into is doomed to fail. We've seen this a thousand times throughout history: if you require people to go out of their convenience to choose the safer option, they won't do it. It doesn't matter how great the tools are. How cheap they are. How easy they are. If they're not part of the standard pipeline everyone gets unless they deliberately modify it, they won't be used.
You've said a few times that C/C++ have tools that get you most of the same controls as Rust. First, they don't. But even if they did, those tools aren't used by default. Rust makes everyone write code that satisfies the borrow checker whether they want to or not. There's no `-Wborrow-mistakes` flag we have to set. There's not even a `-Wno-borrow-mistakes` flag we can turn off if we get tired of the error message. If you write Rust, borrows are safe, and we don't get a say in it.
You can write C code that satisfies Coverity (where I use to work) and `-Wall` and Valgrind and and and, but the person next to you might not. And as long as it's easier to write unchecked C than to run it through a tester before validation, it won't be as safe as Rust at the things Rust checks. It can't be. Anything that depends on humans to make the safe choice is dead before it starts.
However I don't think adding Rust support, rewriting old, critical components, using Rust for a new project, etc. are bad things. If someone volunteers to rewrite critical components in a way that eliminates (or significantly reduces) one of the most exploited and damaging classes of bugs, while also adding support for said way, then I don't see the problem. If someone opens a GitHub issue on your C++ project telling you to rewrite it in Rust, just close it and move on.
On the critical bugs issue... To exploit a lot of these memory bugs it takes an entire new level of effort. We often need to chain together three or more bugs and land the exploit reliably.. This was much easier to do circa 2001 - 2016 but all the mitigations in place have really raised the bar.. From my experience providing exploits to a red teams that pen-test fortune 500 companies (my previous job at iDefense/FusionX), things have gotten far far more difficult. Rarely needed to use any advanced "sexy kill-chains" (like Chrome or IE exploit) because phishing and other means of network entry were far more reliable and much easier. My point is that study Google released expressed the bugs are dangerous and disastrous, yes, but they aren't the most prevalent risk in the real world. I am rambling a bit. Sorry for poor grammar typing on phone.
The current trend is people rewriting Unix command line utilities in Rust, as a hobby. Nobody is rewriting Adobe PhotoShop or Oracle in Rust.
Can you name some projects which you class as "out of control"?
[I don't use Rust, so this isn't "you should RiiR". Adobe isn't rewriting photoshop in Rust because of some Twitter/tech news hype. And if Adobe is rewriting Photoshop in Rust over the coming decades because of government guidance, is that really "out of control"?]
Is this a troll? Isn’t Adobe Reader one of the easiest pieces of software to exploit because it enables risky features by default and lacks proper sandboxing? Just searching for “adobe reader security vulnerability” brings up a critical software update for CVE-2023-26369 as a top hit which is:
> Acrobat Reader versions 23.003.20284 (and earlier), 20.005.30516 (and earlier) and 20.005.30514 (and earlier) are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
> The claim, often cited from a Google study, that memory corruption bugs pose the largest risk feels exaggerated in this context
Actually this comes from analysis of NIST data which tries to track vulnerabilities and memory safety resulting in arbitrary code execution consistently shows up as the number one issue for C/C++ despite it being a non issue for most other languages. Indeed here’s the vulnerabilities for adobe reader and they’re dominated by memory safety issues: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Adobe+reade...
> Don't even get me started on Rust syntax... I am convinced the syntax was intentionally developed to troll us all with the ugliest syntax on the planer.. I'll stop now before I begin ranting forever.
Rust shows what it takes from a language to achieve compile time memory safety (and the same syntax also provides thread safety) with the performance profile of C/C++. The syntax actually isn’t that hard to get used to and learn and I’d argue it’s easier for beginners since incorrect code will throw an error and explain what’s going wrong instead of crashing at compile time. In the static vs dynamic verification spectrum it costs more static verification. Indeed, from that perspective, why are you even coding in c++? Use assembly if it’s too high level and you don’t like syntax getting in your way or use Javascript so that you can write code that has almost no static checking. In practice rust is waaaaay nicer to write in with a much more mature and reliable project build system that works the same everywhere with a rich ecosystem of tooling that is trivially accessible. The standard library is high performance with a lot of things available that c++ would only dream of with c++ still arguing how to make breaking changes to the language in the standard body, a problem that rust developers don’t even think about (eg rust hashmaps are faster and higher quality than c++ maps).
Said another way. Based on CVEs most of the focus of attackers is on memory safety vulnerabilities which means that regardless of price they otherwise fetch, these are still the cheapest and most valuable exploits to uncover in terms of exploit power / dollar spent.
Not a troll. Just a bit too concessionary to C++ developers. :)