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 …

[Henry Wertz 1]

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.

[bazza]

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.

[captain veg]

A pedant comments...

> hoops and pedanticness

Er, pedantry.

-A.

[martinusher]

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.

[elsergiovolador]

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).

[Gene Cash]

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.

[elsergiovolador]

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).

[jake]

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.

[Charlie Clark]

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! ;-)

[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.

[elsergiovolador]

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?

[cyberdemon]

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.

[Electronics'R'Us]

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.

[bazza]

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)!

[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.

[bazza]

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.

[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.

[bazza]

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).

[An_Old_Dog]

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.

[Philip Stott]

Re: Error Types

<PEDANTRY>

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

</PEDANTRY>

[Michael Wojcik]

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).

[cyberdemon]

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.

[jake]

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

[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?

[bazza]

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.

[martinusher]

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.)

[bazza]

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.

[Anonymous Coward]

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.

[nijam]

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!"

[John Smith 19]

because IBM had put its very best developers on the job, and that being IBM from a long time ago,

Govt system + "best developers" --> Federal systems divisio

The people who wrote the software for the ground control for Gemini, Apollo and Shuttle (think they did Mercury as well)

The people who showed Carnigie Mellon that a CMM5 company was even possible and how to do so. It takes 2 mins to describe, but massive commitment (by management particularly) to achieve.

[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?

[Michael Wojcik]

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.

[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.

[bombastic bob]

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.

[jake]

Re: Seriously, are programmers that bad?

Exactly, Bob. We're perfect.

::ahem::

[John Smith 19]

can't we try and improve the tools too?

And people should include the language itself on their list of "tools"

The implication of "Turing complete" is that any "language" (and that includes a shedload of stuff most people would not recognize as a language in the first place) can do any job if a)It runs fast enough on the hardware it has to run on b)You can figure out how to solve the problem well enough in your language of choice to meet a)

Yes writing an OS in FORTRAN sounds like a stunningly bad idea, as does the flight control system for a jet fighter in VB.

But if the development environment is good enough (that includes solid compliers) both are possible

What would be really good are language neutral tools to stop the obviously stupid stuff from happening in the first place. Of course "obviously stupid" has different meanings in different languages. Unfortunately the temptation is to make the tool programmable and then it snowballs eventually into (basically) a compiler-compiler

[Charlie Clark]

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.

[werdsmith]

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.

[bazza]

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!

[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

[jake]

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.

[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.

[jake]

"Real Soon Now."

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

[wolfetone]

Re: "Real Soon Now."

Definitely maybe.

[42656e4d203239]

Re: "Real Soon Now."

Now, in a minute....

[GuldenNL]

Re: "Real Soon Now."

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

[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!

[Munchausen's proxy]

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).

[karlkarl]

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.

[bazza]

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.

[Charlie Clark]

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

[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.

[Claptrap314]

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.

[bazza]

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.

[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.

[Charlie Clark]

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.

[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.

[Anonymous Coward]

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?)

[jake]

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

Yes.

Have fun :-)

[Anonymous Coward]

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.

[Robert Grant]

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.

[Elledan]

Yawn

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

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

[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…

[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.

[John Smith 19]

Enough like C that adoption should feel painless but the 3 $1Bn questions are....

1) How does it achieve that safety?

2) How does it achieve speed?

3) How does it handle problems that cannot use full safety?

It sounds like they enhance the syntax to catch a lot more of the errors than C does (same approach as Pascal, but on a much broader scale) at compile time. Which is the way you'd need to go to have a shot at fast execution.

Where it gets murky is how that speed (I'm pressuming code executes at rates comparable to compiled C on the same platforms)is ultimately achieved. If the answer is "Turn off all the runtime safety checking" then it's a waste of time. I'm hoping that's not the case. I'm betting the process of writing that code is better than in C and makes the code more, not less, optimisable while retaining the safety.

And now the worst of all. Those very nasty, low level, bit twiddly situations. C's initial design goal was to implement Unix, on machines down to something with 64KB of ram and no MMU (a PDP11). If you think of it (more or less) as structured-assembler-with-structured-data-type-support your'e not far wrong.

How (can?) it handle these. If the answer is "Call a function written in assembler" that basically the same as disabling all runtime checks for speed.

Having spent a long time studying software failures I'm convnced of a (very) few things.

1) A good development environment makes development in any language possible provided the processor(s) is/are up to the job of running the code in the first place.

2) Good environments and languages consider what's outside their bubble, and how to communicate with it, preferably as libraries not as built in commands (which card reader unit do you want to mount? in 2022? :-) )

3) S**t happens at interfaces. All interfaces and thin interfaces (IE only passing the used parameters of a 40 parameter structure, not the whole structure) but this is an examplee of writing-stuff-twice (like import/export lists and C templates), which some languages mandate but don't offer any support for.

4) Writing big software (or using a highly georgraphically and temporially dispersed team) is not like one person writing a utility on their own.

5) There are 2 choicse to scale up. Have a language that has features that support big systems, or run the code through a bunch of tools after you've written it. The tools approach is C

6) How you provide that big systems support unobtrusively in a language is likely to have a big influence on developer acceptance, unless you have a big customer (DoD in the case of Ada) to wave a big stick at you. Otherwise its formal requirements IE import/export lists, (especially without tool support) are a massive PITA most people will just avoid.

7) There is the language, its implementation and its environment. The latter two can make up for the deficies of the first, but a well defined language raises the whole game to begin with.

8) There are several situations where you really need to backward chain your logic. IE start with the parameters you're going to pass. What types are they? What range limits should they have? In terms of C, write the templates first then write the code (there's got to be a tool that can do that for you in 2022)

9) I realized that it's the combination of unrestricted placement of both the label and the GOTO that will turn code into spaghetti. There are GOTO use cases (like writing FSM's produced by a code generator). Yes the proverbial "competent" developer can design them out, but after how many person-hours to do so? (After studying the Bliss compiler, a fascinating DEC system language to produce executables with very tight runtime resource constraints and no GOTOs I though "So how about only jumps from inside flow control structures to a label outside any structure? Tight enough? Too loose?" ).

C (the language) was developed in an enviroment where full screen editors were not standard and AFAIK none of the developers were touch typists. Those 2 trival observations explain quite a lot about its structure. Basically anything to avoid a few keystrokes. Anyone still develop like that?

The Linux kernel is unlike the usual embedded scenario as the devs have no control over what hardware it will run on, or even what architecture it will have. MIPS, SPARC, ARM are quite different to Intel (at least on the outside :-) ).

I'm intrigued.