Thanks for pointing the typo out! I've fixed the comment.

In fairness, I think a lot of this comes down to familiarity. I'm fairly familiar with `.clone()` and Arcs at this point, so they don't really change much in terms of ergonomics. Usually their usage is fairly obvious, and quite often my editor literally does magically type the `.clone()` calls through LSP fix commands. It's the same as, say, OCaml's insistence that recursion is better for complex loops than, say, `while` — it's not necessarily wrong, but if you're unfamiliar with the idea, it's going to feel weird.

More important to me is the ergonomics of the broader ecosystem, and that's something that Rust has done well, that other languages just don't seem to be interested in at all. Things like integrating testing into the standard workflow; working hard on getting the stdlib in good condition; having an excellent ecosystem of well-documented, usable libraries; or designing error messages and lints with a focus on getting people to understand how the language works and not just what they've done wrong this time. I've really missed that stuff whenever I've tried MLs. You mention, for example, REPLs, but a unit test is basically a saved REPL session that you can repeat every time you make a change.

I'm not trying to convince anyone that Rust is the best language in the world or something. I really like it, but I find it helpful to think in terms of object ownership even in non-Rust languages, and I can understand why for other people that sort of approach is unhelpful. But I would love to see other languages embrace its ergonomics more, or new languages created with that as their focus.

A unit test has nothing to do with a REPL, a proper REPL provides something similar to jupiter notebooks in feel, alongside debugging and hot code reload experience.

Maybe we have different understandings of REPLs. For me, a REPL is a tool that I can use to try out some portion of my code, see how it responds to various inputs, see how it handles certain cases, and explore the internals of it via debugging tools.

But... that's what I do in a unit test anyway. A unit test is essentially a REPL session that I've frozen in time, can replay whenever I want, can debug, can trigger a fresh run whenever changes occur (which isn't quite hot reloading, but often a darn sight more useful), and can keep track of and share with my team. Which means I'm not just able to explore things on my own, but I can see the explorations that other people have made with their code.

For me the REPL is the experience similar to Lisp Machines, Smalltalk kind of experience, which is loosely captured in Jupiter Notebooks.

As for unit tests being more usefull, depends on how much one is willing to wait for them to run in Rust, given its compile times.