Qual é a melhor linguagem de programação para escrever uma aplicação de serviço de mensagens?

Aplicações de serviço de mensagens normalmente precisam lidar com um grande número de pedidos simultâneos/paralelos. Como tal, algumas linguagens são melhores do que outras devido ao seu suporte embutido para o paralelismo. Não existe uma linguagem "melhor", no entanto.

Primeiro, existem algumas linguagens que são inerentemente ' pior' escolha devido à sua falta de suporte ao paralelismo nativo (tanto na implementação do intérprete/compilador como na especificação da linguagem). Essas seriam muitas das linguagens Dinâmicas (Ruby, Python, etc.). A razão é que os intérpretes para estas linguagens correm num único OS, para além do facto de não haver's nenhum modelo de concurrency embutido para a linguagem. Estas linguagens simplesmente não foram desenhadas para a concorrência e o paralelismo. Agora, alguns podem dizer 'mas eles foram portados para a JVM e blah blah blah' o que lhes dá a capacidade de utilizar os tópicos da JVM, mas o fato é que rodar esses idiomas na JVM não é tão bem testado. Por exemplo, eu tive problemas usando o depurador Pry em JRuby porque JRuby é um pensamento posterior para aquela Gem em particular (e muitas outras).

Existem outras linguagens que são escolhas que vão funcionar, mas são't grandes escolhas. That's geralmente suas linguagens de procedimento (a maioria das quais suporta arquitetura Object Oriented). Estas são linguagens como Java, C++, C, C#, Objective-C, Smalltalk, e similares. Agora, estas linguagens têm bibliotecas de concurrência bem suportadas que foram adicionadas mais tarde, ou suporte a concurrência e paralelismo construídos diretamente na especificação da linguagem. De qualquer forma, no entanto, o modelo processual é construído em torno da memória mutante e do estado e não faz nada para desencorajar ou impedir o programador de fazer isso. Então o que faz dessas linguagens um ' melhor' a escolha do que Ruby e Python é que elas suportam nativamente programação concorrente (usando threads reais, ou green threads, ou o que você quiser). O que os torna maus é que eles dificultam a escrita de código que não se presta a condições de corrida porque a capacidade de mudar valores acedidos na memória é tão fácil que estas linguagens praticamente o encorajam. Agora imagine o que poderia acontecer quando 2 tópicos de execução estão usando o mesmo valor na memória? O que acontece se um thread de execução o sobrescreve de uma forma que os outros não esperam? Isso'é apenas um dos muitos problemas que as linguagens de procedimento lhe colocam neste domínio problemático onde o paralelismo é importante.

Então, o que resta? Onde, lá's 2 famílias de línguas que temos't falamos ainda - Lógica e Funcional. Eu não'não sei muito sobre programação lógica, mas o que posso dizer é que muitas linguagens baseadas em lógica parecem ser ainda bastante imaturas/experimentais, e este StackOverflow post tende a me afastar do Prolog como uma solução quando eu preciso de concorrência: Quão concorrente é o Prolog?.

Então ficamos com as linguagens funcionais. Agora isso vai ficar muito subjetivo (mas não muito subjetivo), e I'tenho certeza que há pessoas lá fora que discordam de mim (de fato, I'tenho certeza que há pessoas que discordam de algumas das coisas que I'já disse até agora, então, claro, faça sua própria pesquisa e tire suas próprias conclusões para si mesmo). Mas eu acho que as linguagens funcionais são as mais adequadas para programação concorrente e paralela por 2 razões principais: 1. Imutabilidade - As linguagens funcionais são construídas de forma a desencorajar (no mínimo) ou tornar de alguma forma impossível (no melhor) a mutação de variáveis e valores em cache no local. O que isto significa é que a maior parte das condições da corrida que você acaba precisando ter cuidado nas linguagens de procedimento do Java, C, C++, etc. vão embora simplesmente por causa do seu modelo de programação. 2. Outro benefício adicional é que a imutabilidade significa que a maior parte do seu programa será composto por ' pure' funções matemáticas (para a mesma entrada, você sempre obtém a mesma saída), o que torna o seu código inerentemente componível, e portanto, extensível. Acho que foi isso que facilitou a adição de um modelo de simultaneidade a linguagens funcionais como Haskell e Lisp, embora algumas tenham sido desenhadas com a simultaneidade em mente (Clojure e Erlang, por exemplo).

Agora a partir daqui, o que é melhor é difícil de dizer. Eu gosto do Haskell porque ele é puramente funcional com um sistema do tipo algébrico, então em tempo de compilação I'tenho certeza razoável de que se o meu código construir, ele'está correto (um benefício que eu gosto não importa que tipo de projeto I'm construindo). Mas também, os tipos me dirão muitas vezes o que meu código está fazendo e como e onde ele pode ser paralelizado. Para começar, Haskell é uma linguagem puramente funcional, então eu quase nunca tenho que pensar em condições raciais. O complicado é que o Haskell é preguiçoso, então se você tem um monte de IO acontecendo, você acaba com erros como ter muitos descritores de arquivo abertos de uma só vez e esse tipo de coisa. A outra desvantagem é que se você tem'não usou uma linguagem com um sistema do tipo Hindley-Milner antes e você não tem'não tem um histórico em Álgebra Abstrata e Teoria da Categoria, ele'vai levar um tempo para você aprender Haskell. No entanto, existem frameworks web Haskell que suportam um grande número de pedidos paralelos muito facilmente.

Outra grande escolha é o Erlang ou qualquer uma das linguagens BEAM (Elixir, LFE, Joxa). Erlang tem um modelo de concorrência comprovado e testado pela indústria que funciona muito bem para lidar com várias requisições ao mesmo tempo.

As linguagens Scala e Clojure também são ótimas escolhas com um modelo de concorrência embutido também. Scala tem a vantagem de um sistema de tipos estático que suporta a maioria dos tipos de dados vantajosos que você pode encontrar em Haskell, mas falta o foco em reforçar a imutabilidade que Clojure tem (embora Scala encoraja uma programação imutável até um grau). Se você já está confortável com a JVM, estas linguagens podem ser a melhor escolha para você.

There's também outras escolhas que eu ganhei't entrar (Nodejs, rust, go, etc) simplesmente porque eu tenho que parar em algum lugar. Mas espero que isto lhe dê uma visão suficiente para reduzir a sua lista de idiomas potenciais para usar.