Hack & Upcycling

p. 04  Réutilisation d’un lecteur audio de figurines

Repères & techniques

p. 26  Mise en œuvre de l’OPC UA

SBC & Raspberry Pi

p. 40  Personnalisez automatiquement vos installations de Raspberry Pi OS

Domotique & Capteurs

p. 58  AlertBox : un boîtier d’alerte multifonctions (suite)

FPGA & Gateware

p. 84  Accélérez vos simulations VHDL avec Verilator

Radio & Frequences

p. 102  Communication LoRa au moyen de RIOT-OS pour la mesure centimétrique par GPS différentiel avec RTKLIB

Nouveaux langages, donc nouveaux outils ?

Avez-vous remarqué que nombre de nouveaux outils en ligne de commandes, très populaires, sont tous écrits dans des langages tout aussi nouveaux ? bat qui remplace cat est écrit en Rust, le délicieux fuzzy finder fzf faisant de l’ombre à bash-completion est en Go, idem pour Zellij (Rust) concurrençant Screen/tmux, ou encore lsd, alias LSDeluxe faisant passer ls pour une antiquité, est développé en Rust... On en viendrait presque à penser que Rust et Go sont la cause directe de la performance de ces outils. Non ?

Pas vraiment, mais en partie tout de même. Je m’explique.

Lorsqu’on souhaite apprendre un nouveau langage, on ne peut le faire de façon théorique et trop académique. Il faut « faire quelque chose avec » pour se heurter à des problématiques bien réelles. Quoi de plus naturel donc que de répliquer l’existant. Après tout, on a un modèle et le cahier des charges est livré clé en main. Souvent, cela se résume à un simple « tiens, je vais refaire XXX pour voir ce que YYY vaut ». Et forcément, quitte à refaire, autant ajouter son grain de sel et améliorer les choses, c’est pourquoi les projets qui débutent ainsi finissent généralement bourrés de fonctionnalités absentes de l’original.

Il faut ensuite remarquer deux choses. D’une part, vous n’aurez entre les mains que les projets qui aboutissent. Cela s’appelle le « biais des survivants » et vous n’entendrez jamais parler des développements qui ne mènent à rien. Ceci donne une fausse impression de réussite systématique. C’est très trompeur, car vous ne saurez jamais combien de devs auront finalement jeté l’éponge.

Une autre chose, qui cette fois est réellement positive, est la suivante : l’outil créé a atteint un niveau de stabilité suffisant pour être rendu public et devenir populaire. Ce n’est pas une preuve de l’aspect miraculeux du langage utilisé, mais, au moins, que celui-ci n’aura pas excédé le développeur. Voire très certainement qu’il aura conquis son cœur, du moins au point de continuer à faire évoluer agréablement sa création. Ce n’est pas rien.

Donc non, ce ne sont ni Rust ni Go qui font la popularité de ces outils, mais ces outils sont la preuve de la popularité grandissante et de l’adoption de Rust et de Go, tout de même.

Denis Bodor