Hacker News new | ask | show | jobs
by shakezula 1950 days ago
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.
1 comments
jokethrowaway 1949 days ago
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.

link
ctvo 1949 days ago
> 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.

link
shakezula 1949 days ago
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.
link
shakezula 1949 days ago
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.

link