4 ms·

I do not have concrete data for a comparison of like for like projects being compiled with comparable lines of code, and complexity of the type system usage, ru

I do not have concrete data for a comparison of like for like projects being compiled with comparable lines of code, and complexity of the type system usage, running on identical machines. As for your view of OCaml byte code compilation speed being on par with Go seems rather unlikely or I'm misunderstanding what you mean. Go is not dealing with anywhere as near a complex type system as OCaml and generates a lot more potato machine code (usually not using -mnative so you can know you can copy a binary to arbitrary machines).

EduardoRFS 5y ago
OCaml is much faster than Go in the bytecode mode, as you have interfaces files which drastically simplify the typing process. The compiling pipeline of bytecode is basically typing -> lambda -> bytegen Bytegen is really close to what Zinc does.
- reecko 5y ago
  > OCaml is much faster than Go in the bytecode mode But doesn't the compiled code run slower in bytecode mode? I think that counts.
  - pjmlp 5y ago
    Sure it does, bytecode is meant for development not for production builds. The healthy mix of interpreter/JIT/AOT backends is what many languages miss on their toolchains.
dwohnitmok 5y ago
Hindley-Milner typechecking in practice is quite fast (as evidenced by ocamlc and Elm's compiler) and easily on par or faster than Go's typechecker (my rule of thumb for Elm code is usually 1 second per 100k lines). In general HM-based type systems are both conceptually quite simple and can have quite fast implementations. What makes them seem "complex" is that languages with HM-based type systems also tend to make it hard to "go around" the type system and enforce much more rigid discipline around how your code can be written.
- throwaway894345 5y ago
  Isn’t pattern-matching alone combinatorial?
  - dwohnitmok 5y ago
    There's all sorts of terrifying exponential things that affect HM typechecking in theory (e.g. pattern matching exhaustivity checking as you mention is directly equivalent to SAT, although this is technically not a part of HM typechecking, it is a feature in practice for most HM-inspired languages). In practice it is actually very rare that they significantly affect compile times because it is very rare for the `n`-size to increase as the size of your codebase increases (these exponential blowups are generally limited to a single expression) for non-pathological code. Basically while you can have exponential blowups inside a single expression, I can't think of a time where you'll have exponential blowups across multiple expressions, which is what counts in a large codebase. One of the times where big-O analysis doesn't accurately predict real-world runtimes.
    - throwaway894345 5y ago
      I agree that the Ns are typically small, but I don’t know how the implementation could type check as quickly as Go’s considerably simpler type system.
      - dwohnitmok 5y ago
        Go's type system is actually of significant implementation complexity (in its details it's actually probably even more complex than Elm although less so than OCaml). In a typical implementation of HM the only nontrivial step (i.e. that isn't just a lookup and then checking if two constants are equal to each other) is union-find, i.e. a couple of set operations, but Go also has set operations it needs to do for type checking interfaces. So there isn't a clear performance win at a high level.
        throwaway894345 5y ago

EduardoRFS 5y ago

OCaml is much faster than Go in the bytecode mode, as you have interfaces files which drastically simplify the typing process. The compiling pipeline of bytecode is basically typing -> lambda -> bytegen Bytegen is really close to what Zinc does.

reecko 5y ago
> OCaml is much faster than Go in the bytecode mode But doesn't the compiled code run slower in bytecode mode? I think that counts.
- pjmlp 5y ago
  Sure it does, bytecode is meant for development not for production builds. The healthy mix of interpreter/JIT/AOT backends is what many languages miss on their toolchains.

dwohnitmok 5y ago

Hindley-Milner typechecking in practice is quite fast (as evidenced by ocamlc and Elm's compiler) and easily on par or faster than Go's typechecker (my rule of thumb for Elm code is usually 1 second per 100k lines). In general HM-based type systems are both conceptually quite simple and can have quite fast implementations. What makes them seem "complex" is that languages with HM-based type systems also tend to make it hard to "go around" the type system and enforce much more rigid discipline around how your code can be written.

throwaway894345 5y ago
Isn’t pattern-matching alone combinatorial?
- dwohnitmok 5y ago
  There's all sorts of terrifying exponential things that affect HM typechecking in theory (e.g. pattern matching exhaustivity checking as you mention is directly equivalent to SAT, although this is technically not a part of HM typechecking, it is a feature in practice for most HM-inspired languages). In practice it is actually very rare that they significantly affect compile times because it is very rare for the `n`-size to increase as the size of your codebase increases (these exponential blowups are generally limited to a single expression) for non-pathological code. Basically while you can have exponential blowups inside a single expression, I can't think of a time where you'll have exponential blowups across multiple expressions, which is what counts in a large codebase. One of the times where big-O analysis doesn't accurately predict real-world runtimes.
  - throwaway894345 5y ago
    I agree that the Ns are typically small, but I don’t know how the implementation could type check as quickly as Go’s considerably simpler type system.
    - dwohnitmok 5y ago
      Go's type system is actually of significant implementation complexity (in its details it's actually probably even more complex than Elm although less so than OCaml). In a typical implementation of HM the only nontrivial step (i.e. that isn't just a lookup and then checking if two constants are equal to each other) is union-find, i.e. a couple of set operations, but Go also has set operations it needs to do for type checking interfaces. So there isn't a clear performance win at a high level.
      - throwaway894345 5y ago