Hacker News Reader

Comment by choeger | Hacker News Reader

Monomorphization.

For every generic function f, rustc will generate as many instances as there are type instances (shape instances? Does the Compiler distinguish between different kinds of references that all get compiled to pointers?).

This feature has a cost. Compare to OCaml's uniform object representation that enables comparatively blazing compilation performance but pays a prize in performance and weird FFI restrictions (integers with a tag bit).

Btw. It's misleading to say "it's the backend" when the frontend is responsible for creating so much work for it.

View on HN

> ...when the frontend is responsible for creating so much work for it.

That's the most important point I think. Clang compiling typical C code is very fast, but the same Clang compiling typical C++ code is very slow. Both use the same LLVM backend.

Kind of, despite its slow builds fame, it is possible to have relative fast builds in C++ with monomorphization.

By using binary libraries, external templates for common type sets, incremental compilation and linking, and nowadays (at least for VC++ already) modules.

What Rust still lacks is having sound alternatives to LLVM, or someone supporting similar workflows in Rust.

Using OCaml as an example, it is great to have multiple backends in the box, plus an interpreter, and pick and choose during development workflows.

Maybe cranelift will help with this. Faster compile times is one of its selling points.

That is something that I also look forward to.

Monomorphization can be manually addressed in Rust by writing generic function impls as delegating to a single function where the generic pameters are partily or fully omitted - a kind of "polymorphization". This is a pretty common pattern, e.g. in the Rust std library. In more recent versions of Rust this can be expanded via the use of const generics, e.g. to express the size and alignment of a generic type parameter, where the implementation only depends on these. So this kind of "polymorphization" can be applied more broadly.

D does the same thing with its template system and the compilation is still extremely fast.

May I take the opportunity to ask, what’s the reason for Metas somewhat heavy use of Ocaml? What’s the appeal? You already pointed out the insane compilation perf.

It's a pleasant and practical language to write, yet fairly safe.

Imagine the safety of Rust but looking more like Python (or Haskell...), the concurrency of Go (since V5), and without a borrow checker (but a GC instead).

I watch some intro to OCAML videos, got excited about the languages features, then tried reading some real OCAML (Tezos, which was touted as the star of idiomatic OCAML projects - can't find the site that listed it now), and I found it so incredibly dense, hard to read, and almost completely devoid of meaningful naming and comments. It felt similar to reverse-engineering minified code to me.

sounds like unfamiliarity. OCaml isn't a language a layman can read without prerequisites.

I found the idea pleasant, but not in actuality. So maybe it's an acquired taste? Haha

oh it definitely is. A lot of Haskell can look like you describe, but it's perfectly legible if you have enough reps under your belt. I find normal languages hard to read nowadays.

Reply on news.ycombinator.com