Un article très intéressant sur ces foutus tests qui passent "de temps en temps"

Une belle exposition de toutes les non-égalités de nombres existant dans les langages informatiques.

C'est pas tous les jours que j'écris une solution qui mélange aussi bien le kotlin idiomatique et l'algorithme bien simplifié

C'est quelque chose que je dis souvent ... Pour lequel je ne suis heureusement pas très écouté.

Un très bon article sur l'écriture d'un interpréteur en Rust. C'est complet, raisonnablement didactique et vraiment clair.

Je ne savais pas (avant d'utiliser Apache Beam) que Google avait développé son alternative à Lombok. C'est à peu près aussi utile que l'original ... Cela dit la génération de descripteurs de services/factories me semble une bonne idée.

Heureusement que Go est un langage "spécialement conçu pour la concurrence"

Il y a du jeu de mot dans les noms des crates Rust, et c'est cool

En voyant azul.rs et orbtk, j'ai une immédiate envie de relancer un vieux projet de logiciel avec GUI, juste pour voir à quel moment ça va craquer

Et un bon gros ... très gros ... paquet sur le polymorphisme en Rust. j'ai appris des trucs sur la signature des méthodes là-dedans ...

Donc on peut utiliser des paramètres optionnels en Rust ... mais ça n'est pas forcément super intuitif.

C'est absolument incroyable de voir que ce produit existe ... et que l'application qui pilote tout ça est open-source

Un article intéressant sur les premiers pièges que rencontrent les débutants en Rust.

Heureusement que JavaEE a depuis longtemps perdu de son intérêt (la faute aux microservices), sinon ce serait une nouvelle franchement dramatique.

Maintenant que j'ai mon bout de code qui lit des flux RSS, et charge les images à grands coups de Base64Encode, il est temps de me pencher sur la question du multithread ...

L'article est super intéressant, et j'ai bien envie de creuser cette structure de données (pour remplacer Kafka, par exemple)

On sent le bon fanboy Go. Parce que ce qu'il dit là peut être dit d'un paquet de langages (pour rappel, le côté "simplified OO" était déjà le moteur de l'adoption de Java)

Je suis complètement d'accord. Un testeur ne doit pas tester l'application, mais écrire les outils de test

C'est pas trop mal (même si certains aspects me paraissent discutables), et ça présente un bon "chemin" d'apprentissage

Comment traduire escalating risk ? Un risque escaladé ? Un risque supérieur ?