A post from a week or two ago about APL and cellular automata (I cannot find it) perhaps illustrated OP's sentiment better: it's easy for a language to do something easily and elegantly, but quickly become fantastically difficult to accomplish with the introduction of new—and sometimes mundane—constraints. The post showed how it was trivial to implement certain cellular automata in APL, but massively difficult to do when the automata became slightly more complex (while being trivial to update a Java implementation to accommodate the new complexity).
The practical difference between running on one server with one core and five servers with four cores is nothing—to YC it's a rounding error either way. If there's a meaningful problem (e.g., comments being computationally expensive to paginate well) that the language/runtime/system/etc cannot solve easily enough for it to be remedied in O(months), it does call into question whether the choice of language is the right one. Yes, it can be patched over by a human moderator. But it still highlights a significant weakness in the technology's core function.
Perhaps ironically, most YC companies (and by consequence, YC) would fail miserably if they chose purism and principle over pragmatism when it came to technology decisions.
The practical difference between running on one server with one core and five servers with four cores is nothing—to YC it's a rounding error either way. If there's a meaningful problem (e.g., comments being computationally expensive to paginate well) that the language/runtime/system/etc cannot solve easily enough for it to be remedied in O(months), it does call into question whether the choice of language is the right one. Yes, it can be patched over by a human moderator. But it still highlights a significant weakness in the technology's core function.
Perhaps ironically, most YC companies (and by consequence, YC) would fail miserably if they chose purism and principle over pragmatism when it came to technology decisions.