> And what can be used instead of C++?
For most use cases Java is a better option. Very fast, without any of the pain.
If you truly must not have a VM (rare), there's still C. Perhaps rust.
For most use cases Java is a better option. Very fast, without any of the pain.
If you truly must not have a VM (rare), there's still C. Perhaps rust.
Java doesn't force OOP in any meaningful way. I mean it does, in that you need to wrap all code in a class, but that's a non-issue (one line of code at the top and a closing bracket). You can write Java code where all functions are static and do nothing is object-oriented, when that's the best match for your needs.
On verbosity, you can latch on to the ConstructorAccessorMapFieldGetterFactorySingleton nonsense if you want but that's on you. Nothing in the Java language forces that on anyone. Having been writing Java code since 1996 I've never written such code.
My rule is that languages are good if they have value types, which explains why PHP is good.
Those are quite different domains, with only minimal overlap.
Embedded systems more often that not are not seeking maximum performance. What matters is smaller code size and running on mimimal hardware. Java doesn't do so well there since you have the overhead of the VM. Java is rarely a sensible choice for embedded code. Just use simple C, or rust if it works for the use case.
(Yes I know project green was originally about embedded set-top boxes! But times changed.)
Performance critical systems are usually large servers for either high througput (web or other server traffic) or low latency (HFT) applications. The opposite end of the spectrum from embedded. That's where Java shines. You might be able to beat Java with carefully hand-tuned C++ but just as likely the JIT might beat you. So for maximum performance server code combined with a more sane developer productivity, Java cannot be beat.