Neko versus Microsoft Dynamic Language Runtime

Hello:

Another recent option for running multiple dynamic languages
under one 
VM is the Microsoft Dynamic Language Runtime (DLR), which
runs on top of 
the CLR.  The DLR aims to solve the current problems with
running 
multiple dynamic languages on the CLR; for example, it
provides a common 
dynamic type system.  It has been most publicized as part of
Silverlight 
1.1, but it's also available separately.

Of course, the DLR's biggest current advantage is the number
of popular 
languages already targeting it.  Microsoft has already
written DLR-based 
implementations of JavaScript and VB; the next version of
IronPython is 
going to be based on the DLR; and IronRuby is in
development.

If I understand correctly, one of the DLR's strengths is
that all 
DLR-based languages share a common namespace tree, the one
provided by 
the DLR.  So code written in any DLR-based language can use
classes 
implemented in any other DLR-based or CLR-based language. 
If I 
understand correctly, this makes code sharing across
languages more 
seamless than it would be with Neko, but it probably imposes

restrictions that Neko does not; there's always a
trade-off.

Given the number of languages already targeting the DLR, and
the 
apparent ease of sharing code between these languages and
other 
CLR-based languages, I'd think the DLR would be quite
appealing to a 
developer wanting to add a scripting interface or a plugin
system to a 
desktop app on Windows, even if said app isn't currently
using the CLR.

Microsoft has made the DLR, IronPython, and IronRuby (still
in 
development) open source, under a permissive license.  So I
don't think 
licensing is an issue, and the DLR could also potentially
run on Mono, 
if that's not being done already.

So I suppose that the DLR's chief drawback is the size of
the CLR or 
Mono; even the CoreCLR included with Silverlight 1.1 Alpha
is about 5 MB 
(including the standard library).  Of course, if a time
comes when the 
vast majority of desktop computers have a reasonably recent
CLR 
installed, as Microsoft surely hopes will happen, then
footprint will be 
much less of a consideration.  But that's a big
"if", probably 
contingent on mass adoption of Windows Vista.

So what advantages does Neko have over the DLR that I've
overlooked? 
This might be good material for the FAQ.

Thanks,
Matt

-- 
Neko : One VM to run them all
(http://nekovm.org)

> So what advantages does Neko have over the DLR that
I've overlooked?
> This might be good material for the FAQ.

A few I can think about :
- size (you name it)
- low memory usage
- embeddable (it does not take 5MB)
- easy to target (you don't need to manipulate binary
opcodes, you only
need to generate a valid Neko program)
- open source (CLR is not open source, and Mono is still
lagging behind)

Nicolas

-- 
Neko : One VM to run them all
(http://nekovm.org)

Matt Campbell wrote:
[...]
> Of course, the DLR's biggest current advantage is the
number of popular
> languages already targeting it.  

The biggest advantage of the DLR is that it's MS.  That's
also its
greatest disadvantage. 

It's an easy sell to corporate IT, you'll be able to find
tons of
resources (books, training, developers), etc.  MS certainly
has
marketing and development muscle to throw behind SilverLight
and the
DLR.  Jim Hugunin and John Lam are very capable developers.

The problem for me is that MS has a way of solving 80-90% of
the problem
elegantly but leaving the last bit horribly convoluted,
overcomplicated
and/or inflexible.  IMO, this is what happens when you have
a closed
source development model and employ a lot of developers with
varying
skill levels to work on the framework.

[...]
> I'd think the DLR would be quite appealing to a
> developer wanting to add a scripting interface or a
plugin system to a
> desktop app on Windows, even if said app isn't
currently using the CLR.

Windows Scripting has been around for a long time.  It
enabled
developers to support VBScript and JScript in their
applications.  The
DLR represents something a lot nicer, but the
idea/capability has been
around for a while via COM.

[...]
> the DLR could also potentially run on Mono,
> if that's not being done already.

http
://tirania.org/blog/archive/2007/Jun-21.html

I think this is the beginnings of a 1.0 implementation
however, not the
DLR bit.

> So I suppose that the DLR's chief drawback is the size
of the CLR or
> Mono; even the CoreCLR included with Silverlight 1.1
Alpha is about 5 MB
> (including the standard library).  

And 1.1 is the release most .NET developers are excited
about.  But its
ship date could be in 2008 (and I believe that's without
linux support).

> Of course, if a time comes when the
> vast majority of desktop computers have a reasonably
recent CLR
> installed, as Microsoft surely hopes will happen, then
footprint will be
> much less of a consideration.  But that's a big
"if", probably
> contingent on mass adoption of Windows Vista.

The first windows OS the main .NET CLR shipped with was
Vista.  I doubt
they'll ship the DLR with Vista.  The way they'll get
Silverlight out is
via windows update.

> So what advantages does Neko have over the DLR that
I've overlooked?
> This might be good material for the FAQ.

In addition to what Nicolas mentioned, IMO:

1) available today.
2) runs on Linux, MacOSX and Windows today.
3) offers a server side solution with mod_neko. (SilverLight
seems
focused on the client, although I'm certain the DLR will run
on IIS/ASP.NET)

-Brian


-- 
Neko : One VM to run them all
(http://nekovm.org)