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

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

#121

Post by the_common_man » Thu, Apr 28, 2022, 3:54 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.

> Errors as return values is only acceptable for code that is so performance-sensitive that you aren't allowed to do dynamic memory allocations

Not really. It is acceptable for code whose maintainers value readability and simplicity over everything else. I totally agree that readability and simplicity are quite subjective and this is up to the maintainers.

I don't really know what "conditions+restarts" is but a few articles landed me into LISP which I find totally unreadable. So, can you point me to some "conditions+restarts" code that I can understand/appreciate easily? Any language is fine, I just want to understand the concept better since I am more a C/C++/JS programmer. (FWIW, never written Go, but it's easy to read and understand).

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

#122

Post by reedjosh » Thu, Apr 28, 2022, 3:54 PM UTC

jitl wrote: post #65

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…

The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and understand what’s happening. At least when I needed to debug Kubernetes issues 4 years ago, I could grep around, dive into a file, and command-click to “go to definition” and quickly build a local understanding of the code around my problem. No spooky action. Everyth…

> It is tedious.

> to reduce the variance between the best programmer on a project and the worst.

In my experience the only way this can be done as with trying to level anything is to bring down the level of the best.

I find this awful.

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

#123

Post by the_common_man » Thu, Apr 28, 2022, 3:55 PM UTC

mcronce wrote: post #47

the_common_man wrote: post #42

Earlier quoted context omitted.

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

It requires several additional lines of code just to bubble up an error, for starters, and there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data.

> It requires several additional lines of code just to bubble up an error

I mean people hate exceptions for a reason (other than in Java world).

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

#124

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

throw10920 wrote: post #109

throwaway894345 wrote: post #95

Earlier quoted context omitted.

> Whether or not you can read everything on the screen at one time is missing the point entirely. The point is that context matters, and the more frequently you have to scroll to find it is more cognitive burden. And I disagree. Scrolling IMO is a lot easier than squinting to parse dense code. We have visual structure (indentation blocks and so on) for a reason. The visual structure aids in readability, and indentati…

> Scrolling IMO is a lot easier than squinting to parse dense code. This is a false dichotomy - there's a third option, which is not squinting (because, presumably, you're doing so because you decreased your font size), and being able to see more on the screen at the same time. Moreover, scrolling is bad for cognition . It's pretty well-known that the human brain likes to use spatial maps - that's the reason why memo…

> This is a false dichotomy - there's a third option, which is not squinting (because, presumably, you're doing so because you decreased your font size), and being able to see more on the screen at the same time.

It's not a false dichotomy. Visual structure (via whitespace) comes at the expense of strict information density (assuming a fixed font size). If this is not true, then we would never have any (syntactically insignificant) whitespace.

> This is not something you can "disagree" on - divorcing information from context always leads to more cognitive burden.

Agreed, but this supports my point. It's a lot easier to scroll and scan visual structure than it is to reparse dense code. Density divorces us from context a lot more than physical distance on a screen.

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

#125

Post by Mawr » Thu, Apr 28, 2022, 3:57 PM UTC

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 metric you care about is correctness.

As usual with such one-sided rants, the downsides to the supposed clearly right alternative are omitted. How long would it take for me to learn Rust + write a given program vs Go? How long does it take to model problems 100% correctly vs merely well-enough?

> It [Go] constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness.

Yes, exactly. Optimizing for the 90% case, not simplicity, is the primary design goal of Go. In other words, pragmatism or the 80/20 rule. Go attempts to provide 80% of the benefit for only 20% of the cost.

This is pervasive throughout the language:

- the author's examples,

- a GC,

- merely good-enough error handling.

The sweet spot Go attempts to strike between speed of coding, correctness, safety, performance, and mental overhead is the reason it's so polarizing. You may like this approach or not, but let's not pretend that Go is all bad or that say Rust is some perfect holy grail that will save us all.

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

#126

Post by snotrockets » Thu, Apr 28, 2022, 3:58 PM UTC

jitl wrote: post #65

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…

The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and understand what’s happening. At least when I needed to debug Kubernetes issues 4 years ago, I could grep around, dive into a file, and command-click to “go to definition” and quickly build a local understanding of the code around my problem. No spooky action. Everyth…

What I wonder, is if by designing a language to enable happy corporates, rather than happy programers, is Go not shooting itself in the foot, as the now less happy programmers (because corp mandated Go) would move to other corps, creating more cost to the corporate than if they had use a more joy-inducing language.

IOW, Go is probably great if you're quite big. But like most Google created dev tools, the questions we need to ask ourselves is "are they a good fit outside Google?"

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

#127

Post by AnimalMuppet » Thu, Apr 28, 2022, 4:01 PM UTC

reedjosh wrote: post #122

jitl wrote: post #65

Earlier quoted context omitted.

The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and understand what’s happening. At least when I needed to debug Kubernetes issues 4 years ago, I could grep around, dive into a file, and command-click to “go to definition” and quickly build a local understanding of the code around my problem. No spooky action. Everyth…

> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.

It may be awful to the best programmer. But if you're looking at the team as a whole, well, how many of the best do you have on the team? It's really hard to create large teams where the average programmer on the team is better than the average programmer in the country. If you can bring up the lower half of the team, that may be a net win, even if it brings down the best one on the team.

The effect of that may be that the best programmers leave the team, though...

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

#128

Post by kretaceous » Thu, Apr 28, 2022, 4:01 PM UTC

I've been learning go over the past 3 weeks. This made me kinda sad in a way. I have similar (and much less angry) complaints with Go as a beginner.

My main gripe is not having proper error handling (try-catch maybe) and lack of default parameters. (Anonymous function without parameters when passed as an argument to another function) would be a nice to have too.

There are some instances I feel that the makers of Go don't want to share the internals because that would be "unnecessary syntax".

Want default parameters? Don't have those. So how does make() work? It's a language construct.

Obviously I'm not going to stop learning as I think it's the easiest language to make small/standalone binaries in and, I love the syntax, the native tooling, the performance, the easy concurrency, etc. It's a worthy tool.

But I really hope some of obvious language quirks get acknowledged and fixed by the Go community.

And I really hope I don't regret.

I haven't really learnt it in depth but it has been easier so far than whatever language I've tried learning it in.

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

#129

Post by sleepybrett » Thu, Apr 28, 2022, 4:04 PM UTC

mcronce wrote: post #68

throwaway894345 wrote: post #55

Earlier quoted context omitted.

The latter is a much stronger argument than the former (no idea why people get so worked up about character counts), but even then, "shit" is really strong considering how often one experiences exception traces when using an application written in Python or Java or some other exception-based language. Point being, we should probably evaluate error handling schemes based on results rather than ideology (even though I…

Screen real estate is limited, especially vertical real estate. Compared to languages with saner error handling, I can read approximately 25% as much Go code at once. That's a real cognitive burden when maintaining code or learning your way around a new codebase, which seems especially egregious from a language whose community consistently proselytizes about how the lack of language features is great for maintainabil…

> Screen real estate is limited, especially vertical real estate.

meh, my ide squashes short if `err != nil` clauses (goland, but I've seen other editors/ides/golang plugins do this as well ), also I run a vertical monitor. It's just not enough of an issue to care about. I've seen similar features for editors for other languages that have features or patterns that also create a lot of 'extra bullshit that takes up screen realestate'.

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

#130

Post by bjourne » Thu, Apr 28, 2022, 4:07 PM UTC

A lot of the criticism is fair but not the part about runtime os detection. It is vastly preferable over conditional compilation since it is much easier to test. With conditional compilation you introduce code paths that are only traversed on, say, Windows. If most developers use, say, Linux you will introduce difficult-to-debug system-dependent bugs. This goes for similar things like SIMD-extensions too. If possible, use runtime checking over conditional compilation.