Hacker News Reader

Comment by yingw787 | Hacker News Reader

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) if using your favored concurrency model results in race conditions?

View on HN

> How you can write simple, reliable, and efficient user code (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.

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.

99% of languages don't have race condition prevention and yet they're doing fine. Go has a pretty good race condition detector.

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.

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.

Those disallow data races, not race conditions. I find that this blog post explains the distinction well: https://blog.regehr.org/archives/490

Ah, yes. My bad... I missed that crucial detail. Still, maybe a non-TC protocol language could fulfill the criteria?

Reply on news.ycombinator.com