O que é a Scarf e por que essa historia importa

A Scarf e uma empresa americana que fornece ferramentas de analytics para projetos open source, ajudando mantenedores a entenderem como seus pacotes são baixados e usados ao redor do mundo. E o tipo de produto que roda em infraestrutura crítica com alto volume de requisições.

Em julho de 2026, o fundador da Scarf publicou um post detalhado explicando que a empresa decidiu, com relutância, abandonar Haskell como linguagem principal após 7 anos de uso em produção. A palavra-chave no titulo original e 'reluctantly' (com relutância) - eles não queriam sair, mas chegaram a conclusão de que era necessário.

Essa historia gerou mais de 80 comentários no Hacker News porque toca numa questão permanente no mundo do desenvolvimento: quando faz sentido usar linguagens não-convencionais em produção e quando o custo supera o beneficio?

Como funciona o Haskell e por que empresas o escolhem

Haskell e uma linguagem de programação funcional pura com tipagem estática forte. 'Pura' significa que funções não tem efeitos colaterais implícitos - você controla explicitamente o que acontece com o mundo externo (IO, estado, etc.) através do sistema de tipos.

O grande atrativo do Haskell e que muitas categorias de bugs simplesmente não compilam. Se o seu código compila em Haskell, as chances de conter certos tipos de erros de lógica ou de tipo são muito menores do que em linguagens dinâmicas ou com tipos mais permissivos. Isso e especialmente valioso para sistemas financeiros, compiladores e infraestrutura crítica.

Outras empresas que usaram ou usam Haskell em produção incluem Standard Chartered (sistema bancário), Mercury (banco digital) e o próprio Facebook (sistema Sigma de detecção de spam). O padrão e: equipes pequenas de engenheiros altamente especializados usando Haskell para problemas onde corretude e prioritária.

💡
Dica

Se você quer entender Haskell antes de decidir usa-lo, o livro 'Learn You a Haskell for Great Good' e gratuito online e e considerado o melhor ponto de entrada para a linguagem.

Principais motivos que levaram a Scarf a abandonar Haskell

O post original da Scarf aponta vários fatores. O primeiro e o mais citado e o problema de contratação: encontrar engenheiros com experiência em Haskell e extremamente difícil no mercado atual. Isso cria dependência de pessoas específicas e torna o onboarding de novos membros lento e custoso.

O segundo fator e o ecossistema de bibliotecas. Embora o Hackage (repositório de pacotes Haskell) tenha muitas opcoes, a qualidade e manutenção são variáveis. Para certas integraces comuns (APIs de terceiros, ferramentas de observabilidade, frameworks web modernos), as opcoes em Haskell são limitadas ou menos maduras do que em Go, Python ou TypeScript.

O terceiro fator, mais sutil, e o custo cognitivo de contexto. Haskell tem uma curva de aprendizado que nunca termina - conceitos como monads, typeclasses, lazy evaluation e programação com tipos de maior ordem exigem estudo continuo. Em times que crescem, isso significa que cada novo engenheiro precisa de meses para ser produtivo.

⚠️
Atenção

Adotar uma linguagem de nicho em produção e uma decisão de longo prazo. O custo de contratação e onboarding pode superar os benefícios técnicos ao longo dos anos, especialmente em equipes que precisam crescer.

Como começar a avaliar uma mudança de stack na sua empresa

O processo de decisão descrito pela Scarf pode servir de modelo para outras equipes que estão considerando uma mudança similar. O primeiro passo e documentar os custos reais da stack atual: tempo de onboarding de novos engenheiros, dificuldade de contratar, incidentes relacionados a ferramentas específicas da linguagem, e velocidade de desenvolvimento de features.

O segundo passo e identificar o que você perderia. No caso da Scarf, o sistema de tipos do Haskell preveniu categorias inteiras de bugs. Qual seria o custo equivalente em testes, code review e ferramentas de análise estática na nova linguagem?

# Checklist rápido para avaliar mudança de stack
# Responda cada item com um número de 1 a 5

- Dificuldade de contratar (1=fácil, 5=muito difícil): ?
- Tempo de onboarding de novos devs (semanas): ?
- Número de libs de terceiros indisponíveis/imaduras: ?
- Velocidade de desenvolvimento de features novas: ?
- Satisfação da equipe técnica com a linguagem: ?

# Se a soma for acima de 15: vale reavaliar o stack

O terceiro passo e escolher a linguagem destino com base nos seus problemas específicos, não nas tendências do mercado. A Scarf foi para uma linguagem com ecossistema maior, mas isso não significa que todos devem fazer o mesmo movimento.

Exemplo prático: o que muda na transição de Haskell para outra linguagem

Para ilustrar o que a Scarf enfrentou, considere um módulo típico em Haskell que processa eventos de download. Em Haskell, o compilador garante que você não pode passar um tipo errado para uma função - se o código compila, o fluxo de dados esta correto por construção.

Na linguagem destino (suponha Go ou TypeScript), essa garantia precisa ser replicada com uma combinação de: testes unitários para cobrir os casos que o tipo cobria, linters e analisadores estáticos como ESLint ou staticcheck, e code review mais rigoroso para casos que o compilador não pega.

Isso não e necessariamente pior - muitas equipes preferem essa abordagem por ser mais familiar. Mas e um custo real que precisa ser planejado. A transição não e só reescrever código: e readaptar toda a cultura de qualidade da equipe.

🚀
Pro tip

Se você vai sair do Haskell (ou de qualquer linguagem com sistema de tipos forte) para outra com tipos mais fracos, invista antes na cobertura de testes. Escreva os testes enquanto ainda entende os invariantes que o compilador garantia.

Comparação: quando usar Haskell versus alternativas mainstream

Haskell não e para todos os contextos. Veja quando ele faz sentido versus quando alternativas são melhores:

  • Haskell: sistemas onde corretude e prioritária acima de velocidade de desenvolvimento, equipes pequenas de especialistas, compiladores e interpretadores, sistemas financeiros críticos
  • Go: serviços de rede com alto throughput, quando você precisa contratar facilmente e ter performance previsível com GC controlado
  • TypeScript: quando parte do time já e full-stack e você quer reusar conhecimento, ou quando o produto tem muita UI e lógica compartilhada
  • Rust: quando você quer garantias de corretude e performance sem GC - uma alternativa a Haskell para sistemas de baixo nível

A Scarf escolheu uma linguagem com ecossistema maior. Mas isso não significa que Haskell estava errado para eles naquele momento - durante 7 anos, a linguagem serviu bem ao produto.

Pontos positivos e limitações do Haskell em produção

Os pontos positivos documentados por usuários de Haskell em produção são consistentes: menos bugs em produção relacionados a tipos e lógica de negócio, código mais conciso para lógica complexa, e refatorações mais seguras porque o compilador pega regressões.

As limitações também são bem conhecidas. Lazy evaluation (avaliação preguiçosa, o padrão em Haskell) pode causar problemas de uso de memoria difíceis de debugar. O ecossistema de ferramentas de observabilidade (tracing, profiling) e menos maduro do que em linguagens mais populares. E a curva de aprendizado nunca se achata completamente.

🔴
Cuidado

Space leaks (vazamentos de memoria causados por thunks não avaliados) são um problema real em Haskell com lazy evaluation. Sem ferramentas de profiling adequadas, podem ser muito difíceis de diagnosticar em produção.

Casos de uso onde Haskell ainda faz sentido

Para startups de fintech com foco em corretude, Haskell continua sendo uma escolha valida. Mercury Bank, por exemplo, usa Haskell em produção com sucesso. O segredo e uma equipe de engenheiros que valoriza a linguagem e permanece na empresa por tempo suficiente para amortizar o custo de aprendizado.

Para projetos académicos e de pesquisa, Haskell e excelente: a linguagem e muito usada em teoria de tipos, compiladores e verificação formal. Se o seu projeto e de pesquisa com publicação, Haskell tem uma comunidade académica ativa.

Para ferramentas de linha de comando e utilitários, Haskell compila para binários eficientes e o ecossistema de parsing e processamento de texto e maduro. Muitas ferramentas populares como Pandoc, ShellCheck e XMonad são escritas em Haskell.

Para equipes que querem aprender programação funcional, Haskell como projeto secundário ou ferramenta interna e um excelente exercício que melhora a qualidade do código em qualquer outra linguagem que a equipe use.

Dicas e boas práticas

💡
Dica 1: Faca um piloto real antes de adotar em produção

Antes de comprometer sua empresa com uma linguagem de nicho, rode um serviço real com ela por 3 a 6 meses. Você vai descobrir problemas de onboarding, tooling e ecossistema que não aparecem em tutoriais.

💡
Dica 2: Documente os invariantes garantidos pelo tipo

Se você usa Haskell (ou Rust, ou qualquer linguagem com tipos fortes), documente quais invariantes o sistema de tipos garante. Isso e ouro se você precisar migrar um dia - você sabe exatamente o que precisa replicar com testes.

🚀
Pro tip: aprenda Haskell mesmo sem usar em produção

Estudar Haskell muda como você pensa sobre código em qualquer linguagem. Conceitos como imutabilidade, composição de funções e efeitos explícitos aparecem em Rust, TypeScript, Swift e até Python moderno. E um investimento que paga em todo lugar.

⚠️
Não romanticize a linguagem

Cada decisão de stack tem tradeoffs. Haskell não e melhor ou pior - e diferente. Escolha baseada no seu contexto: tamanho da equipe, necessidade de contratação, maturidade do ecossistema para o seu domínio.

Vale a pena?

A historia da Scarf não e um veredicto contra o Haskell - e uma licao sobre contexto. Por 7 anos, a linguagem serviu bem a empresa. A decisão de sair foi baseada em fatores de negócio (contratação, crescimento de equipe) mais do que em problemas técnicos fundamentais.

Se você esta considerando Haskell para um novo projeto, a pergunta certa não e 'Haskell e bom?' mas sim 'Haskell e bom para o meu contexto?' Equipe pequena de especialistas que valoriza corretude e disposta a investir em aprendizado: provavelmente sim. Time grande que precisa contratar rapidamente e entregar features em alta velocidade: provavelmente não.

O próximo passo prático: leia o post original do fundador da Scarf (linkado abaixo) para entender os detalhes reais da decisão. E um dos relatos mais honestos sobre uso de linguagem de nicho em produção que existe.