Lang.NEXT 2012

April 10, 2012

Microsoft hosted (and generously paid for) the Lang.NEXT conference at their campus in Redmond last week. The conference was previously called Lang.NET and was focused on the .NET platform. This year they opened the conference to other languages and invited a variety of speakers. Videos of most of the talks are available on Channel 9, along with interviews with many of the participants.

What Languages were Discussed?

I counted 24 languages that were covered in some fashion:

Other talks covered compile-time and run-time technologies:

There were also panels on:

Themes

The number of languages covered was a bit dizzying, but several themes emerged.

Functional programming is becoming mainstream, but not in the way the Haskell and ML folks might have wished. Instead, all the mainstream object-oriented languages are embracing closures.

Asynchrony in support of multi-core and UI responsiveness is pervasive. For Windows 8, any system call with a possible latency over 50 ms is only exposed via non-blocking calls. C# 5.0 adds a very cool await keyword that effectively does a CPS transform on your code. Much like yield in Python turns a procedure into a generator, adding await to a C# method makes it asynchronous, returning a Task object instead of a result. The portion of the method after the await is effectively a continuation that is executed once the awaited result is available. The returned Task object is a future on which callers of the now-asynchronous method can themselves await. Under the hood, this is all implemented using state machines that transition as results of awaited operations become available, avoiding the pesky problem of intersecting tail call optimization and late-binding, virtual dispatch. Asynchronous methods take an optional CancellationToken object that can be used to interrupt the asynchronous code in a way that generates an exception with a stack trace that matches the source code (rather than the transformed version).

IDE support is driving language and OS design. Type providers, a major feature in F# 3.0, are explicitly designed to support autocompletion in the IDE using database schemas vended from on-line databases. IDE plug-ins analyze the live schemas and vend autocompletion suggestions. The new Windows Runtime lets languages provide a shim layer that use WinRT metadata to generate autocompletion information.

Native languages, are back on everyone’s radars after a decade and a half of managed code getting all the buzz. There was some disagreement, but essentially “native” here means languages that target the metal instead of a (non-hardware-emulating) virtual machine. There seem to be a couple things driving this. The first is power consumption. This plays out in the context of data centers. Alexandrescu from Facebook talked about measuring their systems in terms of watts per active user. The power consumption concern also plays out in mobile, where the battery life of iOS devices is substantially better than devices running virtual machines. The second reason given for the resurgence of native languages is their performance. Our phones are remarkable computers, but to maintain the illusion of direct interaction, every bit of latency has to be wrung from the system. That’s tough to do with a virtual machine. It was interesting to hear people outside the Apple developer community echoing things that we talk about inside the community. These arguments always made sense to me, but it’s sometimes hard to separate general opinion from the various echo chambers that we live in.

Conclusions

How do these themes relate to Mac and iOS development? Apple introduced blocks to C in Snow Leopard and iOS 4.0, checking the functional programming box, though using a particularly ugly C-like syntax while doing it. Apple has a variety of mechanism for asynchrony, including the iCloud APIs that use nested blocks and approach a continuation passing style, though not nearly as elegantly as C#’s await. Apple never strayed from the native languages camp. After an ill-fated fling with garbage collection, they seem to be on track with ARC to solve the engineering challenges of memory management. (Note that WinRT uses reference counting via AddRef-Release rather than garbage collection.) IDE support is the area where Apple falls far, far behind. Xcode 4 is probably a necessary step in the evolution to a decent IDE experience. Sadly, it still lacks the refactoring power and quick documentation lookup that IntelliJ had a decade ago. It’s probably time to give AppCode a try.

Archive →