4 ms·

Curious, what are the "high deployment costs of JVM based languages"? Don't must standard workloads simply deploy a jar?

nine_k 9y ago
Likely they mean high RAM consumption?
dyladan 9y ago
I assume this refers to the overhead of the JVM itself. How high that is and how much that matters has been subject to debate, but I think it is objectively higher overhead cost than the Go runtime.
geodel 9y ago
To simply deploy a jar you need to have jar compatible JDK installed on that system. The effort towards that IMO is non-trivial.
hinkley 9y ago
Until Java 9, not a lot was done about the memory footprint of Java. Especially Strings, which were all stored in UTF-16 internally. For a language prone to Stringly Typed coding, that makes containers a hard sell, but caused issues just running it on VMs long before containers were a thing. Really this is something that should have been started for Java 7 and completed in 8. They also kind of hit a wall around 1-2GB of memory that took ages to get past with GC. It had the potential to kill your 95th percentile numbers to have long GC pauses. It contributed to things like Redis and Memcached taking off because of how frequently you needed data close to you but couldn’t just keep it in process.
readittwice 9y ago
I suppose that "high-deployment costs" also includes JVM/application startup and warmup.
jeremiep 9y ago
Most likely some old myth regarding the JVM. Its actually trivial to deploy and updates are just pushing one file; your uberjar. This is so much better than anything node/ruby/python/php have to offer. I also feel much safer running code in a VM on the server than directly native where a single invalid dereference brings down the whole thing in a rain of fire.
- zzzeek 9y ago
  The unbelievable irony I'm observing with the Java-based things I need to deploy these days (Jenkins and Gerrit related) are that quite often they're making me build something, which then fails due to weird maven issues I don't understand (since I haven't been a Java dev since the ant days). The entire point of java was that bytecode is portable, it's "write once, run anywhere". Don't make me build your stupid .jar and figure out all your dependency / build-time issues, just give it to me!
  - jeremiep 9y ago
    I don't think Jenkins is a good indication of modern Java :) If anything Jenkins is a hairy ball of mud you should try to avoid :p I write exclusively Clojure on the JVM now; its like having all the advantages of the JVM and none of the inconvenients of Java!
unscaled 9y ago
Without using containers or fragile (and not very portable) executable wrappers you need to manage the JRE, JAR files and the right classpath. With go you can just run 'go build' and get static executables for all common platforms with zero dependencies. The key difference between that and just throwing jar files on random systems is that static executables truly work anywhere and will never crash because you don't have the right version of JDK and usually won't need messing up with arcane command line parameters or .properties files. Deployment is one area where Go truly shines and I guess that helped its popularity. PHP also got immensely popular due to ease of deployment, although of a different kind, in a different era and with different expectations.

nine_k 9y ago

Likely they mean high RAM consumption?

dyladan 9y ago

I assume this refers to the overhead of the JVM itself. How high that is and how much that matters has been subject to debate, but I think it is objectively higher overhead cost than the Go runtime.

geodel 9y ago

To simply deploy a jar you need to have jar compatible JDK installed on that system. The effort towards that IMO is non-trivial.

hinkley 9y ago

Until Java 9, not a lot was done about the memory footprint of Java. Especially Strings, which were all stored in UTF-16 internally. For a language prone to Stringly Typed coding, that makes containers a hard sell, but caused issues just running it on VMs long before containers were a thing. Really this is something that should have been started for Java 7 and completed in 8. They also kind of hit a wall around 1-2GB of memory that took ages to get past with GC. It had the potential to kill your 95th percentile numbers to have long GC pauses. It contributed to things like Redis and Memcached taking off because of how frequently you needed data close to you but couldn’t just keep it in process.

readittwice 9y ago

I suppose that "high-deployment costs" also includes JVM/application startup and warmup.

jeremiep 9y ago

Most likely some old myth regarding the JVM. Its actually trivial to deploy and updates are just pushing one file; your uberjar. This is so much better than anything node/ruby/python/php have to offer. I also feel much safer running code in a VM on the server than directly native where a single invalid dereference brings down the whole thing in a rain of fire.

zzzeek 9y ago
The unbelievable irony I'm observing with the Java-based things I need to deploy these days (Jenkins and Gerrit related) are that quite often they're making me build something, which then fails due to weird maven issues I don't understand (since I haven't been a Java dev since the ant days). The entire point of java was that bytecode is portable, it's "write once, run anywhere". Don't make me build your stupid .jar and figure out all your dependency / build-time issues, just give it to me!
- jeremiep 9y ago
  I don't think Jenkins is a good indication of modern Java :) If anything Jenkins is a hairy ball of mud you should try to avoid :p I write exclusively Clojure on the JVM now; its like having all the advantages of the JVM and none of the inconvenients of Java!

unscaled 9y ago

Without using containers or fragile (and not very portable) executable wrappers you need to manage the JRE, JAR files and the right classpath. With go you can just run 'go build' and get static executables for all common platforms with zero dependencies. The key difference between that and just throwing jar files on random systems is that static executables truly work anywhere and will never crash because you don't have the right version of JDK and usually won't need messing up with arcane command line parameters or .properties files. Deployment is one area where Go truly shines and I guess that helped its popularity. PHP also got immensely popular due to ease of deployment, although of a different kind, in a different era and with different expectations.