There have been attempts at AOT compiling Java, but afaict they have very little usage. GCJ, now dead, was the main one for years. There's also a newer experimental compiler jaotc: https://openjdk.java.net/jeps/295.
It's difficult for JS engines to match Java's performance without type information to work with. This is only discovered at runtime and the JIT'ed code for a function requires traps in case it is later called by parameters of a different type.
Outside Android, it has always been available in commercial JDKs since the early 2000's.
GCJ was never the main one, it never went beyond a toy AOT compiler.
Anyone that cared about AOT compiling in Java would be paying big bucks to Excelsior JET, Aicas, Aonix, PTC, IBM, J/Rockit, Gemalto and a couple of smaller players.
Naturally in 20 years quite a few things changed, and now PTC, Aicas, IBM, Gemalto are the survivors, while MaximeVM graduated into GraalVM and there is a free beer layer for everyone not willing to pay for AOT compilers in Java.
But in general, AoT is usually a win, even though it doesn't have access to runtime data. C and Fortran are still the gold standard for performance, for example. One reason is that JITs are time constrained, even in long-running processes. Another is these languages are designed for AoT compilation.
And there are ways for AoT compilation to have some, albeit limited, access to runtime data. One way is 'profile guided optimisation'. Another is inserting probes for different types of CPU.
There are plenty of Java implementations to choose from.
I wish professors would actually spend more than 5 minutes discussing how languages and implementations aren't the same thing.
There are newer languages that are more interesting, but picking one of those is more about either attempting to anticipate where the industry is going, or just plain wanting a more fun language. Rust is an example here. Personally I think rust is worth learning, and has a fair shot at taking over a large chunk of software development that would have previously gone to C or C++. Learning rust might make you a better programmer because lots of poor-programming-hygiene type things are compiler errors in rust.
If you just want a way to wring maximum performance out of a piece of hardware, then I would caution you to consider your choice carefully. Writing high performance code requires a complete understanding of the stack underneath you. If you want to see my point in practice go check out the programming languages shootout. Specifically notice that there are benchmarks implemented in "fast" languages that are outperformed by better optimized code written in "slow" languages.
I would recommend against C++ unless you are planning on devoting a very large amount of time to learning it well. I also don't personally like C++. Too many footguns.
I haven't observed that, at least not where one can't write a "better optimized" code in the "fast" language too. Can you give any specific examples?
1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
So in this case it's less "an algorithm" in the narrow sense and more "is it written to use all CPU cores effectively" and is it using the JIT to run the code compiled to the native. Other languages with good scores are also all that can do a good JIT and use all the CPU cores, which yes, confirms that good JITs are really good.
Which still also doesn't mean that I don't know (or have happened to know) enough incompetent programmers who would, indeed, make even worse performing C++ than any entry that we see in the Benchmarks game. I could write a whole article about all the things they would or could do wrong.
I only wanted to see the examples in "the Benchmarks game" specifically.
I'm not sure what you are trying to say though? My point was that you have to develop expertise before you can create high performance programs. If you are considering dropping node because you need more performance, be careful.
That's what is surely not surprising to me, as I've measured the performance of V8 even before node.js existed, and already knew of enough examples that resulted in the code executed with the speed comparable to C. I don't consider any modern JavaScript JIT implementation to be "slow", neither V8, nor the one in Safari or in Firefox. Moreover, all of them have more than one level of achieving the speed -- they adapt to the needs of the code executed, they are really the works of art, and not an accidental development.
Besides, most JavaScript programmers are already dependent on Microsoft products like TypeScript, NPM, and Visual Studio Code. What's one more?
The debugger (clrdbg) is still artificially restricted from running inside anything else than MS' IDEs.
The global certificate store is still a thing.
On that note, the cryptography support varies wildly between platforms, because they still insist on using SChannel on Windows. And I guess that means that they have to use SecureTransport on macOS, to avoid appearing to play favourites or something.
The action at a distance that it encouragtes would make you think you're in a haunted house.
Despite bringing the Windows mentality with them everywhere, there still isn't a competent migration story from Framework, so what's the point? Legacy code is still a pain to port, and you'd be crazy to actually want to write new code in this mess.
It is still not in the same league as Java when it comes to dev tools and the Java ecosystem keeps getting better as well, but at the moment I am torn between the two (or rather, I have two excellent options that I can choose depending on circumstances.)
.NET Core is nice enough to do very large projects in though so I cannot see many reasons of moving away from it (especially from F# which I mostly use now).
It's also not exactly run like a community project. The issue tracker feels more like a customer support system: "can you try updating to the newest release now?" abound, with no mention of what the actual problem or fix was.
From where I am standing it has always been either Java or .NET since the last 20 years, while we keep seeing stuff coming and going every couple of years.
After that, you have Go at 9%, Kotlin (also a JVM Lang) at 6.6% and Scala (also a JVM Lang) at 4%.
Finally, you get Elixir and Clojure both at 1.5%
Source: https://insights.stackoverflow.com/survey/2019
So yes, I think learning Java and the JVM ecosystem is a good investment, considering Java dominates, and if you tally up JVM langs you get something like 51% of professional developers using a JVM based language for work.
We've drifted from just compiled languages here, but the most important server-side language to know is probably PHP. Personally I've really enjoyed working with Drupal.
Also, that doesn't look like a great metric, since it's just the number of website using a particular technology. That's going to be massively skewed by prefab solutions like WordPress and all.
I liked that the StackOverFlow survey asked people what language they used professionally. I feel that's much more relevant.
I've never seen PHP being used for those usages. So I probably made an assumption here that it isn't, or rarely is.
All the languages I listed generally run their own server, and can handle the full request, down to its connection. While I remember PHP only managing the payloads from an existing server, running as an embedded script which the server delegated too on the last step for final rendering of the response.
So for example, it couldn't manage any type of long running in-memory process or anything like that. And it didn't have direct access to IO, as that's all managed by the containing server. Things like that, which not all REST APIs would need, but is generally something I'd expect to be able to do for more generic backend work. Don't know if there are now ways to do all this.
(I'm not convinced it's long term profitable to work on boring platforms either, but of course looking for fun things is more risky)
Doesn't seem that bad to be invested into Java/.NET/C++/Web eco-systems.
[1]: https://www.infoq.com/presentations/java-robot-swarms/
[2]: https://en.wikipedia.org/wiki/Liquid_Robotics
[3]: http://lamport.azurewebsites.net/tla/tla.html
[5]: https://www.infoq.com/presentations/java-science-aerospace/
I find a lot of joy in working in C# and the .NET core. It's very pleasant to work in and might be worth a look.
https://dotnet.microsoft.com/download/dotnet-core/3.1
I even managed to get it to run on an Android tablet via Termux by downloading the ARM64 binaries.
However, I still use C++ for extremely complex networked applications where performance matters, unfortunately Rust doesn’t have battle tested crypto libraries, so I wouldn’t personally use it for networked applications.
Code generation isn't so bad. Even JOOQ (Java's awesome ORM) will suggest you do it. And similarly, Java's generics aren't that great themselves. But you come to expect more from a newer language with so much history to learn from and they missed the ball on generics. (In contrast they got right: gofmt, go test, cross platform builds, go get, etc.)
In the end it is all bytecode (so java, or rather both java and kotlin output bytecode), but kt removes a lot of the ceremony, boilerplate, and altogether ideas that have proven to do not be that great in the years since java's inception.
E.G. I strongly prefer data class to records. No named parameters -> no default params -> way more boilerplate
If you like books, this should be a good intro: https://underscore.io/books/essential-scala/ (you should use IntelliJ IDEA instead of Eclipse, though)
And you can also use it for frontend development: https://www.scala-js.org/doc/sjs-for-js/es6-to-scala-part1.h... (having one language for both backend and frontend leads to great synergy)
To which my shortlist is Haskell, C#, and Rust.