Dashbit Blog

Anecdotally, it is very much different in Elixir land. I occasionally see bugs related to something being unexpectedly `nil` but it's pretty rare IME.

I'd love to evidence what I'm saying with specific numbers since this kind of discussion would benefit from being as objective as possible. Sadly I don't have them. But I still believe what I'm saying and I have a few guesses about some of the causes:

1. Immutable data - so, so many bugs are caused by data mutating out from under you in subtle ways. If you write `x = 1` in your Elixir function, nothing can change the value of `x` except an explicit rebinding. You can then write e.g. `y = f(x)` and know `x` remains unchanged after. Note: this is also true even if the variable is a composite type. `my_struct = blah()` will remain the same in it's entirety no matter what you do with `my_struct`. This is different than in JS where e.g. you can change the contents of an object even if it's declared `const`.

2. Assertive style - the Elixir community favors writing things in an "assertive" fashion [1]. Briefly, this a way of writing code that will fail the moment an assumption is broken rather than letting the issue propagate.

3. Pattern matching (somewhat like destructuring in JS) - Elixir code actually ends up feeling "typed" with pattern matching. E.g. `%Time{} = today = Date.utc_today()` will attempt to bind `today` to the result of `Date.utc_today()` and will raise a `MatchError` when the result, a `%Date{}` struct, fails to…

Excellent read! This is the first time I feel like I finally have a good handle on the "what" & "why" of RSCs.

It has also sparked a strong desire to see RSCs compared and contrasted with Phoenix LiveView.

The distinction between RSCs sending "JSX" over the Wire, and LiveViews sending "minimal HTML diffs"[0] over the wire is fascinating to me, and I'm really curious how the two methodologies compare/contrast in practice.

It'd be especially interesting to see how client-driven mutations are handled under each paradigm. For example, let's say an "onClick" is added to the `<button>` element in the `LikeButton` client component -- it immediately brings up a laundry list of questions for me:

1. Do you update the client state optimistically? 2. If you do, what do you do if the server request fails? 3. If you don't, what do you do instead? Intermediate loading state? 4. What happens if some of your friends submit likes the same time you do? 5. What if a user accidentally "liked", and tries to immediately "unlike" by double-clicking? 6. What if a friend submitted a like right after you did, but theirs was persisted before yours?

(I'll refrain from adding questions about how all this would work in a globally distributed system (like BlueSky) with multiple servers and DB replicas ;))

Essentially, I'm curious whether RSCs offer potential solutions to the same sorts of problems Jose Valim identified here[1] when looking at Remix Submission & Revalidation.

Overall, LiveView & RSCs…

1. Because they've privileged Docker Hub throughout all Docker tooling everywhere, and encouraged everybody to treat it as the central community hub of images. It's not just any registry: it's the core registry for the entire ecosystem, and they've very actively worked to ensure that state (rejecting all requests to make the default configurable, or to deprecate implicit registry references, etc).

2. Because the open-source application form excludes the vast majority of open-source projects. E.g. Curl isn't eligible because the founder additionally offers paid support. I imagine Elixir won't be either as the founder profits from it by running an Elixir consultancy (https://dashbit.co/). Docker Inc itself is marketed as an open-source project, but clearly wouldn't be eligible either. There's no revenue limits, no flexibility, just 'no plan towards >$0 revenue ever'. This is not most people's definition of 'open source'.

3. Because although yes it is a lot of traffic, they're trying to charge the community orgs to host images, whilst simultaneously they already charging the end users to pull these images too! They tightened the rate limits in 2020 so that any serious download usage as a client already requires a paid account.

4. Because they've given only 30 days notice before they'll drop all the existing images, with no redirection or migration options at all - just "pay up or we delete everything".

5. Because this will break every existing reference to every deleted…

> I keep hearing everyone talk about how Erlang/Elixir gives everything out of the box and you don't need to worry about Queues, RPC or whatever...

Many companies are using Distributed Erlang but not the way you described: they are using it to exchange messages between nodes running the same version of the software. Imagine that you are building a web application, you can directly exchange live messages between nodes without Redis/RabbitMQ [1]. If you are deploying a machine learning model, you can route requests through multiple nodes and GPUs without additional deps [2]. If you want to see which users are connected to your app, you can exchange this information directly between nodes [3].

In other words, there is a subset of distributed problems that Distributed Erlang solves very well out of the box: homogeneous systems working on ephemeral data. And some of the scenarios above are very common.

If you need to communicate between different systems or you need to persist data, then I 100% agree with you, I would not use Distributed Erlang (at best it would be one part of the solution). I think this distinction gets lost in many conversations and sometimes it leads to false dichotomies: "why Erlang when I have k8s/grpc/redis?" while in practice there is not a lot of overlap. I have written about Erlang/Elixir vs Redis [4] and vs k8s [5] for those interested.

[1]: https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html
[2]:…

I think Elixir would be interesting for your usecase.

It's a dynamic, garbage collected language. It's easy to pick up and get going with. As a functional programming language there isn't a lot to learn in the way of language constructs, and you don't even have to do the 'wrestling with the type system' thing that you have to do in compiled functional languages like OCaml or Haskell (like you do in Rust).

Its processing 'horsepower' is probably comparable to Python, but it's much better for building low latency things if you want to run something in a bit more of a production use case. This is also improving due to the recent addition of a JIT.

The addition of NX is making Elixir an increasingly interesting place to do ML - write Elixir, have it run on GPU etc. See https://dashbit.co/blog/nx-numerical-elixir-is-now-publicly-available

Python integration is probably best done using the Erlang 'port' system - running Python as a managed process and communicating with it using messages over stdin/stdout. I use it for C interop and it works well (and fits well with the Elixir/Erlang process model). It's not difficult to roll your own in Python e.g. https://github.com/fujimisakari/erlang-port-with-python/blob/master/erlang_port/protocol.py/ or look at something like http://erlport.org/

I'm at a relatively early stage VC-backed startup and from day 1 it's been written in Elixir. It was a fantastic choice, for many reasons, with some being:

- Elixir is good for just getting stuff done. I came from a previous startup that used Go and Elm.

- The community isn't as small as people make it out to be, or, it's quality over quantity. ;)

- There's a lot of good modules out there, and if you need to write your own, it's easy and there's well-defined patterns. E.g. I recently improved our internal Zendesk client and it was a breeze.

- https://dashbit.co/ for paid support/advice is amazing.

- The console for experimentation, debugging, inspection, etc. is fantastic.

- The let it crash, and other Elixir/Erlang philosophies, have been very helpful.

- There's a solid amount of batteries-included, but not in an overbearing/restrictive way.

- It's such a pleasant day-to-day dev experience.

I didn't know Elixir before joining this startup. For myself, and workmates who also didn't have prior experience, it's been a breeze to get up to speed in.