8 ms·

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

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.)

BobbyJo 2mo ago
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!
- asdf88990 2mo ago
  Have you tried to read the Kubernetes or Docker codebases?
  - thiht 2mo ago
    Kubernetes is a behemoth, but the Docker (Moby) source code is actually pretty easy to get into (if you're already a Docker user and understand how containers work)
    - asdf88990 2mo ago
      If you think Docker code is easy to get into then you haven’t seen clean code.
      - thiht 2mo ago
        The point is in Go it's pretty hard to write code so ugly that it'll be hard to read. I'm actually quite confident I could quickly onboard on almost any Go codebase (Kubernetes might be an exception). When I used to work with Java, I very rarely even tried to read the source code of my dependencies because it was unreadable.
  - BobbyJo 2mo ago
    Yes, I find the K8s codebase pretty easy to read actually, but I am biased since I work with K8s and the codebase makes a lot of sense when you understand what everything does already.
jerf 2mo ago
If generics were going to ruin the language, they would have by now. I think you can rest easy.
- ncruces 2mo ago
  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.
wannabe44 2mo ago
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.
- logicchains 2mo ago
  Your handwritten one has a major performance bug: 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.
  - mathisfun123 2mo ago
    > on the other hand, it could have such a performance bug in it and you'd never know. wut...? the debate isn't between closed (incompetent) source and open (competent) source - the debate is between verbose language and expressive language.
  - kajman 2mo ago
    > 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. Perhaps you're much better at programming than I am, but I prefer these semantics in a language because I figure they're much more likely to have been optimized empirically, support vectorization, and be less buggy than another rote loop I'm trying to speed through.
gempir 2mo ago
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
Someone 2mo ago
> 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 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)
- mayama 2mo ago
  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.
- bborud 2mo ago
  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.
eptcyka 2mo ago
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.
- sethammons 2mo ago
  If you are prototyping, assign unused to the underscore. foo := thinger() _ = foo # no longer unused
spockz 2mo ago
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.
aaa_aaa 2mo ago
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.
vander_elst 2mo ago
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?
- b7e7d855b448 2mo ago
  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

BobbyJo 2mo ago

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!

asdf88990 2mo ago
Have you tried to read the Kubernetes or Docker codebases?
- thiht 2mo ago
  Kubernetes is a behemoth, but the Docker (Moby) source code is actually pretty easy to get into (if you're already a Docker user and understand how containers work)
  - asdf88990 2mo ago
    If you think Docker code is easy to get into then you haven’t seen clean code.
    - thiht 2mo ago
      The point is in Go it's pretty hard to write code so ugly that it'll be hard to read. I'm actually quite confident I could quickly onboard on almost any Go codebase (Kubernetes might be an exception). When I used to work with Java, I very rarely even tried to read the source code of my dependencies because it was unreadable.
- BobbyJo 2mo ago
  Yes, I find the K8s codebase pretty easy to read actually, but I am biased since I work with K8s and the codebase makes a lot of sense when you understand what everything does already.

jerf 2mo ago

If generics were going to ruin the language, they would have by now. I think you can rest easy.

ncruces 2mo ago
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.

wannabe44 2mo ago

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.

logicchains 2mo ago
Your handwritten one has a major performance bug: 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.
- mathisfun123 2mo ago
  > on the other hand, it could have such a performance bug in it and you'd never know. wut...? the debate isn't between closed (incompetent) source and open (competent) source - the debate is between verbose language and expressive language.
- kajman 2mo ago
  > 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. Perhaps you're much better at programming than I am, but I prefer these semantics in a language because I figure they're much more likely to have been optimized empirically, support vectorization, and be less buggy than another rote loop I'm trying to speed through.

gempir 2mo ago

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

Someone 2mo ago

> 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 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)

mayama 2mo ago
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.
bborud 2mo ago
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.

eptcyka 2mo ago

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.

sethammons 2mo ago
If you are prototyping, assign unused to the underscore. foo := thinger() _ = foo # no longer unused

spockz 2mo ago

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.

aaa_aaa 2mo ago

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.

vander_elst 2mo ago

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?

b7e7d855b448 2mo ago
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