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.