A recent talk I gave (Oct 2025) about sustainable open source, focusing on the emotional dynamics of long-term OSS work.
It explores some of the common reasons that OSS maintainers burn out. And explores some of the easy ways that OSS users can help to reduce maintainer attrition.
To clarify: the core server is indeed written in Java, but it's written to conform to the standard Clojure web server (Ring [1]) spec and to be consumed by Clojure applications.
The public API is all Clojure-side and essentially uses the Java parts as an implementation detail. This kind of interop is easy to do with Clojure and is usually motivated by performance.
The best way of describing http-kit would probably be as a "Clojure web server written in Java".
The library author is Chinese, so English isn't his native language. We'll be cleaning up typos soon - this post caught us by surprise.
As for Compojure, etc.- those are libraries that operate on top of a Ring web server. Jetty is the default, http-kit is a drop-in replacement. So basically, you'd use both http-kit and whatever other libraries you normally would (like Compojure).
I swapped out a production Jetty+Compojure app to use http-kit+Compojure by changing ~20 lines of code.
Certainly your web server isn't likely to be the performance bottleneck in the majority of real-world applications. Even without a db call, just generating the response Clojure-side will kill your numbers (and Clojure is pretty darn fast).
Still, the ability to cheaply handle large numbers of concurrent connections is great for things like WebSockets and long polling where you aren't crunching data for every connection all the time. This is an async server, so it's well suited to such tasks.
Benchmarks author here. I did my best to get representative numbers, but good benchmarking is tough and this isn't my area of expertise. There's almost certainly errors and room for improvement (suggestions very welcome!).
In particular, I'm pretty sure nginx could be tuned here to lead.
BTW I also ran benchmarks against a more realistic EC2 environment with proportionally similar results (EC2 is slow but its effect across servers was consistent).
I believe this test was run locally for simplicity (and so people can reproduce it easily). As you've pointed out, that's a pretty artificial context and can obviously have a big absolute effect on the numbers.
I will say that in my limited experience these numbers are proportionally representative of what you can get in a real-world environment.
Even testing locally, getting concurrency numbers like this is tough or impossible with many (most?) servers.
So, yes, it's an artificial test - but I think the results are interesting when taken in the correct context.
Hmm, interesting- didn't know about the split-keyboard thing (I'm only on iPhone).
I've been thinking about what else might be an alternative but am coming up short. More than 2 fingers would be impractical on an iPhone.
Question: In the video you linked to, the split-keyboard gesture looks quite specific... 2 separate fingers dragging away from or toward one another. I guess it's asking too much to hope that the device could distinguish between this kind of dragging and scroll-style dragging (2 fingers together, same direction)?
BTW I'm assuming this'll be up in the next beta sometime? Would love to play with it.
In principle really like the idea of something like this- especially in the context of an app like yours where you're targeting long-document writers.
How's it feel to use in practice? I kind of liked the suggestion elsewhere here about needing 2 fingers to do the scrolling to prevent the cursor from accidentally running away.
I've been struggling a little to succinctly articulate the "killer function", since it's more an interplay of things that take a little explaining. The text at the top was my attempt so far: will think some more on it.
It's fully functional without registration, btw - only message sending is disabled. Just scroll down for the profiles. I'll put in a note at the top to make it clearer.
I'm in the process of launching an early prototype version of a Clojure/MongoDB web application I'm working on called Wusoup (www.wusoup.com).
Basically the thing functions as a people-matching and messaging service for dating/friendship/chatting purposes.
The single biggest difference between Wusoup and traditional dating sites (the closest comparison), is that matching is done in a learning fashion by observing user interactions over time.
I'm using cluster analysis to produce a metric space over the profiles, which lets me (or rather, will let me) do some pretty interesting stuff for matching.
Now I've gone about this completely the wrong way: building a non-niche product, and building it before any kind of marketing plan. I realise the odds are pretty much against me on every front. The two biggest obstacles I see are heavy SEO keyword competition and, well, zero user base to start with. Adding insult, this isn't my field so I've got no networks to lean on for support.
Despite all that, I feel strongly about the idea. If I don't pull it off now, I'm convinced that someone else eventually will: I'm convinced this is the right direction for the people-matching problem.
If anyone's interested, I'll be blogging very openly about the whole startup (link on homepage). In particular, I'll be publishing detailed analytics as I go along.
Would seriously love any kind of feedback from HN: especially if anyone has any particular ideas or suggestions to help get me going on the growth/marketing front. You think anyone will actually care?
I guess it's just a difficult situation: especially with the geographical distance, a gut feeling is probably all I'll have to work with.
I'm curious though: is this not a common problem? Outside of the partner context, I don't often see discussions of trust relating to startups.
And about the value of the implementation: of course, I'm sure plenty could come up with the same or better solutions. The trick is that no one seems to have -yet- (publicly, at least) - which means that there may still be some ephemeral advantage to the first mover.
It explores some of the common reasons that OSS maintainers burn out. And explores some of the easy ways that OSS users can help to reduce maintainer attrition.