back to article Keep calm and learn Rust: We'll be seeing a lot more of the language in Linux very soon

To become a Linux developer, you used to need C as your passport. Now Rust can let you be an OS programmer as well. The joke goes: "C combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language." Having programmed in both C and IBM 360 Assembler – it was a long time ago, OK …

  1. karlkarl Silver badge

    "learning a second language is going to be a major burden to maintainers."

    The safety (or at least focus on safety) of Rust is obviously great. We have never quite managed to bring that to C++ (and in many ways, nor should we, it could end up breaking too much).

    My biggest worry about Rust is that it is a little untested for maintaining seriously crusty software. What I mean by that is I recently had (the joy of) a task to maintain a very old C++ Motif (ViewKit) / GL-1.5 simulation software and bring it back to life with wxWidgets / GL-4.x. The whole process sucked but it was manageable.

    Rust on the other hand greatly relies on its language based package manager (crates.io) which, yes is very convenient for *current* dependencies and can save absolute days of work faffing with dependencies. However the sheer number of Rust dependencies that tend to get pulled in (because of this convenience) might prove to be some seriously hard work when fixing up a crusty from 30 years ago. Imagine running cargo only for it to state "Dependency name not found or archived". You would then need to maintain the C++ code. Then fix up the Rust bindings. Then update the crates.io package (that you don't have write access to; so you would need to request maintainership).

    (Do Rust built Linux modules even use crates.io? If not, I am fully in with it. Otherwise I would advise a little more caution).

    1. polaris64

      As far as I'm aware the Cargo package infrastructure will not be used for the Linux kernel, they'll just be using `rustc` to compile Rust modules. They could also probably host their own version of crates.io if they wanted, although I'm sure they already have better options for dependency management for the kernel.

      1. Anonymous Coward
        Anonymous Coward

        "host their own version of crates.io if they wanted"

        Why when there's Git? Crates is just another attempt to fill a self-created hole, it's simply NPM by another name. And then the Elephant in the room... "Crates.io" in particular is directly tied to Microsoft!!!

        1. ssokolow

          Crates.io is implemented on top of git to a large extent.

          It's mainly concerned with three things:

          1. Preventing the left-pad mess by forbidding pulling crates. (You can "yank" versions if you discover a vulnerability in them, but they remain available to any crate that has them pinned in a Cargo.lock file.)

          2. Providing a web interface for browsing the relevant information

          3. Providing names that are shorter and easier to remember and type than full URLs

      2. DrXym

        The code that is actually compiled and linked to the kernel though, probably not so much. But Rust makes it easy to install tools and add build time steps so they might have need for that, e.g. "cargo install cbindgen" to install the C bindings generator tool, or a build.rs that expands attributes in the source and happens to require a crate.

    2. jake Silver badge

      You spend a lot of time talking about C++

      The Linux kernel is coded in C, not C++.

      1. karlkarl Silver badge

        Re: You spend a lot of time talking about C++

        I could have just as easily been talking about an example project in Fortran to emphasise my concerns with Rust's dependency system.

        Don't let the fact that C++ also contains the letter 'C' confuse things. I was talking about quite different issues.

      2. bombastic bob Silver badge
        Meh

        Re: You spend a lot of time talking about C++

        and there are MANY reasons why C++ is not being used within the kernel.

        all of that housekeeping for unwinding things in the event of try/catch is number one.

        And the fact that try/catch exists is unfortunately an indicator that if C++ *WERE* used n the kernel, a bunch of clueless newbies would try making use of it... to the detriment of EVERYTHING. Point is, if a lingo has "a feature" some people will eventually use it, even if it is BAD to do so.

        it falls under "just because you can, does not mean you should". And I include Rust in that analysis as well.

        The C language is efficient (and close to the assembly language it's compiled into) because it _IS_ by design. it's more or less why the language was invented, back when UNIX was ALSO being invented and it needed to be programmed in a language that was close to assembly, but portable enough to compile on multiple platforms.

        Let's NOT just throw caution to the wind and adopt an incompletely tested programming lingo just because "Junior" likes it.

        Now it seems that a SUBSET of Rust is being considered. That may be acceptable, just like a subset of C++ is used on microcontrollers that use the Arduino IDE. Some of C++'s more aggregious "trying to be all and do all" quirks have been carefully omitted, with respect to startup code and constructors and other things that just bloat up a limited program memory space. It's all documented over on the avr-gcc web pages at any rate.

        So I would want similar from Rust: interoperability and fast/compact code should be number 1. Having a bunch of "but if" and "just in case" [paranoid] data checks and double checks in the code [thus stealing CPU cycles for pointless error checks] should be EXCLUDED (and such checks performed MANUALLY by coders, instead, like in C]. Automatic "features" that create inefficiency, in other words, should NEVER be used in the kernel.

        The kernel guarantees certain things are valid. Properly written drivers would do the same thing. if it is necessary to add code that double-checks parameters to guarantee valid data/pointers/etc. then you might as well be WINDOWS. Linux should be SO good that such things are NOT necessary.

        (so that gets back to how Rust is expected to be used, but I suspect perormance prioblems WILL be the most immediate concern and Linux runs on embedded and low clock speed devices for the very reason that it is STILL small and efficient by comparison to other things. Like WINDOWS)

        1. Yes Me Silver badge
          Joke

          Re: You spend a lot of time talking about C++

          "incompletely tested programming lingo"

          Really? I don't think so, and Rust is so much more idiot-proof than C or C++ that this seems like a very wise move. As for performance, Rust is good; pretty close to the machine, but protecting the programmer against their own stupidity. By sacrificing backwards-compatibility with C, Rust does what C++ should have done.

          As Lance Corporal Jones would say, "Don't panic! Don't panic!"

          1. Anonymous Coward
            Anonymous Coward

            Re: You spend a lot of time talking about C++

            "Rust is so much more idiot-proof than C or C++"

            Bigger question is why are you using idiots to program the kernal? or drivers?

            Plenty of other less important work for idiots to do! (windows kernal comes to mind).

            1. Paul Smith

              Re: You spend a lot of time talking about C++

              Hello. My name is Paul and I'm an idiot. I have been dry for 27 days...

            2. AndyJWard

              Re: You spend a lot of time talking about C++

              Everybody can be an idiot on a bad day. The point about Rust is not its abundance of runtime checks (which can be minimised if you work with the language), it is the abundance of compile-time checks and techniques that work, even when a good programmer is having a bad day.

              "A good Fortran programmer can write Fortran in any language" (Dijkstra?)

        2. swm

          Re: You spend a lot of time talking about C++

          I know of one operating system programmed in Smalltalk-76 on the ALTO. Another programmed in Interlisp on the Xerox "STAR" machines. Then there is Symbolics where everything is lisp.

          All of these have safe arrays and garbage collection. (Some have memory leaks though.)

          So a very high-level language can be used to write operating systems. Of course you have to know what you are doing.

          1. jake Silver badge

            Re: You spend a lot of time talking about C++

            Sure! And all of them are academic exercises, although a few such things have (briefly) made it out into the wild where they fill(ed) specific niches. Doesn't make them ideal languages for coding kernels, though.

            As another example, I once wrote a C compiler in Sendmail's configuration language. It worked a treat, even compiled a very early Linux kernel with it. But it was slow, cantankerous, fiddly, and I would never expect it to be used for anything important. It was just an exercise for myself, just to prove to me that I could do it.

            One shouldn't use an electric drill as a lump hammer, either.

        3. John Sager

          aggregious

          Yes, I like that neologism! Just that little bit stronger than egregious.

          1. bombastic bob Silver badge
            Facepalm

            Re: aggregious

            eh the spell checker accepted it. what the hell... it's late at night here and this font is too small to read properly with.

            *DOH*

            1. jake Silver badge

              Re: aggregious

              Aggregious: Many little egregious mistakes bound together in a matrix of apathy so as to present as a unified whole. See: Windows.

        4. ssokolow

          Re: You spend a lot of time talking about C++

          The C language is efficient (and close to the assembly language it's compiled into) because it _IS_ by design.

          I'll defer to Bryan Cantrill on that one:

          Historically, C has been the best fit for these applications just because [it's] so lean: by providing essentially nothing other than the portable assembler that is the language itself, it avoids the implicit assumptions (and girth) of a complicated runtime. But the nothing that C provides reflects history more than minimalism; it is not an elegant nothing, but rather an ill-considered nothing that leaves those who build embedded systems building effectively everything themselves — and in a language that does little to help them write correct software.

          -- http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeymoon/

          Now it seems that a SUBSET of Rust is being considered. That may be acceptable, just like a subset of C++ is used on microcontrollers that use the Arduino IDE.

          ...and this is something the Rust developers officially encourage, with:

          1. A standard library that's split into layers so you can keep the core primitives and disable the stuff that's only applicable to userland coding.

          2. A linter that's part of the official distribution with plenty of lints to enforce project-specific requirements such as "no use of floating point values".

          3. The ability to forbid(...) warnings and lints, turning them into compiler/linter errors which can't be selectively re-enabled.

          So I would want similar from Rust: interoperability and fast/compact code should be number 1. Having a bunch of "but if" and "just in case" [paranoid] data checks and double checks in the code [thus stealing CPU cycles for pointless error checks] should be EXCLUDED (and such checks performed MANUALLY by coders, instead, like in C]. Automatic "features" that create inefficiency, in other words, should NEVER be used in the kernel.

          The kernel guarantees certain things are valid. Properly written drivers would do the same thing. if it is necessary to add code that double-checks parameters to guarantee valid data/pointers/etc. then you might as well be WINDOWS. Linux should be SO good that such things are NOT necessary.

          Rust tries to encourage that through good API design which allows it to be proven at compile time that the invariants will be upheld, thus avoiding the need to choose between safety and performance.

          My favourite example of that is "the typestate pattern" which lets you teach the Rust compiler to prove correct traversal of any state machine, forbidding things like "Tried to set HTTP request header after the body had already begun streaming" at compile time.

          A more mundane example would be the iterator APIs. No need for bounds checking if the iterator looks up the length once at the beginning and the APIs prevent you from wandering out of each entry it hands you.

          From what I've seen, Rust programs tend to run faster than their C and C++ counterparts because the developers feel comfortable introducing and maintaining more aggressive optimizations.

        5. DrXym

          Re: You spend a lot of time talking about C++

          The subset of Rust they're referring to is you can't use stdlib just like you can't use clib in C. I assume for kernel work they'll have a lib of some sort, just not stdlib.

          As for performance, it shouldn't be any different to C. Most of Rust's checks are at compile time and compile to zero runtime overhead. Rust and Clang also share the same backend so it produces gcc compatible .o files that can be linked together.

    3. Roland6 Silver badge

      Re: "learning a second language is going to be a major burden to maintainers."

      Just goes to show just how far standards have fallen...

      From my experience of OS development and maintenance, where knowledge of both the source language and the target ASM was a precursor, if learning a second (high-level) language is a burden, you are probably in the wrong job.

  2. _LC_
    Unhappy

    The way in which this turd is being pushed “top down” makes me want to puke

    “Inherent weaknesses in C and C++.”

    That goes for people who have never learned to program in C++ and just keep on using it as “C with extensions”.

    1. James Anderson

      Re: The way in which this turd is being pushed “top down” makes me want to puke

      I can program in about 20 languages and C++ is the only mainstream language I truly dislike.

      Horrible syntax, unstable APIs , the unreadable Soustrup tome.

      Rust is OK but a tad immature and definitely not for application code.

      PS. correction:

      ": "C combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language."

      IBM 360 assembler is much more powerful and easier to use than "C".

      1. Skiron
        Joke

        Stroustrup C++ 'interview'

        I can hack/debug most languages, but C++ I don't get nor do I wish to get it. Soooo bloody abstract to read you haven't a clue what it does.

        Reminds me of an old 'fake interview' with Bjarne Stroustrup I read years ago, and if you haven't heard of it/read it, it is well worth a laugh:

        https://www-users.cs.york.ac.uk/susan/joke/cpp.htm

        1. karlkarl Silver badge

          Re: Stroustrup C++ 'interview'

          I like C++ when written by dumb people like me. Otherwise it is impossible to understand where the actual logic is.

          A recent talk by Bjarne Stroustrup (I think CppCon) was a particularly good example. Bjarne was talking about "a nice little program" and yet all I could see was a single definition of nested templates. This whole program was only ~6 lines and I couldn't understand any of it. I have been working as a C++ developer for 15 years... haha.

          (Chuck in some Javascript-esque async lambda spaghetti and I don't stand a chance!)

          1. Anonymous Coward
            Anonymous Coward

            Re: Stroustrup C++ 'interview'

            "nested templates"

            You can't look at templates like code, they're processed differently (although they can blindside your first order logic). However, the ever expanding things you can do with templates doesn't help readability. You can ignore most of the newer stuff and that can be proven by looking at the machine code. Some of the newer template stuff will undoubtedly help performance, but only in edge cases. Realistically, the expansion of C++ template features and various other features might be a sign that people have forgotten or refuse to use ASM (which is strange as most C++ code isn't written to be 1:1 portable to begin with).

            Lamda's are abused. IMO they should only be used when you absolutely, positively can't keep context... which is 0.000001% of the time. In fact I can't think of an instance where you can't replace a lambda directly with a function pointer (although you might be too lazy to write the function for that pointer :-/).

            Anyways, I get the feeling that Rust is considered by Linus simply because it's the most recent and popular machine language that is _NOT_ C++.

            1. jake Silver badge

              Re: Stroustrup C++ 'interview'

              "I get the feeling that Rust is considered by Linus simply because it's the most recent and popular machine language"

              I think he's throwing the yowling, baying fanbois a bone just to shut them up. We might get a few drivers & the like written in rust over the next few years, but the vast majority of the kernel will still be in C long after the next language du jour takes the place of rust in the fanboi's fancy.

              Side note: Rust is not now, and never will be, machine language. It's a systems programming language.

              1. Yes Me Silver badge

                Re: Stroustrup C++ 'interview'

                "Rust is not now, and never will be, machine language. It's a systems programming language."

                Which is exactly what C was designed as, but unfortunately, just before structured programming, strong typing, and OO became mainstream thinking. There have been dozens of attempts at fixing this and Rust really looks like the best of the bunch.

                1. jake Silver badge

                  Re: Stroustrup C++ 'interview'

                  The best of a bad lot of replacements isn't necessarily better for the job than the original.

          2. _LC_
            Alert

            Re: Stroustrup C++ 'interview'

            You have to keep in mind that what you are seeing there is mostly for programming libraries, where it's all about efficiency and every cycle counts. In your “everyday programming” you will likely not get in touch with much meta-programming (templates and such), as you will be rather using those libraries.

            1. jake Silver badge

              Re: Stroustrup C++ 'interview'

              One is programming. The other is word processing.

        2. Carlie J. Coats, Jr.

          Write C++ in any language

          There's an old joke that some programmers can write Fortran in any language.

          The sad fact is that in some parts of the environmental modeling community, the fashion is to write just this sort of incomprehensible C++ in Fortran!

          [Fortran, btw, has actually evolved into a very nice language -- much safer than C/C++. OTOH, it is still possible to write much of the stuff the joke complained about using "legacy" compatibility features in Fortran. FWIW.]

          1. jake Silver badge

            Re: Write C++ in any language

            Writing Fortran in any language will earn you a decent living ... but the real money is in writing COBOL in any language.

            1. EarthDog

              Re: Write C++ in any language

              Most C++ and Java code I've seen could be written in COBOL w/ libraries.

            2. adam 40

              What is the collective noun for COBOL programmers?

              (A load of) COBOLLERS!

          2. TimMaher Silver badge
            Windows

            Devils Dictionary

            Fortran is a language developed so that scientists can create their own bugs without help from programmers. As far as I remember. About 1980.

      2. jake Silver badge

        Re: The way in which this turd is being pushed “top down” makes me want to puke

        "IBM 360 assembler is much more powerful and easier to use than "C"."

        That is not only not right; it is not even wrong.

      3. ICL1900-G3 Silver badge

        Re: The way in which this turd is being pushed “top down” makes me want to puke

        Oh, how I loved BAL.

        1. jake Silver badge

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          I still do ... Glad I don't have to run a deck for the Linux kernel, though... :-)

        2. Anonymous Coward
          Anonymous Coward

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          "Oh, how I loved BAL."

          When the printer spewed out several thousand compilation errors - you could bet the programmer had forgotten the first instruction of BALR 3,0

          1. QuiteEvilGraham

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            Wow! R3 as a program base register? I suppose that back in the day, it was the first one that didn't get changed by any machine instructions. Too lazy to hunt through zArch POPS to find out if that's changed since.

            Anyway, you can easily get a clean "compile" by telling the assembler which base register(s) you are using without actually setting it properly; done that more than once.

      4. Hi Wreck

        Re: The way in which this turd is being pushed “top down” makes me want to puke

        <quote>IBM 360 assembler is much more powerful and easier to use than "C".</quote>

        You misspelled VAX.

      5. TimMaher Silver badge
        Facepalm

        Re: Truly dislike

        Ever tried Objective C @James?

    2. boblongii

      Re: The way in which this turd is being pushed “top down” makes me want to puke

      Don't be ridiculous. Firstly, C++ was specifically designed as "C with extensions" which is why it has no coherent object model and took literally decades to provide any sort of memory management beyond - oh, you do it yourself if you think it's important.

      It was a bad language from the off and has never really improved beyond providing ever-more bizarre and abstract nonsense for the true-believers.

      C++ is fast, allows sophisticated handling of data structures which are hard in C, and is a dangerous bloody chore to work with.

      1. bombastic bob Silver badge
        Devil

        Re: The way in which this turd is being pushed “top down” makes me want to puke

        I have no trouble at all using C or C++ (and do it all of the time, actually).

        Memory management is simple if you just think about what you're doing. You can always use thread-safe reference counting (via atomic increment/decrement for example) if you need something that lives outside of a function. What's so hard about that?

        And the primary code flow can be written to avoid the inefficiencies of "one size fits all" objects/classes. Error handling can get a "goto error_exit" where there is code that cleans things up the way they are. That happens a LOT in kernel code, i.e. use of 'goto' for error handling, because it is efficient.

        Maybe there are just too many JUNIOR developers out there that need to be coddled and have their hands held by built-in idiot-proof memory allocation and the associated bloat and garbage collection, and all of the OTHER INEFFICIENCIES that go along with it all.

        (take a look at how the internals of Linux and BSD efficiently handle pre-allocated kernel buffers, for things like file system I/O and the network stack - it's a wake-up call if you've never seen it - and long ago I started using similar methods for my own stuff because it works so well)

        1. Abominator

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          Lots of people that dabble, never really learned to write good code, shoot themselves in the foot.

          A bad workman blames their tools.

          I find there is a lot of people are super eager to drink the cool-ade on the latest thing. Once upon a time, Go-lang was going to take over the world.

        2. boblongii
          FAIL

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          "Memory management is simple if you just think about what you're doing. You can always use thread-safe reference counting (via atomic increment/decrement for example) if you need something that lives outside of a function. What's so hard about that?"

          That's about the stupidest head-in-the-sand thing I've ever seen. You're dismissing the single biggest cause of security problems and crashes (not to mention LOC) as "no big deal".

          "Maybe there are just too many JUNIOR developers out there that need to be coddled and have their hands held by built-in idiot-proof memory allocation and the associated bloat and garbage collection, and all of the OTHER INEFFICIENCIES that go along with it all."

          Or maybe there are too many dinosaurs who think that a) they are perfect, and b) everyone that contributes to their project is perfect.

    3. Charlie Clark Silver badge

      Re: The way in which this turd is being pushed “top down” makes me want to puke

      Maybe, but that could well be a moot point given that the software may already be there.

      The enthusiasm from Rust is unusual in that it comes largely from systems developers and maintainers; the sort of people who have to deal with programming failures on a daily basis.

      1. Anonymous Coward
        Meh

        Re: The way in which this turd is being pushed “top down” makes me want to puke

        > The enthusiasm from Rust is unusual in that it comes largely from systems developers and maintainers [ ... ]

        I don't think this enthusiasm comes from systems people. Linus' enthusiasm for Rust is lukewarm at best.

        Based on what I've seen, and based on the comments I've read here - numerous times - Rust's enthusiasm comes from people who failed at C and/or C++. As expected, they blame the language, not themselves.

        "C sucks because pointers."

        "C++ sucks because constructors/destructors/virtual/inheritance/move semantics/etc etc etc."

        Yada, yada, yada. Maybe you should have tried harder.

        You can polish a turd all you want. In the end, it's still a turd. Yes, I mean Rust.

        1. disgruntled yank

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          @ST

          Do you object to firearms with safeties or cars with seatbelts?

          1. Anonymous Coward
            Facepalm

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            > Do you object to firearms with safeties or cars with seatbelts?

            Because a programming language is just like a car. Or a firearm.

            Do you understand the difference between laziness (unwillingness to put in the effort to learn) and hazard?

          2. _LC_

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            In C++ today, you hardly ever get to allocate stuff yourself. You push things into containers, etc. This is all safe. When you use the new C++ support for operating with files, it all works nicely with std::strings. This way you automatically avoid all the possible exploits stemming from filenames.

            The problem here is clearly that there are dipshit C programmers that will keep allocating memory and passing pointers around “the old way”, because that's what they learned, because that's what they know. They will call the C filesystem functions, because they always used them.

            1. Anonymous Coward
              Anonymous Coward

              Re: The way in which this turd is being pushed “top down” makes me want to puke

              > In C++ today, you hardly ever get to allocate stuff yourself.

              That's very true for C++. For C, we're still stuck with malloc(3C) and free(3C). And if we're talking about Linux kernel development, or system libraries, it's all C.

              I'm all for the conveniences that C++ provides these days with respect to memory management. It's gotten pretty easy and safe.

              What I am not OK with is the notion that one can be a systems programmer without having the first clue about how memory is obtained, used and released back. Because, somehow, one can be a systems programmer without knowing how a computer actually works.

              1. _LC_

                Re: The way in which this turd is being pushed “top down” makes me want to puke

                Yes, but that's the power of encapsulation. Your block goes out of scope – it's deallocated. You shouldn't have to be using unsafe allocation all the time, not even in the kernel. They should provide safe mechanisms for that (which in C++ you can).

                1. jake Silver badge

                  Re: The way in which this turd is being pushed “top down” makes me want to puke

                  "You shouldn't have to be using unsafe allocation all the time, not even in the kernel."

                  You are quite correct. So I don't. Neither does any other kernel programmer worth her salt.

                  "They should provide safe mechanisms for that"

                  Should those mechanisms be hardware, firmware, software or wetware? Who gets to choose?

                  I'm out ... gots me some cats to herd; it's our bi-annual feral vaccine day.

                2. Anonymous Coward
                  Anonymous Coward

                  "Your block goes out of scope – it's deallocated"

                  That was the original sin of C++ - which lead to the need to invent more and more complex ways to avoid it and keep objects alive and have them de-allocated only when really needed... because outside simple programs object lifetimes are a bit more complex than Stroustrup thought.

              2. jake Silver badge

                Re: The way in which this turd is being pushed “top down” makes me want to puke

                "Because, somehow, one can be a systems programmer without knowing how a computer actually works."

                That's what they want ... the cachet of being a systems programmer without having to put in the work to understand how it all fits together. For some unknown reason, they expect some library somewhere to do all the work of understanding the underlying hardware for them.

                Sorry, kids. Crawl, then walk, then run. There are no shortcuts. Not in kernel programming.

              3. adam 40

                Re: The way in which this turd is being pushed “top down” makes me want to puke

                That's for user space, you might be thinking of kmalloc() or get_free_page()

              4. Charlie Clark Silver badge

                Re: The way in which this turd is being pushed “top down” makes me want to puke

                Well, the idea is actually not to do much kernel development in Rust. At least, not initially. It's considered that there modules such as drivers that need to work with the kernel that could be a good fit and where downside risk is minimised due to modular scope.

                Given the number of bugs continue to crop up in drivers this seems like a reasonable approach. Even if it's not a silver bullet, if it can help reduce the number of bugs, it's a good thing. Oh, and I know a few C level programmers who like Rust for just this.

            2. jake Silver badge

              Re: The way in which this turd is being pushed “top down” makes me want to puke

              This old "dipshit C programmer" and kernel contributor wonders how much time you have spent actually working on real world kernels.

              1. DrXym

                Re: The way in which this turd is being pushed “top down” makes me want to puke

                Or any code for that matter. This person has a certain arrogance that doesn't exactly scream experience or knowledge.

                1. Anonymous Coward
                  Mushroom

                  Re: The way in which this turd is being pushed “top down” makes me want to puke

                  > This person has a certain arrogance that doesn't exactly scream experience or knowledge.

                  Oh, and you don't?

                  Had you made any of your idiotic statements proffered here during a first round job interview anywhere in Silicon Valley, you'd be laughed out the door after 5 minutes.

                  I would know. I interview people like you. The big advantage is that I only need to waste 5 minutes out of the allocated hour.

                  But hey, keep telling yourself you know what you are talking about. On the Internet, it doesn't really matter.

              2. Anonymous Coward
                Anonymous Coward

                Re: The way in which this turd is being pushed “top down” makes me want to puke

                Ugh....yup you're deffo a kernel dev. The only thing missing from your post is a link to a git commit history and imgur link of you standing next to Torvalds with your thumb up while he's shaking someone elses hand.

                "how much time you have spent actually working on real world kernels"

                You can spend months working on a kernel fix only for it to never be accepted.

                I've seen kernel patches accepted over the years that are inferior to random folks submissions that were only accepted because the person that submitted the inferior patch was a "known kernel dev".

                There would appear to be a lot more trust than verify in the kernel world. If a patch works and it proves to be solid, it shouldn't matter how much time a person has spent on kernel development. Software developers are ten a penny these days and the law of averages suggests that quite a few of them must have genuine talent regardless of what they have previously worked on.

                My definition of inferior patches are ones that are needlessly complicated, don't fully fix the problem, are technically rollbacks, cause regressions etc.

                The best solutions often come from fresh eyes because fresh eyes can see things that old eyes can't. This is coming from what the tech space would consider to be an old man.

                1. Anonymous Coward
                  Anonymous Coward

                  Re: The way in which this turd is being pushed “top down” makes me want to puke

                  Even I've patched a kernel - it's just some C code - it's quite nice and well organized.

                  Allowing for his level of age/experience why do you find it weird someone with his background wouldn't have at least some exposure to modifying a kernel?

                  It's a little involved - but well documented https://www.kernel.org/doc/html/v4.12/process/adding-syscalls.html

                  At that point, you need a wrapper that invokes your new syscall through the platform ABI.

                  Hey presto you can now call your new syscall from C and anything that can FFI to C, you have patched the kernel.

                  Fame and fortune await - just as soon as you make the syscall do something useful.. YMMV

                2. Swarthy
                  Devil

                  Re: The way in which this turd is being pushed “top down” makes me want to puke

                  My definition of inferior patches are ones that are needlessly complicated, don't fully fix the problem, are technically rollbacks, cause regressions etc.
                  >Cough< Pottering>Cough<

            3. Anonymous Coward
              Anonymous Coward

              Re: The way in which this turd is being pushed “top down” makes me want to puke

              "because that's what they learned, because that's what they know"

              Academics then.

              The only people I've worked with over the years that are steadfastly stuck in their ways are academics. They got their Masters/PhD and never changed from that point onwards.

              I've managed to upset a couple of PhDs in my time (Cambridge PhDs!) by finding flaws in their products. They don't like it when you do that.

              Non-Academic engineers are the natural predator of Academic engineers. Not because we're better...but because we have failed over and over again and learned from it (then fail over and over again in new and interesting ways), plus we operate from the perspective of "everything is shit until proven otherwise with testing" not from the "it's done this way because my professor said so" perspective.

              Techie: Nice app man, it has a few problems though...check it out.

              PhD: I think you're mistaken, I have a PhD from Cambridge you know.

              Techie: Cool, cool...but you also have two SQL injection flaws and your licensing mechanism can be overriden by changing the system time. I can fix it for you if you like for a small fee...

              PhD: Er...no that's ok, it's on the "roadmap" for the next release.

              Techie: Sure it is.

              1. werdsmith Silver badge

                Re: The way in which this turd is being pushed “top down” makes me want to puke

                The only people I've worked with over the years that are steadfastly stuck in their ways are academics. They got their Masters/PhD and never changed from that point onwards.

                This stinks of bullshit. Postgrads work down to a very deep level on a very narrow part of a topic. They aren't generalised. Nobody would expect them to be the last word on any topic that they hadn't researched. And they generally do not throw their academic weight around, because they know what it means.

            4. bombastic bob Silver badge
              Stop

              Re: The way in which this turd is being pushed “top down” makes me want to puke

              The problem here is clearly that there are dipshit C programmers that will keep allocating memory and passing pointers around “the old way”, because that's what they learned, because that's what they know. They will call the C filesystem functions, because they always used them.

              Are you ACTUALLY suggesting that NOT using 'std' objects for your code makes you a DIPSHIT???

              Personally I find the std classes to be INEFFICIENT and CUMBERSOME, as if you were trying to type with GARDENING GLOVES ON. Or something like that. I could write better templates in my SLEEP while DRUNK and they'd be more efficient and less like "academic self-pleasuring exercises".

              Good C++ code often looks a lot like good C code, and may in fact be INTERCHANGEABLE between the two languages.

              1. GrumpenKraut

                Re: The way in which this turd is being pushed “top down” makes me want to puke

                > I find the std classes to be INEFFICIENT

                Inefficient is not a valid critique about std classes. Used right they are more efficient than the vast majority of home grown solutions. Also more correct than the vast majority of home grown solutions.

                If you can match std classes with your own solutions, congrats, you are quite a gifted coder.

                > and CUMBERSOME

                Erm, have you ever looked at C++ 11? It is out for ten years now!

                Btw. I do come from the background of what was described as "dipshit C programmers" in a comment above.

        2. jake Silver badge

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          "Linus' enthusiasm for Rust is lukewarm at best."

          Lukewarm? Seems positively frigid. From TOA, Linus is "in no way 'pushing' for Rust," and he's "open to it considering the promised advantages and avoiding some safety pitfalls, but I also know that sometimes promises don't pan out."

          Sounds like the kiss of death to me ... but with just enough hope to keep the fanbois off his back, so he can concentrate on what is important.

          1. Electronics'R'Us
            Windows

            Damned with faint praise

            An old idiom but as true today as it ever was.

            Damning with faint praise

        3. This post has been deleted by its author

        4. bombastic bob Silver badge
          Devil

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          You can polish a turd all you want. In the end, it's still a turd. Yes, I mean Rust.

          Rusty turds. heh.

          Also sounds a bit like another REG-COMMENTARD-ISM I've grown to love - "putting the lipstick on the NON-oinky end of the boar." (or similar)

      2. DrXym

        Re: The way in which this turd is being pushed “top down” makes me want to puke

        Exactly that. Count how many bugs in the CVE database are one of these things:

        - Buffer overflow / underflow

        - Double free

        - Call after free

        - Null pointer exception

        - Data race

        Rust prevents all of these things as well as many other unsafe practices. Of course it's not going to help with the other half of the bugs to do with application logic or whatever, but it's still a major update over C or C++.

        1. Anonymous Coward
          FAIL

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          >Rust prevents all of these things as well as many other unsafe practices.

          In November 2021, there is no excuse for having these bugs in your code.

          If the code you write still has these problems, today, you shouldn't be writing code.

          It's not that you create the bugs in the first place. You don't even know how to look for potential bugs in your own code. Perhaps you assume the code you write is 100% bug-free.

          There are things like Valgrind, asan, msan and ubsan, just to name a few. These are the free ones. There are also commercial ones.

          But, you've probably never heard of them, let alone used them. Had you ever used them, you would know that these kinds of bugs are not acceptable today. Not in C, and not in C++.

          I'll give you a free lesson: learn humility. Always assume your own code sucks, and look for bugs in it, twice or three times as hard as you would look during someone else's code review.

          1. Anonymous Coward
            Anonymous Coward

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            > In November 2021, there is no excuse for having these bugs in your code.

            What if it's not "your" code, but a spaghetti mess spilled in your lap.

            Not talking specifically about kernel code here, but general coding.

            In that case I think the language can make a positive difference by constraining the number of possibilities that have to carried in mind simultaneously while doing analysis and debugging.

          2. DrXym

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            The more you talk, the more I don't think you're for real.

            1. Anonymous Coward
              Anonymous Coward

              Re: The way in which this turd is being pushed “top down” makes me want to puke

              > The more you talk, the more I don't think you're for real.

              I don't care what you think. You decided to speak, removing all doubt.

          3. Cliffwilliams44 Silver badge

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            ">Rust prevents all of these things as well as many other unsafe practices.

            In November 2021, there is no excuse for having these bugs in your code."

            And yet, here we are today with this still happening? Not just in older code but even in newer code!

            Your statement is absolutely correct and it SHOULD NOT happen! Yet it still does!

            Maybe, i don't know, 40% of programmer are like you and do not make these mistakes, but that leaves 60% that do.

            I for one, am not that concerned about the Linux kernel. I think those guys and Linus have a lot of this under control, but yes, drivers! Not just Linux but also Windows! Then things like Edge devices, firewalls, security devices, Access Points, consumer internet gateways, IoT devices. If the implementation of Rust to the programming of these things helps prevent the "idiot errors" that puts everyone at risk then I'm all for it!

          4. ssokolow

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            The problem is, judging by the run-down of how consistent that "about 70% number" is across various different big-name companies that have thrown lots of effort and money at improving their security, it's simply impossible for teams of people to write safe C and C++, no matter how possible it is for one person to do it.

            See Alex Gaynor's "What science can tell us about C and C++'s security" for a bunch of citations.

            https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/

            ...or are you saying that Google, Apple, Microsoft, Mozilla, and the Linux kernel team are all too lazy to make proper use of "things like Valgrind, asan, msan and ubsan, just to name a few"?

            The effort put into "Safer Usage of C++" by the Google Chrome team sure doesn't paint that picture:

            https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub

        2. James Anderson

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          The problem is most of the kernel code and commonly used libraries were written in C before every computer was connected to the internet and random scumbags could send malicious packets down the wire.

          There was no such thing as buffer-overflow attacks when most of this stuff was written. New code written in C is written with security in mind and check for vulnerabilities. It simply a matter of using the "safe" calls and writing sensible code.

          1. jake Silver badge

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            "There was no such thing as buffer-overflow attacks when most of this stuff was written. "

            We were demonstrating buffer overflows as a potential vulnerability in the lab in the very early 1970s, maybe even the late 1960s, which led to programming away from them ... I believe the Morris Worm (1988) was the first to use it as more than a proof of concept.

    4. DrXym

      Re: The way in which this turd is being pushed “top down” makes me want to puke

      C++ has plenty of its own abominable behaviour. Even something as apparently benign as constructors is a rats nest - constructors, destructors, virtual destructors, initializers, default initializers, default constructors, deleted constructors, implicit constructors, explicit constructors, copy constructors, move constructors, the rule of 3, the rule of 5 etc.

      This mess is baked into the language and just gets worse with each release. Rust avoids all of that just by abolishing the concept of constructors, and using move by default and a derived Clone trait.

      What it means in practice is there is less opportunity for error in code which in turn means less bugs.

      1. Anonymous Coward
        Thumb Down

        Re: The way in which this turd is being pushed “top down” makes me want to puke

        > C++ has plenty of its own abominable behaviour.

        No programming language has its own inherent abominable behavior. A program may exhibit abominable behavior. The responsibility for that behavior rests solely on the programmer who wrote the program, not on the language the program was written in.

        A programming language is nothing more than a specification. I.e. a collection of rules that apply to, and are part of, an abstract grammar.

        Own your failures. You might learn something.

        1. DrXym

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          Ah right, so it's my fault and every other C++ programmer's fault that the language itself is a minefield of complexity, nuance, undefined behaviour and bugs waiting to happen?

          The reality is the way constructors are in C++ is an abomination and that's just one example.

          I honestly don't get the defensiveness here. I have to deal with crap from C++ every single day. If it's not one thing or another and I appreciate that Rust has been designed to avoid those problems either by means of the language or by enforcement in the compiler.

          1. Anonymous Coward
            Anonymous Coward

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            > Ah right, so it's my fault and every other C++ programmer's fault that the language itself is a minefield of complexity, nuance, undefined behaviour and bugs waiting to happen?

            It is indeed your fault that, while you refuse to put in the effort to learn these subtleties, you blame the language for your unwillingness to learn it in the first place.

            German, or French, or Japanese, or Italian, are very difficult languages to learn. All of them are very expressive, and are full of subtleties, complexity, nuance, sometimes inconsistent grammar rules, etc.[1]

            If you don't put in the effort to learn these languages, you will never be able to express yourself in these languages beyond some basic level, and you will never be able to take advantage of the subtleties and expressiveness they have to offer. Whose fault is it?

            -----

            [1]. Not a comprehensive list of languages by any means.

            1. DrXym

              Re: The way in which this turd is being pushed “top down” makes me want to puke

              This is beyond stupid. I DO put the effort into learning the nuances and I strongly dislike it since it is an artifact of an increasingly complex language trying to dig itself out of the hole it made.

              Maybe you're a masochist and love it when a language causes bugs through subtle mistakes that might take hours to find. Or maybe you're super programmer who never makes a mistake in the world and all your team from the most junior up are just like you. In which case congratulations and have at it. It doesn't make it clear to me why you're bitching about Rust and so defensively too.

            2. _LC_

              Re: The way in which this turd is being pushed “top down” makes me want to puke

              I second that, while noting that Italian is one of the easier and more consistent languages. For the same reason, French would be easy, when only spoken. Writing is another story, as it is a “dialectical language”.

        2. Anonymous Coward
          Anonymous Coward

          Re: The way in which this turd is being pushed “top down” makes me want to puke

          If grammar was all there is to a programming language then the compiler is reduced to a syntax checker.

          1. Anonymous Coward
            Facepalm

            Re: The way in which this turd is being pushed “top down” makes me want to puke

            > If grammar was all there is to a programming language then the compiler is reduced to a syntax checker.

            Awesome insight. Keep'em coming.

            You are aware that a compiler and a programming language are two very different things, yes?

            Why am I even asking. Obviously you aren't aware of the difference.

    5. Electronics'R'Us
      Holmes

      Re: The way in which this turd is being pushed “top down” makes me want to puke

      I have not considered C and C++ to have a real equivalence (in terms of code) for decades. Even Stroustrup admits that.

      The definition of what the language is used for has changed as well - originally it was a systems language from Stroustrup's view but in one of the later books 'The C++ programming language' he states it is a general purpose language.

      I have no problem with that and I am comfortable writing code in both languages but a major pitfall can be that someone carries the same mindset from one to the other simply because they are so very different but 'sorta' look the same.

      In the relatively early days (pre 2000) many learned the hard way that the subset of C++ that looks like C is nothing of the sort (that is why we have extern C wrappers).

      Rust is interesting and has its place as do both C and C++. I have played with Rust a bit (nothing really serious, just wanted to try it out) and some parts of it (dependencies come to mind) can be somewhat frustrating but then that is true of any language I have ever used although writing assembly code for 8 bit devices was actually a lot of fun but it requires a pretty solid knowledge of the internals of the device.

      C++ features can be abused (and is, often by newcomers) just the same as any other language but in my view (ymmv) there is just so much extra scope to produce completely unmaintainable code.

      I stay away from the 'vendor defined' features of C (bit fields are a honeypot in particular) and that, along with some self discipline in the use of various other features (no dynamic memory management in small embedded devices removes a huge headache) usually keeps me out of trouble. Oh and turning on all the warnings.

      The pitfalls in C are pretty well known (although people still fall into the traps)

  3. Anonymous Coward
    Anonymous Coward

    They keep trying to market Rust as "Like C but better".

    But it isn't that. It isn't at all like C. Pascal and Basic are more like C than Rust is.

    It lacks the power and flexibility of C for low-level or embedded work and they call that a feature.

    The documentation is like a case study in how to write bad code. eg. Using identically named variables with different scopes.

    It feels as if the designers have missed out on the lessons you learn from spending 30+ years debugging other people's code.

    I really struggle to see anything good about this language.

    1. DrXym

      That's a comment that is so wrong in every respect if there is hardly any point rebutting it in detail. Rust is is used in low-level AND embedded work and it simple to throw the safeguards off (e.g. to call C) in a block while keeping the majority of the code safe.

      If you struggle to see anything good about it to code quality, stability, maintenance then maybe you're not paying attention.

    2. Version 1.0 Silver badge
      Angel

      "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." - C.A.R. Hoare (icon), The 1980 ACM Turing Award Lecture.

      1. DrXym

        Hoare also coined the expression, "the billion dollar mistake" to describe null references. It's probably more like the trillion dollar mistake and many languages are plagued by it.

        1. Anonymous Coward
          Anonymous Coward

          [ ...] to describe null references

          There are no null references. Not in C, and not in C++.

          There are no references in C. Period.

          There are references in C++, but they cannot be null. As per the C++ Standard.

          // nulref.cpp

          int main()

          {

          int& r = nullptr;

          return 0;

          }

          >> g++ -g -O2 -std=c++17 -c nulref.cpp

          nulref.cpp: In function ‘int main()’:

          nulref.cpp:3:12: error: invalid initialization of non-const reference of type ‘int&’ from an rvalue of type ‘std::nullptr_t’

          3 | int& r = nullptr;

          Preempting:

          You can change the declaration

          int& r = nullptr;

          to

          const int& r = nullptr;

          all you want. Still the same. Null references are not allowed, and do not exist in C++.

          You can have null pointers. A pointer is not a reference, and a reference is not a pointer.

          But you're an expert.

          1. DrXym

            Null reference, null pointers. The same principle. Stop being dense.

            1. GrumpenKraut

              Technically a Type & is a Type * const, so yes. But still I have to see an instance of actually managing a (C++) reference to, say, nullptr. I have heard that by doing something yadda-yadda-circular-something this should be possible but never seen an actual instance of this.

              1. DrXym

                A C++ reference is syntactic sugar around pointers. The potential of NULL or 0L is as easy as assigning a reference to *p. It's just think it's willful or (worse) genuine stupidity by the original poster to pretend there is a difference. I'd add that NULL itself causes problems that necessitated the invention of nullptr just to avoid screwups with default parameters.

                As for Rust, in safe mode the language heavily emphasizes borrowing with lifetime checks at compile time. You can use pointers but to use them dangerously you have to encapsulate the block with an unsafe keyword minimizing the risk to its bare minimum.

  4. Anonymous Coward
    Anonymous Coward

    What if we're not kernel developers?

    Call me stupid but I still don't understand the logic: the Linux Kernel is going to get some Rust code, therefore we should all learn Rust. But most of us mortals don't do anything with the Linux Kernel except use it and maybe configure it. Is this article aimed only at kernel developers, or is it missing the words "and this will affect userspace development because...."?

    1. DrXym

      Re: What if we're not kernel developers?

      Personally I think the kernel is a specialist niche but there is ample reason to learn Rust in user space since it produces code that is absent of bugs caused by lifetime issues, null pointers, data races etc.

      Even if you learn it but still mostly program in C or C++ you'll find yourself learning from all the ways the compiler kicked your ass and the experience can help you make less mistakes in those languages.

      1. _LC_

        Re: What if we're not kernel developers?

        “... since it produces code that is absent of bugs caused by lifetime issues, null pointers, data races etc.”

        Oh my, the amount of wishful thinking that went into that one...

        1. DrXym

          Re: What if we're not kernel developers?

          The compiler enforces lifetimes and data protection and you won't be using pointers in normal programming. So no, it's not "wishful thinking".

          1. Androgynous Cupboard Silver badge

            Re: What if we're not kernel developers?

            Your "facts" will do you no good here, my friend - I suspect _LC_ has been furiously downvoting every second post here. Don't take it personally, he waded into a Java thread the other day despite clearly knowing very little on the topic.

            Meanwhile, back here, his argument seems to be no true scotsman would pass a naked pointer around. If you do, or you happen to link to a library that does, or link to a library that links to a library that does, etc, then make no mistake - the error is yours for doing so. C++ the language remains perfect and unsullied; the fact that C++ programmers are not is irrelevant.

            1. swm

              Re: What if we're not kernel developers?

              C++ is not perfect but I really like the standard template library.

            2. DrXym

              Re: What if we're not kernel developers?

              I agree the "no true Scotsman" argument applies here. The CVE database contradicts their nonsense. The existence of linters and specifications like MITHRA C & C++ contradict their nonsense. Reality of code developed over time and touched by many hands contradicts their nonsense.

              While it is good practice to try and use scoped/shared pointers, sometimes you can't especially when interfacing with other APIs, or when things reside on the stack. And real world code doesn't have the benefit of being up to date with the latest bleeding edge C++ spec.

              1. DrXym

                Re: What if we're not kernel developers?

                Correction - MISRA C/C++.

                1. adam 40

                  Re: What if we're not kernel developers?

                  Correction - MISRABLE C++!

                  1. DrXym

                    Re: What if we're not kernel developers?

                    True. It's basically another slathering of super strict static analysis to stop someone doing things the language shouldn't have allowed in the first place.

    2. jake Silver badge

      Re: What if we're not kernel developers?

      If you're not a kernel developer, you can ignore most of this.

      If you're a software developer, you should probably have at least enough of an inkling about rust to intelligently discuss it ... like it or not, there are enough fans to keep it going for a while.

  5. Plest Silver badge

    I tried to love it but...

    I tried really hard to learn RUST, seriously I did I really wanted to like it, it looks like fun but it just won't click. I found Golang, horrendous as that is to some people, just a nicer language to work with. I don't do anything deadly serious but Golang suits me and what I want. Maybe one day when I have more time I will try with RUST again as it seems like it's worth it.

    Or just give up completely and learn C++ properly for once in my life rather than faffing about in it! Ha ha!

    1. Phil Lord

      Re: I tried to love it but...

      You aren't the only one. Quite a few people have found GO easier to learn than Rust. Although Rust has a somewhat richer semantics, some of which GO will gain over time (like generics!), which will make GO more complex.

      Rust has also got easier over time. The most difficult bit is almost certainly lifetimes, and "fighting with the borrow checker" must be the most common point at which people give up. But this stage is significantly easier than in the past because the language has changed.

      1. DrXym

        Re: I tried to love it but...

        I think Go is easier than Rust in some ways. In part that is because it doesn't force you to think about object lifetimes because it is a garbage collected language. In terms of language syntax Swift, Go & Rust all seem like half-siblings.

        One thing that Go isn't great for is error handling. If you look at Swift with its try/catch behaviour (which are not exceptions but result processing blocks), or Rust with its Option / Result types is it forces the programmer to handle errors or at least stick an unwrap in their code where things can panic.

        1. trindflo Silver badge

          Re: I tried to love it but...

          I've always had an issue with garbage collected languages in time-critical venues.

          1. swm

            Re: I tried to love it but...

            There are GCs with guaranteed wait times (in microseconds). Or, in many systems, you can just turn off the GC for a time-critical section of code.

            Your mileage may vary

            not valid in all states

            void where prohibited

            etc.

  6. Anonymous Coward
    Anonymous Coward

    Rust has had my curiosity for some time. One of these days I'll play with it. But at the moment, there is Java work to be done and deadlines to be met.

    I don't expect the bottom to fall out of the Java market before I expect to retire, but I do expect Rust usage to surge compared to its current levels. It will be interesting to see if Rust has any truly new concepts I like, or if it is just a better version of a non-Java object-oriented language. At this point, I know nothing but the name...

  7. Chris Gray 1
    Meh

    Any good docs?

    I'm a language developer and compiler writer (both professional and as a hobby). Strange, I know. Anyway, I'd like to get good documentation of the Rust language (and maybe standard libraries, and some tutorial stuff). From what I've seen, the official way to do that seems to be to install the whole Rust distribution. I won't do that, except perhaps in a virtual machine, since my current language/compiler project needs my current setup. I found one free book for my Amazon Kindle, but it is very bad (not proof-read, mostly cut-n-paste, too much on crates, etc.) Anyone know where to find proper docs? Or, can they be legally extracted from the Rust distribution?

    1. pip25

      Re: Any good docs?

      The language website has decent enough docs in my experience.

      1. Chris Gray 1

        Re: Any good docs?

        Sorry, I forgot that I had gone there. I don't live in a browser - my eyes weird out with a white background (like I see now). I want something I can put on my Kindle and read in an easy chair. I guess I *could* try the Kindle's ancient web browser, but I'm not holding my breath that that would work. I was looking for a PDF (likely a .docx would be *huge*).

        1. ssokolow

          Re: Any good docs?

          If you've got a "Print to PDF" print driver, you can just click the printer icon in the top-right corner of https://doc.rust-lang.org/book/

          As for better reflow support, I think EPUB export is still on the TODO list for the mdBook renderer they use, but someone has generated an EPUB of it that they offer at http://jyotirmoy.net/others/rust-book.epub

          1. Chris Gray 1

            Re: Any good docs?

            Thanks - I tried. In my upper-right corner I just get a link to Git for the doc sources. If I try the browser's print function, I only get the one page, as expected.

            So, I went and got my old Kindle (the original "Kindle Keyboard"). The web browser is under "Experimental", but it had bookmarks for Wikipedia, Google, etc. None work. The only pages I could load with it are some very old straight HTTP pages. Errors it shows suggest that it can't do HTTPS. Oh well, thanks anyway.

            1. ssokolow

              Re: Any good docs?

              Huh. It should be taking you to https://doc.rust-lang.org/book/print.html and automatically triggering the Print dialog.

              Does going to that URL directly work for you?

              If so, another thing you could try is feeding that HTML into Calbre and asking for a format that reflows better than PDF.

              1. Chris Gray 1
                Happy

                Re: Any good docs?

                That worked great - the PDF is now on my Kindle. Thank you very much!

  8. Paul Hovnanian Silver badge

    It's another string to your bow

    Another arrow in your quiver.

    A language that would offer multiple choices of strings to shoot one arrow would be Perl.

    1. jake Silver badge

      Re: It's another string to your bow

      You say type that like it's a bad thing ...

  9. Version 1.0 Silver badge
    Childcatcher

    A new language

    I started writing everything in Assembler but of course I was stuck on the CPU, then switching to FORTRAN was nice and easy because I could write code for more places. When it was replaced with Pascal it made the OS coding environment easier, then C was useful, then Modula-2 and along came C++ and Visual Basic ... each one eventually replacing most code writing ... Rust is today's favorite ... wait a few years and it will be replaced with a new language.

    New languages offer advantages but coders are still doing the coding, it's the people who write the code who matter far more than the language, so all the kids are going to have to learn the new language and they always learn a hell of a lot more when they look at the previous languages.

    1. jake Silver badge

      Re: A new language

      We are not discussing general purpose coding, we're discussing kernel coding.

      Of all those languages you mention, just one (plus assembler) is useful for coding kernels. Guess which one (plus assembler) kernel coders actually use?

      But I agree, learning more than one language is a good thing, and learning many languages is better ... The only question is, where is the point of diminishing returns?

  10. Elledan

    More symbol soup

    Problem with Rust is that it violates the Steelman requirements in just about every way imaginable. It doesn't use clear code without the use of cryptic symbols, it doesn't reduce the number of ways in which code can be written for certain functionality. It doesn't promote the prevention of logic errors, or the prevention of invalid return values (e.g. contract-based programming).

    It's really not very different from C++, just with yet another weird set of symbols to learn, no OOP and no templating. The DoD has certified (a) C++ (subset) for use in jetfighter avionics, so it cannot be that problematic if it gets to join the likes of Ada/SPARK.

    Perhaps the most cardinal sin of adding Rust to the Linux kernel is that it means that the code base with that is no longer in a single language, but schizophrenically split up into a multitude. People (like me) who had to deal with the craziness of Objective-C, with mixed C and Smalltalk syntax can attest to this. Yet Objective-C has the distinct benefit of being a single language, not two distinct and incompatible ones.

    Basically, either rewrite the Linux kernel in Rust, or leave it in C. Don't go mixing languages.

    1. Anonymous Coward
      Anonymous Coward

      Re: More symbol soup

      At least Objective C is a proper superset of C despite looking a bit weird. That's a lot better than the other way around (C and C++).

  11. Loyal Commenter Silver badge

    ...some commands are much slower than their C ancestors and others don't support all the options...

    There's the bit that concerns me right there. The words, "much slower". Yeah, that might be fine in user code that isn't somebody else's dependency, but if code performance is noticeably degraded, vs something that already exists and works, then all the benefits of "you don't have to be careful when writing your code" go out the window. As gamers like to say, "get good".

    1. ssokolow

      Re: ...some commands are much slower than their C ancestors and others don't support all the opt...

      I'm familiar with the project.

      The performance difference is down to uutils coreutils using less optimized algorithms. Nothing to do with differences in the potential performance the languages can achieve.

      (I remember reading blog posts by people seeing to match various coreutils components in Rust as learning exercises, and the main things they demonstrated are how far removed from naive algorithms the GNU coreutils implementations are and how much effect simple but non-obvious things like not-quite-optimal choices for buffer sizes can have on overall performance.)

      1. Loyal Commenter Silver badge

        Re: ...some commands are much slower than their C ancestors and others don't support all the opt...

        Well, that all sounds fair. I suspect a fair few things are down to such vagaries as compiler optimisations as well.

        There is a general point here, though, which I think another commenter has made, about the trade-off between robustness and speed. For example, unchecked memory access is always going to require less computation than bounds-checking. This either translates to slower, or more computationally intensive.

        There is an argument to be made that such tasks could conceivably be hived off into dedicated hardware, which could limit the impact on speed, but still increase overall power usage, and, if you're lucky, also summon the eldritch horrors that come with asynchronicity, such as race conditions.

        1. ssokolow

          Re: ...some commands are much slower than their C ancestors and others don't support all the opt...

          True. The Rust approach is generally to look hard for ways to design APIs that can ensure correct usage without need to check at runtime and, if that's not possible, to offer a safe checked version and an unchecked version that must be called using the unsafe keyword, with the intent that you build your own "safe AND performant" abstraction around it at whatever higher level is appropriate to avoid the need to reason about program behaviour globally.

          To elaborate on a couple of examples I mentioned in another comment:

          1. The iterator APIs rely on how you need the unsafe keyword to dereference raw pointers or do unchecked array access to avoid the need for bounds checks. (Beyond the obvious terminal condition for the loop.) It hands you items, and you can't synthesize new pointers which might need checking.

          2. The typestate pattern leverages the ownership and borrowing system to invalidate variable bindings to old states in a state machine, so you can selectively implement methods and attempting to call a state transition that's not valid will result in either "no such method .add_header on HttpRequest<BodyStreaming>" or "attemped use of moved value" errors at compile time.

          Rust doesn't make you worry about whether your struct is POD like in C++ because, unless you explicitly create a "trait object", methods are just syntactic sugar for free functions that take C-style structs as their first argument with the appropriate compile-time checks for which types can be passed in.

          (If you do create a trait object, it's a fat pointer, consisting of a pointer to a C-style struct and a pointer to the vtable. Still no surprise addition of a vtable to each struct instance... though it will reorder fields to do automatic structure packing unless you specify repr(C) to ask for a C ABI-compatible representation.)

        2. This post has been deleted by its author

      2. EveryTime

        Re: ...some commands are much slower than their C ancestors and others don't support all the opt...

        Why don't you talk about the details of the "less optimized algorithms", and how they directly relate to the language choice?

        It's not that they didn't have the original algorithms to look at. The source code was right there. They had no qualms about directly copying/transcribing everything. They could benchmark and profile to see where the time was lost.

        The coreutils programs are clever because they selective use mmap() and family when that's the most efficient way to read, process and write large objects. That's not a one-off trick. It's an efficient and effective programming model. C is flexible and expressive enough to support it, notably the ability to allow page aligned data to remain aligned throughout processing.

        A similar challenge exists in the kernel. Many structures are carefully aligned within words, cache lines and pages. This is important for performance, but it often critical for correctness.

        The correctness issue is a challenging one. It's often more subtle and pervasive than non-kernel programmers realize. You can't just "encapsulate it in 'unsafe'". Some objects must always be cache aligned, or avoid spanning pages. They can't have language-imposed headers, and they must be directly manipulated without allocating and copying to align them. Even if you solve every current problem, you need the flexibility to address new ones without a re-write when new hardware has an errata like "never allow an [interrupt] to occur when taking a triple page fault during the read of this structure in EL1 or higher", which effectively means the table cannot span a single physical page.

    2. Geez Money

      Re: .some commands are much slower than their C ancestors and others don't support all the options.

      You're comparing a work-in-progress project that's bordering on proof of concept with a mature and highly optimized product, of course the latter is faster. Nothing to do with languages or authors or potential, coreutils is just tuned right.

  12. Mike 125

    safe 'subset'

    >>>

    https://lkml.org/lkml/2021/4/14/1023

    Why Rust?

    Rust is a systems programming language that brings several key advantages over C in the context of the Linux kernel:

    - No undefined behavior in the safe subset (when unsafe code is sound), including memory safety and the absence of data races.

    <<<

    'Safe subset' is what this is all about.

    >At the same time, Ojeda insisted, if you program with Rust well, you "can generate code as good and fast as C or C++."

    Yea, of course you can. But in his insistance, he conveniently leaves out safety.

    I can write safe and portable system code in C. But it's slower than platform-optimised code, which may well produce undefined behaviour if compiled for the wrong platform.

    There's an unavoidable conflict between speed (efficiency) and safety. At the system level, speed counts. If there's ever a speed issue in Rust (and there will be), what will happen? Turn off the safety + call some C. So it doesn't help.

    What helps is 'programming well', running lots of tools, and testing.

    For applications, fine, bring on Rust or whatever.

    1. ssokolow

      Re: safe 'subset'

      The design of Rust is all about encapsulating unsafety.

      Things like Vec<T> and Arc<T> are implemented using unsafe, but they expose APIs that ensure that you can't break their invariants without using unsafe yourself.

      Thus, you can have small portions of the codebase that get much more intense auditing because you know that, as long as they're sound, the compiler won't let the safe parts of the codebase mess that up.

  13. 502 bad gateway
    Paris Hilton

    Seconds out, round two

    Nothing like an article making (possibly inflated) claims about a language to rekindle the good ol’ language wars. For myself, it’s probably incentive enough to have another look at rust, but my eyes do tend to glaze over (lack of interest) when OO-zealots start laying out their stall.

  14. Henry Wertz 1 Gold badge

    Rust's memory safety

    A quick comment on how Rust guarantees memory safety -- the language is arranged so variables are immutable (created then can't be changed) unless you specify it's mutable (can be changed later.) The variable is "owned" by a particular bit of code, if you call a function and pass it to that function, it owns the variable unless it's returned at the end. Things like this let memory safety (bounds checking, not using out-of-scope or freed variables, and so on) to be checked AT COMPILE TIME using static analysis. It's very pedantic, any potential safety issue causes a compiler error. Since this analysis is done at compile time to show memory safe variable and memory usage, there is no overhead at runtime. There is an "unsafe" trait that can be put on functions, There's no sensible analysis to be done if some function's calling out to a C function or reading or writing some piece of hardware or whatever, if you're doing something like that that'd make the compiler barf you mark it unsafe.

  15. Anonymous Coward
    Anonymous Coward

    C? Really? Still?

    I thought the Linux kernel was rewritten in systemd years ago.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like