Speculative: Rust for base system components

[Igor Mozolevsky]

On Sun, 6 Jan 2019 at 14:09, Sidju wrote:

> >Don't know where you've been for the earlier discussion, but someone
> >did an experiment, and guess what: Rust yielded a massive increase in
> >instruction count for a a simple sum-of-integers program, so it's not
> >just "runtime library" issue. As for "potential bugs," see below.
>
> Wasn't that the experiment that sparked the "statically linked by default"
> sidetrack?
> From all that I have been able to find ( https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-gpp.html )
> rust performs far better than java and go (which is what I contrasted
> to) and is not very far behind c and c++ (which I doubt anything will
> beat for the next 10 years).
>
> Admittedly the codesize is increased even with dynamic linking and
> there is some cost for those ownership checks when they occur,
> but it is not horrendous.

Java was given by me as a parody example, don't know why you've taken
comparison against Java so seriously... The second experiment was
purely on executable instruction count, if I recall correctly, not the
binary size; and I'd rather my processor did little work and slept
than did a lot of work to achieve the same result and ate electricity.



> >> Rust isn't a silver bullet that will fix all bugs. It is a slightly more
> >> abstracted and type checking language that is slightly better for a lot
> >> of things. If you don't find that slight improvement worth the difficulty
> >> it is to learn it, then don't.
>
> >The gist is: learn a better discipline of programming to make better
> >code, not yet-another-many-promises-but-few-deliveries language.
>
> By that reasoning we should never have left the glorious days of
> assembly programming.

I'm very much in favour of that---you wouldn't believe how often I
think "this is so trivial to do in asm" while fighting "safeguards"
and other "curiosities" of C!


-- 
Igor M.