Rust in the NetBSD Kernel, and other odd decisions(bentsukun.ch)
14 pointsby jaypatelani12 hours ago4 comments
  • akagusu4 hours ago
    We need memory safety but Rust is not the answer.

    It has no formal spec, changes too fast, depends on third party libraries that change faster than I can breath, and is controlled by a foundation that is controlled by big tech corps.

    What could go wrong?

    • pjmlp3 hours ago
      It has a partial spec.

      https://ferrous-systems.com/blog/ferrocene-25-11-0/

      Lets not forget not having a formal spec apparently wasn't an issue for C, which only got standardized in 1989, and even K&R C only specified a subset of its behaviours, which is a reason why there is so much UB, and implementation specific behaviours with YOLO C, as the Fil-C author likes to call it.

  • nextaccountic7 hours ago
    > In general, the bootstrap relies on a binary package of the previous version. This is unacceptable for an otherwise source-only, self-contained distribution like the NetBSD sources.

    This does not paint the full picture. Rust can be bootstrapped with mrustc, which is written in C++

    https://github.com/thepowersgang/mrustc

    Now, mrustc supports only Rust 1.74. To build Rust 1.92, you need almost 20 builds. But this can be done from source

    Guix has written about bootstrapping Rust from source (they care a lot about this). Here is how it looked like in 2018

    https://guix.gnu.org/nb-NO/blog/2018/bootstrapping-rust/

    • stockerta7 hours ago
      And this is good because? Seriously, modern devs have lost their minds if they think that this state of affairs is okay.
      • rcxdude2 hours ago
        For a good while this process was just straight up not possible for C and C++, until someone put in a lot of effort to recreate the bootstrap process for reasons of reproducible builds (and it's still a long and complicated process I think only a few people have done). For decades people were just building from source with compilers that had extremely long and undocumented bootstrap chains (they may have documentation for how to bootstrap from a different C or C++ compiler, but there wasn't one that would start from scratch).
      • BrouteMinou6 hours ago
        I laughed reading the comment above yours. I also laughed reading yours, you are so right on. Next, I am expecting someone telling that there is a javascript on github to automate that build process...

        This is not what I was expecting computer science to become, 30 years ago...

        • stockerta6 hours ago
          And that JS project needs only 1Gb of node.js modules to run. Aren't computers fun? /s
      • anthk4 hours ago
        Go need a smaller chainloading process from C/C++ too. But the good thing it's there are prebuilt self-contained binary ports from every OS to almost any OS so you can bootstrap it with very little.
  • tancop2 hours ago
    this is the right way to do it. just explain why you think rust is not a good match for your project right now. no politics and no hate for the language.
  • Surac5 hours ago
    if it can't be build with Ansi C or perhaps old style C++ it is not self contained i think. depending a Language on some fast moving binarys is in my eye a bad decission. Excuse my english. im not a native speaker.
    • rcxdudean hour ago
      Why are C and C++ special in this regard? I could just as well claim it's not self-contained unless you can start from source and a snippet of inspectable machine code, like Guix can (which still has fairly significant gaps in what you could call 'completely self contained', if you wanted to poke holes in it).
      • ronsoran hour ago
        C is special because it's possible to relatively easily implement a good-enough C compiler for bootstrapping if needed. It would be under 15,000 lines of code in most languages.

        C++ certainly isn't that special. It's a pain to implement, but so is Rust.

    • bandrami4 hours ago
      There are self-hosted Forths
      • anthk4 hours ago
        Subleq and Eforth can self-compile, yes.

        Being base.dec a subleq EForth image and eforth.fth the source code, to create a new one:

               ./subleq base.dec < tuned_eforth.fth > new.dec

 And Uxn partially. You can run the compiler as a UXN rom (Drimflim.rom).
        So by just having a recent working VM you can compile the rest with uxn2 or 'uxncli dribflim.rom app.tal app.rom'. Tal files are source files.