Nim 2.0 - linguagem de programação focada no paradigma de programação imperativa e no sistema de macros

• O gerenciamento de memória ORC passa a ser o padrão
• O backend JavaScript usa BigInt por padrão para int64 e uint64, e pode ser necessário atualizar códigos que usam esses tipos ao integrar com o backend JS
• --experimental:strictEffects fica sempre ativado, e parâmetros de callback exigem a anotação effectsOf
• A linguagem de marcação padrão para comentários de documentação muda do modo RstMarkdown para Markdown, e são adicionados o pragma {.doctype: Markdown | RST | RstMarkdown.} e os comandos md2html e rst2html
• Parte das funcionalidades relacionadas a os da biblioteca padrão foi separada em uma nova interface que usa a abstração Path, disponível nos módulos std/oserrors, std/envvars, std/paths, std/dirs, std/files, std/symlinks, std/appdirs, std/cmdline
• Vários módulos da biblioteca padrão foram movidos para pacotes Nimble, e o uso de std/punycode, std/asyncftpclient, std/smtp, std/db_*, std/md5, std/sha1, std/sums passa a exigir instalação via nimble ou atlas
• O uso de break sem nome dentro de block sem nome entra em descontinuação (deprecation) e será tratado como erro em versões futuras
• A definição de "strictFuncs" foi alterada para proibir armazenamento em desreferências de ref ou ptr
• O desempacotamento de tuplas em variáveis passa a ser tratado como açúcar sintático expandido em múltiplas atribuições, permitindo desempacotamento de tuplas aninhadas
• A inferência top-down foi implementada em vários casos padrão, permitindo compilar o código de inicialização de seq[(float, byte, cstring)] do exemplo
• Agora é possível definir valores padrão para campos de objetos, e esses valores serão usados em campos não inicializados explicitamente
• Foi adicionada a opção experimental strictDefs, que verifica se variáveis receberam valor explicitamente antes do uso, e se variáveis let foram atribuídas exatamente uma vez
• Foram adicionados o pragma virtual e a extensão do pragma constructor para interoperabilidade com C++, permitindo definir construtores e procs virtuais mapeados para construtores e métodos virtuais de C++
• Nimble 0.14 é incluído junto, com suporte a lock-file, e o local de armazenamento das bibliotecas muda de $nimbleDir/pkgs para $nimbleDir/pkgs2

[GN⁺]

Comentários do Hacker News

• Tenho usado Nim em produção com satisfação. Faço principalmente ferramentas de análise de dados e geração de relatórios, e as compilo como executáveis CLI chamados por scripts de servidor.
  Nim gera executáveis rápidos e pequenos, e tem boas bibliotecas para estruturas de dados JSON heterogêneas e dataframes. Ele tem uma forte preferência pela stack, então mesmo estruturas de dados dinâmicas como sequências e tabelas têm um ponteiro na stack apontando para dados no heap, e o tempo de vida é gerenciado pelo frame da stack.
  Quase não há referências dinâmicas no programa e não preciso me preocupar com GC. O sistema de tipos é simples e sensato, e conduz facilmente a código correto. Os padrões também são próximos de transparência referencial; a menos que você saia disso explicitamente, tudo é passagem de valores imutáveis.
  Generics são poderosos e funcionam como esperado, e a sintaxe universal de chamada de funções é absurdamente útil. Basta criar procedures e funções que recebam um tipo específico como primeiro argumento para escrever algo equivalente a métodos ou interfaces, o que elimina a necessidade dessas abstrações e deixa a estrutura do código simples e plana.
  É tão prazeroso quanto quando descobri D no passado, e até melhor. Imagine um Python com anotações de tipos, compilado nativamente, sem excessos e em que quase 100% é lógica de negócio; isso chega perto da experiência com Nim.

  • Essa descrição não é algo como um vector ou map de C++ colocado na stack? Ele aloca internamente quando necessário, e o contêiner inteiro é destruído quando sai do escopo.
  • Fiquei com vontade de dar uma olhada em Nim. Tenho curiosidade sobre como é o sistema de build. CMake é realmente sofrido.
  • Realmente parece Python. Tomara que fique mais popular; parece um Rust muito mais fácil de usar.
  • Parece bom. Tenho curiosidade sobre o estado do gerenciamento de pacotes e sobre quão sólido é o ecossistema hoje.

• Estou ansioso para experimentar esta versão. Como alguém que programa profissionalmente há 25 anos, vejo Nim como uma linguagem que reúne bem o melhor de vários mundos.
  É fácil de usar como Python, é fortemente tipada, mas com ótima inferência de tipos, e os padrões são rápidos e seguros. Vai bem de embarcados a computação de alto desempenho.
  Graças a UFCS, generics e concepts, você obtém as vantagens de OOP, mas com menos necessidade de criar código de sustentação estabelecendo sem parar relações frágeis entre dados apenas para organização. Diferentemente de Python, ambiguidades viram erros de compilação.
  Sinto que o mesmo programa fica muito menor, mais legível e mais fácil de entender do que na maioria das outras linguagens. Também não há muita mágica acontecendo por trás, porque os padrões fazem sentido.
  Metaprogramação em tempo de compilação está em outro nível. Ela faz parte do núcleo do design da linguagem, sem dialetos separados nem truques de substituição, e é intuitiva de usar. Por exemplo, é fácil gerar código de parsing personalizado a partir de arquivos para eliminar boilerplate repetitivo, e a compilação também é rápida.
  Graças ao excelente sistema de tipos, é mais fácil escrever bem do que em Python, mas o desempenho fica no nível de C/C++, e a distribuição é muito fácil em executáveis pequenos e independentes.
  Tem ABI nativa para C, C++, ObjC e JS, excelente FFI e boa interoperabilidade com Python. Você pode usar diretamente os ecossistemas existentes sem reescrevê-los.
  Imagine escrever pseudocódigo no estilo Python para ESP32, obtendo algo muito eficiente sem muito esforço, e ainda podendo controlar bare metal quando quiser. Ou escrever um app web com backend e frontend na mesma linguagem eficiente, criar um jogo rápido de bullet hell e, ainda assim, não se preocupar com GC porque, salvo indicação explícita, a alocação é na stack.
  Do ponto de vista de negócios, também há muito valor no fato de você prototipar rapidamente como em Python, mas o resultado já ser rápido e leve o bastante para produção. Pode virar uma arma secreta da empresa.

  • Uso Nim como alvo de scripting para jogos e outros usos que não posso detalhar. Isso porque ele pode ser traduzido para C e C++.
    Gosto muito de poder gerenciar diretamente o ambiente C por baixo, enquanto uso por cima uma linguagem moderna de alto nível em que coisas como JSON têm ótimo suporte de primeira classe. Mesmo gostando de Python, Nim é melhor: é um Python melhor.
  • Tenho curiosidade sobre como, concretamente, funciona escrever um app web com backend e frontend na mesma linguagem eficiente.
    Em especial, quero saber quão conveniente é a interoperabilidade com JS durante o desenvolvimento, e se ela vai além de compilar Nim para JS como uma biblioteca independente. Dá para chamar APIs do navegador diretamente a partir de Nim, ou com wrappers bastante simples?
  • Em casos em que microssegundos importam, como código que processa ADC a 22 kSPS em um ESP32, sinceramente precisei de umas 2 horas de ajuste. Na época eu ainda estava começando a aprender Nim, então o trabalho foi principalmente evitar alocações extras.
    Ainda assim, em cerca de 4 anos não houve grande regressão de desempenho nem mudanças necessárias.

• Parabéns a todos os envolvidos e a toda a comunidade Nim. Uso Nim como minha linguagem principal há 10 anos, e gostei muito dos novos recursos do Nim 2.0.
  Alguns deles são realmente transformadores para meus projetos. Por exemplo, valores padrão de objetos podem, em teoria, permitir que Norm[1] funcione não só com instâncias de objetos, mas também com tipos de objetos. Sem os novos enums sobrecarregáveis, Karkas[2] teria sido simplesmente impossível. Ainda está em andamento.
  [1] https://norm.nim.town
  [2] https://karkas.nim.town

  • Entre as mudanças recentes, os valores padrão são meus favoritos. Além de serem úteis no geral e reduzirem ainda mais o boilerplate de inicialização, eles permitem garantir estados válidos em tempo de compilação em coisas como enums. Imagino que isso também se aplique a variantes de objetos.

• Nim é uma linguagem realmente boa para escrever software. Dá para entregar rápido e desenvolver com prazer, produzindo software de altíssimo desempenho.
  Dito isso, pela minha experiência, ainda há algumas arestas. É preciso acertar o compilador C/C++ e as opções, as mensagens de erro são muito pobres, e algumas bibliotecas só funcionam com certas configurações e sistemas. Ainda assim, considerando que a comunidade é pequena, é difícil culpar muito. A integração com VS Code funcionou bem e quase não travou.

  • Mensagens de erro péssimas e ferramentas insuficientes são, na minha opinião, os maiores problemas de Nim. Fora isso, no geral é uma ótima linguagem.
  • Pelo menos os relatórios de erro melhoraram recentemente: https://nim-lang.org/blog/2023/03/31/version-20-rc2.html

• Se a Manning Publications vir isso, seria ótimo se saísse um livro atualizado para a versão mais recente do Nim, e eu gostaria que considerassem uma diagramação diferente, com uma fonte mais legível
  Comprei o excelente livro do Dominik Picheta, mas, por causa da fonte fina na edição impressa, era difícil demais ler mesmo com óculos ajustados, então tive que usar o PDF. Elementos da fonte, como traços e hastes, são finos demais
  Achei que talvez fosse um problema meu por causa da idade, então comparei com a edição original da 2ª edição de K&R, e esse livro ainda era perfeitamente legível

  • O líder do projeto, araq/Andreas Rumpf, também publicou um livro: https://nim-lang.org/blog/2022/06/29/mastering-nim.html
  • Não sou da Manning, mas, se você tiver uma conta de login, pode enviar esse tipo de solicitação pela página de contato: https://www.manning.com/contact

• O Reddit escreveu sobre como usa Nim: https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enj...
  Cada vez mais grandes empresas e startups estão adotando Nim. Estou muito animado com o Nim 2.0 e sou muito grato a todos que contribuíram

  • É interessante dizer que cada vez mais grandes empresas e startups o estão adotando. Fico curioso se há estatísticas ou dados relacionados, ou se é algo anedótico
    Mesmo que seja anedótico, dá para citar alguns nomes de empresas?

• Nim foi minha linguagem favorita por um bom tempo, e estou muito animado que a versão 2.0 finalmente tenha sido lançada. Muitos dos recursos desta versão eram aguardados havia muito tempo
  O único ponto negativo é que, como mencionado lá no fim, alguns módulos incluídos foram movidos para repositórios de terceiros. Não é um grande problema, mas era bom ter suporte a SQLite integrado à biblioteca. Quando se começa a oferecer suporte a alguns bancos de dados, acaba surgindo pressão para dar suporte a mais bancos. Ainda assim, fiquei um pouco surpreso que até o suporte a MD5 e SHA1 tenha sido removido

  • Quando algo entra em uma biblioteca “batteries included”, é fácil a biblioteca ficar estagnada. Python carrega algumas baterias mortas desde os anos 90, mas lá isso é necessário
    É bom que suporte a caminhos ou logging esteja no padrão, mas algumas coisas evoluem melhor como terceiros

• Parabéns a todos os envolvidos. Nim realmente parece uma linguagem interessante
  Estou tentando encontrar um motivo para usá-la no trabalho. Meu trabalho fica na periferia do mobile, então o fato de poder compilar para JS e ObjC é atraente, mas por enquanto não passei de mexer um pouco aqui e ali. Comparado ao Rust, é muito mais simples começar

  • Um pouco relacionado: com Denim, é possível chamar código Nim a partir de Node.js/Bun: https://github.com/openpeeps/denim
    Funciona criando um addon para Node. É bom para reutilizar código Nim em apps web ou para código crítico em desempenho

• Dei uma olhada em Nim alguns meses atrás e, em termos de recursos, havia muita coisa que eu gostaria que existisse em Python. Coisas como interoperabilidade fácil com C/C++, tipos estáticos, compilação e a possibilidade de fazer compilação cruzada para Android/iOS e executar
  Mas, apesar de a linguagem não ser nova, o ecossistema é pequeno. Não há muitas bibliotecas de alta qualidade como numpy, scipy, pandas e opencv do Python. É uma pena que nenhum grande player a adote, e acho que teria sido bom se a Unreal Engine tivesse tentado adotar Nim em vez de criar sua própria nova linguagem de scripting, Verse
  Outra coisa decepcionante é a falta de uma interoperabilidade imediata com bibliotecas C/C++ sem precisar criar adaptadores manualmente. Seria bom se bastasse importar os headers
  Também seria bom haver uma interoperabilidade igualmente fácil com Rust. Isso poderia aumentar a adoção, porque em Rust é mais fácil encontrar crates multiplataforma de alta qualidade que funcionam sem grandes problemas até em dispositivos móveis
  Tenho receio de que, em alguns anos, Python alcance Nim com um Python mais rápido, remoção do GIL, nuitka, briefcase para mobile etc., ou que Mojo ocupe o lugar de Nim

  • Em defesa de Nim, praticamente só Python tem um ecossistema de machine learning enorme com coisas como numpy, scipy, pandas, opencv, pytorch, tensorflow e keras. É realmente difícil fazer trabalho no estilo ML/AI em uma linguagem que não seja Python
    Ainda assim, Nim tem a biblioteca nimpy, que permite uma interoperabilidade quase perfeita com Python. Ou seja, dá para simplesmente importar PyTorch, scipy e opencv e usá-los em Nim

• Tenho curiosidade se alguém tem experiência prática usando Nim e Zig. Queria ouvir em que eles são parecidos e diferentes. Também gostaria de ver benchmarks de servidores web idiomáticos nas duas linguagens, com base no Nim v2

  • Usei ambos em um projeto de SO como hobby. Usei Nim[1] e Zig[2], e prefiro muito mais Nim. O código é conciso e elegante, e me deixa focar na lógica principal em vez de brigar com a linguagem
    Zig também é bom, e gosto do suporte a valores opcionais e da abordagem de tratamento de erros. Mas a sintaxe barulhenta para expressar uma união de erro de um ponteiro opcional para um multiponteiro de uint8, como !?[]u8, me incomodou
    O fato de ter de preparar e passar alocadores na maior parte do código que precisa de alocação dinâmica também atrapalha a lógica principal. Até pequenas tarefas como concatenação ou formatação de strings viram trabalho
    Zig também não tem despacho dinâmico, o que dificulta escrever código polimórfico, obrigando a contornar com alguma forma de duck typing. No fim, concluí que Zig não era para mim
    [1] https://github.com/khaledh/axiom
    [2] https://github.com/khaledh/axiom-zig
  • Mantenho bindings gerados automaticamente para minha biblioteca em C para Zig, Nim, Odin e Rust. Os bindings em Rust certamente precisam de ajustes para ficarem mais idiomáticos
    Olhando os exemplos, é basicamente o mesmo código escrito em várias linguagens, então dá para ter uma visão geral, mas em termos de recursos das linguagens eles só arranham a superfície. Por exemplo, os exemplos em Zig não usam recursos de comptime
    Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples
    Nim: https://github.com/floooh/sokol-nim/tree/master/examples
    Odin: https://github.com/floooh/sokol-odin/tree/main/examples
    Rust: https://github.com/floooh/sokol-rust/tree/main/examples
  • Já escrevi programas em ambos, mas faz um tempo que não uso Nim. Acho que, em termos de prazer ao escrever código, Nim foi melhor
    Zig é mais tedioso, mas isso é por bons motivos. Pessoalmente, eu não escreveria um SO em Nim, mas, quando amadurecer, Zig parece que será excelente para esse uso. Comecei a usá-lo em software embarcado
    Eu usaria Nim para ferramentas de CLI, aplicações de servidor e talvez também aplicações GUI e jogos
    A equipe do Zig parece dedicar muito mais esforço a toda a infraestrutura do compilador, e pela minha experiência isso é realmente impressionante. Há excelentes inovações
  • Usei tanto Nim quanto Zig em projetos novos. Há muitas diferenças específicas, mas, simplificando as características, Nim está mais para uma tentativa de criar um canivete suíço ao estilo Python, só que como linguagem compilada
    Zig é uma linguagem muito mais focada, mirando um nicho específico como sucessora e substituta de C, e acerta muito bem esse objetivo
    Acho que a preferência por uma linguagem depende das necessidades e vontades pessoais que a linguagem usada atualmente não atende. Eu acabei ficando com Zig por achar interessante a abordagem de mirar uma sucessora de C, mas entendo por que outras pessoas escolheriam Nim
  • Zig não parece ter uma implementação nos TechEmpower Benchmarks, mas Nim tem: https://www.techempower.com/benchmarks/#section=data-r21&l=y...