Ruby vs. Elixir - Projects & People edition

I haven’t been writing as much these days because I was super busy preparing two talks for two very different conferences at the same time. The first was RailsConf, and the second was, and both of these happened just 5 days apart from each other. For the second time in 12 months, I’ve had the opportunity to attend two very different conferences just a couple days apart from each other. But despite the differences, there were also a lot of similarities. Let’s start there first.

“Where are we going?”

The one question I heard more of at both RailsConf and was about the future. At RailsConf there was discussion over whether the framework is now complete or not, whether Ruby is dying (which is ridiculous, by the way), and just generally what’s next for Ruby and Rails. There’s a lot of apprehension from the hundreds of new developers just joining the community as to whether or not their jobs will be there in 2 years or so, and that apprehension is complimented by some more senior developers looking for their next challenge.

Without some cool new “thing” to latch on to, folks are feeling like there isn’t the same forward motion and excitement that there has been in the past. Frankly, I think we really need Ruby 3 to come sooner rather than later, not for any technical reasons, but for a marketing and enthusiasm bump for Ruby and Rails. There wasn’t an obvious answer to this question that I saw other than to “keep up the good work,” and I can see how that can be a bummer for developers of all experience levels.

And then on the Elixir side, folks were asking the same question but for very different reasons. José mentioned in his keynote that the language was now stable, and that from here on out there shouldn’t really be many breaking changes. And so, the logical question now is “what’s next?” There were a few common responses that I heard: developing the ecosystem (especially with additional tooling), and evangelizing the technology to bring more developers and companies into the fold. Both of these things have a good long way to go, but this also leads us to our next big difference, and that’s what’s being built by these two communities.

Hammers & Lasers

When I was talking to the many people who had Elixir applications in production at, they were all incredibly interesting applications. There wasn’t a single person I met who had a normal ol’ CRUD app in production. There were, however, people building cool phone systems (VoiceLayer), complicated high-concurrency multi-user authentication tooling (Square Enix), blazingly fast high throughput content delivery systems (Bleacher Report), self driving cars (EasyMile), and multi-language live coding web applications (NextJournal).

Meanwhile, many Rails apps are - as Justin Searls said in his keynote at RailsConf - spreadsheets on the internet. That’s most of what I write these days, and that’s really what Rails excels at. And, like one of my favorite talks at RailsConf said, the only thing keeping you from having a simple CRUD application is typically just your imagination. In general, the applications that many Rails developers build aren’t things that require anything really crazy. Still for many Rails devs, a front end JavaScript framework is considered kinda crazy.

So, what people are building with these languages is another way in which these communities differ. Ruby has carved out a really good market for itself, and as I’ve written before, DHH is a master at marketing. Most web apps are simple things, and Rails is really good at that. It’s the hammer of web programming - omnipresent, reliable, simple, and easy. Elixir, meanwhile, is there to solve the problems that nothing else can solve. It’s like some finely tuned laser that excites just the right kind of atom in some crazy experiment. Definitely not your everyday tool.

The closest thing I see to overlap between these two markets are in those extremely rare cases where some application really takes off and needs to “scale”, like in the case of Bleacher Report. There may come a time when there is enough of an ecosystem and a developer market in Elixir that companies can optimize for the chance of hitting the bigtime by choosing Elixir from the get go. The question is if, one day, that laser becomes cheap enough and easy enough to use so you can also use it to hit things, making the hammer irrelevant.

Doctors & Dropouts

So, there was another related difference to what people are building, and that’s the people doing the building. At RailsConf, the majority of attendees were attending their very first RailsConf. And of those, a huge number had less than 2 years of experience in the field. Ruby is still very much a beginner friendly language, not just because of the language itself, but again because of the community around the language.

There are dozens of bootcamps teaching Ruby and tons of great resources for self-taught programmers to learn Ruby as their first language. It’s also an exceedingly warm and welcoming community, with a lot of work going into inclusivity and making things easy for beginners. This has also led to the Ruby community being one of the more diverse communities in programming.

On the other hand, I met no less than five current or former Computer Science professors at Several others had Phds or MS degrees and have studied really serious parts of CS in great detail. Many of the folks there also had over 10 years of experience in the field. No disrespect here, but there was significantly more grey hair at! At RailsConf I felt like a veteren, but at I felt like an novice. That’s not because anyone was looking down on me or mistreating me - I was just in awe at the amount of knowledge and experience that this community posesses.

This led me to question another thing - maybe the apps that folks are writing in Elixir are complicated because the people writing them are interested in complicated things? There’s an interesting chicken and egg problem here, and more thought about this could yield some interesting ideas about how to shape the future of Elixir and the applications that are written in it.

There is certainly at present a lack of diversity in the Elixir community (in many ways), but I think this one might be driving the future of the language more than many others. If the users of a language are all solving the same level of problems, the basic infrastructure for those simpler problems will never be developed. We’ll have, for example, really great bindings for machine learning platforms before we have a really great application to detect security vulnerabilities in web apps. I even met one person who said they were interested in using Phoenix for a good ol’ CRUD app, but their security folks wouldn’t let them because of the lack of a tool like Brakeman in Elixir.

So, what comes first? The people building the tools for web apps, or the web apps from which these libraries are eventually extracted? My personal belief is that the tooling and ecosystem needs to be there first to attract potential users, which is why my focus has been, and will continue to be, developing these parts of the Elixir ecosystem - especially Credo and Benchee - and on helping more people learn the language through