A few days ago my friend Greg Earle pointed me to an article with the provocative title of “Hail the return of native code and the resurgence of C++“. While the article provides a decent survey of the state of the popular programming language landscape, it misses the point when it comes to why VM-based or interpreted languages have become popular (and will continue to be so).
The reason why languages running on managed runtimes are and should continue to be popular is not quite as simple as relief from manual memory management or “syntactic comforts” as the author puts it. While both are fair reasons in and of themselves (and personally I think syntax is more important than is generally considered) the benefits of managed runtimes are more far reaching.
As Steve Yegge put it, “virtual machines are obvious“. For starters most virtual machines these days come with just-in-time compilers that generate native machine code instead of running everything through an interpreter. When you have complete control over your language’s environment there are a lot of interesting and powerful things you can do, especially in regards to the JIT. No matter how much you optimize your statically generated machine code you have far more information about how your program is actually running at runtime. All that information allows you to make much smarter decisions about what kind of code to generate.
For example, trace-based virtual machines like Mozilla’s Spidermonkey look for “hotspots” in your code: sections that get run over and over again. It can then generate custom code tuned to be fast for those cases and run that instead of the original correct but naive code. Since JavaScript is a dynamically typed language and allows for very loose, dynamic object creation, naive code can be very inefficient. Thus the runtime profiling is all the more important and can lead to massive speed improvements.
If you’re running a purely native-compiled language you miss all the improvements that you could get if you reacted to what you saw at runtime. If you’re writing an application that is meant to run for long periods of time (say a webserver for a large, high-traffic service) it makes all the more sense to use a VM-based language. There is a lot of information that the VM can use to do optimizations and a lot of time for those optimizations to kick in and have a definite performance benefit. In robust virtual machines with years of development behind them you can get performance that is quite comparable to native code. That is, unless you’re pulling all sorts of dirty tricks to carefully profile and optimize your handwritten native code in which case all bets are off. But honestly, would rather spend your days hand-optimizing native code or writing code that actually does interesting things?
Personally, I hardly think a new C++ standard is going to usher in a widespread revival of native code. C++ has problems of it’s own, not the least of which is that it simply a very big language that very few people fully understand (and adding features and constructs doesn’t help that). A fallout of being a complex language without a runtime is that writing debugging or analysis tools for it is hard. In Coders at Work both Jamie Zawinski and Brendan Eich denounce C++ to some extent, but Eich adds that his particular grievance is the state of debugging tools that have been practically stagnant for the last 20 odd years. Being fast, “native” or having a large feature list is not nearly sufficient to be a good programming language.
All that being said, there is definitely a place for native code. But given the expressive power of modern languages and the performance of their runtimes I expect that niche to keep dwindling. Even Google’s new Go programming language, which is ostensibly for systems programming and generates native code has some distinctly high level features (automated memory management for one). But if you’re building embedded systems or writiing the lowest level of operating systems kernels you probably still want to reach for a fast, dangerous language like C. Even then I wouldn’t be surprised if we see a move towards low-level unmanaged kernels fused with managed runtimes for most code in some of these places. Microsoft’s Singularity project comes to mind.
We’ll always have native code (unless we restart making hardware Lisp machines, or Haskell machiness) but that doesn’t mean that we’re going to (or should) see a widespread revival in low-level programming. I want my languages to keep getting closer to my brain and if that means getting away from the machine, then so be it. I want powerful machinery seamlessly analyzing and transforming source code and generating fast native code. I want to build towers on top of towers. You could argue that there was a time when our industry needed a language like C++. But I would argue that time has passed. And now I shall get back to my Haskell and JavaScript.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
