4 ms·

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 happi

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.

gjs278 7y ago
you still had to think about it when you decided to drop it to the floor by putting the _ saying "I acknowledge there was an error, but I don't care"
matthewbauer 7y ago
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?
- matthewbauer 7y ago
  Found it: https://github.com/golang/go/issues/20803 https://github.com/golang/go/issues/20803
- pcwalton 7y ago
  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.
bmurphy1976 7y ago
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.
- UK-AL 7y ago
  In rust though, you dont have to handle errors all the time. You can just unwrap them, and crash when there's an error.
  - bmurphy1976 7y ago
    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.
    - jzoch 7y ago
      You are hardly managing memory in rust...reference allocation is practically garbage collection and feels as such in rust.
      - 0815test 7y ago
        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/cactusref/README.md https://github.com/lopopolo/ferrocarril/blob/master/cactusre... but this will always come with some drawbacks.)
    - mplanchard 7y ago
      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.

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.

gjs278 7y ago

you still had to think about it when you decided to drop it to the floor by putting the _ saying "I acknowledge there was an error, but I don't care"

matthewbauer 7y ago

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?

matthewbauer 7y ago
Found it: https://github.com/golang/go/issues/20803 https://github.com/golang/go/issues/20803
pcwalton 7y ago
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.

bmurphy1976 7y ago

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.

UK-AL 7y ago
In rust though, you dont have to handle errors all the time. You can just unwrap them, and crash when there's an error.
- bmurphy1976 7y ago
  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.
  - jzoch 7y ago
    You are hardly managing memory in rust...reference allocation is practically garbage collection and feels as such in rust.
    - 0815test 7y ago
      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/cactusref/README.md https://github.com/lopopolo/ferrocarril/blob/master/cactusre... but this will always come with some drawbacks.)
  - mplanchard 7y ago
    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.