What the hell is an HCMB? Nothing on DuckDuckGo, and nothing on Urban dictionary. I wish people would stop using acronyms before defining them.
Can confirm: googled and landed right here.
The JVM is not that heavy
161–170 of 373 posts
Re: The JVM is not that heavy
#162I 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 sorts of comments are (no offense) worse than useless. Benchmarking is one of the most difficult things to do in software, and anecdotes like this just make things confusing for new engineers and feed the perpetual hype train around newer languages.
Please refrain from making statements like this unless you have a reproducible quantifiable analysis.
If you really wanted to demonstrate the effect you describe you'd need to have the same team rewrite the application twice, once Java->Java, once Java->go, making sure to align the program structure as much as possible (making exceptions to take advantage of lang specific features of course).
If you were to do that, then that would be interesting! No one does that of course because it's expensive and wasteful from a business perspective, but it's the only way to determine anything useful.
Re: The JVM is not that heavy
#163Jars are just awesome for cross-platform work or for when you need easy deployment. I oscillate between Java and Go now for similar tasks. They are both great for cross-platform and easy deploys/frequent updates. Go is better at systems stuff (that's expected as it is the new C IMO). Java is better if you want a boat-load of rich data structures at your finger tips (more than slices, structs and maps... Go feels bear bones here, but I like it that way just as I like C that way). They both perform about as well as C and C++ for most things and are safe and fun to use. I like C and C++ too, but I'm getting too old to use them.
Re: The JVM is not that heavy
#164I must admit my experience is a few years old, but one thing that the whole text doesn't mention and that has contributed a lot to the negativity I feel towards the java ecosystem: It seemed not well integrated in the Linux ecosystem. What do I mean? I often experienced that Java dependencies were not readily available in Linux distros. Packaging Java stuff was - weird and complicated, not sure how to better phrase i…
Because Java distributes applications as bundles including the libraries (fat JARs, WAR files and so on), libraries need to be available to the builder, not the installer. That means it's perfectly sound that they're in Maven Central (and competitors), and not in the OS's package manager. It's the same with packages in JavaScript, Ruby, Go, Erlang, etc.
The only things you might need to install through OS packages are the JVM, and perhaps an application server if you're doing things that way, which fewer and fewer people are.
When i first started working with Java on unix, i felt the same way as you - i wanted the libraries to come through the OS package manager, the same way native libraries do, and spent ages trying to get my deployed applications to use them. Eventually i realised i was just doing it completely wrong.
Re: The JVM is not that heavy
#165What the hell is an HCMB? Nothing on DuckDuckGo, and nothing on Urban dictionary. I wish people would stop using acronyms before defining them.
Closest I could think of was a typo on Intercontinental Ballistic Missile, but your comment is on the first page of google results.
Re: The JVM is not that heavy
#166So JVM is not heavy compared to even heavier stuff. However compared to Go it is quite heavy in term of disk, RAM usage, and deployment.
Exactly. I see where the author is going with his article (and I think some of the points he raises are actually quite valid), but he's playing both sides of the "heavier than what?" point.
Yes, the JVM is slimmer than many interpreted languages with external dependencies (Python, Ruby, etc), and yes it can be slimmed down through manual labor, but no it is not something you can call "not heavy" with a straight face.
Re: The JVM is not that heavy
#167I 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!
Re: The JVM is not that heavy
#168Earlier 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…
Yes, the limitation is rarely the programming language, it is the programmer. Also, when you do the rewrite you have already solved the domain problem that you did not fully understand when implementing it the first time.
"Plan to throw one away; you will, anyhow." First version to understand the problem, second version to solve it.
But deployment, gc pauses and startup time (jvm vs go) are orthogonal to program quality. I would also expect go to have less memory usage.
> deployment was simpler and faster, memory usage was slashed..., request/response times were much more consistent, startup was practically instant
Re: The JVM is not that heavy
#169Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…
I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...
Locales? Timezones? Unicode? There's a lot of stuff that is there to be used from time to time, does not mean it hits your processor cache often.
BTW, libruby-2.3 is 2,5M, just the shared object file, and it tries to use all aforementioned stuff from the underlying UNIX.
Re: The JVM is not that heavy
#170And it is better than a segfault.