Genuine question. It has been a long time since I was a beginner programmer. Does all the cutesy "slow introduction" stuff appeal to novice programmers?
I am kind of impatient, so it seems a bit annoying to me.
If I were learning something technical that I am new to, say flying a plane, or biology I would prefer just to get stuck in. I would expect a pedagogical approach of course to easy me into it. But the cutesy stuff would feel like unnecessary slowing me down.
The writing style of "Joy of Elixir" is (I think) inspired by "Learn you some Erlang for great good" [1] and "Learn you a Haskell for great good" [2]. Personally, I like the cutesy style for getting started with a new tool/technology/language, just to know the basics.
The main selling point of Elixir is concurrency. Dave Thomas gives this great example in the second page of his book [3]:
defmodule Parallel do
def pmap(collection, func) do
collection
|> Enum.map(&(Task.async(fn -> func.(&1) end)))
|> Enum.map(&Task.await/1)
end
end
result = Parallel.pmap(1..1000, &(&1 \* &1))
Elixir developers can see the beauty of that snippet. However, for beginners, it can be overwhelming or intimidating. If you want to understand what is going on, you first need to learn about enumerables, map/filter/reduce, lambda functions, capture and pipe operators, spawned processes, tasks, etc. Yes, that is a great example for showing the power of Elixir but if you are a beginner chances are you are looking for something easier (e.g., Joy of Elixir).
Take Nix and NixOS [4] for example. That is an impressive technology and it has a (not cutesy) documentation. But, as a beginner, I feel lost. I rather prefer a cutesy getting-starter tutorial or book.
So, yes, I think there is a niche for developers that want to start with cutesy material. It is just a matter of taste.
The pattern in the example above is a fork/join model of concurrency. Task.async will spawn a new task and return a handle to it, the task will be scheduled and run at some point. Task.await takes that handle and waits for the associated task to complete before continuing and returns its result.
Sometimes you want something to happen, but you don’t want to block whatever you’re doing on that. Think things like sending a welcome email when someone signs up for a new account.
Not much of an Elixir developer but if I saw that snippet in code review I would flag it for readability.
Just because you can write something in 3 lines of code using lots of nesting and anonymous functions and variables doesn’t mean you should. This code would do better if it was longer, the variables had names, and the transforming functions broken out and named.
Disagree, you probably think it's unreadable because you don't know the language and/or concepts in this snippet.
But does that mean we shouldn't, for example, use destructuring in javascript because some devs might not know it.
At some point you have to assume a common ground of knowledge, and that common ground in Elixir is somewhat different than in algol derived OOP mainstream.
I never quite understand this mentality that many engineers have.
Instead of taking advantage of advanced language features and teach them to people, we more often than not create rules to avoid using them because "someone else won't understand it".
The important thing to realise is that the dot operator is used to access functions grouped into modules (or even invoke anonymous functions) rather than invoke methods on an object. Because Elixir being a functional language, the central operation is invoking functions on data and passing the results to other functions, rather than calling methods on objects.
From this understanding you can just grok from the code that this is a program that takes a list of numbers and squares them concurrently, in the process using your computer’s parallel processing hardware. And as this is a high level language you can create concurrent workloads with minimal implementation knowledge.
Even if you come from C family of languages where the & denotes something to do with address, you’ll realise the way Elixir uses it is not far away from that, but without the added tediousness of memory management. So elixir builds upon common conventions.
Some things like Enum may confuse a Java programmer. It’s Elixir speak for enumerable data rather than a collection of constants. And of course the pipe operator is different.
It’s certainly not easy to see this and write your own code and offer suggestions. But for a mildly experienced programmer who has already adopted the mindset that code is just a bunch of instructions presented in non-linear fashion, like in a legal document, this is an approachable intro to start asking questions from. First of all one should be willing to read a couple of pages from some book on what are anonymous functions and what is the syntax like for that etc.
The task is a bit more difficult for people who tend to look at code with a more inflexible viewpoint ie junior developers.
I'm not an Elixir beginner but all those ampersands means that either one writes that kind of code everyday or one won't understand what it does when coming back next month. Use names, not shortcuts.
You never know in advance who will work on code in a large project, how expert in that language and under which time pressure. I prefer to stick to a common ground between major languages that lets (say) someone that knows only JavaScript at least read the code and understand what it does. If it means that I have to write a few more lines or type more characters in variable and function names, I do it. I never appreciate where languages and developers want to do smart things. Boring and plain is much safer.
If you find yourself in such conditions that JS developers unable to google ‶elixir ampersand″ are the ones reviewing your code often enough for it to be a constraint while developing, your company has much deeper problems far up the command chain.
The ampersand syntax is extremely common in Elixir code - absolutely the kind of thing you'd write every day. If your Elixir developers find the ampersand stuff hard to read, you've hired the wrong Elixir developers.
I very much didn't like the ampersands the first couple of years looking at Elixir code. I think I've gotten used to it now. Looking at my own code, it's definitely more terse than it used to be. I do usually move such things into a separately named method, or a lambda that's assigned to an appropriate named variable.
I do agree with you though, when you get a screenful of ampersands that contains non-trivial business logic - it's not great.
As a guy who swears by Elixir, I completely support you.
I'd wish somebody to sell Elixir to me with transparent parallelism, demonstrating that it's literally 2-3 extra lines of code (compared to other languages where the extra code you have to write is significant). Pepper it with pattern matching and preemptive concurrency and I'm sold in 5 minutes.
I was already fascinated by Elixir, but this video drove the nail home. It's a great presentation and I don't think I have watched any conference talks (on YouTube) without taking a break except this one.
To me, I think Elixir's technical merits are well documented. If they appeal to you, you're welcome to dive into the deep end any time. No one needs to write you a tutorial for you to start using plug and cowboy - you can just do it.
On the other hand, if you're not quite there, or the technical qualities are not that impressive for your use case - the thing that may draw you into a language is how it encourages you to approach problems. How it lets you describe what you are expecting, and what to do when you are surprised. How to navigate data structures. For that latter category of person - I think the slow, cutesy approach makes a lot of sense. The goal is to fascinate and then seduce. No harm if you're not in the mood - but one day, a cutesy introduction may catch your eye. We all have different tastes.
I'm responding because when I found this a while ago and I felt similar to you, but mostly I felt it was weird coming from Ryan Bigg. Maybe I'm giving him too much credit for the awesomess that is the Rails guides, but I don't think I am...
What I did get from these Elixir guides (at least in my head) is that Ryan is always just being Ryan: a particularly great, proficient, and prolific writer of documentation. When he was writing about Rails, he was in his wheelhouse and he feckin' killed it and appealed to the exact right audience. When he wrote about Elixir, it was good but I felt he was out of his comfort zone and trying a new tone (the one you describe). This is purely my speculation but ya... again, just responding since this comment both made me a bit annoyed that you'd even bring this up (of course you have every right to), and struck a pretty hard chord with me.......and I'm tired and a little tipsy.
Anyway, massive respect to Ryan. I feel like he is one of the, if not The, unsung hero of Rails' popularity. The Rails guides are really special.
And we should be clear... it's not that Dave Thomas doesn't use humor in his courses or books to lighten what can be bit tedious. His humor tends not to be condescending or overbearing which is why I think it succeeds. Just good touches of lightness here and there.
Maybe they could provide a kind of base documentation to GPT-3 and then have it generate lots of tutorials in different styles - “cutesy”, “advanced”, “continued education”, etc. (I meant this to be funny but I’d bet someone has considered it even more seriously.)
I recently onboarded 2 JR developers who didn't know Elixir. I purchased pragmatic's video course for them, but they both liked the Joy of Elixir better.
In contrast, the seniors liked the pragmatic training better.
Last year, I needed to build an MQTT-HTTP bridge. Lots of concurrent long lived stateful connections.
Elixir’s “we ain’t never seen a thread count that scared us” attitude was intriguing. So I took a chance.
If you want a paradigm shift for a change, Elixir is fun. It will probably be a bumpier uphill climb than your run-of-the-mill-syntax-populism-mainstream languages that vie for your engagement now days. I had never realized before how much of my code in the Algol-wearing-the-ObjectOriented-vestry[1] languages is just there to navigate to code that does something. Half of the code is just to determine where the code goes next. Go around? Leave now? This way or that? How bout a three way! Goto! Jump!
Elixir doesn’t solve these problems in the traditional way, and it kind of messes with your brain. A bit like the Grinch standing atop Mount Crumpit: “They code it without loops, without (traditional) if blocks, without switches. And even without return statements, of all things!”
The Elixir slack group is one of my favorite. They helped me out a lot. The Dave Thomas book was OK; I haven’t tried any others yet.
The system runs pretty solid. It was a 6 month or so project. It uses OpenAPI, Bandit (http server), Finch (send http), and Tortoise (MQTT). Other than the library names, which I think the community draws out of a magic and random hat somewhere, it’s pretty straightforward. It’s the least of the worries in our petty varied stack. And it’s lived up to my hopes regarding its threading story.
If there’s a thing that worries me about Elixir, it is that—like the Ruby/Rails community that it draws a lot of individuals from—it’s sort of a one trick pony right now. It’s a backend web tech. That’s obviously where the money is. I just don’t/can’t use it for a desktop app (realistically), or mobile development, or front end web, or command line tools (yes there’s the escript thing, but I don’t see a big execute-in-Elixir movement) or embedded (yes there’s Nerves). All the job posts I see in the Elixir slack channel are for web stuff. I’d guess 95% equate Elixir and Phoenix together.
Still, if someone offered me a job furthering the use of Elixir in something other than “come help us change the world with yet another novel web service”, I’d probably be really tempted.
-1. My dis her is not OO itself, but on the crappy job many mainstream languages have done of executing it. A sort of “I invented the term OO and this isn’t what I had in mind” channeling.
> it’s sort of a one trick pony right now. It’s a backend web tech. That’s obviously where the money is.
In terms of tech, I wouldn’t classify it as one trick pony. You can also build distributed systems (Erlang), high-end embedded systems (Nerves), data pipelines (Broadway), audio/video streams (Membrane) and more coming. :)
However, you are right that most of the money is on backend tech. But I wonder how much of it is a reflection of the market themselves? If backend web is 10-100x bigger than distsys, then we shouldn’t expect proportions to change drastically.
Data pipelines is one of the areas where we can grow, but data pipelines are only part of a data stack, so it is a fragmented offering. The hope is that with efforts such as Explorer and Nx, we can grow more into this space.
Edit: on the positive side, the recent efforts in data, ML, and native clients are all sponsored by primarily backend web companies. But we all know there is a long road between technical implementation and adoption.
> It will probably be a bumpier uphill climb than your run-of-the-mill-syntax-populism-mainstream languages that vie for your engagement now days.
What makes you believe that? IMO, the immutability and pattern matching eliminate a huge class of common frustrations that beginners usually have with the most popular half dozen programming languages.
I think all of them, especially JavaScript, PHP and C are harder to learn than Elixir, unless you already know another similar language.
> What makes you believe that? IMO, the immutability and pattern matching eliminate a huge class of common frustrations that beginners usually have with the most popular half dozen programming languages.
I think moany devs really know a similar language already, when it comes to Java, Javascript, etc. But most have never been exposed to a functional language like Ex
Yeah, I'd agree with that. If you're not a complete beginner and you're learning a 2nd language, it's definitely easier to learn one that's nearly the same as the one you already know.
The Pragmatic Studio courses are great - I highly recommend them.
If you're coming to Elixir from a Rails background and you want to learn Phoenix,
I think the course Phoenix on Rails is good (although I'm biased, since I created it). http://phoenixonrails.com
I like the BEAM and philosophy of Elixir, but there's just...no static typing. As someone coming from TypeScript and Rust, this makes it a very hard sell when I can write web servers with either language just fine and have the compiler catch the many errors I've made. I suppose there is Gleam but the more esoteric the language (or technology in general), the harder it is to debug, so I don't want to be stuck with that kind of situation for a production environment.
It's the chocolate ice cream vs vanilla ice cream argument. There isn't an accounting for taste. If static typing if your thing it's never going to taste the right way to you.
I'm just the opposite, I greatly appreciate dynamic languages and if Elixir had been static I wouldn't be using it. That's probably from my Ruby experiences. My own stylistic tastes change from year to year but that's where my current taste is set. I keep seeing dynamic languages add type hints or bolt on static checkers. I personally just don't get it. I'd much rather just use Rust, Crystal, Golang, Java or Haskell if that's what I wanted.
> I keep seeing dynamic languages add type hints or bolt on static checkers. I personally just don't get it.
I believe it's because at scale, like Ruby at Stripe or Shopify or GitHub, it gets very difficult to change things without other stuff breaking, which a static type system ameliorates. Personally that's why I like static typing over dynamic, as I've initially started with dynamic languages like Python and JS and moved over to static variants because of all the frustrating mistakes I made which a compiler could have caught.
For me at least, I realized that a lot of what I liked about static typing was, one way or another, pattern matching. When you match on type, all of a sudden it's explicit in the code what you're working with. It doesn't capture anywhere near 100% of the value of static typing, but in effect you do wind up with functions which dispatch once and component functions in the interior that don't need to worry about getting passed something nutty. So the library boundary will take lots of logically equivalent inputs, but the output will pretty much always be regular.
agreed. while not a deal breaker for me, i just wish the type hinting system is a more integrated part of the language rather than the awkward annotation-like system that it is right now
While most of these resources could be still valuable, to avoid buyer's remorse, pay attention to the publishing dates, as some of them are very dated:
2022 - $18.95 - Build a Weather Station with Elixir and Nerves
2022 - $18.95 - Build a Binary Clock with Elixir and Nerves
2022 - $15.00 - Programmer Passport: OTP
2022 - $15.00 - Programmer Passport: Elixir
2021 - $27.95 - Testing Elixir
2021 - $26.95 - Concurrent Data Processing in Elixir
2021 - $22.95 - Genetic Algorithms in Elixir
2020 - $27.95 - Real-Time Phoenix
2019 - $26.95 - Programming Ecto
2019 - $28.95 - Programming Phoenix 1.4 (Current version is 1.6)
2019 - $26.95 - Property-Based Testing with PropEr, Erlang, and Elixir
2019 - $24.95 - Designing Elixir Systems with OTP
2018 - $27.95 - Programming Elixir 1.6 (Current version is 1.14)
2018 - $27.95 - Craft GraphQL APIs in Elixir with Absinthe
2018 - $26.95 - Functional Web Development with Elixir, OTP, and Phoenix
2018 - $24.95 - Learn Functional Programming with Elixir
2018 - $24.95 - Adopting Elixir
2015 - $11.00 - Metaprogramming Elixir
2014 - $27.95 - Seven More Languages in Seven Weeks
I love Elixir and I bet the last 6.5 years of my career on it (and Rust) and I don't regret it for a minute.
And exactly as a guy like that, I would prefer intros be much more technical, cold, even robotic -- and elevator-pitch-like. Yes, even those in books, although I'll admit that it's expected that you have sought such an intro by yourself before reading the book. Still, if I was writing a book I'd include an elevator pitch right at the start.
I attended EuRoKo 2016 where Jose Valim made a lightning talk about Elixir. He did sell Elixir to me in 10 minutes indeed, for which I am extremely grateful. He showed right there and then how you can have two nodes (computers, VMs, even two separate shells on the same machine) distribute work to each other. Demo-ed a few other features and I got immediately interested.
Furthermore, trying to act cute or informal in such a material is a turn off for me. Let's keep it professional, folks.
---
Even with that, I recommend Elixir to anyone who doesn't need beastly speed in their programs and for whom the lack of strict static typing is not a problem. It offers a number of advantages that 99% of all other languages out there don't -- like almost completely transparent parallelization, preemptive scheduling and fault tolerance.
> He did sell Elixir to me in 10 minutes indeed, for which I am extremely grateful.
Could you elaborate on this more?
Elixir’s an interesting beast. On one hand, it’s just Erlang by another name. And yet Elixir also brings some merits of its own. How much of Jose’s pitch was for Elixir-the-alter-Erlang? And how much was for something other than Erlang?
Well I have no experience in Erlang -- only checked it out a few times and I like that Elixir removes some of the more manual aspects of Erlang (like manually exporting functions from a module).
So, why Elixir (and partially why Erlang):
- (Erlang + Elixir) Transparent parallelism. This is not a joke. You're a function + closure away from multiplexing stuff on all your CPU cores (or even more e.g. it's OK to have a limit of a worker pool be 100+ for e.g. network workers).
- (Elixir-specific) A lot of tools around fault tolerance and supervision trees. You can have static hierarchies and you can have dynamic ones (spawn children, have them do work, have them shut down). You can register green threads by name and enforce limits on how many of them are around, you can also load-balance work between several nodes.
- (Elixir-specific) Macros: you can generate code at compile-time which is extremely useful if you want to limit the set of values that you'd work with at run-time. Example: the Unicode functionality of Elixir is actually generated by macros that basically do a `for` loop of all codepoints / graphemes and utilizes pattern-matching on each value. Super tedious by hand, extremely trivial with macros / code-generation. Useful in many other scenarios as well e.g. you can inject code in a receiver module with macros.
- (Erlang + Elixir) Pattern matching. While the languages sadly have no static strong typing, pattern-matching helps a ton e.g. interacting with remote APIs you can match on several expected responses and report everything else to your monitoring system, leading to very effective and prototype-friendly development process.
- (Elixir-specific I think) Flow control. You can basically make pipes of functions exactly like all the classic UNIX tools allow you to. I've heard devs scoff at that a good amount of times... same devs were like "OMG how did I live without this so far?!" a few days later. :D It makes for extremely elegant and readable code that allows near-instant onboarding (or reminding oneself of the code they wrote a while ago).
- (Erlang + Elixir) Built-in in-memory cache. The ability to not care about Redis / memcached is a much bigger deal than many suspect. Granted it's a single-node only but honestly? Never mattered in my practice.
---
There are others but this comment became huge already. Main selling point for me as a senior backender and aspiring sysadmin is the extremely easy parallelism and very terse code (that's owed by the piping mechanism of Elixir). The ability to structure your app as a tree of supevisors and workers (that get auto-restarted on failure nonetheless) is a very close third.
Elixir absolutely isn't a silver bullet -- f.ex. it sucks for CLI apps because the VM takes no less than 0.5s to start -- but for a ton of server apps it's up there in the top 5-10 with Rust and Golang.
> - (Elixir-specific) A lot of tools around fault tolerance and supervision trees. You can have static hierarchies and you can have dynamic ones (spawn children, have them do work, have them shut down). You can register green threads by name and enforce limits on how many of them are around, you can also load-balance work between several nodes.
Maybe Elixir adds some tooling, but supervision trees comes from its Erlang/OTP heritage.
I know that OTP is the primitive below but Elixir adds many interesting and useful tools on top e.g. DynamicSupervisor and even a partitioned supervisor (executing tasks among several nodes).
It basically makes OTP even better by building several useful and often needed real-world tools on top of it.
This isn't an argument in bad faith or anything but if all this is so good why is Elixir not more popular? If it's basically Ruby on Erlang (which is what it feels like), you'd think it would've been trivial to retool a rails project to it and take advantage of this insane benefit. Instead the big switch was first to Scala (because of Twitter) and then Python (Dropbox et al.).
But yet here we are. Python is absolutely dominant in web and ML stuff. C is still one of the most popular languages to date. Elixir and Rust barely break top 50. We can't say people don't know about it. Surely if it was insanely powerful Google, Facebook, etc or some huge popular open source project would prove it's utility.
Why isn't it more popular? I ask this, because I have a hard time staking any project I make or work I do on languages that are always sold as extremely powerful but end up being a niche that has been memed into popularity (Rust falls in this category).
Functional programming is and has been, getting more popular, but I think it's hard to argue that it doesn't impact language uptake. Popularity is hard to judge as for every article about it, say 50 people bookmark it to read later, 10 read it and 1 try it, and outside of that there are 10,000 devs who never even clicked the link. That ratio isn't as bright as it appears initially. (1)
I also think the deployment story was a bit muddy with Elixir/Phoenix initially, with a few speed bumps.
Now Phoenix has a "generate dockerfile" command, as well as more explicit tooling around configuring releases, which I think is a good move.
Also it's easy to miss that when you build an Erlang/Elixir release (on the same architecture as your target AFAIK) you actually do get a transportable package (not a single binary) that ships the BEAM runtime etc, so you can actually just rsync the dir somewhere and run it if you want. Deployment even outside of containers is actually pretty easy. I think this is actually undersold by the documentation/community. It's surely no single-binary-multi-arch Go story, but it's easily done.
Personally I think it's 110% worth it.
Anecdotally, Did people say the same thing about python somewhere in it's 30 year span? "If it's so good why is perl cgi still so popular", "It wont ever be as fast as C", etc.
Similarly, Rails came out at a time where webframeworks were ... Symphony? Webforms? None really had the wow that Rails had, but it's not uncommon now so unseating it is a larger task?
1. I think probably Haskell, Clojure and F# probably have the widest "name a functional language" penetration and they all have some baggage. Haskell, IMO most known by osmosis, has obscure syntax and terms, Clojure (probably known of if you write Java) has (what some would term) the dreaded parenthesis-itis and F# has the C#/windows history. Probably some self-biasing here but I think many programmers first exposure will be via Haskell because that's what sticks in your mind as "oh yeah, people say that's cool", then repeatedly bounce off it's pretty dense syntax, terminology and type/side-effect strictness.
I'd wager Twitter switched to Scala instead of Elixir because it existed when they were moving away from Ruby and Elixir didn't. Maybe they still would have if Elixir had existed, but it didn't so we can't know.
And Elixir is not "basically Ruby on Erlang". It adopts some Ruby stylings and Ruby's metaprogramming habits, but the language and underlying libraries are quite a bit different. If for no other reason than Elixir is not an OO language and Ruby is (and heavily depends on its OO model for many things). "trivial" is probably a word most of us need to excise from our vocabularies, translating Ruby -> Elixir may not be the hardest thing in the world, but it's not trivial.
Really, it's not. I don't know how it acquired this reputation if not for using begin/end instead of {}, but it has no more similarities to Ruby than e.g. Perl or Python.
elixir is (was?) very parochial. for a long time it didn't fit neatly in the same shaped box as comparable applications written in ruby or python or java or whatever. part of this was technical (it's a compiled language without any of the effort c or java got in packaging and distribution so operations were complicated when compared to mainstream languages) and part of this was cultural (the infamous 'you don't need x if you use elixir' testimonials) but it combined to scare people who weren't interested in being elixir enthusiasts away. there was definitely a sort of stepford wives vibe around the community where people who just wanted to know how to use elixir to read some data from kafka or redis or deploy an http api or whatever were met with scolding and admonishment for not embracing elixir and eschewing everything they knew. things are definitely better now but i think the damage was done. elixir has a reputation now for being an outsider language
i also think elixir was hurt early by overselling of erlang and the erlang vm. a lot of the "groundbreaking" technology in the erlang vm was groundbreaking but in 1996 not post 2015. even now you can see people talking about how elixir makes parallel programming trivial when it's more or less trivial in all languages now (albeit via libraries or extensions sometimes and not natively). elixir's implementation is quite crude in comparison to some of it's competitors. the same goes for the "seamless distribution" that erlang/elixir proponents talk up. it's just a fully peered tcp mesh and a very simple binary encoding with a tiny rpc framework on top. it's something you could replicate in any language in a weekend (but you probably wouldn't bother. it's not very useful in a modern context). the promise very rarely delivered and people went back to more familiar languages
i think elixir had a brief window to get popular when go was still in it's infancy and nodejs was all written callback style pre async/await and java.util.concurrent was considered arcane knowledge but it failed to get a big enough community that could sustain it once go and nodejs and java got almost as good at concurrency as it was and didn't expect you to forget half of everything you knew about building and operating software. without a clear technical advantage people preferred the familiar
> the erlang vm was groundbreaking but in 1996 not post 2015. even now you can see people talking about how elixir makes parallel programming trivial when it's more or less trivial in all languages now
I have to strongly disagree with this argument. :)
It borders on “all languages are Turing complete, therefore they are equivalent”, but the truth is that the idioms a language highlights make a huge impact on the software we write.
For example, take immutability and concurrency. Making concurrency first class (not an extension), makes you think about concurrency first and you are usually better positioned to deal with Amdahl’s law (i.e. you can use all cores more efficiently).
When it comes to distribution, the same abstraction is used by both concurrency and distribution, which is more accessible, easier to test, etc. You get a unified model that is more than bytes over a socket, it includes dispatching to Erlang processes, entity monitoring and naming, etc.
Thats not even mentioning other features that come from Erlang processes, such as fault tolerance, preemptive scheduling, and instrumentation.
The only confusion - and perhaps what I would have done differently - is that many people equated Erlang distribution to RPC, and that’s something we should have made clearer from day one. Still, I would prefer any language that makes concurrency first class (such as Erlang, Clojure, Go), than one that doesn’t, and there are very few languages that make both concurrency and distribution first class. Personally, if a language doesn’t allow one to transparently multiplex on both IO and CPU, such as Node, then it does not have a good concurrency story.
i don't disagree with you that writing concurrent and parallel programs in erlang/elixir is nicer than in nodejs or go or java. erlang picked a nice set of primitives and elixir extended that with some very good apis. i don't even disagree that language idioms influence software architecture and that elixir and erlang are particularly strong here -- particularly considering otp. however, i just don't think elixir/erlang's concurrency/parallelism story is as important now as it was when erlang was first getting attention for it
at that time the concurrency story in most languages was terrible. non blocking i/o was rare. truly parallel programming was esoteric. that's not the case today though. i am not a huge fan of go but it's undeniable that it has a strong concurrency story AND a strong parallelism story. java has nio and better libraries for concurrent and parallel than it did 10 years ago. even nodejs (which was always the equal of erlang when it came to non blocking i/o) has a very straightforward and fairly efficient worker api for doing parallel computation. languages like rust and swift and julia were born with compelling concurrency and parallelism features
elixir still beats out ruby and python (although python is getting close) but people using ruby and python today largely don't care about these things. they know the limitations and they accept them. if they didn't they have a wealth of languages to pick from
elixir/erlang no longer occupy a unique niche. the other languages have caught up and offer "good enough" libraries and apis. they also bring much to the table that erlang/elixir don't. elixir may lead in concurrent programming but users choose languages that lead in community, ecosystem, compatibility, commercial appeal, etc. for elixir to compete with go, node, java, python it needs (or needed) to offer more
(i say all this as someone who really wishes erlang had 'won'. it's by far my favorite language when you consider solely the syntax and semantics of the code itself. pattern matching should be ubiquitous in modern languages. data should be immutable, full stop. i'd rather write a foldl than a for loop. it didn't win though and the erlang vm is roughly identical today to the erlang vm i was using in 2012 (this isn't to say it hasn't seen improvement but the improvement has been incremental and modest). the ecosystem moves at a glacial pace compared to that of node or go or even a relatively unpopular language like rust or julia)
Agreed that the concurrency gap has narrowed in certain cases or either people don’t care, but I have always seen concurrency/distribution as “enablers”.
You can have the best concurrency story in the world, but if you don’t have good tooling or you don’t focus on the DX, then people will just leave (or perhaps not even start).
Concurrency/distribution is what allows Phoenix to be a real-time, productive, and scalable web framework on its own.
Nerves rely on fault tolerance to bring sanity to embedded systems.
And so on.
In turn those are led by teams who saw the language features and noticed they addressed many issues they were struggling with in other platforms.
But at the end of the day, for languages like Elixir, the frameworks and tools are much better equipped to attract developers than “raw” language features.
PS: disagree on the Erlang VM bit. JIT, dirty NIFs, and maps immediately come to the top of my head as big and important changes in the last 10 years. There have been many usability focused changes in the last 2 years too, in error messages, the shell (upcoming), etc.
Elixir has tradeoffs that many languages refuse to do, like green-threads (from Erlang), that enables you to do many cool things with the concurrency / parallelism / distributed computing bits (and there is a whole ecosystem around these tradeoffs).
But the selling point of Elixir for me is the quality of life for the dev, the docs and tooling are amazing, the community is very focused, the language itself is easy to read and extend (with the powerful macro system) and the pattern match system, is one of those things I wish every language had.
elixir's strength is really the dev experience, agreed. i think if the community had leaned harder into that aspect and less on the 'whole new paradigm' aspect of the language it would have been more successful. people want to do the same thing they are doing now but in a more pleasant way. very few people want a revolution
we had a third party integration taht required creating a websocket connection for each customer.
Using elixir, all I had to do was hookin hoard, write a genserver and hoard registry. It took about a day without knowing how to do it beforehand. Out of the box it clusters these process accross several machines and handles failover and crash recovery.
yea, try doing that in another language. where else is doing that trivial? Elixir doesn't just handle multicore. it handles multi machine parallelism with ease
> i also think elixir was hurt early by overselling of erlang and the erlang vm.
I remember when this was popular. I picked up erlang myself in the craze and then dropped it. As for the outsider language I think this is why Haskell suffers as well. The community is really not great and it's small enough you tend to run into the same kind of person. The entire community is filled with zealots and you're a heretic if you just want to get things done. I didn't realize elixirs community was the same. Thanks for the insights.
> I didn't realize elixirs community was the same.
This can't be further from the truth. ElixirForum is extremely welcoming. Please don't take the word of one person as a fact just because it seems to confirm a bias about Haskell.
Go and check for yourself. Elixir's community is everything else but elitist or looking down on people.
At a high level, starting with "what is a variable" and then going to "now we're talking about maps" seems like it misses some important pedagogical context. If the reader is really unaware of what a variable is, they are probably going to want to learn about things like if statements and functions to understand the value of variables before they start moving on to data structures. Talking about the structure of data only makes sense once you have an understanding of the data you want to structure. For a reader still grappling with programming, I could anticipate this chapter order to be unnecessarily challenging.
But, overall, good work! I think the playful tone makes the technical content more easily digestible, and this is certainly better than having no book on Elixir. I would just focus on ordering the content in a way that lets concepts gradually interact, rather than having them be completely separate.
I do not think Elixir is a good fit for learning programming for the first time. On the other hand, I considered that "Joy of Elixir" is suitable for people that have programmed in other languages, like Python. Therefore, the gap between "what is a variable" and "maps" is not that big.
I recently had to deal with Elixir for my very first time. All I wanted was to dump a db from the ErlangVMs built-in mnesia, and it was so awful if you only know SQL, Firebase and friends. Took me and a friend over two hours to find out that you can only read and restore a mnesia dump if the user@node is 1:1 the same as the original.
I most likely won’t touch it again except if I get a job at some telecommunication provider. The experience was too awful.
I'm sorry to hear you got frustrated with this task, but to be honest, I don't think it would be representative of how it feels working with Elixir or Erlang. It's like sitting down with zero experience to an IBM mainframe and trying to accomplish some routine administration task, setting up mandatory password rotation policy or whatever. It'd feel frustrating and difficult for sure, but it doesn't tell mutch about the mainframe. Especially since it isn't even a design goal for it to feel similar to the Windows or Mac OS your familiar with.
Your frustration is understandable, but if you end up in the same spot again...
You're not really expected to copy a mnesia dump to another node that way, the expectation is you would add the other node to the dist cluster, then add that dist connected node to the shared mnesia schema (each node can only be in one mnesia schema, but you can have multiple schemas in your dist cluster), and then add table copies for the tables you want, with the storage you want on that mode. You could probably fiddle with the schema directly before starting mnesia to make it work though.
That aside, the data files are accessible via the underlying storage modules, disc_only_copies tables use dets and have .DAT extensions (you'll likely have schema.DAT), and disc_copies use disk log and you'll have .DCD and probably .DCL, LATEST.LOG and PREVIOUS.LOG may exist as well.
Well, it was an old database and we actually just wanted to browse the records to see if there is anything important in them. If I had an old sql backup laying around and want to check whether we will need any of this data in the future the experience is much more straight forward.
The path of mnesia was not so easy and intuitive. :X
Who the heck is using mnesia? I've never used an elixir codebase that uses it, and it's (I believe) considered to "not be best practices".. not the least of which is because it's well known that mnesia can lose data irrecoverably.
People say a lot of stuff about mnesia, but it worked pretty well when I was at WhatsApp. We had some patches as mnesia wasn't tuned for the load we gave it, but it was pretty amenable. I don't recall any data loss issues that were mnesia's fault; maybe sometimes we had too much data to properly dump to disk and we chose to truncate files and hope things would work out, and when they didn't data was lost; mnesia may be a contributing factor, but lots of databases do bad things when you write more data than your disk can hold. We did a lot of things that fell outside of 'best practices' though: no transactions, dirty reads and writes, for many years rejoining after netsplits without reconciliation, disabling database dumps sometimes and cowboy operations schemes to try to resume normal operations afterwards despite having insufficient space, etc.
Having data in the same process as the software that manages it is immensely powerful and it would be foolish to give that up when your data fits the model available.
I am kind of impatient, so it seems a bit annoying to me.
If I were learning something technical that I am new to, say flying a plane, or biology I would prefer just to get stuck in. I would expect a pedagogical approach of course to easy me into it. But the cutesy stuff would feel like unnecessary slowing me down.