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.
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. 
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 
), 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
23 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 
First mentioned here:
And again here:
1 Like
