I’m happy to announce RunElixir.com, a free online guide to Elixir. It aims to answer the questions: How can I get started with Elixir?, but also What else is there to learn about Elixir?
I recorded an announcement video with more details here:
TLDW: RunElixir.com is a condensed version of the Elixir docs that aims to give interested developers all they need to get started with Elixir in 30 minutes or so. It is inspired by the Rust by Example online book and the Gleam language tour.
In addition to being a quickstart to Elixir, it will also collect high-level introductions to various Elixir topics to give you an overview of what Elixir has to offer and to explore new topics. For example, you might know about :ets, but do you also know about :persistent_term? Both are useful for keeping state in memory, but you might not hear about them unless somebody tells you about them. That’s what RunElixir tries to do. It will show you what Elixir and Erlang have to offer from a high level.
I will add more topics in the coming weeks, but your feedback would be much appreciated! What do you think about this idea? Do you have any topics that you think should be in the guide? Any feedback is much appreciated
I explain how to use Agents, ets, dets, or persistent_term to store state in your Elixir application. I also added Big-O complexities for ets and persistent_term where possible. Check it out!
Currently I am going through “Lists and Tuples”. I’m not sure if it’s good to have multiple lines in one livebook block and not be possible to evaluate each line on its own… If someone looks at that on a small device, he has to scroll down, up, down, up,… and associate each result to the correct line. Have you already put some thought into this? (Edit: I see now, that you put the number als label therefore. Maybe it’s better to put a short description there? As “get 2nd element”…)
Also, I would mention the Elixir version very soon. I know Elixir doesn’t change much these days, but someone with little experience with Elixir doesn’t know that. Personally, I wouldn’t use a JavaScript, Go or Rust guide if I didn’t know what version it was written for (maybe it’s out of date), so I would mention the version right in the beginning and also that the guide will be close to correct even if the reader’s version is not too far in the future. (Plus a link where to inform you if anything isn’t working anymore → Github?).
Thanks! Yes, I thought about that A LOT unfortunately, that’s the only way I found in which the user can still run the Livebook block and get a response from all function calls. If I create one block per call, the doc becomes too long. I could remove all the IO.inspect calls which I don’t like either and show the response in a comment somehow. That might be better but it’s not great either. If you have a suggestion, please feel free to send a PR
Good work! I am almost a complete newbie at Elixir, so it’s possible my comment is inaccurate but maybe others like me will have a question about this:
Working through the material I reached the Pattern Matching section. Here for (I think) the first time I encountered the “->” operator (is it even an operator? ) . It appears in the fragment
map_empty? = fn
%{} -> true
_ -> false
end
I didn’t know what that meant, so perhaps a bit of explanation there would be good.
Thanks
This is a standard syntax for anonymous function (fn x -> x * 2 end) but here the function has two clauses.
Sidenote: I have no idea where this snippet has been taken from, but the name is extremely misleading, I cannot think of a way to use this function to actually check if the map is empty.
Sidenote 2: there are no operators in Elixir at all.
It’s from the pattern matching section, and it’s actually part of a note exactly about why it doesn’t work, and gives two options for actually determining if the map is empty.
I know what you mean, but it seems like even the Elixir docs use the term “operator”. Erlang also does.
Than you @forestial for the valuable feedback! I’ve updated that section with a better example and added more information for multiple clauses in anonymous functions to the Pattern Matching section
@mudasobwa aren’t things like +, =, |>, <= etc. called operators? For example, the official Elixir docs call |> “the pipe operator”.
Well, it’s all a matter of wording but technically + and company do not differ from functions syntactically or semantically. Moreover, they are indeed functions.
Actually the -> is first mentioned (as @mudasobwa alluded to) in the Anonymous Functions section above, and I’d suggest that a sentence there to explain what it means would also be helpful.
More broadly, it would be helpful to new users if things like this -> had names to be more suggestive of what they do. After looking at this for a while I formed the notion that the -> “injects” the arguments into the function; would it make sense to call this the “injector”? (I suppose that will outrage experienced Elixir users ).
(Javascript seems to use => to mean something similar. There, they call it the “arrow function” which is not a very useful name; it says nothing about what actually happens).
Another comment, again made from my ‘Elixir newbie’ perspective:
The section titled “Recursive Functions” on the “Loops” page is of course extremely important. I think it deserves a bit more explanation to help the new user. I was able to puzzle it out eventually but there is a lot to understand there and I think many would struggle with it. I think that pattern is common in functional languages but much less so in procedural ones, where many new users may be coming from.
As an aside, the defp keyword appears there but it also needs some explanation. In fact it was already used on the “Control Flow” page, but it was not explained there either.
Watched the intro video, as usual very well produced – thanks @PJUllrich!
From watching the intro I feel a bit confused that this site tries to fit two audiences that might be at odds: 1/ short high level intro for newcomers, 2/ collection of guides for more advanced topics like ETS, DETS, community libraries, etc.
What stands out as prominently distinctive is the example-based approach. I appreciate that and I think many other people will too.
If I got it right, the tech stack is the same as the official docs? Did you consider adding to it?
Is there some other thread where adding LiveBook-based examples to the official docs is/was discussed? It could help with discoverability.
Thanks again @PJUllrich for you countless contributions
The section titled “Recursive Functions” on the “Loops” page is of course extremely important. I think it deserves a bit more explanation to help the new user
Thank you @forestial. I added a small explainer to the recursive loop section.
@shishini thank you for that suggestion but until we have an “official” way to install Elixir on Windows, I prefer to link to the official docs on how to install this stuff. I use asdf myself on macOS, so I can monitor if that installer works, but I have no way to check whether e.g. winget continues to work and don’t want to advertise an outdated installation process on RunElixir. I’d rather leave it to the official docs to keep these things up-to-date.
If I got it right, the tech stack is the same as the official docs? Did you consider adding to it?
Yes, @rhcarvalho RunElixir uses the ex_doc but I think it should stay “it’s own thing” for now because it’s an opinionated approach to getting started with Elixir and the official Elixir docs already have a “Getting started” section.
Is there some other thread where adding LiveBook-based examples to the official docs is/was discussed? It could help with discoverability.
Not that I know, but there’s https://notes.club/ and somewhere there’s an awesome GitHub repo will all kinds of Livebook examples. I couldn’t find it quickly though, so if somebody has a link to it, that’d be much appreciated.
Elixir itself provides Windows binaries as well. As does Erlang. As of OTP 27.1 the Windows Erlang installer doesn’t even need admin privileges, which is great!
unfortunately, that’s the only way I found in which the user can still run the Livebook block and get a response from all function calls. If I create one block per call, the doc becomes too long. I could remove all the IO.inspect calls which I don’t like either and show the response in a comment somehow. That might be better but it’s not great either. If you have a suggestion, please feel free to send a PR 
) . It appears in the fragment
For example, the official 
).
