Mescolando Erlang e Haskell

Question

Se hai acquistato nel paradigma di programmazione funzionale, è probabile che ti piace sia Erlang e Haskell. Entrambi hanno nuclei puramente funzionali e altre bontà come i fili leggeri che li rendono una buona misura per un mondo multipolare fanno. Ma ci sono alcune differenze troppo.

Erlang è un linguaggio di fault-tolerant commercialmente collaudato con un modello di distribuzione maturo. Ha una caratteristica apparentemente unico nella sua capacità di aggiornare la sua versione in fase di esecuzione tramite codice carico caldo. (Way cool!)

Haskell, sulla otherhand, ha il più sofisticato sistema di tipo di qualsiasi linguaggio mainstream. (Dove definisco 'corrente principale' essere qualsiasi linguaggio che ha un libro O'Reilly pubblicate Haskell conta.) Il suo rettilineo singola performance filettato sembra superiore a Erlang e dei suoi fili leggeri sembrare ancora più leggero anche.

Sto cercando di mettere insieme una piattaforma di sviluppo per il resto della mia vita codifica e chiedevo se fosse possibile mescolare Erlang e Haskell per ottenere una migliore piattaforma di razza. Questa domanda ha due parti:

1. Mi piacerebbe usare Erlang come una sorta di tolleranza di errore MPI per incollare le istanze di runtime GHC insieme. Ci sarebbe un processo di Erlang per GHC runtime. Se "l'impossibile è accaduto" e il runtime GHC sono morti, allora il processo di Erlang rileverebbe che in qualche modo e muoiono troppo. CARATTERISTICHE Codice di carico e di distribuzione a caldo di Erlang sarebbe solo continuare a lavorare. Il runtime GHC può essere configurato per utilizzare solo un core, o tutti i core sulla macchina locale, o qualsiasi combinazione intermedia. Una volta che la libreria di Erlang è stato scritto, il resto del codice di livello Erlang dovrebbe essere puramente boilerplate e generato automaticamente in base all'applicazione. (Forse da una DSL Haskell, per esempio). Come si fa a raggiungere almeno alcune di queste cose?
2. Mi piacerebbe Erlang e Haskell per essere in grado di condividere lo stesso collettore garabage. (Questa è un'idea molto più lontano di quanto 1.) Lingue eseguito sulla JVM e il CLR ottenere una maggiore massa attraverso la condivisione di un runtime. Capisco che ci sono limitazioni tecniche per l'esecuzione di Erlang (codice di carico caldo) e Haskell (più alto polimorfismo kinded) su entrambi JVM o CLR. Ma per quanto riguarda la disaggregazione solo il garbage collector? (Sorta di l'inizio di un runtime per linguaggi funzionali.) Assegnazione sarebbero ovviamente devono ancora essere veramente veloce, così forse quel po 'ha bisogno di essere staticamente collegati. E ci dovrebbe essere qualche mechansim distinguere il mucchio mutabile dal mucchio immutabili ( incuding scrittura lenta una volta memoria) come GHC ha bisogno di questo. Sarebbe possibile modificare sia HIPE e GHC in modo che i netturbini potrebbero condividere un mucchio?

Si prega di rispondere con esperienze (positive o negative), idee o suggerimenti. In realtà, tutte le risposte (a corto di abusi dritto!) È il benvenuto.

Aggiorna

Grazie per tutte le 4 risposte fino ad oggi -. Ognuno mi ha insegnato almeno una cosa utile che non sapevo

Per quanto riguarda la il resto della vita di codifica cosa - ho inserito leggermente lingua nella guancia per suscitare il dibattito, ma in realtà è vero. C'è un progetto che ho in mente che ho intenzione di lavorare su fino alla morte, e ha bisogno di una piattaforma stabile.

Nella piattaforma ho proposto in precedenza, avrei scrivere solo Haskell, come boilerplate sarebbe generato automaticamente Erlang. Quindi, quanto tempo durerà Haskell? Bene Lisp è ancora con noi e non sembra come sta andando via in qualunque momento presto. Haskell è BSD3 open source e ha raggiunto la massa critica. Se la programmazione stessa è ancora in giro in 50 anni di tempo, mi aspetterei Haskell, o qualche continua evoluzione di Haskell, sarà ancora qui.

Update 2 in risposta al post di rvirding

D'accordo - l'attuazione di un "Erskell / Haslang" macchina completa virtuale universale potrebbe non essere assolutamente impossibile, ma sarebbe certamente molto difficile. Condivisione just il livello garbage collector come qualcosa di simile a una macchina virtuale, pur difficile , viene emesso un ordine di grandezza meno difficile per me però. Al modello di raccolta dei rifiuti, linguaggi funzionali devono avere molto in comune - l'unbiquity dei dati immutabili (compresi thunk) e l'obbligo per l'allocazione molto veloce. Quindi il fatto che comunanza è fornito in bundle con strettamente monolitico VM sembra un po 'strano.

VM non contribuire al raggiungimento di una massa critica. Basta guardare a come linguaggi funzionali 'Lite' come F # e Scala hanno tolto. Scala non può avere la tolleranza ai guasti assoluta di Erlang, ma offre una via di fuga per le moltissime persone che sono legati alla JVM.

  

Mentre avere un unico mucchio marche   scambio di messaggi è molto veloce   introduce una serie di altri problemi,   soprattutto che facendo GC diventa più   difficile come deve essere interattivo   e globalmente non-intrusive in modo da   non possono utilizzare gli stessi algoritmi più semplici   come il modello mucchio per-processo.

Assolutamente, questo ha perfettamente senso per me. Le persone molto intelligenti del team di sviluppo GHC sembrano essere cercando di risolvere parte del problema con un parallelo "fermare il mondo" GC.

http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf

(Ovviamente "fermare il mondo" non sarebbe volare in generale Erlang dato il suo caso d'uso principale.) Ma anche nei casi d'uso in cui "fermare il mondo" va bene, i loro incrementi nella velocità non sembrano essere universale. Quindi sono d'accordo con te, è improbabile che ci sia una migliore universalmente GC, che è il motivo per cui ho specificato nella parte 1. della mia domanda che

  

Il runtime GHC può essere configurato per   utilizzare solo un core, o tutti i core sulla   macchina locale, o qualsiasi combinazione di   tra i.

In questo modo, per un dato caso d'uso, ho potuto, dopo l'analisi comparativa, scegliere di andare via Erlang, ed eseguire una fase di esecuzione GHC (con un GC singlethreaded) più un processo di Erlang per core e lasciare Erlang memoria copia tra i core per una buona località.

In alternativa, su una macchina biprocessore con 4 core per processore con buona larghezza di banda di memoria sul processore, comparativa potrebbe suggerire che corro un GHC runtime (con GC parallelo) più un processo Erlang per processore.

In entrambi i casi, se Erlang e GHC potrebbero condividere un mucchio, la condivisione sarebbe probabilmente essere vincolati ad un singolo thread del sistema operativo in esecuzione su un singolo core in qualche modo. (Io sono sempre fuori dalla mia profondità qui, che è il motivo per cui ho fatto la domanda.)

Ho anche un altro ordine del giorno - il benchmarking linguaggi funzionali indipendentemente da GC. Spesso ho letto di risultati di benchmark di OCaml v GHC v Erlang v ... e chiedo quanto i risultati sono confusi dai diversi GC. E se la scelta di GC potrebbe essere ortogonale alla scelta di linguaggio funzionale? Quanto costa GC comunque? Vedere questo sostenitori diavolo post del blog

http://john.freml.in/garbage-collection-harmful

dal mio amico John Lisp Fremlin, che ha, affascinante, dato il suo titolo post "garbage collection automatica è spazzatura". Quando John sostiene che GC è lento e non ha davvero accelerato più di tanto, mi piacerebbe essere in grado di contrastare con alcuni numeri.

Answer 1

Un sacco di Haskell e Erlang persone sono interessati al modello in cui Erlang supervisiona la distribuzione, mentre Haskell esegue i nodi di memoria condivisa in parallelo facendo tutte le macinare numeri / logica.

Un inizio in questa direzione è la libreria Haskell-Erlang: http://hackage.haskell.org/package / erlang

E abbiamo sforzi simili in terra Ruby, via Hubris: http://github.com/ mwotton / Hubris / albero / master

Il problema adesso è quello di trovare qualcuno per spingere in realtà attraverso l'Erlang / Haskell interoperabilità per scoprire le questioni spinose.

Answer 2

Si sta andando ad avere un momento interessante di miscelazione GC tra Haskell e Erlang. Erlang usa un mucchio e copia i dati per processo tra processi - come Haskell non ha nemmeno un concetto di processi, io non sono sicuro di come si potrebbe mappare questo GC "universale" tra i due. Inoltre, per le migliori prestazioni, Erlang utilizza una varietà di ripartitori, ciascuno con comportamenti leggermente modificato che sono sicuro che possa modificare il sotto-sistema GC.

Come tutte le cose nel software, l'astrazione ha un costo. In questo caso, io piuttosto il sospetto che avrebbe dovuto introdurre tanti strati per ottenere entrambe le lingue oltre la loro disadattamento di impedenza che ti sentiresti di vento con un non molto performante (o utile) comune VM.

La linea di fondo - abbracciare la differenza! Ci sono enormi vantaggi NON esecuzione tutto nello stesso processo, in particolare dal punto di vista dell'affidabilità. Inoltre, penso che sia un po 'ingenuo aspettarsi una lingua / VM per durare per il resto della tua vita (a meno che non si ha intenzione di a.) Vivere un breve periodo di tempo o b.), Diventando una sorta di codice di monaco che funziona solo su una singolo progetto). Lo sviluppo del software è tutto di agilità mentale e di essere disposti a utilizzare i migliori strumenti disponibili per costruire veloce, il codice affidabile.

Answer 3

Anche se questo è un filo piuttosto vecchio, se i lettori sono ancora interessati allora vale la pena dare un'occhiata a Nuvola Haskell , che porta la concorrenza e la distribuzione Erlang stile alla stalla GHC.

Il prossimo distribuito-processo-platform biblioteca aggiunge il supporto per OTP-esque costrutti come gen_servers, alberi di supervisione e varie altre astrazioni "Haskell aromatizzati" presi in prestito da e ispirati da Erlang / OTP.

Answer 4

1. Si potrebbe utilizzare un processo gen_supervisor OTP per monitorare le istanze Haskell che Spawn con open_port (). A seconda di come la "porta" è uscito, si dovrebbe quindi essere in grado di riavviarlo o decidere che si è fermato di proposito e lasciare che il corrispondente processo di Erlang morire, anche.

2. Fugheddaboudit. Anche questi VM indipendente dal linguaggio di cui parli hanno problemi con i dati passati tra le lingue a volte. Si dovrebbe solo serializzare i dati tra i due in qualche modo:. Database XML-RPC, qualcosa del genere

Tra l'altro, l'idea di una piattaforma unica per il resto della tua vita è probabilmente impraticabile, anche. Tecnologie informatiche e il cambiamento della moda troppo spesso aspettarsi che si può continuare a utilizzare una sola lingua per sempre. I suoi punti di domanda molto questo:. Non una lingua fa tutto si potrebbe desiderare, anche oggi

Answer 5

Come dizzyd menzionato nel suo commento non tutti i dati nei messaggi vengono copiati, grandi binari esistono al di fuori dei cumuli di processo e non vengono copiati.

Utilizzo di una struttura di memoria diversa per evitare di dover separati cumuli per-processo è certamente possibile ed è stato fatto in un certo numero di implementazioni precedenti. Pur avendo un unico mucchio rende il passaggio di messaggi molto in fretta che introduce una serie di altri problemi, soprattutto che facendo GC diventa più difficile in quanto deve essere interattivo e globale non-intrusive quindi non è possibile utilizzare il stessi algoritmi più semplici come il modello mucchio per-processo.

Finché usare avere data-strutture immutabili non c'è nessun problema con la robustezza e la sicurezza. Decidere su quali modelli di memoria e GC da utilizzare è un grande trade-off, e purtroppo ci universalmente modello migliore.

Mentre Haskell e Erlang sono entrambi linguaggi funzionali sono in molti aspetti molto diverse lingue e sono molto diverse implementazioni. Sarebbe difficile trovare una macchina "Erskell" (o Haslang), che in grado di gestire entrambe le lingue in modo efficiente. Io personalmente penso che sia molto meglio per tenerli separati e per assicurarsi di avere una buona interfaccia tra di loro.

Answer 6

Il CLR supporta l'ottimizzazione chiamata coda con un codice operativo esplicito tail (come quello usato da F #), che la JVM non (ancora) un equivalente, che limita la realizzazione di un tale stile di linguaggio. L'uso di AppDomains separati non consentire al CLR per codice di hot-swap (si veda ad esempio questo post che mostra come si può fare).

Con Simon Peyton Jones lavora in fondo al corridoio da Don Syme e il # gruppo F di Microsoft Research, sarebbe una grande delusione se non abbiamo verificarsi un IronHaskell con una sorta di status ufficiale. Un IronErlang sarebbe un progetto interessante -. La più grande parte di lavoro sarebbe probabilmente il porting lo scheduler verde-threading senza ottenere come pesi massimi come il motore di workflow di Windows, o di dover eseguire un fascio VM in cima al CLR