1. 1

    Any progress on this since 2012?

    1. 3

      Hi @wcrichton, thanks for the post.

      That part about automatically inferring types of a heterogenous map in OCaml is incorrect. You can create constructors out of nowhere (polymorphic variants), but OCaml will never do this for you and declaring that is also completely typesafe with no runtime errors happening. Also, your link to Stackoverflow is broken (because I wanted to check out what made you conclude such a thing).

      1. 2

        Ah, that was a misleading edit, I’ve clarified the article text. Originally I had OCaml in the explicit sum type category with a note about polymorphic variants, but I realized that was similar to Ceylon so I moved it to the implicit sum type category without appropriately updating the pros/cons. Ultimately, I realized that a more nuanced description of the design space around sum types is warranted, which you can now find in the article (i.e. sum types can be broken down as named vs. anonymous, declared vs. inferred, and matched vs. casted).

        1. 1

          Very good, I think this is a nice improvement. I realize my original comment to a good article was unnecessarily grumpy, so I’ll just wish you a nice weekend instead now.

      1. 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.

          1. 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

              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.