After clash over Rust in Linux, now Asahi lead quits distro, slams Linus' kernel leadership Hector Martin, project lead of Asahi Linux, resigned from that effort early Friday, Japan Standard Time, citing developer burnout, demanding users, and Linus Torvalds's handling of the integration of Rust code into the open source kernel. In a lengthy post, Martin explained his decision, partly blaming a lack of support from …
I don't have a dog in this fight, but you come across more like a strawman troll account version of a free software supporter- one intended to make them look bad and reinforce negative stereotypes.
In that context, your name looks almost like it's trying too hard.
I'm not sure if the possibility that you're for real isn't worse.
Thank you for your polite enquiry - it's the same handle on El-Reg as the past decade and change.
While my initial comment is firmly tongue in cheek, I'd suggest Troll is a little uncharitable.
I've engaged in good faith in this and other threads on various matters, in this I think Trusting Trust is a valid concern which nobody attempts to address. Stylistics aside put a name to your comment because "Ernest advice in that context, comes across as concern trolling. I'm not sure if the possibility that you're for real isn't worse".
@GNU SedGawk:
I see you've taken time out of your busy schedule to go back through a bunch of my recent posts and individually downvote them (or, if not you, someone else has, but I'm guessing it's you), which has given me a good chuckle, so thank you for that!
Cheers!
One day, maybe...
There is some progress, but I don't know how complete it currently is: https://reviews.freebsd.org/D38819
This post has been deleted by its author
It seems to be a common view amongst the Reg commentariat that Rust is snake oil and its proponents are pushy chancers. I get it - I have thirty years of experience in software development that have imbued me with a deep distrust of people offering silver bullets for our software engineering problems. I'm also aware that the term "silver bullet" accompanying a technology that over promises but under delivers predates my time as a professional programmer since I have books by the likes of Fred Brooks and Brad Cox that discuss it.
However, I feel Rust is seriously misrepresented on these forums and that the Rust for Linux project is particularly maligned for the wrong reasons. I've followed the evolution of both the language and the attempt to get it usable for Linux kernel development with interest, since as much as I love C (after all, it was the first programming language I properly learned) I'm painfully aware of its shortcomings.
The Rust for Linux folk knew they faced an uphill battle to get support for it in the kernel, but they probably assumed they could succeed on merit alone as long as they minimised the burden on those with little to no interest in it. What they probably didn't expect, and seems to be playing out, is how downright obstructive some subsystem maintainers would be (Hellwig and Ts'o in particular). The Rust folk have acknowledged they can't make demands on those maintainers to give concessions to their specific needs, and as a result have shouldered the burden of keeping Rust bindings separated while dealing with the fluid (some would say downright unstable) APIs of those subsystems.
Frankly, I'd prefer the Rust for Linux folk to just say "fuck it" and focus instead on something like the FreeBSD kernel, as at this point it feels much more like a meritocracy than the Linux kernel development world. The fact is though that Linux has far more momentum and therefore broader hardware support, so I can understand why it is the more attractive proposition for innovation.
I'm not a fan of C as there's a lot of things I don't like about it. However, I use it anyway because that's what a lot of existing software uses and I need to work with that.
I really liked Modula 2 and at one time wished that was the popular language instead of C. But it didn't become popular so I faced up to reality and learned and used C and forgot about Modula 2. I would rather have a project that has a future and is written in a language that lots of other people know than a project that just happened to be written in a language that I liked but was used by nobody.
I'm sure there are nice things about Rust as a language. However, it isn't the language that unix, Linux, and loads of associated software were written in, and the disadvantages of a multi-language project are significant and unduly burdensome on developers.
What I would prefer is a language which is derived from C (Rust is only vaguely C like) but has seldom used features removed and memory safety features added in. This would allow a sensible upgrade path without having to rewrite everything.
Rust in Linux is currently isolated to a particular subsystem which has limited contact with the rest of the kernal. However, sooner or later it will hit a wall in terms of adoption in existing projects because expanding use of it will require rewriting loads of existing code that was created, tested, and proven in use over several decades. This is a recipe for failure.
I got over being a programming language fan years ago, having learned multiple different languages that came and went. I like writing software that accomplishes a goal, and the language itself is just a tool to get the job done. In my opinion Rust may be fine as an abstract language, but it's the wrong tool for solving the problems that Linux has. I don't think the right tool exists yet, but it won't surprise me if the right tool is created within the next few years now that the problems with using Rust in existing projects have become more apparent.
Thanks for the thoughtful response rather than just a down vote. I should have also mentioned the Redox OS project, a ground up implementation of an operating system in Rust that's lead by a guy at System 76. Maybe it's the best place to focus Rust development for a potentially more memory safe implementation of an operating system kernel as that project has made impressive progress in a short time.
It seems to me, as a total outsider, that the idea of grafting a second language into an already working but heinously complicated and elderly OS, is really a fools errand.
It is like infill housing in existing cities: it turns out 3x more expensive, 5x slower, only gives half the housing that starting from scratch would have.
A clean sheet Rust OS, can with time simply end up better than Linux, and new things will choose to use it.
I dare say Linus has 20 years max left, so that's plenty to get RustOS up to snuff.
A clean sheet Rust OS with what hardware support - Linux is mostly drivers by volume of code.
Sure you can spin hello world OS. and get a loader working, implement enough basics to keep you interested. That's barely a program loader - if you are really lucky, you'll make it to dos 4.0 levels of sophistication in a decade or so.
When you can talk about the breadth of hardware compatibility that Linux has achieved, then Rust can speak, until then, please show stop telling.
A clean sheet Rust OS with what hardware support ?
one could begin with the Raspberry Pi : large volume, long-term availability, small variability, ARM instruction set, no x86 backward compatibility burden ... could be a good beginning. Make it a micro-kernel (or hybrid kernel) with user-space drivers and clean APIs and ABIs, let it focus on security. And if that works, add more hardware. The way I see Rust in Linux is that the Rust folk want to have the cake and eat it : profit from the huge Linux hardware compatibility without having to deal with the huge hardware compatibility issues.
That seems like a good compromise to focus on a single hardware platform with drivers and kernel to show the suitability.
"The way I see Rust in Linux is that the Rust folk want to have the cake and eat it : profit from the huge Linux hardware compatibility without having to deal with the huge hardware compatibility issues."
Completely agree, it's a land grab.
Realistically, one cannot target just a single hardware platform such as RPi with a limited re-write of all-of-Linux in Rust. Whilst the RPi itself has a few hardware versions and its own mix of devices for which drivers are needed, it does have USB and (now) PCIe; people do plug all manner of devices into it. You'd have to do many more drivers than just the ones for the devices the RPi foundation chooses to solder down.
As I understand it, Rust in the Linux kernel is being used for writing device drivers. So, it's adding to the Linux hardware compatibility list, not profiting from it. All these folk have wanted to do is to have a standardised wrapper around the kernel's DMA code, a not unreasonable thing given that the majority of uses for DMA is in device drivers. They were even volunteering to maintain it...
And beyond that, there's plenty of other operating systems whose device drivers are derived from those found in Linux. The source code is a good reference as to "how to control this device". OSS is, well, open; the whole point is to not keep it to oneself or be selective about to whom may use it.
how about if people just STOP spending all of that wheel-spinning time chasing the mayfly of "Rust" and LEARN 'C' REALLY WELL instead...?
But I bet I know what this is about: The next generation keeps saying "It is OUR turn now!"
Perhaps a quick read of Arthur C. Clarke's 'Superiority' is due?
Younger devs have enthusiasm but little experience. Older devs have experience and a desire for stability. Young-uns need to be "Apprentice" for a while until they have a decent grasp of WHY we just do NOT "do those things", after which they'll have experience AND DISCIPLINE to move forward SENSIBLY!
We could have avoided SO much... systemd, Pulse Audio, Gnome 3/4, Adwaita, 2D FLATASS Windows TIFKAM [and KDE], Wayland, the "Dot Bomb" bubble and ".Net" in general, C-pound, adverts as an OS, infinite list follows...
This is where we would differ.
The whole idea that a single OS should be extended to every device ever made, and end up becoming the one and only OS, is a very poor idea.
It is unfortunate that at each moment of time, it is a better idea to extend Linux and accept a compromised result, than to start again with something else. But this is how, compromise by compromise, the OS becomes less and less suited to most of what it is being used for.
I agree that the idea of replicating Linux using Rust is <various negative things> .
The point is to make something different that meets different requirements and works better for whatever it is that it works better for.
And hopefully more somethings than just one. Linux was the survivor from a dozen or so OSes
As a long time mobile Linux user (Sailfish), it is clear to me that Linux doesn't work terribly well as a mobile OS. It is no where as good (for some value of good) as MS made Windowsphone 8.1 by the time they abandoned it. Sailfish is probably the closest to properly functional, but it still takes 1+ year for the team to get a properly working port for each new phone - with Sony open support. At the end of that year there are hardware problems that do not exist in the commercial Sony Android version.
The supposed advantage of virtualising hardware differences away, so that porting to new hardware is easy and problem free does not actually happen in practice. In practice there is not one single non-proprietary, non-Android phone that has complete functionality in the whole world. The idea of a "stack" of "components" has not delivered real portability, performance, reliability or much innovation.
It is only (just) able to deliver workable, economic result when it is within the narrow bounds of the current Android on the current chipsets. No one can leave, because they have to cross the economic valley of death.
To be clear this is not because of Google and Qualcomm being evil, it is just the end result of the universal OS idea.
I learned computing with PEEKs and POKEs on the Commodore C64. We had printed magazines with listings of games that we entered by hand : one guy reading and the other entering the text. And guess what : we had fun ! And we actually had friends, like real friends that were our neighbors. Ah those memories ...
Big upvote for you!
I spent weeks typing a PacMan game into a ZX81 (Timex Sinclair in the US), every 20 minutes or so saving it to cassette. Every random number of minutes the 16K RAM pack would wobble and corrupt the memory and then I had to reboot, reload to last save point and continue. And for those not old enough to remember the ZX81 has a membrane keyboard so every key press needed to be deliberate and apply pressure. Every page or so there was a test point you could run to test your copying skills so far. Once completed I created 3 copies.
And it worked! I was so damm proud of that achievement. Always wondered who wrote these games for the magazines. You just made my day.
“I learned computing with PEEKs and POKEs on the Commodore C64. We had printed magazines with listings of games that we entered by hand : one guy reading and the other entering the text.”
Thanks gods someone else remembers this. For me it was a Vic20, but damn was that the way to go back in the day. Pick up the magazine when it hit the newsstands and would be hitting the keyboard right quickly thereafter.
Sigh. Yes I’m that old.
> I dare say Linus has 20 years max left, so that's plenty to get RustOS up to snuff.
You could try writing "Linux" in rust, from scratch, making it pure 100% rust...
Mind you, in 20 years, Rust will have been forgotten, and we'll probably be on the 9th generation of "new fad language of the day" :-)
>It seems to me, as a total outsider, that the idea of grafting a second
>language into an already working but heinously complicated and
>elderly OS, is really a fools errand.
Not at all. What everyone forgets is that in the Linux kernel there is sections of assembler, so it's already got multiple different languages in it anyway. People will say "ah but that's just bootstrap code" or some such minimising claim, but it's still there.
Rust was created with interop with C in mind. So, far from being a fool's errand, it's simple and pragmatic. One isn't having to mess around working out what each other's calling conventions are (which is a problem one faces if - for example, trying mix C and Pascal, or C and Java, etc). Obviously the benefits of Rust are not magically extended to any C code forming part of the same executable / kernel, but that too is the pragmatic thing to do; one cannot boil the ocean. The result is that one could slowly creep through one's existing C code base and convert it module by module to Rust.
That was a deliberate design decision by Rust, and it is this that's made it so intriguing from an OS developer's point of view. Some OS projects seem to be, well, hesitant (Linux), others seem to be full on heading that way (e.g. Microsoft seem keen).
What'll kill Linux is if everyone else moves on and are clearly reaping benefits as a result, whilst Linux is the last OS left standing accumulating CVEs related to mistakes with memory usage. The large corporations that currenly use it and contribute to it (to varying degrees) would be pretty much obliged to abandon it, if there were a clearly superior alternative written in Rust. CVEs cost money and are a business risk such companies do not want to hold. And if that transition happened, companies like Intel would be more interested in their chips supporting that OS instead of Linux. So they'd stop contributing. And a RustOS already exists - Redox; it's not production ready, but a comparatively small team has been highly productive and rapid (which ought to be a lesson in its own right). If that reaches production readiness, people will start trying it out seriously and may like what they find. I think the assumption in the Linux world is that Linux is like a mighty, impregnable battleship and everything else is a minow, but assumptions are not reality nor can one depend on them.
There's also government; the US gov did a study of economic damage caused by buggy software (so, not just OSes), and its a huge number per year, well north of hundreds of $billions per year. The accumulated financial cost of 1 bad CVE is pretty massive. No wonder they're pushing for developers to adopt safer languages.
Linux is the last OS left standing accumulating CVEs related to mistakes with memory usage.
I ran this through Grok. It did not fully understand the statement, but DID find relevant info, such as this:
"a post from @0xTib3rius notes that the Linux Kernel team now issues CVEs for every bugfix, even if not security-related, which inflates the CVE count. This practice makes it appear as though Linux has more vulnerabilities, but not all are exploitable or critical."
- and -
"Linux does accumulate memory-related CVEs, particularly in the kernel, but this is not unique to Linux. Other OSes face similar issues, and Linux's high CVE count is partly due to its transparent and granular reporting practices. Additionally, Linux's open-source nature and widespread use in critical infrastructure make it a frequent target for vulnerability research, increasing reported CVEs."
Read the sentence again. I think you already know the context, but if you somehow don't, they were stating a hypothetical where other operating systems adopted Rust or something else that eliminated memory-related CVEs*, and Linux didn't, thus that in this situation which is not where we are today, Linux would be the only one with those CVEs. You decided to take something that was clearly a what if and treat it as if it was stated as current fact. That makes it easy to disprove**, but it doesn't make other points.
* And you had plenty of points you could have made. The way we would get to a memory CVE-less world is far from clear here. You could have argued against them by pointing out how difficult that would be in practice. Linux could reduce or eliminate theirs in a few different ways. You could propose one you liked better. I'm not going to argue either of those for you, but you can if you decide to argue against what they said.
** You didn't have to go to an LLM to disprove it. If you know how these CVEs work, you can get actual information about real ones in other operating systems, for example the ones in Microsoft and Vmware that were covered in an article in this paper yesterday. A summary from a bot that could have made up the existence of things is less reliable information, even if it was correct this time.
"The result is that one could slowly creep through one's existing C code base and convert it module by module to Rust."
We don't want to do this. That's exactly the complaint. it's an occupation not a graceful co-existence.
It's a C project - it's glaring tin-eared to posit the desire to throw it all away and turn it into Rust, Is Agent P behind this?
When that sainted day appears, the lame will walk, and the blind shall see.
It's clearly superior by virtue of the compiler frontend - not by any new idea introduced - not by performance, hardware support, rich IPC primitives - but the language it's written in.
This is what makes people want to sigquit.
People are security bugs, exploits in practise are more about sending some horny mid-level management moron an link to click in email, than buffer overflows.
We deploy stuff in containers in VMs so who cares if it crashes, and if you do care the unreadable nature of the code and the NPM situation of Rust Crates https://kerkour.com/rust-crate-backdoor Is not an argument in your favour.
So for an OS Kernel I'd like it clear what happens, I want it explicit, I quite approve of the Kernel Style guide.
I don't want to code in a functional language in an OS Kernel. I don't have a functional CPU, it's imperative and concurrent. I don't want to satisfy the borrow checker before I'm allowed to write code unpaid on hardware in my possession.
If you want to use some tools, feel free. Why try and forced it on others without a shred of evidence.
This row has broken out because of recognised need for a language fit for the 21st century that has security and a robust architecture at its core. C is an old language, as in I first started working with it in 1977! It is designed to compile to highly efficient code that is as close to the machine core as possible. And in this it is highly successful. The problem with C is that it is very easy to write bad code. I will go further, it is very hard to write perfect code.
Rust has been designed to overcome a lot of C's problems with a compile time checker that prevent misuse of data structures. By eliminating race conditions, buffer overruns, etc but still allowing a code conversion to efficient machine code, Rust is less of a language like C and more of a High Order Assembly Language. There are, however, two big downsides to Rust. First is has a very steep learning curve. The concepts of borrowing are just so alien to large parts of the kernel community that it does seem like snake oil - it promises a lot, but getting there is a huge struggle. The second is that it is not best suited to dealing with device drivers, where raw access to registers and I/O ports is itself alien to Rust.
Is Rust the answer to the Linux kernel? Well, perhaps not. Yes, I think it can be a good tool, but maybe start by writing all the user functions that exist in the Linux operating system as small (sometimes not so small) applications. Going headlong in to the kernel is never going to work. The issue with the bindings is just one point.
What Linux should be looking at is the size of the kernel. Does everything that is in there really need to be part of the kernel? In my opinion, we have seen kernel bloat, with the memory foot print increasing. If we had more work being done in non-kernel services or applications, then the kernel becomes smaller. Rewriting the now non-kernel components in Rust is a much cimpler task.
But moving the whole kernel, that is premised on multi access to shared data structures, will be very hard to do in Rust.
Maybe what we really need is a much more rigerous C compiler. Something that takes the lead from the Rust compiler to prohibit, or at least warn, when non-safe operations are being attempted.
Rust has little to do with C. It's an attempt to force functional programming on people who don't give a shit about haskell. http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html
C++ was designed to make writing C more productive, hence it allows you to actually upgrade a C codebase carefully preserving the meaning.
Rust has no record save a browser and reimplementing command line utilities written decades previously, claiming improvements - we'll see.
It's a hostile language with a coercive approach to legibility - code is written to keep the borrow checker happy, in some strange pagan ritual of appeasement.
I can't imagine anything I want less in an OS kernel.
Yes "Plain C" has some issue - but nobody not least the Linux Kernel uses "Plain C" so the gnu extension used in the Kernel rather help here, eliminating the need for the "iron bullet"
Is Rust the answer to the Linux kernel?
Perhaps we should start by stating the question the Linux kernel is supposedly posing. Only then can we make an intelligent decision of whether "Rust is the answer ...". Otherwise, there is a strong whiff of Rust being an answer looking for a question.
Maybe what we really need is a much more rigorous C compiler. Something that takes the lead from the Rust compiler to prohibit, or at least warn, when non-safe operations are being attempted.
clang/llvm is doing pretty well these days. It gives me warnings about things like printf arguments, for example. I like enabling aggressive warnings for release builds for that reason [disabling anything irritating that does not matter to the project].
Maybe a 3rd party tool that looks for edge cases...? And, of course, "code smells". A kind of "Lint" but on steroids.
Things to look for: fixed buffer sizes without buffer checks, use of certain stdio/stdlib/string/memory stuff, variable scoping (use of same name in an inner scope), possible use-after-free, ambiguous formulas (use of | instead of || or not using parentheses), etc.
What Linux needs is not a new language but better governance. Or psychological help. Or both.
The fact that Linus (or other leadership, a word I use in a very loose sense), does not have a longer-term migration/adoption plan for alternative technologies like Rust, or the means to communicate a firm "no" when people start pushing for one, are two of the many big issues Linux faces.
Some very big corporations rely on the continued success of the kernel developers to deliver working code. I'm very surprised they haven't gotten their mitts on the kernel leadership for a little meeting. We call it a "Come to Jesus" meeting in my part of the world.
Tick tock.
"The fact that Linus (or other leadership, a word I use in a very loose sense), does not have a longer-term migration/adoption plan for alternative technologies like Rust"
Or micro kernels? :-)
Well, the thing is, these big corporations that rely on them continuing to deliver working code are for the most part not paying them. Companies that used to have 5 or 6 big devs now have 1 or 2. So they can try to have a 'Come to Jesus' meeting all they want but, well, if Redhat called me in to tell me to shape up, since they don't pay me I'd probably tell them where to shove it LOL.
As Frederick says in his subsequent responses, Redox seems to be the way to go. With the COSMIC desktop they are most of the way there.
£inux as a kernel was of course only intended in the 1990s as a stopgap with the HURD being the ultimate aim. Redox - as a microkernel - seems to promise that which HURD does, but enjoys much greater momentum. The only problem it seems - for Redox being the basis of the GNU project going forward - is that Redox has the "wrong" MIT licence. Maybe that could be changed?
Of course there are other Rust operating systems than Redox cooking, including an implementation of Plan9. There is also the AGPL licensed Genode (not Rust). There needs to be a Plan B in case £inux (kernel) fails.
Well, use of "£inux" isn't helping. What is that supposed to be? Some weird reference to the old use of Micro$oft, indicating how expensive it is to buy a Linux licence?
Plus the weird idea that the GNU project would need or want to take over another kernel, let alone changing the licence from MIT to do so. As with Linux, if you want to use the GNU tools to flesh out a complete system around your kernel, just do it. GNU itself need not take over your kernel.
And the final nail, the weird idea that Linux was ever intended, by anyone, to be a stopgap until HURD was production ready, presumably with the idea that, at that point, Linux would just - stop.
> £inux as a kernel was of course only intended in the 1990s as a stopgap with the HURD being the ultimate aim.
Citation?
Linux and HURD are from entirely different people.
I don't recall Linus ever saying he intended to create a stopgap until the HURD was ready - in fact, his announcement was that Linux "is just a hobby" and "won't be big and professional like Gnu". It was just a response to the licensing around Minix.
> Citation?
https://en.wikipedia.org/wiki/GNU_Hurd
"(GNU HURD) has been under development since 1990 by the GNU Project of the Free Software Foundation, designed as a replacement for the Unix kernel, and released as free software under the GNU General Public License. When the Linux kernel proved to be a viable solution,"... (hence GNU/Linux for the pedants amongst us!) ..."development of GNU Hurd slowed, at times alternating between stasis and renewed activity and interest."
Yes, my little thing of calling it £inux might be childish, but my way of signalling it is not the counterculture OS of early 1990s anymore, Linux (£inux!) development is driven by the needs of big business now.
> https://en.wikipedia.org/wiki/GNU_Hurd ...
Nothing in that says that Linux was ever a stopgap for HURD!
> "When the Linux kernel proved to be a viable solution"... "development of GNU Hurd slowed"
And if you read the article that Wikipedia uses as a source for the line you quoted, the article does NOT say that HURD development slowed BECAUSE of Linux. The pace of development of HURD has never exactly been speedy - for Heaven's Sake, HURD was "on its way" since the 1980s!
> Your link is broken
Blast, you are right, copied and pasted from the wrong bit of the browser; here is the link going via the Wayback Machine.
Having said that, it isn't "my" link, it is the link from the Wikipedia page for the lines that *you* quoted (their [5]) so I'd've hoped that you would have recognised that - and been able to comment that I'd just missed putting on the Wayback prefix.
> the GNU/FSF intended |_inux to be a stopgap for Hurd (which is likely correct)
Likely correct? Really? Sorry, going to need a citation for that...
I'm afraid that I can find no place where GNU/FSF ever even suggest such a thing. They do talk about running HURD within Qemu under GNU/Linux but don't seem unduly angsty about doing that. When talking about Linux and the GNU System, Stallman has said "Fortunately, we didn't have to wait for the Hurd, because of Linux. Once Torvalds freed Linux in 1992, it fit into the last major gap in the GNU system." and "The GNU Project supports GNU/Linux systems as well as the GNU system"; no doubt that he would like to see HURD get wide use one day, but the FSF generally seems chuffed that all their other projects (piffling little things, like GCC :-) ) are gainfully employed.
I liked Modula 2 also and never completely forgot about it. In fact I incorporated a few of its features that could be translated into my C programs many years ago even though it takes more initial effort since C compilers don't support these features. The reason I use them is because they help me write programs that are better to begin with as well as more easily debugged and maintained.
Having spent my entire career in embedded hardware/firmware where the only real alternatives were assembly and C I have still maintained a watchful eye on other programming languages over the years. Rust was the first one in a long time that really interested me so I started to learn it a little over three years ago. Unfortunately just after I started a serious health problem I will be dealing with from now on forced me to stop. Now I have other priorities one of which is to stop spending so much time fscking with computers.
Now I have other priorities one of which is to stop spending so much time fscking with computers.
good luck... i've been trying for a decade or so and... yeah... if i don't have two running systems (not devices) nearby, it feels as if the world is dead...
because everyone needs one at some point --->
Many people are working on these sort of options. The problem is that even though Rust is young it has still had a decade of work on it. New languages would likely face all the problems that Rust does in terms in early stage instability and change. And, while languages like zig allow much tighter integration of the code base (i.e. mixed in the same file) they will still bring all the issues that multi-language builds do.
We will see how it does. As you say, the big question is where R4L will go after drivers. We will see something more substantial? And what would that be?
"What I would prefer is a language which is derived from C (Rust is only vaguely C like) but has seldom used features removed and memory safety features added in. This would allow a sensible upgrade path without having to rewrite everything."
^^^ This. ^^^
I have long felt that fixing the shortcomings of existing languages would be much preferable by introducing a whole wadge of new ones. Don't get me wrong: new languages are useful, offer important features not available in older ones that can't be added easily, and once they have proven themselves they should be the tools of choice for new projects.
But when it comes to dealing with the shortcomings of old languages, then extending the old language in a manner as close as possible to its original "character" (for lack of a better term) seems preferable to me. That's why I never liked C++. The main advantage of C++ over C, as I see it, is its OOP capabilities. So why did something like printf ("Hello World\n"); have to be changed into cout << "Hello World!";? Even something like JavaScript's document.write("Hello world") would have seemed a better approach to me as a solution to adding OOP to traditional C without giving seasoned C developers the willies. (Yes, I get it, there's more to it than that, but that's for another discussion.)
As per the above citation, Rust is only vaguely C like. So are most other languages that have aimed to deal with C's shortcomings (which are in many cases serious ones, it has to be said). Hence the hoohah over mixing it with traditonal C. If traditional C had simply been extended with new features to provide things like OOP, memory safety, strong typing and what not, while still being C, none of this kerfluffle would have occurred.
Instead we've got two very different approaches trying to meet in the middle. There's a reason why the combination of C and Rust is often referred to as Crust.
This could have been handled better. Take, for example, PHP: it started to slowly make its way into production environments at version 3. However, when you compare PHP3 to current PHP8.4, there's a world of difference. But progress has been gradual and sensible: horrors from the past have been deprecated and subsequently removed as progress progressed, and new features have been added in a similarly controlled manner. Why didn't we do that with C? Why don't we do it now? It's not too late.
C++ wasn't about OOP.
It's about
1) shared container/algorithm libraries so we don't all write another linked list again, or have to implement std::transform.
2) RAII - tying the lifetime of resources to the lexical scope of an owning handle, which eliminated a lot of memory / resource management issues.
3) larger systems, C already has facilities for modularity but at a certain size, it's a little easier in C++ simply because the type system is a little richer. Gloriously you can write a very high level expressive C++ fluent api, and provide an very nice C flavour interface with little effort.
It's a little dated now but excellent book on the topic https://www.amazon.co.uk/API-Design-C-Martin-Reddy/dp/0123850037
> C++ wasn't about OOP
Funny, could have sworn that the oldest version was called "C with classes".
> Shared container...
That came well after the first few releases,vwith templates - and then that chap at HP describing the template- metaprogramming library that became STL. Many years into the life of C++.
> It's a little dated now but excellent book...
If you actually want to learn what C++ "was meant to be", start with Stroustrup's Green Book about the history of the language (sorry, don't have a URL at the moment)
This post has been deleted by its author
Oh, I forgot:
> C++ wasn't about OOP
> ...
> RAII - tying the lifetime of resources to the lexical scope of an owning handle
RAII is built upon the object model (your "owning handle" has to be an object with the actual handle/pointer/id of the resource as a member, so that the constructor and destructor of that object manage the resource. And it isn't anything specific to do with lexical scope - the resource is managed by the lifetime of the object, which *might* be lexical scope but need not be. That is, RAII is provided courtesy of the OOPness.
The point I'd responded to posits simple method invocation syntax changes as being the only difference in ideas between facilities offered by C and C++.
I'd attempted to make a different narrower point but fine.
You are correct about the original name of CFront.
You are also correct that C++ is/has elements of OOP facilities.
I'd quibble a little about your nitpick - the entire premise is that the lifetime of the resource is the same as the handle, which in the most trivial example is lexical scope; But fine, its more properly described as lifetime of owning handle rather than scope.
Have a beer.
This post has been deleted by its author
the disadvantages of a multi-language project are significant and unduly burdensome on developers.
YES!!!
First time I ran into this was a FORTRAN wrapper that someone ELSE wrote (and lost the source for) that called into a COBOL library supplied by a tax service to interpret sales tax from a monthly tape update (subscription) so the correct tax would be charged, etc.. The FORTRAN wrapper uses parameters passed by reference. Predecessor altered them in the wrapper function, leading to wrong values in the calling function. (fix was to make local copies, muck with the copies). Thing is, that was fixed BEFORE in an earlier build BUT it came back because "He who shall not be named" DID NOT PROPERLY SAVE THE FIXED SOURCE.
Anyway, the wrapper should have been simple, but "predecessor" found a way to screw it up...
What I would prefer is a language which is derived from C (Rust is only vaguely C like) but has seldom used features removed and memory safety features added in.
1. Your seldom-used features will be different than other peoples' seldom-used features.
2. The features of C which make it not-guaranteed-memory-safe are the same features which make it useful. I'd be interested -- I'm being serious, not sarcastic -- in seeing how you and/or others replicate the useful features of C while maintaining memory safety.
Rust does not offer absolute guarantees of memory safety. Memory safety has to be turned off to do many things that need to be done, particularly with respect to working with Linux which was not designed around a memory safe language and so has many features which have to be used in an "unsafe" manner.
This means that just using Rust does not in itself provide any additional memory safety guarantees. You would have to write an entire OS from the ground up in Rust in order to take advantage of Rust's language features. And if you are going to do that, why would you start with Linux? Just write the new OS without worrying about Linux. If it's really that great and secure, then people will use it based on a better security record and Linux can be gradually retired. I have no emotional attachment to Linux.
If on the other hand the goal is to improve Linux, then the right tool for the job is one which works as well as possible with the existing code base allowing for incremental improvement instead of a multi-year big bang rip and replace. Rust is not designed for incremental change, it's all or nothing.
Right now Rust is in a relatively isolated corner on its own with minimal interaction with the rest of the kernel. Nobody has the time or resources to rewrite large parts of the kernel in Rust that are currently working well enough as they are, even if there may be potential memory safety issues that nobody has found yet.
In other words, there is currently no viable plan of action under which Rust will ever become the sole or even main language used for Linux. If the goal is better security through better memory safety, we won't get there by using Rust.
If the goal is to improve Linux rather than use Linux to promote Rust, the only realistic plan is to use a language which is so closely derived from C that changes to existing code to use it are minimal while memory safety features are additions or extensions to syntax which don't conflict with backwards compatibility. That would allow a gradual function by function change within the same file during the course of normal development and bug fixing rather than having to replace entire subsystems in order to use it at all. This in turn will be something that happens over the span of decades rather than all at once.
I don't believe that this language exists yet. However, there are many people working on the memory safety in static languages who are currently taking in the current lessons with regards to the issue of improving memory safety in existing projects with large code bases and they may come out with a suitable solution within the next few years. Their scope would be much more focused than that of the Rust developers as they would not be designing a whole new language.
They would also not need to come up with a perfect solution. Something that offers a significant improvement that falls short of solving 100% of the problem but is actually easily assimilated into existing projects will make much more of a practical difference than something that offers a theoretically better solution but has no practical path forward.
As I said before, I'm not a fan of C. I use it because it's the language that I need to use in order to work with existing systems. I have learned many different languages over a long career, and continue to learn new ones now.
However, my objective is always to produce useful software, not to promote a language. To me, the language is just a tool to get the job done. If the goal is to improve security in Linux, then Rust is simply the wrong tool for the job and I wouldn't recommend using it for that anymore than I would recommend using Ada or Modula 2 in Linux, regardless of how the latter two languages may be objectively "better" than C.
Using Rust for device drivers, it's current niche in the Linux kernel, is not really playing to it's advantages as it is impossible to write a memory safe device driver that talks directly to hardware. That said I am certain that there are other parts of the kernel where using Rust would be helpful at least as far as memory safety goes. Having said that, after reading a book on Linux kernel internals years ago I can also say that there are many parts of the kernel that, for efficiency's sake, must be written using "unsafe" C. The amount of work that gets done to provide all the elements needed for a modern operating system is truly astounding and pointer access to data structures to allow more complex algorithms to do this work is essential. As long as you use programmers that have an excellent working knowledge of C, as do all kernel maintainers I have no problems with using it. However, given the focus of modern computer science education finding these programmers is becoming increasingly difficult and this is a real problem. One of the things that Edsger Dijkstra said that I strongly disagree with was (paraphrased) that programmers did not need to know how computers work to be programmers. While this is true for a lot of programmers it is not true for the programmers that do the work that makes all the layers of abstraction used today possible.
Rust is not Snake Oil, because Snake Oil worked - you just needed the correct Snake, i.e. time; effort; extensive testing; rigour in design and implementer. Instead "Borrow Checker" "safety" "modern" on examination they're not even snakes, they're slow worms.
The Rust people want to tell the worlds largest C project that C is shit, and we should instead do functional template programming with odes to type systems, in an ML variant with curly braces.
The fact is they want traction for their language and are trying to social engineer their way into a project run by people happy to tell them to fuck off.
There is not any magic instructions that LLVM can emit for X86_64 that GCC cannot. All you have is someone who doesn't want to work in C being a dick, If you want to have Rust drivers - go for it,
You fix the breakage keep them in your tree. I don't want IN-Tree Rust drivers. I was ambivalent at first but this has hardened my objections.
Linux has scaled from HPC Big Iron to MMU-less Micros https://hackaday.com/2023/10/11/tiny-linux-on-a-no-mmu-risc-v-microcontroller/
We didn't need Rust then, we don't need it now. However Rust has nothing credible to hang its hat upon, hence the desperate desire to attach itself to the Kernel and bathe in reflected glory.
The kernel developers who started R4L started the project because of their interest in memory safe languages and specifically Rust. They thought that the project would benefit from Rust.
The social engineering that you speak of is that they started with an RFC, had lots of discussions and got the agreement to start that process, rather than telling them to fuck off.
I think what at least one person is finding tiring, is having the same argument again and again. Do or do not as Yoda would say.
One: Rust generally: Social engineering due to lukewarm developer take-up.
https://users.rust-lang.org/t/white-house-press-release-future-software-should-be-memory-safe/107442
https://stackoverflow.blog/2024/12/30/in-rust-we-trust-white-house-office-urges-memory-safety/
https://www.darkreading.com/application-security/darpa-aims-to-ditch-c-code-move-to-rust
Two: I'm sure a Rust guy thought the Rust Project would benefit.
Three: There is indeed a RFC and the top comment is "no thank you"
Agreement is a little strong - what they got was, well propose your patches, we'll look at it, it was looked at and found wanting.
Including a new language was always going to come with some effort. So nothing is really changed there. But there have been many patches, and lots of work, and occasionally there has been some argy-bargy. And lots and lots of angry people on social media, but then that is modern life; I wouldn't draw too many conclusions from this.
It might well force a better result for all of us, but so far all I feel is insulted by proponents of Rust, as they suggest that by using Rust, some advantage will accrue.
It's not evidenced. My code is just fine in C, C++, or ASM, it's very different in each variant but I don't have those bugs because I test my code, and attempt to design it correctly in a simple fashion, evolving it into more complex forms and testing as I go.
Rust proponent are telling me I have to use their language, which I dislike. I like C, it's an easy language to boostrap a little compiler for. It's a very productive language once you get going.
If I've got room for Rust, I've got room for C++ which for me is an easy choice - not one I'd make in the Kernel; it's fine writing C++ drivers for a company with C++ developers, but I wouldn't submit them in tree https://olegkutkov.me/2019/11/10/cpp-in-linux-kernel/
Rust is just insulting the people whose work they want to benefit from, and only want to benefit from it because it's clearly superior to anything else out there.
Again, that wouldn't insult me. When editors started auto-indenting code, I accepted that they would probably do a better job of it than I would and my code was worse without.
I can understand many reasons why you might not want to use Rust: it's got a steep learning curve, you lack the experience in it, you don't think that it would bring you significant advantage or that the advantages are outweighed by the loss.
I just do not understand why you are so agitated by what other people think is an advantage, nor why you would ascribe such malice to their actions.
I doubt that I am going to understand.
You've no idea of my experience or lack thereof in Rust or in any other language, but as a good Rust advocate you can assert unevidenced and continue as if assertion are conclusions.
It's simply a fact that your argument is unevidenced that some advantage exists; If you feel that telling you that your work is shoddy, absent evidence is not an insult, and that switching from C to Rust is like auto-indenting editors - I'm not sure we can productively discuss language issues.
My code is long lived, sometimes throwaway but mostly its worth spending some time on. I don't think we're going to agree that Rust is suitable for my use cases.
I don't have memory bugs in my code, or threading bugs in my code. Between c++11 and c++17 the same code got shorter and more my work moved out of my library and became standard usage.
So I got to delete code, and port to a shared bug free better standard library. It happened at time of my choosing, at cadence of my choice.
Rust has nothing to offer me when I'm greenfield, because I'll prototype in a scripting language like ruby first and often that's enough.
For things that need the widest possible interface Hourglass interfaces in C++ with C callable interfaces for exports is the default.
I wish you success with Rust, but I think I'll refrain.
C++ offers me an advantage over C and my own libraries.
C offers me an advantage over assembler (register choices, and structured concepts which I'd have to macro up) and my own libraries.
You have asserted lots of things in this thread, particularly about what the motivations of people using Rust are.
For me, I had to choose a few years back between starting a new project in C or in Rust. I wasn't hugely familar with C at the time although, ironically, what is probably the most used thing I have written is in C; and Rust was relatively new, and I didn't know it at all. I picked Rust, and it worked well for me. Nice community, nice tools, expressive language. Steep learning curve, although I *think* that has got easier. The language has certainly advanced a lot since then.
I am glad that you are happy with C and C++.
However, I feel Rust is seriously misrepresented on these forums and that the Rust for Linux project is particularly maligned for the wrong reasons.
You often read people here suggesting that Rust is claiming to be a fix for everything. It doesn't claim that, really it is only claiming improved memory safety without compromising much performance.
People claim that this can be done if you are more careful with C or whatever language. Of course it can, but humans are human therefore fallible. This is why we build bridges with parapets. Of course we don't need parapets if everybody is careful all the time, but humans.....
There are quite a lot of commentators here who are voraciously opposed to anything that might change their comfortable established life, this applies to many thing - ordinary things in life and not just programming languages. They seem to just object without suggesting solutions, they want to talk only about the cons without considering the pros.
I've had a look at Rust, and I find it quite a steep learning curve, so steep in fact that for me to learn it would require more time than I have. But I love the idea and wouldn't want to discourage it.
I think some folk have years of experience and skills built up and are comfortable in their traditional language world, they are looking over their shoulders at the new kid and scared this it might take a bite of their pie. It's easier to knock it down than to embrace it and learn it.
Must be Rust. "is only claiming improved memory safety without compromising much performance." Improved over already correct code how? - Quantify "much",
It doesn't help clarity, or correctness. It promises safety as that's undefinable. Correctness is conspicuously absent from advocacy, clarity and legibility, not promised. Standards with multiple interoperatable implementations ? forget it.
If you want to propose some kind of advancement, try to engage with the reality, which is your world was built in C, C++ and Assembler. Rust is just a frontend to LLVM. why don't you rewrite LLVM in Rust to demonstrate how wonderful your language is.
Why exactly does this seem Safe that something unfamiliar to the eyeballs most likely to be inspecting the kernel should be forced on them. I Reject Rust. It's Unsafe blocked.
Must be Rust. "is only claiming improved memory safety without compromising much performance." Improved over already correct code how? - Quantify "much",
Literally the next paragraph I wrote after that one answers that.
And it's not "my language". I wrote quite clearly in my comment that it's too much for me to learn in the time I've got.
You do a great job of demonstrating the kind of person I'm talking about. You didn't even read, just launched into a whingey rant.
Rust wants a notion of usage encoded in the types. C isn't remotely interested in holding this metadata. This has an impedance which Rust like Go has imposed in an attempt to impose a viral spread of the tooling, leading to pressure to replace with Rust.
There is are some who wish they were constructing elegant mathematical proofs, rather than coaxing a poorly specified loosely implemented hardware device into operation in concert with other systems.
I understand that the faith in the type system means if my program compiles, it's probably correct. But it's laughable - the vast majority of Linux sources are in an imperative style with explicit behaviour being desirable. Rust is a complete departure from this, looking like perl without a side by side presentation of some code, how that's "better" in Rust, I'll stick to C, C++, and ASM,
Rust is unsafe blocked.
You can call C directly from Rust. Or you can autogenerating bindings which reduces the amount of typing and makes the use of C more naturalistic syntactically in Rust.
The bit that takes the work is to make a safe abstraction over the C interface. This part is explicit about things that C is often implicit about: can a value be null or is it guaranteed; what is the lifetime of a pointer; do certain values represent errors.
I am not sure what tiny C front end you would want, nor where you would bolt it.
> You can call C directly from Rust
No you can't
> you can autogenerating bindings
Not really. SWIG / bindgen will only be ~75% successful. This is why the Linux developers are complaining about all these Rust "abstractions" (basically bindings) in the kernel. The problem is MACROs and non-opaque APIs.
> am not sure what tiny C front end you would want, nor where you would bolt it.
Check out C-based languages to get a feel for how this would work. C++/clr, Zig, C++, Objective-C are quite nice examples of tools that can directly consume C code but providing safer abstractions.
Why do you think you cannot call C directly from Rust? I am guessing we are talking about two different things. For Rust, you need to add a header to your rust file to describe the function that the C library offers, then away you go. Rather like C actually, which uses header files.
Not sure where SWIG comes into this. AFAICT, linux is using bindgen. This just transforms C header files into Rust ones as part of the build process. (and why, I hear you ask, can't rustc just consume C header files?). As far as I can tell, Rust in Linux only uses generated bindings. The file "binding.rs" just imports the generated files. So I think you are wrong that macros (on the C side presumably) and non-opaque APIs are the issue there.
The Rust safe abstractions are not the same thing as a bindings. They are the bit that takes you away from unsafe code that is the result of the direct C bindings.
Zig looks nicer than Rust for its role of C integration I agree (I make no comments in general, since I haven't used zig properly). It can directly reference C header files and the compiler will even handle building of C source for you for mixed projects. So, there is a bit more set up there. I expect that Zig would still require something equivalent to the Rust abstraction layer to make life easier for downstream Zig developers; difficult to say, as there is no "zig for linux" project yet. Maybe there will be.
> you cannot call C directly from Rust
You can call a native library from Rust (as you can with any language). But you cannot call a C function directly from Rust without creating bindings (Creating a specific Rust "header" is whats called creating a binding).
> SWIG
SWIG / bindgen perform the same task. Binding generators. Nothing special between them.
> The Rust safe abstractions are not the same thing as a bindings
They are; they are called "fat" bindings. C++ has direct access to C functions but you can also create "fat" bindings as part of RAII wrappers.
Okay, it seems that there is just a small difference in terminology here. Rust does, indeed, currently uses a set of bindings written to file rather than directly use a C header file, while languages like zig do the same thing presumably in memory. That seems to me to be pretty much an implementation detail. As Rust has now automated the binding generation, it is also possible to macro the process out and create a "c_import" statement in the same way that Zig has "@cimport".
Rust can call C, it can call an arbitrary function in C, it can handle arbitrary data structures created in C and it can create C any data structures on the Rust side and pass them to C. You do not need to create shim code in C, using any particular interface or object to achieve that.
You do need to add extra code to describe the additional semantics that Rust uses to define safety which C cannot do. I am not sure that I can see the easy alternative here.
Reading Martin's resignation comments, it seems obvious that he is interweaving technical criticism with attacks on his person.
That's understandable - most software devs refer to their code in the first person singular. But he does this consistently, not just discussing this one patch. It actually reads as obsessive.
But it doesn't help advance the dialog. If Martin responds to criticism from the belief that it is primarily an attack based in personality, then he stops himself from addressing the stated, technical issues. This is what I see in Torvald's "accept the fact that maybe you are the problem".
Even your comment has this. You say "obstructive" I say protective. Helliweg even offered an alternative aproach "Keep the wrappers in your code". I have not seen that addressed by Martin or anyone else. It's like it was seen as the rantings of an obstructionist, and dismissed out of hand.
FreeBSD has dodged SOOoo many bullets, from Poettering and systemd to Gnome 3 to the Wayland cancer. Although there are ports for MOST of that "other stuff", the choice to NOT use/install it has ALWAYS been there. FBSD stabilized Gnome 2 and made it bulletproof for a couple of years while way too many Linux distros fell into the pit of Gnome 3. Eventually Gnome 3 became a port, BUT so did MATE. It was VERY nice timing!
Let's NOT *CORRUPT* the perfectly good and well-tested C language BSD kernel with RUST code. Just DON'T.
Adding Rust would make the LOGO CHANGE fiasco and Dragonfly split-up look like CONSENSUS!
[FBSD has a lot of 'Ents' involved, and contributing code gets MANDATORY high standard compliance and lots of scrutiny. Even "Hungarian notation" will get your submission rejected. And that kind high quality maintainability standard helps make the BSD kernel the rock solid powerhouse it currently is]
> and as a result have shouldered the burden of keeping Rust bindings separated
How nice of them. Too bad that's not how the Kernel development works.
https://docs.kernel.org/process/handling-regressions.html
One of the core rules of Linux Kernel development is "We do not cause regressions.". Also known as "you break it, you fix it".
And this is hard enough as it is when the kernel uses only one language. Now we have an ENTIRELY DIFFERENT language. This new language now writes stuff that relies on existing kernel code. This new language also requires APIs to be built to accommodate it. Guess what, these APIs can now break when the upstream code changes, meaning suddenly maintainers of purely C-based components need to invest time and effort to maintain that API.
And refusing to do that, is not "downright obstructive".
It's what happens when people, many of who invest their free time, don't want to have their own job made harder by an addition they have nothing to do with.
Is a parallel version released at a slower cadence and slightly delayed release dates an impossible idea? Seems a shame to burn so much drive on conflict. Just add more rooms to the house. If things go well then in a few years remerging might go smoothly as the releases become near simultaneous anyway.
There's a kind of tension in the Linux kernel world as it's never had stable kernel APIs. On the one hand, having stable APIs means less maintenance for those using them for things like drivers. On the other hand, backwards compatibility with APIs that turn out to be less than ideal can hinder development of the systems sat behind those APIs.
It's one of the things that has been a big problem for Microsoft. I'm not a fan of their products, but they have gone to great lengths to maintain backwards compatibility. That has come at a cost of improvements that would have potentially improved their own products.
Neither approach is fundamentally wrong - it's hard to get an API right, while breaking an API in a new version is tough for the users of that API. The Rust on Linux people are struggling with the Linux approach of preferring to improve - or at least change - kernel APIs. Perhaps it's better they focus on an environment like Redox OS where those changes aren't dictated to a considerable degree by the underlying architecture being based on the semantics of the C programming language.
"The number of people who have left the Rust project due to burnout is shockingly high. The number of people in the project who are close to burnout is also shockingly high."
Would be an interesting sociology PhD project to compare burnout rates and mental health and other psychological factors between comparable software projects Rust v Golang (or Zig, D,...) as one might ponder whether the quasi-religious fervour in evidence from the Rust community might betoken a pre-existing or pre-Rust dysfunction.
Sorry, but Go is a terrible programming language. It's basically a warmed over C with terrible error handling semantics. It's like its creators have ignored all the experience we've had since the inception of C but added a few misunderstood features they've heard second hand from subsequent languages.
Zig is more interesting though, a language that seems to be somewhere between the outright permissiveness of C and the arguable awkwardness of Rust. It also produces native code that runs incredibly fast, mitigating a lot of the criticism of other "better than C" languages.
You'd have to do a lot of work to figure out what is comparable. For example, if the burnout in the Rust community is at all related to kernel problems, then neither of the other languages you list can be compared as they are not used there. You'd probably also have to consider community size, but you can't compare size without comparing scope of what the community is building as one may manage tools the other one doesn't need, leaves to an open source developer, or just doesn't bother with. You would also need to add in how many people are paid to do it by an employer, as those people will burn out in a very different way, if at all, to their volunteering colleagues. I'm concerned that any research attempted would find these problems too annoying to solve and would have to use a simplistic definition for all the important elements to come to any conclusions.
I have been using Rust for a while now, along with other languages. It choose it for a particular project because it was fast with good tooling. Since I started it has also gained good python integration which is what I needed. Most of the people in the Rust community are using Rust for their own reasons.
I haven't really seen much of the quasi-religious fervour that you are speaking off within the Rust community. Indeed, the rust forums have quite a strong response against it; as well as good policies that are very welcoming to newcomers. When I was new to Rust, I found that very helpful.
I am amazed by the amount of discussion it seems to cause outside, with lots of people piling in, often with very vociferous arguments against. Well most of the r4l developers involved just carried on, I can see why the "cancer" argument irritated one person involved.
He is leaving in a huff, and many of his statements about the Rust issue haven't been very convincing to me. However, one of his points is, in my opinion, correct.
Linux has a problem with Rust. It will go better if they either decide that Rust is in it, and anyone who is unwilling to see Rust can feel free to leave or shut up, or that Rust is forbidden, and anyone who wants it in the kernel are free to leave or shut up. Right now, though, they have the situation where Rust is technically allowed, but when someone writes something in it, some others come around and try to stop it. This is guaranteed to annoy everyone involved. The Rust people see their work, which is often carefully written and tested, trashed by people who don't have a technical objection but just dislike the language. That is frustrating. The people who don't want Rust see an extra burden on them, sometimes supported by irritating ideological arguments and they don't know whether they can opt out of that or not. That is frustrating. While this argument continues, we can pretty much guarantee that everyone will get more frustrated and some of them will burn out as a result. The rest of the Linux community, including developers who are more indifferent and users, would all benefit if this didn't happen. I don't have a way of making it stop, but it would help if the developers could figure out such a way or, if they can't, for the people managing the project to try.
Hector tried to force Linus to make that decision. Linus did not like that. The handling of the situation was not great, at least the way it is represented in the media (and we don't have all the facts etc. and I'm not a kernel maintainer, and I'm not that great with writing in C). So, I guess we all lose. :(
Yes, he did, and it's the one thing he asked for that I think was reasonable. He made lots of comments there which I disagree with, including some personal attacks on people who oppose Rust which I thought were at best a bad idea. However, I think, for the reasons stated in my original comment, that continuing to have this fight every month or so when someone writes something in Rust and someone else gets annoyed because it is Rust is going to cause problems. Each time will add a little stress to some people, and if it happens often enough, those people are going to start reacting to that stress. We just lost one maintainer out of this. Maybe we think that doesn't matter; I'm not using Asahi anyway, and probably others will keep working on it, but do we want to keep rolling those dice? If you dislike Rust, this isn't good news for your side, because for all we know, an anti-Rust maintainer will be next to quit because they're annoyed that nobody is stopping the continued commits of more Rust into the kernel.
I don't know what Linus can do about this. He is unwilling to tell either side to stop at the moment, so maybe he thinks it will work out best if they eventually settle it among themselves. I have my doubts that this is going to happen that way. If anyone has an idea for how this could be mediated so we don't have long fights with personal attacks and insults regularly, I think it would be useful to try.
> It will go better if they either decide that Rust is in it, and anyone who is unwilling to see Rust can feel free to leave or shut up, or that Rust is forbidden, and anyone who wants it in the kernel are free to leave or shut up.
Technically it’s half in, which seems a good place for now. It’s in, but in a corner of its own, where it doesn’t hurt the C DMA code. They only want to know exactly what they are calling. As a C developer against the DMA ABI, I’d want to know that as well. So this seems reasonable.
Had Hector been more diplomatic – granted, hard when you’re fed up, but necessary – Linus might have given him hope that under certain conditions, he’d merge it anyway.
Except that Hector was not the person who wrote the code concerned and the discussion did not answer the question of whether it would be merged or not. The code concerned may still be merged, because the person who tried to stop it doesn't have the power to do that unilaterally. All Hector's involvement did was make several people angry because he insulted people who wanted to block the Rust contributions, Linus rebuked him for that, and he is now leaving. The leaving was probably not only about this incident, given that Hector has reacted similarly, if less extremely, to previous episodes of this long-running series of "people arguing about programming languages". This episode may still end, after we've all stopped paying attention, with the original code considered fine and merged over continued grumblings from the reviewer who didn't want it. Or, for that matter, it being merged to a massive explosion of anger from the same guy, it all depends. The latter would be problematic, and it's far from the only bad way this could end.
"Man doesn't get his way, leaves in a huff from the project, slamming the door and yelling gibberish on his way out. Film at 11..."
Developer has differences of opinion on the best approach forward with a major project, doesn't try to discuss the available options with other team members in a constructive manner but tries to force his way upon the others by calling for social media brigading, is told in no uncertain terms that that's not the way to do it, and then leaves in a huff from the project.
This is about much more than a man leaving in a huff.
As i understand it what was blocked was wrapping an API maintained by the kernel maintainers to allow access by rust. The argument that those rust bindings freezing the API is not a problem for the maintainer because the rust team would handle it is not convincing.
The "you break it you fix it" rule would be violated as the rust team would be in charge of fixing any breakage caused by an API change. Implicitely the rust team gains the power to delay or even nack any pull request that changes an API that has a rust binding any part of the kernel.
Most people underestimate the effort it takes to maintain a piece of code for the long term. I can understand that maintainers are not keen to depend on a team that has a high burnout rate and hasn't yet proved its resiliency by being around for a long time.
I think it's worth considering that the "you break it you fix it" rule is still a very distinct option here. Anyone who breaks the Rust is free to fix it too, they just have assurances that they can call on a Rust person to do it for them if they object to doing it themselves. The Rust team agreeing to fix things was intended as an olive branch to people who did not want Rust to be added because people didn't want to fix it if they broke it. Some of your comments are reasonable, but not all of them are the ones used by people attempting to stop the addition of Rust here.
>The Rust team agreeing to fix things was intended as an olive branch to people who did not want Rust to be added because people didn't want to fix it if they broke it.<
One side considers it to be a big olive branch and the other side considers it to be a small fig leaf over the 'maintainers would [not] have to learn how to do things in Rust' argument.
That seems to be a good illustration of the current issues around Rust in Linux.
I am not following the issue in any way, but I am sure of one thing : before you criticize someone, you need to be sure that you have the authority to do so.
Linus Torvalds has his faults, like everyone, but he has been exemplary in building a revolutionary open source OS and in managing its maintainance.
So, before you go mouthing off about how you don't appreciate how you've been treated, how's about you build something as significant and try to maintain it ?
Then you might see how difficult it is.
This reminds me of the book "birth of a new machine" where they detailed the messy and grueling development of a new computer to beat all other computers, with less resources to make it.
And they were conflicts and disagreements and clashes of personality. And burnouts etc. The leader of the project, Tom West, was seen as distant and unappreciative of the employees, though it is possible he was actually trying to act as a punching bag for the employees' feelings by staying that way.
But any case projects can be messy, at least based on that book. And a bad leader or management can hurt rather than help
I would happily donate monthly to a rust micro kernel project.
It would take a few years to get up and running, but once at a certain point everything would be so much easier - look at how fast the Asahi team got a GPU driver built.
Gotta start somewhere. Now who would be a good fit for the lead?
Here's a link to the donation page for Redox OS https://www.redox-os.org/donate/
> Redox is a Unix-like general-purpose microkernel-based operating system written in Rust, aiming to bring the innovations of Rust to a modern microkernel, a full set of programs and be a complete alternative to Linux and BSD.
I'm sure they would welcome your monthly donation.
Hector and Linus are not the same generation. If Hector would have started it's own kernel, it would have done it on Github with much discussions on social medias, not using raw git and mailing lists. He would have done it in Rust and not in C. He would have financed it with individual donations and not big companies backing. He would have done with youngsters and not old AIX devs. It would not have give Linux at all.
I sometime fail to communicate my opinion clearly with my parents even we speak the same language, I can understand that speaking Rust to a C person is even more difficult, but I gave long time ago that they'll changed one day to get the same interests than me.
Today, I fell like an obsolete adult when speaking with younger generations because their vision are not the same I grew with, and I perfectly understand (since I don't have many choices anyway) that they don't have any interest for some subject I found captivating at their age. And I personally don't have many interest to what they're finding thrilling today.
So yes, times are changing. Linux won't last forever and will one day retire just as Amiga OS, Solaris or Plan 9.
Linux is no longer the cool new kid in the block but the venerable guy that know too well and makes the world running.
Linux only speaks C because it the only language he knows and needs, and nobody could ever change that.
So Hector, just give up on this very idea, it's not a technical but a human characteristic, and move on another project where you can use the language, the tools and the ideas you want to fight for instead of bowing to old conventions. Both projects, Linux and your own, can exist in the world.
> He would have financed it with individual donations and not big companies backing
Linux did not get big companies' backing until it was successful enough that those companies were making use of it, even becoming reliant upon it. It started small and then grew. If Hector started his own project, yes, it would begin with individual donations - but as soon as it gained traction with large companies (i.e. was demonstrated to be, you know, useful), it would attract their donations.
> He would have done with youngsters and not old AIX devs
Hmm, let me just see - ah, yes, "a 21-year old Mr Torvalds has released a new kernel project". Of course, since then, even Linus is now "an old dev" (not sure about the AIX bit).
> will one day retire just as Amiga OS, Solaris or Plan 9
Hmm, Plan 9 never was mainstream (athough parts of it are in widespread daily use, e.g. if you use KVM/QEmu), Oracle quietly extends Solaris 11.4 support until 2037 but, ok, AmigaOS is only in the hands of the rabid fans now. But if Linux takes as long to get to that state, it'll outlive me at least!
> So Hector ... move on another project ... Both projects, Linux and your own, can exist in the world.
For Hector, at least, that does sound like a good idea. Unfortunately, from what we can see at the moment, he seems to be bereft of anything to move on to at the moment.
In 40 years of software development I've lost count of the number of times a small group of engineershave said it would be better to rewrite from scratch and start again. This Rust stuff feels like yet another example.
I guess one person's functional code is always gonna be another's technical debt.
> In 40 years of software development I've lost count of the number of times a small group of engineers have said it would be better to rewrite from scratch and start again.
And doesn't it also seem that, if only they had asked someone if their analysis of the extant code was correct, they could have so often had their misunderstanding quietly & calmly pointed out and saved all the bother of rewiting?
>> better to rewrite from scratch and start again ... I guess one person's functional code is always gonna be another's technical debt.
> Yes indeed. That is exactly how linux got started.
Is that the case? Exactly?
Torvalds has described how he started process switching code not because Minix wasn't good enough but because the discs were taking several months to arrive! What else was he going to spend the time doing?[1]. When Minix did arrive, he wasn't terribly pleased with it so from that point you could say he decided it needed to be rewritten - but then again, Minix was only open-sourced in 2000 - before then, even though you could buy a copy of the source to read and compile, plus a book to explain it all to you, it was still proprietary code: not that easy to fix it up and distribute the changes.
Perhaps if Torvalds's University course had used XINU and *its* book, instead of Minix, he might have directly patched that rather than "start again" (XINU was open source from the beginning, around 1984).
[1] ok, he admits he spent time playing video games as well!
Looks like the main beef is fairly well documented and the mini-spat with Linus is really just a side note.
Hector Martin approached his annoyances the wrong way and Linus pointed it out.
Linus may seem to be a real pussy cat sometimes, a super nice guy, but to continue to lead a project with such massive importance is no mean feat - you can't afford to pull ANY punches.
You have to keep everything in line and nip trouble in the bud before it starts.
I've seen this before. Linux by definition is powered by a herd of cats - anyone who wants to can get involved and they're going to bring their own preferences. But you can't build an OS that way. Torvalds is absolutely right here - it's better to do something imperfectly, but really well than perfectly and never get it finished or break every one else.
If Martin wants a Rust-based Linux, it's easy - make it. Find a group of Rust fans to help port the kernel to Rust. Prove that it's better. But Torvalds is acting as the gatekeeper to the one consistent and shared part of ALL Linuxes: the kernel.
Discuss.
I mean WTF does 'justice' have to do with software?
More people trying to bring political and social morality into what is fundamentally amoral engineering, just makes for bad engineering.
Following on a study that finds people will not date other people of opposite or different political persuasions, this has to be the last straw.
Hard to see what you point is here. Of course "justice" has something to do with software. If you take someone elses code and use it without their permission, you will find yourself on the wrong end of justice. I mean, if I steel the wheels of someones car to use for me own, "this is just engineering and is fundamentally amoral" is not going to get me far.
"...resigned from that effort early Friday, Japan Standard Time, citing developer burnout, demanding users, and Linus Torvalds's handling of the integration of Rust code into the open source kernel."
I'm convinced a huge percentage of people involve themselves in Linux solely to massage their fragile egos.
If you're making software, of course you're going to have demanding users. That's a given.
As for Torvalds...well he's a hazard of the job
I'm surprised to see some people on here referring to git and github in a way that suggests they don't realise the Linus wrote git.
Also Linus is a coder turned manager. He's had (and continues to have) very considerable experience in both worlds, and as far as I can see over all these years has done a pretty good job. How many others could say that?
Anon for obvious reasons.
Known a few commercial software products that had been around a while with commensurate technical debt.
Would always be differing opinions on how best to refactor - using different languages, totally reimplement some functionality from scratch, etc.
Often the most expedient / cost effective choice was made (not necessarily the best long term option) e.g. using languages that most of existing developers were unfamiliar with would often be vetoed due to learning curve and delays before devs productive in new language compared to using existing language(s) - plus chance some devs may "walk". Often in big, relatively high level projects, tend to get compromise workarounds such as making the code more based around API calls, and then various APIs can be re-implemented later.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
