I want off Mr. Golang’s Wild Ride (2020) • Hacker News Board

Re: I want off Mr. Golang’s Wild Ride (2020)

#111

Post by jeroenhd » Thu, Apr 28, 2022, 3:45 PM UTC

jhoechtl wrote: post #82

nmilo wrote: post #72

Earlier quoted context omitted.

Rust's approach is definitely safer, but my point is that the concerns are overblown. The Go compiler raise an error if a variable (error) goes unused, and just ignoring this error by naming it "_" is obviously dangerous. Yes, Rust makes it easier to never ignore an error, but I don't think I've ever accidentally ignored an error that I shouldn't have in Go.

Golang gives you freedom. Rust gives you seat belts. It depends on you what you value more.

I don't think Go gives you freedom, actually. There aren't any good standard library functions for dealing with badly encoded unicode for file names, for example.

Instead, Go provides what the language designers considered solutions to most problems. Window not having Unix permissions? Just fake a bunch of them. Path not valid unicode? Probably not a problem. As long ad you agree with the way the Go designers think, that'll save you tons of work.

Just don't use Go in situations where those solutions might not work out, like when you're iterating over arbitrary files instead of the files you've created yourself in Go code.

Re: I want off Mr. Golang’s Wild Ride (2020)

#112

Post by zozbot234 » Thu, Apr 28, 2022, 3:45 PM UTC

throw10920 wrote: post #104

the_common_man wrote: post #42

Earlier quoted context omitted.

> For example, Go error handling is shit What is bad about it?

Errors as return values is only acceptable for code that is so performance-sensitive that you aren't allowed to do dynamic memory allocations. For everything else, conditions+restarts are the correct answer, because errors-as-values restricts you to a single error-handling strategy and couples high-level code to low-level code as a result.

The problem is that a system of "conditions + restarts" approaches the generality of fully async code. Go can of course do async well enough via its goroutines.

Re: I want off Mr. Golang’s Wild Ride (2020)

#113

Post by mynameisash » Thu, Apr 28, 2022, 3:45 PM UTC

fasterthanlime wrote: post #64

Author here: I wrote this in 2020, have changed jobs twice since. Both jobs involved Go in some capacity, where it's supposed to shine (web services). It has not been a pleasant experience either - I've lost count of the amount of incidents directly caused by poor error handling, or Go default values. If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip some…

Thanks for your amazing articles, Amos!

> I'm interested not in what the language lets you do, but what is typical for a language

This is the crux of the problem. To step away from Go/Rust and pick on another language, one could argue that Python lets you annotate every variable for some linting checks, but that doesn't mean they all are. This leads to horrible time-sinks where someone accidentally adds a comma to the end of a line, turning a scalar into a 1-tuple. I know folks to whom this has happened and who burned a half day trying to track it down.

I personally get annoyed by the "Language X gives me the freedom to do Y." I find that I and a lot of my peers often prefer constraints imposed (instead of freedom given) by the language as a way of preventing countless issues at runtime.

Re: I want off Mr. Golang’s Wild Ride (2020)

#114

Post by jeroenhd » Thu, Apr 28, 2022, 3:47 PM UTC

HL33tibCe7 wrote: post #88

nmilo wrote: post #72

Earlier quoted context omitted.

Rust's approach is definitely safer, but my point is that the concerns are overblown. The Go compiler raise an error if a variable (error) goes unused, and just ignoring this error by naming it "_" is obviously dangerous. Yes, Rust makes it easier to never ignore an error, but I don't think I've ever accidentally ignored an error that I shouldn't have in Go.

> Go compiler raise an error if a variable (error) goes unused It doesn't though. It's not a warning or error to not use the return value of a function that only returns an error, for instance ( https://go.dev/play/p/se6-zHHVezH ). There are static error checking tools you can use like https://github.com/kisielk/errcheck to work around this, but most people don't use them. I've run into a lack of Go error checking ma…

Rust will allow you to ignore a Result as well, to be fair, though with a compile time warning. I don't think I know any language that'll throw a compiler error at you if you ignore the return value of a function that indicates success or failure.

Re: I want off Mr. Golang’s Wild Ride (2020)

#115

Post by mynameisash » Thu, Apr 28, 2022, 3:49 PM UTC

NavinF wrote: post #91

taneq wrote: post #35

Earlier quoted context omitted.

Do C++ people actually call it "bubbling up"? I don't think I've used a language where this isn't the default behaviour so I'm not sure I've ever heard it given an actual name, it's just what happens when you don't catch the exception - it keeps going until someone does catch it, or it hits the runtime and demolishes your program.

Yes, but not just in C++. Bubbling up errors is a common phrase in Java and Python.

I often use and hear "bubbling up" in non-tech discussions, too. It's not at all uncommon, IMO.

Re: I want off Mr. Golang’s Wild Ride (2020)

#116

Post by ModernMech » Thu, Apr 28, 2022, 3:50 PM UTC

rad_gruchalski wrote: post #15

DrBazza wrote: post #8

Earlier quoted context omitted.

This submission came up because the article author is on twitter today complaining about golang and posted the submission link.

So they wanted out in 2020 and they’re still on in 2022. So either the language isn’t really that bad or they have an attention deficit?

At the end of TFA there's an update from April 2022 that explains the author's current thoughts.

Re: I want off Mr. Golang’s Wild Ride (2020)

#117

Post by throwaway894345 » Thu, Apr 28, 2022, 3:50 PM UTC

steveklabnik wrote: post #106

throwaway894345 wrote: post #92

Earlier quoted context omitted.

Of course. I wasn't trying to imply anything to the contrary. But given the prevalence of exceptions, if Go's error handling is performing on par or better, then it seems pretty ridiculous to characterize Go's error handling as "shit". Don't worry Steve, I think Rust's error handling is pretty cool!

I do agree that exceptions feel like the worst of the various bits of the problem space, to me, but just to be extra clear about it, I have never written a significant amount of Go, and therefore don't really have a very strong opinion about its error handling. And error handling is such a huge and interesting problem space! I've long wondered about why I didn't like checked exceptions in Java but do like errors as v…

Agreed! For something as pedestrian as error handling, it's always surprising to me how much it seems there remains to explore.

Re: I want off Mr. Golang’s Wild Ride (2020)

#118

Post by recuter » Thu, Apr 28, 2022, 3:50 PM UTC

chernevik wrote: post #54

HL33tibCe7 wrote: post #22

Could this post be unflagged please? I don't think it satisfies any requirement for flagging.

Off-topic, but HN needs review of flagging abuse. Maybe assign flagging privileges only to those with X reputation, and revocation if on review the privilege is abused? It seems that flagging is as much "I don't like this" as "this is not appropriate". Likewise downvoting. Maybe instead display both downvotes and upvotes, so people can see if a comment is found controversial?

Lately I've had comments swing wildly dozens of points in each direction and also flagged. Brigadiering has come to HN and is getting worse over time. There seems to be a growing segment of internet users who wish to cleanse perceived wrong think, it is disturbing and not what flags/downvotes are for. It also feels like there is more bots.

Re: I want off Mr. Golang’s Wild Ride (2020)

#119

Post by erik_seaberg » Thu, Apr 28, 2022, 3:50 PM UTC

rad_gruchalski wrote: post #15

DrBazza wrote: post #8

Earlier quoted context omitted.

This submission came up because the article author is on twitter today complaining about golang and posted the submission link.

So they wanted out in 2020 and they’re still on in 2022. So either the language isn’t really that bad or they have an attention deficit?

In https://news.ycombinator.com/item?id=31193260 the author clarified that he’s changed jobs twice yet “It doesn't matter that I don't personally write Go anymore: it's unescapable.” I’m also worried about this because of trends at my day job despite having joined a sharp, experienced Scala/Java team.

Re: I want off Mr. Golang’s Wild Ride (2020)

#120

Post by fb03 » Thu, Apr 28, 2022, 3:51 PM UTC

fasterthanlime wrote: post #64

Author here: I wrote this in 2020, have changed jobs twice since. Both jobs involved Go in some capacity, where it's supposed to shine (web services). It has not been a pleasant experience either - I've lost count of the amount of incidents directly caused by poor error handling, or Go default values. If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip some…

Don't fall prey to an ad-hominem argument - I don't think your article negatively hints at any kind of 'this is a Rust fanboy-made praise text' and it saddens me that a genuinely legit article like this needs to have the author defend himself like this.

Your points were well explained. Go has several serious warts which, in my own opinion, are showstoppers, and you are comparing it to a language which is somewhat newer and had more time to mature and of course, learn from other designs and their decisions as well.

Generics were intentionally left out, for example, because of the fear-mongering claim that "if you have generics your code is going to automatically become the C++'s STL at some point". After many years, the lack of even minimal generics got so bad they figured they'd start to lose share to rising languages like Nim, Rust and even the old grandpa C#, now portable everywhere with the Core stuff. It is very clear how badly bolted and rushed generics were in Go.

Rust has its warts as well and the language spec is already starting to become somewhat... large. We need to be careful not to invent C++2.0 right? ;-)

Anyways, just wanted to say this to you in hopes it'd lighten the mood and validate that you are in a good path with these articles. It was a very insightful reading for me. Thank you.