I've been using bat for several years and it's been a really nice drop-in replacement for cat/less/etc.
Like rg, it's one of those "rewrite it in rust" projects that turned out to actually be quite well thought through.
Like rg, it's one of those "rewrite it in rust" projects that turned out to actually be quite well thought through.
Reasons, yes. But not very good ones and blown way out of proportion.
(The issue is further exacerbated, in my opinion, by the prevailing notion that test-driven development is superior to — or at least generally more than adequate for — anything and everything that could be desired. Years ago there was a tense Twitter exchange between Bob Martin [of "Clean Code" note] and Shriram Krishnamurthi [a prominent programming languages researcher and professor at Brown University] on this topic, Martin seemingly unwilling to move past a TDD-oriented worldview at that time.)
I'd say that rewriting anything in any language (even in the same language) would remove large amounts of cruft, and add long-missing neat things that are easier to add when you build from scratch, and with a good understanding which the original authors lacked. Often it also can afford using a better architecture, see rg vs grep: grep has many brilliant technical solutions, but making it multithreaded would be a major rewrite anyway.
The reason “rewrite in Rust” gets a lot of hate is because it’s often a poorer replica in that it supports a subset of features and sometimes so littered with unsafe blocks that it’s barely any safer than their C counterparts.
Ripgrep and bat are the exceptions in that they’re modernisations in every sense of the term. They’re safer, have more modern features, and better defaults. Even if you don’t give a crap about memory safety, there’s a reason to use ripgrep and bat.
Personally I really don’t see the benefit in rewriting stuff unless you’re bringing other modernisations to the table too. But I suspect for some people, it’s more of an exercise to learn Rust than it is an ambition to displace a particular coreutil.
However what I truly don't understand is using a different license. For something so fundamental, please just let that be the same.
But I think there are a lot more great examples. I have used pandas and I like polars. I have used latex but I like typst. People are creating generally valuable tools that bring something new to the table. More competition and diversity is rarely a bad thing.
In practice, even if they’d chosen the GPL for their own code, they’d be including dependencies that weren’t GPL’d, so unless they were committing to doing everything from scratch (including the Rust standard library!) some parts of the codebase would be non-GPL’d.
that doesn't matter. the point of the GPL is to protect the application. that still happens even if libraries used are not GPL. the LGPL would not exist if that were an issue, so using a different more restrictive license for applications, and a less restrictive one for libraries is done intentionally.
This is exactly the issue most of us have with the rust ecosystem and these 'rewrite in rust' projects, though.
By making everything licensed with the absolute bottom wrung restrictions, you're just made it even easier for corpos to have free pickings of any given tool on the internet to incorporate into their own tools and have never-ending Amazon and Elasticsearch situations.
Obviously the community wouldn't even be here to begin with if it wasn't for Linux going with a GPLv2 license. Going forward, with everything becoming more MIT/BSD licensed, I wonder to see how the community/ecosystem will fare.
I suspect, should there come a time in the future where we realize that this may have been a critical error, it'll be far too late to correct it.
So? That's allowed, they should do whatever they want with that code. I've preferred most MIT/Apache stuff over GNU alternatives even for personal use.
>Obviously the community wouldn't even be here to begin with if it wasn't for Linux going with a GPLv2 license. Going forward, with everything becoming more MIT/BSD licensed, I wonder to see how the community/ecosystem will fare.
There are tons of projects with MIT/BSD/Apache and decades of community participation. Including *BSD and Apache server themselves...
Linux being GNU didn't help it becoming driven by big companies paying all the core developers...
But I get it, at least it doesn't have no license.
I also don't think it's careless because "Go with community norms" is a considered way to choose something.
Finally, this isn't really about "careless" exactly, but if I were the authors of this project, I would deliberately choose MIT/Apache2.0 over the GPL, and so like, I dunno, suggesting that they're not being responsible because they didn't pick the GPL isn't a framing I'd agree with.
I've already given plenty of examples of BSD-licensed coreutils. If an evil corporation wanted to steal coreutils, they wouldn't need to take the Rust implementation. And as a bonus, if they took FreeBSD/OpenBSD/whatever, they'd get a project that's far more mature too.
It is, after all, exactly what Apple did with Darwin.
> Obviously the community wouldn't even be here to begin with if it wasn't for Linux going with a GPLv2 license.
That's survivor bias and doesn't fall in line with my experiences using Linux and BSD in the 90s.
BSD originally had a bigger community than Linux for quite a while. What accelerated Linux wasn't the license; it was the hacker culture.
BSD systems were tightly controlled ecosystems, whereas Linux was a free-for-all because the kernel was managed by a different developer to the guy who managed GNU. So everything about the GNU/Linux ecosystem was disparate projects slapped together. This encouraged others to slap their own parts to GNU/Linux. This is why fsck needed to exist: the file system was slapped together so Linux needed a way to fix file corruptions. It's why there's different package managers and why the concept of a "distribution" exists in the first place.
It's what made Linux approachable and it meant development on Linux happened at a much faster pace than on BSD.
Then all of those hackers got jobs. Became managers. And recommended Linux because it's what they learned "UNIX" on.
Linux was basically the original "move fast and break things". If it had been licensed MIT then nothing would have changed.
> I suspect, should there come a time in the future where we realize that this may have been a critical error, it'll be far too late to correct it.
The GPL vs BSD argument is probably older than you've been alive. It's probably older than a considerable number of HNers have been alive. And it's been proven time and time again that it's an ideological debate that has no practical truth. Hence why people stopped arguing it.
Or BSD/ISC for FreeBSD, OpenBSD, macOS etc coreutils? All of which also have subtly different implementations from each other.
Or maybe you are talking about other UNIXs like CDDL for OpenSolaris?
Or perhaps you meant a proprietary license like Solaris, AIX, HP-UX, Tru64 UNIX and so on?
Or maybe we just agree that there isn’t a standard license for coreutils and developers should be free to chose to license their own code however they wish?
The issue is there's a massive leap between GPLv3 and MIT, even something like GPLv2 or anything else is better than MIT or public domain-tier licenses.
Is this really obvious? Did GNU coreutils do this for the project it was attempting to replicate/supplant?
> even something like GPLv2 or anything else is better than MIT or public domain-tier licenses
That's an opinion, not a fact.
Except on average, how often do GPL projects get forked and modified without the changes getting released to the public versus with MIT projects? Which one benefits end users more?
Technically with GPL, you only need to provide the source if requested. You don't specifically need to publish those changes ahead of time. And as it happens, some businesses don't even share the source when requested.
Also interesting your silence about my other point. Tell me, did GNU coreutils copy the license of its ancestor?
But there isn’t a standard license for coreutils, as I’ve demonstrated.
And worse to your point is that literally only one implementation of coreutils is GPLv3. So by your logic “rewrite in rust” projects shouldnt be GPL-licensed.
> The issue is there's a massive leap between GPLv3 and MIT, even something like GPLv2 or anything else is better than MIT or public domain-tier licenses.
Actually MIT is closer to what the term “public domain” means than GPLv3 is.
But either way, you’re arguing preference as fact. And your preference here is basically just a license flame war. I thought the community had evolved passed this pettiness.
There is for the specific coreutils they're attempting to replicate the behavior of though. They're directly targeting the GNU coreutils.
> Actually MIT is closer to what the term “public domain” means than GPLv3 is.
Yeah, that's the problem with it.
> But either way, you’re arguing preference as fact. And your preference here is basically just a license flame war. I thought the community had evolved passed this pettiness.
Is it really pettiness if one license allows for Elasticsearch situations and the other keeps the software and its derivatives free for people to use? Go and try to argue that the Linux kernel should be relicensed as MIT, surely the license doesn't matter at all and had no impact whatsoever on how things got to the point they are now. It's just pettiness, right?
In the case of uutils coreutils specifically, sure. But that's not universally true for every RiR (Rewrite in Rust) project.
> Is it really pettiness if one license allows for Elasticsearch situations and the other keeps the software and its derivatives free for people to use?
GPLv3 wouldn't prevent ElasticSearch situations. They had to create a new license to solve that.
The problem with ElasticSearch was that AWS were making money running ElasticSearch without financially contributing ElasticSearch. There's nothing in GPL that prevents that. If there were, then nobody would be running Linux servers ;)
> Go and try to argue that the Linux kernel should be relicensed as MIT
Why would I argue that when there are plenty of kernels that are BSD licensed? If I cared about software licenses, then I'd use one of them instead.
> surely the license doesn't matter at all and had no impact whatsoever on how things got to the point they are now. It's just pettiness, right?
It's petty because you're complaining that developers should not be free to choose the software license they want for their own software projects because of an ideological complaint you have based around a misunderstanding of GPL.
That's exactly what's needed in many cases tho: someone to drop most of the legacy features.
This is why I said rewrites should be introducing something new, rather than just removing something old.
Plus if you really want to remove old feature flags, you can just do that in the original projects. You don't need to rewrite to remove features.
When I read of rewrites that are a subset of the original, and particularly when they advertise themselves as "opinionated", is a project that the author started to learn x, y or z. And that's a fine goal in itself. But I just wish people were more honest and say "I wrote this to learn Rust".
None of these criticisms apply to bat, though. This tool is adding something new.
it replaces default `ls` in interactive shells on some distros, which is where I encountered it