Scala está pronto para o horário nobre? [fechadas]

Agora que fiz algumas coisas triviais com o Scala (que eu amo por "olá mundo" e aplicativos inventados!), Fico me perguntando ... parte sobre a maturidade das ferramentas para dar suporte ao desenvolvimento e parte sobre a aplicabilidade geral. Os conjuntos de ferramentas estão prontos? O Scala é apropriado para uso em aplicativos corporativos / comerciais? Você o usaria em um projeto não trivial?

Algumas das minhas preocupações (possivelmente infundadas) seriam:

• o IDE e os conjuntos de ferramentas são tão ricos quanto o que temos para desenvolver aplicativos .net e java (o eclipse para Scala parece limitado em comparação com o eclipse para java)?
• os conjuntos de ferramentas de compilação / CI / teste são capazes de lidar efetivamente com o Scala?
• Quão sustentável é o código conciso que pode ser (incentivado?) escrito no idioma?
• é possível encontrar desenvolvedores com a experiência Scala?
• existe massa crítica suficiente para obter ajuda através de referências e livros on-line que são mais do que "introdutórios" ao idioma?

Portanto, o ecossistema está maduro o suficiente para ser usado agora ou é melhor esperar para ver como ele evolui?

EDIT: digamos que "não trivial" é um projeto de desenvolvedores com duração de 10 a 20 anos e com vários lançamentos.

Embora seja verdade que o Scala tenha sido usado na natureza no Guardian e no Twitter, há uma preocupação fundamental.

Grande parte da popularidade do Java vem do fato de ser relativamente fácil de ler e manter. Scala tem um problema aqui, pois pode ser escrito em muitos estilos diferentes. Estilo OO x estilo funcional é a divisão óbvia aqui, mas fica mais complicado quando você fala sobre os três níveis do Scala .

Você precisa garantir que sua equipe e todos os novos contratados em potencial possam seguir o mesmo estilo e que o estilo seja simples o suficiente para que você possa contratar desenvolvedores que possam ser eficazes (nem todos podem contratar os 2% principais) .

O suporte a ferramentas também não está completo, embora eu espere que essa lacuna seja resolvida rapidamente. Você também pode obter suporte para toda a pilha Scala da multidão TypeSafe . Acho que o Scala desenvolverá seu nicho, mas até que os níveis sejam realmente incorporados ao idioma / compilador / o que for, vejo uma dor de cabeça de manutenção nas equipes após os primeiros 1-2 anos de produtividade animada.

Veja esta resposta relacionada para mais detalhes.

Atualmente, o Scala é usado pelo Twitter e pelo The Gaurdian, portanto, certamente está pronto para aplicativos não triviais.

Os programadores Scala serão muito motivados e provavelmente muito bons. Escolher um novo idioma é uma ótima maneira de atrair talentos.

Obviamente, os programadores de Scala geralmente não têm experiência profissional em Scala, e pode haver alguma variedade nos idiomas que eles usam. Alguns podem se esforçar pela pureza do tipo Haskell, enquanto outros podem vê-lo como Java com fechamentos. Portanto, provavelmente levará algum tempo para desenvolver padrões e convenções de codificação consistentes.

Muitas ferramentas Java funcionarão bem, embora o IntelliJ Idea provavelmente valha o investimento sobre o Eclipse.

No geral, pode ser uma boa opção se você tiver controle sobre o projeto. Se isso faz parte de uma grande companhia de seguros, você pode ter problemas se houver diretrizes de arquitetura como: 'Todos os projetos devem ser construídos pelo Maven e implementados no WebSphere'. (Não tenho motivos para pensar que essa regra em particular seria um problema, mas a proliferação dessas regras poderá enganá-lo em algum momento.)

Minha impressão é que grande parte do ecossistema que vem com linguagens "convencionais" (como Java) se destina a compensar sua falta de jeito.

A questão não é: quantas ferramentas existem para uma determinada linguagem (Scala), mas se as ferramentas existentes para essa linguagem são melhores do que as ferramentas existentes para a linguagem de referência (Java). Como 100 ferramentas medíocres não oferecem, o que uma boa ferramenta pode oferecer. E uma coisa que você não deve esquecer é que a própria linguagem faz parte dessas ferramentas.

A declaratividade de uma língua

• é inversamente proporcional à quantidade e severidade dos bugs que você produz com ele, e é por isso que o Java é tão bom em produzir bugs e você precisa de muitas ferramentas para evitá-las e rastreá-las
• é proporcional à sua produtividade, e é por isso que o Java é extremamente detalhado e você precisa de muitos geradores de código e ferramentas semelhantes

Por exemplo, uma vez li um post horrível no blog de um cara do Ruby, que argumentou que a digitação estática é inútil, porque seus testes abrangem a segurança de tipos. Isso claramente veio de alguém que ainda não havia trabalhado com um sistema de tipo estático expressivo. Supondo que eu possa representar todos os relacionamentos de tipo em uma semântica de linguagem e não seja muito trabalhoso (e não é, já que a maioria das linguagens modernas suporta inferência de tipo), recebo tudo isso de graça.

Para avançar um pouco mais: Os testes de unidade garantem que uma unidade atue como especificado ou, para reformulá-la, o teste de unidade são especificações executáveis. No entanto, através da programação declarativa, as próprias unidades são especificações executáveis. Mais uma vez, você recebe algo de graça.

O que estou tentando dizer é que você não deve subestimar o que os recursos de idioma podem fazer por você. E a menos que você realmente os experimente em campo, nunca entenderá.

Então, voltando à pergunta original: as ferramentas existentes para o Scala são melhores do que para Java? Difícil de dizer. Depende do que você quer fazer. Acho que todos concordamos que o idioma é significativamente melhor, agora a pergunta é: quão bom é um ecossistema que você encontrará em sua área de negócios.
Para a web, o Lift é realmente uma opção sólida. Não conhece computadores ou dispositivos móveis.

digamos que "não trivial" é um projeto de desenvolvedores com duração de 10 a 20 anos e com vários lançamentos.

São muitos riscos. As recompensas teriam que valer a pena. No mundo dos aplicativos de negócios empresariais e nos projetos de médio e grande porte, a assunção de riscos é geralmente limitada. Ou melhor, já existe risco suficiente para lidar com ... A previsibilidade é mais importante.

Duvido que a adoção funcione dessa maneira.

É mais provável que comece como um punhado de pessoas trabalhando em uma parte em que o risco está contido, como POC, componentes não críticos, testes ou partes em que o problema parece ser tratado muito melhor pela Scala do que alternativas (talvez se algo envolver ator, por exemplo) ... Então, à medida que as ferramentas amadurecem, a comunidade cresce, o know-how cresce na empresa e pode se expandir.

Ao alavancar o tempo de execução do Java, o Scala certamente está pronto para o horário nobre. Se você puder implementar um aplicativo Scala, uma vez que o bytecode seja gerado, ele sempre funcionará com essa versão específica do Java Runtime. A biblioteca baseada em Scala funcionará como qualquer outra biblioteca de terceiros Java com a qual você esteja familiarizado.

Em termos de IDEs, ferramentas de construção e tudo mais, o Scala não tem o mesmo nível de proliferação que o Java. Portanto, você não possui muitas estruturas ou ferramentas baseadas no Scala. Isso tem mais a dizer com a popularidade do Java do que com a crescente popularidade do Scala. O Scala possui ferramentas funcionais, incluindo o Scala IDE e o sbt, build tool. Mas eles não são tão sofisticados quanto algumas das outras ferramentas auxiliares de Java que existem por aí.

Pontos de coleta de cereja de @huynhjl e @FarmBoy:

• Encontrar um número grande o suficiente de programadores Scala experientes pode ser difícil.

• O dogma de "melhores práticas" para Scala ainda está evoluindo (*).

• Guias de estilo, convenções, etc. ainda estão evoluindo (*).

• O suporte à ferramenta ainda está evoluindo (*).

Juntando tudo isso, talvez uma pergunta melhor para você se perguntar é se sua organização está pronta para usar o Scala em um projeto "não trivial"? Você tem pessoas que conseguem lidar com um grande projeto com tantas coisas "ainda em evolução"? Por outro lado, seria melhor fazer um projeto menor primeiro?

(* De fato, a maioria dos idiomas ainda está evoluindo em um ou mais desses aspectos. O problema aqui é a taxa de mudança / fluxo ... e se sua equipe pode lidar com isso.)

David Pollak, da Good Stuff, tem um excelente post no blog intitulado Idiomas funcionais que governará (mas não este ano) que aborda os detalhes básicos das linguagens funcionais em geral, e Scala em detalhes que eu recomendo a leitura para entender melhor se o Scala está pronto para horário nobre.

Eu nunca entendi a distinção entre enterprisee non enterpriseprogramas.

Eu uso os mesmos programas no trabalho e em casa. Eu não usaria um programa medíocre no meu tempo livre - por que deveria?

O que é um programa não profissional? Vi aplicações ruins serem usadas, porque o usuário não conhecia melhor, devido a problemas de compatibilidade ou porque se recusou a identificar algo novo.

Mas é um problema de software desatualizado e de objetivos que o desenvolvedor tinha em mente - não do idioma em que o programa foi escrito. Se você começar a pensar, em qual idioma o programa foi escrito, ele já acabou: falha.

Enterprise-application é um termo malicioso, que não é útil para discussões sérias.

E qual cliente sabe em qual idioma você fez seu trabalho? Às vezes eles se importam, às vezes não.

Você pode ter perguntas relacionadas à maturidade de um idioma - mas não pode responder a todos os tipos de empresas e aplicativos.