Rodrigo Kumpera Weblog

Programação concorrente é dificil, mais dificil que acordar cedo em pleno inverno. Arrumar gente que entenda e saiba escrever corretamente aplicações multi-threaded é muito dificil. O pior que é bem razoavel esperar isso, afinal acompanhar mentalmente o fluxo de várias threads em paralelo no mínimo faz o cérebro doer. Ou resolvemos isso logo, ou estaremos nos condenando a passar os próximos anos apenas tentando arrumar esse embrólio.

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.