Hacker News Reader

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.

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?

> 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?

The purpose of channels is to provide synchronisation and messaging between goroutines, not to prevent race conditions on shared data.

Go also provides mutexes that are more suited for that.

Sure, passing a pointer through a channel does not in itself provide any protection to the data it references but such protection is not always required. There's a separation of concerns that allows more flexibility.

> such protection is not always required

Safety should be the default, with a way to opt out for people who have thought really hard about the consequences. If I have to opt into the safe version, I need tooling to complain about everywhere I didn't do so.

A pointer is neither safe nor unsafe and in my view people should be expected to know what they are doing when passing pointers across concurrent threads of execution.

It's not rocket science.

Goroutines are supposed to be lightweight so it makes sense to allow lightweight communication.

On the other hand how often have you read in documentation “Do not mutate this buffer” or the equivalent? It is very possible to create traps for people who pick up your code later on. Having the compiler detect those problems rather then it causing a runtime error is something highly desirable.

> This means that once we send a pointer on a channel, it's game over

Yes, as long as you keep sharing the references. So just don't reference that stuff you sent across a channel. Usually there is little reason to use pointers in Go anyway [1] except when building methods to mutate the associated type (think: struct).

That said, it's fairly easy to build cascaded structures that are automatically deep-copied during assignment by not using pointers. So that's a pretty safe way to go, moreover one should keep in mind that Go doesn't try to be functional in any way, so immutable data is not such a thing there.

[1] https://medium.com/@vCabbage/go-are-pointers-a-performance-o...

Until you blow out the stack.