Node.js similarly is single-threaded. Both boast pretty impressive performance.
Being single-threaded is not a detriment to performance, rather, it most often results in faster software, per core, due to lack of the need for synchronization and avoiding a memory allocation that happens for each thread (can be a problem, see C10K problem).
Being single-threaded does not mean you can't do things concurrently. As long as you have a set of async primitives, starting with the venerable select(2), and a bit of language syntactic sugar (preferably, or just setjmp(3)) you can interleave handling of incoming and outgoing data in what is called "cooperative multitasking". There are many higher level frameworks built on top of the principle, which is that - hidden or visible - context switches are voluntary only. As HN seems to be written in Arc, which shares the implementation with Racket, then the feature most likely to be used for this is either call/cc (or one of the higher-level abstractions built upon it, like generators) or it would, going past the "cooperative" territory, simply use threads: https://docs.racket-lang.org/reference/threads.html These threads are not "real" threads, only one instruction among all threads ever executes at once, but the points of context switching are not specified in the code being executed (leading to preemptive multitasking but without parallelism). If HN uses those, then it can be called both "single-threaded" (the VM) and "multi-threaded" (the HN code) at the same time.
Being single-threaded also doesn't prevent you from using multiple cores to max out your processing power. In age old tradition you can just spawn off a few worker processes and call it a day. You might need some sort of Inter-Process Communication, but there are many mechanisms to choose from. Nowadays on Linux you can use the listening socket as a simple round-robin scheduler for processes, free of charge, no need for a separate proxy. The processes might be managed by external supervisor, like systemd, or they might be managed by the language runtime itself, and Racket provides Places for this IIRC: https://docs.racket-lang.org/reference/places.html
Note: I'm just guessing based on what I've heard about HN implementation and my knowledge of Racket which may, or may not, be relevant at this point.
Anyway: rewriting the HN backend to "use multiple OS-level, preemptively scheduled threads" (which you wanted to write but contracted to "multiple threads"), would not result in per-core performance increase, it's actually more probable to cause the exact opposite. I'd guess that the backend is already optimized in terms of algorithms and data storage, so the only recourse now would be to rewrite the whole thing in (or compile down to) a language that tends to perform better than what Racket VM can offer. Given that HN is already a weekend project of a hacker (I mean, written in a Lisp? A Lisp implemented on (former) Scheme...), I'd probably give Nginx + LuaJIT a whirl, or maybe one of the BEAM languages (there's a Lisp over there, too, so another fun weekend for porting Arc to LFE) if manual control over distribution over multiple nodes is desirable (but it would be a total time-sink, while things like Kubernetes (I'm told) mostly work well enough... though K8s is a time-sink in its own right...)
Dang mentioned in another comment the GC being too slow. In that case, replacing the GC implementation could help, if possible. It's also possible to write code that avoids as many allocations as possible, but it's hard, and the GC can still happen at bad moments. In some cases, simply disabling the GC altogether and restarting the process periodically can also give better - or at least more predictable - performance. This is indeed a troubling problem to have, but it's completely orthogonal to single- or multi-thrededness. (Other than the multi-threding tends to allocate more memory for the same workload)
So yeah, that was a tangent, but your statement was very wrong, yet very common, so I thought I'd do my duty as a good techie and shed some light on the matter.
My statement isn't "very wrong" at all. If you actually have one single thread, total, that's a harsh limit on how much you can do. And I never implied it wasn't concurrent within that thread.
You also presented the threadedness as a cure-all solution to performance problems, which it is not. That's wrong.
You also never implied that you mean paralelism in general as opposed to just threads. But yeah, in the case you can't use any kind of parallelism, you're kind of screwed. The problem is that threads are one of the worst ways of introducing parallelism.
No matter your method, you need some kind of scheduling and synchronization if you want to go beyond 5 billion CPU cycles per second on a multi-user site.
> You also presented the threadedness as a cure-all solution to performance problems, which it is not. That's wrong.
No I didn't. But having more than one core in use is the only way to get over a certain threshold, no matter how good your code is.
> The problem is that threads are one of the worst ways of introducing parallelism.
Like I said, it would have been better if I was clearer that I mean completely non-parallel code. But parallelism was my point. Everything you're saying about threads in a single process vs. multiple processes is not me being wrong, because it wasn't my argument.
Or to put it another way: Yes threads in a single process are on the bad end of parallelism. But they're also the easiest. If you see a statement that code can't even do that, then that should already imply that you can't run multiple processes on the same website instance.
> But they're also the easiest.
I don't believe that's true. Threads are the easiest to work with if you have a lot of shared, mutable state kept within an adress space of a single process and, crucially, cannot do anything about it. I don't know if that's the case for HN backend, but it rarely is in practice. Then there's a problem of multiple different threading implementations out there, and also an issue of how the threading mechanisms interact with the runtime (Python is multithreaded, but has a GIL). Frankly, it's a minefield on all sides, and implementing a system that is multithreaded, performant, and correct at the same time is the exact opposite of what I'd call "easy". That's also the reason why I disagree here:
> If you see a statement that code can't even do that, then that should already imply that you can't run multiple processes
To me, threads are not the first thing that comes to mind when I think about parallelism. Being unable to leverage threads, to me, is a good thing: just let this sleeping can of worms lie. As you know, there are multiple (many) ways of achieving parallelism, and they differ very much: I don't think being unable to leverage one of them says anything about the ability to use any of the others. That may be just me, though, so let's just say I have a different impression here and call it a day :)