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?
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.
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.
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.
Yeah, that paragraph was Claude. I did have Claude do some editing of the post and used some of its suggestions because it was much clearer than what I was struggling to say. AI writing isn’t better than good human writing, but once in a while I’m low on brain juice and it’s at least mid, which is an improvement.
The rest is mine, written over about four days. FWIW I also had two people review it was well.
It’s long because I took the work seriously and was trying to pre-empt the usual criticism.
Well, now that this is no longer a hypothetical, meaning there’s a Rust-based runtime ready to go to test your beliefs out with, what would you replace the C ABI with?
I wouldn’t fault you if you don’t know. Even the Rust community can’t seem to settle on this.
What this exercise has demonstrated for me is that Rust is not yet a full replacement for C at the extreme low-level. C is still the preferred language for driving hardware, and I contend the runtime is really about driving the hardware. C lets you do it concisely. Rust lets you do it but there’s a lot of paperwork involved.