Upcoming Rust language features for kernel development

Original Article ↗ Hacker News Discussion ↗

Scope of upcoming Rust-for-Linux features

  • Several commenters note these kernel-driven features (field projection, pinning, heap construction semantics, etc.) are broadly useful to systems programming beyond the kernel: OSes, embedded, bare metal, and complex C interop.
  • Some argue Rust’s focus on kernel needs has slowed other ecosystem work; others see Linux as productively pushing the language into more powerful but still general abstractions.

C (and C++) interoperability

  • Calling C from Rust is described as “excellent” mechanically: extern "C", #[repr(C)], bindgen/cbindgen, plus stable varargs calling.
  • Going the other way (C calling Rust) is seen as workable but painful: manual unpacking of Rust collections, allocator mismatches, subtle FFI safety pitfalls, lack of stable object-format guarantees, and weak tooling for producing C-facing shared libraries (symbol versioning, etc.).
  • Tooling like cargo-c, bindgen, and cbindgen works for many projects, but complex cases (e.g. systemd, Meson integration, advanced FFI-safety) still hit rough edges.
  • C++ interop is called “problematic”; the kernel itself does not use C++.

Rust vs managed languages and GUIs

  • One camp: Rust’s “natural home” is low-level systems; for most user-space apps, managed languages (JVM, .NET, Dart/Flutter, etc.) are preferable.
  • Counterpoint: Rust is “a rare gem” that works well for both firmware and applications, including GUIs.
  • GUI reality: Rust has several active toolkits (egui, Iced, Slint, GTK bindings, gpui), but many agree Rust does not currently “excel” at GUIs: text layout, bidi, font fallback, accessibility, and widget richness lag mature toolkits like Qt/AppKit.
  • Some see choosing Rust for GUIs as unnecessary complexity versus Flutter, C#, Java, etc., unless you specifically want Rust’s safety/performance.

Concurrency, thread safety, and Send/Sync

  • Multiple comments emphasize Rust’s compile-time prevention of data races via ownership and the Send/Sync traits, distinguishing data races from broader race conditions.
  • This is contrasted with C/C++, where correct atomic/mutex usage relies entirely on discipline and tooling.
  • Skeptics argue Rust only helps for a “narrow” class of in-process memory races and can’t protect against races via external resources (files, shared memory across processes, databases).
  • Others reply that for parallelization within a process, the memory-sharing case Rust covers is the most important and hardest to get right.

Rust in the Linux kernel: scope, value, and “experiment” concerns

  • A skeptical thread notes that current in-tree Rust consists largely of infrastructure plus a handful of drivers; questions whether the “world’s most important piece of software” is the right place for language co-development.
  • Responses:
    • Significant real drivers exist or are in progress (Android Binder rewrite, Apple M-series GPU, ARM Mali, others), often reporting far fewer race/memory bugs than expected.
    • Rust-for-Linux began out-of-tree; moving in-tree is necessary to stabilize APIs and make real adoption possible.
    • Kernel APIs being wrapped in safe Rust is itself major work: you’re encoding informal C rules (locking, lifetimes, RCU) into a type system.
  • Some see company influence (Android, large vendors) as driving Rust adoption; others argue there is simply no viable alternative “memory-safe C” today.

Async runtimes in the kernel

  • Commenters joke/half-worry about “Tokio in the kernel.”
  • Kernel developers reply that an async runtime is straightforward on top of existing workqueue infrastructure; a proof-of-concept Rust async runtime for Linux already exists.
  • Clarification that kernel Rust uses no_std and kernel primitives; porting user-space Tokio directly is unrealistic.

Language evolution: projections, heap construction, lightweight clones

  • The article’s pinned-field projections and “structurally pinned” decision are welcomed as unblocking many designs, especially around Pin.
  • Heap-construction semantics (C++-style elision/“guaranteed optimization”) are debated—some want explicit constructs like &out / &in or constructors; others note Rust’s invariants make C++-like constructors problematic.
  • Lightweight clones / Use trait:
    • Some are excited about ergonomics for reference-counted types.
    • Others think the current proposal is too complex/ambiguous; community sentiment has cooled and design is being reconsidered with an eye to simplicity.
  • Several participants express worry that Rust is on a trajectory toward C++-level complexity; defenders reply that:
    • Rust is still much simpler and more coherent than C++.
    • Crucially, most complexity is enforced and checked by the compiler rather than left to human discipline.

FFI, unsafe Rust, and low-level data structures

  • There’s unease about increasingly low-level unsafe constructs (&raw, pointer projections) and whether Rust should chase every C pattern (e.g., intrusive linked lists).
  • Others argue unsafe is appropriate for a small, well-audited core (e.g., a linked-list implementation) wrapped in a safe API; arrays-of-indices “cheats” still lack compiler-checked safety.

Automatic C→Rust translation and LLMs

  • Non-LLM tools like c2rust are highlighted as successfully transpiling some real C projects; they rely on static analysis rather than probabilistic models.
  • LLM-based translation is viewed skeptically: inherent approximation risks introducing subtle bugs beyond what test suites catch; formal methods or other verification would be needed.
  • Large targets like SQLite/Apache/Nginx are considered too big for current tools; success stories tend to be smaller codebases.

Complexity: Rust vs C/C++ and learning curve

  • Multiple comments compare complexity levels: Rust is seen as far more complex than C but substantially less convoluted than modern C++ (with its many initialization forms, value categories, SFINAE, exceptions, move semantics rules, etc.).
  • A recurring theme:
    • C++ complexity often produces silent undefined behavior when misunderstood.
    • Rust’s complexity typically manifests as compiler errors and guidance, making it more “learn-as-you-go” and safer, especially for teams and juniors.