• jeroenhd 12 days ago
    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.

    • nindalf 12 days ago
      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.

      • arinlen 12 days ago
        > It might take a while for these to bear fruit, (...)

        That's the problem. There are no GCC-based Rust compilers, nor is there a fixed timeline for one to be delivered, specially in the short term.

        Therefore, as the OP pointed out, as things stand either Rust in the Linux kernel is dead in the water or it poses a major problem for the Linux community.

        • nindalf 11 days ago
          I don’t know who this “Linux community” is that doesn’t include Linus or Greg or other senior developers that have been working with the Rust for Linux folks for more than a year. They don’t think it’s “dead in the water”.

          Let’s assume for a second that Linus knows what he’s doing. Now look at his mail from April 2021 on what he views as show stoppers (https://lkml.org/lkml/2021/4/14/1099) - OOM panics and 128-bit floating point. The former has been fixed now, which is why Linus appears bullish on adding Rust support to the kernel. Check that mail for the number of times Linus mentions GCC - 0. It’s not a priority for him.

          It’s easy to see why. He (and everyone else involved) are very clear that this will only be used for driver code on architectures that were already supported. So therefore, there is no need to supply a GCC compiler in the short term.

          I pointed out two long term efforts to get GCC Rust support. These could unblock more widespread use of Rust in the kernel, but that’s jumping the gun. Let’s see even one real driver merged before thinking about that.

          Whatever happens, the Linux developers won’t let the project break for millions of users overnight. That’s not how they operate. Your “Linux community” should know that.

      • Tuna-Fish 12 days ago
        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 12 days ago
          There is talk of the Apple Silicon GPU driver being written in Rust, which I would say is non-trivial!
          • Tuna-Fish 12 days ago
            Wow, I hadn't heard that. But ofc this doesn't limit platforms because the hardware is only available on ARM64.
        • superkuh 12 days ago
          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.

          • jeroenhd 12 days ago
            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 12 days ago
              Half of the ecosystem depends on the nightly compiler.
              • smolder 12 days ago
                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 12 days ago
                  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!)

                • rdsubhas 12 days ago
                  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.
                  • nindalf 12 days ago
                    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.


                    • arinlen 11 days ago
                      > Less than 20% of devs use nightly.

                      You tried to make that sound like few Rust developers use nightly, but the same survey you linked to states that, while 7449 said they use the latest stable version for local development, 3333 said they use nightly, with 2853of them using the latest nightly and 481 using a specific version of nightly.

                      All in all, the ratio of Rust developers targeting nightly releases or betas represents something in between a third and a quarter of the whole developer community.

                      That's a lot of people in the Rust community delivering code targeting unstable and unmaintainable releases.

                      • nindalf 11 days ago
                        > unmaintainable releases

                        How did you come to this conclusion? Seems like it must be working for them, because most of them are using nightly out of choice.

                        Plus it’s a service to the community. Their everyday testing helps make the stable releases better. Imagine if no one used nightly - that would be much worse.

                    • woodruffw 12 days ago
                      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.

                  • wongarsu 12 days ago
                    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.

                    • TotempaaltJ 12 days ago
                      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.
                      • ungamedplayer 12 days ago
                        Almost none of that ecosystem is relevant to kernel.
                        • arinlen 11 days ago
                          > Almost none of that ecosystem is relevant to kernel.

                          What exactly leads you to believe that?

                          From the Rust 2021 survey, 2420 said they use nightly to access one or more language features they need, 1028 claimed a Crate dependency requires it, and 876 claimed a tool they use requires it.

                          This, from a sample pool where around 3k users out of around 10k claim they use a nightly version.

                          • ungamedplayer 11 days ago
                            Again. Almost none of these can run in kernel space, those that are required will be duplicated in tree.

                            The survey results are not relevant. The rust code must not use stdlib (the name escapes me) which uses an incompatible memory allocation mechanism.

                            The code used to build will likely need to be checked into the kernel git repo and not downloaded live online, I doubt that the mature development process of the kernel wants the problems that other package managers have.

                            I will fight to ensure that this is not the case in the kernels that I work with, because fetching dependencies is for people who can tolerate other people and networks being faulty.

                            I got shit to do.

                            • nindalf 11 days ago
                              Because the kernel code isn’t pulling dependency code from the internet OR a compiler that changes every day. Kernel code will be checked into the repo, dependencies if any, will be vendored. Nor will much of crates.io be relevant - the kernel will only use no_std with fallible allocations.

                              As for the compiler, it will use a pinned, stable compiler, not nightly.

                              Why are you spreading FUD about nightly + Linux on this thread? At no point has this combination ever been considered.

                          • eternauta3k 12 days ago
                            Would the kernel pull in any dependencies, or just reimplement everything like it currently does?
                            • bonzini 12 days ago
                              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.
                        • jjice 12 days ago
                          > 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.

                          • Rusky 12 days ago
                            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.

                            • pornel 12 days ago
                              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.

                            • jcranmer 12 days ago
                              > 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 12 days ago
                                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.

                                • gspr 12 days ago
                                  > 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.

                                  • superkuh 12 days ago
                                    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 12 days ago
                                      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...

                                      • superkuh 11 days ago
                                        You're saying no true Scotsman will require the latest rust compiler. I'm saying that's not how it is for non-Rust developers trying to use things written in Rust.
                                        • nicoburns 11 days ago
                                          I'm saying the really core libraries (the only ones the linux kernel would ever consider using) don't suffer from this problem. If your development environment is permissive enough that you can pick up a wider variety of libraries, then I can't see any reason not to use the latest compiler.
                                          • superkuh 10 days ago
                                            So we agree. Programs written in Rust don't last more than a couple months. It's just the core libraries that are decent.

                                            Btw, I just attempted to install another rust program (legdur), and guess what, my rustc is too out of date to handle it ("failed to parse the `edition` key, this version of Cargo is older than the `2021` edition, and only supports `2015` and `2018` editions"). So that's 3 of 4 attempts to run Rust programs that have failed. Granted, my rustc is now about a year old, but that's still absurdly short.

                                            • zRedShift 10 days ago
                                              > legdur First commit 2 months ago, started with edition 2021. https://hg.sr.ht/~cyplo/legdur/browse/Cargo.toml?rev=ca11815...

                                              Have you tried compiling something less than bleeding edge, with a year old compiler, or are you picking projects specifically to "showcase" the supposed failings of the Rust compiler?

                                              Many libraries in the ecosystem have a MSRV (minimum support rust version) guarantee, with compile-time shims to enable newer features if a more recent version is detected.

                                              You can pin your dependencies to those versions (and if they don't have an explicit MSRV, just pin it to a version by date or by running https://github.com/foresterre/cargo-msrv on the project to find the effective MSRV).

                                              You can cargo install specific versions of a binary crate, and if they move to the 2021 edition, or use a recently stabilized standard library function or w/e, you can simply choose to install a specific version, that would work with your distro's rustc/cargo.

                                              I'm not even talking about the completely valid, but last resort strategy of many non-bleeding edge distro package maintainers, of simply creating a .patch file and applying it. In legdur's case, --- edition = "2021" +++ edition = "2018" on Cargo.toml would probably do the trick. For libraries/binaries you control, you can use https://doc.rust-lang.org/cargo/reference/overriding-depende... and https://github.com/itmettkeDE/cargo-patch.

                                              Giving up after the first minor roadblock and crying bloody murder is intellectually lazy.

                                              • burntsushi 8 days ago
                                                IMO, this is a nonsense standard. On the one hand, you have an old compiler. On the other hand, you have a new program. Expecting an old compiler to build a new program isn't exactly reasonable, although I grant it depends on taste and the time interval. A better comparison would be to try compiling an older version of the program.

                                                Basically, if you're in environment where you can't or won't update your compiler to something more recent, then why do you expect to be able to use recent programs? Why not use older programs in line with your old compiler?

                                                This is what I don't get about the Debian/Centos folks. They specifically use a Linux distro that gives them old software and then complain when they can't build new programs. Well, if you're using Debian/Centos, then you're committed to old programs. So build old programs, not new programs. Either that, or go install 'rustup' and bring in a newer compiler.

                                                • nicoburns 10 days ago
                                                  > Programs written in Rust don't last more than a couple months.

                                                  They last just fine much longer than that, you may just have to upgrade your compiler if you compile from source (doing so is a single command, takes about 30 seconds max, and new versions are backwards compatible so code targeting older compiler versions will still work). Importantly, you generally do not need the Rust compiler at all if you only wish to run Rust applications. You can usually download a pre-compiled binary distributed by the program authors. Applications (not libraries) requiring a recent compiler / language toolchain and updating as and when is convenient to them is hardly unique to Rust.

                                      • cmrdporcupine 12 days ago
                                        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.

                                        • ImprobableTruth 12 days ago
                                          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.

                                          • corrral 12 days ago
                                            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.

                                            • cmrdporcupine 12 days ago
                                              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 12 days ago
                                                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.
                                                • SubjectToChange 12 days ago
                                                  > 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.

                                                  Clang is starting to leapfrog GCC here. IIRC, some features are better supported and/or more advanced on Clang, other features (e.g. LTO) are exclusive to it. Not to mention it's almost a certainty for Clang to land kernel PGO support long before GCC, in fact Google already uses it in production Android kernels.

                                                  Anyway, rust or not, linux is being decoupled from GCC.

                                                  • dralley 12 days ago
                                                    LTO is not exclusive to clang. "thin" LTO is. It just happens to be more commonly used, since it's faster and uses less memory.
                                                    • SubjectToChange 11 days ago
                                                      > LTO is not exclusive to clang.

                                                      This is in the context of the Linux kernel, which only mainlined Clang LTO support in 5.12. AFAIK, GCC LTO has yet to be accepted.

                                              • nextaccountic 12 days ago
                                                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)

                                                • im3w1l 12 days ago
                                                  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.

                                                  • mamcx 12 days ago
                                                    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?).

                                                  • noobermin 12 days ago
                                                    Sympathetic, but isn't Linux like the poster child for demanding vendors and whoever maintain drivers and stuff without just leaving it working for months to years? Rust is just more bleeding edge than Linux then (which might be a substantial difference, I don't know).
                                                    • raxxorraxor 11 days ago
                                                      Shouldn't we wait for Rust to be more stable then? I still fear that its restrictions are a bit of a fad. If it is included at one point you will hardly ever get rid of it again.
                                                    • coldtea 12 days ago
                                                      >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

                                                      • sillystuff 12 days ago
                                                        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.




                                                        • turbinerneiter 12 days ago
                                                          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 12 days ago
                                                            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 12 days ago
                                                              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.
                                                            • flohofwoe 12 days ago
                                                              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 12 days ago
                                                                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 12 days ago
                                                                  It can be built with llvm too; there was a lot of work put into llvm to support gccisms.
                                                                • bitwize 12 days ago
                                                                  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.

                                                                • eterevsky 12 days ago
                                                                  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.
                                                                  • busterarm 12 days ago
                                                                    You would care if you were on one of the dozen or so CPU architectures that would suddenly become unsupported.
                                                                    • unrealhoang 12 days ago
                                                                      Probably the Rust code will be drivers for devices that are not compatible with non-rust supported architectures anyway.
                                                                      • Unklejoe 12 days ago
                                                                        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 12 days ago
                                                                          By the time these kind of drivers are being written in Rust, the gcc support will be there anyway.
                                                                        • busterarm 12 days ago
                                                                          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 12 days ago
                                                                            The Linux kernel takes backwards compatibility much more seriously than your typical Python package.
                                                                            • busterarm 12 days ago
                                                                              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 12 days ago
                                                                                Seems like Linus and Greg and a bunch of people who oversee technical decisions on the Linux kernel are on board though?
                                                                                • humanwhosits 12 days ago
                                                                                  And they can back-out/revert if they decide to as well
                                                                            • merb 12 days ago
                                                                              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...
                                                                          • josefx 12 days ago
                                                                            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 12 days ago
                                                                              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.

                                                                              • raxxorraxor 11 days ago
                                                                                Secure boot for smartphones is one of the reasons why smartphones are so restrictive and oriented against the user instead of for him. They should drop the support.
                                                                              • kevin_thibedeau 12 days ago
                                                                                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.
                                                                            • esjeon 12 days ago
                                                                              * 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.

                                                                              • zamalek 12 days ago
                                                                                > The kernel doesn't need all those new bells and whistles that Rust wants to offer

                                                                                That's a bewildering statement considering that one of the bells and whistles that Rust offers is memory safety.

                                                                                • esjeon 9 days ago
                                                                                  I mean the ones in the unstable branch. Stable Rust is just good enough, as it can perfectly reproduce the C-like coding experience with added type safety.
                                                                                • nindalf 12 days ago
                                                                                  > 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.

                                                                                  • estebank 11 days ago
                                                                                    > I can’t recall a new Rust release ever breaking existing code. Is this what you’re talking about?

                                                                                    I have one case of code from late 2015 that stopped working in, IIRC, 2016, due to unsoundness being found in the borrow checker and it being fixed.

                                                                                      error[E0713]: borrow may still be in use when destructor runs
                                                                                         --> src/writer.rs:121:21
                                                                                      47  | impl<'a, F: Write + Read + Seek + 'a> Writer<'a, F> {
                                                                                          |      -- lifetime `'a` defined here
                                                                                      121 |         Reader::new(self.file)
                                                                                          |         ------------^^^^^^^^^- returning this value requires that `*self.file` is borrowed for `'a`
                                                                                      122 |     }
                                                                                          |     - here, drop of `self` needs exclusive access to `*self.file`, because the type `Writer<'_, F>` implements the `Drop` trait
                                                                                    I ended up solving it by wrapping `self.file` in an "unnecessary" `Option` and using `Option::take` on `self.file` here. I guess I could have mucked around with `MaybeUninit` and risk UB instead, or removed the convenience `Drop` impl finalizer or made the impl non-generic.

                                                                                    I haven't had a case of code no longer compiling since then.

                                                                                    • esjeon 9 days ago
                                                                                      You're not doing engineering here, bro.

                                                                                      > Could you give some examples of big features from the last 12 months? > ... > I can’t recall a new Rust release ever breaking existing code. Is this what you’re talking about?

                                                                                      Let me show you two links:

                                                                                      1. Rust version history: https://github.com/rust-lang/rust/blob/master/RELEASES.md

                                                                                      2. GCC changes: https://gcc.gnu.org/gcc-12/changes.html#c-family

                                                                                      Compared to Rust, GCC, the C compiler, is absolutely boring. The C language has been stable for decades, so there's hardly anything to be done on the language itself. GCC has been used in all kinds of occasions, and has compiled all types of applications and system software. We know it works in every situation. There's hardly anything to be done. This is how the real stability looks like - boring as shit.

                                                                                      Now, what, 12 months? The number isn't simply getting there.

                                                                                • selckin 12 days ago
                                                                                  Or that then gives people the motivation to work on gcc, have to solve the chicken-egg
                                                                                  • humanwhosits 12 days ago
                                                                                    This should really motivate the rust frontend for gcc though
                                                                                    • sophacles 12 days ago
                                                                                      > You shouldn't need non-GCC compilers to compile Linux


                                                                                      • mkoubaa 12 days ago
                                                                                        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
                                                                                        • guerrilla 12 days ago
                                                                                          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 12 days ago
                                                                                            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.
                                                                                            • steveklabnik 12 days ago
                                                                                              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 12 days ago
                                                                                                I think it is fully supported now: https://docs.kernel.org/kbuild/llvm.html
                                                                                                • steveklabnik 12 days ago
                                                                                                  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"...)

                                                                                              • ncmncm 12 days ago
                                                                                                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.

                                                                                              • bitwize 12 days ago
                                                                                                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 12 days ago
                                                                                                  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 12 days ago
                                                                                                    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 12 days ago
                                                                                                      But how many language spec changes have there been during this time?
                                                                                                      • kklimonda 12 days ago
                                                                                                        Probably all of them? Jakt repo isn't even 3 months old.
                                                                                                    • jeroenhd 12 days ago
                                                                                                      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.

                                                                                                      • tialaramex 12 days ago
                                                                                                        > 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

                                                                                                        Rust's editions are not language versions. They set aside syntax, so far there was 2015 edition (the original Rust 1.0 syntax) and then 2018 edition (a few tweaks, introducing the raw symbol which enables you to mention symbols that conflict with keywords) and most recently 2021 edition (which adds a hack to the older editions so that arrays don't seem to be IntoIterator in 2015 or 2018 edition even though they actually are now).

                                                                                                        C++ ships language versions on its three year cadence. C++ 14, C++ 17 and C++ 20 are three very similar yet distinct languages while Rust's 2015 edition, 2018 edition and 2021 edition are simply syntax for the same language, Rust. You can write brand new code, today, in 2015 edition, and use features that didn't exist six months ago, no problem. You just can't use keywords (like async) that hadn't been invented in 2015 and thus you can't directly use features gated by need for those keywords.

                                                                                                        MSRV (Minimum Supported Rust Version) is a different idea, it says this software needs some features which weren't in Rust until this version. For example if you write 2018 edition, that doesn't magically mean you used async, but on the other hand, if you did require async then no stable Rust versions from 2018 had working async, the keyword was reserved but not useful. So your MSRV might be much newer even though your program syntax is 2018 edition. Documenting MSRV is not a mandatory practice, although it's good to do it for important stuff or where the minimum version is likely to be a surprise.

                                                                                                • dgb23 12 days ago
                                                                                                  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?

                                                                                                  • jtdowney 12 days ago
                                                                                                    > - 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 12 days ago
                                                                                                      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?

                                                                                                      • tialaramex 12 days ago
                                                                                                        Lets see your list of "every single thing that Linus famously hated about C++"

                                                                                                        When I try to make a list one of the first things I find is "any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with."

                                                                                                  • bragr 12 days ago
                                                                                                    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.
                                                                                                    • Fiahil 12 days ago
                                                                                                      > - 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.

                                                                                                      • mejutoco 12 days ago
                                                                                                        > 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.

                                                                                                        • atoav 12 days ago
                                                                                                          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 12 days ago
                                                                                                            This example requires seeing both submissions for C and C++ to compare on their actual speed with the Rust one though
                                                                                                          • nindalf 12 days ago
                                                                                                            > 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/blob/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 12 days ago
                                                                                                              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 12 days ago
                                                                                                                > 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 12 days ago
                                                                                                                > 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.]

                                                                                                              • icambron 12 days ago
                                                                                                                What’s your complaint about the question mark operator?
                                                                                                                • bonzini 12 days ago
                                                                                                                  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-....
                                                                                                                  • dgb23 12 days ago
                                                                                                                    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 12 days ago
                                                                                                                      > 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 12 days ago
                                                                                                                        > 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 12 days ago
                                                                                                                        > 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 12 days ago
                                                                                                                          > 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?

                                                                                                                          • jeffparsons 12 days ago
                                                                                                                            `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...)

                                                                                                                            • dgb23 12 days ago
                                                                                                                              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 12 days ago
                                                                                                                                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.

                                                                                                                        • belter 12 days ago
                                                                                                                          Plus the whole issue of Cargo namespace squatting...


                                                                                                                          • mcdonje 12 days ago
                                                                                                                            If you have a good solution to rent-seeking, a great many marketplaces would benefit.
                                                                                                                          • baby 12 days ago
                                                                                                                            How is that an issue?
                                                                                                                            • sa46 11 days ago
                                                                                                                              One consequence is that you end with cute names instead of clear names. Cherry picking from the top 30 or so crates:

                                                                                                                              - parking_lot

                                                                                                                              - hashbrown

                                                                                                                              - ryu

                                                                                                                              - heck

                                                                                                                              The longer there's a shared namespace, the stranger the names get as the "good" names are already in use.

                                                                                                                              • tialaramex 11 days ago
                                                                                                                                For implementations of a known idea, I would rather have a fun codename than see the word for the idea used to also name the implementation.

                                                                                                                                The contrary case gets confusing fast. "Oh Known Algorithm doesn't work" "Huh, I read a paper which proved it works" "No, I mean, Known Algorithm, not known algorithm". "What?" "The implementation by Popular Author. It's broken for the case we care about". "Can't they fix it?" "They say that although their implementation is called Known Algorithm it's just better that it not fix this because now Known Algorithm is different from the known algorithm". What?

                                                                                                                                Knowing there's a problem, or a different performance trade off, or a lack of maintenance for Haphazard (Jon Gjengset's Hazard Pointers implementation) is very different from having a problem with Hazard Pointers the idea.

                                                                                                                          • gspr 12 days ago
                                                                                                                            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 12 days ago
                                                                                                                              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.

                                                                                                                          • IYasha 12 days ago
                                                                                                                            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 12 days ago
                                                                                                                              Adding bindings for a second language after 25 years is not what I'd call "diversity".
                                                                                                                              • ansible 12 days ago
                                                                                                                                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 12 days ago
                                                                                                                                  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.

                                                                                                                                  • Banana699 12 days ago
                                                                                                                                    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...

                                                                                                                                    • acuozzo 12 days ago
                                                                                                                                      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.

                                                                                                                                      • trasz 12 days ago
                                                                                                                                        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.
                                                                                                                                        • ahahahahah 12 days ago
                                                                                                                                          Isn't parent's very first line, in fact, about how a newer thing was much much worse?
                                                                                                                                          • tester756 12 days ago
                                                                                                                                            And the reason of that is language choice?
                                                                                                                                        • ahtihn 12 days ago
                                                                                                                                          > 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.

                                                                                                                                          • woodruffw 12 days ago
                                                                                                                                            > 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 12 days ago
                                                                                                                                              > 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.

                                                                                                                                          • cesarb 12 days ago
                                                                                                                                            > 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 12 days ago
                                                                                                                                              Only if you consider all assemblies to be the same! Otherwise, many, many more.
                                                                                                                                          • onpensionsterm 12 days ago
                                                                                                                                            Drivers are the wild-west
                                                                                                                                          • titzer 12 days ago
                                                                                                                                            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 12 days ago
                                                                                                                                              You would be interested to know that this already exists in the form of BPF.
                                                                                                                                              • titzer 12 days ago
                                                                                                                                                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 12 days ago
                                                                                                                                                  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.

                                                                                                                                            • samuell 12 days ago
                                                                                                                                              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?
                                                                                                                                              • jeroenhd 12 days ago
                                                                                                                                                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 12 days ago
                                                                                                                                                  > 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.

                                                                                                                                                  • wongarsu 12 days ago
                                                                                                                                                    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.
                                                                                                                                                    • nomel 12 days ago
                                                                                                                                                      > 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.

                                                                                                                                                      • WesolyKubeczek 12 days ago
                                                                                                                                                        I mean that it’s not hidden behind some all-encompassing event loop, nor is there an all-encompassing framework with an event loop hidden from you. It’s more like an exploded view of a mechanism in comparison.
                                                                                                                                                  • fathyb 12 days ago
                                                                                                                                                    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 12 days ago
                                                                                                                                                      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 12 days ago
                                                                                                                                                        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.

                                                                                                                                                        • ISV_Damocles 12 days ago
                                                                                                                                                          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.

                                                                                                                                                          • WesolyKubeczek 12 days ago
                                                                                                                                                            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.)

                                                                                                                                                            • rkangel 12 days ago
                                                                                                                                                              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 12 days ago
                                                                                                                                                                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.
                                                                                                                                                                • eklavya 12 days ago
                                                                                                                                                                  You are extremely lucky. You probably don’t need memory safety :)
                                                                                                                                                                • kzrdude 12 days ago
                                                                                                                                                                  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.
                                                                                                                                                              • belter 12 days ago
                                                                                                                                                                • pornel 12 days ago
                                                                                                                                                                  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.

                                                                                                                                                                  • carlhjerpe 12 days ago
                                                                                                                                                                    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 12 days ago
                                                                                                                                                                      > 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.

                                                                                                                                                                      • Matthias247 12 days ago
                                                                                                                                                                        One could try to use it for those use-cases, but it probably warrants some investigation if it's actually the best possible solution for the problem.

                                                                                                                                                                        The kernel has some different properties than userspace - e.g. context switches between kernel threads can already be cheap, which minimizes some of the reasons for using async/await. Then allocations for continuations using in-kernel slab allocators might also be cheaper then in userspace, whereas placing huge objects (Future)s on the stack (preferred mode of Rust Future composition) might be more expensive with tiny kernel stacks.

                                                                                                                                                                        I guess it might be worth to do experiments for some use-cases to see how it actually would work out.

                                                                                                                                                                        • monocasa 12 days ago
                                                                                                                                                                          Async is very good for only a specific kind of of state machine graph that isn't nearly as prevalent outside of network services.
                                                                                                                                                                      • Tuna-Fish 12 days ago
                                                                                                                                                                        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 12 days ago
                                                                                                                                                                          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.

                                                                                                                                                                        • dundarious 12 days ago
                                                                                                                                                                          I love zig, but neither dev nor stable releases are stable enough yet. Rust nightly builds are quite stable.
                                                                                                                                                                          • goodpoint 12 days ago
                                                                                                                                                                            If anything, Nim would be an excellent candidate because it compiles to C, is memory safe and has no GC anymore.
                                                                                                                                                                            • kzrdude 12 days ago
                                                                                                                                                                              Zig would be if they wanted "C and generics and compile time evaluation", but maybe that does not seem compelling enough to the kernel.
                                                                                                                                                                              • usrn 12 days ago
                                                                                                                                                                                I think zig is a little too opinionated.
                                                                                                                                                                                • vkazanov 12 days ago
                                                                                                                                                                                  It is, indeed, opinionated. It's also small and easy.

                                                                                                                                                                                  Rust is superopinionated. Big and complex as well.

                                                                                                                                                                                  • oconnor663 12 days ago
                                                                                                                                                                                    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.

                                                                                                                                                                                    • usrn 12 days ago
                                                                                                                                                                                      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 12 days ago
                                                                                                                                                                                        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

                                                                                                                                                                                      • 127 12 days ago
                                                                                                                                                                                        Writing multi-line strings in Zig is not easy.
                                                                                                                                                                                        • vkazanov 12 days ago
                                                                                                                                                                                          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 12 days ago
                                                                                                                                                                                            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 12 days ago
                                                                                                                                                                                              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 12 days ago
                                                                                                                                                                                                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.
                                                                                                                                                                                              • 127 11 days ago
                                                                                                                                                                                                - Can't easily indent

                                                                                                                                                                                                - Can't easily copy paste

                                                                                                                                                                                                - Can't easily edit

                                                                                                                                                                                                - Looks ugly

                                                                                                                                                                                                - Harder to read

                                                                                                                                                                                          • Comevius 12 days ago
                                                                                                                                                                                            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.

                                                                                                                                                                                            • ccbccccbbcccbb 12 days ago
                                                                                                                                                                                              Compared to the tyrannical Rust, maybe.
                                                                                                                                                                                            • busterarm 12 days ago
                                                                                                                                                                                              The zig community never made a huge fuss and initiated a mexican standoff by stating their refusal to continue working in C.
                                                                                                                                                                                            • PointyFluff 12 days ago
                                                                                                                                                                                              There's a lot of commenters here who have no idea how rust works, apparently.
                                                                                                                                                                                              • cmrdporcupine 12 days ago
                                                                                                                                                                                                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 12 days ago
                                                                                                                                                                                                  > 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 12 days ago
                                                                                                                                                                                                    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 12 days ago
                                                                                                                                                                                                      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 12 days ago
                                                                                                                                                                                                        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.
                                                                                                                                                                                                        • steveklabnik 12 days ago
                                                                                                                                                                                                          There have been a few. It often comes down to something that was previously unsound being made an error. There’s been long deprecation periods when this happens.

                                                                                                                                                                                                          The fact that it’s hard to even remember that these things have happened is a testament to how rarely it happens and how well the breakage is handled.

                                                                                                                                                                                                          • nindalf 11 days ago
                                                                                                                                                                                                            Hey Steve, thanks for the response. I was struggling to remember, which is why I asked.

                                                                                                                                                                                                            I suspect folks see the Rust release notes on the HN front page and assume that it must be a blockbuster release with lots of move-fast-break-things to make it there. But it’s actually like “new library API, some const fns, compilation time improvements”.

                                                                                                                                                                                                            So then they think “this language is moving waaay too quickly, they need to do LTS versions”. But this is just speculation. That’s why I asked GP. Maybe they’ve actually experienced breakage.

                                                                                                                                                                                                          • phaylon 11 days ago
                                                                                                                                                                                                            They're usually edge cases. For example let-chains changed the parsing logic for if-let constructs across all editions.

                                                                                                                                                                                                            I expect these to become even less frequent with ever rising amounts of Rust code that isn't on Github.

                                                                                                                                                                                                    • ThinkBeat 12 days ago
                                                                                                                                                                                                      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.

                                                                                                                                                                                                      • mijoharas 12 days ago
                                                                                                                                                                                                        > So much work has gone into the Linux kernel, but efforts should be made to replace it.

                                                                                                                                                                                                        Plenty of people are working on new kernels and operating systems both by hobbyists and companies (c.f. Redox[0], Fuscia (zircon kernel[1], e.t.c.).

                                                                                                                                                                                                        The main problem is that linux is an incredibly well developed piece of software, so it will take a very long time for anything to reach feature parity.

                                                                                                                                                                                                        > instead of slowing trying to port the current Linux kernel to Rust.

                                                                                                                                                                                                        I don't think anyone is suggesting to try and port the current kernel to Rust (and I'm fairly sure any suggestions in that direction would be met with a hard no from linus.) The current suggestion is just to allow language bindings to facilitate the writing of drivers in rust.

                                                                                                                                                                                                        Even looking to the future which could see some critical components of the kernel written in rust, I don't think anyone is suggesting that the entire kernel should be ported, since that's a monumental task (and suffers from the exact same issue as above, for questionable benefit).

                                                                                                                                                                                                        [0] https://www.redox-os.org/

                                                                                                                                                                                                        [1] https://fuchsia.dev/fuchsia-src/concepts/kernel

                                                                                                                                                                                                      • enriquto 12 days ago
                                                                                                                                                                                                        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 12 days ago
                                                                                                                                                                                                          They're not using Cargo.
                                                                                                                                                                                                          • enriquto 12 days ago
                                                                                                                                                                                                            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 12 days ago
                                                                                                                                                                                                              I strongly disagree on every count, but I’m glad you’re happy.
                                                                                                                                                                                                              • mllllv 12 days ago
                                                                                                                                                                                                                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.
                                                                                                                                                                                                                • SAI_Peregrinus 11 days ago
                                                                                                                                                                                                                  Make lets you download shit from the internet.
                                                                                                                                                                                                                  • enriquto 11 days ago
                                                                                                                                                                                                                    > Make lets you download shit from the internet.

                                                                                                                                                                                                                    ...sure, by specifying the whole url and calling an external program where the actual shit downloading happens. The same as bash, C and so on. Of course, it is in very bad taste to do so, and by no means a standard or even common thing to do when using makefiles.

                                                                                                                                                                                                                    Maybe it would be OK if cargo let you download code, after giving it a sort of "unsafe" flag or something. But the current behavior is just bonkers.

                                                                                                                                                                                                                    • > But the current behavior is just bonkers.

                                                                                                                                                                                                                      Don't understand your gripe. Is it just that you don't like things to be this easy for the dev? Dependencies should not just be disfavored but actually hard to use?

                                                                                                                                                                                                            • fxttr 12 days ago
                                                                                                                                                                                                              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 12 days ago
                                                                                                                                                                                                                can someone eli5 why rust is okay but not c++11 variants?
                                                                                                                                                                                                                • woodruffw 12 days ago
                                                                                                                                                                                                                  '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 12 days ago
                                                                                                                                                                                                                    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.

                                                                                                                                                                                                                    • woodruffw 12 days ago
                                                                                                                                                                                                                      Rust famously does not do implicit allocation or implicit nontrivial construction. It also famously doesn’t do implicit construction when concrete parameter types don’t match the types in function signatures, which is a common source of side effects (and memory corruption) in C++.

                                                                                                                                                                                                                      In general, Rust is more implicit than C, but significantly less implicit than C++. Moreover, the ways in which Rust is implicit are more consistent and less likely to introduce bugs.

                                                                                                                                                                                                                      • ncmncm 12 days ago
                                                                                                                                                                                                                        You will need to cite evidence that implicit argument type conversion is a common source of memory corruption.
                                                                                                                                                                                                                        • woodruffw 12 days ago
                                                                                                                                                                                                                          I figured it rose to the level of conventional wisdom. I don’t have a source to cite, because I’ve only dealt with it in random codebases.

                                                                                                                                                                                                                          As an anecdote: I had a codebase where a nontrivial constructor contained a “registry” of created objects, for introspection. The design contract for that part of the API included the assumption that all constructions would be explicit, but it wasn’t actually enforced. Later, someone did some subclassing and added some APIs that inadvertently performed a converting construction, resulting in broken invariants around offsets and members in the registry.

                                                                                                                                                                                                                          Was it a good design? No, it was terrible. But nothing stopped someone from writing it, and the codebase otherwise “did everything right” (C++11, warning flags out the wazoo, fuzzing, unit tests, etc.)

                                                                                                                                                                                                                          It was a real pain in the ass to debug, and it fundamentally couldn’t have happened in a Rust codebase. And that’s just one tiny corner.

                                                                                                                                                                                                                          • ncmncm 12 days ago
                                                                                                                                                                                                                            How would you have achieved what that code was doing, in Rust?

                                                                                                                                                                                                                            Code written to assume it will only ever run in context X being made to run in context Y instead is a problem that happens in every language equally. It is prevented by making a predicate Z to report whether X, and asserting Z where it matters. It is not a product of conversion.

                                                                                                                                                                                                                            In Rust, you would have had a factory function for type A, and somebody would have made a factory function for B that called the one for A, provoking the same failure.

                                                                                                                                                                                                                            We still need evidence of the original claim that implicit argument type conversion is a common source of memory corruption. We already know that bad design breeds bugs.

                                                                                                                                                                                                                            • woodruffw 12 days ago
                                                                                                                                                                                                                              Yes, you couldn’t do exactly that in Rust, and that’s a good thing. It was a bad design decision.

                                                                                                                                                                                                                              In Rust, the closest thing would probably be a shared Rc member for the registry and a non-owning indexing scheme (either weak references or something symbolic). But I’ve never actually seen a Rust codebase that needed to apply the registry pattern; it’s usually the wrong abstraction, like I said.

                                                                                                                                                                                                                              Edit: And no, replicating this pattern in Rust would not have produced the same failure. The failure mode in C++ resulted in exploitable memory corruption.

                                                                                                                                                                                                                      • rcxdude 12 days ago
                                                                                                                                                                                                                        >Rust does everything C++ does, as far as things happening invisibly

                                                                                                                                                                                                                        These 4 things do not happen invisibly in rust:

                                                                                                                                                                                                                        code running on struct creation (it will be an explicit ::new() call)

                                                                                                                                                                                                                        code running on struct copying (it will be an explicit ::clone() call)

                                                                                                                                                                                                                        code running on struct moving (moving is always a memcpy in rust, no custom code can run).

                                                                                                                                                                                                                        Error handling flow control (no exceptions, error handling will at minimum be marked with a '?'). (yes panic exists but this is basically for the same purposes as a kernel panic).

                                                                                                                                                                                                                        Rust favours making things explicit, much more so than C++.

                                                                                                                                                                                                                    • jcranmer 12 days ago
                                                                                                                                                                                                                      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++.

                                                                                                                                                                                                                      • boris 12 days ago
                                                                                                                                                                                                                        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 12 days ago
                                                                                                                                                                                                                          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 12 days ago
                                                                                                                                                                                                                            Other commenters have good points, but don't underestimate the fact that Linus doesn't like C++.
                                                                                                                                                                                                                            • ncmncm 12 days ago
                                                                                                                                                                                                                              This, despite that Rust has every single thing Linus hated about C++.
                                                                                                                                                                                                                              • tialaramex 11 days ago
                                                                                                                                                                                                                                This claim would be a lot more compelling if, when confronted, you were able to list the things "Linux hated about C++" and show how Rust has them.
                                                                                                                                                                                                                          • adwn 12 days ago
                                                                                                                                                                                                                            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

                                                                                                                                                                                                                          • 3836293648 12 days ago
                                                                                                                                                                                                                            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

                                                                                                                                                                                                                            • kllrnohj 12 days ago
                                                                                                                                                                                                                              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 12 days ago
                                                                                                                                                                                                                                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 12 days ago
                                                                                                                                                                                                                                  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 12 days ago
                                                                                                                                                                                                                                  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
                                                                                                                                                                                                                                • the_duke 12 days ago
                                                                                                                                                                                                                                  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 12 days ago
                                                                                                                                                                                                                                    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.
                                                                                                                                                                                                                                    • rkangel 12 days ago
                                                                                                                                                                                                                                      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.

                                                                                                                                                                                                                                      • vkazanov 12 days ago
                                                                                                                                                                                                                                        And what is wrong with libgccjit? It's not hugely popular, yes, but there are some use examples, i.e. Emacs.
                                                                                                                                                                                                                                        • 3836293648 12 days ago
                                                                                                                                                                                                                                          Documentation and the number of patches every project I've seen try to use it has needed to send.
                                                                                                                                                                                                                                      • tmountain 12 days ago
                                                                                                                                                                                                                                        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 12 days ago
                                                                                                                                                                                                                                          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.
                                                                                                                                                                                                                                        • kryptiskt 12 days ago
                                                                                                                                                                                                                                          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 12 days ago
                                                                                                                                                                                                                                            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.
                                                                                                                                                                                                                                        • sdfhdhjdw3 12 days ago
                                                                                                                                                                                                                                          Could someone explain to me why you would want to add Rust to the kernel, without using the word "safe".
                                                                                                                                                                                                                                          • monocasa 12 days ago
                                                                                                                                                                                                                                            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 12 days ago
                                                                                                                                                                                                                                              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 12 days ago
                                                                                                                                                                                                                                                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.
                                                                                                                                                                                                                                            • jcranmer 12 days ago
                                                                                                                                                                                                                                              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).

                                                                                                                                                                                                                                            • adgjlsfhk1 12 days ago
                                                                                                                                                                                                                                              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.
                                                                                                                                                                                                                                              • varajelle 12 days ago
                                                                                                                                                                                                                                                Convenience of using zero-cost abstractions to get the same things done faster/easier?
                                                                                                                                                                                                                                                • sdfhdhjdw3 12 days ago
                                                                                                                                                                                                                                                  That's the guiding design principle of C++.
                                                                                                                                                                                                                                                • josephcsible 12 days ago
                                                                                                                                                                                                                                                  Could someone explain to me why people need to breathe, without using the word "oxygen".
                                                                                                                                                                                                                                                  • feet 12 days ago
                                                                                                                                                                                                                                                    Breathing in humans is driven by the need to remove CO2 from the blood
                                                                                                                                                                                                                                                    • kamaal 11 days ago
                                                                                                                                                                                                                                                      We need to use rust to remove unsafe elements from the Kernel.
                                                                                                                                                                                                                                                  • webkike 12 days ago
                                                                                                                                                                                                                                                    Rust is more fun to program in than C. I was a pure C guy before I learned Rust.
                                                                                                                                                                                                                                                    • dieortin 12 days ago
                                                                                                                                                                                                                                                      Surely being fun is not the best reason to add a language to a kernel.
                                                                                                                                                                                                                                                      • pornel 12 days ago
                                                                                                                                                                                                                                                        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 12 days ago
                                                                                                                                                                                                                                                          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 12 days ago
                                                                                                                                                                                                                                                            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 12 days ago
                                                                                                                                                                                                                                                              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 12 days ago
                                                                                                                                                                                                                                                                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.

                                                                                                                                                                                                                                                                • rcxdude 12 days ago
                                                                                                                                                                                                                                                                  Both. The borrow checker encodes a lot of rules and habits which experienced C and C++ developers tend to develop anyway, because breaking those rules tends to result in bugs (and people who learn rust often report that it makes them better C/C++ programmers). But it is possible to break those rules and get away with it in ways which the borrow checker is unable to verify, and unsafe blocks exist in part to allow you to do so if you're really sure you're right (though frequently beginners are not).
                                                                                                                                                                                                                                                              • webkike 12 days ago
                                                                                                                                                                                                                                                                Well, he certainly won’t lose that by switching to rust judging by the comments in this thread!
                                                                                                                                                                                                                                                            • webkike 12 days ago
                                                                                                                                                                                                                                                              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 12 days ago
                                                                                                                                                                                                                                                            The compiler and language make it easier to unambiguously specify a program.
                                                                                                                                                                                                                                                          • adamius 12 days ago
                                                                                                                                                                                                                                                            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.
                                                                                                                                                                                                                                                          • tamrix 12 days ago
                                                                                                                                                                                                                                                            Time to fork?

                                                                                                                                                                                                                                                            I'm going to call the new c only Linux cinux

                                                                                                                                                                                                                                                            • mllllv 12 days ago
                                                                                                                                                                                                                                                              • b20000 12 days ago
                                                                                                                                                                                                                                                                i hope this never happens. if it does then i will lose all interest in ever contributing.
                                                                                                                                                                                                                                                                • dagmx 12 days ago
                                                                                                                                                                                                                                                                  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 12 days ago
                                                                                                                                                                                                                                                                    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 12 days ago
                                                                                                                                                                                                                                                                      grug agree. focus should be on trap complexity demon, make easier for new grugs to contribute meaningfully to kernel.


                                                                                                                                                                                                                                                                      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 12 days ago
                                                                                                                                                                                                                                                                        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).
                                                                                                                                                                                                                                                                        • bitwize 12 days ago
                                                                                                                                                                                                                                                                          Yes, times have changed; today, "game device" and "not connected to the internet" are almost a contradiction in terms. Besides, the makers of such devices want to stop the next Gary Bowser from finding an exploit that will let people run "homebrew" (read: pirated) games.

                                                                                                                                                                                                                                                                          The fact is that new developers (and many old ones) see C as too risky and difficult to work in now, meanwhile JavaScript kids are transitioning to Rust and writing code that's nearly as performant as your C code but with fewer bugs.

                                                                                                                                                                                                                                                                          As I like to say, Rust isn't for you... it's for your replacement.

                                                                                                                                                                                                                                                                          • > it's not just a "server" operating system anymore

                                                                                                                                                                                                                                                                            This is not much of an argument. Yes, you have another use case, and maybe memory safety bugs are not an issue for you (which -- you hear this a lot among C programmers until they are bitten). But also clearly that doesn't mean those bugs aren't an issue for everyone else, or that the Linux kernel should prize your POV over all others.

                                                                                                                                                                                                                                                                            Also, maybe your use is extremely limited? I mean "portable game device not connected to the internet" is pretty small share of the total Linux marketshare. It's probably a small share of the total Linux "portable game device" marketshare.

                                                                                                                                                                                                                                                                        • webkike 12 days ago
                                                                                                                                                                                                                                                                          How will it add new barriers? You can still program your drivers in C.
                                                                                                                                                                                                                                                                          • b20000 12 days ago
                                                                                                                                                                                                                                                                            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.

                                                                                                                                                                                                                                                                            • mijoharas 12 days ago
                                                                                                                                                                                                                                                                              > no, because sooner or later i will need to touch rust code when i work on drivers

                                                                                                                                                                                                                                                                              This is not the case and is not planned. Are you trying to make some kind of slippery slope argument or something?

                                                                                                                                                                                                                                                                          • mynameisash 12 days ago
                                                                                                                                                                                                                                                                            > 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 12 days ago
                                                                                                                                                                                                                                                                          It will be tough, but I think Linux will manage to keep limping along even without you.
                                                                                                                                                                                                                                                                          • b20000 12 days ago
                                                                                                                                                                                                                                                                            maybe contributors will move on to other operating systems then, like BSD?
                                                                                                                                                                                                                                                                          • webkike 12 days ago
                                                                                                                                                                                                                                                                            Okay, so?