C++ only sucks for programmers *cough* code_monkey/scripters and people who are too lazy or get easily sidetracked by all of its power, excess of feature. C++ is about giving the programmer as much ability as possible without writing too much architecture specific code. AI is done in c++/lisp Embedded Systems are done in C/C++. NASA writes things in C/C++.
Linus Torvalds was a python programmer from my understanding, according to wikipedia. In short people like simpler languages because they allow them to get straight to the point without getting caught of into the features. I watched a lecture on youtube that explained the paradox of too much choice. Having an abundance of choice was deemed a bit paralyzing according to the lecturer. Having said choice more often leads to a better outcome but less happiness due to the loss of the resources, usually time and or money. The reason people use scripting languages is because are not necessarily that they are easier to use or to learn but its that they are faster to learn ALL of. If you add the fact that C++ is a super set of C (almost every feature of C is in C++) and you add people who have little time and or patience then have calamity.
The reason why OOP/scripting languages were invented was to more easily utilize the tools written in C and Assembly by simplifying or abstracting them. Python Java and C++ all come with precompiled/linked libraries written in native object code produced by an assembly language (more tedious to write). Python is implemented in pure C which is then converted into assembly code.
If you really need to use Java for the bulk of your project then there are ways to tie your native code into it. (read: JNA and JNI)
I feel the need to insert another disclaimer here.
To anyone thinking about using JNA / JNI:
The native interfaces are a very often a royal pain to maintain (must maintain builds for all platforms and all flavors of the JVMs that run on each platform - that means at least X builds for each supported platform which must be either distributed correctly or otherwise provided correctly if your distribution is a web applet. Please only use it as a last resort (IE deadline is tomorrow and your ass is on the line). Granted there are rare valid uses for it, but most often it's a big mistake. (Think of what would happen if the user updates their JVM from 32 to 64 bit!)
Though, realistically, I doubt at 31 years old I could learn that many languages.
I hope you're wrong there, I didn't even start learning C++ until I was 32. I'm 36 now and have done some C# and java though I wouldn't consider myself proficient in either. I do plan to learn them better and pick up a few more, in particular python. So if a 31 year old can't do it, I guess I'm screwed.
Why JNI/JNA? You can do it in pure Java. There are at least two ways to do manual memory management without GC in Java:
1. mmapped I/O
Besides that, GC is cheaper than general-purpose new/delete. It provides faster allocation and zero-cost deallocation for most of the objects - which is close in performance to a dedicated hand-tuned memory allocation in C++, implemented using placement new. That's why wide string manipulation in Java is faster than C++ std::wstring (which does quite a lot of allocations internally - whenever you copy / splt / append strings, etc.).
The native interfaces are a very often a royal pain to maintain
True, but this is not because of the interface, but because of the fact that native code is native. The exactly same restrictions apply to any C/C++ produced binary program or library.
Under the hood it's still achieved using native code. Using terms like "pure java" is very misleading... I am curious though, as to how this memory is deallocated...my guess would be phantom reference queues...but now I'm looking it up in the JDK source. * Looks like it's achieved by the sun.misc.Unsafe and sun.misc.Cleaner that are used in a private runnable class in DirectByteBuffer. Sun.misc.Cleaner extends PhantomReference, so I'm assuming that my guess was correct.
True, but this is not because of the interface, but because of the fact that native code is native
It's mostly because of the fact that you cannot control which JVM the client uses after they install your application. Setting up a build chain for the different systems is pretty easy to do, but keeping the user from breaking the application is borderline impossible. An entirely native distribution doesn't suffer from this problem, as it will continue to run so long as the user doesn't muck around with the installation. That's why I blame the nightmare on the interface itself, as something as simple as a VM update can break applications that use JNA / JNI.
Under the hood it's still achieved using native code
Right, but it is portable and you don't have to deliver any extra so/dll.
An entirely native distribution doesn't suffer from this problem, as it will continue to run so long as the user doesn't muck around with the installation.
Unless you link everything statically, there may be thousands of reasons native application breaks on the client system. E.g. wrong versions of / lacking / broken libraries or different kernel version, etc. As for JVM incompatibilities, I haven't seen any JVM that would use a different JNI API than the reference Oracle VM. So the only thing you have to assure is compiling your native library for the target OS.
So the only thing you have to assure is compiling your native library for the target OS.
...are you forgetting that 32 bit libraries do not work with 64 bit virtual machines? I can only speculate that there are other varying factors that will also break outside of the native code such as using a non-oracle JVM.
It seems quite brain-dead to me that 64 bit VMs aren't compatible with 32 bit libraries. Perhaps the designers just cobbled something up like they did with type erasure designed it that way on purpose.
Generally a 32 bit program can run fine on a 64 bit OS, as long as the system provides full set of required 32-bit libraries. On Windows that may be true, but on Linux it is not always the case. E.g. neither Firefox nor Chrome work seamlessly in 32-bits on Ubuntu.
JNA / JNI in a perfectly valid solution, but only for those who know what they are doing.