[tsmarsh]

Java is slow compared to C/C++ and Fortran and comparable with SBCL / Rust. But it is fast compared to Python, JavaScript, PHP and Ruby.

It's the rise of these languages that confuses me.

They somehow got away with the 'fast enough' argument whilst Java is constantly being compared to languages that are designed for fine tuning for the target architecture.

In my mind it is Java that is 'fast enough' and,with Java 8, very expressive. The continued success of these incredibly slow interpreted languages in enterprises where you need to buy servers feels like an anti-pattern.

[mjw1007]

From my perspective, choosing Python over Java (on Linux) around 2001:

It was easy to find benchmarks showing that Java was fast. But Java turned out to be slower in every situation we might consider using it.

Command-line applications were slower because the JVM took ages to start.

GUI applications were slower, apparently because Python would use C-implemented widgets while Java would do much of the drawing itself.

Web applications were slower without any good excuse as far as I could see, but something in the application server that was the mainstream way of doing things added more per-request overhead than starting a whole new Python interpreter via CGI.

CPU-intensive operations (I remember image resizing in particular) were slower because, again, you ended up comparing the JVM against a well-written C extension.

[jacques_chester]

I would say that of these, most are still true-ish, except web apps and some CPU-intensive cases. Where you have a long-running service, Java shines.

Java marketing was a disaster. Remember when it was going to be the replacement for browsers? It was not a great way to engender goodwill.

[jghn]

I think that the part this is missing is that when comparing Java to Python/Ruby part of the argument for the latter is the dynamic language aspect. To the folks making these statements, Java is seen as involving all the headaches of those faster languages but none of the advantages whereas Python/Ruby have slower runtimes but come with potentially faster development time, etc. I personally don't like this comparison but it's how I see it made typically.

Random anecdote which led me to stop calling Java slow: I'll never forget the time I took a 3000ish line Python program which had been heavily performance tuned and thus completely impenetrable. I converted it to a dumbest-scheme-possible naive implementation in Java weighing in at roughly 100 lines , expecting that to be a first pass. It turned out that the Java implementation was many times faster so we called it good enough and moved on with life. Obviously YMMV and all of that

[fractalb]

3000 lines of Python to 100 lines of Java? 30 times smaller program! I thought Python was more expressive than Java.

[jghn]

It was due to the “highly tuned” vs “dumbest thing possible” difference

[fh973]

Do multi-threaded workloads, which a lot of high performance workloads are, Java has also the potential to be faster than C++ due to garbage collection and threading aware optimizations it can make. Memory allocation, especially when memory lifecycle spans threads can be expensive in C++.

"A JVM does that???" by Cliff Click is a good introduction on what can go in the background.

[jackmott]

so write a specialized GC for the task in C or C++.

C++ can always win!

JVM has hotspot? use profile guided optmization in C!

There is no escape!

[sgift]

If you are one of the three people in the world that can do it. ;-)

[fauigerzigerk]

Just use an arena allocator (or similar) where appropriate. It's not difficult and it's how C, C++ and Rust win all micro benchmarks that involve memory allocation: http://benchmarksgame.alioth.debian.org/u64q/binarytrees.htm...

[aw3c2]

I just looked at the list for where my beloved cherrypy might sit. It is almost at the bottom. But that does not matter because writing webapps with it is easy and fun.

[tsmarsh]

As I see it, most sites don't need the hardware they're allocated. If you want to sleep on the weekend, you need at least two and probably three servers. That is almost certainly in the realms of 10x what most applications actually need. So a language that is 10x slower than C isn't a big deal.

CherryPy fits nicely into this window of opportunity, but as soon as you have to go back to your boss and say "I think we need a bigger boat" someone should be asking questions about library and language choices, at the very least there should be a conversation about prototypes vs production architectures.

Similarly, Python and the dynamic languages are 'fast enough' because in the 90s the bottleneck was IO, not CPU. That is still true, but is becoming less true. SSDs rapidly closed that gap, and it looks like memristor storage could mean that non-volatile RAM is as large as SSD and as fast as DRAM is today.

The dynamic language decision to focus on single threaded performance is also smart, but that will stop being true when CPU have hundreds of cores, instead of 10s. Synchronized access to cache is 100x slower than regular access. So to see benefit for work loads other than the "embarrassingly parallel" with multi-core you need around 100 threads. The new competition in the CPU market might see the first 100 core die on the market in 5 years.

The trend towards 'serverless' could be even worse for dynamic/interpreted languages. Smaller slices of billing will show that the same service written in Java vs Python cost 5-10x less. That was harder to show when you had to pay for at least two servers for every deployed service, now it will be very clear to CFOs how much language choice affects their bottom line.

What this means is that the perceived difference in performance between Java and Python can only grow over the next 5-10 years. If Java continues to gross you out, I'd be looking to pad your resume with something like Clojure / Go / Rust. High productivity, high performance languages are here and their relevance is growing.