Parmi les trois, celui qui m’est familier, c’est TS, celui que je sais utiliser, c’est Python, et celui que je ne connais pas bien mais que j’ai envie de faire, c’est Rust...
Quoi qu’il en soit, le plus rassurant dans tout ça, c’est que Java ne fasse pas partie de ces trois-là
Hum... je trouve dommage que ce ne soit plus le cas, parce que lorsque toutes les fonctions de navigation passent par une bibliothèque de base, si le système bloque une URL donnée, on bénéficie d’une cohérence appréciable, impossible à contourner, dans les fonctions de navigation intégrées de toutes les applications.
Ce type de médicament n’apparaît qu’occasionnellement dans les actualités, mais, en général, il ne dépasse pas nettement le niveau d’un collyre mydriatique… Sans doute, la sécurité n’était pas souvent garantie lors d’un usage prolongé.
Je pense qu’il est probablement plus sûr de l’utiliser seulement une ou deux fois par semaine. Un usage plus fréquent et sur une plus longue durée peut entraîner plusieurs problèmes.
Personnellement, je trouve que claude-code est meilleur pour le refactoring.
Quand j’ai demandé à cursor + GPT5 d’effectuer ce type de refactoring, comme supprimer des méthodes inutiles, claude-code les repérait bien et les supprimait, alors que j’avais l’impression que GPT5 ne parvenait pas à appréhender l’ensemble du projet.
Il y a encore pas mal de petits bugs, surtout liés aux tags, mais ça semble rester un outil qu’on peut continuer à utiliser en attendant les mises à jour.
Niko Matsakis occupe une position qui fait de lui, au-delà de rayon, une figure presque paternelle de Rust. Bien sûr, Graydon Hoare en est le fondateur, mais on peut dire que c’est Niko qui a le plus contribué aux parties les plus importantes du langage.
J’utilise moi aussi Claude Code avec une grande satisfaction.
Je crois que cela fait maintenant environ 6 semaines que je l’utilise.
Je partage l’avis de l’auteur sur la plupart des points.
Dans l’évolution de l’expérience, de codeur => développeur qui conçoit l’architecture fonctionnelle => architectures plus vastes (système, réseau, sécurité) => planification,
on a l’impression qu’il y aura moins d’occasions pour les codeurs d’apprendre sur le terrain.
Si la programmation centrée sur les idées devient la norme,
j’ai le sentiment qu’au minimum, savoir gérer seul une stack full-stack basée sur l’IA deviendra la base pour un codeur, etc.
Vous modifiez directement le titre avant de le publier ?
Je me demande comment vous sélectionnez les articles, les publiez, et traduisez aussi les commentaires de manière aussi fluide. :D
On peut aussi le voir comme ça. D’après mon expérience, par rapport à PyO3, python.h — ce qui explique aussi pourquoi zig peut être une bonne alternative — permettait beaucoup plus facilement de descendre au niveau de l’OS ou de la vectorisation puis d’en remonter ; en revanche, du point de vue de l’absence de souci de gestion mémoire, au-delà d’une certaine échelle Rust peut offrir une meilleure productivité à long terme.
Si le C est facile, c’est parce qu’il constitue la base des grands langages modernes — Python/TS/Go/PHP/Java — ou qu’il en partage une syntaxe proche ; autrement dit, ce n’est pas seulement que sa syntaxe est simple, mais aussi que c’est une langue que l’on finira par rencontrer, ou que l’on a déjà rencontrée un jour. À l’inverse, Rust se situe à l’opposé, si bien que malgré sa grande valeur, son adoption dans une équipe demande des efforts considérables. Je pense que c’est parce que c’est moins un langage évolutif qu’un langage innovant.
Il semble qu'il y ait une erreur dans la traduction du titre.
Le contenu semble porter sur la correction de l'hypermétropie provoquée par la presbytie.
Le terme coréen désignant la myopie signifie « un état où l’on voit bien uniquement de près », c’est-à-dire la near vision acuity.
« Fix near vision » signifie que l’on a corrigé un problème de vision de près (qui était mauvais),
ce qui me semble correct si l’on dit qu’on a corrigé le problème d’hypermétropie lié à la presbytie, ou plutôt corrigé la vision de près.
Je ne l'utilise toujours pas...
Parmi les trois, celui qui m’est familier, c’est TS, celui que je sais utiliser, c’est Python, et celui que je ne connais pas bien mais que j’ai envie de faire, c’est Rust...
Quoi qu’il en soit, le plus rassurant dans tout ça, c’est que Java ne fasse pas partie de ces trois-là
La présence ou non d’une connexion me semble être une différence de concept assez importante.
Hum... je trouve dommage que ce ne soit plus le cas, parce que lorsque toutes les fonctions de navigation passent par une bibliothèque de base, si le système bloque une URL donnée, on bénéficie d’une cohérence appréciable, impossible à contourner, dans les fonctions de navigation intégrées de toutes les applications.
Ce type de médicament n’apparaît qu’occasionnellement dans les actualités, mais, en général, il ne dépasse pas nettement le niveau d’un collyre mydriatique… Sans doute, la sécurité n’était pas souvent garantie lors d’un usage prolongé.
Je pense qu’il est probablement plus sûr de l’utiliser seulement une ou deux fois par semaine. Un usage plus fréquent et sur une plus longue durée peut entraîner plusieurs problèmes.
Omarchy, la distribution Linux créée par DHH
Ça ressemble pas mal à https://write.hada.io/ que j’avais fait il y a assez longtemps. À part la prise en charge du Markdown et les tâches, haha
Le problème des « imports circulaires » en Python n’a-t-il pas déjà des solutions assez claires ? J’ai du mal à y voir un problème vraiment majeur.
Personnellement, je trouve que
claude-codeest meilleur pour le refactoring.Quand j’ai demandé à cursor + GPT5 d’effectuer ce type de refactoring, comme supprimer des méthodes inutiles,
claude-codeles repérait bien et les supprimait, alors que j’avais l’impression que GPT5 ne parvenait pas à appréhender l’ensemble du projet.Il y a encore pas mal de petits bugs, surtout liés aux tags, mais ça semble rester un outil qu’on peut continuer à utiliser en attendant les mises à jour.
Niko Matsakis occupe une position qui fait de lui, au-delà de
rayon, une figure presque paternelle de Rust. Bien sûr, Graydon Hoare en est le fondateur, mais on peut dire que c’est Niko qui a le plus contribué aux parties les plus importantes du langage.Si on utilise des passkeys puis qu’on perd son appareil, ça doit vraiment être galère...
En tant que développeur Rust, vous avez naturellement plus d’affection pour ce langage, donc l’information est peut-être un peu biaisée !
Merci de partager ces informations.
J’utilise moi aussi Claude Code avec une grande satisfaction.
Je crois que cela fait maintenant environ 6 semaines que je l’utilise.
Je partage l’avis de l’auteur sur la plupart des points.
https://jeho.page/essay/2025/07/15/claude-code.html
Dans l’évolution de l’expérience, de codeur => développeur qui conçoit l’architecture fonctionnelle => architectures plus vastes (système, réseau, sécurité) => planification,
on a l’impression qu’il y aura moins d’occasions pour les codeurs d’apprendre sur le terrain.
Si la programmation centrée sur les idées devient la norme,
j’ai le sentiment qu’au minimum, savoir gérer seul une stack full-stack basée sur l’IA deviendra la base pour un codeur, etc.
Vous modifiez directement le titre avant de le publier ?
Je me demande comment vous sélectionnez les articles, les publiez, et traduisez aussi les commentaires de manière aussi fluide. :D
L'astigmatisme ne peut-il pas être traité ? 😢
On peut aussi le voir comme ça. D’après mon expérience, par rapport à PyO3,
python.h— ce qui explique aussi pourquoi zig peut être une bonne alternative — permettait beaucoup plus facilement de descendre au niveau de l’OS ou de la vectorisation puis d’en remonter ; en revanche, du point de vue de l’absence de souci de gestion mémoire, au-delà d’une certaine échelle Rust peut offrir une meilleure productivité à long terme.Si le C est facile, c’est parce qu’il constitue la base des grands langages modernes — Python/TS/Go/PHP/Java — ou qu’il en partage une syntaxe proche ; autrement dit, ce n’est pas seulement que sa syntaxe est simple, mais aussi que c’est une langue que l’on finira par rencontrer, ou que l’on a déjà rencontrée un jour. À l’inverse, Rust se situe à l’opposé, si bien que malgré sa grande valeur, son adoption dans une équipe demande des efforts considérables. Je pense que c’est parce que c’est moins un langage évolutif qu’un langage innovant.
Ah, j’ai raccourci le titre lié à l’IA et j’ai fait comme ça. Je l’ai déjà mis à jour.
Il semble qu'il y ait une erreur dans la traduction du titre.
Le contenu semble porter sur la correction de l'hypermétropie provoquée par la presbytie.
Le terme coréen désignant la myopie signifie « un état où l’on voit bien uniquement de près », c’est-à-dire la near vision acuity.
« Fix near vision » signifie que l’on a corrigé un problème de vision de près (qui était mauvais),
ce qui me semble correct si l’on dit qu’on a corrigé le problème d’hypermétropie lié à la presbytie, ou plutôt corrigé la vision de près.