[steve_adams_86]

One of the key things I like about Go, despite shortcomings, is your last point. Our team effortlessly shares Go code, and its tooling makes it so any of us at any time can easily compile and run projects without hassles or hang ups.

The other day we reviewed some oldish and complex code and it was so plain to see what it was doing and get back into the flow of that logic. I don’t find this happens with other languages as much.

I’m not saying Go is the right tool everywhere for everyone. I do love that about it though.

[shakezula]

Definitely agree with this. Go is one of the only languages I've worked in where I can jump into _any_ project and it feels familiar, I just have to dig around to get into the specifics.

I have never had that same familiarity from Python, Ruby, JavaScript. I think there's something to be said about that in Go's favor.

[jokethrowaway]

While I agree with you on the familiarity across different projects (and I applaud ideas like gofmt) - it's also very verbose code (due to the simplicity of the language).

That makes it very hard to read go code and build a mental model in your head.

[ctvo]

> it's also very verbose code (due to the simplicity of the language). That makes it very hard to read go code and build a mental model in your head.

Verbose does not equal complex usually.

Something that's a single method call on a built-in type may be 3 lines in Go. This doesn't make it hard to understand or keep in your head. "This iterates over a map" is the same regardless of the lines of code. You can very quickly skim verbose code, especially in a language like Go, where idioms and conventions are identical across many code bases.

[shakezula]

Agreed, somewhere else in this thread someone complained that Go doesn't have an object iterator function and I really don't understand how k, v := range <map> isn't an intuitive approach, especially when range is so common in Go. Sure, it might be two more lines of code but it's not like it any more difficult to reason about or mentally track.

[shakezula]

I agree that Go is a little bit more verbose, but I usually consider that an example of "explicit is better than implicit" and I like that Go shows me the internals a lot more than other languages. The one thing that really drew me to Golang over any other was that it was extremely _easy_ for me to build a mental model of fairly complex code.

Go's interfaces in particular feel like a really easy way to build clean, composable abstractions that make sense and hide complexity in the right way. The single-function-interface pattern is really one of my favorite things about Go lately.

[jariel]

We might want to highlight this more often that not.

Code legibility is starting to become a primary if not the primary factor for a lot of software these days, because that's what allows it to be maintained.

I think more analysis should be done on why this is for go. Java and C# should be similarly legible, they are not complex languages either. It's possible that go encourages certain paradigms.

[collyw]

This sounds great but thinking of my system at work, it´s not the language that is the problem. It´s all the moving parts that you need to get to play together nicely before you can even start to develop. Front end, back end, database, nginx proxies, email platforms.

[steve_adams_86]

Go has won here for us as well because it forces you to write very dumb code, resulting in exposing the logic of how systems interface in a very dumb but easy to understand way.

It may take some scanning to go through all the dumb code, but you typically won't get fooled by abstractions. Go offers so little in terms of abstractions that you can usually see right through them.

This won't be everyone's experience, but it has been mine very consistently across internal and 3rd party code.