The allure of new languages vs. the necessity of problem-solving
dayvster.com
dayvster.com
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.
Compare this to Steam's SteamOS, Proton, etc, all of which are built on top of copyleft software, and everyone benefits from it. I'm not a Steam customer or SteamOS user, but Steam's changes to Wine help me out everyday. Similarly, Steam's use of Linux on their Steam Deck has lead to kernel changes that benefit all Linux users with AMD hardware.
Meanwhile, you can't even use modern WiFi or Bluetooth on FreeBSD despite platforms built on top of it all having solved that problem a decade, or more, ago
My point is that you can't rely on the goodwill of corporations when you're building the commons. They will happily wall off the commons you and others cultivated for themselves. They need to be incentivized into being good citizens instead of just mooching.
Maybe if companies were incentivized to give back to FreeBSD, it could be a viable competitor to Linux when it comes to hardware and standards we've taken for granted for the last two decades. That's a world I'd rather live in.
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.
Which repo(s), for those of us who may have been out of the loop?
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...
I think licensing is an important way to prevent those types of abuses, and to maximize users' benefits.
So, evidently, not enough people have been exploited for big $$$ by platforms run on FOSS infrastructure, important parts of which are GPL licensed.
if the ‘growing sentiment’ wants to, they’re quite free to write their own code and use literally any license they want.
disturbingly, i’ve heard more than a few of these people upset because they can’t take our code that we gpl’d intentionally and lock it away stealing it as their own.
How many people do you know, who write open source? If you've been in the tech industry at all its probably hundreds if not thousands. How many of them are okay with the GPL when someone used their GPL'd code in a product (and lets say they even provide an obscure URL with source code for that part of it) and that product is making them thousands if not millions of dollars in product revenue.
Nearly every person I know in that position, have been offended by someone making money off their work, and they don't get any of it. That latter bit is especially irksome in most cases. Usually its some rant of "I wrote that code for people to share, not get rich off of!" or something like that. The "Busybox" story[1] is like the poster child here. Once there were successful lawsuits these folks figured out how to have their cake and eat it to. Read up on the Linksys lawsuit[2]. Forcing compliance costs money (lawyers and such) and time and the payoff is pretty much always to the lawyers and not the people who were irritated their software was being profitably sold.
Contrast that with software that has an explicit non-commercial license but offers a commercial license, that stuff gets licensed and the developers get paid when it does, not a bunch of lawyers.
I realize not everyone has grown up with this stuff, the point I was trying to make (poorly it seems) is that as a legal tool to "protect" developers from having others steal their work and profit from it, I feel like it failed utterly to do that. When the company I was at was acquired by IBM back in 2015 I did all of the license clearance work for all of the software in our stack. People who had "permissive" licenses that offered a way for IBM to license it with legal cover, they got whatever they needed (some wanted a token licensing fee, others a donation to FSF or another non-profit), for the parts that were covered under GPL and not available under a different license, IBM just dropped on the floor because of their history with the whole SCO/Linux lawsuits.
I get that folks want to share their code with folks who can use it, I totally support that. I also know that absolutely nobody wants to be called at 3AM to fix. for free, a CVE that their code has because some Enterprise customer paying the caller is all in a twist. Having language in the license at the start that clarifies stuff like that is essential.
[1] https://torquemag.io/2013/03/busybox/
[2] https://en.wikipedia.org/wiki/Free_Software_Foundation,_Inc.....
GPL use of the code is kosher, if you want to use it without being beholden to the terms of the GPL, you pay for different licensing terms.
That said, the GPL is not always the best license for this and yes, it can lessen the grip you have on extracting profit from code, but the lessened grip is the point of the license.
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.
> 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.
The question is not "is Rust harder than C or C++?". The question is, "is writing correct Rust harder than writing correct C or C++?".
You could even think of it in financial terms: "is the cost of writing correct Rust higher or lower than the cost of writing correct C or C++?".
Another interesting qualification to add on is: "...for someone who doesn't already know Rust or C or C++". If you had to onboard a new team member, and they didn't know Rust or C or C++, which language would you want your project to be in? Which would they be able to safely contribute to the fastest? I know what I'm picking.
Agreed, and I think part of the reason is because they take it personally when someone claims programmers (in general) can't consistently write memory safe C/C++.
The biggest C-based open source project I personally started is https://github.com/acdha/mountstatus. It's a simply utility I made back in the early 2000s when I worked at a place with a lot of Linux/FreeBSD/Solaris/OS X servers using NFS storage and needed the low-level control to have a process be able to reliably scream for help when we hit the various kernel bugs which would cause an entire mount point to hang in a way which caused any normal filesystem operation to hang, which I did by forking a child process and testing whether it stopped responding. Since that stayed in memory all the time and needed to be portable, C was a natural choice and it worked well enough but there were a few features I never worked on because the pain and suffering level of managing concurrency or pushing metrics to Prometheus was a psychological deterrent, especially when I changed jobs and any time spend on OSS was coming out of my hobby time.
At some point I decided to try rewriting it in Rust, and I was happy with the results and cut v2.0 in 2017. It wasn't _that_ much time – this is a tiny project – but the subjective experience was that it didn't feel so much like a chore and not having to worry about things like package management changed how you approached features which should be simple and stayed simple because Rust package management is simple compared to managing C dependencies on multiple platforms. (As a cautionary note, I became a parent later that year and you can see the decline in free time set in pretty hard)
It's very unclear – to me it seems more like there's a vocal minority on people on here commenting on every C post "someone should rewrite this in a memory-safe language".
People tend to forget that C got so popular because it had very simple semantics (with much UBI ofc). Golang is arguably more popular than rust, has much simpler semantics and is much easier to pick up.
In all my years in tech I've rarely seen a more complex tool beat a simpler one (otherwise we'd all be using VMS), I'm not holding my breath for rust's longevity.
Version control beat handing around labelled floppies, despite being far more complex, since it's still easier than managing state by hand.
I wouldn't be surprised if rust replaced C for similar reasons. It might be syntactically more complex, but it's still far simpler than stopping your library from being a beginner pwn exercise at a local CTF.
Language simplicity also isn't that important. Usage-wise you're missing out on a lot of potential features and benefits, and implementation-wise you're not gaining a lot as everyone just writes LLVM frontends these days. If language simplicity was that important, we'd all be writing Lisp these days.
well for a good 15-20 years the jvm had awful startup times which probably was why it was not attractive as a systems language. Does being garbage collected matter for a tool like cat? I would say no
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...
Are they compatible enough yet? Last time I checked uutils wasn't honoring user locales at all.
The input file to the benchmark is all ASCII text chars (unibyte?) and `choose` does take the safe(r?) route and assume all text is UTF-8 and handle accordingly.
0:
| LC_ALL=C | LC_ALL=en_US.UTF-8 | not setting LC_ALL explicitly
-------------------------------------------------------------------
choose | 110.6 ms | 110.6 ms | 110.8 ms
cut | 813.9 ms | 983.9 ms | 971.7 ms
gcut | 172.8 ms | 172.5 ms | 174.0 ms
ucut | 78.22 ms | 79.39 ms | 79.38 msThompson and Ritchie could have used ALGOL, Lisp, FORTRAN, BCPL or PL/I to write Unix, but instead they created C and used that. I guarantee at the time there was someone at Bell Labs bitching about how they should be solving "real problems" instead of messing around with a new programming language.
But more practically, developers write code because they're paid to, or to scratch an itch. If a real problem doesn't substantially bother anyone enough to get solved by a developer, then it's not really a problem.
In general, code maintenance and optimization is always Somebody Else's Problem™. Instead of writing this blog post, the author could have spent that time optimizing some open source code, right?
I personally believe these completely “rewrites” aren’t the right way to do it. I think possibly slowly rewriting portions of code that are problematic are the best approach. But I don’t know how feasible that is when it comes to Rust + C.
Placing people on different sides is unnecessarily divisive. Consider that folks genuinely want to work together and make things better.
How frequently does that happen compared to existing maintainers choosing to incorporate Rust? Off the top of my head I think all of Linux, git, fish, librsvg, and Python's cryptography library involved existing maintainers choosing to use Rust as opposed to "Rust people" "worming their way" into projects. Did you have other projects in mind?
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/
At the same time, every generation of programmers will come in and will want to make a dent in the space time.
Why would a new developer want to use the stuff grand pa wrote ad nauseam? They want to take charge of their own adventure. Not everyone was born when things were exciting and we didn't know where we were going.
New tools likely wouldn't carry cruft that accumulated through time, as the tools understood their own essence, as they changed and morphed over time.
There is a Not_invented_here syndrome at play, with a New_shiny factor and potentially the benefits of cutting down a tool to the essential.
If anything, it's a good learning practice to rewrite existing tool, your way.
Rust does bring advantages, but if they don't learn the past, they're bound to repeat the mistakes made; memory safety only being a small part of the problem, over time (most of these old C tools now have been vetted many times over and are now pretty 'safe').
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.
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.
I’d even risk saying Python’s popularity is one symptom of the AI bubble we’re in.
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/longjmp
That 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 the end of the day, greybeards are going to retire and new generations are not going to want to deal with code bases built around technology and decisions that were made in the 1990s.
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.
Y = Rust
I already mentioned my utility `choose` in another thread but what you are describing was my philosophy in making it. I felt that cut was unintuitive and limited, I saw other people in my workplace having some similar struggles with it, so I created something that is similar but different, not intended by clone it but rather to provide a more suitable alternative.
What do the numbers say?
How many CVEs?
Are there downward trends?
Have these tools stabilized?
Prove it with numbers, and your words will have even more power.
> 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 changing it would be tempting fate. There's a tension between performance and security which doesn't exist to nearly the same degree in Rust, which is why you get instances like this where zero-unsafe Rust can run circles around the canonical C library.
https://old.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...
I just don't believe "pile of old C" is any kind of strong indicator of quality or performance, positive or negative.