Live data from Hacker News

The Case for Rust in the base system

mail-archive.freebsd.org

71–80 of 155 posts

Re: The Case for Rust in the base system

#71
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]

Please don't do this here, even if another comment is annoying.

Re: The Case for Rust in the base system

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

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

Re: The Case for Rust in the base system

#73
post #60
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".

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/

Re: The Case for Rust in the base system

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

[deleted]

Re: The Case for Rust in the base system

#75
post #73
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/

> If the chip vendors are not willing to develop and upstream a LLVM back-end

oh, my sweet summer child...

Re: The Case for Rust in the base system

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

There's always the mrustc[1] compiler that compiles Rust to C source files. So any platform that can compile C, can also compile Rust (with caveats of course).

Of course, this only means we could, it doesn't necessarily mean we should.

[1]: https://github.com/thepowersgang/mrustc

Re: The Case for Rust in the base system

#77
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 on millions of lines of C.

https://vdocuments.mx/monitoring-the-execution-of-space-craf...

If it's going to impact OS stability and decrease performance and portability of the humble, dependable, simple C, it doesn't belong in the core. C is better than Rust for OS development.

Re: The Case for Rust in the base system

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

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…

If those devices really need updates then the vendor can fork BSD and do the updates they need. It's not like the existing code will stop working on them.

This is also why we LTS versions.

Re: The Case for Rust in the base system

#79

Earlier quoted context omitted.

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

Ha what a bunch of idiots (he says, typing this on his 40% ortholinear mechanical keyboard with two stage spring switches and POM blank keycaps).

Re: The Case for Rust in the base system

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

I assume you are still programming in COBOL?
Post reply on HN