[arthurbrown]

Interesting that OCaml was flexible and expressive enough to be used as a prototype testbed but not chosen as the implementation language, especially given the maturity of both. I would be surprised if Zigs incremental builds could be meaningfully faster than dune's.

Cross compilation is great, but not mentioned in the "why Zig" section. Is memory control that crucial for a compiler?

Rust itself was originally written in OCaml, same with WASM. I'm curious about what milestone gets reached where the maintainers collectively decide to transition away.

[steveklabnik]

Rust moved away from OCaml when it decided to be re-written in Rust. The post alludes to this as being a usual time for a wholesale re-write, and I'd agree.

[arthurbrown]

I appreciate the insight, and on closer reading the post clearly states that realistically only Zig and Rust were ever considered anyway.

Since you're here, could you comment on the approach Rust took in their rewrite? Was it more of a straight translation like Go did when they self hosted -- similar to the recent Bun transliteration? Or were there architectural changes made along the way like this article describes with Roc?

[steveklabnik]

The Rust re-write happened before I got involved. If pcwalton is around and sees this comment, maybe he can provide a more first-class account.

> Was it more of a straight translation like Go did when they self hosted -- similar to the recent Bun transliteration? Or were there architectural changes made along the way like this article describes with Roc?

From what I remember, it was a whole-sale re-write from scratch, not a transliteration. While Rust took a lot of inspiration from OCaml, especially in those days, it was different enough that I'm not sure that a more direct transliteration would have been particularly possible, though again, see above, I wasn't there, so I don't know for sure.

[grayrest]

One of the primary goals for the Roc project is compiler speed. I presume OCaml is out of the running because it's not a systems language.

[pjmlp]

Depends on the beholder.

Unix system programming in OCaml

https://ocaml.github.io/ocamlunix/

https://mirage.io/

[satvikpendem]

OCaml compiler is incredibly fast. I wonder how it'd fare with Jane Street's extensions for the borrow checker etc in OxCaml, if it's good enough for their HFT I'm sure it's good enough for a new language.

[antonvs]

I wrote a toy Scheme implementation in OCaml by using the Camplp4 preprocessor. In benchmarks, it was faster than Gambit Scheme, which compiles through C.

[patrec]

Sounds interesting, have you put it online somewhere?

[antonvs]

No. I wrote it about 10 years before GitHub existed, and it’s just a toy. All it does is transform core Scheme syntax to Ocaml syntax, converting untyped values in the usual way to a ‘Value’ sum type.

I originally thought it would be slower than the faster Scheme compilers, like Gambit, because of how naive it was, but I was surprised to find that on benchmarks, including compute-heavy ones like fractals and I/O heavy ones like web serving, it outperformed Gambit. That’s really a reflection on Ocaml though, I didn’t do anything special.

If you asked an LLM to do that today, it could probably produce something better for you pretty quickly.

[djha-skin]

I suspect this "not a systems language" alludes only to OCaml's rather steeper learning curve and until-recently difficulty with multiple threads. I am sure it could roll just fine as a single-threaded compiler language written by a small team, which indeed, it was.

[steveklabnik]

OCaml has often historically been considered a language that's been appropriate to write systems tooling like compilers, runtimes, and unikernels in, even though GC'd languages were/are not often considered for such projects.

[pjmlp]

They are considered in many research labs since Xerox, unfortunately there are still too much anti-GC religion among mainstream devs.

[sph]

I don’t think there’s too many of us on the ‘GC did nothing wrong’ hill.

Reading the average HN opinion, it seems everybody is writing high-performance latency-sensitive systems that would implode if a response would take 1 ms longer than normal.

[jandrewrogers]

Sampling bias. Most of the people responding are probably those with a strong opinion because of what they work on. Everyone else is likely relatively indifferent to it.

It is a misconception that GCs only affect latency-sensitive systems. High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either.

That a GC is adverse to the performance both latency-oriented and throughput-oriented workloads doesn't leave many use cases in "high-performance" systems. Maybe systems that are severely I/O bound but is barely a thing these days.

[sph]

> Maybe systems that are severely I/O bound but is barely a thing these days.

Any kind of web service is barely a thing today? Which is what 99% of HN posters are working on, hence my comment.

> High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either

Games are high-performance throughput-optimized systems that have adopted GC languages for 15+ years now, and again a type of application which is much more latency sensitive than most people deal in their day to day.

Nobody is claiming GC is a panacea, but it’s good enough for a lot more use cases people give it credit for.

[wolvesechoes]

> Most of the people responding are probably those with a strong opinion because of what they work on

Quite the opposite. People here have strong opinion because they work on web apps and CLI toys.

[pjmlp]

It is also a misconception that all GC are born alike, and that don't exit languages with support for value types, stack allocation and GC free memory regions with C like pointer fun if so desired, while being mostly GC enabled.

[senderista]

Could you elaborate on "GCs are not used there [high-performance throughput-optimized systems]"? Are you referring to the cascading effects of tail latency on systems with high fanout?

[Capricorn2481]

> Most of the people responding are probably those with a strong opinion because of what they work on.

I can assure you that's not the case on here. The people working in truly low latency environments are not commenting on GC threads to begin with because it's a non-starter for them. For whatever reason, there is just a chunk of people that eat a lot of FUD around GCs who are working in the exact domains they thrive in.

[senderista]

Not to mention that in general GC simply requires more memory.

[pjmlp]

The Web scale meme exists for a reason, yeah.

[c-cube]

definitely not suitable for runtimes. After all, OCaml's own runtime is in C, not OCaml! For compilers I agree it's a fine choice.