Nim 2.0 — un langage de programmation axé sur le paradigme impératif et le système de macros

 (nim-lang.org)
2 points par GN⁺ 2023-08-02 | 1 commentaires | Partager sur WhatsApp
  • La gestion mémoire ORC devient la valeur par défaut
  • Le backend JavaScript utilise désormais BigInt par défaut pour int64 et uint64 ; les codes interagissant avec le backend JS et utilisant ces types peuvent nécessiter une mise à jour
  • --experimental:strictEffects est toujours activé, et les paramètres de callback nécessitent l’annotation effectsOf
  • Le langage de balisage par défaut des commentaires de documentation passe de l’ancien mode RstMarkdown à Markdown, avec l’ajout du pragma {.doctype: Markdown | RST | RstMarkdown.} et des commandes md2html et rst2html
  • Certaines fonctionnalités liées à os de la bibliothèque standard sont séparées dans de nouvelles interfaces utilisant l’abstraction Path, fournies via les modules std/oserrors, std/envvars, std/paths, std/dirs, std/files, std/symlinks, std/appdirs et std/cmdline
  • Plusieurs modules de la bibliothèque standard ont été déplacés vers des paquets Nimble ; l’utilisation de std/punycode, std/asyncftpclient, std/smtp, std/db_*, std/md5, std/sha1 ou std/sums nécessite l’installation via nimble ou atlas
  • L’utilisation d’un break sans nom dans un block sans nom est dépréciée et deviendra une erreur dans une prochaine version
  • La définition de "strictFuncs" change afin d’interdire les affectations via déréférencement de ref ou ptr
  • Le dépaquetage de tuples dans les variables est traité comme du sucre syntaxique développé en plusieurs affectations, et le dépaquetage de tuples imbriqués devient possible
  • L’inférence top-down a été implémentée dans plusieurs cas courants, ce qui permet de compiler le code d’initialisation seq[(float, byte, cstring)] de l’exemple
  • Des valeurs par défaut peuvent être définies pour les champs d’objets ; elles sont utilisées pour les champs qui ne sont pas initialisés explicitement
  • Le commutateur expérimental strictDefs est ajouté afin de vérifier qu’une valeur a été explicitement affectée à une variable avant son utilisation, et qu’une variable let est affectée exactement une fois
  • L’interopérabilité C++ ajoute le pragma virtual et un pragma constructor étendu, permettant de définir des constructeurs et des proc virtuelles correspondant aux constructeurs et méthodes virtuelles C++
  • Nimble 0.14 est inclus, avec prise en charge des lock-files, et l’emplacement de stockage des bibliothèques passe de $nimbleDir/pkgs à $nimbleDir/pkgs2

À lire aussi

1 commentaires

 
GN⁺ 2023-08-02
Avis sur Hacker News

  • J’utilise Nim en production avec satisfaction. Je crée surtout des outils d’analyse de données et de génération de rapports, compilés en exécutables CLI appelés par des scripts serveur.
    Nim produit des exécutables rapides et petits, et ses structures de données JSON hétérogènes ainsi que ses bibliothèques de dataframes sont bonnes. Il privilégie fortement la pile : même les structures de données dynamiques comme les séquences et les tables ont un pointeur sur la pile qui pointe vers les données sur le tas, et leur durée de vie est gérée par la frame de pile.
    Il y a très peu de références dynamiques dans le programme, et je n’ai pas à me soucier du GC. Le système de types est simple et raisonnable, et guide facilement vers du code correct. Les valeurs par défaut sont aussi proches de la transparence référentielle : sauf à s’en écarter explicitement, tout est immuable et passé par valeur.
    Les génériques sont puissants et se comportent comme prévu, et la syntaxe d’appel de fonction universelle est incroyablement utile. Il suffit de créer des procédures et fonctions qui prennent un type donné en premier argument pour écrire l’équivalent de méthodes ou d’interfaces, ce qui rend ces abstractions inutiles et garde une structure de code simple et plate.
    C’est aussi agréable que lorsque j’avais découvert D, voire mieux. Si vous imaginez un Python compilé en natif, annoté avec des types, dont presque 100 % est de la logique métier et sans superflu, vous serez proche de l’expérience Nim.

    • Cette description ne correspond-elle pas à quelque chose comme un vector ou une map C++ placé sur la pile ? Il alloue en interne quand c’est nécessaire, puis l’ensemble du conteneur est détruit quand il sort de la portée.
    • Ça me donne envie de jeter un œil à Nim. Je me demande à quoi ressemble le système de build. CMake est vraiment une plaie.
    • Ça ressemble vraiment à Python. J’aimerais qu’il devienne plus populaire ; on dirait un Rust beaucoup plus facile à utiliser.
    • Ça a l’air bien. Je me demande où en est la gestion des paquets, et à quel point l’écosystème actuel est solide.

  • J’ai hâte d’essayer cette version. Avec 25 ans de programmation professionnelle derrière moi, je considère que Nim réunit très bien le meilleur de plusieurs mondes.
    Il est aussi facile à utiliser que Python, fortement typé mais avec une excellente inférence de types, et ses valeurs par défaut sont rapides et sûres. Il convient aussi bien à l’embarqué qu’au calcul haute performance.
    Grâce à l’UFCS, aux génériques et aux concepts, on obtient les avantages de la POO tout en ayant moins besoin d’écrire du code d’échafaudage qui empile sans fin des relations de données fragiles pour organiser les choses. Contrairement à Python, les ambiguïtés deviennent des erreurs de compilation.
    J’ai l’impression qu’un même programme est beaucoup plus petit, lisible et facile à comprendre que dans la plupart des autres langages. Il n’y a pas non plus beaucoup de magie en arrière-plan, parce que les valeurs par défaut ont du sens.
    La métaprogrammation à la compilation est d’un autre niveau. Elle est au cœur de la conception du langage, sans dialecte séparé ni bricolages de substitution, et elle est intuitive à utiliser. Par exemple, il est facile de générer du code de parsing personnalisé à partir de fichiers, ce qui supprime du boilerplate répétitif, et la compilation reste rapide.
    Grâce à son excellent système de types, il est plus facile d’écrire correctement qu’en Python, tout en offrant des performances comparables à C/C++, et il est très simple à déployer sous forme de petits exécutables autonomes.
    Il dispose d’ABI natives pour C, C++, ObjC et JS, d’un excellent FFI, ainsi que d’une bonne interopérabilité avec Python. On peut utiliser directement les écosystèmes existants sans les réécrire.
    Imaginez écrire du pseudo-code de style Python pour un ESP32, très efficace avec très peu d’effort, tout en pouvant descendre au contrôle bare metal quand vous le souhaitez. Ou écrire une application web avec le backend et le frontend dans le même langage efficace, créer un jeu de bullet hell rapide, tout en n’ayant pas à vous soucier du GC parce que, sauf indication contraire, l’allocation se fait sur la pile.
    D’un point de vue business aussi, le fait de prototyper aussi vite qu’en Python mais d’obtenir déjà quelque chose d’assez rapide et léger pour la production a beaucoup de valeur. Cela peut devenir l’arme secrète d’une entreprise.

    • J’utilise Nim comme cible de scripting pour des jeux et pour d’autres usages que je ne peux pas détailler. C’est parce qu’il peut être traduit en C et C++.
      Ce que j’aime vraiment, c’est pouvoir gérer moi-même l’environnement C sous-jacent, tout en utilisant par-dessus un langage moderne de haut niveau qui prend très bien en charge des choses comme JSON en tant que citoyens de première classe. Même en aimant Python, je trouve que Nim est meilleur, un meilleur Python.
    • Je me demande concrètement comment fonctionne l’écriture d’une application web avec le backend et le frontend dans le même langage efficace.
      En particulier, j’aimerais savoir à quel point l’interopérabilité JS est confortable pendant le développement, et si cela va au-delà de la compilation de Nim en JS comme bibliothèque autonome. Peut-on appeler directement les API du navigateur depuis Nim, ou via des wrappers assez simples ?
    • Pour les cas où les microsecondes comptent, comme du code traitant un ADC à 22 kSPS sur ESP32, il a honnêtement fallu environ 2 heures de tuning. À l’époque, je venais tout juste d’apprendre Nim, et il s’agissait surtout d’éviter des allocations supplémentaires.
      Malgré tout, en environ 4 ans, il n’y a pas eu de grosse régression de performance ni de changements nécessaires.

  • Félicitations à toutes les personnes impliquées et à toute la communauté Nim. J’utilise Nim comme langage principal depuis 10 ans, et j’aime beaucoup les nouveautés de Nim 2.0.
    Certaines changent vraiment la donne pour mes projets. Par exemple, les valeurs par défaut des objets pourraient en théorie permettre à Norm[1] de fonctionner non seulement avec des instances d’objets, mais aussi avec des types d’objets. Sans les nouvelles énumérations surchargeables, Karkas[2] aurait été tout simplement impossible. C’est encore en cours de travail.
    [1] https://norm.nim.town
    [2] https://karkas.nim.town

    • Parmi les changements récents, les valeurs par défaut sont ce que je préfère. Elles sont utiles de manière générale et réduisent encore le boilerplate d’initialisation, mais elles permettent aussi de garantir un état valide à la compilation pour des choses comme les énumérations. Cela s’applique probablement aussi aux variantes d’objets.

  • Nim est un très bon langage pour écrire du logiciel. On peut livrer rapidement et développer avec plaisir tout en produisant des logiciels très performants.
    Cela dit, d’après mon expérience, il reste encore quelques aspérités. Il faut aligner le compilateur C/C++ et ses options, les messages d’erreur sont très pauvres, et certaines bibliothèques ne fonctionnent que sur des configurations et systèmes précis. Mais compte tenu de la petite taille de la communauté, il est difficile de trop lui en vouloir. L’intégration VS Code fonctionnait bien et plantait très rarement.

    • Les mauvais messages d’erreur et le manque d’outillage sont selon moi les plus gros problèmes de Nim. À part ça, c’est globalement un excellent langage.
    • Au moins, le rapport d’erreurs s’est amélioré récemment : https://nim-lang.org/blog/2023/03/31/version-20-rc2.html

  • Si Manning Publications tombe là-dessus, j’aimerais qu’un livre à jour sur la dernière version de Nim voie le jour, et qu’ils envisagent une autre mise en page avec une police plus lisible
    J’ai acheté l’excellent livre de Dominik Picheta, mais l’édition papier était trop difficile à lire à cause de la finesse de la police, même avec des lunettes adaptées, et j’ai dû utiliser le PDF. Les composants de la police, comme les traits et les fûts, sont trop fins
    Je me suis demandé si c’était mon problème parce que je vieillissais, alors j’ai comparé avec l’édition originale de K&R 2e édition, et ce livre reste parfaitement lisible

  • Reddit a écrit un billet sur la façon dont ils utilisent Nim : https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enj...
    De plus en plus de grandes entreprises et de startups adoptent Nim. Nim 2.0 me rend très enthousiaste, et un grand merci à toutes les personnes qui y ont contribué

    • Le fait que de plus en plus de grandes entreprises et de startups l’adoptent est intéressant. Je me demande s’il existe des statistiques ou des données à ce sujet, ou si c’est anecdotique
      Même si c’est anecdotique, peut-on avoir quelques noms d’entreprises ?

  • Nim est mon langage préféré depuis un moment, et je suis très enthousiaste de voir enfin la 2.0 sortir. Beaucoup des fonctionnalités de cette version étaient attendues depuis longtemps
    Le seul inconvénient, comme mentionné tout en bas, est que certains modules inclus ont été déplacés vers des dépôts tiers. Ce n’est pas un gros problème, mais j’aimais bien que la prise en charge de SQLite soit intégrée à la bibliothèque. Dès qu’on commence à prendre en charge quelques bases de données, on subit forcément une pression pour en prendre en charge davantage. En revanche, je suis un peu surpris que même la prise en charge de MD5 et SHA1 ait été retirée

    • Quand quelque chose entre dans une bibliothèque « batteries incluses », la bibliothèque a tendance à se figer. Python traîne depuis les années 90 certaines batteries mortes, mais là-bas elles sont nécessaires
      C’est bien que la gestion des chemins ou du logging soit dans le standard, mais certaines choses doivent rester tierces pour pouvoir mieux évoluer

  • Félicitations à toutes les personnes concernées. Nim me semble vraiment être un langage passionnant
    J’essaie de trouver une raison de l’utiliser au travail. Mon activité touche au mobile, donc le fait de pouvoir compiler vers JS et ObjC est séduisant, mais pour l’instant je n’ai pas dépassé le stade des expérimentations. Comparé à Rust, il est beaucoup plus simple de s’y mettre

    • Dans un registre assez proche, Denim permet d’appeler du code Nim depuis Node.js/Bun : https://github.com/openpeeps/denim
      Cela fonctionne en créant des add-ons Node. C’est pratique pour réutiliser du code Nim dans des apps web ou pour du code critique en performance

  • J’ai regardé Nim il y a quelques mois, et côté fonctionnalités il y avait beaucoup de choses que j’aimerais voir dans Python. Par exemple l’interopérabilité facile avec C/C++, le typage statique, la compilation, ou encore la compilation croisée et l’exécution sur Android/iOS
    Mais même si le langage n’est pas nouveau, l’écosystème reste petit. Il n’y a pas beaucoup de bibliothèques de haute qualité comme numpy, scipy, pandas ou opencv en Python. C’est dommage que de grands acteurs ne l’adoptent pas, et j’aurais aimé qu’Unreal Engine essaie d’adopter Nim plutôt que de créer son propre nouveau langage de scripting, Verse
    Un autre point regrettable est l’absence d’interopérabilité immédiate avec les bibliothèques C/C++ sans devoir créer soi-même des adaptateurs. Ce serait bien de pouvoir simplement importer les headers et que ce soit terminé
    J’aimerais aussi une interopérabilité aussi simple avec Rust. Cela pourrait favoriser l’adoption, et il est plus facile de trouver en Rust des crates multiplateformes de qualité qui fonctionnent sans trop de problèmes, même sur les appareils mobiles
    Je crains que, d’ici quelques années, Python ne rattrape son retard avec un Python plus rapide, la suppression du GIL, nuitka et briefcase pour mobile, ou que Mojo ne prenne la place de Nim

    • Pour défendre Nim, en pratique Python est quasiment le seul à disposer d’un énorme écosystème de machine learning avec numpy, scipy, pandas, opencv, pytorch, tensorflow, keras, etc. Il est vraiment difficile de faire du travail de type ML/IA dans un langage autre que Python
      Cela dit, Nim dispose de la bibliothèque nimpy, qui permet une interopérabilité presque transparente avec Python. Autrement dit, on peut simplement importer PyTorch, scipy ou opencv et les utiliser depuis Nim

  • Je me demande si certains ont une expérience concrète avec Nim et Zig. J’aimerais savoir en quoi ils se ressemblent et en quoi ils diffèrent. J’aimerais aussi voir des benchmarks de serveurs web idiomatiques pour les deux langages, sur la base de Nim v2.

    • J’ai utilisé les deux dans un projet d’OS amateur. J’ai utilisé Nim[1] et Zig[2], et je préfère nettement Nim. Le code est concis et élégant, et il permet de se concentrer sur la logique essentielle plutôt que de se battre avec le langage
      Zig est bien aussi, et j’aime sa prise en charge des valeurs optionnelles ainsi que son approche de la gestion des erreurs. Mais la syntaxe bruyante pour exprimer une union d’erreur d’un pointeur optionnel vers un multi-pointeur de uint8, comme !?[]u8, m’a rebuté
      Dans la plupart du code qui nécessite de l’allocation dynamique, devoir préparer et passer un allocateur gêne aussi la logique principale. Même de petites opérations comme la concaténation ou le formatage de chaînes deviennent du travail
      Zig n’a pas non plus de dispatch dynamique, ce qui rend difficile l’écriture de code polymorphe, et il faut contourner cela avec une forme de duck typing. Au final, j’ai conclu que Zig ne me convenait pas
      [1] https://github.com/khaledh/axiom
      [2] https://github.com/khaledh/axiom-zig
    • Je maintiens des bindings générés automatiquement pour ma bibliothèque C, pour Zig, Nim, Odin et Rust. Les bindings Rust ont clairement besoin d’être retravaillés pour devenir plus idiomatiques
      En regardant les exemples, on voit surtout le même code écrit dans plusieurs langages, ce qui donne une vue d’ensemble, mais côté fonctionnalités de langage cela ne fait qu’effleurer la surface. Par exemple, les exemples Zig n’utilisent pas les fonctionnalités 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’ai écrit des programmes avec les deux, mais cela fait un moment que je n’ai pas utilisé Nim. Je crois que Nim était plus agréable pour écrire du code
      Zig est plus ennuyeux, mais pour de bonnes raisons. Personnellement, je n’écrirais pas un OS en Nim, alors que Zig, une fois arrivé à maturité, semble excellent pour cet usage. J’ai commencé à l’utiliser pour du logiciel embarqué
      Nim, je l’utiliserais pour des outils CLI, des applications serveur, et peut-être aussi des applications GUI et des jeux
      L’équipe Zig semble investir beaucoup plus d’efforts dans toute l’infrastructure du compilateur, et d’après mon expérience c’est vraiment impressionnant. Il y a d’excellentes innovations
    • J’ai utilisé Nim et Zig sur de nouveaux projets. Il y a beaucoup de différences concrètes, mais pour simplifier leurs caractéristiques, Nim se rapproche davantage d’une tentative de faire un couteau suisse à la Python, mais en langage compilé
      Zig est un langage beaucoup plus focalisé, qui vise un créneau précis : être un successeur et un remplaçant de C, et il atteint très bien cet objectif
      Je pense que les préférences de langage dépendent des besoins et envies personnels que le langage qu’on utilise actuellement ne satisfait pas. Je me suis installé du côté de Zig parce que son approche de successeur de C m’intéresse, mais je comprends aussi pourquoi d’autres choisissent Nim
    • Zig ne semble pas avoir d’implémentation dans les TechEmpower Benchmarks, mais Nim en a une : https://www.techempower.com/benchmarks/#section=data-r21&l=y...