Python makes me want to pull my hair out though. Full blown virtual machines make running it tolerable, but the language's inconsistencies... though, I keep trying because I'm hoping theres patterns I don't see.
Python's popularity is an accident of timing. If you're digging deep for wisdom and gold nuggets you're not going to find any. The gold of python is the surface level stuff. Easy to type for hunt-n-pec typers. Press tab to indent is easier than {}.
That's all it took for an army of noobs who wanted to be "hackers" to choose Python. Then they grew up, got real jobs and brought Python with them.
The main problem I hear in deep systems work is that it’s harder to find qualified and interested candidates to work on older components. Recoding these in rust is a reasonable way to overcome this issue and build up junior staff. Many large systems shops are also of the opinion that fixing C/CPP to do what they want going forward is impossible, and are simply tired of keeping *hundreds* of engineers on staff to fix sig11 crashes and other C/CPP specific issues.
If the number one problem for your business is dealing with c/cpp specific crashes, or you desperately need threading/async - then perhaps rust is right for you? Maybe ai will enable this conversion.
while CPP offers exceptions/threads/coroutines, the interaction of these features can lead to undefined behavior. Requiring that the entire code base follows your convention. Older code bases often use older patterns like forking, global variables, making modern patterns incompatible. See the callouts on object destructors for try/catch as an example https://en.cppreference.com/w/cpp/utility/program/longjmpThat is not even close to true.
In Go or C or C++ I have to respect comments that say “make sure to hold mutex foo before calling this function!” In Rust I don’t, the type system enforces it at compile time. That alone is a huge difference and there are many differences like that.
At a time when relicensing and other rug pulls are making headlines I find it disturbing that so many developers are going with "permissive" licenses for their recreation of things in Rust.
Edit: not technically relicensing, which would not be legal. They are writing functional clones from scratch under a new license.
If you can prove they copied code, sure, it’s derivative. If you can prove they started from a fork, maybe you have a case. Starting from scratch is about as this is new as it gets.
History has shown that the original tools used the correct license, these new ones are like optimistic clones leaving vault 13.
We known open-source theft (in the non-ironic sense) is common. And we know at least one of the Rust repos had to have its history rewritten due to a license violation of some sort. It isn't a major jump to assume there's GPL-violation in the tool-rewrites too.
Yeah, but if they rewrite GPL tools to corpo-friendly licenses, I'm going to call them corporate bootlickers. Or useful idiots.
Corporations are looking to capture the value of your voluntary labour and sell/rent access to your work for their exclusive profit.
You offer software with no requirement to share changes and nobody shares changes, it's just corpos asking you code for them for free *surprised pikachu face*
Besides, we've evolved a bit since the 90s/00s: the main risk to software freedom is no longer binary blobs but cloud services - and the GPL doesn't save you there. And any license requiring disclosing your coreutils to anyone accessing your computer over the internet would be a massive dealbreaker to most people...
It's a way to get good parts of the community wet and accustomed to the Rust tool chain and form plenty of developers in writing Linux software at scale.
Otherwise, of course, it makes no sense.
Ubuntu is not Linux.
> I’ve also briefly touched upon that at best in the absolute best case scenario a rewritten version of GNU Core Utils in Rust would be able to match the performance of the original implementation. As we know GNU Core Utils are mostly written in C and some C++ mixed in sparingly. So far benchmarks have shown time and time again that at best with a lot of optimizations and tweaks Rust can only ever match the performance of C and in most cases it is actually slower. So the best case outcome of this rewrite is that we get a tool that does the same thing as the original and at best offers the same performance. So what is the actual benefit of this rewrite?
This assumes that the C code is already fully optimal, but it very obviously is not.
https://www.phoronix.com/news/Rust-Coreutils-0.2.2
Of course, I call bullshit anyways. Most Rust vs C comparisons are going to compare similar idiomatic code in both languages, which gives you a nice baseline to compare against. That's useful for determining the baseline performance, which is indeed, "C but a tiny bit slower in some cases", which is due to things like additional checks that can't be elided at compile time (bounds checks, overflow checks.)
However, in practice, Rust provides better abstraction tools than C, which makes more complex optimizations a lot more practical. A good example would be SIMD optimizations. And Rust does this while giving better tools to ensure correctness, sometimes allowing optimal code to be surprisingly high-level (i.e. iterator usage compiling down to surprisingly straight-forward assembly.) (And to be clear, Rust is not the only language that offers better abstraction tools than C, but I do think it is one of the most promising options available. C++ is a mess, but it does work. New options like Zig are interesting but still need more time to mature.)
Ultimately, I do personally think that Rust coreutils is not very important in terms of safety. GNU coreutils does not really suffer from any particular problems that uutils solves. But still, it's a really good test case for Rust, and it does definitely open up some opportunities for better performance and correctness. Plus, I'm sure uutils will find itself in many places, such as places where GPL-licensed software can't really go (which may very well be a net negative, but I'm stating the fact here) or new operating systems that are based on Rust and want to keep as much stuff as possible free of requiring a C toolchain.
Yeah, there's a lot of crusty old C code out there which has fallen way behind in performance, but everyone still uses because it's proven to be robust by C standards and replacing it would be tempting fate. That's how you end up with zero-unsafe Rust PNG crates outperforming the canonical libpng, for example.
https://old.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...
In practice it's of course more complicated. Any rewrite will also introduce a lot of bugs, so short-term the rewrite will probably have a negative result. I think it's a weird decision for Ubuntu to switch to uutils when it is still incomplete and probably buggier than the GNU version, but perhaps in the long run (5+ / 10+ years?) it might turn out to be the better option.
It's also important to keep the wider ecosystem in mind. Even if C and Rust were functionally identical, a rewrite could still make sense. Imagine if coreutils was written in a language like COBOL: the language choice would severely restrict the number of potential contributors. Who's going to learn it solely for the thankless job of maintaining boring tooling like coreutils? With the current generation of OSS maintainers slowly dying off, you need to recruit new (younger) developers to take over. If all the kids love Rust and hate C, then perhaps a switch to Rust might be a necessary evil to ensure we'll have well-maintained coreutils for another generation. You still need to be careful to avoid the fad of the day, but I think it's pretty clear by now that Rust is here to stay.
As an aside, as [1] shows, the "it'll at best be equal" argument is factually incorrect. There is no good reason to believe that GNU coreutils could not possibly be improved upon.
As you note (and I agree) Rust eliminates a whole class of potential bugs that are proven to be probably the primary vector of CVEs and we live in an era where that's simply unacceptable for core infrastructure. Heartbleed was one very public example. But these memory safety bugs are traded on the black market and end up in tools like Pegasus to spy on (or even kill) politicians and even journalists.
IME people an incredibly warped view of just how subtle and easy it is to introduce a memory safety bug. I think people think it's just bounds checking arrays and buffers. It's not. Writing any kind of multithreaded code (ie anything using primitives like mutexes directly) is incredibly error-prone. When you add in heteregenous cores and out-of-order processing it gets much, much worse.
There's a large company I know with many bright engineers who contributes heavily to tools like valgrind and asan. This is a company with a lot to lose and is deeply concerned about security. Somebody came up with a valgrind check and ran it over their C++ code base and, lo and behold, found issues that had been dormant in their code base for up to a decade. None exploited, as far as anyone knew. But think about it: a decade of checks, automated code-checking, etc had all missed some of these bugs.
People like to complain that writing correct Rust is hard. Thats's true, particularly for novices. But you'll get better. Thing is, writing correct C++ code isn't exactly easy either.
And perhaps writing such code in Rust is hard because writing memory safe code is hard.
The author wrote about why he opposes such rewrites. You might not agree with him but you will get him… once you read the article.
This link[0] shows a CVE with CVSS of 9.8 in 2015 (and a handful of smaller ones). From this other page on the same site[1], it claims that all of all 5 of the CVE's are caused by overflow or memory corruption.
[0] https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...
[1] https://www.cvedetails.com/product/5075/GNU-Coreutils.html?v...
In this incarnation we don't always hear, "Rust is the future."[1] We hear:
* "improving security, ensuring long-term maintainability, and optimizing performance" "memory safety, concurrency, and performance" [2]
* "its ability to prevent common programming errors such as null pointer dereferences and buffer overflows" [3]
* "is that it's very portable." [4]
* "I believe that we should shift the focus away from memory safety (which many other languages also offer) and instead focus on the explicitness, expressiveness, and ecosystem of Rust that is highly competitive" [5]
* "Better error messages.Providing comprehensive internationalization support (UTF-8). Improved performances" [6]
All of these things are operational and thus quantifiable, and some (perhaps even most), are probably true. But none of them engage with evidence-based decision making. Therefore it's not really about any of these, but that's what we've been doing since the beginning of time.
1. Although we do hear this[5].
2. https://uutils.github.io/blog/2025-02-extending/
3. https://bytegoblin.io/blog/the-power-of-rust-on-linux-a-begi...
4. https://lwn.net/Articles/1007907/
leakycap•2d ago