zlacker

[return to "Rust in the NetBSD Kernel, and other odd decisions"]
1. akagus+bQ[view] [source] 2026-02-03 10:46:39
>>jaypat+(OP)
We need memory safety but Rust is not the answer.

It has no formal spec, changes too fast, depends on third party libraries that change faster than I can breath, and is controlled by a foundation that is controlled by big tech corps.

What could go wrong?

◧◩
2. budgef+Jz1[view] [source] 2026-02-03 15:23:24
>>akagus+bQ
> changes too fast

The core language has been static for ages, and breaking changes are handled by the edition system so you can use a modern compiler to build code on old syntax. Since the 1.0 release ten years ago there have been four editions.

It's absolutely not changing too fast

> depends on third party libraries that change faster than I can breath

No it doesn't. The standard library is already sufficient for a lot of work; and there is an unhosted version with a "core" version of that standard library which has zero dependencies.

Modern Rust, Java, Python, TypeScript etc. developers choose to use a lot of third party libraries; but that's only because the tooling and ecosystem are both good enough to facilitate that. Nothing about the language forces it.

◧◩◪
3. johnny+k03[view] [source] 2026-02-03 21:31:41
>>budgef+Jz1
the proof is right there in all the discussion about rust in the linux kernel too.
◧◩◪◨
4. pornel+wl3[view] [source] 2026-02-03 23:27:42
>>johnny+k03
Not sure if you mean proof of changing too fast …or not fast enough?

Linux has a wishlist of features they want for kernel development, and Rust has been working towards adding them.

Here's the paradox: Rust is very careful about compatibility and stability, the stable releases are changing slowly. But the Rust for Linux project wants to use the newly prototyped features right away, so they depend on not-yet-released features from unstable nightly versions of Rust.

[go to top]