3 ms·

OCaml is one of those languages that is a real joy to use and makes me wonder why its not used more often. I feel like if I jump into a Lisp or ML language, I a

OCaml is one of those languages that is a real joy to use and makes me wonder why its not used more often. I feel like if I jump into a Lisp or ML language, I am so productive and can write some really complicated software with relative ease. But they are relatively rare in industry, and I have never really crossed the t on why, despite various reasonings about it. This is a great achievement for OCaml, but does anyone have an explanation on why it was so difficult to implement for them?

c-cube 4y ago
It's just very hard to write a solid concurrent GC. There are not many in existence today. Here the challenge was doubled by the obligation to preserve the single core performance of existing programs, with the very fast allocation path on the minor heap. It's always harder to add these features to an existing language that already has significant programs written in it.
- amelius 4y ago
  Would it be possible to take this work and turn it into a more general GC library that language implementers can use beside LLVM?
  - c-cube 4y ago
    If your language matches ocaml's runtime semantics, then sure. It means uniform representation, 63bits integers, etc. but can be quite useful if your language is ML-ish.
    - sadiq 4y ago
      Also worth pointing out there's design constraints on the OCaml 5 GC imposed by some of OCaml's language features (looking at you ephemerons) and C API invariants. There may be different constraints for other runtimes.
epolanski 4y ago
I think John Carmack made a good point on this topic which I did not think of before. He stated that albeit he spent years working with Lisps (CL and Racket mostly) or Haskell he stated that jumping on projects in those languages instantly requires you pay the price of having to learn the abstractions and DSLs that the users wrote for the project before being able to understand anything. He compared it with C or Go, where he realized that it was easier to him to read kernel code without any context, because there is no abstraction price to pay. What you see is what there is to understand. He basically says that those languages (MLs, Lisps) are great for personal projects or very small teams but they don't scale well, this also reflects on open source where many will build their libraries and programs, but very few get into collaborating in those communities.
- nightfly 4y ago
  I'm certainly no expert, but isn't (linux) kernel C full of pre-processor macros that muddy reading the code?
- jojohohanon 4y ago
  I think golang is designed intentionally to make it easy to read unfamiliar code. To paraphrase: The idea being that a well designed library api gets you 90% of the benefits of a richer language’s features, but without exactly that penalty that Carmac calls out.
  - gleenn 4y ago
    Doesn't that kinda presume that everyone should just "write a well-designed library"? If it's that much easier to just use a richer language shouldn't we just do that?
- anentropic 4y ago
  I don't know what JC said exactly but I would guess that some of the issues of scaling Lisps (dynamic typing, DSL hell) don't really apply to OCaml
- naasking 4y ago

c-cube 4y ago

It's just very hard to write a solid concurrent GC. There are not many in existence today. Here the challenge was doubled by the obligation to preserve the single core performance of existing programs, with the very fast allocation path on the minor heap. It's always harder to add these features to an existing language that already has significant programs written in it.

amelius 4y ago
Would it be possible to take this work and turn it into a more general GC library that language implementers can use beside LLVM?
- c-cube 4y ago
  If your language matches ocaml's runtime semantics, then sure. It means uniform representation, 63bits integers, etc. but can be quite useful if your language is ML-ish.
  - sadiq 4y ago
    Also worth pointing out there's design constraints on the OCaml 5 GC imposed by some of OCaml's language features (looking at you ephemerons) and C API invariants. There may be different constraints for other runtimes.

epolanski 4y ago

I think John Carmack made a good point on this topic which I did not think of before. He stated that albeit he spent years working with Lisps (CL and Racket mostly) or Haskell he stated that jumping on projects in those languages instantly requires you pay the price of having to learn the abstractions and DSLs that the users wrote for the project before being able to understand anything. He compared it with C or Go, where he realized that it was easier to him to read kernel code without any context, because there is no abstraction price to pay. What you see is what there is to understand. He basically says that those languages (MLs, Lisps) are great for personal projects or very small teams but they don't scale well, this also reflects on open source where many will build their libraries and programs, but very few get into collaborating in those communities.

nightfly 4y ago
I'm certainly no expert, but isn't (linux) kernel C full of pre-processor macros that muddy reading the code?
jojohohanon 4y ago
I think golang is designed intentionally to make it easy to read unfamiliar code. To paraphrase: The idea being that a well designed library api gets you 90% of the benefits of a richer language’s features, but without exactly that penalty that Carmac calls out.
- gleenn 4y ago
  Doesn't that kinda presume that everyone should just "write a well-designed library"? If it's that much easier to just use a richer language shouldn't we just do that?
anentropic 4y ago
I don't know what JC said exactly but I would guess that some of the issues of scaling Lisps (dynamic typing, DSL hell) don't really apply to OCaml
naasking 4y ago