Many people love it on HN, but for me coding in Go is a chore that makes me disinterested in my job. After 3 years of working with it, I dispute the claims about readability and simplicity. In Go, you solve problems by outputting inhuman amounts of code. It can feel productive, but most of it is just noise.
Of course just because I'm not well suited for it doesn't mean it's not for others. But there's a lot that we've collectively learned about programming, that's not acknowledged in Go's design.
You can start coding in it pretty fast, that much is true.
This was my experience as well. I inherited a codebase of very simple, well-written Go. Anytime I needed to go to the source to find out how the business logic was implemented, I ended up scrolling... and scrolling... and scrolling... collecting the information bit by bit like a scavenger hunt.
Go seems like it would be great for motivating someone to figure out the simplest possible way of solving a computing problem. Unfortunately for software development (but fortunately for humanity) not all problems allow engineers the freedom to brutally simplify the solution. Many domains come with hundreds of rules and exceptions that were all added for nontechnical, human-driven reasons, and your company probably does not have the power to throw out all existing business practices, human expectations, and regulatory requirements in your domain and replace them with something simple to implement. You just have to suck it up and implement the requirements in the most programmer-friendly way you can, and Go doesn't offer very good tools for that.
Admittedly, Go sets a higher floor than more expressive languages. A smart programmer with poor judgment can do a lot worse in Java or Scala than they could in Go. But Go's ceiling isn't much higher than its floor.
It's not noise if you can understand every line written though. That's maintainable code that will last the decades, instead of being replaced with the next hip language 5-10 years down the line.
If you don't have to think too much about what code does, you can get a better overview of what's going on.
Plus, there's more developers available if your code is simple. That is one unspoken (yet written down!) reason why Go was devised - to be able to have mediocre developers still be productive.
Clever code is illegible by most people, unless they wrote it, are very smart themselves, and are actually interested in the code in front of them.
Go code is readable and comprehensible by everyone.
> It's not noise if you can understand every line written though.
If I can understand every line of a 10,000 line program, is it not still noise compared to a 100 line program that accomplishes the same goal?
> If you don't have to think too much about what code does, you can get a better overview of what's going on.
That's the problem with Go. I do have to think about what the code does, because the ability to abstract things to a higher level is virtually nonexistent.
I don't have to think about what this code does at all. It's obvious. And I am extremely confident that there are no bugs. The Golang equivalent?
var tmp []item
var res []item
for _, item := range items {
for _, entry := range whitelist {
if item == entry {
tmp = append(tmp, item)
break
}
}
}
sort.Slice(res, func(i, j item) bool {
return tmp[i].Price < tmp[j].Price
})
for _, item := range items {
res = append(res, item.Name)
}
Sure I can understand every line of the latter. It's still noise. And it's only comprehensible by sitting down and carefully reading every single line. Are there bugs? I think not, but I'd have to think through it to be sure. Go took what should have been a simple problem and somehow turned it into something that would feel at home if I was writing a device driver.
I’m simply not convinced about that talking point. It’s an extraordinarily strong claim that it’s comprehensible to everyone.
Sure if you have a 100 lines of pure Go, that should be readable. But take a look for instance at the source for go tool cover. How much time do you need to spend to understand it? Then imagine Rob didn’t write it, but a junior. How much more convoluted would it be?
I'm as torn as some of the other commenters here as Go can feel stifling to me frequently, but I have to say I find Go's readability comes with a culture of reading the source, which can be powerful. Often if I'm using a Go tool and I have questions about exactly what it's doing under the hood, unlike other languages where I have to learn the localized style/conventions/patterns (are you using annotations? Dependency Injection? Thread pools or async?), I can just pop open the source and read it. That doesn't necessarily mean I'll _understand_ what I'm reading easily but it does let me pick up subtleties under the hood.
Hashicorp's tools are great examples; before you could find endless posts online about using their tools I'd often dive into portions of Consul or Nomad with questions. Both of these are complicated pieces of software and being able to read the source helped a lot. On the other hand, trying to debug Werkzeug and Flask in Python is a nightmare of objects inheriting weird properties and all sorts of control flow weirdness, despite Flask ostensibly being a lightweight web framework.
You’re conflating ease of understanding/reading Go code with complexity of a hard problem. I can personally read the standard library, or basically any library, and I regularly do to understand how stuff works under the hood. But certain problems are hard and are going to take time to understand the problem and solution versus a basic idea of some things the code is doing. Eg: reading how a RabbitMQ library is using a parameter versus understanding the entire protocol it’s handling. Go is very nice in being able to read other people’s code where other languages it’s extremely hard. (Eg: I’ve tried to read the code for SQL Alchemy in Python and it’s… very hard)
"It's not noise if you can understand every line written though. " It can still just be noise. Have you never seen getters and setters in Java? Error handling in Go is mostly just noise a well. I mean manually wrapping errors so that you can get a stack trace? Our codebase is littered with span calls that in Java could have been relegated to an AOP library.
In Go, you solve problems by outputting inhuman amounts of code.
The standard library manages to pack a lot of functionality in little code. Its probably not easy to write simple concise code in Go but it is certainly possible.
The standard library is good. If you can solve your problem by mostly using tools from the standard library in a short main package, Go works well. The work that I do unfortunately doesn't have that property.
The point you are responding to is not about using th stdlib, but implementing it. If you look at the stdlib itself, it adds lots of functionality without too much code, from scratch.
Most of it doesn't. Take a look at net/http. I'm not aware of anything it does that your package could not. Certainly nothing that would move the needle on succinctness.
The std lib is disciplined about using safe Go ideas except in the exceptional cases. I feel like it’s nothing that is enforced by the formal spec of the language, just that the std lib has an exceptional emphasis on making it really hard to walk away with misconceptions.
It really depends on what you're comparing Go to and on what kind of projects. Some languages will fair better for simplicity for some tasks. Other languages will fair better for simplicity for other tasks. Programming is a hugely vast topic with an infinite number of problems to be solved in an infinite number of ways.
Of course just because I'm not well suited for it doesn't mean it's not for others. But there's a lot that we've collectively learned about programming, that's not acknowledged in Go's design.
You can start coding in it pretty fast, that much is true.