4 ms·

Right tool for the right job, I think. I’ve had absolutely wonderful experiences with Elixir doing web apps (both LoB style and SaaS style). Probably the best o

Right tool for the right job, I think. I’ve had absolutely wonderful experiences with Elixir doing web apps (both LoB style and SaaS style). Probably the best one, and it’s such a canonical example, is a group chat app using Websockets. It just feels so good, and with libcluster, multiple nodes in K8s can autodiscover and join each other. No problems at all having chats where the members are connected to websockets on different nodes; everything mostly Just Works. On the flip side, I prototyped out a drone flight controller in Elixir thinking that the “fail and restart” portion would be awesome for reliability (if the RTK receiver craps out and restarts, no big deal, the EKF can just fall back to using the IMU until the RTK is back online). That part of it all worked great, but doing real-time numerical computing in Elixir is painful. As was generating the signals for the ESCs. I was making C modules to try to talk to the ESCs, and errors in those modules had the ability to corrupt the BEAM. I started looking at ports too (where the C code runs as a separate process), but gave up when it felt like everything was feeling way too complex and fragile. Let it crash is great, but “it crashes all the time” is not. I could have probably gotten it working, but... not a great domain for it.

tomc1985 6y ago
That seems odd given that the BEAM was designed for reliable real-time telephone switching
- tonyarkles 6y ago
  You're not wrong! I actually tried doing a bunch of research to figure out how the original Ericsson phone switches worked with Erlang, but couldn't find a whole lot of info.
  - imhoguy 6y ago
    At least we have this "Erlang: The Movie" demo to reverse engineer some bits: https://m.youtube.com/watch?v=BXmOlCy0oBM https://m.youtube.com/watch?v=BXmOlCy0oBM
    - tonyarkles 6y ago
      That's awesome! Thanks!
  - dnautics 6y ago
    IIRC a good way to put is that the phone switches didn't work with erlang, but the phone switch controllers did.
- jacquesm 6y ago
  Soft real-time != hard real-time. Erlang is great at soft real-time but does not work at all for hard real-time, there simply are no guarantees, just very good average latency. If you want hard real time (such as for in-flight control of a drone) then you should look elsewhere.
adamfeldman 6y ago
Just curious -- were you using Nerves[0] for the drone flight controller? [0]: https://github.com/nerves-project/nerves https://github.com/nerves-project/nerves
- tonyarkles 6y ago
  That was the eventual plan! I was prototyping stuff out on a BeagleBone Black with vanilla Elixir, and if the prototype felt promising I was going to bake it into a Nerves image. This was quite a while ago too; Nerves may have some bits baked into it now that might have helped.
brudgers 6y ago
let it crash != robustness not required Let it crash is an engineering design for systems large enough that statistically unlikely failures occur regularly. Like a data center or the original use case, telephone switch centers. Even if let it crash worked, it seems philosophically inappropriate for a drone controller.
- lostcolony 6y ago
  Yeah; the basic philosophy of 'let it crash' presumes that the issue is bad internal state, and you need to get back into a known good state. If your domain doesn't really have a way to get back to a known good state, or a way to determine a state is good and persist it, it's not going to help you.
  - deleted 6y ago
    [deleted]
- marcosdumay 6y ago
  I see no incompatibility with a drone controller if you have enough redundancy or can restart services fast enough for it to not be a problem (probably 1 second is still ok). What is completely incompatible with disposable workers is complex numeric processing. Unless you can segment it with small non-communicating unities, of course. That's the kind of application that asks for a low level language.
- TickleSteve 6y ago
  Not at all, "let it crash" is simply a way of phrasing "consider reset in your flow of control". In embedded systems, certainly safety-critical ones, you have to consider the possibility of a reset path at all points in your flow of control. Your code resetting is a valid flow of control. This is absolutely necessary to get a properly robust system. Your drone system needs to be able to handle a reset at any point and still maintain adequate control of the aircraft. This is "Let it crash". "Let it crash" is essentially the same thing. Take account of the necessity of reset, because you can't stop it happening.

tomc1985 6y ago

That seems odd given that the BEAM was designed for reliable real-time telephone switching

tonyarkles 6y ago
You're not wrong! I actually tried doing a bunch of research to figure out how the original Ericsson phone switches worked with Erlang, but couldn't find a whole lot of info.
- imhoguy 6y ago
  At least we have this "Erlang: The Movie" demo to reverse engineer some bits: https://m.youtube.com/watch?v=BXmOlCy0oBM https://m.youtube.com/watch?v=BXmOlCy0oBM
  - tonyarkles 6y ago
    That's awesome! Thanks!
- dnautics 6y ago
  IIRC a good way to put is that the phone switches didn't work with erlang, but the phone switch controllers did.
jacquesm 6y ago
Soft real-time != hard real-time. Erlang is great at soft real-time but does not work at all for hard real-time, there simply are no guarantees, just very good average latency. If you want hard real time (such as for in-flight control of a drone) then you should look elsewhere.

adamfeldman 6y ago

Just curious -- were you using Nerves[0] for the drone flight controller? [0]: https://github.com/nerves-project/nerves https://github.com/nerves-project/nerves

tonyarkles 6y ago
That was the eventual plan! I was prototyping stuff out on a BeagleBone Black with vanilla Elixir, and if the prototype felt promising I was going to bake it into a Nerves image. This was quite a while ago too; Nerves may have some bits baked into it now that might have helped.

brudgers 6y ago

let it crash != robustness not required Let it crash is an engineering design for systems large enough that statistically unlikely failures occur regularly. Like a data center or the original use case, telephone switch centers. Even if let it crash worked, it seems philosophically inappropriate for a drone controller.

lostcolony 6y ago
Yeah; the basic philosophy of 'let it crash' presumes that the issue is bad internal state, and you need to get back into a known good state. If your domain doesn't really have a way to get back to a known good state, or a way to determine a state is good and persist it, it's not going to help you.
- deleted 6y ago
  [deleted]
marcosdumay 6y ago
I see no incompatibility with a drone controller if you have enough redundancy or can restart services fast enough for it to not be a problem (probably 1 second is still ok). What is completely incompatible with disposable workers is complex numeric processing. Unless you can segment it with small non-communicating unities, of course. That's the kind of application that asks for a low level language.
TickleSteve 6y ago
Not at all, "let it crash" is simply a way of phrasing "consider reset in your flow of control". In embedded systems, certainly safety-critical ones, you have to consider the possibility of a reset path at all points in your flow of control. Your code resetting is a valid flow of control. This is absolutely necessary to get a properly robust system. Your drone system needs to be able to handle a reset at any point and still maintain adequate control of the aircraft. This is "Let it crash". "Let it crash" is essentially the same thing. Take account of the necessity of reset, because you can't stop it happening.