tomekowal

Long answer: web applications have usually tons of independent request. Each request does its own thing, might never communicate with other requests, touches the DB and returns. You have two choices in such scenarios. You can either maximise throughput or minimise latency. BEAM's scheduler choses the latter which is usually what you want for web. More detailed discussion: https://tkowal.wordpress.com/2015/01/27/the-unintuitive-late...

With:

- per process garbage collection

- one BEAM process per request

- short lived HTTP processes

you might never trigger garbage collection, the whole memory is deallocated at the end of requests.

It basically means, BEAM gives you high level languages like Gleam or Elixir that are fast to write and prototype as Rails or Django, but are almost as performant as handwritten memory managed applications written in low level language.

This is magic sauce in startups: the freedom to go fast, prototype and iterate with scalibility issues popping up waaay later than in Ruby/Python stacks (sometimes never - if your startup is successful without supporting whatsapp's user base :P)

And that's just if you are donig plain old HTTP backend. With new reactive architectures, keeping persistent processes server side and using LiveView instead of JS frameworks can again cut development time.

And then, there is support for AI with LiveBook and NX... It is weird how many hard issues BEAM just makes much easier.

I had a talk where I showed how Elixir and Elm programming languages complement each other and someone in the audience asked what are we using Elixir for in our company. When I said that for payment systems he looked surprised, because he heard about "let it crash" in Elixir and he thought it is unusable for anything critical. That inspired me to talk about how we use Elixir for handling money.

I also answered questions on Stak Overflow for some time. Of course there are many typos or library quirks that are simply missed, but often you see a person that just entirely misunderstood the concept. This is also a target for talks. There might more people struggling with the same thing (especially if your question gets more views).

Pay attention to what surprises people when you are talking with them. If someone didn't know what you find obvious, there is a good chance more people don't know it. We have some kind of bias where we think that what WE know is common knowledge and automatically EVERYONE ELSE is smarter than us (because they know everything we know and some more that we don't). That is obviously not true :)

If you find a topic that surprised couple of people it means you have and idea worth sharing. It doesn't have to be novel! I often put quotes and references from blog posts that I read about given topic to show that this idea is not new at all! Old ideas are often not widely known or forgotten. They are perfect for conferences, because they might be crystalized over years, so it is easy to research them.

Comparing to Ruby: Phoenix promises to be as productive as Rails, but more performant and it keeps the promise if all the libraries you need are already ported to Elixir. Even if not, people consider writing them from scratch.

Comparing to Erlang: Elixir fixes a lot of problems like encoding or inconsistencies in standard library. It introduces many new concepts borrowed from Ruby so it might be a little overwhelming for Erlang developers (Erlang is really small and simple language - the hard part is OTP).

Learning Elixir is like learning to touch type. Initially it slows you down, because you have your habits. You need to learn new abstractions, because old solutions just don't work. After short period you are as productive as before. After a month you can deliver hight quality code quicker which is the ultimate goal of every programmer :) And it magically scales on more machines or at least utilizes all of the cores.