3 ms·

There's a proposal[1] by Ian Lance Taylor of the go team, but it includes every sum type implicitly including nil. Which very much not what you'd expect of a su

by ajb 2y ago

There's a proposal[1] by Ian Lance Taylor of the go team, but it includes every sum type implicitly including nil. Which very much not what you'd expect of a sum type, but every interface being zeroable seems to be embedded quite deeply in the language. [1]https://github.com/golang/go/issues/57644 https://github.com/golang/go/issues/57644

thiht 2y ago
Every proposal they make start with something absurd, gets backslash in the comment, and after a few iterations it ends up with a lovely proposal. I almost suspect they do it on purpose to make sure each significant proposal gets enough engagement
- ncruces 2y ago
  Sum types in Go need to have a zero value, if it's not nil, it needs to be something else. There's nothing purposely ridiculous about it.
  - valenterry 2y ago
    It is ridiculous. Nulls were not called "the billion dollar mistake" in Java for no reason.
    - int_19h 2y ago
      Thing is, it's not an easy problem to solve while retaining the simplicity. It means that now you need to have rules in the language for definitely-initialized fields (since you can't just default-init them to null as there is no null). Which means that you need full-fledged constructors for everything, and syntax for invoking them in all cases where they may be needed - e.g. think about what should happen if you try to create an array of structs with ref fields in them. This is all solvable - C++ and Rust both do it, for example. But it introduces a lot of complexity to the language.
      - valenterry 2y ago
        Yeah - but it's not like this hasn't been researched and done before no? But adding it in retrospect is probably not easy, I agree.
        int_19h 2y ago
        It has been done before, but then you end up with a language twice as complicated as Go. Look at all the rules around initialization - constructors, temporaries, move semantics, RVO etc - in C++ for an example. If your goal is specifically to design a simple language, that is not a good path to go down. FWIW my personal opinion is that the resulting complexity is necessary, and we as engineers just have to bite the bullet and deal with that mental overhead (and if it means that coding becomes too complicated for some, so be it). But the market ultimately decides; and it decided in favor of lots of code that's cheap and fast to write even at the expense of bugs, so we have tools catering specifically to that.
        School-Cotton 2y ago
        It’s disingenuous to point to C++ as an example of essential complexity here. C++ is just extremely unnecessarily complex in every way. I’m not really aware of anywhere that lack of default zero initialization makes rust more complicated, for example.
        int_19h 2y ago
        I'm not claiming that C++ level of complexity is necessary, only that it is a widely known language with a lot of features that exist solely to enable this one thing. Rust can do this with less complexity by embracing choices that, while conceptually simple, are very unorthodox and unintuitive, such as everything being a move rather than a copy with few exceptions (whereas in pretty much every other PL it has always been the other way around, if move semantics is supported at all).
        ncruces 2y ago
        You're calling designing a language with nil in 2007–2009 ridiculous. We could argue that, but that's not what I wrote. I wrote that, after 15 years of baggage, there's nothing purposely ridiculous about stating that Go sum types must have a zero value (either nil or something else). Either Go sum types have a zero value; or they can't be used everywhere a type can be used in Go; or you're radically and backwards incompatibly changing the language.
- atombender 2y ago
  I wish the error handling proposal had gone the same way. The numerous error handling proposals finally got an official proposal [1] for a "try" keyword, which was arguably less elegant than some other proposals, and got a lot of pushback, and the Go team eventually withdrew it for somewhat unclear reasons. They admitted the proposal was flawed, but the main reason seems to be that many comments didn't want a solution in the first place ("for many of you it’s simply not a problem to solve"). [1] https://www.infoq.com/news/2019/07/go-try-proposal-rejected/ https://www.infoq.com/news/2019/07/go-try-proposal-rejected/
valenterry 2y ago
Go repeating the billion dollar mistake. Why am I not surprised...
- ajb 2y ago
  Thinking about it, it's not obviously worth making sum types non-nillable unless you also figure out a comprehensive nil-free solution for the rest of the language. Because if you include any interface in your sum, that branch will be nillable anyway. So you might as well check for nil only once at the base case, rather than on each branch.
masklinn 2y ago
> every interface being zeroable seems to be embedded quite deeply in the language. Not just every interface, every single type. And it’s at the very core of the language. For any type T you can name, you can write var v T And it’ll give you a v you can interact with, no opt out. You can barely opt out of implicit shallow copies via hacks based around lock method names.
kubb 2y ago
Come to think of it, this might be one of the reasons why we don’t have them. There’s no obvious solution without drawbacks, but I believe there are solutions.

by ajb 2y ago

thiht 2y ago

Every proposal they make start with something absurd, gets backslash in the comment, and after a few iterations it ends up with a lovely proposal. I almost suspect they do it on purpose to make sure each significant proposal gets enough engagement

ncruces 2y ago
Sum types in Go need to have a zero value, if it's not nil, it needs to be something else. There's nothing purposely ridiculous about it.
- valenterry 2y ago
  It is ridiculous. Nulls were not called "the billion dollar mistake" in Java for no reason.
  - int_19h 2y ago
    Thing is, it's not an easy problem to solve while retaining the simplicity. It means that now you need to have rules in the language for definitely-initialized fields (since you can't just default-init them to null as there is no null). Which means that you need full-fledged constructors for everything, and syntax for invoking them in all cases where they may be needed - e.g. think about what should happen if you try to create an array of structs with ref fields in them. This is all solvable - C++ and Rust both do it, for example. But it introduces a lot of complexity to the language.
    - valenterry 2y ago
      Yeah - but it's not like this hasn't been researched and done before no? But adding it in retrospect is probably not easy, I agree.
      - int_19h 2y ago
        It has been done before, but then you end up with a language twice as complicated as Go. Look at all the rules around initialization - constructors, temporaries, move semantics, RVO etc - in C++ for an example. If your goal is specifically to design a simple language, that is not a good path to go down. FWIW my personal opinion is that the resulting complexity is necessary, and we as engineers just have to bite the bullet and deal with that mental overhead (and if it means that coding becomes too complicated for some, so be it). But the market ultimately decides; and it decided in favor of lots of code that's cheap and fast to write even at the expense of bugs, so we have tools catering specifically to that.
        School-Cotton 2y ago
        It’s disingenuous to point to C++ as an example of essential complexity here. C++ is just extremely unnecessarily complex in every way. I’m not really aware of anywhere that lack of default zero initialization makes rust more complicated, for example.
        int_19h 2y ago
        I'm not claiming that C++ level of complexity is necessary, only that it is a widely known language with a lot of features that exist solely to enable this one thing. Rust can do this with less complexity by embracing choices that, while conceptually simple, are very unorthodox and unintuitive, such as everything being a move rather than a copy with few exceptions (whereas in pretty much every other PL it has always been the other way around, if move semantics is supported at all).
      - ncruces 2y ago
        You're calling designing a language with nil in 2007–2009 ridiculous. We could argue that, but that's not what I wrote. I wrote that, after 15 years of baggage, there's nothing purposely ridiculous about stating that Go sum types must have a zero value (either nil or something else). Either Go sum types have a zero value; or they can't be used everywhere a type can be used in Go; or you're radically and backwards incompatibly changing the language.
atombender 2y ago
I wish the error handling proposal had gone the same way. The numerous error handling proposals finally got an official proposal [1] for a "try" keyword, which was arguably less elegant than some other proposals, and got a lot of pushback, and the Go team eventually withdrew it for somewhat unclear reasons. They admitted the proposal was flawed, but the main reason seems to be that many comments didn't want a solution in the first place ("for many of you it’s simply not a problem to solve"). [1] https://www.infoq.com/news/2019/07/go-try-proposal-rejected/ https://www.infoq.com/news/2019/07/go-try-proposal-rejected/

valenterry 2y ago

Go repeating the billion dollar mistake. Why am I not surprised...

ajb 2y ago
Thinking about it, it's not obviously worth making sum types non-nillable unless you also figure out a comprehensive nil-free solution for the rest of the language. Because if you include any interface in your sum, that branch will be nillable anyway. So you might as well check for nil only once at the base case, rather than on each branch.

masklinn 2y ago

> every interface being zeroable seems to be embedded quite deeply in the language. Not just every interface, every single type. And it’s at the very core of the language. For any type T you can name, you can write var v T And it’ll give you a v you can interact with, no opt out. You can barely opt out of implicit shallow copies via hacks based around lock method names.

kubb 2y ago

Come to think of it, this might be one of the reasons why we don’t have them. There’s no obvious solution without drawbacks, but I believe there are solutions.