4 ms·

LSP client in Clojure in 200 lines of code

164 points by vlaaad 1y ago

90s_dev 1y ago
[flagged]
- 0_gravitas 1y ago
  My thoughts are "cool!, neat!" But I don't feel like the world particularly needs to hear my singleton exclamations, no reason to add unnecessary noise, this isn't reddit.
  - bjconlan 1y ago
    Yeah I feel yah; But to bolster the post: I now want to hear more as to why Defold now has a clojure repl! I noticed some musings around some native bindings in gh issues which is "interesting" but I'm not quite getting it. I guess off to the forums I go!
- pharsa 1y ago
  What same things?
  - 90s_dev 1y ago
    I don't know, I was hoping someone would tell me!
- lenkite 1y ago
  Clojure is dying. But its heir - Jank might take the crown.
  - pseudony 1y ago
    The thing about not having loads of syntax is that at some point, there is not much to do aside from polishing. I don't know why it would feel comforting to people that languages like python/c++/rust keep piling on syntax and features like the people in Rammstein's keine lust, who keep stuffing themselves in spite of their grotesque size. Haven't looked at jank, but given it looks like lisp, it would be the same thing. No news is actually good news in some cases
    - lyu07282 1y ago
      > there is not much to do aside from polishing If only other languages could just have been designed perfectly first try like <insert your favourite irrelevant lisp dialect>...
      - pseudony 1y ago
        Right, and popularity is the ultimate determinant of value. Maybe you are simply ignorant of how many systems might actually run a lisp or similar "irrelevant" programming language in the systems you interact with. From airline reservation systems to banking and high-frequency trading. JavaScript is not, in fact, eating the world, and nor will Python, Rust or whatever else.
  - uludag 1y ago
    > Clojure is dying is it really though? While I feel the hype is definitely not what it used to be, after getting back into Clojure after a few year hiatus I'm not noticing anything that would suggest it's dying. For example, there's still active Clojure podcasts still in production. Jank may very start exceeding Clojure in terms of hype though.
    - askonomm 1y ago
      Clojure is very fragile though. Most Clojure companies are driven by vc funding and so whenever there's even a slight economic downturn, the few jobs that there are all disappear, sometimes mid-interview process, I've found out the hard way. But if you have tons of savings to justify a potentially half-year-or-more job search then no, not dying. But I wouldn't exactly say alive either, and the job market also hasn't grown in any noticeable way in the last half a decade.
    - contrarian1234 1y ago
      [dead]
    - KingMob 1y ago
      Clojure's stability means code will last awhile without breaking, but the ecosystem is shrinking. Less hype also means fewer jobs, fewer new libs, etc. It doesn't help that the last few releases have been pretty uninspiring.
  - shivekkhurana 1y ago
    Jank is Clojure. Languages are often thought of in-coupling with the runtime. But Clojure is a way of writing code. The official implementation runs on JVM. There are community ports for Node, C#, Go. Jank is the port on CPP. Jank winning is Clojure winning.
  - 90s_dev 1y ago
    Never heard of Jank until now, very interesting. One of my lifelong dreams was to make my own language that compiles to assembly and is actually useful, even if only for small projects. Everyone seems to be doing that successfully lately with LLVM. I tried to learn x86 asm and failed so many times, there's little hope I'll be able to learn x64 asm well enough to generate code for it. Maybe I should just hop on the LLVM train.
  - LouDNL 1y ago
    Clojure isn't dying, it's a niche language with a very much alive community. I admit that jobs are limited, but the ones that do exist are very interesting. My day job consists solely of programming in Clojure, so no, dead is not the correct word here.
  - jmaker 1y ago
    How much of the existing ecosystem can be used via Jank? How much compatibility is there?
whalesalad 1y ago
This is the most Java-y Clojure I’ve probably ever read. Just use Java? It’s so verbose and complex for what it is doing. Breaking this down into smaller functions and using core.async would make it even more succinct. Just want to emphasize this because clojure is indeed a small, lesser known language that has a hard enough time attracting users. This is not what anyone would consider an idiomatic example of using clojure.
- roenxi 1y ago
  Would it be 200 lines of Java? It'd be 200 lines of just for the boilerplate. It isn't really a selling point of Clojure because it is subjective, but low-syntax high-terseness look of the code is in itself a reward for using the language. And there isn't anything especially wrong with sticking to Java primitives if someone is comfortable with them. They work fine for Java programmers. The dude doesn't need to learn a new async library to write an LSP client if he doesn't feel like it. Code works, its easy to read, easy to understand and modify.
  - koito17 1y ago
    Line count is not very useful to compare without the context of standard library size, third-party dependencies, etc. The code in TFA depends[1] on a JSON library[2] that is about a thousand lines of code (excluding tests) wrapping a Java library for JSON decoding. Then there's other things to consider, like the fact that this LSP client, while succinct, pays not only the cost of loading Jackson, but also the cost of loading clojure.core, which is quite non-trivial[3]. Startup time for LSP servers and clients definitely matters to some, considering that e.g. even clojure-lsp recommends running native executables over JAR files[4]. Can't find documentation proving it's for quick startup, but it's a plausible rationale for their recommendation of a binary over a JAR. Note: I have used Clojure professionally and in hobby projects. I think it's nice that one can interactively develop a minimal LSP client and the resulting amount of work is roughly 200 lines of code. I say "minimal" because it's unclear how this client deals with offsets reported by LSP servers, which are all given as offsets in a UTF-16 encoded string. In any case, I still think advertising "LSP client in 200 lines of code" hides valuable information regarding functionality, implementation, "actual" code size, and trade-offs made in the choice of technology stack. [1] https://github.com/vlaaad/lsp-clj-client/blob/a567e66/deps.edn https://github.com/vlaaad/lsp-clj-client/blob/a567e66/deps.e... [2] https://github.com/metosin/jsonista/blob/c8f2b62/project.clj#L20-L22 https://github.com/metosin/jsonista/blob/c8f2b62/project.clj... [3] https://clojure-goes-fast.com/blog/clojures-slow-start/#clojure https://clojure-goes-fast.com/blog/clojures-slow-start/#cloj... [4] https://clojure-lsp.io/installation/#embedded-jar-legacy-executable https://clojure-lsp.io/installation/#embedded-jar-legacy-exe...
curtisszmania 1y ago
[dead]
- deleted 1y ago
  [deleted]
deleted 1y ago
[deleted]
askonomm 1y ago
Holy crap is this unreadable or what (notably the lsp-base fn). There's a reason why in most Clojure companies I've worked at we try to make as small functions as possible, because otherwise it very very quickly becomes an unreadable mess, and you write code after all for humans to read, because if you didn't, you might as well just write binary. But, I'm not surprised many people don't want to get into Clojure or Lisps in general, because it takes a boatload of conventions and active discipline to make it a good experience.
- slifin 1y ago
  To me something unreadable is code that I cannot statically make any assertions about the runtime behaviour of the code This function you're complaining about looks like 2 virtual threads doing program input reading and output writing for the LSP client given some ArrayBlockingQueues in about 25-30 lines If I wanted the complete story I could use Clojure's inbuilt test runner to slip some ArrayBlockingQueues in there and run it under record with Flowstorm Then leisurely seek through the entire state of the program, to get the play-by-play of how this works There are so many good design choices in this language and a good 30% of colleagues I run into are not even doing the basics of like running a REPL, I think some people just need to clock in with a decade of C# or PHP or TS or JS or Python or whatever to get a taste of a language with next to no inbuilt immutability, statements instead of expressions, no reload-ability in the language semantics and just crapshot debuggers that run in lockstep with the program execution

164 points by vlaaad 1y ago

90s_dev 1y ago

[flagged]

0_gravitas 1y ago
My thoughts are "cool!, neat!" But I don't feel like the world particularly needs to hear my singleton exclamations, no reason to add unnecessary noise, this isn't reddit.
- bjconlan 1y ago
  Yeah I feel yah; But to bolster the post: I now want to hear more as to why Defold now has a clojure repl! I noticed some musings around some native bindings in gh issues which is "interesting" but I'm not quite getting it. I guess off to the forums I go!
pharsa 1y ago
What same things?
- 90s_dev 1y ago
  I don't know, I was hoping someone would tell me!
lenkite 1y ago
Clojure is dying. But its heir - Jank might take the crown.
- pseudony 1y ago
  The thing about not having loads of syntax is that at some point, there is not much to do aside from polishing. I don't know why it would feel comforting to people that languages like python/c++/rust keep piling on syntax and features like the people in Rammstein's keine lust, who keep stuffing themselves in spite of their grotesque size. Haven't looked at jank, but given it looks like lisp, it would be the same thing. No news is actually good news in some cases
  - lyu07282 1y ago
    > there is not much to do aside from polishing If only other languages could just have been designed perfectly first try like <insert your favourite irrelevant lisp dialect>...
    - pseudony 1y ago
      Right, and popularity is the ultimate determinant of value. Maybe you are simply ignorant of how many systems might actually run a lisp or similar "irrelevant" programming language in the systems you interact with. From airline reservation systems to banking and high-frequency trading. JavaScript is not, in fact, eating the world, and nor will Python, Rust or whatever else.
- uludag 1y ago
  > Clojure is dying is it really though? While I feel the hype is definitely not what it used to be, after getting back into Clojure after a few year hiatus I'm not noticing anything that would suggest it's dying. For example, there's still active Clojure podcasts still in production. Jank may very start exceeding Clojure in terms of hype though.
  - askonomm 1y ago
    Clojure is very fragile though. Most Clojure companies are driven by vc funding and so whenever there's even a slight economic downturn, the few jobs that there are all disappear, sometimes mid-interview process, I've found out the hard way. But if you have tons of savings to justify a potentially half-year-or-more job search then no, not dying. But I wouldn't exactly say alive either, and the job market also hasn't grown in any noticeable way in the last half a decade.
  - contrarian1234 1y ago
    [dead]
  - KingMob 1y ago
    Clojure's stability means code will last awhile without breaking, but the ecosystem is shrinking. Less hype also means fewer jobs, fewer new libs, etc. It doesn't help that the last few releases have been pretty uninspiring.
- shivekkhurana 1y ago
  Jank is Clojure. Languages are often thought of in-coupling with the runtime. But Clojure is a way of writing code. The official implementation runs on JVM. There are community ports for Node, C#, Go. Jank is the port on CPP. Jank winning is Clojure winning.
- 90s_dev 1y ago
  Never heard of Jank until now, very interesting. One of my lifelong dreams was to make my own language that compiles to assembly and is actually useful, even if only for small projects. Everyone seems to be doing that successfully lately with LLVM. I tried to learn x86 asm and failed so many times, there's little hope I'll be able to learn x64 asm well enough to generate code for it. Maybe I should just hop on the LLVM train.
- LouDNL 1y ago
  Clojure isn't dying, it's a niche language with a very much alive community. I admit that jobs are limited, but the ones that do exist are very interesting. My day job consists solely of programming in Clojure, so no, dead is not the correct word here.
- jmaker 1y ago
  How much of the existing ecosystem can be used via Jank? How much compatibility is there?

whalesalad 1y ago

This is the most Java-y Clojure I’ve probably ever read. Just use Java? It’s so verbose and complex for what it is doing. Breaking this down into smaller functions and using core.async would make it even more succinct. Just want to emphasize this because clojure is indeed a small, lesser known language that has a hard enough time attracting users. This is not what anyone would consider an idiomatic example of using clojure.

roenxi 1y ago
Would it be 200 lines of Java? It'd be 200 lines of just for the boilerplate. It isn't really a selling point of Clojure because it is subjective, but low-syntax high-terseness look of the code is in itself a reward for using the language. And there isn't anything especially wrong with sticking to Java primitives if someone is comfortable with them. They work fine for Java programmers. The dude doesn't need to learn a new async library to write an LSP client if he doesn't feel like it. Code works, its easy to read, easy to understand and modify.
- koito17 1y ago
  Line count is not very useful to compare without the context of standard library size, third-party dependencies, etc. The code in TFA depends[1] on a JSON library[2] that is about a thousand lines of code (excluding tests) wrapping a Java library for JSON decoding. Then there's other things to consider, like the fact that this LSP client, while succinct, pays not only the cost of loading Jackson, but also the cost of loading clojure.core, which is quite non-trivial[3]. Startup time for LSP servers and clients definitely matters to some, considering that e.g. even clojure-lsp recommends running native executables over JAR files[4]. Can't find documentation proving it's for quick startup, but it's a plausible rationale for their recommendation of a binary over a JAR. Note: I have used Clojure professionally and in hobby projects. I think it's nice that one can interactively develop a minimal LSP client and the resulting amount of work is roughly 200 lines of code. I say "minimal" because it's unclear how this client deals with offsets reported by LSP servers, which are all given as offsets in a UTF-16 encoded string. In any case, I still think advertising "LSP client in 200 lines of code" hides valuable information regarding functionality, implementation, "actual" code size, and trade-offs made in the choice of technology stack. [1] https://github.com/vlaaad/lsp-clj-client/blob/a567e66/deps.edn https://github.com/vlaaad/lsp-clj-client/blob/a567e66/deps.e... [2] https://github.com/metosin/jsonista/blob/c8f2b62/project.clj#L20-L22 https://github.com/metosin/jsonista/blob/c8f2b62/project.clj... [3] https://clojure-goes-fast.com/blog/clojures-slow-start/#clojure https://clojure-goes-fast.com/blog/clojures-slow-start/#cloj... [4] https://clojure-lsp.io/installation/#embedded-jar-legacy-executable https://clojure-lsp.io/installation/#embedded-jar-legacy-exe...

curtisszmania 1y ago

[dead]

deleted 1y ago
[deleted]

deleted 1y ago

[deleted]

askonomm 1y ago

Holy crap is this unreadable or what (notably the lsp-base fn). There's a reason why in most Clojure companies I've worked at we try to make as small functions as possible, because otherwise it very very quickly becomes an unreadable mess, and you write code after all for humans to read, because if you didn't, you might as well just write binary. But, I'm not surprised many people don't want to get into Clojure or Lisps in general, because it takes a boatload of conventions and active discipline to make it a good experience.

slifin 1y ago
To me something unreadable is code that I cannot statically make any assertions about the runtime behaviour of the code This function you're complaining about looks like 2 virtual threads doing program input reading and output writing for the LSP client given some ArrayBlockingQueues in about 25-30 lines If I wanted the complete story I could use Clojure's inbuilt test runner to slip some ArrayBlockingQueues in there and run it under record with Flowstorm Then leisurely seek through the entire state of the program, to get the play-by-play of how this works There are so many good design choices in this language and a good 30% of colleagues I run into are not even doing the basics of like running a REPL, I think some people just need to clock in with a decade of C# or PHP or TS or JS or Python or whatever to get a taste of a language with next to no inbuilt immutability, statements instead of expressions, no reload-ability in the language semantics and just crapshot debuggers that run in lockstep with the program execution