Author here, ask me anything :).

So, the project itself is not that hard. nREPL itself is very simple to implement, and even bencode is not that hard (having implemented it in Clojure and ClojureScript, in a purely functional way). It give a huge benefit to development, too.

The most complicated part, for Ruby at least, was (and still is) the actual editor part - parsing code and identifying where we are in the source, and what exactly do we need to evaluate, especially considering all special syntax that Ruby have.

For Ruby, things work quite well because the “binding” of the current “context” (like, inside a method which variables are visible, what are their values, etc) is first-class - meaning that I can “store” this binding in the nREPL side and then evaluate code as if I was still running that method (again, huge debugging capabilities here!). I don’t know how much IEx exposes, but considering that Elixir is a functional language, maybe we don’t even need these “hacks” because we don’t need to create a class, then set attributes, mutate stuff, before we can actually run some function

Hi Thanks for pinging me. Some really great discussion here.

(For posterity: I just updated the nexREPL README to include a link to the simple demo I shared earlier today on Twitter, and to also link to this thread.)

Having been immersed in this for the past few days, a few thoughts:

• The biggest advantage of working in the existing nREPL ecosystem (IMO) is access to the editor-specific clients. However, after surveying the landscape of existing client implementations, and excluding the ones that aren’t Clojure-exclusive, there’s not a lot of options.
• Eval’ing the expression at the given point/cursor position is pretty essential. The clients I tested don’t send all the necessary information over-the-wire to properly implement this on the server (there are optional parameters in the nREPL protocol for the “eval” operation for the file name, line number, column number, etc., which conceivably could let you put the logic on the server, but you still run into trouble with handling unsaved files etc).
• All that being said, the relative simplicity of the nREPL protocol means that it isn’t a huge stretch to build a custom client. But at that point, why not build something fully custom that directly integrates with IEx and doesn’t have any Clojure baggage?
• I am bullish on the idea of mediating this through LSP (as described at a high level in the nexREPL README), where LSP is the protocol that a custom “eval code” code action is sent through, the LSP server figures out the context and exactly what code you need to eval, and then sends the code directly to an existing IEx session. This of course is only one path of many options, but it solves the client issues and could reasonably be something built in to a language server (which would really help with adoption).

@mauricio.szabo that works on the nrepl for ruby and wrote the client for clojure nrepl on atom/pulsar did a video showing the powers of nrepl in ruby, i think that’s a good way to see how different and helpful a nrepl is from a usual language server.

@mjrusso problem of integrating in LSP is that we don’t actually solve client issues. I don’t believe any LSP client that exists now expects an “evaluate” operation, and while that can be added, clients don’t actually have any logic for this kind of interaction to happen - meaning there are no UI design to handle evaluations, for example.

The great advantage to reuse some nREPL client is that if the client/plug-in doesn’t send all the information, the only actual change they need to add is to send that info - every other task related to “evaluate something and get back a result”, like some “awaiting result” state, or a command to “break” the evaluation, are probably already present. Piggiebacking on something that exists, even if it needs some adjustment, can be a huge advantage compared to start something fully custom that will need to start up implementations from scratch.

I know this is kind of a weird chicken-and-egg situation, where we need client support to justify a server implementation, and we need server support tonikplement the ckient side too

Great news then - I’m cureently using TreeSitter to parse Ruby in the Lazuli project