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. pjmlp+z21[view] [source] 2026-02-03 12:16:57
>>akagus+bQ
It has a partial spec.

https://ferrous-systems.com/blog/ferrocene-25-11-0/

Lets not forget not having a formal spec apparently wasn't an issue for C, which only got standardized in 1989, and even K&R C only specified a subset of its behaviours, which is a reason why there is so much UB, and implementation specific behaviours with YOLO C, as the Fil-C author likes to call it.

◧◩◪
3. snovym+2K1[view] [source] 2026-02-03 16:03:45
>>pjmlp+z21
> Lets not forget not having a formal spec apparently wasn't an issue for C

C emerged in the 1970s when there weren't many other options, and it was rapidly propagated because US antitrust laws forced AT&T to inexpensively license Unix (and by extension C) to universities and research institutions.

That was half a century ago.

I am a supporter of Rust adoption, but the line of reasoning that "C didn't need X, so Rust shouldn't either" is fundamentally flawed.

The time difference between today and C's public emergence is the same as the time between C's emergence and the 1920s. The field of computing is radically different today and any language that wishes to see wider adoption now must play by a completely different set of rules than those of 50 years ago.

[go to top]