@flowthing the issue with nREPL is the completions namespace which spawns futures at the top level. if you change that to delays, it works.

I have a native version of REPL-y in a private repo. I can invite you if you want. I'm not ready to publish this code, since it's hacky

Yes, I did manage to compile a native image from the nREPL repo, but is that useful?

The future -> delay change I think we should make in any case.

Or maybe I've misunderstood something and you actually can use clojure.core/eval with a native image?

no, you can't

this is the entire point of sci basically

Right, that's what I thought. I'm just trying to understand why it's useful to compile nREPL into a native image, then. 🙂

I think a native nREPL client (like REPL-y) could be useful. A server probably not so much, unless it's hooked to an evaluator which can run inside a native image, like sci. This is why babashka has an nREPL server

Right, I can see that a client might be useful. Is an nREPL client what clojure-lsp needs?

I think they just added it as a dev dependency

I think the largest effort in making nREPL compile into a native image is to add checks to ensure that nobody breaks native image compatibility in the future.

which is basically why I rolled my own version of an nREPL server

also to keep the image size down