Rust for the Kernel Could Possibly Be Merged for Linux 5.20

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SonarQube - Static code analysis for 29 languages.
  • Scout APM - Less time debugging, more time building
  • SaaSHub - Software Alternatives and Reviews
  • Rust-for-Linux

    Adding support for the Rust language to the Linux kernel. (by Rust-for-Linux)

    > 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 a new library API is used, how would an old tool chain compile that? AFAIK, this is a non goal.

    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.

  • jakt

    The Jakt Programming Language

    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

  • SonarQube

    Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.

  • rfcs

    RFCs for changes to Rust

  • zig

    General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

    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

  • cargo-deb

    A cargo subcommand that generates Debian packages from information in Cargo.toml (by kornelski)

    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)

  • surveys

    Repo for coordinating the creation, distribution, collection, and analysis of surveys for the Rust project. (by rust-lang)

    Less than 20% of devs use nightly. About a third of the devs who use nightly do it because of a dependency. A far cry from the “half” claimed by GP.

    https://github.com/rust-lang/surveys/raw/main/surveys/2021-a...

  • gccrs

    GCC Front-End for Rust

    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.

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • netbsd-sandbox

    The secmodel_sandbox security module for NetBSD

  • cargo-msrv

    🦀 Find the minimum supported Rust version (MSRV) for your project

    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.

  • cargo-patch

    Cargo Subcommand for patching dependencies using patch files

    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.

  • rust

    Empowering everyone to build reliable and efficient software.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts