Announcement

Collapse
No announcement yet.

Initial Support For The Rust Language Lands In Linux-Next

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

  • #11
    Now if I had a penny for every time someone said that something will fix the "security issues"...

    Comment


    • #12
      Originally posted by johanb View Post
      Typo: Currently the kernel upport needs a recent nightly Rust toolchain for building.
      And that's your main comment? I saw needs a recent nightly toolschain.

      From wikipedia: "while Rust was "widely viewed as a remarkably elegant language", adoption slowed because it repeatedly changed between versions".

      Also: "Mozilla laid off 250 of its 1,000 employees ... Among those laid off were most of the Rust team....The event raised concerns about the future of Rust".

      There is no Rust language, otherwise there would be a Rust language standard and a Rust standardization committee. And (multiple) compilers implementing that. As such we merely have a "foundation" and the board has held it's first meeting (9 Feb 2021).

      Good luck getting Linus to accept code that builds today but not tomorrow into the kernel.

      Comment


      • #13
        Originally posted by cobratbq View Post

        What is self-inflicted about the problems rust intends to solve?
        Programmers invented computers, C, and C++. Therefore, it's our collective fault that memory vulnerabilities in C and C++ programs stay at around 70% of CVEs no matter what we try.

        Comment


        • #14
          Originally posted by ferry View Post

          And that's your main comment? I saw needs a recent nightly toolschain.

          From wikipedia: "while Rust was "widely viewed as a remarkably elegant language", adoption slowed because it repeatedly changed between versions".

          Also: "Mozilla laid off 250 of its 1,000 employees ... Among those laid off were most of the Rust team....The event raised concerns about the future of Rust".

          There is no Rust language, otherwise there would be a Rust language standard and a Rust standardization committee. And (multiple) compilers implementing that. As such we merely have a "foundation" and the board has held it's first meeting (9 Feb 2021).

          Good luck getting Linus to accept code that builds today but not tomorrow into the kernel.
          The language is stabilized and does not make breaking changes anymore. To cover new features there are "editions", currently two (2015 and 2018) and 2021 is planned, in the same way C++ has 11, 14, 17, etc.

          It also adopted by many tech giants so it won't go anywhere. Quite an opposite, I don't see a compelling reason to start any new project in C or C++ nowadays unless it targets some architecture which is not supported by LLVM.

          There is also an ongoing effort to bring Rust frontend to GCC.

          Besides C++ has a standard and is repeatedly changing between versions, it's not a problem at all. Languages that do not change die in obsolescence.

          Comment


          • #15
            Originally posted by ferry View Post

            And that's your main comment? I saw needs a recent nightly toolschain.
            Why is this a problem? It is not even mainlined. in a few months the required changes are in stable.


            Originally posted by ferry View Post
            From wikipedia: "while Rust was "widely viewed as a remarkably elegant language", adoption slowed because it repeatedly changed between versions".
            That statement is from 2014. And before the 1.0 release. Since then everything is fine.

            Originally posted by ferry View Post
            Also: "Mozilla laid off 250 of its 1,000 employees ... Among those laid off were most of the Rust team....The event raised concerns about the future of Rust".
            YES, and the industry showed big commitment and founded the organization. Problem solved.

            Originally posted by ferry View Post
            Good luck getting Linus to accept code that builds today but not tomorrow into the kernel.
            Ay, you have to try harder. We used to have better trolls on phoronix.

            Comment


            • #16
              Originally posted by cobratbq View Post
              What is self-inflicted about the problems rust intends to solve?
              The problem of having too many brainlets on staff is entirely self-inflicted.

              Also, I wonder whether it was Michael or tildearrow that deleted my post. How petty and pathetic...

              Comment


              • #17
                Originally posted by ferry View Post
                Also: "Mozilla laid off 250 of its 1,000 employees ... Among those laid off were most of the Rust team....The event raised concerns about the future of Rust".
                Rust's existence has not depended on Mozilla for quite some time (although until the creation of the Rust Foundation did use Mozilla's hosting facilities (they layoffs expedited the creation of the foundation which had been previously planned)). While one should not dismiss the importance and value of Mozilla's employees in creating and shepherding rust, rust outgrew Mozilla, and recent contributions to the ecosystem were more from outside than inside Mozilla itself.

                Comment


                • #18
                  Originally posted by ed31337 View Post
                  BTW, does anybody know why rustc shows up in top as always being in the "S" sleeping state, but simultaneously using up 100% (or more) CPU? Why doesn't rustc act like a normal process?
                  First thing I'd investigate is exactly how your process monitor is determining that. Does it support expanding processes into their component threads? (What htop does by default so that at least you learn it's an option while you're turning it off... no joke. That's the rationale for making that the default.)

                  Maybe it's doing something like "The majority of the threads are sleeping, so I'll call it sleeping, but one thread is taking 100% CPU".

                  Comment


                  • #19
                    Originally posted by milkylainen View Post
                    Now if I had a penny for every time someone said that something will fix the "security issues"...
                    No one believes that rust will fix all security issues. One can still safely decide to do stupid things (or intentionally damaging things). But rust can, if used appropriately, address one particularly common security issue, which is memory safety, which has been claimed to represent nearly 70% of bugs (which does not represent any specific project accurately, but it is a number worth trying to reduce).

                    Comment


                    • #20
                      Originally posted by ferry View Post
                      There is no Rust language, otherwise there would be a Rust language standard and a Rust standardization committee.
                      In other words, the only mainstream languages that you accept as existing are C, C++, C#, Fortran, Scheme, and whatever other languages either found it politically expedient to undergo standardization (C# and .NET), grew a standard after they had a forest of incompatible implementations to bring to heel (C, C++, ECMAScript... which is a subset of what real websites depend on, etc.), or are 40+ years old.

                      Java, Python, Ruby, Lua, and a whole bunch of other languages are in the same boat as Rust, with a reference implementation, one or more secondary implementations of varying completeness, and no official standard and standardization committee... and Rust does have a very rigorous public RFC process for evolving the language in a careful and documented way.

                      Rust already provides stronger forward compatibility guarantees for existing source code than C++, which does have a standard.

                      Comment

                      Working...
                      X