A Dynamic Language Runtime (DLR)
Today, at MIX 07, we announced a new level of support for dynamic languages on .NET that we're calling the DLR.
From the beginning, Microsoft's .NET framework was designed to support a broad range of different programming languages on a Common Language Runtime (CLR). The CLR provides shared services to these languages ranging from a world-class GC and JIT to a sandboxed security model to tools integration for debugging and profiling. Sharing these features has two huge benefits for languages on the CLR. First, it's easier to implement a language because lots of difficult engineering work is already done for you. Second, and more importantly, these languages can seamlessly work together and share libraries and frameworks so that each language can build on the work of the others.
The CLR has good support for dynamic languages today. IronPython-1.0 demonstrates this. The new Dynamic Language Runtime (DLR) adds a small set of key features to the CLR to make it dramatically better. It adds to the platform a set of services designed explicitly for the needs of dynamic languages. These include a shared dynamic type system, standard hosting model and support to make it easy to generate fast dynamic code. With these additional features it becomes dramatically easier to build high-quality dynamic language implementations on .NET. More importantly, these features enable all of the dynamic languages which use the DLR to freely share code with other dynamic languages as well as with the existing powerful static languages on the platform such as VB.NET and C#.
The DLR is about giving you the best experience for your language - true to the language, excellent tools, performance and seamless integration with a wealth of libraries and platforms. The essential benefits of the DLR are about sharing. It lets language implementers share standard features rather than rebuilding them from scratch. This lets them focus on the features that make a given language unique rather than on reinventing yet another GC system. It lets developers share code regardless of the language the code is implemented in and to use whatever language they prefer regardless of the language preferred by the environment they want to run in. Coupled with the Silverlight 1.1 platform announced today, it even lets languages share a sandboxed security model and browser integration. This means that developers building browser-based applications can now use their preferred language even for client-side code.
We're initially building four languages on top of the DLR - Python, JavaScript (EcmaScript 3.0), Visual Basic and Ruby. We shipped today both Python and JavaScript as part of the Silverlight 1.1alpha1 release today. John Lam and I will be demoing all four languages, including VB and Ruby, working together during our talk tomorrow at 11:45.
In addition to the Silverlight release, we've also made the full source code for both IronPython and all of the new DLR platform code available on codeplex under the BSD-style Microsoft Permissive License. All of that code can be downloaded today as part of the IronPython project at codeplex.com/ironpython. If you want to know more about the DLR, you should feel free to download the code. However, you should understand that this is a very early release of these bits and we still have significant work left to do including refactoring, design changes, performance tuning - not to mention documentation.
For the short term, our focus is on using a small number of languages to drive the first wave of DLR development where we can work closely and face-to-face with the developers in order to iron out the worst kinks in the DLR design. After this initial phase, we want to reach out to the broader language community. If you're building a language on top of .NET and are interested in supporting dynamic language features then we want your feedback on the DLR. However, I'd discourage you from trying to implement on top of the DLR today. I don't want you to get frustrated trying to work with these really early bits and then not be interested in working with us when we're better prepared to engage with the language community. We plan to kick off a broader engagement with language implementers at the upcoming lang.net conference in three months - at the end of July. This will be the best place to really engage with the DLR and let us know what we got wrong.
In the meantime, I'll be using this blog to post our design notes for the DLR as they're written and any feedback you have on the design is welcomed. Tomorrow I'll talk more about the shared dynamic type system and the "One True Object".