4 ms·

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

by loeg 3y ago

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 believer and think it's the right tool for the job in a lot of situations where the historical answer was C or C++. Maybe it's the right tool for FreeBSD, too.

boricj 3y ago
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".
- midmagico 3y ago
  [flagged]
  - LAC-Tech 3y ago
    You go to parties where people are passionate about 32-bit PowerPC? ... can you invite me? This sounds great.
    - tialaramex 3y ago
      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...
      - LAC-Tech 3y ago
        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).
  - dang 3y ago
    Please don't do this here, even if another comment is annoying.
- duped 3y ago
  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.
  - boricj 3y ago
    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/ https://rust-gcc.github.io/
    - refulgentis 3y ago
      > If the chip vendors are not willing to develop and upstream a LLVM back-end oh, my sweet summer child...
    - duped 3y ago
      You've got the prioritization backwards
- mrweasel 3y ago
  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.
  - patmorgan23 3y ago
    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.
  - kelnos 3y ago
    I feel like those are the kinds of devices that never get manufacturer updates anyway. And even if they did, the manufacturer likely is no longer supporting them. Sure, it's nice to be able to tinker and hack to see if you can upgrade them yourselves, but is it worth maintaining architecture support for that kind of use case? Not asserting that is definitely not, but I think it's worth considering.
- pharmakom 3y ago
  What if Rust compiled to C? Wouldn’t that be a good way to support long tail platforms with low effort?
  - jcranmer 3y ago
    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.
perlclutcher 3y ago
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 https://github.com/thepowersgang/mrustc
nocombination 3y ago
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-craft-flight-software.html?page=11 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.
- richardwhiuk 3y ago
  I assume you are still programming in COBOL?
  - nocombination 3y ago
    It's not what you program in that matters—it's how you test and ensure quality results.
    - littlestymaar 3y ago
      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.
    - kstrauser 3y ago
      I like that Rust tests my code as I write it.
      - dboreham 3y ago
        Looks for lollipop...
raggi 3y ago
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.
- raggi 3y ago
  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.
  - kjs3 3y ago
    This. FreeBSD probably shouldn't be held back by VAX or MC88k support, but I'd be really disappointed if NetBSD for example abandon them.
- mike_hock 3y ago
  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.
  - est31 3y ago
    > Even arm32 and x86 are Tier 2. Not exactly unusual architectures. There is 32-bit x86 tier 1 targets like i686-unknown-linux-gnu. > The only Tier 1 architectures are [...] only the absolute mainstream. Not exactly a bastion of architecture support. Tier 1 means that the target has the full testsuite run against it for each single pull request. Running the CI is computationally extremely complex, and it is hard to provide a reliable and fast CI service for most architectures.
    - mike_hock 3y ago
PartiallyTyped 3y ago
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.

by loeg 3y ago

boricj 3y ago

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

midmagico 3y ago
[flagged]
- LAC-Tech 3y ago
  You go to parties where people are passionate about 32-bit PowerPC? ... can you invite me? This sounds great.
  - tialaramex 3y ago
    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...
    - LAC-Tech 3y ago
      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).
- dang 3y ago
  Please don't do this here, even if another comment is annoying.
duped 3y ago
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.
- boricj 3y ago
  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/ https://rust-gcc.github.io/
  - refulgentis 3y ago
    > If the chip vendors are not willing to develop and upstream a LLVM back-end oh, my sweet summer child...
  - duped 3y ago
    You've got the prioritization backwards
mrweasel 3y ago
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.
- patmorgan23 3y ago
  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.
- kelnos 3y ago
  I feel like those are the kinds of devices that never get manufacturer updates anyway. And even if they did, the manufacturer likely is no longer supporting them. Sure, it's nice to be able to tinker and hack to see if you can upgrade them yourselves, but is it worth maintaining architecture support for that kind of use case? Not asserting that is definitely not, but I think it's worth considering.
pharmakom 3y ago
What if Rust compiled to C? Wouldn’t that be a good way to support long tail platforms with low effort?
- jcranmer 3y ago
  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.

perlclutcher 3y ago

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 https://github.com/thepowersgang/mrustc

nocombination 3y ago

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-craft-flight-software.html?page=11 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.

richardwhiuk 3y ago
I assume you are still programming in COBOL?
- nocombination 3y ago
  It's not what you program in that matters—it's how you test and ensure quality results.
  - littlestymaar 3y ago
    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.
  - kstrauser 3y ago
    I like that Rust tests my code as I write it.
    - dboreham 3y ago
      Looks for lollipop...

raggi 3y ago

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.

raggi 3y ago
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.
- kjs3 3y ago
  This. FreeBSD probably shouldn't be held back by VAX or MC88k support, but I'd be really disappointed if NetBSD for example abandon them.
mike_hock 3y ago
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.
- est31 3y ago
  > Even arm32 and x86 are Tier 2. Not exactly unusual architectures. There is 32-bit x86 tier 1 targets like i686-unknown-linux-gnu. > The only Tier 1 architectures are [...] only the absolute mainstream. Not exactly a bastion of architecture support. Tier 1 means that the target has the full testsuite run against it for each single pull request. Running the CI is computationally extremely complex, and it is hard to provide a reliable and fast CI service for most architectures.
  - mike_hock 3y ago

PartiallyTyped 3y ago

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.