I'm starting to love this language more each day. On the other hand, my teacher handed us an assignment to make an industrial elevator lift (without doors or human safety checks) simulation through Erlang. It is quite easy to wrap your head around this problem: The elevator requires a motor, the motor can only go at one speed in two directions and can only sense when it reaches the top or bottom. The elevator also requires a single sensor for each floor. Basically, each sensor is its own process, and talks to a supervisor which then talks to the motor. The elevator also requires a button cabinet. Imagine that each button when pressed, sens a signal, to the elevator master supervisor. Then, the master supervisor can light on or off the button. There is also a display because why not. The motor is easy to implement with a finite-state machine, and the master sensor will have to distribute its slave sensors. Can you see now? With what you learned from this video it is quite simple to get a grasp on how the process tree looks like. Erlang is so fun!
@@ruhtam8971 Since this lab work was handed to my teacher, it is now the university intellectual property and I cannot post the solution. I will have to ask my teacher if I'm allowed to share the code. He will most likely say no to my question because it was the last project for this course and other students might plagiarize my own work. I hope you understand my situation.
@@ruhtam8971 You should start with "P1" if you are a newbie to Erlang. The difficulty increases quite a lot afterwards, specially with the other lab works. I hope you have a great day sir!
Absolutely love Erlang and all of the material Joe Armstrong has online. Anybody interested in computer science in general should watch Joe's online talks. RIP Joe, you are a hero to me and countless others.
We had to use this language in university to write algorithms and datastructures. At first I was like wtf, but then after a while I really started to dig it. The ability to write implicit if-cases just with function headers makes it very elegant imo.
Fun fact. You can in theory just use case- and if-statements for flow control without even touching pattern matching in the function headers, but the code very quickly becomes unwieldy because of the static variables; (recursive) loops done like this are quite hilarious. It's a fun exercise to see how far you can push the language by limiting some of its features.
Douglas Adams: Click, click, hum. Click, hum, click, hum, click, hum. Click, click, click, click, click, hum. Hmmm. A low level supervising program woke up a slightly higher level supervising program deep in the ship's semi-somnolent cyberbrain and reported to it that whenever it went click all it got was a hum. The higher level supervising program asked it what it was supposed to get, and the low level supervising program said that it couldn't remember exactly, but thought it was probably more of a sort of distant satisfied sigh, wasn't it? It didn't know what this hum was. Click, hum, click, hum. That was all it was getting. The higher level supervising program considered this and didn't like it. It asked the low level supervising program what exactly it was supervising and the low level supervising program said it couldn't remember that either, just that it was something that was meant to go click, sigh every ten years or so, which usually happened without fail. It had tried to consult its error look-up table but couldn't find it, which was why it had alerted the higher level supervising program to the problem. The higher level supervising program went to consult one of its own look-up tables to find out what the low level supervising program was meant to be supervising. It couldn't find the look-up table. Odd.
You are encouraged to check for _expected_ errors. Unexpected errors are to be handled non-locally, though design of your supervision tree. The reality of Erlang programming is that you spend more time than average thinking about error and failure, but it obscures your business logic less, and your code is more reliable.
@@IIARROWS if you think he was being an asshole you probably don't understand what he is saying. The language design encourages you to think about the system behaviour for your error conditions while also reducing the amount of code you write for handling those errors.
Erlang OTP has the concept of supervisor that monitor and restart its process if one is crashed. Over catching errors usually makes life very hard to locate the real line of bug code is.
At its core Erlang is very simple language. The problem is that this language requires a little bit different approach to thinking, and this is the "hard part".
By the way, it's funny that Elixir/Erlang are considered functional languages (which they indeed are), but by implementing the actor model with message passing, they actually adhere more closely to the original OOP concept as Alan Kay intended it than many 'modern' OOP languages like Java.
@@user-uf4lf2bp8t I wrote it wrong - it absolutely IS functional language, but from a higher perspective, the actor model also almost perfectly aligns with the original intent of OOP design.
@@user-uf4lf2bp8t Quora: What does Alan Kay think about Joe Armstrong claiming that "Erlang might be the only object-oriented language" and also his thesis supervisor’s claim that “Erlang is extremely object oriented”? Alan Kay: I love Joe Armstrong - we lost a great man when he recently left us. And, he might be right. Erlang is much closer to the original ideas I had about “objects” and how to use them. However, another way to look at this is to consider “What Is Actually Needed” (WIAN) and realize that much more is needed beyond what we are programming in today. Joe would most definitely be more in favor of this idea than worrying about what either one of us did decades ago.
@@jsonkody people love talking about "the original version of OO " but that really doesn't matter. Smalltalk is the language that started that model of programming, but it didn't stay using the actor model for very long, and mostly went over to method based "messages" by smalltalk 72. So your smartass "original OO" that was started by smalltalk very quickly shifted to method based OO like we see in Java.
Yes, we did a computation server, that was able to move around for updates etc. We did that in Uppsala university around 1995 (some thing, don't remember). It had computation server management in Erlang and solving the problem with Prolog. :-)
Can we please have another video with source code for a simple working program, and see it in action? I'm really impressed and intrigued by Erlang and want to know more.
Declarative programing Let the code fail (No guard clauss) Runs on virtual machine Seperate process for every task Fault tolerance Scalability Can run in a cluster of machines and pass messages
I was blown away by the brilliance of Erlang when I heard Joe Armstrongs presentations about it. Before that, Casey Muratoris criticism of OOP made me overreact a bit: I became very sceptical of systems that advocated abstractions and focused on “maintainability”, because, very often, “maintainability” just meant arbitrary idea of simplicity and willing blindness towards the actual complexity of the system. But Erlang ACTUALLY addresses those issues by doing something radically different. And the approach of it shows perfectly what is wrong with OOP. If you are writing a program that will be one process and one binary, you are fundamentally unable to handle errors and achieve structures like erlang is. So why are we hellbend on writing “provably safe” and “modular” code based on “frameworks” - when none of those are true for anyone else than the single developer? The overall binary is not provably safe, nor is the source code as a whole is. Erlang as a system can be. The application is not modular, as long as it runs as a single process. Erlang is naturally capable of distributed computation. And the “framework” is just code in your binary you most likely didn’t bother reading (and which might be amount too big to physically read by single human, in a month). That’s not a true framework, because that’s not a true structure. Erlang, being distributed on multiple physical machines, multiple VMs and multiple processes is a true framework. In comparison, the “frameworks” modern developers use is just copy-pasting code we might or might not have read, composed of copy-pasted code we most definitely did not read. Now that consumer processors no longer see as rapid growth in processing power - as while definitely very possible, such devices would be impractical to cool down in consumer devices, I really hope there is some big shift in culture of software and OS development.
I'd like to see a comparison of the concurrency in Erlang (in more details) with Haskell's model, where Haskell's threads spawned with forkIO are also described similarly as "lightweight" (...but the communication between them in Haskell is done through the MVar data type and/or STM's TVar type). STM (Software Transactional Memory) in Haskell would probably be a great video on its own. Maybe another one for Graham Hutton? :)
They are similar in many ways but one key way in which they are different is the garbage collection. Haskell's GC time cost is linear with the amount of memory used by all threads and can have large pauses for global GC. Erlang's GC is performed on a per-thread basis and as a result there is never any global pause. Erlang programs tend to have a much better 99th percentile latency than those written in Haskell, Java, etc.
Another key point is that pervasive use of timeouts and assertions means that deadlocks are much rarer and are something that can be recovered from, while in Haskell it would cause the whole program to crash. Erlang has much better runtime error handling properties, though less ability to prevent runtime errors than Haskell due to lack of a static type system.
I`m C++ and Erlang dev, Erlang supports actor model which is imo safest and easiest to maintain and scale up solution in design of concurrent systems, unfortunately it is not fast enough so there is a need to implement actor model in C++, and what was elegant and clean in Erlang becomes nightmare in C++.
It's recommended for most to write using Elixir which is a child of Erlang. Elixir, which uses the rock solid Erlang VM, has much nicer syntax, great libraries and an awesome community.
@@JSDudeca Elixir is not a "child Erlang". Using that phrase suggests that it's somehow less powerful or is a watered down version. To most people who are familiar with more modern languages, the Elixir syntax and tooling will seem much more familiar, but rest assured it is in no way a "child Erlang". It has everything you would get with Erlang, plus some extras.
@@peterr6205 - Your point is well taken. In re-reading my comment it was definitely a typo. I had meant that "Elixir is a child of Erlang". Elixir is an awesome language and I look forward to using it in future projects. I cannot see myself ever writing Erlang as Elixir has it all.
@@JSDudeca In what way is Elixir "recommended" over Erlang? It's the same thing with different syntax. Elixir doesn't do anything that Erlang can't. It's based on preference and neither one is "recommended" over the other. I'll pick Erlang any day of the week to avoid half of my lines consisting of the keyword bloat that is "do" and "end" but completely understand why people who have done Ruby might want to pick Elixir instead.
@@Gwaerondor If working on small personal projects, it's really up to the person but in big teams However with Elixir it is a much easier language to get new team members, train up new talent, find support on issues etc. This is why I recommend Elixir to N00b's.
I've been programming in hardware description languages like VHDL and Verilog for many many years now, and it sounds like Erlang is very similar in architecture.
This is very interesting compared to Elm. Unlike Erlang, in Elm you have to handle every possible error case explicitly. I think I still prefer Elm, but this is still really interesting!
Elm is more akin to Haskell, in the way that it uses a strong type system, whereas Erlang has dynamic typing. Some people are working on a strongly type language that runs on the Erlang VM (Gleam) but it is still a work in progress so far.
@@AndersJackson that might have been referring to dialyser, you should get a look at it. It is a bit bothersome to set up and get working properly apparently though.
Objective C is primarily a message-passing paradigm, and BeOS had it baked into the OS level. I think it started with Smalltalk. The idea of sharing memory by communicating rather than communicating by sharing memory is fundamental to Go (channels), as is very rapidly spawning lightweight processes (goroutines).
Objects started with Simula, Object orientation started with Smalltalk. Compared to Smalltalk, C++, Java, C# etc are not object oriented languages. Smalltalk and Object orientation are about sending messages between objects, not calling methods. (That it is implemented as methods are another thing).
This process isolation looks very similar to what chrome and firefox browsers are doing from some time. They also spawn multiple instances and then communicate via messages. Also when one card crashes it will not hang whole browser. Supervisor process will simply terminate crashed process.
Message passing, share-nothing design, and supervisors sound kinda cool, but what am I missing here? It would be lovely to get into the tradeoffs of Erlang's design (which, as with everything else in engineering, has a cost).
It might be more difficult to find Erlang developers than JavaScript developers. They might cost more. Some people find Erlang's syntax ugly and/or unreadable. Luckily, there is Elixir.
It needs some accustoming to be able to properly work with OTP (the supervisor thing in the video). Also as @Paula said, there are not that much developers, so it can be problem for some companies as well.
I'm not sure I understand your question. BEAM is the runtime/VM that is used to run erlang(not directly, but after it's compiled to bytecode). Within the Erlang community, BEAM is the only major VM that is used, while there might be other implementations, I've never heard of anyone running anything except BEAM. So it would follow that anyone who is a fan/user of Erlang (or any other BEAM language, like Elixir), is a fan of the BEAM.
@@MarieAmeliaFreyaAster BEAM is not a separate project. BEAM is the reference implementation of Erlang. In a way, it IS Erlang. While you could argue Erlang is the syntax and rules of the language, in reality, Erlang is the compiler.VM that compiles and runs Erlang source code, and that currently is the BEAM.
@@MarieAmeliaFreyaAster I'm actually curious about what you'd like to know. My goal it not to be argumentative about your comment or request for info. For example, Java runs on the JVM, but there are also many other runtimes that people use, so understanding the differences, both technologically and politically (google vs oracle, etc.) makes a lot of sense, but with Erlang there's only one runtime, so therefore Erlang and the BEAM can be thought of as one thing. So anything you would learn about Erlang, would be applicable to BEAM. I'm curious what info you're looking for, or what facts you'd like about BEAM. I'm really not trying to be argumentative. I'd like to give you more info if I can. I've been working with Erlang and Elixir (both major BEAM languages) for over 3 years.
Some of it reminds me of objects in other languages - they don't share memory, communicate by sending messages, supervisor objects decide what to do in a crash scenario, ... Would definitely be interesting to learn more about it!
Alan Kay (creator of the term Object Oriented Programming) once said that there are only 2 languages that implemented OOP as what he meant - Smalltalk and Erlang.
Yes, he is talking about an OS thread managing multiple calls, and when it crashes because of a problem processing one of the calls, the whole thread terminates, and all other calls it manages go down with it. As opposed to a BEAM “process” managing just one call crashing without affecting any other BEAM “processes” and the calls they manage.
It fascinates me everytime that old programming languages often seem more thoughtful constructed than lets say modern ones like javascript, even if they often had narrow usecases.
Well Javascript is probably one of the worst languages ever created so yeah, not very representative of modern languages. There are way better ones out there. ;)
@@dexter9313 *cough cough* MUMPS *cough cough* the worst programming language I was ever required to work with. . Javascript is brilliant in comparison.
@@addmoreice Well that's why I said "one of the worst", because I'm sure there are some hidden gems here and there. ;) Should have said "worst popular language" maybe.
Its an important distinction that any concurrency must use message passing. This is excellent for information processing and servers but debilitating for something like operating system drivers.
Wow, it seems that Kotlin was inspired a lot by Erlang!! Especially when you consider how coroutines work and how the Kotlin Native concurrency model works. It is really, really similar to Erlang. The concept of processes (coroutines) and supervising (Jobs and Supervisor scope) and scoped error handling (Jobs) is almost the same in both languages.
How is fallibility of network messaging handled though? Does it mean that sending a message to another process in the same supervisor tree is just as scary-looking as another node?
I don’t really want to know how the vm’s interact with each other in reality i mean it must happen through packets but what it sends and how it does the routing decision is really the part that maybe makes it so scalable.
You can have similar pattern (thread with a dedicated queue) in any paradigm. And OOP isn't just C++ or Java. Unfortunately I don't know anything about Erlang, so I can't comment about it's simplicity.
@@AleksyGrabovski it is designed by Ericsson, the telecom company, to write software for their telehone switches. Which means that it has to handle fault tolerance of LOTS of nines (never be non responsive because of software) and massive concurrent, as it has to handle thousands of events without waiting. There are nothing an library in an OOP programming language would do for you. An ordinary language with support for threads would die because it run out of memory long before Erlang has started 100 times the number of threads. And the built in support for catching errors/failure in other threads are built into the runtime system. Yes, Ericsson tried to write some telephone switch software in C++, but never got near the uptime of Erlang based software, and the responsiveness of the software. Yes, upgrade of software is built into the system. You can runt different versions of the software in different threads. And to change version, you can just crash the processes in a controlled manner, so that to controlling threads in Erlang/OTP can restart these threads when needed.
jaff Same. The thing that struck me the most was how little relevance control structures have in functional programming. The only thing your are going to use is case and cond, but even this is rare and you just pattern match most of the time. With any other language I end up with a mess of for loops, if, else and while statements.
@@FeelsDonkMan The similarity to Ruby is fairly superficial. It does have some similaritys (do ... end blocks etc), but if you tried to use it in a Ruby style manner, I think you might end up making a big mess. Its not a procedural or OOP language.
When you do calculation, you store the new result in a new variable. And because you do all loops in recursion, you do get a new set of variables each call. :-) And actually, non mutable variables the default in ML languages likeHaskell and OCaml. Nothing strange there at all, actually.
It doesn't solve the bug all the time, sometimes it does, like when you restart the computer and it works again. But the thing is, not every scenario causes the bug. It just let other part keeps running.
The animation for pattern matching and recursion is major milestone in computer science education
... I mean ive seen animations similar to it in my undergrad several years ago already
@@patternwhisperer4048 My man I never did, I had to visual myself, I was lucky that I had it easy
@@patternwhisperer4048 I saw it as an embryo in 1971
Epic !
Haven't done erlang but just recently learned elixir. Elixir is erlangs child basically. It's awesome, if you haven't tried it yet try it now.
So when Elixir crashes then Erlang gets a notification? =P
It's a BEAM language. There's a lot of them, but I think Elixir is probably going to be the one to push this paradigm forward.
@@Nehpets94 like ruby
I was already tempted...
RabbitMQ is written in Erlang. Elixir is very cool.
I met this man at ElixirConfLA 2019, I've gotta say he is a genius in terms of Erlang.
did i ask?
I'm starting to love this language more each day.
On the other hand, my teacher handed us an assignment to make an industrial elevator lift (without doors or human safety checks) simulation through Erlang.
It is quite easy to wrap your head around this problem:
The elevator requires a motor, the motor can only go at one speed in two directions and can only sense when it reaches the top or bottom.
The elevator also requires a single sensor for each floor. Basically, each sensor is its own process, and talks to a supervisor which then talks to the motor.
The elevator also requires a button cabinet. Imagine that each button when pressed, sens a signal, to the elevator master supervisor. Then, the master supervisor can light on or off the button. There is also a display because why not.
The motor is easy to implement with a finite-state machine, and the master sensor will have to distribute its slave sensors.
Can you see now? With what you learned from this video it is quite simple to get a grasp on how the process tree looks like. Erlang is so fun!
Nice
Please share the solution in github and link it here if you can spare some time. I want to learn this too
@@ruhtam8971 Since this lab work was handed to my teacher, it is now the university intellectual property and I cannot post the solution. I will have to ask my teacher if I'm allowed to share the code. He will most likely say no to my question because it was the last project for this course and other students might plagiarize my own work. I hope you understand my situation.
@@StickySli okay then I'll attempt a solution on my own taking inspiration from your explanations. Thank you
@@ruhtam8971 You should start with "P1" if you are a newbie to Erlang. The difficulty increases quite a lot afterwards, specially with the other lab works. I hope you have a great day sir!
Absolutely love Erlang and all of the material Joe Armstrong has online. Anybody interested in computer science in general should watch Joe's online talks.
RIP Joe, you are a hero to me and countless others.
Ericsson really made impressive progress all over Telecom, from mechanical switch modules through Erlang to Bluetooth.
We had to use this language in university to write algorithms and datastructures. At first I was like wtf, but then after a while I really started to dig it.
The ability to write implicit if-cases just with function headers makes it very elegant imo.
Fun fact. You can in theory just use case- and if-statements for flow control without even touching pattern matching in the function headers, but the code very quickly becomes unwieldy because of the static variables; (recursive) loops done like this are quite hilarious. It's a fun exercise to see how far you can push the language by limiting some of its features.
First Erlang was written in Prolog, so that was the part that came from Prolog.
This was brilliant! I had always wondered what made Erlang so special!
Yes, it's indeed very special and it's a shame that it does not have the attention it deserves. Now with Elixir it slowly changing.
Douglas Adams:
Click, click, hum.
Click, hum, click, hum, click, hum.
Click, click, click, click, click, hum.
Hmmm.
A low level supervising program woke up a slightly higher level supervising program deep in the ship's semi-somnolent cyberbrain and reported to it that whenever it went click all it got was a hum.
The higher level supervising program asked it what it was supposed to get, and the low level supervising program said that it couldn't remember exactly, but thought it was probably more of a sort of distant satisfied sigh, wasn't it? It didn't know what this hum was. Click, hum, click, hum. That was all it was getting.
The higher level supervising program considered this and didn't like it. It asked the low level supervising program what exactly it was supervising and the low level supervising program said it couldn't remember that either, just that it was something that was meant to go click, sigh every ten years or so, which usually happened without fail. It had tried to consult its error look-up table but couldn't find it, which was why it had alerted the higher level supervising program to the problem.
The higher level supervising program went to consult one of its own look-up tables to find out what the low level supervising program was meant to be supervising.
It couldn't find the look-up table.
Odd.
So it's encouraged to skip error checking?
_I was born for this_
You are encouraged to check for _expected_ errors. Unexpected errors are to be handled non-locally, though design of your supervision tree. The reality of Erlang programming is that you spend more time than average thinking about error and failure, but it obscures your business logic less, and your code is more reliable.
If you are a bad programmer, you can do that on every programming language.
Don't be an asshole.
@@lpil I feel this is something that needs to be made more explicit to beginers. It took me a while to figure out what 'let it crash' actually meant.
@@IIARROWS if you think he was being an asshole you probably don't understand what he is saying. The language design encourages you to think about the system behaviour for your error conditions while also reducing the amount of code you write for handling those errors.
Erlang OTP has the concept of supervisor that monitor and restart its process if one is crashed. Over catching errors usually makes life very hard to locate the real line of bug code is.
I worked on a system written in C# with 120 threads (don't ask!) and Erlang would have been brilliant for that. Great video.
I've been learning Erlang over the last two weeks and I love it. It's so weird, but so damned fast to code in.
This is surprisingly easy to wrap one's head around. Rad.
At its core Erlang is very simple language. The problem is that this language requires a little bit different approach to thinking, and this is the "hard part".
By the way, it's funny that Elixir/Erlang are considered functional languages (which they indeed are), but by implementing the actor model with message passing, they actually adhere more closely to the original OOP concept as Alan Kay intended it than many 'modern' OOP languages like Java.
I don't think those 2 concepts of "message passing" are quite the same
@@user-uf4lf2bp8t I wrote it wrong - it absolutely IS functional language, but from a higher perspective, the actor model also almost perfectly aligns with the original intent of OOP design.
@@user-uf4lf2bp8t Quora: What does Alan Kay think about Joe Armstrong claiming that "Erlang might be the only object-oriented language" and also his thesis supervisor’s claim that “Erlang is extremely object oriented”?
Alan Kay: I love Joe Armstrong - we lost a great man when he recently left us.
And, he might be right. Erlang is much closer to the original ideas I had about “objects” and how to use them.
However, another way to look at this is to consider “What Is Actually Needed” (WIAN) and realize that much more is needed beyond what we are programming in today.
Joe would most definitely be more in favor of this idea than worrying about what either one of us did decades ago.
@@jsonkody people love talking about "the original version of OO " but that really doesn't matter. Smalltalk is the language that started that model of programming, but it didn't stay using the actor model for very long, and mostly went over to method based "messages" by smalltalk 72. So your smartass "original OO" that was started by smalltalk very quickly shifted to method based OO like we see in Java.
It's all coming back to me now! Flashbacks ftw!
Yeah! I wrote a chat server/client in Erlang during my university days. I love Erlang.
@@danceswithdirt7197 I did that too! Well, maybe not for a chatbot, but I did something with it. I prefer Haskell, personally though.
Yes, we did a computation server, that was able to move around for updates etc. We did that in Uppsala university around 1995 (some thing, don't remember). It had computation server management in Erlang and solving the problem with Prolog. :-)
Can we please have another video with source code for a simple working program, and see it in action? I'm really impressed and intrigued by Erlang and want to know more.
caw25sha I’d suggest looking into Elixir
More Erlang and some Elixir
A video about Elixir, then?
Look up on UA-cam: Erlang The Movie
Search for this presentation on UA-cam.
GOTO 2019 • The Soul of Erlang and Elixir • Saša Jurić
Erlang got my curiosity because it reminds of a city called Erlangen, but after watching this video - Erlang has my attention.
I have a question. What are we doing? Why have I learned object oriented programming? This is awesome. This is next level
So what does his shirt say at the bottom?!
let it crash
Camera man is an intern
Wash at 40C
He slightly reminds me of Jose Mourinho
@@LucienHughes jose mourinho minus the ego
Awesome intro to erlang, I'm very motivated to learn more, thank you!
Declarative programing
Let the code fail (No guard clauss)
Runs on virtual machine
Seperate process for every task
Fault tolerance
Scalability
Can run in a cluster of machines and pass messages
What an elegant design for error handling
erlang! one of my favourites :D
good to see it get some attention
Erlang sounds pretty interesting, thanks for this explanation
please ask this man to create a full course
Every word of his was golden. I enjoyed listening to him. Thanks!
I was blown away by the brilliance of Erlang when I heard Joe Armstrongs presentations about it.
Before that, Casey Muratoris criticism of OOP made me overreact a bit: I became very sceptical of systems that advocated abstractions and focused on “maintainability”, because, very often, “maintainability” just meant arbitrary idea of simplicity and willing blindness towards the actual complexity of the system.
But Erlang ACTUALLY addresses those issues by doing something radically different. And the approach of it shows perfectly what is wrong with OOP.
If you are writing a program that will be one process and one binary, you are fundamentally unable to handle errors and achieve structures like erlang is. So why are we hellbend on writing “provably safe” and “modular” code based on “frameworks” - when none of those are true for anyone else than the single developer?
The overall binary is not provably safe, nor is the source code as a whole is. Erlang as a system can be.
The application is not modular, as long as it runs as a single process. Erlang is naturally capable of distributed computation.
And the “framework” is just code in your binary you most likely didn’t bother reading (and which might be amount too big to physically read by single human, in a month). That’s not a true framework, because that’s not a true structure. Erlang, being distributed on multiple physical machines, multiple VMs and multiple processes is a true framework.
In comparison, the “frameworks” modern developers use is just copy-pasting code we might or might not have read, composed of copy-pasted code we most definitely did not read.
Now that consumer processors no longer see as rapid growth in processing power - as while definitely very possible, such devices would be impractical to cool down in consumer devices, I really hope there is some big shift in culture of software and OS development.
Joe Armstrong was legend, rest in peace
Riste Kostadinov the death cause of Joe is so strange, someone could never got infected such disease and passed away that quick
You are hitting bang on with the last few videos, really interesting.
I'd like to see a comparison of the concurrency in Erlang (in more details) with Haskell's model, where Haskell's threads spawned with forkIO are also described similarly as "lightweight" (...but the communication between them in Haskell is done through the MVar data type and/or STM's TVar type). STM (Software Transactional Memory) in Haskell would probably be a great video on its own. Maybe another one for Graham Hutton? :)
They are similar in many ways but one key way in which they are different is the garbage collection. Haskell's GC time cost is linear with the amount of memory used by all threads and can have large pauses for global GC. Erlang's GC is performed on a per-thread basis and as a result there is never any global pause. Erlang programs tend to have a much better 99th percentile latency than those written in Haskell, Java, etc.
Another key point is that pervasive use of timeouts and assertions means that deadlocks are much rarer and are something that can be recovered from, while in Haskell it would cause the whole program to crash. Erlang has much better runtime error handling properties, though less ability to prevent runtime errors than Haskell due to lack of a static type system.
I`m C++ and Erlang dev, Erlang supports actor model which is imo safest and easiest to maintain and scale up solution in design of concurrent systems, unfortunately it is not fast enough so there is a need to implement actor model in C++, and what was elegant and clean in Erlang becomes nightmare in C++.
This is the best lecture on apoptosis on youtube.
Beautiful language in my opinion.
This guy makes programming sound cool.
This is really amazing. I want to write code in Erlang now.
It's recommended for most to write using Elixir which is a child of Erlang. Elixir, which uses the rock solid Erlang VM, has much nicer syntax, great libraries and an awesome community.
@@JSDudeca Elixir is not a "child Erlang". Using that phrase suggests that it's somehow less powerful or is a watered down version. To most people who are familiar with more modern languages, the Elixir syntax and tooling will seem much more familiar, but rest assured it is in no way a "child Erlang". It has everything you would get with Erlang, plus some extras.
@@peterr6205 - Your point is well taken. In re-reading my comment it was definitely a typo. I had meant that "Elixir is a child of Erlang". Elixir is an awesome language and I look forward to using it in future projects. I cannot see myself ever writing Erlang as Elixir has it all.
@@JSDudeca In what way is Elixir "recommended" over Erlang? It's the same thing with different syntax. Elixir doesn't do anything that Erlang can't. It's based on preference and neither one is "recommended" over the other. I'll pick Erlang any day of the week to avoid half of my lines consisting of the keyword bloat that is "do" and "end" but completely understand why people who have done Ruby might want to pick Elixir instead.
@@Gwaerondor If working on small personal projects, it's really up to the person but in big teams
However with Elixir it is a much easier language to get new team members, train up new talent, find support on issues etc. This is why I recommend Elixir to N00b's.
The BEAM vm is really powerful, thank you Erlang!
A language created for todays web.
I've been programming in hardware description languages like VHDL and Verilog for many many years now, and it sounds like Erlang is very similar in architecture.
Maybe because it's functional, so you explain what the result should be rather than the steps to achieve it?
This is very interesting compared to Elm. Unlike Erlang, in Elm you have to handle every possible error case explicitly. I think I still prefer Elm, but this is still really interesting!
Elm is more akin to Haskell, in the way that it uses a strong type system, whereas Erlang has dynamic typing. Some people are working on a strongly type language that runs on the Erlang VM (Gleam) but it is still a work in progress so far.
@@florianthelliez7739 there was also work that did type system checks on the Erlang program when compiling. I never heard how it worked out though.
@@AndersJackson that might have been referring to dialyser, you should get a look at it. It is a bit bothersome to set up and get working properly apparently though.
4:03 Great animation showing how do we execute a function that uses pattern matching
Objective C is primarily a message-passing paradigm, and BeOS had it baked into the OS level. I think it started with Smalltalk. The idea of sharing memory by communicating rather than communicating by sharing memory is fundamental to Go (channels), as is very rapidly spawning lightweight processes (goroutines).
Go has shared memory and channels are more like passing a baton than asynchronous communication between concurrent processes, no?
Objects started with Simula, Object orientation started with Smalltalk. Compared to Smalltalk, C++, Java, C# etc are not object oriented languages.
Smalltalk and Object orientation are about sending messages between objects, not calling methods. (That it is implemented as methods are another thing).
This process isolation looks very similar to what chrome and firefox browsers are doing from some time. They also spawn multiple instances and then communicate via messages. Also when one card crashes it will not hang whole browser. Supervisor process will simply terminate crashed process.
yeah! but browsers do it for security primairly
I'm getting a flash-back! Long live the AXE!
Message passing, share-nothing design, and supervisors sound kinda cool, but what am I missing here? It would be lovely to get into the tradeoffs of Erlang's design (which, as with everything else in engineering, has a cost).
It might be more difficult to find Erlang developers than JavaScript developers. They might cost more. Some people find Erlang's syntax ugly and/or unreadable. Luckily, there is Elixir.
It needs some accustoming to be able to properly work with OTP (the supervisor thing in the video). Also as @Paula said, there are not that much developers, so it can be problem for some companies as well.
Team Erlang \o/
What's your take on BEAM though
I'm not sure I understand your question. BEAM is the runtime/VM that is used to run erlang(not directly, but after it's compiled to bytecode). Within the Erlang community, BEAM is the only major VM that is used, while there might be other implementations, I've never heard of anyone running anything except BEAM. So it would follow that anyone who is a fan/user of Erlang (or any other BEAM language, like Elixir), is a fan of the BEAM.
@@peterr6205 BEAM is its own project though, I'd just like to hear their thoughts about it
@@MarieAmeliaFreyaAster BEAM is not a separate project. BEAM is the reference implementation of Erlang. In a way, it IS Erlang. While you could argue Erlang is the syntax and rules of the language, in reality, Erlang is the compiler.VM that compiles and runs Erlang source code, and that currently is the BEAM.
@@peterr6205 I give up
@@MarieAmeliaFreyaAster I'm actually curious about what you'd like to know. My goal it not to be argumentative about your comment or request for info. For example, Java runs on the JVM, but there are also many other runtimes that people use, so understanding the differences, both technologically and politically (google vs oracle, etc.) makes a lot of sense, but with Erlang there's only one runtime, so therefore Erlang and the BEAM can be thought of as one thing. So anything you would learn about Erlang, would be applicable to BEAM. I'm curious what info you're looking for, or what facts you'd like about BEAM. I'm really not trying to be argumentative. I'd like to give you more info if I can. I've been working with Erlang and Elixir (both major BEAM languages) for over 3 years.
Some of it reminds me of objects in other languages - they don't share memory, communicate by sending messages, supervisor objects decide what to do in a crash scenario, ...
Would definitely be interesting to learn more about it!
In fact some people have said that Erlang is closer to the true idea of OOP than the usual OOP languages (C++, Java…). ;)
Alan Kay (creator of the term Object Oriented Programming) once said that there are only 2 languages that implemented OOP as what he meant - Smalltalk and Erlang.
This was an amazing talk. Thanks - mind opener on different programming paradigm
Like having a plate of food with none of the servings touching each other. That sounds nice to me.
Maybe reference the original Erlang movie which demonstrates process failure and live module replacement quite well
Yey my current favorite language, did not expect to find it here!
That factorial program is so simple but so cool too
Indeed. Factorial programs are the “hello, world!” programs for functional programming languages.
An impressive explanation.
Is the "tread" he is mentioning @ 10:34, the OS thread?
Yes, he is talking about an OS thread managing multiple calls, and when it crashes because of a problem processing one of the calls, the whole thread terminates, and all other calls it manages go down with it. As opposed to a BEAM “process” managing just one call crashing without affecting any other BEAM “processes” and the calls they manage.
A Like and subscription because of the telephone in the background on the desk.
It fascinates me everytime that old programming languages often seem more thoughtful constructed than lets say modern ones like javascript, even if they often had narrow usecases.
Well Javascript is probably one of the worst languages ever created so yeah, not very representative of modern languages. There are way better ones out there. ;)
@@dexter9313 *cough cough* MUMPS *cough cough* the worst programming language I was ever required to work with. . Javascript is brilliant in comparison.
@@addmoreice Well that's why I said "one of the worst", because I'm sure there are some hidden gems here and there. ;) Should have said "worst popular language" maybe.
@@addmoreice Bringing up Mumps is kind of cheating. it was always considered a dog ugly language with incomprehensible semantics.
Yeah, I wouldn't call Javascript a language as much as it is scripted, bastardised C++.
You should create some Erlang tutorials ❤️
He has written at least one book about Erlang.
Designing for Scalability with Erlang/OTP,
Francesco Cesarini and Steve Vinoski
The last lair of the onion : an electromagnet that flips the switch and swings back to re-flip it before getting turned on again
Its an important distinction that any concurrency must use message passing. This is excellent for information processing and servers but debilitating for something like operating system drivers.
So drivers must not be concurrent.
@@davidwuhrer6704 They have to be by definition unless you want your operating system to be like DOS.
@@Furiends Then they must use some form of message passing.
@@Furiends you can have the drivers to be non-concurrent, and let the OS handle the concurrency.
And yes, most drivers are not concurrent.
Why is there no subtitles on this video ?
It is sad.
I'm kinda annoyed too
This is currently a very new video and it sometimes takes a while for the subtitles to be generated. Try again tomorrow.
@@caw25sha ah makes sense. Will do
Subtitles in Erlang plz
I'm lucky enough to use Erlang and Elixir. Awesome!
Good stuff , use elixir at my work and this is a great breakdown of Erlang
This guy has a way with words
Excellent explanation! Thank you!
OMG can we like this video twice?!
♥️ Erlang. RIP Joe Armstrong.
Hey, this guy was at NIIT conference:)
Can you recommend a good book that breaks down this theory?
Erlangers rise up!
*One guy somewhere in the back:* YEAH!!
YEAH!!!
Wow, it seems that Kotlin was inspired a lot by Erlang!! Especially when you consider how coroutines work and how the Kotlin Native concurrency model works. It is really, really similar to Erlang.
The concept of processes (coroutines) and supervising (Jobs and Supervisor scope) and scoped error handling (Jobs) is almost the same in both languages.
Huh, interesting. Sounds like I should take another dive into kotlin. IIRC, coroutines were not a thing last time i checked some time ago.
A small detail ... Should really be ... erlang/OTP. Nice videoo.
They are used interchangeably, but Erlang/OTP is not somehow more correct than just saying Erlang.
Erlang is a computer language developed in Sweden by the Swedish telephone company Ericsson.
Great explanation thank you.
Why isn't there a common xmpp for all the world communication?
How is fallibility of network messaging handled though?
Does it mean that sending a message to another process in the same supervisor tree is just as scary-looking as another node?
I love Erlang.
Btw, in the factorial example you could also use a pattern that matches one and you wouldn't have needed a when clause.
But would that catch calling factorial() with a negative number?
@@PaulaJBean Hmm, no
Should I start learning Erlang or Elixir?
Could you guys think about doing a video on the Actor Model?
Hello Joe!
Hello Mike!
I love Francesco Cesarini
Cool video! Thanks for sharing
I don’t really want to know how the vm’s interact with each other in reality i mean it must happen through packets but what it sends and how it does the routing decision is really the part that maybe makes it so scalable.
Sorry...what?
ERLANG is awesome, it is ugly duck in technology, i believe ERLANG is one of most beautiful system in computer world.
Those Erlang processes are very similar to an active object pattern in OOP.
OOP is a disaster. Erlang is a clean and simple problem solving tool in comparison.
You can have similar pattern (thread with a dedicated queue) in any paradigm. And OOP isn't just C++ or Java.
Unfortunately I don't know anything about Erlang, so I can't comment about it's simplicity.
@@AleksyGrabovski it is designed by Ericsson, the telecom company, to write software for their telehone switches. Which means that it has to handle fault tolerance of LOTS of nines (never be non responsive because of software) and massive concurrent, as it has to handle thousands of events without waiting.
There are nothing an library in an OOP programming language would do for you. An ordinary language with support for threads would die because it run out of memory long before Erlang has started 100 times the number of threads. And the built in support for catching errors/failure in other threads are built into the runtime system.
Yes, Ericsson tried to write some telephone switch software in C++, but never got near the uptime of Erlang based software, and the responsiveness of the software.
Yes, upgrade of software is built into the system. You can runt different versions of the software in different threads. And to change version, you can just crash the processes in a controlled manner, so that to controlling threads in Erlang/OTP can restart these threads when needed.
if erlang's syntax isn't your jam, elixir is actually really nice.
jaff Elixir is the nicest language I have come across in the last 15 years.
@@tjpld i wish i learned elixir far sooner than i did so i could've spent more time learning the right lessons.
jaff Same. The thing that struck me the most was how little relevance control structures have in functional programming. The only thing your are going to use is case and cond, but even this is rare and you just pattern match most of the time. With any other language I end up with a mess of for loops, if, else and while statements.
Very similar to Ruby for obvious reasons. Something I really want to learn as well.
@@FeelsDonkMan The similarity to Ruby is fairly superficial. It does have some similaritys (do ... end blocks etc), but if you tried to use it in a Ruby style manner, I think you might end up making a big mess. Its not a procedural or OOP language.
Any coverage on Brady's channels on the other Erlang? (Agner Krarup Erlang)
Just FYI, this Erlang (the language) was actually named after the "other" Erlang :) That whole Erlang = "Ericsson language" theory is plain wrong.
The captions are obsessed with Fred.
in Scheme you can just do factorial like this:
(define (factorial x) (apply * (iota x 1)))
RIP Joe Armstrong
un curso en español por favor! 🙏
So, actor model?
So if variables can't be modified and there is no shared memory, how would you program something like a counter?
recursion
When you do calculation, you store the new result in a new variable. And because you do all loops in recursion, you do get a new set of variables each call. :-)
And actually, non mutable variables the default in ML languages likeHaskell and OCaml. Nothing strange there at all, actually.
Well, I don't get everything what he said. Any recommendations to read something about Erlang?
I think "Seven Languages in Seven Weeks" has a chapter on it. "Seven More Languages..." has a chapter on Elixir.
Hi could you recommend a book to learn this language?
Designing for Scalability with Erlang/OTP,
Francesco Cesarini and Steve Vinoski
Erlang and OTP in Action,
Martin Logan
Eric Merritt
Richard Carlsson
Is the virtual machine scalable?
Yes.
Sounds pretty cool
Thank you very much.
I love how he says "very little memory, a few K" LOL when I was his age we would have said "very little memory a byte or two" LOL
Erlang looks cool!
12:05 lol. Restart is the neverending solution to most problems.
It doesn't solve the bug all the time, sometimes it does, like when you restart the computer and it works again. But the thing is, not every scenario causes the bug. It just let other part keeps running.