frontpage.
newsnewestaskshowjobs

Open Source @Github

fp.

A stack that fits your project, and keeps fitting as it changes

https://manifestack.com/
1•yuxt•16s ago•0 comments

Doom on the Vectrex Turns the Classic Shooter into Tron-Like Vector Art

https://www.engadget.com/2279239/doom-on-the-vectrex-turns-the-classic-shooter-into-tron-like-vec...
1•adunk•47s ago•0 comments

Show HN: Monolith / an engine-building game about software startups

https://monolithgame.app/
1•chancelloradams•1m ago•0 comments

Can AI Make a Game Engine? [video]

https://www.youtube.com/watch?v=R_uf5OfMGio
1•poly2it•2m ago•0 comments

Loose opinions on future of software, developers and corporations

https://www.akashtandon.in/technology/2026-10-05-loose-opinions-on-software/
1•akashtndn•2m ago•0 comments

Unity Spark: AI Game Maker with a Real Editor

https://unity.com/spark
1•ilreb•3m ago•0 comments

Show HN: Nimblegate – stop Claude Code and Codex pushing leaked API keys

https://github.com/nimblegate/nimblegate
2•nimblegate•3m ago•0 comments

Show HN: Cai:218x fewer tokens than Graphify, 2976x than raw files

https://daidocs.com/results-code.html
1•Amin_Rigi•5m ago•0 comments

Cosmic shuts the door on AI code as GNOME debates letting bug reports in

https://www.theregister.com/software/2026/10/07/cosmic-shuts-the-door-on-ai-code-as-gnome-debates...
2•sbulaev•6m ago•0 comments

Show HN: BuildABrowser – Rendering Engine with CSS Grid, Passes Acid2, in Java

https://github.com/BuildABrowser/BuildABrowser
1•everyos_•7m ago•1 comments

Pharmacological Activation of AMPK Extends Lifespan in Yeast, Worms and Flies

https://onlinelibrary.wiley.com/doi/10.1111/acel.70721
1•geox•7m ago•0 comments

JPEG-XL code golf art gallery

https://jpegxl.info/old/art/
2•gcr•7m ago•0 comments

Show HN: Open-source demo of a wallet punch card that updates itself

https://punchline.passmint.com/
1•alexpate•7m ago•0 comments

Claude for Google Workspace public beta

https://claude.com/resources/articles/claude-now-works-in-google-docs-sheets-and-slides
2•dieortin•7m ago•0 comments

Microbenchmarks in the Age of Clankers

https://mrale.ph/blog/2026-10-06-microbenchmarks-in-the-age-of-clankers.html
1•ingve•8m ago•0 comments

Write Like It's 1866: LLMs Relearn Telegraphese

https://fiveminutesforward.com/post/2026-10-04-telegraph-test/
2•Theory42•9m ago•0 comments

Great Divergence

https://en.wikipedia.org/wiki/Great_Divergence
1•fireflymetavrse•9m ago•0 comments

Show HN: CloudGrip – Open-source AI proxy to cap LLM API budgets

https://github.com/Aliyunazeer/cloudgrip-backend
2•aliyunazeer07•9m ago•0 comments

Show HN: LLM verification pipeline against hallucinations

https://rickinto.place/veriquote
1•rickintoplace•10m ago•0 comments

Nano Banana 2.1 vs. GPT Image 2.5 Flare

https://www.reddit.com/r/consentbar/comments/1wzup5k/nano_banana_21_vs_gpt_image_25_flare/
1•genesem•10m ago•1 comments

Show HN: Cockpit – a live instrument panel for Claude Code sessions

https://github.com/drkokorev/cockpit-for-claude
1•hy4hy•12m ago•0 comments

Adaptive Expertise Is Not a Skill

https://jtpeterson.substack.com/p/adaptive-expertise-is-not-a-skill
1•surprisetalk•13m ago•0 comments

Show HN: Navier-Stokes Equation Explained Colorfully

https://p.migdal.pl/equations-explained-colorfully/#navier-stokes
1•stared•13m ago•0 comments

Ask HN: Whats the future of marketplaces going to be like

1•ddaniel10•14m ago•2 comments

How to Read Code

https://www.seangoedecke.com/how-to-read-code/
1•mltvc•14m ago•0 comments

AI vs. Human Creativity

https://matiasmobilia.substack.com/p/ai-vs-human-creativity
1•matiasmobilia•15m ago•0 comments

"Good" AI

https://thoughts.wyounas.com/p/what-does-good-ai-mean
2•simplegeek•15m ago•0 comments

My complete rewrite of the TypeScript compiler

https://twitter.com/theo/status/2107789940482621795
1•0xedb•16m ago•0 comments

Google SearchGuard: Reversing the Challenge VM from Scratch

https://igorkozlowski.substack.com/p/google-searchguard-reversing-the
1•igor-lemon•17m ago•0 comments

Designing Calm Technology

https://calmtech.com/papers/designing-calm-technology
2•ankitg12•23m ago•0 comments
Open in hackernews

LSP client in Clojure in 200 lines of code

https://vlaaad.github.io/lsp-client-in-200-lines-of-code
164•vlaaad•1y ago

Comments

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.e...

[2] https://github.com/metosin/jsonista/blob/c8f2b62/project.clj...

[3] https://clojure-goes-fast.com/blog/clojures-slow-start/#cloj...

[4] https://clojure-lsp.io/installation/#embedded-jar-legacy-exe...

pron•1y ago
Between records and compact classes [1] Java's boilerplate isn't what it once was.

[1]: https://openjdk.org/jeps/512

newlisp•1y ago
It's idiomatic "low-level" Clojure, though. Not everything is a happy place where you're just manipulating maps and vectors like in most examples.
0x1ceb00da•1y ago
> lesser known language that has a hard enough time attracting users

For very good reasons.

dig1•1y ago
I don't see why this wouldn't be considered idiomatic clojure code; it makes proper use of all the facilities provided by the language and the main intention of this code is to follow the article. Additionally, the clojure core team often encourages not to shy away from using java code directly, as this approach strikes a good balance between performance and language expressivity.

> It’s so verbose and complex for what it is doing. ... and using core.async

I think this code is actually quite straightforward and easy for a clojure developer to understand. In fact, using core.async in this case would be overkill and could complicate things further.

daveliepmann•1y ago
This looks like the other completely normal, idiomatic Clojure programs I've seen which manipulate a StringBuilder. And as Clojurians go I'm far to the succinctness/concision-preferring end of the spectrum.

I'm curious to see your core.async-based version :)

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