What is the best Elixir talk to present to a team to try Elixir?

Can I get some suggestions for the best talk to present to my team and leadership in order to convince them to try Elixir?

3 Likes

I like The Soul of Erlang and Elixir by Saša Juric. It doesn’t go into details on Elixir but it does show the benefits of using it.

21 Likes

Give them an example of WebSocket-based web application that can scale out without introducing things like Redis and MQ, packed it in a Docker image, and let Kubernetes/Docker swarm handle the container orchestration and let the replicas find each other using libcluster.

Actually I’m working on such a project myself, for the internal use in my company. It’s a per-project terminology base. Here are the repos on GitHub (sorry for being a Chinese mandarin native speaker):

And here’s an example docker-compose.yml for Docker Swarm:

version: '3.7'

services:
  app:
    image: 127.0.0.1:5000/termina:0.2.0
    ports:
      - 4000:4000
    environment:
      TERMINA_HOST: localhost
      TERMINA_PORT: 4000
      TERMINA_DB_HOSTNAME: db
      TERMINA_DB_USERNAME: postgres
      TERMINA_DB_PASSWORD: postgres
      TERMINA_DB_DATABASE: termina
      TERMINA_DB_POOL_SIZE: 10
    deploy:
      mode: replicated
      replicas: 3

  ui:
    image: 127.0.0.1:5000/termina-ui:0.2.2
    ports:
      - 80:80

  db:
    image: postgres:12-alpine
    hostname: db
    volumes:
      - /data/termina/db:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: termina
      POSTGRES_INITDB_ARGS: "--encoding=UTF8"
    deploy:
      mode: replicated
      replicas: 1

  migration:
    image: 127.0.0.1:5000/termina:0.2.0
    environment:
      # same as the app
    command: 
      - /app/bin/termina
      - eval
      - "Application.load(:termina); Application.fetch_env!(:termina, :ecto_repos) |> hd() |> Ecto.Migrator.with_repo(&Ecto.Migrator.run(&1, :up, all: true))"
    deploy:
      restart_policy:
        condition: on-failure
3 Likes

Thank you for link, it is amazing.

There are many great Elixir talks and the one by Saša Juric is high on the list. With that in mind, I would rather share a talk on Phoenix or Nerves, depending on your audience. A framework focused talk is by nature more applied and it could be more engaging for Elixir newbies.

1 Like

Twitter clone in 15 minutes is mind-blowing if you are aware what it takes to build something similar with other stacks.

https://www.phoenixframework.org/blog/build-a-real-time-twitter-clone-in-15-minutes-with-live-view-and-phoenix-1-5

8 Likes

Oh, yeah! That one’s also great!

My first pick is definitely The Soul of Erlang and Elixir as well, but as a followup to that I also like the practical demo in (by an employee of Quicken/Rocket Mortgage):

8 Likes

This is a good talk, but right in the middle Saša tells the audience not to use Elixir for distributed systems. The second sentence on Elixir’s website says:

Elixir leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems

I’m not sure how I can try to convince my team to try Elixir to build a new distributed system while also showing them a talk that says “do not use Elixir” for distributed systems.

Does he? What I remember him saying is to not use the built in support for distribution in the BEAM VM, but rather look at libraries e.g. Swarm. :thinking:

If that’s what he meant it wasn’t apparent to me.

I like the talk very much and I think this just shows honesty of a tech person. If someone tell you: here is a distributed solution that can scale linearly from one node to one thousand nodes, I will be very skeptical. Of cause using Elixir for a distributed system would has its own pros and cons and sweet spot, but it is beyond the scope of Saša’s talk.

Except he didn’t say it had a sweet spot. He said don’t use it for distributed systems.

He said:

Some people use it in production, some don’t, there are serious problems all the way, but they are mostly mechanical and could be fixed …

He could have phrase it more positively but this is not “don’t use it for distributed systems” but rather “use it at your own discretion and brace yourself for some rough ride”

1 Like

Another talk by one of my coworkers, @bryanhunter

2 Likes

I presume you’re refering to the part at 32:33 when I say that “BEAM distribution is plagued with a bunch of serious issues”. This definitely came out stronger than I intended (I guess I got carried away in the heat of the moment :slight_smile:), and somewhat sloppy. What I wanted to say is that there are some issues & challenges with distributed BEAM (aka distributed Erlang). I talked about those issues during the Q&A, which is unfortunately not recorded, but you can find the summary in this Redis response.

First, it’s worth noting that distributed BEAM is not the only way how you can build distributed systems running on multiple machines. Many other languages don’t even have such high-level support for that, and people still build distributed systems with them, using various techniques such as coordinating through 3rd party services (e.g. database, message queue, k-vs such as etcd or Redis, …), and/or building their own in-cluster communication protocol on top of TCP or HTTP.

Nothing stops you from doing the same with BEAM languages, i.e. bypassing distributed BEAM completely. For example, you could use Oban to distribute jobs accross multiple instances of BEAM nodes which are not even connected into a cluster. A few months ago I advised one client to do exactly that, instead of trying to coordinate things using distributed BEAM, because I believe that in this particular case such approach would simplify things significantly. Over the past years I’ve seen various reports of people building large-scale distributed systems with Erlang and Elixir, but without using distributed BEAM. It’s worth mentioning Partisan as an example of this approach.

That said, I also acknowledged that people use distributed BEAM in production. I don’t think I’ve seen a single BEAM-focused conference where there wasn’t at least one talk about distributed BEAM in practice. So I definitely don’t think that distributed BEAM is not usable, it’s just that I think it’s not as simple as it could be, or as it look like in the demo (though admittedly, distributed systems are never easy).

Finally, in the talk I also mentioned that distributed BEAM issues are mechanical, and that they can be fixed with time and effort. Only a few days after I gave the talk, OTP 22 has been released with one important improvement in this area. I’ve seen some improvements in the ecosystem too. For example, I’m excited about the ra library, which seems like a really solid and well tested Raft implementation in BEAM. While this is still relatively low-level, I feel it could be used as a toolkit for building simpler-to-use higher-level abstractions for distributed systems.

So tl;dr I never said “don’t use Elixir for distributed systems”, and that’s definitely not what I meant to communicate when I mentioned that there are some issues :slight_smile:

22 Likes

Excellent. My take away from this and the reddit thread is as of OTP 22, small scale, (say 50 nodes) same data center clustering using nothing but the built-in distributed BEAM is already a viable solution for some problem domains. I’d like to read some recent real world testimonies in this regard.

1 Like

Saša, thanks for responding to this thread. I want my teammates to watch this talk and was worried that the part at 32:33 would turn them off from Elixir, especially when one of Elixir’s tag line is “Distributed”. I’ve finally got a team here at Microsoft that’s willing to take a look at Elixir and I want that first look to go really well!

4 Likes

You can check Zandra Norman - Scaling Distributed Erlang if you want a deeper look into how distributed Erlang (and Elixir by extension) might work in the future.

1 Like

Not a talk, but the opening chapter and preface in Programming Phoenix is brilliant - and it’s free to download too :003:

First mentioned here:

And again here:

1 Like