Speculative: Rust for base system components

[Sidju]

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

It is indeed dependent on some "unsafe" libraries to function and there may be exploits in those (Literally applicable to all languages. What is machine code if not a library?), but from what I've gathered you could write those in rust as well using the @unsafe flag. (This probably yields better safety than the c++ glue slapped together by a java programmer to "get the JVM to run, goddammit!". But that isn't really the point.)

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.

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.

-------- Original Message --------
On 5 Jan 2019, 20:41, Igor Mozolevsky wrote:

> On Sat, 5 Jan 2019 at 19:16, Enji Cooper wrote:
>>
>> > On Jan 3, 2019, at 12:24, Igor Mozolevsky wrote:
>> ...
>>
>> > And by what metric is that "safety" measured, how does one measure
>> > "safety" objectively? To me, that sounds like a techie version of
>> > virtue-signalling... Even the Rust-clan seem to be rather confused
>> > about it: https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
>>
>> It’s pretty clear to me what the author means: rust features safe and unsafe
>> extensions, much like C++, Java, Perl, python, tcl, etc. Generally speaking,
>> “unsafe” language features are those that require additional care, like using
>> malloc/free appropriately, avoiding global state, locking resources as needed,
>> etc.
>>
>> > Btw, Java is "safe" too, and it's been around for *much* longer!
>>
>> Not necessarily true. Are you aware of how native java extensions work?
>>
>> Java as a language was written to be generic/platform agnostic, however in
>> order to be useful, Java requires platform extensions. As such, Java
>> supports developers writing glue code in C/C++ (like python extensions),
>> which can have a host of potential issues with memory leaks, concurrency
>> safety, etc, in addition to potential issues with security sandboxing and the like.
>>
>> With the number of zero-day bugs in java that have been in the language
>> in the past few years, I don’t trust the language’s sense of safety in terms
>> of memory management and sandboxing in the JVM.
>
> You're being deliberately obtuse, right? Because there's no "native
> Rust extensions" (i. e. you can't make Rust call a buggy and unsafe
> c-library)? And can you seriously guarantee that there will be no
> zero-day bugs in Rust libraries, there's probably none *found* yet
> simply because hardly anyone does anything serious in it! Your slating
> of Java is just as applicable to Rust with the caveat that Rust has
> been around and thus explored and abused far less. Why would you
> trust automagic memory management in Rust when you don't trust
> Java's? Rhetorical, of course, as there's no sensible answer.
>
> --
> Igor M.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"