13 ms·

Rust heads into the kernel?

170 points by h1x 5y ago

nynx 5y ago
More discussions about whether ownership can be tacked onto another language.
matheusmoreira 5y ago
It's gonna be interesting to see how it will affect the kernel ABIs. High level languages have features that produce nightmarish binary interfaces and it's unrealistic to believe existing code will be able to interface with them. So will the code be restricted to a minimalist subset of Rust?
- nynx 5y ago
  Rust can easily produce C compatible symbols.
  - matheusmoreira 5y ago
    Yes, but the benefits of Rust won't extend beyond those symbols. Also, certain features of Rust that have no C equivalents cannot be exported. Will the gains in safety be contained entirely inside the modules that are written in Rust?
    - nynx 5y ago
      Yes.
    - Flex247A 5y ago
      From my experience, absolutely.
    - oconnor663 5y ago
      > certain features of Rust that have no C equivalents cannot be exported Right, only "repr(C)" types can show up in "extern" APIs. So no data-bearing enums, no Vec<T>, etc. > Will the gains in safety be contained entirely inside the modules that are written in Rust? I think for some things the answer is yes, and for other things the answer is no. If the issue is that callers might retain some pointer or descriptor longer than they should, leading to a use-after-free or something like that, then there's probably no way to fix that with an API-compatible Rust reimplementation. What safe Rust would prefer to do is either 1) force explicit lifetime constraints on the caller or 2) replace the pointer/reference with some sort of smart pointer, which can either keep its referent alive or at least safely detect the fact that the referent is dead. But of course a C-compatible API has no way to represent (1), and (2) would presumably be an incompatible API change, so the Rust reimplementation can't really solve this issue. (Though if both Rust and C APIs get exposed for the new code, then new Rust callers could benefit from (1).) On the other hand, if the issue is that the caller might pass in some invalid indexes or other metadata, leading to an out-of-bounds array access within the module, Rust can help quite a bit. If the array in question is actually owned by the module (and not just a raw pointer to unknown memory) then bounds checking is required one way or another (unless it's either optimized away or explicitly skipped with unsafe code), and a Rust reimplementation will probably not suffer from out-of-bounds issues. Raw pointers into the caller's memory are harder to check, but even there if they can be converted to a safe slice immediately inside the API boundary, some subset of out-of-bounds accesses can still be caught. Looking at these two different kinds of bugs, I think it's interesting to think about what "inside the module" means here. In both cases, the UB we want to prevent (either use-after-free, or an out-of-bounds access) is "caused" by the caller's mistakes outside the module, but "occurs" on lines of code inside the module. In the first case, Rust can't protect itself against a bad (C) caller, but in the second case it might be able to.
- geofft 5y ago
  The kernel, fortunately, already doesn't want to have a public ABI. https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://www.kernel.org/doc/Documentation/process/stable-api-... The primary goal is to write in-tree drivers in Rust, which can still be loadable modules, but they'll be built to whatever ABI that particular version of the kernel uses. And even for out-of-tree modules, you have to recompile them against the specific kernel and ideally with the same version of the compiler etc.; ABI incompatibilities across C compilers are rare, but not unheard of.
the_duke 5y ago
Linux will definitely need a very curated setup to reap the full benefits of idiomatic Rust. Right now both alloc/std and even basic language constructs like indexing into a slice can panic. With little help from the tooling to guard against it. This makes sense when considering that Rust evolved as a language for writing somewhat higher level applications like browsers. While Rust and especially the library ecosystem is generally great at forcing you to handle application domain error conditions, that mostly doesn't extend to these lower-level concerns. But I'm hopeful that this can improve the entire ecosystem over the medium term. With things like lints that forbid panics, more focus on custom allocators and fallible allocations in std and the library ecosystem, etc. edit: just to clarify on the slice index panicking: my point isn't that the C situation is better, but that a big reason for moving to Rust would be to benefit of a safer, more convenient language that doesn't require such extreme carefulness as C. So the language should help in preventing panics, or making it obvious where they can occur. This is perfectly possible in Rust by using accessors that return `Option<T>` or iterators. But the tooling for such use cases can be improved, for example with lints, and the API surface can be customized to mostly prevent such conditions with the type system.
- nynx 5y ago
  A rising tide lifts all boats! I'm really looking forward to the improvements that come to the rust ecosystem from integration into Linux.
- wyldfire 5y ago
  > Right now both alloc/std and even basic language constructs like indexing into a slice can panic AFAIK they're not using std. And isn't this kind of panic the kind of thing that causes BUG()s today? Probably can just map one to the other.
  - btbuilder 5y ago
    out of memory conditions should not cause a kernel panic.
    - 5y ago
sk1459 5y ago
I suppose this can’t be stopped. I hope someone has the resources to curate a working fork of the Linux kernel that doesn’t have all the “improvements” it’s about to get.
- Flex247A 5y ago
  May I ask what is so bad about it?
  - sprash 5y ago
    The Rust compiler is very slow and has very high memory requirements. Compiling the Kernel on e.g. older Raspberry Pis is already barely possible and will potentially become completely impossible once rust enters the kernel.
    - nine_k 5y ago
      Both gcc and rustc are good at cross-compiling. There are many MCUs that run Linux but definitely are incapable of compiling it. IIRC most of the build time of a rust program is spent not in the rust compilation proper but in LLVM doing code generation and optimization. I hope both LLVM will become more efficient with time, and rust will learn to pass it such IR that it can process faster. There are obvious incentives for both of these things. But of course it would be sad if the minimum requirements to compile the kernel grew again, and now excluded older RPis.
    - Macha 5y ago
      gcc and clang are pretty slow on the scale of all programming languages. Rust is basically the only thing that modern C/C++ compilers are faster than. Should we abandon C and C++ for something else then?
  - sk1459 5y ago
    Rust is for writing blog posts about how it’s the most liberating, empowering and inspiring experience of your life. Boring technology like C and Java are for writing software. There’s already an OS completely written in Rust called Redox. Nobody uses it. I’m not entirely sure you could do useful work with it, which is contrary to the Rust marketing team’s talking points that Rust code is guaranteed to be fast and guaranteed to be bug free because Rust is just so darn great and the compiler authors so wonderful and smart. That there are basically no success stories other than a couple side projects after a decade of marketing is of no consequence. Don’t read the blog posts. Go to the repositories. Check out the crates.io landfill. Grab the Rust book and try to write anything more significant than a CLI toy. I promise that you will know exactly why nobody uses the language in anger. The Fuschia team, who are partly responsible for the Rust myth don’t even use it in their kernel. But they want it in Linux. I wouldn’t be shocked if this was all some conspiracy by Google and Microsoft to make a personal computing unusable so that everyone has to use their cloud offerings.
giovannibonetti 5y ago
I wonder if Zig [1] would be a better fit than Rust for the Linux Kernel. I haven't touched systems programming for a decade, but looking from the outside, it seems like the author put even more effort towards C ABI compatibility than the Rust team. [1] https://ziglang.org/ https://ziglang.org/
- matheusmoreira 5y ago
  It would be really interesting to see Zig code in the kernel as well. It's certainly much closer to C than Rust.
- newaccount2021 5y ago
  Zig is nowhere near mature enough to even be considered for kernel use.
- wyldfire 5y ago
  Zig does seem like a closer match to C and so could have been better suited than Rust. It doesn't provide the same safety as Rust, so it's not as big of a payoff, though. Also, it's still fairly new relative to rust. The kernel project distributes several userspace utilities and new ones of those might be worth writing in Zig.
- Keyframe 5y ago
  Zig is a cute but dead man walking project. Rust has gained traction and that's what ultimately matters.
  - fsloth 5y ago
    "Dead man walking" is quite harsh. Zig is a one man passion project. Those are awesome. Rust is becoming and industrial scale tool. Those are awesome as well. However, each has their place. One man passion projects should not be used in anything mission critical. They totally should be used for fun, enjoyment and inspiration, and they may potentially grow to industry scale.
    - 5y ago
nightpool 5y ago
Previous discussions: (This specific post:) https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26831841 https://news.ycombinator.com/item?id=26831841 (Previous Rust-in-kernel work:) https://news.ycombinator.com/item?id=24334731 https://news.ycombinator.com/item?id=24334731 https://news.ycombinator.com/item?id=23800201 https://news.ycombinator.com/item?id=23800201 https://news.ycombinator.com/item?id=20833639 https://news.ycombinator.com/item?id=20833639
- dang 5y ago
  Thanks! Here are the annotated versions of those links: Linus Torvalds on Rust support in kernel - https://news.ycombinator.com/item?id=26831841 https://news.ycombinator.com/item?id=26831841 - April 2021 (290 comments) An RFC that adds support for Rust to the Linux kernel - https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26812047 - April 2021 (261 comments) Supporting Linux kernel development in Rust - https://news.ycombinator.com/item?id=24334731 https://news.ycombinator.com/item?id=24334731 - Aug 2020 (354 comments) Linux kernel in-tree Rust support - https://news.ycombinator.com/item?id=23800201 https://news.ycombinator.com/item?id=23800201 - July 2020 (491 comments) Linux kernel drivers in Rust might become an option in the future - https://news.ycombinator.com/item?id=20833639 https://news.ycombinator.com/item?id=20833639 - Aug 2019 (254 comments) (I'm thinking of making HN's software render links to previous threads in this format automatically. If anyone can think of a downside to that, please let me know - maybe at hn@ycombinator.com so as not to take this thread off topic.)
eatonphil 5y ago
Slight tangent, is C the only language in the kernel at the moment? (Not including scripts used to build things the kernel.) For example NetBSD has Lua in the kernel and FreeBSD has or had a Forth interpreter in the bootloader.
- geofft 5y ago
  Yes, unless you count the ACPI machine language or BPF, but both of these are languages interpreted by the kernel, not languages linked directly to C.
  - vlovich123 5y ago
    If I’m not mistake, the BPF interpreter is gone. All those programs are JITed. I don’t know BPF well enough to know, but I suspect you can call kernel C functions from there. Overall though, your overarching point still stands that the Rust development is big in that this marks the first time actual Linux kernel code will be written in a language other than C (or platform-specific assembly).
    - wtallis 5y ago
      The BPF JIT is still optional. When it is enabled, there is a separate option to disable the interpreter and always use the JIT (CONFIG_BPF_JIT_ALWAYS_ON).
      - ncmncm 5y ago
        Running eBPF does not involve a JIT at all. The code is compiled to native, if it is, exactly when it is inserted, not when it is first used. Most uses insert code once or at specific junctures, and execution mostly happens at points widely separated from those. People talk about the insertion process as if it were JIT just because it reuses infrastructure originally invented for JIT.
- edgyquant 5y ago
  Yes the kernel is entirely written in C and assembly, there’s a Linus rant about why that is and why he doesn’t want C++ in it. Curious as to what changed his mind about rust
creamytaco 5y ago
Odds are it's not going to happen. You just need to read between the lines. There's a lot of handwaving from the Rust side and very little of actual importance. You gotta remember that most of the heavy hitters in Linux Kernel development haven't even commented yet. When the Rust side presents something mergeable, the massacre will begin.
- nynx 5y ago
  I don't see this at all. Could you point to an example?
  - creamytaco 5y ago
    It's just my intuition built by reading LKML and following Linux kernel development for 20 years. There are a lot of folks waiting for something mergeable before a torrent of criticism (and I'd imagine outright NAKs) comes down. I think a lot of Rust people read Linus's "I don't hate it" as explicit approval. But anyone who's followed LKML knows that this is not the case.
    - vlovich123 5y ago
      That’s a surprising read given Linus’ general overall positive sentiment to the preliminary interactions. Yes there are concerns but it seems like the team involved is working on solving them & believes it is a tractable problem, not to mention strong support from the Rust standard library maintainers. There are always risks but I wager this is far more serious than past attempts like the C++ one which never had any significant commitments from the standards body to support kernel needs. That Rust is building a language that can fit wildly different use-cases (embedded, kernel, web servers, systems programming, etc) without serious sacrifices for other use-cases is truly impressive to me.
      - creamytaco 5y ago
        Even if Linus wants it, and this is a big stretch since "I don't hate it" is best characterized as neutral and not positive, there are others who have a say. Remember what happened with KDBUS? Gregkh fought long and hard to get it merged but in the end it didn't happen because too many people didn't want it.
xaduha 5y ago
What is the biggest project written in Rust? Servo? Hasn't Firefox gave up on it?
- Buttons840 5y ago
  Firefox did ship some Rust code, and I haven't heard anything about Firefox giving up on Rust. https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation
  - stu2b50 5y ago
    They haven't officially, but the last layoffs gutted the teams working on rust to such an extent that it seems it's no longer a prioritization, at least if they remain for the same amount of funding.
    - Buttons840 5y ago
      What do you mean "they haven't officially"? The link I posted states "the first major Rust components were shipped in Firefox 56", is this not official?. Do you believe that is wrong? (I'm just trying to reconcile what I'm reading in these comments with what is stated in the link I posted.)
    - iudqnolq 5y ago
      Did the gut lang usage or just lang dev?
      - steveklabnik 5y ago
        They no longer employ the language developers, and the Servo developers, but they still write Rust code.
  - Yoric 5y ago
    Bug chunks of Firefox are still being rewritten in Rust. Parts of Google Fuchsia are apparently developed in Rust, too.
robocat 5y ago
When rust can significantly beat C for security, speed of development, and speed of execution then it will start to infect the kernel. Why use rust if it only improves security but has other downsides? This is an amazing peoject because it will encourage rust to improve to be better than C for multiple dimensions.
- kaba0 5y ago
  I’m not a rust fanboy, but why do you think it doesn’t beat C for speed of development or speed of execution? While the former is hard to prove without empirical studies, I would be very surprised to find a language with such a weak abstraction power as C more productive than Rust. And for the latter, there are benchmarks showing Rust can surpass C in execution speed — and even just theoretical it has more metadata available so it can make in theory make better optimizations.
bjourne 5y ago
A pet peeve of mine is the almost complete lack of empiricism in Computer Science. "Nevertheless, we believe that, even today, the advantages of using Rust [in the Linux kernel] outweighs the cost." Where is the evidence? "Rust is obviously a better choice for Linux than C." "Ok, if it is obvious, it should be easy to demonstrate?" This is not only about Rust - 99% or so of all new tech can't demonstrate any benefits.
- freeopinion 5y ago
  While human preference is probably not the most important consideration and is debatable, it does count as one possible benefit.
- nullc 5y ago
  It's not just being able to demonstrate the benefits empirically, but the combination of that with constantly loudly touting them. When someone thinks their hashmap is faster in theory they get asked to benchmark it... it often isn't in practice. But when someone decides that some norm in whitespace, use of parenthesis, or use favored control-flow concepts will result in a lower defect rate or reduced maintenance costs we somehow are expected to accept these conclusions without clear evidence. Even though everywhere is in computer science where we can easily measure results there are countless examples of theoretically better stuff that works less well in practice. Why should we expect our intuition on human interactions to be any better than our intuitions over which data structures are faster?
- emmericp 5y ago
  Most "new tech" is engineering, not science. If you want empiricism try academic papers instead of mailing lists ;) Some numbers: most critical bugs in the Linux kernel are due to memory safety: 40 out of 65 bugs allowing for code execution found in Linux in 2017 could have been prevented by using a memory-safe language [0]. The paper is about Go, but the same logic applies for Rust. Fun fact: 39 out of these 40 bugs were in drivers [1], so I think starting with drivers in Rust is a good idea. [0] https://www.usenix.org/conference/osdi18/presentation/cutler https://www.usenix.org/conference/osdi18/presentation/cutler (really good read!) [1] https://arxiv.org/pdf/1909.06344.pdf https://arxiv.org/pdf/1909.06344.pdf (disclaimer: I'm a co-author of that paper)
nonbirithm 5y ago
I find it interesting how virulently opposed Linus was to introducing C++ to the kernel in contrast to the embrace of Rust. It made me think that the idea of another language in the kernel wasn't the issue in itself, but that C++ was a bad language and Rust wasn't, and also that there were tangible benefits to adopting Rust like memory safety that couldn't be had with C. I do hope that Rust doesn't suffer from an explosion in complexity and compile times, though. Memory safety and overengineering shouldn't have to go hand in hand.
- hpaavola 5y ago
  "C++ is a horrible language. [...]" http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus So yes, Linus does really like C++ :)
  - phendrenad2 5y ago
    If Linus dislikes something, you know it's either really bad, or really good.
- threatripper 5y ago
  C++ is like nuclear power. Very powerful but very dangerous if only used slightly wrong. It would have been a constant fight over which parts of C++ are off limits and which parts are good to use. In recent years the language has improved but it carries a lot of baggage. Also it's too close to C in some regards and invites C programmers who just don't know enough dark corners of C++ yet. To me C++ is a language of last resort. It can do everything you need but you should not touch it if there is any other option.
  - Lev1a 5y ago
    > C++ is like nuclear power. Building from your metaphor, I would add: Python et al.: normal household batteries; everyone can use/operate them, not much power but can be used with little to no training and a screwup happening means you went looking for trouble Java et al.: electric batteries; substantially more power but has to stop relatively often (GC pauses), everyone can use the things running on them at least reasonably well [0] but one little thing can potentially cause a catastrophic chain reaction (one cell out of thousands => thermal runaway (eg. the infamous NullPointerException)) Rust, Go et al.: industrial backup generators or hydroelectric plants; substantially more power yet again but have a startup/setup time (learning a more complicated language/ecosystem), as reliable as can be realistically done but have to be spec'd right for the building/installation/etc. at hand (time vs. resources tradeoffs); screwups happening means you probably went looking for trouble (eg. in Rust: excessive cloning of data, building of circular references without weak references; not so sure about specific examples in Go but didn't want to lump it together with Java et al.) C, C++ et al.: "nuclear power [...] very powerful but dangerous if only used slightly wrong" like in your metaphor; should only really be used by experts but even they are not safe from introducing catastrophic failures with something seemingly harmless (seen as such at the time of writing the code); it gets safer over time but there is the huge inertia of existing installations running with huge time and resource costs associated with dismantling or even modernisations; footguns are everywhere and not always immediately recognisable especially since there recommendations about usage and safety concerns floating around which are sometimes years or decades out of date [0]: AFAICT a substantial part of the business software world runs on Java code cobbled together by not-necessarily-full-on-experts PS: My personal experiences/biases: - learned C++11 for a while, didn't like it, SEGFAULTs and associated debugging/fine-tooth-combing over the some-tens-or-hundreds-of-lines long code got really annoying really quickly - learned Java, Haskell and Prolog in Uni; Haskell was a nice intro to functional programming but nothing I would want to use even occasionally, Prolog was meh, Java was/is a convoluted, resource-hungry mess with huge amounts of boilerplate for every little thing and will IMHO always be associated with bad assignments in class(es) - Python3 I use every other week or so but not for "real programming (TM)", but instead for small (automation/download/crawler) scripts; I like it but for serious programming in a business environment - ie. something I personally would want to rely on for money - the duck-typing is just too unstable for my liking, even though I still like it for rapid prototyping of concepts coming into my head which I then later may or may not transfer into: - Rust... currently and personally my favorite language for "real programming (TM)" even though I struggled with the borrow checker for a long, long time (and still run into it on occasion); sometimes really long compile times but nice runtime performance in most cases even without special care and tuning while I still have the confidence that if it compiles it runs and any errors encountered at testing-/runtime are probably more due to logic errors than running into something like "oops, in this deep branch of cascading ifs I accidently didn't set some object's field or dict's value meaning at some later point the program blew up due to NoneError or something similar" - learned a bit of Go (before even finding out about Rust) but I just didn't like it, it just didn't "gel with me", don't even really remember the specific reason(s)
nemetroid 5y ago
Note that this is from a month ago. Some discussions about Rust in the Linux kernel from around that time: https://news.ycombinator.com/item?id=26831841 https://news.ycombinator.com/item?id=26831841 (292 comments) https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26812047 (262 comments)
cratermoon 5y ago
As popular and ubiquitous as Linux is, there was a time before it. It wouldn't shock me if, in another decade or two, a new operating system kernel written entirely in Rust came along and filled most of the niches that Linux fills while addressing all the security, stability, portability (mobile/low power device support), and licensing concerns that have emerged in the three decades since Linus announced version 0.02 to the world.
- the_duke 5y ago
  The critical point is not the OS itself, but the tooling, ecosystem and the drivers. There is a lot more hardware and software now than when Linux got started. For something different to overcome the initial bootstrapping problem it will need to be significantly better and be pushed by a very large player. Googles Fuchsia is the only possible current candidate I know of.
  - kaba0 5y ago
    Yeah, forking Linux/making at least the drivers backward compatible is a must for any chance at a new OS emerging. But Linux has so many features that I don’t see a new contender getting anywhere close in the next few decades at least.
Keyframe 5y ago
Acceleration of GCC support could help.
- steveklabnik 5y ago
  It's not required for Rust in-tree; if Rust wants to get into the kernel, rather than only drivers, then it would help.
deleted 5y ago
[deleted]
IshKebab 5y ago
> 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. Such a luddite view. "My car gets 40 rods to the hogs head..." I'm always amazed to see such stuck-in-the-mud views from people working in technology which is such a modern fast moving field.
- phendrenad2 5y ago
  Cars benefit from newer scientific advancements like better materials and computerized control. What scientific advancements make C++ or Rust fundamentally different from C?
  - kaba0 5y ago
    Not having to rely on text-based macros, because they can actually abstract things?
  - notriddle 5y ago
    The borrow checker?
  - IshKebab 5y ago
    Outside of `unsafe` blocks Rust is memory safe. It also has a much stronger type system which means code is more likely to work. That's something you have to experience first hand to understand, but you know that feeling you get writing C or C++ where new code appears to work the first time you run it? "That's suspicious. It must not have rebuilt, or maybe I forgot to call the new code." With Rust the compiler can catch so many mistakes that by the time you actually run the code there's a pretty good chance that it is right. My instinct is no longer "suspicious! Where have I gone wrong?"; it's "ha it worked! Though I'd still better double check".
ben0x539 5y ago
It's sad that a bunch of legit criticism around Rust in the kernel (like around tooling and maintenance burden if nothing else) probably won't lead to actual improvements being made because a tiny handful of people can't help themselves but dial up their condescension up to eleven and derail any attempt at productive discussion. On the other hand, I continue to be amused by arguments along the lines of "I'd already made up my mind that Rust is bad, but then I actually looked at some Rust code and realized it doesn't use C syntax, and now I'm even more upset"...
- pas 5y ago
  > but dial up their condescension up to eleven Sorry, what does this mean exactly? Could you come up with a hypothetical sentence that is like this? Thanks!
  - tempest_ 5y ago
    https://www.youtube.com/watch?v=KOO5S4vxi0o https://www.youtube.com/watch?v=KOO5S4vxi0o
  - yarg 5y ago
    There's a little bit of snark that results from any criticism of the suitability of Rust and its ecosystem for integration into the kernel. Rust's tooling isn't quite as mature as it could be, and it achieves its advanced capabilities and performance by eschewing a runtime (which would make it unacceptable) in favour of labourious compilation. The snark to me seems unnecessary; a more even headed discussion would acknowledge the limitations and focus instead on what can and will be improved or mitigated and what compromises are acceptable. The tooling will mature with time, panics will be mitigated, and the compile time performance is often a sacrifice worth making for the sake of the safety provided.
  - ben0x539 5y ago
    I don't want to call anyone out by making specific examples. I'm talking about comments that in their wording presuppose agreement that the person you're talking to doesn't know what they're doing, or the thing you're talking about is misguided and deserves to be sabotaged. Implications like that may very well be correct, but as always, not sticking to the technical aspects of the subject makes it harder to get anything done.
pdimitar 5y ago
I am sure I am not the first to think of this but here's an idea: Can we have a compiler flag or a Cargo switch inside the project's file that disables all std API that can panic? Basically complain that the function is not found. I for one always strive to write my Rust code with `Result<T>` and never rely on panics so I'd love it if that can actually be enforced and checked by the compiler.
- steveklabnik 5y ago
  Not currently, but it is theoretically possible.
  - pdimitar 5y ago
    Obviously those of us not in the core team can only fill wish lists. :) And I don't want to sound entitled! But I hope that if it's both possible and not very hard, then it will be considered. I'd personally love to double down on Rust's safety and dial it to eleven in all my hobby and commercial projects.
    - steveklabnik 5y ago
      It is not simple. But I would like to see it someday too :)
cogburnd02 5y ago
From https://itsfoss.com/hyperbola-linux-bsd/ https://itsfoss.com/hyperbola-linux-bsd/ > [T]he interest in allowing Rust modules into the kernel are a problem for us, due to Rust trademark restrictions which prevent us from applying patches in our distribution without express permission. We patch to remove non-free software, unlicensed files, and enhancements to user-privacy anywhere it is applicable. We also expect our users to be able to re-use our code without any additional restrictions or permission required. > This is also in part why we use UXP, a fully free browser engine and application toolkit without Rust, for our mail and browser applications.

170 points by h1x 5y ago

nynx 5y ago

More discussions about whether ownership can be tacked onto another language.

It's gonna be interesting to see how it will affect the kernel ABIs. High level languages have features that produce nightmarish binary interfaces and it's unrealistic to believe existing code will be able to interface with them. So will the code be restricted to a minimalist subset of Rust?

nynx 5y ago
Rust can easily produce C compatible symbols.
- matheusmoreira 5y ago
  Yes, but the benefits of Rust won't extend beyond those symbols. Also, certain features of Rust that have no C equivalents cannot be exported. Will the gains in safety be contained entirely inside the modules that are written in Rust?
  - nynx 5y ago
    Yes.
  - Flex247A 5y ago
    From my experience, absolutely.
  - oconnor663 5y ago
    > certain features of Rust that have no C equivalents cannot be exported Right, only "repr(C)" types can show up in "extern" APIs. So no data-bearing enums, no Vec<T>, etc. > Will the gains in safety be contained entirely inside the modules that are written in Rust? I think for some things the answer is yes, and for other things the answer is no. If the issue is that callers might retain some pointer or descriptor longer than they should, leading to a use-after-free or something like that, then there's probably no way to fix that with an API-compatible Rust reimplementation. What safe Rust would prefer to do is either 1) force explicit lifetime constraints on the caller or 2) replace the pointer/reference with some sort of smart pointer, which can either keep its referent alive or at least safely detect the fact that the referent is dead. But of course a C-compatible API has no way to represent (1), and (2) would presumably be an incompatible API change, so the Rust reimplementation can't really solve this issue. (Though if both Rust and C APIs get exposed for the new code, then new Rust callers could benefit from (1).) On the other hand, if the issue is that the caller might pass in some invalid indexes or other metadata, leading to an out-of-bounds array access within the module, Rust can help quite a bit. If the array in question is actually owned by the module (and not just a raw pointer to unknown memory) then bounds checking is required one way or another (unless it's either optimized away or explicitly skipped with unsafe code), and a Rust reimplementation will probably not suffer from out-of-bounds issues. Raw pointers into the caller's memory are harder to check, but even there if they can be converted to a safe slice immediately inside the API boundary, some subset of out-of-bounds accesses can still be caught. Looking at these two different kinds of bugs, I think it's interesting to think about what "inside the module" means here. In both cases, the UB we want to prevent (either use-after-free, or an out-of-bounds access) is "caused" by the caller's mistakes outside the module, but "occurs" on lines of code inside the module. In the first case, Rust can't protect itself against a bad (C) caller, but in the second case it might be able to.
geofft 5y ago
The kernel, fortunately, already doesn't want to have a public ABI. https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://www.kernel.org/doc/Documentation/process/stable-api-... The primary goal is to write in-tree drivers in Rust, which can still be loadable modules, but they'll be built to whatever ABI that particular version of the kernel uses. And even for out-of-tree modules, you have to recompile them against the specific kernel and ideally with the same version of the compiler etc.; ABI incompatibilities across C compilers are rare, but not unheard of.

the_duke 5y ago

Linux will definitely need a very curated setup to reap the full benefits of idiomatic Rust. Right now both alloc/std and even basic language constructs like indexing into a slice can panic. With little help from the tooling to guard against it. This makes sense when considering that Rust evolved as a language for writing somewhat higher level applications like browsers. While Rust and especially the library ecosystem is generally great at forcing you to handle application domain error conditions, that mostly doesn't extend to these lower-level concerns. But I'm hopeful that this can improve the entire ecosystem over the medium term. With things like lints that forbid panics, more focus on custom allocators and fallible allocations in std and the library ecosystem, etc. edit: just to clarify on the slice index panicking: my point isn't that the C situation is better, but that a big reason for moving to Rust would be to benefit of a safer, more convenient language that doesn't require such extreme carefulness as C. So the language should help in preventing panics, or making it obvious where they can occur. This is perfectly possible in Rust by using accessors that return `Option<T>` or iterators. But the tooling for such use cases can be improved, for example with lints, and the API surface can be customized to mostly prevent such conditions with the type system.

nynx 5y ago
A rising tide lifts all boats! I'm really looking forward to the improvements that come to the rust ecosystem from integration into Linux.
wyldfire 5y ago
> Right now both alloc/std and even basic language constructs like indexing into a slice can panic AFAIK they're not using std. And isn't this kind of panic the kind of thing that causes BUG()s today? Probably can just map one to the other.
- btbuilder 5y ago
  out of memory conditions should not cause a kernel panic.
  - 5y ago

sk1459 5y ago

I suppose this can’t be stopped. I hope someone has the resources to curate a working fork of the Linux kernel that doesn’t have all the “improvements” it’s about to get.

Flex247A 5y ago
May I ask what is so bad about it?
- sprash 5y ago
  The Rust compiler is very slow and has very high memory requirements. Compiling the Kernel on e.g. older Raspberry Pis is already barely possible and will potentially become completely impossible once rust enters the kernel.
  - nine_k 5y ago
    Both gcc and rustc are good at cross-compiling. There are many MCUs that run Linux but definitely are incapable of compiling it. IIRC most of the build time of a rust program is spent not in the rust compilation proper but in LLVM doing code generation and optimization. I hope both LLVM will become more efficient with time, and rust will learn to pass it such IR that it can process faster. There are obvious incentives for both of these things. But of course it would be sad if the minimum requirements to compile the kernel grew again, and now excluded older RPis.
  - Macha 5y ago
    gcc and clang are pretty slow on the scale of all programming languages. Rust is basically the only thing that modern C/C++ compilers are faster than. Should we abandon C and C++ for something else then?
- sk1459 5y ago
  Rust is for writing blog posts about how it’s the most liberating, empowering and inspiring experience of your life. Boring technology like C and Java are for writing software. There’s already an OS completely written in Rust called Redox. Nobody uses it. I’m not entirely sure you could do useful work with it, which is contrary to the Rust marketing team’s talking points that Rust code is guaranteed to be fast and guaranteed to be bug free because Rust is just so darn great and the compiler authors so wonderful and smart. That there are basically no success stories other than a couple side projects after a decade of marketing is of no consequence. Don’t read the blog posts. Go to the repositories. Check out the crates.io landfill. Grab the Rust book and try to write anything more significant than a CLI toy. I promise that you will know exactly why nobody uses the language in anger. The Fuschia team, who are partly responsible for the Rust myth don’t even use it in their kernel. But they want it in Linux. I wouldn’t be shocked if this was all some conspiracy by Google and Microsoft to make a personal computing unusable so that everyone has to use their cloud offerings.

giovannibonetti 5y ago

I wonder if Zig [1] would be a better fit than Rust for the Linux Kernel. I haven't touched systems programming for a decade, but looking from the outside, it seems like the author put even more effort towards C ABI compatibility than the Rust team. [1] https://ziglang.org/ https://ziglang.org/

matheusmoreira 5y ago
It would be really interesting to see Zig code in the kernel as well. It's certainly much closer to C than Rust.
newaccount2021 5y ago
Zig is nowhere near mature enough to even be considered for kernel use.
wyldfire 5y ago
Zig does seem like a closer match to C and so could have been better suited than Rust. It doesn't provide the same safety as Rust, so it's not as big of a payoff, though. Also, it's still fairly new relative to rust. The kernel project distributes several userspace utilities and new ones of those might be worth writing in Zig.
Keyframe 5y ago
Zig is a cute but dead man walking project. Rust has gained traction and that's what ultimately matters.
- fsloth 5y ago
  "Dead man walking" is quite harsh. Zig is a one man passion project. Those are awesome. Rust is becoming and industrial scale tool. Those are awesome as well. However, each has their place. One man passion projects should not be used in anything mission critical. They totally should be used for fun, enjoyment and inspiration, and they may potentially grow to industry scale.
  - 5y ago

nightpool 5y ago

Previous discussions: (This specific post:) https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26831841 https://news.ycombinator.com/item?id=26831841 (Previous Rust-in-kernel work:) https://news.ycombinator.com/item?id=24334731 https://news.ycombinator.com/item?id=24334731 https://news.ycombinator.com/item?id=23800201 https://news.ycombinator.com/item?id=23800201 https://news.ycombinator.com/item?id=20833639 https://news.ycombinator.com/item?id=20833639

dang 5y ago
Thanks! Here are the annotated versions of those links: Linus Torvalds on Rust support in kernel - https://news.ycombinator.com/item?id=26831841 https://news.ycombinator.com/item?id=26831841 - April 2021 (290 comments) An RFC that adds support for Rust to the Linux kernel - https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26812047 - April 2021 (261 comments) Supporting Linux kernel development in Rust - https://news.ycombinator.com/item?id=24334731 https://news.ycombinator.com/item?id=24334731 - Aug 2020 (354 comments) Linux kernel in-tree Rust support - https://news.ycombinator.com/item?id=23800201 https://news.ycombinator.com/item?id=23800201 - July 2020 (491 comments) Linux kernel drivers in Rust might become an option in the future - https://news.ycombinator.com/item?id=20833639 https://news.ycombinator.com/item?id=20833639 - Aug 2019 (254 comments) (I'm thinking of making HN's software render links to previous threads in this format automatically. If anyone can think of a downside to that, please let me know - maybe at hn@ycombinator.com so as not to take this thread off topic.)

eatonphil 5y ago

Slight tangent, is C the only language in the kernel at the moment? (Not including scripts used to build things the kernel.) For example NetBSD has Lua in the kernel and FreeBSD has or had a Forth interpreter in the bootloader.

geofft 5y ago
Yes, unless you count the ACPI machine language or BPF, but both of these are languages interpreted by the kernel, not languages linked directly to C.
- vlovich123 5y ago
  If I’m not mistake, the BPF interpreter is gone. All those programs are JITed. I don’t know BPF well enough to know, but I suspect you can call kernel C functions from there. Overall though, your overarching point still stands that the Rust development is big in that this marks the first time actual Linux kernel code will be written in a language other than C (or platform-specific assembly).
  - wtallis 5y ago
    The BPF JIT is still optional. When it is enabled, there is a separate option to disable the interpreter and always use the JIT (CONFIG_BPF_JIT_ALWAYS_ON).
    - ncmncm 5y ago
      Running eBPF does not involve a JIT at all. The code is compiled to native, if it is, exactly when it is inserted, not when it is first used. Most uses insert code once or at specific junctures, and execution mostly happens at points widely separated from those. People talk about the insertion process as if it were JIT just because it reuses infrastructure originally invented for JIT.
edgyquant 5y ago
Yes the kernel is entirely written in C and assembly, there’s a Linus rant about why that is and why he doesn’t want C++ in it. Curious as to what changed his mind about rust

creamytaco 5y ago

Odds are it's not going to happen. You just need to read between the lines. There's a lot of handwaving from the Rust side and very little of actual importance. You gotta remember that most of the heavy hitters in Linux Kernel development haven't even commented yet. When the Rust side presents something mergeable, the massacre will begin.

nynx 5y ago
I don't see this at all. Could you point to an example?
- creamytaco 5y ago
  It's just my intuition built by reading LKML and following Linux kernel development for 20 years. There are a lot of folks waiting for something mergeable before a torrent of criticism (and I'd imagine outright NAKs) comes down. I think a lot of Rust people read Linus's "I don't hate it" as explicit approval. But anyone who's followed LKML knows that this is not the case.
  - vlovich123 5y ago
    That’s a surprising read given Linus’ general overall positive sentiment to the preliminary interactions. Yes there are concerns but it seems like the team involved is working on solving them & believes it is a tractable problem, not to mention strong support from the Rust standard library maintainers. There are always risks but I wager this is far more serious than past attempts like the C++ one which never had any significant commitments from the standards body to support kernel needs. That Rust is building a language that can fit wildly different use-cases (embedded, kernel, web servers, systems programming, etc) without serious sacrifices for other use-cases is truly impressive to me.
    - creamytaco 5y ago
      Even if Linus wants it, and this is a big stretch since "I don't hate it" is best characterized as neutral and not positive, there are others who have a say. Remember what happened with KDBUS? Gregkh fought long and hard to get it merged but in the end it didn't happen because too many people didn't want it.

xaduha 5y ago

What is the biggest project written in Rust? Servo? Hasn't Firefox gave up on it?

Buttons840 5y ago
Firefox did ship some Rust code, and I haven't heard anything about Firefox giving up on Rust. https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation
- stu2b50 5y ago
  They haven't officially, but the last layoffs gutted the teams working on rust to such an extent that it seems it's no longer a prioritization, at least if they remain for the same amount of funding.
  - Buttons840 5y ago
    What do you mean "they haven't officially"? The link I posted states "the first major Rust components were shipped in Firefox 56", is this not official?. Do you believe that is wrong? (I'm just trying to reconcile what I'm reading in these comments with what is stated in the link I posted.)
  - iudqnolq 5y ago
    Did the gut lang usage or just lang dev?
    - steveklabnik 5y ago
      They no longer employ the language developers, and the Servo developers, but they still write Rust code.
- Yoric 5y ago
  Bug chunks of Firefox are still being rewritten in Rust. Parts of Google Fuchsia are apparently developed in Rust, too.

robocat 5y ago

When rust can significantly beat C for security, speed of development, and speed of execution then it will start to infect the kernel. Why use rust if it only improves security but has other downsides? This is an amazing peoject because it will encourage rust to improve to be better than C for multiple dimensions.

kaba0 5y ago
I’m not a rust fanboy, but why do you think it doesn’t beat C for speed of development or speed of execution? While the former is hard to prove without empirical studies, I would be very surprised to find a language with such a weak abstraction power as C more productive than Rust. And for the latter, there are benchmarks showing Rust can surpass C in execution speed — and even just theoretical it has more metadata available so it can make in theory make better optimizations.

bjourne 5y ago

A pet peeve of mine is the almost complete lack of empiricism in Computer Science. "Nevertheless, we believe that, even today, the advantages of using Rust [in the Linux kernel] outweighs the cost." Where is the evidence? "Rust is obviously a better choice for Linux than C." "Ok, if it is obvious, it should be easy to demonstrate?" This is not only about Rust - 99% or so of all new tech can't demonstrate any benefits.

freeopinion 5y ago
While human preference is probably not the most important consideration and is debatable, it does count as one possible benefit.
nullc 5y ago
It's not just being able to demonstrate the benefits empirically, but the combination of that with constantly loudly touting them. When someone thinks their hashmap is faster in theory they get asked to benchmark it... it often isn't in practice. But when someone decides that some norm in whitespace, use of parenthesis, or use favored control-flow concepts will result in a lower defect rate or reduced maintenance costs we somehow are expected to accept these conclusions without clear evidence. Even though everywhere is in computer science where we can easily measure results there are countless examples of theoretically better stuff that works less well in practice. Why should we expect our intuition on human interactions to be any better than our intuitions over which data structures are faster?
emmericp 5y ago
Most "new tech" is engineering, not science. If you want empiricism try academic papers instead of mailing lists ;) Some numbers: most critical bugs in the Linux kernel are due to memory safety: 40 out of 65 bugs allowing for code execution found in Linux in 2017 could have been prevented by using a memory-safe language [0]. The paper is about Go, but the same logic applies for Rust. Fun fact: 39 out of these 40 bugs were in drivers [1], so I think starting with drivers in Rust is a good idea. [0] https://www.usenix.org/conference/osdi18/presentation/cutler https://www.usenix.org/conference/osdi18/presentation/cutler (really good read!) [1] https://arxiv.org/pdf/1909.06344.pdf https://arxiv.org/pdf/1909.06344.pdf (disclaimer: I'm a co-author of that paper)

nonbirithm 5y ago

I find it interesting how virulently opposed Linus was to introducing C++ to the kernel in contrast to the embrace of Rust. It made me think that the idea of another language in the kernel wasn't the issue in itself, but that C++ was a bad language and Rust wasn't, and also that there were tangible benefits to adopting Rust like memory safety that couldn't be had with C. I do hope that Rust doesn't suffer from an explosion in complexity and compile times, though. Memory safety and overengineering shouldn't have to go hand in hand.

hpaavola 5y ago
"C++ is a horrible language. [...]" http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus So yes, Linus does really like C++ :)
- phendrenad2 5y ago
  If Linus dislikes something, you know it's either really bad, or really good.
threatripper 5y ago
C++ is like nuclear power. Very powerful but very dangerous if only used slightly wrong. It would have been a constant fight over which parts of C++ are off limits and which parts are good to use. In recent years the language has improved but it carries a lot of baggage. Also it's too close to C in some regards and invites C programmers who just don't know enough dark corners of C++ yet. To me C++ is a language of last resort. It can do everything you need but you should not touch it if there is any other option.
- Lev1a 5y ago
  > C++ is like nuclear power. Building from your metaphor, I would add: Python et al.: normal household batteries; everyone can use/operate them, not much power but can be used with little to no training and a screwup happening means you went looking for trouble Java et al.: electric batteries; substantially more power but has to stop relatively often (GC pauses), everyone can use the things running on them at least reasonably well [0] but one little thing can potentially cause a catastrophic chain reaction (one cell out of thousands => thermal runaway (eg. the infamous NullPointerException)) Rust, Go et al.: industrial backup generators or hydroelectric plants; substantially more power yet again but have a startup/setup time (learning a more complicated language/ecosystem), as reliable as can be realistically done but have to be spec'd right for the building/installation/etc. at hand (time vs. resources tradeoffs); screwups happening means you probably went looking for trouble (eg. in Rust: excessive cloning of data, building of circular references without weak references; not so sure about specific examples in Go but didn't want to lump it together with Java et al.) C, C++ et al.: "nuclear power [...] very powerful but dangerous if only used slightly wrong" like in your metaphor; should only really be used by experts but even they are not safe from introducing catastrophic failures with something seemingly harmless (seen as such at the time of writing the code); it gets safer over time but there is the huge inertia of existing installations running with huge time and resource costs associated with dismantling or even modernisations; footguns are everywhere and not always immediately recognisable especially since there recommendations about usage and safety concerns floating around which are sometimes years or decades out of date [0]: AFAICT a substantial part of the business software world runs on Java code cobbled together by not-necessarily-full-on-experts PS: My personal experiences/biases: - learned C++11 for a while, didn't like it, SEGFAULTs and associated debugging/fine-tooth-combing over the some-tens-or-hundreds-of-lines long code got really annoying really quickly - learned Java, Haskell and Prolog in Uni; Haskell was a nice intro to functional programming but nothing I would want to use even occasionally, Prolog was meh, Java was/is a convoluted, resource-hungry mess with huge amounts of boilerplate for every little thing and will IMHO always be associated with bad assignments in class(es) - Python3 I use every other week or so but not for "real programming (TM)", but instead for small (automation/download/crawler) scripts; I like it but for serious programming in a business environment - ie. something I personally would want to rely on for money - the duck-typing is just too unstable for my liking, even though I still like it for rapid prototyping of concepts coming into my head which I then later may or may not transfer into: - Rust... currently and personally my favorite language for "real programming (TM)" even though I struggled with the borrow checker for a long, long time (and still run into it on occasion); sometimes really long compile times but nice runtime performance in most cases even without special care and tuning while I still have the confidence that if it compiles it runs and any errors encountered at testing-/runtime are probably more due to logic errors than running into something like "oops, in this deep branch of cascading ifs I accidently didn't set some object's field or dict's value meaning at some later point the program blew up due to NoneError or something similar" - learned a bit of Go (before even finding out about Rust) but I just didn't like it, it just didn't "gel with me", don't even really remember the specific reason(s)

nemetroid 5y ago

Note that this is from a month ago. Some discussions about Rust in the Linux kernel from around that time: https://news.ycombinator.com/item?id=26831841 https://news.ycombinator.com/item?id=26831841 (292 comments) https://news.ycombinator.com/item?id=26812047 https://news.ycombinator.com/item?id=26812047 (262 comments)

cratermoon 5y ago

As popular and ubiquitous as Linux is, there was a time before it. It wouldn't shock me if, in another decade or two, a new operating system kernel written entirely in Rust came along and filled most of the niches that Linux fills while addressing all the security, stability, portability (mobile/low power device support), and licensing concerns that have emerged in the three decades since Linus announced version 0.02 to the world.

the_duke 5y ago
The critical point is not the OS itself, but the tooling, ecosystem and the drivers. There is a lot more hardware and software now than when Linux got started. For something different to overcome the initial bootstrapping problem it will need to be significantly better and be pushed by a very large player. Googles Fuchsia is the only possible current candidate I know of.
- kaba0 5y ago
  Yeah, forking Linux/making at least the drivers backward compatible is a must for any chance at a new OS emerging. But Linux has so many features that I don’t see a new contender getting anywhere close in the next few decades at least.

Keyframe 5y ago

Acceleration of GCC support could help.

steveklabnik 5y ago
It's not required for Rust in-tree; if Rust wants to get into the kernel, rather than only drivers, then it would help.

deleted 5y ago

[deleted]

IshKebab 5y ago

> 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. Such a luddite view. "My car gets 40 rods to the hogs head..." I'm always amazed to see such stuck-in-the-mud views from people working in technology which is such a modern fast moving field.

phendrenad2 5y ago
Cars benefit from newer scientific advancements like better materials and computerized control. What scientific advancements make C++ or Rust fundamentally different from C?
- kaba0 5y ago
  Not having to rely on text-based macros, because they can actually abstract things?
- notriddle 5y ago
  The borrow checker?
- IshKebab 5y ago
  Outside of `unsafe` blocks Rust is memory safe. It also has a much stronger type system which means code is more likely to work. That's something you have to experience first hand to understand, but you know that feeling you get writing C or C++ where new code appears to work the first time you run it? "That's suspicious. It must not have rebuilt, or maybe I forgot to call the new code." With Rust the compiler can catch so many mistakes that by the time you actually run the code there's a pretty good chance that it is right. My instinct is no longer "suspicious! Where have I gone wrong?"; it's "ha it worked! Though I'd still better double check".

ben0x539 5y ago

It's sad that a bunch of legit criticism around Rust in the kernel (like around tooling and maintenance burden if nothing else) probably won't lead to actual improvements being made because a tiny handful of people can't help themselves but dial up their condescension up to eleven and derail any attempt at productive discussion. On the other hand, I continue to be amused by arguments along the lines of "I'd already made up my mind that Rust is bad, but then I actually looked at some Rust code and realized it doesn't use C syntax, and now I'm even more upset"...

pas 5y ago
> but dial up their condescension up to eleven Sorry, what does this mean exactly? Could you come up with a hypothetical sentence that is like this? Thanks!
- tempest_ 5y ago
  https://www.youtube.com/watch?v=KOO5S4vxi0o https://www.youtube.com/watch?v=KOO5S4vxi0o
- yarg 5y ago
  There's a little bit of snark that results from any criticism of the suitability of Rust and its ecosystem for integration into the kernel. Rust's tooling isn't quite as mature as it could be, and it achieves its advanced capabilities and performance by eschewing a runtime (which would make it unacceptable) in favour of labourious compilation. The snark to me seems unnecessary; a more even headed discussion would acknowledge the limitations and focus instead on what can and will be improved or mitigated and what compromises are acceptable. The tooling will mature with time, panics will be mitigated, and the compile time performance is often a sacrifice worth making for the sake of the safety provided.
- ben0x539 5y ago
  I don't want to call anyone out by making specific examples. I'm talking about comments that in their wording presuppose agreement that the person you're talking to doesn't know what they're doing, or the thing you're talking about is misguided and deserves to be sabotaged. Implications like that may very well be correct, but as always, not sticking to the technical aspects of the subject makes it harder to get anything done.

pdimitar 5y ago

I am sure I am not the first to think of this but here's an idea: Can we have a compiler flag or a Cargo switch inside the project's file that disables all std API that can panic? Basically complain that the function is not found. I for one always strive to write my Rust code with `Result<T>` and never rely on panics so I'd love it if that can actually be enforced and checked by the compiler.

steveklabnik 5y ago
Not currently, but it is theoretically possible.
- pdimitar 5y ago
  Obviously those of us not in the core team can only fill wish lists. :) And I don't want to sound entitled! But I hope that if it's both possible and not very hard, then it will be considered. I'd personally love to double down on Rust's safety and dial it to eleven in all my hobby and commercial projects.
  - steveklabnik 5y ago
    It is not simple. But I would like to see it someday too :)

cogburnd02 5y ago

From https://itsfoss.com/hyperbola-linux-bsd/ https://itsfoss.com/hyperbola-linux-bsd/ > [T]he interest in allowing Rust modules into the kernel are a problem for us, due to Rust trademark restrictions which prevent us from applying patches in our distribution without express permission. We patch to remove non-free software, unlicensed files, and enhancements to user-privacy anywhere it is applicable. We also expect our users to be able to re-use our code without any additional restrictions or permission required. > This is also in part why we use UXP, a fully free browser engine and application toolkit without Rust, for our mail and browser applications.