A popularização obtida com a queda do custo de processadores multi-core e a dificuldade de se produzir software que fizesse um aproveitamento adequado desta arquitetura, despertou uma retomada pelo interesse e uma revisita às linguagens funcionais. Existem várias linguagens que se encaixam nessa classificação e as mais populares que temos notícias são Scheme, Haskell e ErLang. Para uma breve clarificação, as linguagens mais comumente usadas, como por exemplo C/C++, Java e etc., são classificadas como sendo linguagens imperativas. Por questões de objetividade, explorarei sucintamente ErLang mas creio que muitas de suas características valem para as outras linguagens funcionais também.
ErLang é na verdade a abreviação de Ericson Language e comumente está associada ao seu framework de produtividade chamado OTP (Open Telecom Platform). Criada em 1986, se tornou open source 12 anos depois. O suporte para SMP (Symmetric MultiProcessing) viria posteriormente em 2006.
A visão de que o mundo em si e todos os problemas a serem sistematizados são inerentemente concorrentes, sendo que seus elementos estão sujeitos à falhas, desafiam a industria de telecomunicações e são elegantemente endereçadas por esta linguagem e seu framework. Há registros de que esta plataforma atinge índices de confiabilidade de nove noves (impressionantes 99.9999999%) por ter sido desenhada e implementada para suportar aplicações distribuídas, tolerantes a falhas e hot-swappable em seu DNA. Estas características indicam que, apesar de ter em seu foco motivador uma área indústrial específica, esta linguagem se mostra excelente para uma grande diversidade de problemas.
Para entender ErLang temos que nos desatar de alguns conceitos fundamentais presentes nas linguagens imperativas.
Primeiro, em ErLang, variáveis não tem tipo pré-definido e são imutáveis: uma vez que uma atribuição é feita, o conteúdo de uma variável não poderá ser alterado. Este conceito pode gerar uma reação de espanto à primeira vista. Na verdade, devemos relembrar dos fundamentos da matemática que aprendemos no ginásio ao resolvermos um sistema de equações: ao se obter o valor de uma variável, seu conteúdo mantêm-se inalterado.
Segundo, a execução de uma função em ErLang não gera efeitos colaterais. Isto significa que, para um mesmo conjunto de argumentos, se obtêm sempre o mesmo resultado, não importando quando a função é executada. Diferentemente, uma função em uma linguagem imperativa pode ter seu o resultado variando não só pelo conteúdo de seus argumentos mas como também há uma dependência do estado em que o programa se encontra. Isto fica mais claro quando tomamos, para efeito de comparação, o paradigma da programação orientada a objetos, onde é fundamental acompanhar o estado do objeto para o entendimento do comportamento do mesmo.
Processos em ErLang são leves e é comum termos aplicações com centenas ou mesmo milhares de processos sendo executados concorrentemente. O único meio de um processo se comunicar com outro é através de envios de mensagens assíncronas. Em tempo, processos nesse ambiente são análogos a threads em Java.
Estas características fundamentais criam um modelo de execução facilmente desacoplável, facilitando a distribuição do processamento por vários núcleos, processadores ou mesmo distribuídos entre servidores distintos. A característica de imutabilidade e o não compartilhamento de variáveis (shared memory) evitam locks e race condition de dados, que são de longe os mais complexos problemas de serem diagnosticados em sistemas concorrentes.
A penetração desta linguagem é crescente e sua integração com outras linguagens é bem suportada. A conexão com Java pode ser obtida através do JInterface e um bom artigo sobre esta integração pode ser encontrado no TheServerSide.com.
Para aqueles descrentes que só se interessam por algo depois de lhes serem apresentados casos de sucesso, podemos citar que as mensagens instantâneas do Facebook e o Yahoo! BOSS como sendo alguns exemplos de produtos que tem componentes críticos implementados nesta linguagem.
ErLang talvez não seja a solução mais adequada para tudo. É provável que problemas computacionais de processamento intenso possam obter melhores resultados através do uso de bibliotecas como o MPI, TBB ou de alguma outra linguagem de domínio especifico. Mas ErLang certamente trás um arsenal eficiente e consistente que direcionam os esforços de implantação para desafios mais nobres, permitindo ao desenvolvedor se focar estritamente em problemas do domínio da aplicação e não tanto em infra-estrutura.
ErLang é na verdade a abreviação de Ericson Language e comumente está associada ao seu framework de produtividade chamado OTP (Open Telecom Platform). Criada em 1986, se tornou open source 12 anos depois. O suporte para SMP (Symmetric MultiProcessing) viria posteriormente em 2006.
A visão de que o mundo em si e todos os problemas a serem sistematizados são inerentemente concorrentes, sendo que seus elementos estão sujeitos à falhas, desafiam a industria de telecomunicações e são elegantemente endereçadas por esta linguagem e seu framework. Há registros de que esta plataforma atinge índices de confiabilidade de nove noves (impressionantes 99.9999999%) por ter sido desenhada e implementada para suportar aplicações distribuídas, tolerantes a falhas e hot-swappable em seu DNA. Estas características indicam que, apesar de ter em seu foco motivador uma área indústrial específica, esta linguagem se mostra excelente para uma grande diversidade de problemas.
Para entender ErLang temos que nos desatar de alguns conceitos fundamentais presentes nas linguagens imperativas.
Primeiro, em ErLang, variáveis não tem tipo pré-definido e são imutáveis: uma vez que uma atribuição é feita, o conteúdo de uma variável não poderá ser alterado. Este conceito pode gerar uma reação de espanto à primeira vista. Na verdade, devemos relembrar dos fundamentos da matemática que aprendemos no ginásio ao resolvermos um sistema de equações: ao se obter o valor de uma variável, seu conteúdo mantêm-se inalterado.
Segundo, a execução de uma função em ErLang não gera efeitos colaterais. Isto significa que, para um mesmo conjunto de argumentos, se obtêm sempre o mesmo resultado, não importando quando a função é executada. Diferentemente, uma função em uma linguagem imperativa pode ter seu o resultado variando não só pelo conteúdo de seus argumentos mas como também há uma dependência do estado em que o programa se encontra. Isto fica mais claro quando tomamos, para efeito de comparação, o paradigma da programação orientada a objetos, onde é fundamental acompanhar o estado do objeto para o entendimento do comportamento do mesmo.
Processos em ErLang são leves e é comum termos aplicações com centenas ou mesmo milhares de processos sendo executados concorrentemente. O único meio de um processo se comunicar com outro é através de envios de mensagens assíncronas. Em tempo, processos nesse ambiente são análogos a threads em Java.
Estas características fundamentais criam um modelo de execução facilmente desacoplável, facilitando a distribuição do processamento por vários núcleos, processadores ou mesmo distribuídos entre servidores distintos. A característica de imutabilidade e o não compartilhamento de variáveis (shared memory) evitam locks e race condition de dados, que são de longe os mais complexos problemas de serem diagnosticados em sistemas concorrentes.
A penetração desta linguagem é crescente e sua integração com outras linguagens é bem suportada. A conexão com Java pode ser obtida através do JInterface e um bom artigo sobre esta integração pode ser encontrado no TheServerSide.com.
Para aqueles descrentes que só se interessam por algo depois de lhes serem apresentados casos de sucesso, podemos citar que as mensagens instantâneas do Facebook e o Yahoo! BOSS como sendo alguns exemplos de produtos que tem componentes críticos implementados nesta linguagem.
ErLang talvez não seja a solução mais adequada para tudo. É provável que problemas computacionais de processamento intenso possam obter melhores resultados através do uso de bibliotecas como o MPI, TBB ou de alguma outra linguagem de domínio especifico. Mas ErLang certamente trás um arsenal eficiente e consistente que direcionam os esforços de implantação para desafios mais nobres, permitindo ao desenvolvedor se focar estritamente em problemas do domínio da aplicação e não tanto em infra-estrutura.
Comentários
[]s
Yara
Para usar mais de um nucleo o runtime precisa suportar isso. E o sistema operacional tb. Por exemplo, no linux isso eh feito pelo suporte SMP. As versoes recentes do Hotspot(JVM Sun) tb suportam o uso de mais de um nucleo.
O paradigma de funcionamento do Erlang eh um pouco diferente... No mundo Java eh algo proximo de um JMS assincrono utilizando Queue + correlation_id... Porem imagine isso implementado jah na linguagem, sem API ou provider de messageria.
Eh uma questao de facilidade inerente a linguagem. Existem outras coisas legais como hotswap de codigo a quente. No java precisamos utilizar OSGi e ainda assim definir modulos...
Erlang eh fantastico, pena que eh pouco difundido... Eu particularmente ainda me sinto mais a vontade com java.util.concurrent... ;)
Abs,
JV -- julioviegas.com
Aproveitando o gancho da Yara e do Julio, imaginando uma linguagem funcional e o mundo Java, me vem na cabeça Scala.
[]s
Eder
Yara, creio que o Julio já tenha respondido a todas as questões que você levantou, acrescentando que em ErLang, a aplicação já nasce concorrente e que o desenvolvedor é implelido a isso nesse ambiente. Em outras liguagens, concorrência é por muitas vezes uma opção arquitetural ou é utilizada devido a algum requisito funcional.
Eder, eu falhei não citando Scala na lista mas gostaria de destacar que a minha intenção não é criar uma guerra entre linguagens, nem promover alguma em especial.
Meu interesse continua sendo escalabilidade, confiabilidade e eficiencia. Erlang me atrai pelo modo em como esses tópicos são endereçados.
Os mecanismos tradicionais de sincronização tornam o programa complexo e dificílimo de depurar. Locks, semáfaros e mesmo soluções de mais alto nivel como transactional memory mostram suas deficiências em certas condições de carga.
[]s,
Bene.