4 ms·

I use Haskell examples because that's the language I'm most comfortable with, but, e.g. the Result type used in Rust is another example of how this can be done

I use Haskell examples because that's the language I'm most comfortable with, but, e.g. the Result type used in Rust is another example of how this can be done better. https://rustbyexample.com/std/result.html https://rustbyexample.com/std/result.html Ergonomic error handling or generics/parametric polymorphism aren't "Haskell methodologies". Go is one of a very small number of languages that have been designed in the last decade and lack features like this. The reason I participate in HN comment threads about Go is largely how entertaining I find comments strenuously rationalizing Go's inadequacies. In one (very recent but definitely memorable) case[1], I was told that > You [should] first reconsider your need to make a generic data structure and evaluate on a case by case basis. [1]: https://news.ycombinator.com/item?id=14970919 https://news.ycombinator.com/item?id=14970919

laumars 9y ago
I didn't say ergonomic error handling nor generics et al were Haskell methodologies. I'm saying you keep coming into Go threads just to troll that Go isn't as good as Haskell. This isn't even the first thread this week you've been making Haskell vs Go comparisons.
- mrkgnao 9y ago
  Again, at the risk of repeating myself, it's not Haskell, it's "many languages other than Go, of which Haskell is one I'll be using by way of example". (I'm not sure why you made that edit, but I've made a mental note of what the last bit said. Arguing on the internet is a difficult, if useless, skill, and I'd hate to be tiresome.)
  - laumars 9y ago
    I made the edit because on reflection the part i took out was blunt and unnecessary. I felt I crossed the line so I apologize for that.
    - mrkgnao 9y ago
      That's gracious of you. :)
Veedrac 9y ago
Rust is my favourite language, I beg to disagree that its Result or Option types are more concise or require less boilerplate. The only real differences are that Rust's are type checked and harder to use.
- apta 9y ago
  Golang (may contain syntax errors): func readNumberFromFileAndDoubleIt(filename string) (int, err) { file, err = os.Open(filename) if err != nil { return 0, err } defer file.Close() // BUG!! this returns an error, but since we defer it, it is not going to be handled bytes, err := ioutil.ReadFile(filename) if err != nil { return 0, err } contents := string(bytes) i, err := strconv.Atoi(contents) if err != nil { return 0, err } return 2*i, nil } Rust (may contain syntax errors): fn read_number_from_file_and_double_it(filename: &str) -> Result<i32> { let mut file = File::open(filename)?; // file automatically closed at end of scope let mut contents = String::new(); file.read_to_string(&mut contents)?; contents.parse().map(|i| 2*i) } 4 vs 15 lines, I think it's obvious which one is easier to read
  - Veedrac 9y ago
    Sure, in an unrealistic subset of cases, try! can hide the mess. But these aren't fair, and especially nor is your comparison. Any practical code using Results soon ends up wanting to mix the errors from multiple sources. This requires a lot of boilerplate effort to make everything interop, and the machinery to reduce this is both complex and not standardised. If you don't go the upfront boilerplate-and-machinery route, things look awful. And of course, if you use something else, like an Option, you're back to let foo = match bar() { Some(foo) => foo, None => return None, }; Go is much more consistent, and less pathological. Your example is especially disingenuous, though. For example, you chastise Go with defer file.Close() // BUG!! this returns an error, but since we defer it, it is not going to be handled but ignore the fact that this "bug" is nonoptionally hardcoded[1] into the Rust program. Which is it then? Rust's error handling looks nice on fake examples, and manageable inside self-contained libraries. My experience of actually using multiple libraries is that Rusts error handling is a choice between tangly handling of nested errors or verbose attempts to early-exit. [1]: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/fd.rs#L242 https://github.com/rust-lang/rust/blob/master/src/libstd/sys...

laumars 9y ago

I didn't say ergonomic error handling nor generics et al were Haskell methodologies. I'm saying you keep coming into Go threads just to troll that Go isn't as good as Haskell. This isn't even the first thread this week you've been making Haskell vs Go comparisons.

mrkgnao 9y ago
Again, at the risk of repeating myself, it's not Haskell, it's "many languages other than Go, of which Haskell is one I'll be using by way of example". (I'm not sure why you made that edit, but I've made a mental note of what the last bit said. Arguing on the internet is a difficult, if useless, skill, and I'd hate to be tiresome.)
- laumars 9y ago
  I made the edit because on reflection the part i took out was blunt and unnecessary. I felt I crossed the line so I apologize for that.
  - mrkgnao 9y ago
    That's gracious of you. :)

Veedrac 9y ago

Rust is my favourite language, I beg to disagree that its Result or Option types are more concise or require less boilerplate. The only real differences are that Rust's are type checked and harder to use.

apta 9y ago
Golang (may contain syntax errors): func readNumberFromFileAndDoubleIt(filename string) (int, err) { file, err = os.Open(filename) if err != nil { return 0, err } defer file.Close() // BUG!! this returns an error, but since we defer it, it is not going to be handled bytes, err := ioutil.ReadFile(filename) if err != nil { return 0, err } contents := string(bytes) i, err := strconv.Atoi(contents) if err != nil { return 0, err } return 2*i, nil } Rust (may contain syntax errors): fn read_number_from_file_and_double_it(filename: &str) -> Result<i32> { let mut file = File::open(filename)?; // file automatically closed at end of scope let mut contents = String::new(); file.read_to_string(&mut contents)?; contents.parse().map(|i| 2*i) } 4 vs 15 lines, I think it's obvious which one is easier to read
- Veedrac 9y ago
  Sure, in an unrealistic subset of cases, try! can hide the mess. But these aren't fair, and especially nor is your comparison. Any practical code using Results soon ends up wanting to mix the errors from multiple sources. This requires a lot of boilerplate effort to make everything interop, and the machinery to reduce this is both complex and not standardised. If you don't go the upfront boilerplate-and-machinery route, things look awful. And of course, if you use something else, like an Option, you're back to let foo = match bar() { Some(foo) => foo, None => return None, }; Go is much more consistent, and less pathological. Your example is especially disingenuous, though. For example, you chastise Go with defer file.Close() // BUG!! this returns an error, but since we defer it, it is not going to be handled but ignore the fact that this "bug" is nonoptionally hardcoded[1] into the Rust program. Which is it then? Rust's error handling looks nice on fake examples, and manageable inside self-contained libraries. My experience of actually using multiple libraries is that Rusts error handling is a choice between tangly handling of nested errors or verbose attempts to early-exit. [1]: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/fd.rs#L242 https://github.com/rust-lang/rust/blob/master/src/libstd/sys...