Linux luminaries discuss efforts to bring Rust to the kernel Both Linus Torvalds' Open Source Summit keynote and Jonathan Corbet's "Kernel Report" discussed efforts to allow Rust modules in Linux. The next version of the kernel will be 6.0, but as ever, the change of major version number doesn't denote any major technical changes. Torvalds acknowledged that it might have been desirable …
So, it appears that a LOT of effort is needed to get Rust into the LInux kernel. A _LOT_.
Question: what is the 'bang for the buck' expected at the end of the process?
In comparison, Microsoft has spent a GREAT DEAL of effort re-re-redesigning the user interface. Let's suppose they had LEFT IT as it was for Winxows 7, but then spent a BUNCH of time making improvements needed for touch screens without breaking the keyboard+mouse NOR the hotkeys NOR the UI that people were now very familiar with. They COULD have made the kernel SO robust that patches would no longer have to be deployed weekly. OK maybe not but still.
NOW we have a significant amount of Linux kernel dev time dedicated to folding RUST into it, and THEN having to MAINTAIN it.
In My Bombastic Opinion, there may be BETTER ways to spend this time, maybe more code reviews and performance tweeks? And maybe we could use some really good open source video drivers for various adapters (for XOrg, naturally, why waste time on Wayland).
I once again cite Arthur C. Clarke's "Superiority"
Question: what is the 'bang for the buck' expected at the end of the process?
Three possibilities spring to mind:
1) it turns out that rusty code is no easier to write and/or slower to run. Over time, take-up is minimal and eventually the support is dropped. As a result, we now have a better idea of the properties that a language must have if you want to write a kernel.
2) The opposite. Over time, more and more of the kernel gets rusty and eventually the kernel is just some assembly language routines propping up a lot of rust. As a result, well, same as before except it is C that no-one ever uses again.
3) Something in between, with each language having a well-defined role for different kinds of kernel component. As a result, no-one ever tries to write a kernel without multi-lingual support designed in from the start.
Whatever the outcome, I'm pretty sure we're going to learn something fairly important about how to write an OS. I'm also fairly sure that lesson will carry over to a few other large software projects.
Possibility number the fourth:
The next language du jour will displace rust in the fanboi's fancy before rust works properly with GCC, making this yet another footnote in the annals of computing.
No, mainline kernel development is not moving to llvm/clang any time soon.
I think the bang for the buck is kernel work that would be lost without rust support. It is yet to be seen if the cost of supporting rust will be worth it, but I am guessing it will. Linux isn't a single entity managed project, so you have to be flexible about working with others.
I mostly don't see how there's much argument about it. I'm not writing any kernel contributions, so I just watch from the outside. Clearly they think it is interesting... I'm curious about the possibilities. Linus tends to be conservative and sometimes counterintuitive on some restrictions, so I am mostly depending on him when he allows something vs denies it.
That may be so, but a homogeneous codebase (i.e C everywhere) is still easier in this regard. No bindings needed at all.
C++ being a 99% "superset" of C kind of achieves this but there are a few other issues.
That said, much of the AMDGPU drivers is C++ and it seems to integrate OK with the rest of the kernel.
C interop with C++ is better than anything else ever could be, as it's explicitly defined to be a superset of C. The bindings are no-op, and the minimal binding is quite literally six lines at most - sometimes no lines of code at all.
Rust may or may not be a good language, and does indeed have excellent bindings. But don't make silly superlative claims.
>Question: what is the 'bang for the buck' expected at the end of the process?
Survival?
I think that it's worth unpacking the full consequences of the suggestion from Mark Morgan Lloyd that Rust is a sibling of Algol, rather than a derivative.
What appears to be going on is that Rust is really challenging everyone's fundamental assumptions of what a programming language is. It's a bit like discovering a whole new mode of transport. Suppose we lived in a world without birds, bugs, etc; say nothing in the natural world was capable of flight, and the concept of flight was totally unknown to us. And then, someone comes along with a "build yourself an aeroplane kit". We'd all be looking at our shipyards, car factories and slow railway lines, saying "but we can already travel from A to B perfectly well with all this lot", whilst realising that buying a kit and actually building oneself an aeroplane and using it is going to make the world a very different place. All of the passenger train companies know that someone somewhere is going to start an airline...
That's basically what's going on. We've already written a ton of software that works perfectly well, but it's taken a lot of effort, it still occassionally gives us trouble, and now we know that we'd probably have done it all very differently had we'd had Rust back in the 1960s. If one major OS does start migrating it's going to start accruing the benefits of having done so, and those that don't migrate won't. This will eventually determine which OSes survive and which die off. To switch back to the transport analogy, it's by no means guaranteed that one of the train companies will start an airline, but they all know what will eventually happen if someone, somewhere does.
The software industry has been here before. Once upon a time, programmers wrote in assembler (or even in opcodes). Then, along comes the idea of a compiler. There you go then; we'd never today say that we should have stuck with assembler and expanded assembler code bases indefinitely, instead of picking up a compiled language such as C...
> 'There are possibly some well-designed and written parts which have not suffered a memory safety issue in many years. It's insulting to present this as an improvement over what was achieved by those doing all this hard work.'
This is just silly. Yes, most of the kernel has been painstakingly scrubbed of memory safety issues, but there have been tons of them and there are many more lurking. I used to write in assembly language - I don't any more (once a year or so) because I can use C#, Rust, or Python and get literally 100x times as much work done in the same amount of time without worrying if my JMPing is idempotent. It's not an 'insult' to my past self to admit that assembly language programming is a touchy, dangerous, pain in the ass. Good for me for having been able to do that, but thankfully it's rarely necessary any more.
Similarly, it will be great to know that future kernel drivers, and maybe more significant parts, written by other people who are not as awesome as me (tongue -> cheek) can be guaranteed free of memory safety issues. This is indeed a giant improvement. So kudos to the guys who did it in C (including me!) while keeping memory safe, but they're not going to be 'insulted' by making it possible to go from banging two rocks together to hammers.
Methinks you miss the point. The fact that the kernel has, as you say, been painstakingly scrubbed of memory safety issues, is indeed the result of necessary "hard work". That hard work included (and continues to include) extreme care, planning, and discipline to prevent propagating those same errors in future work. Now comes the next panacea-du-jour, "memory-safe" languages (air-quotes intentional), because the next generation of "coders" can't be arsed to develop the discipline, do the planning, and execute the extreme care because, well the "compiler will do all that for me". Except it won't in all cases. So the ongoing development will be dumbed-down with the "practitioners" counting on an imperfect tool to be perfect. We all know how that will end....1
Perhaps "insult" was too strong a term. But the impending deterioration of developer skills deserves some form of epithet to properly label it. My suggestion: s/insult/pathetic/
1cf. garbage collection as the panacea for object and heap management; and of course, the Tesla "autopilot".
Things is when you write kernel C you don't have libc, it the syntax but not the language you are used to, so you have to write a lot of code you would otherwise use a library for yourself. Having a lot of help from the compiler is necessary.
Rust is like -Wall on steroids, it's not hubris, it's the exact opposite: it's acknowledging that you are not invincible and you need help from the compiler.
And it's not like the "scrubbing" of the kernel has been totally successful and fully completed anyway. Just scanning down today's edition of the CVE list for Linux reveals a load of memory-related flaws (use after free, double free, etc). Sure, those may have been or are well on the way to being fixed, but they made it out into the wild and were in use like that for a time.
There may well be parts of the Linux code base that are very well reviewed, but it's clear that it's not all like that all the way through.
It’s silly to suggest it’ll dump down development, it’s still kernel work and not for everyone. Also an interesting thing about Rust is that although it keeps an eye on references to memory and how they’re used you still have to understand how that works to write code that compiles. It uses an affine type system, that you have to understand rather than a black box garbage collector. That’s why Rust have a steeper learning curve than other languages but you end up writing better code - even if going back to other languages afterwards.
This post has been deleted by its author
use of C-pound (aka C#), as opposed to assembly language, gets you a downvote from me.
Although your point about memory safety is valid, it can be overcome in both C and assembly language through proper code review, diligence, and standardization. And Linus acting like "Linus 1.0" on occasion (heh)
And you STILL have to ask how much performance cost would result from using Rust for "memory safety" to protect from lazy/incompetent coders?
It depends.
When the checks are all either compile-time or the ones you'd be manually putting in if the toolchain didn't do it for you, then the runtime cost is zero while the development savings are useful.
The trouble is when it adds runtime checks over and above the necessary. Which is the same problem people have with C++ exceptions, and why a lot of developers turn those off.
This much-hyped memory safety is a bit of a red herring when it comes to compiling Rust code. For sure, the language doesn't allow many risky C type operations. But ultimately it's got to be compiled into machine code, and both CLang and GCC break down source code written in any supported language into lower level representations before the machine code is generated. And then there's a subsequent optimisation phase if you want it. So whilst it might offer less risky operations at the source level, there's no way a language can actually guarantee memory safety after compilation.
Dont understand? Really? Can you guarantee that a Rust front end for the GCC would always generate memory-safe GIMPLE representations for every possible Rust expression? That's not a function of the Rust language (which I find likeable, with many good ideas in its design), but of the compiler implementation, so my point that memory safety can't be guaranteed by language design alone is pretty straightforward when talking about the GCC, which generates all its machine language from GIMPLE, not direct from source code.
Come on, of course you get _SANE_ memory safety.
Otherwise, insanely: Stray radiation do-hickies from space? Strange gremlin voltages across motherboards? Resonating frequencies from adjacent industrial buildings? Insectoid induced electrical shorts? So many uncommon things, so little time.
Rust does not guarantee memory safety, it helps you write memory safe code. It gives you enough rope to hang yourself should you want to.
It's very easy to write safe rust, and for it to be obvious that it it is safe. Independent of the compiler or target arch.
It's safe even when multi threaded. That's pretty clever it's almost impossible write multithreaded c that is _obviously_ safe. Multithreaded rust is as easy as single threaded rust because single ownership works across threads.
Rust _is_ pretty cool. It's not just the memory safety, also the ability to write test code along side production code and documentation code that you know compiles and is correct too. It's number system is strangely convenient too.
I find it's origins to be remarkable. Who'd have thought that the ghastliness and memory-bloat of old-fashioned FireFox would spawn a language as remarkable as this?
Incidentally, you can write multi-threaded C that is obviously safe, it all depends on how one goes about it. The strength of concepts like Actor model or Communicating Sequential Processes is that threads are only ever dealing with their own private copy of data, never sharing access to it (this gets rid of the hazards of C and shared memory, semaphores, etc). If you do all your C multithread code using ZeroMQ for passing messages between threads, you're getting very close to "obviously safe" code.
Actor model brings in its own problems, which CSP does not automaticallty eliminate. But with CSP you get the benefit that Actor model's potential problems become certainties in CSP (meaning you can easily find them). But also CSP comes with an algebra, a process calculii, which allows one to prove "correctness" (in the sense of not deadlocking, livelocking, etc).
For entertainment value, have a look at XC - stripped down C (no pointers, the horror!) coupled with a message passing system derived from Occam. The target Xcore CPUs are essentially the spiritual heirs of the Transputer, after all...
I stopped seriously evaluating it, and the Xcore, when it started to become apparent that XMOS were no longer interested in the general purpose microcontroller market, but still, it was fun.
When you say "it is easy to write safe rust", you are assuming the compiler doesn't have bugs. The compiler having bugs is exactly the problem the post your are reply to was trying to raise.
Personally, the compiler having bugs doesn't worry me that much; it's an issue, but much less of an issue than programmers make mistakes _all_ the time.
Of course not, but Rust has never given that guarantee.
What it does offer is that in a subset of Rust (the safe subset) if certain classes of memory issues do occur in a piece of code, then they are due to a bug in Rust, not a bug in the code. In C, you can introduce many forms of memory error in trivial code which, in practice, means you can introduce it in any code, without it being considered a bug in C.
In terms of the underlying optimisation and compilation, that is just an implementation detail. It's changes where the bug might need to be fixed, not that it is a bug. In practice, if this kind of issue occurs at the clang/gcc level, then it's likely to affect quite a few more languages than Rust.
Is that a big thing? Maybe, maybe not. What it does do is allow a separation of concerns. Some aspects of memory safety become the job of the Rust developers rather than the end developer. It's similar to the other things you described -- the end programmer does not has to worry about loop inlining or any of the many optimisations that are being performed at clang level. It is one trick that we don't have to use any more because it's done somewhere else.
PPC is alive, albeit somewhat on life support. IBM has a vested interest in maintaining Linux support for the arch amongst it’s niche applications.
S390 or other mainframes it’s a similar argument. If selling Z system mainframes needs Linux then it will get support. Having worked on S390 hardware in the somewhat distant past I know of no real reasons that rust could not be powered to it apart from time/effort/cost.
I've always found it strange that the kernel and C++ didn't move towards better support for each other. There are operations where C++ cuts down on the code complexity so much that time can be spent on better algorithms. Multithreading with error handling comes to mind as something I don't even want to try in C. OOP can be simulated in C and Rust but it's more manual coding to maintain. (Yes, I realize that C++ objects can't pass between kernel and user space because of the vtable)
biggest problems with C++ in the kernel has to do with object construction and destruction, and unwinding following an exception. If you compile with no static object constructors or destructors and eliminate everything related to exception handling, you could use the remaining C++ features pretty well.
That being said, I think similar changes to Rust are required. Some things just do NOT (and CAN not) belong in a kernel!
A lot of kernel-mode drivers are already written in C++.
As I understand it, Tlthis work is basically to allow Rust to be used for kernel-mode drivers too.
Which is a good thing, drivers are hard. If the toolchain can help (be that memory safety guarantees, RAII etc) this is good.
However, it's still going to be a subset of those languages that can be used.
I think an amazing thing is not that Rust is going to be let in after 31 years, but that Linux has been around for 31 years. I can remember when we didn't have Linux. And it sucked. Let's keep going, shall we?
We don't HAVE to write anything in Rust, but it's a valid experiment. If it goes to shit, then it goes to shit. If it doesn't, we have something new.
In my mind it would probably be better if Rust resources were expended in developing the Redox OS, which was build from the ground up with Rust as it's goal instead of trying to shoehorn rust into the Linux kernel, making it slightly more complex (dealing with multiple languages).
In many ways migrating existing code from C to Rust, just seems redundant. Where is the innovation. Instead of developers who are experts in Rust, you will end up with developers who are mediocre at C and probably slightly better at Rust than mediocre.
I don't think porting code from C to Rust is going to happen in that many cases. At the moment, it is giving the option for new drivers to be written in Rust. Whether, Linux ends up moving toward Rust more generally remains to be seen. But I doubt that much of it will be re-written -- it's just too big a task.
Going back and reading the article, when the text you quoted is put back into its context, there is nothing in it that implies there will be lots of time wasted on re-implementing from C to Rust.
Especially if you bother to go and look at the referenced LWN article, which talks about the two currently extant drivers, starting with "The idea of being able to write kernel code in the Rust language has a certain appeal, but it is hard to judge how well that would actually work in the absence of examples to look at."
So there is now *one* commonly used driver being rewritten in Rust plus one new driver for a network protocol. Now anyone else who is interested in coding Rust drivers can use the NVMe driver as an example, comparing the two versions to see what the different approaches entail. And everyone else can have a go at running the new driver to see for themselves how the whole idea is panning out: for which NVMe is a pretty good choice, as it is commonly available and commonly used hardware, so it will be pretty clear if it is working or not.
If you are of the opinion that providing examples and experimenting to see if Rust can do what some hope is a waste of time then...
Of course, if the experiment shows that rewriting the NVMe driver results in clearly obvious advantages over the C version (probably won't run 10x faster, but if it did...) then, yes, there would probably follow a frenzy of recoding.
So you would be happy to allow Rust to decide which architecture future Linux device drivers will be allowed to work on ?
https://doc.rust-lang.org/nightly/rustc/platform-support.html
Tier 1 "guaranteed to work" - summary: mostly aarch64, i686, x86_64
Tier 2 "guaranteed to build"
Tier 3 "Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work. Official builds are not available."
I'm not saying that Rust is a really bad idea, just that it currently does not have the support in place today (it is only 12 years old) for the same level of architectures that are today fully supported by C compilers.
> Of course, if the experiment shows that rewriting the NVMe driver results in clearly obvious advantages over the C version (probably won't run 10x faster, but if it did...) then, yes, there would probably follow a frenzy of recoding.
I've programmed in HEX (one, nibble at a time) on some really old architectures, used more assembly languages that I can remember these days, and my comfort zone has been C for at least 40 years (about 10 years after C was created), for one very simple reason it is so close to assembly in performance and is so easy to read and fully understand other peoples code (compared to assembly languages, which vary wildly across architectures). That is some background to understand why I say that you that you will NEVER see 10x the performance from Rust in a kernel space, compared to C programmed by a well seasoned computer guru.
Ok, we can move onto this second topic
> just that it currently does not have the support in place today
The key word here being "currently".
Remember, at the moment this is all in the "let us find out if is it going to be worth doing?" stage; none of the existing C code is actually being replaced yet, in any production kernels.
When (if!) the Rust work demonstrates it actually has worth to the kernel there will be more delay as the new code is thrashed and made stable and production-ready even for the architectures already supported by Rust.
In the time to get to that stage, the Rust compilers have the chance to improve architectur support: as well as the GCC version, there is now some *reason* for other backends to be built, as they would now be used in a non-trivial project.
And at the risk of seeming petty, with regards to your convincing paragraph that Rust could never be 10x faster than C (as it was a rather excessive reaction to what was not only an obvious parenthetical hyperbole but also indicated that I don't expect such a speed up to occur):
Unless one language is vastly different in its manner of execution (e.g. purely interpretive BASIC versus Pascal compiled to machine code), which is clearly not the case when comparing C and Rust, as you know the only time you'd ever see an order of magnitude improvement would be with a change in algorithm and/or data structure in use. One thing that switching to a different language, especially one with any "oddball" behaviour compared to the previous choice, can do is to prompt a re-examination of the algorithms and data structures.
Of course, any such changes are likely to be portable back into the C variant and built for all the architectures, in which case clearly the whole experiment was a failure as there wouldn't be any Rust running in the kernel. Hmm.
Please note, BTW, that I've not said one way or the other whether I personally want there to be any Rust in the Linux kernel, but if they want to try then have it. I'll trust Linus to reject the results if they aren't useful after all (and that includes because the compiler support isn't up to scratch), otherwise, yay, we all win.
Rust : Started in 2010
C++: Started in 1985
C: Started in 1970
Can't argue Rust has the safety credentials to do that kind of work but just 12 years against almost 40 and 52 years for the main O/S level langs? I don't code in C and C++, I actually prefer Rust and Golang but even I wouldn't trust a language that's barely "out of nappies"!
Somebody was writing C code in the 70's, though, certainly the 80's, and that code is still running and for some reason its revered as superior (by some) even though we know there are (a few) long lived bugs.
Yes, things were harder back then, is that...better?
My father worked in a bank as a teller back then and I shit you not they used abacuses to count coin deposits. Now they weigh bags of coins. Does that make tellers worse their jobs? No it does not.
Some memory safety, sure. Big difference is you don't see 'array out of bounds', or 'null pointer exception' until runtime which means you have to test every execution path and fix stuff... big ask for most applications, it seems.
So rust means you get a big error earlier in the life cycle, its a lot harder to get those same mistakes surfacing in production.
Its not perfect and you can get memory leaks and logic errors crop up, but its better than what came before. I sincerely hope something better will follow it in turn.
False sense of security would only apply to people who use it without thinking - and they'll write shit code whatever language they use so I'd rather they used rust as it does have more safety nets and its less likely my credit card details will leak due to a breach at a company I have no choice but to interact with
I've done some programming in Rust. I would say really the biggest benefit is in fact the memory and thread safety guarantees. Quite simply, if you do something in a way that is not memory or thread-safe, in Rust you will usually get a compiler error. There are certainly systems in Linux that have been heavily audited with no memory errors and such found for years, you probably will not get any benefits from rewriting in Rust. But I could see (as the new nvme driver and M1/M2 Mac GPU driver are doing) writing a driver in Rust, once you get it to compile you are FAR less likely to have memory-handling or thread-related snafus than if you just try to do your best and look at the code for problems by hand.
Rust obviously uses braces which lulls the incautious into a sense of security. However, its underlying assignment model is sufficiently novel that I'm inclined to call it a sibling of ALGOL rather than a derivative… and just about every general-purpose language (except Smalltalk, LISP, Forth and APL) is a derivative of ALGOL, so you see how big it is.
What the ever-lovin' hell is that supposed to mean? Is his claim that Rust departs from the ALGOL model? In terms of memory ownership, sure; but then OO languages depart from the ALGOL model in terms of functional dispatch, for example, which seems similarly significant. Managed languages depart from ALGOL (at least in practice) in terms of object access. Pretty much everything gave up on ALGOL 60's call-by-name.
I like Rust, and since software security is one of my fields, I think strict object ownership is a big step forward for practical software development. (And I say that as someone who's spent years writing C with an express goal of avoiding common memory-related issues.) But I don't think strict object ownership is revolutionary; it's a sensible evolution of procedural programming languages.
To the list of exceptions add Fortran and COBOL, since they both predate ALGOL. ML-family languages such as Haskell, OCaml, and F#. And all varieties of assembly language. Prolog, SQL, most scripting languages, 4GLs ... (arguably those aren't "general purpose", I suppose).
So as someone who has written and validated / verified a bunch of commercial compilers over the decade I did a quick look.
So where is the full formal grammar? Not done yet.
How about a primitive by primitive description of expected behavior / edge conditions? I cant find any.
I looked at the various primitives for ease of compiler generation / run-time overhead. I can see several which could have very unexpected edge conditions due to compiler specific implementations of non obvious special conditions.
Greatest benefit is supposed to be memory safety yet provides multiple paths to subvert memory safety. And so on and so on.
Then there is whole problem of language specification to facilitate compiler validation and reduce opportunities for compiler errors. I cannot see any.
This is very basic stuff.
Get back to us when you have a comprehension and exhaustive language specification of the language that reaches the standard of even the first editions "Java Language Specification" by Gosling, Joy and Steele or "Common LISP. The Language" by Steele. Both of which I have used to write compilers from. Both comprehensive and very well written but still, you'd be surprised of just how many tricky places there still were in implementing a full compliant and validatable compiler.
Until then Rust is Just Another Stupid Bloody Language created by people who really dont know what they are doing. There have been many dozens of those over the years. Many many dozens. Only created because someone thought "would nt it be cool to create a new language that implemented some personal pet features" . No other reason.
Who cares. We dont need any more general purpose languages. That problem was solved decades ago. New domain specific and task specific languages will always be needed. Because that will always be a moving target with better ways of solving new (and old) problems will always come about.
This really rather reads like you are saying "they didn't do it right, because they did not do it the same as they did another language". You might be right, but the process of language design might be expected to evolve even as language design does.
The question of the spec comes up now and again. It's important to some, less to others. In the days of Common Lisp and, to a less extent, Java then a spec was important because it allowed alternative implementations, and avoided a control by a single vendor. Rust does not have this, however, there is an implementation, which is free to use, which will continue to be free to use, which is backed by a foundation, which will is dedicated to this end. So, a single implementation is not so much of an issue, nor is a "main" implementation with others tracking that. It works for python and many other languages.
A spec is required for some things, though. And so people who care about that are writing one. It will track behind the language and not lead it. Again, different from CL and C. But it means that the language can evolve and new things can be tried extensively before they become part of the spec.
You say that you have found several paths to subvert memory safety. That's fine. Rust is trying to provide a memory safe subset of the language, with minimized undefined behaviour. If you can find a way to subvert memory safety that is not marked as unsafe, then you have found a bug. If it is marked as unsafe, then the misunderstanding is yours.
Rust's stated aims are fairly clear and rather far from "implementing some personal pet features". You may not value these aims; you may not think it will achieve them, fair enough, but claiming there is not justification suggests that your "quick look" may have been too quick.
So you have never actually had to write a commercial compiler then. For people who need to write software that is used in the real world. For shipping software.
As I said, a complete bunch of amateurs. A toy language for toy projects.
There are no novel, original or unique features in Rust. Every single idea has been thought of before. Decades ago. Many times. Obviously no one involved has much familiarity with the many languages that have come and gone over the decades. And why. Or could be arsed to spend even a few hours going through good reference books like the 4 vols of "Handbook of Programing Languages" by Salus that would show just how unoriginal the ideas actually are.
When you have written working / shipped code in many languages, functional, procedural, declarative etc, and written a few compilers from the standards docs, it only take a "quick look" to work out the fine detail of any new language. I start by reading the formal grammar and go from there. Because I have seen it all before and I look over the new language from a compiler writers point of view. Because that will quickly tell me if the authors have a clue what they are doing and where the likely points of failure are. If the language and its compilers will be dependable.
There is not one single compelling feature in Rust for use as a systems programming language or for writing large ISV end user applications. Both of which I have done for decades. In fact the catastrophic decline of Firefox of which the rewrite in Rust was the biggest contributor just reinforces this view.
I'd guess your daily work does not involve using a wide range of various language to create stable shippable commercial software. My current project involves very large codebase using C/C++ with embedded JS and TCL, dealing with JVM/CIL and LLVM opcodes, and also using tools written in Python, TXL, and a bunch of ANTLR little languages. Previous project involved C/C++/Java/ObjC/Swift/Dart with tools written in Python. Starting to see the trend?
As I said Rust is Yet Another Stupid Language. Literally dozens have come and gone over the decades. There is zero reason to believe Rust will be any different. Buy, hey, playing with toys is fun. For those who dont have a job to do.
"There are no novel, original or unique features in Rust"
No. I would, indeed, not expect them to use features which were completely novel, not in a language which is intended for end usage. The combination is novel, of course, although that's true for most languages.
"Because that will quickly tell me if the authors have a clue what they are doing and where the likely points of failure are."
Okay, that's good, but you haven't said anything about these really.
You are indeed correct, I don't write compilers or commercial software; I write software to support scientific research and that is my expertize. That makes me experimental by nature. But people are using it to ship software, in real environments and it is currently gaining traction. Of course, Rust might disappear. Or it might grow in size and usage. That's why you try things. Or, at least why I try things.
So I was correct. You dont have any relevant domain expertise.
All of the New Latest And Greatest Language That Will Solve Everything fail for the exactly the same reason. The features that are so important to the language designers are utterly irrelevant in the real word of end user software development. Which account for 99.99999% of all CPU cycles used by running software out there in the real world.
All successful languages succeed because the language designers had a real world problem to solve. And the features and implementation reflect that. All failed languages fail because the designers want to do some "neat things". A purely intellectual exercise.
Or in the case of Rust, because none of the senior people in Mozilla had the technical competence or wherewithal to do a refactor / re-archirect of the existing Firefox code base. I know - the codebase is getting messy and needs a big clean up - lets invent a new language.
As I said, amateur hour. Rust was such a huge success with Firefox that its market share fell from 25% to 3% and every single open tab in the browser now has a footprint of around 400Meg. Technical incompetence of the highest order.
And you want us to take this toy language seriously?
What's wrong with taking a collection of good ideas and putting them together?
Sure, formal documentation and standards need to happen for serious traction to happen; but do you remember C before C had an ANSI standard? Cross-platform coding used to be a hell of a lot more difficult than it is now.
Not so different to where Rust is today, is it?
I am a luddite on a lot of things (hell, the majority of programs I maintain are Fortran 77), but when it comes to writing ever-more complex software for ever-more complex systems, I am very happy about improvements to the toolchain to reduce risk.
Like yourself, I won't be using Rust "soon", but it's value is obvious and it won't take much more movement for it to become an important standard.
When watching the Linux Plumbers Conference i saw speakers walking around with face-masks, while the video was recorded on Sep 19 2022. The pandemic was already declared over 6 months ago. Also Linus Torvalds was reportedly very sick in 2021, and that was when the plan to move to Rust was hatched. All this together smells like a dark plot and sketchy coup over the destiny of the Linux Kernel. A new conference should be organized, which has a real attendance in an open setting, announced at least 6 months in advance and without imposed travel problems, like vaccination mandates. Microsoft promoted and has financial stakes in both Rust in the Linux kernel and the mRNA "vaccine" shots. This is not a proper way of affairs.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
