Tim Bray has been experimenting with some new darling of a language — Erlang — and finds it wanting. In the same sense of the “Hello World” application every language offers, he has taken a sample problem of parsing, sorting, and tabulating and for all Ruby’s slowness, it crushes Erlang.
There’ve been comments and blogs along the lines of “WTF, trying to shake down Erlang using what amounts to a degenerate Awk script!!? This isn’t what Erlang is for! It’s all just I/O! Lines of text are so 1980’s!”
Nope; the further this goes, the more I think it’s a valid line of research. You know all those kazillions of Sun servers out there? Let me tell you, they’re not all running state-of-the-art Java-on-the-net apps. A huge proportion of all those cycles goes into Perl scripts and COBOL batches and C++ meat-grinders and FORTRAN number-crunching. Furthermore, if you look at the numbers from running my Perl and Ruby scripts, it’s obvious that they’re pegging both the CPU and I/O needles; so they’re nicely multidimensional in a simple way.
This is the kind of nasty unglamorous job that a lot of our customers run all the time to pay their rents, and this whole business is making a big bet on many-core computers, and it’s just not on to tell all those people that those are the wrong kind of jobs for the new iron.
As anyone going into professional computing should be aware, you don’t start with a blank slate or new hardware very often. More likely, you’ll be adding a feature or hunting a bug in someone else’s code, probably in a language you hate, with no comments, a raft of opaquely named variables and routines, and trying to work around production jobs on over-allocated hardware.
Deal with it. A lot of these new languages about saving programmer time with all kinds of tricks. Programmer time gets used and paid for once, while execution time on the system might be daily, hourly, maybe constant. That’s where the efficiencies are, for many.