Hacker News Reader

Comment by iamcalledrob | Hacker News Reader

I've found that often people who have been deep in the JVM ecosystem really struggle to enjoy Go, and vice versa.

It's like the JVM ecosystem commits deeply to the complete opposite of idiomatic Go, and once you've built those neural pathways, it's hard to unlearn it all.

Kitchen sink stdlib, Exceptions, Verbose naming, Complex build system, @Deprecated...

View on HN

I spent around 15 years doing Java exclusively, and after discovering Go (around 2012) I couldn't wait to adopt it and have never looked back since. I don't think Go is perfect, but I find it a much better default pick for most things I've worked on compared to Java. Of course Go has limitations, especially in the type system and error handling, but rather than go back to Java for those cases where it matters most to me, I tend to choose Rust these days. It shares some of the advantages of Java (compared to Go) and also comes with its own set of other major advantages too.

I hate Java just as much, but at least it’s trying to improve and grow beyond its past limitations, instead of promoting bad design decisions as good for the programmer.

I have worked with many languages - from Java, Delphi, C/C++, Assembly, PHP, Go, Rust etc. I don't really understand the hatred for Java. The build system in Java is not complicated .. whether Gradle, Maven or whatever unless your requirements are very complicated (multiple builds etc).

In my opinion the most complicated system out there is Javascript and all of the myriad tools needed to support that ecosystem. It has approached the complexity of C++ and perhaps even exceeded it

I'm a committed Kotlin shill and a very experienced Gradle user but I'm the first to admit that it is absolutely arcane for those new to it. Once you know all the incantations it's really flexible and performant but good luck writing a plugin for the first time.

My favorite thing about gradle is that the build file is written in the same language as your code. This gives you the great power of easily adding a little hack into your build file, so it's pretty rare you actually have to make a plugin.

The downside is that every build file is a little bit unique, but IME it's not that much worse than what happens in golang. In golang people usually slap a makefile on top of the go commands, and then you have to read the makefile to figure out what targets you need to run, and if it gets a little complicated then they start calling out to shell scripts and things like that. ech.

To be fair, I do think Gradle is more complicated than Maven or Cargo.

Very interesting. Bulk of my career has been writing Kotlin/Java and after a year of Go I am _still_ really struggling. Nice to know I'm not alone!

I see the benefits (I've have seen some absolute Java ee monstrosities that would be impossible to build in Go) but why am I getting paged at 3am because someone forgot to set a field on a struct. Similarly all the codegen to workaround the lack of inheritance - who cares how fast the compiler is if you've got to do 30s of codegen on top.

> but why am I getting paged at 3am because someone forgot to set a field on a struct

https://golangci-lint.run/usage/linters/#exhaustruct

This is very odd.

Java is my "main" language, but I do enjoy Go. I think it is very ergonomic, and it shines in some contexts where Java is lackluster.

The error handling in Go is kinda meh, but hardly a dealbreaker.

> Kitchen sink stdlib, Exceptions, Verbose naming, Complex build system, @Deprecated...

Now do drawbacks.

Every time that I see verbose naming I can't but think someone got posessed by Dr. Heinz Doofenshmirtz's spirit.

- Behold! The LongRangeAtomicStructureCompactinatingReconfigurator!

- (rolling eyes) So a ShrinkRay.

- No, no, it is named LongRangeAtomicStructureCompactinatingReconfigurator to improve readability and communication.

- (rolling eyes even more) Sure.

That's a culture issue, not a language issue. And no, the language doesn't attract these type of people, but rather language is so good that it is prevalent in domains that hire those people.

Sure, Dr, sure.

A distinction that belongs in a dictionary perhaps. To a programmer the ecosystem and the language are one and the same. One cannot rewrite every piece of code out there to suit their fancy.

Java has Spring/Java EE, what people typically call EnterpriseJavaBean and it has Vert.x, Quarkus, Micronaut which are complete opposite.

That's not good, it means the language is effectively two languages now and you do not know what to expect when you open a supposedly "Java" codebase.

If you've known Java for years from the Spring POV and the codebase in written in the "modern" style, you're lost in the woods now.

Worse yet, choosing between the two styles is now a decision that every single project and company needs to make. Endless, pointless bikeshedding akin to which code formatting is to be used or Maven vs Gradle.

Such decisions should be made higher up, at the language design/culture level. It should be obvious which options are the correct ones by just looking at the feature set of the language, the ecosystem of code already written in it, the style guides, etc. If changes are needed, the few language creators should bless a single way forward and push for the ecosystem to all move to it instead of deferring the decision to the millions of users of the language.

I'd rather have this than a variable called `l`.

Are you sure there such an entity as "the JVM ecosystem"? What is the common thread you can run through Kotlin Android jockeys, Clojure scientists, and Enterprise Fizzbuzz Java 11 types?

Yes who needs generics and a proper error handling system.

When you can have Go where the boilerplate is so bad you literally have to rely on generating source code files in order to maintain a sane level of productivity.

I use idiomatic Go every day and it's like being back in the 90s.

Its actually a good question on who needs generics. It makes code unreadable and was never really useful in commercial products.

Try writing Go without generics. No typed maps, arrays, slices, channels or function types. Only `interface{}`. Go always had generics, you just weren’t allowed to write your own until recently.

You use it everyday, yet have not figured out that it has had generics for almost 3 years?

Its generics aren't as advanced as Java's or any other language with generics for that matter. Plus most things are now only adding support for generics, so there's a fragmented ecosystem of code before and after generics were introduced.

This. It's so frustrating that sync.Map isn't generic and reusing the builtin map API is impossible.

In our entire codebase, Go's generics have been used, like, 3 times, even though they were introduced almost 3 years ago. It's unsurprising: generics are most useful for writing your own custom containers, and generally, most projects don't need their own custom containers. It felt somewhat anticlimactic, considering all the anticipation.

You often don’t need custom containers, but you need containers! I shouldn’t have to write my own custom method to map or for each over a list of items, etc.

Reply on news.ycombinator.com