5 ms·

That isn't really the sort of thing Golang is trying to address, at least, not directly. Go is very unlikely to add immutable data structures at this point. And

That isn't really the sort of thing Golang is trying to address, at least, not directly. Go is very unlikely to add immutable data structures at this point. And Go is not built to prevent race conditions. There is a race detector that can detect many race conditions in running programs, but nothing in the type system.

yingw787 7y ago
IMHO type systems are pretty much impossible to change after the fact (see: Python's `str` type and the whole 2/3 migration fiasco), which is why I thought to bring it up since it's a major version change. I think a lack of support for efficient immutable types gets in the way of `golang` being a concurrency-first language, if the language endorses CSP with native support for goroutines and channels in the first place. How you can write simple, reliable, and efficient user code (https://golang.org https://golang.org) if using your favored concurrency model results in race conditions?
- apta 7y ago
  > How you can write simple, reliable, and efficient user code (https://golang.org https://golang.org) if using your favored concurrency model results in race conditions? You can't. And the language is not expressive enough to be able to write generic immutable data structures as you have in Scala/Java/Kotlin/etc.
- Thaxll 7y ago
  99% of languages don't have race condition prevention and yet they're doing fine. Go has a pretty good race condition detector.
  - zeeboo 7y ago
    Indeed, I believe it's impossible to statically prevent race conditions in a turing complete language. Data races can be prevented, but that's just a subset of all possible race conditions.
    - Quekid5 7y ago
      I think Erlang does? I don't really know Erlang, but AFAIK there's no way to share anything mutable between processes. Any data which is shared is (semantically) copied when it's sent to a different process. (Ignoring FFI, and such.) Same thing applies to the STM "subset" of Haskell -- conformance to which is statically verified by the type checker[1]. [1] There's no particular magic going on wrt. checking -- STM is a monad. It just happens to have "magic" runtime support.
      - zeeboo 7y ago
        Those disallow data races, not race conditions. I find that this blog post explains the distinction well: https://blog.regehr.org/archives/490 https://blog.regehr.org/archives/490
        Quekid5 7y ago
        Ah, yes. My bad... I missed that crucial detail. Still, maybe a non-TC protocol language could fulfill the criteria?
- tmerr 7y ago
  Dry answer: In practice, you try to not mutate values you receive unless you know you own them. Usually it's clear from the type signature. If ints are sent over the channel, or structs each containing an int and string, you know you can do whatever you want with them. If it's ambiguous, the sender should document whether the receiver has ownership. I think with 1 sender and 1 receiver the common solution in Rust is the same, to copy (or maybe move) the values sent... the type system provides some safety guarantees but I doubt it would be much different for performance. You wouldn't be able to send an immutable reference over a channel in Rust, since the compiler wouldn't know where the reference's lifetime ends. You could resort to refcounting, but you would probably only put in the effort if the data structure was large enough that copying was prohibitively expensive.

yingw787 7y ago

IMHO type systems are pretty much impossible to change after the fact (see: Python's `str` type and the whole 2/3 migration fiasco), which is why I thought to bring it up since it's a major version change. I think a lack of support for efficient immutable types gets in the way of `golang` being a concurrency-first language, if the language endorses CSP with native support for goroutines and channels in the first place. How you can write simple, reliable, and efficient user code (https://golang.org https://golang.org) if using your favored concurrency model results in race conditions?

apta 7y ago
> How you can write simple, reliable, and efficient user code (https://golang.org https://golang.org) if using your favored concurrency model results in race conditions? You can't. And the language is not expressive enough to be able to write generic immutable data structures as you have in Scala/Java/Kotlin/etc.
Thaxll 7y ago
99% of languages don't have race condition prevention and yet they're doing fine. Go has a pretty good race condition detector.
- zeeboo 7y ago
  Indeed, I believe it's impossible to statically prevent race conditions in a turing complete language. Data races can be prevented, but that's just a subset of all possible race conditions.
  - Quekid5 7y ago
    I think Erlang does? I don't really know Erlang, but AFAIK there's no way to share anything mutable between processes. Any data which is shared is (semantically) copied when it's sent to a different process. (Ignoring FFI, and such.) Same thing applies to the STM "subset" of Haskell -- conformance to which is statically verified by the type checker[1]. [1] There's no particular magic going on wrt. checking -- STM is a monad. It just happens to have "magic" runtime support.
    - zeeboo 7y ago
      Those disallow data races, not race conditions. I find that this blog post explains the distinction well: https://blog.regehr.org/archives/490 https://blog.regehr.org/archives/490
      - Quekid5 7y ago
        Ah, yes. My bad... I missed that crucial detail. Still, maybe a non-TC protocol language could fulfill the criteria?
tmerr 7y ago
Dry answer: In practice, you try to not mutate values you receive unless you know you own them. Usually it's clear from the type signature. If ints are sent over the channel, or structs each containing an int and string, you know you can do whatever you want with them. If it's ambiguous, the sender should document whether the receiver has ownership. I think with 1 sender and 1 receiver the common solution in Rust is the same, to copy (or maybe move) the values sent... the type system provides some safety guarantees but I doubt it would be much different for performance. You wouldn't be able to send an immutable reference over a channel in Rust, since the compiler wouldn't know where the reference's lifetime ends. You could resort to refcounting, but you would probably only put in the effort if the data structure was large enough that copying was prohibitively expensive.