You guys can keep complaining about how go is too verbose, but I love everything about go.
I love the error handling, I love the forced formatting, i love all the linting it has including style guides. When you read other source code it's so easy to understand it and make sense of it. Thank you go team
(Ok, maybe I am a bit sceptical with the latest generic additions, but overall it's a great language. I love it.)
Oh yeah totally agree. I don't understand why someone would want to write `slices.Contains(s, needle)` when you can write this beautiful poem like a Shakespeare in VSCode:
found := false
for _, v := range s {
if v == needle {
found = true
break
}
}
Oh and I totally want to build a stack trace manually. It's like doing cardio to me.
if err != nil {
return fmt.Errorf("my function name but in spaces: %w", err);
}
This is very elegant by the way, so that we need errors.Is now, which has to dynamically check if the error implements Unwrap() error or Unwrap() []error. Because having any language facilities for error handling is harmful.
> Because having any language facilities for error handling is harmful.
No, making error handling verbose mandatory is meant to make developers do mental cardio and be mindful of what they are doing.
You can either keep developers mindful or punish them after they make a mistake by shouting at them and make them waste their time during re-compiling.
P.S.: Yes, I love Go's error handling mechanics, which makes handling errors mandatory, not optional, and if you ignore the error, this is a deliberate choice and the burden is on the developer.
Go does the former, Rust does the latter.
This comment could make the same point and be even more effective if wasn't written as a snarky retort in violation of several of the guidelines of the site ( https://news.ycombinator.com/newsguidelines.html )
I don't say it's perfect, but right in this moment I feel most comfortable with go and I don't mind jumping through a few hoops or writing things multiple times
Also, if error wrapping hurts you so much (I don't use it), just implement a project-specific error that works how you want. This could be something that is JSON serializable, that captures a line number at each return site, etc. It will take like 10 minutes to get your project's errors working exactly how you want.
My projects usually do -
log.SetFlags(log.LstdFlags | log.Lshortfile)
// ...
if err != nil {
log.Println(err)
return errors.New("Error doing the thing.")
}
That essentially logs a stack trace with line numbers up the whole error chain, each return adding the outer context. I only ever use errors.Is for os.ErrNotExist.
1. There is nothing stopping you from implementing a Contains function.
2.That error handling is one of the best features. It makes me explicitly acknowledge the errors instead of letting them just happen. No error goes unnoticed!
Each if err != nil is an explicit reminder to check, do I need to clean up? Do I need to log this error to a file?
"And no more oh an error happened I wonder where"
With LLMs verbosity is not an excuse anymore. Just generate it and focus on other things then
found := false
for _, v := range s {
if v == needle {
found = true
break
}
}
Do you see it? It copies the v into a local variable, which could be tremendously wasteful if it's a large struct. You should instead be taking a pointer to s[i] and comparing the value there with `needle`.
If you'd used `slices.Contains(s, needle)`, on the other hand, it could have such a performance bug in it and you'd never know.
Even if you prefer manually checking for errors after every call that might fail, I fail to see how one can love go’s verbosity. Compare go’s
foo, err := bar()
if err != nil {
return ERR;
}
with something like (hypothetical)
foo := bar() ||| return ERR;
where the compiler, seeing that bar returns an Either<int,err> can enforce the presence of the ||| clause or, alternatively, require later code to check for errors if the ||| clause isn’t present. I think that’s both more robust (prevents one from forgetting to check for errors) and shorter (allowing for showing a lot more code on a screen or page)
I think the examples are both bad along different axis. One occupies more lines, the other results in _more_ and uglier syntax. They’re both bad. So the question is which axis is worse.
While the first occupies more lines I suspect I’d spend less time spotting it in the code. The physical shape of the expression is something my brain is used to seeing after 40 years of programming. Even when code grows more complex.
The second is OK when it stands alone, but I am not so certain it would be as easy to spot in more complex surroundings. Even on a single line, there is something a bit ugly about the code. Even before we get to the desperate triple-pipe. That kind of reminds me of the desperate attempts at repairing JS after they realized its equality semantics were shot. Just heap more characters on it.
The thing is: it is actually very hard to judge how ergonomic a language is by just looking at it. You have to use it and you have to use it enough to realize where the paint points really are. I’ve read through a lot of the responses in this discussion and I’ll be honest: I think a lot of people who criticize other languages (be they Rust, C, Go or whatever) aren’t very fluent in them. It takes a couple of years to develop fluency.
There are so many proposals for improving errors, even half implemented ones that are dropped. I even stopped checking pros and cons after a few. As ultimately everything got rejected and the message is that you have to live with verbose checking with llms now.
100% with you on every point. It's the only language I've worked in that lets me read other codebases without an hour or two of "wut?" happening, so they did something right!
When I moved from Kotlin to Go because of a job change. it was painful. Apart from its runtime benefits, it is overrated IMO. it lacks basic conveniences. Go is not a simple language, it is a primitive language.
I love how during prototyping, the compiler will tell me off for having an unused variable and fail to compile. I totally love the idea of crashing when writing on a closed channel.
I think that the best feature that go was able to create is a very strong community around the language, where practices are as important as the language itself. Maybe these practices are what makes the community strong?
Also not adding every single feature that could be nice is a good thing to me. Yes, there is a lot of syntactic sugar you could add, but this just ends up in even more debates and in the end it doesn't matter that much. There is a very clear path how to achieve regular things in go and that works fine for now
I do love the batteries included attitude. Having benchmarking included as well as a mechanism to run tests to check (test) for race-conditions right from the language/build tool is amazing.
My only wish is that go could become less verbose. There are several frontends to go that are more compact, compile down into golang, and then let you enjoy all the benefits.
For SpiceDB[0], we've found a lot of success using this framework to define our own analyzers; it's probably 10x easier now with LLMs. No need for tribal knowledge or more time wasted on code review if you can just turn it into a linter and move on.
the most valuable thing in this article for me was this:
The early loop looked like this:
/goal improve the perf by 20%
-> a great deal of plausible code
-> a confusing benchmark
-> another plausible patch
Later it looked like this:
find the expensive work
-> explain why it happens
-> change one mechanism
-> compare with the previous Rust revision
-> test the complete application
-> retain, revise, or reject
Someone in the thread about the Ruff update ingenuously said they wished Go had something like Ruff, being unaware of this framework. In that thread, someone seemed to take it as a sign that many people who might care to know about this don't yet, so they made a dedicated post for it.
The Go team's emphasis on tooling in the service of software engineering is a boon to human and agentic development alike. Give yourself and your agents great tools.
An example from one of my recent projects: https://github.com/verdverm/gmd/blob/main/Makefile (give agents simple "tool calls" instead of needing to divine the correct args/flags every time, essentially invocable agents.md content)
One of the interesting things to call out from this is using build tags for testing { unit, coverage, recorded, real api }, with the buffet allowing the agent to iterate faster and more targeted. I tend to run the linting and coverage in a new session, have a report generated, and then another fresh session to start dealing with gaps.
You guys can keep complaining about how go is too verbose, but I love everything about go.
I love the error handling, I love the forced formatting, i love all the linting it has including style guides. When you read other source code it's so easy to understand it and make sense of it. Thank you go team
(Ok, maybe I am a bit sceptical with the latest generic additions, but overall it's a great language. I love it.)
Oh yeah totally agree. I don't understand why someone would want to write `slices.Contains(s, needle)` when you can write this beautiful poem like a Shakespeare in VSCode:
Oh and I totally want to build a stack trace manually. It's like doing cardio to me.
This is very elegant by the way, so that we need errors.Is now, which has to dynamically check if the error implements Unwrap() error or Unwrap() []error. Because having any language facilities for error handling is harmful.
> Because having any language facilities for error handling is harmful.
No, making error handling verbose mandatory is meant to make developers do mental cardio and be mindful of what they are doing.
You can either keep developers mindful or punish them after they make a mistake by shouting at them and make them waste their time during re-compiling.
P.S.: Yes, I love Go's error handling mechanics, which makes handling errors mandatory, not optional, and if you ignore the error, this is a deliberate choice and the burden is on the developer. Go does the former, Rust does the latter.
33 replies →
This comment could make the same point and be even more effective if wasn't written as a snarky retort in violation of several of the guidelines of the site ( https://news.ycombinator.com/newsguidelines.html )
4 replies →
I don't say it's perfect, but right in this moment I feel most comfortable with go and I don't mind jumping through a few hoops or writing things multiple times
5 replies →
https://pkg.go.dev/slices#Contains ?
Also, if error wrapping hurts you so much (I don't use it), just implement a project-specific error that works how you want. This could be something that is JSON serializable, that captures a line number at each return site, etc. It will take like 10 minutes to get your project's errors working exactly how you want.
My projects usually do -
That essentially logs a stack trace with line numbers up the whole error chain, each return adding the outer context. I only ever use errors.Is for os.ErrNotExist.
1 reply →
1. There is nothing stopping you from implementing a Contains function.
2.That error handling is one of the best features. It makes me explicitly acknowledge the errors instead of letting them just happen. No error goes unnoticed!
Each if err != nil is an explicit reminder to check, do I need to clean up? Do I need to log this error to a file?
"And no more oh an error happened I wonder where"
With LLMs verbosity is not an excuse anymore. Just generate it and focus on other things then
You forgot to put /s after your post.
Your handwritten one has a major performance bug:
Do you see it? It copies the v into a local variable, which could be tremendously wasteful if it's a large struct. You should instead be taking a pointer to s[i] and comparing the value there with `needle`.
If you'd used `slices.Contains(s, needle)`, on the other hand, it could have such a performance bug in it and you'd never know.
6 replies →
> I love the error handling
Even if you prefer manually checking for errors after every call that might fail, I fail to see how one can love go’s verbosity. Compare go’s
with something like (hypothetical)
where the compiler, seeing that bar returns an Either<int,err> can enforce the presence of the ||| clause or, alternatively, require later code to check for errors if the ||| clause isn’t present. I think that’s both more robust (prevents one from forgetting to check for errors) and shorter (allowing for showing a lot more code on a screen or page)
I think the examples are both bad along different axis. One occupies more lines, the other results in _more_ and uglier syntax. They’re both bad. So the question is which axis is worse.
While the first occupies more lines I suspect I’d spend less time spotting it in the code. The physical shape of the expression is something my brain is used to seeing after 40 years of programming. Even when code grows more complex.
The second is OK when it stands alone, but I am not so certain it would be as easy to spot in more complex surroundings. Even on a single line, there is something a bit ugly about the code. Even before we get to the desperate triple-pipe. That kind of reminds me of the desperate attempts at repairing JS after they realized its equality semantics were shot. Just heap more characters on it.
The thing is: it is actually very hard to judge how ergonomic a language is by just looking at it. You have to use it and you have to use it enough to realize where the paint points really are. I’ve read through a lot of the responses in this discussion and I’ll be honest: I think a lot of people who criticize other languages (be they Rust, C, Go or whatever) aren’t very fluent in them. It takes a couple of years to develop fluency.
There are so many proposals for improving errors, even half implemented ones that are dropped. I even stopped checking pros and cons after a few. As ultimately everything got rejected and the message is that you have to live with verbose checking with llms now.
100% with you on every point. It's the only language I've worked in that lets me read other codebases without an hour or two of "wut?" happening, so they did something right!
Have you tried to read the Kubernetes or Docker codebases?
4 replies →
When I moved from Kotlin to Go because of a job change. it was painful. Apart from its runtime benefits, it is overrated IMO. it lacks basic conveniences. Go is not a simple language, it is a primitive language.
I love how during prototyping, the compiler will tell me off for having an unused variable and fail to compile. I totally love the idea of crashing when writing on a closed channel.
If you are prototyping, assign unused to the underscore.
foo := thinger()
_ = foo # no longer unused
If generics were going to ruin the language, they would have by now. I think you can rest easy.
The greatest thing about generics is … that they're not used much if at all.
Which is a great way to make sure they're not overused, which in my experience is better than underuse.
I think that the best feature that go was able to create is a very strong community around the language, where practices are as important as the language itself. Maybe these practices are what makes the community strong?
Also not adding every single feature that could be nice is a good thing to me. Yes, there is a lot of syntactic sugar you could add, but this just ends up in even more debates and in the end it doesn't matter that much. There is a very clear path how to achieve regular things in go and that works fine for now
I do love the batteries included attitude. Having benchmarking included as well as a mechanism to run tests to check (test) for race-conditions right from the language/build tool is amazing.
My only wish is that go could become less verbose. There are several frontends to go that are more compact, compile down into golang, and then let you enjoy all the benefits.
It doesn't have a lot of style guides or linting though. You have to install and configure quite a lot of tooling for that
For SpiceDB[0], we've found a lot of success using this framework to define our own analyzers; it's probably 10x easier now with LLMs. No need for tribal knowledge or more time wasted on code review if you can just turn it into a linter and move on.
[0]: https://github.com/authzed/spicedb/tree/main/tools/analyzers
This isn't new?
You can see it's used by _a lot_ of linters already:
https://pkg.go.dev/golang.org/x/tools/go/analysis?tab=import...
It was mentioned in the Ruff article comments and probably reposted.
I visited that link three years ago. It isn't new. It's nifty, though.
This is one of the least informative discussions in HN front page that I remember.
the most valuable thing in this article for me was this:
The early loop looked like this:
Later it looked like this:
So what is context? This isn't new and why the submission ?
Someone in the thread about the Ruff update ingenuously said they wished Go had something like Ruff, being unaware of this framework. In that thread, someone seemed to take it as a sign that many people who might care to know about this don't yet, so they made a dedicated post for it.
Thanks
I was just looking for this. Will give it a spin.
Can these sorts of primitives be used to create broader "architectural" linters?
Yes, and I use them often in the context of writing adversarial ‘go vet’ style anti-slop analyzers that run pre-commit.
The Go team's emphasis on tooling in the service of software engineering is a boon to human and agentic development alike. Give yourself and your agents great tools.
An example from one of my recent projects: https://github.com/verdverm/gmd/blob/main/Makefile (give agents simple "tool calls" instead of needing to divine the correct args/flags every time, essentially invocable agents.md content)
One of the interesting things to call out from this is using build tags for testing { unit, coverage, recorded, real api }, with the buffet allowing the agent to iterate faster and more targeted. I tend to run the linting and coverage in a new session, have a report generated, and then another fresh session to start dealing with gaps.
Another super cool testing tool in the Go internal source is `testscript`. Roger Peppe extracted a number of those internal utilities here https://github.com/rogpeppe/go-internal/tree/master/testscri...
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
It's spam look at the users history. They just comment the same thing everywhere
This is another instance of a spam attack I first noted over a year ago. New accounts all set up to keep linking to this one particular Stack Overflow question. Ref. https://meta.stackoverflow.com/questions/433930/repeated-wav...