Live data from Hacker News

The Case for Rust in the base system

mail-archive.freebsd.org

81–90 of 155 posts

Re: The Case for Rust in the base system

#81
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…

How is this relevant to parent comment?

Re: The Case for Rust in the base system

#82

Earlier quoted context omitted.

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…

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.

Re: The Case for Rust in the base system

#83

Earlier quoted context omitted.

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.

That post is from 2019, the layoffs of the teams were in 2020.

Mozilla is still a member of the foundation, so they do support it in that sense, but they are one of many companies that do so.

Re: The Case for Rust in the base system

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

Re: The Case for Rust in the base system

#85
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…

Yeah, the architecture point comes up in lost of rust in core type discussions, but I think when it comes to the BSD's it's actually a critical argument. I'm not particularly excited by limping along unusual architectures that most of the contributors can't perform reproductions on, but the BSD's are a bastion in this space and something probably has to be. Addressing this issue in both Rust and LLVM would be valuable at large.

Re: The Case for Rust in the base system

#86

Earlier quoted context omitted.

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 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 of FreeBSD my primary question: is it really necessary? Or is it just because a bunch of Rustaceans want to?

Re: The Case for Rust in the base system

#87
post #85
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…

Yeah, the architecture point comes up in lost of rust in core type discussions, but I think when it comes to the BSD's it's actually a critical argument. I'm not particularly excited by limping along unusual architectures that most of the contributors can't perform reproductions on, but the BSD's are a bastion in this space and something probably has to be. Addressing this issue in both Rust and LLVM would be valuabl…

It seems actually FreeBSD has dropped a lot of old platforms in recent versions, so this may not be a problem anymore. I imagine it would be with some other BSD's.

Re: The Case for Rust in the base system

#88

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.

The amount of budget and time you have for the all project is finished, and in practice it's much easier for management to skip testing and QA than to reduce the scope of the project / the amount of features.hence the terrible quality that's plaguing this entire industry.

Re: The Case for Rust in the base system

#89
post #51

Earlier quoted context omitted.

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

> getting used to the borrow checker's rules is a big part of Rust's learning curve. It’s also a big part of C and C++’s learning curves, it’s just that the compiler doesn’t tell you about it; you’re being taught by segfaults and silent memory corruption instead.

Very true. My hot take on this is, if you want to learn C or C++ "properly" (not just well enough to get your homework done, but well enough to write medium-size programs that pass ASan/UBSan/TSan), the fastest way is to learn Rust first. This is emphatically not because Rust is quick to learn, but rather because ownership and borrowing discipline takes years of mentorship to absorb in C and C++, and plenty of career programmers never really get it.

Re: The Case for Rust in the base system

#90

Earlier quoted context omitted.

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

Just to avoid any “cyclist rides more aggressively when wearing helmet” type behaviour:

It’s probably worth nothing that that vast majority of, and of large scale attacks, is basic shit that has nothing to do with memory safety.

There’s benefit to memory safety, but just cause you’re wearing a helmet doesn’t mean you’re completely safe.

Additionally, it’s not Google overall, but chromium project that find this, as well as not Microsoft overall, but specifically Windows. These are two projects that will naturally see a much higher rate of memory safety issues.

Post reply on HN