During a meeting with a few high-profile engineers, I presented what Ruby brought to the table. An IBM Distinguished Engineer[2] stopped me in my tracks and said, “It sounds slow”.

I love Ruby as much as a programmer can possibly love a programming language, but that engineer’s conjecture was right on the money. Ruby’s emphasis has always been on programmer efficiency, not execution efficiency.

Generally speaking, Ruby programs are significantly slower than equivalent programs in C or Java.

A lot of work has been done to improve Ruby’s performance, with a good degree of success, and that’s terrific – but is it enough in today’s world?

In many ways, yes. You’re not going to employ Ruby to calculate 13 trillion digits of Pi, nor will you use it to power the backend of a messaging app with millions of users.

However, Ruby will suit most scripts just fine. Further, I would argue that Rails still gives you the best bang for your buck in terms of web frameworks, when it comes to a large subset of CRUD-based web applications.

Ruby is lovely and has many uses, however, what Ruby is not, is the language that will define the next ten years. As beautifully designed as it is, it simply isn’t the ideal language to tackle the challenges that an increasingly distributed world throws at us.

Concurrency is the name of the game, and Ruby is, for the most part, limited in its ability to cope with it (despite valuable efforts). It’s not that you can’t do concurrency in Ruby, it’s that there are much better, battle-tested tools to do so.

If you are a fellow Ruby developer who would like to remain relevant in the next decade, I highly suggest that you start looking for something new to pair to Ruby as your main language. (Though, fair warning, you might end up replacing Ruby with it.)

Your main language for the next ten years will be highly dependent on the development context, of course. If you develop iOS apps, Swift is such a language. Android apps? Kotlin is looking good and might have a shot at that. Data Science? Julia, if they can sort out a few performance issues, could get the edge over Python and R. System programming? Rust and Go will be worth a close look, too.[3]

I’m enough of a generalist to dabble in many programming domains, but above all, I’m a web developer, so my main language for the next decade will have to excel in distributed environments where n machines make m requests, for large values of n and m (e.g., IoT alone enables this scenario).

So what comes after Ruby? Some people might argue that it’s Node.js. Not for me personally, though. I’m afraid Ruby has spoiled me. I find Ruby to be a joy to use. JavaScript, not so much.

We are looking for a high-level language that can handle concurrency like a champ, has an elegant, highly readable syntax, provides a great user experience for the developer, and… is functional. In short, fun and functional. 🙂

I find functional programming (with immutable data types) to be a significantly better approach to thinking about most problems, and modeling solutions for them, than Object Oriented programming.[4] I blame my past dabbling with Haskell and Clojure for this.

Speaking of Clojure, on the JVM, both Scala (w/ Akka), and Clojure (w/ STM & Pulsar) are valid options.

Of the two, Clojure is the one that comes closer to a great fit for me. Very close. Unfortunately, I’m somewhat of an aesthete, and coming from Ruby, the Lisp syntax still feels like a downgrade.[5]

Further, the JVM is great, but when it comes to dependable concurrency, you really can’t beat what the Erlang VM (i.e., BEAM) has to offer (ask the team at Whatsapp).

The problem with Erlang is that its Prolog-like syntax feels obsolete. I have never seen an Erlang program and said to myself, “Wow, that was a joy to read”. Or refactor. It’s not the worst, but I personally find it to be a fairly uninspiring language to work with.

Thankfully Erlang is not the only language for its highly fault-tolerant and concurrent VM. There is indeed a language worth getting excited about.

For me, that language is Elixir. Elixir fits all the requirements above and feels like a joy to both read and use.

Like many other Rubyists, when I first found Elixir I thought of it as Ruby for the Erlang VM, due to its largely familiar syntax. But it turns out to be so much more than that. In fact, it’s much more than Erlang as well.

To hastily summarize, we get:

• A highly readable, elegant, concurrent, functional programming language.
• The fantastic Erlang VM (i.e., BEAM) and OTP integration.
• Shared nothing Actor-based concurrency.
• Metaprogramming via macros.
• Polymorphism via protocols.
• A whole host of other nice features (pipeline operator, pattern matching, docstrings, streams, mix, etc).
• An excellent web framework called Phoenix.
• A fast growing supportive community, that it’s reminiscent of Ruby during the early days of Rails.

Ruby’s usage skyrocketed in the past decade and I would argue that Elixir, though not widely adopted as of yet, is well equipped to do the same in the coming ten years.

Give it a try and let me know how you like it.

The post A Language for the Next 10 Years appeared first on Programming Zen.