How will Python and Ruby applications be affected by .NET?

Question

I'm curious about how .NET will affect Python and Ruby applications.

Will applications written in IronPython/IronRuby be so specific to the .NET environment, that they will essentially become platform specific?

If they don't use any of the .NET features, then what is the advantage of IronPython/IronRuby over their non .NET counterparts?

Answer 1

I can't say anything about IronRuby, but most python implementations (like IronPython, Jython and PyPy) try to be as true to the CPython implementation as possible. IronPython is quickly becoming one of the best in this respect though, and there is a lot of traffic on Planet Python about it.

The main thing that will encourage developers to write code that's different from what they would write in CPython is the lack of C extension modules like NumPy (This is a problem in Jython and PyPy as well).

An interesting project to keep your eye on is IronClad, which will let you call C extension modules from within IronPython. This should eventually mean that you can develop code under CPython, using whatever modules you like, and it will run unmodified on IronPython.

http://www.resolversystems.com/documentation/index.php/Ironclad

So to answer your questions:

It should be easy enough to write IronPython applications that work on CPython as well, but I would probably aim to go the other way around: CPython programs that work on IronPython as well. That way, if it doesn't work then it's more likely to be a known bug with a known work-around.

The advantage of IronPython et al existing is that they provide alternative implementations of the language, which are sometimes useful for spotting bugs in CPython. They also provide alternative methods for deploying your Python applications, if for some reason you find yourself in a situation (like silverlight) where distributing the CPython implementation with your application is not appropriate.

Answer 2

Will applications written in IronPython/IronRuby be so specific to the .NET environment, that they will essentially become platform specific?

IronRuby currently ships with most of the core ruby standard library, and support for ruby gems.

This means that it will support pretty much any native ruby app that doesn't rely on C extensions.
The flipside is that it will be possible to write native ruby apps in IronRuby that don't rely on the CLR, and those will be portable to MRI.

Whether or not people choose to create or use extensions for their apps using the CLR is the same question as to whether people create or use C extensions for MRI - one is no more portable than the other.

There is a side-question of "because it is so much easier to create IronRuby extensions in C# than it is to create CRuby extensions in C, will people create extensions where they should be sticking to native ruby code?", but that's entirely subjective.

On the whole though, I think anything that makes creating extensions easier is a big win.

---

If they don't use any of the .NET features, then what is the advantage of IronPython/IronRuby over their non .NET counterparts?

1. Performance: IronRuby is already faster for the most part than MRI 1.8, and isn't far off MRI 1.9, and things will only improve in future. I think python is similar in this respect.

2. Deployment: As people have mentioned, running a native ruby cross-platform rails app inside IIS is an attractive proposition to some windows-based developers, as it lets them better integrate with existing servers/management infrastructure/etc

3. Stability: While MRI 1.9 is much better than 1.8 was, I don't think anyone could disagree that CLR has a much better garbage collector and base runtime than C ruby does.