10 ms·

Go is a distillation of many decades of software engineering experience. The people behind Go (e.g., Russ Cox) have learned from history. The peanut gallery lo

Go is a distillation of many decades of software engineering experience. The people behind Go (e.g., Russ Cox) have learned from history. The peanut gallery loves to complain about superficial aspects of Go. Typically these are people with little or no actual experience using the language and tools. They fixate on imagined problems that don't matter in practice. But anyone who has used Go full-time for a few years is likely to deeply respect and appreciate it.

mperham 5y ago
I couldn't have said it better. Other ecosystems decided to use lots of little dependencies and I can't imagine a worse engineering decision. This way lies madness.
geodel 5y ago
Agreed. There are some folks very closely associated with other language ecosystems but they spend more time in endlessly critiquing every little thing about Go.
- laurent92 5y ago
  I wonder how there are not more NPM vulnerabilities. We control nothing. Especially during war.
laerus 5y ago
- icholy 5y ago
  let foo; try { foo = await is_this_better(); } catch (err) { console.log("if err != nil doesn't seem so bad all of a sudden"); }
  - lostcolony 5y ago
    receive {lack_of_erlang_error_handling_is_a_missed_opportunity, true} -> ok after 0 -> throw let_it_crash end.
  - ryeguy 5y ago
    This comparison misses the point. Go requires you to bubble up errors manually, that's the difference.
    - randomdata 5y ago
      At least one can respect Go for being consistent, even if requires a little extra manual labour. The languages that require you to manually bubble up some types, but not others, are just bizarre. Like, they're onto something neat, but why stop halfway? I don't want to put in the manual work for any type. If I've decided the manual effort is worthwhile, I don't want weird exceptions to worry about. Pick a lane, programming languages.
  - mFixman 5y ago
    func ThisCouldUseExceptions() error { err := Exceptions() if err != nil { return terrors.Propagate(err) } err = GeneraliseBetter() if err != nil { return terrors.Propagate(err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return terrors.Propagate(err) } value, err := AlsoTheyHelp() if err != nil { return terrors.Propagate(err) } chained_val, err := WithChaining(value) err = AndPreventAccidentallyIgnoringErrors(chained_val) if err != nil { return terrors.Propagate(err) } }
    - philosopher1234 5y ago
      func ThisCouldUseExceptions() error { err := Exceptions(arg) if err != nil { return fmt.Errorf("if a '%v' dev: %w", err) } err = GeneraliseBetter() if err != nil { return fmt.Errorf("has to actually: %w", err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return fmt.Errorf("read these errors: %w", err) } value, err := AlsoTheyHelp() if err != nil { return fmt.Errorf("they will actually be: %w", err) } chained_val, err := WithChaining(value) if err != nil { return fmt.Errorf("useful: %w", err) } err = AndPreventAccidentallyIgnoringErrors(chained_val) if err != nil { return fmt.Errorf("this isnt a real problem: %w", err) } }
zdw 5y ago
Some of those "superficial aspects" are really annoying. For example, Go forced version tags to have a `v` prefix in git repos for their dependency system, which broke a whole host of CI tools that expected plain numeric values for release versions. There's a outsized amount of Go-specific special casing for this one seemingly arbitrary decision in multi-language CI systems.
- morelisp 5y ago
  > Go forced version tags to have a `v` prefix in git repos for their dependency system "Forced" is a bit strong - you can pin any ref, the vX tags just also have some default semver-ish treatment. > a whole host of CI tools that expected plain numeric values for release versions Like what? Pure numeric tags are also ambiguous with git refs; this can be worked around by careful arguments, but it means most tooling was already broken when dealing with such things. If you were one of the people using "release-X.Y.Z" or "rXYZ" I feel for you though. > Go-specific special casing 'v' tags have been idiomatic for ages. Semver 1.0 went so far as to mandate it in 2010, though that was taken out in 2.0. https://semver.org/spec/v1.0.0.html#tagging-specification-semvertag https://semver.org/spec/v1.0.0.html#tagging-specification-se...
kelnos 5y ago
I haven't used Go full-time, but I have used it on and off for more than a few years. There are certainly things I respect and appreciate about it, but there are also a lot of things that annoy me about it. Some that you might consider "superficial", I consider important. If I'm going to be spending all day in a language, I want the ergonomics of the language itself to work with me, not against me, and Go often does not fit the bill there (for me -- others' opinions are free to differ). I don't find most of this article to be all that persuasive. Rust, for example, has a separate lock file, which the article derides. That doesn't really make sense, as lock files are also checked into source control, so you get the same benefit that Go touts of go.mod. My threat model doesn't consider having a separate module/package repository to be much of a risk, so I don't care about that point all that much. Admittedly, having source control be the source of truth is just simpler, which is good, but it also means that module publishers can pull versions (or the entire module) for arbitrary, selfish reasons, and then the community is left with a lot of difficulty (there's also a big problem if someone wants to move their code from GitHub to GitLab or something like that). Centralized module repositories can remove this problem if they choose to. The Go Module Mirror appears to be a hack that tacitly admits this problem. I did find the "a little copying..." bit to be interesting, and I agree with it. With Rust, pulling in a single dependency tends to pull in many tens of transitive dependencies, which I don't like.
- merely-unlikely 5y ago
  "but it also means that module publishers can pull versions (or the entire module) for arbitrary, selfish reasons, and then the community is left with a lot of difficulty" By default go get will download the source code into the pgk/mod folder. So if a module is pulled by the author, you can just use your copy of the source to fork it.
  - kelnos 5y ago
    That's fine if you've already downloaded it, but doesn't help for people trying to pull it for the first time, either as a direct or transitive dependency.
s-video 5y ago
I love Go as well, but I don't think being the first to kick up a flame war will do anything for us.
______-_-______ 5y ago
For a decade+, people complained that go lacks generics. Would you say those were all people with no experience fixated on an imaginary problem that doesn't matter, or were the complaints valid?
- philosopher1234 5y ago
  I would say that it is legitimately annoying to have to copy and paste data structures, but mostly doesn't matter, and the intensity of the complaining does not match the intensity of the problem. People mostly just dont like the expertise of the go devs.
bjackman 5y ago
I've been using Go for a couple of years now and it's funny: I do not love Go, I just work effectively in it. I am not passionate about it, but I recommend it for absolutely all appropriate use-cases. It doesnt go for intellectual satisfaction, it goes for getting shit done. You have to respect it for being so radically bland.
- 0des 5y ago
  Go is boring and that's appreciated by myself and others in my peer group.
- jatone 5y ago
  I get intellectual satisfaction from solving the problems not from the language I use to do it. go hits a fantastic blend in that regard.
nu11ptr 5y ago
Couldn't disagree more (I spent years writing Go, and now Rust - will NEVER go back)
azth 5y ago
I've used golang at my employer for several years now, and I came out respecting and appreciating the design decision that have and are going into Java/C#/Kotlin much more given the atrocities I've seen written in golang.
- sbmthakur 5y ago
  Are those some common Golang anti-patterns?
seabrookmx 5y ago
A few years of Golang under my belt and I still hate it. Russ Cox and co. seem incredibly arrogant to me in that they can ignore decades of PL research only to reinvent a bizarre way of achieving what other languages do in a more standard way (package management, error handling), or just adopt that standard super late (generics). Go has some great qualities and you can make great software with it no doubt. But I find the development of the language frustrating to witness, not inspiring.
- pphysch 5y ago
  What is your favorite PL?
  - seabrookmx 5y ago
    C# probably. Though I enjoy Typescript and Python as well. C# has generics, exceptions, is the birthplace of async/await, has LINQ, an unmatched standard library, a great build system and package management system, is open source, cross platform, fast.. It doesn't compile to a single native binary unlike golang which is a bummer. But 95% of my software ships as a container so this isn't too big of deal for me. The MS-provided base images are really good too.
- morelisp 5y ago
  Who is doing "PL research" in package management?
throwaway23i92 5y ago

mperham 5y ago

I couldn't have said it better. Other ecosystems decided to use lots of little dependencies and I can't imagine a worse engineering decision. This way lies madness.

geodel 5y ago

Agreed. There are some folks very closely associated with other language ecosystems but they spend more time in endlessly critiquing every little thing about Go.

laurent92 5y ago
I wonder how there are not more NPM vulnerabilities. We control nothing. Especially during war.

laerus 5y ago

icholy 5y ago
let foo; try { foo = await is_this_better(); } catch (err) { console.log("if err != nil doesn't seem so bad all of a sudden"); }
- lostcolony 5y ago
  receive {lack_of_erlang_error_handling_is_a_missed_opportunity, true} -> ok after 0 -> throw let_it_crash end.
- ryeguy 5y ago
  This comparison misses the point. Go requires you to bubble up errors manually, that's the difference.
  - randomdata 5y ago
    At least one can respect Go for being consistent, even if requires a little extra manual labour. The languages that require you to manually bubble up some types, but not others, are just bizarre. Like, they're onto something neat, but why stop halfway? I don't want to put in the manual work for any type. If I've decided the manual effort is worthwhile, I don't want weird exceptions to worry about. Pick a lane, programming languages.
- mFixman 5y ago
  func ThisCouldUseExceptions() error { err := Exceptions() if err != nil { return terrors.Propagate(err) } err = GeneraliseBetter() if err != nil { return terrors.Propagate(err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return terrors.Propagate(err) } value, err := AlsoTheyHelp() if err != nil { return terrors.Propagate(err) } chained_val, err := WithChaining(value) err = AndPreventAccidentallyIgnoringErrors(chained_val) if err != nil { return terrors.Propagate(err) } }
  - philosopher1234 5y ago
    func ThisCouldUseExceptions() error { err := Exceptions(arg) if err != nil { return fmt.Errorf("if a '%v' dev: %w", err) } err = GeneraliseBetter() if err != nil { return fmt.Errorf("has to actually: %w", err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return fmt.Errorf("read these errors: %w", err) } value, err := AlsoTheyHelp() if err != nil { return fmt.Errorf("they will actually be: %w", err) } chained_val, err := WithChaining(value) if err != nil { return fmt.Errorf("useful: %w", err) } err = AndPreventAccidentallyIgnoringErrors(chained_val) if err != nil { return fmt.Errorf("this isnt a real problem: %w", err) } }

zdw 5y ago

Some of those "superficial aspects" are really annoying. For example, Go forced version tags to have a `v` prefix in git repos for their dependency system, which broke a whole host of CI tools that expected plain numeric values for release versions. There's a outsized amount of Go-specific special casing for this one seemingly arbitrary decision in multi-language CI systems.

morelisp 5y ago
> Go forced version tags to have a `v` prefix in git repos for their dependency system "Forced" is a bit strong - you can pin any ref, the vX tags just also have some default semver-ish treatment. > a whole host of CI tools that expected plain numeric values for release versions Like what? Pure numeric tags are also ambiguous with git refs; this can be worked around by careful arguments, but it means most tooling was already broken when dealing with such things. If you were one of the people using "release-X.Y.Z" or "rXYZ" I feel for you though. > Go-specific special casing 'v' tags have been idiomatic for ages. Semver 1.0 went so far as to mandate it in 2010, though that was taken out in 2.0. https://semver.org/spec/v1.0.0.html#tagging-specification-semvertag https://semver.org/spec/v1.0.0.html#tagging-specification-se...

kelnos 5y ago

I haven't used Go full-time, but I have used it on and off for more than a few years. There are certainly things I respect and appreciate about it, but there are also a lot of things that annoy me about it. Some that you might consider "superficial", I consider important. If I'm going to be spending all day in a language, I want the ergonomics of the language itself to work with me, not against me, and Go often does not fit the bill there (for me -- others' opinions are free to differ). I don't find most of this article to be all that persuasive. Rust, for example, has a separate lock file, which the article derides. That doesn't really make sense, as lock files are also checked into source control, so you get the same benefit that Go touts of go.mod. My threat model doesn't consider having a separate module/package repository to be much of a risk, so I don't care about that point all that much. Admittedly, having source control be the source of truth is just simpler, which is good, but it also means that module publishers can pull versions (or the entire module) for arbitrary, selfish reasons, and then the community is left with a lot of difficulty (there's also a big problem if someone wants to move their code from GitHub to GitLab or something like that). Centralized module repositories can remove this problem if they choose to. The Go Module Mirror appears to be a hack that tacitly admits this problem. I did find the "a little copying..." bit to be interesting, and I agree with it. With Rust, pulling in a single dependency tends to pull in many tens of transitive dependencies, which I don't like.

merely-unlikely 5y ago
"but it also means that module publishers can pull versions (or the entire module) for arbitrary, selfish reasons, and then the community is left with a lot of difficulty" By default go get will download the source code into the pgk/mod folder. So if a module is pulled by the author, you can just use your copy of the source to fork it.
- kelnos 5y ago
  That's fine if you've already downloaded it, but doesn't help for people trying to pull it for the first time, either as a direct or transitive dependency.

s-video 5y ago

I love Go as well, but I don't think being the first to kick up a flame war will do anything for us.

______-_-______ 5y ago

For a decade+, people complained that go lacks generics. Would you say those were all people with no experience fixated on an imaginary problem that doesn't matter, or were the complaints valid?

philosopher1234 5y ago
I would say that it is legitimately annoying to have to copy and paste data structures, but mostly doesn't matter, and the intensity of the complaining does not match the intensity of the problem. People mostly just dont like the expertise of the go devs.

bjackman 5y ago

I've been using Go for a couple of years now and it's funny: I do not love Go, I just work effectively in it. I am not passionate about it, but I recommend it for absolutely all appropriate use-cases. It doesnt go for intellectual satisfaction, it goes for getting shit done. You have to respect it for being so radically bland.

0des 5y ago
Go is boring and that's appreciated by myself and others in my peer group.
jatone 5y ago
I get intellectual satisfaction from solving the problems not from the language I use to do it. go hits a fantastic blend in that regard.

nu11ptr 5y ago

Couldn't disagree more (I spent years writing Go, and now Rust - will NEVER go back)

azth 5y ago

I've used golang at my employer for several years now, and I came out respecting and appreciating the design decision that have and are going into Java/C#/Kotlin much more given the atrocities I've seen written in golang.

sbmthakur 5y ago
Are those some common Golang anti-patterns?

seabrookmx 5y ago

A few years of Golang under my belt and I still hate it. Russ Cox and co. seem incredibly arrogant to me in that they can ignore decades of PL research only to reinvent a bizarre way of achieving what other languages do in a more standard way (package management, error handling), or just adopt that standard super late (generics). Go has some great qualities and you can make great software with it no doubt. But I find the development of the language frustrating to witness, not inspiring.

pphysch 5y ago
What is your favorite PL?
- seabrookmx 5y ago
  C# probably. Though I enjoy Typescript and Python as well. C# has generics, exceptions, is the birthplace of async/await, has LINQ, an unmatched standard library, a great build system and package management system, is open source, cross platform, fast.. It doesn't compile to a single native binary unlike golang which is a bummer. But 95% of my software ships as a container so this isn't too big of deal for me. The MS-provided base images are really good too.
morelisp 5y ago
Who is doing "PL research" in package management?

throwaway23i92 5y ago