"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.
https://github.com/pauek/arc-sbcl
And there's no version of Anarki that runs on sbcl?:
I talked to one of the Anarki devs (or at least someone who uses it) about possibly open-sourcing a version of clarc which would run the original open-sourced version of HN, but it's a bit hard because the implementation would require some careful surgery to factor out the relevant parts.
This type of application stack that includes the language you're writing in and even, when convenient, its implementation, is really satisfying to work with. There is much less need for workarounds, arbitrary choices, and various indirections (e.g. what used to be called dependency injection, for example). All the plumbing is an order of magnitude simpler and it allows us to keep the codebase much smaller than it would otherwise be. I also spend basically zero time bitching about having to deal with software dependencies, making me realize how much of my former life as a programnmer was taken up with just that.
I think of this as sort of the unikernel form of application dev and of course it's a fine fit for a Lisp, since "write the language you want to write your program in as you write your program in it" is the natural style there. The tradeoff is that there's a lot of vertical coupling between the layers. If you want to factor out one layer for general consumption, e.g. to open source the language implementation so other people can build cool things with it, there's a fair bit of work to do.
Also, since the language implementation exists to run a specific application, we just don't bother supporting we don't need for HN. That too comes back to bite you when you want to open-source it!
HN has had 15+ years of work since the original news application was open-sourced; that's a lot of things-we-added at-some-point. Most of those are at the application level but some ended up in Arc and some in the Arc implementation it was convenient to put them there. This is especially handy when you have limited time to work on the code.
I suppose I shouldn't be surprised that Arc/clarc would be modified as news is modified (Arc sort of being built around news in the first place).
I just wouldn't expect there to be hn specific sauce in clarc that would make sense to excise if opening up clarc; AFAIK it's been stated that there's some secret sauce wrt fighting spam, detecting voting rings and so on...
Then again, thinking more about it, it sounds reasonable that some of that might land on the Arc/clarc side, not in news.
[Ed: I think that turned out quite well]