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

281–290 of 373 posts

Re: The JVM is not that heavy

#281

Post by [deleted] »

pjmlp wrote: post #248
cutler wrote: post #196

Earlier quoted context omitted.

This is one thing I've never understood about Clojure - the Java interop. I actually love Clojure but I close my eyes to the fact that it requires an object-oriented VM to work its magic. Clojure is a functional Lisp based on immutable data structures which is about as far from Java OOP as it gets yet we're encouraged to mix Java objects and classes into our Clojure apps as if nothing matters.

Funny, when I code in Clojure there are these things called multi-methods, protocols and multiple dispatch. I think it was originally designed in a Lisp library called CLOS, which incidentally stands for Common Lisp Object System. Very nice explained on how to implement OOP in Lisp, in a book called "The Art of the Metaobject Protocol". Users of Lisp based languages should think twice before criticizing OOP.

[deleted]

Re: The JVM is not that heavy

#282

Post by frant-hartm »

nikcub wrote: post #261

Microsoft seem to have learned a lot from Java in designing their new .NET Core CLR. It has gotten almost everything right: * a small and fast CLR (JVM) * a class library that defaults to almost nothing but primitive classes * proper and standardized version, platform and package management (NuGet) * open source and MIT license[0] * a patent promise[1] * arguably the best dev IDE available (Visual Studio) and one of…

I could more or less agree with most of it apart from

> arguably the best dev IDE available (Visual Studio) and one of the best up-and-coming dev text editors (VS Code)

https://www.jetbrains.com/resharper/documentation/comparison...

Refactoring, Coding assistance, Navigation & search sections being most important.

Re: The JVM is not that heavy

#283

Post by noir_lord »

fetbaffe wrote: post #231
jpgvm wrote: post #218

Earlier quoted context omitted.

Orthogonal to quality but imperative to velocity. At the end of the day despite Go's failings it's a good (maybe the best?) language for large projects and teams because it compiles fast, is easy to anyone to run anywhere, tests run quickly, programs execute quickly and there is already good tooling/editor support. Nothing beats efficient workflow for improving velocity.

I could use the exact same arguments but for PHP.

Which is why I still often use PHP.

For my usages its a reasonable language.

Re: The JVM is not that heavy

#284

Post by pvdebbe »

asmosoinio wrote: post #87
ekidd wrote: post #71

Earlier quoted context omitted.

> real 0m0.248s A quarter of a second to start up the VM, run some code, and exit again is actually pretty steep compared to typical interpreted and compiled languages. Among other things, this means that you can't really call Java executables from a loop in a shell script. For comparison purposes, both Ruby and Rust will show between "0.00 elapsed" and "0.02 elapsed" for a simple "Hello, world" program on my laptop.

The parent did write "parsing a 20 MB file". So not a hello world.

No post body was provided.

Re: The JVM is not that heavy

#285

Post by jwr »

Jeaye wrote: post #157
jwr wrote: post #149

Earlier quoted context omitted.

Yes, the startup is slow. But nothing afterwards is. The JVM gets bad press because of startup time while in reality that hardly matters.

In production, what matters is the ridiculous memory usage. Both Java and App Engine are to blame about this, but the Python and Go folks aren't running into the same issue.

Well, I don't know what you consider "ridiculous", but I run a web/application server with significant complexity (written in Clojure) in a 2GB RAM VM, with the JVM taking up about ~800MB. I'd say that's pretty reasonable and it meets my production/business needs.

Re: The JVM is not that heavy

#286

Post by eru »

derefr wrote: post #41
gregschlom wrote: post #25

Also 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 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…

Careful there---it's a slippery slope all the way to unikernels.

https://mirage.io/

Re: The JVM is not that heavy

#287

Post by ldev »

brianwawok wrote: post #96
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…

> 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…

Exactly, that's how some not very bright people were tricked into thinking that Node.js is actually fast.

Re: The JVM is not that heavy

#288

Post by adrianN »

geocar wrote: post #273
cbsmith wrote: post #212

Earlier quoted context omitted.

Huh? What? Several points: * Who said the 10MB is all used at once? * I don't know your hardware, but there is very, very good chance you are actually quite wrong about * If you were referring strictly to CPU cache, then I'm even more confused, because the entire existence of that stuff is predicated on it being faster than memory, so... (and even still, if your total CPU cache isn't 10MB, it likely isn't that much s…

> Who said the 10MB is all used at once? The parent was suggesting that this was all that was actually needed out of the 100mb or so downloadable. If you think the JVM is smaller, how small is it exactly? > If you were referring strictly to CPU cache, then I'm even more confused, because the entire existence of that stuff is predicated on it being faster than memory, so... (and even still, if your total CPU cache isn…

Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching.

You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application.

Re: The JVM is not that heavy

#289

Post by Zach_the_Lizard »

ldev wrote: post #287
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…

Exactly, that's how some not very bright people were tricked into thinking that Node.js is actually fast.

And at work, we're now rewriting all those NodeJS services in Go or Java.

We hired some Node maintainer(s) a long time ago, rumor has it, who got us on the Node train.

Re: The JVM is not that heavy

#290

Post by adrianN »

geocar wrote: post #271
gregschlom wrote: post #174

Earlier quoted context omitted.

10MB for a platform that allows you to run code on all three major operating systems without too much trouble and in a performant way is a huge win, in my opinion. Not many alternatives come close to that.

Q/KDB is 600kb, also runs code on all three major operating systems (and a few minor ones). It's also about 1000x faster than Java/Spark[1]. 1000x slower doesn't sound like a huge win to me; it sounds like a huge cost, so my question is what do we gain by making our programs 1000x slower? [1]: http://tech.marksblogg.com/benchmarks.html

That benchmark is literally comparing Apples to Oranges. It's not even the same hardware.
Post reply on HN