4 ms·

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.
- valenterry 2y ago
  I wouldn't go as far as calling a language that has nil in 2007-2009 ridiculous and I didn't do so. But adding sumtypes in 2025 and using a default nil or zero value/type to it, yeah that I do call ridiculous and I stand by it. It might be a good decision even (I don't know), but it's still ridiculous by my understanding of that word.
  - ncruces 2y ago
    Look, as I wrote: Go has zero values, and for a Go type to fully participate in the Go type system, it must have a zero value. Additionally, for it to fit the 2025 implementation of the runtime, its representation in memory must have a fixed size, with fixed locations for any pointers, and the memory representation of the zero value must be zero. The runtime can change, but for the runtime to change to accommodate new concepts, the change can't obliterate the expectations of 15 years of existing code. Given those restrictions, you can either not have sum types (which is the current state of affairs, and will be for the foreseeable future), or you can pick a zero value for your sum types. If you find having a zero value for sum types ridiculous, you're simply rejecting sum types in Go, which is fine. There is, after all, a reason the proposal wasn't accepted. Otherwise, we're all happy to accept suggestions that meet the criteria of not breaking compatibility or wreaking havoc with existing code.

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.

valenterry 2y ago
I wouldn't go as far as calling a language that has nil in 2007-2009 ridiculous and I didn't do so. But adding sumtypes in 2025 and using a default nil or zero value/type to it, yeah that I do call ridiculous and I stand by it. It might be a good decision even (I don't know), but it's still ridiculous by my understanding of that word.
- ncruces 2y ago
  Look, as I wrote: Go has zero values, and for a Go type to fully participate in the Go type system, it must have a zero value. Additionally, for it to fit the 2025 implementation of the runtime, its representation in memory must have a fixed size, with fixed locations for any pointers, and the memory representation of the zero value must be zero. The runtime can change, but for the runtime to change to accommodate new concepts, the change can't obliterate the expectations of 15 years of existing code. Given those restrictions, you can either not have sum types (which is the current state of affairs, and will be for the foreseeable future), or you can pick a zero value for your sum types. If you find having a zero value for sum types ridiculous, you're simply rejecting sum types in Go, which is fine. There is, after all, a reason the proposal wasn't accepted. Otherwise, we're all happy to accept suggestions that meet the criteria of not breaking compatibility or wreaking havoc with existing code.