Re: Planned obsolescence ? (*BSD, Rust)

[Riccardo Mottola <riccardo.mottola@libero.it>]

Hi Jan-Daniel,

Jan-Daniel Kaplanski wrote:
> Also, let's not forget that while Rust is memory safe per default, it 
> isn't a bug-free paradise. You can still have logic bugs. Of which 
> there was one recently in the Rust implementation of coreutils, 
> specifically '"date -r file" returns a wrong date'[4], which directly 
> caused unattended upgrades to break in Ubuntu 25.10 [5] (or any other 
> program that relied on a date check of a file for that matter). It 
> goes to show that a rewrite introduces a potential for new bugs that 
> are unrelated to the original implementation, even if that rewrite 
> happens to be in Rust.

nice example where a tool is the issue, certain tools are sold for their 
safety and might give a false sense of safety when using them.

> It feels like the movement to introduce Rust everywhere is more 
> because Rust has become such a buzzword that everyone must use it now 
> and less because of the capabilities of Rust. Not to throw shade, but 
> if the only benefit is memory safety you might as well do a rewrite in 
> any other memory safe language that provides I/O access (e.g. Haskell) 
> instead.

I stand to this analysis... rust has now an aura of safety beyond its 
own merit, it is clearly a buzz or hype. I would rather keep it out of a 
"core" system and leave the language issue to user applications. 
However, we might soon disagree what "core" is and today it becomes 
rapidly complex (e.g. you may want to expect both a SSH and a command 
line package manager which connects through various network options, a 
framebuffer... ).


Perhaps if rust on GCC gives "enough rust" do compile the needed tools, 
it might be enough to support also architectures whic gcc supports, that 
is for now 68k, PPC, Alpa, HP-PA...

Riccardo


[1] https://rust-gcc.github.io/