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

271–280 of 477 posts

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

#271

Post by christophilus »

dimgl wrote: post #241

I liked the article. I think it was really well written and these are great points. So if not Go, then what's the alternative? I too am starting to feel a bit burnt out by some of Go's deficiencies, but one of the things I really like about Go is its concurrency model. What other languages have great concurrency models? Please keep in mind that I want to keep things simple... having a single binary to deploy is incre…

I’ve kicked the tires with a lot of languages, and always end up coming back to Go. It’s a pretty subpar language, but it hits a sweet spot that nothing else does: fast builds, decent tooling, relatively small single binary deployment, pretty good performance out of the box, decent stdlib. I could go on.

I want to use Ocaml or a Lisp or a number of other languages, but Go really does the entire package better than anything I’ve looked at.

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

#272

Post by kaba0 »

dragonwriter wrote: post #246
mcronce wrote: post #90

Earlier quoted context omitted.

> Go is a language that gets out of your way, encourages you to solve your problem Maybe I'm just too dumb for Go, but this is not consistent with my experience at all. Go's insistence on pretending that complexity doesn't exist would get in my way all the time. Go's extreme hostility toward FFI calls got in my way several times.

Go always seems to be to be designed to be simple for the compiler (which, to be fair, has benefits: fast compilation is useful in a compiled language, to keep code-build-test cycles short) more than the programmer.

I never really understood this reasoning. To me the ideal thing would be a fast debug-compile mode that barely optimizes and a don’t care how slow release mode that uses every possible optimization for the end result.

Rust is plenty interactive with its similar mode of working. Incremental builds are fast.

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

#273

Post by philosopher1234 »

kaba0 wrote: post #264
Jyaif wrote: post #252

Earlier quoted context omitted.

Can you see the value in being able to create software more quickly, at the expense of the software's stability?

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.

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

#274

Post by masklinn »

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…

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

An other issue which is as big or bigger is that Go only tracks variables, it doesn't track reads and writes (unlike... well rust for starters).

So the compiler will also be perfectly happy if you call two erroring function, check the first's error but then reassign the second's error to the same variable (say, err, because it's always the variable for the error) and... completely forget to check it: https://go.dev/play/p/GJiovZwvHqj

I think errcheck also checks for it, but as you say it's not part of the language and its use is not ubiquitous.

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

#275

Post by eweise »

philosopher1234 wrote: post #216
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…

>because it prevents you from building abstractions, Replying to just this part of your comment, but building abstractions can be as much a source of new complexity and cognitive overhead as it can reduce them. I think Go is wise to be on the side of less abstraction, because most of the abstractions it makes hard end up hurting more than they help. >What an extremely convenient template to dismiss any nuanced argume…

There's nothing stopping you from building bad abstractions in Go, and I find it pretty common. Here's an example:

Debug(msg string, keyvals ...interface{})

The keyvals interface assumes you are passing in both a key and a value but if you don't, it doesn't work correctly and in fact in our code I think it blows up.

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

#276

Post by philosopher1234 »

Fritsdehacker wrote: post #260
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…

I think describing this article as a one sided rant isn't really fair. The author shows that Go makes a few design decisions that make it easy to shoot yourself in the foot. This is generally a bad idea. Rust may be the summum of correctness. In my view that makes it an ideal candidate for comparison. It shows the reader what a better solution would look like. And that this can work in practice. Does that mean you sh…

It’s one sided when it points out the pitfalls without bothering to describe why they’re there, and what the upside is. There are sloppy mistakes in Go, just like in anything, but many of the common criticisms of go are about trade offs not about mistakes.

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

#277

Post by shadowgovt »

lliamander wrote: post #222
shadowgovt wrote: post #49

Earlier quoted context omitted.

And the most interesting thing to my mind is how little the subtle gotchas matter. The key is they're subtle. If a subtly-wrong design takes only 20% of the code of the truly-correct design to express and understand and it works for 99% of the cases, then there's actually a benefit to a lot of users of using that architecture. If you end up in the swamp outside the happy path you can get badly burned, but that's the…

I've only been doing Node for about a year now, and already I've been bit by gotchas. Obviously all languages have their warts, and I can compensate. Using Typescript with it, I've actually been quite productive. It's higher level of expressiveness relative to Java is also a breath of fresh air. But some languages definitely have more warts than others, and Javascript/Node is on the higher end of that distribution. A…

Out of curiosity (if you're at liberty to say), what has bit you?

I do Node / TypeScript basically all day these days, and I'm probably too close into the forest anymore; I'm wondering if other people are getting bitten by things that I just roll right past because I'm used to the pain.

The extremely weak (and frankly incorrect) Date handling that's built into JavaScript is the first thing that comes to mind.

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

#278

Post by christophilus »

pjmlp wrote: post #202
baby wrote: post #39

Golang is great because it was the first to include excellent tooling in addition to the language (strict compiler, linting, non-customizable gofmt, package manager, good html docs, online playground, etc.) It’s undeniable that it brought a lot of good ideas that languages like Rust borrowed. Golang is still undefeated in terms of battery included. Its standard library is top notch and full featured. On the other han…

Common Lisp, Smalltalk, Delphi, C++ Builder, Java, .NET languages... Plenty of examples preceded Go in what good tooling means.

I’ve used all of those except Delphi. I think Go got a lot right and is in a different (better) ballpark, tooling wise.

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

#279

Post by Fritsdehacker »

philosopher1234 wrote: post #276
Fritsdehacker wrote: post #260

Earlier quoted context omitted.

I think describing this article as a one sided rant isn't really fair. The author shows that Go makes a few design decisions that make it easy to shoot yourself in the foot. This is generally a bad idea. Rust may be the summum of correctness. In my view that makes it an ideal candidate for comparison. It shows the reader what a better solution would look like. And that this can work in practice. Does that mean you sh…

It’s one sided when it points out the pitfalls without bothering to describe why they’re there, and what the upside is. There are sloppy mistakes in Go, just like in anything, but many of the common criticisms of go are about trade offs not about mistakes.

Sure, but the way I read the article, that's what the author shows. They don't like trade-offs that are made.

Maybe the tone of the article feels a little aggressive towards Go, I don't know. To me it felt more like an outcry of frustration with the chosen trade-offs.

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

#280

Post by christophilus »

jitl wrote: post #94
moralestapia wrote: post #20

Earlier quoted context omitted.

Could you share a few of them?

- Most Node code I encounter that uses “streams” gets something wrong. Usually minor, sometimes major stuff like forgetting errors exist altogether, or to reject a promise wrapper when an error occurs. - Incorrect use of concurrency stuff like process.nextTick. This function probably doesn’t do what you think it does based on the function name - it won’t “yield to the event loop”. - for years Buffer and friends was t…

> Most Node code I encounter that uses “streams” gets something wrong

This is really true. I ported a Node project to Go for this reason, and the streams in Go were miles easier to reason about.

Post reply on HN