Older HN users may recall when busy discussions had comments split across several pages. This is because the Arc [1] language that HN runs on was originally hosted on top of Racket [2] and the implementation was too slow to handle giant discussions at HN scale. Around September 2024 Dang et al finished porting Arc to SBCL, and performance increased so much that even the largest discussions no longer need splitting. The server is unresponsive/restarting a lot less frequently since these changes, too, despite continued growth in traffic and comments:
"Btw, we rolled this out over 3 weeks ago and I think you're the first person to ask about it on HN. There was one earlier question by email. I think that qualifies as a splash-free dive."
I had no idea and I'm an HN addict!
dang 4 minutes ago [-]
The "splash-free dive" metaphor came from the greatly missed sctb and was the springboard for much fun conversation at HNHQ.
I was the person who emailed him about it earlier.
2024-09-05, me:
On another topic, I just noticed that the 700+ comments on https://news.ycombinator.com/item?id=41445413 all render on a single page. Hurray! Is the pagination approach obsolete now? I know that you've commented several times about wanting to optimize the code so pagination wasn't necessary. I don't know if that's finished or if pagination will have to go on the next time there's a big breaking story.
Dan G:
Yes: the performance improvements I've been working on for years finally got deployed, so pagination is turned off for now.
(In case you're curious, the change is that Arc now runs over SBCL instead of Racket.)
...
Btw you're the only person I know of who's noticed this and pointed it out so far!
I have very mixed feelings about how much I know about this site.
18 minutes ago [-]
pjmlp 50 minutes ago [-]
While great option, LispWorks and Allegro Common Lisp should not be overlooked, too many focus on SBCL + Emacs and then complain about Lisp tooling.
cultofmetatron 35 minutes ago [-]
> too many focus on SBCL + Emacs and then complain about Lisp tooling.
well yea, lispworks and allegro are expensive commercial projects. I wish sbcl, the defacto best open source option had better tooling. emacs is great and all for the true believers but I'm an unwashed vscode user. For plenty of reasons I can't justify it in my startup but I'd love to spend more time working with common lisp for personal projects but my time is limited so I prefer clojure or rust.
stackghost 6 minutes ago [-]
I use emacs regularly, and I think the complaints against it are perfectly valid. Emacs awesome in lots of ways, but it also really, really sucks in lots of other ways.
But putting emacs aside, the SBCL tooling seems reasonable to me. The real reason I rarely reach for lisp these days is not the tooling, but because the Common Lisp library ecosystem is a wasteland of partial implementations and abandoned code bases.
It's also been my experience that LLMs are better at writing more mainstream languages, especially "newbie-proof" languages like Go.
In any case, I don't see why one would reach for Allegro or Lispworks over SBCL unless one really enjoys writing lisp by hand and needs specific features they offer that SBCL doesn't. I would imagine those features are vanishingly few.
emptybits 2 hours ago [-]
Can we get a "(1999)" date on this, please? Only half joking becuase I see Common Lisp and, sure, I upvote ... but honestly, what's the purpose of this HN submission without context?
SBCL is obviously fantastic but let's contrast with another popular implementation: Embeddable Common Lisp. https://ecl.common-lisp.dev/
Top marks for SBCL performance but ECL can be a better fit for embedding into mobile applications, running on lighter weight hardware, and in the browser.
We upgraded to 2.6.1 about a week ago and switched to using the new(ish) parallel(ish) garbage collector. I still can't tell what the impact has been.
Claude Code (which is a wizard at analyzing log files but also, I fear, an incorrigible curve-fitter) insisted that it was a real breakthrough and an excellent choice! On the other hand there was a major slowdown last night, ending in SBCL dying from heap exhaustion. I haven't had a chance to dig into that yet.
emptybits 1 hours ago [-]
Thanks. Your link gives more insight into "why submit now?" Appreciate it.
shadowgovt 1 hours ago [-]
My favorite bit of SBCL trivia is the name: this is descended from Carnegie Mellon's build.
Steel. Bank.
wiz21c 1 hours ago [-]
I don't get it :-(
wk_end 1 hours ago [-]
I think it's just that Andrew Carnegie made his fortune in the steel industry, and the Mellons made their fortune in banking.
PantaloonFlames 46 minutes ago [-]
Yes and
Carnegie Technical Schools was founded in 1900 based on a $1m donation from Andrew Carnegie,
Mellon Institute of Industrial Research was originally founded in 1913 by Andrew and Richard Mellon.
Carnegie Mellon was created by combining the two institutions in 1967.
giraffe_lady 1 hours ago [-]
That's very fun and makes so much more sense than my half guess that it was from a defunct regional mid 20th century bank I had never heard of.
jibal 2 hours ago [-]
What about it?
oytis 1 hours ago [-]
It's a recurrent event when someone on HN discovers some well-known piece of technology.
jjtheblunt 10 minutes ago [-]
agreed, but "tosh" posted numerous times on SBCL over the last 7 years, so it's a valid question.
It's awesome and the lucky 10,000 deserve to be introduced to it?
mikestorrent 17 minutes ago [-]
A well known quantum computing company's entire stack runs on SBCL, with Emacs in production... works really well, don't knock it until you've tried it. Phenomenal REPL.
umairnadeem123 19 minutes ago [-]
the HN migration from Racket to SBCL is probably the best real-world case study for SBCLs native code compiler quality. going from pages of comments needing pagination to rendering everything in one shot is not a minor optimization - thats an order of magnitude improvement in throughput for a real production workload.
what doesnt get mentioned enough is SBCLs type inference. if you add type declarations to hot paths, the compiler generates code that rivals hand-optimized C. the REPL-driven development workflow where you can redefine functions in a running system is still unmatched by anything in the modern tooling ecosystem.
Rendered at 21:05:20 GMT+0000 (Coordinated Universal Time) with Vercel.
https://news.ycombinator.com/item?id=41679215
[1] https://paulgraham.com/arc.html
[2] https://racket-lang.org/
"Btw, we rolled this out over 3 weeks ago and I think you're the first person to ask about it on HN. There was one earlier question by email. I think that qualifies as a splash-free dive."
I had no idea and I'm an HN addict!
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
2024-09-05, me:
On another topic, I just noticed that the 700+ comments on https://news.ycombinator.com/item?id=41445413 all render on a single page. Hurray! Is the pagination approach obsolete now? I know that you've commented several times about wanting to optimize the code so pagination wasn't necessary. I don't know if that's finished or if pagination will have to go on the next time there's a big breaking story.
Dan G:
Yes: the performance improvements I've been working on for years finally got deployed, so pagination is turned off for now.
(In case you're curious, the change is that Arc now runs over SBCL instead of Racket.)
...
Btw you're the only person I know of who's noticed this and pointed it out so far!
I have very mixed feelings about how much I know about this site.
well yea, lispworks and allegro are expensive commercial projects. I wish sbcl, the defacto best open source option had better tooling. emacs is great and all for the true believers but I'm an unwashed vscode user. For plenty of reasons I can't justify it in my startup but I'd love to spend more time working with common lisp for personal projects but my time is limited so I prefer clojure or rust.
But putting emacs aside, the SBCL tooling seems reasonable to me. The real reason I rarely reach for lisp these days is not the tooling, but because the Common Lisp library ecosystem is a wasteland of partial implementations and abandoned code bases.
It's also been my experience that LLMs are better at writing more mainstream languages, especially "newbie-proof" languages like Go.
In any case, I don't see why one would reach for Allegro or Lispworks over SBCL unless one really enjoys writing lisp by hand and needs specific features they offer that SBCL doesn't. I would imagine those features are vanishingly few.
SBCL is obviously fantastic but let's contrast with another popular implementation: Embeddable Common Lisp. https://ecl.common-lisp.dev/
Top marks for SBCL performance but ECL can be a better fit for embedding into mobile applications, running on lighter weight hardware, and in the browser.
Claude Code (which is a wizard at analyzing log files but also, I fear, an incorrigible curve-fitter) insisted that it was a real breakthrough and an excellent choice! On the other hand there was a major slowdown last night, ending in SBCL dying from heap exhaustion. I haven't had a chance to dig into that yet.
Steel. Bank.
Carnegie Technical Schools was founded in 1900 based on a $1m donation from Andrew Carnegie,
Mellon Institute of Industrial Research was originally founded in 1913 by Andrew and Richard Mellon.
Carnegie Mellon was created by combining the two institutions in 1967.
https://hn.algolia.com/?q=tosh+sbcl
what doesnt get mentioned enough is SBCLs type inference. if you add type declarations to hot paths, the compiler generates code that rivals hand-optimized C. the REPL-driven development workflow where you can redefine functions in a running system is still unmatched by anything in the modern tooling ecosystem.