1. 14
  1.  

  2. 14

    Rusts compile times are not fast which makes it a poor target as far as I’m concerned

    1. 6

      It’s true that, in the short term, slow compile times are a logistical issue. The post is moreso a vision statement than a concrete realization of an idea.

      1. 2

        True! I hope it improves in the future. I think generally since it does monomorphization and some type inference, it won’t get to the speed of LLVM compile times… but if you’re a language that can compile its generics to Rust’s, then it’s not really a problem.

        Also you make a great point about interoperability! that compiling to a higher-level language lets two languages communicate better

      2. 1

        That’s true, but neither are C or C++ compile times, and that’s what most languages are built in. Like zig for example.

        EDIT: My point is that I can see rust improving their compile times considerably. I don’t envision C/C++ getting legitimately faster at this point.

        1. 1

          Aren’t C compile times very fast? I guess it depends on the optimization level

      3. 12

        It’s an intriguing proposal, and I think we will see some experiments in this direction in the near future.

        To be skeptical on one point, though, I’m not ready to say this particular claim is wrong, but it does make me raise an eyebrow:

        Rust only imposes one opinion on your program: that it should be safe. I would argue that the only real difference at the runtime level between programs you can write in LLVM and programs you can write in Rust is that Rust requires all of your programs to be safe, i.e. not have memory errors/data races.

        Is that really the only opinion it imposes on your program? I mean if it were, that would be no real restriction, because you can always drop into unsafe. But consider C as a target language. It doesn’t even attempt to require your program to be memory-safe, and yet a number of compiler implementers have found C as a target language limiting. Is Rust less limiting than C as a target language? It might be, but this post doesn’t lay out an argument in that direction.

        For example, the Haskell compiler GHC deprecated its C backend and now targets LLVM primarily. As I understand it, one of the primary issues was over garbage collection. The post does mention that Rust “needs a battle-hardened GC”, but it’s not necessarily that the target language needs one GC. That would be useful as a way of getting going and might suffice in many cases, but to avoid limiting the kinds of languages and performance profiles you can support, a compiler IR needs to provide low-level enough access for the source language to plug in its own GC strategies, and ideally own memory representations too. It’s possible the Rust internals that are alluded to provide this better than C does; admittedly I know nothing about what kinds of useful-for-compilers internals the Rust toolchain exposes.

        1. 4

          Well, to be clear, the opinion that Rust imposes is that whatever you generate must be a valid Rust program. It uses Rust syntax, static, and semantics. However, by contrast with C, Rust’s type system is expressive enough to permit a wide range of translations. No respectable functional language would use C’s type system as their own, but potentially Rust’s would suffice. In contrast to LLVM, I e that Rust provides a number of benefits (package manager, type system, for loops, etc.), but that unlike compiling to a higher level target (e.g. Java, like Scala/Clojure, or JavaScript, like all web languages), compiling to Rust doesn’t preclude you from most low-level optimizations.

          It’s a fair criticism that Rust might not be able to support a garbage collector efficient enough for practical use, since that hypothesis has yet to be empirically validated. I’m optimistic, although the experience of the GHC devs does point the other direction.

          1. 5

            expressive enough to permit a wide range of translations

            That’s a bit less exciting than “rust imposes no limitations other than safety” (which isn’t even true – a transpiler that did its own safety checks might have an easier time generating rust that rustc couldn’t verify and then wrapping it with unsafe{}).

          2. 2

            GC is one concern, I don’t want to use libgc everywhere and call it good enough for example. Good enough to start sure. Another example is exception implementation. If C is the target then you’ll implement them with setjmp/longjmp with runtime record keeping overhead. If llvm is the target then presumably you can plug into the same zero cost exceptions that are used in c++. I don’t know what the exception handling story is with rust, haven’t looked to be honest.

          3. 6
            1. 3

              Thanks for digging that up. The top two posts on that thread are informative critiques I think.

            2. 5

              However, if two languages compile to the same type system, then they can seamlessly interoperate.

              Sorry, I don’t see how this is true. The limiting factor in interoperability is typically the communication channel and the representation of types, not the type systems themselves.

              It’s entirely possible that I could write two languages that have the same type system and not be able to (seamlessly) interact because I elected to represent the types very differently. Say, for example, the layout of a tagged union is different. I’ll have to convert that to the other representation in order to use it. The implementation language doesn’t matter.

              Furthermore, isn’t LLVM a language with a type system? Then the wording of the claim, as I read it, says that anything the compiles to LLVM can seamlessly interoperate. That’s certainly not true.

              Is this the intended wording? Because I don’t see how it stands up.

              1. 3

                Sorry, I don’t see how this is true. The limiting factor in interoperability is typically the communication channel and the representation of types, not the type systems themselves.

                This is exactly why calling foreign code can be slow or bring abstraction gap attacks. It’s also why OpenVMS standardized that stuff for cross-language development. Then, Microsoft CLR did later with a VM. Languages also stayed Java or C compatible for their ecosystems.

              2. 4

                I’m skeptical of the idea of such a high-level language being a good general-purpose compiler target. To draw a rough physical analogy (imperfect, as with all analogies, but hopefully illustrates my perspective): rust : legos :: instructions : atoms. You can build just about anything with enough atoms of the right kinds. You can build lots of things with legos, but it’s tough to make a good basketball with them.

                1. 3

                  My understanding is that LLVM supports as a target far more platforms than rust. Is that not the case?

                  1. 1

                    Of course it does but since you can compile Rust to LLVM, it doesn’t matter.

                    1. 0

                      Rust compiles to LLVM, so by extension it inherits some of that support. See here for a full list of platforms: https://forge.rust-lang.org/platform-support.html

                      1. 1

                        … sure, but if you’re compiling to rust as an intermediate to LLVM as an intermediate to platform-binary, it’s not clear what the rust step is gaining you. Unless your new language is highly-semantically-compatible with rust in the first place, but in that case it might be better implemented as a series of rust macros.

                        Edit: After reading the rest of the comments more thoroughly, I realize that I’m just inching towards the same arguments that are made better by others.