A nice example of how using the wrong programming language for your project impedes your progress/feature delivery.
HN wouldn't exist without Arc, so it's pointless to argue about this. But I love talking about it so I'm going to anyway.
The feedback loops between the language, the HN software, and the living system of the community go very deep. I could write a lot about that. It's one of the most interesting things about the project, though unfortunately not visible. The software just works its Lispy magic behind the scenes, remaining small and malleable. It's still only 15k lines of code, including the language implementation, and that code does a lot.
On performance, it's pretty cool that Arc has managed to run HN through 12+ years of growth without much optimization. It's a good sign, not a bad one, that we're only doing major rework for performance reasons now. HN is far from Reddit-scale, but still: the application runs on a single core. (Though we do cache pages for logged-out users and serve those from an Nginx front end.)
As long as we're on the topic, consider this: the software for both HN and YC was just a single Arc program (and not a large one) for the first 9 years of their existence, during which they went from nothing to massively successful to industry-changing. Written by one person, programming part-time. That is a staggering achievement. The power of using the right language for your project goes far further than most people dream. Our imagination about this is crippled by path dependence, social proof, and the conditioning that comes from only ever doing things the same few ways, like those fish in experiments (which may be urban legends?) who stick to their corner of the aquarium even after a glass barrier has been removed. The solution space of software and programming is so much larger than most of us want to imagine that it is. Sad.
I'm not saying that everyone should use Arc—language/programmer fit is a key part of language/project fit. But when all three variables align, incredible things become possible. Not only HN, but YC would not exist without Arc. Another case that came up recently was Cloudflare; very different language, project, and programmer, but a similar story (https://news.ycombinator.com/item?id=22883548).
Rather, it's that there's a deep interdependency between the three variables of language, programmer, and problem that give rise to a system like HN+YC (which was a single program until 2014). If you changed any one of those variables you'd either have gotten something radically different or nothing at all. So my statement is a bit like saying that YC would not exist without PG; and your objection is a bit like saying: that's an exaggeration, any person who did the same steps at the same time could have arrived at the same place (and perhaps better since that person might have been a better manager as well).
(Not only PG built YC, of course! But PG wrote the software and that was a critical piece.)
I'm not saying that all programs have this property about programming languages—rather, that some do, and they tend to be particularly interesting and creative. For another example, one might say that Unix would not exist without C.
There would be more interesting and creative systems in the world if we were more open as a community to these unexplored spaces. We exclude them in order to have the feeling that we know what we're doing, and we reinforce this by ridiculing and dismissing deviants. The social dynamics that exclude new creative possibilities are incredibly strong, which is one reason why when systems like this do end up succeeding, they tend to be the work of loners, weirdos, or people who have some strange mutation to withstand social pressure. (This by the way is the origin of the "$weird-language is only good for solo programmers" meme, ironically confusing cause and effect.) No doubt other fields work the same way; software is just the one I know well enough for the mechanisms to be obvious to me.
An analogy just occurred to me, which I want to note so I don't forget it. The relationship between a program and the language it's written in is like the relationship between a piece of music and the instrument it was composed for. To say "this system could have been built in some other language" is like saying "this music could have been composed for some other instrument". That may technically be true; music gets transcribed for other instruments all the time, just as programs get ported to other languages. But it misses the most important thing: the creative process by which the music or program got written in the first place.
There are intimate feedback loops between the mind of the composer, the developing music, and the design of the instrument—which possibilities it makes natural/easy vs. which it discourages/excludes. Every instrument and every programming language has a different set of these. They may not differ in what can theoretically be played on them, but they differ immensely in how they organize the space of possibilities—which ones are near at hand vs. out of reach. You can play the same scales on the piano, the cello, and the guitar, but where the mind goes next as it composes a new sequence of notes—not a scale, but a sequence that has never existed before—is deeply conditioned by the instrument it's working with, which is the medium it's growing in. Some next-notes are far more likely than others, and which next-notes those are differs greatly between instruments. In the same way, a program grows by accruing constructs (expressions, statements, forms, types), and the ones that are most likely to get added next are the ones that are most natural and nearest-to-mind, given the program so far. Which next-constructs those are differs greatly between languages.
Since each next-note or next-construct is deeply conditioned by the sequence it's adding to, this effect compounds as the system grows. It follows that, at least for the most interesting and creative systems, a program is literally unthinkable apart from the language it grows in. So much for "languages don't matter"—yet how often that untrue truism is repeated! The reason for this fallacy is that we take a program as if it existed prior to being written, which is impossible.
So when I say HN/YC would not exist without Arc (or Lisp really), I mean it in the sense that https://www.youtube.com/watch?v=rGgG-0lOJjk#t=14 would not exist without the cello even though https://www.youtube.com/watch?v=mhfxM5FOzjQ#t=3 is a thing, https://www.youtube.com/watch?v=x6GZ6xeGnJQ#t=15m would not exist without the piano even though https://www.youtube.com/watch?v=XXGCfW-cGoE#t=91 is a thing, and https://www.youtube.com/watch?v=skdE0KAFCEA would not exist without the electric guitar even though https://www.youtube.com/watch?v=kNFpOh2seqo is a thing.
As long as we're on the topic, consider this: the software for both HN and YC was just a single Arc program (and not a large one) for the first 9 years of their existence, during which they went from nothing to massively successful to industry-changing.
I mean, you don't have to agree, but his opinion is probably more informed on the topic than yours is.
And maybe, because they launch YC companies here and let them advertise job openings here, it's part of their business model.