A new year brings new resolutions and an excuse to spend some time thinking about the things that have happened over the last year and what will be different in the future. A lot happened in 2013, but on the technical front, the thing that makes me most excited is the continuing rise in acceptance of languages that are more strongly opinionated about their purpose and focus, like Go, F#, and Haskell. There's a tendency among programmers to search for the one language to rule them all, the language that perfectly expresses computation, the language that everyone will use to see fewer problems in their code. Personally, I think that kind of language doesn't actually exist -- the inherent engineering trade-offs in creating a language mean that each language will be more tailored for one kind of programming than another¹. I hope the trend towards more widespread use of functional programming continues in 2014, because I think changing the way programmers tend to think about computations away from the typical threads+state model will lead to more insights about how to deal with the explosion of cores and increasing programmability of GPUs.

But I'm not interested in trying to make a forecast for the community of programmers and software engineers as a whole; I think looking at blogs like Lambda the Ultimate or reading research on programming languages and thinking critically about it is far more useful than anything I could contribute. I do, however, have a few languages that I'm really looking forward to getting the chance to use more in 2014. I also know I'm going to use a few languages that I have mixed feelings about, so I'll mention those too.

"Systems" languages

Starting with the good stuff: I really think that 2014 is going to be a great year for people to start seriously exploring system programming languages as an alternative to C++ or Objective-C. Both Objective-C and C++ have a litany of their own problems, but are the only practical alternatives to classic C for certain classes of programs (like games and really responsive mobile apps) that care deeply about having explicit control over memory layout and guarantees about predictable costs for memory management. I see three strong contenders right now: D, Go, and Rust.

Go seems to have the most steam right now, especially in the realm of creating servers that talk on the web. I think Go shines in that realm, but I have a lot of qualms about it as a language for broader use, especially in games. Stop-the-world garbage collection is a bit of a show-stopper if you want to be able to reliably reason about your program's ability to render at 60 or 120 Hz. I'm also not sure about the general applicability of goroutines and channels to eliminate shared state problems, though I haven't written enough code that pushes the model to its limits.

I have spent the least amount of time programming in D, so I won't say much about it besides mentioning that I'd like to write more code in it. I admire its embrace of message passing and generally feel like it's a version of Erlang that will be easier to get skeptical C++ programmers to adopt.

Rust has me the most excited. It's still undergoing a lot of changes, but the starting point of "let's build a language that will make the best browser rendering engine" means that it's made a lot of choices that I think are solid compromises between functional models and remaining faithful to the execution model of most real computers. The presence of object lifetime markers at a syntactic level also makes me really happy: how long does this thing live should be a straightforward question to ask in most cases when looking at new code.

Languages for familiar runtimes

At a higher level, I'm looking forward to spending more time with a couple of languages that let programmers take advantage of the existing environments for the JVM and .NET without having to use with Java or C#. Getting to use functional features and more expressive languages while retaining access to the tooling and library support on the JVM or CLR make these languages look really attractive in applications where you can use garbage collection.

Clojure remains one of the languages I'm absolutely thrilled about. I found it in 2008, when I was primarily writing code for the JVM and feeling deeply dissatisfied with the non-Java options available for JVM-hosted code. Almost six (!!) years later, the language continues to make me smile when I use it. Its combination of macros and immutability make it feel like the best Lisp dialect currently available. The dynamic nature of the language always feels like a breath of fresh air when I come to it after a long time programming in more strongly, statically typed languages.

F# feels like less of a revelation than Clojure, but remains one of the most interesting options for code that runs on the .NET CLR. If nothing else, its presence in Visual Studio makes it a great starting point to introduce programmers more used to C++ or C# to the power and flexibility that comes with a REPL and functional approaches to programming.

The Unsolved Problems

The biggest glaring gap to me in the programming landscape right now is a concurrency-minded programming language that sits in between the more low-level, memory-layout focused languages and higher level scripting languages that come with their own (often heavyweight) runtime environments. The language holy grail, to me, continues to be a language that makes it easy to write game code in a functional style yet is as easy to integrate into a standalone program as Lua. I'm still searching for that.