[erlang] the next java

[javaboy]

http://www.infoq.com/news/2007/08/erlang-java-for-concurrent-futur
Vi posto un articolo interessante (che in realtà nasce come commento ad un altro articolo che però solo i più volenterosi riusciranno a leggere).
Il linguaggio Erlang utilizza un "modello per la concorrenza" radicalmente diverso dai tradizionali linguaggi di programmazione e questo lo rende ideale per la programmazione di macchine multiprocessore che in futuro saranno sempre più comuni.
Al momento è un linguaggio assolutamente di nicchia, anche se stanno iniziando a nascere le prime applicazioni al di fuori del settore delle telecomunicazioni per il quale è stato creato. La chat di facebook ad esempio è stata programmata in Erlang.
Pensate che Erlang possa ritagliarsi uno spazio più ampio oppure anche nel settore delle applicazioni concorrenti dovrà cedere il passo a soluzioni più tradizionali come ad esempio stackless python?
Pensate che i linguaggi puramente funzionali come erlang siano realmente la soluzione più indicata per applicazioni concorrenti?
Probabilmente nessuno di noi per lavoro utilizzerà mai erlang ma studiarlo potrebbe essere una esperienza interessante in quanto completamente diverso dai linguaggi di programmazione che tutti utilizziamo quotidianamente.

Questo è il sito ufficiale:
http://erlang.org/

Questo è un webframework in erlang creato da uno degli sviluppatori di facebook:
http://erlyweb.org/

[shinya]

Erlang è sicuramente una piattaforma interessante (ma non posso dire di conoscerlo veramente quindi non posso non esprimermi solo superficialmente), ma che diventi il "nuovo Java" la vedo molto dura.
Il "nuovo Java" lo vedo più vicino a Scala; la transizione per il programmatore Java medio è molto più dolce.
Tra l'altro, nota a margine: è notizia recente che twitter abbia riscritto buona parte della sua infrastruttura usando Scala appunto (mandando a quel paese Ruby on Rails).

[PGI-Bis]

Come lingua non sembra neanche tanto male. Credo tuttavia che avrà più fortuna qualcosa tipo Scala.

I purismi non mi sembrano avere un grande successo nel campo dei linguaggi di programmazione. Prevalgono i misti. Forse perchè permettono a generazioni successive di programmatori di dialogare tra loro.

[dupa]

continuo a non capire perchè mai dovrei abbandonare Java EE (e come me altre N-mila programmatori/società) quando mi consente di fare, bene e rapidamente, tutto quello di cui ho bisogno.

poi figuriamoci che in ambito aziendale già spesso è difficile convincere qualcuno a passare a java5 da java 1.3/1.4.. figuriamoci a un altro linguaggio.

[javaboy]

continuo a non capire perchè mai dovrei abbandonare Java EE (e come me altre N-mila programmatori/società) quando mi consente di fare, bene e rapidamente, tutto quello di cui ho bisogno.

poi figuriamoci che in ambito aziendale già spesso è difficile convincere qualcuno a passare a java5 da java 1.3/1.4.. figuriamoci a un altro linguaggio.

Non credo che qualcuno pensi che erlang possa realmente diventare il nuovo java.
Tuttavia è innegabile che i linguaggi funzionali stiano pian piano guadagnando favori (la microsoft ha aggiunto alcune caratteristiche funzionali a C#, ha lanciato il linguaggio funzionale f#, python e ruby hanno parecchie caratteristiche dei linguaggi funzionali per non parlare di nuovi linguaggi come clojure e scala). Erlang inoltre è studiato per le applicazioni concorrenti che a causa dell'aumentare del numero di core diverranno sempre più diffuse.
Quando avremo computer con 256 core li programmeremo in java combattendo con i thread? Sinceramente ne dubito.
Probabilmente useremo qualche nuovo linguaggio che sicuramente non sarà erlang ma probabilmente ne erediterà parecchie caratteristiche.

[dupa]

Non credo che qualcuno pensi che erlang possa realmente diventare il nuovo java.
Tuttavia è innegabile che i linguaggi funzionali stiano pian piano guadagnando favori (la microsoft ha aggiunto alcune caratteristiche funzionali a C#, ha lanciato il linguaggio funzionale f#, python e ruby hanno parecchie caratteristiche dei linguaggi funzionali per non parlare di nuovi linguaggi come clojure e scala). Erlang inoltre è studiato per le applicazioni concorrenti che a causa dell'aumentare del numero di core diverranno sempre più diffuse.
Quando avremo computer con 256 core li programmeremo in java combattendo con i thread? Sinceramente ne dubito.
Probabilmente useremo qualche nuovo linguaggio che sicuramente non sarà erlang ma probabilmente ne erediterà parecchie caratteristiche.
Ma un qualunque application server Java EE, le richieste che arrivano tipicamente dai browser le elabora ognuna nel suo thread...

e poi cmq puoi pure fare multi-thread ma se l'applicazione ha transazioni con locking su righe/tabelle.. nn credo che sia il linguaggio che ti risolve sto problema.

[mindwings]

Ma un qualunque application server Java EE, le richieste che arrivano tipicamente dai browser le elabora ognuna nel suo thread...

e poi cmq puoi pure fare multi-thread ma se l'applicazione ha transazioni con locking su righe/tabelle.. nn credo che sia il linguaggio che ti risolve sto problema.

I linguaggi facilitano l'espressione di una soluzione - un linguaggio incarna sempre un modello concettuale :fagiano:

Tony Arcieri 1 (http://www.clickcaster.com/items/what-makes-erlang-so-great)

Tony Arcieri 2 (http://www.clickcaster.com/items/hi--i-m-the-actor-model---you-may-remember-me-from-such-models-as-oop)

[javaboy]

Ma un qualunque application server Java EE, le richieste che arrivano tipicamente dai browser le elabora ognuna nel suo thread...

e poi cmq puoi pure fare multi-thread ma se l'applicazione ha transazioni con locking su righe/tabelle.. nn credo che sia il linguaggio che ti risolve sto problema.

Beh chiaramente se il collo di bottiglia sono i locking su righe/tabelle penso ci sia poco da fare.
Erlang comunque ha due caratteristiche importanti:
1) I processi in erlang non corrispondono ai processi gestiti dal SO nè ai thread, sono estremamente più leggeri e gestiti dalla erlang VM. Come puoi vedere negli articoli postati da mindwings YAWS (web server scritto in erlang) regge 80.000 connessioni contemporanee contro le 4000 di apache.

2) La programmazione multithread tradizionale è quanto di più error prone si possa immaginare. Erlang grazie all'actor model, al fatto che non esistano letteralmente variabili, permette di programmare in maniera concorrente senza alcuno sforzo. Chiaramente, nel 90% delle applicazioni, Java rimarrà la scelta più sensata ma esistono delle situazioni per cui erlang calza a pennello.

[shinya]

Giusto per completezza: l'Actor Model non è una prerogativa di erlang, si può fare anche in Java. Alcuni link sull'argomento:

http://apocalisp.wordpress.com/2008/06/18/parallel-strategies-and-the-callable-monad/
http://apocalisp.wordpress.com/2008/06/30/parallel-list-transformations/
http://blog.tmorris.net/actor-concurrency-for-java/
http://functionaljava.org/

Questo per dire che non è obbligatorio impazzire con i thread in java per raggiungere un alto grado di concorrenza (ammesso che serva, tutta questa concorrenza).

Per quanto riguarda il lock di righe/tabelle sul db, questo è dovuto all'architettura stessa. In erlang si userebbe Mnesia come strumento di persistenza dei dati, che affronta questo tipo di problemi. Esistono soluzioni più o meno simili utilizzabili anche in Java, tipo Terracotta o CouchDB.