Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case for Rust in the base system

mail-archive.freebsd.org

Post reply on HN
Print view View original

41–50 of 155 posts

Re: The Case for Rust in the base system

#41

Post by influx »

bluejekyll wrote: post #16
influx wrote: post #14

Ironic since I’ve been thinking: FreeBSD : Go :: Linux : Rust

Can you explain your comment a little more? I don’t understand the relationship between these that you’re suggesting.

FreeBSD and Go are slow to change, extremely hesitant to introduce API changes, and adhere more towards tradition.

Rust and Linux are changing rapidly and aren’t as worried about completely uprooting entire systems. See for example sys v init vs systemd.

Go didn’t get generics until 1.18 and promises backwards compatibility.

In Rust, the popular command line parser Clap completely changed its API between 3 and 4 such that you’ll need to update your code.

As much as I like predictably and simplicity, I think Rust will largely be more successful similar to Linux winning over FreeBSD.

Re: The Case for Rust in the base system

#42

Post by ijustlovemath »

loeg wrote: post #22
yjftsjthsd-h wrote: post #11

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

From that link, it looks like FreeBSD is beginning to phase out MIPS and PPC entirely, and 32-bit ARM is nearing phase-out. It seems entirely reasonable that over the next few years it takes to integrate a Rust core that the "blessed" architectures of both projects will be aligned

Re: The Case for Rust in the base system

#43

Post by oconnor663 »

hartator wrote: post #30
oconnor663 wrote: post #21

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 for sure, and which one is a bigger deal depends a lot on context.

Cybersecurity issues make Rust a good choice for writing parsers for example. File format parsers handle scary data from the internet (JPEG, X.509, etc), and those often contain addresses and offsets that turn into raw pointers in the implementation, so they're a common source of security bugs. At the same time, they're usually isolated behind a reasonably tight API, so it can be practical to rewrite them in Rust even when all the calling code is still C or C++ or even Python.

On the other hand, fewer-mistakes-sucking-up-dev-time is an especially big deal in multithreaded code. There was a story from Mozilla about how they'd tried to add threading to part of Firefox (I think it might've been the CSS engine?) and failed multiple times, but then they succeeded in Rust. Threading bugs tend to be painful to reproduce, and Rust's compile-time checks are extremely valuable there.

Re: The Case for Rust in the base system

#44

Post by brobinson »

hartator wrote: post #30
oconnor663 wrote: post #21

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?

Microsoft, Google, and other companies have all determined that about 70% of CVEs are memory-related. Here's the US government's take: https://www.cisa.gov/news-events/news/urgent-need-memory-saf...

These memory-related exploits disappear with Rust aside from in "unsafe" blocks (possibly the worst named keyword in any language... it should have been called "trusted"), and that means you have a smaller and more easily auditable attack surface for these types of memory-related exploits. Some code (e.g., FFI) can't be verified as memory-safe by the Rust compiler at compilation time so "unsafe" is there as an escape hatch. I've written a bunch of Rust since 2014 building things like webservers, realtime futures processing algorithms, MEV bots, etc., and I've only had to use "unsafe" a few times.

I've also worked in security on products at Fortune 100 companies, and C is a constant nightmare for CVEs. I think I have PTSD from having to update libcurl. The more software we have written in memory safe languages, the better off we all are.

Re: The Case for Rust in the base system

#46

Post by jitl »

bluejekyll wrote: post #16
influx wrote: post #14

Ironic since I’ve been thinking: FreeBSD : Go :: Linux : Rust

Can you explain your comment a little more? I don’t understand the relationship between these that you’re suggesting.

Go and FreeBSD share the similarity of a large base system that’s useful out of the box: in go the runtime and large, useful stdlin, in FreeBSD the base system composed of the kernel and standard programs. Both also encourage a certain cultural aesthetics around that base of accepting and going with the flow of the base’s limitations. For FreeBSD, things like composing posixly-correct sh scripts, BSD Makefile stuff. For Go, boilerplate, if err != nil, for a long time “you don’t need generics”.

In contrast, Linux and Rust are both smaller core systems with more exposed complexity, but also require a large user space to make the core useful. Linux is just a kernel so you gotta bring everything else in the OS. Rust you need libraries for things most other languages (including Go) include, like regex, async, etc. However both Linux and Rust have a culture of adapting the system to work exactly how you like, in Linux again you bring everything you want - want systemd? Cool. Don’t want systemd, that’s cool too. In rust, people go absolutely crazy with macros and abstractions and likely it will still be plenty fast at runtime.

Re: The Case for Rust in the base system

#47

Post by masklinn »

eloisant wrote: post #38
hartator wrote: post #30

Earlier quoted context omitted.

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

It's mostly from the cybersecurity standpoint actually, at least for large projects / companies. MS, Chromium, Project Zero, Mozilla, have pretty consistently found that north of 70% of vulnerabilities were rooted in memory safety.

The dev-error is broader language guarantees, which dovetail into memory safety but are useful on their own e.g. data race safety, rich type system, ...

Re: The Case for Rust in the base system

#48

Post by hartator »

formerly_proven wrote: post #20
hartator wrote: post #5

Very naive question. What's the main selling point of Rust besides being stably sponsored by Mozilla?

I don’t think Mozilla has had any major sponsorship role for a few years now?

> https://internals.rust-lang.org/t/mozilla-is-hiring-for-the-...

It seems that some Rust folks are still on Mozilla payroll.

Re: The Case for Rust in the base system

#49

Post by jcranmer »

hartator wrote: post #5

Very naive question. What's the main selling point of Rust besides being stably sponsored by Mozilla?

I can't give you just one selling point, because Rust has two main competitive features, and it's hard for me to say which one is enticing FreeBSD more here:

1. Rust has a more modern sense of computer primitives than C does. For example, C has the char-short-int-long-long long set of types which correspond to 8, 16, 32, and 64 bit integers in practice (and yes, 5 types for 4 sizes), whereas Rust has u8/u16/u32/u64. Rust also has a builtin slice type, which is a desperately needed notion of pointer + size of array, and C's lack of such type has proven to be the source of much malware. The standard library is also somewhat richer too, you have better support for things like threads or networking than C/C++ does. But note that Rust is still like C in that it has a very thin runtime layer, and can also go a step further and have "no" standard library at all, which is necessary in several contexts.

2. The borrow checker. Effectively, use-after-free (or any other lifetime issue) vulnerabilities become compiler errors, and even many kinds of data races are also turned into compiler errors. Also it can do things like make iterator invalidation issues a compiler error as well.

Re: The Case for Rust in the base system

#50

Post by [deleted] »

oconnor663 wrote: post #32
dosshell wrote: post #27

Earlier quoted context omitted.

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

[deleted]
Post reply on HN