BEAM is amazing piece of technology, running backbone switches with 500-600 gigabits throughput per each in eighties with like 10-20 milliseconds of downtime per year. They actually originally written software for those switches in C++ (few years of hundreds of devs work) but it crashed with like few dozen simultaneous calls, so that project was a huge failure and then Joe Armstrong team of THREE devs written software in Erlang in few months and it was huge success. It was basically first production-level implementation of CSP actor model concurrency, way ahead of time
What about modern clouds when you never know which node is alive every time? Is any work was done for transparent clustering over lags and unpredictable topology?
In CS, few new great things are actually new. Us geeks have a biased towards not looking back (at least in my experience). We'd rather build something ourselves, without studying the history of that tech. It's our BANE
There are two problems: 1) Erlang syntax is ugly for imperative programmers: no loops, recursion, no handy Strings, strange operators,.. no OOP with objects & classes 2) The BEAM machine was made many years ago with HA clustering, but it is made for backplane ATCA blade servers, not for modern clouds when you never know which node is alive every time
Sweden genius did the magic, and did a poor job on marketing on Erlang/OTP. While Java did a top marketing job. José Valim, you make the old powerful magic shine again. Thank you!
Soft real-time updates to your page contents such as notifications, seeing other comments appear relatively quickly after they're posted, updating statistics or feeds without refreshing the page.
For presence channels you could do some sort of service discovery where each room/topic is a specific type of server (redis-master, redis-slave, postgres-slave, etc.)
think about it, what do you prefer: - the client always asking (ann then bothering) the server on what's new - or the server notifying the client when new data is ready to be consumed at least for me it's not about only chats, but any domain can have benefits of having channels/websocket/pub-sub architecture
I have worked on a project that uses channels to push updates to the client, so there is no need for polling of data. Combine it with something like React which re-renders the components that have changed efficiently, and you got yourself a pretty solid solution.
We built a whole farming application with a web and mobile frontends, and they are connected with Phoenix Channels. Farmers stay connected all day long on the mobile app reporting and tracking farming stuff. Most of them in the middle of nowhere, with bad connection and the Phoenix Channel just stays open and they can all see each other in realtime.
EVER SINGLE talk about Elixir I've found talks about the history of functional programming. I think it's a distraction. Elixir guys need to stop doing this.
12:55 - "Because it's sei la- I don't know"
brilliant
r/suddenlycaralho
Amo meu brasil
BEAM is amazing piece of technology, running backbone switches with 500-600 gigabits throughput per each in eighties with like 10-20 milliseconds of downtime per year. They actually originally written software for those switches in C++ (few years of hundreds of devs work) but it crashed with like few dozen simultaneous calls, so that project was a huge failure and then Joe Armstrong team of THREE devs written software in Erlang in few months and it was huge success. It was basically first production-level implementation of CSP actor model concurrency, way ahead of time
What about modern clouds when you never know which node is alive every time?
Is any work was done for transparent clustering over lags and unpredictable topology?
This seems like a powerful ancient magic that has just been rediscovered. Why isn't it widespread?
In CS, few new great things are actually new. Us geeks have a biased towards not looking back (at least in my experience). We'd rather build something ourselves, without studying the history of that tech. It's our BANE
There are two problems:
1) Erlang syntax is ugly for imperative programmers: no loops, recursion, no handy Strings, strange operators,.. no OOP with objects & classes
2) The BEAM machine was made many years ago with HA clustering, but it is made for backplane ATCA blade servers, not for modern clouds when you never know which node is alive every time
Because a lot of people is afraid of powerful ancient magic, obviously. ;)
Performance
Sweden genius did the magic, and did a poor job on marketing on Erlang/OTP. While Java did a top marketing job.
José Valim, you make the old powerful magic shine again. Thank you!
Documentation is really good. That is what missing for some great software's so new comers quit quickly.
Brilliant presentation! very, clear and passionate, thank you!
Love the guy in the audience opening a chip bag @36:35 haha
I'm sold!
I am in love with Elixir
37:20
I can just hear Bryan Cantrill screaming right now.
Sounds like he's touching on DDD/Bounded Contexts in the final question. Very interesting.
this was a great talk. good job!
And now they even have LiveView!
This is pretty exciting but I can never think of a use case for channels other than a chat application.
Soft real-time updates to your page contents such as notifications, seeing other comments appear relatively quickly after they're posted, updating statistics or feeds without refreshing the page.
For presence channels you could do some sort of service discovery where each room/topic is a specific type of server (redis-master, redis-slave, postgres-slave, etc.)
think about it, what do you prefer:
- the client always asking (ann then bothering) the server on what's new
- or the server notifying the client when new data is ready to be consumed
at least for me it's not about only chats, but any domain can have benefits of having channels/websocket/pub-sub architecture
I have worked on a project that uses channels to push updates to the client, so there is no need for polling of data. Combine it with something like React which re-renders the components that have changed efficiently, and you got yourself a pretty solid solution.
We built a whole farming application with a web and mobile frontends, and they are connected with Phoenix Channels. Farmers stay connected all day long on the mobile app reporting and tracking farming stuff. Most of them in the middle of nowhere, with bad connection and the Phoenix Channel just stays open and they can all see each other in realtime.
The loud coughing in the background is very irritating.
Especially these days ^^
Every time I hear a cough in this talk, I cringe...
so a supervisor it's some kind of exception catching system (but smarter)?
EVER SINGLE talk about Elixir I've found talks about the history of functional programming. I think it's a distraction. Elixir guys need to stop doing this.
bruh you know you can forward on TH-cam right?