Hacker News new | ask | show | jobs
by lawpoop 3643 days ago
> no such thing as slow language, only slow implementations

My interpretation of that (and perhaps I'm reading too much into it) was that for modern-day 'retail' tasks (taking an HTTP request, querying a database, dispatching workers, running business logic, and returning a styled webpage) that going for low-level languages over high-level languages did not bear out as much improvement, esp. reconciled against development time and code flexibility.
2 comments
jerf 3643 days ago
No, I'm fairly sure this saying is used in the context of the implementations actually being slow. "You're always in IO" is a different defense used for the slow languages, one which I have also found is overstated, for what it's worth. I have found in practice it isn't that hard to build even a simple-looking REST interface that has non-trivial amounts of time spent in non-IO code in Perl or Python. I think a lot of people would be shocked if they sat down and really worked out just how little Python/Perl/etc. code they can run before they webserver noticeably starts slowing down at even small scales.
link
stickfigure 3643 days ago
Agreed.

I spent a little time working with Guido on cache design for the App Engine data access api (ndb). In Java-land, it's a big win to cache datastore entities in memcache because fetch latency is about an order of magnitude faster. In Python-land, caching is a mixed bag - real-world profiling found marginal benefit even with 100% hit rate, and a significant performance disadvantage if the hit rate drops off. This is primarily attributed to pickling overhead.

If you're curious, here are the benchmarks (from 2011): https://github.com/googlecloudplatform/datastore-ndb-python/...

link
lawpoop 3643 days ago
I'm rethinking my interpretation on this.
link
collyw 3643 days ago
These are typical web app based tasks and IO is usually the bottleneck in such situations, not the language.
link
lawpoop 3643 days ago
That's sort of my point, if I understand you correctly.

There are two responses to "Hey, the site is slow!" One is "Well, that's because PHP/Python/Java is slow, we should start coding in C/etc". Another is "The codebase or architecture is probably unoptimized and/or poorly structured in some areas; let's identify, prioritize and start fixing those areas."

The slow languages are "good enough", in an engineering sense, for today's retail features. The payoff of using a fast language doesn't provide enough value for its cost. It doesn't matter that searching a PHP array is slow; that's not where the problems are in today's software.

link