Isn't Java the choice for things that aren't performance critical but are too complicated to write in C?

Java survives because thats actually most things.

If you're writing complex code java is rarely the answer as it requires so much complexity itself.

Hint: Most java projects just appear to be complex because of the poor quality of the language (and developers).

Java is hands down the choice for simple projects written by way too many poor quality developers. The JVM can barely manage 12 GB of memory, Java is a piece of crap when it comes to anything that's actually complex.

Saying that developers who use Java are poor quality is also an awful thing to say. Yes, there are many "poor" Java developers. But, it's only because there are so many Java developers in the first place. So, of course when you take even a small percentage of such a large number there will still be a large enough sample to look significant. It's the same for all other languages.

Java has been my primary language for the last 14 years. During that time I have worked with countless individuals who I would regard as some of the smartest and most competent programmers (who develop using Java) I have known or heard of. These people make your banks, file sharing sites, massive online market places, electronic billing etc. work. So, go ahead and bash all the developers from Google, Sun, SpringSource, Apache Contributors, Oracle and the other 10,000+ companies out there, but empirical evidence has shown that the language and platform work.

Your statement is just so "trollish"... seriously?

Edit: capitalized Internet. Letting the run-on sentences and bad grammar fly.

You can't have a medium to large Java thread on this site without a lot of people deriding Java developers. It's practically a law of nature.

I never said there isn't a lot of java code, or that it doesn't work, my assertion is that java is not the hands down choice for high complexity / performance work.

If you've got a bunch of mediocre programmers who can't be trusted to make + add things together then sure java is a great choice.

That means that days or weeks spent hunting your latest memory corruption issue makes C a non-option for these applications.

As for mediocre programmers - sure, and a large bunch of mediocre programmers scales, whereas a small team of star programmers doesn't. Someone has to tweak the UI. Someone has to implement all that tedious persistence logic. You need star programmers for that? No.

I'm excited to see if Go intrudes on this field, but it's a big field and Go's just starting out.

Quite a bit of that programming practice did develop in C++, but Java as a language provides stronger safety guarantees than C++ (lots of memory-related errors are difficult to impossible to have in Java) without sacrificing all that much performance. When you ask for a reasonably performant, statically-typed, memory-safe, object-oriented language, you're going to get pointed at Java (and C#). So that's what people use in that domain.

Here's the 12 GB of memory...

http://www.datastax.com/docs/1.0/operations/tuning

As far as the language is concerned...

What problem of high performance & complexity apps does Java 7 solve that C++11 doesn't?

"Just use Boost" is not a viable strategy when it adds so much complexity in and of itself.

I'm not defending Java, but it's helpful to know what the limits of each tool are.

I strongly disagree that Boost really adds "so much complexity"--and, by the way, shared_ptr and friends are in C++11, and by extension within the standard library. So you don't even need this, unless your goal is to target extremely old platforms. But honestly, if you seriously need shared_ptr, your code design is probably just Not Very Good.

The LMAX Disruptor pattern would like to have a word with you.

http://lmax-exchange.github.io/disruptor/

http://martinfowler.com/articles/lmax.html

http://stackoverflow.com/questions/6559308/how-does-lmaxs-di...

I'm not just namechecking the Disruptor pattern. I have extensive experience with it. It's about 10% slower than what could be achieved with C -- which is to say, the benefits of not having to program in C far outweigh the 10% loss of performance. And its performance is almost always far higher than what's needed, i.e. the bottlenecks are elsewhere.

I strongly disagree that Boost really adds "so much complexity"

We'll have to agree to disagree, I think. Importing Boost is often a sign that something is awry with the design goals of the project. Either the choice of language is wrong, or the project is too ambitious. Though there are some aspects of Boost that are pretty good, such as its unit testing framework.

if you seriously need shared_ptr, your code design is probably just Not Very Good.

This I fully agree with.

What does that even mean?

Are you saying that you have a proof of the theoretically fastest C program that would implement the same functionality and it's 10% slower than that? Does the C you're comparing it against use the Disruptor pattern too? Or is this just a comparison against a naive, single-threaded C program? How does that number vary with the overall heap size of the program?

Numbers like this get thrown around that strike me as incredibly dubious.

If you're comparing the JVM's GCed heap with some specific, user-managed allocation scheme, then know that the latter can be done (and is often done) in Java too.

Modern machines have, I don't know, say, 64GB RAM? How much of that can you use for thread stacks? 1GB tops? Modern applications work with really big heaps. Stack allocation is irrelevant for most of what the application is doing.

> Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.

Yeah, it seems that way, but it turns out that it isn't. Previous attempts to allocate Java objects on the stack showed little or no improvements.

A heap allocation in Java is a pointer bump, and deallocation of a short-lived object is free (Well, this is not quite true, because many allocations will trigger a young-generation collection which, in the JDK's GCs – though not in some commercial ones – takes linear time in the size of surviving objects)

> You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.

You have the same option in Java, too, and it's pretty much the same amount of work.

Well I disagree with that. In C++ it is quite common for most objects to be allocated on the stack. I have never heard stack allocation being described as irrelevant. Of course if the language puts everything on the heap then that statement might be true.

Most objects? You have 64GB of RAM! You want to tell me that you can take advantage of all that RAM with thread stacks? You're unlikely to even use 4GB of stack.

If you don't, then you're talking about a small application.

Hunting for memory leaks and pointers gone berserk will become someone's full time job.

I like C++, but don't miss using it in enterprise projects.

Java does have some unfortunate complexity, but I don't think it is in the same league.

Java also includes a library that is more extensive in some areas than the vanilla standard C++ one.

The JVM is also more robust to some types of programmer errors than any run time for C++ that I know of.

Most of what the code does is hidden behind ceremony.

Imagine Newtown writing out instructions on how to calculate gravity instead of just writing: F = G((m1 m2)/(r^2))

I really don't understand how a language that can't succinctly express calculus from 300 years ago would be regarded as suitable for complex code.

Most Java programmers don't care about expressing calculus. They care about expressing interactions between web services, sql, and applying rules as the data flows through their modules. Or between user interface elements and service requests. It's all about moving data around, working on that data when you've got it, and triggering actions.

As you point out when you have a reasonably complicated problem like applying functions java fails miserably and other languages are a much better choice.

So server-side Java lives in a niche and I would never suggest it for, say, anything client-side or basic web apps.

The runtimes aren't that much slower, and for I/O bound tasks, odds are Node is going to run just as fast with less application complexity.

No, in the real world, it's exactly the opposite. Nobody cares about writing a function because generally that's the simple part. Do it however you want. Deploying the system to take inputs and feed outputs, now that's the hard part. Where do those inputs come from? In what form? Are there security requirements to gather or push data? Do you store-and-forward or don't you? What protocol? Stateful or not stateful? Transactional or not transactional? The problems involved in "move these bits in this format on this machine to those bits in that form on that machine over there" are in fact so complex that you can't even prove it to be an NP-complete problem because the problem itself transcends algorithmic analysis. It is much more a social problem than a technical problem, but the social problem is so massive that any simple-minded technical approach will fail to address the scope of the issue and in every case I've ever seen, simply makes the problem worse.

Hell, Scala is one INSANELY complicated language. It's got about every feature under the sun. Java is simple and to the point...unless you really want to use spring or something of the sort.

Anyway, you've got a really contorted view of Java, and you are conflating some fundamental things.

And its not about complexity or features in a tool, its about how those features interplay with the base design of the tool.

Virtually all serious software that uses complex concurrent data structures is written in Java nowadays, because the JDK is pretty much the only runtime that supports state-of-the-art, envelope-pushing, concurrency.

Here's my previous discussion with haberman on the subject: https://news.ycombinator.com/item?id=6505853

Though if you were only affirming that it isn't a language construct you are correct.

Define complex?