2 ms·

I’ve written a ton of microservices in Java and have recently started a new project using a very similar architecture, but with Go. I had a chance to reflec on

I’ve written a ton of microservices in Java and have recently started a new project using a very similar architecture, but with Go. I had a chance to reflec on what I like about Go, and what I miss from Java. To boil it all down: * I prefer the Java language over Go, for a bunch of reasons, although neither is perfect. * I very much prefer using binaries over bytecode objects, so Go is much better here. * The JVM is a very large runtime to associate with your code, and the startup time is still much longer than for Go (or it was a year ago). This makes Java CLI tools slow, and a great CLI can help make a great product. * I prefer Go’s approach to the standard library; easy to use production ready “for dummies” implementations, instead of abstract “reference” implementations. * I specifically don’t like Go’s use of capitalisation to mark fields and variables as public, since I find that collisions between type and variable names are really common. * Go’s “idiomatic” practices are much saner than Java. I’d already stopped using getters and setters in Java, along with dropping several other abstract “best practices” (factory factories!!?? “Fluent” APIs??), and Go really embraces a light approach here. So I guess I don’t really like idiomatic Java. I got the feeling I wasn’t alone, tho. * In general I like how Go feels like it’s a Unix tool, where Java always felt like they were trying to rewrite the world. This approach always felt odd to me, considering where Java came from. * I have really come to hate the “everything’s a framework” approach in Java and abandoned it a couple of years ago. Especially, Java EE, Wildfly, Spring, JPA etc. they all add enormous weight and complexity without realising any material benefit. It’s not that it has to be this way, and I think things were improving, but so many Java libraries were just massively complex and abstract, for no good reason. So for my use case, Go is clearly the right choice, but after 12 months working in Go there is plenty that I miss about the Java language. I had really high hopes for the Java AOT stuff but it seemed to stall (maybe I missed something).

littlestymaar 6y ago
I agree with pretty much everything you said except this one: > In general I like how Go feels like it’s a Unix tool, where Java always felt like they were trying to rewrite the world. Go is pretty much on par with Java when it comes to rewriting the world albeit not in the same way: they have their own assembly, their own linker, and even have their own libc using raw syscall (even doing so on windows and Mac for a while, which caused issues because there is no syscall stability there). And since it has a poor FFI, many Go developers end up rewriting their own libs in Go for pretty much everything when they need one lib.
- doctor_eval 6y ago
  Yeah - I agree, and I suppose given the history and people who wrote Go, I tend to give it a pass here where maybe I shouldn’t. I also don’t tend to do any work in C any more so haven’t noticed that. I would say though that Go library calls work more like Unix/stdlib calls than Java, which makes abstractions out of even the most basic stuff, like filenames. But my point was more that, relative to Java, the performance and CLI tools feel very Unix like, they remind me of my C programming days. I mean Javac/mvn/gradle are all so slow relative to Go; Java command line tools don’t really seem to care about developer ergonomics. It’s hard to imagine chaining a bunch of Java CLI tools together with pipes! This is more because of the long startup times and cost of the JVM, but that too is part of the problem.
kasperni 6y ago
> I had really high hopes for the Java AOT stuff but it seemed to stall (maybe I missed something). Project Leyden [1] aims to standardise AOT for the Java Platform. It is planned to start sometime in the new year. We will most likely end up with two implementations of it. One is GraalVM's native image which will most likely need to make some changes in order to follow the specification. And another implementation will likely be one that is based on HotSpot's C2 compiler [2][3]. [1] https://www.infoq.com/news/2020/05/java-leyden/ https://www.infoq.com/news/2020/05/java-leyden/ [2] https://github.com/openjdk/jdk/pull/960#issuecomment-722023038 https://github.com/openjdk/jdk/pull/960#issuecomment-7220230... [3] https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html

littlestymaar 6y ago

I agree with pretty much everything you said except this one: > In general I like how Go feels like it’s a Unix tool, where Java always felt like they were trying to rewrite the world. Go is pretty much on par with Java when it comes to rewriting the world albeit not in the same way: they have their own assembly, their own linker, and even have their own libc using raw syscall (even doing so on windows and Mac for a while, which caused issues because there is no syscall stability there). And since it has a poor FFI, many Go developers end up rewriting their own libs in Go for pretty much everything when they need one lib.

doctor_eval 6y ago
Yeah - I agree, and I suppose given the history and people who wrote Go, I tend to give it a pass here where maybe I shouldn’t. I also don’t tend to do any work in C any more so haven’t noticed that. I would say though that Go library calls work more like Unix/stdlib calls than Java, which makes abstractions out of even the most basic stuff, like filenames. But my point was more that, relative to Java, the performance and CLI tools feel very Unix like, they remind me of my C programming days. I mean Javac/mvn/gradle are all so slow relative to Go; Java command line tools don’t really seem to care about developer ergonomics. It’s hard to imagine chaining a bunch of Java CLI tools together with pipes! This is more because of the long startup times and cost of the JVM, but that too is part of the problem.

kasperni 6y ago

> I had really high hopes for the Java AOT stuff but it seemed to stall (maybe I missed something). Project Leyden [1] aims to standardise AOT for the Java Platform. It is planned to start sometime in the new year. We will most likely end up with two implementations of it. One is GraalVM's native image which will most likely need to make some changes in order to follow the specification. And another implementation will likely be one that is based on HotSpot's C2 compiler [2][3]. [1] https://www.infoq.com/news/2020/05/java-leyden/ https://www.infoq.com/news/2020/05/java-leyden/ [2] https://github.com/openjdk/jdk/pull/960#issuecomment-722023038 https://github.com/openjdk/jdk/pull/960#issuecomment-7220230... [3] https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html