icanmakeitbetter.com and Elixir

Home / elixir / icanmakeitbetter.com and Elixir

icanmakeitbetter.com and Elixir

Greetings. I’m Bruce Tate, CTO for icanmakeitbetter.com. I run our team of developers, and still code every day. Over the next few months, I’m going to walk business managers through some of the technology decisions we make, and technologists through how we choose and implement emerging technologies.

In 2015, you’re going to see some noticeable changes to our site. Pieces of our site will get more responsive, and we’ll be introducing some much more interactive concepts. We’ll deliver those new concepts quickly, and we expect them to be able to scale very well, from the beginning. Behind this movement is an exciting language called Elixir. In this article, I’m going to walk you behind the scenes and tell you why we are investing in this language, and what we expect it to do for us.

You might ask yourself “Isn’t one computer language just as good as the next?” That was my attitude for a number of years. You see, computer programmers are best when they are lazy. I hate upgrading my phone. I don’t even change my socks until I have to.

I love Ruby. The language is fast enough for the business problems we throw at it, and it allows us to be extremely adaptable. And, I could give my users better performance just by waiting because computer speeds would double every seven years or so.

No More Free Lunch

A scary paper called The Free Lunch is Over announced an end to this trend. In a nutshell, the way that computers work is changing. Chips used to get faster and more powerful because we found ways to make them smaller. Now, the individual circuits are just a few atoms thick, so we can’t shrink them anymore. Chip makers are responding by stacking up multiple cores on the same chip. To me, the software developer, each chip looks like multiple computers, and the languages I use today does not handle that architecture very well. The cool kids are noticing, and I am noticing the cool kids noticing.

So in 2012, I started going to a new series of conferences, mostly in Europe, that focused on functional programming, a programming style that handles multicore architectures and the problems we see so often on a distributed cloud. If I was going to have to buy my own lunch, it should at least be tasty. These are the things I wanted out of my language:

1. Concurrent and fast

Any reasonable language for the last half of this decade needs to manage concurrency, and do so as more than an afterthought. The current crop of languages, from Java to C#, from Ruby to Python, either punts on the problem by just doing one thing at a time or puts all of the burden on developers with an approach like threads and locks. (Programmers – pick up Paul Butcher’s excellent book called Seven Concurrency Models in Seven Weeks for more insight.) We need languages that handle concurrency in a fundamentally different way.

2. Natural syntax

The Perl language allows you to write some of the most densely compacted programs in the industry. At it’s peak, Perl had contests called “Golf” for the programmer who could express a given problem with the shortest program possible. The problem is that we write a program once, but read it thousands of times.

So we don’t want a write-only language. It has to be easy to write, and easy to read, with more weight given to the readability.

3. Fast and repeatable development cycle

We need to be able to test quickly, have an interactive console for exploration and handling emergencies, create custom repeatable tasks for deployment or development activities, and the like. We also need to be able to contribute to the language community, and consume the contributions of others.

4. Metaprogramming

Programming is about expressing concepts. Expressing these concepts in the most native language possible makes programs easier to read and write. Put another way, if programming is about expressing idioms and my language can translate larger idioms into smaller programs than yours, I am going to win because I am building with larger blocks than you.

5. Failure management

Good languages have mechanisms for dealing with failure. Great languages insulate the typical programmer from ever having to deal with failure.

That’s a pretty daunting list. But I’m lazy, and I really need a language that will let me slack off in all of the right ways.

Reducing the List

Eventually, I found three alternatives. They were:

Ruby plus $$$

We could keep coding in Ruby and just pay more for hardware. Ruby satisfies 2, 3, and 4. Ruby is weak at 1 and 5, and on multicore, will become hopeless. For a while, we decided to stay on Ruby because we didn’t like the other alternatives enough.

Erlang

This language solved 1 and 5, and better than anyone else ever has. Erlang runs a significant chunk of the world’s messaging traffic. It’s the language behind that obscene acquisition by Facebook, WhatsApp. But from a syntax perspective, the language is a wreck. The metaprogramming is also weak.

Clojure

This language solved 1, 3, and 4. It had a macro system that allows perhaps the best metaprogramming facilities of any language we were considering. It was horrible at 2 and middle-of-the-road at 5. If we were a Java shop, it would be all over. Instead, we decided to keep looking.

What we really wanted was a twisted love child with DNA from all of these three alternatives.

Enter Elixir

In 2012, I heard about the work of José Valim. He was one of the most prolific developers in the Ruby space. He’d actually been reading one of my books, Seven Languages in Seven Weeks (or on Amazon), and it turns out we were thinking in many of the same directions. I sat in a talk about his new language Elixir, and was tremendously impressed.

I started going to Erlang conferences and others to speak about Elixir, and became more and more convinced that it was the language for us. Elixir combined the natural syntax of Ruby with the Erlang virtual machine and libraries for concurrency and failover and the macro system from Clojure.

In October, we started our Elixir development. We’re working on some real-time features for our communities and surveys that will allow a much more interactive style of market research. So far, we’ve been incredibly productive. We’ll be able to claim 100% code coverage, and a highly interactive and concurrent application that will let us scale just about indefinitely.

Why should you care?

As a customer of icanmakeitbetter.com, you’ll notice that our features built with Elixir are much faster and more reliable. They are also more interactive, because the language lets us model a much more concurrent world. Our costs will stay low, so yours will too.

As a technologist, you will notice that we’re investing in the language. We’re committing core code to the language and creating a groundbreaking open-source testing framework – Shouldi –  to support the ecosystem.

As a developer, you should care because with Elixir, you don’t have to give up scalability for fun.

It’s going to be an exiting year, and we plan to tell you about it as we go through this remarkable transition.

Bruce Tate
Bruce Tate
Bruce Tate is the CTO of icanmakeitbetter.com, and author of more than 10 books, including the best-selling Seven Languages in Seven Weeks.
Recommended Posts
Showing 6 comments
  • Fred
    Reply

    Hi Bruce, good article and I’ll be watching your progress with interest. Do you use Elixir as a full back-end or are you just replacing RoR modules with Elixir ones? Also, is there any web-dev framework for Elixir?

    • Bruce Tate
      Reply

      We’re going to be slowly doing more and more of the back end in Elixir. Everything that needs to be high performance. So for now, much of our admin work will remain RoR. We’re still a bit more efficient on that side of the house, but it’s mostly because we’re more familiar with it.

      Elixir is fantastic and it will eventually be our full stack.

    • Michael
      Reply

      Hey Fred, http://www.phoenixframework.org and https://github.com/dynamo/dynamo are two interesting candidates for web development with Elixir.

  • Michael
    Reply

    Hi Bruce, ‘a write-only language’ is one of the best terms if read so far. It is so true. I share your thoughts about the reasons for Elixir point by point and I have a lot of interesting ideas I want to try with Elixir, which I never even consider trying with Ruby or RoR. I am exited to watch your way with Elixir.

  • Mike
    Reply

    I remember switching From Java to Ruby after reading Beyond Java.
    Now i feel in the same mood as 10 years ago and i must thank you again.
    Sincerely
    Mike

  • Garry
    Reply

    Have you considered having Elixir hand-off heavy computation work to Clojure? Best of both worlds. I love both of these languages not just for their efficiency but more for the mind-expanding influence. The trouble is once you spend a lot of time with functional programming and expose yourself to the ideas of Rich Hickey and Jose Valim it’s very hard to work with OO. It just feels wrong, which can be a real problem if you’re a freelance contractor trying to earn a living in an industry dominated by OO.

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you as soon as possible!

WordPress Lightbox Plugin