1. 17
  1. 11

    This could be painful for the BSDs. I doubt anybody wants to require rust in base.

    1. 20

      Rust keeps growing, so it’s only going to get harder to ignore. The focus should be on what needs to be improved to have it in, rather than how to keep it away.

      1. 10

        It is not about ignorance and more about compatibility.

        “Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

        Consider me a skeptic – I think these compiler ecosystems face a grim bloaty future.”


        1. 3

          I wasn’t implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts.

          There may also be compatibility issues but, in 2017, that is a pretty ignorant thing to say about Rust when the uutils project had already existed for years. Or maybe Theo is simply sneering about GNU’s implementation of the POSIX utilities, which uutils attempts to emulate.

          edit: also, started in early 2017, redox-os’s BSD-compatible coreutils project.

          1. 3

            Theo buried the lede in the email. In 2017, it was his considered opinion that it was essentially impossible to include Rust in the OpenBSD base distribution because Rust couldn’t be compiled by base.

            It’s possible that in 2020, this situation has improved, which would mean that a necessary precondition to include Rust programs in OpenBSD base has been fulfilled. It still needs to be proven that replacing tried and true utilities written in C with ones written in Rust would result in meaningful improvements of the quality of the OpenBSD system as a whole.

            1. 4

              It may have improved for i386 (I don’t know) but there are additional platforms that OpenBSD needs to consider.

              Today there are platforms that use clang and some other platforms that can’t use clang and are stuck with the last gcc, but at least 99% of OpenBSD base is just C and so generally most things can compile with either clang or gcc. Bringing rust into base then escalates this “have” vs “have nots” situation and then you start to have “tier 1” (amd64, arm64, i386?) vs “tier2” (sparc64, macppc, etc). Maybe that is already happening though. I imagine NetBSD will be in a similar situation.

              1. 4

                You’re correct, I didn’t even consider the other architectures that OpenBSD supports.

                So to summarize

                1. Rust isn’t supported on all platforms
                2. Rust is too large and complicated to be compiled from source via OpenBSD’s base
                3. Rust offers dubious advantages for OpenBSD
                1. 1

                  Rust offers dubious advantages for OpenBSD

                  In the context of mesa or in OpenBSD using Rust internally?

                  I think those are 2 different arguments. OpenBSD might not want to commit to using (or supporting) Rust, but it cannot decide if another project wants to use Rust for reasons they consider good.

                  1. 1

                    In the context of OpenBSD using Rust internally (as part of base).

                2. 3

                  Hm, so in general, the whole thing would start with upstreaming an OpenBSD target and working with upstream to get it maintained and then getting support in for things they need. i386 is a hard case though, because LLVM support may be lacking (I have no assessment of that).

                  The hard reality here is that all project need to find maintainers for those things and they are few and far between.

                  On the Rust side in general, I’m happy to see that OpenBSD currently maintains their own patches. I tried to encourage OpenBSD folks I met to upstream, but have yet so see that happening. We’re generally happy to accept them given bandwidth and maintenance commitment (bandwidth is a regular issue, but we’re always working to improve that).


                  1. 1

                    Speaking for illumos, for which support ought to appear natively in the next Rust stable release, upstreaming has been a generally pleasant experience. It all took way longer than I expected, at least in part due to the long pipeline from master to stable, but everybody with whom I interacted along the way has been polite and helpful!

                    1. 2

                      Thanks for letting me know! BTW, this is the first time I got the pipeline from master to stable described as “long”, but I can understand where you are coming from!

                      I’m happy to hear that the interaction was pleasant. That’s a good baseline to get the contribution speed up!

              2. 1

                I think should understand the other aspects of it. Rust, at the time, not being able to compile on i386.

        2. 1

          Rust’s dependency on LLVM is a portability problem, but note that it doesn’t apply in this case since Mesa depends on LLVM independent of Rust.