7 ms·

What makes elixir/erlang good fit for rpi? When compared to let's say rust or lua. Serious question, no offense.

sunkencity 9y ago
erlangs bit matching syntax, case statements for structs... incredibly elegant. I don't know about Rust or Lua, maybe they have this too.
- steveklabnik 9y ago
  Rust doesn’t have the bit matching syntax, but we do have match generally.
  - anuragsoni 9y ago
    It'd be interesting to explore something similar to the bitstring[1] library for Ocaml. Where should one start if exploring syntax extensions for Rust. I haven't looked into rust in a while now so i'm not sure how far one can get with macros these days. [1] https://github.com/xguerin/bitstring https://github.com/xguerin/bitstring
    - steveklabnik 9y ago
      “Macros 1.2” is what you want to look up; it’s in FCP right now!
- timgilbert 9y ago
  In particular, the elixir_ale library is a very pleasant interface to various bits of hardware you might want to interact with at the GPIO/i2c/etc level. https://github.com/fhunleth/elixir_ale https://github.com/fhunleth/elixir_ale
- zeckalpha 9y ago
  MetaLua does!
brightball 9y ago
IMO the BEAM run time is ideal for it. If I were writing code to drop onto a small device, I’d want the capability to efficiently have a lot of things run at the same time with a small processor, to know that a single heavy unit of work wouldn’t negatively affect the responsiveness of everything else and to know that all of those tiny pieces were built to basically never go down. Personally speaking, it would be difficult to imagine using anything else for that type of work.
- elcritch 9y ago
  The ability to utilize the BEAM's fully pre-emptive processes makes it great for programming hardware tasks and higher level tasks in the same environment. Compared to other languages like Lua, Node, Python, or even Go which all use various forms of cooperative multi-tasking or async-io. In these systems you have to be careful not to block other critical tasks. That's a pain but not the end of the world. However, for me the best feature is that I can remotely log into a running BEAM VM and interactively explore the live system [1]. Since Erlang has been used in "embedded" type systems for a long time there are a lot of useful libraries. For example a tiny bit of wrapper code let me setup a secure remote Elixir REPL using standard SSH keys for our embedded devices [2]. You can also run entire "applications" much as you would a system service, but which you can communicate with natively in Elixir/Erlang. Also the support for running sub-processes as ports is really nice. In general it's really more like a live operating system which you can program and investigate. The primary thing lacking is a capabilities system to allow running non-privileged code in a sand-boxed manner. 1: https://tkowal.wordpress.com/2016/04/23/observer-in-erlangelixir-release/ https://tkowal.wordpress.com/2016/04/23/observer-in-erlangel... 2: https://github.com/elcritch/iex_ssh_shell https://github.com/elcritch/iex_ssh_shell
sevensor 9y ago
Not an Erlang user, but I'm tickled by the idea of having a reliable cluster made out of unreliable little computers. Erlang has a great reputation for process supervision.
- elcritch 9y ago
  It would be fun to build a redundant hardware control system which used three cheap SBC’s to do a form of Triple modular redundancy [1]. It’d be straightforward to prototype with Nerves/Elixir! 1: https://en.m.wikipedia.org/wiki/Triple_modular_redundancy https://en.m.wikipedia.org/wiki/Triple_modular_redundancy
jbhatab 9y ago
There's a few reasons to use nerves, 1. It has a good system to hot load the code onto the pi and immediately start running your new code making deploys more efficient than other compiled languages. 2. Erlang uses processes which are very resilient and a good fit for projects that require constant streams of data & lots of connections which can be relevant in IOT. Basically the jobs restart themselves in a robust fashion. 3. Erlang runs on beam which is a well established VM that has years of development behind it making it a robust core for your project compared to some other operating systems that you may load onto your RPI. I don't think this is the biggest reason, but it is one. The hot reloading & concurrency model are my favorites & elixir is just fun to build in as well. I'm already using it for web so to bring it into IOT makes it natural for a web/IOT mixed project.
- dividuum 9y ago
  Since parent ask for a comparison with Lua and the Pi: I'm running a digital signage service (https://info-beamer.com/hosted https://info-beamer.com/hosted) that uses a custom minimal Linux (~35MB) on the Pi and a program written in C that is scriptable in Lua. One of the key features is hot reloading of code (and visual assets). Thanks to the flexibility and robustness of Lua that works incredibly well: You can even push new code to the central website using git, it instantly deploys it to connected devices and they reload their code. If done correctly you can update the content and logic your displays without any interruption. The C code is pretty robust for a few years now and never crashes or leaks memory.
  - necrodome 9y ago
    This is great. How is the business side of it?
    - dividuum 9y ago
      Looking good. Once customers realize that our platform is far more powerful that just throwing a browser at everything, they get really excited. You can fully automate everything with the API, build perfectly smooth 60fps content and even play synchronized content across any number of screens. And a lot more. Coupled with the low cost and the reliability of the Pi, it really looks great. Still, getting the word out is difficult as the Pi is still considered a toy by many.
equalunique 9y ago
The BEAM VM's preemptive multitasking may be a more efficient use of rpi's limited CPU in comparison to the cooperative multitasking of say NodeJS for example.
- jerf 9y ago
  Broadly speaking, Node is faster than BEAM: https://benchmarksgame-team.pages.debian.net/benchmarksgame/compare/hipe-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... Unless you're going pretty crazy with concurrency, BEAM isn't going to catch up to Node. BEAM is a beast when it's in its own runtime managing concurrency, but the bytecode interpreted language it implements is very "meh" when it comes to performance. (Since people seem to take these sorts of assessments personally, full disclosure and cards on the table: I massively prefer the BEAM world to the Node world. Nevertheless, the facts are what they are. The interpreter for BEAM is just not where you go for performance.)
  - querulous 9y ago
    sure, but you might not care so much for throughput in a situation where latency is critical
  - dnautics 9y ago
    These are mostly computational tasks... Why would you use BEAM for these?
    - singingboyo 9y ago
      Seriously. Elixir/Erlang are VERY clear about the VM (BEAM) not being particularly good at intensive computation. Use a port (or NIF if you really need to).
      - dnautics 9y ago
        don't do intensive computation in a NIF! You'll screw up the scheduler. Use a port.
jerf 9y ago
"What makes elixir/erlang good fit for rpi?" Honestly, I'd say it isn't a good fit for any particular reason. jbhatab isn't wrong, but there's other environments that will have other advantages over Elixir/Erlang/BEAM, depending on what you want to do. What is the case here is that the Raspberry Pi is basically a little computer and can run pretty much anything, Erlang included. Erlang was built in a world where a Raspberry Pi's specs would have been mindblowing, so it works just fine, just like anything else first built in the 1990s.

erlangs bit matching syntax, case statements for structs... incredibly elegant. I don't know about Rust or Lua, maybe they have this too.

steveklabnik 9y ago
Rust doesn’t have the bit matching syntax, but we do have match generally.
- anuragsoni 9y ago
  It'd be interesting to explore something similar to the bitstring[1] library for Ocaml. Where should one start if exploring syntax extensions for Rust. I haven't looked into rust in a while now so i'm not sure how far one can get with macros these days. [1] https://github.com/xguerin/bitstring https://github.com/xguerin/bitstring
  - steveklabnik 9y ago
    “Macros 1.2” is what you want to look up; it’s in FCP right now!
timgilbert 9y ago
In particular, the elixir_ale library is a very pleasant interface to various bits of hardware you might want to interact with at the GPIO/i2c/etc level. https://github.com/fhunleth/elixir_ale https://github.com/fhunleth/elixir_ale
zeckalpha 9y ago
MetaLua does!

brightball 9y ago

IMO the BEAM run time is ideal for it. If I were writing code to drop onto a small device, I’d want the capability to efficiently have a lot of things run at the same time with a small processor, to know that a single heavy unit of work wouldn’t negatively affect the responsiveness of everything else and to know that all of those tiny pieces were built to basically never go down. Personally speaking, it would be difficult to imagine using anything else for that type of work.

elcritch 9y ago
The ability to utilize the BEAM's fully pre-emptive processes makes it great for programming hardware tasks and higher level tasks in the same environment. Compared to other languages like Lua, Node, Python, or even Go which all use various forms of cooperative multi-tasking or async-io. In these systems you have to be careful not to block other critical tasks. That's a pain but not the end of the world. However, for me the best feature is that I can remotely log into a running BEAM VM and interactively explore the live system [1]. Since Erlang has been used in "embedded" type systems for a long time there are a lot of useful libraries. For example a tiny bit of wrapper code let me setup a secure remote Elixir REPL using standard SSH keys for our embedded devices [2]. You can also run entire "applications" much as you would a system service, but which you can communicate with natively in Elixir/Erlang. Also the support for running sub-processes as ports is really nice. In general it's really more like a live operating system which you can program and investigate. The primary thing lacking is a capabilities system to allow running non-privileged code in a sand-boxed manner. 1: https://tkowal.wordpress.com/2016/04/23/observer-in-erlangelixir-release/ https://tkowal.wordpress.com/2016/04/23/observer-in-erlangel... 2: https://github.com/elcritch/iex_ssh_shell https://github.com/elcritch/iex_ssh_shell

sevensor 9y ago

Not an Erlang user, but I'm tickled by the idea of having a reliable cluster made out of unreliable little computers. Erlang has a great reputation for process supervision.

elcritch 9y ago
It would be fun to build a redundant hardware control system which used three cheap SBC’s to do a form of Triple modular redundancy [1]. It’d be straightforward to prototype with Nerves/Elixir! 1: https://en.m.wikipedia.org/wiki/Triple_modular_redundancy https://en.m.wikipedia.org/wiki/Triple_modular_redundancy

jbhatab 9y ago

There's a few reasons to use nerves, 1. It has a good system to hot load the code onto the pi and immediately start running your new code making deploys more efficient than other compiled languages. 2. Erlang uses processes which are very resilient and a good fit for projects that require constant streams of data & lots of connections which can be relevant in IOT. Basically the jobs restart themselves in a robust fashion. 3. Erlang runs on beam which is a well established VM that has years of development behind it making it a robust core for your project compared to some other operating systems that you may load onto your RPI. I don't think this is the biggest reason, but it is one. The hot reloading & concurrency model are my favorites & elixir is just fun to build in as well. I'm already using it for web so to bring it into IOT makes it natural for a web/IOT mixed project.

dividuum 9y ago
Since parent ask for a comparison with Lua and the Pi: I'm running a digital signage service (https://info-beamer.com/hosted https://info-beamer.com/hosted) that uses a custom minimal Linux (~35MB) on the Pi and a program written in C that is scriptable in Lua. One of the key features is hot reloading of code (and visual assets). Thanks to the flexibility and robustness of Lua that works incredibly well: You can even push new code to the central website using git, it instantly deploys it to connected devices and they reload their code. If done correctly you can update the content and logic your displays without any interruption. The C code is pretty robust for a few years now and never crashes or leaks memory.
- necrodome 9y ago
  This is great. How is the business side of it?
  - dividuum 9y ago
    Looking good. Once customers realize that our platform is far more powerful that just throwing a browser at everything, they get really excited. You can fully automate everything with the API, build perfectly smooth 60fps content and even play synchronized content across any number of screens. And a lot more. Coupled with the low cost and the reliability of the Pi, it really looks great. Still, getting the word out is difficult as the Pi is still considered a toy by many.

equalunique 9y ago

The BEAM VM's preemptive multitasking may be a more efficient use of rpi's limited CPU in comparison to the cooperative multitasking of say NodeJS for example.

jerf 9y ago
Broadly speaking, Node is faster than BEAM: https://benchmarksgame-team.pages.debian.net/benchmarksgame/compare/hipe-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... Unless you're going pretty crazy with concurrency, BEAM isn't going to catch up to Node. BEAM is a beast when it's in its own runtime managing concurrency, but the bytecode interpreted language it implements is very "meh" when it comes to performance. (Since people seem to take these sorts of assessments personally, full disclosure and cards on the table: I massively prefer the BEAM world to the Node world. Nevertheless, the facts are what they are. The interpreter for BEAM is just not where you go for performance.)
- querulous 9y ago
  sure, but you might not care so much for throughput in a situation where latency is critical
- dnautics 9y ago
  These are mostly computational tasks... Why would you use BEAM for these?
  - singingboyo 9y ago
    Seriously. Elixir/Erlang are VERY clear about the VM (BEAM) not being particularly good at intensive computation. Use a port (or NIF if you really need to).
    - dnautics 9y ago
      don't do intensive computation in a NIF! You'll screw up the scheduler. Use a port.

jerf 9y ago

"What makes elixir/erlang good fit for rpi?" Honestly, I'd say it isn't a good fit for any particular reason. jbhatab isn't wrong, but there's other environments that will have other advantages over Elixir/Erlang/BEAM, depending on what you want to do. What is the case here is that the Raspberry Pi is basically a little computer and can run pretty much anything, Erlang included. Erlang was built in a world where a Raspberry Pi's specs would have been mindblowing, so it works just fine, just like anything else first built in the 1990s.