27 ms·
Linus Torvalds on Rust support in kernel
- leugim 6y agoIs this excitement in Linus-lang?
- 1_player 6y agoMore like cautious optimism on his part.
- teknopaul 6y agoComing from C its a striking missing feature of rust. I still find it unnatural, and most of the code I write is Java, where the "what if" is replaced by allocation of project time for gc tuning. Rust's "don't think about allocs" when everything you do is dominated by memory ownership is wierd. Rust eradicates a whole class of memory related issues except "not enough". Panic is not necessarily safe/secure, that proc might be doing something important. Nofixilla take this approach too much, the assumption that no action is secure, what dies might be your burgler alarm. Fortunatly Linus prioritises working. I feel like his input will help the rust community.
- icy 6y agoHardly. He's reserving judgement.
- tgdn 6y agoI've got "Body for this message unavailable"
- busymom0 6y agoTry this archived version: https://archive.is/VpcHT https://archive.is/VpcHT
- nemetroid 6y agoPreviously discussed in https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26812047.
- deleted 6y ago[deleted]
- quietbritishjim 6y agoPrevious post about the RFC suggesting to add it is here [1]. This is Linus's reaction to that RFC. The top comment there also links to this email from Linus, and there's some interesting discussion there. [1] https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26812047
- brunoluiz 6y agoEvery time something like "Linus Torvalds on ..." pops up, I get curious if it will be an interesting explanation or a full Linus rage TM. This post is defo the former though (perhaps he is not raging anymore hehe). If you never saw one of his rage moments, take a look at: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75 and https://lkml.org/lkml/2013/7/13/132 https://lkml.org/lkml/2013/7/13/132
- bennysomething 6y agoThought he decided he was gonna try to be polite? I prefer the rage version. Less corporate email style
- noir_lord 6y agoBoth those posts are 8 or more years old. He has toned it down somewhat in recent years - still blunt but that's an admirable trait for a techie (note blunt !== rude).
- brunoluiz 6y agoIndeed, people change after so many years. It is good to see that now he is providing insightful explanations, without raging or anything. After all, he is the creator of Linux and his thoughts about its directions are always super valuable.
- azernik 6y agoIMO his rage posts usually still had great insightful points (cf "we do not break userspace"). The rage part was maybe unnecessary, but it wasn't the entire content of the emails.
- carlhjerpe 6y agoI like the Linus that shittalks NVIDIA, though i guess that's free NVIDIA markeing, which I really do not want them to have.
- 6y ago
- siscia 6y agoThe point is extremely valid. It has never been an issue in my use case of Rust, but the lack of an interface for when the system is out of memory is problematic. Not only in kernel, but in all system-level software. Then, it happens, less and less frequently, but still, I want to know and I want to be able to handle it.
- skohan 6y agoHaving this feature is one of the USP's of Zig isn't it?
- deleted 6y ago[deleted]
- volta83 6y agoThe problems are that: - most such interfaces do have a constant overhead that all programmers using the language have to pay. - some major operating systems (like Linux, ehem) make these interfaces useless for all their user space apps by enabling overcommit by default, which makes it hard/impossible to write portable code that can handle OOM Explicit OOM handling would mean that most users end up paying a relatively high upfront cost for something that in practice for them (e.g. if they are Linux programmers) delivers no value. For example, on Linux with overcommit (the default), even if the system is out of memory, malloc won't return null. It returns a pointer that's not null, such that your if(ptr == nullptr) will act as if everything is "ok", but then, when you try to read/write that memory, that will trigger a hardware exception, that the kernel will catch, and then the kernel will tell the OOM-killer to "make space" by killing "some process", and maybe your app is just killed, or some other app that your app is working with is killed leading to a race condition, or... or.... When your app is killed by the OOM killer, the signal that your app gets is "irrecoverable", which means that your app will die, you can at best try to do some cleanup before it does, but it will die nevertheless. So I find it extremely ironic for Linus to argue that practical programming languages are hard to use for environments that must handle OOM errors, when they are championing one of the major platforms that makes handling OOM useless by default. I keep saying this, but the obvious fix is for the Linux kernel to use overcommit internally just like they expect user space to do. When the kernel then runs out of memory, it should then start killing drivers at random to make for some space. If they think that's such a great default behavior, they should commit to it. \s
- GordonS 6y agoHmm, I would have thought that Rust produces standard ELF binaries that will run on Linux as-is. Could someone ELI5 why the kernel needs changes to support Rust?
- pta2002 6y agoThis is for writing kernel modules, which ideally need to be integrated in the kernel build system.
- ajb 6y agoBecause this is about allowing parts of the kernel itself to be written in rust.
- deleted 6y ago[deleted]
- dijit 6y agoMostly this is surrounding (as others have mentioned) writing kernel components, such as drivers, in Rust. Context on the post Linus says is: "If rust cannot report an error without aborting when it runs out of memory, then we can't use it". I have never written any rust code which does not abort when it runs out of memory, but I have never written for hardware (only with userland in mind) and my knowledge isn't that great anyway, so I'm not sure if it's possible or not.
- GordonS 6y agoAh, I didn't realise it was about writing bits of the kernel itself in Rust, now it makes sense, thanks!
- KirillPanov 6y agoAgreed. The whole panic situation is an awful mess that the Rust designers refuse to deal with. It's the sort of thing you put into a language when it's a toy, but Rust isn't a toy anymore and they refuse to do any of these: * remove it * make panics reliably "catch"-able 100% of the time like thrown exceptions (in languages with exceptions) * make it possible to statically check panic-safety, the way we check unsafe {} The dodge I always hear is "yeah but your code could always go off into an infinite loop, and we'll never be able to prevent or detect that". Okay, but nobody uses "while(1){}" as a deliberate response to an error condition. The Rust standard library is jammed full of code that will deliberately panic if tickled the wrong way. Look, I love Rust, but the denial around panic is just ridiculous. We need "might_panic" annotations, enforced exactly the way "unsafe" annotations are enforced, and the standard library needs to be updated to provide them. Bite the bullet. Linus is right. This should have happened years ago.
- salicideblock 6y agoHear hear! Here's to hoping that inclusion in the kernel will provide the motivation for addressing this in Rust. This is a point that may benefit from the new backing of Rust by the foundation - non-userspace was a side thing for Mozilla, but in Google and Amazon they have some core stuff depending on kernel.
- bitlevel 6y agoHere's to hoping it goes nowhere near the kernel until the Rust developers address it first, not the other way round.
- littlestymaar 6y agoThis comment is strongly missinformed: 1- panicking allocations are here to stay, because in lots of case, it's the most convenient behavior. BUT Rust is adding fallible allocations methods (prefixed with try_) which return a result instead of panicking on allocation failure. 2- panics are catch-able as long as you don't compile your binary with panic=abort setting (and as long as you don't panic in your panic handler itself (including in your types' destructor, which are called during stack unwinding)) 3- panics can only occur in specific places (array indexing, allocations, utf-8 validation, unwrap, etc.) which are by definition known at compile-time, and there's tooling to catch these up [1]. In practice, a might_panic annotation would add a lot of noise for pretty much everybody, because most of us mortals use panicking function all days and it's not a big deal. Obviously it is critical for Linux, but because it's relevant only to the minority of Rust users, it doesn't make sense to include it in rustc itself: it's exactly the kind of situation where external tooling is the good option. [1] https://github.com/Technolution/rustig https://github.com/Technolution/rustig
- j10c 6y agoAgree, kernel is responsible for managing all low level stuffs that we mostly take granted, it should not have an extra level of abstraction. I have read many mains of Linus where he specifically rants about the need of avoiding kernel panic, he specfically points what not to do in those mails. Certainly worth reading to understand this mail.
- joseluisq 6y agoYeah, worth reading. Even not being me a systems-developer stricto sensu, but Rust dev BTW. There are valuable sort of pro/cons standpoints about Rust RFC for the Kernel. And honestly I have learned many things. Hours well spent :). Just recomendable even if you like Rust or not.
- alexnewman 6y agoHow can he just be discovering this . Does he know rust at all?
- zibzab 6y agoMaybe he likes to get his facts right before presenting it to the world? Edit: according to other threads, this is part of an ongoing discussion on Rust feasibility for the kernel.
- teknopaul 6y agoshock someone who doesn't know rust. :) n.b. He states he does not.
- coldtea 6y agoWhy would he "know rust"? Did it become a requirement for being a dev that he somehow missed?
- aetherspawn 6y agoIt's a little haphazard to say that Rust is a requirement for being a [kernel] dev, when it is, as of yet, not actually merged into the main kernel due to conceptual flaws. Nor is it actually a major component in any kernel that makes up >1% market share AFAIK.
- coldtea 6y agoThat's my point too...
- jedimastert 6y agoProbably not. Why would he?
- gpm 6y agoThis also isn't a feature of rust, thankfully, just of the default libraries that the rust-kernel people are still using.
- gigatexal 6y agoLinus’s proposal for Result<T, E> seems a lot like the Golang approach to things where you almost always return a value and an error. I’m not a rust developer and a very weak go dev so take the above as you will.
- coldtea 6y agoThe Result<T, E> is actually Rust's aproach, which is a formal (better) version of Golang's approach. Better as in the result is standardized, and not ad-hoc like in Golang, and must be handled to use the value.
- pornel 6y agoIn Rust it's guaranteed that you never get both Ok and Err values at the same time (Result is a tagged union, not a tuple). In golang both are independent, and it's unclear whether you can or should use the ok value when err != nil. There are some interfaces that actually return both at the same time.
- coldtea 6y ago>In Rust it's guaranteed that you never get both Ok and Err values at the same time (Result is a tagged union, not a tuple). Yeah, that's the standardized part -- it's a tagged union. In Goland the second value might not even be an error, it's just a convention using the variadic return capabilities...
- joseluisq 6y agoYeah, I see `Result<T, E>` more solid in Rust than on-purpose Go error approach as you already mentioned and even more concise than `Exceptions` in other languages. BTW there are already interesting discussions around the topic if someone wants to have a look. https://news.ycombinator.com/item?id=25254737 https://news.ycombinator.com/item?id=25254737
- zidoo 6y agoI really miss old Linus - This email is way too long :). However, it is 100% on point.
- phoe-krk 6y agoThe title is slightly misleading, and so is Linus' response here. This RFC never claimed to be in shape to be immediately mergeable into the mainline kernel as-is. Miguel (the author of the patch) has replied to this mail (and in other places in the thread) that the Rust alloc() is currently called only as a temporary measure to speed up development, and all panic() calls from allocation failures are just as temporary. This is all because the Rust code that hooks into the kernel memory allocation functions is not yet usable. The main point of this RFC is that "the [in-kernel Rust] support is good enough that prototyping modules can start today." There's no point in making long arguments about alpha-quality design shortcuts on an alpha-quality prototype that are also explicitly mentioned by the patch authors to be of alpha quality. See e.g. https://lkml.org/lkml/2021/4/14/1130 https://lkml.org/lkml/2021/4/14/1130 and https://lkml.org/lkml/2021/4/14/1023 https://lkml.org/lkml/2021/4/14/1023 EDIT: Thanks for the child comments; it seems that Linus is simply not aware of all the specifics and is asking for more information and/or decided to look at the code before reading the full mail thread.
- caust1c 6y agoI don't really see anything misleading in the post. Linus says that the comments/responses are from a position of ignorance and it seems like he's just seeking understanding. If anything is misleading it's linking to random emails in lkml without context. :-P (Maybe that's what you were getting at). Personally, I'm very excited about Rust in the kernel.
- Ceezy 6y agoHe doesn't mention that it's an alpha feature
- CodeWriter23 6y agoThere are literally millions of things he didn’t say. He did however express a requirement for acceptance. That’s the message, if you want this in the kernel, it has to never call panic() at run time. Why? Because kernel crashes are unacceptable for the types of deployment Linux is used for.
- dncornholio 6y agoI get great value in a lot of comments from Linus. He can explain himself really well, even be an asshole at times, but I always feel he makes himself very understandable in a way that doesn't make me think he actually is one. He seems to have learned a lot in how to respond though, because this one is pretty tame :)
- bashinator 6y agoThis seems to be a non-issue? Torvalds has valid concerns, the patch submitter acknowledges those concerns and describes how they can and will be fixed before anything is merged.
- diegocg 6y agoWe are lucky that this is a link to the mailing list, and you can read the answers. Tech "journalists" read all mails from Linus and try to create click-baity articles from them, completely ignoring the context.
- davidgerard 6y agoIt's interesting tech stuff that's relevant to HN, it certainly caught my interest. There doesn't have to be a conflict for something to be a good HN submission.
- deleted 6y ago[deleted]
- andy_ppp 6y agoI’m not au fait with Rust or memory management or systems code to understand the issue here. Does anyone have a good explanation?
- steveklabnik 6y agoThe short explanation is, this code wasn't in its final form yet, but good enough to ask for a high level review of the code, the review came back "hey this looks okay overall but I have some questions about <details>" and the reply was "great! <details> is the work we haven't done yet; we'll get on that."
- andy_ppp 6y agoAh I understand that bit! I don’t understand why panicking if you run out of memory is a thing and or why it’s especially bad in kernel code...
- steveklabnik 6y agoAh okay. Rust's panics are used as the "I cannot recover from this error" mechanism. Most applications don't really properly handle OOM, and so this kind of error falls into the "I want my current thread to just die, thanks" style of error handling, hence a panic. That's bad in the kernel because you don't want the kernel to die, you do want to handle it and do something. The semi-ironic part here is that this behavior is the way that it is largely because of how the Linux userland works, where it's often tough to even tell that your system is is in a near-OOM or OOM state. Which is why applications rarely handle it, even if they theoretically could. Now, Rust itself has good support for these environments; I work on an embedded kernel, and we do no allocations at all. But what the kernel wants is where Rust is currently weakest in support; we have good support for "no allocations" and "panic on OOM or return Result on OOM" but not great support for "return Result on OOM and do not panic on OOM", and reasonably, the kernel would like the behavior they don't want to be impossible. That's the work that needs to be done.
- 6y ago
- de6u99er 6y agoThis was already shared yesterday. See top comment. https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26812047
- azernik 6y agoFrom a later email in the thread: > There's a philosophical point to be discussed here which you're skating > right over! Should rust-in-the-linux-kernel provide the same memory > allocation APIs as the rust-standard-library, or should it provide a Rusty > API to the standard-linux-memory-allocation APIs? Yeah, I think that the standard Rust API may simply not be acceptable inside the kernel, if it has similar behavior to the (completely broken) C++ "new" operator. Having done C++-in-the-kernel work, this is precisely right. That work required not only abandoning the C++ memory model, but also implementing a separate standard library that complied to kernel-space limitations/requirements.
- dralley 6y agoYou're skipping over all the emails that explain that it's not a fundamental limitation, many of the falliable allocation APIs already exist and many others have been in planning for a long time.
- azernik 6y agoI was referring to the C++ description as "precisely right". Though note from those emails that Rust-in-the-kernel will also require a rework of a lot of stdlib stuff, especially if they want to use the kernel allocator; it'll just be a LOT neater and more idiomatically-Rusty than the stuff I had to deal with, and will be much more compatible with off-the-shelf Rust libraries. And the developers of this Rust port repeatedly talk about removing panicking API calls from the library for kernel use, and adding extra non-panicking versions to the standard library. It's only that latter work that will likely make it into Rust upstream.
- ncmncm 6y agoYou can write bad code in any language. You can invent BS about any language. Linux kernel does not use glibc, why assume it would use the default generic application-level std lib for Rust, or for C++? FUD does not enlighten.
- scoutt 6y agoAside from Linus' reaction, there are some really interesting pearls in that thread, for example: Regarding code style[1]: > The more you make it look like (Kernel) C, the easier it is for us C people to actually read. My eyes have been reading C for almost 30 years by now, they have a lexer built in the optical nerve; reading something that looks vaguely like C but is definitely not C is an utterly painful experience. > You're asking to join us, not the other way around. I'm fine in a world without Rust. CoC was already brought into battle[2]: >> I could be mistaken but you seem angry. Perhaps it wouldn't be a bad idea to read your own code of conduct, I don't think you need a browser for that either. > Welcome to LKML. CoC does not forbid human emotions just yet. Deal with it. These ([3] [4]) messages have an interesting perspective about maintenance. > I'm sure about one thing, the C bugs we have today will be fixable in 20 years. I'm not even sure the Rust code we'll merge today will still be compilable in 10 years nor will support the relevant architectures available by then, and probably this code will have to be rewritten in C to become maintained again. Linus wants to see a real, working kernel driver instead of Android Binder[5]: >Would there be some kind of real driver or something that people could use as a example of a real piece of code that actually does something meaningful? [1] https://lkml.org/lkml/2021/4/16/118 https://lkml.org/lkml/2021/4/16/118 [2] https://lkml.org/lkml/2021/4/16/143 https://lkml.org/lkml/2021/4/16/143 [3] https://lkml.org/lkml/2021/4/16/181 https://lkml.org/lkml/2021/4/16/181 [4] https://lkml.org/lkml/2021/4/16/283 https://lkml.org/lkml/2021/4/16/283 [5] https://lkml.org/lkml/2021/4/14/1091 https://lkml.org/lkml/2021/4/14/1091
- wycy 6y ago> The more you make it look like (Kernel) C, the easier it is for us C people to actually read. My eyes have been reading C for almost 30 years by now, they have a lexer built in the optical nerve; reading something that looks vaguely like C but is definitely not C is an utterly painful experience. I think he makes a good point about the fact that it's certainly possible the Rust code written today won't still compile in 10 years, but writing Rust in C-style seems like a terrible approach. Write using the idioms of the language used.
- alfonsodev 6y ago
- flazzarino 6y agoThe ultimate memory safety PL is rejected because it cannot malloc without blowing up?
- steveklabnik 6y agoIt has not yet been rejected. The review is vaguely positive. Like any pull request, there has been some feedback, which will now be addressed.
- Communitivity 6y agoWhat I would love to see is Rust in the kernel, with a caveat. That caveat is something akin to Erlang's OTP supervision trees. Erlang has a similar philosophy to Rust in that if something erroneous happens the process fails. The difference is that Erlang OTP is designed to have supervisor processes of the worker processes. The only thing the supervisors do is monitor the processes under them and control when, if, and how those processes are restarted on failure or other conditions. The supervisors themselves have supervisors, right up to the root supervisor for each Erlang application. Rust got the language and the tooling perfect, but Erlang got the services and service infrastructure perfect. The more I think about it the more I think I should shut up and put up. In other words, apply my knowledge of Erlang and OTP to create a gen_server in Rust as a jumping off point for a OTP like Rust framework, perhaps called OARS (Open Advanced Rust Services). This is definitely bigger than one person. If you'd like to join me on this journey then reply to this comment and I'll send you project details by the end of the weekend.
- ta988 6y agoI don't know enough Rust and Erlang for helping with that, but that definitively sounds great. What would you use for IPC?
- gpm 6y agoI don't really know much about erlang, but I think this may be along the lines of what you are thinking of: https://github.com/bastion-rs/bastion https://github.com/bastion-rs/bastion (I also don't really think the linux kernel people would be interested...)
- weakfish 6y agoIf you don't mind a student rust enthusiast, I would love to take a crack at this. Email is john123allison AT gmail DOT com
- asabil 6y agoI would love to see the same thing, I always told people around me that Erlang/OTP is more akin to an OS than a traditional programming language. That being said, the key feature to enable what Erlang supports is asynchronous termination, which as far as I know is not possible in regular Rust.
- davidhyde 6y agoIn the embedded Rust world it is common to explicitly define a custom global allocator and panic handler. The global allocator is even optional although you then won't be able to use heap allocated structs like String and Vec. Therefore the Rust compiler does not force you to use the built in allocator or panic handler and you are free to implement them how you choose. See for alloc: https://docs.rust-embedded.org/book/collections/index.html https://docs.rust-embedded.org/book/collections/index.html See for panicking: https://docs.rust-embedded.org/book/start/panicking.html https://docs.rust-embedded.org/book/start/panicking.html
- steveklabnik 6y agoThis code is using that allocator, that's part of the issue. He wants there to be no panics, not to have the panics handled in a special way.
- davidhyde 6y agoI see, so anything that can possibly fail should return a result instead of "maybe" panicking as a side effect? So no panics at all in the language? That may adversely affect the ergonomics of the language for user space applications. Perhaps it would be better to build a completely fallible version of the standard library and use linting to enforce no panics.
- steveklabnik 6y agoAt the very least, no panics for allocations. Methods that return Result exist, the issue is that while they do, the panic-ing ones also exist. There are plans to address this, they just haven't been implemented yet.
- davidhyde 6y agoThanks, interesting to hear!
- jononor 6y ago
- seodisparate 6y agoRedox-OS has a similar situation that kernel code should never panic https://gitlab.redox-os.org/redox-os/redox/blob/master/CONTRIBUTING.md#kernel https://gitlab.redox-os.org/redox-os/redox/blob/master/CONTR... . No possible panics should ever exist in kernel space, because then the whole OS would just stop working. Note that Redox-OS is written completely in Rust.
- mixedCase 6y agoI see in that document the mention of a libredox as a libstd replacement, I'm guessing that means they have their own primitives with constructors that handle allocation failures?
- TheCraiggers 6y agoThis is the first time I've ever seen this usage of NAK. I'm used to the ACK/NAK jargon, but this one is new to me. I can figure this one out by context I think, but I find the new usage interesting. Can anyone shed light on how exactly he's using it here, and the reasons why you think that?
- mixedCase 6y agoAs a synonym of "rejected as invalid", for that is the information conveyed by a NAK response.
- deleted 6y ago[deleted]
- KingOfCoders 6y agoA Rust noob. But isn't allocation done with e.g. String::from("abc")? I wouldn't want to have an API there.
- The_rationalist 6y agoAre there discussion about java/kotlin kernel support through Graal Native? That would have too à great value proposition
- ilaksh 6y agoThey will probably solve the panic issue. However, it is strange to me that no one is explicitly mentioning the fundamental underlying tension here between C and Rust. Rust is a reaction to the lack of safety inherent in languages like C. Rust is an opportunity to really evolve operating systems forward. That's why projects like Redox OS have more promise in the long term for me than dragging the Linux community to Rust.
- deleted 6y ago[deleted]
- flakiness 6y agoWe should pay more attention to this rust-on-linux project than this specific thread. It's a treasure trove. The first email of the thread is good introduction: https://lkml.org/lkml/2021/4/14/1023 https://lkml.org/lkml/2021/4/14/1023 The code: https://github.com/Rust-for-Linux/linux/tree/rust/rust/kernel https://github.com/Rust-for-Linux/linux/tree/rust/rust/kerne... Very cool!
- mcguire 6y agoLinus' comments are surprising to me. First, I would have thought that Rust is far too much like C++ for him. :-) Second, he seems remarkably calm about the very idea of a compiler inserting memory allocations in kernel code. He's only talking about panics. It's been a long time since I was involved in any kernel code, but invisible allocations would have set me (and any kernel programmers I knew) off worse than the worst rant anyone has ever seen from Linus. Any kind of invisible things (destructors, anyone?) would.
- gpm 6y ago> but invisible allocations would have set me (and any kernel programmers I knew) off worse than the worst rant anyone has ever seen from Linus Reading tea leaves here, but I think he's calm about this because he's pretty sure it's not happening (Which it isn't)
- paavohtl 6y agoRust doesn't have invisible allocations. The compiler doesn't even know what an allocation is.
- mcguire 6y ago"So if the Rust compiler causes hidden allocations that cannot be caught and returned as errors, then I seriously think that this whole approach needs to be entirely NAK'ed, and the Rust infrastructure - whether at the compiler level or in the kernel wrappers - needs more work." So Linus is worried about nothing?
- paavohtl 6y agoYes, basically. The Rust standard library has data structures and functions which require memory allocation, and _will_ panic on allocation failure. But the allocating subset of the standard library is a separate module, which is usually turned off in embedded or kernel-level code. The current prototype uses it to speed up development, but the long term plan as far as I understand is to replace it or augment the current implementation to support fallible allocation (which is being worked on anyway).
- drummer 6y agoThis whole effort to bring rust into Linux kernal should be killed with fire asap before it's too late.
- andrewmcwatters 6y ago> Also, I'm a bit worried about long-term survival of the new language-of-the-day-that-makes-you-look-cool-at-beer-events. I was once told perl would replace C everywhere. Does someone use it outside of checkpatch.pl anymore ? Then I was told that C was dead because PHP was appearing everywhere. I've even seen (slow) log processors written with it. Now PHP seems to only be a WAF-selling argument. Then Ruby was "safe" and would rule them all. Safe as its tab[-1] which crashed the interpreter. Anyone heard of it recently ? Then Python, whose 2.7 is still present on a lot of systems because the forced transition to 3 broke tons of code. Will there ever be a 4 after this sore experience ? Then JS, Rust, Go, Zig and I don't know what. What I'm noting is that such languages appear, serve a purpose well, have their moment of fame, last a decade and disappear except at a few enthousiasts. C has been there for 50 years and served as the basis of many newer languages so it's still well understood. I'm sure about one thing, the C bugs we have today will be fixable in 20 years. I'm not even sure the Rust code we'll merge today will still be compilable in 10 years nor will support the relevant architectures available by then, and probably this code will have to be rewritten in C to become maintained again.[1] [1]: https://lkml.org/lkml/2021/4/16/283 https://lkml.org/lkml/2021/4/16/283
- lenkite 6y agoLinux should stick to C. If Rust is still around in 20 years, then it can be chosen as a mainstream kernel programming language for Linux. Google Fuchsia's Zircon kernel chose to use C++ over Rust over stability concerns. Best to have an independent cleanroom kernel implementation where Rust can prove itself.
- philippeb8 6y agoPeople think Rust is the savior, while the truth is you can still have dangling pointers by returning references from functions. Fornux C++ Superset is the way to go. Thanks.