4 ms·

This isn't really a practical problem. If you created the slice, you control it and you can modify its elements, append to it, etc. If you didn't create the s

This isn't really a practical problem. If you created the slice, you control it and you can modify its elements, append to it, etc. If you didn't create the slice, you don't control it. If you want to modify it or append to it, you should copy it first. This has reflected how I've seen Go used professionally by people experienced in the language. The language could offer more help (but probably never will), but it's not hardly a regression from C. The real regression from C is the lack of const pointers.

pjmlp 2y ago
And enums, type Colours (Red, Blue, Green) //.... c := Colours.Blue a := pred(c) b := succ(c) for x := range Colours { //.... } 1976's Pascal style is unthinkable to ever land in Go, but we have iota and const, lets not complain.
- kbolino 2y ago
  Go's "enums" are worse than a lot of other languages, but they're not worse than C.
  - pjmlp 2y ago
    Indeed, then again maybe we should not design languages with features worse than C in the 21st century, having 60 years of field experience.
    - kbolino 2y ago
      It's not worse. It's just only slightly better. The most damning thing you can say about Go is not that it doesn't improve upon C, it's that it improves only on C (and only in the ways cared about). The authors of Go really didn't examine other languages very closely. So starting with the authors' goals (light on the page, bounds checked, concurrency with message passing, easy to pick up, fast to compile) and a fairly deep knowledge of C (but little else) you pretty much get Go (especially early Go).
      - pjmlp 2y ago
        Even that isn't really the case, as Go, as it started, was basically Inferno's Limbo in a new clothing, with some influence from Oberon-2 method syntax and the SYSTEM package as unsafe. Unfortunately afterwards they decided to follow Wirth's quest in Oberon-07 minimalism, instead of Active Oberon.
        baranul 2y ago
        I've always felt that the behavior of Go's ownership, in regards to minimalism, is a reflection of it being considered a solution for their internal problems. This is something outside of what users are requesting or needing. People have to look at Go alternative languages like Goplus, V (Vlang), Borogo, etc... for wanted features or greater responsiveness to user demands.
  - 9rx 2y ago
    Go enums are the same as in every single other language. After all, all an enum does is count. There isn't anything more you can do with it. You can introduce data structures and types that utilize enums, with some languages taking that idea further than others, but that's well beyond enums themselves.
    - masklinn 2y ago
      > Go enums are the same as in every single other language. After all, all an enum does is count. There isn't anything more you can do with it. You may want to meet a modern language one day. Or hell not even a modern language, even a shit one like Java. As it turns out there are languages where you can define an enum foo { bar, baz } and when you type a parameter as a `foo` you're not at risk of getting 69 or 4328.
      - 9rx 2y ago
        > You may want to meet a modern language one day. Like what? CrabLang? Its enums are identical to Go, unsurprisingly. Above the enum rests a discriminated union that ends up hiding the details of the enum. That is where things begin to differ greatly. You have to do some real trickery to actually get at the underlying enum result in that language. But, when you do, you see that it is exactly the same. > and when you type a parameter as a `foo` you're not at risk of getting 69 or 4328. That's thanks to the type system, though, not enums. Enums are not a type. Enums are a number generator. Hence the name.
        tialaramex 2y ago
        > That's thanks to the type system, though, not enums. Enums are not a type. Enums are a number generator. Hence the name. What's happened here is that you've mistaken "Things I believe" for "What everybody else believes" but you're talking to other people, not yourself, so, this makes you seem like a blithering idiot. The particular version of this trap you've fallen into is a variation of the "It's all just the machine integers" mental model from C. It's just a model and the problem arises when you mistake that model for reality. Now, technically this model isn't even correct for C's abstract machine, but it's close enough for many programmers and it tends to match how they think the hardware works, which is even more confusing for the hardware people who know how it actually works but that's another conversation. This model is completely useless for languages which don't have the same type system, and so it's no surprise that it immediately led you astray.
kccqzy 2y ago
The practical problem is about transferring the control. Without it, you end up doing way too much defensive copying.

pjmlp 2y ago

And enums, type Colours (Red, Blue, Green) //.... c := Colours.Blue a := pred(c) b := succ(c) for x := range Colours { //.... } 1976's Pascal style is unthinkable to ever land in Go, but we have iota and const, lets not complain.

kbolino 2y ago
Go's "enums" are worse than a lot of other languages, but they're not worse than C.
- pjmlp 2y ago
  Indeed, then again maybe we should not design languages with features worse than C in the 21st century, having 60 years of field experience.
  - kbolino 2y ago
    It's not worse. It's just only slightly better. The most damning thing you can say about Go is not that it doesn't improve upon C, it's that it improves only on C (and only in the ways cared about). The authors of Go really didn't examine other languages very closely. So starting with the authors' goals (light on the page, bounds checked, concurrency with message passing, easy to pick up, fast to compile) and a fairly deep knowledge of C (but little else) you pretty much get Go (especially early Go).
    - pjmlp 2y ago
      Even that isn't really the case, as Go, as it started, was basically Inferno's Limbo in a new clothing, with some influence from Oberon-2 method syntax and the SYSTEM package as unsafe. Unfortunately afterwards they decided to follow Wirth's quest in Oberon-07 minimalism, instead of Active Oberon.
      - baranul 2y ago
        I've always felt that the behavior of Go's ownership, in regards to minimalism, is a reflection of it being considered a solution for their internal problems. This is something outside of what users are requesting or needing. People have to look at Go alternative languages like Goplus, V (Vlang), Borogo, etc... for wanted features or greater responsiveness to user demands.
- 9rx 2y ago
  Go enums are the same as in every single other language. After all, all an enum does is count. There isn't anything more you can do with it. You can introduce data structures and types that utilize enums, with some languages taking that idea further than others, but that's well beyond enums themselves.
  - masklinn 2y ago
    > Go enums are the same as in every single other language. After all, all an enum does is count. There isn't anything more you can do with it. You may want to meet a modern language one day. Or hell not even a modern language, even a shit one like Java. As it turns out there are languages where you can define an enum foo { bar, baz } and when you type a parameter as a `foo` you're not at risk of getting 69 or 4328.
    - 9rx 2y ago
      > You may want to meet a modern language one day. Like what? CrabLang? Its enums are identical to Go, unsurprisingly. Above the enum rests a discriminated union that ends up hiding the details of the enum. That is where things begin to differ greatly. You have to do some real trickery to actually get at the underlying enum result in that language. But, when you do, you see that it is exactly the same. > and when you type a parameter as a `foo` you're not at risk of getting 69 or 4328. That's thanks to the type system, though, not enums. Enums are not a type. Enums are a number generator. Hence the name.
      - tialaramex 2y ago
        > That's thanks to the type system, though, not enums. Enums are not a type. Enums are a number generator. Hence the name. What's happened here is that you've mistaken "Things I believe" for "What everybody else believes" but you're talking to other people, not yourself, so, this makes you seem like a blithering idiot. The particular version of this trap you've fallen into is a variation of the "It's all just the machine integers" mental model from C. It's just a model and the problem arises when you mistake that model for reality. Now, technically this model isn't even correct for C's abstract machine, but it's close enough for many programmers and it tends to match how they think the hardware works, which is even more confusing for the hardware people who know how it actually works but that's another conversation. This model is completely useless for languages which don't have the same type system, and so it's no surprise that it immediately led you astray.

kccqzy 2y ago

The practical problem is about transferring the control. Without it, you end up doing way too much defensive copying.