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.
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.
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?
È 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 R.
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
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.