No keynote ScalaDays, que aconteceu em junho, Rod Johnson apresentou sua visão do futuro, quando Scala fixou todos os seus problemas e se tornou a linguagem de fato da JVM.

A apresentação está disponível em Parleys, e é instrutivo ver tanto o vídeo, bem como os comentários abaixo .

Não é necessário dizer que o seu discurso não caiu bem com o Scalarati. Dito isso, alguns podem receber críticas construtivas sem serem afetados por elas.

Havia dois argumentos principais a respeito de como Scala precisa evoluir para se tornar a linguagem de fato daqui a cinco anos:

• A comunidade precisa se tornar mais simpática e acolhedora
• A incompatibilidade entre as versões antigas tem que parar

O primeiro, sem dúvida, mostrou melhora ao longo dos anos, mas o fato é que quanto mais programas complexos /algoritmos/tipos são usados, o nível de discurso envolvido nas listas de discussão se torna polarizado. A mesma coisa aconteceu com C++ ao longo de sua vida, com wisend C++ assistente olhando para seus neófitos C com desdém.

As coisas estão mudando, e lentamente,para melhor. Alguns dos membros mais venenosos da comunidade Scala – e você provavelmente já sabe quem eles são – se mudaram ou pelo menos se tornaram mais suaves. Geralmente todo mundo tenta ser útil, mas ensinar novos conceitos, ao mesmo tempo a adoção crescente é um problema difícil.

Quanto à incompatibilidade para trás… bem, isso é a mesma coisa que sempre foi. Isso surge de vez em quando – geralmente após um grande lançamento – e a resposta é sempre a mesma: para preservar a inovação e a flexibilidade, o passado não pode restringir o futuro.

Como resultado, um programa compilado com uma versão mais antiga (e isso inclui grandes revisões passadas, não apenas pequenas correções de bugs contra o atual) só deixa de executar as bibliotecas compiladas com para uma versão mais recente. Nunca houve um lançamento de Scala no qual fosse possível compilar e executar uma biblioteca mais antiga com uma versão mais nova de um programa. Embora o Scala Universe nunca tenha decolado, os desenvolvedores da biblioteca ainda impulsionam as versões de suas bibliotecas para os lançamentos atuais e passados; ou, pior ainda, apenas a versão atual.

Compare e contraste isso com praticamente qualquer outra biblioteca ou linguagem. Mesmo C, que é uma plataforma específica, tinha uma ABI definida que poderia permitir que outros programas de ligação contra – e batendo a versão do compilador C não invalidassem todas as bibliotecas que você tem no seu sistema. Java, é claro, é o garoto-propaganda da compatibilidade; programas compilados nos dias de versão contra 1.0 ainda podem ser usados em uma recente JVM.

O negócio é: para Scala se tornar o padrão de fato, ele precisa se estabelecer, ou pelo menos ter um plano de migração entre os lançamentos para que as empresas não tenham que atualizar o mundo a cada seis meses. Java, mesmo que seja velho e fora de moda, consegue isso muito bem. Provavelmente o trabalho com lambdas do Java terá um impacto e um tempo de vida muito maiores do que Scala, simplesmente porque os desenvolvedores, uma vez lançado, serão capazes de confiar nele.

A visão de Rod foi criada para daqui a cinco anos, quando o Scala tiver resolvido esses problemas. Em 2018, foi a alegação – Scala será a principal linguagem na JVM. O único problema é que esses problemas são conhecidos há cinco anos, e ainda não foram corrigidos.

Quase quatro anos atrás, eu escrevei o artigo Is Scala ready for the enterprise?, no qual eu perguntei se Scala estava pronto para empresas. Foi quando o Scala 2.8 estava prestes a ser lançado (quebrando a compatibilidade com Scala 2.7, e não vamos esquecer que o Scala 2.7 era incompatível com a versão 2.6). Tornou-se bastante claro desde o início que o Scala não estava pronto na época.

O que vem acontecendo ao longo dos últimos quatro anos?

Nada.

Bem, não é estritamente nada, mas em relação a melhorar compatibilidade, aumentar uma comunidade e construir uma fundação em rocha sólida para o futuro, estamos exatamente na mesma posição agora como estávamos então. Havia os ávidos fãs de Scala, que se recusavam a ouvir qualquer coisa que não fosse 100% elogio – na verdade, um conjunto similar de pessoas que se recusavam a levar em conta os pontos que Rod estava abordando em seu discurso. No entanto, a maioria dessas pessoas não passou por uma mudança de versão com o Scala, ou viu a dor que ele pode causar, ou que extrapolaram a pensar o que vai fazer para versões futuras.

Em essência, a visão de Rod de que “em cinco anos o Scala vai se tornar o padrão de fato” ainda está tão longe quanto há quatro ou cinco anos. A meia-vida de Scala é cerca de dois anos; cada vez que ele passa por uma nova versão, ele consegue matar alguns interesses e, ao mesmo tempo, recrutar novos apóstolos para o futuro.

Esse processo de autolimitação significa que o Scala nunca vai realmente morrer; em algum ponto, ainda há mais pessoas que são novas para o Scala do que pessoas que foram queimadas por ele, por isso há sempre uma nova oferta de pessoas dispostas a acreditar que pode não acontecer com eles. O mesmo é válido para fumantes, claro.

Mas o que isso significa é que o Scala nunca vai realmente encontrar uma lugar em ambientes corporativos, nem se tornar a linguagem de fato para a JVM. Haverá sempre histórias populistas de sucessos em pequenas equipes de TI – sem dúvida onde o Scala será mais bem sucedido – porque muitas vezes eles podem se dar ao luxo de serem mais ágeis e fazerem uma migração de “parar o mundo” para o melhor e o mais recente a cada dois anos.

Ironicamente, com o lançamento do Java 8 nos próximos oito meses, pode ser que o Java 8 seja o novo Java, não Scala.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://alblue.bandlem.com/2013/08/will-scala-ever-be-enterprise-ready.html