5 ms·
This argument holds water until you have languages that are orders of magnitude faster with the same developer enjoyment and experience. 13 years ago, I'd argue
by joesmo 10y ago
This argument holds water until you have languages that are orders of magnitude faster with the same developer enjoyment and experience. 13 years ago, I'd argue that choices were rather limited. Nowadays, there are too many choices. Fast enough is just not good enough in a market with plenty of competition.
What is fast enough? If you're building a web app, fast enough is not the same as if you're building a web API. The latter needs to perform much better than the former in my experience because the former might make multiple calls to the latter in a single request. I find it almost impossible to make an argument for interpreted languages at this point for backend services considering how slow they are and how few, if any, benefits they have over the many non-interpreted languages out there. I'm thinking of languages like Clojure and Elixir, but even Java has a framework that supports hot code reloading (Play) thus getting rid of the last remaining benefit of an interpreted language. Once you get rid of that, it really no longer makes sense to use an interpreted language, all other things that DHH mentioned being more or less equal.
- vidarh 10y ago"Orders of magnitude faster" isn't possible in any case where more than 10% of your time is spent waitin on external factors (kernel space, waiting on IO etc.), which is the case for pretty much everything I've ever done. There are certainly types of code that will be CPU bound, in which case, yeah, there's a good case for using something else - or calling out to something else -, but for large parts of what people write, not being IO bound is a warning sign that you should take a long hard look at what you're doing, because chances are you're doing something silly. Webapps and typical APIs for webapps tends to be amongst those. Of the work I've done in the last 20 years, maybe 2-3 projects have been projects where CPU performance have been an issue. For others it will be every project they every do. But the point is there are plenty of us for whom language performance is not a factor we usually need consider.
- joesmo 10y agoI benchmark most interpreted language http frameworks in the low tens to hundreds of requests per minute range at best without any app code and you're telling me that CPU performance isn't an issue?
- vidarh 10y agoNo, I'm telling you that CPU performance usually isn't an issue. Most sites will never, ever need to serve enough dynamic requests for that kind of performance to be an issue (and you can certainly do far better than that on dirt cheap hardware).
- MrBra 10y ago> with the same developer enjoyment and experience Expand on this please?