5 ms·

> There's a good argument for immutability by default, but many programmers dislike all the extra declarations required. That's one little reason why Rust is l

> There's a good argument for immutability by default, but many programmers dislike all the extra declarations required. That's one little reason why Rust is loved by many: immutability by default. Meanwhile, it's not even possible in Go to declare immutable variables!

Cthulhu_ 2y ago
I hope it gets added, it adds so much safety to the language. Mind you, Go is not a very safe language in general, its type system is pretty loose compared to e.g. Java or Typescript. I don't believe it wants to be though.
- tapirl 2y ago
  It is possible to add more immutability in Go. There are many proposals for this: https://github.com/go101/go101/wiki/Go-immutable-value-proposal-list https://github.com/go101/go101/wiki/Go-immutable-value-propo.... The main reason nothing happened in this direction is the core team think it is not important enough.
  - Animats 2y ago
    It's tough to retrofit new restrictions to old code. C/c++ code still doesn't have "const" everywhere it could. You have to make the default immutable - write "var" or "mut", not "const" - or it doesn't get used everywhere it should. But that breaks old code.
  - kiitos 2y ago
    It's very clear that the reason these kinds of proposals haven't been accepted has nothing to do with the core team not believing they're important enough, but instead because of the impact that they have on the rest of the language.
    - tapirl 2y ago
      What impact in your opinion?
      - kiitos 2y ago
        Immutability is a fundamental property of a language, it's not something that can be bolted on post-facto in a version update. Go as a language doesn't provide immutability.
        tapirl 2y ago
        If the "for ;;" loop semantics can be bolted on post-facto in a version update, nothing else couldn't. Go provides certain immutability.
        kiitos 2y ago
        It does not. Believe what you will.
        tapirl 2y ago
        You are not familiar with Go.
- shrimp_emoji 2y ago
  [dead]
XorNot 2y ago
Immutable by default is only really possible now that we have gobs of memory though. I'm not even sure it's likely to stay popular: the demands of data processing at scale mean we're all likely to be routinely handling gigantic datasets which we don't want to copy all over the place. The real problem is just visibility: am I editing a copy of the original? Who else can edit the original? Who's going to? I'd argue those two questions are what we actually want to know the answer to, and immutability criteria are just an awkward compromise solution.
- the8472 2y ago
  Immutable by default doesn't mean you have to write your program as a giant copy-aon-write or log-structured architecture. You can still commit all your shared global program state behind a mutex/rwlock crimes when that makes sense. But you can contain write access to that data to the places where it's needed. And at the function-local level move elision should turn copy-and-modify to in-place modification if the original is no longer used.
- tialaramex 2y ago
  "Immutable by default is only really possible now that we have gobs of memory though" I don't think so, actually. It's just changing the default. A choice to have types like Java's String which are always immutable might drive up memory usage, but just realising that the defaults are wrong and altering the language doesn't impact this at all, instead it makes your programs more explicit about what's actually happening.
- pico303 2y ago
  Immutability isn’t a new idea, and you don’t need “gobs of memory.” Erlang was developed in the 80’s.
- p_l 2y ago
  LLVM will transform your mutable program into immutable one anyway because otherwise it's much harder if not impossible to write a lot of optimizations or validations. You can collapse a lot of the additional copies at compile time even for C

Cthulhu_ 2y ago

I hope it gets added, it adds so much safety to the language. Mind you, Go is not a very safe language in general, its type system is pretty loose compared to e.g. Java or Typescript. I don't believe it wants to be though.

tapirl 2y ago
It is possible to add more immutability in Go. There are many proposals for this: https://github.com/go101/go101/wiki/Go-immutable-value-proposal-list https://github.com/go101/go101/wiki/Go-immutable-value-propo.... The main reason nothing happened in this direction is the core team think it is not important enough.
- Animats 2y ago
  It's tough to retrofit new restrictions to old code. C/c++ code still doesn't have "const" everywhere it could. You have to make the default immutable - write "var" or "mut", not "const" - or it doesn't get used everywhere it should. But that breaks old code.
- kiitos 2y ago
  It's very clear that the reason these kinds of proposals haven't been accepted has nothing to do with the core team not believing they're important enough, but instead because of the impact that they have on the rest of the language.
  - tapirl 2y ago
    What impact in your opinion?
    - kiitos 2y ago
      Immutability is a fundamental property of a language, it's not something that can be bolted on post-facto in a version update. Go as a language doesn't provide immutability.
      - tapirl 2y ago
        If the "for ;;" loop semantics can be bolted on post-facto in a version update, nothing else couldn't. Go provides certain immutability.
        kiitos 2y ago
        It does not. Believe what you will.
        tapirl 2y ago
        You are not familiar with Go.
shrimp_emoji 2y ago
[dead]

XorNot 2y ago

Immutable by default is only really possible now that we have gobs of memory though. I'm not even sure it's likely to stay popular: the demands of data processing at scale mean we're all likely to be routinely handling gigantic datasets which we don't want to copy all over the place. The real problem is just visibility: am I editing a copy of the original? Who else can edit the original? Who's going to? I'd argue those two questions are what we actually want to know the answer to, and immutability criteria are just an awkward compromise solution.

the8472 2y ago
Immutable by default doesn't mean you have to write your program as a giant copy-aon-write or log-structured architecture. You can still commit all your shared global program state behind a mutex/rwlock crimes when that makes sense. But you can contain write access to that data to the places where it's needed. And at the function-local level move elision should turn copy-and-modify to in-place modification if the original is no longer used.
tialaramex 2y ago
"Immutable by default is only really possible now that we have gobs of memory though" I don't think so, actually. It's just changing the default. A choice to have types like Java's String which are always immutable might drive up memory usage, but just realising that the defaults are wrong and altering the language doesn't impact this at all, instead it makes your programs more explicit about what's actually happening.
pico303 2y ago
Immutability isn’t a new idea, and you don’t need “gobs of memory.” Erlang was developed in the 80’s.
p_l 2y ago
LLVM will transform your mutable program into immutable one anyway because otherwise it's much harder if not impossible to write a lot of optimizations or validations. You can collapse a lot of the additional copies at compile time even for C