45 ms·

I have been watching Elixir YouTube videos pretty much every day for the last few weeks. I guess there was an Elixir conference recently and after I watched a c

I have been watching Elixir YouTube videos pretty much every day for the last few weeks. I guess there was an Elixir conference recently and after I watched a couple, YouTube has been sending me a consistent stream of Elixir content. I really want to try out this language. I love the idea of Erlang but the few times I've had to deal with it (an ejabberd chat server was one) I found it to be a bit too quirky. Every video I've seen with Joe Armstrong leads me to believe he was an under-appreciated genius. Isolated processes and message passing (Actors) seem a good candidate for the future of distributed programming (see this recent video from Crockford on his new Misty programming language [1] - notice how the questions were about Elixir/Erlang). I love pattern matching and elixir uses this to a high degree. However, I am not 100% sold. Clearly this community punches above its weight, and the BEAM is obviously no slouch and is a brilliant choice for a platform to build upon. But I get concerned looking at the magic of LiveView (and LiveBook). My experience is that if something sounds too good to be true, it often is. A lot of the jargon is also totally unfamiliar to me - things like GenServers and other esoteric kinds of platform specific knowledge. It feels like stepping into a one-way portal, I'm not sure any knowledge in that universe is transferable. There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. With alternatives like Go having a pretty respectable concurrency story ... it is pretty hard to justify taking the risk on such a small community. But kudos to that community. It is honestly impressive to me what they have achieved. I'm also very excited to see what happens with their type system implementation. 1. https://www.youtube.com/watch?v=R2idkNdKqpQ https://www.youtube.com/watch?v=R2idkNdKqpQ

throwawaymaths 3y ago
> looking at the magic of LiveView (and LiveBook) What's the magic? I think it's pretty easy to get a correct mental model of everything in livebook maybe excepting exact details of how the diff calculation/data compression works. Even so, you can spy on the websocket messages and get a reasonable picture of what's going on in a pinch. Liveview is incredibly straightforward.
- zoogeny 3y ago
  > Liveview is incredibly straightforward. I don't agree. One of the keynotes from the 2023 ElixirConf was Chris McCord (one of the principle developers of LiveView) describing how it is almost 1.0 [1]. One thing that made me laugh a bit was him emphasizing how much Javascript he's had to write (he was referencing the fact that there is an internal community meme that you can achieve such incredible behaviors without writing Javascript). His quip was "because I wrote it all". I wonder if you asked him "was it straightforward?" what do you think his answer would be? There are a lot of videos of people talking about how they managed to write something in LiveView. Here is one from 2022 "How I built a block based editor in LiveView" [2]. That is a good one to see how non-trivial tasks can be difficult in LiveView, describing a few times how he had to fight with it to get it to kinda-sorta do what he wanted. Certainly this man will achieve his goal since he is smart and motivated, but his description of his journey does not lead me to a conclusion of "this is incredibly straightforward". This is impressive tech no doubt, but it is far from clear it is currently reliable enough to stake a startup on. Another tangential issue I have with LiveView is the obvious requirement for a persistent socket connection ... which leads me to wonder how one would approach local-first type developments. Again, certainly possible but definitely not straightforward. 1. https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeSync https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeS... 2. https://www.youtube.com/watch?v=7yZwxsG7tVs https://www.youtube.com/watch?v=7yZwxsG7tVs
  - porker 3y ago
    LiveView is optional though and IMO is still overused for tasks that would be better accomplished with client side JS. Where this gets messy is mixing LiveView and client side JS, and I need to experiment further with this (or find people who have).
  - rkangel 3y ago
    I suspect that you might be right about using LiveView for things that are traditionally full, rich client side JS apps. However, it is absolutely awesome for the "slightly javascript" case of a lot of UIs. Two examples, from my work: Forms with "live" display of validation errors, using one single set of validation on the backend, rather than the duplicated frontend and backend having to match. It's completely trivial to implement with LiveView. Status displays - We built some development hardware based on a Xilinx Zynq FPGA (FPGA + ARM running Linux) and used LiveView to report a lot of the hardware state - primarily the status of all of the registers. A little fiddling with HTML+CSS for the register widget, but then everything else could not have been easier - render your widget once per register, and rerun that whole thing any time pubsub provides an updated register value.
hosh 3y ago
I went from Ruby to Elixir to Nodejs. I am writing Nodejs because I have to, not because I want to. Having used it now, I will never ever start a new project with it. Nodejs's concurrency controls, ability to scale, tools for reliability and observability are so far behind from the BEAM ecosystem. I sometimes think people think Elixir is too good to be true because they're too used to platforms not designed to be resilient.
- conradfr 3y ago
  Elixir is definitely a better Nodejs... that JS developers don't know about.
  - hosh 3y ago
    It took me months before it sank in that Nodejs async wasn't really async as I knew it from Elixir -- there's an implicit queue, and no true suspension of the execution flow. One justification for this was that it is supposed to make it easier to reason. It made it more difficult for me to reason -- maybe single-threaded async reactor is a poor substitute for immutability. Unhandled promise rejection is an example of a consequence of this design. That's not really a thing in Elixir by design. But in the Nodejs world, people don't even see it as a design flaw. It makes reasoning about reliability much more difficult.
    - skrebbel 3y ago
      > One justification for this was that it is supposed to make it easier to reason. It’s a valid justification because it makes it substantially easier to reason compared to mutable multithreaded languages/runtimes such as C(++), Java and C#. Eg a semaphore in JS doesn’t exist. It’s just a boolean. Interlocked Increment doesn’t exist. It’s just someVar++. And so on, it’s very nice. That doesn’t mean that there aren’t other setups (such as immutable data with message passing) that are even easier to reason about. Every new tech compares itself to the current mainstream.
      - deleted 3y ago
        [deleted]
victorbjorklund 3y ago
I actually find the opposite to be true. Elixir is less "magic" once you learn it. I can see and understand what most things are doing and read the code. With javascript? Not so much. On the point of hard to hire and hard to find tutorials. It is true. It is way harder to find for example someone that done what you wanna do in elixir vs javascript. When it comes to libaries it isnt so big problem. There are lots of libraries and so far I havent really encountered any problems. Only thing would be if you interact with an API they might provide a client library for javascript and python (but less common for Go) but not elixir. But honestly it is usually not so hard to use an API with just a http-client.
- devoutsalsa 3y ago
  Elixir is actually the easiest language to read (for me), once I knew it. You can make it difficult to follow if you want to, but when people are using it to pass around plain old data structures, it's very legible. Speaking only for myself. YMMV.
  - ljm 3y ago
    (author here) - I've also found this to be true. The most confounding aspects of elixir tend to be choices made to fit a square object into a round hole. For example, creating interfaces over functions so Hammox can mock them in your tests. It creates a lot of frustrating boilerplate and suddenly your actual code gets lost in the noise of indirection.
- agumonkey 3y ago
  an instance of simple vs easy
jb3689 3y ago
You are overthinking some of it at least when it comes to concurrency. Look at what a process is and how send works. GenServer is a natural generalization of a pattern you’d write a thousand times. Knowledge of actors is transferable. Go has libraries which implement actor abstractions for example. Process mailboxes are just message queues like Go’s channels are. There are differences with respect to how the interpreters work and how processor yields work. Stuff like LiveView though looks like magic because it is magic. There are a lot of moving parts involved in getting it working. It’s the result of work that has been going on for the past decade across multiple communities though. The ideas are mature even if there is a lot of abstraction. Stuff like Riak was well ahead of its time. They basically had the idea of being able to create robust distributed systems much the same way you would a GenServer.
- riffraff 3y ago
  Why do you think riak was well ahead of its time? (actual question, I'm not arguing) IIRC it was a few years after the dynamo paper came out, and at a time when a bunch of other nosql+high scalability solutions did (e.g. Cassandra)
  - macintux 3y ago
    I suspect the parent comment is primarily referring to Riak Core, which was another layer of abstraction above Erlang’s OTP for distributed processing. Riak the database used Riak Core, but it could be used independently of the database. I hadn’t thought about Core in a long time, I should take another look. Looks like someone is carrying the idea forward: https://riak-core-lite.github.io/ https://riak-core-lite.github.io/
    - riffraff 3y ago
      Ah that makes sense, thank you.
- baq 3y ago
  Riak was pretty bad at ops. Leaving and joining nodes took ages and god forbid you tried to use any of the added features like solr search. If you settled on a very small subset of all features it worked nicely... it just wasn't very useful if anything went wrong due to app or user error.
thibaut_barrere 3y ago
> There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. There is a real need to push Elixir outside its initial circles and it's being done a bit at the moment (I feel). Both Chris & José are doing a lot of work for exposure outside the initial Elixir circles, and some people in the community are doing the same at their own levels. Hiring is not that complicated actually, because a fair bit of people want to work in the language (I experience that first-hand), and a good developer will be up-to-speed quite quickly too. But the "niche" aspect must be tamed in my opinion, and is both a risk (for the language itself) and a short-term reward (being proficient in a niche something is usually quite good).
- Champagn3Papi 3y ago
  I switched jobs and working as an elixir dev now. I love elixir don't get me wrong, but some of the documentation especially some of the more advanced features in ecto are very confusing. It doesn't help you can define your ecto instructions in multiple flavors too (inline vs piping) You can't mix inline with pipe operators without creating an additiona variable too hold the original query. If we want to make it less niche, there's definitely good working points there. Once people understand how to hit a database from elixir it magically clicks and the other stuff is more trivial.
  - thibaut_barrere 3y ago
    Ecto is a specific area and I must say I share your view on the "flavours" aspect (keywords vs not). I would personally love if there was only "one way". And agree that there are both excellent documentation, _and_ things that are kind of "assumed" and would need better "beginner" stuff (in my opinion).
  - di4na 3y ago
    Ecto documentation is definitely i think one of our weakest point. Which is great on one hand, because it means we are quite above the average stack in term of onboarding and doc. But also really makes ecto documentation and onboarding a visible sore point in the middle of the rest. Sadly i do not have solutions rn but if people have ideas please come offer them.
dorian-graph 3y ago
> There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. With alternatives like Go having a pretty respectable concurrency story ... it is pretty hard to justify taking the risk on such a small community. People say this every time Elixir comes up, but, I would like to hear evidence of this being true. I worked at a startup for a couple of years and had never used Elixir. The majority of the engineers who worked there, whilst I did, also hadn't. We had a few who were experts in the language and a couple who had well-known open source packages. Genuinely from my experience, each of the things in your list are simply not true. > But I get concerned looking at the magic of LiveView (and LiveBook). What magic? Again, genuinely questioning this.
timwis 3y ago
I have found the book _Programming Phoenix LiveView_ to be a great explainer as to what’s going on in liveview. It’s written for people new to Phoenix as well. I’m only halfway through and already building quite a lot with it, and, critically, I reckon I could explain pretty well what’s going on under the hood. https://pragprog.com/titles/liveview/programming-phoenix-liveview/ https://pragprog.com/titles/liveview/programming-phoenix-liv...
jacquesm 3y ago
The basic idea that infuses all of Armstrong's writings and work is reliability, not concurrency, that's just a means to an end to achieve higher reliability (and lower latency, which in the context of (soft) real time can be a failure condition if certain guarantees are not met.
- zoogeny 3y ago
  I think you are right and wrong. I've watched 3 or 4 videos of Joe Armstrong on YouTube this week (he seemed to show up a lot at Strange Loop). He talks a lot about concurrency for its own sake. However, you are right that he also heavily emphasizes reliability and how concurrency contributes to that. More interesting to me is his physical theories about computation. For example, he hints often at his idea of the blackhole as the most powerful computer. As we think about the distribution of computational systems, I wonder how often we consider the density of computational systems.
hmmokidk 3y ago
Live view has immensely less magic than react or nextjs. In fact it's kind of crazy how much of it I understand given I haven't tried. The community is just all about simple tools and understanding them.
querulous 3y ago
the big risk with elixir imo is that it's runtime/vm is still owned by ericsson and there's no alternative. i know things like firefly exist but they aren't mature replacements (to my knowledge)
- zoogeny 3y ago
  I thought Open Source Erlang is Apache 2.0 based on the first paragraph on the Erlang faq page [1]: "You can use Open Source Erlang to build commercial products without having to pay royalties or licence fees to Ericsson. Open Source Erlang uses the Apache License 2.0." I think it is a bit confusing actually, since they differentiate between Erlang (the language), ERTS (Erlang Runtime System) and the BEAM. It isn't clear to me what "Open Source Erlang" refers to with respect to those distinctions, or what the licenses are for each of them. 1. https://www.erlang.org/faq/implementations https://www.erlang.org/faq/implementations

throwawaymaths 3y ago

> looking at the magic of LiveView (and LiveBook) What's the magic? I think it's pretty easy to get a correct mental model of everything in livebook maybe excepting exact details of how the diff calculation/data compression works. Even so, you can spy on the websocket messages and get a reasonable picture of what's going on in a pinch. Liveview is incredibly straightforward.

zoogeny 3y ago
> Liveview is incredibly straightforward. I don't agree. One of the keynotes from the 2023 ElixirConf was Chris McCord (one of the principle developers of LiveView) describing how it is almost 1.0 [1]. One thing that made me laugh a bit was him emphasizing how much Javascript he's had to write (he was referencing the fact that there is an internal community meme that you can achieve such incredible behaviors without writing Javascript). His quip was "because I wrote it all". I wonder if you asked him "was it straightforward?" what do you think his answer would be? There are a lot of videos of people talking about how they managed to write something in LiveView. Here is one from 2022 "How I built a block based editor in LiveView" [2]. That is a good one to see how non-trivial tasks can be difficult in LiveView, describing a few times how he had to fight with it to get it to kinda-sorta do what he wanted. Certainly this man will achieve his goal since he is smart and motivated, but his description of his journey does not lead me to a conclusion of "this is incredibly straightforward". This is impressive tech no doubt, but it is far from clear it is currently reliable enough to stake a startup on. Another tangential issue I have with LiveView is the obvious requirement for a persistent socket connection ... which leads me to wonder how one would approach local-first type developments. Again, certainly possible but definitely not straightforward. 1. https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeSync https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeS... 2. https://www.youtube.com/watch?v=7yZwxsG7tVs https://www.youtube.com/watch?v=7yZwxsG7tVs
- porker 3y ago
  LiveView is optional though and IMO is still overused for tasks that would be better accomplished with client side JS. Where this gets messy is mixing LiveView and client side JS, and I need to experiment further with this (or find people who have).
- rkangel 3y ago
  I suspect that you might be right about using LiveView for things that are traditionally full, rich client side JS apps. However, it is absolutely awesome for the "slightly javascript" case of a lot of UIs. Two examples, from my work: Forms with "live" display of validation errors, using one single set of validation on the backend, rather than the duplicated frontend and backend having to match. It's completely trivial to implement with LiveView. Status displays - We built some development hardware based on a Xilinx Zynq FPGA (FPGA + ARM running Linux) and used LiveView to report a lot of the hardware state - primarily the status of all of the registers. A little fiddling with HTML+CSS for the register widget, but then everything else could not have been easier - render your widget once per register, and rerun that whole thing any time pubsub provides an updated register value.

hosh 3y ago

I went from Ruby to Elixir to Nodejs. I am writing Nodejs because I have to, not because I want to. Having used it now, I will never ever start a new project with it. Nodejs's concurrency controls, ability to scale, tools for reliability and observability are so far behind from the BEAM ecosystem. I sometimes think people think Elixir is too good to be true because they're too used to platforms not designed to be resilient.

conradfr 3y ago
Elixir is definitely a better Nodejs... that JS developers don't know about.
- hosh 3y ago
  It took me months before it sank in that Nodejs async wasn't really async as I knew it from Elixir -- there's an implicit queue, and no true suspension of the execution flow. One justification for this was that it is supposed to make it easier to reason. It made it more difficult for me to reason -- maybe single-threaded async reactor is a poor substitute for immutability. Unhandled promise rejection is an example of a consequence of this design. That's not really a thing in Elixir by design. But in the Nodejs world, people don't even see it as a design flaw. It makes reasoning about reliability much more difficult.
  - skrebbel 3y ago
    > One justification for this was that it is supposed to make it easier to reason. It’s a valid justification because it makes it substantially easier to reason compared to mutable multithreaded languages/runtimes such as C(++), Java and C#. Eg a semaphore in JS doesn’t exist. It’s just a boolean. Interlocked Increment doesn’t exist. It’s just someVar++. And so on, it’s very nice. That doesn’t mean that there aren’t other setups (such as immutable data with message passing) that are even easier to reason about. Every new tech compares itself to the current mainstream.
    - deleted 3y ago
      [deleted]

victorbjorklund 3y ago

I actually find the opposite to be true. Elixir is less "magic" once you learn it. I can see and understand what most things are doing and read the code. With javascript? Not so much. On the point of hard to hire and hard to find tutorials. It is true. It is way harder to find for example someone that done what you wanna do in elixir vs javascript. When it comes to libaries it isnt so big problem. There are lots of libraries and so far I havent really encountered any problems. Only thing would be if you interact with an API they might provide a client library for javascript and python (but less common for Go) but not elixir. But honestly it is usually not so hard to use an API with just a http-client.

devoutsalsa 3y ago
Elixir is actually the easiest language to read (for me), once I knew it. You can make it difficult to follow if you want to, but when people are using it to pass around plain old data structures, it's very legible. Speaking only for myself. YMMV.
- ljm 3y ago
  (author here) - I've also found this to be true. The most confounding aspects of elixir tend to be choices made to fit a square object into a round hole. For example, creating interfaces over functions so Hammox can mock them in your tests. It creates a lot of frustrating boilerplate and suddenly your actual code gets lost in the noise of indirection.
agumonkey 3y ago
an instance of simple vs easy

jb3689 3y ago

You are overthinking some of it at least when it comes to concurrency. Look at what a process is and how send works. GenServer is a natural generalization of a pattern you’d write a thousand times. Knowledge of actors is transferable. Go has libraries which implement actor abstractions for example. Process mailboxes are just message queues like Go’s channels are. There are differences with respect to how the interpreters work and how processor yields work. Stuff like LiveView though looks like magic because it is magic. There are a lot of moving parts involved in getting it working. It’s the result of work that has been going on for the past decade across multiple communities though. The ideas are mature even if there is a lot of abstraction. Stuff like Riak was well ahead of its time. They basically had the idea of being able to create robust distributed systems much the same way you would a GenServer.

riffraff 3y ago
Why do you think riak was well ahead of its time? (actual question, I'm not arguing) IIRC it was a few years after the dynamo paper came out, and at a time when a bunch of other nosql+high scalability solutions did (e.g. Cassandra)
- macintux 3y ago
  I suspect the parent comment is primarily referring to Riak Core, which was another layer of abstraction above Erlang’s OTP for distributed processing. Riak the database used Riak Core, but it could be used independently of the database. I hadn’t thought about Core in a long time, I should take another look. Looks like someone is carrying the idea forward: https://riak-core-lite.github.io/ https://riak-core-lite.github.io/
  - riffraff 3y ago
    Ah that makes sense, thank you.
baq 3y ago
Riak was pretty bad at ops. Leaving and joining nodes took ages and god forbid you tried to use any of the added features like solr search. If you settled on a very small subset of all features it worked nicely... it just wasn't very useful if anything went wrong due to app or user error.

thibaut_barrere 3y ago

> There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. There is a real need to push Elixir outside its initial circles and it's being done a bit at the moment (I feel). Both Chris & José are doing a lot of work for exposure outside the initial Elixir circles, and some people in the community are doing the same at their own levels. Hiring is not that complicated actually, because a fair bit of people want to work in the language (I experience that first-hand), and a good developer will be up-to-speed quite quickly too. But the "niche" aspect must be tamed in my opinion, and is both a risk (for the language itself) and a short-term reward (being proficient in a niche something is usually quite good).

Champagn3Papi 3y ago
I switched jobs and working as an elixir dev now. I love elixir don't get me wrong, but some of the documentation especially some of the more advanced features in ecto are very confusing. It doesn't help you can define your ecto instructions in multiple flavors too (inline vs piping) You can't mix inline with pipe operators without creating an additiona variable too hold the original query. If we want to make it less niche, there's definitely good working points there. Once people understand how to hit a database from elixir it magically clicks and the other stuff is more trivial.
- thibaut_barrere 3y ago
  Ecto is a specific area and I must say I share your view on the "flavours" aspect (keywords vs not). I would personally love if there was only "one way". And agree that there are both excellent documentation, _and_ things that are kind of "assumed" and would need better "beginner" stuff (in my opinion).
- di4na 3y ago
  Ecto documentation is definitely i think one of our weakest point. Which is great on one hand, because it means we are quite above the average stack in term of onboarding and doc. But also really makes ecto documentation and onboarding a visible sore point in the middle of the rest. Sadly i do not have solutions rn but if people have ideas please come offer them.

dorian-graph 3y ago

> There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. With alternatives like Go having a pretty respectable concurrency story ... it is pretty hard to justify taking the risk on such a small community. People say this every time Elixir comes up, but, I would like to hear evidence of this being true. I worked at a startup for a couple of years and had never used Elixir. The majority of the engineers who worked there, whilst I did, also hadn't. We had a few who were experts in the language and a couple who had well-known open source packages. Genuinely from my experience, each of the things in your list are simply not true. > But I get concerned looking at the magic of LiveView (and LiveBook). What magic? Again, genuinely questioning this.

timwis 3y ago

I have found the book _Programming Phoenix LiveView_ to be a great explainer as to what’s going on in liveview. It’s written for people new to Phoenix as well. I’m only halfway through and already building quite a lot with it, and, critically, I reckon I could explain pretty well what’s going on under the hood. https://pragprog.com/titles/liveview/programming-phoenix-liveview/ https://pragprog.com/titles/liveview/programming-phoenix-liv...

jacquesm 3y ago

The basic idea that infuses all of Armstrong's writings and work is reliability, not concurrency, that's just a means to an end to achieve higher reliability (and lower latency, which in the context of (soft) real time can be a failure condition if certain guarantees are not met.

zoogeny 3y ago
I think you are right and wrong. I've watched 3 or 4 videos of Joe Armstrong on YouTube this week (he seemed to show up a lot at Strange Loop). He talks a lot about concurrency for its own sake. However, you are right that he also heavily emphasizes reliability and how concurrency contributes to that. More interesting to me is his physical theories about computation. For example, he hints often at his idea of the blackhole as the most powerful computer. As we think about the distribution of computational systems, I wonder how often we consider the density of computational systems.

hmmokidk 3y ago

Live view has immensely less magic than react or nextjs. In fact it's kind of crazy how much of it I understand given I haven't tried. The community is just all about simple tools and understanding them.

querulous 3y ago

the big risk with elixir imo is that it's runtime/vm is still owned by ericsson and there's no alternative. i know things like firefly exist but they aren't mature replacements (to my knowledge)

zoogeny 3y ago
I thought Open Source Erlang is Apache 2.0 based on the first paragraph on the Erlang faq page [1]: "You can use Open Source Erlang to build commercial products without having to pay royalties or licence fees to Ericsson. Open Source Erlang uses the Apache License 2.0." I think it is a bit confusing actually, since they differentiate between Erlang (the language), ERTS (Erlang Runtime System) and the BEAM. It isn't clear to me what "Open Source Erlang" refers to with respect to those distinctions, or what the licenses are for each of them. 1. https://www.erlang.org/faq/implementations https://www.erlang.org/faq/implementations