Hacker News Reader

Comment by tapirl | Hacker News Reader

What are the differences between raw CSP primitives and ull-fledged actor model?

In an Actor model, you can explicitly send messages to actors (send), monitor their state (executing, failed, completed), and take actions against them (kill, spawn).

A fallout from this is that you can have one actor supervise another, to protect your program from errors: https://hexdocs.pm/elixir/Supervisor.html

The Golang runtime provides only these actions: (spawn). It’s up to the author to create communication channels, and it’s impossible to query for the status of a Goroutine. This means you have no explicit control over goroutines, so you can’t kill misbehaving ones like you could in another language.

I feel raw channels provide more possibilities than Actor model. In fact, you can build such an Actor model by warpping CSP channels. It is not too hard.

Yes, I think this is precisely the idea.

Anecdotally, 99% of the complaints I read WRT Go can be solved by using libraries that already exist. If one wants a batteries-included-in-the-stdlib form of facility, one should look at languages like Python.

Yes, one principle of Go design is try to use as few syntaxes/concepts as possible to support as many use cases/features as possible.

Actor model cannot be implemented wrapping CSP, because CSP is bounded and synchronous, while Actor model is unbounded and asynchronous. But you can implement CSP on top of Actor model.

In Go I can write to a channel that nothing will ever read, and I can attempt to read from a channel to which nothing will ever write.

In a pure actor model raw channels wouldn't be directly available and I would be required to push to and read from a concrete goroutine.

Reply on news.ycombinator.com