Announcement

Collapse
No announcement yet.

Rust-Written Replacement To GNU Coreutils Progressing, Some Binaries Now Faster

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

  • Oh, it is that topic again. So much fun reading about brainwashed primates whining about the magic pill which can make them flawless software, relax their anxiety and heal their insanely rusty neurosis for good.

    To all rust sectarians: you were told thousand times already, at current state rust is non-portable, insecure and laughably poorly programmed/packaged/distributed by any measure of software development.

    It will not gain any meaningful acceptance until gcc-rust is ready. And guess what? The on-going effort continues for 8 (eight!) years without significant progress. Guess why? Exactly. Because rust is such a mess that it is a monumental, if possible at all, task even for the authors themselves. Just read the developer logs and bug reports. They are unable to do that.

    No sane person wants to depend on self-contained "magic" compiler which is unmaintainable and non-free. So until that changes, let me just read more and more of your whining and watch rust dies eventually.

    Comment


    • Originally posted by jacob View Post

      Because the GPL maintains the system fair - everyone who wishes to use your code must keep it open source. MIT, BSD and similar licences simply give a free ride to closed source proprietary developers with absolutely nothing in return. No wonder Apple and Microsoft love them and detest the GPL.
      The argument as to which license is "more free" depends on your definition of freedom (your rights vs others rights). And in the end, your software, your choices, as both respect *a* definition of freedom. Those that do not like someone else's freedom do not really believe in freedom.

      Comment


      • Originally posted by flower View Post

        usually it is because more people are working on a library which oftens results in it beeing better optimized than a one-person developed single use solution.

        so it could be that rust coreutils just rely more on an optimized library than a c implementation.

        that said: c is faster. but it is easy to develop slow c code (it is easy to develop slow code in any language).
        C is not faster. Rust can provide aliasing info and by default allows the noalias "flag" on arguments for example, which C doesn't unless you explicitly mark everything manually. The reason why this wasn't seen much in the wild is because LLVM had a bug causing UB issues if the flag was used, exactly because C/C++ couldn't properly provide such use cases.

        There are possibly others and also the fact that Rust provides richer abstraction types can lead to better optimization as well. In the end it all boils to "optimizer knows more when it runs on generated Rust code than on C generated code" which is true because Rust is more explicit about a lot of things than C.

        Comment


        • Originally posted by JustRob View Post
          There's support for rusting things but I wonder why Elixir wasn't chosen: https://elixir-lang.org/

          There's already a GoLang version: https://github.com/guonaihong/coreutils

          The rewrite was a solution searching for a problem we didn't have while avoiding a better suited (for CoreUtils) language that scaled and is concurrent, with safety.
          From the link, "Elixir leverages the Erlang VM". The use of VM blocks a lot of stuff. Any language that use VM can only be trusted, before careful investigation, to replace projects that already use VM / interpreter. So Elixir may replace Java or Python, but definitely not anything of C. The resistance will be so high that nobody bothers.

          GoLang's use of garbage collector introduces a similar resistance.

          Comment


          • This is just Rust being Rust. Every Rust app is "_____, except written in Rust, and therefore fast, secure, free of bugs, and awesome". Yet, none of them ever beat their C counterparts, and rusty coreutils will be no exception. This is being driven by a bunch of sub-par developers who decided to latch onto Rust because they thought it was going to be "the future", it's mostly the people who actually thought Ruby was a good idea before they jumped ship to Rust. If these developers were top shelf visionaries, you would be getting innovative new apps, and not clones of existing things, where the gimmick is it is written in Rust.

            Even the original Rust app, Firefox, has lost substantial market share since the Rust porting. It's on the verge of becoming something that is only widely used on the 1% of Linux desktop computers.

            C is not going anywhere. Any language is a dumpster fire in the hands of a sub-par developer, and C is no exception. But in the hands of a skilled developer with proper test suites, and tools like GDB/LLDB, Valgrind, and others, you can write perfectly safe and reliable C code that outperforms any higher level language.

            Comment


            • In fact, let's take it one step further: Every Rust app is marketed under the false premise that Rust is a superior language to C. How is "superior" defined? As having better outcomes in the hands of unskilled developers. Because plenty of developers have been getting great outcomes in so-called "unsafe" languages like C and C++ for decades.

              So some unaccomplished developers are writing many pointless things in Rust now, and running their mouths about it like they discovered the cheat codes to programming. This is the worst FOSS fallacy since Gentoo and Arch users thought they discovered the cheat codes to performance by allowing an entire system to be compiled with -O3 -fsuper-fast -mobscure-isa-with-immature-support, as if:
              a. These flags actually lead to consistent performance gains
              b. There are no stability losses, performance regressions, it's simply some magic go-fast hack with no downsides, that others were not smart enough to discover
              c. It's so obviously faster that there is no need to even prove the benefit of doing this, and anybody who doubts it is a heretic

              But hey, at least some people are getting to feel smugly superior who otherwise might never get the chance.

              Comment


              • Originally posted by flower View Post

                usually it is because more people are working on a library which oftens results in it beeing better optimized than a one-person developed single use solution.

                so it could be that rust coreutils just rely more on an optimized library than a c implementation.

                that said: c is faster. but it is easy to develop slow c code (it is easy to develop slow code in any language).
                There is no single reason why C is faster. Everything which is possible in C, is possible in Rust. But the other way around is not true. In fact, Rust guarantees strict aliasing, such that the compiler can optimize more aggressively than ever possible in C.

                Comment


                • Originally posted by coder View Post
                  It's funny that you pick on those examples, because basically every wheel, knife, saw, and even hammer is now made of different materials and in different ways than they were even 100 years ago.
                  And each of these new wheels is made for a specific purpose that these cannot really be used anywhere else than their intended place. These all do the same and trade simplicity for complexity and lose their usefulness. If you cannot see this then you can also not see why C is still successful.

                  Comment


                  • Originally posted by MadCatX View Post
                    The proper way to deal with that is to have protocols and tools that detect a problem before it becomes a real problem.
                    No. A protocol is in itself a set of instructions. You are tacking on code onto code to fix other code, because you have not learned why you keep making these mistakes. Instead, you run from pasture to pasture in hope to escape your mistakes. You will make as many mistakes as before, no matter the language you use. In the end will you get caught up in so many restrictions that the only reason why you make fewer mistakes is because you get less done.

                    Comment


                    • Originally posted by phoronix View Post
                      Phoronix: Rust-Written Replacement To GNU Coreutils Progressing, Some Binaries Now Faster

                      ...and in some cases now even outperforming the upstream project.

                      https://www.phoronix.com/scan.php?pa...utils-Jan-2022
                      I didn't see any benchmarks.

                      Comment

                      Working...
                      X