Live data from Hacker News

The Case for Rust in the base system

mail-archive.freebsd.org

31–40 of 155 posts

Re: The Case for Rust in the base system

#32
post #17

Earlier quoted context omitted.

Rust‘s type system prevents memory safety bugs because it reasons about object lifetimes statically. At the same time rust allows you to write systems code on bare metal.

> it reasons about object lifetimes statically. How does that differ from RAII? I think i misunderstand you or lack knowledge, because this sounds exactly like RAII. I know that rust has major compile time checks, but saying that the difference is that it reason about life time as difference to c++ is misleading. I think the major point of c++ compared to c is that c++ "reason about object lifetime statically" with d…

Rust and C++ work very similarly with respect to objects you own. In both languages they get cleaned up by a destructor when they go out of scope. However, Rust also has a lot of language features that deal with objects you borrow, i.e. have a pointer to. In C++ you might make a "use-after-free" mistake and hold a pointer to an object that's already been destructed, which can lead to all sorts of memory corruption. In Rust, the same mistake almost always results in a compile-time error. The part of the compiler that enforces all this is called the "borrow checker", and getting used to the borrow checker's rules is a big part of Rust's learning curve.

One thing C++ programmers might be interested to learn, is that this doesn't only apply to simple variables and references; it also applies to library data structures and their methods. The Rust compiler doesn't really "know" what the .clear() method on a Vec does, but it knows enough to prevent you from calling that method while you're holding references to the Vec's elements.

Re: The Case for Rust in the base system

#33

Earlier quoted context omitted.

The stuff that’s included in the system after a standard install, before you install any additional stuff. It’s all in one repository and it’s maintained by the FreeBSD project. Stuff like the kernel, libc, utils, dtrace, compilers needed to build base, ... Basically everything that’s needed for a usable system. It’s updated all together through binary patches, not separately through packages like on Linux. When you…

This is a perfect and concise description.

Not after I added the second paragraph. ;)

Re: The Case for Rust in the base system

#34
post #22

My first thought was that rust doesn't target as many platforms as FreeBSD (at least not well), but looking at https://www.freebsd.org/platforms/ apparently the answer is that FreeBSD doesn't support many platforms anymore so I guess that's no longer a problem.

Yeah, but Rust tier 1 is only x86, x86_64, and arm64. And only Linux. That excludes MIPS, PPC, and arm32, all of which FreeBSD continues to support to varying degrees. x86_64-FreeBSD is a Rust tier 2 "it might work" target, as are arm6/7 and PPC. MIPS is Rust tier 3 "we don't build for it or test on it."

Surely that's not set in stone right? Like FreeBSD could contribute money & resources to hook up CI machines to make it a tier 1 target?

Re: The Case for Rust in the base system

#35
post #22

My first thought was that rust doesn't target as many platforms as FreeBSD (at least not well), but looking at https://www.freebsd.org/platforms/ apparently the answer is that FreeBSD doesn't support many platforms anymore so I guess that's no longer a problem.

Yeah, but Rust tier 1 is only x86, x86_64, and arm64. And only Linux. That excludes MIPS, PPC, and arm32, all of which FreeBSD continues to support to varying degrees. x86_64-FreeBSD is a Rust tier 2 "it might work" target, as are arm6/7 and PPC. MIPS is Rust tier 3 "we don't build for it or test on it."

My understanding of the tiers of support is based on the level of commitment from the community. That is, if the FreeBSD folks wanted to make it a Tier 1 target, they can, “If running the testsuite requires additional infrastructure (such as physical systems running the target), the target maintainers must arrange to provide such resources to the Rust project, to the satisfaction and approval of the Rust infrastructure team.” — https://doc.rust-lang.org/nightly/rustc/target-tier-policy.h...

This seems very much within the realm of the FreeBSD’s capabilities.

Re: The Case for Rust in the base system

#38

Earlier quoted context omitted.

There are two very broad set of features: 1) Memory safety. If you live in the world of kernels and embedded code, your options are mostly C, C++, and (as of just the last few years) Rust. Of those, only Rust reliably prevents memory corruption mistakes like use-after-free. 2) Being a 21st century language. Rust has a lot of features that any new language would be expected to have these days: a unified build system,…

> Memory safety Another very naive question. Are memory safety concerns from a cybersecurity standpoint or from less-dev error standpoint?

Mostly from a less-dev error standpoint but I think you gain in cybersecurity as well, as the language won't let you write code that accesses memory in places it's not supposed to.

Re: The Case for Rust in the base system

#39

My first thought was that rust doesn't target as many platforms as FreeBSD (at least not well), but looking at https://www.freebsd.org/platforms/ apparently the answer is that FreeBSD doesn't support many platforms anymore so I guess that's no longer a problem.

You may have been thinking of NetBSD. NetBSD prides itself on a very broad platform support.

Re: The Case for Rust in the base system

#40

Earlier quoted context omitted.

There are two very broad set of features: 1) Memory safety. If you live in the world of kernels and embedded code, your options are mostly C, C++, and (as of just the last few years) Rust. Of those, only Rust reliably prevents memory corruption mistakes like use-after-free. 2) Being a 21st century language. Rust has a lot of features that any new language would be expected to have these days: a unified build system,…

> Memory safety Another very naive question. Are memory safety concerns from a cybersecurity standpoint or from less-dev error standpoint?

Both, and they're related in the sense that software errors can become exploitable vulnerabilities. This is a handy summary by the NSA: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
Post reply on HN