Speculative: Rust for base system components

Sidju lists at sidju.se
Sun Jan 6 14:09:18 UTC 2019


On 6 Jan 2019, 14:08, Igor Mozolevsky wrote:

>On Sun, 6 Jan 2019 at 11:43, David "Sid" Olofsson wrote:
>>
>> Rust features several limitations on pointer usage by default that increase
>> memory safety by forcing you to write a safe solution. (They are pretty
>> interesting, I recommend looking into it.)

>Rhetorical: remind me what Java's pointer usage policy is again?

From what I have perceived when coding, "pretend they don't exist" and "leave it to the garbage collector".
Rust instead uses compile time ownership and r/w permissions.

>> By moving the bulk of your application out of "unsafe" c or c++ and into
>> heavily type checked, ownership oriented and abstracted rust you would
>> reduce the potential bugs without the performance reduction and large
>> runtime required by java.

>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.

>> 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.
No language will fix a bad programmer, but a good language will help the programmer learn what is bad. ("You are reading an unitilialised variable. That is not allowed." and similar)

I am not saying we should all do everything in rust. I am just saying that it is slightly better at some things and that it should be considered for those things.


More information about the freebsd-hackers mailing list