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

121–130 of 526 posts

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

#121

Post by OtomotO »

kaoD wrote: post #55
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…

Many people against Go's error handling do not advocate for exceptions, but for a combination of an Either/Result type (for recoverable errors) and fully aborting (for unrecoverable errors).

Abort on the other hand is used WAY to liberally in Rust.

How I hate it, that every second function call can break my program when it's clearly not a "halt the world, it's totally unrecoverable that the user sent us nonsense" type.

Return a Result and get on with your life!

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

#122

Post by quotemstr »

maleldil wrote: post #119
quotemstr wrote: post #105

Earlier quoted context omitted.

Rust's error handling evolution is hilarious. In the beginning, the language designers threw out exceptions --- mostly, I think, because Go was fashionable at the time. Then, slowly, Rust evolved various forms of syntactic sugar that transformed its explicit error returns into something reminiscent of exceptions. Once every return is a Result, every call a ?, and every error a yeet, what's the difference between your…

> what's the difference between your program and one with exceptions Because errors as values are explicit. You're not forced to use ? everywhere; you can still process errors however you like, or return them directly to the calling function so they deal with it. They're not separate control flow like exceptions, and they're not a mess like Go's.

No, because you end up with a function coloring problem that way. A function that returns something other than Result has to either call only infallible code or panic on error, and since something can go wrong in most code, the whole codebase converges as time goes to infinity on having Result everywhere.

Yeah, yeah, you can say it's explicit and you can handle it how you want and so on, but the overall effect is just a noisy spelling of exceptions with more runtime overhead and fewer features.

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

#123

Post by OtomotO »

quotemstr wrote: post #91
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…

Hard disagree. Exceptions are actually good. They make code clear and errors hard to ignore. I've written a ton of code over decades in both exceptional and explicit-error languages and I'll take the former every day. There's no function color problem. No syntactic pollution of logic with repetitive error propagation tokens. Also, exception systems usually come with built in stack trace support, "this error caused by…

Bah, no, I hated that you had to wrap basically every code block in a try/catch in Java, because the underlying lib could change and suddenly throw a Runtime-Exception.

At the same time Checked Exceptions were a nightmare as well, because suddenly they were part of the contract, even though maybe wrong later.

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

#124

Post by ralegh »

nulld3v wrote: post #101
richbell wrote: post #75

Earlier quoted context omitted.

I wish the discourse that Go is a "simple" language would die. Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4 ). It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".

This 100%, I was just about to type a long rant up about this. There are so many weird parts of the language that took me forever to grasp, and in many cases, I still don't have an intuitive grasp of things. And plenty of other examples that aren't in that article: - You have a struct with an embedded interface. Does the outer struct satisfy the embedded interface? And can I type assert the outer struct into whatever…

> but do I really know without performing a benchmark?

Not really. But that’s one of Rob Pikes rules [1], I think the intention is to write whatever is simplest and optimize later. The programmer doesn’t need to remember 100 rules about how memory is allocated in different situations.

[1] https://users.ece.utexas.edu/~adnan/pike.html

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

#125

Post by underdeserver »

wokwokwok wrote: post #83
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 guess I feel bad for people who are particularly sensitive to the areas that Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. Well, that’s a stellar endorsement of the article, because that’s literally the point they’re making. You’ll use go. …and then regret it. …but by then it’ll be too late, and you’re stuck with it. I think the author makes a comp…

Uhh, maybe.

Where is the tradeoff analysis? Yeah, you might regret using Go when some zero value you forget to fill in somewhere pops up later and ruins your pipeline. But are you considering all the issues that didn't pop up because you chose Go?

Java's boilerplate code? Rust and C++'s lifetime analysis and memory management? C's lack of tooling? Python/Typescript's runtime errors? Functional languages' tiny employee pool? How much did trouble did you save by avoiding these?

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

#126

Post by clausecker »

stouset wrote: post #45
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.

I dislike sum-type based error handling. It is annoying syntactically and only really doable with lots of high-level combinators, which in turn hinder debuggability.

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

#127

Post by thaumasiotes »

WesolyKubeczek wrote: post #11

The article is great. The bigger picture, of course, is that it’s always “pick your poison”. On one hand, say, I love operator overloading, I love how Python does it (once you satisfy an interface, its operators Just Work). On the other hand, I can appreciate the choice not to do it at all because half of the ecosystem will do it, and another half won’t. Also, it would require implementing function overloading, and i…

> I love operator overloading, I love how Python does it (once you satisfy an interface, its operators Just Work).

Is this different from other styles of operator overloading? Why does it matter whether, when I want to overload the + sign, I need to define a function called `__add__` or `operator+`?

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

#128

Post by quotemstr »

OtomotO wrote: post #123
quotemstr wrote: post #91

Earlier quoted context omitted.

Hard disagree. Exceptions are actually good. They make code clear and errors hard to ignore. I've written a ton of code over decades in both exceptional and explicit-error languages and I'll take the former every day. There's no function color problem. No syntactic pollution of logic with repetitive error propagation tokens. Also, exception systems usually come with built in stack trace support, "this error caused by…

Bah, no, I hated that you had to wrap basically every code block in a try/catch in Java, because the underlying lib could change and suddenly throw a Runtime-Exception. At the same time Checked Exceptions were a nightmare as well, because suddenly they were part of the contract, even though maybe wrong later.

Checked exceptions are more trouble than they're worth. That doesn't make exceptions in general bad.

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

#129

Post by eru »

monksy wrote: post #10
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 would certainly argue against the claim that explicit error handling is far overkill. Where I agree: It forces you to think about all of the possibilities your code might generate. (This is more of a C question than it is with other languages) However, when abstracting blocks of code away, you don't always need to handle the error immediently or you may want to handle it down the stack. You're giving up a lot of re…

Rust handles this much better.

Error handling is still explicit, but it gives you the tools needed to make it less tedious.

Post reply on HN