http://paulgraham.com/hundred.html

It’s many years old. And it’s a bit more “meta” than your article. But the languages you describe as being “interesting” are, so frequently, cross-pollinated from multiple other languages. And that’s one of the points he makes.

To each his own. I actually like Perl and Groovy (I tend to think of Groovy as Perl for the JVM) and I enjoy Scheme implementations, if for no other reason than the sheer density of how much functionality you can implement in 100 (or 1,000) lines of code. I’ve written tools which parse hundreds of megabytes of logfiles, distill useful information from them and output them to a CSV I can open in Excel and peruse. The tool was < 300 lines of Perl (that's after you trim out all the extra whitespace and comments; as you, yourself, point out in another of your articles, sometimes that "next programmer" is you).

I don't mind the syntax of Lisp / Scheme because I recognize that all compilers / interpreters turn your source code into an Abstract Syntax Tree and Lisp is just a serialized, text-based AST; it's trivially easy to convert between the two. Once you start thinking in terms of ASTs, your mindset WRT how programming SHOULD BE completely alters. Think of it as safe, legal LSD for programmers; that kind of mind-altering, and not in a bad way. I wouldn't be surprised if the Next Programming Language is one where you create a graphical AST on your tablet, bypassing the text-based input entirely. We all know that tablets really aren't so good for text input. If you can eliminate the need to input text and convert the text to an AST before it's interpreted / compiled ….

Thanks for sharing, Adrian.

I entirely agree with you. For heavy processing, I think it’s worth keeping an eye on the following languages:

* Crystal
* Rust
* Julia
* Pony
* Nim
* C# or F# on .NET Core
* Scala (JVM and all)

JRuby is a worthwhile effort. Thank you for mentioning it.

JRuby is in use by hundreds of companies from Visa to Comcast to the BBC, running loads that CRuby could probably never scale up to. We’ve had users halve or quarter their AWS costs by moving to JRuby. And with the JRuby 9000 series, we have our own optimizing compiler and we are working with Oracle on a next gen runtime based on the Graal JIT.

Elixir is a very nice language and I’m sure it will see success… but what you present here as “Ruby” only covers one runtime: a runtime with no JIT, limited GC, and non-parallel execution. Posts like this turn people away from Ruby for the wrong reasons, reasons we are actively addressing in JRuby.

And besides…you KNOW JRuby…I’m surprised you’d completely ignore it in this post 🙂

I love the language and wanted to adopt it at work. We needed to import some medium sized xml feeds (think 50 MB, nothing crazy).

The import script written in elixir was using parallel processing and it was pretty good – better than single threaded Go. But when we added parallel computing to Go, that killed it.

We ended up adopting Go though I don’t like it. Personally I’ve “adopted” Julia which seems to be promising for both data crunching, general computing (long running background tasks) and parallel computing.

I like Elixr, and Jens is right, unless you are taking advantage of the BEAM/OTP, it is slow. Elixir is certainly Rubyesque, but the tooling is great too.

I am keeping a sideways eye on Pony lang. It’s actor-based, OO, but supposed to be real fast, and doesn’t use a poison pill to kill all actors.

You really don’t need them. Erlang has lists where other languages have arrays because the latter are unbelievably useless in a language where your primary means of retrieving data is pattern matching.

In addition to this, arrays encourage a lot of imperative approaches which make life very difficult for you on the BEAM, which is already a huge problem for people coming into that ecosystem from Ruby.

Thank you for your insightful comment, Jens. I entirely agree that Erlang is not the right tool for every problem.

There are much better solutions for, say, number crunching. However, I believe that for the use case I specify in the article (distributed systems, web programming), Erlang-based solutions are a very solid option.

I spent much of 2011 porting CouchDB to iOS, and then trying in vain to get it to run at acceptable speed on an iPhone, before giving up. (It took 5 seconds just to initialize; a deal breaker for mobile apps.) Others at Couchbase (Dustin Sallings, Damien Katz) tried to get CouchDB’s storage engine to keep up with memcached, and ended up rewriting the engine in C, which is what’s in Couchbase Server.

I suspect people think Erlang is fast because it’s so parallelizable — just throw more cores or more CPUs at problems. But not every problem can be defeated that way, either because the algorithms aren’t parallel or because you’re restricted to hardware with a limited number of cores (and memory bus bandwidth.)