Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Java still eats like 5x ram compared to node, Java tools are slow, Java frameworks are gargantuan, even those claiming "lean".

Java is fine if you don't care about RAM and start time, though.



https://quarkus.io/guides/building-native-image

You should try Quarkus. It is a production framework built by Redhat. It uses Java-GraalVM under the cover to compile your entire webapp to an executable (like golang does).

It's just as fast.

Java is the highest performance and most tuned VM there is. I think you're really thinking of java from a long time ago, if ur thinking this


> Java is the highest performance and most tuned VM there is.

Not defending the opposite argument, but V8 is also pretty impressive. It's rooted in work done for Smalltalk long before JavaScript was a thing.


> It's rooted in work done for Smalltalk long before JavaScript was a thing.

The same is true of HotSpot. https://en.wikipedia.org/wiki/HotSpot_(virtual_machine)#Hist...


Ah that Supersonic-Subatomic-Java. Whatever Redhat lacks in quality side in Java frameworks, they more than compensate with corny marketing taglines.


If you use gargantuan Java frameworks, you'll use a lot of RAM. Just don't do that. With Spring Boot and similar frameworks, the RAM usage is really just very modest. I'll give you startup times, since I am not a believer in Quarkus and Graal. And I wouldn't use Java for a serverless function that needs to spin up and respond quickly. But for a typical (blue/green-deployed) application in my world, startup time is still only a few seconds, which is fine for many applications. And I am not settling for "fine", just saying that the startup time isn't a big consideration, against a lot of things the Java (or Spring, in my case) ecosystem offers me.


I had a Quarkus server app start up in 0.1s the other week. And BTW Spring Boot does native compilation now too [1]

Your "belief" is putting you at risk of ignoring a wide range of Java use cases unnecessarily.

[1] https://docs.spring.io/spring-native/docs/current/reference/...


You are probably right. It's one of those things where I've not seen a need to jump aboard. I'm still being fearful of reflection going to break on me. Probably irrational fear, but fed by me not understanding how it wouldn't break. Which I should study up on. Which I don't, since I don't have the need. And here I am ... vicious circle.


Startup time is fine.. just don't use spring where it has to read every class at runtime to determine what to inject.


Well that's the Spring's great feature: To convert as many compile time errors in to runtime errors as possible.


To be fair there is the new Kotlin based wiring API which avoids that with the caveat you need to instantiate everything manually etc. Which is probably a decent tradeoff for some folks.


There’s other alternatives like Avaje Inject and Quarkus which uses the same annotations but does the injection generation at compile time.


Care to share more thoughts on Quarkus? I'm evaluating it for an upcoming app. From my limited reading it can be used with and without Graal.


My favourite bit of Quarkus is the same as my favourite bit of Micronaut - DI is compile time.


See my sibling comment: my fears are irrational.


Javalin is _very_ lightweight, and starts up fast. Use the framework that best suits your requirements.

Also, Java is working on reducing ram usage: https://openjdk.java.net/projects/lilliput/


there's Helidon: https://helidon.io/ as well from Oracle. though at the moment, I'm using Javalin.


I thought so too. And wrote simple web service using Helidon SE. It eats 300+ MB of RAM. I spend some time trying to optimize GC and all that stuff. Similar node service would eat 30 MB of RAM.

May be Graal would save us all. Until then Java is beyond salvation.


Other than a very very niche usecase, I really don’t see how eating 300 MB of RAM is so problematic when we quite literally have servers with terabytes of RAM. Yeah java can be configured to run GC all the time and target <100M of ram, but it rather runs the GC only seldom (jvm is actually one of the most energy efficient runtimed languages out there!) and trades memory usage to throughput.


Because in the cloud you're paying hefty price for every MB of RAM. For example with Jelastic you have 128 MB per cloudlet. And it's 2x difference between 120 MB and 130 MB. And with dedicated servers I don't have terabytes of RAM, I have two server with 24 GB each.

And no, you can't configure Java to target <100 MB of RAM. I configured it with -Xmx64m and it still eats around 300 MB. Java just fat and you can't do nothing about it at this time.


Or you care about actual performance of the system?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: