50 years later and we are still asking "To C or not to C, that is the question" personally i dont like nanny compilers telling me how to write, warnings are much more helpful to nudge me in the right direction.
See this explanation, this is why.
So many system bugs are because of unclear memory ownership, buffer overflows, and race conditions. C/C++ don't help you avoid any of these footguns. Any other system that relies on GC is non-deterministic and prone to mystery hiccups, which is why OS and driver tech has been pretty much the same foundation since the 70s.
Rust lets you avoid 2 of those 3 issues (thread race conditions are still a thing). And being compiled, instead of interpreted bytecode means you can get reasonable performance on smaller machines. No wonder these OS guys are so excited.
Yup. Most of my career has been working on embedded realtime software, so interpreted languages are right out and really only C and a subset of C++ are available. I’ve now been using Rust in that way for about nine months now and while the syntax is sometimes silly feeling, being able to not worry about some many other issues has made development much better.
Rust would be better if the rust community wasn’t so up everyone’s ass about using rust.
Attacking the messenger because you don't have any good argument against the message?
This is the Linux kernel project, one of the technically most conservative projects in the FLOSS community.
Rust is C++ with nanny nags, and immature libraries, and a lot of improvements that 30+ years of C++ has made obvious today which weren't so obvious back then.
The worst thing about Rust, from my perspective, is that it really seems to push programmers to "multithread all the things" because Rust offers the delusion that you can do that more safely now. Newsflash: all the things do not need to be multithreaded, there's an awful lot of code that's just peachy in a single threaded implementation, thank you very much, and multithreading it is just inviting trouble for no significant gains.
Mostly, a good library on C++ (Qt used to be one of those, but it's started becoming annoying in the past few years) offers a lot of what Rust enforces at the language level. Stick to the library implementations and you're safe. Color outside the lines when the library isn't up to what you need - but do so carefully.
Mostly, a good library on C++ (Qt used to be one of those, but it's started becoming annoying in the past few years) offers a lot of what Rust enforces at the language level.
I like C++, but let's not pretend that's actually true. Qt is completely full of really unsafe APIs, most of them quite old by now. It certainly doesn't offer anywhere close to any safety Rust provides.
Even something as innocent as passing a pointer to Qt's javascript engine can end up in use after free, and the signal+slot stuff goes wrong real fast once you do need multi threading.
(which is not to single out Qt specifically, the STL has plenty of really stupid and unsafe APIs as well)
Kroah‑Hartman consistently framed language choices in terms of reviewer workload rather than developer convenience. Linux has "over 5,000 developers" but "about 150 core maintainers that review the majority of the code," a skew that drives his priorities. "We optimize for reviewers. We don't optimize for developers because we have a lot of developers," he said, suggesting Rust's ability to enforce locking and lifetime rules at build time means reviewers can spend their limited bandwidth on logic rather than bookkeeping: "If it builds as a reviewer, I know it's OK. I can look at the logic."
That's a great point. Living open source code must be readable and maintainable. Rust is an excellent match for that.
I've got a non trivial project in Rust, and it takes like 5 min to compile on my machine. Personally, I don't know how anybody can call this fun. I find it insane to have to wait minutes to see the changes and to iterate. And like sure you can break shit up into crates to speed up compilation, but to do that you already have to have a design you're happy with and that's stable.
I find it insane to have to wait minutes to see the changes and to iterate.
i did devops between 2015 & 2025 and got used to the cadence of waiting between 15 & 180 minutes for testing/production pipelines to finish vetting the work i submitted to them.
i went back to doing IT last year and setup similar pipelines to update the code base my predecessor left behind and my new boss expressed the same consternation about waiting for your changes to iterate.
i'm thankful for it because it gives me 30-ish minute windows to browse and annoy people on lemmy throughout the day. lol
Five minutes with build cache? Or from cold build?
With cache, then there's almost certainly something wrong with your computer or project.
Also... you aren't building with --release every time are you?
5 minutes sounds like way too much, unless you mean a fresh compile. But then you shouldn't need to wait that long between changes, since incremental compilation should kick in then.
And like sure you can break shit up into crates to speed up compilation, but to do that you already have to have a design you're happy with and that's stable.
I mean, if you have your modules structured in a tree structure and with proper visibility, then it isn't a particularly big leap to put it into a separate crate. You just move the files, maybe fix some visibility modifiers still, and then a bit of boilerplate to add it to the workspace.
It's only really when you're publishing to crates.io, that you don't particularly want to keep changing the names/scopes of the crates, as they'll stick around on there for the foreseeable future.
I recall looking at mold, but it didn't end up helping much in my case. And haven't looked at sccache, that might actually help if it can cache compilation incrementally in an intelligent way.
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0