And libraries like Quarkus [2] that leverage it that can launch in < 0.016s with < 12MB of RAM.
[1] https://www.graalvm.org/22.0/reference-manual/native-image/
Java needs set of microservice libraries reimagined from the ground up. Optimized for size and RAM consumption. Optimized for GraalVM compilation (it's bad, but it's not that bad, libraries make it that bad). Also preferably including new tool for building because Maven and Gradle are bad.
I'm in the same boat. I love Java, but I hate Java ecosystem. I hate golang, but I love its ecosystem. And I think that it's possible to write golang-like ecosystem for Java. After all there're people who wrote deno and bun to oppose node.js. Hopefully vaja will appear.
Which has pretty much already happened.
Maven and Gradle are not bad at all, hell, Gradle is probably one of the few build tools that can actually handle more complex tasks correctly. Sure, that fancy new build tool definitely is more ergonomic to use for that hello world with 3 dependencies listed, but can it actually be used for generating locale files and whatnot? Not everything is running the compiler.
Java’s ecosystem is one of the best and I can claim that quite objectively.
public class Main {
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 60; i++) {
System.out.printf("%d\n", i);
Thread.sleep(1000);
}
}
}
After spamming as many flags as I could find (literally listing all possible flags and seeing what looked like a high number, and lowering it), I could only get this program to use 307MB VIRT and 40MB RES memory.Unfortunately I didn't save the flags I used.
That's more or less on par with the equivalent Node.js program on my PC (Node.js actually uses a bit more RES memory, 44MB).
So I guess as long as you can (and want to) spam a lot of flags, it's feasible to lower memory usage.
Disclaimer: Not a Java dev.
If you want a lean, native-compilable microservice framework, there is Quarkus: https://quarkus.io/
My biggest hope when generics were announced was that we'd finally get an alternative to writing `if err != nil` 10+ times per function, but it doesn't support generic method type parameters. That alone kneecaps it severely by making type-safe method chaining useless in most scenarios (unless you never need to map to another type, ever, I guess. Lucky you.)
I watched the talk, thought I understood it "enough", then completely fell on my face trying to write a JSON parser.
Could be me though, maybe I should try it again now that it's been a few months
If you want performance, stick with Golang. If you want rapid prototyping/dev, go with Python, 3.11 is much better in performance than older versions.
The issue with Java is that right off the bat you are presented with bloat. Just to have a main function requires a class (and people realize this is wrong, which is why Kotlin and Groovy fixed this).
Want a build system? You have to learn a whole another language essentially, like ant/maven/or gradle.
Want to have logs? You have to use a library that has its own xml configuration files that specify behavior, in their own format. Oh and that library may have glaring vulnerabilities where logging something results in FETCHING CODE FROM THE INTERNET AND EXECUTING IT, BY DESIGN. Same goes for most any other public library that is widely used.
Oh and btw, its bad practice in making your class members public, you should make them private. But its also bad practice in writing getters and setters - instead use a library that hacks the AST and writes functions there that are not visible in the code, for which you need special plugins for every IDE to recognize.
I honestly don't know how people deal with this and remain so ignorant to it to continue using Java.
They managed to create a more verbose Java 1.1 (yes, this is objectively true), with even more footguns than it had at the time. Oh, and it is absolutely not more performant than Java for most use cases - sure, it is a good choice for very basic server applications that barely allocate anything, but complex applications where allocations are significant will absolutely run faster with Java.