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

I Want Off Mr. Golang's Wild Ride

fasterthanli.me

Post reply on HN
Print view View original

211–220 of 508 posts

Re: I Want Off Mr. Golang's Wild Ride

#211

Post by shazow »

hota_mazi wrote: post #132
Karunamon wrote: post #107

Earlier quoted context omitted.

Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.

Go does absolutely nothing to ensure you handle the error. The only thing in Go source code that you see more often than the boiler plate "if err != nil" is "a, _ = foo()". It's all too easy to ignore an error in Go.

> Go does absolutely nothing to ensure you handle the error.

Go has many community linters available, https://github.com/kisielk/errcheck is popular for checking unhandled errors.

If you'd like a combo-pack, check out https://github.com/golangci/golangci-lint which includes all of the popular linters in a configurable way.

Re: I Want Off Mr. Golang's Wild Ride

#212

Post by Thaxll »

pcwalton wrote: post #189
Karunamon wrote: post #107

Earlier quoted context omitted.

Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.

Go doesn't ensure that you handle errors, if the function doesn't have a return value other than the error. The compiler will happily let you silently drop the result of os.Mkdir() on the floor.

I'm no Rust expert, but Rust doesn't enforce that either.

There is no language that enforce error checking afaik.

Re: I Want Off Mr. Golang's Wild Ride

#213

Post by marcus_holmes »

Cyph0n wrote: post #177
marcus_holmes wrote: post #97

Earlier quoted context omitted.

I'd buy that if there hadn't been approximately 48764576459674 "Rust vs Go" (well, more usually "this is why Rust is way better than Go and you're some kind of moron if you're not switching to Rust today") articles in the last few months.

> "this is why Rust is way better than Go and you're some kind of moron if you're not switching to Rust today" I didn't see that anywhere in this article. Rust was just used to show an alternative approach.

[citation] last two lines of the article:

"At this point in time, I deeply regret investing in Go.

Go is a Bell Labs fantasy, and not a very good one at that."

Re: I Want Off Mr. Golang's Wild Ride

#214

Post by brianberns »

hinkley wrote: post #161
palerdot wrote: post #78

Earlier quoted context omitted.

Python is 'strongly' typed `dynamic` language!!!

There are two technical conversations I don't have because everybody just gets mad and nothing gets resolved. (Note to reader: if you haven't guessed already, this means I am not going to be reading replies to this thread and certainly not responding to them. Go outside and get some air.) One, the Monty Hall problem. You either get it or you will die on a hill of misunderstanding. I've never seen anyone's mind be cha…

Off topic: I’ve had success explaining the Monty Hall problem by generalizing it to, say, 10,000 doors, where Monty opens 9,998 of them before allowing you to switch. People seem to intuitively understand that it’s extremely likely that the prize is behind the other door.

Re: I Want Off Mr. Golang's Wild Ride

#215

Post by masklinn »

delusional wrote: post #94
gameswithgo wrote: post #18

A lot of people seem to be missing an overarching point, which is the benefits of a language having Sum types, so that edge cases can be represented clearly, and in a way where the consumer of the api can't fail to know they exist, and can't fail to handle them. Anyone thinking of making a new language today, should really get some familiarity with Option and Result types. They make so many things not only safer, but…

It's curious that after pretty universally rejecting checked exceptions, they have now returned as result.

Checked exceptions were universally rejected not because they are intrinsically bad but because the language support was awful (e.g. could not wrap or abstract over a nested object possibly rethrowing), they were sitting right next to unchecked exception with limited clarity, guidance and coherence as to which was which, and they are so god damn ungodly verbose, both to (re)throw and to convert.

Results are so much more convenient it's not even funny, but even without that you could probably build a language with checked exceptions where they're not infuriatingly bad (Swift has something along those lines, though IIRC it doesn't statically check all the error types potentially bubbling up so you know that you have to catch something, not necessarily what).

Re: I Want Off Mr. Golang's Wild Ride

#216

Post by Thaxll »

hota_mazi wrote: post #132
Karunamon wrote: post #107

Earlier quoted context omitted.

Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.

Go does absolutely nothing to ensure you handle the error. The only thing in Go source code that you see more often than the boiler plate "if err != nil" is "a, _ = foo()". It's all too easy to ignore an error in Go.

This is fud, I've never seen in Go code people dropping the err with _.

The reason why you don't see that is because you have to be explicit about that, it's not something you forget it's done on purpose which obviously no one does.

Re: I Want Off Mr. Golang's Wild Ride

#217

Post by sitzkrieg »

i wrote go professionally on a project for a year in a single very intense push, and i was burned by every single thing listed in the article. felt like uphill impedance mismatch the whole way. its nice to see it articulated well

Re: I Want Off Mr. Golang's Wild Ride

#218

Post by bsamuels »

hinkley wrote: post #161
palerdot wrote: post #78

Earlier quoted context omitted.

Python is 'strongly' typed `dynamic` language!!!

There are two technical conversations I don't have because everybody just gets mad and nothing gets resolved. (Note to reader: if you haven't guessed already, this means I am not going to be reading replies to this thread and certainly not responding to them. Go outside and get some air.) One, the Monty Hall problem. You either get it or you will die on a hill of misunderstanding. I've never seen anyone's mind be cha…

this is the only comment on this thread that gave me any pleasure to read. thanks for sharing

Re: I Want Off Mr. Golang's Wild Ride

#219

Post by Thaxll »

hota_mazi wrote: post #108
fhood wrote: post #22

The author spent a lot of time dwelling on Window's filesystems, at which point many of the readers got bored and started commenting. There are actually a couple of excellent points in here, the majority of which relate to Go's tendency to just be silently completely wrong in its behaviors from time to time, and is absolutely packed with hidden gotchas.

> the majority of which relate to Go's tendency to just be silently completely wrong 100% right on. Go's handling of errors is often ridiculed for its verbosity and lack of thought, but the fact that Go makes it so easy to sweep errors under the rug has real and devastating consequences in the real world. Go programs are much less safe than programs written in Rust or Java for that reason.

"Go programs are much less safe than programs written in Rust or Java for that reason."

This is plain wrong. ( Rust included )

Post reply on HN