I’ve been asked by my supervisors at work to finally give everyone in the team presentation about “that Elixir thing you can’t seem to shut up about” (
) so I’m busy preparing slides that would hopefully present a good pitch as to why FP and Elixir is a good idea. I’d be happy to hear about past talks and presentations from other people that I could use as inspiration!
3 Likes
Make VERY SURE to outline the runtime’s benefits:
- Preemptive scheduling (what 99% of the runtimes out there don’t have)
- OTP’s let it crash and get restored way of work
- Supervisors!
- Extremely easy to achieve parallelism and concurrency
Most people just fangirl at the language and a lot of other people are very rightfully not impressed. This decision is only 5-10% about the languages (say because of meta-programming / macros and good libraries). 90-95% of the benefit is the runtime so do your very best to highlight that!
8 Likes
Thank you so much!
I already got the “let it crash” (while clarifying that crash should be isolated and not propagated to the user, ’cause I can easily see how people could misinterpret that without knowing the broader concept) mindset and supervisors covered, but definitely did not mention preemptive scheduling and only briefly touched parallelism.
Actually, might need to first read up on the meaning and implications of preemptive scheduling myself, to cover all of my bases in case people ask questions 
Thank you!
5 Likes
Preemptive scheduling
Not one single OTP Process (what in other programming languages are called actors, green threads, fibers) can affect the latency of the others. The average execution time of any given function should remain mostly the same even under heavy load – a huge selling point IMO. That’s why Phoenix apps on $5 worth of servers can handle 2000+ requests a second (while a Ruby on Rails or Laravel vanilla app can be brought to its knees by 100-200 requests a second).
Parallelism / concurrency
Consider this:
def send_email_batch(list_of_emails) do
# This will receive no more than 100 email addresses
YourMailSender.send_batch_message(list_of_emails)
end
list_of_emails # Supposedly a very big list
|> Stream.chunk(100)
|> Task.async_stream(&send_email_batch/1, timeout: :infinity, max_concurrency: 20)
|> Stream.run()
This will get a big list of emails, break the list into smaller lists of 100 emails each and send each chunk (batch) in parallel, but it never sends more than 20 batches at the same time (the :max_concurrency option of Task.async_stream), e.g. at any given time maximum of 2000 emails are being sent (if we assume this is your email sending provider’s API rate limit and that you want to comply with it).
This extremely transparent parallelism / concurrency is what brought me to Elixir.
6 Likes
Some great thoughts by Dimi and you might also find what Robert wrote in the Erlang Rationale worth a look 
These EF threads might also contain something of use?
Good luck and let us know how you get on 
6 Likes
This video makes a very good work at explaining it with a demo:
Feel free to take some notes on the talk and share it with your colleagues 
4 Likes
@dimitarvp Wow, that’s an amazing write-up! Thank you so much, would it be okay with you if I almost copy-pasted those two points into my presentation? 🙇♂️
@AstonJ @Exadra37 Thank you so much! Will go through all the resources you kindly gathered for me throughout today, and tomorrow should be the big day! Getting kind of nervous
4 Likes
Sure, copy it, I didn’t write it here to make money out of it. I hope my writings help you!
5 Likes
Start with this sentence from A History of Erlang by Joe Armstrong,
“Erlang was designed for writing concurrent programs that “run forever””.
6 Likes
These are all excellent suggestions, but I would suggest you take a few steps back before putting anything in your presentation.
The list of things that Elixir does exceptionally well is so long that you can easily lose people after listing several things they don’t care about.
If you just present them with a set of amazing tools & qualities, it could come across sounding like solutions without problems (none of these solutions are) but with a skeptical eye they can be seen that way.
I would suggest you make a list for yourself of what is currently important to your engineering department. Which are the strengths in your current technology stack that your stakeholders are happy with. Which are the weaknesses or pain points in your current tech stack that Elixir would help you solve. Then see where Elixir shines in those key areas and focus on that.
If they care about programmer productivity, talk about that, if they care about system uptime, talk about that, if they care about server resources, talk about that, if they care about developer engagement, talk about that.
If you have too many things, I would try to focus on things that other languages just can’t do. The kind of things that are enabled by running a million processes on one server, and/or being able to cluster those processes across several servers. For example, Phoenix Channels or LiveView functionality can’t be easily implemented in any other language while maintaining the same strengths of scalability and resource usage.
Another example of a problem where Elixir is extremely difficult to beat, is a server being able to take 10k HTTP requests all at once and just hold on to them while slowly fetching back-end data for each of them. Many other languages are fast, even faster than Elixir, but spinning up 10k separate processes to run each web request in, and to keep them all running at the same time, just isn’t a thing without the Beam. This is also a great example of a problem that people just won’t care about until they run into it, so you need to consider your audience before you try and tell them about it.
6 Likes
Thank you all for your amazing suggestions, they were extremely helpful! 
Since I was presenting to engineers from different branches and different countries without knowing their current projects and pain points (nor their current tech stacks, actually! I think our Bangladesh and Philippines branches are primarily Java-focused, but nearly anything goes in our branches in Japan), I decided to take a very general approach:
- first show them some core concepts and benefits of functional programming,
- following by making a stop at a station called Erlang,
- and finishing the tour by looking at some boring and some interesting parts of Elixir (my reasoning being that I can’t just keep shoving cool features in their faces if they never saw Elixir’s syntax in the first place, so first let’s quickly talk about some boring syntax);
- finally, the last 10 minutes were then focused on Phoenix and how I see Phoenix very differently from existing web frameworks.
If interested, I can share my slides (or maybe slides with the presenter’s notes, would that be better? But they’re quite unpolished and bit personal maybe), or better yet, I might get permission to share full recording tomorrow or early next week.
6 Likes
That sounds super interesting so would be cool if you could share your thoughts (or even start a dedicated thread about Phoenix or web frameworks if you think it might be worth it) 
3 Likes
Sorry, it took me this long to get approval to make the video public! 
Here’s my talk (starts at ~1:29 after being introduced by my team leader), and while I’m happy it convinced some people in my company and their interest in the language peaked, I’d say “please don’t expect too much from the video”
I’ve got no public speaking skills to speak of, I made quite a few mistakes there (including a fairly funny one where I copied @dimitarvp’s comment into my speaker’s notes for inspiration but in the heat of the moment and due to being nervous, I proceeded to read it in full, incl. his last sentence ) and it’s probably just going to be one of those talks that can be categorized as “Elixir fangirling” in the end.
3 Likes