3 ms·

The same argument can be made for any mature language with a solid ecosystem of tools and libraries. Except the part about scalability, that's just BS. It has

The same argument can be made for any mature language with a solid ecosystem of tools and libraries. Except the part about scalability, that's just BS. It has little to do with language and is all about architecture. Sure, at some point language can help you squeeze every ounce of performance out of the hardware (although my money would not be on Java for that), but that's only in cases where either performance is critical or the scale is so huge that saving on hardware makes a big difference.

guard-of-terra 12y ago
It has a lot to do with language. If your language's runtime has solid threading and reasonably pauseless GC (at several gigabytes heap) you run into much much less problems with scalability. Java people take many things for granted.
waps 12y ago
You forget just how much difference there is between languages. Comparing Python and Java for example, it's easy to find things that take 1-2 cpu cycles in Java (or even 0), that take thousands of cpu cycles in Python (e.g. function calls). http://benchmarksgame.alioth.debian.org/u32/python.php http://benchmarksgame.alioth.debian.org/u32/python.php I mean, I would agree that 1s versus 1.3 seconds doesn't really matter. But look at those numbers we're talking 40-50 TIMES faster in half the cases. The number I tend to use is that one programmer is worth 10 servers. But this has diminishing returns : the larger the site gets, the more you'll focus on servers. But even for small sites. Python is about double java's productivity, no more. That only helps you for very small programs. So for large sites, python would have to be 40-50 times more productive than java. This is exactly python's weak point, and java's strong point ... And from experience I know. Large python programs are horrendously difficult to change. They're like how large perl programs used to be. Changing a tiny thing in one far removed part of the program affects 10 other places in the program, with absolutely no warning, until the site crashes. And then you put a try-catch in your main loop and AAARGH.
- TheLoneWolfling 12y ago
  And yet there is a benchmark in that particular set you linked in which Python runs in 3/4 the time. Also, I don't like the CLBG - it removed PyPy and a bunch of other implementations of various languages. I would be intrigued to see the speed of PyPy on that particular set of benchmarks, for instance.
  - igouy 12y ago
    I would be pleased if you took the program source code and the measurement scripts and published your own measurements. http://benchmarksgame.alioth.debian.org/play.html#languagex http://benchmarksgame.alioth.debian.org/play.html#languagex But we all seem feel the same way about this, we all feel that we should sit on our hands and wait for someone else to do the chores we don't wish to do.
- paulddraper 12y ago
  Yes, AAARGH indeed.
- jbergens 12y ago
  I agree that the project size (LOC and usage) matters a lot and that small projects could use almost any language. I don't agree that everything i linear. A project with 10 times the LOC is not just 10 times harder to build, it might be anywhere from 20-100 times harder. For example, 10 000 LOC is possible for a developer to read and remember quite well, 100 000 LOC is much harder and takes longer to read. 1 million LOC is probably really, really hard to read and understand (especially when we are talking about old code with a lot of cruft and possibly multiple changes in the design over time). So for a small code base that happens to have millions of users you should probably go for a fast language and take the time to optimize a lot. For a large code base with very few users you should probably use an expressive language and don't care about performance. And then you have all in-betweens which are left as an excercise to the reader ;-)

guard-of-terra 12y ago

It has a lot to do with language. If your language's runtime has solid threading and reasonably pauseless GC (at several gigabytes heap) you run into much much less problems with scalability. Java people take many things for granted.

waps 12y ago

You forget just how much difference there is between languages. Comparing Python and Java for example, it's easy to find things that take 1-2 cpu cycles in Java (or even 0), that take thousands of cpu cycles in Python (e.g. function calls). http://benchmarksgame.alioth.debian.org/u32/python.php http://benchmarksgame.alioth.debian.org/u32/python.php I mean, I would agree that 1s versus 1.3 seconds doesn't really matter. But look at those numbers we're talking 40-50 TIMES faster in half the cases. The number I tend to use is that one programmer is worth 10 servers. But this has diminishing returns : the larger the site gets, the more you'll focus on servers. But even for small sites. Python is about double java's productivity, no more. That only helps you for very small programs. So for large sites, python would have to be 40-50 times more productive than java. This is exactly python's weak point, and java's strong point ... And from experience I know. Large python programs are horrendously difficult to change. They're like how large perl programs used to be. Changing a tiny thing in one far removed part of the program affects 10 other places in the program, with absolutely no warning, until the site crashes. And then you put a try-catch in your main loop and AAARGH.

TheLoneWolfling 12y ago
And yet there is a benchmark in that particular set you linked in which Python runs in 3/4 the time. Also, I don't like the CLBG - it removed PyPy and a bunch of other implementations of various languages. I would be intrigued to see the speed of PyPy on that particular set of benchmarks, for instance.
- igouy 12y ago
  I would be pleased if you took the program source code and the measurement scripts and published your own measurements. http://benchmarksgame.alioth.debian.org/play.html#languagex http://benchmarksgame.alioth.debian.org/play.html#languagex But we all seem feel the same way about this, we all feel that we should sit on our hands and wait for someone else to do the chores we don't wish to do.
paulddraper 12y ago
Yes, AAARGH indeed.
jbergens 12y ago
I agree that the project size (LOC and usage) matters a lot and that small projects could use almost any language. I don't agree that everything i linear. A project with 10 times the LOC is not just 10 times harder to build, it might be anywhere from 20-100 times harder. For example, 10 000 LOC is possible for a developer to read and remember quite well, 100 000 LOC is much harder and takes longer to read. 1 million LOC is probably really, really hard to read and understand (especially when we are talking about old code with a lot of cruft and possibly multiple changes in the design over time). So for a small code base that happens to have millions of users you should probably go for a fast language and take the time to optimize a lot. For a large code base with very few users you should probably use an expressive language and don't care about performance. And then you have all in-betweens which are left as an excercise to the reader ;-)