5 ms·

> He did sell Elixir to me in 10 minutes indeed, for which I am extremely grateful. Could you elaborate on this more? Elixir’s an interesting beast. On one ha

> He did sell Elixir to me in 10 minutes indeed, for which I am extremely grateful. Could you elaborate on this more? Elixir’s an interesting beast. On one hand, it’s just Erlang by another name. And yet Elixir also brings some merits of its own. How much of Jose’s pitch was for Elixir-the-alter-Erlang? And how much was for something other than Erlang?

pdimitar 4y ago
Well I have no experience in Erlang -- only checked it out a few times and I like that Elixir removes some of the more manual aspects of Erlang (like manually exporting functions from a module). So, why Elixir (and partially why Erlang): - (Erlang + Elixir) Transparent parallelism. This is not a joke. You're a function + closure away from multiplexing stuff on all your CPU cores (or even more e.g. it's OK to have a limit of a worker pool be 100+ for e.g. network workers). - (Elixir-specific) A lot of tools around fault tolerance and supervision trees. You can have static hierarchies and you can have dynamic ones (spawn children, have them do work, have them shut down). You can register green threads by name and enforce limits on how many of them are around, you can also load-balance work between several nodes. - (Elixir-specific) Macros: you can generate code at compile-time which is extremely useful if you want to limit the set of values that you'd work with at run-time. Example: the Unicode functionality of Elixir is actually generated by macros that basically do a `for` loop of all codepoints / graphemes and utilizes pattern-matching on each value. Super tedious by hand, extremely trivial with macros / code-generation. Useful in many other scenarios as well e.g. you can inject code in a receiver module with macros. - (Erlang + Elixir) Pattern matching. While the languages sadly have no static strong typing, pattern-matching helps a ton e.g. interacting with remote APIs you can match on several expected responses and report everything else to your monitoring system, leading to very effective and prototype-friendly development process. - (Elixir-specific I think) Flow control. You can basically make pipes of functions exactly like all the classic UNIX tools allow you to. I've heard devs scoff at that a good amount of times... same devs were like "OMG how did I live without this so far?!" a few days later. :D It makes for extremely elegant and readable code that allows near-instant onboarding (or reminding oneself of the code they wrote a while ago). - (Erlang + Elixir) Built-in in-memory cache. The ability to not care about Redis / memcached is a much bigger deal than many suspect. Granted it's a single-node only but honestly? Never mattered in my practice. --- There are others but this comment became huge already. Main selling point for me as a senior backender and aspiring sysadmin is the extremely easy parallelism and very terse code (that's owed by the piping mechanism of Elixir). The ability to structure your app as a tree of supevisors and workers (that get auto-restarted on failure nonetheless) is a very close third. Elixir absolutely isn't a silver bullet -- f.ex. it sucks for CLI apps because the VM takes no less than 0.5s to start -- but for a ton of server apps it's up there in the top 5-10 with Rust and Golang.
- Jtsummers 4y ago
  > - (Elixir-specific) A lot of tools around fault tolerance and supervision trees. You can have static hierarchies and you can have dynamic ones (spawn children, have them do work, have them shut down). You can register green threads by name and enforce limits on how many of them are around, you can also load-balance work between several nodes. Maybe Elixir adds some tooling, but supervision trees comes from its Erlang/OTP heritage.
  - pdimitar 4y ago
    I know that OTP is the primitive below but Elixir adds many interesting and useful tools on top e.g. DynamicSupervisor and even a partitioned supervisor (executing tasks among several nodes). It basically makes OTP even better by building several useful and often needed real-world tools on top of it.

pdimitar 4y ago

Well I have no experience in Erlang -- only checked it out a few times and I like that Elixir removes some of the more manual aspects of Erlang (like manually exporting functions from a module). So, why Elixir (and partially why Erlang): - (Erlang + Elixir) Transparent parallelism. This is not a joke. You're a function + closure away from multiplexing stuff on all your CPU cores (or even more e.g. it's OK to have a limit of a worker pool be 100+ for e.g. network workers). - (Elixir-specific) A lot of tools around fault tolerance and supervision trees. You can have static hierarchies and you can have dynamic ones (spawn children, have them do work, have them shut down). You can register green threads by name and enforce limits on how many of them are around, you can also load-balance work between several nodes. - (Elixir-specific) Macros: you can generate code at compile-time which is extremely useful if you want to limit the set of values that you'd work with at run-time. Example: the Unicode functionality of Elixir is actually generated by macros that basically do a `for` loop of all codepoints / graphemes and utilizes pattern-matching on each value. Super tedious by hand, extremely trivial with macros / code-generation. Useful in many other scenarios as well e.g. you can inject code in a receiver module with macros. - (Erlang + Elixir) Pattern matching. While the languages sadly have no static strong typing, pattern-matching helps a ton e.g. interacting with remote APIs you can match on several expected responses and report everything else to your monitoring system, leading to very effective and prototype-friendly development process. - (Elixir-specific I think) Flow control. You can basically make pipes of functions exactly like all the classic UNIX tools allow you to. I've heard devs scoff at that a good amount of times... same devs were like "OMG how did I live without this so far?!" a few days later. :D It makes for extremely elegant and readable code that allows near-instant onboarding (or reminding oneself of the code they wrote a while ago). - (Erlang + Elixir) Built-in in-memory cache. The ability to not care about Redis / memcached is a much bigger deal than many suspect. Granted it's a single-node only but honestly? Never mattered in my practice. --- There are others but this comment became huge already. Main selling point for me as a senior backender and aspiring sysadmin is the extremely easy parallelism and very terse code (that's owed by the piping mechanism of Elixir). The ability to structure your app as a tree of supevisors and workers (that get auto-restarted on failure nonetheless) is a very close third. Elixir absolutely isn't a silver bullet -- f.ex. it sucks for CLI apps because the VM takes no less than 0.5s to start -- but for a ton of server apps it's up there in the top 5-10 with Rust and Golang.

Jtsummers 4y ago
> - (Elixir-specific) A lot of tools around fault tolerance and supervision trees. You can have static hierarchies and you can have dynamic ones (spawn children, have them do work, have them shut down). You can register green threads by name and enforce limits on how many of them are around, you can also load-balance work between several nodes. Maybe Elixir adds some tooling, but supervision trees comes from its Erlang/OTP heritage.
- pdimitar 4y ago
  I know that OTP is the primitive below but Elixir adds many interesting and useful tools on top e.g. DynamicSupervisor and even a partitioned supervisor (executing tasks among several nodes). It basically makes OTP even better by building several useful and often needed real-world tools on top of it.