In un annuncio intitolato The future of Ruby.NET, il Dottor Wayne Kelly ha dichiarato la sua decisione di chiudere il progetto Ruby.NET in favore di IronRuby, l’implementazione alternativa di Ruby sviluppata da Microsoft. IronRuby è analogo al più noto IronPython e si distingue dal più maturo Ruby.NET per la scelta di adottare il DLR (Dynamic Language Runtime) invece del CLR (Common Language Runtime).
Da un punto di vista strettamente tecnico la decisione è piuttosto azzeccata, visto che il DLR si presta meglio del CLR per linguaggi dinamici come Ruby e Python. Gli sforzi degli sviluppatori interessati possono finalmente concentrarsi sull’implementazione più promettente.
L’annuncio finirà però col deludere alcuni, principalmente per due motivi. Primo, Ruby.NET è un progetto open source indipendente e quindi non di proprietà di Microsoft (che lo ha comunque sponsorizzato). Se consideriamo il sentimento anti-microsoft molto di moda di questi tempi, è facile comprendere che il prevalere di IronRuby potrà non essere visto di buon occhio. Il secondo aspetto riguarda la maturità dei progetti. Ruby.NET era quasi pronto per essere utilizzato in concomitanza con Ruby on Rails, mentre IronRuby è una pre-alpha con ancora tanta strada da fare prima di raggiungere la compatibilità totale con Ruby 1.8.
Personalmente la considero una scelta responsabile che arriva pochi giorni dopo il 2008 Lang.NET Symposium. Ma trattandosi di un progetto open source, non è detto che qualcuno non decida di portarlo avanti anche senza il beneplacito del suo creatore.
A me queste implementazioni su .NET sembrano piuttosto inutili perché per fare un esempio IronPython non può utilizzare la standard library di CPython e quindi viene meno molta dell’espressività del linguaggio che deriva anche dal modo di disegnare le API (molto diverso da Python a .NET).
Ci si finisce con il trovare, come diceva qualcuno IronPython che è un C# senza graffe[1], il che snatura completamente il senso di usare Python.
Ugly!
—
[1] http://blogs.msdn.com/saveenr/archive/2007/08/18/c-3-0-as-python-with-braces.aspx
Non sono inutili Lorenzo, hanno il loro posto.
Il deployment di Ruby on Rails ad esempio, è problematico su Windows. Avere un’implementazione completa per .NET permette allo sviluppatore di far girare applicazioni sullo stesso stack windows/IIS/.NET usato per ASP.NET.
IronRuby non sarà per tutti. Ma è un ticket importante per chi vuole introdurre Ruby all’interno di aziende che sono .NET based e hanno già moltissimo codice .NET. Lo stesso discorso vale per JRuby per i Java shop.
Se inizi da zero, chiaramente non hai bisogno di usare implementazioni alternative.
Il problema è che Rails non girerà mai su IronRuby come Django non girerà mai su IronPython.
Diverso è il caso delle implementazioni per la JVM, ma quelle che hanno come target la DLR hanno lo scopo (neanche troppo implicito) solo di portare la sintassi Python o Ruby che sia sulla piattaforma .NET.
Per quanto riguarda il deployment IIS supporta FCGI[1] quindi non vedo particolari problemi (a parte il fatto che configurare FCGI fa pena!)
—
http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1521
Ruby.NET era vicino a far girare Rails e IronRuby potrà farlo girare in futuro, visto che è uno dei loro obiettivi come indicato anche da Wayne.
Il deployment di Rails su Windows e meno che ideale e persino sconsigliato. Chiunque l’abbia provato sa di cosa parlo.
Rails ha sempre avuto dei problemi a girare con FastCGI e nel mondo Rails è ormai considerato sconsigliato come modo di depoyment. Anche se IIS inizia ad avere supporto sperimentale per Rails, mi pare chiaro che avere un’implementazione completa che gira su .NET sarebbe una gran cosa.
@Lorenzo: cito testualmente da una mail di qualche settimana fa di John Lam (responsabile del progetto IronRuby) inviata sulla mailing list IronRuby-Core:
“We have always maintained that we will run Rails. It wouldn’t be Ruby if it couldn’t run Rails.”
Inoltre c’è un interesse molto forte, accompagnato fin dall’inizio da esplicite richieste di contributi che stanno venendo piano piano raccolte dalla comunità che si sta costruendo intorno ad IronRuby, per il porting delle librerie più importanti dell’MRI, ultimamente stanno prendendo forma i lavori per un parser nativo in C# per YAML (per fare un esempio).
Dimenticavo anche questo link all’ultimo post sul blog di John con il quale ci si ricollega al post di Antonio e che contemporaneamente dovrebbe chiarire le perplessità di Lorenzo.
IMO il problema delle implementazioni alternative è che comunque non avranno le librerie che richiedono i binding C.
Quanti applicazioni rails usano, per fare un esempio, gruff o attachment_fu o ruby-debug?
In assenza dei binding non potrebbero funzionare, ed è difficile che gli autori dell’implementazione alternativa replichino _tutto_.
Stesso discorso per python, ovviamente.