Java is platform independent (dependend on JVM) its as fast as you can write (you can embed assembly native link for atomic operations) its is robust if you build it robust.

I know from ADA,Ruby,Perl,COBOL,C/C++/C#,Java,Objective C so from my work experiences Java MAKES YOU WRITE GOOD CODE IN FIRST PLACE so you will build good architecture from bottom-up. C/C++ makes you use external libraries and rewrite your code for specific platform (chipset) so its more time and work expensive.

I would highly recommend everyone who is hating on Java or C/C++ to try to write really good and clean code in both and then decide objectively which is better.

And don’t try to use argument that “C++ has pointers and destructors and phantom references and transient/volatile attributes etc.” because Java have them too, you just were too lazy to notice.

Sure you can write shitty code like a pig import every JDK1.1 library from 90′s and leave all the optimalisation on Java Heap, but then please don’t be angry on Java but be angry to yourself because you are shitty coder and you didn’t try.

I have written ARM chipset protocols for bank CISCO routers on top of Java and I would NEVER DO THAT IN C/C++ because of fixed bus and unsigned short hack. That is the magic of JVM –> You are working with virtual instances and even when something goes wrong you can rely of multithreading and soft-reset single instance not whole application.

Thats just some words to defend Java and C/C++ …. its not about language itself, its about fucking habits of coders who were raised/trained on that language.

And I admit sometime when I see someones code I just want tu punch them for irresponsibility.

I know that there are a lot of people who are reading this post would simply like for C++ to die. I am going to explain why those people feel that way, IMO, after pointing out a few mundane facts about C++.

1. In C++, the Standard Library is technically not part of the language, whereas in languages like JAVA, the library is inseparable from the language. IMO, this is the biggest “drawback” in C++. I feel that the people who made STL were not given sufficient time to “find the classes” in C++. In fact, there are highly-useful container classes that I use every day that simply do not exist in STL. At the very least, the set of primitives should have been made complete. Again, I do not think this is the fault of the creators of STL. It takes time to have enough insight and perspective to “find the classes”. Even more, once those classes are found, one needs a huge amount of self-restraint to not get carried away with fantastic notion – I am talking about the separation of algorithms and objects here.

2. Languages like JAVA/C#/Python/etc. are not really portable. Supporters of these non-C/C++ languages hijacked the interpretation of “portable” (no pun intended). By definition, and by precedent, portability meant that a language could be compiled and executed for pretty much any machine: past, present, and future. This is not true for the non C/C++ languages. Those languages often only run on one machine – the virtual machine in which they execute. Ironically, those virtual machines are often written in a truly-portable language, like C or C++. There are machines from the 1970′s that will run C/C++, but will not run Java. There are machines that will exist after 2020 that will run C++, but not Ruby.

4. C++ is not “just another programming language”. It is impossible to be an excellent C++ programmer without being a good software engineer. And it is impossible to be an excellent software engineer without understanding computer architecture. Therefore, claiming to be an expert in C++ implies good knowledge of computer architecture. Claiming to be an expert in, say, Ruby, implies no such thing. Evidence of this fact can be seen in recent software-engineering job postings. The recruiter will often write: “Wanted C++/Ruby/Perl/Python programmer.” What is happening here is that the hiring manager actually wants a Ruby or Perl or Python programmer (since the company actually never uses), but they add “C++”, because they know the value of someone who has deep understanding of computer engineering, and that they are more likely to get a candidate with that skill ~if~ the candidate has deep understanding of C++.

5. In any field of engineering, there are primitives that the engineer must use to build a system. For example, a 15-meter-tall robot will be built of large primitives like steel tubes; medium-sized primitives like hoses, gears, and clamps; and small primitives like resistors, capacitors, and digital accelerometers. A tenet of good engineering is that the toolbox of primitives be (a) complete (b) well-distributed. The second part (b) is particularly important. It means that, if part of your robot needs a 50kg pneumatic tube, so be it: If another part requires a photo-transistor that is the size of a pea, then you have that also. The entire panorama of primitives is optimal when the engineer is able to go “maximally macro” and “minimally micro” and also everything in between. That is a power of C++. C++ allows the engineer to go maximally-macro with data structures that might be over 100MB each and yet still be assigned and copied as if they were scalars. It allows the engineer to go minimally-micro by fiddling with the bits of a memory-mapped I/O register on 8-core CPU that requires software bus-mastering. And it allows hitting every necessity in between. Not even C allows generalized programmer-defined assignment of data structures.

What do all these facts mean? Power. The power of C++ is unprecedented. It allows a single engineer to create massive applications alone. It allows reachability to the entire system space of computer programming. There is no limit to what can be achieved. Worst-case scenario where C++ is so foreign to the task at hand is that a run-time interpreter can be hosted by a program written in C++. The opposite is not true. Ruby cannot be made to fiddle with DMA registers without help from C++-like code. In some ways,This frightens and/or irritates some people. Many people would rather we all be “more or less in the same boat” when it comes to what can be achieved with our toolboxes. They would rather we all face the same limitations, so as to level the playing field. You can always identify such people easily – they are the ones that want C++ to die, the use of it affects them or not. They would also prefer that, if there is a way to do something, like send a file over the Internet using HTTP, that it be done in a uniform, consistent manager, where everyone does it the same way, even if that way is sub-optimal. In other words, they prefer that the library of the language be part of the language proper. And finally, let’s face it: different brains are wired differently. If I had to play “Mary Had A Little Lamb” on a guitar, at the risk of death, I’d be dead. I have no artistic ability whatsoever, and I am OK with that. This is probably the biggest reason of all. There is a certain uneasiness that comes from knowing your neighbor has mental faculties that allows him to do something that you cannot, something that is currently highly regarded and highly rewarded.

For any given feature, what is the easiest way to specify it so that the compiler writers don’t have to do too much work.

Now C is much more usable than C++ only because it has so many fewer features.

In both languages you can very easily reason about the generated assembly for non-optimizing compilers, but C++ has many features that are painfully slow without more advanced optimizations, whereas the same is not true about C (though the scope of allowed optimizations are one place where people get tripped up with C).