A line-by-line translation of the OCaml runtime from C to Rust

Learning
21

It doesn’t take a genius to see it though, there’s no detective work needed here.

I think most people don’t actually enjoy reading heaps of machine generated text – putting more effort in reading than OP put in writing, that’s backwards. It’s why forums banned spam for as long as forums existed: spam is low-effort machine-generated anti-social posting. The whole point of a forum is human-to-human communication and pro-social exchange.

It should be easier for one to communicate their original ideas effectively and be to the point than to work through those ideas initially. What does it communicate about the level of care for one’s audience that they delegate that to the verbosity generator? Or indeed what does it communicate about the level of care for the experiment itself that the comparatively easier task – the obvious opportunity to communicate agency and intent – is also automated?

22

It should be reminded that there is already a forum rule against posting LLM generated content so I don’t feel it’s a discussion that needs to be rehashed here.

In this case, given the follow up discussion, it seems enough people engaged with the content (myself included) regardless of how much of that is LLM generated or assisted and got something out of it. As such I find the discussion about the format of the post to be OT.

23

I’m not sure what value this brings? Is there any conceptual benefit beside using an automated translation tool that generates code no human has actually looked at?

I sure understand the value of our new LLM tools but there are tools. As software engineers, we are at the helm of them. directing them to apply our craft, not the other way.

I don’t think that I would have approached the rewrite as a “line by line, click click click” million line PR but rather start with a few questions:

  • Are there structural ways in rust that would guide an implementation of the ocaml runtime that is idiomatic and lends itself to some new gained benefit from the framework?
  • What are the essential conceptual things that need to be ported etc.

I would also question some assumptions such as preserving C ABI for bindings: if you are to rewrite the whole runtime in rust, why keep all C compatibility? All the headers etc? This is a vast undue burden.

This is the high-level type of work that is left to us when the machines can write millions of lines of code at once.

Lastly, I would also send a solid caution about inheriting tools you may or may not fully understand. Rust has its own set of tools and these tools will have issues and these issues will creep their way into the new rust runtime. And LLMs can be really bad at those.

Here’s an example I had recently: a GC closure code that was in a OCaml object initializer, causing a memory leak. At face value, there was no reason it should cause it because, semantically, the closure call should have worked. And the LLM was all but happy to confirm this. Until a human had to step in, check what was under the hood and notice the issue: Object finalizers declared in `initializer` can prevent the object from being collected · Issue #14861 · ocaml/ocaml · GitHub

So, yeah, LLM coding assistants are amazing tools but they are tools, with limitations and, pretty please, with a long road ahead of us to better understand how to structure our work using them so that it remains fun, with us at the helm and with carefully crafted engineering practices.