> The relevance is that even a 175 LOC project in Java takes up enormous memory and disk footprint

_This particular_ 175 LOC Java project takes up an enormous amount of memory. For all you know it was just coded poorly and the Go one is a bit more reasonable.

> the JVM is this super-heavyweight thing that's really just inherently inappropriate for a lot of applications.

The JVM introduces overhead but not so much that you can make these sorts of extrapolations.

The footprint of this particular service could have been optimized in Java but:

  1. the JVM itself imposes a high floor (hotspot, many shared libs loaded, ...)

  2. the Java language is full of overhead at every level (boxed types are a pet peeve of mine)

  3. the Java ecosystem has a tendency to regard memory as an inexhaustible resource, which lead a lot of waste in many 3rd party libraries

The core point is that optimizing this particular Java program (and the others that followed) would have been more time-consuming than a Golang rewrite and would have probably increased the complexity whereas a Golang rewrite reduced it.

Optimization was the original goal, increased maintainability was a pleasant result.

Point 2... yeah, that's one of my major problems with Java. Unnecessary boxing and the unreasonable amount of complexity if you work around it. In any type of Object collections, it consumes memory, stresses garbage collector unnecessarily and causes a lot of CPU cache misses.

Value types would help so much with this issue. I know they're coming one day. I hope Java/JVM can replicate memory efficiency and cache coherence of C++ std::vector for small objects.

34MB for Hello World, according to this SO post: http://stackoverflow.com/questions/13692206/high-java-memory...

I'm not going to install the JDK just to verify, but feel free to report back if you get different results.

For comparison... I did a similar Hello World test around the timeframe of .Net 2.0, and it was around 11mb to load IIRC. The latest iojs on windows seems to be just under 9mb.

Not sure what the golang overhead is, by comparison.

I can't say what an Hello World uses, but I have a Tumblr API → RSS gateway written in Go running for a few months, and it uses ~2MB.

Until you have enough microservices and each microservice carries its own Go runtime. Then having one JVM suddenly isn't so bad. The problem (as someone else said) is that using Docker may not be the right solution here.

There are enough solutions (e.g. servlet containers) where you can run multiple services in one VM, with isolation, and security hardening (using security manager).

With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has downsides (typically more memory use) and upsides (upper bound on the maximum memory use of a process).

Your remark about isolation is not entirely true: when you run multiple services in one VM, there are still a number of shared resources.

Most notably, all services will share the same heap, so one ill-behaved service can bring down all the other services. The only way to prevent this, is to run each service in a separate VM.

And at that point, you are once again comparing one Go runtime per service with one JVM per service.

> With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has ... upsides (upper bound on the maximum memory use of a process).

If you're running a Go app in a container, you can use also tune the upper bound on memory use by restricting the available memory for the container.

Yes, it's larger than a C or Go process. Does it usually matter? No.

The whole Netflix is based on the JVM and Java. They are enormously big, they have high CPU and I/O requirements in many cases, and yet, they manage well on Java.

I'm not a big fan of Java as language (to say the least), but the JVM as a runtime is very-very sophisticated.

The disk footprint was measuring the size of the docker container, who knows what was in it. Something would have to be wrong for 175 lines to require 650MB of dependencies... it could if it were loading all of Spring/Hibernate/etc., but then I'd challenge it wasn't a "microservice" at all.

Basically Ubuntu 15.04 docker image + openjdk8 + mysqlclient + the service itself

JDK... 167MB tarball + 330MB uncompressed

That's the JDK.

You just need the Server JRE which is 57MB tarball + 157MB uncompressed.