Por que eu amo OCaml (2023)

• O desenvolvedor, que valoriza programação funcional e garantias estáticas, passou por várias linguagens e acabou avaliando muito positivamente o design equilibrado de OCaml
• Em comparação com o sistema de tipos complexo e a compilação lenta de Haskell, OCaml oferece simplicidade e praticidade ao mesmo tempo
• Lembra o Go pela compilação rápida e runtime enxuto, mas mantém pontos fortes de linguagens funcionais como pattern matching e tipos soma
• Com builds rápidos, binários estáticos e ferramentas ricas de documentação (odig, utop), oferece alta produtividade e boa acessibilidade
• O maior atrativo de OCaml é apresentado como o equilíbrio entre simplicidade e expressividade, além de um design de linguagem refinado

---

Experiência com linguagens de programação e comparação

• A partir da experiência de desenvolver software amador e profissional em várias linguagens, o autor organiza as características de uma boa linguagem
  • Apresenta como fatores importantes: compilação rápida, runtime simples, fortes garantias estáticas, componentes funcionais, bom desempenho e qualidade da documentação
• Haskell ajudou a aprender a forma de pensar da programação funcional, mas sua sintaxe complexa e compilação lenta são apontadas como problemas
  • A tendência da comunidade de buscar complexidade e problemas de runtime como space leak tornam a manutenção difícil
• Go possibilita simplicidade, compilação rápida, boas ferramentas e compreensão de código conciso
  • Porém, seu design conservador, o tratamento de erros verboso e a ausência de verificação nula explícita aumentam a chance de bugs e causam incômodo
  • A ausência de REPL e a postura negativa em relação a ideias funcionais também são mencionadas como limitações

Principais pontos fortes de OCaml

• OCaml é avaliada como uma linguagem que atende à maior parte dos critérios acima
  • Fortes garantias estáticas: suporte a tipos soma, variantes polimórficas e pattern matching
  • Runtime simples: usa coleta de lixo, mas funciona como uma linguagem de nível de sistema
  • Compilação rápida: com o sistema de build Dune, é mais rápida que Haskell ou Rust
  • Geração de binário único com linkagem estática, facilitando a distribuição
  • Excelentes ferramentas de documentação: odig (navegação offline de documentação), utop (REPL), estrutura separada entre arquivos de interface e implementação
• O recurso de inferência automática de tipos melhora a eficiência na escrita de código
  • A estrutura de definir tipos em arquivos de interface ajuda na navegação clara pelo código

Design da linguagem e impressões

• OCaml é uma linguagem antiga, mas mantém uma sensação de design refinado
  • Alguns recursos orientados a objetos e bibliotecas complexas são considerados desnecessários
• No geral, o equilíbrio entre simplicidade e expressividade e um bom ecossistema de documentação e ferramentas são os principais atrativos de OCaml
• O autor avalia OCaml de forma muito positiva como uma “linguagem simples, mas expressiva” e menciona uma satisfação difícil de encontrar em outras linguagens

[GN⁺]

Comentários no Hacker News

• Usei um pouco de OCaml e tive vários problemas
  O suporte a Windows é péssimo, e só no OCaml 5 melhorou para algo como “bem ruim” em vez de horrível
  A sintaxe é difícil para humanos lerem, e quando dá erro de sintaxe, basta um único caractere errado para aparecer um erro de 1000 linhas
  O ocamlfmt transforma até match complexos em uma única linha, o que prejudica a legibilidade
  A documentação também é excessivamente concisa e quase não tem exemplos
  O OPAM parece bom na teoria, mas na prática tem muitos bugs; havia até um bug em que, se você pertencesse a mais de 32 grupos Unix, ele não encontrava o curl
  Como as anotações de tipo nas assinaturas de função são opcionais, isso reduz as vantagens da tipagem estática
  O ecossistema também é pequeno, e nem copiar arquivos tem função embutida
  Essa obsessão com listas simplesmente encadeadas também é ineficiente
  Ainda assim, é melhor que C ou Python, mas eu provavelmente não escolheria isso em vez de Rust

  • Para usar OCaml no Windows, eu recomendaria F# em vez disso
    Como ele tem como alvo a CLR, a distribuição é muito mais fácil, e dá para aproveitar diretamente o ecossistema .NET
    Dá para usar quase sem adaptação bibliotecas NuGet feitas para C# ou VB.NET, então o ecossistema é enorme
    A documentação de F# é muito mais rica e tem muito mais exemplos
    Links de referência: F# Language Reference, F# Core Docs, F# Cheatsheet
  • Fui ver se esse bug do curl no OPAM existia mesmo e confirmei na issue #5373
    Na verdade é um problema relacionado ao musl, causado pelo fato de o OPAM ter sido compilado com esse binário
  • A maior parte disso é questão de curva de aprendizado, mas mesmo depois de se acostumar, a desconexão do ecossistema continua
    O ocamlformat, se configurado com o perfil janestreet, fica muito melhor que o padrão
    O problema das anotações de tipo nas assinaturas de função se resolve fornecendo arquivos .mli, mas a maioria não faz isso
    Em compensação, o plugin de OCaml para VS Code oferece a melhor experiência para iniciantes
  • Concordo com a crítica à obsessão por listas simplesmente encadeadas
    No hardware de hoje, penso que a coleção padrão deveria ser vector
  • Concordo totalmente que o suporte a Windows é ruim
    Antigamente nem era possível instalar direto pelo ocaml.org; era preciso passar por mingw ou wsl
    Então, na prática, era como se nem existisse OCaml para Windows

• O motivo de os designers da linguagem Go quase não terem adotado ideias de programação funcional é claro
  Como disse Rob Pike, a maioria dos desenvolvedores do Google era jovem e acostumada com linguagens da família C, então precisavam de uma linguagem fácil de aprender
  Como mudar para a forma de pensar das linguagens funcionais exige muito tempo, Go tentou evitar esse custo

  • Na prática, também há muitos Googlers insatisfeitos com as decisões da equipe do Go

• Sempre que vejo a palavra “ML”, meu coração ainda acelera por um instante, e aí percebo que não é Meta Language, e sim Machine Learning, e me decepciono

  • ML significa Meta Language, e LLM significa o grupo de pesquisa Languages and Logic Montreal
  • Acho até melhor esse tipo de confusão
    O que me incomoda mais hoje em dia é o uso excessivo da palavra “AI”
    Eu preferiria que não usassem o termo AI até surgir uma AGI de verdade
  • Quando usei ML pela primeira vez, no fim dos anos 1980, numa máquina 80286, fiquei realmente impressionado
  • Já postei um comentário parecido antes e levei um monte de downvotes; desta vez fico feliz que a reação tenha sido melhor

• Se você assistir à palestra de Richard Feldman, ela explica bem por que linguagens funcionais não conseguiram se popularizar
  Ou a linguagem domina uma plataforma, ou tem um aplicativo matador, ou conta com um orçamento gigantesco de marketing
  O motivo de Python ter crescido tanto também foi ter se tornado a linguagem central do ecossistema de AI
  Eu também aprendi programação funcional com OCaml e fiz projetos com Haskell e Zig, mas no fim voltei à realidade de “usar as ferramentas que dão para usar”
  OCaml, Rust e Haskell são populares como linguagens que as pessoas “querem aprender”, mas não como linguagens “amplamente usadas de fato”

  • Não concordo com a afirmação de que a popularidade do Python se deve à AI
    O Torch era originalmente baseado em Lua, e foi migrado para Python, que já era muito popular
  • Acho que o motivo de programação funcional não ter virado mainstream foi a postura elitista
    O pessoal de FP foi indiferente às mudanças tecnológicas do mundo real, e nesse meio-tempo linguagens como C, Pascal, Perl e Tcl ocuparam o mercado
    No fim, FP ficou como “os sacerdotes dentro da catedral”, enquanto as linguagens imperativas conquistaram o público

• Já usei F#, e a concorrência baseada em Actors me pareceu fácil de entender
  Mas quando entram em cena arrays mutáveis, tudo fica mais complicado
  Tenho curiosidade sobre por que alguém preferiria OCaml a F# no trabalho

  • F# está perdendo compatibilidade aos poucos por causa de mudanças na CLR, e o compilador é lento, com ferramentas instáveis
    Já OCaml conta com remoção do lock global, compilação rápida e recursos poderosos como módulos, GADTs e effects
    F# ainda leva vantagem em suporte a Windows, SIMD e tipos sem boxing, mas OCaml está alcançando aos poucos
  • A integração do F# com .NET é uma faca de dois gumes
    Há muitas bibliotecas, mas a maioria não tem estilo de F#
    OCaml tem um ecossistema nativo maior
  • Na empresa, desenvolvemos as partes mais intensivas em computação com F#
    A interoperabilidade com C# é boa, mas usar bibliotecas F# a partir de C# era um pesadelo
    No fim, você acaba mantendo uma camada externa em C#, e a base de código vira um híbrido
    O ecossistema .NET é rico, mas a forma de pensar centrada em OOP entra em choque com o estilo FP
    O Visual Studio é confortável, mas é ruim para fluxos de trabalho baseados em CLI
    A velocidade de compilação só vai piorando, e testar também é estranho
    Quando usei OCaml, o design ergonômico da linguagem pareceu muito mais natural
  • OCaml é muito mais poderoso que F# em aspectos como functors, módulos de primeira classe, GADTs e sistema de objetos
    F# é chamado de “OCaml para .NET”, mas na prática é apenas uma linguagem da família ML; são quase linguagens diferentes

• Como OCaml é uma linguagem antiga, talvez dê para abrir mão dos recursos de OOP, mas acho que Standard ML é mais completo

  • Eu também gosto de SML, mas o sistema de objetos do OCaml é subestimado
    Ele é útil para registros com tipagem estrutural, open recursion e bindings de JS como Js_of_ocaml
  • Estou escrevendo um compilador em SML, e ele tem restrições estranhas como sobrecarga de int/real e value restriction
    Também não oferece suporte a atualização de registros, o que é inconveniente
  • Antes eu gostava mais de SML, mas naquela época estava na moda linguagem “com O no nome”, e por isso OCaml recebeu mais atenção

• Desde o começo dos anos 2000, OCaml sempre foi uma “linguagem quase perfeita”
  Mas, quando os pontos de atrito começaram a ser resolvidos, outras linguagens já tinham absorvido essas ideias

  • OCaml é uma linguagem como o Velvet Underground
    Pouca gente aprende, mas todo mundo que aprende vai lá e cria uma nova linguagem
    Fonte
  • Mesmo assim, OCaml realmente opera sistemas de negociação de bilhões de dólares
  • Não entendo o que seria esse “atrito”
    Já existem muitos projetos rodando bem em OCaml
    E agora, com a adição de um sistema de effects, ele está até mais avançado

• Popularidade e qualidade são coisas diferentes
  popularidade ≠ excelência, e na música também é assim
  Isso só é decidido por tendências e inércia

  • Popularidade e grau de simpatia têm até uma correlação inversa
    Quanto mais usada uma linguagem é, mais gente a odeia,
    e quanto mais desconhecida, mais fácil é superestimá-la
  • O “bom” na música é subjetivo, mas o “bom” de uma linguagem pode ser objetivado pela eficiência na resolução de problemas
    OCaml é menos popular porque o grupo de usuários que sente essa eficiência é pequeno
    E a postura dogmática do pessoal de FP também contribui

• Acho que Elixir é uma linguagem parecida com OCaml, mas com mais chance de se popularizar
  Ela tem vantagens de FP como imutabilidade, pattern matching e modelo Actor,
  e funciona com estabilidade sobre a runtime BEAM
  Não tem tipagem estática, mas está adotando verificação de tipos gradual

  • Na verdade, o que mais me intriga é por que F# não é mais popular
    Mesmo podendo usar diretamente o ecossistema .NET, ele é menos conhecido que OCaml
  • Elixir tem ecossistema e ferramentas excelentes, e a sintaxe é mais familiar que a de Erlang
    Há inclusive muitas empresas que a usam em backends de SaaS
  • Mas a maioria das organizações considera o paradigma funcional (centrado em recursão) algo pesado
    Por isso as linguagens FP continuam sendo de nicho
  • Pessoalmente, acho Elixir menos cansativo mentalmente e mais flexível que OCaml
  • Gleam também é interessante, mas linguagens que não compilam não servem para o meu trabalho

• OCaml se parece com Go no sentido de ser uma linguagem de sistemas com GC
  Eu prefiro GC a gerenciamento manual de memória ou borrow checking
  O GC da linguagem D também era excelente, mas o problema é que a própria palavra “GC” assustava as pessoas