4 ms·

A language where it's natural to think about and properly handle every error condition.

mattnewton 10y ago
Personally the syntax seems like a regression to me, as a JavaScript programmer who moved on to promises from the old callback function(err, Val){ if err pattern. Higher order control flow abstractions are really nice, but hard to do in go because of the weak type system. If it was fully dynamic we couldn't worry about it, and if it allowed a bit more power like generics we could have elegant stuff like Haskell's either monad.
cr0sh 10y ago
Someone who gets it. In Go, this is one of the most difficult concepts of the language to wrap one's head around. Moreso, it's a concept that makes you bang your head against the wall at first; at least it did for me. After being so used to "getting away with" not thinking about this in other languages, being forced to think this way in Go can be maddening. Then a light goes on. ...and then you look at your old code and go "eeesh"; in my case, I was coming from a PHP background at the time I was learning Go. Don't get me wrong - I still like PHP and other languages, and I don't use Go much as it is, but once I wrapped my head around many of it's "strangeness" (compared to other languages), I really appreciated it (because I recognised that the whole point of the language was to help prevent common errors and in many cases force better programming practices to that end), and began to enjoy it.
- vvanders 10y ago
  I hate to be the one who brings Rust into a Go thread but if you find forced error handling to be a revelation then you'll find the borrow checker does the same thing for your program structure and architecture. There's also a ton of really nice error handlers[1] that let you ergonomically deal with errors while still being forced to confront them. [1] - https://doc.rust-lang.org/book/error-handling.html https://doc.rust-lang.org/book/error-handling.html
  - kmicklas 10y ago
    > I hate to be the one who brings Rust into a Go thread You shouldn't feel bad for this. The Go programmers are legitimately unaware that there's a better world out there.
    - greenhouse_gas 10y ago
      Honestly, not at this point of HN. I don't think there was one thread that mentioned (or didn't mention) anything about Go which didn't have comments criticizing it. Everyone knows its problems, and everyone knows about Rust. It's just that some people don't need such extreme Real Time that they can't afford GC at the expense of the borrow-checker and lifetimes.
      - kmicklas 10y ago
        > Everyone knows its problems, and everyone knows about Rust. I guess they've at least heard of it, yeah, but how many of them have actually tried Rust (or any other language with a modern type system)? > It's just that some people don't need such extreme Real Time that they can't afford GC at the expense of the borrow-checker and lifetimes. They should probably be using Java, C#, Scala, ML, F#, Haskell, etc. then.
        reality_czech 10y ago
        I have tried Rust, Go, Java, SML, Lisp, Javascript, and many other languages. I prefer Go in many situations where simplicity, speed of compilation, and portability are important. Rust is an interesting language with a lot of potential but the jury is still out on how wide the adoption will be. There is a steep learning curve, and the borrow checker has limitations. One thing I don't appreciate is being lectured by pimply-faced nerds about how Go programmers should embrace Java/C++ generics into their heart as their personal saviors. I understand what Java and C++ are, I can choose to use them or not, and it's none of your business.
    - omginternets 10y ago
- parenthephobia 10y ago
  > In Go, this is one of the most difficult concepts of the language to wrap one's head around. Moreso, it's a concept that makes you bang your head against the wall at first; at least it did for me. You imply you agree with the parent poster, but if it was "natural" to do error handling this way, surely it wouldn't be the language's most difficult concept?
  - zacmps 10y ago
    It is natural imo. I think the reason people struggle with it is because of how different it is from most modern programming languages.
malcolmgreaves 10y ago
Which is a great idea: knowing which expressions can fail and which ones cannot. However, the way go encodes this idea isn't very ergonomic or elegant. I'd suggest that you take a look at ways other languages do this. For example, the `Either` type in Haskell or the disjunction type `scalaz.\/` in Scala.

Personally the syntax seems like a regression to me, as a JavaScript programmer who moved on to promises from the old callback function(err, Val){ if err pattern. Higher order control flow abstractions are really nice, but hard to do in go because of the weak type system. If it was fully dynamic we couldn't worry about it, and if it allowed a bit more power like generics we could have elegant stuff like Haskell's either monad.

cr0sh 10y ago

Someone who gets it. In Go, this is one of the most difficult concepts of the language to wrap one's head around. Moreso, it's a concept that makes you bang your head against the wall at first; at least it did for me. After being so used to "getting away with" not thinking about this in other languages, being forced to think this way in Go can be maddening. Then a light goes on. ...and then you look at your old code and go "eeesh"; in my case, I was coming from a PHP background at the time I was learning Go. Don't get me wrong - I still like PHP and other languages, and I don't use Go much as it is, but once I wrapped my head around many of it's "strangeness" (compared to other languages), I really appreciated it (because I recognised that the whole point of the language was to help prevent common errors and in many cases force better programming practices to that end), and began to enjoy it.

vvanders 10y ago
I hate to be the one who brings Rust into a Go thread but if you find forced error handling to be a revelation then you'll find the borrow checker does the same thing for your program structure and architecture. There's also a ton of really nice error handlers[1] that let you ergonomically deal with errors while still being forced to confront them. [1] - https://doc.rust-lang.org/book/error-handling.html https://doc.rust-lang.org/book/error-handling.html
- kmicklas 10y ago
  > I hate to be the one who brings Rust into a Go thread You shouldn't feel bad for this. The Go programmers are legitimately unaware that there's a better world out there.
  - greenhouse_gas 10y ago
    Honestly, not at this point of HN. I don't think there was one thread that mentioned (or didn't mention) anything about Go which didn't have comments criticizing it. Everyone knows its problems, and everyone knows about Rust. It's just that some people don't need such extreme Real Time that they can't afford GC at the expense of the borrow-checker and lifetimes.
    - kmicklas 10y ago
      > Everyone knows its problems, and everyone knows about Rust. I guess they've at least heard of it, yeah, but how many of them have actually tried Rust (or any other language with a modern type system)? > It's just that some people don't need such extreme Real Time that they can't afford GC at the expense of the borrow-checker and lifetimes. They should probably be using Java, C#, Scala, ML, F#, Haskell, etc. then.
      - reality_czech 10y ago
        I have tried Rust, Go, Java, SML, Lisp, Javascript, and many other languages. I prefer Go in many situations where simplicity, speed of compilation, and portability are important. Rust is an interesting language with a lot of potential but the jury is still out on how wide the adoption will be. There is a steep learning curve, and the borrow checker has limitations. One thing I don't appreciate is being lectured by pimply-faced nerds about how Go programmers should embrace Java/C++ generics into their heart as their personal saviors. I understand what Java and C++ are, I can choose to use them or not, and it's none of your business.
  - omginternets 10y ago
parenthephobia 10y ago
> In Go, this is one of the most difficult concepts of the language to wrap one's head around. Moreso, it's a concept that makes you bang your head against the wall at first; at least it did for me. You imply you agree with the parent poster, but if it was "natural" to do error handling this way, surely it wouldn't be the language's most difficult concept?
- zacmps 10y ago
  It is natural imo. I think the reason people struggle with it is because of how different it is from most modern programming languages.

malcolmgreaves 10y ago

Which is a great idea: knowing which expressions can fail and which ones cannot. However, the way go encodes this idea isn't very ergonomic or elegant. I'd suggest that you take a look at ways other languages do this. For example, the `Either` type in Haskell or the disjunction type `scalaz.\/` in Scala.