Care to elaborate?
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?
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.
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.
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.
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.