Another reason I failed to mention that Java is in decline is that the geek / utility-driven folks at Sun had essentially said "Java is a mature language now" and were focusing on other languages for the platform. Then the sales and marketing people at Oracle got involved and realized that was not the best way to bilk their existing customers.

Groovy - slower, much worse toolability

Scala - less readable, slower, slow compilation, worse toolability, too complex.

People keep repeating this as it was some sort of axiom. My feeling is that people mean that it's hard to write large Java-like projects outside Java. It's not the the problems can't be solved without Java, it's that you "can't" solve them the Java-way without using Java or C#.

"You want to switch out the horse? How are you going to get around? Show me something that has at least four legs, can run as fast, eats less and has more stamina!"

The car or the plane looses this comparison.

Point is that all that "stuff" Java programmers are used to might be missing in other languages & ecosystems. And that might be a real issue. But some of that stuff only exists in Java-land to fix issues with Java, and the fact that it's not needed is actually a feature.

I'm sure someone, somewhere, complained that the first cars didn't have feces collection system =)

This is a widely repeated myth. Static typing does enable a few additional autocomplete capabilities, but most of the other things you probably think of as fancy IDE features are completely possible for dynamic languages.

For example, using Common Lisp with emacs and SLIME, I have:

Function/method name completion, Variable name completion, Jump to definition, Show callers, Rename (heuristic, but usually better than static analysis), Extract method, All sorts of interactive debugging capabilities, Documentation lookup, and Numerous compile-time static analysis checks including type errors!

can is probably an overreach, but I expect the author was referring to the wide range of projects like Hadoop, Solr, etc.

If you want static typing, decent performance (and especially if you want a wide range of people who can work on your software) then you have C++/C# or Java. Or you are feeling adventurous or are ex-Google then maybe Golang.

There are other languages of course, but for most you are going to be struggling to find programmers who know them and library support isn't there, so you are writing lost of stuff yourself. If that's what you like, then fine.

If you don't want static typing, then there's a much broader range of course.

Or some kind of godawful tiered corporate thing that's big and unwieldy precisely because it's implemented in java?

Believe me, godawful corporate things are unwieldy in whatever language they are written in.

Have you ever seen a corporate Rails app? The saying "it compiles so it must work" is supposed to be a joke, but I've seen Rails apps where a large amount of the app would never have compiled if Ruby had a compile step. But then they did claim that Rails was an improvement because they could develop faster with out the compile cycle. Most of the app didn't work, but yes.. I concede that not having to make sure it worked did let them get in on servers faster.

Scary but true.

No question this is generally true. But note that it's no worse for government than the private sector. The thing that bugs me is that government seems to take the worst aspects of the private sector (e.g. secrecy). If we've built a fabulous claims processing engine, why not give it away to other government departments?

Photoshop - Needs C-like performance for image processing parts. If they started development today, I think they would go with a C# / C++ hybrid.

Facebook - The fact that they had to write their own PHP compiler is telling. PHP is nowdays quite similar to Java without the tooling, performance and massive ecosystem.

I absolutely, completely don't understand where is this coming from. There are so many languages that there has to be a choice.

It of course depends on a given project, but I'd think that it's bigger projects which are more flexible in choosing the technology. I mean, if you have heaps of cash and many developers, than having to write three or ten additional libraries shouldn't matter. And then suddenly OCaml and Haskell are starting to look nice. Ask Jane Street.

In the projects I was involved in we had different set of constraints - we needed to ship something quickly, with small team and limited financial support. In such case how much more performant the Java would be, how much better tooling it has and so on was irrelevant and sheer speed of development in Python, Ruby or Racket was a win.

I get a feeling that this sentiment that "there is no alternative" for Java comes from people who are being forced to use Java at work (even for things it's not suited for) and who want to console themselves. It's something like "ok, I use Java as a templating language, but that's how it has to be". Well, I think it's not.

On the other hand, if you know what you want is Java - go for it. It's always the same old "best tool for the job". Just don't artificially narrow the choice of tools.

Java is used by a lot of extremely productive programmers and some brilliant apps are written in it.

You are no different from them, you were just born a few decades later (same for me). Except, you can look back and learn from their experiences, if you are wise.

The more you digg into the languages, the more you see, that Java rules them all... I've tried MANY, MANY languages (from assembler, Basic, Pascal, C, C++, Smalltalk, C#, Python, Ruby/Rails, Groovy, PHP, Perl, awful JavaScript which shouldn't be called a language at all, because it has bugs built in it and many others) and nobody is forcing me to use Java, but I program my Rasberry Pi-s only in Java...

With latest Rasbperian Wheezy where Oracle JDK is included I can tell you it is super cool and super fast for this small ARM processor... I will not use Python on it... Either Java or C - nothing else do I need...

ill be coding with libgdx and pushing to html5 and android while the thought leaders decide their next move.

Java is so big today because at one point for all the marketing money by Sun and C++ incompetence among programmers, it had a field day. I remember an architect who made Java compulsory in a program because as he was tired of C++, he just couldn't get it and neither any of his team members.

Today Java is, what C++ was at its times. Its showing age, and merely adding features and bloating won't fix it. There is tons of Java around, just like there was tons of C++. So people will be using Java for a while. But the creamy projects will be moving on to newer languages and there won't be growth or progress in Java world anymore. And sooner or later people will realize they don't want to associated with tools on their resume, only to be hired as 'migration engineers'.

Before that happens, its better to move on to something better.

"Thought leaders" are hopefully just using the best language suited for the job. It often comes down to what kind of code you are writing and what it needs to run on.

Or are you just being snobbish about javascript? It's a pretty solid language, and has interpreters installed on virtually every computer on earth with built-in distribution.

>It has built-in interpreters (read "Browsers") on every computer.

JS is pretty slow (It uses an interpreter!). The notion of using it on the backend is debatable. "A lot of people are putting a lot of effort in to it" isn't a valid argument. u said it yourself: "people are told to/forced to use it"

As for the hardware thing, didn't you read the HN discussion about that? no body thinks that's a good idea. It just a way to let web devs do something on the hardware without bothering to learn an actual low level language.

It is pretty fast. It has a world class VM with an optimising JIT compiler. V8 is considerably faster than many other interpreted language, Ruby, Python etc. It's being used on the backend by many smart companies.

>> As for the hardware thing [...] It just a way to let web devs do something on the hardware without bothering to learn an actual low level language.

I know C. I use it when necessary but I'd rather write JS. Apparently so would plenty of other people. It's not about laziness.

"has interpreters installed on virtually every computer on earth with built-in distribution" - which means we are stuck with it, thanks very much for "open" web.

http://www.ohloh.net/languages/compare?l0=java&l1=javascript...

Although it looks like Ruby isn't growing as quickly as JavaScript and Python.

It will be interesting to see if perceptions change after JavaScript and Python overtake Java.

I miss thought leaders using French, or Latin :-(

- Type inference: strong typing at the convenience of weak typing. (Some languages are moving towards this. C++ stapled on `auto` keywords, Rust is designed using it)

- Type classes: unifying things that "can do X", allowing the programmer to write functions that do similar things but work on many different types. A "sort" function can then be written for all things that "are containers of elements that can be compared". (Again, Rust adopts this.)

- Allowing separation of pure and impure functions. Imagine having a "pure" keyword that guarantees that a function doesn't have side effects. The benefit of this cannot be overstated in a multithreaded environment.

C# also sort of implements type classes. For your example, there's IComparable in C#; implement it and a List<SomeObject> can be directly sorted.

For pure functions, there's the [Pure] attribute, but it isn't enforced by the compiler, it's just a contract, a promise.

This is what templates do in C++.

C++ does not support any processor extensions, they are not defined anywhere in ANSI/ISO C++ language standard.

They are a language extension not guaranteed to be available in all C++ compilers in the same form, thus not portable.

Java can make use of processor extensions by writing a small Assembly snippet callable via JNI.

Which is actually similar to what is required in C and C++ code, when writing "portable" code that should compile in various compilers.

This is true only if you're a language lawyer, but there's very little point to sticking pedantically to a language standard and not take advantage of the ubiqtuitous language extensions available. All the popular compilers out there support all the latest CPU instruction sets with the same syntax, etc. E.g. xmmintrin.h for SSE, avxintrin.h for AVX.

> Java can make use of processor extensions by writing a small Assembly snippet callable via JNI.

While this is true, you destroy any performance gain with the complexity of the JNI calling convention. It only pays off if you're doing a quite long stints of SSE/AVX/NEON code at once. Wrapping a small vector dot product or matrix multiplication in JNI will not yield any performance gain in practice. So while you can call native code via JNI, it's nowhere near as practical as writing it with intrinsics in C code. In addition, you get compiler optimizations to your native code if you use intrinsics from C, if you do it via JNI you lose all interprocedural optimization.

Certainly, and it is one of the features that I am often missing in Java. Rather than having an array of structs, you need to make n parallel arrays, where n is the number of struct fields. And sometimes such hacks are necessary to make things compact and fast.

But I do understand why they don't provide value types. Say, that I am allocating an array of foobar_t. And foobar_t is defined in another library. If the author of the other library changes the layout of foobar_t, you get ABI breakage. This is what brought the whole PIMPL/d-pointer mess that is often necessary in C++ and to some extend C libraries.

http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm... and http://www.slideshare.net/ZeroTurnaround/ryan-sciampaconerun...

http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm...

You use jni to call libraries somebody else made (opengl?), you don't plan your project around using jni.

http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...

There is no contradiction that a compiler written in a language with expensive semantics (say python), could compile a program written in another language (say C) to produce highly efficient machine code.

The JVM operations, such as JIT compilation and garbage collection, are bound by the performance of C code.

The performance of the code you write depends significantly on the quality of the machine code produced by the JIT compiler. This quality of this code is not theoretically dependent on the implementation language of the JIT.

Maybe not a contradiction in logic, no. But in practice the compiler has to solve a problem that is much harder than the problem the programmer would have to solve to write efficient C code for this one case. It's also one that has different complexity.

So you're in the situation now that a few compilers (VERY few, though this is very very hard to do) will actually beat stupid programmers in optimization, but there is nothing any compiler can do to beat the optimizations a good programmer will implement.

As for startup time, the sad part of that is that is one area where you could really improve C/C++ : startup time. Right now a C program has 4 distinct things that need to run before main() starts, and involve quite a bit of calculation, C++ has a lot more (the various kinds of initializers which can cause arbitrarily complex calculation).

A lot of these initializers result in constant (and small) memory layouts, and could in fact be run at compile time. What you generally do in initialization phase is to calculate registered classes (e.g. for serialization, or protocols) and make indexes of them. Maybe even compile regexes. All of that could be optimized to occur at compile time (as long as memory usage of the code is reasonable).

I am not making any kind of sufficiently smart compiler claim (http://c2.com/cgi/wiki?SufficientlySmartCompiler).

You think I am saying that a compiler can do optimization better than a human.

What I assert is that the implementation language of a the tool that generates machine code guarantees nothing about either the source language, or the quality of the generated code. This was the assertion of the parent that invalid. He said that because the Java JIT compiler was written in C, that necessarily implies that the generated machine code would be slower that C.

Consider an Assembler, written in C, that generates machine code. By your logic you can't argue that assembly code is always less efficient than C.

Or alternatively Fortran compilers, written in C, which produce machine code that outperforms code generated from C for many tasks.

It's actually quite easy.

Now, of course for every Java program there exists a C++ program that performs at least as well – proof: the JVM – but that doesn't mean that that program could be written by humans at acceptable cost. The JVM does a lot of optimistic inlining that's simply not possible in C/C++ (in those languages you'll need to write the same code lots of times).

Now compare that C compiler to the jvm compiler, which has the benefit of using detailed information about the exact system configuration and other runtime behaviours during its compilation phases.

Which one has the advantage?

The JVM compiler compiles for the JVM, which is written in C. So, how again can something written in C perform faster than...something written in C?

I'm not claiming that line by line transcription, C will always perform each particular operation faster than Java. But the fact that you could write the entire JVM in C means that you could recreate the exact platform and replicate the results. Is that sane? No, not really.

Comparing languages is typically silly, as it mostly boils down to implementation. If you -really- intend to compare speeds of languages, it would necessitate writing the best possible code in both languages, which may or may not even resemble each other. Under those circumstances, Java is not capable of beating C. Ever.

I don't understand why this is an argument anymore, it doesn't really even make much sense...unless my definition of 'language speed' is unusual.

Because the eventual target is native code, the only limit on performance[2] is what program transformations the compiler is willing to perform. This is limited by how much information the compiler has, and what sort of transformations are valid in the language.

For the first, it's about a wash. Java has a mix of 'safety' features that may obligate inserting checks at runtime that C would assume away, but it also forbids a lot of things that a C compiler would have to accept that limit the ability to optimize programs. In particular, a C compiler has to make a lot of pessimistic assumptions about what all those pointers are doing and what happens to memory across an external function call.

JVMs have a solid advantage in the second -- it performs the equivalent of profile guided optimization at runtime against real usage patterns, something that AFAIK no C compiler even attempts... and the runtime tooling needed to turn C into something you could JIT-optimize would result in something I don't think most C programmers would recognize.

A third issue is GC, which is on by default in Java-land and off by default in C: if your program is under very little memory stress and has very complex memory access patterns, the overhead of malloc()/free() is going to be huge compared to the cost of running the occasional GC. But, if your program is under strong memory stress and the logic to determine when to malloc() and when to free() is trivial, GC overhead will be a serious issue.

None of this means a given Java environment is faster than a given C environment but there's not really anything you could assume from first principles that makes one faster than the other. Neither reaches the ultimate "speed of light" of computation that is self-modifying hand-tuned machine code favored by all Real Programmers[3].

But the real bottom line for performance is which language has faster library implementations, and which has idioms that programmers actually use that produce faster or slower code. Those considerations are probably going to be way more important than the hypothetical top speed of a perfect program made by cycle-counting weenies. It's also the sort of thing you'd have to run actual experiments at large scale to answer.

[1] the JVM might interpret Java bytecode that isn't frequently run based on some optimization heuristic, but it doesn't have to. A 100% JIT emitting JVM could exist, and might even be a JVM flag for all I know.

[2] if you ignore the time JVM spends optimizing at load/JIT time, which you can in most cases aside from startup time.

[3] http://www.catb.org/jargon/html/story-of-mel.html

[4] Despite this extensive apology for Java, I despise it and if I never have to touch it or the JVM ecosystem again it will be too soon.

Well, first of all, the JVM generates machine code, not C.

Apart from that, you can easily be shown to be wrong. If you are compiling a binary with C, you are compiling for the lowest common denominator. Say, if you are compiling for x86_64, you are probably compiling for all x86_64 CPUs. You can optimize for newer instances of x86_64 (say Core i3), but you cannot use any instructions that are not available on e.g. Core 2, if that is the lowest common denominator that you support.

The Java VM could, on the other hand, decide to use instructions during the compilation of hot spots which are available on a Core i3 and not on a Core 2, when it detects that the CPU is a Core i3.

This is absurd.

First of all, there isn't one JVM. There are dozens to chose from, many of them certified. Each implemented in whatever language their designers have chosen.

Some JVMs are meta-circular, meaning they are also written in Java. For example, Squawk, Maxime, Jikes RVM.

Second, even if you mean Oracle's JVM, the embedded version is not the same as the desktop/server one, one uses C the other C++.

Not to mention that after Java 8's release, Hotspot might be replaced by Graal, the new JIT compiler written in Java as well.

Currently being developed and already in use by AMD for their Java/GPGPU work.

Easy. JVM has runtime information it can use that C compiler simply doesn't have. There are some synthetic benchmarks that show how "java is faster than C".

Even that assumes that your program does not significantly shift its behavior mid-execution--in fact, you're optimizing for the average, not the current case.

One of the coolest JIT things is ability to inline virtual calls. Think about that, I could have my code calling a 3rd party library calling another 3rd party library thru 10 levels of stack and if all that call ever returns is "false", then JIT will optimize right through all that.

I don't believe PGO does virtual call inlining. That's a C++ nonstarter. In C, the equivalent would be inlining for function pointer calls.

But in any case, it's perfectly possible that a platform written in C could produce results faster, because it's not an interpreter but a compiler that translates the application directly to machine code, and which could benefit from optimizations not available ahead-of-time.