5 ms·

My first job at Microsoft was to build IronRuby, which was an implementation of Ruby on top of the Common Language Runtime. I got the job because I had built a

My first job at Microsoft was to build IronRuby, which was an implementation of Ruby on top of the Common Language Runtime. I got the job because I had built a bridge that connected MRI (Matz's Ruby Interpreter) to the CLR before I joined the company. This project ultimately failed because of a principle that we learned from the school of hard knocks: respect developers' existing code investments. Developers couldn't use it because many of Ruby's existing libraries were thin wrappers over native code, and we couldn't get them to work for many reasons. It turns out that the project was more of a demonstration of our ability to get dynamic languages to run efficiently on the CLR. To that end, I think we were successful. But once we achieved that there was not much of a path forward so the project was eventually shuttered.

rohansingh 4y ago
I remember IronRuby. It was a great demonstration and I think you inspired a lot of folks who came after. Maybe it didn't accomplish your original goal, but props for what you did accomplish. Quite impressive.
el_benhameen 4y ago
For what it’s worth, I’m pretty sure we still have a little bit of iron ruby deep within some of our build tooling.
Devasta 4y ago
We use IronRuby for a monitoring application at my job. Its provides dashboards with hundreds of red/green annuciator tiles that users across the enterprise can create and customize. They can make a call to an API or run an SQL query or whatever and then as part of the tile configuration they include a few dozen lines of Ironruby to determine if the query results are good or bad and what messages to display on TV screens around the offices. We couldn't have made it user customizable without something like IronRuby, thank you so much for implementing it!
- localhost 4y ago
  Wow. Thanks for sharing this! I had no idea that it was still being used somewhere. I'll share with folks on the team that I'm still in touch with!
turtleyacht 4y ago
Does this mean a version of VB6 (classic ASP) could run on .NET Core (Linux)? That would finally liberate the language from the platform (IIS on Windows).
- andix 4y ago
  No. But in theory you could implement a wrapper, sure. But do yourself a favor, and just rewrite your application with a modern framework.
  - turtleyacht 4y ago
    I agree, many benefits would be realized in a modern framework. With so much functionality stored in stored procs, VBScript was essentially just looping records and writing things out to tables. But there was lots of business logic there too. It felt like I had a purpose liberating "old database" logic into application code--the sky castles of Brooks, as it were--where it could be changed "more easily." Given the app was ported to C#, I suppose the stored procs would be the last to go. Recently, I learned Cloudflare had started with lots of the domain living in the db. So it is not an unfamiliar technique, but a pleasant surprise to hear of it (for me).
    - andix 4y ago
      The business logic you may be able to convert to VB.net. It’s a bit weird but not worse than C#.
      - turtleyacht 4y ago
        At least one product was developed in VB.NET. We tried to keep the current conventions when maintaining or extending it. It was mostly a wrapper around stored procs, so just a lot of Response.Writes. For some reason, to me VBScript feels like I can whip up something really quickly, and VB.NET is "all the power of the CLR, with a bit of sugar to help transition to .NET." VB.NET does feel a bit weird. Maybe some compromises to transition folks to .NET, and from there to C#.
michaelcampbell 4y ago
FWIW I remember IronRuby quite fondly. If not the outcome, the effort.
physicles 4y ago
> respect developers' existing code investments As a former Microsoftie myself, it saddens me that the company seems to have forgotten this.
int_19h 4y ago
I think it was in part because in 2010, Microsoft was already switching gears to Windows 8. A part of that was DevDiv getting sidelined by Windows. Windows was not a fan of .NET in general since Longhorn/Vista, but more importantly, the grand plan for Win8 involved the brand new application framework, WinRT. So when it came to VS 2012 and .NET 4.5, the emphasis was on WinRT interop - which is not a scenario where DLR is useful. It's a good thing that DLR is still there, though. While undeniably niche, sometimes it makes things so much easier. For example, I've used it to support dynamic reloading of C# code in a game, for rapid prototyping of mods.
- localhost 4y ago
  Our funding was gone by April 2009 IIRC, which was before Windows 7 shipped. Jim Hugunin and I shopped the team around and eventually landed in the Technical Computing org. The only thing that survived from that era was Python Tools for Visual Studio.
ska 4y ago
Was this basically what doomed IronPython also? I remember a conversation ages ago about how you couldn't really get a (common?) lisp running properly, irrc due to limitations in the way CLR modeled classes amongst other things, but FFI came up there too.
- localhost 4y ago
  Yes. The problem was that the interpreters for both languages did not have a well-defined FFI. From a native library you could reach up into the interpreter and party over the AST to your heart's content. We couldn't in any practical sense emulate those data structures from the CLR which meant that native libraries couldn't run. That meant that existing scripting code that used those libraries would need to be rewritten to use an equivalent .NET library (e.g., regex). We naively thought that was what people would do and that turned out to be a mistake :(
  - singularity2001 4y ago
    What do you mean by well defined FFI? Why couldn't calls to native libraries be marshaled?
    - ska 4y ago
      Iirc They did something like this for c++ and it wasn’t pretty but I can’t remember details, it may have been mostly because of the unstable ABI.
  - damagednoob 4y ago
    > That meant that existing scripting code that used those libraries would need to be rewritten to use an equivalent .NET library. We naively thought that was what people would do... AFAIK, that's what JRuby does but Java had (has?) a bigger community and is more platform independent. Microsoft was a different company back then and wasn't supported on Linux. Betting on IronRuby/IronPython meant you had to use Windows as your platform.
seanmcdirmid 4y ago
I got so much mileage out of the DLR they built to support those languages even if things didn't work out afterwards. To this day, I don't think anything as effective exists anywhere in language tech land.
aardvark179 4y ago
IronRuby may not have succeeded but it and the DLR were inspirational, and I don’t think I’d have been working on JVM based language implementations for the last decade and a bit without initially being to point at things like IronRuby and say, “We know it’s possible.”

rohansingh 4y ago

I remember IronRuby. It was a great demonstration and I think you inspired a lot of folks who came after. Maybe it didn't accomplish your original goal, but props for what you did accomplish. Quite impressive.

el_benhameen 4y ago

For what it’s worth, I’m pretty sure we still have a little bit of iron ruby deep within some of our build tooling.

Devasta 4y ago

We use IronRuby for a monitoring application at my job. Its provides dashboards with hundreds of red/green annuciator tiles that users across the enterprise can create and customize. They can make a call to an API or run an SQL query or whatever and then as part of the tile configuration they include a few dozen lines of Ironruby to determine if the query results are good or bad and what messages to display on TV screens around the offices. We couldn't have made it user customizable without something like IronRuby, thank you so much for implementing it!

localhost 4y ago
Wow. Thanks for sharing this! I had no idea that it was still being used somewhere. I'll share with folks on the team that I'm still in touch with!

turtleyacht 4y ago

Does this mean a version of VB6 (classic ASP) could run on .NET Core (Linux)? That would finally liberate the language from the platform (IIS on Windows).

andix 4y ago
No. But in theory you could implement a wrapper, sure. But do yourself a favor, and just rewrite your application with a modern framework.
- turtleyacht 4y ago
  I agree, many benefits would be realized in a modern framework. With so much functionality stored in stored procs, VBScript was essentially just looping records and writing things out to tables. But there was lots of business logic there too. It felt like I had a purpose liberating "old database" logic into application code--the sky castles of Brooks, as it were--where it could be changed "more easily." Given the app was ported to C#, I suppose the stored procs would be the last to go. Recently, I learned Cloudflare had started with lots of the domain living in the db. So it is not an unfamiliar technique, but a pleasant surprise to hear of it (for me).
  - andix 4y ago
    The business logic you may be able to convert to VB.net. It’s a bit weird but not worse than C#.
    - turtleyacht 4y ago
      At least one product was developed in VB.NET. We tried to keep the current conventions when maintaining or extending it. It was mostly a wrapper around stored procs, so just a lot of Response.Writes. For some reason, to me VBScript feels like I can whip up something really quickly, and VB.NET is "all the power of the CLR, with a bit of sugar to help transition to .NET." VB.NET does feel a bit weird. Maybe some compromises to transition folks to .NET, and from there to C#.

michaelcampbell 4y ago

FWIW I remember IronRuby quite fondly. If not the outcome, the effort.

physicles 4y ago

> respect developers' existing code investments As a former Microsoftie myself, it saddens me that the company seems to have forgotten this.

int_19h 4y ago

I think it was in part because in 2010, Microsoft was already switching gears to Windows 8. A part of that was DevDiv getting sidelined by Windows. Windows was not a fan of .NET in general since Longhorn/Vista, but more importantly, the grand plan for Win8 involved the brand new application framework, WinRT. So when it came to VS 2012 and .NET 4.5, the emphasis was on WinRT interop - which is not a scenario where DLR is useful. It's a good thing that DLR is still there, though. While undeniably niche, sometimes it makes things so much easier. For example, I've used it to support dynamic reloading of C# code in a game, for rapid prototyping of mods.

localhost 4y ago
Our funding was gone by April 2009 IIRC, which was before Windows 7 shipped. Jim Hugunin and I shopped the team around and eventually landed in the Technical Computing org. The only thing that survived from that era was Python Tools for Visual Studio.

ska 4y ago

Was this basically what doomed IronPython also? I remember a conversation ages ago about how you couldn't really get a (common?) lisp running properly, irrc due to limitations in the way CLR modeled classes amongst other things, but FFI came up there too.

localhost 4y ago
Yes. The problem was that the interpreters for both languages did not have a well-defined FFI. From a native library you could reach up into the interpreter and party over the AST to your heart's content. We couldn't in any practical sense emulate those data structures from the CLR which meant that native libraries couldn't run. That meant that existing scripting code that used those libraries would need to be rewritten to use an equivalent .NET library (e.g., regex). We naively thought that was what people would do and that turned out to be a mistake :(
- singularity2001 4y ago
  What do you mean by well defined FFI? Why couldn't calls to native libraries be marshaled?
  - ska 4y ago
    Iirc They did something like this for c++ and it wasn’t pretty but I can’t remember details, it may have been mostly because of the unstable ABI.
- damagednoob 4y ago
  > That meant that existing scripting code that used those libraries would need to be rewritten to use an equivalent .NET library. We naively thought that was what people would do... AFAIK, that's what JRuby does but Java had (has?) a bigger community and is more platform independent. Microsoft was a different company back then and wasn't supported on Linux. Betting on IronRuby/IronPython meant you had to use Windows as your platform.

seanmcdirmid 4y ago

I got so much mileage out of the DLR they built to support those languages even if things didn't work out afterwards. To this day, I don't think anything as effective exists anywhere in language tech land.

aardvark179 4y ago

IronRuby may not have succeeded but it and the DLR were inspirational, and I don’t think I’d have been working on JVM based language implementations for the last decade and a bit without initially being to point at things like IronRuby and say, “We know it’s possible.”