[omegabravo]

Go is not cool, it's boring and readable. I don't need a diagram to understand what the code is doing compared to Java. I say that with deep respect for the JVM and all the problems that are solved with it. It's an incredible ecosystem.

I'm productive in Go because I realise most of my time isn't spent typing, it's thinking. I shy away from over abstraction and lean heavily towards composition.

If you're solving a problem that requires complicated type system - don't use Go. If you're writing a UI - don't use Go. If you like 20 layers of abstraction - don't use Go.

If you're writing a product like I am, with similar constraints, then Go is an excellent fit.

People for some reason like to pretend everyone is working on the same problem that they are, and have the same requirements they do.

This person doesn't like Go, and that's fine. I have no doubt I'd be able to solve their problem in Go, and I have no doubt they'd be able to solve my problem in Java.

[DogLover_]

Thats fair! I just don't agree with the readable part and thinking. I personally get tired having to look at all the archaic boilerplate to find the actual logic that I want to reason about.

[verdverm]

Java code has a lot of boilerplate too, consider a "hello world" program, then consider a program split into multiple files in a single directory

[therealdrag0]

I think both Java and go are too verbose and noisy on the eyes.

[verdverm]

I won't disagree with that. At the same time, I loathe code where I cannot comprehend what's going on unless I'm an expert in the syntax and esoteric language features. I spend more time looking at other people's code than my own.

Go's advantage here is that everyone's code has a much higher similarity score than other languages, both in syntax and semantics

Go was written primarily for software engineering over implementing programming language research ideas. It's more than the language, it's also the tooling, automation, and simplicity around it.

[therealdrag0]

Having a standard formatter certainly helps. But not having rich modern features built-in means more custom/non-standard code, not less, that you have to read.

I haven’t used go in a few years so not familiar with how it’s improved. But not having basic container functions like ‘map’ was absolutely bonkers.

[verdverm]

> having rich modern features

Also means having to understand a lot more syntax to understand what's going on

I would not lump map/reduce into this category since they are trivial to implement with a function and a loop