Como akka se compara a Erlang? [fechadas]


97

Estive olhando para akka recentemente e é bastante impressionante. Parece que tem a maioria dos recursos matadores do erlang - transparência de localização, hierarquias de supervisão e muito mais. Há algum recurso que erlang tem que akka não tem?


Veja este filme sobre erlang na prática. Pena que não há nada sobre scala youtube.com/watch?v=G0eBDWigORY
mhstnsc

Respostas:


123

Isenção de responsabilidade: eu sou o PO para Akka

  • Erlang faz cópia ao enviar - Akka usa memória compartilhada (objetos imutáveis) para envios dentro da VM
  • Erlang faz GC por processo - Akka usa JVM GCs
  • Erlang tem OTP - Akka se integra com todo o ecossistema Java (Apache Camel, JAX-RS, etc etc)
  • Erlang faz o agendamento do processo para você - Akka permite que você use muitos Dispatchers diferentes com oportunidades de configuração infinitas
  • Erlang faz recarregamento de código a quente - Akka pode suportá-lo, mas é menos flexível por causa do carregamento de classe JVM

Esses são os do topo da minha cabeça.

Por outro lado, usar Akka significa que você pode usar Scala, Java, Groovy ou JRuby para escrever seus aplicativos.


39
Os objetos Erlang também são imutáveis ​​e o modelo de simultaneidade não requer cópia no envio dentro do mesmo nó. BEAM para objetos grandes envia uma referência. Fonte: esta resposta do SO por @rvirdig .
FooF

26
Erlang faz cópia no envio para tornar o GC mais eficiente - ele pode funcionar por processo. É por isso que não há grandes pausas de GC nos aplicativos Erlang, ao contrário dos aplicativos JVM / Akka.
andreypopp

4
Bem, Andrey, isso depende de qual JVM / GC você está usando. azulsystems.com/products/zing/whatisit
Viktor Klang

4
Erlang tem um número de redução para cada processo, mesmo que você esteja em um loop de computação pesado e ocupado, Erlang VM pode pausar o processo e permitir que outros processos famintos levem mais ciclos de CPU. Esse é um recurso muito importante que o JVM não oferece.
Daniel

6
@MaX Erlang costuma ser 5x mais lento do que Java devido à falta de suporte JIT. Mas Erlang não tem pausa de GC, é projetado para simultaneidade e aplicativos de telecomunicações 7 * 24, Erlang se preocupa mais com a justiça do processo, evitando inanição e deadlock, não foi projetado para rendimento como JVM. Então, é realmente laranja e maçã.
Daniel

74

Em Erlang, os processos são comutados aproximadamente a cada 1000 reduções. Em uma estrutura ingênua como o agente Scala / Akka, o agente possui um agendador até terminar o trabalho no recebimento. Xeque-mate. Fim de jogo. Hasta la vista :) Gente, não perca tempo com pseudo-técnicos. Fiquei chocado que os caras aqui comparassem Scala com Erlang.

Também existem muitos outros chamados "recursos matadores", mas aqui está o meu conselho, não pense em termos de recursos, pense em expressões idiomáticas que permitem uma linguagem específica. Scala rouba os "melhores recursos", Erlang permite / implementa você com os idiomas certos para construir sistemas de forma confiável, com uma linguagem de alto nível que se baseia nos idiomas certos. Quando você aprende Erlang, está reconstruindo sua mente, sua maneira de pensar sobre um sistema confiável distribuído, Erlang ensina e atualiza você. Scala é apenas mais uma linguagem imperativa (oh, desculpe, palavra engraçada, multiparadigmal) que tenta roubar boas características de outras línguas.


9
A maneira erlang de tornar todo o IO implicitamente assíncrono é muito elegante. O Async IO pode ser feito usando NIO APIs no Scala, o que não parece um cheque mate para mim, mas uma solução menos elegante.
HRJ,

7
Que diabos você está falando?! como é o processamento de 1000 tarefas diretas melhor do que um agendamento roundrobin, ou mesmo perto de um agendamento de menor caixa de correio !!
FUD

8
@vjache - eu concordo. Meus muitos anos como programador java me ensinaram que, em algum momento, você terá que investigar a camada abaixo de você. Scala / Akka parece ser apenas mais uma camada acima de muitas outras camadas (por exemplo, nio, netty, etc), todas as quais você precisará entender em algum ponto. Embora eu tenha acabado de começar a trabalhar com Erlang, parece que terei menos camadas que preciso entender para fazer o trabalho. A programação distribuída em Erlang parece muito mais leve para Scala / Akka, provavelmente de uma forma semelhante que o python era a alternativa mais leve para java para aplicativos da web.
Chris Snow

@FUD: talvez ele quisesse dizer 1000 instruções Erlang? ele não poderia estar se referindo a 1000 mensagens ...
Erik Kaplun

2
@ErikAllik Ele quis dizer 1000 "reduções". Pense em uma redução como um token para executar um trecho de código (não é, mas faz o trabalho de explicar ...). Após 1000 reduções, o agendador muda para um processo diferente. Mais informações em erlang.org/pipermail/erlang-questions/2001-April/003132.html
Aegis

40

Quase ninguém menciona o isolamento do processo. Sem garantias de "sua discussão não pode mexer com meu lixo", os sistemas distribuídos são muito mais difíceis de raciocinar. (Eles já são difíceis o suficiente com os processos de Erlang.)

AFAIK (que não está longe, dada minha experiência direta limitada com a JVM), apenas Erlang consegue realmente isolar o processo "certo" na JVM. O Sr. Google pode dar algumas dicas sobre onde encontrar pesquisas de Fox e Candea (?) Sobre sistemas de pesquisa que usam uma técnica de "micro-reinicialização" ("computação orientada para recuperação"). Um desenvolvedor Erlang lê essa pesquisa e diz algumas coisas:

  1. Bem-vindo ao clube, por que demorou tanto?
  2. A JVM torna muito, muito difícil de ingressar, no entanto. :-)

O isolamento do processo é realmente muito bom. No entanto, nem mesmo Erlang está imune a um NIF que deu errado.
Viktor Klang

14

Para mim, a troca de código a quente em um cluster Erlang inteiro sem tempo de inatividade (por exemplo make:all([netload]:) é um dos recursos matadores do Erlang.

Mas vamos reverter sua pergunta: O que akka tem que Erlang não tem? Claro que você pode adicionar dezenas de extensões e bibliotecas (scala, akka, spring, osgi, ...) ao Java para tentar chegar perto de Erlang. Mas onde está o ponto? Em suma, todas essas extensões são muito mais complexas do que aprender a linguagem Erlang simples, que já provou por mais de 2 décadas que pode fazer o trabalho oferecendo escalabilidade superior com tempo de inatividade zero.


30
IMO, Scala é uma linguagem muito melhor no nível de sintaxe do que Erlang. Ele tem objetos, características, namespaces próprios, segurança de tipo adequada, nenhuma sintaxe de registro feia, etc. A comunidade é maior, posso usar todas as ferramentas Java disponíveis e parece mais polido.
ryeguy de

15
@ryeguy: "melhor linguagem no nível de sintaxe" ... hmm, defina "melhor" para "sintaxe". Quando comparo linguagens, a sintaxe é o fator mais irrelevante (porque é apenas uma questão de gosto ou para o que você está acostumado).
Peer Stritzinger de

4
@ryeguy Semânticas diferentes, sintaxe diferente.
lançamento em

3
a troca de código a quente torna-se uma dor se você precisa manter o estado entre as diferentes versões do código, no final é mais fácil desligar o processo e migrar o estado na inicialização
OlegYch

4
@ryeguy A sintaxe de uma linguagem de programação é quase irrelevante; o que importa é sua semântica. Erlang é um PL funcional, então é claro que não tem objetos. Traços, segurança de tipo, etc, são devidos ao Scala ser uma linguagem fortemente tipada, enquanto Erlang é tipado dinamicamente; essa é uma escolha de design. No entanto, gostaria de convidá-lo a dar uma olhada no Elixir se você quiser os benefícios de Erlang com um toque mais moderno;)
Aegis

5

Provavelmente Erlang é melhor para sistemas distribuídos maiores (seguindo a resposta de vjache), mas para um servidor normal, quando você apenas deseja usar todo o poder de várias CPUs, o Akka é uma boa escolha - fornece boa abstração, desempenho e integração com o ecossistema Java.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.