5 ms·

I'm not sure if I understand you: the `res, err := fun(); if err != nil` pattern shows up everywhere in most Go code, and I think that pattern-matching would be

by oisdk 7y ago

I'm not sure if I understand you: the `res, err := fun(); if err != nil` pattern shows up everywhere in most Go code, and I think that pattern-matching would be a better fit for it. Swift does it pretty well, as does Rust, both of which occupy a similar space to Go. I get that there's a tradeoff with including certain features, I suppose I disagree that the tradeoff is a negative one when it comes to things as simple as pattern-matching, and I think it should be included in languages like Go.

deleted 7y ago
[deleted]
reificator 7y ago
I'm not arguing against pattern matching. Like I said, I prefer it where possible. I'm also not arguing in favor of multiple return with mandatory checked err values. (Though I prefer either over the collective insanity that went into making exceptions the default approach to handling errors in most languages.) I'm just pointing out that I think you're missing a key word in the stance of the go language developers. They're not saying that if err != nil is better or worse, simpler or more complex, etc... than pattern matching for application code. They're saying that supporting pattern matching makes the language itself more complex, and they're not in favor of that tradeoff. You're focusing on application complexity, and that's a very different thing. Both the go language authors as well as the kind of developers that choose to use go think of the relative simplicity of the language itself as a feature. Even if it causes the application code to be slightly more complex. It's just another dimension that can be used when comparing programming languages, and one that group tends to value more than other groups.
- oisdk 7y ago
  Oh ok, I understand. I don't really buy the idea that go is a simple language, I have to say. A lot of go's design choices read (to me) as needlessly complex, like features were added to address corner cases one by one instead of implementing the fundamental feature in the first place. "Multiple return values" instead of tuples; several weird variations on the c-style for-loop; special-cased nil values instead of `Maybe` or `Optional`; `interface {}` and special in-built types instead of generics, etc. ADTs and pattern-matching would obviate "multiple return values", nils, and greatly simplify error handling.
  - reificator 7y ago
    A very instructive exercise for anyone who is or intends to be a software developer is to write some sort of interpreter and/or compiler. (As well as a virtual machine and/or emulator) Depending on your approach this can take a weekend, a few months, or the rest of your life. For instance, and amusingly enough written in golang, one of the most respected recent books on this topic is `Writing an Interpreter in Go` and its sequel `Writing a Compiler in Go`. https://interpreterbook.com/ https://interpreterbook.com/ and https://compilerbook.com/ https://compilerbook.com/ Both of these books are reasonably short, and have the reader make meaningful progress within a weekend. Going through the motions of actually making your own programming language (or reimplementing an existing one) teaches you a lot of things you wouldn't otherwise expect about how to write general code, how to use existing languages effectively, and how things work under the hood. It's also one of the best ways to really get a practical feel for how to approach unit testing. It's an exercise I'd recommend if you haven't gone through it already. It might make it really click for you why some features that seem like a no brainer and should be in every language aren't, and why some undesirable "features" are so prevalent.
    - Scarbutt 7y ago
      one of the most respected recent books on this topic is `Writing an Interpreter in Go` Is 'recent' the key word here? ;) cause that is a very bold claim to make.
      - reificator 7y ago
        https://news.ycombinator.com/item?id=21154309 https://news.ycombinator.com/item?id=21154309
    - AdieuToLogic 7y ago
      > A very instructive exercise for anyone who is or intends to be a software developer is to write some sort of interpreter and/or compiler. Another exercise, perhaps less demanding in this regard, is to explore using Free Monads[0] to implement an EDSL[1] for a problem domain. Of course, the approachability of this varies based on the person involved. > For instance, and amusingly enough written in golang, one of the most respected recent books on this topic is `Writing an Interpreter in Go` and its sequel `Writing a Compiler in Go`. Queue obligatory reference to "the dragon book": Compilers: Principles, Techniques, and Tools[2] 0 - https://softwareengineering.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern https://softwareengineering.stackexchange.com/questions/2427... 1 - https://www.quora.com/What-is-an-embedded-domain-specific-language https://www.quora.com/What-is-an-embedded-domain-specific-la... 2 - https://suif.stanford.edu/dragonbook/ https://suif.stanford.edu/dragonbook/

by oisdk 7y ago

deleted 7y ago

[deleted]

reificator 7y ago

I'm not arguing against pattern matching. Like I said, I prefer it where possible. I'm also not arguing in favor of multiple return with mandatory checked err values. (Though I prefer either over the collective insanity that went into making exceptions the default approach to handling errors in most languages.) I'm just pointing out that I think you're missing a key word in the stance of the go language developers. They're not saying that if err != nil is better or worse, simpler or more complex, etc... than pattern matching for application code. They're saying that supporting pattern matching makes the language itself more complex, and they're not in favor of that tradeoff. You're focusing on application complexity, and that's a very different thing. Both the go language authors as well as the kind of developers that choose to use go think of the relative simplicity of the language itself as a feature. Even if it causes the application code to be slightly more complex. It's just another dimension that can be used when comparing programming languages, and one that group tends to value more than other groups.

oisdk 7y ago
Oh ok, I understand. I don't really buy the idea that go is a simple language, I have to say. A lot of go's design choices read (to me) as needlessly complex, like features were added to address corner cases one by one instead of implementing the fundamental feature in the first place. "Multiple return values" instead of tuples; several weird variations on the c-style for-loop; special-cased nil values instead of `Maybe` or `Optional`; `interface {}` and special in-built types instead of generics, etc. ADTs and pattern-matching would obviate "multiple return values", nils, and greatly simplify error handling.
- reificator 7y ago
  A very instructive exercise for anyone who is or intends to be a software developer is to write some sort of interpreter and/or compiler. (As well as a virtual machine and/or emulator) Depending on your approach this can take a weekend, a few months, or the rest of your life. For instance, and amusingly enough written in golang, one of the most respected recent books on this topic is `Writing an Interpreter in Go` and its sequel `Writing a Compiler in Go`. https://interpreterbook.com/ https://interpreterbook.com/ and https://compilerbook.com/ https://compilerbook.com/ Both of these books are reasonably short, and have the reader make meaningful progress within a weekend. Going through the motions of actually making your own programming language (or reimplementing an existing one) teaches you a lot of things you wouldn't otherwise expect about how to write general code, how to use existing languages effectively, and how things work under the hood. It's also one of the best ways to really get a practical feel for how to approach unit testing. It's an exercise I'd recommend if you haven't gone through it already. It might make it really click for you why some features that seem like a no brainer and should be in every language aren't, and why some undesirable "features" are so prevalent.
  - Scarbutt 7y ago
    one of the most respected recent books on this topic is `Writing an Interpreter in Go` Is 'recent' the key word here? ;) cause that is a very bold claim to make.
    - reificator 7y ago
      https://news.ycombinator.com/item?id=21154309 https://news.ycombinator.com/item?id=21154309
  - AdieuToLogic 7y ago
    > A very instructive exercise for anyone who is or intends to be a software developer is to write some sort of interpreter and/or compiler. Another exercise, perhaps less demanding in this regard, is to explore using Free Monads[0] to implement an EDSL[1] for a problem domain. Of course, the approachability of this varies based on the person involved. > For instance, and amusingly enough written in golang, one of the most respected recent books on this topic is `Writing an Interpreter in Go` and its sequel `Writing a Compiler in Go`. Queue obligatory reference to "the dragon book": Compilers: Principles, Techniques, and Tools[2] 0 - https://softwareengineering.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern https://softwareengineering.stackexchange.com/questions/2427... 1 - https://www.quora.com/What-is-an-embedded-domain-specific-language https://www.quora.com/What-is-an-embedded-domain-specific-la... 2 - https://suif.stanford.edu/dragonbook/ https://suif.stanford.edu/dragonbook/