Live data from Hacker News

The Case for Rust in the base system

mail-archive.freebsd.org

91–100 of 155 posts

Re: The Case for Rust in the base system

#91

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?

Just like C, COBOL will always be with us.

> According to research, up to 850 billion lines of COBOL code are currently running in nearly 30,000 organizations, typically in critical production environments. 90 percent of Fortune 500 companies rely on it. Never has there been this much COBOL in circulation and the volume is only likely to increase for the foreseeable future.

https://www.chrly.pt/en/2023/06/14/cobol-the-immortal-langua...

Re: The Case for Rust in the base system

#93
Pity the heading/topic is not like that:

- The Case for Rust in the FreeBSD Base System

Most Linux folks are not aware of what 'base system' means - and that its related to FreeBSD.

About the Rust inclusion - I would include it - and would add these targets:

    # make buildworld (without Rust)
    # make rust (like Rush without 'buildworld')
    # make buildworldrust ('buildworld' + Rust)
Regards.

Re: The Case for Rust in the base system

#94

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?

Tomato, tomato.

Re: The Case for Rust in the base system

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

What if Rust compiled to C? Wouldn’t that be a good way to support long tail platforms with low effort?

Not necessarily. C isn't a great language to target, since it's full of fun undefined behavior quirks that you will trip over if you look at it slightly cross-eyed. And part of the problem with the long tail platforms is that they can have issues that you don't expect (e.g., function pointers and data pointers might have different representation!).

So the main set of platforms you're looking at are ones that are functional enough to have modern, stable C compilers, aren't too quirky that reasonably portable C code would "just" work, and yet ones that you don't already have support for in Rust. Outside of the embedded space, there's like... fewer than 5 architectures left, the most notable of which probably being Alpha.

Re: The Case for Rust in the base system

#96

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…

Not solving all security issues isn't the same as not solving security issues. I'd rather my financial data be handled by software written in something that solves many whole classes of vulnerabilities than something that solves none of them.

Re: The Case for Rust in the base system

#97
It would be a huge mistake for FreeBSD to adopt Rust in base at this stage, and would likely fracture whatever cohesion exists amongst the current team; it would be "emacs vs. vi" all over again, except worse; it would be that those using emacs wouldn't be able to easily read vi-created documents, and vice versa...

That the very first thing to do is have to fix the compiler and build environment, and only then start to actually use it, is an additional complication.

Re: The Case for Rust in the base system

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

Even arm32 and x86 are Tier 2. Not exactly unusual architectures. The only Tier 1 architectures are amd64 and arm64, i.e. only the absolute mainstream. Not exactly a bastion of architecture support.

Re: The Case for Rust in the base system

#99

> fusefs tests. Absolutely impossible to do in C. I considered Rust, but went with C++ so they could live in base. They are too closely coupled to fusefs(5) to live out-of-tree. Can anyone comment on why this is impossible in C?

Not impossible, but a big pain. vtables can be done by hand, but C++ does that for you. I don't know rust or the problem they are talking about, but I believe something like that.

Re: The Case for Rust in the base system

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

Besides LLVM, there's been progress for a GCC backend, and in google summer of code, a suggested project is a c backend, so that all c compilers may be leveraged.
Post reply on HN