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.
I would venture to say, with no facts or figures mind you, that if you were to evaluate the number of lines of code dedicated to kernel programming to that of applications running applications on the Internet, that the resultant figure would be so small for kernel code that it would look like kernel development doesn't even exist.
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.
What about java makes it better for high performance / complexity code?
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.
It's a natural fit for enterprise programming where time to implement is usually key and logic is endlessly extended to accommodate whatever new business requirements emerge after the last round was deployed. And robustness is valued more highly than raw performance. Use Java - pay for twice the servers and get ten times the uptime? Done.
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.
In the kind of situation GP describes, what matters is probably the well-established practices for extending the behavior of an already-built system without breaking what's already there. A lot of Java practice has built up around having behavior determined dynamically (OOP is a nice fit for that, whereas C does not have great facilities for it). Much of the "ceremony" involved in using the big, complex Java frameworks is about preparing a piece of code for eventual extension. When some behavior is hard-coded in, it's difficult to change later, so the code is parameterized over anything and everything that might eventually change. Of course this looks silly when you do it for small things that won't change -- no need for FizzStrategy and BuzzStrategy interfaces when the only thing you'd ever want to do is print "fizz" or "buzz".
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.
Oh please, Workday uses a JVM managing 160GB. Lucene/Solr are not simple projects, by any yardstick, for example. I do agree Java the language is somewhat cumbersome, but saying that its a piece of crap for anything thats complex is naive
It solves the problem of using mediocre developers to get code into production. Clunky, slow and overly complicated is infinitely better than a segfault.
Automatic memory management (especially with a garbage collector) is antithetical to high performance. I like the JVM (for Scala, mostly; Java-the-language can go screw), but there is nothing there really remotely close to C++ and C, and the garbage collector is a very large part of why.. Rust might horn in on C++'s bailiwick, but until then, it's gonna be a while.
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.
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.
> It's about 10% slower than what could be achieved with C
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.
Good luck doing manual memory management in whatever language (C, Pascal, C++, ...) with distributed teams, using developers of disparate skill levels.
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.
Sigh. This again? A good garbage collector will always reach a higher throughput than "manual" dynamic allocation/deallocation in C/C++. Pauses are a different matter, and can impact latency; in cases where latency is crucial, Java programs either resort to manual memory management or use a commercial low-latency GC.
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.
C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction. Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.
You shouldn't really use the term "always" either. You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
> C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction.
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.
> Stack allocation is irrelevant for most of what the application is doing.
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.
> In C++ it is quite common for most objects to be allocated on the stack.
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.
Languages like Matlab are best suited for expressing calculus. Why are you choosing a poor tool for the job?
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.
The problems of pushing bits from one server to another aren't that complicated and the pomp and circumstance of java gets in the way of actually accomplishing those things.
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.
No offence, but it's clear you have no idea about the domains in which server-side Java is typically used. Very large enterprises have all kinds of weirdness and the Java ecosystem has a bunch of libraries found in no other language ecosystem that make things manageable. Java-the-language is sadly verbose and tedious but that's not why people choose it.
So server-side Java lives in a niche and I would never suggest it for, say, anything client-side or basic web apps.
I'd say that NodeJS or Ruby would be decent alternatives depending on your need. npm and gem are really nice in this space and cover just about any need you might have without weighing your system down in pomp and circumstance.
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.
Actually, part of the problem is the academic experience of believing that applying functions is hard and pushing bits is simple. It deceives delusional academics like yourself into believing it's just a matter of doing the work and not really a real computation problem at all.
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.
The "ceremony" you're talking about has nothing to do with the language itself and everything to do with the community. You can write Java and not use the factory pattern, you know.
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.
Community is a big part of the language. Else we would be writing in our self invented languages. You can write Java like anything you want, but that will make you an alien in a big world. Code reviewers won't accept your code for being the odd-one-out.
And its not about complexity or features in a tool, its about how those features interplay with the base design of the tool.
You seriously don't know what you're talking about.
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.
Erlang is awesome, but only offers high-level concurrency constructs (actually, just a couple), it does not support low level ones (CAS). You can't write, say, a good concurrent hash-map in Erlang. Or in Haskell, for that matter.
I'd like to see any language withstand the combination of big project, lots of managers, mixed levels of experience and expertise on the team, and over-reliance on structure and methodology versus having the right people. It just happens that Java gets picked for those kinds of projects.
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.