Hacker News Reader

Comment by pcwalton | Hacker News Reader

Go does not force you to think about errors at every single point. If a function returns only an error (such as, for example, os.Mkdir), the language will happily let you drop the error on the floor.

View on HN

This is underappreciated! I suppose you are less likely to care about errors if you aren't getting values from a function, but not always. I wonder if there is a proposal to force this case to be handled, like Haskell's -Wunused-do-bind?

There's go vet. But it's inconsistent with the Go warnings-are-errors philosophy. Ignoring the return value of os.Mkdir() is far more likely to be a bug than an unused import is.

Found it: https://github.com/golang/go/issues/20803

And that's totally fine. I don't always want to be fighting with monads. If I did I'd write Haskell code. Go is the quick and dirty git-er-done tool that provides quite a bit more performance and type safety than Python, but maintains some of the development speed/ergonomics.

Here's the thing, some of us don't want Rust. It looks great! It's perfectly awesome for it's primary domain (i.e. re-implementing critical portions of a modern browser). But it's not what I want to use as my daily driver.

I'm writing stupid shit that's munging CSV files and transforming json documents. I want a language that mostly gets out of my way, but performs well and can scale beyond a couple thousand lines of code. Go fits that space nicely, even with its (or maybe because of) conceptually imperfect error handling.

Wait, what? The OP said that they like Go’s error handling because it forces them to think about errors and make their code more robust. You’re saying you like Go as a “quick and dirty git-er-done tool”. Those are opposite viewpoints! For your use case, it seems like something like try() being added to Go would be a benefit, since it would make it easier to write “quick and dirty” code that still provides at least basic error handling.

I mostly agree with the op. I was replying to pcwalton's comment, or more specifically those who would solve every problem with a monadic straight jacket. I don't agree that that is always the best way to handle errors. There are tradeoffs involved that are hard to define but really do make a difference. I think Go finds a sweet spot thay has been ignored by the academic community. Hence my labeling of Go's error handling as conceptually imperfect.

I see many golang users just parrot what golang authors say, without having any evidence about those claims. Things like "golang is designed for development in the large", or "golang forces you to think about errors" or that the way it handles errors is robust, all claims that have nothing to support them (on the contrary, reality is the opposite of those claims).

In rust though, you dont have to handle errors all the time. You can just unwrap them, and crash when there's an error.

It's not just that though, GC is also a big part of the equation. I stopped manually managing memory 20 years ago. I'm not interested in going back to that.

I get that certain aspects of Rust make that easier (and certainly safer) but I'm not working in a domain where the performance gains of ditching GC matter.

I’ve written quite a bit of Rust, including an implementation of a collision-resistant UID algorithm and a static website generator. I’ve also written quite a few “git-er-done” scripts in the language as part of other projects (for example, a script to randomly generate linked data and write it to a couple of CSVs). At no point so far have I had to manually manage memory. As others have noted, this is what the borrow checker enables: you write code as though it were in a GC language, and the compiler handles inserting the allocations and deallocations.

Of course, you can manually manage memory in Rust, but it is almost never necessary for high level applications.

I’m not at all claiming it’s the best tool for every job (although I do think it’s great), just clarifying the point about memory management.

You are hardly managing memory in rust...reference allocation is practically garbage collection and feels as such in rust.

Reference allocation _is_ essentially equivalent to garbage collection, the one thing it doesn't deal with correctly is reference cycles. Which are inherently unlikely if you spend the time and effort to organize your code properly. (The Rust community is also working on cycle-aware reference collection, e.g. https://github.com/lopopolo/ferrocarril/blob/master/cactusre... but this will always come with some drawbacks.)

Reply on news.ycombinator.com