Announcement

Collapse
No announcement yet.

Uutils 0.0.13 Released For GNU Coreutils Replacement In Rust

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by ssokolow View Post
    Probably not favourable for uutils. From what I remember, it began as more of a programming exercise (meaning it wouldn't have started with a lot of the performance optimizations coreutils has) and I'd imagine they're probably mostly focused on getting the test suites passing.
    Tbqh I'd assume the approaches taken by a non-C implementation of coreutils would generally outperform their C counterparts because much of the speed of text processing applications is driven by the usage of the correct data structures more than anything, and I would expect it to be less obvious and considered by a C programmer especially a 1980s C programmer than a modern developer who has readily and easily accessible hashsets, tries, and such at hand.

    That said stdin/stdout is the biggest bottleneck of them all when it comes to real throughput.

    Comment


    • #22
      Originally posted by Old Grouch View Post
      It might be important to some that GNU coreutils is GPLv3 licensed, but uutils is MIT licenced.
      And while Apple will likely not do so (they have never been especially interested in the unix cli), being MIT licensed they might just finally update their coreutils versions to bring them into the current century.

      Comment


      • #23
        uutils/Windows is coming. You cannot call it Windows, it's uutils/Windows.

        Comment


        • #24
          Round and round and round again ! Notice how lots of stuff is rewritten every couple of years.

          Hope the same thing does not happen when Bust/Dust/Gust (The super compiler released to fix Rust memory corruption - coz some n00bs failed to learn and use the language correctly ) is released.

          Comment


          • #25
            Originally posted by Luke_Wolf View Post

            Tbqh I'd assume the approaches taken by a non-C implementation of coreutils would generally outperform their C counterparts because much of the speed of text processing applications is driven by the usage of the correct data structures more than anything, and I would expect it to be less obvious and considered by a C programmer especially a 1980s C programmer than a modern developer who has readily and easily accessible hashsets, tries, and such at hand.

            That said stdin/stdout is the biggest bottleneck of them all when it comes to real throughput.
            You'd think that, but not necessarily. Take a look at A Little Story About the `yes` Unix Command by Matthias Endler.

            Comment


            • #26
              Originally posted by xhustler View Post
              Round and round and round again ! Notice how lots of stuff is rewritten every couple of years.

              Hope the same thing does not happen when Bust/Dust/Gust (The super compiler released to fix Rust memory corruption - coz some n00bs failed to learn and use the language correctly ) is released.
              Uutils began as people doing a Rust rewrite because they wanted a hobby/learning project that held their interest. If distros decide the result is more to their taste than GNU coreutils, that's a completely independent decision.

              Comment


              • #27
                Originally posted by xhustler View Post
                Round and round and round again ! Notice how lots of stuff is rewritten every couple of years.

                Hope the same thing does not happen when Bust/Dust/Gust (The super compiler released to fix Rust memory corruption - coz some n00bs failed to learn and use the language correctly ) is released.
                Why do people who don't know Rust write like this?
                Wouldn't be easier just to give a scan over the official Rust book instead of posting psychotics rants?

                Comment


                • #28
                  Originally posted by ssokolow View Post

                  You'd think that, but not necessarily. Take a look at A Little Story About the `yes` Unix Command by Matthias Endler.
                  I mean... yes is just a special case of "stdin/stdout is slow" and the severe bottleneck does require acknowledgement and effort to work around... as I mentioned, however... most other text processing commands can be buffered into a single read/write so that's much less of an issue.

                  Comment


                  • #29
                    Originally posted by Luke_Wolf View Post

                    I mean... yes is just a special case of "stdin/stdout is slow" and the severe bottleneck does require acknowledgement and effort to work around... as I mentioned, however... most other text processing commands can be buffered into a single read/write so that's much less of an issue.
                    My point is that these things sometimes turn out to be more than they appear, so it's good to withhold judgment.

                    Comment


                    • #30
                      https://archlinux.org/packages/core/x86_64/coreutils/
                      Packaged size: 2.7 MB
                      Installed size: 16.4 MB
                      https://archlinux.org/packages/commu...ils-coreutils/
                      Packaged size: 9.4 MB
                      Installed size: 112.6 MB
                      Is this a joke? This must be a joke, right?

                      Comment

                      Working...
                      X