this post was submitted on 17 Jul 2026
133 points (97.2% liked)

Linux

66459 readers
459 users here now

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

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 7 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
133
'Rust makes coding fun again': Why Linux is moving away from C, according to Greg Kroah-Hartman (www.zdnet.com)
submitted 1 day ago by HaraldvonBlauzahn@feddit.org to c/linux@lemmy.ml
83 comments fedilink hide all child comments
top 50 comments
sorted by: hot top controversial new old
[–] fubarx@lemmy.world 27 points 1 day ago (7 children)

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.

[–] BartyDeCanter@piefed.social 13 points 1 day ago

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.

load more comments (6 replies)
[–] Artemis_Mystique@lemmy.ml 0 points 12 hours ago* (last edited 12 hours ago) (1 children)

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.

[–] HaraldvonBlauzahn@feddit.org 72 points 1 day ago (1 children)

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.

load more comments (1 replies)
[–] yogthos@lemmy.ml 8 points 1 day ago (8 children)

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.

[–] asdfasdfasdf@lemmy.world 7 points 1 day ago (1 children)

Five minutes with build cache? Or from cold build?

[–] yogthos@lemmy.ml 4 points 1 day ago (1 children)

No, I'm not using --release every time of course. And sometimes it's minutes even with the cache.

[–] asdfasdfasdf@lemmy.world 3 points 23 hours ago (1 children)

That's highly abnormal to have minute long debug build times.

[–] yogthos@lemmy.ml 2 points 22 hours ago (2 children)

for 100k loc?

[–] MangoCats@feddit.it 5 points 19 hours ago (1 children)

100k loc without a reasonable architecture is... problematic.

I have run into problems with C++ linker/optimizers which will choke on big (50k loc) .cpp files which are auto-generated from definitions, they get slow like that, build times around 20 minutes for the worst of them. Keep the files more like 10k loc and down if you don't want this kind of issue.

[–] yogthos@lemmy.ml 2 points 18 hours ago* (last edited 18 hours ago)

Nowhere did I say there's no reasonable architecture. Please don't put words in my mouth. What I said, is that I haven't found a good way to get quick compiles end to end. And already I don't have any files more than 3-4k loc, most are under 1k.

[–] asdfasdfasdf@lemmy.world 2 points 21 hours ago (1 children)

Yeah I doubt it. I've worked in large Rust codebases too. I'd do some benchmarking. Cargo has some nice flags that let you see exactly what it's doing. You can open the compilation report up in a browser and zoom in on different steps of the process and see everything.

[–] yogthos@lemmy.ml 2 points 21 hours ago (1 children)

I've tried looking before and couldn't get a significant improvement. I'll have to investigate it again I guess.

[–] ISO@lemmy.zip 3 points 20 hours ago (2 children)

Make sure you're using a fast linker. Although I think lld is the default now, so that should be less of a concern these days. But see if mold or wild would help.

More relevantly, you should be using cranelift for codegen in dev builds.

If you have codegen-units = 1 in your release profile, make sure you have a separate dev profile that doesn't.

If you still experience decapitating slowness (doubtful), and it's actually the rust compiler being slow (super doubtful), you can try the parallel frontend. Apparently there are almost™ no bugs left in its implementation (It's one of the project priorities now).

Needless to say, but you should be checking your --timings to really know what's going on.

[–] MangoCats@feddit.it 1 points 19 hours ago

The various linkers do make a difference, but all of them choke, eventually, when individual files get too massive.

[–] yogthos@lemmy.ml 1 points 19 hours ago (1 children)

thanks will see what happens

[–] ISO@lemmy.zip 1 points 3 hours ago (1 children)

It would be a cool if you report back in a separate post if you discovered anything interesting. It's not like we're overwhelmed by too much activity here.

Also, while I think it should be obvious, but I forgot to clarify that if you're inheriting from a profile with codegen-units = 1, then you need to set that explicitly to a higher value in the inheriting profile.

[–] yogthos@lemmy.ml 1 points 2 hours ago

yeah, if I find any dramatic improvement I'll follow up

[–] eldavi@lemmy.ml 13 points 1 day ago* (last edited 1 day ago) (6 children)

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

load more comments (5 replies)
[–] iByteABit@lemmy.ml 6 points 1 day ago (1 children)

mold and sccache help a lot with the compile times

[–] yogthos@lemmy.ml 5 points 1 day ago

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.

[–] trem@lemmy.blahaj.zone 7 points 1 day ago (5 children)

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.

load more comments (5 replies)
load more comments (4 replies)
load more comments
view more: next ›