Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JVM is not that heavy

opensourcery.co.za

Post reply on HN
Print view View original

221–230 of 373 posts

Re: The JVM is not that heavy

#221

Post by eklavya »

realusername wrote: post #159
flavor8 wrote: post #40

Earlier quoted context omitted.

Which tooling specifically? Going from Java to Python a couple years ago I was in shock about how immature the tooling in the Python world is by comparison.

I also hate the Java tooling as well personally, it's my #1 complaint with the language and one of the reason I avoid it. I would say that nothing really follows unix principles and seem over-engineered, everything is quite complex to grasp to become proficient.

I don't know when I used Haskell after using Scala, the first thing I missed was the JVM tooling. There is nothing I have seen ever that comes near.

Re: The JVM is not that heavy

#222

Post by janwillemb »

martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

"Don't rewrite an application from scratch. There is absolutely no reason to believe that you are going to do a better job than you did the first time." -- Joel on Software, Things You Should Never Do, Part I [1]

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Re: The JVM is not that heavy

#223

Post by radicalbyte »

yoden wrote: post #99
derefr wrote: post #41

Earlier quoted context omitted.

> I wrote a simple tool that allows you to filter out what you don't need It'd be a short hop from here to a tool that basically does for JDK-platform apps what Erlang's releases do for the ERTS platform: builds a new JRE (as a portable executable, not an installer) that actually contains the app and its deps in the JRE's stdlib, such that you just end up with a dir containing "a JRE", plus a runtime "boot config" fi…

https://docs.oracle.com/javase/8/docs/technotes/guides/deplo... Not only is it a short hop, it already exists :P

The problem with visiting that site is that Oracle have started litigating against users of their JVMs.

In that way the JVM can be "heavy".

Re: The JVM is not that heavy

#224

Post by lenkite »

martingxx wrote: post #110
brianwawok wrote: post #96

Earlier quoted context omitted.

> aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS. This is the easy trap to fall into though. What if you aggressively rewrote the Java apps from crappy legacy frameworks to well developed Java apps? A rewrite ALMOST always is faster. So the new language seems faster. Except if you would then rewrite the rewrite back in the original languag…

These apps are mostly microservices and the Java ones are mostly only a year or two old. None of them use things like spring. Some use Dropwizard. Would you consider dropwizard modern? If not, what would you use instead?

Use vertx if you want lean REST micro-services. I so wish vertx was part of the standard library.

The main advantages that Go has over Java is that the standard library is brilliant - thus obviating the need for folks to create monstrous frameworks (and losing performance) and that Go has better memory utilization because of value types (structs) and because it is AOT compiled. Unfortunately Java JIT as designed by the JVM devs takes a lot of memory.

In raw performance, I would still give the edge to Java over Golang though.

Re: The JVM is not that heavy

#225

Post by jshen »

kasey_junk wrote: post #98
martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

I've spent a fair bit of time in both, most recently the last couple of years in go. I think its a very mixed bag and there is no clear winner. The tooling, especially for runtime operations, are so much superior to the golang options its night and day. I have much more success modeling complex business models in java with its better type system, and for doing low latency work its much easier to do on the jvm due to…

I have golang website/web app that runs at tens of megabytes per process. A very similar java web app runs in a few hundred megabytes per process.

I also run these in on cloud platforms that auto scale. The golang processes spin up very quickly, the java ones not so much.

In these two respects the JVM is heavy compared to golang for my very common scenarios. The heaviness also causes me to spend more money for the JVM solution.

Re: The JVM is not that heavy

#226

Post by jshen »

exabrial wrote: post #167
martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

These types of arguments cause many intelligent people to headdesk. They're hardly an apples to apples comparison. Of course "Go was Faster". It's because you started with a clean slate!

That's not it. A fairly small http server in go will run in tens of megabytes. The same thing on the JVM requires a couple hundred megabytes at best. The difference in startup time is roughly the same as well.

Re: The JVM is not that heavy

#227

Post by kazagistar »

bjoernw wrote: post #172
snuxoll wrote: post #147

Earlier quoted context omitted.

I mean, even the "enterprisey" stuff like Spring Boot is more than fast enough. I have a little REST service I just deployed to production today, 5 seconds to start up on my laptop's SSD (unfortunately it took about 50 seconds in production because our SAN is dog-slow for some reason).

How is Spring Boot "enterprisey"? It makes modern java programming simpler and more accessible by hiding some of the unnecessary complexity. It enables things like https://jhipster.github.io/ which to me is the Rails equivalent in the java world.

> hiding complexity

This makes me shiver in terror.

Re: The JVM is not that heavy

#229

Post by vacri »

rb808 wrote: post #20

Not just heavy but I really don't like all our processes named "java" with stupid -D cmd line parameters. A Nice native binary app will let you can name it what you want with config as you like it.

Not to mention that having three horizontal monitors still isn't wide enough to see the entire flag list in top/htop (looking at you, ELK stack)...

Re: The JVM is not that heavy

#230

Post by e3b0c »

martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

We have similar experiences as well.

  $ ps -eo rss,cmd,user | grep jenkins
  4928228 /usr/bin/java -Djava.awt.he jenkins

  $ ps -eo rss,cmd,user | grep drone
  12940 /drone agent                root
  19924 /drone server               root
We run the two applications in the same machine. Admittedly Jenkins is much feature-rich but we only use its vanilla settings without whatever fancy plugins for a few legacy SVN repos.

P.S. The Drone server and agent are running within docker containers.

Post reply on HN