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

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

#191

Post by fasterthanlime » Thu, Apr 28, 2022, 5:18 PM UTC

Mawr wrote: post #125

The author fundamentally misunderstands language design. He picks an arbitrary design constraint, in this case correctness, and argues that any language that does not provide 100% correctness is bad. He uses Rust for his examples, a language that has correctness as one of its top design goals, and contrasts it with Go, for which correctness is not that important. So of course Rust will come out on top when the only m…

What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design).

Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctness underpins /everything/, it's not a hobby), I can't help but notice you carefully use the word "attempt" when referring to the promises Go /does/ make.

One of the things I'm saying is that Go does not deliver on those. It does not deliver on "speed of coding", precisely because everyone, even seasoned Go developers, keep hitting its many design pitfalls.

It does not lower mental overhead, because it prevents you from building abstractions, and pushes complexity out of the language and into your head.

There's a lot to be said about safety and performance, which gets bleaker real quick once CGo enters the picture (hence why the Go team likes to remind folks that CGo is not Go).

But say we disagree there and you truly find it a breeze to write large amounts of Go code: as soon as you deploy something to production and others start to rely on it: you don't get to choose not to care about "correctness". If you don't, you're just pushing the problem onto someone else.

You may be pushing the problem onto ops people, other devs, or your customers, but it does land on someone. And nowadays that someone is often me: my frustration is fueled by years of real world use, I do not, like you seem to imply, enjoy thinking about these things in the abstract, just for the fun of it.

Of course, you can choose to ignore that too, and that's fine! But let's please drop the pretense that this kind of response is anything other than "I refuse to think about this".

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

#192

Post by fasterthanlime » Thu, Apr 28, 2022, 5:22 PM UTC

daviddever23box wrote: post #182

Blaming a language such as Go for poor software design choices is like yelling at a garden spade, in ASL. I've seen some well-written library code that is kept up-to-date, and I've seen some crufty libs that, frankly, would barely pass muster on an internal code review. A good litmus test is to check the linting configuration for a given library repository, as well as the frequency by which a given library is updated…

If your idea of a "grown up engineer" is one who fails to notice systemic problems and diligently, repeatedly hits themselves in the head with a rake because that's the way it's always been done, we have very different ideas.

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

#193

Post by reedjosh » Thu, Apr 28, 2022, 5:23 PM UTC

throwaway894345 wrote: post #154

reedjosh wrote: post #110

Earlier quoted context omitted.

I just can't stand taking three lines to unpack a value from a map or to return if error. Why can't I just say `return if err := somefunc(); err != nil` It's mega frustrating on top of the lack of generics and other abstractions. And now that generics are coming about, I'm sure it will take forever until my current project can use them. My current project is in the k8s ecosystem which due to the lack of generics, imp…

I can't relate. Newline characters have never been burdensome to me, and they aid in visual structure (the control flow is represented by the visual structure of the program, not only for "good data" paths, but also for error paths). My programming problems are usually not related to localized keystroke boilerplate, but rather larger issues of abstraction and data modeling. > My current project is in the k8s ecosyste…

Well, if you don't know the structure of a resource ahead of time but know that it has a status.ready, I would think that would be a candidate for a generic? I haven't explored that much yet, but in retrospect I might even be able to convert all objects to a struct that has only status.ready without generics.

I've only been in the ecosystem 6 months, but yeah larger abstractions are difficult too.

I'm not a fan of the lack of sub-classing. I like writing a base class and concrete one, and it's quite difficult in Go unless you want to make everything an interface.

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

#194

Post by geodel » Thu, Apr 28, 2022, 5:23 PM UTC

fb03 wrote: post #120

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 new…

Tone matters a lot. Just being strictly, technically correct does not get much far, specially in these times. Its funny that author put in scathing, personalized review of Go but then act surprised that some Go fans took that personally.

At least in Go case it is just random Go fans dismissing criticism. Go authors do not jump in to defend language at every internet posting. This is absolutely not the case with Rust where committers just pop-in everywhere language/ecosystem is criticised.

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

#195

Post by mcculley » Thu, Apr 28, 2022, 5:23 PM UTC

klodolph wrote: post #181

mcculley wrote: post #167

I am both bemused and empathetic for those who keep having this realization with Go. It is like an abusive relationship and people stay in it too long before realizing it is not going to get any better. I took a look early on at Go. I tinkered with it and decided it would not work for me. It lacked a lot of things that any new language should have, given the lessons learned in language design over the last few decade…

I don’t get the “abusive relationship” metaphor. It just seems like the “abuse” metaphor is an attempt to stir up emotions. Every language has its own weird way of doing things. You decided Go wouldn’t work for you? Ok, I get it. People who stick with Go are in an “abusive relationship”? Seems like an attempt to stir up a flame war more than anything else. I’ve never encountered a language that I’m 100% happy with. I…

It sounds like you enjoy Go. That is great. I am referring to TFA/post which sounds similar to many experiences with Go.

Of course all languages have pros and cons. I am referring to the specific situation where people are expecting a modern language and ecosystem heavily influenced by its user community. Go is not such a language. People should have different expectations.

> The history of language design is the history of people making decisions about how to design their language, and then discovering that the decision had unintended consequences, like, five or ten years later.

I agree completely, which is why it is so surprising that people adopted Go when it seemed to learn very little from history.

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

#196

Post by cdelsolar » Thu, Apr 28, 2022, 5:24 PM UTC

gambler wrote: post #26

Go has a lot of issues. Some of them would be easily fixable if people promoting and developing Go actually admitted the problems. However, the fanbase usually acts as a cult pretending that issues are features. Thing is, just like broken, hackish dependency "management" had to be fixed (introducing tons of complexity for the sake of not destroying backward compatibility), other problems will have to be fixed as well…

> Go error handling is shit.

See, if you actually think this, then there can be no common ground here. Just use other languages and stop complaining.

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

#197

Post by mcculley » Thu, Apr 28, 2022, 5:26 PM UTC

throwaway894345 wrote: post #190

mcculley wrote: post #167

I am both bemused and empathetic for those who keep having this realization with Go. It is like an abusive relationship and people stay in it too long before realizing it is not going to get any better. I took a look early on at Go. I tinkered with it and decided it would not work for me. It lacked a lot of things that any new language should have, given the lessons learned in language design over the last few decade…

I would challenge you to rephrase this without the loaded language, not only because loaded language invites a flame war, but also to see if your argument is compelling without assuming outright that the language is bad. I.e., can you make a persuasive argument that the language is bad rather than simply coming up with myriad different ways of implying that you don't like the language (or perhaps even the people who…

I won't edit my post. Maybe I did use bad wording. I will contemplate that.

I don't think Go is "bad". The important point to me is the expectation that Go will adapt to its user community.

For example, I am not at all surprised that Go has bad abstractions for files under Windows. I would not expect Pike or Thompson to care about Windows. I would not try to make Go work as a cross platform language.

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

#198

Post by steveklabnik » Thu, Apr 28, 2022, 5:26 PM UTC

jeroenhd wrote: post #114

HL33tibCe7 wrote: post #88

Earlier quoted context omitted.

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

Languages with "linear types" would, but there aren't any mainstream ones.

(And, to be extra clear, it only lets you ignore a Result if you don't care about the Ok value, if you want to use it, it does not.)

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

#199

Post by pjmlp » Thu, Apr 28, 2022, 5:27 PM UTC

vrnvu wrote: post #163

robonerd wrote: post #85

Earlier quoted context omitted.

> However, the fanbase usually acts as a cult pretending that issues are features. Per Rob Pike (Lang NEXT 2014), golang was created for fairly young programmers that are fresh out of school and don't know many other languages. So, something I've observed: When somebody doesn't know many things but is building a career, planning their life, on one of the things they know, they're going to take that one thing more per…

Do you have any data or survey to back your statement? Forgive me if I've misunderstood you but are you saying that Golang is mostly used by young programmers? In my experience most Golang developers are highly experienced... Same with Rust.

Yes, you just needed to search for Lang NEXT 2014 and Rob Pike.

Enjoy the video, https://youtu.be/YM7QYx-LPSA

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

Or if you prefer reading, https://talks.golang.org/2012/splash.article

"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."

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

#200

Post by shadowgovt » Thu, Apr 28, 2022, 5:29 PM UTC

jeroenhd wrote: post #111

jhoechtl wrote: post #82

Earlier quoted context omitted.

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,…

The counterpoint is "your filenames shouldn't be badly-encoded unicode." In other words, "If `ls` can't render it, it's a bad filename. Rename the file."

(This does mean that Go is constraining the set of problems it's easy to solve with it. But that's the nature of programming in general... We decide what problems need to be easier to solve at the expense of putting some problems outside the "sweet spot" and requiring more work to solve them).