Forum: Italian Ruby user group "Toward a Design for Ruby"

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:

http://www.youtube.com/watch?v=BagNfTbXn3w&feature=plcp

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

Voi che ne pensate?

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 
http://pragprog.com/book/btlang/seven-languages-in...
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 Regini 
<freegenie@gmail.com> ha scritto:

2012/11/10 Fabrizio Regini <freegenie@gmail.com>:
> 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 :)


--
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com

Il giorno 10 novembre 2012 07:27, Luca Pradovera
<luca.pradovera@gmail.com>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 :-)
>

Nessuno propone http://golang.org/ ?
Strano :-p

S.

Il giorno 10 novembre 2012 07:27, Luca Pradovera
<luca.pradovera@gmail.com>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.
>

Luca una curiosit.
Avete provato, valutato Rubinius ?
Perch in teoria http://rubini.us/doc/en/systems/concurrency/ ... :-)

Ma forse avete altre esigenze di progetto.
JVM --> oltre a JRuby tanto altro, apertura per il futuro, project 
(risk)
management ;)

S.

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.
--
Luca Pradovera
luca.pradovera@gmail.com
+39 346 4296868



Il giorno 10/nov/2012, alle ore 18:36, Sergio Berisso 
<sergio.berisso@gmail.com> ha scritto:

Il giorno 10 novembre 2012 18:41, Luca Pradovera
<luca.pradovera@gmail.com>ha scritto:

> Abbiamo valutato Rubinius ma per essere sinceri per adesso il supporto
> alle gemme del mondo YARV  un po' zoppicante.
>

Peccato.
Perch il progetto anche se in ritardo "mostruoso" rimane interessante.
http://rubini.us/2011/06/07/inside-rubinius-20-preview/
Usano http://llvm.org/, hanno costruito una loro VM come il progetto
http://vmkit.llvm.org/, ecc..
Contribuite.
Fabrizio contribuisci (anche se "non hai la stoffa" ... chiss, forse
invece ... :)


> 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
> :-)
>

Thanx

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


Si ma il linguaggio che si porta dietro Erlang VM ... ;)
A quel punto forse  meglio
http://elixir-lang.org/
http://elixir-lang.org/getting_started/ex_unit.html

Almeno non fa impazzire il povero dev aspirante polyglot :)

S.

Il giorno 10 novembre 2012 10:45, gabriele renzi <rff.rff@gmail.com> 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 :-D

S.

>> Usando pesantemente Celluloid, una volta la settimana sulle nostre ML
>> salta fuori Erlang. E l rimane :-)
>>
>
> Nessuno propone http://golang.org/ ?
> Strano :-p

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.

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Node  gi passato di moda, imho.
Go non pu non funzionare, con i backers che ha.
Erlang,  Erlang :-)
--
Luca Pradovera
luca.pradovera@gmail.com
+39 346 4296868



Il giorno 10/nov/2012, alle ore 20:56, David Welton 
<davidnwelton@gmail.com> ha scritto:

Il giorno 10 novembre 2012 20:56, David Welton <davidnwelton@gmail.com> 
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
http://en.wikipedia.org/wiki/Technology_adoption_lifecycle
Forse siamo gi oltre gli early adopters
http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png

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.

S.

Il giorno 10 novembre 2012 00:05, Fabrizio Regini <freegenie@gmail.com> 
ha
scritto:

> Ho appena finito di vedere questo video del talk "Toward a Design for
> Ruby"  dalla Rubyconf 2012 e mi sono un p depresso:
>
> http://www.youtube.com/watch?v=BagNfTbXn3w&feature=plcp
>
> 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.

Ciao,
Sergio

2012/11/10 Fabrizio Regini <freegenie@gmail.com>

> Voi che ne pensate?
>

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.

Ciao,

Credo che Node.js non sia una alternativa a Rails per un po' di motivi:
1. Il primo  una piattaforma, il secondo  un web framework, quindi il
paragone non si pone.
2. Nonostante sia passato qualche anno dalle prime release di Node, al
momento non ci sono aziende che hanno puntato sulla tecnologia al 100%,
cosa che invece avviene con Rails (
https://github.com/joyent/node/wiki/Projects,-Appl...).
3. 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)
4. 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:
https://npmjs.org/browse/keyword/redis vs
https://rubygems.org/search?utf8=%E2%9C%93&query=redis

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

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.

Luca


2012/11/10 Stefano Pigozzi <stefano.pigozzi@gmail.com>

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
--
Luca Pradovera
luca.pradovera@gmail.com
+39 346 4296868



Il giorno 11/nov/2012, alle ore 10:57, Luca Guidi <guidi.luca@gmail.com> 
ha scritto:

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.

-f

2012/11/11 Luca Guidi <guidi.luca@gmail.com>:
> Ciao,
>
> Credo che Node.js non sia una alternativa a Rails per un po' di motivi:

Questo e` un ottimo "debunking" di Node.js:


--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Ecco il link.  Il nuovo 'message composer' di Gmail ha ancora qualche 
difetto...

http://www.unlimitednovelty.com/2012/08/debunking-...


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.

On Sun, Nov 11, 2012 at 12:37 PM, David Welton <davidnwelton@gmail.com> 
wrote:
>
> http://www.welton.it/davidw/
>
> http://www.dedasys.com/



--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

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.

Luca

È una discussione interessante: anche io penso che nodejs non sia una 
vera alternativa oggi come oggi.
Nota di colore: al corso ruby di cui vi avevo accennato qualche giorno 
fa c'è una buona affluenza, quasi nessuno l'aveva mai sentito nominare 
prima d'ora e diversi mi hanno chiesto di soffermarmi sull'aspetto della 
programmazione concorrente nella prossima lezione.

Inviato da Ipad

Sante Gennaro Rotondi
Responsabile ICT ─ CIO

dSmart srl
Via per Cernusco 1
20060 Bussero (Mi)
t +39 0297380504
m +39 393 6769152
skype: sante_dsmart
www.dsmart.it

Questa e-mail contiene informazioni strettamente confidenziali che non 
possono essere copiate, divulgate o aperte da chi non sia il 
destinatario finale (o ne sia direttamente autorizzato). Se avete 
ricevuto questa e-mail per errore vi preghiamo di informarci subito.

This E-mail is confidential and you must not disclose, copy, circulate 
or in any other way use the information it contains unless you are (or 
are authorised to receive it for) the intended recipient. If you have 
received this E-mail in error please inform us immediately

2012/11/11 Luca Guidi <guidi.luca@gmail.com>:
> 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)


http://akka.io/


--
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com

I miei tre cent:

1) La gestione della concorrenza diventerà sempre più importante ma non
è detto che Ruby sia il linguaggio più adatto per gestirla. I funzionali
sembrano avere dei vantaggi intrinseci, insieme allo svantaggio di
essere ostici alla maggior parte degli sviluppatori poiché che si sono
formati su linguaggi procedurali.

2) Anche se la tipica applicazione Rails a poco carico non avrà mai
problemi, avere un modo per scalare con il numero dei core disponibili
non ci farà male. Per Ruby in generale (quindi non solo Rails) toglierci
il GIL/GVL è un'assicurazione sul futuro.

3) MRI è l'implementazione di riferimento, ma sarebbe molto meglio avere
una definizione del linguaggio e un set di test per stabilire se
un'implementazione è realmente Ruby. Se non lo vogliono fare i developer
core di MRI possono farlo gli altri. Riuscirci significa incentivare
tutti a collaborare, anche MRI, perché i test di compliancy serviranno
anche a loro.

E una domanda:

Con MRI il nocciolo del mio workflow Rails è editare un file in emacs,
ricaricare la pagina e vedere se funziona. Con Java e Tomcat c'era di
mezzo una compilazione ed un deploy, una volta fatto a mano, poi gestito
in automatico da un IDE così bene da far quasi coincidere il workflow
con quello MRI/Rails. Per JRuby si deve tornare ad usare un'IDE come per
Java?

Grazie!
Paolo

Gabriele,
 lo stato globale a non rendere adatto il paradigma. Si pu comunque
arrivare allo scopo, ma con molta fatica.


2012/11/11 gabriele renzi <rff.rff@gmail.com>

Anche secondo me Ruby  ancora il linguaggio migliore per il web con cui 
mi
sono trovato a fare i conti finora (con poche eccezioni).

Il primo pregio in assoluto, e probabilmente la ragione principale del 
suo
successo tra le startup,  la rapidit con cui  possibile creare una
applicazione web complessa. Problemi di scalabilit come diceva bene 
David,
magari ad averli.

Quello che penso  che Rails e Ruby saranno la prima scelta ancora per un
bel p di tempo, ma il web sta cambiando, quindi meglio tenere gli occhi
aperti. Tra sei mesi avremo tutti un socket aperto per i server-side 
events
e magari i costi deployment si cominceranno a far sentire anche con 
pochi
utenti.

-f

2012/11/11 Luca Guidi <guidi.luca@gmail.com>