In effetti Erlang ha delle potenzialit notevoli. Secondo me non ce la
far mai a sfondare finch non cambier sintassi per cammuffarsi da
linguaggio procedurale. A quel punto sar un linguaggio con un nome
diverso, ma meritano attenzione le performance del runtime ed il modo in
cui il Erlang ingloba il parallelismo.
Grazie, molto interessante.
La documentazione è quasi inesistente e per capire come fare certe cose
si deve guardare la directory dei test nel sorgente, ma pare proprio un
Erlang con un vestito procedurale addosso, e anche bello da vedere
Appena avrò tempo vedrò di compilarlo e fare qualche prova.
Ecco… il ‘re’ dell’event driven e Erlang, secondo me, e la vedi
che riesci a fare molto di piu con meno memoria rispetto a Rails, PHP o altri sistemi simili, perche non copia tutto il sistema con fork o
thread. Vale la pena darci un’occhiata per capire come funziona,
perche ha alcune idee molto interessanti, e molto diverse dal 'mainstream'. Poi... io ho dei dubbi sulle sue possibilita; non
credo che diventera un linguaggio molto usato, ma e comunque
qualcosa di notevole.
In effetti Erlang ha delle potenzialità notevoli. Secondo me non ce la
farà mai a sfondare finché non cambierà sintassi per cammuffarsi da
linguaggio procedurale. A quel punto sarà un linguaggio con un nome
diverso, ma meritano attenzione le performance del runtime ed il modo in
cui il Erlang ingloba il parallelismo.
Per i curiosi, poco più di un mese fa ho bloggato del mio impatto con la
sua sintassi. Ve lo indico anche se fargli pubblicità potrebbe essere
controproducente, perché scritto a caldo in presa diretta contiene di
sicuro un sacco di bestialità dovute all’ignoranza del linguaggio, ma lo
trovate a
Paolo
PS: scrivevate di websocket. Ho fatto delle prove e sicuramente sono
meglio dei metodi di push usati finora, però necessitano di un backend
che regga tutte le connessioni. Ecco perché ho iniziato a guardare
Erlang.
E allora tenta di limitare il numero di istanze, cosa che riesci a fare
profilando la codebase e limitando i tempi di risposta.
Voglio dire, Resque e affini ci sono da una vita, cos come soluzioni quasi
decenti per il caching, il minifying, nginx puo’ servire gli asset direttamente,
si puo’ usare gzip … di roba da fare per limitare i blocchi ai backend ce n’. Se
poi ancora lento si guarda altrove, ma almeno non si sta sparando nel mucchio e
il problema stato isolato.
Ovviamente alcuni problemi sono evidentemente difficili da risolvere con questo
modello, la “timeline” di Twitter un esempio.
Con Zooppa ho risolto con un servizietto in async_sinatra su EM e RabbitMQ, che
va benone. Ma ho sostituito una pagina con un servizio, ci ho messo 10 giorni,
non mi sono messo a riscrivere tutto usando node.js o erlang
Ho volutamente ignorato gli aspetti di caching e minifying perche’ mi
premeva di piu’ considerare le situazioni dinamiche.
Le soluzioni che ricerco sono proprio quelle in cui puoi aggiungere al
tuo arco le frecce di EM/queueing, penso tu abbia ragione sul fatto
che il miglior compromesso sia l’ibrido piuttosto che
l’implementazione event-driven di tutta la webapp.
E’ appena uscito un gran bel testo a riguardo: The art of Capacity Planning
della O’Reilly.
thx, lo aggiungo alla wish list
In ogni caso anche se applicazioni Comet-like dovessero essere il futuro, forse
meglio parlare di Websockets, a quel punto se le performance sono cos orrende
semplicemente scrivi un servizio in un’altra tecnologia che salta completamente
Rails e pusha sul browser direttamente.
certo, come hai detto prima vado giu’ di mini servizi EM-based.
grazie per le risposte e per la contestualizzazione con la tua
esperienza
