I always read "not compiled" as a synonym for "slow."
I'm not worried about Python's type system. At worst it's manageable, at best it's expressive for prototyping.
But when I see benchmarks that suggest Python is 10 to 100X slower for critical server code, I have to wonder why anyone would use it for enterprise development.
Which is why there are so many Java and C++ code jockeys working in enterprise. Neither language is pretty or fun or interesting from a CS point of view. But there's no arguing both consistently run faster than anything this side of assembler.
I would have expected critical industrial infrastructure code to pay some attention to that - because speed isn't an abstraction. When you're running giant data centres, extra cycles consistently cost real money.
Dev costs are relatively small compared to operating costs. So it's well worth spending extra time getting good, fast compiled code working.
PyPy really closes the speed gap. The latest PyPy 2.5 release uses pinning to pass pointers between the C layer and PyPy greatly improving IO performance [1]. I've noticed this in a project I've been working on holding open large amounts of concurrent connections (> 100k at a time), PyPy has been completely competitive with Go, and actually using less memory. Yes, it's not as fast as a Java/C+ version, but with PyPy its more like 2-5x slower, not 10-100x slower which really changes things.
>But when I see benchmarks that suggest Python is 10 to 100X slower for critical server code, I have to wonder why anyone would use it for enterprise development.
Because CPU cycles are cheap and bugs are not.
>Dev costs are relatively small compared to operating costs.
It really just depends on the project. Sometimes, all you want to do is, like, take data, type-check it, maybe do a couple of simple transforms, and then store it. But you want to do it 50,000 times per second.
In that case, it may very well be the case that ops costs absolutely dwarf dev costs.
Similarly, it may be that what you want is to take data and run it through super-complicated algorithms depending on a lot of business data, and massage it all over the place... but you only need to do this 10 times per second. In which case your dev costs may absolutely dwarf your ops costs.
Python being really fast to code means that the biggest optimizations (those that'll give you a million times or more increment in performance) are fast and cheap to implement. If after that performance is still that relevant, you can always replace parts of the code, with the biggest optimizations already in... And replacing code that already solves a problem tends to be much safer than solving it in "development time intensive" languages.
C++ does have its place (I'm not convinced about Java), but starting with it some project you could make as well with Python just because of performance isn't a good policy.
On my latest project, I've spent about 5k in operating costs, and about 100k in dev costs, and that is just one example. I really don't know where you're coming from when you say dev costs are relatively small compared to operating costs...
In much enterprise development (indeed much of development in general) development time is much more important than CPU time. Not just because of price, but also in reaction time to new and changing requirements.
But when I see benchmarks that suggest Python is 10 to 100X slower for critical server code, I have to wonder why anyone would use it for enterprise development.
Because not all enterprise development relates to critical server code?
Neither language is pretty or fun or interesting from a CS point of view.
I find working with c++ brings huge amounts of fun, and I do that almost daily :P But maybe I don't have a CS view (not sure what that is supposed to be?)
I'm not worried about Python's type system. At worst it's manageable, at best it's expressive for prototyping.
But when I see benchmarks that suggest Python is 10 to 100X slower for critical server code, I have to wonder why anyone would use it for enterprise development.
Which is why there are so many Java and C++ code jockeys working in enterprise. Neither language is pretty or fun or interesting from a CS point of view. But there's no arguing both consistently run faster than anything this side of assembler.
I would have expected critical industrial infrastructure code to pay some attention to that - because speed isn't an abstraction. When you're running giant data centres, extra cycles consistently cost real money.
Dev costs are relatively small compared to operating costs. So it's well worth spending extra time getting good, fast compiled code working.