Forum: Italian Ruby user group Twitter, Ruby, Scala

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
7de465f222e6a9c7fe658e370d0bfe05?d=identicon&s=25 Paolo Montrasio (pmontrasio)
on 2009-04-09 10:10
Come saprete Twitter è un'applicazione scritta principalmente in Ruby on
Rails. Per ragioni varie stanno iniziando a spostare parte del backend
ad un'altra tecnologia chiamata Scala. A
http://www.artima.com/scalazine/articles/twitter_o... oltre
alle ragioni dello switch spiegano quelli che secondo loro i punti forti
e quelli deboli di Ruby. E' una lettura interessante.

Paolo
67f1108eabf701ed53b05a875e3d8203?d=identicon&s=25 Stefano Rodighiero (Guest)
on 2009-04-09 10:19
(Received via mailing list)
2009/4/9 Paolo Montrasio <paolo@paolomontrasio.com>:

> Come saprete Twitter è un'applicazione scritta principalmente in Ruby on
> Rails. Per ragioni varie stanno iniziando a spostare parte del backend
> ad un'altra tecnologia chiamata Scala. A
> http://www.artima.com/scalazine/articles/twitter_o... oltre
> alle ragioni dello switch spiegano quelli che secondo loro i punti forti
> e quelli deboli di Ruby. E' una lettura interessante.

si`, dopo un po' di cani menati per l'aia all'inizio dell'intervista,
ho trovato interessante il punto

"""
As our system has grown, a lot of the logic in our Ruby system sort of
replicates a type system,
either in our unit tests or as validations on models. I think it may
just be a property of large
systems in dynamic languages, that eventually you end up rewriting
your own type
system, and you sort of do it badly. You’re checking for null values
all over the place.
There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this
a kind of User object?
Because that’s what we’re expecting. If we don’t get that, this is
going to explode."
"""

s.
7ec76fde95878f95d7ae2e23cd99533e?d=identicon&s=25 Carlo Pecchia (cpecchia)
on 2009-04-09 10:24
(Received via mailing list)
I principali vantaggi di Scala, in questo caso, risiedono (IMHO) sulla
possibilità di fare deployment su batterie di JVM e sulla possibilità
di scrivere codice con paradigma funzionale (=> maggiori possibilità
di parallelismo). Il fatto dello static typing è, secondo me,
marginale: se scrivi del buon codice con Ruby non dovresti
preoccuparti dei tipi...


2009/4/9 Stefano Rodighiero <stefano.rodighiero@gmail.com>:
> ho trovato interessante il punto
> There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml
>



--
Carlo Pecchia
email: c.pecchia@gmail.com
twitter: @carlopecchia
6111b4012d1401ca83fdcea6b1d71237?d=identicon&s=25 Antonio Cangiano (Guest)
on 2009-04-09 15:03
(Received via mailing list)
2009/4/9 Carlo Pecchia <c.pecchia@gmail.com>:
> I principali vantaggi di Scala, in questo caso, risiedono (IMHO) sulla
> possibilità di fare deployment su batterie di JVM e sulla possibilità
> di scrivere codice con paradigma funzionale (=> maggiori possibilità
> di parallelismo). Il fatto dello static typing è, secondo me,
> marginale: se scrivi del buon codice con Ruby non dovresti
> preoccuparti dei tipi...

Concordo con quanto scrive Carlo e aggiungo anche che Scala è un
linguaggio molto veloce che rende la programmazione parallela più
semplice tramite il modello ad attori, già largamente adottato da
Erlang. Per il backend di un servizio web che serve milioni di
richieste al giorno un linguaggio come Scala o Erlang è sicuramente
più indicato di Ruby. Non c'è nulla di male nel dirlo. Bisogna sempre
scegliere gli strumenti migliori per il tipo di lavoro richiesto.

In campo internazionale mi sono astenuto dal partecipare nella
discussione, per evitare di creare ulteriore ado about nothing. Ho
solamente fatto una battuta su Twitter circa il fatto che Twitter ha
ancora problemi di scalabilità e posto la domanda retorica "accusiamo
Scala questa volta?". La battuta vuole prendere in giro quelli che
hanno subito accusato Ruby per i problemi di Twitter. In realtà Ruby
on Rails può essere scalato senza troppi problemi. Sono le scelte di
architettura che hanno la maggiore influenza, non tanto i linguaggi o
i framework utilizzati.

Detto questo, usare Ruby per implementare il sistema di queue di un
servizio web che serve migliaia di richieste contemporanee ogni
secondo, è ovviamente una scelta poco oculata. Andava bene come primo
prototipo, per partire alla svelta, ma rimanere su Ruby per il
back-end, ora che sono uno dei più grandi siti al mondo, con milioni
di dollari di finanziamenti, non ha molto senso.

In tre parole: hanno fatto bene.

Ciao,
Antonio
--
http://antoniocangiano.com - Zen and the Art of Programming
http://math-blog.com - Mathematics is wonderful!
http://stacktrace.it - Aperiodico di resistenza informatica
Follow me on Twitter: http://twitter.com/acangiano
Author of "Ruby on Rails for Microsoft Developers":
http://bit.ly/rorforms
114ff87909d3f24150ff3d70d5254338?d=identicon&s=25 Luca Guidi (Guest)
on 2009-04-09 15:43
(Received via mailing list)
Antonio, io concordo in pieno e sottoscrivo ogni tua parola, quello che
mi ha dato fastidio è questo:

"We're still happy with Rails for building user facing features...
performance-wise, it's fine for people clicking around web pages. It's
the heavy lifting, asynchronous processing type of stuff that we've
moved away from." (http://bit.ly/2F4x8)

Cioè Rails è un giocattolo.



E ancora:
"There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a
kind of User object? Because that’s what we’re expecting. If we don’t
get that, this is going to explode.” It is a shame to have to write all
that when there is a solution that has existed in the world of
programming languages for decades now." (http://bit.ly/BdqG)

Cioè adottiamo Scala perché col weak typing di Ruby facciamo casini.



"But the JVM is very good at that, because it’s been optimized for that
over the last ten years." (http://bit.ly/BdqG)

.. JRuby?



Io ho l'impressione che abbiano a) voglia di stupire con scelte
coraggiose e b) sopperire a delle incapacità tecniche con un linguaggio
oggettivamente più prestante.

Ripeto, hanno fatto bene. Bisogna essere pragmatici nelle scelte e
valutare le tecnologie in base alle proprie esigenze. Ma rimango un po'
deluso da post come questi: Twitter should move away from Ruby (Dave
Thomas http://bit.ly/10BZVD).


Vedo questi due episodi come un pericoloso precedente. Non so lì in
Canada, ma qui in Italia c'è ancora una profonda arretratezza
tecnologica, e solo qualche CTO più "coraggioso" permette in via
sperimentale l'utilizzo di Rails.

Ora già immagino frasi del tipo: "Twitter ha preferito Scala e Dave
Thomas gli ha dato ragione.."

Senza contare che non tutti siamo Twitter e non dobbiamo gestire
migliaia di richieste al secondo.

Luca
6111b4012d1401ca83fdcea6b1d71237?d=identicon&s=25 Antonio Cangiano (Guest)
on 2009-04-09 15:59
(Received via mailing list)
On Thu, Apr 9, 2009 at 9:42 AM, Luca Guidi <guidi.luca@gmail.com> wrote:
> "We're still happy with Rails for building user facing features...
> performance-wise, it's fine for people clicking around web pages. It's
> the heavy lifting, asynchronous processing type of stuff that we've
> moved away from." (http://bit.ly/2F4x8)
>
> Cioè Rails è un giocattolo.

Sì, la scelta tecnica è corretta, ma il modo in cui l'hanno
presentata, è finito col danneggiare Rails.

> E ancora:
> "There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a
> kind of User object? Because that’s what we’re expecting. If we don’t
> get that, this is going to explode.” It is a shame to have to write all
> that when there is a solution that has existed in the world of
> programming languages for decades now." (http://bit.ly/BdqG)
>
> Cioè adottiamo Scala perché col weak typing di Ruby facciamo casini.

Questa non ha senso. Si tratta di un'ammissione di colpa. Facevano
prima a dire "non sappiamo programmare in linguaggi dinamici".

> "But the JVM is very good at that, because it’s been optimized for that
> over the last ten years." (http://bit.ly/BdqG)
>
> .. JRuby?

Sì.
> Io ho l'impressione che abbiano a) voglia di stupire con scelte
> coraggiose e b) sopperire a delle incapacità tecniche con un linguaggio
> oggettivamente più prestante.

Penso di sì. Tieni anche presente che al3x è un grosso fan di Scala e
sta scrivendo un buon libro a riguardo, che dovrà pur essere venduto a
qualcuno. ;-)

> Ora già immagino frasi del tipo: "Twitter ha preferito Scala e Dave
> Thomas gli ha dato ragione.."
>
> Senza contare che non tutti siamo Twitter e non dobbiamo gestire
> migliaia di richieste al secondo.

Concordo con te. Episodi come questi, o la scappata di Zed, hanno
sicuramente ridotto l'immagine di Rails negli occhi delle persone meno
informate. Un danno purtroppo. Ripeto, scelta tecnica azzeccata, ma
concordo con te che il modo in cui hanno annunciato la cosa fa molto
"Rails non scala", 2005 circa.

Ciao,
Antonio
--
http://antoniocangiano.com - Zen and the Art of Programming
http://math-blog.com - Mathematics is wonderful!
http://stacktrace.it - Aperiodico di resistenza informatica
Follow me on Twitter: http://twitter.com/acangiano
Author of "Ruby on Rails for Microsoft Developers":
http://bit.ly/rorforms
9daa9b4739a6e95078cbcfb624d7bb8e?d=identicon&s=25 David Welton (Guest)
on 2009-04-09 15:59
(Received via mailing list)
> Vedo questi due episodi come un pericoloso precedente. Non so lì in
> Canada, ma qui in Italia c'è ancora una profonda arretratezza
> tecnologica, e solo qualche CTO più "coraggioso" permette in via
> sperimentale l'utilizzo di Rails.
>
> Ora già immagino frasi del tipo: "Twitter ha preferito Scala e Dave
> Thomas gli ha dato ragione.."

Se hanno paura di una "novita`" come Rails, allora come vedranno
Scala?  Meno programmatori, meno libri, meno tutto, *tranne*, quei
benefici (librerie, soprattutto) che hai grazie alla JVM.

In ogni caso, sono sempre piu` convinto della strada "fai una tua
azienda/sito/quello che e`" se sei veramente convinto che qualcosa ti
da` cosi` tanto vantaggio, ma quello e` un altro discorso.

--
David N. Welton

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

http://www.dedasys.com/
114ff87909d3f24150ff3d70d5254338?d=identicon&s=25 Luca Guidi (Guest)
on 2009-04-09 16:08
(Received via mailing list)
David Welton wrote:
> Se hanno paura di una "novita`" come Rails, allora come vedranno
> Scala?  Meno programmatori, meno libri, meno tutto, *tranne*, quei
> benefici (librerie, soprattutto) che hai grazie alla JVM.
Io non intendevo dire che preferiranno Scala a Ruby, ma semplicemente
che rimarrano sulla strada di Java, sorridendo tra loro, e
beatificandosi del fatto che le loro scelte difensive alla fine hanno
pagato: "Siamo stati a guardare, Ruby/Rails non ce l'ha fatta, il tempo
ci ha dato ragione".

Ciao,
Luca
7ec76fde95878f95d7ae2e23cd99533e?d=identicon&s=25 Carlo Pecchia (cpecchia)
on 2009-04-09 16:13
(Received via mailing list)
Quello che più mi "preoccupa" (parola grossa) è la risposta
disarticolata della community Ruby/Rails a tutto ciò. Al di là dei
vari ed inevitabili flame gli unici atti concreti che ricordo sono:
 - i benchmark di Antonio sulle varie implementazioni ruby
 - gli screencasts di Gregg Pollack sulla scalabilità di Rails


Il 9 aprile 2009 16.08, Luca Guidi <guidi.luca@gmail.com> ha scritto:
> Ciao,
> Luca
> --
> blog: www.lucaguidi.com
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml
>



--
Carlo Pecchia
email: c.pecchia@gmail.com
twitter: @carlopecchia
114ff87909d3f24150ff3d70d5254338?d=identicon&s=25 Luca Guidi (Guest)
on 2009-04-09 16:27
(Received via mailing list)
Carlo Pecchia wrote:
> Quello che più mi "preoccupa" (parola grossa) è la risposta
> disarticolata della community Ruby/Rails a tutto ciò. Al di là dei
> vari ed inevitabili flame gli unici atti concreti che ricordo sono:
>   - i benchmark di Antonio sulle varie implementazioni ruby
>   - gli screencasts di Gregg Pollack sulla scalabilità di Rails

Carlo, quello che "preoccupa" me è il linguaggio. I benchmark di Antonio
sono un importante punto di riferimento sulle prestazioni delle varie
implementazioni. Ma dobbiamo ammettere che tutti i linguaggi dinamici (a
causa delle loro VM) hanno seri problemi con i long running processes e
che la JVM è il top nel gestire questo tipo di
necessità.
Abbiamo server che hanno decine di processori, dobbiamo poter sfruttare
questo ben di Dio! Il tanto acclamato Ruby 1.9 introduce i thread nativi
(era ora!) e li blocca con il GIL. Ma scherziamo? L'unico a difendere la
scelta è Guido Von Rossum, perché Python ha fatto lo stesso.

Credo che una soluzione a questo punto sia adottare LLVM, come sta
facendo il team di MacRuby.

Ciao,
Luca
6111b4012d1401ca83fdcea6b1d71237?d=identicon&s=25 Antonio Cangiano (Guest)
on 2009-04-09 16:38
(Received via mailing list)
2009/4/9 Luca Guidi <guidi.luca@gmail.com>:
> Credo che una soluzione a questo punto sia adottare LLVM, come sta
> facendo il team di MacRuby.

Un simpatico aneddoto. L'altra notte l'autore di MacRuby e io stavamo
giocando un po' con alcuni micro-benchmark. Lui provava in Ruby e io
li trasformavo in Scala. Scala è ovviamente più veloce, ma MacRuby si
difendeva abbastanza bene. Nel caso del fattoriale (senza tail
recursion optimization) con numeri molto grandi (f(30000)), MacRuby
impiegava metà del tempo di Scala. Ovviamente questo non significa
nulla (probabilmente BigInt in Java è lentino). Scala è molto più
veloce, punto. Però è interessante vedere come un approccio basato
sulla LLVM, con le ottimizzazioni giuste, possa fornire risultati
promettenti. Tra l'altro se provi f(30_0000) con Ruby 1.9, ti manda a
quel paese. ;)

Ciao,
Antonio
--
http://antoniocangiano.com - Zen and the Art of Programming
http://math-blog.com - Mathematics is wonderful!
http://stacktrace.it - Aperiodico di resistenza informatica
Follow me on Twitter: http://twitter.com/acangiano
Author of "Ruby on Rails for Microsoft Developers":
http://bit.ly/rorforms
114ff87909d3f24150ff3d70d5254338?d=identicon&s=25 Luca Guidi (Guest)
on 2009-04-09 17:36
(Received via mailing list)
Failure whalefire: http://etherbrian.org/tweet/ :)
42651926eec2d760f10c78bcb473e5e3?d=identicon&s=25 Fabrizio Regini (Guest)
on 2009-04-10 01:29
(Received via mailing list)
Ciao a tutti,

Il giorno 09/apr/09, alle ore 15:42, Luca Guidi ha scritto:

>
> Vedo questi due episodi come un pericoloso precedente. Non so lì in
> Canada, ma qui in Italia c'è ancora una profonda arretratezza
> tecnologica, e solo qualche CTO più "coraggioso" permette in via
> sperimentale l'utilizzo di Rails.

sto seguendo con molto interesse questo thread. La mia società ha
iniziato a lavorare con Rails un paio di anni fa. Non è stata una
scelta facile. Ricordo il primo commit di una applicazione Rails nel
nostro repo come un momento importante, una pietra miliare, una svolta
epocale. I mesi precedenti avevamo condotto uno studio mettendo a
confronto vari framework di sviluppo. Eravamo fan di python (e lo
siamo ancora) ma Rails era un'altra cosa rispetto a Django, e Ruby
"non era poi così male" (a quel tempo "metaprogrammazione" era per noi
un errore di battitura).
La scelta ha pagato, in termini di gratificazione e di qualità del
lavoro. Il destino ha voluto molti dei progetti che ci hanno dato il
pane finora non ponessero vincoli architetturali particolari, e quindi
abbiamo potuto lasciarci i sorrisini sarcastici alle spalle e
procedere per la nostra strada con Ruby on Rails.
Rails si è guadagnato la nostra fiducia piena.
Eppure... il fatto che Twitter abbia scelto Scala, anche solo per un
componente, ha insinuato il seme del dubbio nel team. Si sà, quando i
simboli cadono fanno sempre molto rumore.
Stiamo per intraprendere un importante progetto internazionale, frutto
dello studio di quasi un anno, e la scalabilità è stata un argomento
fin dall'inizio.
Il mio capo (grande fan di Rails pure lui) l'altro giorno viene e mi
dice: " ...visto, Twitter alla fine ha dovuto usare Java... Rails non
ce l'ha fatta...".
Lo capisco. Stiamo investendo molto in questo progetto e la tensione è
alta. Mettici pure che non possiamo far crescere il team perchè non
riusciamo a trovare programmatori Rails! (a proposito, tra poco mi
permetterò di pubblicare un annuncio nella lista).

Mi sono dilungato solo per dire: e' vero, il dubbio è sempre dietro
l'angolo. Non ho niente contro Java, se rinasco programmatore magari
ci lavoro pure. Ma possibile che per gestire una stringa di 144
caratteri bisognava scomodare Scala? (e non credo che Twitter abbia
lesinato sull'hardware). Mi puzza poco poco di trovata pubblicitaria,
ma parlo da ignorante.

Mi piace in occasioni simili citare le parole del mio primo direttore
tecnico: "Il mare dell'infromatica è pieno di sirene".
Si riferiva a quelle di Ulisse, non a quele della guardia costiera,
ovviamente.

Noi serriamo i ranghi e continuiamo per la nostra strada. Appena
toccheremo i limiti di Rails condivideremo l'evento con questa lista.

Saluti e scusate se sono andato off-topic,

Fabrizio Regini
7ec76fde95878f95d7ae2e23cd99533e?d=identicon&s=25 Carlo Pecchia (cpecchia)
on 2009-04-10 08:53
(Received via mailing list)
Salve,
ho trovato il tuo post interessante.

Ritengo che in un'architettura complessa, come quella che può stare
dietro Twitter, problemi di scalabilità si presentano a più livelli:
rendering delle pagine, accesso al DB, e così via...

Pertanto la scelta di riscrivere qualche componente con Scala (o
Erlang, o Java, o C++, ...) la trovo del tutto ragionevole. Del resto
il front-end è *rimasto* su Rails.

Problemi simili si presentano anche in altri casi, se hai avuto modo
di dare un'occhiata al progetto Redis
(http://zzimma.antirez.com/post/Redis---REmote-DIct...)
ti rendi conto di come, in alcuni casi, persino un DB "performante"
(come potrebbe essere MySQL) non è adatto al tuo scopo... e allora
"riparti da zero" ed implementi una soluzione in C :) !

Diatribe come queste (quasi da discussione da bar dello sport) sulla
scalabilità di un framework/linguaggio verso un altro sono e
resteranno all'ordine del giorno.

Buona giornata!


Il 10 aprile 2009 1.28, Fabrizio Regini <fabrizio.regini@exelab.eu> ha
scritto:
> sto seguendo con molto interesse questo thread. La mia società ha
> pane finora non ponessero vincoli architetturali particolari, e quindi
> dice: " ...visto, Twitter alla fine ha dovuto usare Java... Rails non
> ma parlo da ignorante.
>
> Fabrizio Regini
>
>
>
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml
>



--
Carlo Pecchia
email: c.pecchia@gmail.com
twitter: @carlopecchia
05720447a341aaffb8827039df3931df?d=identicon&s=25 Luca Mearelli (Guest)
on 2009-04-10 09:54
(Received via mailing list)
dunque:

2009/4/10 Fabrizio Regini <fabrizio.regini@exelab.eu>:
> Mi sono dilungato solo per dire: e' vero, il dubbio è sempre dietro
> l'angolo. Non ho niente contro Java, se rinasco programmatore magari
> ci lavoro pure.

 usare la JVM NON equivale ad usare Java, per esempio una delle
implementazioni di ruby piu efficienti e' JRuby che gira appunto sulla
JVM (vedi i vari benchmark oppure, ancora meglio, prova e misura le
tue applicazioni rails su JRuby :-) ). Lo stesso scala e' molto
diverso da Java.

>Ma possibile che per gestire una stringa di 144
> caratteri bisognava scomodare Scala? (e non credo che Twitter abbia
> lesinato sull'hardware).

twitter non e' un CMS o una piattaforma di microblog (o almeno non e'
solo quello), per le sue dinamiche ed alla dimensione che ha, twitter
pone sfide architetturali interessanti, che non avrebbe senso
affrontare in maniera monolitica ma usando lo strumento giusto per
ciascun componente.

Che poi l'uscita di al3x e degli altri di twitter sia stata infelice
e' evidente ma credo sia stata piu' dovuta ad "ignoranza" (del modo di
esporre certe scelte per evitare polemiche) che a "malizia"

Infine (non vorrei sollevare un polverone, ma mi piacerebbe sapere
cosa ne pensate :-) ) non capisco molto le critiche sulla loro
affermazione che "dovevano usare il kind_of?" perche' mi pare che
ignorino il fatto che non sappiamo abbastanza del contesto in cui
questa "worst practice" ha dovuto essere usata. Non sappiamo ad
esempio come il codice di twitter si e' evoluto, non sappiamo quanto
sia "antico" il codice che genera i problemi ma possiamo immaginare
che possa essere piuttosto "complesso" ed "incasinato", visto che
twitter si e' evoluto da un "side project", che non avevano previsto
la direzione in cui gli utenti lo avrebbero fatto evolvere, che quando
hanno avuto problemi di scalabilita' hanno forse avuto la necessita di
mettere pezze senza avere il tempo di fare inteventi "ragionati" (un
po' come riparare un treno in corsa).
Il contesto puo' dettare delle esigenze che non permettono di creare
il codice come vorremmo o come idealmente dovremmo fare ed una "worst
practice" e' a volte l'unica "practice" a disposizione che puo
permettere di migliorare un sistema :-(

ciao,
Luca
9daa9b4739a6e95078cbcfb624d7bb8e?d=identicon&s=25 David Welton (Guest)
on 2009-04-14 11:19
(Received via mailing list)
> Carlo, quello che "preoccupa" me è il linguaggio. I benchmark di Antonio
> sono un importante punto di riferimento sulle prestazioni delle varie
> implementazioni. Ma dobbiamo ammettere che tutti i linguaggi dinamici (a
> causa delle loro VM) hanno seri problemi con i long running processes e
> che la JVM è il top nel gestire questo tipo di necessità.

Questo non e` del tutto corretto - Tcl, per esempio, pur non essendo
velocissimo, non ha alcun problema a gestire processi che rimangono in
vita per dei mesi.  Ha una buona gestione dei thread (non esiste il
lock globale) e degli eventi.  Non so se contare Erlang come
'linguaggio dinamico' anche se non ha un sistema di tipi, ma e` uno
dei linguaggi piu` affidabili per un 'long running process' che ci sia
(viene dal mondo della telefonia).

Insomma... non e` che bisogna necessariamente puntare sul JVM, anche
se e` sicuramente una scelta con dei vantaggi noti.

--
David N. Welton

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

http://www.dedasys.com/
Sent from Padova, PD, Italy
7de465f222e6a9c7fe658e370d0bfe05?d=identicon&s=25 Paolo Montrasio (pmontrasio)
on 2009-04-14 20:32
Luca Guidi wrote:
> Antonio, io concordo in pieno e sottoscrivo ogni tua parola, quello che
> mi ha dato fastidio è questo:
>
> "We're still happy with Rails for building user facing features...
> performance-wise, it's fine for people clicking around web pages. It's
> the heavy lifting, asynchronous processing type of stuff that we've
> moved away from." (http://bit.ly/2F4x8)
>
> Cioè Rails è un giocattolo.
>

No dai, non deprimiamoci così, perché in fondo non hanno detto questo.
Proviamo a dare a Cesare quel che è di Cesare: loro hanno detto che per
certe applicazioni Rails è la cosa migliore che hanno per le mani,
mentre per altre sono maggiormente adatti strumenti differenti.

Nel mio piccolo, l'avevo scoperto anch'io due anni e mezzo fa quando
riscrivendo una query come stored procedure avevo ottenuto un x4.25 di
performance rispetto ad usare ActiveRecord. Dettagli a
http://ilconnettivo.wordpress.com/2006/09/26/bench...
ma non è importante.

Fatta la scoperta non avevo però pensato che AR fosse un giocattolo,
dato il tempo che mi fa risparmiare nella prograzione di ogni accesso al
db. Semplicemente avevo scoperto che sotto un carico pesante potrebbe
aver senso ottimizzare ricorrendo ad altri linguaggi. Non mi è mai
capitato (purtroppo?) e quindi sono felice con AR. Per le stesse ragioni
anche certe aree dei sistemi operativi non sono scritte in C ma in
linguaggio macchina e non per questo si dice che il C è un giocattolo
(almeno dal punto di vista delle performance).

Concludo: ci stanno dicendo che Rails è una best practice per certe
applicazioni e non per altre. Per il backend anch'io tante volte ho un
mix di Ruby, shell, Perl e Java. Poiché un linguaggio/framework
universale non è mai esistito, sono più che felice di usare lo strumento
giusto per lo sviluppo dei front end delle applicazioni web (il pezzo
tra il db e l'utente) mentre per il resto vado ad usare quel che è più
pratico/performante.

Paolo
This topic is locked and can not be replied to.