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

  • Originally posted by Volta View Post
    Linux killed your POS OS? Good!
    Quite the opposite.

    Comment


    • Originally posted by Danielsan View Post
      So Rust it is just the excuse to erase the GPL from the "GNU Coreutils" and to leave just "Coreutils". Genius!
      Awesome.

      Comment


      • Originally posted by sdack View Post
        Simplicity is what allowed C to prevail.
        Yes, at a time when simplicity of the compiler was of paramount importance. Back in 1972 it allowed it to be reasonably usable on the PDP and similar machines. The computational power required to compile a language like Ada, C++, Rust simply wasn't available. But that doesn't mean that C would prevail if it appeared today. Nowadays it's simplicity is a liability, not an advantage. It's still widely used of course thanks to its huge ecosystem.

        Originally posted by sdack View Post
        It allowed having different compilers from competing makers and different versions of the language over time, and it still manages to produce runnable code.
        Different competing compilers were essential when it was customary for compilers to be proprietary. Now that compilers are expected (and indeed are) free speech and free beer, there is no risk associated with having only one and thus the point is largely moot.

        Originally posted by sdack View Post
        C has always been diplomatic with its environment.
        Actually not really. It looks like that if you have only ever used C in an environment that has itself been implemented in and for C (e.g. libraries use C ABI conventions, API parameters expect C types, etc). Use C outside of that cocoon and it's as alien as any other language. Even JNI is a PITA to use in C. Likewise the first versions of the AmigaOS had a kernel written in B, not C, and developing in C on it was annoying and needlessly convoluted.

        Of course C is still easier to accommodate in a foreign environment than say Rust, because it's ABI is so minimalistic as it knows nothing about generic types, fat pointers, dynamic dispatch etc. But once again that doesn't make it superior, just much more error prone.

        Originally posted by sdack View Post
        You will never have this with Rust. Rust alienates its environment as a principle of its existence.
        What does that even mean?

        Comment


        • Originally posted by soulsource View Post

          That's why I mentioned that Rust is closer to functional programming languages. The term "variable" is actually a misnomer in that context, as in idiomatic Rust almost all values are immutable, and their final value is known at the point of declaration.
          This is very similar to the concept known as "const correctness" in C/C++, with the main difference being that it's the default behaviour in Rust.
          In Clojure we call them bindings instead. I prefer that term.

          Comment


          • Originally posted by wswartzendruber View Post
            Not all operating systems respect the GPL, obviously.

            macOS certainly doesn't. The BSD variants don't. The FSF and GPL are not the end-all, be-all of software licensing. Regardless of what they say, Apple will still be proprietary. And their products will continue to fill store shelves. And consumers will continue to not care.
            This is dumbassery. If Microsoft shipped a GPL program but provided corresponding source, then they have every legal right to do so.

            You don't get to draw arbitrary lines in open source or free software as to who gets to participate and who doesn't.

            Comment


            • Originally posted by Developer12 View Post

              This is dumbassery. If Microsoft shipped a GPL program but provided corresponding source, then they have every legal right to do so.

              You don't get to draw arbitrary lines in open source or free software as to who gets to participate and who doesn't.
              They could absolutely ship a GPL program by itself. But they don't get to ship a GPL program as a part of a proprietary suite.

              This is precisely why Apple doesn't ship BASH with macOS and they use KSH instead.

              Comment


              • Originally posted by krzyzowiec View Post
                In Clojure we call them bindings instead. I prefer that term.
                In the Rust documentation both, variable and binding are used, and sometimes also variable binding.
                If you look at the documentation for the let keyword, it even starts with "Bind a value to a variable."

                I also prefer the term binding, but over the last few weeks, for which I've been working with Rust Qt Binding Generator, I've picked up the habit of avoiding it to avoid any ambiguity with respect to Qt QML bindings.

                Comment


                • Originally posted by wswartzendruber View Post
                  They could absolutely ship a GPL program by itself. But they don't get to ship a GPL program as a part of a proprietary suite.

                  This is precisely why Apple doesn't ship BASH with macOS and they use KSH instead.
                  Actually you can even ship a GPL program as part of a proprietary suite as long as the GPL rights applicable to the program itself remain in force and can be practically exercised. And even if the GPL program is effectively restricted by the proprietariness of the other components (i.e. "tivoisation"), the practice is obviously considered unwelcome but still seems to be perfectly legal, otherwise 95% of Android products could not be sold.

                  Comment


                  • Originally posted by sdack View Post
                    Fire, wheel, blade, hammer, ...

                    Those are ancient and are still going strong.

                    You better be ready to add C to this list.
                    Whereas the point of your analogy is clear and actually quite relevant... you're misusing your own analogy. You're mixing abstraction and specification. There are many forms of heat or fire and many different temperatures. There have been many different specific form of wheel, blade, hammer, etc.

                    C is not the abstraction. The abstraction would be computer language. As C is a specific programming language, which in turn are just, well, a specific form of computer language. Which actually, in turn, are just a specific version of language in general but that may be too abstract for the purposes of your analogy.

                    Having said that -- Wheels used to start out as nothing more than, well, horizontal slices of the trunks of trees. Over time, we evolved that concept into more specific, more specialized and more optimized forms. Same with blades. Same with hammers. Same with even fire. We used to rely on lightning strikes hitting something flammable to provide us with fire. Before actually learning how to produce it ourselves. We used to rely on burning wood as sources of heat before optimizing that further and so forth and so on.

                    We used to not understand how objects seemed to fall down whenever we dropped them. Then along came Isaac Newton. Who came up with a very workable theory on just what is going on. But, by the time Einstein came around, people had realized that Newton's theories were incomplete and needed refining. Einstein then created his Special Theory of Relativity. Which provided more insight into how the universe works. But, even to Einstein himself, it was still incomplete. So, he then came up with his General Theory of Relativity, which we now know to also be incomplete.

                    My point with all of that is this -- Whereas C is a solid language that has served us all incredibly well for decades now as the Internet would literally not even exist without it since, well, the Internet runs on Linux and Linux is coded in C, C still is, by definition alone, not going to be the final computer language we will use. Progress is inevitable and it is a good thing. Without progress, we'd still be digging up termites in front of our cave dwellings. Using nothing but sticks. C will be replaced one day. It is an inevitability. And even a necessity. Is Rust the language that is going to replace it? I don't know. History will have to be the judge on that. But out of all candidates we've seen in the past decades, Rust is the candidate with the best potential yet. Again, I am not sure Rust will replace C. But to imply, as you just tried to do, that C is going to be the final computer language we will ever need, that it is the ultimate computer language and cannot ever be improved upon or replaced... is, well, tantamount to people at one point believing that the Earth was the center of the universe and the Sun orbited around it. I'm telling you, if 200 years from now we're still relying on C we definitely went wrong somewhere and it would be an even greater embarrassement than cancel culture already is.

                    If people like you had your way, medicine would still consist of bloodletting and believe me, bloodletting cost more lives than it saved.

                    Comment


                    • Not only should the Rust Coreutils be more secure
                      Hmmmm

                      $ grep "[[package]]" Cargo.lock | wc -l
                      332
                      Yeah, sorry, I have to press "X" for doubt here

                      Comment

                      Working...
                      X