Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lies we tell ourselves to keep using Golang (2022)

fasterthanli.me

Post reply on HN
Print view View original

31–40 of 526 posts

Re: Lies we tell ourselves to keep using Golang (2022)

#31

Post by pif »

devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

> I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up.

I kind of see your point. In this very moment, it doesn't matter whether I agree. What I don't understand, though, is why (typically) people who abhor exceptions are among the fiercest defenders of garbage collection, which does add a “magic” and uncontrollable layer to object destruction.

Personally, having learned to love RAII with C++, I was shocked to discover that other languages discarded it initially and had to add it in later when they realized that their target developers are not as dummy as those choosing Golang.

Re: Lies we tell ourselves to keep using Golang (2022)

#32

Post by pif »

jchw wrote: post #22

Every time I read a critique of Go, I feel the same way: I'm still going to continue to use it anyways. The reason why I am going to continue to use it anyways is because while I understand that it has plenty of easily documented issues in theory (and that people regularly do actually run into in practice), I still find that it is one of the better programming languages in practice anyways. Some of the things that pe…

> I choose a language that I feel works well for me

Which is the wisest choice for everyone. Golang is only a problem when a manager imposes it on you.

Re: Lies we tell ourselves to keep using Golang (2022)

#33

Post by vasco »

pif wrote: post #32
jchw wrote: post #22

Every time I read a critique of Go, I feel the same way: I'm still going to continue to use it anyways. The reason why I am going to continue to use it anyways is because while I understand that it has plenty of easily documented issues in theory (and that people regularly do actually run into in practice), I still find that it is one of the better programming languages in practice anyways. Some of the things that pe…

> I choose a language that I feel works well for me Which is the wisest choice for everyone. Golang is only a problem when a manager imposes it on you.

"Manager imposes it on you" just means you work in a team rather than alone. You can pick whatever you like for side projects, of course you're going to use whatever your team uses otherwise.

Re: Lies we tell ourselves to keep using Golang (2022)

#34

Post by koito17 »

troupo wrote: post #12
devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

It's actually very rare that it should be the caller who has to handle the errors. Go, however, forces you to spread your error handling over a thousand little pieces with zero overview or control of what's happening. Rust eventually realised this and introduced try! and ? to simplify this

More importantly, Rust has the notion of a result type and it is designed to be both generic and composable.

A problem I often face in Go and TypeScript code is code that ignores errors, often unintentionally. For instance, many uses of JSON.parse in TypeScript do not check for the SyntaxError that may be thrown. In Go, it is common to see patterns like

  _ := foo.Bar()
  // assume Bar() returns error
This pattern exists to tell the reader "I don't care if this method returns an error". It allows one to avoid returning an error, but it also stops the caller from ever being handle to the error.

Also, the position of the error matters. While the convention in the stdlib is to return errors as the final value, this isn't necessarily followed by third party code.

Similarly, errors are just an interface and there is no requirement to actually handle returned errors. Even if one wants to handle errors, it's quite awkward having to use errors.As or errors.Is to look into a (possibly wrapped) chain of errors.

The benefit of Rust's Result is that

- position doesn't matter

- there is strong, static type checking

- the language provides operators like ? to effortlessly pass errors up the call stack, and

- the language provides pattern matching, so it's easy to exhaustively handle errors in a Result

The last two points are extremely important. It's what prevents boilerplate like

  if err != nil {
    return nil, err
  }
and it's what allows one to write type-safe code rather than guess whether errors.As() or errors.Is() should be used to handle a returned error.

Re: Lies we tell ourselves to keep using Golang (2022)

#36

Post by misonic »

While the article raises some valid critiques, it often overlooks the fundamental tradeoffs that make Go successful in its niche. Go’s simplicity is not a flaw but a deliberate choice, enabling rapid onboarding and maintainable code for large teams. Its explicit error handling may seem verbose but ensures clarity and avoids hidden surprises common in exception-heavy languages. The complaints about ecosystem isolation and tooling ignore the fact that Go provides powerful built-in tools like pprof and dlv, which are better suited for Go’s runtime than general-purpose alternatives. Go isn’t trying to be Rust or Python—it’s a pragmatic tool for scalable, performant systems.

Re: Lies we tell ourselves to keep using Golang (2022)

#38

Post by rvense »

akira2501 wrote: post #13

> I've mentioned "leaving struct fields uninitialized". This happens easily when you make a code change from something like this: Really? Are you not using gopls? It absolutely will warn you about this. And the mutex case. And a lot of the other similar criticisms. > Go not letting you do operator overloading, harkening back to the Java days where a == b isn't the same as a.equals(b) In languages that have it I've ne…

> In languages that have it I've never used operator overloading to produce anything good or that was obviously better than just using methods.

I used a Scala library for S3 once that overloaded + to mean upload.

    var bucket; var file;
    bucket + file;
Which is obviously bad and unnecessary.

It's really a feature that should be used very rarely by those who make basic libraries, but there it can make a lot of sense - data structures, numeric types, etc.

Re: Lies we tell ourselves to keep using Golang (2022)

#39

Post by pif »

vasco wrote: post #33
pif wrote: post #32

Earlier quoted context omitted.

> I choose a language that I feel works well for me Which is the wisest choice for everyone. Golang is only a problem when a manager imposes it on you.

"Manager imposes it on you" just means you work in a team rather than alone. You can pick whatever you like for side projects, of course you're going to use whatever your team uses otherwise.

[flagged]

Re: Lies we tell ourselves to keep using Golang (2022)

#40

Post by chikere232 »

forrestthewoods wrote: post #18
afiodorov wrote: post #14

Not sure why Go is compared to Rust all the time, whilst most appropriate comparison is Java.

Because someone decides what language to write a new thing in is very likely to consider Go and Rust. They are very unlikely to consider Java. Are Rust and Go sufficiently different that they should each be chosen in different cases? Sure! But that’s literally why someone would consider both and pick one.

They should consider Java though.

People have an irrational hate for it based on the enterprise cruft and horrible third party frameworks you can just completely ignore if you build a new thing

It's not good for commandline stuff but for a long running small service it is pretty great

Post reply on HN