1. 41
  1.  

  2. 12
    • rust ABI target issues

    I’m not sure what that means exactly.

    Is that something we are aware of? If not, we’d be interested to hear problems.

    • need to keep rust working

    Is there anything we can do to ease the pain that currently isn’t on our roadmap?

    1. 19

      I believe it relates to this reported issue semarie@ in that thread is an OpenBSD developer and a contributor to the rust project.

      1. 11

        That is a fascinating bug thread. For lack of a better word.

        1. -4

          That thread pretty much confirms what I thought about the lack of quality and vision in the implementation of Rust, and the toxicity of the people working on it.

          Glad I can avoid it.

          1. 8

            Could you please point me towards the toxicity?

            Alex appreciates that it’s a problem and that we currently have no fully fitting solution for all that.

            1. 7

              There is at least one person on that thread who I don’t feel is exactly acting up to community standards, however, this is the only thread I can ever remember seeing them on, so I wouldn’t exactly chalk it up as a usual thing.

              1. [Comment removed by author]

                1. 7

                  My core complaints about lobste.rs aren’t about one-off posters.

                  And, regardless, I agree that it’s still a problem, which is why I brought it up.

            2. 4

              I have to say I didn’t see much toxicity. There was a little spiciness but the discussion stayed on-point, pretty much.

              1. 4

                I don’t know if go is much better, actually. Keeping up with interface changes is hard.

            3. 2

              That was an amazing read. Thank you.

              1. 2

                I skimmed over the first and last bits – what was amazing about it?

                To me this seems to be another indication of C’s (and C++‘s) network effects, and why Rust will have a hard time breaking them. But I didn’t follow the whole thread.

                I think http://ziglang.org/ is interesting because it has closer C integration than Rust – it actually links in libclang and you can parse and use C header files on the fly.

                I think a lot of people don’t understand that C code offers both APIs and ABIs. Historically in BSDs the kernel and user space are coupled by an API and not an ABI. Other languages generally need ABIs, because APIs are by definition specific to C’s type system, which most languages have no understanding of, including Rust.

                Linux is of course different in offering binary compatibilty. And ironically Windows is more polyglot than many Unices because of COM. I don’t do WIndows anymore (and I don’t know Rust), but I suspect you can interface with nearly all of Windows with a single COM library in Rust. It might not be pretty but it should work.

                1. 6

                  I think http://ziglang.org/ is interesting because it has closer C integration than Rust – it actually links in libclang and you can parse and use C header files on the fly.

                  I think a lot of people don’t understand that C code offers both APIs and ABIs. Historically in BSDs the kernel and user space are coupled by an API and not an ABI. Other languages generally need ABIs, because APIs are by definition specific to C’s type system, which most languages have no understanding of, including Rust.

                  Rust also has pretty elaborate machinery to parse header files and generate the relevant C code (bindgen) that’s heavily used in Servo and Firefox. We fully understand how C works, but Rust its own language and consciously doesn’t put C integration over everything. That also doesn’t mean Rust is fully opposed to adopt things from C, like the recently introduced untagged (and unsafe) unions.

                  That works well, but libc is the one library where both worlds collide very heavily, because libc is not just any C library, but also fundamental to OSes.

                  1. 1

                    Does Rust know the size of a C integer, or is that the bindgen or libc crates?

                    It seems like libc defines a type c_int.

                    https://github.com/rust-lang/libc

                    If Rust doesn’t have c_int, then I would say it doesn’t understand C’s type system. In other words, Rust can understand ABIs but not APIs “natively”. My point is that the C integration in ziglang is more direct. But like you say that’s a fine design choice because Rust doesn’t prioritize C integration over everything.

                    1. 2

                      Ah, in that case I misread your statement and focused too much on libclang.

                      You are right, Rust has no concept of c_int in core. Integers are not even the biggest problem there (as we obviously have types with the same semantics, which can be passed in and out of C. Things like c_void and pointers are the bigger “problem” there (though Rust consciously has raw pointers in the language itself).

                      We have the machinery to map that automatically (and at zero cost), but yes, it’s machinery outside of rustc.

                    2. 0

                      I don’t think the issue in question has much to do with C integration, bindgen, etc. I think mattmacy has the correct summary: “Rust has its own notions of target and outside of Linux and Windows that notion is wrong”. The fix is to include ABI in target together with OS and architecture. Linux and Windows just decided to never change ABI, but there are other choices.

                      1. 2

                        I was specifically referring to the parents statements about ziglang. Lots of the issues mentioned in the thread are also libc API changes, not only ABI.

                        I agree on the issue of the target specification. Sooner or later, it needs to be approached.

                        1. 1

                          Even under Linux that idea seems to be wrong - glibc regularly changes function calls & maintains internal versioning to ensure that old binaries still call the old versions of the functions.

                          I don’t think Rust’s libc crate is giving them the guarantees they think it does.

              2. 3

                I think this might be the talk:

                https://youtu.be/8wuW8lfsVGc?t=1h27m9s

                1. 3

                  landry@ <3

                  1. 1
                    • exotic archs, endianess: the boat has sailed, deal with it

                    How are we meant to parse this?

                    1. 4

                      They’re not supporting exotic architectures anymore.

                      1. 3

                        2017 has exactly four vanilla architectures: x86, amd64, arm, and arm64.

                        1. 3

                          I should mention that Rust does support more than just that :p https://forge.rust-lang.org/platform-support.html

                          1. 1

                            Oops, I meant to be speaking about the zeitgeist rather than just Rust.

                            The other architectures I see in Rust’s Tier 2 support are MIPS, PPC and asm.js. Familiar names but not exactly what I would call vanilla these days.

                        2. 3

                          Time to buy a real computer, not one of those sparc toys.

                          1. 3

                            I like to couple toy computers (ARM, sparc64) with toy operating systems (BSDs). It’s fun because toys are for fun :)