As per the subject, the obvious question that I haven't really seen much coverage on is what the primary differences are between IronRuby and Ruby.NET, what are the advantages of one over the other, and conversely, the disadvantages of one over the other.
Here are my assumptions thus far based on bits and pieces gathered over the past few weeks,
Common Language Runtime and the Dynamic Language Runtime * IronRuby is built on top of the DLR. * Ruby.NET is built on top of the CLR.
Integration w/ Silverlight * While the first alpha release will not provide support for Silverlight, as some point in the future, IronRuby will be available for use in applications targeted towards Silverlight. * I am unsure whether or not Ruby.NET will compile against the current and/or planned Silverlight FCL, so it is unknown at this stage whether or not Ruby.NET via Silverlight will be an option.
Shared Code Between Projects * IronRuby uses the Ruby.NET parser which was licensed by MSFT directly from Gardens Point.
Support for the Core Ruby Libraries * Ruby.NET has been tested (and passed) against the Ruby 1.8.2 core ruby libraries * At this point in time (the first IronRuby alpha will be made available on the 26th of this month during John Lam's OSCON presentation) IronRuby has limited support for the core Ruby libraries.
Past these particular assumptions (which to the best of my knowledge are correct) is anyone interested in shedding some light as to where they feel the advantages and disadvantages of one project over the other might exist? My guess is that this information will be helpful to a lot of folks in attempting to make the determination as to which project best suits their particular needs, so getting this discussion moving forward seems like an important thing to do.
On 7/17/07, M. David Peterson <xmlhac...@gmail.com> wrote:
> Common Language Runtime and the Dynamic Language Runtime > * IronRuby is built on top of the DLR. > * Ruby.NET is built on top of the CLR.
I should point out the fact that the primary benefit of the DLR beyond being tuned to the specific needs of dynamic languages is that of cross language compatibility between other languages built on the DLR. In other words, a library built for IronPython 2.0 is accessible inside of your IronRuby code base as well as Dynamic VB(VBx) and the new DLR JavaScript compiler, and therefore JavaScript(3.0) itself. Vistasmalltalk/DLR[1] is another language in which you will be enabled to interop with directly.
Conversely, it is my understanding that a library compiled by Ruby.NET is accessible to any CIL-compliant language, which neither IronPython, IronRuby, or any other DLR-based language will have the ability to do (well, there are no guarantees, though I have heard that in some edge cases it might be possible.)
> Integration w/ Silverlight > * While the first alpha release will not provide support for Silverlight,
as some point in the future, IronRuby will be available for use in applications targeted towards Silverlight.
> * I am unsure whether or not Ruby.NET will compile against the current
and/or planned Silverlight FCL, so it is unknown at this stage whether or not Ruby.NET via Silverlight will be an > option.
With some minor changes (removing some dependencies, and replacing some locked down method calls) Ruby.NET _almost_ runs on the current Silverlight 1.1 bits. The major showstopper I ran into is that since Ruby.NET uses PERWAPI instead of Reflection.Emit it needs to load compiled assemblies through a call to "Assembly.Load(byte[] rawAssembly)". However, in the current Silverlight bits this method is marked [SecurityCritical] - which basically means it can't be used.
I'm pretty certain this is just an issue with the current bits being locked down which will be addressed later on.
On 7/17/07, Douglas Stockwell <d...@11011.net> wrote:
> With some minor changes (removing some dependencies, and replacing some > locked down method calls) Ruby.NET _almost_ runs on the current > Silverlight > 1.1 bits.
Nice!
The major showstopper I ran into is that since Ruby.NET uses
> PERWAPI instead of Reflection.Emit it needs to load compiled assemblies > through a call to "Assembly.Load(byte[] rawAssembly)". However, in the > current Silverlight bits this method is marked [SecurityCritical] - which > basically means it can't be used.
> I'm pretty certain this is just an issue with the current bits being > locked > down which will be addressed later on.
It will be interesting to see how this plays out. I could completely understand why marking it [SecurityCritical] could continue forward into the final release, as allowing the ability to dynamically load a raw assembly holds the potential of of opening a gaping security hole.
Of course I know diddly squat about the new security model introduced in Silverlight (well, I've read an overview, but that's as close to diddly squat as you can get w/o claiming complete ignorance ;-) Beyond the obvious, what does marking a method as [SecurityCritical] actually put into place. For example, would it allow static loading of an assembly at compile time, but not dynamic loading at run time? Or am I completely off the mark here?
Well, regardless, it looks like I've got some studying to do to better understand what this means, but none-the-less, this definitely sounds encouraging! One could easily imagine writing an application in Ruby that is compiled via Ruby.NET and made accessible to languages such as C# and VB.NET, while at the same time using IronRuby to gain the performance benefits of the DLR while communicating back and forth between the other DLR languages inside of a Silverlight application.
>> The major showstopper I ran into is that since Ruby.NET uses >> PERWAPI instead of Reflection.Emit it needs to load compiled assemblies >> through a call to "Assembly.Load(byte[] rawAssembly)". However, in the >> current Silverlight bits this method is marked [SecurityCritical] - which >> basically means it can't be used.
>> I'm pretty certain this is just an issue with the current bits being locked >> down which will be addressed later on.
> It will be interesting to see how this plays out. I could completely
understand why marking it [SecurityCritical] could continue forward into the final release, as allowing the ability to dynamically load a raw assembly holds the potential of of opening a gaping security hole.
Yeah, it would seem that way, and it's a matter of MSFT doing the necessary reviews. But if I recall correctly (which by all means I may not), the exact same code path is used to load ordinary downloaded assemblies. If so, then the security issue is basically moot.
> Of course I know diddly squat about the new security model introduced in
Silverlight (well, I've read an overview, but that's as close to diddly squat as you can get w/o claiming complete ignorance ;-) Beyond the obvious, what does marking a method as [SecurityCritical] actually put into place. For example, would it allow static loading of an assembly at compile time, but not dynamic loading at run time? Or am I completely off the mark here?
[SecurityCritical] here means that "user code" can't call the method in question, it is almost that simple. So at present we can't load a dynamic assembly from an in-memory blob. IronRuby/IronPython won't have this problem as they use the internal mechanics of Reflection.Emit to load dynamic assemblies.
But yes, if you had a statically compiled assembly which doesn’t generate any further code at runtime, then there is no problem.
I ran into a few other SecurityCritical oddities, so I'm pretty confident this is just an oversight or lack of review time. But it might be worthwhile making some noise to the right people just in case.
On 7/17/07, Douglas Stockwell <d...@11011.net> wrote:
> I ran into a few other SecurityCritical oddities, so I'm pretty confident > this is just an oversight or lack of review time. But it might be > worthwhile > making some noise to the right people just in case.
I'd be happy to help in that regard :D I've had mixed luck getting responses in the Silverlight forums, so will have to resort to other means, but this seems important enough to make some noise about for sure!
M. David Peterson wrote: > Past these particular assumptions (which to the best of my knowledge are > correct) is anyone interested in shedding some light as to where they > feel the advantages and disadvantages of one project over the other > might exist? My guess is that this information will be helpful to a lot > of folks in attempting to make the determination as to which project > best suits their particular needs, so getting this discussion moving > forward seems like an important thing to do.
I think the biggest difference in IronRuby is of the greatest importance: we all can't contribute to it. IronRuby, like IronPython, will not allow external contributions into the codebase. So it's open source, but it's only a one-way street.
I was wondering when that was going to come up ...
The main advantages that Ruby.NET offers is:
The open source contribution model
* Designed to statically generate .NET libraries that can be used by other .NET languages
* Further ahead in the completeness of our implementation
IronRuby has both the benefit of the DLR, but also the baggage it entails.
We generate CIL code statically, whereas they generate it at runtime.
The DLR is a large and complex framework and was not specifically designed for Ruby - it is more Python centric.
It's also important to point out that the DLR doesn't involve any changes to the underlying CLR, it is built entirely on top of the CLR, so there is nothing that they can do that we fundamentally couldn't do.
They use the light weight code generation API which has the advantage of garbage collecting dynamically generated code - this is more of an issue for them as all of their code is dynamically generated, whereas we only require it for "eval". None the less, we could in the future switch from using PERWAPI to using the light weight code generation API. This would also address the issue that Doug raised with about running on Silver light (but I'm not convinced that that is essential).
> I was wondering when that was going to come up ...
> The main advantages that Ruby.NET offers is:
> The open source contribution model
> · Designed to statically generate .NET libraries that can be used > by other .NET languages
> · Further ahead in the completeness of our implementation
> IronRuby has both the benefit of the DLR, but also the baggage it entails.
> We generate CIL code statically, whereas they generate it at runtime.
> The DLR is a large and complex framework and was not specifically designed > for Ruby - it is more Python centric.
> It's also important to point out that the DLR doesn't involve any changes > to the underlying CLR, it is built entirely on top of the CLR, so there is > nothing that they can do that we fundamentally couldn't do.
> They use the light weight code generation API which has the advantage of > garbage collecting dynamically generated code - this is more of an issue for > them as all of their code is dynamically generated, whereas we only require > it for "eval". None the less, we could in the future switch from using > PERWAPI to using the light weight code generation API. This would also > address the issue that Doug raised with about running on Silver light (but > I'm not convinced that that is essential).
|
