I feel you got the let it crash idea slightly wrong. By "the programmer knows what to do", the author says that "if an exception occurs, it's because something is wrong _with the code_, which means that the developer is supposed to know how to fix it". That's why it's ok to let it crash if it's not supposed to happen in a non-buggy code: the developer is sure that if it crashes, it's a bug that can and should be fixed.
Yeah, I can maybe understand 😅 I spent a while preparing this talk and I feel like I made a lot of progress from where it started, but after I gave it I also got a number of insights from talking with different people at CodeBEAM. I’ve been thinking about writing a blog post or maybe giving the talk again with some of those insights in mind. But basically the point is: In Erlang there’s an expectation that you will be using processes/genservers/supervisors all of the time, but in Elixir that doesn’t happen so much, primarily because Elixir-ists generally work at a higher level and leave libraries to take advantage of the power of BEAM concepts and abstract away things which aren’t relevant to their applications (to be clear, I still thing Elixirists should *definitely* understand how processes/supervisors work, but they should also know that they probably won’t need them as often as they may be led to believe). It feels a bit like how, early in Elixir’s life, I read many blog posts talking about hot-code-reloading and how it made Elixir a game changer. But after a while the community came to a conclusion of “hot code reloading is useful if you *really* need it for specific cases, but most of the time it doesn’t fit with the most common ‘modern’ approach of deployments going out many times a day/week” The other main point is that, because of: * frequent deploys * eschewing of hot-code-reloading * the expectation that you’re going to have an external database …processes can’t be/aren’t used in Elixir for long-term state in the same way that it seems like they are in Erlang. Though after my talk at least one person suggested that Erlang applications rarely depend on process / memory state either, which was a bit of a surprise from the “story” that people tend to tell of Erlang (usually revolving around the original story of using Erlang for telephone switches) There was also some stuff in there exploring storing state (in GenServers, ETS, via PartitionSupervisor, etc…) that maybe muddies the point, TBH… 😅
I feel you got the let it crash idea slightly wrong. By "the programmer knows what to do", the author says that "if an exception occurs, it's because something is wrong _with the code_, which means that the developer is supposed to know how to fix it". That's why it's ok to let it crash if it's not supposed to happen in a non-buggy code: the developer is sure that if it crashes, it's a bug that can and should be fixed.
Hi. I did not get the point. :(
Yeah, I can maybe understand 😅 I spent a while preparing this talk and I feel like I made a lot of progress from where it started, but after I gave it I also got a number of insights from talking with different people at CodeBEAM. I’ve been thinking about writing a blog post or maybe giving the talk again with some of those insights in mind.
But basically the point is: In Erlang there’s an expectation that you will be using processes/genservers/supervisors all of the time, but in Elixir that doesn’t happen so much, primarily because Elixir-ists generally work at a higher level and leave libraries to take advantage of the power of BEAM concepts and abstract away things which aren’t relevant to their applications (to be clear, I still thing Elixirists should *definitely* understand how processes/supervisors work, but they should also know that they probably won’t need them as often as they may be led to believe).
It feels a bit like how, early in Elixir’s life, I read many blog posts talking about hot-code-reloading and how it made Elixir a game changer. But after a while the community came to a conclusion of “hot code reloading is useful if you *really* need it for specific cases, but most of the time it doesn’t fit with the most common ‘modern’ approach of deployments going out many times a day/week”
The other main point is that, because of:
* frequent deploys
* eschewing of hot-code-reloading
* the expectation that you’re going to have an external database
…processes can’t be/aren’t used in Elixir for long-term state in the same way that it seems like they are in Erlang. Though after my talk at least one person suggested that Erlang applications rarely depend on process / memory state either, which was a bit of a surprise from the “story” that people tend to tell of Erlang (usually revolving around the original story of using Erlang for telephone switches)
There was also some stuff in there exploring storing state (in GenServers, ETS, via PartitionSupervisor, etc…) that maybe muddies the point, TBH… 😅