back to article Linus Torvalds says Rust is coming to the Linux kernel 'real soon now'

At The Linux Foundation's Open Source Summit in Austin, Texas on Tuesday, Linus Torvalds said he expects support for Rust code in the Linux kernel to be merged soon, possibly with the next release, 5.20. At least since last December, when a patch added support for Rust as a second language for kernel code, the Linux community …

  1. Henry Wertz 1 Gold badge

    Sounds good to me

    Sounds good to me.

    Rust will be unfamiliar and something new to learn to many, but it's more like C than like, say, Python, Java, or C# etc. I found it relatively similar to a very pedantic dialect of C -- that's both the weakness and the strength of it.

    Weakness -- I found it hard to use. It's very pedantic and requires some things to be explicitly stated that are not even required in C let alone some "higher-level" languages. There were some hoops to jump through to get things done that are easier in both plain C and in other languages.

    Strengths -- those hoops and pedanticness I was talking about? These allow the compiler to PROVE the code is safe from many problems (you cannot have buffer overflows, memory leaks, if you're using threaded code it proves you're access to any shared data structures is thread-safe, among others). It's not imposing overhead to do garbage collection, check buffer lengths, run some expensive mutual exclusion system at runtime, the very pedanticness I was saying is a weakness is a strength here in that these properties can be proved at compile-time. Similar to C# in one aspect, Rust does have a way to flag "unsafe" calls etc., so you can interface with code written in conventional languages.

    So -- the strengths mentioned are obviously good things for kernel code, keep the kernel bugs down to actual logic errors and avoid the unsafe buffer use, memory leaks, and unsafe thread behaviors. The weaknesses I mention are not significant weaknesses for kernel code, there's already a lot of restrictions on what can and should be done for drivers and so on written in C anyway, documented in both the kernel docs for writing drivers and so on, and embodied in the sample drivers included for most Linux subsystems. Rust will simply take advantage of these restrictions to perform some static code analysis ahead of time.

    1. bazza Silver badge

      Re: Sounds good to me

      I firmly agree.

      I'm also relieved. I think that, long term, Rust is the way OS kernels will go, because of the pedantic compiler / memory safety / etc. The "proof" starts becoming a reason to use the OS, if one is security minded. If Windows / MacOS / FreeBSD all went towards Rust, and Linux didn't (or at least, didn't give it a go), Linux might in the long run have become a liability.

    2. captain veg Silver badge

      A pedant comments...

      > hoops and pedanticness

      Er, pedantry.

      -A.

  2. martinusher Silver badge

    Seriously, are programmers that bad?

    I had a look at "memory safe" Rust and found the C problems it manages are the sort of problems that an experienced C programmer will never make. (OK, "never" is a big word, we all make mistakes but but...) The reason is straightforward -- writing any kind of C level code is a highly disciplined activity where the programmer has to keep in mind exactly where everything is and what its doing at all times. Its true that if you're writing a complete piece of software in C, say and embedded application -- then higher level code will still be written in C but at that point the C programmer will avoid mixing 'high' and 'low' level functions because it breaks the overall structure of the program. Still, if Rust can do the job of "higher level low level code" then why not?

    I can't quite see what the problem that Linus has with Perl. Perl is a powerful language but ultimately "its just another language". It excels at file manipulation which is why you might come across it orchestrating complex builds (I've used it for this purpose). I'm not an expert, a "Perl Monk", so this might have saved both me and the code since Perl has a great many shortcuts that allow people to write extremely terse and so essentially unreadable programs. You don't have to do this, though -- you can write a fairly normal looking piece of software and if you add appropriate comments where the syntax might be a bit arcane (pattern matching and search within files, for example) then others shouldn't have a problem with it. Like with C you've got to be disciplined and above all resist the temptation to show off -- unless collecting millstones is your thing you need to be able to pass your magnum oerve onto someone else.

    1. elsergiovolador Silver badge

      Re: Seriously, are programmers that bad?

      There is no money for workers doing this kind of job. So as the rewards are low, it does not attract talent that could score more doing something else.

      Big corporations especially want to use free things - including labour. If you look at CEOs or shareholders, their biggest contribution are their contacts and money (likely from wealthy parents), not actual meaningful work.

      In their interest is to keep engineering wages low, so that the influx of newcomers into "their" world is as low as possible and only those "accepted" can enter it.

      So yeah, with things like "co-pilot" and "safe" languages the agenda is to make anyone being able to "code" - ideally accepting or rejecting the code proposed by the AI and get paid minimum wage (with benefits paid for by engineers caught by higher tax rates - again part of multi-faceted effort to ensure a worker will always be a worker and can't climb the class ladder).

    2. Gene Cash Silver badge

      Re: Seriously, are programmers that bad?

      experienced C programmer

      You got some of them? We could use one or two. We won't pay them what they're worth, of course.

      The people we've got can't remember the order of arguments to strcpy.

      you can write a fairly normal looking piece of software [in perl]

      Yeah, and I hope some day to see some. All the perl I've had to deal with has been 1200baud-modem-line-noise. I don't even attempt to understand it, I just rewrite it in something sane. I've yet to see any perl with comments.

      1. elsergiovolador Silver badge

        Re: Seriously, are programmers that bad?

        strcpy is unsafe, so it's good they don't remember it (hopefully because they don't use it).

      2. jake Silver badge

        Re: Seriously, are programmers that bad?

        " I've yet to see any perl with comments."

        Judging by the rest of your post, that's probably no great loss.

        1. Charlie Clark Silver badge
          Joke

          Re: Seriously, are programmers that bad?

          Comments in Perl are likely to be ironic: what did you think `!{}=?` means? Presumably, you can even run in it in ironic mode where the comments are taken into account! ;-)

      3. Anonymous Coward
        Anonymous Coward

        Re: Seriously, are programmers that bad?

        "experienced C programmer

        You got some of them? We could use one or two. We won't pay them what they're worth, of course."

        I used to be one, the guru who troubleshoots any bad C that compiles and gives different results, depending on the platform. And I quit being a dev in the late 90s exactly for this reason: not a kopeck for us.

        "The people we've got can't remember the order of arguments to strcpy."

        Ah, ah, lol. I remember well those, see above !

        "you can write a fairly normal looking piece of software [in perl]

        Yeah, and I hope some day to see some. All the perl I've had to deal with has been 1200baud-modem-line-noise. I don't even attempt to understand it, I just rewrite it in something sane. I've yet to see any perl with comments."

        I've written something sane and understandable 10 years after, as I was later told. But yes, very few people have actually had the chance to see something sane in Perl.

        A bit more in C, since it's less crazy.

        Hopefully, in Rust, 90% of written code will look sane. Such is definitely not the case in Perl or C/C++ !

        This is a good move tm.

        1. elsergiovolador Silver badge

          Re: Seriously, are programmers that bad?

          When I put "C developer" in the job boards, the listings offer shockingly low pay.

          Why would anyone bother doing C apart from hobbyists if you can make much more money with seemingly simpler stack like Go?

          1. cyberdemon Silver badge
            Linux

            Re: Seriously, are programmers that bad?

            You are looking at the wrong job boards maybe, or perhaps you should study some microcontroller datasheets and widen your search to "embedded C / firmware engineer", because my company would pay good money, ~£70k, for a good embedded C developer.

            We are using Zephyr RTOS and stm32, and although they (zephyr) are also considering Rust support, it isn't near reality yet. Plenty of really scary C macro-fu in their build system, mostly to support devicetree across various microcontroller architectures, and it's really nice. But you need to know how to do safe object-oriented programming in C. And if you think that's impossible, you are not ready.

            1. Electronics'R'Us Silver badge
              Holmes

              Re: Seriously, are programmers that bad?

              I have been doing embedded C for over 30 years for various microcontrollers; the only real difference is the number of peripherals actually on chip. One or two back then, dozens or more now.

              The first one I used with embedded peripherals (not my first microprocessor plus peripherals which was an 8080) was a 65121 from California Micro Devices which was based on the 65C02 which was admittedly written in assembly.

              I completely agree that it is perfectly possible to write safe object oriented code in C (and probably any language we care to name, although there the question might be why).

              Among other things some of my projects require true hard real time performance such as ADC and DAC interfacing (without that, the standard DSP equations break) so the concept of task and time windowing becomes very important. Deterministic performance is not difficult to get, but apparently some find it too difficult.

              Sometimes I even use a small microcontroller that is dedicated to the task of actually doing the interfacing with DMA upstream to simplify the application layer.

              I have used Rust a bit and I find the syntax a bit arcane but I can live with it.

              I have seen many a C macro fu for device dependencies; those 'families' of devices aren't always as close as the vendors try and tell you.

      4. bazza Silver badge

        Re: Seriously, are programmers that bad?

        @Gene Cash,

        Yeah, and I hope some day to see some. All the perl I've had to deal with has been 1200baud-modem-line-noise. I don't even attempt to understand it, I just rewrite it in something sane. I've yet to see any perl with comments

        The way you describe it, I'm wondering if the "something sane" might include WhiteSpace, or BrainFuck (at least, sane in comparison)!

    3. VoiceOfTruth

      Re: Seriously, are programmers that bad?

      -> I can't quite see what the problem that Linus has with Perl.

      I can. It's unreadable unless you are writing and reading Perl regularly. I happened upon some of my own Perl code from 20 years ago recently, after a long hiatus. I could not understand what I had written. It worked, but I don't know how.

      -> Perl has a great many shortcuts

      See above, as indeed you did!

      -> you can write a fairly normal looking piece of software

      I have rarely seen normal looking Perl, and I used to look at Perl a lot back in the cgi-bin days.

    4. bazza Silver badge

      Re: Seriously, are programmers that bad?

      I had a look at "memory safe" Rust and found the C problems it manages are the sort of problems that an experienced C programmer will never make. (OK, "never" is a big word, we all make mistakes but but...)

      As you go on to say, it takes discipline. But the long, long list of major security / functionality bugs that have been found in lots of "really important old code" (including in the Linux kernel, and lots of open and closed source stuff written in C) is pretty solid evidence that the required level of discipline is not achievable.

      The interesting thing to ask is, with a strict disciplinarian compiler like Rust that won't let you make any mistakes of certain sorts, will that do the trick?

      There's no solid answer, but I think that what we'll find is that the places where it remains possible to have made mistakes in source code are usefully pushed away from places where mistakes can have the severest consequences. For example, reading a network protocol stream. If you can't have a buffer overrun, that cuts out a ton of arbitrary remote code execution security hazards. Make a mistake in intepretting the protocol data can still cause problems, but this is more likely to end up with a straightforward (and fairly safe by comparison) program crash.

      Years ago, the Institute of Electrical Engineers (now the IET) here in the UK did a study of different safety critical software systems (back in the 1990s). They looked at system source code, in-service support logs, the lot. What was interesting was that systems written in Ada - the "safety critical language du jour" - weren't actually any better in certain metrics (e.g, semantic errors per 1000 lines, run-time faults per 1000 hours) than any other language. The very best system covered in the report was an air traffic control system that IBM had built in C (the very last language one would even then have picked for a safey critical application). The reason why was because IBM had put its very best developers on the job, and that being IBM from a long time ago, they just didn't foul up very often. But, not never. (I think the report had an analogy, that writing an airtraffic control system in C and having to get it right was the same as cutting your toenails with a big, powerful chainsaw; you're going to be very careful!

      Extend that to today, and use of Rust (in, well, anyhting), and we can expect there to be issues, even though Rust itself eliminates a whole class of error and despite the time saved in development / testing / code review.

      1. VoiceOfTruth

        Re: Seriously, are programmers that bad?

        -> The interesting thing to ask is, with a strict disciplinarian compiler like Rust that won't let you make any mistakes of certain sorts, will that do the trick?

        This is a very important question. It would be very tempting to some people to say the equivalent of "I have a firewall so I don't have to be quite as careful" if they are using Rust. I am not very familiar with Rust, but the language doesn't matter. I would not want to get into a situation where somebody just tacitly accepts code that is written in Rust is better than C. It still needs reviewing.

        1. bazza Silver badge

          Re: Seriously, are programmers that bad?

          I agree with that. Though hopefully, the general average standard is raised (provided that code review work carries on as before).

      2. An_Old_Dog Bronze badge
        Meh

        Error Types

        One sort of error no compiler can help with is semantic errors with respect to the program units themselves, that is, a programmer thinking function parameter "velocity" represents meters/second, instead of miles/hour, or vice-versa.

        1. Philip Stott
          Coat

          Re: Error Types

          <PEDANTRY>

          I think you mean speed *not* velocity (velocity has a direction).

          </PEDANTRY>

          1. Michael Wojcik Silver badge

            Re: Error Types

            Velocity is a vector, but it still has units, so the Metric-versus-English problem still applies. OP didn't say "velocity" in the example was a scalar type; it could have been a vector (in the hypothetical program).

            1. cyberdemon Silver badge
              Headmaster

              Re: Error Types

              Can you please stop using the word English to describe the daft system of units that existed before the 20th century? Nobody in England, or indeed Britain, uses them anymore. (Except the Pint. But only because the British pint is bigger than the American pint.)

              It's not Metric versus English, it's SI versus Imperial. And that empire withered and died a long time ago.

              But you're right that we can still express velocity in metres per second, obviously.

              1. jake Silver badge
                Pint

                Re: Error Types

                "Nobody in England, or indeed Britain, uses them anymore."

                Have a pint? Or does the bathroom scale say that you weigh too many stone in these sedentary Covid times? Perhaps you should be walking/jogging/running a few miles per day? Did the milkman deliver your pint this morning? How many cubic feet of gas do you use boiling your kettle per month? If you're on the electrics, how many kWh does it take to boil the kettle?

                And etc. You Brits are funny when it comes to teh metrics :-)

                "The nice thing about standards is that there are so many of them to choose from." —Andrew S. Tanenbaum

        2. birkett83

          Re: Error Types

          The rust compiler can *absolutely* help you with that.

          You can define zero-sized types for MilesPerHour, MetresPerSecond, SmootsPerFortnight etc and then give your velocity struct a generic parameter for the unit. The compiler will then give you a type error if you try to use a Velocity<MilesPerHour> where it was expecting a Velocity<MetresPerSecond>.

          Since the units are zero-sized types, they're not actually stored memory when the program is run, they exist only at compile time. This is an example of what rust developers call "zero-cost abstractions".

          The ability to enforce these kinds of safety properties is a pretty neat application of Rust's strong type system and it's considered good practice in Rust. Have a look at the Euclid crate for an example of this pattern being used in practice.

          Cool huh?

          1. bazza Silver badge

            Re: Error Types

            I didn't know it could do that. That's fab. Dimensional analysis built into the compiler? Woohoo!

            Ada could do something similar I think, but it relies on a runtime engine whereas Rust doesn't.

      3. martinusher Silver badge

        Re: Seriously, are programmers that bad?

        >The very best system covered in the report was an air traffic control system that IBM had built in C (the very last language one would even then have picked for a safety critical application).

        I have an idea why this is having worked on projects for British Telecom 40 years ago or so. The amount of design documentation and testing -- paperwork -- was off the scale, mounds of it. So you could say that ATC system was first built on paper -- designed, redesigned, simulated, tested and tested again -- and then implemented in C (and tested, retested, tested again and so on). Its a very lengthy and, by modern standards, not at all cost effective way to write code. Its the "quick, cheap, good, choose any two" thing where management invariable wants all three. (FWIW I've never entirely solved this problem but I figure if I ever did I'd make big money of the pundit circuit.)

        1. bazza Silver badge

          Re: Seriously, are programmers that bad?

          I think it depends on the cost of a mistake.

          That way of software development - building it on paper first - was / is reputed to run at something like 1 line of finished code per day per developer on the project. Slow, laborious, but if done right for the right reasons, there's likely no faster way, and it's cost effective (in the sense that it might cost millions to develop, but possibly untold billions if it ever goes wrong).

          The Boeing 737MAX is a good example of the price of doing it badly; Boeing built MCAS "on paper", handed that over to another company to do the coding. That company's developers took one look at the paper design, and really didn't like it. Apparently, there was an exchange of emails between them and Boeing asking, "are you really, really sure?", and Boeing replied "yes, get on with it". Okaaaaaay. That messaging exchange probably counts as one of the most significant in the history of safety critical coding. I dread to think how muh money that mistake by Boeing has cost them, and of course it tragically lead to hundreds of avoidable deaths.

          1. CrackedNoggin

            Re: Seriously, are programmers that bad?

            Uh ... Boeing decided to use two attitude sensors. The algorithm should be simple, right? If either one goes bad, then issue an alert so that the pilots would take manual control. Oh, can't do that because then it would be necessary to add the procedure for "taking manual control" to the manual and training - which was not allowed because it require extra training and thus the plane could not be certified as "identical to the existing 737 in terms of operation and training", and would a longer and more detailed re-evaluation to make sure there were no introduced safety safety safety safety safety issues.

            So the software company was instructed to use both two sensors, for extra safety, but also to never report an errors. So if the sensors differ, how to know which one was correct? No way to know, so the software company asked to use just one.

            I'd like to see what was written on that paper you mention. I think it was some nonsense written by the a financial dept employee, because most of the competent engineers were already laid off, because they talk back more than outsourcing companies do.

      4. nijam Silver badge

        Re: Seriously, are programmers that bad?

        > The interesting thing to ask is, with a strict disciplinarian compiler like Rust that won't let you make any mistakes of certain sorts, will that do the trick?

        Absolutely not. Of course.

        And apropos Perl, the worst "line noise" I encounter is comments from people who criticise it for using a notation thy're unfamiliar with. At least it's not as bad as the abomination that is Python: "Yea! Let's make white space semantically significant! That worked so well in Makefiles!"

    5. Steve McIntyre

      Re: Seriously, are programmers that bad?

      Yes, seriously - programmers are that bad. All of us. I've been a professional software engineer for 25 years, doing lots of C (and other languages) along the way. I've genuinely described myself as "thinking in C" at various points.

      However, I've lost count of the number of times that I've seen *good* programmers make mistakes, myself included. C makes it *very* easy to make certain kinds of mistake, and as an industry we *keep on* making those mistakes. Rather than just push the "find better programmers" argument, can't we try and improve the tools too?

      1. Michael Wojcik Silver badge

        Re: Seriously, are programmers that bad?

        I agree. I've been writing code in C since 1988, before the language was standardized. I had the original K&R book mostly memorized, and most of the C90 standard memorized; I reviewed the changes to the language in C94 (which admittedly wasn't much), C99, and C11. I've read the Rationales that accompany the standards. I've read (and re-read) a number of books on C development, such as van der Linden's Expert C Programming and Jones' The New C Standard.

        I've written, tested, debugged, and maintained hundreds of thousands of lines of C, my own and other people's, most of it system software such as middleware and application engines. I've done device drivers, graphics kernels, compilers, debuggers. I've worked on embedded systems, micros, minis, mainframes. C is still the language I work in most often.

        Software quality is one of my research areas; security is another. These are things of considerable concern to me. I do extensive refactoring and prefactoring of code to wrap the (very primitive) C standard library in higher-level abstractions and simplify implementing cross-cutting aspects.

        I still make mistakes that the Rust ownership model and borrow checker would catch at compile time. I know that because I've written a little Rust and I'm gradually doing more of it.

        I've worked with a great many programming languages, from pretty much all the families, from assembler (on a dozen architectures) through 3GLs, functional, OO, and multiparadigm languages. I've used scripting languages and data-flow languages and constraint languages and lots of DSLs.

        Rust is pretty good. It makes a substantial contribution to improving software quality. A very disciplined C developer can indeed write C which is much, much better than run-of-the-mill C code; but automating the detection of significant classes of issues at compilation time is still better.

        1. Anonymous Coward
          Anonymous Coward

          Re: Seriously, are programmers that bad?..who remembers the HLL debacle of the 1980's?

          Since 1988?

          .. then you will have pretty much missed the great Pascal, Modula II/III, ADA fiascos of the early / mid 1980's when HLL's were going to solve all the worlds software problems. C was going to be history by 1990.

          I can think of at least one major PC software product, one of the biggest names at the time, that was destroyed by the 1980's HLL fad. After their great Modula II total rewrite fiasco they never recovered their market dominance. The Modula II version was so slow as to be unusable. Competitors who stayed with mixed asm / C survived and prospered. Until crushed by MS in the 1990's..

          Every single attempt since the 1960's to replace a low level system languages with a HLL has failed. Starting with the PL/I train wreck in the 1960s. It was going to replace every other language. Although Algol on some hardware came very close in the 1970's. Algol was such a nice language to work with.

          Since then. If you want performance and optimum use of platform resources, its C. Some projects have started in a HLL but once they got traction the simplest and cheapest way to get a performance boost, was to start rewriting in C.

          Rust tries to solve problems that were solved many decades ago by using code validation tools. If you are writing high level applications , fine. But for system software, C written by people who know what they are doing will beat it ever time. Easily.

          Of course if you really know what you are doing then mixed asm / C will keep the pipelines / IPU's filled with no blocks and the cache lines prefetched close to 100% of the time. Which is something a HLL could not even attempt to do. No matter how many PhD's are involved. Look at enough compiler code-gen output disassembly and you will see what I mean.

      2. bombastic bob Silver badge
        Devil

        Re: Seriously, are programmers that bad?

        programmers are that bad. All of us

        Except for ME, of course! No need to include ME in your self-deprecation.

        1. jake Silver badge
          Pint

          Re: Seriously, are programmers that bad?

          Exactly, Bob. We're perfect.

          ::ahem::

    6. Charlie Clark Silver badge

      Re: Seriously, are programmers that bad?

      I think one of the issues is that modern machines are much more complex than they used to be and modern programs and OSes are much more sophisticated. This means there are risks for even the best programmers on their best days and I think there are enough examples of this. Actually, any time a programmer thinks they're great is probably a time to be wary.

      Rust seems to be following the "building a better mousetrap" approach and has managed to chalk up some impressive results demonstrating effectively that it solves some common problems, without introducing too many new ones. Kernels are one of the areas where this kind of thing is really important.

      In contrast, Perl follows the swiss army knife approach and tries to do everything and, while lots of people are very happy with this, I think there are lots of examples of why people have switched to other languages (Python, Go, Rust, etc.) for some of the tasks where maintenance is likely to be important.

      1. werdsmith Silver badge

        Re: Seriously, are programmers that bad?

        RUST is an excellent teacher, for bad programmers like me.

        I attempt to do some coding in RUST and the compiler gives me such a bollocking that I am more careful next time.

        1. bazza Silver badge

          Re: Seriously, are programmers that bad?

          I'd like to see compilers get "voices", in the same way you could get different "Voices" for TomTom satnavs. I'd like the voice of John Cleese telling me whenever I've used an uninitialised variable, etc!

    7. Anonymous Coward
      Anonymous Coward

      Re: Seriously, are programmers that bad?..ah the downvotes

      Your are probably old enough to remember the at least five or six other languages that were going to "replace C" over the last five decades. Problem was they were all big, inefficient had even more problems of their own.Plus the sort of people who write crap code in C always find new and creative ways of writing crap code in the new wonder language.

      The problem is not the language. The problem is the person writing it. A well disciplined programmer can write rock solid code in any language. A sloppy programmer will write bad code in any language.

      Looking at the supposed advantages of Rust I just see Yet Another Bloody Language that supposedly "fixes" problems in C that were caught by aggressive compiler warning, advanced versions of lint and various code validation tools which we had 30 plus years ago. And rarely arose when a dev team enforced very rigorous coding standards. I'm not talking stupid comments in the code rules either.

      If you write code that looks just like your term project at uni its going to be crap. There again that is hardly surprising as I have yet to meet a graduate of any Cop Sci Dept in the last few decades who was taught anything about pragmatic real world code base architectures, defensive programming, debugging, etc etc.

      What do you mean stuff goes wrong? Error message and resource failures have to be handled? The API documentation is wrong? I have to find and fix sporadic non-reproducible bugs?

      Welcome to the real world.

      Rust is not going to solve any of these problems. Because none of the previous "wonder" languages did either. In the same way that the next Fad Diet that comes along cannot solve the problem that someone eats too much, gets too little exercise, and is generally an all round total slob.

      Discipline, old boy, discipline

      1. jake Silver badge
        Pint

        Re: Seriously, are programmers that bad?..ah the downvotes

        "In the same way that the next Fad Diet that comes along cannot solve the problem that someone eats too much, gets too little exercise, and is generally an all round total slob."

        Methinks you're going to get a bunch of downvotes from so-called "devs" who are total slobs linguistically, with no control over their diet[0], and a severe aversion to exercising common sense.

        I've had to maintain code like that, too ... Beer. Not an answer, but it helps.

        [0] In the "executive meeting" sense of the word.

  3. Anonymous Coward
    Anonymous Coward

    A lot of fun to be had writing the new coding style soon

    Coding style definitely helps keep things sane.

    Will have to be updated (written from scratch) for rust.

  4. jake Silver badge

    "Real Soon Now."

    Ah. So roughly half past the twelfth of Never, then.

    1. wolfetone Silver badge

      Re: "Real Soon Now."

      Definitely maybe.

      1. 42656e4d203239 Bronze badge

        Re: "Real Soon Now."

        Now, in a minute....

        1. GuldenNL

          Re: "Real Soon Now."

          Typical non-technical CIO -“C’mon! what am I paying you for?”

  5. HammerOn1024

    People

    "People don't understand the VM subsystem, even when it's written in C,"...

    Then you need new people.

    RUST... just more bloatware for script kiddies.

    From the tales of "Real Men Don't Use Pascal": If you can't do it in FORTRAN, do it in C. If you can't do it in C, do it in Assembler. If you can't do it in Assembler, do it in Binary. If you can't do it in Binary, it's not worth doing!

    1. Munchausen's proxy
      Flame

      Re: People

      "People don't understand the VM subsystem, even when it's written in C,"...

      Then you need new people.

      ---

      Or a new VM subsystem. Overcommitment is an abomination whose only purpose is to allow bad code to run (for a while, anyway).

  6. karlkarl Silver badge

    There are going to have to be some fairly substantial binding layers put in place before the Rust can even interoperate with the existing C code. This is going to take a lot of work to ensure safety (and maintenance of these binding layers will be endless).

    I am certainly not against a safer systems language being used but I don't think the benefits will be quite as much as many people think when there hear "Rust == Safe == Good",

    C++ is ~90% safe and they pulled out of that project (even though binding between C and C++ is easier compared to any other language), but possibly the higher safety guarantees that Rust provides will tip the scales and make it worth it. Time will tell.

    1. bazza Silver badge

      Rust was specifically design to interoperate with existing C code. It's pretty trivial to link to C libraries, etc. C++ is a different matter.

      Time will indeed tell. It's interesting that it's got this far in Linux (and MS are reputedly looking at it too for Windows), in the sense that so far it's difficult to see a solid reason not to try.

    2. Charlie Clark Silver badge

      I think the kernel developers have identified certain areas where they think an implementation in Rust will be of benefit.

    3. Anonymous Coward
      Anonymous Coward

      C++ was(is?) easier to code for memory leaks because it has destructors, making the pairing of constructors and destructors less work and easier to see.

  7. Claptrap314 Silver badge

    Remember when Scala was going to solve this problem for higher level languages?

    I'm not holding my breath.

    And my complaint against C for something like an OS kernel is that you loose direct access to the flags register. Integer overflow error almost disappear when you have it.

    Think about that.

    Bounds-checking array accesses become MUCH cheaper.

    Think about that.

    Imagine (if you're old enough) writing C with that capability in place. NOW, explain how excited you are about Rust.

    Again, I'm not saying that Rust is no good for the kernel. However, it strikes me that people seem to want to jump to entirely new tools when really, some minor tweaks to existing tools can get them much of what they need.

    1. bazza Silver badge

      Re: Remember when Scala was going to solve this problem for higher level languages?

      Sure. But I think it's fair to say that there's far, far more to Rust than just guarding against buffer overflows.

  8. grumpy-old-person

    Why does modern hardware not facilitate "safe" software?

    Many decades ago there were many attempts to design hardware that would not allow many of the problems that are still with us - even though hardware speed should support things that were simply too slow when implemented way back.

    The book "Advances in Computer Architecture" by Glenford Myers describes a number of the projects.

    The section detailing the IBM SWARD machine is particularly interesting, and IIRC the principles were used in the IBM System38.

    Perhaps it's time (past time?) to have hardware that will prevent many errors (eg an uninitialised variable!) instead of coming up with more languages which will eventually be found to have their own issues.

    1. Charlie Clark Silver badge

      Re: Why does modern hardware not facilitate "safe" software?

      Because the need for speed drives the market. There are several academic designs for such CPUs but nothing you can buy.

      1. grumpy-old-person

        Re: Why does modern hardware not facilitate "safe" software?

        The need for speed!

        The recent problems with processors has reduced the speed to avoid the security issues - and it has been accepted as necessary.

        In the book "The Elements of Programming Style" there is a comment about turning off array bounds checking - so that one can get the wrong results as fast as possible.

        Principle was true all those years ago and still true today.

      2. Binraider Silver badge

        Re: Why does modern hardware not facilitate "safe" software?

        Could you deploy such an academic design on an FPGA? (If you can get an FPGA?)

        1. jake Silver badge

          Re: Why does modern hardware not facilitate "safe" software?

          Yes.

          Have fun :-)

    2. Binraider Silver badge

      Re: Why does modern hardware not facilitate "safe" software?

      Two processors, one system. High-sec core for high-importance jobs, and then a performance core for less important ones.

      Assign tasks at OS level for relevant authority; and also some sort of segregated memory management across the two to prevent side-channelling into the high sec core?

      Doesn't seem too unreasonable an idea to me.

  9. Robert Grant Silver badge

    It's worth differentiating between the relative import of the Titanic contribution of Linus Torvalds to humanity, and the ephemeral rules of politeness he has transgressed.

  10. Elledan
    Trollface

    Yawn

    Wake me up when the Linux kernel merges Ada code into it.

    Until then I'll be moving more systems over to BSDs.

  11. Mike_in_the_house

    This is Linus trying to be a nice guy, he is not! :)

    Yeah,It will eventually come, but just in case, let me apologize in advance if I decide not to in the short term…

    Linus might have a rant or two, but he is not dumb, he needs a very strong talent pool, which is what drives language adoption. Furthermore, Rust is a heavily dependent upstream language, it will limit security from this nature, not knowing what bit of code, if any has been modded, like we have seen in similar languages where the exposure came from the library…. how long will it take to some to look at the “safe code” see how it evaluates it’s use and find new ways attack the code. It’s a never ending story. Now consider this, New tool, few resources to review the code, and an upstream process… and you are in for a fiasco, nothing to do with RUST, it could be any language, just that in this case it is RUST.

    Also, all this talk of performance, it’s really hard to measure performance from one cade base to another, unless you are keeping likes to likes, in most cases, RUST is doing two level optimization, at he source ( writing the code) and at the compiler level…. I find it troubling unless you take a set of factors in place, and then leverage the LLVM to compile the code, else it’s no different than performance refactoring.

    Consider this, RUST is a new language, it’s a cool language, so were many language of the C era that never really took off, if that happens, Linux could be in a thought situation, not finding maintainers for the RUST code base. More risks that benefits from what I can tell, heck, just work on LLVM static code validation instead of refactoring, might well be worth the trouble to find any flaws on what’s there now than having to rewrite it all.

    Talent pool is way too small to consider it viable at the moment… but I’m just a dumb ass not in comparison to Linus…

    1. elaar

      Re: This is Linus trying to be a nice guy, he is not! :)

      Rust isn't a cool language. It has a cool pre/compiler, and a lot of great ideas, but some of the semantics/syntax ideas are unnecessarily complicated and bewildering.

      My opinion is they decided to tackle all of the most complicated parts of C by making them even more abstruse in Rust.

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

Biting the hand that feeds IT © 1998–2022