Summer of “Iron”: LINQ, Visual Studio tooling, and the Apache License
New releases and announcements from the “Iron” projects have come out over the last couple days, so I wanted to give you an overview of what’s happening, point out the really cool parts, and reiterate some of the motivations.
From a release perspective, both IronRuby and IronPython released new versions of the DLR-based .NET programming language implementations: IronPython 2.7 Alpha and IronRuby 1.1. Click on the respective release name for the full release notes and downloads, but I’ll summarize a bit here:
IronPython 2.7 Alpha
This Alpha release is the first IronPython release working towards Python 2.7 compatibility, and contains a number of bug fixes and performance improvements. It also now requires .NET 4.0 or Silverlight 4; you will need to build from source for down-level frameworks. The installer now includes Visual Studio support for IronPython, rather than being a separate installer, and the source-code for the tools has been open-sourced! Keep reading for licensing information …
Aside from a bunch of bug-fixes, the latest release of IronRuby adds support for .NET extension methods, meaning that .NET programming patterns that are dependent on extension methods, like LINQ, the Reactive framework, Parallel.NET, etc, are now all usable from Ruby code. For example, here’s a simple LINQ example:
For more information see the 101 LINQ samples ported to IronRuby.
Also, since I never announced the IronRuby 1.0 release on my blog … consider this the announcement.
Apache License, Version 2
IronRuby, IronPython, and the DLR are now licensed under the Apache License, Version 2. To address all concerns around “why” this is changing, it is solely in reaction to feedback about the licensing terms from users and the .NET/Python/Ruby/dynamic-language communities at-large. The Apache License is a more familiar and popular license to those communities than the Microsoft Public License; using it should lower any license-related barriers people encountered in the past when considering these programming-language implementations.