mempkoon Lobsters • Recommends
Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt
0:00 / 0:00
Let's #TalkConcurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt
Erlang Solutions
18K subscribers • 48 videos on Hallway
- Recommended by 4 people: 3 on Hacker News and 1 on Lobsters.
- A classic. People kept recommending it from 2019 to 2026.
- Presented by Sir Tony Hoare, Joe Armstrong, and Carl Hewitt
- An opinion. It argues one side of a question engineers disagree on.
Intermediate. Assumes working knowledge.
13K views7 years ago4 recommendations
Computer scienceHistory and cultureConcurrency and parallelismHistory of computingPeople who shaped computing
Tony Hoare, Joe Armstrong, and Carl Hewitt discuss the history, design, and future of CSP, Erlang, and the actor model.
Let's #TalkConcurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt with host Francesco Cesarini. When considering the panel to discuss concurrency, you’d be pushed to find a higher calibre than Sir Tony Hoare, Joe Armstrong, and Carl Hewitt. All greats within the industry and beyond, they give an amazing insight into the lifeline of concurrency and actor models over the past few decades, their bountiful experiences within the concurrency field, and where they see concurrency heading in the future. Full transcript: erlang-solutions.com/blog/let-s-talkconcurrency-panel-discus…Why it's here
4 people recommend thisWhat people say. Highly recommended as a historic discussion between the legendary creators of major concurrency paradigms.
Moments people linked to
coolKid721on Hacker News • Recommends
On “Erlang's not about lightweight processes and message passing (2023)”
Watch the guy who came up with Erlang, the Actor model and CSP discuss it: link to this video One of my favorite videos on youtube.
apoorvgargon Hacker News • Recommends
On “Joe Armstrong has died”
link to this 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.
lokelowon Hacker News • Recommends
On “Turing Award winner and former Oxford professor Tony Hoare passed away”
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 link to this video
u/raiphin r/ProgrammingLanguages • Mentions
On “Most sensible abstraction & feature set for a systems language?”
> For computers modeled on the von neumann arch or a "classical computer" (basically, 99% of the stuff we use), what is the "best" way to abstract it in a way that gives you the most optimum balance of performance, ergonomics, productivity, etc.?
A computing resource.
That might sound inadequate or unhelpful. So let's expand that to a computing resource that:
* Can take data in, alter its state, and push data out. (This is still very abstract, but is a useful abstraction that I'm confident will not be controversial unless I'm crazy or someone else is.)
* May be one of many that are connected such that data pushed out can become data taken in by the same or another computer. (This notion…
andrekandreon Hacker News • Mentions
On “Red and blue functions are a good thing”
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 link to this video again, apologies if im arguing something that wasnt implied, it was just something i noticed ^^
pbohunon Hacker News • Mentions
On “A million ways to die from a data race in Go”
…del 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: link to this 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…
u/raiphin r/ProgrammingLanguages • Mentions
On “Looking for Language Formal Specifications to Study”
I think your explicit questions are about how (I think) some of the rivers I conjure can, perhaps, provide a solid formal mathematical foundation applicable to *open* systems (including PL languages and their implementations), things that are *evolving*, things that can, aiui, have some mathematically describable *identity* and *consistency*.
But rather than confront that head on, let me instead focus on what I currently find the most understandable such river to me, namely the Hewitt River, and on the mathematical foundations he has developed, and hear your reaction to that.
(First, because that is at least just a question of relatively simple mathematics presented by an established compu…
u/raiphin r/ProgrammingLanguages • Mentions
On “Languages that don't support Error-Catching as a Control Structure?”
Aiui:
* In life, shit happens. ("Yeah, you're 5, but suck it up kid.") The same applies to code. So you need to be able to tolerate shit happening to code. As Joe says, in the general case you need to be able to tolerate a computer process crashing (whether due to bad software, fatal cpu or memory failure, power outage, arbiter#Asynchronous_arbiters_and_metastability) randomness, whatever; again, shit happens). So he developed a solution to deal with processes arbitrarily going "rogue" (eg infinitely looping, dropping off a network, whatever). And made that solution *"bullet proof"*, fast, and ergonomic. And once you have that, you can just let a process crash and all will be OK. Nothing…
u/raiphin r/ProgrammingLanguages • Mentions
On “Resources on concurrent PL semantics?”
Some folk have some serious cred in concurrency due to thinking carefully about it, and this kid in particular really *should* know what he's talking about, so I'll start with him:
> **This is the crucial argument** ...
>
> If you're writing programs that interact with the real world, you've got to construct a model of the real world inside the computer. As is done just universally in design of real-time systems.
>
> And the real world has things called objects. And the objects do things; fit in a certain place (more or less; they can move around); but the movement of objects; the existence of objects; the sequentiality of the actions performed by the same object; these are features of th…
u/lepinekin r/ProgrammingLanguages • Mentions
On “What would make you try a new language?”
I'm curious by nature so I like to try any new serious programming language and I had hoped to find the ideal one for decades actually but not anymore since to implement the language of the future it would require like a project to go on the moon see Let's #TalkConcurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt [video ;)
So instead I have turned into my own meta-programming language to accelerate trying or using any existing or new programming language or framework. This means I will really be able to try many new programming languages or frameworks because before that It would take me too much time and effort.
u/raiphin r/ProgrammingLanguages • Mentions
On “Everything is an Object....”
>I do at least understand the supposed advantage of many OOP features like encapsulation
Do you?
A minor concern I have is that you name only one "advantage" (it's a singular noun). But I imagine that might be a type or otherwise unimportant details. Let's see.
The much, *much*, **MUCH** more qualifier is "supposed".
That latter qualification suggests you either don't accept the laws of physics that mandate state being held by an object, and that state being encapsulated, in order for a language to support all forms of concurrency, or are thinking of some other advantage. (There are many distinct advantages claimed for encapsulation; perhaps you are aware of those but not the one that ma…