Hacker News Reader

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.

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)

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/

Ah that makes sense, thank you.

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.

I think that was before things like raft or paxos

I had some similar issues with rabbitmq

On the other hand, Phoenix channels were much more flexible about membership

I was gonna say the actor model stems from state machines I believe. It's a nice way to manage state and communication. It reminds me of supervisors and processes in general but not program language specific.

Erlang developed the way it did before people started calling it an Actor model.

The key characteristic is not a state machine, but that:

- first class processes send messages to each other

- messages are queued

- each process is single execution flow. If you want to reenter code, start another process and send messages to it

- process execution can be preempted

- values passed in messages are for the most part, immutable.

- first class support for “links”, where one process gets notified when another process crashes (basis for supervision trees)

The consequences of this design are:

- for the most part, you don’t need mutexs

- spin locks are cheap

- every process can be suspended indefinitely when nothing is in the message queue. This is better than an async reactor.

- processes don’t get “lost” (I am looking at you, Nodejs)

- processes can receive control messages to suspend or shutdown, restart, etc. Most other platforms have to externalize that to say, K8S and such controls are crude.

- errors don’t get “lost” (Nodejs again …)

- repl in production, can inspect the whole system live, under load

- overloaded systems degrades gracefully instead of locking up

Erlang did appear after the creation of the actor model. The actor model is from 1973 : https://en.m.wikipedia.org/wiki/Actor_model And Erlang is from 1987 : https://fr.m.wikipedia.org/wiki/Erlang_%28langage%29

https://softwareengineering.stackexchange.com/a/277469

Looks like I misread it. While the Actor model was conceived before Erlang, the Erlang actor model was developed in parallel. It isn’t a pure implementation of Actors (everything is an Actor, making it closer fo Smalltalk). Only processes are Actors. It also implies that Akka is not a true Actor model as conceived in the originao ‘73 paper.

This goes into greater detail on the history: https://www.labouseur.com/courses/erlang/history-of-erlang-a...

In any case, there are not many contemporary systems that uses these ideas.

I have no trouble understanding the concepts, its the nomenclature that is different. It is the same with Haskell or other niche languages - once you are familiar with the terminology then you start to feel comfortable.

However, I just consider some things in the world outside of Elixir/Erlang/BEAM to be a bit more common. For example, using Docker with Kubernetes/ECS/etc as a deployment story. Or connecting micro-services using REST/gRPC/GraphQL. Or using queue systems like SQS or Kafka (to be fair, literally yesterday an ElixirConf talk about using Kafka with Elixir was posted). The advantage of BEAM is that you can avoid that stuff in some cases because it is built in to the platform - but that is a double edged sword since now you aren't doing those things.

Even if I have used Akka for Actors in Scala/Java/Kotlin, something about the BEAM based languages still feels like I am stepping onto the Galapagos Islands and seeing a ecosystem that has been evolving in its own isolation for decades. Sure, there are birds, but they just don't look like any birds I've seen before.

> 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).

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.

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).

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.

I believe José deserves a lot of credit. For example, the Elixir Conference looks well-produced. No doubt there is a large team behind that, but it is obvious his influence guides that process. I'm particularly thinking of the LiveNative talk where the founder of the company talks about his own vision for extending LiveView to mobile and desktop. He mentions several times when José has interacted with him to help guide the project to stay inline with Elixir's overall goals. Of course, there is also the hints of frustration of a commercial business having to wait for community consensus. But that kind of direct involvement in the community is extremely encouraging.

You also make a very good point about the risk and reward metric. One of the reasons I have been focusing on Elixir as opposed to other niche languages is the progress the community is making is inspiring. I recall an essay by Paul Graham where he talks about Lisp being a contributor to his success with the startup that made him wealthy. He believed that being faster to market with features due to his platform choice was decisive in that success. In that way, something like Elixir (and really, the BEAM) could be a decisive component to some startups success. Given that they are focusing on important contemporary ideas, that is possible. LiveBook for example and Nx/Axon/etc for ML may actually be a killer feature.

Of course, time will tell. I don't have a crystal ball. But I am very interested in watching it all unfold.

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.

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.

(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.

an instance of simple vs easy

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.

Elixir is definitely a better Nodejs... that JS developers don't know about.

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.

> 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.

You and I may know this, yet I have encountered smart people who defend a local maxima.

The whole reason Nodejs exists is because programmers eternally re-invent the wheel instead of accepting that there are already some pretty good wheels that they probably have no chance of matching.

> 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.

> 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=CodeS...

2. https://www.youtube.com/watch?v=7yZwxsG7tVs

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).

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.

This isn't really contextualizing the problem space well imo. How many companies exclusively used react pre-1.0? How many people using the "straight forward" vueJS had ever read the source code to understand the internals?

When someone says that liveview is straightforward, they aren't comparing it to stable backend languages that almost exclusively run on one operating system and one architecture and they certainly aren't referring to the many hacks every JS library incorporates to make the library more useful.

I think we have different definitions of straightforward. Liveview is straightforward to use because of Chris mccords effort and his good taste in software design and how a genserver is a good framework for state management.

I find LiveView either straightforward or a bit complicated, compared to other solutions, depending on the exact use cases. It's not necessarily easy initially to grow you own way to properly handle some scenarios, and some people can find the mental switch not that easy (but in general, it has been very useful to me!).

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-liv...

> 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.

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.

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.

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.

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)

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