6 ms·

> If a programming language supports union types and type inference then there is no need for such a "special" language feature Laughs in Go. > While Zig's er

> If a programming language supports union types and type inference then there is no need for such a "special" language feature Laughs in Go. > While Zig's errorhandling is not bad and miles above Go's Laughs again in Go. Go has no "foundations" regarding errors, it's just a convention. It has no union types. It doesn't have weird corner cases. It's just a returned value you can handle. Or not. Of all the error handling paradigms I've seen, Go's requires the least amount of "specialized thinking" (try/catch or whatnot)--it's just becomes another variable.

grumpyprole 3y ago
Go's lack of sum types mean that there is no static check for whether the error has actually been handled or not. Go's designers went to all the trouble of having a static type system, but then failed to properly reap the benefits. Sum types are the mathematical dual of product types. It makes sense for any modern language to include them.
- kosherhurricane 3y ago
  > Go's lack of sum types mean that there is no static check for whether the error has actually been handled or not. I dunno, my IntelliJ calls out unhandled errors. I imagine go-vet does as well.
  - grumpyprole 3y ago
    A simple syntactic check will only ever work as a heuristic. Heuristics don't work for all cases and can be noisy. The point is, no modern language should need such hacks. This problem was completely solved in the 70s with sum types.
- dthul 3y ago
  Ever since I learned of sum types, they have ruined my enjoyment of programming languages which don't have them. I sorely miss them in C++ for example (and std::variant is not a worthy alternative). I don't understand why any new language wouldn't have them.
  - koolba 3y ago
    Pedantic typechecking is like learning to spot improper kerning, you think it’s a good thing but you spend your entire life cringing at the world around you.
  - valenterry 3y ago
    Just wait until you learn union types, type classes, type providers, and so on. It's even worse afterwards. :-)
  - galkk 3y ago
    std::variant is a good example of many things bad with c++ improvement process, as a language. If you want to just pattern match on type of visitor there is “another convenience helper” that you need to bring, and result still looks not pleasant. Introduced in like c++17, even in c++23 you still need to write a std::visit to process it. Committee members waste time on yak shaving that std::print
- lpapez 3y ago
  In theory the lack of sum types sounds like a drawback for Go error handling, in practice it does not matter at all IMO. So far I have never worked a Go project without a strict linter enabled on the pipeline checking that you handled the case when err != nil. I don't care if it is the compiler or the linter doing it, the end result in practice is that there actually is no chance of forgetting to check the error, and works just as well as a stronger type system while also making the code stupidly obvious to read.
  - grumpyprole 3y ago
    > no chance of forgetting to check the error, and works just as well as a stronger type system A linter-based syntactic check is no substitute for a proper type system. A type system gives a machine checked proof. A heuristic catches some but not all failures to handle errors, it will also give false positives.
    - foldr 3y ago
      Error handling via sum types only enforces the rather weak constraint that you cannot access a non-error return value in the case where the function returns an error. It certainly doesn’t catch all failures to handle errors. For example, in Rust you are perfectly free to call a function which returns a Result and then ignore its return value (hence ignoring the case where an error occurred). Go’s error checking linters impose stricter constraints in some respects than the constraints on error handling imposed by Rust’s type system.
      - grumpyprole 3y ago
        > only enforces the rather weak constraint that you cannot access a non-error return value in the case where the function returns an error. This "rather weak constraint" as you put it, completely solves Tony Hoare's "billion dollar mistake": null pointer exceptions. Something Go also suffers from due to lack of Sum types. With regard to your Rust example, the compiler will give a warning that can be turned into an error to completely prevent this, if desired. As the parent said, sum types are "foundational" and have many applications for writing safe statically checked code. Eradicating null pointers and enabling chainable result types are only the tip of the iceberg.
- Tozen 3y ago
  A good point. Newer languages influenced by Go, like Vlang[1], have sum types partially for such reasons. [1]: https://github.com/vlang/v/blob/master/doc/docs.md#sum-types https://github.com/vlang/v/blob/master/doc/docs.md#sum-types
- memefrog 3y ago
  No language has a 'static check for whether the error has actually been handled or not'. In Rust, for example, you can just 'unwrap' an error. In Haskell you can use 'fromJust'. And in Go you can just ignore 'err' and assume it is 'nil'. Sum types might be the 'mathematical dual of product types' but programming languages are not mathematics. The possibly implementations of sum types are quite varied. It makes sense in low-level languages for the programmer to use what makes sense in the particular situation.
  - grumpyprole 3y ago
    Unwrap and fromJust can be disallowed if need be, they are "unsafe" convenience functions whose use can and should be tracked. Not all languages with sum types will permit them. Rust also has "unsafe" code blocks, should we also claim it is therefore not memory safe? Some would try to do so, but at least this unsafe code is tracked and not idiomatic. > programming languages are not mathematics This may be how you choose to view them. But many of us seeking to build safer and more correct software aim to make programming more like mathematics. Mathematics tells us how to compose and tells us how to prove. Both things the software industry is currently failing at.
    - memefrog 3y ago
      >Unwrap and fromJust can be disallowed if need be, they are "unsafe" convenience functions whose use can and should be tracked. And with the same sort of third-party tools you use to 'track' those and ensure they're not used, you can track unused error returns in Go or C. > Not all languages with sum types will permit them. All do. >Rust also has "unsafe" code blocks, should we also claim it is therefore not memory safe? Some would try to do so, but at least this unsafe code is tracked and not idiomatic. Absolutely we should! Rust fanatics try to claim it is a memory-safe language when it isn't. Real memory-safe languages like Java have existed for far longer. >This may be how you choose to view them. But many of us seeking to build safer and more correct software aim to make programming more like mathematics. Mathematics tells us how to compose and tells us how to prove. Both things the software industry is currently failing at. You missed the entire point of what I said.
cdaringe 3y ago
Cries in go. I segfaulted go while learning it in the first 5 minutes. Its a a solved problem, unfit for general purpose programming on this problem class alone

grumpyprole 3y ago

Go's lack of sum types mean that there is no static check for whether the error has actually been handled or not. Go's designers went to all the trouble of having a static type system, but then failed to properly reap the benefits. Sum types are the mathematical dual of product types. It makes sense for any modern language to include them.

kosherhurricane 3y ago
> Go's lack of sum types mean that there is no static check for whether the error has actually been handled or not. I dunno, my IntelliJ calls out unhandled errors. I imagine go-vet does as well.
- grumpyprole 3y ago
  A simple syntactic check will only ever work as a heuristic. Heuristics don't work for all cases and can be noisy. The point is, no modern language should need such hacks. This problem was completely solved in the 70s with sum types.
dthul 3y ago
Ever since I learned of sum types, they have ruined my enjoyment of programming languages which don't have them. I sorely miss them in C++ for example (and std::variant is not a worthy alternative). I don't understand why any new language wouldn't have them.
- koolba 3y ago
  Pedantic typechecking is like learning to spot improper kerning, you think it’s a good thing but you spend your entire life cringing at the world around you.
- valenterry 3y ago
  Just wait until you learn union types, type classes, type providers, and so on. It's even worse afterwards. :-)
- galkk 3y ago
  std::variant is a good example of many things bad with c++ improvement process, as a language. If you want to just pattern match on type of visitor there is “another convenience helper” that you need to bring, and result still looks not pleasant. Introduced in like c++17, even in c++23 you still need to write a std::visit to process it. Committee members waste time on yak shaving that std::print
lpapez 3y ago
In theory the lack of sum types sounds like a drawback for Go error handling, in practice it does not matter at all IMO. So far I have never worked a Go project without a strict linter enabled on the pipeline checking that you handled the case when err != nil. I don't care if it is the compiler or the linter doing it, the end result in practice is that there actually is no chance of forgetting to check the error, and works just as well as a stronger type system while also making the code stupidly obvious to read.
- grumpyprole 3y ago
  > no chance of forgetting to check the error, and works just as well as a stronger type system A linter-based syntactic check is no substitute for a proper type system. A type system gives a machine checked proof. A heuristic catches some but not all failures to handle errors, it will also give false positives.
  - foldr 3y ago
    Error handling via sum types only enforces the rather weak constraint that you cannot access a non-error return value in the case where the function returns an error. It certainly doesn’t catch all failures to handle errors. For example, in Rust you are perfectly free to call a function which returns a Result and then ignore its return value (hence ignoring the case where an error occurred). Go’s error checking linters impose stricter constraints in some respects than the constraints on error handling imposed by Rust’s type system.
    - grumpyprole 3y ago
      > only enforces the rather weak constraint that you cannot access a non-error return value in the case where the function returns an error. This "rather weak constraint" as you put it, completely solves Tony Hoare's "billion dollar mistake": null pointer exceptions. Something Go also suffers from due to lack of Sum types. With regard to your Rust example, the compiler will give a warning that can be turned into an error to completely prevent this, if desired. As the parent said, sum types are "foundational" and have many applications for writing safe statically checked code. Eradicating null pointers and enabling chainable result types are only the tip of the iceberg.
Tozen 3y ago
A good point. Newer languages influenced by Go, like Vlang[1], have sum types partially for such reasons. [1]: https://github.com/vlang/v/blob/master/doc/docs.md#sum-types https://github.com/vlang/v/blob/master/doc/docs.md#sum-types
memefrog 3y ago
No language has a 'static check for whether the error has actually been handled or not'. In Rust, for example, you can just 'unwrap' an error. In Haskell you can use 'fromJust'. And in Go you can just ignore 'err' and assume it is 'nil'. Sum types might be the 'mathematical dual of product types' but programming languages are not mathematics. The possibly implementations of sum types are quite varied. It makes sense in low-level languages for the programmer to use what makes sense in the particular situation.
- grumpyprole 3y ago
  Unwrap and fromJust can be disallowed if need be, they are "unsafe" convenience functions whose use can and should be tracked. Not all languages with sum types will permit them. Rust also has "unsafe" code blocks, should we also claim it is therefore not memory safe? Some would try to do so, but at least this unsafe code is tracked and not idiomatic. > programming languages are not mathematics This may be how you choose to view them. But many of us seeking to build safer and more correct software aim to make programming more like mathematics. Mathematics tells us how to compose and tells us how to prove. Both things the software industry is currently failing at.
  - memefrog 3y ago
    >Unwrap and fromJust can be disallowed if need be, they are "unsafe" convenience functions whose use can and should be tracked. And with the same sort of third-party tools you use to 'track' those and ensure they're not used, you can track unused error returns in Go or C. > Not all languages with sum types will permit them. All do. >Rust also has "unsafe" code blocks, should we also claim it is therefore not memory safe? Some would try to do so, but at least this unsafe code is tracked and not idiomatic. Absolutely we should! Rust fanatics try to claim it is a memory-safe language when it isn't. Real memory-safe languages like Java have existed for far longer. >This may be how you choose to view them. But many of us seeking to build safer and more correct software aim to make programming more like mathematics. Mathematics tells us how to compose and tells us how to prove. Both things the software industry is currently failing at. You missed the entire point of what I said.

cdaringe 3y ago

Cries in go. I segfaulted go while learning it in the first 5 minutes. Its a a solved problem, unfit for general purpose programming on this problem class alone