4 ms·

'Go doesn't have immutables'? So it has mutability then. How does that affect how 'boring' a language is? Surely immutability is simpler.

• tsimionescu 6y ago
  Immutability is much more difficult to reason about except for some very mathy problems. It is extremely natural to think in terms of state, so much so that almost all algorithms you'll find in computer science are commonly expressed in imperative terms.
  • dimitar 6y ago
    It is fine to use local mutable variables to implement an algorithm, however global objects modified all over a complex program can be risky - you might have bugs caused by getting into an "unexpected" state.
    • tsimionescu 6y ago
      And what does that have to do with everything being immutable by default? Either the language supports mutability as a first-class concept, or it doesn't. Sure, you shouldn't be using mutable global state, either in Go or in Haskell. The bad part about Go is that it's impossible to write type-safe immutable collections. Apart from that, I don't think it encourages mutable global state anymore than any other language with first-class mutation.
  • erik_seaberg 6y ago
    In a concurrent language, shared mutable state is the trap that Hoare's CSP book was urging us to avoid. Worse, in Go builtin maps are always writable yet parallel writes and reads can segfault. There's a sync.Map type but it isn't a drop-in replacement (because builtin maps don't implement any interfaces) and it isn't typesafe (because no generics).
    • tsimionescu 6y ago
      Yes, Go has very bad primitives whichever way you look at them. I still think you can't say a language with built-in immutability is more boring technology than one with built-in mutability. There's nothing stopping you from using Go's maps without mutation. You can go ahead and send copies of maps through channels, just like you would if they were really immutable. Sure, the interface is clunky, but so is every other interface in Go, so I don't see too much reason to complain here...