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

101–110 of 155 posts

Re: The Case for Rust in the base system

#101

Post by nordsieck »

nocombination wrote: post #86
jimberlage wrote: post #84

Earlier quoted context omitted.

The Curiosity rover might be doing ok, but the many places that have my social security number are not. I care more about the latter than the former.

Right—and maybe those places ought to install OpenBSD. https://www.openbsd.org/ Rust is not immune to security vulnerabilities. And at the end of the day, social engineering will steal more data than "hacking the mainframe". Why break in when you can just ask to be let in? OpenBSD has a great security track record because they resist excessive change and prefer simplicity . For those who want to add Rust to the core…

> Right—and maybe those places ought to install OpenBSD.

Sure.

But running on OpenBSD doesn't solve application level vulnerabilities. And sure - OpenBSD may help limit the ability of an attacker to leverage one vuln into compromising the entire system. But if the original attack was important enough, that's cold comfort.

Re: The Case for Rust in the base system

#102

Post by yjftsjthsd-h »

tialaramex wrote: post #39
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.

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

No, I meant FreeBSD, though NetBSD is (much) further on the same spectrum. If I read that Darwin or NT were looking at using Rust, I'd figure that was easy enough; they more or less only target x86 and ARM, which are mostly well-covered by Rust. If NetBSD said they were moving to Rust... I dunno, I'd assume that either Rust had really changed their approach to platform support, or that NetBSD as I knew it had ceased to exist. OpenBSD is actually also on that far end of the spectrum, because they care even more about self-hosting, which means that the inability of rustc to actually run (or at least self-host) on 32-bit x86 is a hard blocker. FreeBSD is in the middle; I knew they don't intend to hit as many hardware platforms as their siblings, but I still thought they had broader coverage than rustc. And (per the page I linked) they used to, but as of the latest releases they've been really cutting down their targets. Which... I dunno, it's practical, but still sad. I guess there's at least still OpenBSD and NetBSD to cover portability.

Re: The Case for Rust in the base system

#103

Post by tialaramex »

logicprog wrote: post #70
hartator wrote: 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 lang…

By the way it's not "race condition" safety. Race conditions are a completely normal part of our world and so Rust can't magically fix race conditions. Bob's going to shred all "10+ year old" paper records "after lunch" and Hannah needs the paper customer list from 2003 for the 2:30pm meeting? Well that's a race, good luck, Rust can't help. However, (safe) Rust can eliminate data races, a very weird special case caused by the difference between how you imagine the computer works and how it actually works.

A data race goes like this: At least two simultaneous execution contexts (maybe threads for example) are looking at the same object X and at least one of them changes it, but there is no particular order of these events agreed between these contexts.

In your head, even with parallel computing everything seems to happen in some sort of global order. A happens before B, or B happens before A. This is called Sequential Consistency, and it's a lie, the machine doesn't actually work like that, but humans can't really understand non-trivial software without this lie, so, all our high level software (and when I say "High level" I mean like the C Programming Language) pretends sequential consistency is always preserved and goes to some lengths to achieve that.

In Rust you can go about your business. (Safe) Rust promises this is true and it'll make damn sure. But in many languages like C or C++, actually you can very easily inadvertently construct a data race, revealing that it was a lie and if you do so all bets are off. Since you probably can't reason about your program's behaviour anyway, they figure "fuck it" and that's Undefined Behaviour.

Bonus round for languages which do better than most: Go says if you race a trivial object like an integer, you lose Sequential Consistency but this isn't automatically UB. Complex races are UB.

Java says races are never UB, but they do lose Sequential Consistency. Your Java Program is now very, very difficult to understand, but it's not nonsense.

OCaml goes furthest, it says your race isn't UB and it offers very tight constraints on what's wrong. OCaml's work on this is relatively new, so it may be a while before we're confident whether this is a manageable situation normal humans (well OCaml programmers) can handle.

Re: The Case for Rust in the base system

#104

Post by avgcorrection »

nocombination wrote: post #86
jimberlage wrote: post #84

Earlier quoted context omitted.

The Curiosity rover might be doing ok, but the many places that have my social security number are not. I care more about the latter than the former.

Right—and maybe those places ought to install OpenBSD. https://www.openbsd.org/ Rust is not immune to security vulnerabilities. And at the end of the day, social engineering will steal more data than "hacking the mainframe". Why break in when you can just ask to be let in? OpenBSD has a great security track record because they resist excessive change and prefer simplicity . For those who want to add Rust to the core…

> For those who want to add Rust to the core of FreeBSD my primary question: is it really necessary? Or is it just because a bunch of Rustaceans want to?

Bfha... the link is a thread by the FreeBSD devs. Stop it with this language evangelist strawman.

Re: The Case for Rust in the base system

#105

Post by duped »

boricj wrote: post #73
duped wrote: post #60

Earlier quoted context omitted.

If by "modern" you mean "LLVM" then I'm sure the chip vendors will get right on it when they have a GCC backend that works and all of their customers use it.

There is a Rust front-end for GCC that is under active development [1]. If the chip vendors are not willing to develop and upstream a LLVM back-end then they can start contributing to it as an alternative. [1] https://rust-gcc.github.io/

You've got the prioritization backwards

Re: The Case for Rust in the base system

#106

Post by tialaramex »

yjftsjthsd-h wrote: post #102
tialaramex wrote: post #39

Earlier quoted context omitted.

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

No, I meant FreeBSD, though NetBSD is (much) further on the same spectrum. If I read that Darwin or NT were looking at using Rust, I'd figure that was easy enough; they more or less only target x86 and ARM, which are mostly well-covered by Rust. If NetBSD said they were moving to Rust... I dunno, I'd assume that either Rust had really changed their approach to platform support, or that NetBSD as I knew it had ceased…

Darwin isn't going to do Rust. Apple's plan is that Swift can be made to do everything necessary for their operating system. Since Apple are bad at doing more than one thing, they've settled on the idea of a single successor language, chosen under advice but by senior management. So, Swift. Unless it proves impossible to use Swift (and I doubt it) that's what they'll do.

For everything above the line, Swift is definitely viable today. Expect shiny new stuff from Apple to be Swift first, or even sometimes Swift only. If you're an Apple First developer, you should learn Swift, or you are going to be relegated to maintaining legacy software in the next maybe 3-5 years.

Microsoft is already solidly on the Rust bandwagon. So yes, Rust for NT is very possible. Unlike Apple though the Microsoft corporation has always been able to do a bunch of things at once, even if it doesn't always do them all well -- it doesn't need a singular focus to achieve success. So don't expect Microsoft to magically pull effort off C++ and .NET to do more Rust.

Re: The Case for Rust in the base system

#107

Post by IshKebab »

nocombination wrote: post #82
richardwhiuk wrote: post #80

Earlier quoted context omitted.

I assume you are still programming in COBOL?

It's not what you program in that matters—it's how you test and ensure quality results.

That's stupid the language you write in has a huge effect on how you test and ensure quality results. They aren't separate things.

E.g. at one end of the spectrum you have Python where you have to write explicit tests for typos and type errors.

At the other end of the spectrum you have formal verification languages like Dafny that may not require any tests to be written.

Rust is somewhere in-between. It has a very strong type system and lots of features that make memory errors and business errors less likely than in most other languages. You still need some tests, but not as many as with C/C++, Python, JavaScript, etc.

Re: The Case for Rust in the base system

#108

Post by steveklabnik »

tialaramex wrote: post #106
yjftsjthsd-h wrote: post #102

Earlier quoted context omitted.

No, I meant FreeBSD, though NetBSD is (much) further on the same spectrum. If I read that Darwin or NT were looking at using Rust, I'd figure that was easy enough; they more or less only target x86 and ARM, which are mostly well-covered by Rust. If NetBSD said they were moving to Rust... I dunno, I'd assume that either Rust had really changed their approach to platform support, or that NetBSD as I knew it had ceased…

Darwin isn't going to do Rust. Apple's plan is that Swift can be made to do everything necessary for their operating system. Since Apple are bad at doing more than one thing, they've settled on the idea of a single successor language, chosen under advice but by senior management. So, Swift. Unless it proves impossible to use Swift (and I doubt it) that's what they'll do. For everything above the line, Swift is defini…

> Since Apple are bad at doing more than one thing, they've settled on the idea of a single successor language, chosen under advice but by senior management. So, Swift.

Apple has been using Rust for years, and I'm not aware of any decisions to move away from that, though given how secretive they are, I guess that could be a possibility.

> So yes, Rust for NT is very possible.

Rust is already being shipped (in preview) in Windows' kernel.

Re: The Case for Rust in the base system

#109

Post by logicprog »

tialaramex wrote: post #103
logicprog wrote: post #70

Earlier quoted context omitted.

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

By the way it's not "race condition" safety. Race conditions are a completely normal part of our world and so Rust can't magically fix race conditions. Bob's going to shred all "10+ year old" paper records "after lunch" and Hannah needs the paper customer list from 2003 for the 2:30pm meeting? Well that's a race, good luck, Rust can't help. However, (safe) Rust can eliminate data races , a very weird special case cau…

> However, (safe) Rust can eliminate data races,

Yes, thank you for pointing that out, ive had a bad headache for most of the day and knew I was saying the wrong term when I wrote it, but couldn't for the life of me remember what the right one was! And yeah I'm pretty familiar with this, although I wasn't aware of OCaml's strides

Re: The Case for Rust in the base system

#110

Post by saagarjha »

nocombination wrote: post #77
loeg wrote: 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…

Honestly, after being in the software industry for a couple of decades and seeing how many times folks attempt to reinvent the wheel (for commercial or other reasons), I am beginning to sigh when I see how many language zealots there are (not you, just in general). The reality is, Rust does not need to replace everything. Nor should it be held on some kind of pedestal. E.G. Curiosity rover is doing just fine running…

The C code that went into the Curiosity rover was quite expensive.
Post reply on HN