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

41–50 of 526 posts

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

#41

Post by rand_r »

abtinf wrote: post #25
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…

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…

> never handled correctly

I’ve seen this argument, but if you look at real golang code and examples, it’s just a bunch of “if err nill” copy pasta on every line. It’s true that handling errors is painstaking, but nothing about golang makes that problem easier. It ends up being a manual, poor-man’s stack-trace with no real advantage over an automatically generated one like in Python.

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

#42

Post by tonfreed »

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…

Exactly. Every programming language is a tool in your toolbox, and you should choose the appropriate one for the job at hand. For me, that's Go around 95% of the time.

I have no need to worry about a 24 byte overhead for a slice allocation, if I did have to worry about that, I'd probably use C or Rust.

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

#43

Post by swiftcoder »

rand_r wrote: post #41
abtinf wrote: post #25

Earlier quoted context omitted.

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…

> never handled correctly I’ve seen this argument, but if you look at real golang code and examples, it’s just a bunch of “if err nill” copy pasta on every line. It’s true that handling errors is painstaking, but nothing about golang makes that problem easier. It ends up being a manual, poor-man’s stack-trace with no real advantage over an automatically generated one like in Python.

Which could be solved in one swipe by adding a Result sum type, and a ? operator to the language. This is more a self-inflicted limitation of Go, then a general indictment of explicit error handling.

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

#44

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)

#45

Post by stouset »

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…

Without fail, every single person I’ve seen rave about go’s error handling compares it only to exceptions as if that’s the only alternative.

On the flip side I have yet to find a person who’s familiar with sum types (e.g., Maybe, Option, Result) that finds the golang approach even remotely acceptable.

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

#46

Post by pif »

pif wrote: post #44
vasco wrote: post #33

Earlier quoted context omitted.

"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]

> People tend to forget that Golang was created on purpose for poor programmers.

Ergo: if you actually like it, you must not be that great a developer.

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

#47

Post by chikere232 »

vander_elst wrote: post #27

Currently onboarding to go. For me personally, it's too opinionated e.g. for: error handling, mutability, unit testing, naming conventions, lack of features like sum types. As a new joiner, some things have a "religious" feeling, like: the go gods have given us THE language and we must use it their way, without questioning too much. I have the feeling other languages are less opinionated and this allows for more ergo…

I suspect it's designed that way intentionally.

It's a language built to make it hard for new joiners to mindlessly add complexity, as the language itself will fight you. It makes it hard to add dependencies that aren't very visible and vendored in, it makes it hard to change how the language behaves with overloading, preprocessor magic or macros, and so on.

It's built to fit Google specifically, with their army of new grads, and deep investment into reinventing all the dependencies themselves, and having a huge monorepo.

If you're not google, you're gonna have a bad time, which is also good for google.

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

#49

Post by bsaul »

pif wrote: post #31
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 d…

How does RAII works in concurrent systems ? It seems to me you need to add compile-time object lifetime evaluation (as in rust) which so far incurs a high toll on language complexity.

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

#50

Post by bckr »

pif wrote: post #44
vasco wrote: post #33

Earlier quoted context omitted.

"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]

I don’t think this implies it can’t be the right tool for the job, even when everyone on the team is a good programmer.

I don’t think it implies that you can’t write good programs in it.

Post reply on HN