Re: The Case for Rust (in any system)

On Sep 5, 2024, at 11:34 AM, Tomek CEDRO <tomek@cedro.info> wrote:
> 
> wow! this is undeniable argument even for someone who opposes the idea (like me) :-)

Not really!

Showing that a present system has issues does not imply in any
way that a proposed new system (or major change) will fix the
said problems! This is a common fallacy that people fall for.
Many people. Many many people :-)

Nor does it say anything about the cost & disruption of making
such a change, or how long will it take for the change to realize
the promise.

I did a quick check to see how code size has increased (just
focusing on the kernel):

Snapshot	  LoC
 R2.1.0:         464163
 R3.1.0:        1036969
 R4.1.0:        1364739
 R5.1.0:        2183960
 R6.1.0:        2718891
 R7.1.0:        3396813
 R8.1.0:        4029778
 R9.1.0:        5436430
R10.1.0:        6268965
R11.1.0:        7902854
R12.1.0:        8216741
R13.1.0:        8900711
R14.1.0:        9769864
current:        9899932 (as of this morning)

On average about 775K lines are added per release, with a couple
of increases over a million. So even if *all* the new code that
gets added is in Rust and is totally bugfree, it will take a
further 12-13 years before the bugprone C code goes down to 50%.
[By then Rust may not longer be a hot language but that is for
 another thread (or async/await)]

The point being, even if you add Rust, there is a long term need
to "do better" in the C code.

> maybe this is time to simply crate a new Open-Source OS from scratch written in Rust?
> 
> manual rewrite of existing code seems too complex from a technical standpoint. sometimes it's just easier to start from scratch?

This would be about as quixotic as DARPA's TRACTOR program
(TRanslate All C code TO Rust)! No such AI exists today. Any
auto translated code needs to be hand checked. I suspect you're
better off teaching the AI about the common code bugs in C and
how to fix them or at least detect them.