OxCaml - Conjunto de extensões para a linguagem de programação OCaml

 (oxcaml.org)
1 pontos por GN⁺ 2025-06-15 | 1 comentários | Compartilhar no WhatsApp
  • OxCaml é um conjunto de extensões que adiciona recursos voltados a desempenho ao OCaml
  • Atua como o compilador de produção da Jane Street e como um laboratório de experimentação para recursos futuros do OCaml
  • Busca ampliar o controle de desempenho com foco em segurança, conveniência e previsibilidade
  • Oferece recursos em várias áreas, como fearless concurrency, controle de layout e controle de alocação
  • É disponibilizado como open source, permitindo que usuários experimentais e pesquisadores testem livremente e enviem opiniões

Introdução ao OxCaml

O que é o OxCaml

  • OxCaml é um conjunto de extensões em rápida evolução para a linguagem de programação OCaml
  • Ele é o compilador de uso prático da Jane Street e uma plataforma experimental para fortalecer a programação orientada a desempenho no OCaml
  • O objetivo é contribuir essas extensões ao OCaml oficial no longo prazo

Principais objetivos de design do OxCaml

  • O objetivo é oferecer um ambiente no qual seja possível controlar, de forma segura, conveniente e previsível, os fatores determinantes de desempenho do comportamento do programa
  • Esse controle é fornecido de forma opcional apenas quando realmente necessário
  • Tudo é implementado dentro do ecossistema do OCaml

Abordagens concretas de design

  • Segurança: reforça a segurança da linguagem para garantir a produtividade do programador e a correção do código. Linguagens amplamente inseguras são difíceis de usar

  • Conveniência: oferece controle sem aumentar a complexidade da programação e mantendo os benefícios da inferência de tipos

  • Previsibilidade: expõe as principais características de desempenho de forma explícita no nível do sistema de tipos, facilitando o raciocínio sobre o desempenho do código

  • Essas extensões seguem um modelo pay-as-you-go, aplicado apenas nas partes necessárias. Ou seja, se você não usar os recursos de extensão, poderá manter a simplicidade e os padrões do OCaml existente

  • OxCaml é compatível com todos os programas OCaml e, internamente, aponta para uma evolução do OCaml. Mantém a segurança, facilidade de uso e produtividade do OCaml atual

Recursos de extensão do OxCaml

Fearless concurrency

  • Para enfrentar a dificuldade de escrever programação concorrente correta, o OxCaml usa extensões no sistema de tipos para bloquear estaticamente data races

Layouts

  • Permite que o programador especifique explicitamente o layout dos dados na memória
  • Também oferece acesso nativo às extensões de processador SIMD do hardware moderno

Controle de alocação

  • Fornece ferramentas para controlar detalhadamente a alocação de memória, reduzindo a carga do garbage collection (GC) e melhorando a eficiência de cache e o determinismo do programa

Melhorias de qualidade de vida

  • Além da programação de sistemas, oferece recursos que se mostraram úteis em tarefas individuais

    • Polymorphic parameters
    • Include functor
    • Labeled tuples
    • Immutable arrays

Uso e adoção do OxCaml

  • OxCaml é open source e permite que pesquisadores, usuários experimentais e desenvolvedores contribuam por meio de testes e feedback

  • No entanto, os recursos de extensão do OxCaml não garantem estabilidade nem retrocompatibilidade (embora a retrocompatibilidade com programas OCaml existentes seja garantida)

  • São fornecidas versões das ferramentas padrão do OCaml adaptadas ao OxCaml

    • Gerenciamento de pacotes: compatível com dune e opam
    • Integração com editores: suporte a LSP-server
    • Formatação de código-fonte e geração de documentação incluídas

  • Várias bibliotecas e ferramentas publicadas pela Jane Street são fornecidas em duas formas

    • Para o OCaml upstream: versão com as extensões do OxCaml removidas
    • Exclusiva para OxCaml: versão que utiliza os recursos de extensão

  • Alguns recursos de extensão não podem ser removidos, por isso essas bibliotecas só podem ser usadas no OxCaml. Quando as extensões necessárias forem integradas ao OCaml oficial, uma versão compatível com OCaml também deverá ser publicada

Leituras relacionadas

1 comentários

 
GN⁺ 2025-06-15
Comentários no Hacker News

  • Gostaria de destacar que, em relação a este projeto criado pela equipe da Jane Street, houve uma discussão interessante em um episódio de podcast com participação deles sobre considerações de desempenho ao trabalhar com OCaml
    A preocupação com o uso de linguagens com GC em ambientes de latência ultrabaixa continua existindo
    Por exemplo, se uma pausa do GC acontecer no meio de uma operação de trading de alta frequência, isso pode se tornar um problema grave
    Compartilho o link do podcast

    • Compartilha a experiência de ter perguntado diretamente ao Ron Minsky no Twitter por que não usam Rust em aplicações de baixa latência
      Na resposta, Ron reconheceu que Rust é excelente, mas focou no valor de manter todo o código em uma única linguagem
      Há grande vantagem em compartilhar tipos, ferramentas, bibliotecas, idiomatismos e facilitar a mobilidade entre projetos
      Também menciona que o OCaml está evoluindo internamente para incorporar bem as principais vantagens do Rust, permitindo adoção gradual
      Como desvantagens do Rust, cita tempos de compilação longos, sistema de tipos complexo e insatisfação com o tratamento de async/await
      Acima de tudo, enfatiza a preferência por uma ferramenta de linguagem única adequada a uma ampla variedade de ambientes de trabalho
      Link para o tweet

    • Enfatiza que a linguagem com GC em si não é o problema central, mas sim a visão de tratar todas as linguagens com GC como se fossem iguais
      O verdadeiro problema aparece quando a linguagem com GC não oferece manipulação explícita de stack e tipos por valor
      Se você quer a produtividade de uma linguagem com GC junto com opções refinadas para programação em nível de sistema, cita alternativas como Cedar, família Oberon, Modula-3, D, Nim, Eiffel, C#, F#, Swift e Go

    • Em termos gerais sobre ambientes de runtime que usam GC, é possível usar algoritmos como o coletor paralelo da JVM para minimizar pausas de GC
      No entanto, esse método não oferece garantias uniformes, então pode exigir overprovisioning de RAM do sistema
      Indo além, também existe a estratégia de fazer overprovisioning intencional dos servidores para que alguns possam sair temporariamente do pool e executar um "GC offline"
      Essa abordagem exige cooperação entre roteadores de requisições e servidores, então só faz sentido quando há orçamento suficiente para ampliar a infraestrutura
      Explicação do GC paralelo da JVM

    • Compartilha a experiência de vários sistemas sofrendo com problemas de compactação do GC
      Em sistemas de trading, costuma-se adotar a política de minimizar alocações depois da inicialização
      Em JS existe uma biblioteca chamada "Zero" que oferece utilitários sem alocação

    • Diz que não verificou o link, mas comenta que, em ambientes como trading com abertura e fechamento do mercado, talvez fosse possível desativar o GC durante o pregão e reiniciar após o fechamento

  • Gostaria de destacar que o primeiro recurso deste fork a ser enviado para o upstream foi labeled tuple
    O suporte está previsto para o OCaml 5.4
    Link do PR upstream
    Link da discussão relacionada

    • Mesmo que esse recurso pareça um pouco pequeno, há bastante expectativa em torno dele
      Também gostaria de acrescentar, como informação, o artigo e o vídeo apresentados pelo autor do recurso na ML2024
      Vídeo no YouTube
      PDF do artigo

    • Como exemplo de labeled tuple, ele pode evitar erros com a ordem de pares, mas pessoalmente há quem prefira mais os registros anônimos do F#
      Por exemplo, {| product = 6; sum = 5 |} não tem significado associado à ordem dos campos, então não há esse tipo de erro

    • Neste fork, immutable array também entrou no 5.4, com apenas uma pequena diferença de sintaxe

    • Enfatiza que struct e enum anônimos com labels estão entre os recursos mais desejados em uma linguagem de programação
      Como exemplo, em Rust é possível definir tanto struct com labels quanto sem labels,
      mas lamenta que não seja possível usar um struct anônimo com labels como tipo de retorno de função

      struct Foo(i32, i32);
struct Bar{sum: i32, product: i32}
fn can() -> (i32, i32)
fn cant() -> {sum: i32, product: i32}

  • Não sabia que este fork oferecia suporte a SIMD
    Se também tiver unboxed type, alocação explícita na stack e suporte a Windows, menciona a possibilidade de o OxCaml se tornar bastante viável, em vez de F#, em ambientes voltados ao consumidor, como game dev

    • No momento, SSE/NEON de 128 bits já está funcionando, e o suporte a AVX deve chegar em breve
      O suporte a Windows não está exatamente bloqueado, mas requer algum trabalho
      Também gostaria de destacar que o OxCaml adicionou suporte a SIMD

  • Compartilha uma dica de configuração de variável de ambiente para quem usa um novo opam switch
    env OCAMLPARAM="alert=-unsafe_multidomain,_," opam install cohttp-lwt-unix
    Isso resolve o problema de instalações antigas quebrarem desnecessariamente quando alertas são promovidos a erro
    É possível evitar o problema de instalação desativando esse alerta com a variável de ambiente OCAMLPARAM

  • Diz estar acostumado com um excelente plugin do vscode para Golang e pergunta se há planos de integrar o ambiente OCaml ao vscode
    A integração com vscode tornou a configuração muito simples

    • O próprio plugin de OCaml para vscode já oferece bastante suporte à integração de sintaxes mais novas, como dune, menhir e reason
      Se o OxCaml ganhar popularidade, é natural que essa integração avance
      Pessoalmente usa emacs, então não consegue comentar em muitos detalhes, mas considera esse um caminho natural

  • Gostaria de mencionar uma versão micro do OcaML
    Link do projeto mlite

  • Pergunta se o objetivo de tornar este projeto público pode ter sido permitir que LLMs indexem as informações e as usem em modelos abertos

    • Considera que isso não faz sentido algum, porque as LLMs já são fracas até mesmo com OCaml comum e há pouco volume de dados; com OxCaml, o material é ainda mais escasso
      Para esse tipo de finalidade, faria mais sentido criar um MCP com documentação própria

    • Como sinal, isso não tem valor suficiente, então na prática é irrelevante
      Por exemplo, mesmo ao completar Gleam, o desempenho das LLMs é muito fraco e falha mesmo quando recebe padrões claros e instruções explícitas sobre erros
      Por isso, considera fraco demais o sinal para que o objetivo fosse fornecer informações sobre OxCaml

  • Aponta como curioso o fato de o OxCaml ser uma extensão de um dialeto de uma família de dialetos do tipo ML
    Há expectativa para ver como será o próximo passo

    • Já se perguntou quem é mais problemático: as pessoas que continuam adicionando recursos a linguagens existentes ou as que simplesmente criam novas linguagens desde o início
      Diz pertencer ao segundo grupo, mas acha que programadores têm uma característica quase genética de não conseguir deixar as ferramentas como estão

    • Faz uma sugestão em tom de brincadeira perguntando se também poderiam apresentar F#

  • Confirma que o projeto usa o nome "oxidized" por causa de objetivos de recursos associados ao Rust, como fearless concurrency e evitar GC, e não porque use Rust de fato
    Comenta que é um nome que pode causar certa confusão

    • Aponta uma pequena ironia: o nome Rust, na verdade, viria do mofo "Rust", e não de ferrugem

    • Compartilha que a Jane Street mantém há muito tempo uma série de posts chamada "Oxidizing OCaml"

    • O termo também foi usado no título do artigo "Oxidizing OCaml with Modal Memory Management", mas dentro do artigo a palavra oxidize não foi definida nem citada explicitamente
      É estranho, mas passa a impressão de ser um nome bastante viciante

    • Prevê que, do lado do Rust, a integração com um tracing GC customizado — que permite lidar com estruturas de grafo gerais enquanto ainda busca desempenho máximo — continuará sendo mais prática até que este projeto alcance paridade funcional com Rust
      Caso contrário, avalia que a manutenção aconteceria basicamente por já existir muito código relacionado a OxCaml