Ciao a tutti,
ho appena finito di vedere questo video del talk “Toward a Design for
Ruby” dalla Rubyconf 2012 e mi sono un p depresso:
Descrive una situazione del presente e futuro prossimo di Ruby che non
molto rosea. Non mi ero mai reso conto dei problemi legati al processo
di sviluppo del linguaggio. Dalla confusione nella mailing list alla
confusione dei test stessi di Ruby, alle discussioni in giapponese
Mi ha fatto venire voglia di:
a) contribuire a Rubinius (ma non ho la stoffa)
b) cominciare a lavorare con JRuby
c) studiare un altro linguaggio
JRuby is the answer, almeno al momento.
Ho avuto occasione di parlare con Matz ad agosto, l’impressione è che
lui sia una gran persona ma non veda niente di sbagliato nel modello
corrente, soprattutto l’ormai ritrito GIL.
Un altro linguaggio? Non ci sono linguaggi che sono nello stesso sweet
spot di Ruby che non siano su JVM. E allora tanto vale usare JRuby.
Consiglio caldamente
per farsi un’idea delle alternative reali.
Noi stiamo migrando il nostro primo progetto a JRuby perché in telefonia
la concurrence è tutto. Preparati solo a patchare qualche gemma quando
non sfortunatamente a forkarne una, ma niente di drammatico.
Usando pesantemente Celluloid, una volta la settimana sulle nostre ML
salta fuori Erlang. E lì rimane
Inviato da iPhone
Il giorno 10/nov/2012, alle ore 00:05, Fabrizio R. [email protected] ha scritto:
b) cominciare a lavorare con JRuby
c) studiare un altro linguaggio
Voi che ne pensate?
a) rubinius era una figata di idea, 6 anni fa, quando doveva essere
come squeak (VM scritta in ruby). Adesso è molto meno divertente imo.
b) jruby è, super usabile
c) perché no, non fa male.
Ma a priori: se la confusione di ruby-core/ruby-dev[0] non ti ha
creato problemi fino ad ora, non è un problema. Se devi fare una cosa
dove pensi che il GIL ti dia casini, prova altro da mruby. A me
personalmente non ha mai creato problemi, dato che non faccio roba con
alta concorrenza, quindi me ne posso infischiare
Alla fine (m)ruby non copre il 100% degli usi possibili di un
linguaggio di programmazione, ma mica è detto che si debba usare
sempre la stessa cosa per tutto.
[0] ed è migliorato molto da quando cominciai io, penso che i core dev
giappi abbiano imparato un po’ di inglese
Il giorno 10 novembre 2012 07:27, Luca P. [email protected]ha scritto:
Ho avuto occasione di parlare con Matz ad agosto, l’impressione che lui
sia una gran persona ma non veda niente di sbagliato nel modello corrente,
soprattutto l’ormai ritrito GIL.
Probabilmente, come dice Gabriele, per l’uso che ne fa lui (ed il team
che
sviluppa MRI … e la maggior parte dei ruby dev nel mondo) va bene cos.
I corner case “highly concurrent systems” o “massive computing” (vedi http://bioruby.org/) forse sono troppo … “casi limite”
Usando pesantemente Celluloid, una volta la settimana sulle nostre ML
salta fuori Erlang. E l rimane
Abbiamo valutato Rubinius ma per essere sinceri per adesso il supporto
alle gemme del mondo YARV un po’ zoppicante.
JRuby una scommessa sicura e onestamente DAVVERO una bomba. Anche l
qualche volta devi toccare una gemma ma sono 1 ogni 10, non il
complemento
Erlang salta fuori per due ragioni: essendo nel mondo della telefonia,
molto ben considerato. La seconda che di fatto la reference
implementation dell’actor model.
Il giorno 10 novembre 2012 07:27, Luca P. [email protected]ha scritto:
JRuby is the answer, almeno al momento.
Ho avuto occasione di parlare con Matz ad agosto, l’impressione che lui
sia una gran persona ma non veda niente di sbagliato nel modello corrente,
soprattutto l’ormai ritrito GIL.
Un altro linguaggio? Non ci sono linguaggi che sono nello stesso sweet
spot di Ruby che non siano su JVM. E allora tanto vale usare JRuby.
Se a qualcuno interessa, faccio una presentazione fra una settimana a
Codemotion Venezia ( http://venezia.codemotion.it/ ) dove parlero di Node, Go, e Erlang. Niente di troppo profondo, ma credo che i primi due abbiano delle possibilita interessanti nei prossimi anni, e vale
la pena conoscere un po’ Erlang.
Il giorno 10 novembre 2012 10:45, gabriele renzi [email protected] ha
scritto:
Se devi fare una cosa dove pensi che il GIL ti dia casini, prova altro da
mruby.
A me personalmente non ha mai creato problemi, dato che non faccio roba
con
alta concorrenza, quindi me ne posso infischiare
Alla fine (m)ruby non copre il 100% degli usi possibili di un
linguaggio di programmazione, ma mica detto che si debba usare
sempre la stessa cosa per tutto.
Yep
Peccato per Rubinius …
Ma a priori: se la confusione di ruby-core/ruby-dev[0] non ti ha
creato problemi fino ad ora, non un problema.
[…]
[0] ed migliorato molto da quando cominciai io, penso che i core dev
giappi abbiano imparato un po’ di inglese
Cavolo.
Il giapponese interessante.
Ma dover leggere-scrivere in kanji sulla ml … help
Il giorno 10 novembre 2012 20:56, David W. [email protected]
ha
scritto:
Se a qualcuno interessa, faccio una presentazione fra una settimana a
Codemotion Venezia ( http://venezia.codemotion.it/ ) dove parlero di Node, Go, e Erlang. Niente di troppo profondo, ma credo che i primi due abbiano delle possibilita interessanti nei prossimi anni, e vale
la pena conoscere un po’ Erlang.
+1
Node.js in piena crescita, esplosione, trend
Forse siamo gi oltre gli early adopters
David non posso esserci ma vedr con piacere slides.
Un consiglio: se vai in compagnia (con amici, compagna, altre persone)
portate videocam e poi metti video online.
Cos posso anche vedere tuo intervento
Almeno … in teoria su sito codemotion ci sono link a slide, video.
Ma quelli di marzo 2012 a Roma mi sembra non ci siano.
Il tipo mi sembra abbastanza “butthurt” per le nuove features di 2.0 che
non possibile implementare in modo semplice e con la stessa semantica
in
rubinius. Sostanzialmente minaccia di forkare il linguaggio verso la
fine
del talk. Ma invece di minacciare perch non fa un po’ di manning up e
forka e basta la semantica del linguaggio?
Potrebbe imho uscire qualora di meglio rispetto che il committee. Quella
si
che mi sembra una minchiata. Basta guardare dove arrivato JAVA con il
committee.
BTW, per moltissimi use-case la concurrency non cos importante.
Descrive una situazione del presente e futuro prossimo di Ruby che non
molto rosea. Non mi ero mai reso conto dei problemi legati al processo di
sviluppo del linguaggio. Dalla confusione nella mailing list alla
confusione dei test stessi di Ruby, alle discussioni in giapponese
Sto vedendo intervento di Brian (ed altri di Rubyconf 2012 …
interessanti, grazie del link)
Poi ti dico.
Il paradigma asincrono porta rapidamente al famoso Callback Hell ed
di
difficile testabilit. Forse un modello basato su attori, potrebbe
migliorare la manutenibilit. (Interessante lettura a riguardo: http://elm-lang.org/learn/Escape-from-Callback-Hell.elm)
Troppa frammentazione nell’ecosistema e/o mancanza di standard
condivisi. Pensate a quanti framework per il testing, per il web (server
e
client side), websocket, template di rendering, driver per database:
oppure
provate a comparare queste due ricerche: keywords:redis - npm search vs search | RubyGems.org | your community gem host
Ho la percezione che Node venga usato come un tool secondario, da
affiancare ad altre tecnologie pi mature.
Per quanto riguarda le VM, vedo solo JRuby come una valida alternativa,
perch si basa sull’eccellente JVM, che permette vero parallelismo ed un
garbage collector che stato perfezionato, tenendo conto dell’esperienza
di centinaia di migliaia di applicazioni Java in produzione negli ultimi
15
anni. Forse non tutti sanno che… il GIL stato rimosso nella 1.9.3, per
far spazio al GVL, che comunque un lock globale, ma usa strategia
migliore: http://johnleach.co.uk/words/1245/visualising-the-ruby-global-vm-lock
Personalmente mi trovo bene con MRI, perch lavoro in ambiente web
(Rails/Sinatra). Per quanto ami il linguaggio, non esiterei ad usarne
uno
diverso per risolvere problemi in cui Ruby deficitario.
I miei timori erano rivolti principalmente alla prospettiva di trovarsi
con un linguaggio frammentato in diversi fork a causa della mancanza di
ampie vedute della direzione attuale (Matz & Co.).
Mi trovo bene con Ruby e Rails, e per il momento non ho intenzione di
cambiare, ma vero che le compagnie investono sulle tecnologie su cui
sanno di poter contare. E cos come le cose sono cambiate velocemente
negli utlimi 5 anni (quanti programmavano in Ruby 5 anni fa? e quanti
oggi?) altrettanto velocemente potrebbe succedere il contrario.
Il talk parla principalmente di questo. Forse un p troppo pessimista ma
mi ha colpito.
Al di l dei pareri personali, +1 sull’analisi e anche sull’uso di altri
linguaggi per risolvere i problemi, anche se onestamente aree in cui si
debba per forza usare Node ce ne sono pochine.
Io sul tema sono un po’ talebano, per me Node.js il PHP delle
piattaforme server-side
Fabrizio,
Credi che i creatori di COBOL abbiano avuto alcuna lungimiranza? Eppure
il
linguaggio ancora usato. Non mi preoccuperei troppo, in fondo
l’utilizzo
principale di Ruby sembra essere il web, e MRI assolve a quel compito.
Anche se il GVL fosse rimosso della 2.1, il paradigma ad oggetti non
ideale per la programmazione concorrente, per cui l’esplorazione di
altri
linguaggi rimane una scelta obbligata. Certo un multi-threading vero,
aiuterebbe non poco ad incrementare il throughput di richieste HTTP al
minuto.
Ecco il link. Il nuovo ‘message composer’ di Gmail ha ancora qualche
difetto…
Detto questo, credo comunque che ci sia uno spazio per qualcosa da
usare assieme o al posto di Rails per certi compiti dove ci sta
qualcosa di piccolo, veloce e capace di gestire bene i web socket.
Staremo a vedere cosa ci porta Rails 4 da questo punto di vista.
Altra cosa importante da dire: per la grande maggioranza dei progetti,
e *molto* piu importante trovare un “product market fit” che avere
una cosa ultra performante in partenza. Dover scalare e` “a good
problem to have” che la maggioranza delle startup e progetti
probabilmente non affronta mai.
il paradigma ad oggetti non
ideale per la programmazione concorrente, per cui l’esplorazione di altri
linguaggi rimane una scelta obbligata.
[citation needed]
In fondo, Simula67 ha inventato la OOP ed stato una delle principali
ispirazioni per il modello actor based.
IMO la cosa che problematica sempre lo stato globale condiviso, ma
non necessario buttare via gli
oggetti insieme a quello.
E.g. Akka[0] una figata pur usando una piattaforma OO (scala/java/jvm)
