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

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

fasterthanli.me

Post reply on HN
Print view View original

371–380 of 477 posts

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

#371

Post by throwaway894345 »

db65edfc7996 wrote: post #362
throwaway894345 wrote: post #305

Earlier quoted context omitted.

I've been developing Python professionally for 15 years, including almost a decade of deploying to containers. I think Go is much easier to use (especially in a container environment): 1. Static types make it much easier to read and write code for even a single individual, and the benefit scales superlinearly as the contributor count and code base age increase. Go also has a ton of other tooling which just outclasses…

> If you want reproducibility, it takes ~30 minutes just to resolve dependencies for relatively small-but-not-toy-sized projects. I will be the first to complain about Python packaging, but 30 minutes is far far beyond anything I have experienced.

Idk man. Pipenv. I’ve heard people say similar about poetry, but I’ve also heard people say poetry has improved.

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

#372

Post by gambler »

the_common_man wrote: post #42
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…

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

For starters, there is no way to consume multiple return values of a function or method inline. This makes chaining extremely verbose and often results in having three lines of error handling per one line of "normal" logic.

Secondly, Go creates a silly dichotomy by introducing two completely different mechanisms for error processing: error values and panics. (Soon to be three, because people will start using generics.)

Thirdly, "errors are values" approach is extremely counterproductive when you have to create generic error handling (with logging, default behaviors on failur,e etc). Something as simple as printing why a web page panicked becomes an exercise in cleverness.

Go enthusiasts will probably say none of this matters if you follow some set of "good practices". However, even core language libraries often fail to handle errors consistently. (E.g. text/template.)

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

#373

Post by erik_seaberg »

gambler wrote: post #372
the_common_man wrote: post #42

Earlier quoted context omitted.

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

For starters, there is no way to consume multiple return values of a function or method inline. This makes chaining extremely verbose and often results in having three lines of error handling per one line of "normal" logic. Secondly, Go creates a silly dichotomy by introducing two completely different mechanisms for error processing: error values and panics. (Soon to be three, because people will start using generics…

f(g()) does work if g returns multiple values and f takes that many args, but f(g(), h()) always requires that g and h each return a single value.

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

#374

Post by throwaway894345 »

mcronce wrote: post #315
lijogdfljk wrote: post #242

Earlier quoted context omitted.

Yea.. i used Go for 5 years. I just can't agree that the simplicity is true. Yes, the language itself is, but it offloads complexity into my program and thus my day to day is jumping around huge piles of logic which could be made for easier to reason about and understand with some actual help in managing the complexity. Your complex programs aren't easier in Go, in my experience. The simplicity of the language doesn'…

> runtime costs of the overuse of Interface{} (prior to Generics at least) Generics aren't going to improve this situation - at least not the current iteration of generics :(

It depends. Things like sorting a slice will be faster, for example. But yeah, the current iteration is a bummer.

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

#375

Post by valand »

philosopher1234 wrote: post #273
kaba0 wrote: post #264

Earlier quoted context omitted.

Yes, but that is definitely not achieved by checking for errors every second line.

I think checking for errors every line makes my go programs easier and faster to produce at a higher level of quality.

Some languages achieve error checking by type transforms and pattern matching, which are much more effective and efficient than error checks after every function call

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

#376

Post by usrn »

lamontcg wrote: post #206
lumost wrote: post #9

My Anecdotal Experience: Golang is great for spinning up new services and tools with very little overhead, the language is well designed for the backend - and the lack of avoids "odd" decisions which other engineers will dislike in the future. If your job is building lots of new things using relatively common building blocks, then Golang looks fantastic! However on mature services, engineers often need because they a…

If you need to use Vectors and Quaternions then Go isn't really for you either. The lack of any ability to do any operator overloading or writing arithmetic types along with the lack of parameteric polymorphism means you wind up doing stuff like Q.VectorMult(v) instead of just Q * v. Somewhere there's one of those "Go Koans" about how languages should allow programmers to easily express their intent, which I think th…

I kind of like making that a method since matrix products are not associative.

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

#377

Post by mause_piep »

fasterthanlime wrote: post #191
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 — correctn…

The generalization of anecdotal experience is a flaw in any argumentation. We see it every day everywhere.

You *assume* that Go creates sooner or later problems everywhere it runs. I have another anecdotal data point: At my workplace the most troublesome services are the ones written in Java. The Go services are much easier to manage and run much more reliably. Actually I can't remember of any issues with Go services.

So, you need to take more data points into account to come to a justified verdict. Your generalization of Go leading systematically to huge problems is far away from reality. There's already a huge amount of services written in Go. Networking stuff, backend APIs, CLIs, databases, ... do they all fall apart? No, just the opposite: They are some of the most successful projects in the last years.

Your analysis of the (tiny) problems is correct. Your conclusion that people shouldn't use Go is very wrong.

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

#378

Post by mause_piep »

Mawr wrote: post #310
fasterthanlime wrote: post #191

Earlier quoted context omitted.

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 — correctn…

> What an extremely convenient template to dismiss any nuanced argument against "worse is better". Nuance is exactly what I'm arguing for, there's none in the article. > 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). You're right, I apologize. I usually try hard to never directly addre…

Agreed. I just want to make clear that Rust/Ada/etc. don't give correctness guarantees! Their compiler is just more enforcing. It's all not black and white.

Rust is promoted for its correctness, but those correctness related bugs Rust prevents are an extremely low fraction of real world bugs (comparing to managed memory languages). I mean, how many type-system related bugs are there in real world projects with Java, C# or Go?

Rust is promoted with "fearless concurrency". Does it prevent your code from deadlocks, which are among the most tricky bugs?

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

#379

Post by joelfolksy »

0xdeadb00f wrote: post #245
miloignis wrote: post #31

Earlier quoted context omitted.

What's your argument? The point the article is making is that Go says it's simple, but isn't, while Rust doesn't say that it's simple, and uses its complexity to solve the complex problem. Bubbling up means returning the error to the caller, and is general error handling jargon.

Just because Go doesn't have a consistent API for file stuff, does not make it 'not simple' it makes it inconsistent. It is still simpler, and easier for me to understand ALL of the Go code on screen, than it was for me to understand just that rust function signature, and all the stuff in the paragraph I posted.

I hear you. People keep saying Spanish is an easier language than English, but yesterday I pulled up an article written in Spanish and I couldn't even read the first word.

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

#380

Post by OvermindDL1 »

everybodyknows wrote: post #353
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…

> its FFI story is painful Is the Rust FFI story much better? Serious question: I have a Go code base with performance-sensitive inner loops. Considering options now for the longer term.

> Is the Rust FFI story much better?

So very much so. All the usual C types are available, you even have as much control as even saying that you want to struct laid out as it is in C, doing something as simple as binding a function is just declaring the function like you would in C. As it uses llvm it can even inline across C code, optimize and all just like they were written in the same language if you wish to do that.

Post reply on HN