Em Java:

int soma_array (int[] array) {
    int r = 0;
    for(int i = 0; i < array.length; ++i)
        r += array[i];
    return r;
}

Em Erlang:

soma_lista(Lista) ->
    soma_lista(Lista, 0).
 
soma_lista([H | T], Acc) ->
    soma_lista(T, H + Acc);
 
soma_lista([], Acc) ->
    Acc.

Nada de especial na versão em Java, já a versão em Erlang é bem enigmática, para a maioria quase indecifrável. O problema, talvez, seja o fato de ser uma linguagem puramente funcional, que significa, entre outras coisas, que não existe destructive assignment – não é possível alterar o valor de qualquer coisa depois de definida. Por isso que todo loop deve ser escrito usando tail recursion*.

Há quem possa achar que a sintaxe não ajuda, pois estamos usando notação própria para pattern matching e processamento de listas. Porém, como veremos, é possível reescrevê-lo removendo a sintaxe enxuta por algo mais familiar a linguagens imperativas. Para exemplificar esse processo, vou aproximar a versão Java o máximo da em Erlang e o primeiro passo é introduzir recursão.

int soma_array(int[] array) {
    return soma_array (array, 0, 0);
}
 
int soma_array(int[] array, int idx, int acc) {
    if (idx == array.length)
        return acc;
    return soma_array(array, idx + 1, acc + array[idx]);
}

Bem melhor agora! O código lembra um pouco mais a versão funcional. Porém ainda tem a diferença que Erlang usa listas encadeadas no lugar de arrays e são processadas maneira similar ao LISP, utilizando uma função que retorna o primeiro elemento e outra que retorna o resto da lista depois do primeiro. Se modificarmos o código Java para levar isso em conta, vamos ter algo que lembra muito Erlang. O código fica da seguinte forma:

interface Lista {
    int head();
    List tail();
    boolean isEmpty();
}
 
int soma_lista(Lista list) {
    return soma_array (list, 0);
}
 
int soma_lista(List list, int acc) {
    if (list.isEmpty())
        return acc;
    return soma_lista (list.tail(), acc + list.head());
}

Agora que temos uma versão do código Java com o devido processamento de listas, que tal reescrever a versão em Erlang para não usar a notação de processamento de listas e pattern matching. Com isso teremos algo que é gritantemente próximo ao exemplo anterior, como veremos a seguir:

soma_lista(Lista) ->
    soma_lista(Lista, 0).
 
soma_lista(Lista, Acc) ->
    if
        Lista == [] -> Acc;
        true -> soma_lista(tl(Lista), Acc + hd(Lista))
    end.

Agora sim, temos aquilo que meu amigo pode chamar de código decifrável. Porém não é sem abrir mão do poder da linguagem – o que é uma pena, eu diria. Um programador de Erlang provavelmente iria estranhar ver algo como escrito na última versão. Para terminar esse artigo vou mostrar como ficaria se utilizarmos as funções de acesso aleatorio a listas, algo não muito aconselhável, já que é uma operação O(N).

soma_lista(Lista) ->
    soma_lista(Lista, 1, 0).
 
soma_lista(Lista, Idx, Acc) ->
    if
        Idx > length(Lista) -> Acc;
        true -> soma_lista(Lista, Idx + 1, Acc + lists:nth(Idx, List))
    end.

*Já me descobri péssimo com tradução, por isso não me arriscarei com essa também.

Ponteiros exigem que a pessoa desenvolva a disciplina mais complicada a um programador, que entender e explorar indireção. Todo problema difícil pode ser resolvido facilmente quando adicionamos um nível extra de indireção, está é uma das máximas da nossa área, que é importante para todo profissional. O complicado é conseguir ver uma pessoa assimilando a idéia de comportamento indireto, ainda mais por ser algo sem exemplos na natureza.

Quando falamos de pattern matching, o segredo por trás é a decomposição estrutural, pela qual os casamentos são realizados. Erlang e Scala são exemplos de linguagens que suportam esse recurso. Sua principal utilidade está em expressar uma série de condicionais de maneira muito mais simples e clara que usando operadores tradicionais. O porém fica pelo fato de sua operação ser muito mais interessante quando usamos tipos algébricos (assunto para outro artigo) que para objetos, então não é nada simples integrar com um linguagem OO.

A utilidade em aprender ambos vai além de saber como usá-las, está em entender o fundamento por traz de cada um pois muitos dos grandes avanços da programação estão enraizados neles – reparem como a maioria do catalogo do GoF trata apenas do uso de indireção adicional.

Para entender melhor a situação, vejamos o modelo de execução que todo sistema operacional espera de seus processos. Um processo possui uma ou mais threads, cada thread possui apenas uma linha de execução* e faz chamadas bloqueantes ao kernel. Ou seja, cada uma deve seguir executando por apenas um caminho e deve parar enquanto uma chamada ao sistema não completa. Contrastemos agora com modelo de green-threads, que pode ser visto da seguinte forma: um processo possui uma ou mais threads, cada uma administra varias linhas de execução e uma chamada ao kernel não impede prosseguir com as demais.

Essa diferença de funcionamento gera dois problemas. Primeiro de identidade, já que cada thread não possui somente uma linha de execução associada, então primitivas de locking não funcionam pois duas green-thread vão aparecer para o kernel como uma só. O segundo está relacionado ao comportamento do kernel, uma chamada bloqueante partindo de uma linha de execução vai causar várias outras pararem junto.

Ambos problemas dificultam muito a integração com bibliotecas externas, que podem usar o mecanismo de locking do sistema operacional, ou então bloquear indevidamente demais threads. Por exemplo, no Gtk+, o acesso aos widgets é protegido por locks nativos, que em um ambiente com green-threads vai por água abaixo e acaba corrompendo o estado, também tem o fato que executar processamento pesado fora da thread de eventos não ajuda, pois se uma bloqueia, todas bloqueiam. Por fim, tem a questão da escalabilidade, já que várias threads são bloqueadas sem precisar.

Existem alguns sistemas que conseguiram transpor essas barreiras, mas não sem um alto custo associado. Passam, primeiro, a adotar uma primitiva de mais alto nível que uma thread, como um ator, que é muito mais simples de utilizar. Depois fazem o trabalho pesado, criam um mecanismo de execução assíncrona das tarefas bloqueantes, seja fazendo offload para threads nativas auxiliares, ou usando aio e/ou multiplexação. Por fim, partem para as medidas radicais, definindo uma interface para código estrangeiro que garante a semântica e o comportamento das green-threads.

A interface de integração com código estrangeiro, também conhecida por FFI (Foreign Function Interface), é o elemento mais crítico e problemático, pois precisa impor uma forma diferente de trabalho aos integradores, normalmente via troca assíncrona de mensagens entre uma thread com o código ‘perigoso’ e as demais gerenciadas. Uma versão muito mais cabeluda do JNI, para quem conhece.

Das linguagens que implementam efetivamente userland threading, que eu conheço são
Erlang, Scheme e Factor. Elas permitem o uso de milhares de thread leves que consomem poucos recursos e não fazem o escalonador do SO entrar em parafuso. A JVM da BEA, JRockit, uma época suportou green-threads, mas devido a dificuldade de implementar a parte GUI do Java e não criar caos durante chamadas nativas, desistiram do projeto quando o linux passou a ter suporte nativo descente.

* Por linha de execução entenda o conjunto de registradores e a pilha de funções.

Embarquei em um projeto pessoal envolvendo erlang, quero desenvolver um software de tamanho substancial. Quero aprender esse treco e aprender de verdade. Fiz isso com java, desenvolvi, junto com alguns amigos, um software que chegou a ter mais de 330 classes e 52 mil linhas de código. O resultado foi que aprendi muito e fico assustado como acertamos, quase que por acidente, em muitas coisas. Quero repetir isso e quem quiser participar, sinta-se convidado.

Voltando ao assunto deste artigo, que era sobre dúvidas elementares. Até então eu só tinha usado erlang através de seu console interativo, resolvi então ver como iniciar uma aplicação diretamente. Mãos a obra! Eu sei java e sei que preciso definir um classpath no qual a VM encontrará minha classe com método o main desejado. Facil, não?

Acho que ninguém imagina que “erl -classpath” funcionaria. Depois de ler a documentação com os muitos parâmetros que o erl, que é o equivalente moral ao java.exe, continuei sem ter idéia de como fazer. Minha solução foi baixar o yaws, um servidor http escrito em erlang, e decifrar o script de inicialização dele. Consegui, depois de quase duas horas de frustações, fazer o trivial.

Essa empreitada de hoje me mostrou que iniciar em uma tecnologia completamente nova é trabalhoso, até mesmo para tarefas supostamente simples. Como pode que não existe um tutorial facilmente acessivel que me diz como fazer isso? Provavelmente o mesmo ocorre com Java e, descontato aqueles que não tem empenho suficiente, gera muita frustação para quem está no começo.

Aproveitando, caso interesse a alguém fazer o mesmo que eu, primeiro use o parâmetro “-pa” para indicar os diretórios que contém os arquivos beam e depois use “-s” para o processo init do emulador chamar a função que você deseja.

Linguagens dinâmicas, como Python e Ruby tem a obrigaçào moral de suportar um sistema muito mais dinâmico que Java. Os dois motivos são bem razoaveis: o primeiro que não existem informações de tipos no código da aplicação, logo não existe o problema da assinatura da função mudar de “int f(int)” para “short f(int)”; e tem a vantagem de possuirem runtimes muito mais simples – apenas com um interpretador, lidar com todos os problemas do ponto de vista de um JITer é um caos.

HCR é super importante para o recurso de intrumentação introduzido no java5. Tem um monte de ferramentas de diagnóstico e profiling leves que se baseiam na API java.lang.instrument.

Imagine que sua aplicação em produção está deixando a desejar em termos de performance, mas felizmente ela foi intrumentada em pontos estratégicos para monitorar coisas como tempo de resposta do banco e quais actions do Struts estão causando problemas. Esse troubleshooting ocorre no sistema de produção e quase não orera o sistema – diferente de um profiler.
Não acho que vale muito a pena perder tempo tentando melhorar essa tecnologia, pois é muito complexa. Seria muito mais interessante uma JVM com suporte a isolates super super leves, ao ponto de podermos criar um para cada requisição web que desejássemos processar. Com isso teriamos aquilo que todo programador de cobol e mainframe esfrega com tanto orgulho na nossa cara, a robustes e isolamento a falhas da plataforma deles. Uma requisição web que causa um OOM mata o sistema inteiro, mas se pudessemos utilizar isolates, dava até para dormir melhor com estagiarios trabalhando no projeto.

Por isso que Erlang é a linguagem mineirinha da atualidade, ela vai comendo quieta pelas bordas e vai supreender, nós desenvolvedores de Java, c# e Ruby, pois quando a Intel lançar um processador com 32 cores e o MacPro vier com 8 desses brinquedos nós não vamos ter a menor idéia de como fazer o load do sistema chegar em 10% sem tudo explodir. Se você acha que estou exagerando, os quad-core da intel saem no final desse ano, coisa de 18 meses depois dos primeiros Core 2 Duo e nosso querido Gordon Moore vai continuar acertando.

O grande problema é o modelo que as linguagens que usamos, tais como Java, C ou Ruby, tem essa coisa horrivel que é memória compartilhada entre as várias linhas de execução, nossas queridas threads. O Joe Armstrong, um guru nesta área argumenta sobre isso neste artigo e defende o porque de ser um problema muito bem.

O Joe também fala que apenas usando múltiplos procesos e passagem de mensagens entre eles é possivel conseguir o mesmo resultado, só que de forma muito mais facil e confiavel, ele ainda sugere usar Erlang. A um tempo escrevi um artigo falando um pouco sobre como Erlang funciona e ainda continuo firme que o seu modelo de execução é muito superior ao que temos nas linguagens mainstream – mas peca por ser uma linguagem dificil de usar.

Mas quais são as característica que tornam Erlang tão interessantes? Primeiro, seu suporte a processos super leves, manter um milhão deles executando em paralelo é perfeitamente possivel, já que para criar um basta pouco mais de 1kb de memória e o tempo de alocá-la – compare isso com o tempo e o uso de memória para subir uma JVM. Depois temos uma sintaxe especial para troca de mensagens assíncronas entre processos – que é uniforme em relação a localização de cada um. Cada processo possui sua área propria de memória, se um processo fizer muita meleca e morrer, nada interfere no funcionamento dos demais. Essa resiliência torna Erlang uma linguagem muito mais segura e confiavel que as demais.

Por isso que eu acredito que o próximo Java vai ser a linguagem que suportar um ambiente de execução semelhante ao do Erlang. Esse me parece ser o avanço técnológico que justificaria uma adoção em massa, e para entender isso bastar olharmos para tras. Gerenciamento manual de memória é facil de explicar e fazer um estagiário entender, ele vai saber que quando terminar de usar um pedaço de memória, ele deve ser liberado – apesar disso excelentes desenvolvedores gastam muito tempo caçando memory-leaks em código C/C++. Programação concorrente com memória compartilhada é dificil achar plenos/seniors que são capazes de entender direito. Java introduziu gerenciamento automático de memória para as massas, agora precisamos uma linguagem que faça o mesmo com processos leves e passagem de mensagens.