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

91–100 of 526 posts

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

#91

Post by quotemstr »

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…

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 this other error" support, debugger integration ("break the first time something goes wrong"), and tons of other useful features.

(Common Lisp conditions are even better, but you can't have everything.)

You can't just wave the word "goto" around as if it were self-evident that nonlocal flow control is bad. It isn't.

> And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about.

That's not been my experience at all. Writing exception safe code is a matter of using your language's TWR/disposable/RAII/etc. facility. A programmer who can't get this right is going to bungle explicit error handling too.

Oh, and sum types? Have you read any real world Rust code? Junior developers just add unwrap() until things compile. The result is not only syntactic clutter, but also a program that just panics, which is throwing an exception, the first time something goes wrong.

Many junior developers struggle with error handling in general. They'll ignore error codes. They'll unwrap sum types. They might... well, they'll propagate exceptions non-fat ally, because that's the syntactic default, and that's usually the right thing. We have to design languages with misuse in mind.

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

#93

Post by masklinn »

lkirkwood wrote: post #24
XorNot wrote: post #8

Earlier quoted context omitted.

When I started trying to teach myself Rust, the error handling story fell apart on me very quick. Like as soon as I wanted to try and get sensible reporting in their, suddenly we were relieving libraries, adding shims and fighting mismatched types and every article was saying the same thing: haha yeah it's kind of a problem. I'm very, very unsold on explicit error handling compared to exceptions for practical program…

I felt the same but after switching to anyhow and thiserror in pretty much every Rust project I work on I find it quite painless. It's not ideal to rely on crates for a core language feature but I never find myself fighting error types anymore. Have you tried those crates? Do you still hold that opinion?

You don’t need crates for it, anyhow is basically a better Box, if you just want the error signal you can use that. The main thing missing from the stdlib fur this use case is I don’t think there’s anything to easily wrap / contextualise errors built in.

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

#94

Post by monksy »

rvense wrote: post #38
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 - da…

That says more about the library design more than it does about the library.

There are much better examples of the operator overloading for example cons:

item :: item2

Later you can break that down in pattern matching.

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

#95

Post by eska »

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.

That’s to be expected since it is marketed towards beginner and casual programmers.

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

#96

Post by jonathanstrange »

richbell wrote: post #75
KingOfCoders wrote: post #65

Go: "I'm a simple language!" User uses Go for some time. User: "I hate you, you're a simple language!" Perhaps it's because I'm 50+, I love a simple language. I feel the "critique" is not very balanced, and I view judgements that are not balanced as weak, as everything in technology is about tradeoffs. I of course come to a different conclusion: https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our...

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

I have no idea why anyone would say it's not simple, it's super-simple. Learning how duck typing works with interfaces and how to use it is perhaps the only hurdle. In my experience, only certain BASIC dialects like VisualBasic are simpler.

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

#97

Post by ViewTrick1002 »

serbuvlad wrote: post #21

I love Go, so I am biased. However, the beautiful thing about Go is that it doesn't even attempt to prevent classes of bugs by making them impossible. It's a car with ABS but no lane assist, with power steering but no collision detection. Out of all the bugs which Go permits I have yet to see one which could survive in production for some time without being discovered. Almost all of them would cause a failure the fir…

Instead it is a plethora of footguns which are attempted to be managed through convention.

This post is always a scary read:

https://www.uber.com/blog/data-race-patterns-in-go/

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

#98

Post by eru »

instig007 wrote: post #69
zwnow wrote: post #53

Earlier quoted context omitted.

You can call us poor programmers if that boosts your ego. The industry is still built upon people who can build fast. Go allows that and so does Javascript. You might not like it but that's what is earning most people their bread nowadays.

> The industry is still built upon people who can build fast. Correction: the commercial software is, not the industry. The industry and corporations are capitalising on quality open-source software, meticulously written off working hours with a straight head and passion, and a great attention to details. The fact that you can write glue fast enough to satisfy your SLT is predicated on the presence of those quality c…

Lot of open source software is written by people who get paid for doing so.

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

#99

Post by dgellow »

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…

Go is as boring of a tool as it gets. Which is why I will happily use it

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

#100

Post by eru »

pif wrote: post #46
pif wrote: post #44

Earlier quoted context omitted.

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

Probably, yes. Though that's an empiric finding, and doesn't follow logically from the premises.
Post reply on HN