SeanTAllenon Lobsters • Recommends
The wide world of almost-actors: comparing Pony to BEAM languages
0:00 / 0:00
Scott Lystig Fritchie - The wide world of almost-actors: comparing the Pony to BEAM languages
Code Sync
15K subscribers • 57 videos on Hallway
- Recommended by 2 people: 1 on Lobsters and 1 in engineering communities.
- A classic. People kept recommending it from 2019 to 2024.
- Presented by Scott Lystig Fritchie
Advanced. Deep dive for people who know the field.
6K views7 years ago2 recommendations
Programming languagesDistributed systemsConcurrency and parallelismElixir and ErlangLanguage design and type systems
Scott Lystig Fritchie compares the actor model implementation in Pony with BEAM languages like Erlang and Elixir.
This video was recorded at Code BEAM STO 19 bit.ly/2W2vgDC Get involved in Code Sync's next conference bit.ly/2Mcm4aS --- THE WIDE WORLD OF ALMOST-ACTORS: COMPARING THE PONY LANGUAGE TO BEAM LANGUAGES by Scott Lystig Fritchie THIS TALK IN THREE WORDS: Actors BEAM Pony TALK LEVEL: Advanced ABSTRACT As Erlang & Elixir programmers, the Actor Model of computation sits comfortably in our minds. Processes that communicate only by message passing makes building concurrent applications easy. It feels natural. We take it for granted. The inventor of the Actor Model, Dr. Carl Hewitt, says that Erlang does not implement the Actor Model. Erlang co-creators Joe Armstrong and Robert Virding agree with Hewitt. Let's explore Actor Model wrongs & rights with BEAM languages compared to Pony (ponylang.io). Read the full abstract: codesync.global/speaker/scott-lystig-fritchie56/ --- THE SPEAKER - SCOTT LYSTIG FRITCHIE Stuck in distributed systems tarpits for 30 years Scott Lystig Fritchie was a UNIX systems administrator until he returned to programming full-time at Sendmail, Inc. While at Sendmail in 2000, a colleague introduced him to Erlang. His world hasn't been the same since. In addition to writing Erlang and occasionally C for the Erlang virtual machine, he has had papers published by USENIX, the Erlang User Conference, and the ACM and has given presentations at Erlang Factory, Code BEAM, and Ricon. Scott works at Wallaroo Labs on a polyglot distributed system of Pony, Python, and C. More on Scott Lystig Fritchie: codesync.global/speaker/scott-lystig-fritchie56/ --- CODE SYNC & CODE BEAM STO 19 Code BEAM STO is powered by Code Sync. Code BEAM STO 19 was sponsored by Klarna, The RealReal, Erlang Solutions, dek technologies, Derivco Sports, and aeternity. CODE SYNC Website: www.codesync.global Twitter: www.twitter.com/CodeBEAMIO Facebook: facebook.com/CodeSyncGlobal LinkedIn: linkedin.com/company/code-sync/ Mail: info at codesync.global #Actors #PonyLang #BEAMWhy it's here
2 people recommend thisWhat people say. Recommended for understanding the differences between Erlang's concurrency model and the formal Actor Model.
u/oscarryzin r/ProgrammingLanguages • Recommends
On “State of the art for parallelism & concurrency?”
OP Just be aware to not equate Erlang with the actor model. They were designed at around the same time and have similar ideas, but Erlang came up with its own thing.
See:
* https://softwareengineering.stackexchange.com/a/277469/82
* https://erlang.org/pipermail/erlang-questions/2014-June/079792.html
* [video
u/vanderZwanin r/ProgrammingLanguages • Mentions
On “Atmos - a programming language and Lua library for structured event-driven concurrency”
> So still `multi-threaded` is the hard thing.
As it always is.
> The more I think about this, we need a way to model a `OS` so we can have it all
Interestingly, matklad said something similar in an interview that was published yesterday:
> Also kernel space! The user space is the easy part. A historical issue defining our computer landscape is that modern kernels try really hard to provide the illusion of a blocking API. You write a file, which takes time then you continue when it’s done. This is smoke and mirrors, this isn’t how hardware works at all! It’s always fire and forget: Write this, here’s a region of memory, wake me up when it’s over. It’s fundamentally asynchronous.
>
> The…