• Passa alla navigazione primaria
  • Passa al contenuto principale
  • Passa alla barra laterale primaria
  • Programmazione
  • Siamo tutti geek
  • IT Business
  • Tlc & Internet
  • Applicazioni & OS
  • Networking & Security
  • Software Engineering
  • Gadget

Stacktrace

Aperiodico di resistenza informatica

  • Home
  • Collabora
  • Archivi
  • Chi siamo
  • Termini d’uso

Addio Ruby.NET

5 Febbraio 2008 A cura di Antonio Cangiano

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.

Archiviato in:Programmazione Contrassegnato con: ironruby, microsoft, ruby, ruby.net

Info Antonio Cangiano

Antonio lavora come Software Engineer & Technical Evangelist presso la IBM in Canada. È inoltre il direttore di Stacktrace.it, un internet marketing strategist, imprenditore del web, serial blogger, e autore di un paio di libri in inglese (recentemente Technical Blogging.) Puoi dare un'occhiata ai suoi progetti sulla sua homepage e seguendolo su Twitter. Antonio è vegano e segue una dieta plant-based.

Interazioni del lettore

Commenti

  1. Lorenzo Bolognini dice

    5 Febbraio 2008 alle 13:59

    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

  2. Antonio Cangiano dice

    5 Febbraio 2008 alle 16:54

    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.

  3. Lorenzo Bolognini dice

    5 Febbraio 2008 alle 17:26

    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

  4. Antonio Cangiano dice

    5 Febbraio 2008 alle 17:51

    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.

  5. Daniele Alessandri dice

    5 Febbraio 2008 alle 22:23

    @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).

  6. Daniele Alessandri dice

    5 Febbraio 2008 alle 22:35

    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.

  7. riffraff dice

    7 Febbraio 2008 alle 15:14

    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.

Barra laterale primaria

Seguito da più di 16,000 programmatori

Idea Hai idee per un articolo? Contattami!

Leggi il mio libro

Technical Blogging: Amplify your influence

Printed | Ebook | Audiobook

Follow @stacktrace

Post recenti

  • Recensione di Amazon Books a Seattle
  • Il vero nemico degli artisti in rete
  • 10 consigli per interagire con il proprio geek di famiglia
  • Amazon lancia il Kindle italiano
  • IBM rilascia la versione 9.7.5 di DB2 Express-C

Commenti recenti

  • Leonardo su 10 consigli per interagire con il proprio geek di famiglia
  • Gilton su 10 consigli per interagire con il proprio geek di famiglia
  • Lorenzo su La fluidità del codice
  • Lorenzo su 10 consigli per interagire con il proprio geek di famiglia
  • Mr.Price su 10 consigli per interagire con il proprio geek di famiglia

Categorie

  • Applicazioni & OS (13)
  • Editoriali (11)
  • Gadget (7)
  • IT Business (25)
  • Legge & Privacy (8)
  • Libri (6)
  • Networking & Security (11)
  • Programmazione (104)
  • Siamo tutti geek (33)
  • Software Engineering (9)
  • Tlc & Internet (17)

Tag popolari

agile algoritmi amazon apple business c cisco conferenze django eventi extreme programming firefox framework geek google internet ironruby italia java libro linguaggi linux lisp matematica microsoft mozilla networking perl php Programmazione project euler pycon python rails rest rubinius ruby scheme startup vignetta visione web web2.0 windows xul

Hanno collaborato

  • Antonio Cangiano (RSS) (68)
  • Marco Beri (RSS) (23)
  • Michele Simionato (RSS) (22)
  • Alex Beri (RSS) (18)
  • Ludovico Magnocavallo (RSS) (12)
  • Valentino Volonghi (RSS) (9)
  • Marco Ceresa (RSS) (9)
  • Piergiuliano Bossi (RSS) (7)
  • Davide Ficano (RSS) (7)
  • Simone Dall'Angelo (RSS) (7)
  • Gabriele Renzi (RSS) (6)
  • Giovanni Intini (RSS) (6)
  • Daniele Varrazzo (RSS) (5)
  • Nicholas Wieland (RSS) (5)
  • Michele Finotto (RSS) (4)
  • Luigi Panzeri (RSS) (4)
  • Matteo Nodari (RSS) (3)
  • Lawrence Oluyede (RSS) (3)
  • Stefano Rodighiero (RSS) (3)
  • Andrea Righi (RSS) (3)
  • Roberto De Ioris (RSS) (2)
  • Alberto Revelli (RSS) (2)
  • Davide Casali (RSS) (2)
  • Franco Lombardo (RSS) (2)
  • Claudio Cicali (RSS) (2)
  • Carmine Noviello (RSS) (2)
  • Massimo Scamarcia (RSS) (1)
  • Marco De Paoli (RSS) (1)
  • Francesco Matarazzo (RSS) (1)
  • Emmanuele Somma (RSS) (1)
  • Nicola Larosa (RSS) (1)
  • Massimiliano Mirra (RSS) (1)
  • Lorenzo Bolognini (RSS) (1)

Disclaimer

Stacktrace.it partecipa al Programma Affiliazione Amazon EU, un programma di affiliazione che consente ai siti di percepire una commissione pubblicitaria pubblicizzando e fornendo link al sito Amazon.it (e altri siti Amazon di altri paesi). Forniamo inoltre link a siti non associati con Amazon, che ci permettono di percepire una commissione sulle vendite. Amazon e il logo Amazon sono marchi registrati di Amazon.com, Inc. o delle sue affiliate.

Copyright © 2007-2018 Antonio Cangiano