Where Do I Want to Go?

TLDR: The title is a pun.

In the past year or so I've been looking at different languages, trying to gain a sense of what I might do “after Java.” My investigations have been cursory, as they must be: adopting a (bad) Matrix reference, I don't think you can truly know a language until you have fought with it. But maybe you can get a sense of whether it's worth fighting. So here are the languages I've considered, and my impressions:

Scala

Many of my colleagues believe that Scala is the best “JVM language”; we're doing several projects with it, and offer several classes in the language. I like some of the ideas that it incorporates, especially the clear delineation between mutable and immutable data (and a strong preference for the latter).

But … it's ugly. My first impression of Scala was that it had too many symbolic operators. As I kept seeing it, my impression changed: it had too many features and ideas, period. And based on discussions with my colleagues, there isn't an easy path to learning the language: you need to program idiomatically from day one.

That said, it looks like Scala will be the next language that I use professionally, probably within the next few months. Maybe my opinion will change.

Clojure

I don't get LISP, and the people who claim to get it always seem a bit too religious to me (not merely religious, but too religious). Perhaps I will be enlightened if anyone can explain exactly why macros are different from any other interpreter — or for that matter, any type of code generation. For now, however, Clojure (as the most-commercial LISP) isn't in my future.

Groovy

Why isn't Groovy more popular than it is? Of the features that I listed in my previous post, Groovy has everything except a concurrency story. It's easy to write, runs on the JVM, can interact directly with Java libraries, and offers some neat features of its own. Yet the only people who seem to use it are those who adopted Gradle as their build tool.

It was while I was trying to learn Gradle that I decided Groovy wasn't for me. To truly understand Gradle, you need to understand the Groovy approach to building DSLs by blending functions and blocks into a seamless whole. It's quite impressive once you figure it out. But, like Scala, there's no easy path to knowledge. The path from “Hello, World” to idiomatic Groovy involves a quantum leap.

And the documentation, quite frankly, sucks. It's a bunch of disconnected wiki pages that assume you know what you're looking for before you look for it. Perhaps not so bad on its own, but I believe it belies the approach to Groovy's language design: it's trying to be the new Perl.

Ruby

I've worked a bit with Ruby. It's nice, but I don't find myself wanting to devote the next section of my career to being a “Ruby developer.”

JavaScript

Does JavaScript have a future outside of the browser? I don't think so, Node.js notwithstanding. I think the biggest issue is the lack of library support: if I want a feature that's not part of the core language I need to write it myself. It's much like C++ before the STL (and while JQuery is great for interacting with the DOM, it's not a general-purpose library).

I also make far too many typos to be a happy JavaScript programmer. Making this worse, most of the frameworks that I've used swallow exceptions.

Erlang

Erlang is a strange language; it's very obvious that it started life as a rules engine. It has some extremely interesting features, such as list comprehensions that are closer to a database query than anything you'll find elsewhere. And most important, it has a notion of “shared nothing,” message-passing concurrency that I like.

But … it's a strange language. Actually, the way that I often describe it is “primitive,” designed to solve the problems of the 1980s. There's heavy emphasis on buffer manipulation, while strings are treated as lists of (ISO8859-1!) characters. I'm seeing ever more projects that use it, but I think there are better alternatives.

Python

Python is a beautiful language: every time I get to use it, I smile. Unfortunately, as far as I can tell (based on not-so-regular attendance at the local Python Users' Group), it's confined to scripting and “need it now and not tomorrow” programs. It also doesn't have a good (to me) concurrency story.

Go

Go has many of the features that I consider important, and it has an impressive pedigree (Kernighan and Pike). It does have some strange quirks, which will be the topic of future posts. And it's a young language, still evolving; code written today may need to be rewritten tomorrow.

That said, Go seems to make the most sense for my future. Like Java, it was a language created for a clear purpose (concurrent back-end applications), and I happen to think that the future mainstream will be concurrent. Better then to have a language that was designed for that purpose, rather than one that has concurrency bolted on.

Coming up: my adventures in learning Go.