Live data from Hacker News

The Case for Rust in the base system

mail-archive.freebsd.org

61–70 of 155 posts

Re: The Case for Rust in the base system

#61
post #53

Earlier quoted context omitted.

The Go/Rust rivalry is just a peanut gallery meme. It’s never been a real thing IMO.

Yeah, go competes with Java and Python. Rust is in a different class of tools.

I would narrow it even further: Go competes with Java. Their forte is both programming-in-the-large on the backend.

It's much harder to manage a large codebase/application with Python, but it excels at data science and research programming, which Go and Java do not.

(Obviously, there is overlap between all, and you could do anything in any language.)

Re: The Case for Rust in the base system

#62
post #54

Earlier quoted context omitted.

If these architectures can't muster enough manpower to keep up with modern toolchains then they are living on borrowed time. Maintainers of active, modern development projects have a limited tolerance for anachronism before they say "get a modern toolchain up and running or get left behind, we're sick and tired of C89".

[flagged]

You go to parties where people are passionate about 32-bit PowerPC?

... can you invite me? This sounds great.

Re: The Case for Rust in the base system

#63
post #41

Earlier quoted context omitted.

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…

All mainstream languages treat backwards compatibility as paramount at this point, it's table stakes at this point. Rust is no exception.

I will admit that because the library ecosystem in Rust is younger, you do see things like Clap's breaking changes more often than in other languages.

Re: The Case for Rust in the base system

#64

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.

Maybe in the 1990s. Now, try getting it running even on a network edge platform like those from Netgate. NetBSD's hardware support is singularly unstable and unusable.

Most new platforms port to Linux, commit drivers to the Linux kernel, and ignore the other platforms. The other platforms don't really seem to bother anymore, unfortunately. Things have bit-rotted to such an extent that FS will destroy large amounts of data and.. nobody seems to notice. Kernel panic reports are ignored. Debuggers fail to set functional breakpoints on native hardware. CPU quirks that need workaround to prevent panics are never committed.

Meanwhile, developing this kind of expertise is about as far from the minds of younger experimenters and hackers now as baking cakes and permaculture gardening were from the 00s hardware hackers decades ago. Not only is it far from the minds of younger experimenters, but even attempting to develop it hits a hard wall of hardcore, draconian behavioural purists, secops fashionistas who deride essentially any burgeoning attempts at writing drivers, and language revolutionaries who rage extensively at people for writing any new code in any language but their own favourite.

The situation is pretty harsh and it's likely not going to get any better anytime soon.

Re: The Case for Rust in the base system

#65
post #59

Earlier quoted context omitted.

The Go/Rust rivalry is just a peanut gallery meme. It’s never been a real thing IMO.

Go is what I reach for if my other options might be Java or Python but I don’t want deployment and support to be really stupid and awful. Rust’s close alternative is C++. Maybe also C? I don’t know if Rust can fill its niche of ultra-portable libraries that are relatively easy to import and use in tons and tons of other languages & systems.

Other than LLVM portability concerns, I think Rust can for sure replace C/C++ libraries (I'm talking DLLs etc).

Sure, there will be a small C ABI shim but the developer experience writing in Rust I think is worth it.

Also, nowadays whenever I want to write a fast Python extension, I don't think twice before using pyo3, super simple to write and build.

Re: The Case for Rust in the base system

#66

Earlier quoted context omitted.

Can't you do that now? The article lists ports tools doing those things already

Sure I can but Rust in the base system would provide: - A stable target, and - Lots of FreeBSD specific Rust code to read from expert FreeBSD programmers, as guidance - Probably better ability to build ISOs of my own that include the base system and my jail and ZFS management Rust programs, so that I can install servers from that ready-made ISO and have less post-install work to do

In terms of server install ISOs, I can highly recommend mfsBSD, and also cloud-init to trigger post-install setup

Re: The Case for Rust in the base system

#67

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. On the one hand, what Rust essentially forces you to do is just to program according to proper RAII principles that an experienced C++ programmer would already know and should already be using (especially once polonius lands), it's just better at checking failure to do so than any sanitizer or linter could ever be, so it's a way to avoid having to deal with annoying, hard to track down memory bugs. And in fact, the greater confidence static lifetime guarantees give you allows you to do things like using move semantics more where C++ programmers would have to use copies out of defensive programming. That's predominantly why I personally use it, as far as memory safety goes. On the other hand, [around 60-70% of serious security bugs have been proven to be caused by memory safety across many different projects](https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...) so if you do care about security in what you're doing, it's a boon there too.

Re: The Case for Rust in the base system

#68

Earlier quoted context omitted.

[flagged]

You go to parties where people are passionate about 32-bit PowerPC? ... can you invite me? This sounds great.

They might be Amigans which seems like a pretty bad outcome. Look forward to an hour or more of someone who is enthusiastically wrong about a broad range of topics and has been scammed for thousands of dollars without learning a thing from the experience. Oh the new one is faster and cheaper, but you had to get in early to lock in the price? And the delays have really only been a couple of years? Right, yes...

Re: The Case for Rust in the base system

#69
post #54
post #19

To strongman the "anti" case: I believe that FreeBSD still nominally supports a number of architectures that have immature or no Rust support, which seems like a major blocker to (at least) rewriting major system components like devd in Rust. And build times are already a problem -- the joke five years ago was that the FreeBSD build was a wart on the side of Clang. Doubling that isn't ideal. That said, I'm a big Rust…

If these architectures can't muster enough manpower to keep up with modern toolchains then they are living on borrowed time. Maintainers of active, modern development projects have a limited tolerance for anachronism before they say "get a modern toolchain up and running or get left behind, we're sick and tired of C89".

I feel like that might leave embedded devices without an upgrade path, and those are the devices that needs to longest "warning". So yes, borrowed time, but that might be a decade.

That no to say that Rust shouldn't be considered, but maybe initially for new development or selective rewrites. Some of the mentioned, like nscd or devd in particular, shouldn't be that high on the list. The ZFSd should be fairly safe, as that's mainly needed on the larger platforms.

Re: The Case for Rust in the base system

#70
post #5

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

One of the biggest things about Rust for me is that it's essentially Prometheus, bringing the fire of modern languages and more advances PL theory to systems programming, which imo is sorely needed. We don't need a 10% better C or C++, we need a huge jump for the field. Rust I think does this. They have:

1. A type system that's deeply inspired by OCaml, a language that's designed and used by a lot of programming language research people and is widely praised (just look at how every other language — C#, Java, Kotlin — is suddenly trying to pile half baked imitations of ML features like ADTs and deep pattern matching onto their existing OOP type systems), except they've both imemented the type system correctly and fully, and also filed off all the warts and awkward features, and replaced OCaml's verbose and underpowered first class module system with Haskell style type classes

2. got amazing, highly flexible and generalized iterator and monad support (you can use iterator methods on monads), basically second only to Haskell itself, that compiles down to the equivalent of hand written assembly code loops

3. an error handling system using monads that neatly sidesteps the issues with both traditional C style error handling and exceptions that combines with point two in an exponential curve of awesomeness for error handling

4. hygienic (from Racket) and procedural (eg Common Lisp) macros

5. And finally ofc their statuc memory safety and race condition safety, which is based on linear types ala Idris.

But most importantly, Rust's designers seem to IMO have carefully picked only the advanced programming language features that tend to make your code clearer as well as more correct, and help you model problems at the right level of abstraction to be intuitive, and also only features that can be implemented in a way that is as performant as the equivalent C++ code, roughly speaking at least. They also seem to have been very careful with how they integrate and implement everything in order to uphold those goals.

So you get to have 90% of the power of a language like Haskell, in a language that performs like, and has the low level capabilities of, C++, with the extra benefit of — for instance — less dogmatic puritanism and more deterministic and comprehensible performance and execution properties then Haskell, and less Lovecraftian horror full of surprise gotchas than C++.

It's kind of like the ultimate pragmatic language for someone like me who has gone deep into pure functional languages and other esoteric languages and wants to have as much as of that goodness as is practical.

Post reply on HN