No mention of the relicensing going on. All the GNU utilities are GPL licensed.
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.
I have mixed feelings about this. On paper you're of course right and a copyleft license would be better, but in practice I don't think it matters all that much for something as small as coreutils. It's just yet another implementation of a standardized interface, nobody is going to fork it and build a billion-dollar business around it. Any change or improvement is probably worth more when upstreamed than when kept in a proprietary fork, just because your maintenance burden is lessened.
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...
Coreutils licensing is just one part of the amalgamation that prevents the Nintendo Switch-ification (it's based on FreeBSD) of entire free software stacks. Not only do non-Switch users not benefit from changes, the entity that made billions on top of free software then uses that war chest to sue free software developers into oblivion.
I think licensing is an important way to prevent those types of abuses, and to maximize users' benefits.
The "Horizon" OS used on the Nintendo Switch is not FreeBSD-based, it merely contains some FreeBSD code, but is largely, as far as I am aware, a home-grown proprietary operating system not substantially based on any "free" system. The Sony PlayStation 4 (and probably PlayStation 5) actually are substantially based on FreeBSD, though.
But the large volume of copyleft does make it much easier for all the BSD/MIT/X11/ISC ("permissively licenced") stuff to show up in e.g., enterprise Linux distribution releases, under the "we have to do it anyway for all these other packages, so we may as well do it for all the FOSS code that we use" type of argument. There was a kerfuffle with RHEL a couple of years back, where they tried to provide sources only to paying customers. Not sure where that ends up.
Not relicensing at all, just simply adhering to a spec, as the GNU tools do. Can we get down from the soap box now on rewrites? People are free to reimplement anything if there’s a spec and no law against it. Derivative works only works when there is no public record of a specification prior to an IP introducing it. A copyright. IANAL but I’m pretty sure that’s how that works.
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.
Counterpoint: usually there is no spec, and you have to look at the actual tool to figure out what's going on. For closed-source binaries there's a clear escalation between "run the tool and see what it seems to do" and "disassemble the code to really know" (which is supposed to ), but with open-source, the source code is just there to steal.
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.
Sorry, I don't remember any details, just the pain of trying to update forks (and I was only peripherally involved in the ecosystem then, and not at all now).
FreeBSD and Sony's PlayStation, Nintendo's Switch and Apple's macOS/iOS.
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
Don’t bash FreeBSD, it’s not their fault. It’s entirely the fault of the corporations that decided not to trunk their changes upstream for the betterment of the community. Their bespoke flavor of BSD dies with them.
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.
GP’s point is that the corporations would have been forced to open source their changes (thus allowing FreeBSD to incorporate them) if FreeBSD had been GPL-licensed. I disagree of course, as FreeBSD has benefited significantly from corporate adoption —- especially Apple’s porting of FreeBSD userland —- and that corporate adoption would never have occurred had FreeBSD not distinguished itself from Linux by being permissive licensed.
> People are free to reimplement anything if there’s a spec and no law against it.
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*
There is a growing sentiment that the GPL is the one source of the inability to derive economic benefit from doing productive software work. That was kind of explicit in RMS' manifesto, he was pissed off that people were charging $5,000 for a C compiler that "a competent engineer could write in a week", but if you remove all options of collecting some of the value that people who are getting paid by shipping you're code, it not only de-incentivizes development, the entire ecosystem is at risk.
Dual/mutli licensing is one avenue towards effective monetization of GPL code.
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.
this ‘growing sentiment’ has always been there. particularly with the crowd who persistently wants to lock everything behind a monthly subscription or insert hidden data collecting.
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.
The problem is that coreutils isn't done. It is still getting new features - it even had a release today [0]! And if new features are being added, then we're getting new bugs as well. Using Rust eliminates an entire class of rather serious bugs, so in a greenfield environment it would almost certainly be a better choice for a critical project like coreutils.
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.
I guessed the topic from the page title and am glad to second your comment. Your third paragraph is I think is even more broadly true: I'm not _that_ old, I learned C in the 90s, have contributed to some widely-used C-based open source projects (I don't want to overstate this ), etc. but even with that experience, I would avoid working on a C-based project if I had to simply because using something like Rust is so much more pleasant as a developer from better functionality to package management to the experience of using the toolchain. People do that because it's a job, but working on things like coreutils doesn't exactly pay “this is now interesting” money.
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)
> 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.
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.
Plenty of complex tools have beaten simple ones, especially when it alleviates some other form of complexity.
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.
Golang doesn't fill quite the same niche, though: it's garbage collected, for example. I'd personally question whether we need the main pros of C for basic command line tools (that's a topic for another time), but it does explain why we're seeing far fewer "rewrite it in Go" sentiment. If memory safety was the only relevant metric, we would've rewritten everything in Java decades ago.
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.
> If memory safety was the only relevant metric, we would've rewritten everything in Java decades ago.
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
As soon as I saw the submission title I knew "it's something Linux related complaining about Rust" and it was (ie coreutils).
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.
Agreed, and I wish all of the "Rust is hard" people would offer this critique _in context_.
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.
> IME people an incredibly warped view of just how subtle and easy it is to introduce a memory safety bug.
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++.
> as it had basically never had any major security vulnerabilities in its entire existence.
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.
I mean the one bug with the 9.8 CVSS was a denial of service when calling sort(1). That sounds like CVE grade inflation tbh – if you have attackers running sort on your machine they can probably run worse exploits.
I understand there are wider issues here but the reason I personally use the new hotness rewrites like fd or rg or zellij is because they are just straight up better. Better interface, prettier presentation. They have the benefit of hindsight behind them which allows them to really solve a lot of problems with the originals that need to maintain backward compatibility. My only complaint is they are not gpl.
Since the article emphasizes performance so much, I’d have liked to see some benchmarking of the new core utils against the old, instead of the questionable and unsourced claim that “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.”
I tried adding LC_ALL=C as well as LC_ALL=en_US.UTF-8 and it didn't make much of a difference outside of BSD cut[0].
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 ms
Improving legacy software is boring; consequently, less people are willing to do it, and those people tend to work slower. Rewriting a legacy program in a new language may take more work, but because it's more interesting, more people who work faster will do it, such that it takes less time overall.
But at some point, the new rewrites will also become boring when most of the job is done and only the edge cases are left to polish. Will there be enough enthusiasm by then to keep the project on-par with the more mature one?
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.
> The problem with Rust people is that they are worming their way into projects
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?
Language hype always justifies itself through intellectualizing its own desire.
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]
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.
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').
I don’t get why people are so militantly opposed. I get not wanting to contribute to something you don’t believe in but if it’s a good faith effort by others doing the work - let them
Probably due to the small but very vocal group of pro-Rust zealots. "Rewrite it in Rust" has become a meme for a reason - and unfortunately it was more about people demanding Rust rewrites from existing C projects than doing Rust rewrites on their own.
That, and all languages more or less converged to the same functionality with different syntax/naming conventions. They also all offer similar toolchains with similar frameworks for nearly all problems. The remaining places where one language dominates often has it doing so due to extreme network effects and extreme toolchain investments.
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, and all languages more or less converged to the same functionality with different syntax/naming conventions.
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.
Fair enough — you can do that, which is nice, but in Rust it happens automatically. A program that attempts to concurrently mutate the same object without taking a mutex will always fail to compile (unless you hack around this restriction with unsafe) whereas in C++ you have to intentionally build the API that way.
it is funny. I wrote a C# app last week. We mostly do PHP, which I like to call "Runtime Java" these days when using in a enterprise setting. Just as many factories and footguns but hey we slapped a decent OO system on it
And the inexperienced. I got hyped over golang a while back because of go routines. Then I discovered any remotely recent .net version already had what I needed. (I'm a c# dev by default)
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.
> ...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 think it was simply the rise of machine learning frameworks. Python was always advertised as good to prototype, test ideas etc. Then the network effect compounded recently: https://youtu.be/ZTPrbAKmcdo
I’d even risk saying Python’s popularity is one symptom of the AI bubble we’re in.
from the title I thought I was going to find someone agreeing with me that the current LLM craze is chasing natural language processing at the cost of other AI research. ironically I'm a fan of the coreutils rewrite, and the general trend of rewriting projects in more capable languages, I see it as paying future maintenance costs up front.
I think the other side of this is the fetishization of "if it isn't broken don't fix it" and computing conservatism a la the famous Dropbox/rsync comment. An equally valid inquiry is to ask "why should we not replace it", which can lead to some valid and correct thoughts.
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.
"X, but written in Y!" has always been something of a red flag. We don't need rust versions of solid, well-established projects. It just causes strife within those communities (see Linux kernel), confusion for users, and opportunity costs. Want to produce something in rust? give the user something new. Zoxide comes to mind. Love it. Want rust in the kernel? How about a green-field project, like Redox, that does this? This is a better, more productive approach than disrupting well established projects.
I mostly agree, but you may be interested to know that Zoxide is actually "X, but written in Y". Maybe there's some feature set difference but they are the same concept.
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.
Because it's a step towards larger Rust adoption in Linux, simple.
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.
I see it as a way to force Rust on people.
That's almost like saying "You will have to learn some Rust whether you want it or not" to Linux maintainers.
Yes! Why is every company hiring for LLM talent? Companies that have no business doing so. They probably don't even know that supervised machine learning exists.
This is all about destroying free software and allowing "open source" to take over, nothing with memory safety whatsoever. This can sound conspiracy but the main idea is to push permissive licenses, so companies can exploit your work without even mentioning your name. I believe the goal of Canonical and similar companies is to create a fully alternative Linux+GNU environment without GPL/AGPL, push it with embrace, extend, extinguish tactics and eventually create a developer culture that contributing to permissive license parallel project is a better alternative than original copyleft one.
How does it prevent you from licensing code you write any way you want? If those companies pay for a GPL-free linux distribution (kernel excepted i suppose), what's the problem? they paid for the work, they should be able to license it the way they want, and nothing prevents others from using and writing GPL'd software...i'm having trouble seeing the evil here...
That doesn't just sound conspiracy, that is a conspiracy theory. Permissive licenses are a perfectly valid free software option that some people prefer. They are not some kind of shadowy attempt to undermine free software.
First, programming language fads have been a thing since about 10 minutes after the immortal Adm. Grace Hopper came up with COBOL.
Thompson 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?
On one hand, I think it's hype and a waste of time, but on the other, I fully support people doing what they want. On the plus side, it IS a lot easier rewriting things that exist than solving novel problems.
Not really the world's biggest Rust fan, for multiple reasons. However, I find the arguments in this particular article to not be very compelling. The only concrete argument that is actually worth addressing is this one, and it's predicated on a false premise:
> 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.
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.
> This assumes that the C code is already fully optimal, but it very obviously is not.
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.
Yeah, I find the notion that coreutils is so proven and solid that it can't possibly be improved in any way to be utterly ridiculous. And I'm not even saying Rust necessarily has to be the thing to do it.
I just don't believe "pile of old C" is any kind of strong indicator of quality or performance, positive or negative.
GNU core utils are single-threaded. Rust allows safely to use several threads without much efforts. That alone will speed up utilities even if they are IO-bounded. Finally one could stop running double tar instead of cp -a on a huge tree to speed up things when coping big trees.
Yes, but this is a core part of the economy. As soon as we "solve" something, it becomes commodity in a matter of years and the bottom falls out of our current employment/revenue models.
No mention of the relicensing going on. All the GNU utilities are GPL licensed.
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.
I have mixed feelings about this. On paper you're of course right and a copyleft license would be better, but in practice I don't think it matters all that much for something as small as coreutils. It's just yet another implementation of a standardized interface, nobody is going to fork it and build a billion-dollar business around it. Any change or improvement is probably worth more when upstreamed than when kept in a proprietary fork, just because your maintenance burden is lessened.
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...
Coreutils licensing is just one part of the amalgamation that prevents the Nintendo Switch-ification (it's based on FreeBSD) of entire free software stacks. Not only do non-Switch users not benefit from changes, the entity that made billions on top of free software then uses that war chest to sue free software developers into oblivion.
I think licensing is an important way to prevent those types of abuses, and to maximize users' benefits.
The "Horizon" OS used on the Nintendo Switch is not FreeBSD-based, it merely contains some FreeBSD code, but is largely, as far as I am aware, a home-grown proprietary operating system not substantially based on any "free" system. The Sony PlayStation 4 (and probably PlayStation 5) actually are substantially based on FreeBSD, though.
But the large volume of copyleft does make it much easier for all the BSD/MIT/X11/ISC ("permissively licenced") stuff to show up in e.g., enterprise Linux distribution releases, under the "we have to do it anyway for all these other packages, so we may as well do it for all the FOSS code that we use" type of argument. There was a kerfuffle with RHEL a couple of years back, where they tried to provide sources only to paying customers. Not sure where that ends up.
Not relicensing at all, just simply adhering to a spec, as the GNU tools do. Can we get down from the soap box now on rewrites? People are free to reimplement anything if there’s a spec and no law against it. Derivative works only works when there is no public record of a specification prior to an IP introducing it. A copyright. IANAL but I’m pretty sure that’s how that works.
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.
Counterpoint: usually there is no spec, and you have to look at the actual tool to figure out what's going on. For closed-source binaries there's a clear escalation between "run the tool and see what it seems to do" and "disassemble the code to really know" (which is supposed to ), but with open-source, the source code is just there to steal.
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.
> And we know at least one of the Rust repos had to have its history rewritten due to a license violation of some sort.
Which repo(s), for those of us who may have been out of the loop?
Sorry, I don't remember any details, just the pain of trying to update forks (and I was only peripherally involved in the ecosystem then, and not at all now).
Ah, no worries. Does sound like a bit of a pain to deal with.
Not sure this person is claiming code is being copied, but instead claiming there's a bad legal footgun happening.
History has shown that the original tools used the correct license, these new ones are like optimistic clones leaving vault 13.
Do you have examples of undesirable situations arising that would not have been prevented by selecting the GPL instead of a permissive license?
FreeBSD and Sony's PlayStation, Nintendo's Switch and Apple's macOS/iOS.
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
Don’t bash FreeBSD, it’s not their fault. It’s entirely the fault of the corporations that decided not to trunk their changes upstream for the betterment of the community. Their bespoke flavor of BSD dies with them.
I agree with both of your points.
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.
GP’s point is that the corporations would have been forced to open source their changes (thus allowing FreeBSD to incorporate them) if FreeBSD had been GPL-licensed. I disagree of course, as FreeBSD has benefited significantly from corporate adoption —- especially Apple’s porting of FreeBSD userland —- and that corporate adoption would never have occurred had FreeBSD not distinguished itself from Linux by being permissive licensed.
> People are free to reimplement anything if there’s a spec and no law against it.
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*
There is a growing sentiment that the GPL is the one source of the inability to derive economic benefit from doing productive software work. That was kind of explicit in RMS' manifesto, he was pissed off that people were charging $5,000 for a C compiler that "a competent engineer could write in a week", but if you remove all options of collecting some of the value that people who are getting paid by shipping you're code, it not only de-incentivizes development, the entire ecosystem is at risk.
> is the one source of the inability to derive economic benefit from doing productive software work
So, evidently, not enough people have been exploited for big $$$ by platforms run on FOSS infrastructure, important parts of which are GPL licensed.
Dual/mutli licensing is one avenue towards effective monetization of GPL code.
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.
this ‘growing sentiment’ has always been there. particularly with the crowd who persistently wants to lock everything behind a monthly subscription or insert hidden data collecting.
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.
Who specifically is saying this?
It's a rhetorical device. We're not meant to take it literally.
Sigh, serves me right I guess.
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.....
yeah cause charging for floppy distribution is evil, putting mmpeg behind a saas products totally ok!
The problem is that coreutils isn't done. It is still getting new features - it even had a release today [0]! And if new features are being added, then we're getting new bugs as well. Using Rust eliminates an entire class of rather serious bugs, so in a greenfield environment it would almost certainly be a better choice for a critical project like coreutils.
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.
[0]: https://www.phoronix.com/news/GNU-Coreutils-9.8
[1]: https://www.phoronix.com/news/Rust-Coreutils-0.2.2
I guessed the topic from the page title and am glad to second your comment. Your third paragraph is I think is even more broadly true: I'm not _that_ old, I learned C in the 90s, have contributed to some widely-used C-based open source projects (I don't want to overstate this ), etc. but even with that experience, I would avoid working on a C-based project if I had to simply because using something like Rust is so much more pleasant as a developer from better functionality to package management to the experience of using the toolchain. People do that because it's a job, but working on things like coreutils doesn't exactly pay “this is now interesting” money.
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)
> 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.
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.
Plenty of complex tools have beaten simple ones, especially when it alleviates some other form of complexity.
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.
If I understand correctly, in your analogy, golang is floppies and rust is a sophisticated version control system? lol
Golang doesn't fill quite the same niche, though: it's garbage collected, for example. I'd personally question whether we need the main pros of C for basic command line tools (that's a topic for another time), but it does explain why we're seeing far fewer "rewrite it in Go" sentiment. If memory safety was the only relevant metric, we would've rewritten everything in Java decades ago.
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.
> If memory safety was the only relevant metric, we would've rewritten everything in Java decades ago.
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
As soon as I saw the submission title I knew "it's something Linux related complaining about Rust" and it was (ie coreutils).
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.
Excellent comment.
Agreed, and I wish all of the "Rust is hard" people would offer this critique _in context_.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.
> IME people an incredibly warped view of just how subtle and easy it is to introduce a memory safety bug.
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 C\C++ memory model is simply not suitable for creating secure internet connected software.
> as it had basically never had any major security vulnerabilities in its entire existence.
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...
I mean the one bug with the 9.8 CVSS was a denial of service when calling sort(1). That sounds like CVE grade inflation tbh – if you have attackers running sort on your machine they can probably run worse exploits.
I understand there are wider issues here but the reason I personally use the new hotness rewrites like fd or rg or zellij is because they are just straight up better. Better interface, prettier presentation. They have the benefit of hindsight behind them which allows them to really solve a lot of problems with the originals that need to maintain backward compatibility. My only complaint is they are not gpl.
Since the article emphasizes performance so much, I’d have liked to see some benchmarking of the new core utils against the old, instead of the questionable and unsourced claim that “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.”
In the past few days I've been benchmarking my own tool `choose` against BSD cut, GNU cut, and uutils cut and the uutils cut is certainly faster than BSD or GNU versions: https://github.com/theryangeary/choose/blob/master/benchmark...
The benchmark is against unibyte text. You would get more accurate results by doing `export LC_ALL=C` in your benchmark script
I tried adding LC_ALL=C as well as LC_ALL=en_US.UTF-8 and it didn't make much of a difference outside of BSD cut[0].
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:
> I’d have liked to see some benchmarking of the new core utils against the old,
Are they compatible enough yet? Last time I checked uutils wasn't honoring user locales at all.
Yes cat, top and ls not being fast enough is driving me nuts. /s
Improving legacy software is boring; consequently, less people are willing to do it, and those people tend to work slower. Rewriting a legacy program in a new language may take more work, but because it's more interesting, more people who work faster will do it, such that it takes less time overall.
But at some point, the new rewrites will also become boring when most of the job is done and only the edge cases are left to polish. Will there be enough enthusiasm by then to keep the project on-par with the more mature one?
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.
I think they are wasting their time… but it’s their time. They get to decide what a valuable way to spend it is, not me.
and the folks who choose not to waste time can build valuable things and make market share from the others.
The problem with Rust people is that they are worming their way into projects, causing their time wasting to affect other people.
The problem with C people is....
Placing people on different sides is unnecessarily divisive. Consider that folks genuinely want to work together and make things better.
> The problem with Rust people is that they are worming their way into projects
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?
Language hype always justifies itself through intellectualizing its own desire.
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/
5. https://corrode.dev/blog/foundational-software/
6. https://github.com/uutils/coreutils
I think it's the other way around.
Yes.
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').
I don’t get why people are so militantly opposed. I get not wanting to contribute to something you don’t believe in but if it’s a good faith effort by others doing the work - let them
Probably due to the small but very vocal group of pro-Rust zealots. "Rewrite it in Rust" has become a meme for a reason - and unfortunately it was more about people demanding Rust rewrites from existing C projects than doing Rust rewrites on their own.
> I don’t get why people are so militantly opposed
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.
Yes, this is why language hype has largely died down among all but the truly myopic.
That, and all languages more or less converged to the same functionality with different syntax/naming conventions. They also all offer similar toolchains with similar frameworks for nearly all problems. The remaining places where one language dominates often has it doing so due to extreme network effects and extreme toolchain investments.
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, and all languages more or less converged to the same functionality with different syntax/naming conventions.
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.
You can encode mutex holding into the type system in C++ in a very similar way as Rust. E.g., APIs can take folly::Synchronized<T>::RLockedPtr: https://github.com/facebook/folly/blob/76f81836a2ccb6cd3bc7d...
Fair enough — you can do that, which is nice, but in Rust it happens automatically. A program that attempts to concurrently mutate the same object without taking a mutex will always fail to compile (unless you hack around this restriction with unsafe) whereas in C++ you have to intentionally build the API that way.
it is funny. I wrote a C# app last week. We mostly do PHP, which I like to call "Runtime Java" these days when using in a enterprise setting. Just as many factories and footguns but hey we slapped a decent OO system on it
And the inexperienced. I got hyped over golang a while back because of go routines. Then I discovered any remotely recent .net version already had what I needed. (I'm a c# dev by default)
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.
> ...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 think it was simply the rise of machine learning frameworks. Python was always advertised as good to prototype, test ideas etc. Then the network effect compounded recently: https://youtu.be/ZTPrbAKmcdo
I’d even risk saying Python’s popularity is one symptom of the AI bubble we’re in.
from the title I thought I was going to find someone agreeing with me that the current LLM craze is chasing natural language processing at the cost of other AI research. ironically I'm a fan of the coreutils rewrite, and the general trend of rewriting projects in more capable languages, I see it as paying future maintenance costs up front.
I think the other side of this is the fetishization of "if it isn't broken don't fix it" and computing conservatism a la the famous Dropbox/rsync comment. An equally valid inquiry is to ask "why should we not replace it", which can lead to some valid and correct thoughts.
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.
"X, but written in Y!" has always been something of a red flag. We don't need rust versions of solid, well-established projects. It just causes strife within those communities (see Linux kernel), confusion for users, and opportunity costs. Want to produce something in rust? give the user something new. Zoxide comes to mind. Love it. Want rust in the kernel? How about a green-field project, like Redox, that does this? This is a better, more productive approach than disrupting well established projects.
I mostly agree, but you may be interested to know that Zoxide is actually "X, but written in Y". Maybe there's some feature set difference but they are the same concept.
X = https://github.com/rupa/z
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.
The article assumes the 90s tools undergoing rewrites are battle-tested, hardened, and _secure_.
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.
Because it's a step towards larger Rust adoption in Linux, simple.
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.
I see it as a way to force Rust on people. That's almost like saying "You will have to learn some Rust whether you want it or not" to Linux maintainers.
> Because it's a step towards larger Rust adoption in Linux, simple.
Ubuntu is not Linux.
Correct, its uutils/Linux
Yes! Why is every company hiring for LLM talent? Companies that have no business doing so. They probably don't even know that supervised machine learning exists.
This is all about destroying free software and allowing "open source" to take over, nothing with memory safety whatsoever. This can sound conspiracy but the main idea is to push permissive licenses, so companies can exploit your work without even mentioning your name. I believe the goal of Canonical and similar companies is to create a fully alternative Linux+GNU environment without GPL/AGPL, push it with embrace, extend, extinguish tactics and eventually create a developer culture that contributing to permissive license parallel project is a better alternative than original copyleft one.
How does it prevent you from licensing code you write any way you want? If those companies pay for a GPL-free linux distribution (kernel excepted i suppose), what's the problem? they paid for the work, they should be able to license it the way they want, and nothing prevents others from using and writing GPL'd software...i'm having trouble seeing the evil here...
That doesn't just sound conspiracy, that is a conspiracy theory. Permissive licenses are a perfectly valid free software option that some people prefer. They are not some kind of shadowy attempt to undermine free software.
First, programming language fads have been a thing since about 10 minutes after the immortal Adm. Grace Hopper came up with COBOL.
Thompson 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?
On one hand, I think it's hype and a waste of time, but on the other, I fully support people doing what they want. On the plus side, it IS a lot easier rewriting things that exist than solving novel problems.
yes. and the way companies hire is driving it.
Yes
He doesn't mention the big advantage Rust has over C: memory safety.
Blazing fast!
Not really the world's biggest Rust fan, for multiple reasons. However, I find the arguments in this particular article to not be very compelling. The only concrete argument that is actually worth addressing is this one, and it's predicated on a false premise:
> 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.
> This assumes that the C code is already fully optimal, but it very obviously is not.
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...
Yeah, I find the notion that coreutils is so proven and solid that it can't possibly be improved in any way to be utterly ridiculous. And I'm not even saying Rust necessarily has to be the thing to do it.
I just don't believe "pile of old C" is any kind of strong indicator of quality or performance, positive or negative.
[dead]
GNU core utils are single-threaded. Rust allows safely to use several threads without much efforts. That alone will speed up utilities even if they are IO-bounded. Finally one could stop running double tar instead of cp -a on a huge tree to speed up things when coping big trees.
Ok but have they actually done this or are you talking about a theoretical improvement?
Yes, but this is a core part of the economy. As soon as we "solve" something, it becomes commodity in a matter of years and the bottom falls out of our current employment/revenue models.