1. 46

  2. 15

    If I understand correctly, this would give pure Rust programs all of the redistributability benefits of MUSL with none of the fuss it takes to build. I can’t wait!

    1. 9

      Finally. libc-less Rust has been a goal for a long time. It was tried in steed, but steed got abandoned. I pray rustix goes over the finish line this time.

      1. 3

        I assume this means we can have a std that is unsafe free, since that would effectively be “pushed down” one level into Rustix instead?

        1. 15

          Yes this will reduce amount of unsafe in std.

          On the other hand, my impression is that reducing amount of unsafe in std is a non-goal or at least a low priority. Some people even think amount of unsafe in std should be increased (so that they can be properly audited and rest of ecosystem can use less unsafe).

          std is very performance sensitive and contains lots of unsafe usages for performance for codes that can be written unsafe free. BTree is a good example: it is known std-compatible BTree can be written without any unsafe, but it is a little bit slower. So std BTree is full of unsafe.

          1. 4

            Performance related unsafe aside, surely it is a goal to have as small amount of unsafe in std as possible?

            Without knowing the exact details, my gut feeling is that merging Rustix into std would maybe make it easier to review the use of unsafe. To currently review something like std::fs means I both need to know what libc does, that the mapping between std and libc is correct, and trust that libc does the right thing against the kernel (which hopefully isn’t too much of a problem).

            1. 12

              I think people are unwilling to delete unsafe if it causes 1% performance regression. That’s what I meant about low priority. Priority is about tradeoff.

              1. 1

                According to the article, rustix-based std is actually faster than current unsafe for some APIs.

                1. 2

                  For OS calls yes. But you won’t get that speed for data structures like B-Trees - and if you’re removing unsafe there why not at both places, will be the question. I think that rust isn’t ready to abandon libc for its stable experience over something that’s some weeks to months old and has to be maintained for every arch, while libc already works and has more eyes/testers on its code. Especially since go already tried to replace libc and failed in the end. Maybe in the futures and I could imagine that it’ll be easy to switch to this as the std, but for now there are probably bigger issues.

                  1. 9

                    Also, Linux is the only OS where raw syscalls are The Official Public API. Pretty much everywhere else you are strongly advised NOT to abandon libc.

                    1. 1

                      I believe OpenBSD even kills the process if it tries to talk syscalls directly without going through its libc

                      1. 1


              2. 3

                One of the deciding factors of “does this go in std or not” is whether it needs unsafe to run well or not. This is one reason PRNG’s and regex’s aren’t in std.