They've really listed all the hurdles, the largest one being mentioned last: :-)
"The Rust support was merged in v6.1 into mainline in order to help determine whether Rust as a language was suitable for the kernel, i.e. worth the tradeoffs, technically, procedurally and socially.
To be fair, they had valid technical arguments... at the start. It's just they were all debated and overruled quite quickly and objectors weren't left with any valid technical arguments to fall back on.
Rust-in-Linux has been a pretty big driver for the Rust project to improve. Solving all the pain points Linux encountered has been a huge focus for the last few releases. Turns out having a high-level adopter like this is a great motivation to just clean up the needless bikeshedding.
I haven’t followed the kernel world for a long time and don’t know much about the internals or the “politics” anymore, but honest question, why wasn’t C++ ever used or adopted? I don’t get why rust has been a candidate for a long time, but C++ hasn’t (unsafeness and all of that aside)
When you do a cost/benefit analysis, c++ just doesn't seem enough of an advantage to justify switching; But rust does.
Sure, they are both complex languages, and it's probably fair to say that rust is even more complex than c++. But the guarantees you get in return are well worth it.
Programming in rust is an interesting experience. Once the code compiles, it tends to just work. You might still have logic bugs, but whole other classes of bugs are eliminated. You are essentially front loading a huge amount of debugging before it even compiles. The actual programming might take longer for rust code, but you tend to save on debugging time.
This is also a massive advantage for code review. As long the bindings (which wrap all the unsafe calls to existing c code) are correct, any new code that just calls those bindings is guaranteed to be free of many types of bugs. Simply check the code compiles, doesn't have any unsafe blocks; And that's a large chunk of code review done for free, by the compiler.
I don't really think C++ would offer any benefit for the Linux kernel (debate me on this if you want). With Rust we get memory safety and improvements in language design after 50 years of research on the issues we've had with C/C++. And with C we get code that can be mapped quite closely to raw instructions. It is easy to create unreadable C++ code that is hard to understand (especially at an instruction level) as a result of misusing abstractions, so I can understand how this would be bad for kernel development. Also I think Linus actually has tried C++ with the Subsurface project, he didn't really like it...
I have been away from compiled low level languages for a good 7 years by now because work and research, and I don’t really know much about rust apart from what people proposed as advantages when it started and from back around that time (which seem to be the same now tbh, security vs C/C++, etc). I think I remember reading why Linus didn’t like C++. Either way, my knowledge of rust isn’t deep enough to compare vs what I know of C++ (very rusty on this too).
Also C++ has evolved an insurmountable amount since the last std I used, 17, but the thing about C++ is that it basically (used to be..) “almost” a superset of C, so you can almost code in pure C and it was supposed to compile with g++. Also you can go as heavy on abstraction, template, OOP, or whatever as you want. Also C++ has safe(r) features nowadays from what I’ve heard, but I guess not to the low level of rust.
I really don’t know tbh. Was just curious about why rust and not C++.
(My answer is very non-answer lol, sorry about that)
There are others that are extremely opposing against rust in the kernel without any technical arguments.
With technical arguments. Rust is more complex and harder to learn than C, and mixing two very different programming languages always causes additional issues, not only by doubling the required learning, but also interoperability issues between the parts written in different languages. (For the last argument: They have already had issues with some C interfaces apparently not being suitable for Rust bindings, and the Rust maintainers' change requests to those interfaces being rejected by the C maintainers.) The Rust proponents just do not care about those arguments.
Pretty funny comment from someone who uses a distro that forced their users out of a tried and tested utils package to something new written in Rust, throwing a couple of CVEs and performance issues along the way…
Do as I say not as I do?
I for one find it positive that Rust landed in the kernel. It’s not a “let’s rewrite it all”, it’s a “glad new stuff is going to be better than what we can achieve with C”.
The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only "about a year away" from disallowing new drivers written in C and requiring the use of Rust.
Anyone worried about systems not supported by LLVM / EOL architectures etc: Please keep in mind that the quote is about new graphics drivers, which are … not something legacy systems need worry about.
Debian have recently announced a "Hard Rust requirement" starting from May, so it seems we nearing the end of generic linux distros on platforms without viable rust tools.
With Debian taking the plunge, I'm not actually sure how much longer linux itself will avoid a hard rust requirement. I doubt it will last 5 years.
So while sticking your head in the sand might still be working for now, it's not viable in the long term. If your platform doesn't have a viable Rust toolchain, you need to either be working towards one, or doing EOL planning.
Git has decided to start using/requiring it too, so yeah, seems like mainstream Linux distros will be dependent on having a working Rust toolchain in the near future.
I guess the fact that nobody has made an Alpha CPU in like 20 years means nobody has been motivated enough to maintain an LLVM backend.
That arch died fast. At one of my first jobs, they were already buying second hand AlphaStations off eBay in 2008 just to keep their system running while the port to x86 linux was completed.
It‘s nice to see Rust getting traction. Love that language. Was on an Embedded convention lately and they are also trying to adapt Rust where it makes sense.
tl;dr is Rust's type system is different from any other mainstream language. It's called an "affine type system" which basically means that values are treated as resource, like in the real world.
In the real world, if I have a book and I give it to you, I no longer have the book. I cannot even attempt to write it in.
This is how Rust works as well - if you have an instance of a Book type and pass it to a function, then the function now "owns" the book. Any attempt to use or reference the book after you pass it to the function is a compile time error.
In other languages, it would still be available and would let you use the book.
It's brilliant since it's such a simple change to the way programming language works and solves so many problems, not just memory safety ones. It's actually great for general purpose programs too.
In addition to checking that you don't access other peoples books, the borrow checking is also making sure that no one else is looking at the book when you write on it and that no one has loaned out the book when you decide to throw it out.
tl;dr is Rust's type system is different from any other mainstream language.
I think Scala 3, Swift and Haskell can probably be considered mainstream and they all have linear/affine stuff in them. But much like rust none of them are true affine type systems anyway. They are all sub-structural hybrids.
Both Copy and &mut T break the purity of the system.
It's called an "affine type system" which basically means that values are treated as resource, like in the real world.
In the real world, if I have a book and I give it to you, I no longer have the book. I cannot even attempt to write it in.
This is how Rust works as well - if you have an instance of a Book type and pass it to a function, then the function now "owns" the book. Any attempt to use or reference the book after you pass it to the function is a compile time error.
I don't think this is necessarily great way to describe affine type system. What you are describing is more about move-semantics which are closely related obviously, but should not be conflated.
It doesn't hurt, but the way C, C++ and Rust do it are all somewhat different, and you should be able to learn it from Rust. Being familiar with some language in the ML family, or something generally similar, like Haskell, F# or LINQ also helps. Rust has a lot of ML behaviour dressed up in curly braces and semicolons.
More specifically:
Indirection:
C relies extensively on pointers
C++ offers pointers and a bunch of reference types
Rust relies mainly on references and offers "raw pointers" behind unsafe
Memory management:
C relies on manual malloc and free
C++ can do manual memory, but also leans pretty heavily on RAII
Rust is all-in on RAII
Style:
C is generally "simple" or "small" and leans towards an imperative style
C++ is pretty complex and offers OOP and a bunch of paradigms
Rust has objects but not inheritance, Hindley-Milner-ish type inference, algebraic data types, structural pattern matching, leans towards traits/typeclasses for generics, all of which might sound familiar to users of something vaguely in the ML family.
All in all, if you're interested in Rust, you should just go for that. Learning one language to learn another is generally never a required detour.
They didn't "solve the memory management conundrum", it really only makes a particular set of memory bugs impossible, by checking lifetime constraints statically (i.e. at compile-time).
There are many parts of the "memory management conundrum", so to say, that Rust doesn't solve and doesn't attempt to solve, because it only really cares about the safety aspects.
I think part of why Rust has ended up getting so much hate is the fact people always imply that Rust solves all memory problems and it doesn't, never claimed to and never even tried to do so. I wish people were more realistic and pragmatic about the language, as someone that really enjoys using Rust but is tired of both the baseless incessant whining from the C folks and the baseless evangelism from a certain set of the Rust folks.
I wasn't trying to make a point, just intrigued. Why are the C folks whining? Solving even a fraction of the memory difficulties is better than nothing. I never used C professionally, but even my sandboxy learning projects were difficult to track once they grew in size and complexity.
In the beginning maintainers were concerned about maintenance burden increasing for code they didn't understand. ie. "Is my code going to be stalled because I refactored a C API broke some Rust assumptions?" In time most have realized that C is still the first class citizen, and Rust breakages are the responsibility of "the Rust people". Although it probably is true that the maintenance burden increased depending on the subsystem, it certainly didn't as much as some were expecting.
Then some refactoring had to be done to accomodate Rust's more explicit lifetime management, but a large amount would've probably been due sometime or other anyways. If anything, the refactor debacle showed why having a loose set of contraints spread around in a dozen or so peoples' heads is a bad idea, although for many it was a case of the annoying middleground between "this is obvious for a human but incredibly difficult to encode for Rust".
FFI is always a pain wrt building. The situation is much better now than then, but C's platform support is still (naturally) wider than Rust's, so IIRC some more obscure (sorry) platforms had their support reduced.
Also note that the type of person driven to maintain a kernel subsystem probably also tends to be more conservative than most (EDIT: in the traditional sense). This pays off a lot (hooray for no C++ in the kernel!), but in this situation many dismissed Rust as yet another "miracle" language that will come and go. At the time this was completely justified given how soon it was after 1.0 and how young Rust's support for the kernel was, but it's come a long way a decade later (EDIT: and definitely still has a long way to go still in all fairness)
That makes sense, every large organization needs to strike a balance between sclerosis vs. jumping onto every new thing and building a Babel tower. Now that you've pointed it out, it's easy to understand where they come from. I've been chided for the same reasons when I started working as a junior dev. I wanted to refactor everything.
I think a somewhat fairer description would be that the C purists are whining. The kernel devs who have been writing in C but want an alternative can also be described as C folks.
At some level we can see a split between
the people who want to work on the kernel to solve some problem, who are comfortable with C, but might also be fine with or even prefer some other language, and
the people who want to work on the kernel because that lets them write C, and even ignore other languages.
People get hung up on programming languages sometimes and treat it like a team sport. That includes C fans.
I mean there some things that rust cant do but c can(of course without using unsafe) its also a harder language. So i can understand why they dont want change. But in other hand its better than nothing that c provides in terms of memory protection
Unsafe is part of the language so it doesn't make sense to ignore it. The entire C language is even more unsafe than using unsafe functions in Rust. Types and references still have thread boundary and borrow checks in unsafe scopes and functions. Even the inline assembly syntax in Rust explicitly annotates registers for compiler checks in the assembly. There's really nothing C can do that Rust can't also do.
Thats what i said?? Even if we use unsafe in part of our code, the other part is in safe. So at the very lleast we have some safety measures that c doesnt have
Your first sentence declares that there are things that Rust can't do that C can. Dismissing a good chunk of language features that are labeled unsafe. It shouldn't matter if an operation is labeled as unsafe or not. It can do everything C does.
Unsafe simply means that the programmer will exercise caution in upholding the soundness guarantees of the compiler when using an unsafe function. All of the compile-time checks for memory and thread safety, as well as runtime bounds checks on slices, still apply in unsafe scopes to types and references. Whereas in C, everything is unsafe with none of those checks.
There's really nothing C can do that Rust can't also do.
So why re-invent the wheel then? I'm all for it, if it is used where appropriate, but unfortunately it is often made out to be the solution to all worldly problems, which just isn't the case. It just seems like you could just as well write C in safe mode instead of throwing everything away and rewrite in Rust. Being realistic with expectations and limitations. Seen this too many times when new stuff comes along. Starts off great, bloats and gets reinvented again and things suffer along the way. True revolution and success stories don't come along often, so I do hope Rust is one of them even if it's not my cup of tea.
Did you read that backwards? There is no "safe mode" for C (unless you add pointer capabilities and GC a la Fil-C, but that comes with huge unnecessary overhead for a kernel). Provable safe C at compile time requires the same kind of extra annotations as Rust or formal proofs, so Rust isn't "re-inventing" the wheel here, it brings tangible benefits.
Read it again. You missed the point completely. Rust can do everything that C can, and it does it better than C. And by logical conclusion, Rust can do many things that C is incapable of supporting. It is not held back by the antiquated standards of C from half a century ago .Also, there's no such thing as safe C.
Because all the tricks learned over decades to deal with C might not be needed anymore and they are back to “beginner” status if they program in Rust. Ergo buster.
What other memory problems are you hearing from Rust folks that it solves? The main thing I hear people mistakenly claim it solves is memory leaks, but that claim is usually from beginners.
I think for example the idea that ghost (implicit) allocations are problematic is basically never even considered by lot of rust evangelist, but that's something which the language constantly forces you into... Naively written C and C++ have this same exact problem as well (I would argue it feels 10x worse in C because at-least in C++ you can somewhat reason about it).
Rust's type system is about memory safety. Implicit allocations isnt related to that. I've never heard Rust folks claim anything about it not making implicit allocations.
But that's complete motte & bailey, rust evangelist always claim three things:
That rust fixes memory management
That rust enforces correctness
That rust enforces optimality
Implicit allocations are parts of both 1 and 3, and I would argue in some circumstances even 2... Like the memory leak argument is another demonstration of the exact same phenomena, you are fully bought into rust and even you notice it, because that claim is omnipresent, even-though it's on it's face stupid and you can cyclically Rc<RefCell> yourself to your hearts content.
People wouldn't be so hostile to rust evangelists if they claimed "Rust is a language that enforces aliasing and lifetime invariants at compile time" instead of "Rust is a language that fixes memory management in holistic sense".
Rust developers have been saying that it enforces ownership, aliasing XOR mutability, and thread boundary send+sync constraints at compile-time since day one. In addition to automatically adding bounds checks at runtime. The only people ascribing additional meaning to that are those who dislike Rust (the anti-Rust cult), and they need to strawman arguments like these to justify their irrational position.
Implicit memory allocation is not an issue. You can easily avoid implicit allocation if you really want to. Use with_capacity, clear, push, fill, truncate, etc. But in most cases it isn't necessary. This also forgets that the system allocator is already pooling allocations on behalf of the process, whether you use explicit or implicit allocations. So most of those implicit allocations are already being pooled for reuse with little overhead. The standard library's allocation strategy uses optimal buffer sizes that best utilize malloc's memory pooling behaviors too. Where multiples of 4 are the most common buffer requests.
I would even argue that implicitness being the default for the standard library is the best choice for practical reasons. As the vast majority of software is already efficient enough that tenability and readability are far more important. Most app developers coming from a language with runtime garbage collection don't need this to hinder their adoption of the language either. If a hot path needs it, they can easily opt into that.
If you think you have a problem that benefits from more hands on explicit allocation than what the standard library provides through methods on buffer types, you can select from arenas and pools like generational-arena and slotmap. There are allocation strategies like bumpalo (which often provide stable Allocator APIs). There's also the Allocator trait from the standard library on a nightly build.
Rc and Arc are used sparingly in day to day Rust code, but the documentation is very explicit about how to use these types correctly, as well as what memory safety means. Cyclic references are still memory safe. The memory is not corrupted or invalid, and accessing that memory won't cause UB or soundness issues. A cyclic reference has similar behaviors as leaking memory on the heap to create a static reference, but again I've not seen much real world code using it to that extent. Self-referential types are often seen as an anti-pattern. So this is more of a hypothetical issue than a practical concern. Regardless, the memory is still valid, it simply has a static lifetime and will always exist. Let's not stretch the definition of correctness in this context of memory safety to mean something else.
Rust developers have been saying that it enforces ownership, aliasing XOR mutability, and thread boundary send+sync constraints at compile-time since day one. In addition to automatically adding bounds checks at runtime.
And according to the commenter I originally replied to, they also claim rust prevents leaks.
The only people ascribing additional meaning to that are those who dislike Rust (the anti-Rust cult), and they need to strawman arguments like these to justify their irrational position.
"Rust allows us to build correct and bug free software" is literally what the rust survey has as a top response for "why rust?", the top response is not about memory safety or security, but about "correctness"...
Implicit memory allocation is not an issue. You can easily avoid implicit allocation if you really want to. Use with_capacity, clear, push, fill, truncate, etc. But in most cases it isn't necessary.
Well how does your method solve my issue in an environment where there is no system allocator? Like free standing and RT is what I care about, and everything you recommend is worthless in that scenario.
It also kinda proves my original point... Once I said implicit allocation is problematic for me, I had rust evangelist show up and claim that it's actually not an issue.
Rc and Arc are used sparingly in day to day Rust code, but the documentation is very explicit about how to use these types correctly, as well as what memory safety means.
I didn't say anything in opposition to any of this (tho I think "used sparingly" is maybe underestimating how much you actually see them). I just said that claiming that leaks are impossible in rust is stupid because stuff like cyclic references involving Rc can trivially leak.
Self-referential types are often seen as an anti-pattern.
Self-referential types are often seen as an anti-pattern in the rust community, because the language is horrible at dealing with them.
So this is more of a hypothetical issue than a practical concern.
I mean I have shot myself in the foot this way when working with bunch of graph structures in rust, so it's completely practical concern.
They do not completely solve that problem. I have to use more Rust apps (almost all the Rust apps that I use are for development), but the first and most used Rust app by me was Neovide, and I experienced a frequent crash related to a memory leak that is inherent to Neovide itself. So to me is a little funny that the first rust app that I used, the major crash is about memory leak.
Memory leaks aren't a safety issue. You cannot cause undefined behavior by leaking memory.
Rust does not claim to solve memory leaks (in fact, they're explicitly supported), though they should only happen in rare circumstances (such as reference count loops).
I disagree. It offers much better safety, so as a user I prefer it to be used because my stack will be less likely to contain security issues or crashes
It's a programming language. By itself it doesn't do anything, it's just a way to write code. What's cool about it is it applies the 40 years of type system research that's been done since C was created to give programmers a much more expressive way of conveying the structures of their code in a precise, mathematical way. This in turn allows computers to do static analysis to discover logical inconsistencies and contradictions, as well as a much richer context from which to infer unambiguously the meaning of code, freeing programmers from having to add that context themselves.
It just means the code doesn't have keep reminding the compiler of what type of object you're dealing with all the time, or tell it that when you're allocating an object you want the allocation to be the size of the object etc.
It's a programming language that eliminates entire classes of critical bugs which are common in C. More Rust means a safer OS, and easier for newcomers to pick up and contribute to.
It's a programming language that eliminates entire classes of critical bugs which are common in C. More Rust means a safer OS, and easier for newcomers to pick up and contribute to.
Honestly, in the current generative AI landscape I am no longer sure that googling will actually give a more complete answer. Too much crap and misinformation to wade through.
Can’t wait till gccrs is released and able to compile the Linux Rust code. It will be good for Rust to have more than one compiler maturing the language and ecosystem and allowing for just one compiler to build the whole kernel. It will also open up Rust to more platforms.
i will never in a million years understand why rust has become such a social football, such a thing for people to argue over. and it's both sides: both the rust evangelists as well as the people arguing against it. like, rust is fine, maybe it's the successor to C, that'd be cool, but it's not going to change the world and good lord people have to stop making such a big deal out of it lmao.
Imagine you have 15 years of experience coding in C. A lot of it translates, a lot of it doesn't.
Now imagine you are a fresh blooded developer arriving in the arena, you pick up Rust because it seems like the future. You want the job that the first guy has.
You can see why the first person may be defensive and why the second one may hype up rust a little too much.
my personal issue with the rustaceans is that they seem to have this idea that because "rust is memory safe" that's just enough to justify experimental rewrites of core software and that headlong rush is what i don't understand. i'm all for using rust -- some of my favorite desktop apps are mostly written in rust -- but i just really hate this idea that "just rewrite it in rust" is enough to fix any given problem.
Imagine you have 15 years of experience coding in C. A lot of it translates, a lot of it doesn't.
Now imagine you are a fresh blooded developer arriving in the arena, you pick up Rust because it seems like the future. You want the job that the first guy has.
Let's hope it doesn't go the way of so many other hyped things into bloatware, re-invention and obscurity. The Rust space already has enough projects being abandoned and never finished and changes to the language already got some folks say they don't approve. Seen it too many times not to find that trend worrying. Maybe being in the kernel will adjust that onto the right track, hopefully.
Please show us the back doors you've discovered via source code audit. Surely you must have seen these back doors or else you wouldn't be posting about them, right? Nobody would just lie on the internet, right?
Wow you work so hard for them. Yes, to feel save is the most healthy way of living. But you end up being the most miserable warmonger country in the world for too many decades. And now you are becoming a dictatorship with all your trust in it. Awesome!
I have no prove, and no knowledge to find them. But makes people doubt about it, because in my opinion, you, and anyone should doubt about any recommendation of the fbi, and the gov. And maybe people with that knowledge can get their hands on it.
I don’t give a F about what bothers you about my comments anyway.
What makes you think I'm bothered by your comments? All I did was ask for proof of your extraordinary claim. When you're trying to convince other people of something like this you need some sort of information you can point to that suggests you're not lying.
I could say that nobody should trust you because I strongly suspect you torture puppies for fun. I have no evidence of you doing this, but that doesn't matter. You're a sadistic puppy torturer. Do you see the problem?
You are comparing me, an average person with no power, to one of the most powerful organizations of the one if not the number one warmonger country of the world. Make it make sense. And my "extraordinary claim" is just a two words comment, that triggers too many of you, as I can see.
Binary blobs? Last time i checked it was super hard to bootstrap rustc with an open toolchain you just used an older version of rustc most of the time to iteratively upgrade over. Pretty much the sale as most C++ compilers but the point is there.
considering that some of the "old guys" you mentioned are the ones who pushed it, including the "second in command" of the kernel.. not sure why you'd say that. Someone trusted enough to take the place of Linus and maintainer of the stable kernel branch!
Exactly, is not in the main kernel, so what is your point?
Someone TRIED to add it long time ago, and that was a big drama fest.
You can read some main extract here: https://harmful.cat-v.org/software/c++/linus
But feel free to go on the mailing list and read all the drama around d it to have a better idea.
Not as big as the rust one, but just because it did not go nearly as far :)
You can clearly map time and tendencies, and probably you can connect dots following prev knowledge, CoCing many opensourse projects and sudden Emking of the communities - that were real things (and still is, but in a way smaller scale). Was RS hype a coincidence? I dunno, but suspiciously the same time that happened...
Hm. I never said Rust is a bad prog lang, I'm writing on it maybe half of my working time and that is fine, that is a tool that works awesome in many cases. But I do not understand the "rewrite-in-rust" phenomenon which many community members are sick of... the additional spicy aspect is I never saw "such ppl" rewritten something that is not working or working bad, instead the only good working things are considered for RiR... that's sad, because it's not practical and is not efficient...
how many of these "community members" are actual programmers? How many of of them get a say of how others who actually run the projects spend their time. None of those people get to tell somebody else if they are wasting their time. That's just how open source works.
It is only actually annoying and bad in the cases where projects who don't ever want to use rust keep being bothered about rewriting it in rust.
yeah, quite a colorful one, black and white, red and yellow, new and old , young and mature, - and everything and everyone is respected. You know, like in books...
Will you elaborate on what you think SJW and cancel culture is and how that applies to a programming language being adopted in the Linux kernel? Without explanation that just sounds like you went a little too far down a conspiracy rabbit-hole.
I do think/hope that with ai assistant coding, rust-ificiation of linux will be a lot faster than otherwise. Such fast transformation could be very good for the future of linux distros.
That's why I am on Windows 10 LTC IoT now, Rust doesn't support many architectures like C does and that will be a chaos to support such devices if somebody look at Debian apt that will have rust as a hard dependency, many architectures will be dropped from Debian to fit rust.
That's a non-sequitur. Windows 10 LTSC only supports x64 and ARM64. Both have very good support with Rust, so I'm not sure what Windows has to do with anything here.
If your big concern is support of odd-ball architectures, switch to a BSD.
They've really listed all the hurdles, the largest one being mentioned last: :-)
Torvaldsially.
Linus is pretty open to rust.
There are others that are extremely opposing against rust in the kernel without any technical arguments.
Just read some messages in this thread. That are the kind of people meant there.
To be fair, they had valid technical arguments... at the start. It's just they were all debated and overruled quite quickly and objectors weren't left with any valid technical arguments to fall back on.
Rust-in-Linux has been a pretty big driver for the Rust project to improve. Solving all the pain points Linux encountered has been a huge focus for the last few releases. Turns out having a high-level adopter like this is a great motivation to just clean up the needless bikeshedding.
I haven’t followed the kernel world for a long time and don’t know much about the internals or the “politics” anymore, but honest question, why wasn’t C++ ever used or adopted? I don’t get why rust has been a candidate for a long time, but C++ hasn’t (unsafeness and all of that aside)
When you do a cost/benefit analysis, c++ just doesn't seem enough of an advantage to justify switching; But rust does.
Sure, they are both complex languages, and it's probably fair to say that rust is even more complex than c++. But the guarantees you get in return are well worth it.
Programming in rust is an interesting experience. Once the code compiles, it tends to just work. You might still have logic bugs, but whole other classes of bugs are eliminated. You are essentially front loading a huge amount of debugging before it even compiles. The actual programming might take longer for rust code, but you tend to save on debugging time.
This is also a massive advantage for code review. As long the bindings (which wrap all the unsafe calls to existing c code) are correct, any new code that just calls those bindings is guaranteed to be free of many types of bugs. Simply check the code compiles, doesn't have any
unsafeblocks; And that's a large chunk of code review done for free, by the compiler.Fair enough! Thanks for the answer
I don't really think C++ would offer any benefit for the Linux kernel (debate me on this if you want). With Rust we get memory safety and improvements in language design after 50 years of research on the issues we've had with C/C++. And with C we get code that can be mapped quite closely to raw instructions. It is easy to create unreadable C++ code that is hard to understand (especially at an instruction level) as a result of misusing abstractions, so I can understand how this would be bad for kernel development. Also I think Linus actually has tried C++ with the Subsurface project, he didn't really like it...
I have been away from compiled low level languages for a good 7 years by now because work and research, and I don’t really know much about rust apart from what people proposed as advantages when it started and from back around that time (which seem to be the same now tbh, security vs C/C++, etc). I think I remember reading why Linus didn’t like C++. Either way, my knowledge of rust isn’t deep enough to compare vs what I know of C++ (very rusty on this too).
Also C++ has evolved an insurmountable amount since the last std I used, 17, but the thing about C++ is that it basically (used to be..) “almost” a superset of C, so you can almost code in pure C and it was supposed to compile with g++. Also you can go as heavy on abstraction, template, OOP, or whatever as you want. Also C++ has safe(r) features nowadays from what I’ve heard, but I guess not to the low level of rust.
I really don’t know tbh. Was just curious about why rust and not C++.
(My answer is very non-answer lol, sorry about that)
This is what i hate about these Rust morons, very divisive, dodges and ignores any valid technical criticism.
What’s the valid criticism then?
read story about plan of implementing rust in cpython, and how it will affect gentoo
With technical arguments. Rust is more complex and harder to learn than C, and mixing two very different programming languages always causes additional issues, not only by doubling the required learning, but also interoperability issues between the parts written in different languages. (For the last argument: They have already had issues with some C interfaces apparently not being suitable for Rust bindings, and the Rust maintainers' change requests to those interfaces being rejected by the C maintainers.) The Rust proponents just do not care about those arguments.
Torvalds was the biggest voice corralling the nay sayers into submission.
Next milestone: Go in the kernel! If it's good enough for Rob Pike and Ken Thomson, surely it's good enough for Linus Torvalds.
Stay mad.
I know that is this a joke, but Go will never be in the kernel since it dependes on a Garbage collector AFAIK
That's why I wrote my whole OS in perl!
Pretty funny comment from someone who uses a distro that forced their users out of a tried and tested utils package to something new written in Rust, throwing a couple of CVEs and performance issues along the way…
Do as I say not as I do?
I for one find it positive that Rust landed in the kernel. It’s not a “let’s rewrite it all”, it’s a “glad new stuff is going to be better than what we can achieve with C”.
Linus actually slapped people against Rust
It's nice that it's going so well, but also perhaps not all that surprising. Something more curious was shared on a subscriber LWN post shared with /r/rust:
Anyone worried about systems not supported by LLVM / EOL architectures etc: Please keep in mind that the quote is about new graphics drivers, which are … not something legacy systems need worry about.
Debian have recently announced a "Hard Rust requirement" starting from May, so it seems we nearing the end of generic linux distros on platforms without viable rust tools.
With Debian taking the plunge, I'm not actually sure how much longer linux itself will avoid a hard rust requirement. I doubt it will last 5 years.
So while sticking your head in the sand might still be working for now, it's not viable in the long term. If your platform doesn't have a viable Rust toolchain, you need to either be working towards one, or doing EOL planning.
Git has decided to start using/requiring it too, so yeah, seems like mainstream Linux distros will be dependent on having a working Rust toolchain in the near future.
LLVM is really finishing off any possibility of keeping my Alpha running
That's a shame.
I guess the fact that nobody has made an Alpha CPU in like 20 years means nobody has been motivated enough to maintain an LLVM backend.
That arch died fast. At one of my first jobs, they were already buying second hand AlphaStations off eBay in 2008 just to keep their system running while the port to x86 linux was completed.
GCCrs is getting close it may be ready for next year making all those compiler complaints mute.
Very awesome but why did they choose that picture in the article? It looks nothing like rust, and more like Tux got shitted on.
Well, programmers are famously good at graphic design. It has "graphic design is my passion" all over it
i cant unsee it now why have you done this
So in other words it's very fitting.
What about this does not fit?
the shit parts
It‘s nice to see Rust getting traction. Love that language. Was on an Embedded convention lately and they are also trying to adapt Rust where it makes sense.
New linux user here: What's rust and what does it do?
Its just programming language, like C. From user perspective you don't need to think more about it, this is just for developers.
I low-key want to learn it just so I can understand how on Earth they managed to solve the memory management conundrum...
tl;dr is Rust's type system is different from any other mainstream language. It's called an "affine type system" which basically means that values are treated as resource, like in the real world.
In the real world, if I have a book and I give it to you, I no longer have the book. I cannot even attempt to write it in.
This is how Rust works as well - if you have an instance of a Book type and pass it to a function, then the function now "owns" the book. Any attempt to use or reference the book after you pass it to the function is a compile time error.
In other languages, it would still be available and would let you use the book.
It's brilliant since it's such a simple change to the way programming language works and solves so many problems, not just memory safety ones. It's actually great for general purpose programs too.
Huh, that's a great metaphor for borrow checking.
In addition to checking that you don't access other peoples books, the borrow checking is also making sure that no one else is looking at the book when you write on it and that no one has loaned out the book when you decide to throw it out.
I think Scala 3, Swift and Haskell can probably be considered mainstream and they all have linear/affine stuff in them. But much like rust none of them are true affine type systems anyway. They are all sub-structural hybrids.
Both
Copyand&mut Tbreak the purity of the system.I don't think this is necessarily great way to describe affine type system. What you are describing is more about move-semantics which are closely related obviously, but should not be conflated.
The standard recommendation for people wanting to learn Rust is the official Rust book + the rustlings exercises.
Is it recommended to understand C and memory management before diving into rust?
It doesn't hurt, but the way C, C++ and Rust do it are all somewhat different, and you should be able to learn it from Rust. Being familiar with some language in the ML family, or something generally similar, like Haskell, F# or LINQ also helps. Rust has a lot of ML behaviour dressed up in curly braces and semicolons.
More specifically:
unsafemallocandfreeAll in all, if you're interested in Rust, you should just go for that. Learning one language to learn another is generally never a required detour.
It isn't necessary. I learned C after Rust, and I think that was a better choice.
Awesome, thank you. I needed this to push me to dive straight into Rust.
They didn't "solve the memory management conundrum", it really only makes a particular set of memory bugs impossible, by checking lifetime constraints statically (i.e. at compile-time).
There are many parts of the "memory management conundrum", so to say, that Rust doesn't solve and doesn't attempt to solve, because it only really cares about the safety aspects.
I think part of why Rust has ended up getting so much hate is the fact people always imply that Rust solves all memory problems and it doesn't, never claimed to and never even tried to do so. I wish people were more realistic and pragmatic about the language, as someone that really enjoys using Rust but is tired of both the baseless incessant whining from the C folks and the baseless evangelism from a certain set of the Rust folks.
I wasn't trying to make a point, just intrigued. Why are the C folks whining? Solving even a fraction of the memory difficulties is better than nothing. I never used C professionally, but even my sandboxy learning projects were difficult to track once they grew in size and complexity.
In the beginning maintainers were concerned about maintenance burden increasing for code they didn't understand. ie. "Is my code going to be stalled because I refactored a C API broke some Rust assumptions?" In time most have realized that C is still the first class citizen, and Rust breakages are the responsibility of "the Rust people". Although it probably is true that the maintenance burden increased depending on the subsystem, it certainly didn't as much as some were expecting.
Then some refactoring had to be done to accomodate Rust's more explicit lifetime management, but a large amount would've probably been due sometime or other anyways. If anything, the refactor debacle showed why having a loose set of contraints spread around in a dozen or so peoples' heads is a bad idea, although for many it was a case of the annoying middleground between "this is obvious for a human but incredibly difficult to encode for Rust".
FFI is always a pain wrt building. The situation is much better now than then, but C's platform support is still (naturally) wider than Rust's, so IIRC some more obscure (sorry) platforms had their support reduced.
Also note that the type of person driven to maintain a kernel subsystem probably also tends to be more conservative than most (EDIT: in the traditional sense). This pays off a lot (hooray for no C++ in the kernel!), but in this situation many dismissed Rust as yet another "miracle" language that will come and go. At the time this was completely justified given how soon it was after 1.0 and how young Rust's support for the kernel was, but it's come a long way a decade later (EDIT: and definitely still has a long way to go still in all fairness)
That makes sense, every large organization needs to strike a balance between sclerosis vs. jumping onto every new thing and building a Babel tower. Now that you've pointed it out, it's easy to understand where they come from. I've been chided for the same reasons when I started working as a junior dev. I wanted to refactor everything.
I think a somewhat fairer description would be that the C purists are whining. The kernel devs who have been writing in C but want an alternative can also be described as C folks.
At some level we can see a split between
People get hung up on programming languages sometimes and treat it like a team sport. That includes C fans.
Change is scary.
I mean there some things that rust cant do but c can(of course without using unsafe) its also a harder language. So i can understand why they dont want change. But in other hand its better than nothing that c provides in terms of memory protection
Unsafe is part of the language so it doesn't make sense to ignore it. The entire C language is even more unsafe than using unsafe functions in Rust. Types and references still have thread boundary and borrow checks in unsafe scopes and functions. Even the inline assembly syntax in Rust explicitly annotates registers for compiler checks in the assembly. There's really nothing C can do that Rust can't also do.
Thats what i said?? Even if we use unsafe in part of our code, the other part is in safe. So at the very lleast we have some safety measures that c doesnt have
Your first sentence declares that there are things that Rust can't do that C can. Dismissing a good chunk of language features that are labeled unsafe. It shouldn't matter if an operation is labeled as unsafe or not. It can do everything C does.
Unsafe simply means that the programmer will exercise caution in upholding the soundness guarantees of the compiler when using an unsafe function. All of the compile-time checks for memory and thread safety, as well as runtime bounds checks on slices, still apply in unsafe scopes to types and references. Whereas in C, everything is unsafe with none of those checks.
So why re-invent the wheel then? I'm all for it, if it is used where appropriate, but unfortunately it is often made out to be the solution to all worldly problems, which just isn't the case. It just seems like you could just as well write C in safe mode instead of throwing everything away and rewrite in Rust. Being realistic with expectations and limitations. Seen this too many times when new stuff comes along. Starts off great, bloats and gets reinvented again and things suffer along the way. True revolution and success stories don't come along often, so I do hope Rust is one of them even if it's not my cup of tea.
Did you read that backwards? There is no "safe mode" for C (unless you add pointer capabilities and GC a la Fil-C, but that comes with huge unnecessary overhead for a kernel). Provable safe C at compile time requires the same kind of extra annotations as Rust or formal proofs, so Rust isn't "re-inventing" the wheel here, it brings tangible benefits.
Read it again. You missed the point completely. Rust can do everything that C can, and it does it better than C. And by logical conclusion, Rust can do many things that C is incapable of supporting. It is not held back by the antiquated standards of C from half a century ago .Also, there's no such thing as safe C.
That condition seems like a joke. Rust can do the same thing, unless you deliberately prevent it?
And if you have to choose between C with no protection and rust with protection in everything or almost everything, I think the winner is obvious.
Because all the tricks learned over decades to deal with C might not be needed anymore and they are back to “beginner” status if they program in Rust. Ergo buster.
What other memory problems are you hearing from Rust folks that it solves? The main thing I hear people mistakenly claim it solves is memory leaks, but that claim is usually from beginners.
I think for example the idea that ghost (implicit) allocations are problematic is basically never even considered by lot of rust evangelist, but that's something which the language constantly forces you into... Naively written C and C++ have this same exact problem as well (I would argue it feels 10x worse in C because at-least in C++ you can somewhat reason about it).
But that's complete motte & bailey, rust evangelist always claim three things:
Implicit allocations are parts of both 1 and 3, and I would argue in some circumstances even 2... Like the memory leak argument is another demonstration of the exact same phenomena, you are fully bought into rust and even you notice it, because that claim is omnipresent, even-though it's on it's face stupid and you can cyclically
Rc<RefCell>yourself to your hearts content.People wouldn't be so hostile to rust evangelists if they claimed "Rust is a language that enforces aliasing and lifetime invariants at compile time" instead of "Rust is a language that fixes memory management in holistic sense".
Rust developers have been saying that it enforces ownership, aliasing XOR mutability, and thread boundary send+sync constraints at compile-time since day one. In addition to automatically adding bounds checks at runtime. The only people ascribing additional meaning to that are those who dislike Rust (the anti-Rust cult), and they need to strawman arguments like these to justify their irrational position.
Implicit memory allocation is not an issue. You can easily avoid implicit allocation if you really want to. Use
with_capacity,clear,push,fill,truncate, etc. But in most cases it isn't necessary. This also forgets that the system allocator is already pooling allocations on behalf of the process, whether you use explicit or implicit allocations. So most of those implicit allocations are already being pooled for reuse with little overhead. The standard library's allocation strategy uses optimal buffer sizes that best utilize malloc's memory pooling behaviors too. Where multiples of 4 are the most common buffer requests.I would even argue that implicitness being the default for the standard library is the best choice for practical reasons. As the vast majority of software is already efficient enough that tenability and readability are far more important. Most app developers coming from a language with runtime garbage collection don't need this to hinder their adoption of the language either. If a hot path needs it, they can easily opt into that.
If you think you have a problem that benefits from more hands on explicit allocation than what the standard library provides through methods on buffer types, you can select from arenas and pools like generational-arena and slotmap. There are allocation strategies like bumpalo (which often provide stable Allocator APIs). There's also the Allocator trait from the standard library on a nightly build.
Rc and Arc are used sparingly in day to day Rust code, but the documentation is very explicit about how to use these types correctly, as well as what memory safety means. Cyclic references are still memory safe. The memory is not corrupted or invalid, and accessing that memory won't cause UB or soundness issues. A cyclic reference has similar behaviors as leaking memory on the heap to create a static reference, but again I've not seen much real world code using it to that extent. Self-referential types are often seen as an anti-pattern. So this is more of a hypothetical issue than a practical concern. Regardless, the memory is still valid, it simply has a static lifetime and will always exist. Let's not stretch the definition of correctness in this context of memory safety to mean something else.
And according to the commenter I originally replied to, they also claim rust prevents leaks.
"Rust allows us to build correct and bug free software" is literally what the rust survey has as a top response for "why rust?", the top response is not about memory safety or security, but about "correctness"...
Well how does your method solve my issue in an environment where there is no system allocator? Like free standing and RT is what I care about, and everything you recommend is worthless in that scenario.
It also kinda proves my original point... Once I said implicit allocation is problematic for me, I had rust evangelist show up and claim that it's actually not an issue.
I didn't say anything in opposition to any of this (tho I think "used sparingly" is maybe underestimating how much you actually see them). I just said that claiming that leaks are impossible in rust is stupid because stuff like cyclic references involving
Rccan trivially leak.Self-referential types are often seen as an anti-pattern in the rust community, because the language is horrible at dealing with them.
I mean I have shot myself in the foot this way when working with bunch of graph structures in rust, so it's completely practical concern.
They do not completely solve that problem. I have to use more Rust apps (almost all the Rust apps that I use are for development), but the first and most used Rust app by me was Neovide, and I experienced a frequent crash related to a memory leak that is inherent to Neovide itself. So to me is a little funny that the first rust app that I used, the major crash is about memory leak.
Memory leaks aren't a safety issue. You cannot cause undefined behavior by leaking memory.
Rust does not claim to solve memory leaks (in fact, they're explicitly supported), though they should only happen in rare circumstances (such as reference count loops).
I disagree. It offers much better safety, so as a user I prefer it to be used because my stack will be less likely to contain security issues or crashes
It's a programming language. By itself it doesn't do anything, it's just a way to write code. What's cool about it is it applies the 40 years of type system research that's been done since C was created to give programmers a much more expressive way of conveying the structures of their code in a precise, mathematical way. This in turn allows computers to do static analysis to discover logical inconsistencies and contradictions, as well as a much richer context from which to infer unambiguously the meaning of code, freeing programmers from having to add that context themselves.
Wait... Infer unambiguously the meaning of code??? Can it infer the meaning of life too??
Can't you?
To write more Rust?
It just means the code doesn't have keep reminding the compiler of what type of object you're dealing with all the time, or tell it that when you're allocating an object you want the allocation to be the size of the object etc.
I didn't need this explanation because I was just being pithy, but thank you.
It's a programming language that eliminates entire classes of critical bugs which are common in C. More Rust means a safer OS, and easier for newcomers to pick up and contribute to.
thanks for the low key sane response
How abt googling would get you a more complete answer
Honestly, in the current generative AI landscape I am no longer sure that googling will actually give a more complete answer. Too much crap and misinformation to wade through.
Rust is a programming language that's a lot better than the current standard: C.
There are a couple people who really really don't like change. So, they also hate Rust.
As a user, you won't notice anything.
This response is as needlessly hostile, unhelpful, and pretentious as the people who say the same about rust...
its a programming language that adopted and discarded features based on compromise between familiarity and correctness.
Can’t wait till gccrs is released and able to compile the Linux Rust code. It will be good for Rust to have more than one compiler maturing the language and ecosystem and allowing for just one compiler to build the whole kernel. It will also open up Rust to more platforms.
Good
Rustaceans rejoice
i will never in a million years understand why rust has become such a social football, such a thing for people to argue over. and it's both sides: both the rust evangelists as well as the people arguing against it. like, rust is fine, maybe it's the successor to C, that'd be cool, but it's not going to change the world and good lord people have to stop making such a big deal out of it lmao.
It's pretty simple.
Imagine you have 15 years of experience coding in C. A lot of it translates, a lot of it doesn't.
Now imagine you are a fresh blooded developer arriving in the arena, you pick up Rust because it seems like the future. You want the job that the first guy has.
You can see why the first person may be defensive and why the second one may hype up rust a little too much.
Additionally, deranged internet trolls.
Spot-on
my personal issue with the rustaceans is that they seem to have this idea that because "rust is memory safe" that's just enough to justify experimental rewrites of core software and that headlong rush is what i don't understand. i'm all for using rust -- some of my favorite desktop apps are mostly written in rust -- but i just really hate this idea that "just rewrite it in rust" is enough to fix any given problem.
Imagine you have 15 years of experience coding in C. A lot of it translates, a lot of it doesn't.
Now imagine you are a fresh blooded developer arriving in the arena, you pick up Rust because it seems like the future. You want the job that the first guy has.
Yeah you're right but every piece of software is an opinionated implementation of an idea, you'll always get people fighting :D
Ah dang, I thought the video game 'rust' was finally gonna allow Linux users on the regular server for a second. Still cool, I guess
Let's hope it doesn't go the way of so many other hyped things into bloatware, re-invention and obscurity. The Rust space already has enough projects being abandoned and never finished and changes to the language already got some folks say they don't approve. Seen it too many times not to find that trend worrying. Maybe being in the kernel will adjust that onto the right track, hopefully.
every language will have this, and C has plenty of this. That's just the nature of active ecosystems.
Work to do in the language upstream? It's either ready or not, what do they mean by this?
It's ready enough to be used, but there are still improvements to be made, e.g. stabilising features.
FBI happy
Terry Davis has died but his cause lives on
???
Don't mind the schizoposters. You might have seen them blowing their gasket about pipewire, systemd or wayland in the past.
The FBI has been arguing for memory safe languages like rust to increase security, so the “FBI happy” statement might be true.
Yeah, but increased security benefits everyone, and good luck to them putting a back door in an open source project.
The back doors are a necessity for “national security concerns”.
Please show us the back doors you've discovered via source code audit. Surely you must have seen these back doors or else you wouldn't be posting about them, right? Nobody would just lie on the internet, right?
[deleted]
See you in Valhalla brother
Wow you work so hard for them. Yes, to feel save is the most healthy way of living. But you end up being the most miserable warmonger country in the world for too many decades. And now you are becoming a dictatorship with all your trust in it. Awesome!
[deleted]
And fbi
[deleted]
Are you sure it is against all logic and reasoning? Or it has a history that can make you at least doubt about them?
Cause I don’t really care that much, it was a comment on the fly that escalated to this, but honestly I doubt about the bastards a lot.
I have no prove, and no knowledge to find them. But makes people doubt about it, because in my opinion, you, and anyone should doubt about any recommendation of the fbi, and the gov. And maybe people with that knowledge can get their hands on it. I don’t give a F about what bothers you about my comments anyway.
[deleted]
Yeah, exactly, you are so smart!
What makes you think I'm bothered by your comments? All I did was ask for proof of your extraordinary claim. When you're trying to convince other people of something like this you need some sort of information you can point to that suggests you're not lying.
I could say that nobody should trust you because I strongly suspect you torture puppies for fun. I have no evidence of you doing this, but that doesn't matter. You're a sadistic puppy torturer. Do you see the problem?
You are comparing me, an average person with no power, to one of the most powerful organizations of the one if not the number one warmonger country of the world. Make it make sense. And my "extraordinary claim" is just a two words comment, that triggers too many of you, as I can see.
Do you have any sources for this, other than Lunduke? I mean, real evidence.
I like how Lunduke was the first thing to come to mind after reading the original comment, it's almost always Lunduke spreading this
What the fuck is lunduke lol
Why would they be happy about fewer exploitable memory bugs, use after frees, out of bound reads and writes, etc?
The struggle to stay relevant and keep fighting ghosts is real.
[deleted]
a Trojan horse for what? are they sneaking in programming socks or something?
Binary blobs? Last time i checked it was super hard to bootstrap rustc with an open toolchain you just used an older version of rustc most of the time to iteratively upgrade over. Pretty much the sale as most C++ compilers but the point is there.
considering that some of the "old guys" you mentioned are the ones who pushed it, including the "second in command" of the kernel.. not sure why you'd say that. Someone trusted enough to take the place of Linus and maintainer of the stable kernel branch!
You clearly know nothing about this issue at all.
Are you saying then there is an issue?
Yes, a few developer madre a big fusa about it.
But is more if a social issue than a technical one.
Exactly, that's exactly what I'm saying, somehow rust brought social issues instead of technical ones... that's sad...
Any new language would have bring in those very issue, so dont worry about it.
c++, python, ruby, c#, swift kotlin, go, - none of them did...
Because none of them got put in the kernel.
And C++ did even without be in the kernel, when reject by torwalds xD
cpp is actually being used in proprietary drivers. And there is no requests to add drivers-pp framework right into the kernel...
Exactly, is not in the main kernel, so what is your point?
Someone TRIED to add it long time ago, and that was a big drama fest.
You can read some main extract here: https://harmful.cat-v.org/software/c++/linus But feel free to go on the mailing list and read all the drama around d it to have a better idea.
Not as big as the rust one, but just because it did not go nearly as far :)
[deleted]
You can clearly map time and tendencies, and probably you can connect dots following prev knowledge, CoCing many opensourse projects and sudden Emking of the communities - that were real things (and still is, but in a way smaller scale). Was RS hype a coincidence? I dunno, but suspiciously the same time that happened...
rust started 13 years ago and reached 1.0 10 year ago! 10 years! It was organic growth for 10 years.
You are just making this up.
Hm. I never said Rust is a bad prog lang, I'm writing on it maybe half of my working time and that is fine, that is a tool that works awesome in many cases. But I do not understand the "rewrite-in-rust" phenomenon which many community members are sick of... the additional spicy aspect is I never saw "such ppl" rewritten something that is not working or working bad, instead the only good working things are considered for RiR... that's sad, because it's not practical and is not efficient...
how many of these "community members" are actual programmers? How many of of them get a say of how others who actually run the projects spend their time. None of those people get to tell somebody else if they are wasting their time. That's just how open source works.
It is only actually annoying and bad in the cases where projects who don't ever want to use rust keep being bothered about rewriting it in rust.
Hahahaha I love it when you guys somehow call it cancel culture to use a specific programming language.
Your worldview must be very... interesting.
yeah, quite a colorful one, black and white, red and yellow, new and old , young and mature, - and everything and everyone is respected. You know, like in books...
Will you elaborate on what you think SJW and cancel culture is and how that applies to a programming language being adopted in the Linux kernel? Without explanation that just sounds like you went a little too far down a conspiracy rabbit-hole.
Jesus, I wasn't even this delusional during my actual psychosis.
Take your meds.
You know nothing about this.
You know nothing about this AND that...
I do think/hope that with ai assistant coding, rust-ificiation of linux will be a lot faster than otherwise. Such fast transformation could be very good for the future of linux distros.
Oh, you're a consultant somewhere, aren't you?
Oh, no, I do not want AI code in the kernel unless it's been heavily vetted, which kind of defeats the extra speed.
That's why I am on Windows 10 LTC IoT now, Rust doesn't support many architectures like C does and that will be a chaos to support such devices if somebody look at Debian apt that will have rust as a hard dependency, many architectures will be dropped from Debian to fit rust.
Which unsupported architectures do you actually care about?
They have to be a troll. Their solution for loss of exotic architectures is to switch to an operating system that only supports x86 and ARM...
Yeah, that's what I suspect too
the ones that don't run even windows 10.. so it makes no sense.
you do know that the windows kernel has rust in it too right? Probably even before windows 10 was EOL.
That's a non-sequitur. Windows 10 LTSC only supports x64 and ARM64. Both have very good support with Rust, so I'm not sure what Windows has to do with anything here.
If your big concern is support of odd-ball architectures, switch to a BSD.
You are so clueless
Can you list the architectures W10 IoT supports? Can you list the architectures that will lose debian support?