4 ms·

People who wrote the coreutils give a shit too. The reason “rewrite in Rust” gets a lot of hate is because it’s often a poorer replica in that it supports a su

People who wrote the coreutils give a shit too. 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.

sureglymop 1y ago
I have no issue with rewriting the coreutils in rust technically but I also don't think it's that interesting. They work just fine as they are. 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.
- steveklabnik 1y ago
  MIT/Apache2 is the default in the Rust ecosystem, and so the authors selected it because they didn’t care that much, and so going with the community default makes sense. 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.
  - em-bee 1y ago
    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.
  - DaSHacka 1y ago
    > MIT/Apache2 is the default in the Rust ecosystem, and so the authors selected it because they didn’t care that much, and so going with the community default makes sense. 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.
    - coldtea 1y ago
      >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 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...
    - steveklabnik 1y ago
      I disagree but I understand your perspective, and that's fine. I mostly wanted to communicate "the choice of license was mostly out of needing to just pick one, it was not ideologically motivated."
      - sureglymop 1y ago
        I understand what you mean but wouldn't you say that in itself seems a bit careless considering the scope and context of this project? But I get it, at least it doesn't have no license.
- hnlmorg 1y ago
  What license would that be? GPLv3 for GNU? GPLv2 for busybox? Or BSD for Toybox (Android) 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?
  - DaSHacka 1y ago
    I think the obvious answer is whatever tool you're attempting to replicate/supplant, you should use the same (or a compatible) license. 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.
    - burntsushi 1y ago
      > I think the obvious answer is whatever tool you're attempting to replicate/supplant, you should use the same (or a compatible) license. 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.
      - DaSHacka 1y ago
        > 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?
        hnlmorg 1y ago
        Happens all the time; even with GPL projects. 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.
coldtea 1y ago
>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 That's exactly what's needed in many cases tho: someone to drop most of the legacy features.
- hnlmorg 1y ago
  I like how you’ve spun a negative into a positive, and I do mean that sincerely. But if we are honest, legacy features hidden behind flags have never been an issue requiring deprecation.
  - em-bee 1y ago
    removing features reduces code complexity, feature flags don't. and in this case, if you need the legacy features the original apps are still there and maintained, so it's not like we lose functionality like you would if an upgrade removed features and you'd be forced to decide to choose between the old version and the new one.
    - hnlmorg 1y ago
      The thing with this approach is that it only works for a limited time. Then that new project starts to gain the same bloat and people then make the same complaints and rewrite it again. The whole approach is a wasteful churn of NIH (not invented here) syndrome just to produce mediocre replicas. 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.

sureglymop 1y ago

I have no issue with rewriting the coreutils in rust technically but I also don't think it's that interesting. They work just fine as they are. 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.

steveklabnik 1y ago
MIT/Apache2 is the default in the Rust ecosystem, and so the authors selected it because they didn’t care that much, and so going with the community default makes sense. 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.
- em-bee 1y ago
  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.
- DaSHacka 1y ago
  > MIT/Apache2 is the default in the Rust ecosystem, and so the authors selected it because they didn’t care that much, and so going with the community default makes sense. 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.
  - coldtea 1y ago
    >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 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...
  - steveklabnik 1y ago
    I disagree but I understand your perspective, and that's fine. I mostly wanted to communicate "the choice of license was mostly out of needing to just pick one, it was not ideologically motivated."
    - sureglymop 1y ago
      I understand what you mean but wouldn't you say that in itself seems a bit careless considering the scope and context of this project? But I get it, at least it doesn't have no license.
hnlmorg 1y ago
What license would that be? GPLv3 for GNU? GPLv2 for busybox? Or BSD for Toybox (Android) 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?
- DaSHacka 1y ago
  I think the obvious answer is whatever tool you're attempting to replicate/supplant, you should use the same (or a compatible) license. 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.
  - burntsushi 1y ago
    > I think the obvious answer is whatever tool you're attempting to replicate/supplant, you should use the same (or a compatible) license. 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.
    - DaSHacka 1y ago
      > 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?
      - hnlmorg 1y ago
        Happens all the time; even with GPL projects. 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.

coldtea 1y ago

>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 That's exactly what's needed in many cases tho: someone to drop most of the legacy features.

hnlmorg 1y ago
I like how you’ve spun a negative into a positive, and I do mean that sincerely. But if we are honest, legacy features hidden behind flags have never been an issue requiring deprecation.
- em-bee 1y ago
  removing features reduces code complexity, feature flags don't. and in this case, if you need the legacy features the original apps are still there and maintained, so it's not like we lose functionality like you would if an upgrade removed features and you'd be forced to decide to choose between the old version and the new one.
  - hnlmorg 1y ago
    The thing with this approach is that it only works for a limited time. Then that new project starts to gain the same bloat and people then make the same complaints and rewrite it again. The whole approach is a wasteful churn of NIH (not invented here) syndrome just to produce mediocre replicas. 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.