Just me or are most blog posts and youtube tutorials outdated?

You could be right, but when I started learning Elixir, I just downloaded the latest version and got 1.5.2 (I think).

That’s good to hear. If you know of any good ones, please post.

1 Like

Could we talk more about what issues in particular there were? It’s quite interesting to me, since looking from the inside, often one might not see it. In theory the code from 1.0 should compile and work perfectly fine today. There are some new features with each release and one may get some compilation warnings, but the code should work. In general, I’d say I am surprising how stable regarding backwards compatibility Elixir is.

So I wonder if it’s actual problems or rather just caution broght from other languages and platforms that don’t guarantee this kind of backwards compatibility.

Especially when it comes to books, the knowledge contained there definitely doesn’t get outdated with a new version. Especially now with 1.6 which mostly brings improvements in tooling. But also I would say the changes in 1.5 and 1.4 should be mostly covered by going through the changelog in about 15-20 minutes. As I said, I’m keen on hearing “experience reports” with something more concrete - if there are truly some issues, for me it means that the release process should be improved more than anything else.


I have commented on lesson “Elixir Tutorial Part 4 (GenStage)” (
https://goo.gl/nu6qXX). Look for my name, “michele mendel”.

To be fair, I was using v1.6, because of the new formatting functionality.
This may seem like a small thing, but it took me some time to figure this
out. On one hand it was a good exercise, but also somewhat distracting. I
have full respect for people doing tutorials for free, but a payed tutorial
should be more up to date.

After the experience with the above mentioned tutorial, I got reluctant to
try anything older than v1.5, but I may be wrong. I have already paid for
the tutorial on Udemy and will try it out.

I really enjoy Elixir. I am also learning Elm at the same time, and
together they are wonderful languages.




I’m running 1.6.0-rc.0 and using the older way to specify supervisors and workers still seems to work for me with, for example, Ecto. Maybe you just forgot to actually import Supervisor.Spec?

That’s strange, since this is what’s written about it:


NOTE: The functions in this module are deprecated and they do not work with the module-based child specs introduced in Elixir v1.5.

Yes, I saw the note on the site. I think the wording might be misleading in that it makes it seem like this no longer works in general. It does in fact work and pulling the code from the repository (https://github.com/tensor-programming/Elixir-4/, not the one listed in the YouTube description, this YouTube channel and organization is run really badly) you can run it without any issue with v1.6.

A friend once told me that he thought the abstractions introduced for supervisor specs and whatnot in Elixir were a bad idea. I think I brushed it off and said that supervisor specs suck so they should be fixed, but he argued that people would end up not knowing what it is they were doing since everything is hidden away too much and maybe he was right. If we weren’t trying to fix this by making it look like magic, people would learn the ugly way but at least know exactly how it worked.


Hmm, I really hope Elixir is not going down the Java path, with a lot of deprecated code that will still work ten years from now.

On one hand I agree, but just in the previous post I argued for using (and supporting) something that is ~21 years old. The reason is that this specific issue wouldn’t exist if people knew what the supervisor spec was actually generating (previously a tuple with a specification for what a child is and nowadays a map with the same information, with reasonable keys that describe the specification).

Yes, I definitely agree with that. Migrating projects to new version is in my experience very easy, many times it works with no changes at all.

I believe the problem here is that the material does get outdated, since some techniques recommended by learning resources are deprecated.

As I’m just working on Elixir in Action update, I’ve felt this myself. In just three releases, there have been some additions which forced me to do a thorough rewrite of supervisor chapters. In just three versions (1.4-1.6) we’ve got the Registry, new child specs, and DynamicSupervisor, which completely changes the way we manage supervision trees. The old way still works, and that’s great. But I understand if people entering Elixir are frustrated to find that the techniques presented in the material are not recommended anymore.

Just to be clear, I’m happy to see how the language constantly moves forward, and I’m very excited about the mentioned extensions to the language. I was personally advocating the inclusion of Registry for a long time. I definitely hope Elixir will keep that pace and move forward. But the consequence is that the learning material will also grow outdated to some extent.

The best advice I can give to the people just learning Elixir is to start with the official learning guides, as these will always be up to date. And of course, reference docs are IMO very well written.

I agree! I’ve started working on EiA way back around 0.9, when we didn’t even have maps, and I’ve been constantly amazed how well organized and informative the changelog is. This made it very easy for me to migrate the content, as well as Elixir projects I’m working on.


That’s good to know. I will put your book on my reading list.

The main reason I think https://online.pragmaticstudio.com/courses/elixir/ is such an excellent course, is that they start building the program using only spawn and then replacing it with GenServer. You really understand the reason behind the abstractions.

As long as the reason behind the abstraction is clear, I don’t mind if there are different ways to do the same thing. The problem comes up when there seems to be a “wrong” way of doing something, which is usually what deprecated code tells us, and when there is no clear reason which one to use.

Java never seem to get enough of collections, and JavaScript has too many ways to create new objects, including the somewhat unnecessary class. With a given rationale behind each choice, I can make an intelligent decision what to use, and not having to rely on chance.

All code written in earlier Elixir versions should work on more recent Elixir versions. So even if a book was written for Elixir v1.3, everything should work on Elixir v1.5 or v1.6. You may get a deprecation warning but the warning will point you to the proper direction.

I agree it is misleading and in the latest iteration they can even be mixed, I believe. I will update it.


Having a simple function that validates its inputs and returns a data structure is hardly magic. It is pretty much the bread and butter of programming in Elixir.

Sometimes I get the impression people throw the word “magic” around as a quick way to disagree with something without actually describing why or without considering the list of pros and cons that go behind it. For example, when you say X is magic, it can be followed by an explanation that “it is a macro that rewrites the AST” or “it is macro that injects variables” or because “it is a function that relies on side-effects”. This allows everyone to judge how much complexity is actually involved, instead of hiding it all behind “magic”.

Anyway… :slight_smile: we need to remember that when Supervisor.Spec was added to Elixir, the only way to specify a supervision tree in OTP was by using tuples, like this:

{Registry, {Registry, :start_link, [...]}, :permanent, 5000, :worker, [Registry]}

This is not an acceptable API by any measure. A new developer wouldn’t understand what half of those things are, because we don’t even have key names. And most experienced developers would be unable to build such tuples without consulting the docs every time. And if you got something wrong, the error reports were less than ideal.

Since we didn’t want to rewrite supervisors, we had to wrap the validation and creation of those tuples, which led to Supervisor.Spec. Now that OTP itself has moved away from tuples, Elixir went back to mirroring OTP and now prefers the child specification to be specified as a map, but we didn’t have this option back then.


The idea wasn’t to just try to sweep it away. I presented why I thought this may have been harmful to some degree in the very post you quoted and it was also very clear in that very post that I agree with both sides of this:

I think I brushed it off and said that supervisor specs suck so they should be fixed, but he argued that people would end up not knowing what it is they were doing since everything is hidden away too much and maybe he was right.

That’s precisely the API you then go on to criticize and what I referred to in the post after:

The reason is that this specific issue wouldn’t exist if people knew what the supervisor spec was actually generating (previously a tuple with a specification for what a child is and nowadays a map with the same information, with reasonable keys that describe the specification).

If anything, I think I’ve highlighted the trade-offs of hiding the spec tuple behind a curtain, let’s say. It’s not magic, but it’s also something that’s occluded supervisor specs to a lot of people. If they knew the underlying structure of it they’d also understand the replacements and what they can always use under the hood when the replacements are changed/disappear/cause issues for them.

To be clear, I still think abstracting it was the way to go, but I definitely understand why my friend thought it was a bad idea.


Dave Thomas elixir course is the best one I’ve seen so far. I’m halfway through it and I wish there were more of this quality… it leaves out all the annoying fluff and 45 minutes of writing tests with 5 minutes of poorly explained coding. I wish he had more than one course, I’d buy them all.


He’s already started on his second one :003:

Please leave a review in that thread if you haven’t done so already :slight_smile:


This is one of the reasons I started my channel 3 months ago! Dozens of longer-form videos and not out of date.

I have nothing approaching Dave’s level of experience, but it’s a lot of free content and often inspired by actual projects.


I’ve been keeping an eye on your videos and watching alongside other stuff for a while now. I really like the idea of free video courses and you are really helping the Elixir community :slight_smile:


Watched some of your vids recently when I stumbled upon them on YouTube. I was wondering that there were only a few views, as the content is really great! Keep it up. :blush:


Every channel will start out small with only a few views, overtime as more people watch and like the video YouTube’s algo will recommend it to others interested in learning elixir :slight_smile:

1 Like