Bozhidar Batsov

Btw, I guess for babashka the runtime can easily be clojure as well, given how highly compatible they are. That's not a big deal in the end of the day...

> Having a separate version / java from version / babashka doesn't make sense, since you cannot have different Java/GraalVM versions with the same babashka version, i.e it's a derived...

Btw, doesn't your nREPL server have different versioning from `babashka` - I guess it still might be nice to include its version so that clients could display it.

We have a deal! 🤝

> Is this information going to be used by CIDER? Yeah, it will be. The plan is to have CIDER support better non-Clojure nREPL servers See https://github.com/clojure-emacs/cider/issues/2848 for more details....

Yeah, maybe we should have a separate key about the language, as with ClojureScript you can have both a Java runtime and a self-hosted JavaScript runtime and you need to...

> I've been following this conversation with some trepidation, as it reminds me of how the web has struggled to improve because of everyone doing user agent checks. Instead of...

1) The target language gets set manually in clients (e.g. on connect) 2) Clients restrain themselves from implementing any functionality in terms of `eval` and just rely on nREPL ops...

E.g. you want to provide code completion by just evaluating code in some code completion library (as opposed to a dedicated op) - that's how Leiningen currently provides code completion...

Btw, there's one more nuance we have to keep in mind - how do you probe for capabilities that are not actually ops (e.g. the `print` middleware doesn't expose any...