Avete effettivamente "provato" (significa programmato, non solo letto un articolo su di esso) Erlang e deciso contro di esso per un progetto? Se è così, perché? Inoltre, se hai scelto di tornare alla tua vecchia lingua, o di usare un altro linguaggio funzionale come F #, Haskell, Clojure, Scala, o qualcos'altro, anche questo conta e spiega perché.Perché hai deciso di "contro" usare Erlang?
Sono tornato ad Haskell per i miei progetti personali da Erlang per la semplice virtù del sorprendente sistema di tipi di Haskell. Erlang ti offre un sacco di strumenti per gestire quando le cose vanno male. Haskell ti dà gli strumenti per impedirti di sbagliare in primo luogo.
Quando si lavora in una lingua con un sistema di tipi forte, si stanno dimostrando teoremi gratuiti sul proprio codice ogni volta che si compila.
Hai anche un po 'di zucchero sovraccarico dal macchinario di typeclass di Haskell, ma questo è in gran parte secondario a me - anche se mi permette di esprimere un numero di astrazioni che sarebbero terribilmente prolisse o non idiomatiche e inutilizzabili in Erlang (ad es. Gli accessori di categoria di Haskell).
Amo Erlang, adoro i suoi canali e la sua scalabilità senza sforzo. Mi rivolgo ad esso quando queste sono le cose di cui ho bisogno. Haskell non è una panacea. Rinuncio a una migliore comprensione operativa del consumo di spazio. Rinuncio al magico spazzino. Rinuncio agli schemi OTP e a tutta quella scalabilità semplice.
Ma è difficile per me rinunciare alla coperta di sicurezza che, come è comunemente detto, in Haskell, se si verifica tipicamente, è probabilmente corretto.
Un certo numero di motivi:
Perché sembra alieno da chiunque utilizzato per la famiglia C di lingue
Perché volevo essere in grado di eseguire sul Java Virtual Machine a Approfitta degli strumenti che ho conosciuto e compreso (come JConsole) e degli anni di sforzi che sono passati a JIT e GC.
Perché non volevo dover riscrivere tutte le librerie (Java) che ho accumulato nel corso degli anni.
Perché non ho idea dell'ecosistema di Erlang (accesso al database, configurazione, compilazione, ecc.).
Fondamentalmente mi è familiare con Java, la sua piattaforma e l'ecosistema e mi hanno investito molto impegno nella costruzione di roba che gira su JVM. E 'stato più facile di gran lunga per passare alla Scala
Hai provato uno dei ponti Java/Erlang là fuori? – Zubair
No! Mi è veramente piaciuto scala dall'inizio, quindi non ho avuto bisogno di guardare più lontano. –
Avevo guardato Ruby e Groovy un po '. Erlang sembra così estraneo a chiunque sia abituato alla famiglia del linguaggio C; L'ho scontato presto su –
Mentre io non ho, altri su internet hanno, ad esempio,
Abbiamo esaminato i meriti relativi C++ e Erlang nell'attuazione di un raggio acustico parallelo tracing algoritmo di brevetto marina. Abbiamo trovato una curva di apprendimento molto più piccola e ambiente di debug migliore per parallelo Erlang che per la programmazione C++ basata su pthreads . La nostra implementazione C++ ha sovraperformato il programma Erlang di almeno 12 volte. I tentativi di utilizzare Erlang sul microprocessore IBM Cell BE sono stati frustrati dal numero di memoria di Erlang . (Source)
E qualcosa di più vicino al mio cuore, che mi ricordo di aver letto di nuovo a seguito del concorso ICFP:
La codifica è stato molto semplice, traducendo pseudocodice in C++. Ho potuto usare Java o C#, ma sono al il punto in cui la programmazione ad alto livello in C++ è altrettanto facile, e io voluto riservarsi la possibilità di rapidamente cadere giù in qualche basso livello giocherellando se ci fosse arrivato. Erlang è la mia altra lingua preferita per l'hacking in giro, ma ero preoccupato di correre in alcune prestazioni problema che non ho potuto estrarre da me stesso. (Source)
Wow, non so nemmeno che Erlang abbia funzionato con il processore IBM Cell BE. Quindi Erlang è il migliore per ambienti di memoria di grandi dimensioni? – Zubair
Erlang è una scelta eccellente per ambienti high-transaction ad alta affidabilità. Le probabilità sono che le telefonate effettuate avvengano tramite switch basati su Erlang. Ed è sempre più comune nei server internet, come MQ e Jabber. – Will
Gli interruttori telefonici sono un buon terreno di coltura per le lingue. AT & T Bell ha anche generato due linguaggi mainstream, C e C++. E i loro interruttori telefonici per gran parte degli anni '90 hanno la più alta affidabilità misurata FCC. Ma la curva di apprendimento per arrivarci era piuttosto alta. – MSalters
Conosco Erlang dall'università, ma finora non l'ho mai usato nei miei progetti.Principalmente perché sto sviluppando principalmente applicazioni desktop, e Erlang non è un buon linguaggio per fare delle belle GUI. Ma presto implementerò un'applicazione server, e darò una prova a Erlang, perché è quello che fa per lui. Ma mi preoccupo di aver bisogno di più librerie, quindi forse proverò con Java.
Joe Armstrong non ha scritto specificamente un adattatore Erlang per il protocollo X windows? Avevo pensato che scrivere GUI a Erlang sarebbe stato abbastanza semplice. –
Sì, puoi scrivere GUI in Erlang. Ma è complicato se vuoi qualcosa di più avanzato come WPF. – Jonas
Per me, il fatto che Erlang è dinamicamente tipizzato è una cosa che mi rende diffidente. Sebbene I do utilizzi linguaggi tipizzati dinamicamente perché alcuni di loro sono così orientati ai problemi (prendi Python, risolvo molti problemi con esso), vorrei che fossero tipizzati staticamente.
Detto questo, in realtà ho intenzione di dare Erlang una prova per qualche tempo, e ho appena iniziato a scaricare il sorgente. Quindi la tua "domanda" ha raggiunto qualcosa dopo tutto. ;-)
usato per un gateway messaggio per un proprietario, a più livelli, protocollo binario. I modelli OTP per i server e le relazioni tra i servizi e la corrispondenza del modello binario hanno reso il processo di sviluppo molto semplice. Per tale caso d'uso probabilmente preferirei di nuovo Erlang alle altre lingue.
Ho già utilizzato Erlang in alcuni progetti. Lo uso spesso per servizi rilassanti. Dove non lo uso, tuttavia, è per complesse applicazioni Web front-end in cui strumenti come Ruby on Rails sono di gran lunga migliori. Ma per il powerbroker dietro le quinte non conosco uno strumento migliore di Erlang.
Uso anche alcune applicazioni scritte in Erlang. Uso CouchDB e RabbitMQ un po 'e ho configurato alcuni server EJabberd. Queste applicazioni sono gli strumenti più potenti, più facili e flessibili nel loro campo.
Non volendo utilizzare Erlang, perché non usa JVM è nella mia mente abbastanza sciocco. JVM non è uno strumento magico che è il migliore nel fare tutto nel mondo. Nella mia mente, la capacità di scegliere tra un arsenale di strumenti diversi e non rimanere bloccati in una singola lingua o struttura è ciò che separa gli esperti dalle code-scimmie.
PS: Dopo aver letto il mio commento di nuovo nel contesto ho notato che sembrava che stavo chiamando oxbow_lakes un codice scimmia. Davvero non ero e mi scuso se l'ha presa così. Stavo generalizzando sui tipi di programmatori e non avrei mai chiamato un individuo un nome così negativo basato su un suo commento. Probabilmente è un buon programmatore, anche se lo incoraggio a non fare della JVM una sorta di rottura di accordi.
Penso che il tutto "Non sembra C quindi è male" è stato un po 'peggio del bit JVM. È tutto solo un po 'sciocco se me lo chiedi. Ma nessuno mi sta chiedendo, quindi dovrei semplicemente tacere nel mio angolo. ;) – Rayne
La JVM non è uno strumento, è una piattaforma. Sebbene io sia del tutto favorevole alla scelta dello strumento migliore per il lavoro, la piattaforma è per lo più già determinata. A meno che non stia sviluppando qualcosa di autonomo, da zero e senza il desiderio di riutilizzare qualsiasi codice/libreria esistente (tre aspetti che sono già improbabili isolati), potrei essere libero di scegliere la piattaforma.
faccio utilizzare più strumenti e linguaggi, ma ho soprattutto targetg la piattaforma JVM. Ciò preclude a Erlang la maggior parte se non tutti i miei progetti, tanto interessanti quanto alcuni concetti.
Silvio
La migliore ragione per evitare di Erlang è quando non è possibile impegnarsi per il modo funzionale di programmazione.
Ho letto un blog anti-Erlang poche settimane fa, e una delle critiche dell'autore a Erlang è che non riusciva a capire come rendere una funzione restituire un valore diverso ogni volta che la chiamava con lo stesso argomenti. Quello che non aveva davvero capito è che Erlang è così apposta. È così che Erlang riesce a girare così bene su più processori senza blocco esplicito. La programmazione puramente funzionale è una programmazione senza effetti collaterali.Puoi arm-torcere Erlang a lavorare come voleva il nostro blogger ranting, aggiungendo effetti collaterali, ma così facendo butti via il valore che offre Erlang.
La programmazione funzionale pura non è l'unico modo corretto di programmare. Non tutto deve essere matematicamente rigoroso. Se si determina che la propria applicazione sarebbe meglio scritta in una lingua che usa impropriamente il termine "funzione", è meglio incrociare Erlang fuori dalla lista.
L'approccio di Erlang a 'rand()': http://xkcd.com/221/ – MSalters
'rand()' costituisce uno studio interessante nel design delle funzioni. Molte funzioni di libreria C standard sono non rientranti, 'rand()' tra di loro. Molte implementazioni della libreria C forniscono alternative rientranti, per una buona ragione. (La libreria C sulla macchina che sto usando ora fornisce il reentrant puramente funzionale 'rand_r()', per esempio.) Erlang fornisce il tipo di 'C: uniforme()', ma anche il 'casuale puramente funzionale: uniform_s() '. Si dovrebbe usare la versione che rende esplicito lo stato interno in entrambe le lingue. –
https://secure.wikimedia.org/wikipedia/en/wiki/Function_%28mathematics%29 "Una funzione assegna esattamente un valore a ciascun input di un tipo specificato." –
Usiamo Haskell, OCaml e (ora) F # così per noi non ha nulla a che fare con la mancanza di sintassi simile a C. Piuttosto saltiamo Erlang perché:
Ci sono probabilmente altre ragioni a cui non riesco a pensare in questo momento, ma questi sono i punti principali.
Ma hai provato a usarlo? –
Oh sì, molto, anche se mai per un'applicazione di produzione. Quando si valuta una nuova tecnologia, aiuta a costruire alcuni strumenti interni con esso prima. Ci piace Erlang e non abbiamo problemi con i prodotti che lo utilizzano come RabbitMQ, ma preferiamo le tecnologie elencate sopra per i motivi già delineati. – Shaun
Ho deciso di non utilizzare Erlang per il mio progetto che stava per essere eseguito con molti dati condivisi su un singolo sistema multiprocessore e sono andato con Clojure perché Clojure ottiene realmente la concomitanza con la memoria condivisa. Quando ho lavorato su sistemi di storage di dati distribuiti, Erlang è stato un ottimo adattamento perché Erlang brilla davvero nei sistemi di trasmissione di messaggi distribuiti. Confronto il progetto con la migliore funzionalità della lingua e scelgo di conseguenza
Mentre mi sono piaciuti molti aspetti del design del runtime Erlang e della piattaforma OTP, ho trovato un linguaggio di programmazione piuttosto fastidioso da sviluppare. le virgole ei punti sono totalmente zoppi e spesso richiedono la riscrittura dell'ultimo carattere di molte righe di codice solo per cambiare una riga. Inoltre, alcune operazioni semplici in Ruby o Clojure sono noiose in Erlang, ad esempio la gestione delle stringhe.
Per i sistemi distribuiti che si basano su un database condiviso il sistema Mnesia è davvero potente e probabilmente una buona opzione, ma programma in una lingua per imparare e divertirmi, e il fattore fastidioso di Erlang ha iniziato a superare il fattore divertimento una volta ha superato le esercitazioni di conto bancario di base e ha iniziato a scrivere plug-in per un server XMPP.
Amo Erlang dal punto di vista della concorrenza. Erlang ha davvero fatto ragione alla concorrenza. Non ho finito per usare erlang principalmente a causa della sintassi.
Non sono un programmatore funzionale di mestiere. Generalmente uso il C++, quindi sono desideroso di cambiare stile (OOP, imperativo, meta, ecc.). Sembrava che Erlang mi costringesse ad adorare la sacra mucca di immutabili dati.
Mi piace il suo approccio alla concorrenza, semplice, bello, scalabile, potente. Ma per tutto il tempo in cui stavo programmando in Erlang ho continuato a pensare, uomo preferirei molto un sottoinsieme di Java che non consentiva la condivisione dei dati tra thread e il modello di concorrenza usato da Erlangs. Ho pensato che Java avrebbe avuto la migliore scommessa di limitare la lingua del set di funzionalità compatibile con i processi e i canali di Erlang.
Recentemente ho scoperto che lo D Programing language offre Erlang style concurrency con la sintassi di stile c familiare e il linguaggio multi-paradigma. Non ho ancora provato nulla di fortemente concorrente con D, quindi non posso dire se è una traduzione perfetta.
Quindi, in modo professionale, utilizzo C++ ma faccio del mio meglio per modellare le applicazioni in modo massivo come in Erlang. Ad un certo punto mi piacerebbe dare agli strumenti di concorrenza di D un vero test drive.
Non ho intenzione di guardare nemmeno Erlang.
Due post del blog inchiodato per me:
macchinari Erlang cammina l'intera lista per capire se hanno un messaggio per elaborare, e l'unico modo per ottenere un messaggio significa camminare l'intera lista (I il sospetto che i messaggi di filtraggio di pid coinvolge anche a piedi l'intero elenco dei messaggi)
http://www.lshift.net/blog/2010/02/28/memory-matters-even-in-erlang
non ci sono miracoli, anzi, Erlang non fornisce troppi servizi per affrontare ov inevitabili erloads - ad es. è ancora compito del programmatore dell'applicazione gestire il controllo dello spazio disponibile nella coda dei messaggi (presumibilmente camminando lungo la coda per calcolare la lunghezza corrente e suppongo che non ci siano meccanismi integrati per garantire equità tra i mittenti).
Entrambi (1) e (2) sono ben al di sotto ingenuo sul mio libro, e sono sicuro che ci sono più software "chicche" di natura analoga seduta all'interno macchinari Erlang.
Quindi, niente Erlang per me.
Sembra che una volta che si ha a che fare con un sistema di grandi dimensioni che richiede prestazioni elevate in sovraccarico C++ + Boost è ancora l'unico gioco in città.
Ho intenzione di guardare D dopo.
Volevo utilizzare Erlang per un progetto, a causa della sua incredibile scalabilità con il numero di CPU.(Usiamo altre lingue e occasionalmente colpiamo il muro, lasciandoci a dover modificare l'app)
Il problema era che dobbiamo consegnare la nostra applicazione su diverse piattaforme: Linux, Solaris e AIX, e sfortunatamente non c'è installazione di Erlang per AIX al momento.
Essendo una piccola operazione preclude l'impegno nel porting e nel mantenimento di una versione AIX di Erlang, e chiedere ai nostri clienti di utilizzare Linux per una parte della nostra applicazione è un no go.
Spero ancora che arriverà un AIX Erlang in modo che possiamo usarlo.
Si noti che Haskell non ha nemmeno bisogno del ciclo write-compile-execute poiché supporta REPL (ad esempio tramite 'ghci'). Per me, questo unisce il meglio dei mondi di linguaggi statici (letteralmente scritti) e dinamici. –
@ REP di Konrad Haskell ha dei limiti, tuttavia. Per prima cosa, non puoi scrivere le definizioni di 'data' al suo interno. È necessario scriverlo in un file e farlo elaborare da REPL. Sia ghci che abbracci. –
@Daniel Fortunatamente, data la natura di ciò che faccio, la maggior parte delle volte in cui voglio lavorare in un REPL, posso passare a un gruppo di combinatori Functor/Bifunctor da extra di categoria per creare il tipo di dati di cui ho bisogno. Detto questo, ci sono almeno una serie di macro ghci là fuori che possono caricare dinamicamente le definizioni dei dati durante la sessione aggiungendo un file sorgente Haskell temporaneo per voi e ricaricandolo. –