upvote

points

by arthurbrown6 hours ago |
comments
upvoteby steveklabnik6 hours ago|
next
[-]
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.
reply
upvoteby arthurbrown5 hours ago|
parent|
[-]
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?

reply
upvoteby steveklabnik5 hours ago|
parent|
[-]
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.

reply
upvoteby grayrest6 hours ago|
prev|
[-]
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.
reply
upvoteby satvikpendem6 hours ago|
parent|
next
[-]
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.
reply
upvoteby djha-skin5 hours ago|
parent|
next
[-]
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.
reply
upvoteby antonvs5 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby pjmlp4 hours ago|
parent|
prev|
next
[-]
Depends on the beholder.

Unix system programming in OCaml

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

https://mirage.io/

reply
upvoteby steveklabnik5 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby pjmlp4 hours ago|
parent|
[-]
They are considered in many research labs since Xerox, unfortunately there are still too much anti-GC religion among mainstream devs.
reply
upvoteby sph2 hours ago|
parent|
[-]
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.

reply
upvoteby jandrewrogers23 minutes ago|
parent|
[-]
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.

reply