
Let's #TalkConcurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt
About this video
A panel with Tony Hoare, Joe Armstrong and Carl Hewitt, hosted by Francesco Cesarini, on the history and future of concurrency. The three creators of CSP, Erlang and the actor model discuss their differing approaches.
Why it appears in the archive
HN recommends it for getting the inventors of major concurrency models together, disagreements included.
AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.
From the Hacker News discussion
Watch the guy who came up with Erlang, the Actor model and CSP discuss it: [VIDEO] One of my favorite videos on youtube.
Read original comment ↗[VIDEO] This recent panel (Armstrong, Hewitt and Hoare) discussion on concurrency was the first time I got to know about him and it gave me a lot of food for thought.
Read original comment ↗I was introduced to him pretty late in the game, in this interview where he and Joe Armstrong and Carl Hewitt talked concurrency! It was interesting hearing them discuss their different thoughts and approaches [VIDEO]
Read original comment ↗Threads + some kind of channel (a la Erlang processes or Go's goroutines) are pretty much direct programmatic representations of CSP. sorry if i misinterpreted, but i dont think that is correct that erlang processes exemplify channels/csp afaiu erlang is based on non-sequencial processes more like the actor model, there is no "communicating sequencial" process at the base of it (though you can implement csp in actor languages) afaik here you can see joe armstrong and carl hewitt fundamentally disagree with sir tony haore (csp) and sequential channels as a fundamental construct [1] [VIDEO] again, apologies if im arguing something that wasnt implied, it was just something i noticed ^^
Read original comment ↗Not quite. Erlang uses the Actor model which delivers messages asynchronously to named processes. In Go, messages are passed between goroutines via channels, which provide a synchronization mechanism (when un-buffered). The ability to synchronize allow one to setup a "rhythm" to computation that the Actor model is explicitly not designed to do. Also, note that a process must know its consumer in the Actor model, but goroutines do not need to know their consumer in the CSP model. Channels can even be passed around to other goroutines! Each have their own pros and cons. You can see some of the legends who invented different methods of concurrency here: [VIDEO] There's also a nice talk Rob Pike gave that illustrated some very useful concurrency patterns that can be built using the CSP model: [LINK]
Read original comment ↗