From Java to Go, and Back Again (2016)

Re:From Java to Go, and Back Again (2016) by innagadadavida on Saturday June 23, 2018 @02:53PM (#17382762)

A major pain point with JVM even today is the startup time. This is especially true for command line tools. I use hdfs tools and it is really slow to start. Someone wrote a Go replacement that is 100X faster to start. None of the JVM sophistication means anything if it cannot solve simple common world problems. The java community has failed in this regard in my opinion.

[1] https://github.com/colinmarc/hdfs

[ Parent | on HN ]

Re:From Java to Go, and Back Again (2016) by rhencke on Saturday June 23, 2018 @03:12PM (#17382859)

Keep your eye on Graal - specifically its native-image component.

Not only do you get instant startup, you also get a statically linked binary that doesn't need a JRE present to run. Throw it a JAR - get a native binary for your system.

https://github.com/oracle/graal

[ Parent | on HN ]

Re:From Java to Go, and Back Again (2016) by guitarbill on Saturday June 23, 2018 @03:21PM (#17382894)

Someone used GraalVM to eliminate cold-start penalty for Lambdas, genius [0] ! I'm very excited about Graal, if only because it'd make deployments easier, but the debuggability remains to be seem.

[0] https://news.ycombinator.com/item?id=17284022

[ Parent | on HN ]

Re:From Java to Go, and Back Again (2016) by sreque on Saturday June 23, 2018 @03:12PM (#17382853)

Totally agreed that java fails hard for use cases involving small, lightweight binaries that are low memory and fast to start. This is an area where golang shines on the other.

People are starting to experiment with AOT compilation via graal to make headroom in this space, but the techonology being used feels young, nascent, and experimental or immature:

https://medium.com/graalvm/instant-netty-startup-using-graal...

https://www.innoq.com/en/blog/native-clojure-and-graalvm/

Interestingly most high-level runtimes also have slow startup, including python, ruby, and node.js, but java's feels worse because people seem to want to use heavyweight frameworks like spring or aspectj that absolutely murder startup time, that for instance generate bytecode on startup or use classpath scanning to discover dependencies.

[ Parent | on HN ]

Re:From Java to Go, and Back Again (2016) by thermodynthrway on Saturday June 23, 2018 @03:23PM (#17382916)

Yeah it's a bad trade-off developers don't realize they're making sometimes. Spring is Gigantic. Application containers like Tomcat aren't much better. It's easy to write huge apps in Java that still perform well so there's not much pressure to modulize huge monolithic libraries. So we all just deal with the 200+ deep stack frames.

Newer frameworks like Vert.X and Dropwizard address this pretty well. We have a fairly large Dropwizard project that still starts in ~5 seconds. Also some written in Spring MVC that take 2 minutes...

Also, God AspectJ let's you create horrible abominations. And it feels like it was designed to encourage you to do so. A great example of why you shouldn't always use self modifying code even if it's easy to do.

[ Parent | on HN ]

Re:From Java to Go, and Back Again (2016) by thermodynthrway on Saturday June 23, 2018 @03:06PM (#17382823)

This is actually being addressed, eventually. There's work being done to lower the startup time in Java 9-10 but I'm not sure what state it's in. Basically cache everything from the first run to make future launches almost instant

[ Parent | on HN ]

Re:From Java to Go, and Back Again (2016) by ptx on Monday June 25, 2018 @02:00AM (#17390185)

I played around a bit with that, i.e. app class-data sharing and AOT compilation. It turns out Java 9 comes with an enormous regression in launch performance, so that even with app CDS enabled it is slower than Java 8 to start.

Java 10 is slightly better but still slower than Java 8 by default. Enabling app CDS gets you back to comparable performance to Java 8. With AOT enabled (in addition to app CDS) it might be faster, but that just crashes on machine (and only works on Linux anyway).

So don't get your hopes up too much.

[ Parent | on HN ]