Hacker News Reader

Comment by frontfor | Hacker News Reader

I’m not sure about Go being full of footguns, but for one, a panic in any goroutine forcibly terminates the entire application.

View on HN

The constant incantation of if err != nil is bad for my aging hands and frankly hurts even more when you see Rust's single-character error marshalling using ? operator.

I have aliases for these kinds of general things (in vim) for most languages i use. Eg. if im inside a typescript file i have a mapping produces if ($obj) { $ } and i tab to enter the next "$" to insert the correct things.

The same goes fo Go. I have a mapping for if err != nil { ... } and the cursor is places inside the block.

I dont understand why people dont use this kind of thing for the most common programming constructs.

I would suppose they do and are free to do it - however, liberally having to spread it all over the code hurts readability. I'm sure people can say in response to that after a while you stop noticing or that their favorite IDE can collapse it and so on. It can be excuses all the way down instead of admitting that it is a shortcoming of the language.

You say it hurts readability but most of the time I want the unhappy paths to be visible.

Coding software that works when conditions are met is easy. Coding software that works when things break is hard. So I want error handling to stand out because it forces errors to be handled visibly and properly.

All too often I see Python programs drop to a stack trace under normal execution or JavaScript return cryptic errors that don’t mean much to anyone bar the core maintainer. But I seldom see 3rd party Go software bomb out in quite the same way. And I think that’s in large part because Go doesn’t try to hide errors away as an inconvenience that we shouldn’t be looking at.

So I’ll agree Gos approach is ugly. But sometimes good software does just look ugly. And the way I see it, it’s the quality of the compiled software that matters more than the beauty of the combination of characters that built it.

I am not questioning it's effectiveness. I have written Go code that is chugging along without issues in Production. My point is ergonomics and effectiveness are not mutually exclusive - hence the example of Rust's ? operator - effective and ergonomic (Rust also has issues with difficult to read lifetime+trait annotations).

The sad part is that people have been talking about this for years but Go team stubbornly refuses to make error handling more ergonomic.

> Rust's ? operator - effective and ergonomic

It is, but it's also subtle, and if you want branches (especially sad-path branches) to be explicit, that's not a good thing.

https://100go.co/ has a great list of Go footguns

Most of the stuff on there is just talking about general programming mistakes. Eg overly nested code is a problem a developer can make in any language.

Sure there are some Go specific stuff in there. But the whole thing reads more like someone preaching an irrational hatred for something rather than a fair breakdown of genuine footguns.

I think that's the intention of a panic.. however there is still recover if you need to "catch" it.

The issue is you need to explicitly recover each goroutine just so a nil dereference or a panic from a library you have no control over doesn’t bring down the whole application. Maybe this is the way it has to be, but it is a little known fact that might bite you.

The only time a library should be panicking is if they’ve reached a state they cannot continue from.

I’d be interested to know which libraries you’re working with where this has been a problem because I’ve only ever experienced one occasion where a 3rd party library panicked unnecessarily.

Reply on news.ycombinator.com