[HN Gopher] Linus Torvalds: Rust for the Kernel Could Possibly B...
___________________________________________________________________
Linus Torvalds: Rust for the Kernel Could Possibly Be Merged for
Linux 5.20
Author : FPGAhacker
Score : 342 points
Date : 2022-06-23 13:05 UTC (9 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| fxttr wrote:
| I really have mixed feelings about that, but I am really curious
| to see what's happening. Some people also experimented with some
| kernel modules written in Rust on FreeBSD. If rust + linux is a
| success story, maybe FreeBSD could learn from it and adopt some
| ideas.
| DesiLurker wrote:
| can someone eli5 why rust is okay but not c++11 variants?
| boris wrote:
| C++ burnt through a lot of good will in the C++98 era where it
| was admittedly a hot mess (and all the compilers where buggy
| dumpster fires). Now on one hand we have people who publicly
| and loudly swore off touching C++ ever again based on this
| experience (and even more people parroting the "C++ is a mess"
| statement without any experience) and on the other the
| excitement of Rust with all the hype making people invest a
| large amount of effort into learning it.
| Arkanum wrote:
| My limited understanding is that rust provides significant
| advantages in terms of memory safety[1], that should reduce the
| chance of errors and bugs, whilst c++11 does not provide these
| same advantages.
|
| [1] Comparison of memory safety of c vs Zig vs Rust (from
| elsewhere in the comments): https://www.scattered-
| thoughts.net/writing/how-safe-is-zig/
| seabrookmx wrote:
| Other commenters have good points, but don't underestimate the
| fact that Linus doesn't like C++.
| ncmncm wrote:
| This, despite that Rust has every single thing Linus hated
| about C++.
| woodruffw wrote:
| 'jcranmer gave a good summary, but to add one or two more
| points:
|
| * It's very difficult to predict allocation patterns in C++
| (even modern variants) from just the source code. An innocent
| looking object allocated on the stack might have a nontrivial
| constructor with all kinds of side effects. Rust, while being
| slightly less explicit than C, is _much more_ explicit than
| C++.
|
| * Modern C++ doesn't actually play that nicely with C. C++'s
| aliasing rules and casting rules keep getting more and more
| strict, whereas kernel programming lends itself to a lot of
| "bag-of-bytes-to-struct"-style programming. It would be very
| unfortunate if adding a C++ compiler to the kernel's build
| broke pre-existing C code by detecting UB in the context of C++
| and decided to simply erase it.
| ncmncm wrote:
| Neither of those is correct, as a legitimate reason. Rust
| does everything C++ does, as far as things happening
| invisibly. Everything Linus famously ranted about is there.
|
| And, Rust has even more incompatibilities with fast-and-loose
| C memory use. There are reasons why C and C++ compilers have
| "sanitizer" modes. Those identify places where code would be
| surprisingly elided. Yes, C has those too.
| jcranmer wrote:
| Rust's design has given more thought for how to work in the
| kind of programming environment that the Linux kernel sits in
| than C++ (even C++11) has.
|
| Specifically (and this is no longer quite eli5), Rust's
| freestanding mode--working without a standard library--is
| somewhat fuller and more fleshed out than the C++ freestanding
| mode.
|
| Now, the sibling comment that points out that C++ gained a bad
| reputation pre-C++11 is probably a bigger reason for it not
| being seriously considered whereas Rust is, but there are some
| technical reasons where Rust does better than C++.
| b20000 wrote:
| i hope this never happens. if it does then i will lose all
| interest in ever contributing.
| dagmx wrote:
| So you don't contribute now, and you want people to not do so
| something on the off chance you contribute something in the
| future, that is of more value than this delivers?
| b20000 wrote:
| you don't know whether i contribute or not.
|
| introducing another language will create additional barriers
| for new driver developers. the kernel itself is already
| complicated enough and the focus should be on better
| documentation for new developers and a more welcoming
| attitude in general to improving (read simplifying) APIs like
| ALSA-SoC, for example. and please don't tell me that the docs
| in the kernel tree are good enough.
|
| as a device creator, i look at this from a completely
| different and more practical perspective than those who are
| obsessed about programming languages. in the end the kernel
| serves the hardware community and is not some kind of
| programming utopia to prove how smart you are.
| bitwize wrote:
| grug agree. focus should be on trap complexity demon, make
| easier for new grugs to contribute meaningfully to kernel.
|
| but.
|
| C is language created by grugs in 70s. programmers born in
| 90s, 2000s very different. wear "programming socks". think
| C very, very bad -- danger!
|
| rust is systems language for programming soxers. reality
| is, programming soxers now make big-BIG part of shamans in
| oss. like rust. want to rewrite everything in rust, think
| they can trap buffer overrun and use-after-free demons
| forever.
|
| grug think there are perfectly fine grug languages -- ada,
| even lisp -- can trap demons same-same. grug also think
| tools can help keep demons out of C code base. but momentum
| behind rust now. grugs who maintain kernel must meet
| developers where they are. if kernel grugs resist change,
| programming soxers refuse to join project. go to press, say
| "these CVEs could have been prevented had they used rust!"
| gruggernews say "well, they're not wrong..." linux lose
| face. lose base of new programmers. very bad for project.
| b20000 wrote:
| linux is now used in devices, it's not just a "server"
| operating system anymore like it was in the past. times
| have changed, and even though vulnerabilities are still
| important, they don't matter for many devices (e.g.
| portable game device not connected to the internet).
| webkike wrote:
| How will it add new barriers? You can still program your
| drivers in C.
| b20000 wrote:
| no, because sooner or later i will need to touch rust
| code when i work on drivers which means i need to learn
| the language and its constructs.
|
| i then have to maintain and keep up that know-how which
| adds more cost to my business.
|
| and the kernel is not going to become a 100% rust code
| base anytime soon.
| mynameisash wrote:
| > you don't know whether i contribute or not.
|
| Okay, so _do_ you contribute? Because your wording here:
|
| >> i will lose all interest in ever contributing
|
| To me reads as a clear indication that you don't yet.
| ntoskrnl wrote:
| It will be tough, but I think Linux will manage to keep limping
| along even without you.
| b20000 wrote:
| maybe contributors will move on to other operating systems
| then, like BSD?
| webkike wrote:
| Okay, so?
| sdfhdhjdw3 wrote:
| Could someone explain to me why you would want to add Rust to the
| kernel, without using the word "safe".
| adgjlsfhk1 wrote:
| Because 3/4ths of the security problems in C code are memory
| errors which rust removes, while still providing the low level
| code necessary to write a kernel.
| jcranmer wrote:
| Rust actually does a (marginally) better job of being a low-
| level, almost portable assembler kind of language than C does.
| This isn't even really about things like undefined behavior (of
| which Rust still has quite a profusion), but in things like
| being able to actually pun types.
|
| Additionally, Rust is a newer language that has incorporated
| some of the past 50 years of programming language design
| lessons that C has not incorporated (and likely never will).
| sdfhdhjdw3 wrote:
| This is not a bad answer.
| monocasa wrote:
| Why should we constrain ourselves to not use the word 'safe' in
| the context of one of the most privileged portions of code
| running on a computer?
|
| Linus has made it pretty clear that it's why he's allowing it;
| it provides something above and beyond other system languages
| wrt to writing correct code while still working with the
| kernel's structure and requirements (with a little elbow
| grease).
| sdfhdhjdw3 wrote:
| The reason why is asked "without the word safe" is that on HN
| rust seems like cargo cult, in the sense that the word "safe"
| is used as a thought stopping - after all, who is against
| "safe"? - and so its meaning is never really explained.
| adgjlsfhk1 wrote:
| The meaning of "safe" is pretty straightforward. It means
| that you don't read memory that you have freed, don't read
| memory that you haven't initialized, and don't read or
| write memory that you don't own.
| webkike wrote:
| Rust is more fun to program in than C. I was a pure C guy
| before I learned Rust.
| dieortin wrote:
| Surely being fun is not the best reason to add a language to
| a kernel.
| pornel wrote:
| Linus has commented that using C may eventually be an
| obstacle to attracting new contributors. Rust is attracting
| new developers and gaining mindshare. From Rustaceans'
| perspective C looks tedious and antiquated -- _not_ fun to
| work on.
| sdfhdhjdw3 wrote:
| Really? Is this the same Linus that has commented that he
| likes the fact that C turns people off, because people
| who get turned off that easily probably don't have the
| grit to contribute to the kernel, and so he doesn't want
| them anyway? (paraphrasing)
| pornel wrote:
| There's a difference. One comment was about having a
| language that will scare away amateurs, the other was
| about having a language that will not scare away valuable
| contributors.
|
| Besides, fighting with the borrow checker requires a lot
| of grit ;)
| sdfhdhjdw3 wrote:
| I don't know anything about Rust, but I've heard about
| fighting the borrow checker.
|
| I wonder - doesn't that mean that either the borrow
| checker is a bit shit, OR you're systematically doing
| something wrong and don't realize it?
| oconnor663 wrote:
| The truth is definitely some mix of both of those things.
| There are cases where the borrow checker can't understand
| some code that everyone can agree should be allowed, and
| maybe a larger set of cases where there's some debate
| about what should be allowed. The 1.0 compiler was
| substantially worse about this, and the introduction of
| "nonlexical lifetimes" in 2018 was a major improvement,
| though there's still plenty more to do.
|
| One of the reasons that "fighting the borrow checker" is
| such a common experience, is that it can be hard to tell
| the difference between cases like "this doesn't work
| because you forgot a small piece of syntax" vs "this
| doesn't work because you need a special helper type to
| make it work" vs "this doesn't work because fundamentally
| Rust will never allow this to work". For example, sharing
| objects between two threads often requires the
| `Arc<Mutex<...>>` pattern, which is a combination of two
| different helpers, and beginners who've never seen that
| combination before are very unlikely to discover it on
| their own. But once you have some experience with common
| patterns, and you know how to avoid writing code that
| will fundamentally never work, compiler errors are much
| more likely to be helpful.
|
| A lot of people ultimately decide that "the compiler was
| right all along" and that their code is really _better_
| now that they 've learned to satisfy the borrow checker.
| Personally, I think learning how to write Rust code is a
| helpful shortcut to learning how to write safe and
| correct C/C++, because the "borrow checker in your head"
| pushes you towards designs that work well in all three
| languages. But this is definitely a matter of opinion,
| not to mention extreme selection/survivorship bias, etc.
| webkike wrote:
| Well, he certainly won't lose that by switching to rust
| judging by the comments in this thread!
| webkike wrote:
| Well, the OP took one of them away, and other people are
| pointing out other reasons. It's just one reason.
|
| But maybe I can elaborate a little further: it's as fast as
| C, but more fun.
| eigenform wrote:
| The compiler and language make it easier to unambiguously
| specify a program.
| josephcsible wrote:
| Could someone explain to me why people need to breathe, without
| using the word "oxygen".
| feet wrote:
| Breathing in humans is driven by the need to remove CO2 from
| the blood
| varajelle wrote:
| Convenience of using zero-cost abstractions to get the same
| things done faster/easier?
| sdfhdhjdw3 wrote:
| That's the guiding design principle of C++.
| samuell wrote:
| Pardon my ignorance, but given the complexity of Rust, the
| incoherence of the async story etc, wouldn't something like Zig
| be a more reasonable choice for Linux, with its ability to be
| introduced gradually etc?
| Tuna-Fish wrote:
| What value would Zig provide to the kernel?
|
| The reason Rust is interesting in the space is the memory
| safety without a GC. Zig doesn't have that.
| azakai wrote:
| Zig's safety is lower than Rust's, that's true, but it is
| still a very big improvement over C, so a case could be made
| for it in principle. But of course in practice Zig is not
| stable enough to consider that yet.
|
| Anyhow, this isn't all or nothing: a case could also be made
| one way or the other about how much 'unsafe' to allow in Rust
| in the kernel. It's a question of tradeoffs.
| jeroenhd wrote:
| Zig isn't finished yet. Rust has stable language features.
|
| You also don't need async in many if not most cases, especially
| if you're writing kernel code. I wouldn't want to use a kernel
| module that pulls in all of tokio/reqwest/hyper just like I
| don't want a kernel module that links against openssl.
|
| Async makes a lot of sense for userland code, but not so much
| for kernel code. I haven't seen async get used in any demo for
| kernel Rust modules and I doubt it'll happen anyway.
|
| Looking at a comparison between common kernel structures and
| theoretical Rust implementations of those (like on
| https://security.googleblog.com/2021/04/rust-in-linux-
| kernel...) I think the kernel can get improved security and
| reliability from Rust without any "fancy" Rust. Just the basic
| type system improvements, nullability improvements and explicit
| checks will be enough for some real benefits.
| WesolyKubeczek wrote:
| > You also don't need async in many if not most cases,
| especially if you're writing kernel code.
|
| Have you seen how much communication with the hardware in
| drivers is actually very asynchronous? It's all hand rolled
| C, of course, but there's a lot of it.
|
| But look at the bright side: people likely won't be enjoying
| hand-rolling asynchronous Rust since language-level
| primitives exist, so maybe there will be enough pressure and
| enough of use case diversity to make a more solid
| implementation that doesn't suck, or sucks way less than the
| current one.
| nomel wrote:
| > It's all hand rolled C
|
| What do you consider "hand rolled"? The kernel has
| extensive support for these use cases since, as you said,
| hardware is usually async. Async with hardware is rarely
| tangled, from my limited experience. It's usually event
| driven.
| wongarsu wrote:
| Currently the rust ecosystem is rapidly moving towards
| treating tokio as the default-and-only async runtime. If
| the linux kernel community establishes an async runtime
| tuned for embedded/kernel use cases that could bring some
| much needed diversity and speed up the process of making
| async ergonomic and less bolted-on.
| dundarious wrote:
| I love zig, but neither dev nor stable releases are stable
| enough yet. Rust nightly builds are quite stable.
| belter wrote:
| Zig case is not compelling enough: https://www.scattered-
| thoughts.net/writing/how-safe-is-zig/
| goodpoint wrote:
| If anything, Nim would be an excellent candidate because it
| compiles to C, is memory safe and has no GC anymore.
| busterarm wrote:
| The zig community never made a huge fuss and initiated a
| mexican standoff by stating their refusal to continue working
| in C.
| usrn wrote:
| I think zig is a little too opinionated.
| vkazanov wrote:
| It is, indeed, opinionated. It's also small and easy.
|
| Rust is superopinionated. Big and complex as well.
| 127 wrote:
| Writing multi-line strings in Zig is not easy.
| vkazanov wrote:
| Huh? It might be slightly wordy, but otherwise very
| simple and easy for both people and computers to read.
| Even a primitive editor with primitive highlighting can
| make the syntax painless.
|
| Reasoning: https://github.com/ziglang/zig/issues/162
| kristoff_it wrote:
| I really don't understand why people have issues with
| Zig's multiline syntax. \\I really
| don't \\understand why people \\have
| issues with \\Zig's multiline syntax
| lostmsu wrote:
| I never used Zig, but used many other languages, and that
| looks better than most which don't have line prefix like
| \\\: in languages that don't need it there is confusion
| about significance of whitespace in the beginning of 2nd+
| lines.
| kristoff_it wrote:
| Yep, that's precisely what that sintax solves, and also
| makes it easier to build a grammar for it (think of
| editor syntax highlighting for example) because the
| multiline marker is repeated in every line, instead of
| being a contextual marker. This is the same reason why
| Zig doesn't have dedicated multiline comment syntax.
| usrn wrote:
| Yeah I'm not a fan of Rust either. It has some great ideas
| though. Part of me wants to try writing my own language
| after I finish my current side project.
| jeroenhd wrote:
| You may be interested in Jakt, an experimental language
| written for SerenityOS. It has some very Rust-like
| festures for memory safety but no borrow checker or async
| (at least, not at the moment).
|
| Currently, it compiles into C++ as it's written
| specifically for an entire operating system written in
| C++ but I can see native compilation becoming an option
| down the line.
|
| It's far from stable but it's worth looking at:
| https://github.com/SerenityOS/jakt
| oconnor663 wrote:
| Rust definitely has its opinions and its chosen
| complexities. I'd point to the way global allocators are
| used by default (opinionated) and the way trait coherence
| rules work (opinionated and kind of complicated). That
| said, I think a _lot_ of the complexity of Rust is actually
| fallout from a relatively small number of design choices:
|
| - programs ought to be UB-free by default, and overriding
| those defaults should be rare
|
| - mutation is allowed, including shared mutation across
| threads
|
| - runtime assumptions similar to C and C++, i.e. no garbage
| collector, and a useful subset of the lanugage doesn't
| require heap allocation
|
| Given those requirements (in short, a "safe systems
| programming language"), I think you very quickly find
| yourself needing 1) lifetimes, 2) the no-mutable-aliasing
| rule, and 3) move semantics. Those things contribute a lot
| of the "feel" of Rust, and probably the majority of the
| difficult learning curve. But I think it's interesting to
| consider that "the type system should deal with lifetimes"
| isn't really a baked-in opinion that Rust has, as much as
| it is the necessary complexity stemming from the other
| opinions above.
| ccbccccbbcccbb wrote:
| Compared to the tyrannical Rust, maybe.
| [deleted]
| Comevius wrote:
| Opinionated in the context of programming languages usually
| means that the language forces it's own abstractions on you,
| you have to work with and around them.
|
| Zig is not like that, it's pretty much just C, but simpler,
| ergonomic. It's design is a reasonably simple, portable
| abstraction of contemporary hardware. It gives you all the
| power to come up with your own abstractions on top of that.
| carlhjerpe wrote:
| I have no idea what I'm talking about, but rust can also be
| introduced gradually, and async isn't a language feature the
| kernel will use, actually the kernel will probably not even use
| the standard library because of how rust assumes it'll never
| run out of RAM.
| varajelle wrote:
| > and async isn't a language feature the kernel will use
|
| Why not thought? Lots of drivers could benefit from async to
| simplify their state machine as they wait for interrupt for
| example.
| monocasa wrote:
| Async is very good for only a specific kind of of state
| machine graph that isn't nearly as prevalent outside of
| network services.
| fathyb wrote:
| Rust is mainly introduced to the kernel to allow writing safer
| drivers, which makes a lot of sense considering a crashing
| driver likely means a crashing computer.
| easytiger wrote:
| I've ran Linux (various) for near on 20 years and ran it on
| hundreds servers for 15. I've only ever hit one such crash
| for an external piece of custom hardware with a noddy kernel
| module. Plenty of crashing kernel modules yea.
| jeroenhd wrote:
| I've run into many Linux driver bugs, usually for video
| drivers but sometimes for other components. On one laptop,
| AMD's kernel driver corrupted every third boot for a while,
| though that's been fixed. It's still dumping error messages
| and failures during boot but other than that it seems to
| work fine. On my new laptop, the kernel didn't even support
| my audio interface for a while.
|
| There was a bug with Intel GPUs that was unfixed for at
| least three kernel versions where plugging in an external
| monitor over an HDMI-to-Displayport adapter would reliably
| freeze the system the moment the kernel tried to modeset.
| That's finally been fixed from what I can tell, I believe
| it had something to do with a change to an NFS driver
| somehow.
|
| Server hardware often doesn't need complex or bleeding edge
| kernel modules. You don't need sound or video, you don't
| need framebuffer resolutions, you don't even need that much
| in terms of keyboard compatibility. It's a lot easier to
| run a kernel of the most complex hardware out there isn't
| hooked up to your system. That doesn't mean Linux is bug
| free, it merely means that the kernel code for the limited
| hardware of your choice has been maintained well.
|
| The real challenge for Linux or any kernel really is to run
| reliably on a laptop with an uncommon variation of common
| hardware, preferably sold for only a few months. That's
| where the real bugs come in.
| [deleted]
| WesolyKubeczek wrote:
| Lucky you to not have had to use the abomination that is
| any Realtek wireless card, because drivers for those were
| super-atrocious. I'm having problems with established good
| citizen stuff like amdgpu and i915 on a regular basis.
|
| (Frankly, I doubt that those would be resolved with Rust,
| or even if the developers all got attendants that would
| massage their feet.
|
| The GPU driver developers are hugely busy with cranking
| support for new cards, and bugs in the older cards support
| are rarely tended to, when they are it makes headlines. I
| blame skewed incentives.)
| eklavya wrote:
| You are extremely lucky. You probably don't need memory
| safety :)
| rkangel wrote:
| There are definitely kernel bugs, but yes they are
| relatively infrequent. It takes a lot of effort to achieve
| that though, and better tooling can help.
|
| There are also definitely kernel security problems (e.g.
| this from a quick google:
| https://www.cvedetails.com/vulnerability-
| list/vendor_id-33/p...). If Rust can eliminate a percentage
| of those then great.
| kobalsky wrote:
| there a incredible maintenance effort behind linux
| stability. memory safe languages like rust won't have a
| immediate measurable impact in the user experience of
| someone using an LTS Linux distribution, but they will, in
| the long term, improve the development cycle.
| ISV_Damocles wrote:
| Both of statements can be true, though. Developers skilled
| enough / brave enough to write kernel drivers can be very
| careful about not leaking memory or mismanaging the
| hardware in question, and Rust can make that job much
| easier by being pedantic about memory mistakes or type
| misuses (with custom types that are validated at compile
| time but no runtime overhead).
|
| I've worked on C and Rust codebases, though nothing near as
| complex as the Linux kernel, and I'm excited for this
| change as it will reduce the burden on the kernel
| developers to reach the same quality output, so we either
| get drivers faster, or drivers for hardware we wouldn't
| have otherwise received, or both.
|
| As far as the fear of Rust kernel drivers that don't
| compile with GCC's Rust frontend, I trust Linus to keep the
| bar high on letting this feature in, and that kernel
| drivers accepted into the tree compile with just GCC as
| they always have.
|
| Third-party drivers may not, but that's also true today if
| someone wrote a driver that only compiled with LLVM. This
| doesn't really happen in practice as it goes against the
| path-of-least-resistance for the developer: they'd have to
| switch their toolset out when working on that driver vs
| everything else, and the auto-building by DKMS would
| probably fail on them if they used it during development --
| all of the conventions used by the rest of the kernel
| infrastructure will keep them in line.
| kzrdude wrote:
| I'm just curious what would a panic!() in Rust kernel code
| look like - an oops log in dmesg? panics happen in Rust for
| example to handle indexing out of bounds errors with the
| default bounds checking or to guard against divide by zero.
| steveklabnik wrote:
| https://github.com/Rust-for-
| Linux/linux/blob/rust/rust/kerne...
| pornel wrote:
| The "async is bad" meme is getting old. Someone has written an
| article about JS's limitation (which Rust doesn't have) and how
| they don't like C# syntax, and it gets endlessly slapped on
| every language as a vague notion of "colors".
|
| Async in Rust is incredibly well designed, and works very well
| for such a low-level design that minimizes heap allocations and
| virtual dispatch. Rust intentionally prefers locally explicit
| syntax for things that affect control flow, and wants to be
| back-end agnostic without a runtime, which goes against
| implicit built-in "colorless" magic.
| kzrdude wrote:
| Zig would be if they wanted "C and generics and compile time
| evaluation", but maybe that does not seem compelling enough to
| the kernel.
| [deleted]
| adwn wrote:
| Huh. I submitted this story yesterday [1], and it hardly got any
| traction. Weird. Is there a "preferred" time to post HN
| submissions?
|
| [1] https://news.ycombinator.com/item?id=31832081
| narimoney wrote:
| why does it matter?
| adwn wrote:
| If I've found a story which I think would be of interest to
| many people, it makes sense to submit it in a way that
| maximizes the potential viewership.
| enriquto wrote:
| That's great. But please, no cargo! It would be horrifying!
|
| Also, having rust in a serious project like linux, (and omitting
| all the cargo madness), would be a great thing for the language.
| steveklabnik wrote:
| They're not using Cargo.
| enriquto wrote:
| So happy to hear that! I hope this starts a tradition of
| cargo-less rust that is sorely missing.
|
| Rationale: just like Rust does not let you segfault, a decent
| build system should not let you download shit from the
| internet. Much less so, without asking you explicit
| permission. Much less so, silently and by default.
| steveklabnik wrote:
| I strongly disagree on every count, but I'm glad you're
| happy.
| mllllv wrote:
| Totally agree. Not sure when downloading millions of lines
| of random code from the internet and executing it with
| essentially full permissions became a programmer virtue.
| mllllv wrote:
| jeroenhd wrote:
| I like Rust and I'd love to see it in the Linux kernel, but not
| before the GCC+Rust issues are all fixed. You shouldn't need non-
| GCC compilers to compile Linux and from what I can tell there
| isn't any GCC Rust compiler that's fully equivalent to the
| standard Rust compiler just yet.
|
| They say that Rust support is optional, but when the first big
| driver gets written in Rust it'll become mandatory. So either the
| Rust integration will fail and nothing important will get written
| in it, or it won't be optional. I'm not sure what comfort that's
| supposed to bring.
| humanwhosits wrote:
| This should really motivate the rust frontend for gcc though
| guerrilla wrote:
| Okay but think of it this way... maybe this is creating more
| demand for a GCC Rust compiler. Maybe it finally gives some
| people the excuse or funding to do what they need to do.
| rjsw wrote:
| Is there anything in the Linux kernel that can't be compiled
| with clang? There is plenty of experience with building BSD
| variants using it.
| ncmncm wrote:
| It's one thing to say developers have to add a new compiler
| front end for some drivers if they want to compile them; and,
| that some developers will just have to add it regardless.
|
| It is wholly another to say that they need adopt a whole
| different code-generation regime. It adds risk, and adds to
| what they need to understand to know what they are building.
| A pro needs to understand where problems come from, and be
| equipped to dig down to them.
|
| So, OK for hobbyists, but a burden for pros. It is the
| difference between "neat project, might succeed" and
| "mature". Rust stands a good chance of becoming mature in a
| few years, more than can be said about almost everything
| else.
| steveklabnik wrote:
| Historically, the answer to that was "yeah totally." But
| folks have put a lot of work into getting clang to build the
| kernel, and IIRC Google has been building their Android
| kernels with clang for a few years now.
|
| ~~It's not~~ (see below) It wasn't supported directly by
| upstream, and in fact historically was pretty much the
| opposite: the intention was to not care about portability
| between compilers at all.
| jyxent wrote:
| I think it is fully supported now:
| https://docs.kernel.org/kbuild/llvm.html
| steveklabnik wrote:
| Thank you! That's more than I knew of.
|
| (I do think that what "support" means is kind of amusing,
| I would also say that this counts as support, but above
| you have people arguing that only Rust's Tier 1 support
| is called "support"...)
| Tuna-Fish wrote:
| The initial work is just scaffolding that allows using Rust for
| some drivers, and projects intended to test said scaffolding.
| (Basically, rewrites of some drivers that are already in the
| kernel but that are not considered to be of the greatest of
| quality.)
|
| It will take quite a while yet before something important is
| made in Rust, and this early work can be done in parallel with
| the GCC-Rust work.
| Wowfunhappy wrote:
| There is talk of the Apple Silicon GPU driver being written
| in Rust, which I would say is non-trivial!
| Tuna-Fish wrote:
| Wow, I hadn't heard that. But ofc this doesn't limit
| platforms because the hardware is only available on ARM64.
| coldtea wrote:
| > _You shouldn 't need non-GCC compilers to compile Linux_
|
| Huh? What relationship the Linux kernel and GCC has?
|
| They're independent projects. It might be handy/nice/convenient
| to not need non-GCC compilers to compile Linux, but it's not
| like it's some license requirement or project obligation on
| behalf of Linux
| flohofwoe wrote:
| It should be rephrased to "Rust support in Linux shouldn't
| require two separate compiler toolchains", e.g. either the
| Rust toolchain can also compile the C parts, or the C
| toolchain can also compile the Rust parts (can Linux actually
| be built with a different C compiler than GCC yet? I thought
| it relies on specific GCC behaviour?)
| mauricioc wrote:
| This is not an equivalent rephrasing. Although I make some
| pragmatic compromises every now and then, I think the GNU
| mission is important, and historically Linux has been an
| important part of the GNU system. GCC's copyleft license is
| a big ideological advantage for me, and, although I like
| the _option_ of using LLVM, I think being _forced_ to use
| LLVM is a step backwards.
| monocasa wrote:
| It can be built with llvm too; there was a lot of work put
| into llvm to support gccisms.
| turbinerneiter wrote:
| It's a weird phrasing, but I agree on the compiler topic,
| maybe for other reasons: an important project like Linux
| should not really on a single compiler. I think it is good to
| have the ability to use either GCC or LLVM to build the
| kernel. That ensures that you don't accidentally rely on a
| compiler bug, no lock-in, ... .
|
| For C and C++ code you want to be able to build with
| different compilers.
|
| I think that also makes sense for Rust, the language and the
| compiler should be two separate things and there should be
| multiple compiler suppliers.
|
| Are there arguments why this would be less relevant for Rust
| than C?
| jcranmer wrote:
| Clang has been a viable compiler for only about a decade--a
| third of Linux's existence--and could itself build Linux
| only a few years ago. Prior to clang's existence, Linus is
| on record as saying that he didn't care about compatibility
| with other compilers, which at the time would have been
| something like Sun's C compiler.
|
| So it's very much against the historical policy of the
| Linux kernel to _not_ be tied into a single compiler, even
| if it is a welcome change in policy.
| R0b0t1 wrote:
| Moving Linux and FOSS away from GCC runs the risk of
| enabling the mass adoption in industry of LLVM/Clang and
| the drying up of open source commits to either project once
| Clang is in a place where it does not generally require
| community contributions.
| bitwize wrote:
| Linux has long been written to be compiled specifically with
| gcc, including the use of GNU extensions.
|
| If other compilers implement compatible features such that
| they can compile the kernel, fine. But gcc has been _the_
| supported compiler.
| sillystuff wrote:
| GCC supports quite a few more architectures than llvm.
| Kernels for these archs would not be able to use Rust in the
| current state. So, this will limit rust to platform specific
| drivers until either llvm is at parity for gcc for archs that
| linux is available on, or gcc's rust front-end is fully
| capable of compiling any rust code in the kernel.
|
| In addition to the large maintenance effort for llvm to
| support so many additional back-ends, there is a non-
| negligible number of folks who would be very opposed to being
| forced to use a non-gpl compliler to build a gpl kernel.
|
| https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Archit.
| ..
|
| https://en.wikipedia.org/wiki/LLVM#Back_ends
|
| https://en.wikipedia.org/wiki/List_of_Linux-
| supported_comput...
| nindalf wrote:
| The GCC story isn't that far behind - there are two
| complementary efforts to get GCC support into the Rust
| ecosystem.
|
| One is a Rust frontend to GCC (https://github.com/Rust-
| GCC/gccrs) while the other is a GCC backend to the existing
| Rust compiler (https://blog.antoyo.xyz/rustc_codegen_gcc-
| progress-report-12). It might take a while for these to bear
| fruit, but it'll be awesome when they do. That should address
| the very valid concern that the full Linux kernel won't compile
| for all supported architectures.
|
| And it's not really a problem that the GCC effort will take
| time. The headline of this article implies that the Rust
| integration is nearly done but it's only the beginning. Based
| on the issue tracker there's years of work left to get
| everything working perfectly. That's enough time to get GCC
| supported well.
| selckin wrote:
| Or that then gives people the motivation to work on gcc, have
| to solve the chicken-egg
| eterevsky wrote:
| I don't see why Rust usage in the kernel should be blocked by
| GCC of all things. Of course kernel has been traditionally
| compiled by GCC, but there was never a ban on any additional or
| alternative tools. There is a number of dependencies on things
| like make, bison and so on.
| esjeon wrote:
| * The kernel doesn't need all those new bells and whistles
| that Rust wants to offer in the future, at least not as fast
| as how they are being shipped.
|
| * The kernel requires stability. Building a kernel w/ rustc
| is like building a house on a flying bullet.
|
| * GCC is insanely good at porting to other architectures,
| something vendors have been relying on for a long long time.
|
| * Consistency in applying compile flags and optimizations.
|
| Idk, these are all I can think of right now.
| nindalf wrote:
| > least not as fast as how they are being shipped.
|
| Could you give some examples of big features from the last
| 12 months? I can't think of any big ones off hand. IIRC,
| just a large number of small improvements.
|
| > The kernel requires stability.
|
| I can't recall a new Rust release ever breaking existing
| code. Is this what you're talking about?
|
| > GCC
|
| Rust will have a GCC backend and/or frontend soon.
|
| > Consistency in applying compile flags and optimizations.
|
| Can't say much about this but I'm fairly sure the kernel
| devs won't let anything be merged until they're satisfied.
| We can trust them on this.
| busterarm wrote:
| You would care if you were on one of the dozen or so CPU
| architectures that would suddenly become unsupported.
| unrealhoang wrote:
| Probably the Rust code will be drivers for devices that are
| not compatible with non-rust supported architectures
| anyway.
| busterarm wrote:
| Also true, but there's a precedent for Rust developers &
| shipping their changes without regard for what's being
| deprecated. [1]
|
| [1]: like when PyPI cryptography first switched to Rust
| and broke ansible/openwrt/etc.
| ntoskrnl wrote:
| The Linux kernel takes backwards compatibility much more
| seriously than your typical Python package.
| busterarm wrote:
| The Linux kernel community and Rust community still
| aren't on the same page on things yet, as you'll learn by
| reading lwn regularly.
|
| We're just not there yet.
| nindalf wrote:
| Seems like Linus and Greg and a bunch of people who
| oversee technical decisions on the Linux kernel are on
| board though?
| humanwhosits wrote:
| And they can back-out/revert if they decide to as well
| merb wrote:
| ansible... btw. ansible breaks basically tons of stuff
| every release, so no matter if the pypi crytography broke
| ansible. ansible is already broke. heck they renamed
| their package in the most stupid way ever...
| Unklejoe wrote:
| If the drivers are for PCI or USB devices, then they
| would have probably worked for those unsupported
| architectures "for free" if they were written in C.
| nicoburns wrote:
| By the time these kind of drivers are being written in
| Rust, the gcc support will be there anyway.
| josefx wrote:
| I thought we are talking about Rust? Full official Tier 1
| support for aarch64 and x86, why would you even want more?
| That is two, and let me say it again TWO fully supported
| CPU architectures, that is twice as many as your average
| computer needs. Nobody needs dozens, certainly not someone
| who wants to be a Rockstar Rust dev. . /s
| btilly wrote:
| There are lots of cases where you want more. For example
| Google's secure boot for Pixel uses the Titan M security
| chip, which is a RISC-V architecture.
|
| Still, looking at
| https://llvm.org/docs/CompilerWriterInfo.html, it is hard
| to find an architecture that Clang won't support that is
| relevant to many people. And if someone does find one,
| well, Clang is open source and open to adding more
| architectures.
| kevin_thibedeau wrote:
| The majority of microprocessors deployed in the world are
| using neither of these platforms. Some of their
| developers like having a featureful compiler for them.
| superkuh wrote:
| Yup. And if you have to use the rustc compiler that means you
| cannot use the rustc compiler from your repositories. Rust
| changes in forwards incompatible ways so fast that rustc is
| literally out of date and unable to compile new Rust code in
| less than 3 months. It's not because Rust is inherently bad,
| it's just that the type of people who write in rust are
| bleeding edge types (for now) and have no consideration for
| forwards compatibility.
|
| They just assume you'll curl | rustup.whatever and install a
| new version of rustc every month from a third party website
| like _every single Rust guide suggests_. That 's not optimal
| for the linux kernel. But maybe kernel dev types won't be as
| bad as the typical bleeding edge rust dev.
|
| And given that rapid rate of change in Rust, I don't see how
| GCC can ever keep up. Maybe in 10 years when Rust is more
| stable.
| jcranmer wrote:
| > Rust changes in forwards incompatible ways so fast that
| rustc is literally out of date and unable to compile new Rust
| code in less than 3 months. It's not because Rust is
| inherently bad, it's just that the type of people who write
| in rust are bleeding edge types (for now) and have no
| consideration for forwards compatibility.
|
| Funnily enough, I'm using the rustc compiler from Debian
| repositories (who of course is not well-known for eagerness
| to adopt bleeding-edge), and I've not run into any Rust code
| that wouldn't work with that compiler.
| devmor wrote:
| That's because you're not specifically using programs built
| with brand new rust features and then complaining that you
| have to update the compiler to use them.
|
| You know, like a sane person.
| superkuh wrote:
| I installed Debian 11 before it was released officially.
| Its rustc was less than 3 months old. I personally ran into
| 2 rust programs I couldn't compile due to compiler forwards
| incompatibility within weeks. One example was the software
| defined radio program, plotsweep, if you want to look it up
| in cargo.
| nicoburns wrote:
| That's an application, not a library though. There's
| really no reason for an application not to require the
| latest compiler version if they so choose. There are
| definitely libraries that take this approach too, but
| they tend to be higher-level domain-specific ones.
|
| The foundational libraries in the ecosystem tend to take
| a much more conservative approach to MSRV (minimum
| supported rust version), supporting older Rust versions
| for as long as possible, and only bumping the version
| when new features that significantly improve the library
| are released (and often only once the versions
| implementing those features are packaged in stable
| releases of major distros).
|
| For example, the `rand` crate supports Rust versions down
| to 1.36 (released in July 2019) [0], the regex crate
| supports down to 1.41.1 (released Feb 2020) [1], etc.
|
| [0]: https://github.com/rust-random/rand#rust-version-
| requirement...
|
| [1]: https://github.com/rust-lang/regex#minimum-rust-
| version-poli...
| gspr wrote:
| > Funnily enough, I'm using the rustc compiler from Debian
| repositories (who of course is not well-known for eagerness
| to adopt bleeding-edge), and I've not run into any Rust
| code that wouldn't work with that compiler.
|
| Oh hey, there's two of us ;-)
|
| My shoulders relaxed significantly when I also put Cargo in
| offline mode, pointed it to the directory where Debian
| installs its librust-*-dev packages, and stopped
| downloading rapidly changing stuff off of crates.io.
| cmrdporcupine wrote:
| Alternatively the sheer weight of the Linux kernel's
| influence means that the GCC implementation of Rust becomes
| the dominant one, altering the way people install and manage
| Rust.
|
| Rust is good, but I also do not like the trend in every
| language and/or build system having its own package
| management with its own third party dependencies and its own
| custom installers separate from the distro. I understand the
| pragmatic problems this solves, but I think it has serious
| ramifications for reproducibility, security, auditing, etc.
| im3w1l wrote:
| Let's say for the sake of argument that I whipped up some
| software over the weekend. It's 9pm Sunday night and I want
| to publish my work so other people can play around with it.
| My friends being true nerds all have different opinions on
| which distro is the best.
|
| Let's consider my alternatives. 1. I can (and will) publish
| the source and give instructions on how to build it. This
| works but is a bit inconvenient for the user. They have to
| manually install and manually check for updates and
| manually install updates. 2. I can publish on language-
| package-manager. This is a simple and easy process. It can
| be figured out in less than 30 minutes. For the user they
| put the name of my project into a config file and that's
| it. 3. I can publish on top-5 system package managers. This
| will take days or maybe even weeks of labor.
|
| So basically, it's just not viable for hobbyists. It can
| only work for companies that pay people a salary to deal
| with it.
| ImprobableTruth wrote:
| The reproducibility story with system package managers is
| an absolute nightmare.
|
| In general, language package management systems,
| containerization and fully statically linked distributions
| (appimage, flatpak, snaps, etc.) are all a direct response
| to system package managers being woefully inadequate in all
| sorts of ways.
|
| And unless something like Nix takes over which actually
| allows reproducible builds, we'll continue to see
| alternative solutions continue to encroach on system
| package managers.
| cmrdporcupine wrote:
| Absolutely, I understand why these systems are there. And
| see the issue. The problem is the rapid propagation of
| them. There's too many, and they live outside the purvey
| of the distribution management, and often (... NPM, etc.)
| have poor auditing and moderation.
|
| I see why they happen. I don't blame the people to make
| them. I just think it's a potentially awkward situation
| when it comes to something as core as the kernel; which
| has traditionally only required GCC.
| jupp0r wrote:
| Rapid propagation? Fully statically linked binaries have
| been a thing for decades. The practice only got broken
| under most Linux distros when glibc decided to make it
| impossible to be linked against statically.
| corrral wrote:
| IMO distros shouldn't be packaging the world anymore,
| anyway. Base system from the distro, everything else from
| a separate, probably cross-distro package manager.
|
| The trouble, of course, is that this is hell for a Linux
| desktop system, because you can't cleanly put the GUI
| stack in either "base system" or "everything else",
| especially with all the shared libs and such.
| mamcx wrote:
| The problem of package managers is that are too many in too
| many OSes (and most varied on linux).
|
| Having one for Rust reduce a lot of complexity (Same
| operation across all OS), and is the best place to take
| decisions (Rust developers know Rust needs, debian ones who
| knows?).
| nextaccountic wrote:
| Rust actually works fine with distros. See for example
| https://github.com/kornelski/cargo-deb and
| https://wiki.archlinux.org/title/Rust_package_guidelines
|
| I use Arch Linux and Most Rust programs I use are installed
| from the Arch repositories or AUR. Rust packages are very
| well integrated with the distro, they depend on distro
| packages and have other packages depend on it. As far as
| the user is concerned, the Rust build system is just a
| developer-only stuff like CMake or autotools or ninja or
| whatever.
|
| Anyway I would like to point out that C++ also do something
| similar to what Rust libraries typically do, which is to
| use header-only libraries that don't appear as separate
| distro packages. It's as if every Rust library meant to be
| used by Rust programs (as opposed to libraries that expose
| a C API that can be called by other languages) were a
| header-only library. And this is actually great because
| Rust (like C++) monomorphizes generics, that is, if you
| call a generic function defined on another crate, the
| compiler actually generates a new function just with the
| type parameters you supplied, and there's no way the
| library can know upfront which generic instantiations will
| happen over all programs that use it.
|
| On the reproducibility front, I think it would be great if
| C program actually did what Rust does and pinned the exact
| damn versions of all libraries they use (like Cargo.toml
| does)
| jjice wrote:
| > it's just that the type of people who write in rust are
| bleeding edge types (for now) and have no consideration for
| forwards compatibility.
|
| Feels like a pretty blanket statement. I'd assume that they'd
| base the minimum version on Rust's editions. An edition is
| released every 3 years and is meant to be a solid LTS (as far
| as I'm aware) version of the language. If they use Rust 2021
| edition, you can tell the compiler that (like C89 vs C11) and
| it will reject code that's newer. C has plenty of newer stuff
| too that isn't allowed in kernel code at the moment as well.
| pornel wrote:
| Rust editions are nothing like C versions. They're
| orthogonal to language version. They're more like C
| trigraphs or -W flags.
|
| All new Rust features are available from all Rust editions.
| The 2015 edition has got new features 3 weeks ago, and will
| get more again in 3 weeks.
|
| Old Rust editions are only for backwards compatibility with
| old source code, e.g. to let it use names that became
| keywords later.
| Rusky wrote:
| Editions aren't that clear-cut- crates targeting old
| editions can still use most new language features, and all
| new library features. For example, the NLL borrow checker
| was originally enabled in the 2018 edition, but it's now
| available in 2015 as well.
|
| Editions are more designed to manage backwards-incompatible
| changes, like new keywords or tweaks to corner cases in the
| type system.
| jeroenhd wrote:
| Rust has language versions and you can specify the language
| version to use in your Cargo.toml file. This is possible
| today and it shouldn't pose a problem for the kernel at all
| as long as there are rules about what versions to support.
|
| You don't need a super modern version of the spec to use
| Rust.
|
| As for Rust's incompatibilities, as long as you stay clear
| from methods marked unstable and the nightly compiler
| versions you'll be fine. Rust's libraries have breaking
| changes, but the stable language features haven't had any
| since the 1.0 release as far as I'm aware.
|
| If your problem is forwards compatibility, well, you can't
| use clang10 to compile the kernel either. Sometimes the
| version gets bumped, but it doesn't need to happen too often.
| I think GCC's rust compiler will keep up just fine.
| vips7L wrote:
| Half of the ecosystem depends on the nightly compiler.
| smolder wrote:
| I dont't think "half" is accurate, at least not anymore.
| A lot of things have moved from Nightly to Stable
| compatibility with stabilization of async, for example.
| Rocket builds on stable now, while for a long time it
| didn't.
|
| I'd like to see the actual percentage but AFAIK it would
| take some analysis. Crates.io shows 86417 total crates,
| searching for "stable" shows 3346 and "nightly" shows
| 2527... So that's not a good heuristic, probably.
| steveklabnik wrote:
| It's impossible to deep link into a PDF, but the raw
| survey data from last year is out: https://blog.rust-
| lang.org/inside-rust/2022/06/21/survey-202...
|
| It shows that the vast majority of people use latest
| stable. A decent chunk also use nightly, and the reason
| why "a crate dependency I need requires it" is pretty far
| down the list of reasons.
|
| Oh and a pet theory: the way you feel about this is
| correlated with the kind of work you do. I'd you're
| writing an OS, you probably use nightly still, and so
| your dependencies probably do too. But if you're higher
| up the stack, where unsafe is less common and the
| appropriate language features are more filled out, you
| probably never use nightly. This makes talking past
| people unfortunately easy to do.)
|
| (n.b. I'm glad they released the raw data, because
| otherwise we wouldn't be able to share this, because it
| wasn't included in the blog post this year. I brought
| this up before publishing but my advice was ignored, oh
| well!)
| lifthrasiir wrote:
| I believe many browser-embedded PDF readers now support
| `page` fragments [1]:
| https://raw.githubusercontent.com/rust-
| lang/surveys/main/sur...
|
| [1] https://datatracker.ietf.org/doc/html/rfc8118#page-4
| steveklabnik wrote:
| Oh fun! Thanks.
| simlevesque wrote:
| Back in the days, before deep links... we'd just say the
| page number.
| rdsubhas wrote:
| Parent is saying the proportion is very high. It's not
| the exact number that matters. Even if one dependency
| your project uses needs nightly, then your entire project
| has to use nightly.
| woodruffw wrote:
| This is true, but you'd have to show that those nightly
| dependencies are relatively central to the Rust
| dependency graph (i.e., that lots of other things depend
| on them). To the best of my knowledge, that's not really
| the case (the really central dependencies in the Rust
| ecosystem are things like serde, libc, anyhow, etc. that
| all use the stable compiler).
|
| In my experience writing Rust professionally (including
| making heavy use of dependencies), I've only needed the
| nightly compiler once. And that was for our own code, not
| an external dependency.
| nindalf wrote:
| Less than 20% of devs use nightly. About a third of the
| devs who use nightly do it because of a dependency. 6-7%
| of Rust devs is a far cry from the "half" claimed by GP.
|
| https://github.com/rust-
| lang/surveys/raw/main/surveys/2021-a...
| TotempaaltJ wrote:
| I've not experienced this. I know it used to be very
| significant, but on my latest (and biggest) project that
| I've been working on for ~a year, I haven't run into any
| nightly-only packages that I couldn't easily do without.
| wongarsu wrote:
| That used to be true a couple years ago, but I don't
| think I've used a nightly compiler version at any point
| in the last 12 months.
|
| That said, I think for this first phase the kernel is
| planning on a specific stable version of the compiler
| with nightly features enabled, because they have a couple
| specific needs that haven't made it through the
| stabilization process yet.
| eternauta3k wrote:
| Would the kernel pull in any dependencies, or just
| reimplement everything like it currently does?
| bonzini wrote:
| It doesn't use cargo but it does use the core and alloc
| crates. Some parts such as Mutex are reimplemented for
| interoperability with C code.
| mkoubaa wrote:
| Do you really need to fix ALL the gcc rust issues ? The Linux
| kernel could disallow rust features that are known not to work
| in gcc
| bitwize wrote:
| We've known for some time now that the future would be written
| in Rust. If you do not have a Rust compiler in addition to a C
| compiler on your system, now is the time to consider installing
| one.
| kramerger wrote:
| Nope, everybody knows that the future will be coded in Jakt.
|
| Jokes aside, I bet Jakt (a completly new language) has
| introduced fewer language and compiler changes in the last 3
| months than Rust (5-10 years old now?).
| Deukhoofd wrote:
| Jakt has introduced far more language and compiler changes
| in the last 3 months, don't be silly. Like the entire thing
| has been written in Rust first in the last 3 months, and
| then was rewritten in Jakt. Those are massive changes!
| kramerger wrote:
| But how many language spec changes have there been during
| this time?
| kklimonda wrote:
| Probably all of them? Jakt repo isn't even 3 months old.
| jeroenhd wrote:
| Jakt still relies on Rust to compile the current standard
| of the language and the language spec is frozen until the
| Jakt compiler becomes self hosting. Even so, the spec is
| far from finished and the language will probably change
| weekly for weeks to come once the compiler has been
| finished.
|
| Rust's compatibility problems are quite irrelevant in my
| opinion. You can pin a language version and future
| compilers will still run your code as long as you don't use
| any explicitly unstable features (so no nightly compilers
| and no manually enabling unstable features). Yes, Rust
| moves faster compared to C's glacially slow language
| development, but almost every language does these days.
| Even C comes out with new versions every few years and C
| compiler versions get deprecated all the time.
| sophacles wrote:
| > You shouldn't need non-GCC compilers to compile Linux
|
| Why?
| 3836293648 wrote:
| I really like rust, but I really don't like how much adoption
| it's getting. Rust is better than basically everything else out
| there, but it still really feels like a stepping stone language
| during a time of rapid language development. Even single threaded
| synchronous rust has its issues and it really feels like one or
| two more steps will get us to a significantly better place and
| getting rust adopted everywhere will just come and bite us in the
| end.
|
| Also, GCC should fix their stupid libjitgcc so new languages can
| use it reasonably instead of making everyone use llvm and then
| complain that there is no gcc implementation
| rkangel wrote:
| I know what you mean - there is potential for something even
| better. That said, having something that actually _is_ better
| than C /C++, and having it become widely known accepted enough
| that I don't really have to justify using it at work is really
| good.
|
| And Rust will smooth the path for other language in the systems
| space. Rust had to work extra had because there has only be one
| dominant (pair of) languages for so long. Now that people have
| got used to choosing, hopefully it'll be easier next time for
| Rust++ or whatever.
| kllrnohj wrote:
| So you know rust is the best fit, but you don't like it because
| of... vague reasons? Rust is the first compelling systems
| language since C++. This isn't an area with much attention paid
| to it. What is this a stepping stone towards? Zig is the only
| other thing that seems to get brought up, but it's not bringing
| any new ideas to the table. Certainly nothing close to what
| Rust is doing with the lifecycle checker.
|
| But why should Linux, or anyone really, let future promises
| block meaningful improvements today? If something comes along
| that's better than Rust for this, then another
| adoption/migration process can happen.
| lostmsu wrote:
| Rust needs better debugging support. A huge gap is inability
| to call arbitrary trait methods in expression evaluators.
|
| The issue is really starting considering you can't even call
| Debug's fmt.
| monocasa wrote:
| Kernel developers aren't using a repl, and in fact straight
| up were hostile to kgdb to even attach a debugger for a
| long time.
| 3836293648 wrote:
| Maybe it's because I just started paying attention recently,
| but I'm seeing new approaches to the memory safety issue on
| r/ProgrammingLanguages every other week. Just off the top of
| my head, Vale looks interesting. But it's clearly under
| active research, even if it's not super visible
| vkazanov wrote:
| And what is wrong with libgccjit? It's not hugely popular, yes,
| but there are some use examples, i.e. Emacs.
| 3836293648 wrote:
| Documentation and the number of patches every project I've
| seen try to use it has needed to send.
| the_duke wrote:
| I get your point, and I'm sympathetic because I had similar
| thoughts.
|
| But building a successful language and ecosystem takes a
| combination of visionary initiators, dedicated contributors,
| money, a significant value add, luck , and lots of time.
|
| Rust has warts that could be done better by a newer language.
| There are some interesting experiments, but I don't know of any
| language that would fit the bill right now.
|
| And if that language emerges it will need many years and
| probably a corporate backer to reach the level of maturity
| required for critical workloads like the kernel.
|
| The world shouldn't be limited to C for another 10 years.
| ncmncm wrote:
| It is correct to suspect that Rust will turn out to be a
| transitional language. If Rust fizzled (still very possible!)
| it would be embarrassing, and maybe troublesome.
| adamius wrote:
| Lua would be good. Device drivers need not be all about high
| performance especially for initial development. Lua would be fast
| enough for plenty of purposes.
| nequo wrote:
| NetBSD has Lua support.[1] Unfortunately there doesn't seem to
| be a lot of published material on it. One interesting
| application I found was secmodel_sandbox[2] which used it to
| implement something similar to AppArmor.
|
| [1] https://www.netbsd.org/~lneto/bsdconbr15.pdf
|
| [2] https://github.com/smherwig/netbsd-sandbox
| phendrenad2 wrote:
| FreeBSD also.
| nequo wrote:
| My understanding is that FreeBSD only uses Lua in the
| bootloader. Has it made its way into the kernel too?
| [deleted]
| dgb23 wrote:
| EDIT: It is very bit unfortunate that my general/off-topic
| comment is currently the most upvoted. I was not commenting on
| the Linux integration specifically. I'm a _novice and hobbyist_
| when it comes to Rust.
|
| For example this comment
| https://news.ycombinator.com/item?id=31849071 is much more
| interesting and on topic.
|
| ---
|
| I want to provoke a little bit, but I'm genuinely curious about
| the following:
|
| I feel like the Rust ecosystem is still quite immature in a lot
| of areas. Just a few indicators to illustrate what I mean:
|
| - Both async/await and the question mark operator feel like
| rushed implementations, neither seem like the best long term
| solutions for Rust and are not in line with the otherwise solid
| foundation of the language.
|
| - Open source code examples sometimes use an array of external
| dependencies that are unrelated to a given project and feel
| arbitrary. This reminds me of the JS ecosystem.
|
| - Some projects pride themselves to not use "unsafe" code,
| including linking with battle tested C code, which seems like an
| arbitrary restriction that sounds better than it actually is.
| There is even an open source maintainer that got mobbed out from
| his own project because he used "unsafe" in places that others
| didn't agree with.
|
| - Rust is fashionable. Putting "Rust" next to a HN title
| immediately gets clicks and upvotes. SO surveys and similar
| report high interest in the language. This is not an inherently
| bad thing, quite the opposite. But as a secondary effect it might
| detract from objective, technical decision making.
|
| I really like the language, I have _way_ more good things to say
| about it than bad things. But am I alone in feeling like this?
| Other modern language communities come with a philosophy that
| promotes stability and simplicity. Is the Rust community riding
| on the merits of Rust's unique value proposition, while
| forgetting some important fundamentals?
| atoav wrote:
| One thing on the plus site: a tech blogger was calling out a
| tournament for the fastest string tokenizer in any language. I
| wrote a very naive Rust tokenizer in 5 minutes max and it
| easily won second place. First place was a highly optimized
| assembler code.
|
| I am not sure the assembler thing would handle UTF-8 as well as
| my incredibly low effort Rust solution tho.
|
| What I want to say with this is: There are _real_ , tangible
| advantages to the language when some noob who would shoot
| himself into the leg three times while writing the C/C++
| equivalent manages to write safe code that performs well while
| not investing a lot of time.
| sharedptr wrote:
| This example requires seeing both submissions for C and C++
| to compare on their actual speed with the Rust one though
| nindalf wrote:
| > objective, technical decision making
|
| There have been several carefully planned iterations of the
| Rust for Linux effort. Every iteration has addressed some
| feedback from senior kernel developers including Linus
| Torvalds. The Rust for Linux folks then worked with the Rust
| project to introduce these features slowly into Rust. An
| example of such a change is fallible memory allocation. These
| iteration cycles have been happening for _years_.
|
| Check out the issues, especially the "wanted features and
| bugfixes" for each rust component (https://github.com/Rust-for-
| Linux/linux/issues?page=2&q=is%3...) for more details into all
| the work that's happened here.
|
| Throughout I have seen nothing but professionalism, courtesy
| and hard work from all parties involved here - the kernel devs,
| the Rust for Linux devs and the Rust project devs.
|
| You do them all a disservice by implying that this decision was
| taken without "objective, technical decision making".
|
| > not linking with C code
|
| I would need specific examples of C code being better than the
| Rust equivalent but people using the Rust equivalent anyway. I
| can give several counter examples. Such as libgit2, a C library
| with Rust bindings. It is widely used in the Rust ecosystem,
| including by the Rust project itself instead of the nascent
| gitoxide project. This shows pragmatism.
|
| There are other examples of projects being rewritten in Rust
| but usually that's ends up with the Rust version being very
| good. Such as when the maintainer of rsvg rewrote it in Rust.
| Look at the test suite results
| (https://github.com/RazrFalcon/resvg).
|
| Or when someone wrote a text search tool (ripgrep) in pure Rust
| instead of using PCRE bindings. Look at the benchmarks (https:/
| /github.com/BurntSushi/ripgrep/blob/master/benchsuite...) -
| it's faster than any competing tool on nearly all of them. If
| you've used search in VSCode, you were using ripgrep.
|
| Or when someone wrote a pure Rust crypto library rustls when
| OpenSSL bindings exist. I believe the results of the security
| audit speak for themselves (https://github.com/rustls/rustls/bl
| ob/main/audit/TLS-01-repo...). See the comments on code quality
| - "Cure53 was unable to uncover any application-breaking
| security flaws. After spending thirty days on the scope in late
| May and early June of 2020, the team of auditors considered the
| general code quality to be exceptional and can attest to a
| solid impression left consistently by all scope items.
| Naturally, this is partially thanks to the usage of Rust as the
| preferred language for the entire implementation of the rustls
| project"
|
| These examples show that when good developers rewrite something
| in Rust, we all benefit from the results. If you have an
| example of a Rust rewrite giving worse results, and being
| adopted over the C bindings, that would be helpful. I can't
| recall any such instance offhand.
|
| > Open source code examples sometimes use an array of external
| dependencies that are unrelated to a given project and feel
| arbitrary. This reminds me of the JS ecosystem.
|
| Could you give examples? From what I've seen Rust library
| authors take care to only pull in what's necessary. I'd be
| interested to see these libraries that pull in "unrelated"
| dependencies.
|
| Note, developing in Rust doesn't suddenly make mediocre code
| great. I'm sure there's mediocre code out there, just like
| there is in _every_ single ecosystem. The question is, can you
| get stuff done while only sticking to high quality
| dependencies? I think you can.
|
| > async-await and question mark.
|
| There is a language strangeness budget each language gets to
| use. Use up too much of the budget and the language feels alien
| to newcomers.
|
| Rust already introduces new strange things like lifetimes. New
| syntax like the question mark and _post-fix_ await strain the
| budget further. I'll admit, it's hard for new people. But I
| also think this syntax pulls it's weight. This is subjective
| and reasonable people can disagree.
|
| That said, these syntax decisions are set in stone. I wouldn't
| wait in the hope that they might change.
| dgb23 wrote:
| Thank you for the detailed response. Some of the points are
| reassuring and/or interesting.
|
| Just wanted to comment shortly on this:
|
| > Could you give examples? From what I've seen Rust library
| authors take care to only pull in what's necessary. I'd be
| interested to see these libraries that pull in "unrelated"
| dependencies.
|
| I would hate to call out specific authors and crates. I would
| rather see a general awareness and discussion around the
| issue. Your comment is reassuring though.
| nindalf wrote:
| > I would hate to call out specific authors and crates
|
| Yeah I feel you. No need to call anyone out when they're
| just putting out their work for free for us to use.
|
| That said, I think generally the code that I've seen is
| good quality. Everyone uses rustfmt, everyone tries to
| address clippy lints. I've seen PRs in popular libraries
| dropping optional libraries to get slimmer. Rust libraries
| aren't perfect, but they're pretty good.
| pas wrote:
| > post-fix await
|
| For Scala devs this is the sane way :) (Or for anyone who
| likes RPN ^^) [Or for anyone who simply encountered a bit too
| many "(await (await x.y).z).w" expressions in other
| languages.]
| mejutoco wrote:
| > Some projects pride themselves to not use "unsafe" code
|
| This is normal? not having unsafe code does not guarantee
| absence of bugs, but at least it isolates the problematic bits
| in the sections marked as unsafe.
|
| If you need unsafe, you can always use unsafe.
|
| Battle tested codebases like bind or openssh -- and many
| others, independently of the language of implementation -- had
| bugs in the past. It always helps to have extra assurances.
| Using safe/Unsafe is one more tool to have assurances.
| Fiahil wrote:
| > - Both async/await [...] feel like rushed implementations
|
| This is a recurring comment, but I would argue that it's not
| "rushed" but rather "incomplete" from supporting ecosystem
| (like a futures library being reactor-agnostic).
|
| Async/Await is great for a couple of things, but not a silver
| bullet. So, apart from high-throughput network applications,
| (like web/app servers), you should stick to regular threads and
| channels. You can leverage Actor-based concurrency in your
| program that isn't async.
|
| > - Rust is fashionable.
|
| Because it's genuinely great ! I've been writing Rust code
| since 2018, and at that time "Golang" in titles would get all
| the hype. I get the urge to keep things as a secret underground
| in a true Hacker spirit. Relax : nobody is going to spoil Rust
| and Rust isn't going to become a new Javascript.
| gspr wrote:
| While I love Rust, I think you're spot on with your concerns
| (apart from the questionmark operator - it's just delicious
| pragmatic convenience).
|
| The culture of exploding dependency trees is a recipe for
| disaster, especially when combined with the prevailing attitude
| of "use the latest version or bust".
| cmrdporcupine wrote:
| Yeah, I've been down this road before with Java + Maven 10-15
| years ago. Exploding dependency trees, DLL hell, etc. And I
| see it in the (admittedly mostly foreign to me) Node/NPM
| world. Quantities of third party dependencies with their own
| graphs can be trouble. At least with Maven there was a
| publishing/vetting process.
|
| Still, it makes dev a lot easier.
| jtdowney wrote:
| > - Both async/await and the question mark operator feel like
| rushed implementations, neither seem like the best long term
| solutions for Rust and are not in line with the otherwise solid
| foundation of the language.
|
| I'd disagree with both of these. They may not be to your style
| but that doesn't make them rushed. Both features had long
| debates around their adoption.
|
| > - Open source code examples sometimes use an array of
| external dependencies that are unrelated to a given project and
| feel arbitrary. This reminds me of the JS ecosystem.
|
| That is irrelevant to this project. You should read the rust
| kernel docs to see why.
|
| > - Some projects pride themselves to not use "unsafe" code,
| including linking with battle tested C code, which seems like
| an arbitrary restriction that sounds better than it actually
| is. There is even an open source maintainer that got mobbed out
| from his own project because he used "unsafe" in places that
| others didn't agree with.
|
| Also irrelevant. This may be a criticism of Rust but it in no
| way affects how rust may be adopted into linux.
|
| > - Rust is fashionable. Putting "Rust" next to a HN title
| immediately gets clicks and upvotes. SO surveys and similar
| report high interest in the language. This is not an inherently
| bad thing, quite the opposite. But as a secondary effect it
| might detract from objective, technical decision making.
|
| Linus is famous for doing fashionable things and forgoing
| technical decision making.
| ncmncm wrote:
| In particular, Rust has every single thing that Linus
| famously hated about C++, and lots more in that vein,
| besides.
|
| Has he changed his mind about those things? Or does he not
| realize they are there, and that kernel code will use them?
| bragr wrote:
| I'd encourage you to go read the project docs in the kernel for
| this. This rust project has been ongoing for years and I
| believe the documentation and discussion there addresses all
| the issues you raise. This is not a knee jerk "fashionable"
| decision.
| belter wrote:
| Plus the whole issue of Cargo namespace squatting...
|
| https://users.rust-lang.org/t/name-squatting-on-the-crates-i...
| baby wrote:
| How is that an issue?
| mcdonje wrote:
| If you have a good solution to rent-seeking, a great many
| marketplaces would benefit.
| dgb23 wrote:
| Composite namespaces. Like "mcdonje/fourtytwo" or
| "com.acme/http".
| cyborgx7 wrote:
| Not giving out real estate on a "first come-first serve
| basis" but actively moderating the allotment of real
| estate.
| dutchmartin wrote:
| I've seen and reported those squads and the admins did
| properly address those.
| icambron wrote:
| What's your complaint about the question mark operator?
| dgb23 wrote:
| In of itself it seems like a very nice feature.
|
| However it represents something that I don't like, which is
| trading language surface complexity and readability for
| programmer convenience. It is not something that gives you
| more power, just something that makes code a bit easier to
| write. Also there was seemingly not that much push-back
| against the feature which makes me a bit uneasy. Not sure why
| that is to be honest.
|
| I don't want to start a discussion about the question mark
| operator specifically. That's not important to me. What I
| like to gauge is the general culture around the language
| itself and the community around it. Half devil's advocate,
| half uncertainty driven.
| ntoskrnl wrote:
| > trading language surface complexity and readability for
| programmer convenience
|
| I would say the question mark improves readability,
| compared to having to check/return error codes by hand
| after every function call.
|
| To your more general point, the language is pretty much
| established and syntax features are added very rarely. I
| think one more feature, let guards, is coming down the pipe
| soon, but other than that I wouldn't be surprised if the
| surface syntax never changes again.
| mmarq wrote:
| > I would say the question mark improves readability,
| compared to having to check/return error codes by hand
| after every function call.
|
| Which is one of my complaints about Go.
| result, err = doSomething(); if err != nil {
| ... } result, err = doSomething2();
| if err != nil { ... }
| Fiahil wrote:
| > However it represents something that I don't like, which
| is trading language surface complexity and readability for
| programmer convenience.
|
| In this case it's a welcomed convenience. Have you used
| `thiserror` and `anyhow` crates ? They may alter your
| judgement on that point.
| bigbillheck wrote:
| > It is not something that gives you more power, just
| something that makes code a bit easier to write.
|
| Who needs a for loop when you have while?
| dgb23 wrote:
| For and while have different semantics. For is not just
| sugar for a while loop, it means something more specific
| and restricted than a general while.
| jeffparsons wrote:
| For _is_ "just sugar for a while loop". In fact, here's
| the Rust documentation detailing what a `for` loop "de-
| sugars" down to: http://doc.rust-
| lang.org/nightly/std/iter/#for-loops-and-int...
|
| > it means something more specific and restricted than a
| general while
|
| Sure, but that's still sugar. That's what sugar is.
|
| Want to know something really crazy? In Rust, the `if`
| keyword is also just syntactic sugar over `match`. Still
| finding bits of grey matter on the walls from when I
| learned that one.
| jeffparsons wrote:
| `while`? That's just sugar on top of `loop` that
| automatically inserts an `if` and a `break` for you.
| Don't be lazy, spell it out.
|
| (Although, in Rust, `if` is also actually just sugar over
| `match`, so, uh...)
| bonzini wrote:
| It's not extensible (the `Try` trait is unstable) but this is
| being worked on, see https://github.com/rust-
| lang/rfcs/blob/master/text/3058-try-....
| PointyFluff wrote:
| There's a lot of commenters here who have no idea how rust works,
| apparently.
| IYasha wrote:
| This is my humble opinion, but kernel shouldn't be a place for
| language diversity. Even code comments should be standardized for
| such critical and complex project with so many participants.
| speed_spread wrote:
| Adding bindings for a second language after 25 years is not
| what I'd call "diversity".
| cesarb wrote:
| > Adding bindings for a second language after 25 years is not
| what I'd call "diversity".
|
| Actually, a third language. The Linux kernel already has two:
| C and assembly.
| guipsp wrote:
| Only if you consider all assemblies to be the same!
| Otherwise, many, many more.
| ansible wrote:
| And being stuck forever with a language that was invented
| over 50 years ago doesn't seem like a good idea either. If we
| want to take full advantage of the last half-century of PL
| research, we should just abandon Linux at some point and go
| with a completely new codebase instead? (Actually, that
| sounds kinda good to me, but I get why that may not be the
| best decision.)
| tsujp wrote:
| I feel like the crux of your argument here is that because
| C is 50 years old and research into programming languages
| has occurred in that same 50 year period that C is now
| automatically bad.
|
| What if there's nothing wrong with its intended purpose?
| The wheel has been around for some time, there has been
| research into other axle-mounted components surely we
| replace the wheel then?
|
| I don't understand the "it's old therefore bad" argument.
| woodruffw wrote:
| > I don't understand the "it's old therefore bad"
| argument.
|
| It's a bad argument, _and_ it 's not the argument the
| person you're replying to is making.
|
| C is bad for reasons that are _mostly_ disconnected to
| its age. Better languages were written in the 1960s and
| 1970s, and worse languages are written today. What the GP
| is saying is that C has not _meaningfully improved_ over
| the last half century.
| ansible wrote:
| > _I feel like the crux of your argument here is that
| because C is 50 years old and research into programming
| languages has occurred in that same 50 year period that C
| is now automatically bad._ > > _What if there 's nothing
| wrong with its intended purpose?_
|
| So is it your position that C is the pinnacle of systems
| programming languages? That no significant improvement in
| PLs has been made... that could ever be made?
|
| I'm a Rust fanboi, but I totally get why some people
| don't like it. And why many people believe that something
| better (in one or more different directions) is possible.
| Or that something else would an even better fit for Linux
| kernel development.
|
| If the formally proven stuff gets more traction, I'd
| likely jump ship to something like that. Though a lot,
| lot of work needs to be done there, especially when
| talking about interacting with hardware... such a
| headache. But if our base computing infrastructure could
| be proven to be correct (hardware and software), that
| could dramatically improve the entire software ecosystem.
| There would still be problems, but if we can at least
| move them up a level or two in the software stack, we
| have an easier time finding and fixing them. This is the
| difference between the Spectre attack and leaving the
| permissions for a password file wide open.
|
| I don't know what a better future is going to look like
| exactly, but I know that we're not going to get there
| with just good old C code.
| Banana699 wrote:
| C is, in fact, bad. The moment it was released. It's so
| bad that one of the designers of Algol once quipped
| "Algol60 was an improvement over many of its
| predecessors, and many of its successors"[1], I had no
| doubt C was at the forefront of his mind when he said
| that. It was already a decade old when it was first
| released. Its wide use is a textbook example of path
| dependence and fashion worship that plagues software
| engineering, because it was distributed freely along with
| Unix, and Unix was the hot new free thing.
|
| GP was just emphasizing how old and crumbling that fossil
| is with the 50 years old remark.
|
| >What if there's nothing wrong with its intended purpose
|
| And what, exactly, _is_ its intended purpose ? It was to
| rewrite a 10K LOC kernel maintained by a core team of 3
| developers from PDP-7 assembly, in an age before the
| personal computer and the internet. It was literally
| created as an ad hoc, bug ridden and unspecified
| implementation, starting with the thinnest dressing over
| assembly and adding the absolute bare minimum required
| for a human to write ~10K LOC without gouging their own
| eyes off.
|
| There is plenty wrong with it.
|
| >I don't understand the "it's old therefore bad"
| argument.
|
| It's easy. Fields where there are progress invalidates
| and supersede their own widsom. You wouldn't go to a
| doctor trained 50 years ago if you could help it. You
| wouldn't drive a car made 50 years ago. The only fields
| where that's not the case is stagnating one, like
| building houses or making furnitures. Things where
| 'progress' consists of irrelevant-to-quality changes.
|
| Programming language design is in the first category, and
| not the second. Especially in the period from 1975 to
| 2000, it learned and discovered so much that languages
| made before that period might as well be cave man
| scribbling on cave walls.
|
| [1] https://quotepark.com/quotes/1741351-c-a-r-hoare-
| about-algol...
| trasz wrote:
| You're assuming that newer stuff is always better.
| Experiences with operating systems don't quite confirm
| this, though. There has been plenty of operating systems
| in newer languages, and nobody remembers them.
| tester756 wrote:
| And the reason of that is language choice?
| ahahahahah wrote:
| Isn't parent's very first line, in fact, about how a
| newer thing was much much worse?
| acuozzo wrote:
| Given the state of undefined behavior in the standard,
| I'm inclined to agree with you.
|
| With that being said, can you recommend a modern language
| designed around a model of computation flexible enough to
| target e.g. non-flat memory models?
|
| I'm additionally interested in targeting MCUs with no
| ISA-supported stack and ~2KiB of RAM.
| ahtihn wrote:
| > What if there's nothing wrong with its intended
| purpose?
|
| But there is. See the long, long, so very long list of
| vulnerabilities caused by incorrect memory management.
| onpensionsterm wrote:
| Drivers are the wild-west
| tmountain wrote:
| Does anyone have context on how Rust will make its way into the
| kernel? I'd imagine the initial motions will be pointed towards
| allowing Rust code to build alongside the existing C codebase
| without friction. Is the intent to incrementally introduce new
| modules and subsystems in Rust after that? Is there an end goal
| to rewrite everything in Rust?
| Tuna-Fish wrote:
| The initial project is to build a shim out of unsafe rust that
| allows drivers to be written in entirely safe rust. Nothing
| else is targeted yet.
| tmountain wrote:
| Ah, okay, that makes sense.
| kryptiskt wrote:
| I'm pretty sure that something like Android would start out as
| the first users, as they are interested and it doesn't run on
| any architecture that lacks Rust.
|
| There is no plans to bring it into the core of Linux.
| nicoburns wrote:
| That and Asahi Linux (which similarly only targets hardware
| with good Rust support). The developer who has been working
| on reverse engineering the Apple Silicon GPU seems to be very
| seriously considering writing the linux kernel driver in in
| Rust.
| cmrdporcupine wrote:
| As other commenters have poked at; I'd hope that if Rust is going
| into the kernel (even if just for drivers), that means it's
| hopefully hopefully started to "calm down" as a language.
|
| At least in regards to the features that affect kernel-level
| development. Stabilizing that doesn't preclude active development
| in things like async or in the standard library (both of which
| I'd expect not to see much or any use in the kernel.) But I'd
| hope for decent work towards backwards and forwards compatibility
| in the set of language features used there.
| nindalf wrote:
| > At least in regards to the features that affect kernel-level
| development.
|
| Strange you should mention this because they've been working on
| and will continue to work features to make Rust more suitable
| to the Linux kernel. This issue (https://github.com/Rust-for-
| Linux/linux/issues/355) for features in rustc was opened a year
| ago and it seems half done.
|
| > backwards and forwards compatibility
|
| Backwards compatibility has existed for 7 years, since Rust
| 1.0. If your code ever compiled under any version of Rust since
| 1.0, it will compile with all future versions. Guaranteed.
|
| Forwards compatibility - not sure how this would be guaranteed.
| If your code uses a new library API, how would an old tool
| chain compile that? AFAIK, this is a non goal.
|
| > calm down
|
| I think it calmed down after async stabilised 4 years ago. I
| don't recall seeing big changes since then.
|
| On a broader note, Rust's 6-week release cycle might make it
| _seem_ like big features are being added all the time, but I
| don't think this is the case. It's usually just a few small
| features or conveniences, some bug fixes, minor improvements to
| compile times.
| mllllv wrote:
| It hasn't. Rust is 12 years old, has no specification,
| incomplete documentation, a borrow checker that won't allow
| some valid code today but may allow that same code tomorrow,
| and a level of complexity that is seriously next level. It's
| about as calm as C++ on cocaine in my opinion.
| phendrenad2 wrote:
| I expect that Rust will kind of fork, like Python 2.x vs 3.x
| (remember that?). We'll have "stable Linux rust" and "move-
| fast-and-break-things meme Rust". Those of us who value
| stability will say "Thank you Linus Torvalds" and just use
| the "Linux rust" for everything.
| nindalf wrote:
| Could you give an example of a Rust release breaking
| existing compiling code? The Rust Project goes to great
| lengths to avoid this. For example, before every release
| they try to compile every open source Rust codebase with
| the release candidate compiler.
| tamrix wrote:
| Time to fork?
|
| I'm going to call the new c only Linux cinux
| ThinkBeat wrote:
| I think this is a bad idea or at least far too soon.
|
| In my opinion the Rust language and eco system is not yet at the
| stability of C.
|
| I feel certain that mixing two different languages inside the
| kernel will give all new and challenging errors to debug.
|
| Also it is the fallacy of sunken cost.
|
| So much work has gone into the Linux kernel, but efforts should
| be made to replace it.
|
| What I would like to see is a project to create a new and modern
| kernel, taking a lot of what has been learned by the "prototype"
| Linux kernel and create something new and better.
|
| It would also be free to take full advantage of the language
| improvements between Rust and C.
|
| Sure it would take a lot of time, but I think it is time well
| invested, instead of slowing trying to port the current Linux
| kernel to Rust.
| titzer wrote:
| If the internal APIs of the Linux kernel were boiled down to
| WebAssembly, then many kernel modules and drivers could be
| written in any language and cheaply isolated, making it harder,
| maybe impossible to corrupt kernel memory. IMHO that would lead
| to a more modular, robust kernel with lots of options for
| programming it, without resorting to a full microkernel design
| that has costly IPC.
| Skunkleton wrote:
| You would be interested to know that this already exists in the
| form of BPF.
| titzer wrote:
| With Wasm you could use any fully-featured programming
| language that compiles to Wasm, rather than severely-
| restricted and stylized C with a single toolchain that can
| generate BPF bytecode. Wasm has a formal specification and
| many high-performance implementations with near-native
| performance. BPF predated Wasm by a lot, yet not being a
| general purpose bytecode, hasn't had the engineering time
| invested that Wasm has.
| born-jre wrote:
| from my limited understanding bpf is not general propose by
| design, like disallowing infinite loops etc. otherwise
| people have been designing competent bytecode/vm since
| 90's.
|
| wasm kernel extension does sounds nice, especially after
| the meltdown and spectre.
| [deleted]
___________________________________________________________________
(page generated 2022-06-23 23:01 UTC)