Stephen Colebourne, desenvolvedor da API Joda Time e líder da JSR 310, que trata de melhorias na API de datas e horas do Java, questionou em um post a aplicabilidade da linguagem Scala. Ele compara Scala com EJB 2, especificação considerada um dos pontos mais fracos do Java EE.
[No EJB 2] uma grande quantidade de configurações, código XML e complexidade foram impostas na plataforma Java. A especificação foi amplamente adotada, mas debaixo de muitas críticas. Desenvolvedores descobriram que embora a especificação EJB 2 procurasse reduzir a complexidade na construção de aplicações corporativas, com um alto nível de abstração, na verdade adicionava mais complexidade sem oferecer os ganhos esperados.
Colebourne coloca que prefere a linguagem Fantom a Scala, e que também está aberto a outras linguagens como Kotlin, Groovy e Ceylon. Ele acredita, porém, que Scala não é uma linguagem adequada para o futuro.
Uma de suas objeções é que Scala não fornece um sistema de módulos adequado. Ele aponta que o Java inicialmente também não oferecia tal funcionalidade (e ainda não oferece, mas pelo menos hoje a necessidade é reconhecida); por isso ferramentas como Maven, Ivy e o padrão OSGi tiveram que ser criados para suprir essa lacuna. Entretanto, quando se trabalha em sistemas de grande porte, a modularização é uma ferramenta muito importante para auxiliar a manutenção.
Na verdade, existiu uma proposta de modularidade em Scala há cerca de dois anos, que foi rapidamente abandonada. Houve forte resistência em suportar versões ou módulos (dos quais o sistemas de módulos dependem para funcionar). Naquele momento, Scala ainda não era uma linguagem pronta para uso corporativo e dois anos depois, continua na mesma situação.
Stephen também considera o sistema de tipos em Scala excessivamente complexo, concordando com a opinião de Steve Yegges:
90% da especificação de Scala é sobre o sistema de tipos. É o maior sistema de tipos que já se viu, multiplicado por cinco. Há tipos de tipos, e tipos de tipos de tipos; tanta complexidade ...] Existe um conceito chamado complexidade da complexidade<T>, significando que não é apenas complexidade, nem mesmo complexidade da complexidade: é complexidade da complexidade parametrizada. Existem tipos nos tipos de tipos. É assombroso.
Stephen também ressalta que as assinaturas de tipos, inicialmente usadas para demonstrar que o método compila corretamente, perdem o sentido no Scala, mesmo antes do suporte a Unicode. Ele apresenta o seguinte exemplo, retirado de uma das bibliotecas do Scala, e desafia todos a tentar descrever o que faz o código:
def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That
Stephen argumenta que o sistema de tipos do Scala está dando má fama à tipagem estática:
Sinto que esse enorme sistema de tipos existe para prevenir erros de compilação e para pré-verificar o código. Mas se for aplicada essa lógica na direção oposta, ninguém vai conseguir fazer nada útil com a linguagem. Para mim, o sistema de tipos do Scala extrapola em muito o razoável, dado o que oferece em troca.
Estas opiniões não são novas. Ceki Gülcü, criador dos projetos Log4j e do SLF4j, questiona se Scala merece confiança, observando que a linguagem evoluiu, mas que quebrou a compatibilidade com versões anteriores diversas vezes.
Existe um aspecto em Scala que acho profundamente irritante. A linguagem está sempre quebrando a compatibilidade binária a cada nova versão. Apesar de promessas anteriores, a compatibilidade foi quebrada na versão 2.7, quebrada novamente na versão 2.8, e de novo na versão 2.9.
Complementando o argumento de Ceki: antes de o Java aparecer, recompilar o código era a forma de se obter portabilidade entre diferentes sistemas operacionais e diferentes versões. Isso continuou até a criação do padrão "C ABI", possibilitando que binários fossem disponibilizados e usados para diferentes versões de um mesmo sistema operacional, e finalmente levando a distribuições binárias como Debian, RedHat e Ubuntu. Foi a falta destas ABIs que impediram empresas de entregar versões binárias de seus produtos nos primeiros releases do kernel do Linux e sistemas operacionais.
Ceki arhumenta ainda que as linguagens que estão "concorrendo" com o Scala irão reduzir a distância e melhorar seus pontos fracos; e Scala vai parar de ser tão atraente. Scala, segundo ele, conseguiu inicialmente capturar a imaginação de um grande grupo de desenvolvedores Java. A linguagem instiga os que querem aprender sobre os aspectos da programação funcional e criar código conciso.
Mas, ao constantemente ignorar o que torna uma linguagem estável ao longo do tempo, e seguindo o mesmo caminho de inchamento que o Java (ao mesmo tempo ignorando a compatibilidade entre releases), o Scala se manteve fora dos projetos corporativos. Existem sim histórias de sucesso de times que adotaram Scala inicialmente, mas não há casos de sucesso de equipes que mantiveram o código um ou dois anos depois.
Agora temos uma variedade de outras linguagens baseadas na JVM que oferecem meios semelhantes de exploração, de Fantom a Xtend, que estão intensificando seus trabalhos para ganhar espaço. Até mesmo o Java irá trazer módulos e lambdas na próxima versão; e mesmo que essas mudanças no Java tenham sido adiadas por mais um ano, ainda é provável que o Java consiga trazer a programação funcional para as massas antes que o Scala estabilize. Talvez seja tarde de mais para o Scala arrumar a casa antes que o Java tome conta.