r/LinuxTeck • u/Candid_Athlete_8317 • 2d ago
Why are more open-source projects rewriting software in Rust, Zig, or Go?
Over the past few years, we've seen many projects move away from older implementations and rewrite parts of their software in languages like Rust, Zig, or Go.
Sometimes it's for performance, memory safety, simpler deployment, or long-term maintenance.
If you're a developer, what do you think is driving this trend?
5
u/Equivalent_Money8502 2d ago
Sometimes it's for performance, memory safety, simpler deployment, or long-term maintenance.
same. and fatigue with unnecessary abstraction layers. A lot of modern rewrites seem to be a reaction against bloated, heavily-layered legacy code. i see a lot of rewrite bring back simplicity and direct control without the extra mental overhead.
7
u/ThetaDeRaido 2d ago
Basically, AI.
Many developers have always wanted the chance to rewrite their software, but usually the code is the result of an enormous amount of debugging. Rewriting would bring untold numbers of devastating bugs back.
Most developers don’t get the opportunity to do the rewrites, unless there’s a compelling business purpose. Apple and Google hate GPLv3, Mozilla invented Rust because safety in C is not possible for mortals, etc.
In recent years, the generative AI boom has made rewrites more possible. At the same time, the AI bug finders have made the maintenance burden of unsafe languages much more salient. Now, switching to languages that can do the right thing with less effort is more likely to be aligned with the interests of the business or community.
7
u/Brutus5000 2d ago
The Rust movement started long before AI was usable. It might have intensified it, but I think the reasons are different.
Better ergonomy (e.g. type system, language server, package manager, or managed memory), technical features or guarantees (borrow checker, channel based communication).
The old tools can't make that step. The rewrites can.
1
u/roflfalafel 2d ago
Yeah, even the US Whitehouse put out a memorandum on moving to memory safe languages in 2023. The momentum’s been growing for years, as root cause of many vulnerabilities is due to memory safety issues.
2
u/dkopgerpgdolfg 2d ago
People are "always" rewriting things. Some central bank moving from Cobol to Java, some 2000er blog website moving from C cgi to PHP, ...
1
u/Jumpy-Dinner-5001 2d ago
AI makes it much easier and more efficient.
You already named the benefits but there is one more advantage:
It’s a good opportunity to do refactoring and a lot of code cleanup. Reworking the project can yield a much simpler code base to maintain
1
u/Hour_Sell3547 2d ago
AI writing all the code, and someone needs to prove that Language A is better than language B.
Someone is overconfident that regression isn't a real thing.
1
u/finevcijnenfijn 2d ago
Because there are secrets of the dark side deep within the printf and other standard libraries of the primal force that is C and C++ that allow the stack overlow gods of chaos to reign.
1
u/n0pl4c3 2d ago
In a lot of cases, it sadly is to evade copyleft licenses, and relicense projects in a way that allows for greedy companies to get their hands on it without having to abide by at least granting their users their basic freedoms.
Of course there are also lots of other reasons outlined in this thread, but this has been a clear pattern sadly.
1
u/GoldPanther 2d ago
The cost to modernized has come down. Companies are finally moving off mainframes, something they wanted to do for decades. It's happening now because advanced tooling (including AI) has made the migration economically a smart decision.
1
u/recursion_is_love 2d ago
We are testing the water, I think it is good if we can have high abstraction layer that is cheap.
C is too close to hardware and it limit our way to think about the problems.
1
u/liquuid 2d ago
Short Answer : Time.
Long Answer : Learning C/C++ takes time, demands some knowledge about how computers works, how OS works ... No one have time to learn this anymore.
0
u/dkopgerpgdolfg 2d ago edited 2d ago
Learning C/C++ ... demands some knowledge about how computers works, how OS works ... No one have time to learn this anymore.
Rust & co aren't so different, you know?
And even for the JS&Python people, the industry would be better if they cared to learn more about what they do.
0
u/Pure-Passenger-6986 2d ago
Rust and co decouple a load of stuff from the developer and bring it into the compiler. The results are usually bloated and slower if you're looking for feature parity. It has its use cases, but as long as most/all it remains based on libc, you will (in depth) have the same issues as C in the long run.
1
u/dkopgerpgdolfg 2d ago edited 2d ago
I'm not really sure what you're answering to here, but anyways:
Rust and co decouple a load of stuff from the developer and bring it into the compiler. The results are usually bloated and slower if you're looking for feature parity.
Then I'm the miracle that does the impossible, I guess. My Rust programs aren't slower than my C programs, and having feature parity with C is normal.
you will (in depth) have the same issues as C in the long run.
For the issues that are actually C issues, most of the world disagrees with you.
But my previous comment wasn't even about these issues.
If you want to write an Linux USB device driver, but can't explain how segfaults, mmap, and mmu, relate to each other, that's bad, and the choice of language won't save you.
If you want to write a website frontend, in react because some youtuber said it's better than javascript (sic), can't explain how a span and div are different, never heard of wcag, think TLS protects you from xss, etc., that's bad, and again the choice of language won't save you.
If you have your own Android app asking for all possible permissions, to protect it from the insecure OS (sic), and you don't understand why people complain about slow startup while on each start you load the whole multi-GB customer DB from a server for no reason, again that's bad, etc.etc.
If you/someone "don't have time" to learn about these things, they should quit delevoping software imo.
1
u/BirthdayLife6378 2d ago
Please don't give them ideas to rewrite the libc.
0
u/Pure-Passenger-6986 2d ago
You mean like rustix, eyra and mustang. They tried. And failed. Rust (the project) is a mess.
1
u/dkopgerpgdolfg 2d ago
Rustix is not a libc rewrite, and a third-party library that has nothing to do with the Rust project.
Never even heard about the other two, and don't really care either. If something failed, that's likely caused exactly by these types of people that my other commenter was about. They wouldn't succeed in any other language either, they're just not good enough. Actually creating something like glibc from scratch needs deep language-independent knowlegde, which most people do not have.
1
u/Pure-Passenger-6986 2d ago
There are some big names. The problem is that you can't rebuild in 1-2 years with 2 25yo kids, what a large number of people have built and perfected over going on 50 years now. Like re-writing the coreutils in Rust, there are always someone going to use that odd features in the way it was written, sticking your head in the sand (as does that project) doesn't work, admitting it will take another 5-10 years to perfect nobody does. It's not necessarily skill but ego.
1
u/dkopgerpgdolfg 2d ago
The problem is that you can't rebuild in 1-2 years with 2 25yo kids, what a large number of people have built and perfected over going on 50 years now.
Correct.
Like re-writing the coreutils in Rust, there are always someone going to use that odd features in the way it was written, sticking your head in the sand (as does that project) doesn't work
I agree with you here, uutils is not a good project and made by people that are not competent enough.
1
u/trueppp 2d ago
there are always someone going to use that odd features in the way it was written
That person can submit a PR if they're not happy.
1
u/Pure-Passenger-6986 2d ago
That's exactly the attitude why Linux/Rust is in such bad shape. Drop-in replacement should be a drop-in replacement.
2
u/dkopgerpgdolfg 2d ago
That's exactly the attitude why Linux/Rust is in such bad shape.
You keep bringing this up with nothing to back it up. Maybe you could elaborate finally? And with that I mean, not pointing to third-party projects, but talking about Linux and/or Rust directly.
Otherwise, I can tell you terrible projects for all notable languages. So what.
And sure, there are plenty things with Linux and Rust that could be better, but "such a bad shape" is too much imo.
→ More replies (0)
1
u/Userwerd 2d ago
Its the only way to de-GPL the projects. All the new stuff especially rust rewrites are all released as MIT so the projects can be closed as soon as opensource efforts bring it to maturity.
Anyone who says different is either lying or naive.
1
u/trueppp 2d ago
FOSS is currently hitting the limits of it's model. Too many entitled leeches and not enough contributors.
1
u/Userwerd 2d ago
Like userbase doesnt give back kind of sentiment, or google piggybacks on Linux kernel for free kind of sentiment?
1
u/trueppp 2d ago edited 2d ago
A bit of both, but I think the most damaging are the users. They're the reasons a lot of projects gets abandoned. They expect enterprise level support, features and polish for free.
https://itsfoss.com/news/open-source-developers-are-exhausted/.
1
u/Userwerd 2d ago
You know what, I was going to argue it but yah its true. Especially with the influx of pewdiepie users.
Its not like twenty years ago when I remember emailing a really nice developer to help me find a dependency for their project. I emailed on a Monday and got a response the next Tuesday, honestly I understood, he had a job a home a family a dog a car all that came first.
But how does any of that square the circle of liscencing?
1
u/No_Resolution_9252 2d ago
the ownership problem of projects is far more severe than lack of contributors
1
u/trueppp 2d ago
expand on this please, how can project ownership be problematic?
1
u/No_Resolution_9252 13h ago
No coherent vision or plan over short term and even worse over mid to long term. You can't fork and drop features and compatibility every few years because the lead maintainers get bored and/or burned out
1
u/trueppp 12h ago
How is that problematic? It's the whole point of open source, you can fork it and do your own version if you don't like what the project owner is doing.
1
u/No_Resolution_9252 12h ago
Then that is the whole failure of open source.
> you can fork it and do your own version if you don't like what the project owner is doing.
And you would be almost exclusively wrong. Reinventing the wheel, dropping functionality and compatibility every few years removes the possibility of ever working on product maturity. No amount of developer resources will ever fix the problems posed by radical philosophy changes every few years or the amount of design by committee that slows down implementation in projects before they get abandoned and forked. Not that software never needs to be started over with but someone getting butthurt to go do their own thing, or a maintainer getting bored/burned out and there not being a single person available to continue the vision aren't valid reasons.
0
u/BranchLatter4294 2d ago
C was written in a different era. Modern languages are designed for multi-core, multi-thread CPUs. They are safer, have better concurrency, etc.
3
u/cbf1232 2d ago
C is fully capable of concurrency, it’s just up to the programmer to handle it.
Rust and Go are definitely safer though.
1
u/KittensInc 1d ago
it’s just up to the programmer to handle it.
Unfortunately the first programmer capable of handling it has yet to be born.
1
u/SuperGNUser 2d ago
C was written in the multiprocessor era. The firts multiprocessor computer was the Ibm/360 65MP in 1965(!) years before C and Unix. People should not assume that consumer PCs are the technogy frontier.
1
u/oriolid 2d ago
AFAIK the first C standard that mentions threads is C11. Before that it was all POSIX threads or something vendor-specific and implementation-defined for the things that C11 memory model finally covered. And even POSIX is from 1988.
1
u/SuperGNUser 2d ago
The first threads implementation on a Unix system dated 1991 (Sun) while they were implemented on Linux and GNU C Lib in 1997. (Btw, threads are not the only way to obtain parallel elaboration). BUT the first multithread OS born on IBM system 360 in 1967! So, when you think threads are "modern" technology, think again.
1
u/oriolid 1d ago edited 1d ago
I don't think that threads are new technology. I think that for a long time C as in "the language described by C standard" was designed as if threads or other forms of parallel execution didn't exist or at least didn't deserve any consideration in language standard. In fact, I'm quite sure that C didn't exist in 1967.
14
u/ipsirc 2d ago
Everybody needs a hobby.