Hacker News Reader

Comment by doctor_eval | Hacker News Reader

I wrote Java code for 20+ years and I can tell you exactly why I prefer Go: it produces native binaries.

I mean, it’s also less verbose, easier to start a new project, faster to startup, has far fewer configuration knobs, has native dependency management, is far easier to build CI/CD for, compiles more quickly, has very few NPEs gotchas, has value types, and avoids idiomatic boilerplate.

Go is far from perfect, but it has clear advantages over Java and I would not go back.

But the thing I love the most is the lack of a JRE. If I build for a target, it runs there.

View on HN

> I mean, it’s also less verbose

Are we talking about the same language? Or maybe you consider writing "if err != nil" every few seconds as good exercise for your fingers...

I think we shouldn't point fingers at Java when it comes to Go's verbosity.

I can simply do dict.contains("foo") in Java vs having to go through a verbose hoop:

    if val, ok := dict["foo"]; ok {
        //do something here
    }

Common operations like filtering/transforming collections are very concise in Java - I'm certain doing so in Go will be a bunch of more boilerpate:

    collection.stream().filter(...).map(...).collect(...)

Don't get me started on having to go through iota hoops to declare enums.

Go's language maintainers refusal to add list operations / comprehensions and you having to type it out by hand every time is something I hate everyday while I'm getting paid to write it.

I’m guessing these will come with generics. Wasn’t that also the case with Java?

Go generics already shipped. I wasn't around for Java 4 days so I don't really know when the main operations shipped but one language maintainer was categorically against it so I wouldn't hold high hopes.

Go generics are still in their infancy. Java generics enabled a lot of functionality that came later. But java generics and particularly type erasure are nothing to write home about, and Go maintainers were also said to be against them, so who knows if comprehensions or other features might pop up one day.

Well, I listed a number of things I prefer about Go, and the verbosity I was talking about was the classic ButtonFactoryFactory and other naming classics. It’s true however that I ended up throwing that stuff away from my Java code and started to enjoy life again.

But I can say honestly that I prefer Go’s error handling, which I find tends to result in errors which are actionable. I think it takes a lot more effort up front to get Java exceptions to work rationally.

If I could change Java then the thing I’d do is I’d make it necessary to declare all exceptions in a method, but get rid of caught exceptions. So you can see what’s coming, even if you don’t have to deal with it.

In terms of stream operations, well, I write a lot of typescript lately and just like in Java, I find that I end up having to fall back to regular loops quite often. I’m not convinced that stream operations are useful in as many use cases as people would like. For example, the moment something can throw an exception, things are going to get gnarly.

> If I could change Java then the thing I’d do is I’d make it necessary to declare all exceptions in a method, but get rid of ~~caught~~ checked exceptions

That's pretty much what javadocs contain already

Name one FactoryFactory in the JDK

FactoryFactory is (or was) a well known parody of the multiple levels of abstraction Java developers were encouraged to make when performing even simple tasks. This started with an insistence that we should use getters and setters for field access, and it basically went downhill from there.

This kind of nonsense was endemic to the Java engineering culture while I was working in it.

Perhaps the worst example I saw was during the fluent API craze where someone in my team replaced a constructor call for a Button with five lines of fluent Builder pattern gibberish.

The point of mentioning FactoryFactory was to poke fun at the culture surrounding Java, which ended up being one of the reasons I stopped using it, because idiomatic java stopped making sense to me.

Hopefully it’s changed now.

That was one reason I liked Go as well, it's no longer the case though, you can produce native binaries with GraalVM.

Last time I used GraalVM, there were huge holes in what language features were supported, compiling dynamic code was hit-or-miss, and also its cross-compilation story was not good (requires you to compile it on the target architecture). Perhaps my information is out-of-date now?

Yeah I find the argument for Graal to be very disingenuous. It’s certainly not an out of the box solution; I’d say it’s just another Java technology stack we would need to learn. And there are so many of those.

So I guess I also like Go’s batteries-included standard library.

Reply on news.ycombinator.com