Alors aujourd'hui, je t'en prie, écris, toi, un journal, pour expliquer comment on code en JS/Node, ce qu'il y a de positif, de bon, de cool, là-dedans.
Je suis surpris de voir pas mal d'applis qui sont simplement de la documentation (par ex. plusieurs applis des APHP ou de l'INRAE), et en plus la dite documentation est séparée en plusieurs applis. J'ai du mal à comprendre l'intérêt d'avoir fait cet effort par rapport à un simple site, et aussi curieux du nombre d'utilisateurs de ces applis.
Si je comprends bien comment Future (en Java) marche, il permet d'exécuter une fonction dans un autre thread (ou plus généralement d'une façon fournie par l'exécuteur), et ensuite d'obtenir son résultat avec la méthode Future.get(), qui est bloquante.
Avec le modèle Reactor, ce n'est pas possible (ni souhaité) d'avoir une fonction bloquante (vu que ça bloquerait tous les traitements du thread unique, et, dans le cas de Future.get provoquerait un deadlock), donc il n'est pas possible d'avoir une fonction Future.get, et donc d'extraire le résultat du calcul du Future.
On serait donc obligé d'utiliser le résultat de la Future sans l'extraire, par exemple avec CompletableFuture.thenApply, ce qui, si on utilise ça partout, serait particulièrement illisible, d'où l'intérêt d'avoir un sucre syntaxique comme async/await pour gérer ça plus simplement
Franchement c'est un peu lamentable de passer du temps à écrire ce message qui n'a aucun détail précis (qui permettraient au lecteur de comprendre ce qui ne te plait pas dans le langage) plutôt qu'à mettre à jour tes connaissances.
Je pourrais répondre point par point mais je ne vois pas pourquoi je prendrais du temps alors que tu ne l'as pas fait.
Juste pour prendre ton premier point un peu précis :
Le JavaScript est un langage dramatique [...] à débugger
Pour débugger un programme JavaScript, que ce soit Node.JS ou dans le navigateur, je met un point d'arrêt en cliquant dans mon éditeur ou dans les outils de développement, et quand je relance le programme, il s'y arrête.
Franchement je ne vois rien de complotiste ou d'incohérent (après je suis l'auteur, j'imagine que ça aide).
Je ne voulais pas dire qu'il est complotiste ou incohérent, mais qu'en regardant uniquement des indices rapidement visibles (la longueur et le thème, et maintenant le score négatif), des gens ont pu conclure sans lire que c'était ce type de journal
J'en conclue donc que peu importe le fond, que j'y ai passé quelques heures, il faut que je me tape des -1 de réflexe ?
Malheureusement ce n'est pas l'effort qu'on y a mis qui fait le succès de quelque chose, surtout pour un contenu sur internet où tout le monde à une surabondance de choses à lire ou à regarder.
Dans le cas de ton journal il y a pour moi deux soucis qui font que les lecteurs de DLFP ne vont pas y accorder l'attention qu'il mérite :
Comme déjà évoqué, la référence à l'IA : il y a eu ces derniers mois de nombreux contenus de mauvaise qualité générés par IA, ce qui fait que les lecteurs ont désormais une réaction épidermique
La longueur et le thème philosophique du journal : il y a là aussi un historique de journaux de ce type, mais avec un contenu incohérent ou complotiste, laissant presque (ou pas) penser à des problèmes psychiatriques chez leurs auteurs
Pré-scriptum : oui, j'ai fait écrire mon commentaire à un LLM (GPT-5.5)
L'utilisation du LLM dans ton journal se voit beaucoup trop. On retrouve tous les travers habituels : des tonnes de texte, des analogies à répétition, des détours dans tous les sens et une argumentation qui avance péniblement. Le résultat donne une impression de profondeur, mais quand on regarde de près il y a souvent assez peu de substance derrière.
Le plus gênant, c'est que cela fait perdre du temps au lecteur. Parce que générer trois pages de texte ne coûte quasiment rien à une IA, le texte n'est plus contraint par l'effort d'écriture. En revanche, chaque paragraphe supplémentaire doit être lu par des humains. J'ai eu plusieurs fois l'impression de devoir traverser de longues digressions pour extraire une idée qui aurait tenu en quelques lignes.
Au final, j'ai surtout l'impression que le LLM a servi à augmenter le volume du journal plutôt que sa qualité. Le texte aurait probablement gagné à être deux ou trois fois plus court et à consacrer l'espace économisé à renforcer les arguments plutôt qu'à les reformuler.
L'article est intéressant, mais je trouve que la gravité du "problème" évoqué n'est absolument pas en rapport avec la popularité de l'article.
Tout d'abord, la solution que préfère l'auteur (dernier paragraphe) sont les green threads. Ce n'est pas une meilleure solution mais un compromis différent, comme dit dans mon journal (besoin de gérer la synchronisation à la main, overhead sur chaque thread, profil de performance différent). Certes il n'y a plus le sujet du function coloring au niveau du langage, mais encore faut-il que les autres compromis conviennent.
Sur le fond, la raison principale pour laquelle le function coloring n'est pas un vrai problème, c'est que dans un programme bien architecturé, l'I/O est en haut de l'arbre des appels, et qu'au fur et à mesure qu'on rentre dedans on essaie d'avoir des fonctions pures, ou plus généralement qui peuvent facilement être testées.
D'ailleurs le function coloring n'est pas spécifique à async/await : une fonction qui prend en premier argument une connexion à la base de données, ou encore une référence à la requête en cours ne peut pas être appelée par une fonction qui n'a pas cette référence. Certes dans ce cas il y a des façons simples d'éviter le problème comme utiliser un singleton, du thread-local storage ou équivalent, mais ce n'est pas forcément une solution propre ou souhaitable.
Pour moi le seul cas où il y a un vrai problème est si l'on doit appeler une fonction async à partir d'une librairie qui ne le prévoit pas, par exemple un validateur XML qui permet de fournir un callback pour vérifier certains éléments, et on souhaite dans ce callback appeler un service web. Mais, en pratique, du moins dans l'écosystème node.js, c'est extrêmement marginal (personnellement je n'ai jamais vu le problème), et, vu que la grande majorité des librairies sont opensource il est facile de les modifier pour avoir le comportement qu'on souhaite.
Et, enfin, ce n'est pas vrai qu'il n'est pas possible d'appeler des fonctions async à partir d'une fonction sync. Ce n'est pas une bonne idée vu que ça bloque l'event loop, mais, par exemple en Node.js ça peut être fait en exécutant la fonction dans un worker thread et en attendant son résultat avec Atomics.wait.
D'ailleurs ça se voit au score légèrement positif de la dépêche comparé aux scores extrêmement négatifs des journaux rédigés par IA pour projet vibe codé par IA.
Pour moi le score est positif car la dépêche est plus subtile, mais ça illustre que le problème est en train de s'aggraver.
Je m'explique :
Pour moi, le score est positif car c'est moins flagrant que le contenu est du contenu sans intérêt : les signes de l'écriture par IA sont moins présents, les objections sont anticipées (rôle de l'IA dans la création du projet et du journal, l'utilisateur est nouveau, etc.), contenu davantage dans la ligne éditoriale du site (libre, potentiellement intéressant pour le public).
Par contre, le fond est autant inintéressant que les autres journaux qui eux ont été moinssés : projet non fonctionnel (c'est présenté comme quelque chose de réutilisable mais il y a juste une démo), code généré par IA, et même concept de base foireux (la récupération du mot de passe par mail est remplacée par un système troué).
Donc au final, même si la dépêche est peut-être passée grâce à une relecture manuelle et non grâce aux progrès de l'IA, ça montre que les progrès en rédaction de l'IA (ou les progrès prévisibles) ne feront que rendre plus difficile à identifier ces contenus, sans que leur qualité augmente pour autant.
Je ne comprends pas bien où tu veux en venir. En lisant tes messages, on a l'impression que tu es là pour chipoter, un peu comme un climatosceptique qui viendrait demander des chiffres et des sources dans une discussion sur la canicule actuelle.
J'imagine bien que ce n'est pas réellement le cas, mais je ne comprends pas le fond de ta pensée.
En ce qui me concerne, et je pense que c'est aussi l'avis de la majorité des personnes qui commentent ici c'est que 1) il y a régulièrement des journaux et au moins une dépêche postés par IA, et je suis sûr à 100% de mon diagnostic 2) ces journaux sont pénibles, et sont devenus trop fréquents.
Perso j'ai compris la phrase complète "vous faites excessivement de retours négatifs comme les dévs que j'encadre", mais effectivement ton interprétation marche aussi
Si on regarde les contenus générés par IA, que ce soit les journaux ici, ou par exemple les contributions aux projets Open Source, on constate que les auteurs de ces contributions sont paresseux, et il y a plein de problèmes qui en découlent :
Le journal n'est pas relu, et est subtilement faux ou ne contient pas d'informations utiles, donc le lecteur perd son temps
Le projet en lien du journal est vibe codé et ne sera jamais maintenu, donc l'utilisateur perd son temps
L'auteur ne répond pas aux commentaires, donc le commentateur qui pose une question perd son temps.
Par contre il faudrait également modérer le commentaire auquel je réponds, qui est manifestement illégal, vu qu'il contient des propos diffamatoires (imputation de délits) envers des personnes facilement identifiables.
Tu ne sembles pas avoir constaté que les faits se sont produits plutôt hors des horaires de travail, qu'il y a plein de raisons possibles de ne pas travailler à un moment donné, et surtout que tu ne connais pas les actions des personnes que tu cites, qui sont de toute façon présumées innocentes laisse penser que tu as subi un grave traumatisme.
Évitent les versions flottantes, donc les nouvelles versions (vérolées) ne sont pas téléchargée par défaut sans action de l’utilisateur sur les numéros de version.
npm non plus n'utilise pas de versions flottantes (dans le sens que tu l'entends dans ton commentaire). npm install installe les versions indiquées dans le package-lock.json, qui sont des versions exactes (hash compris), y compris pour les dépendances transitives. Il n'y a que le cas où un package est absent du package-lock que la version flottante est installée (typiquement si un nouveau package a été ajouté manuellement au package-lock). npm ci fait la même chose que npm install, sauf que dans ce dernier cas (besoin d'installer un package absent du package-lock) il retournera une erreur.
Le sujet ce n'est pas si la réponse est pertinente ou pas, c'est que n'importe qui peut poser la question à un LLM s'il le souhaite. Donc si l'OP a posé sa question ici, c'est qu'il n'est pas intéressé par une réponse de LLM sans aucun apport humain.
Combien de personnes ont encore un modèle concerné par ce problème ?
J'ai la version usb-only d'un modèle concerné par le problème. Pour le coup on est plutôt sur le contraire de l'obsolescence programmée : l'imprimante a 20 ans, marche très bien, et on peut toujours acheter des consommables.
Il supporte les pointeurs du style void * comme en C.
Le fait d'avoir des section unsafe en rust le rend inutile ?
Le problème, en Go, est que tu peux avoir des NullPointerExceptions en écrivant du code normal. En rust, comme tu l’indiques, le « problème » est limité à des sections de code très précises que tu peux analyser avec plus d’attention.
C’est d’autant plus dommage que ce problème n’existe pas dans les autres langages récents (typescript, swift, etc.).
Oui, je confirme. J'ai compris qu'il y avait un sérieux problème de conception avec cette phrase : « La transmission, c’est un seul plateau et 9 pignons ». C'est très anormal, avec autant de pignons, tu as une sacrée largeur entre le plus grand et le plus petit, et ça fait normalement dérailler à coup sûr le plateau quand tu n'es pas sur les pignons centraux.
[^] # Re: Syndrome de Stockholm?
Posté par fork_bomb . En réponse au journal Pourquoi le modèle de concurrence de Node.js est bien. Évalué à 6 (+6/-1).
Par exemple le journal sous lequel tu commentes ?
# Salut
Posté par fork_bomb . En réponse au journal [Projet] Appel à relecture du catalogue des applications mobiles proposées par la puissance publique. Évalué à 3 (+2/-0).
Super travail, merci !
Je suis surpris de voir pas mal d'applis qui sont simplement de la documentation (par ex. plusieurs applis des APHP ou de l'INRAE), et en plus la dite documentation est séparée en plusieurs applis. J'ai du mal à comprendre l'intérêt d'avoir fait cet effort par rapport à un simple site, et aussi curieux du nombre d'utilisateurs de ces applis.
[^] # Re: no future
Posté par fork_bomb . En réponse au journal Pourquoi le modèle de concurrence de Node.js est bien. Évalué à 4 (+3/-0). Dernière modification le 08 juin 2026 à 13:15.
Si je comprends bien comment Future (en Java) marche, il permet d'exécuter une fonction dans un autre thread (ou plus généralement d'une façon fournie par l'exécuteur), et ensuite d'obtenir son résultat avec la méthode Future.get(), qui est bloquante.
Avec le modèle Reactor, ce n'est pas possible (ni souhaité) d'avoir une fonction bloquante (vu que ça bloquerait tous les traitements du thread unique, et, dans le cas de Future.get provoquerait un deadlock), donc il n'est pas possible d'avoir une fonction Future.get, et donc d'extraire le résultat du calcul du Future.
On serait donc obligé d'utiliser le résultat de la Future sans l'extraire, par exemple avec
CompletableFuture.thenApply, ce qui, si on utilise ça partout, serait particulièrement illisible, d'où l'intérêt d'avoir un sucre syntaxique comme async/await pour gérer ça plus simplement[^] # Re: Syndrome de Stockholm?
Posté par fork_bomb . En réponse au journal Pourquoi le modèle de concurrence de Node.js est bien. Évalué à -3 (+1/-5).
Franchement c'est un peu lamentable de passer du temps à écrire ce message qui n'a aucun détail précis (qui permettraient au lecteur de comprendre ce qui ne te plait pas dans le langage) plutôt qu'à mettre à jour tes connaissances.
Je pourrais répondre point par point mais je ne vois pas pourquoi je prendrais du temps alors que tu ne l'as pas fait.
Juste pour prendre ton premier point un peu précis :
Pour débugger un programme JavaScript, que ce soit Node.JS ou dans le navigateur, je met un point d'arrêt en cliquant dans mon éditeur ou dans les outils de développement, et quand je relance le programme, il s'y arrête.
[^] # Re: assistance
Posté par fork_bomb . En réponse au journal L'IA et le mythe du combat ultime. Évalué à 8 (+7/-0).
Je ne voulais pas dire qu'il est complotiste ou incohérent, mais qu'en regardant uniquement des indices rapidement visibles (la longueur et le thème, et maintenant le score négatif), des gens ont pu conclure sans lire que c'était ce type de journal
[^] # Re: assistance
Posté par fork_bomb . En réponse au journal L'IA et le mythe du combat ultime. Évalué à 9 (+11/-3).
Malheureusement ce n'est pas l'effort qu'on y a mis qui fait le succès de quelque chose, surtout pour un contenu sur internet où tout le monde à une surabondance de choses à lire ou à regarder.
Dans le cas de ton journal il y a pour moi deux soucis qui font que les lecteurs de DLFP ne vont pas y accorder l'attention qu'il mérite :
Comme déjà évoqué, la référence à l'IA : il y a eu ces derniers mois de nombreux contenus de mauvaise qualité générés par IA, ce qui fait que les lecteurs ont désormais une réaction épidermique
La longueur et le thème philosophique du journal : il y a là aussi un historique de journaux de ce type, mais avec un contenu incohérent ou complotiste, laissant presque (ou pas) penser à des problèmes psychiatriques chez leurs auteurs
# Moi aussi je sais utiliser l'IA
Posté par fork_bomb . En réponse au journal L'IA et le mythe du combat ultime. Évalué à 10 (+12/-2).
Pré-scriptum : oui, j'ai fait écrire mon commentaire à un LLM (GPT-5.5)
L'utilisation du LLM dans ton journal se voit beaucoup trop. On retrouve tous les travers habituels : des tonnes de texte, des analogies à répétition, des détours dans tous les sens et une argumentation qui avance péniblement. Le résultat donne une impression de profondeur, mais quand on regarde de près il y a souvent assez peu de substance derrière.
Le plus gênant, c'est que cela fait perdre du temps au lecteur. Parce que générer trois pages de texte ne coûte quasiment rien à une IA, le texte n'est plus contraint par l'effort d'écriture. En revanche, chaque paragraphe supplémentaire doit être lu par des humains. J'ai eu plusieurs fois l'impression de devoir traverser de longues digressions pour extraire une idée qui aurait tenu en quelques lignes.
Au final, j'ai surtout l'impression que le LLM a servi à augmenter le volume du journal plutôt que sa qualité. Le texte aurait probablement gagné à être deux ou trois fois plus court et à consacrer l'espace économisé à renforcer les arguments plutôt qu'à les reformuler.
[^] # Re: Syndrome de Stockholm?
Posté par fork_bomb . En réponse au journal Pourquoi le modèle de concurrence de Node.js est bien. Évalué à 5 (+4/-0).
Mais encore ?
[^] # Re: What color is your function ?
Posté par fork_bomb . En réponse au journal Pourquoi le modèle de concurrence de Node.js est bien. Évalué à 2 (+2/-1).
L'article est intéressant, mais je trouve que la gravité du "problème" évoqué n'est absolument pas en rapport avec la popularité de l'article.
Tout d'abord, la solution que préfère l'auteur (dernier paragraphe) sont les green threads. Ce n'est pas une meilleure solution mais un compromis différent, comme dit dans mon journal (besoin de gérer la synchronisation à la main, overhead sur chaque thread, profil de performance différent). Certes il n'y a plus le sujet du function coloring au niveau du langage, mais encore faut-il que les autres compromis conviennent.
Sur le fond, la raison principale pour laquelle le function coloring n'est pas un vrai problème, c'est que dans un programme bien architecturé, l'I/O est en haut de l'arbre des appels, et qu'au fur et à mesure qu'on rentre dedans on essaie d'avoir des fonctions pures, ou plus généralement qui peuvent facilement être testées.
D'ailleurs le function coloring n'est pas spécifique à async/await : une fonction qui prend en premier argument une connexion à la base de données, ou encore une référence à la requête en cours ne peut pas être appelée par une fonction qui n'a pas cette référence. Certes dans ce cas il y a des façons simples d'éviter le problème comme utiliser un singleton, du thread-local storage ou équivalent, mais ce n'est pas forcément une solution propre ou souhaitable.
Pour moi le seul cas où il y a un vrai problème est si l'on doit appeler une fonction async à partir d'une librairie qui ne le prévoit pas, par exemple un validateur XML qui permet de fournir un callback pour vérifier certains éléments, et on souhaite dans ce callback appeler un service web. Mais, en pratique, du moins dans l'écosystème node.js, c'est extrêmement marginal (personnellement je n'ai jamais vu le problème), et, vu que la grande majorité des librairies sont opensource il est facile de les modifier pour avoir le comportement qu'on souhaite.
Et, enfin, ce n'est pas vrai qu'il n'est pas possible d'appeler des fonctions async à partir d'une fonction sync. Ce n'est pas une bonne idée vu que ça bloque l'event loop, mais, par exemple en Node.js ça peut être fait en exécutant la fonction dans un worker thread et en attendant son résultat avec Atomics.wait.
[^] # Re: sources ?
Posté par fork_bomb . En réponse au journal Publication de contenus augmentés par l'IA. Évalué à 7 (+6/-0).
Pour moi le score est positif car la dépêche est plus subtile, mais ça illustre que le problème est en train de s'aggraver.
Je m'explique :
Pour moi, le score est positif car c'est moins flagrant que le contenu est du contenu sans intérêt : les signes de l'écriture par IA sont moins présents, les objections sont anticipées (rôle de l'IA dans la création du projet et du journal, l'utilisateur est nouveau, etc.), contenu davantage dans la ligne éditoriale du site (libre, potentiellement intéressant pour le public).
Par contre, le fond est autant inintéressant que les autres journaux qui eux ont été moinssés : projet non fonctionnel (c'est présenté comme quelque chose de réutilisable mais il y a juste une démo), code généré par IA, et même concept de base foireux (la récupération du mot de passe par mail est remplacée par un système troué).
Donc au final, même si la dépêche est peut-être passée grâce à une relecture manuelle et non grâce aux progrès de l'IA, ça montre que les progrès en rédaction de l'IA (ou les progrès prévisibles) ne feront que rendre plus difficile à identifier ces contenus, sans que leur qualité augmente pour autant.
[^] # Re: sources ?
Posté par fork_bomb . En réponse au journal Publication de contenus augmentés par l'IA. Évalué à 7 (+6/-0).
Je ne comprends pas bien où tu veux en venir. En lisant tes messages, on a l'impression que tu es là pour chipoter, un peu comme un climatosceptique qui viendrait demander des chiffres et des sources dans une discussion sur la canicule actuelle.
J'imagine bien que ce n'est pas réellement le cas, mais je ne comprends pas le fond de ta pensée.
En ce qui me concerne, et je pense que c'est aussi l'avis de la majorité des personnes qui commentent ici c'est que 1) il y a régulièrement des journaux et au moins une dépêche postés par IA, et je suis sûr à 100% de mon diagnostic 2) ces journaux sont pénibles, et sont devenus trop fréquents.
[^] # Re: Evidemment !!!
Posté par fork_bomb . En réponse au journal ELY - Un agent IA auto-hébergé conforme RGPD avec anonymisation native. Évalué à 1 (+0/-0).
Perso j'ai compris la phrase complète "vous faites excessivement de retours négatifs comme les dévs que j'encadre", mais effectivement ton interprétation marche aussi
[^] # Re: Evidemment !!!
Posté par fork_bomb . En réponse au journal ELY - Un agent IA auto-hébergé conforme RGPD avec anonymisation native. Évalué à 1 (+3/-3).
Tu es bien généreux de nous honorer de ta prose alors que nous sommes tes subordonnés.
# Bonjour
Posté par fork_bomb . En réponse au journal ELY - Un agent IA auto-hébergé conforme RGPD avec anonymisation native. Évalué à 10 (+11/-1). Dernière modification le 14 mai 2026 à 15:40.
Est-ce que tu as lu les journaux précédents au sujet des journaux générés par IA ?
Si oui, qu'en as-tu conclu ?
[^] # Re: qu'est ce qui vous gêne ?
Posté par fork_bomb . En réponse au journal [LinuxFr] Confiance, IA et contenu. Évalué à 10 (+14/-1).
Si on regarde les contenus générés par IA, que ce soit les journaux ici, ou par exemple les contributions aux projets Open Source, on constate que les auteurs de ces contributions sont paresseux, et il y a plein de problèmes qui en découlent :
Le journal n'est pas relu, et est subtilement faux ou ne contient pas d'informations utiles, donc le lecteur perd son temps
Le projet en lien du journal est vibe codé et ne sera jamais maintenu, donc l'utilisateur perd son temps
L'auteur ne répond pas aux commentaires, donc le commentateur qui pose une question perd son temps.
# Essaie de te faire des amis
Posté par fork_bomb . En réponse au journal Pourquoi je recommanderai (vraiment) pas Wero de sitôt.. Évalué à -5 (+14/-20).
Tu comprendras à quoi ça sert.
[^] # Re: LLM ou pas LLM ?
Posté par fork_bomb . En réponse au journal [HS] [META] Les humains sont-ils courtois avec les IAs ?. Évalué à 3 (+2/-0).
C'est clairement rédigé par une IA, il y a pas mal d'indicateurs qui laissent penser que c'en est une.
Sur le fond : chaque phrase a l'air plausible, mais toutes les phrases mises bout à bout ne construisent pas une pensée cohérente.
Sur la forme :
[^] # Re: Biais médiatique
Posté par fork_bomb . En réponse au lien Mort de Quentin Deranque : un deuxième collaborateur du député LFI Raphaël Arnault fait partie des onze personnes en garde à vue. Évalué à 4. Dernière modification le 24 février 2026 à 13:24.
Désolé pour le commentaire agressif.
Par contre il faudrait également modérer le commentaire auquel je réponds, qui est manifestement illégal, vu qu'il contient des propos diffamatoires (imputation de délits) envers des personnes facilement identifiables.
[^] # Re: Biais médiatique
Posté par fork_bomb . En réponse au lien Mort de Quentin Deranque : un deuxième collaborateur du député LFI Raphaël Arnault fait partie des onze personnes en garde à vue. Évalué à 2. Dernière modification le 24 février 2026 à 11:21.
NdM: phrase agressive supprimée
Tu ne sembles pas avoir constaté que les faits se sont produits plutôt hors des horaires de travail, qu'il y a plein de raisons possibles de ne pas travailler à un moment donné, et surtout que tu ne connais pas les actions des personnes que tu cites, qui sont de toute façon présumées innocentes laisse penser que tu as subi un grave traumatisme.
[^] # Re: Je me demande
Posté par fork_bomb . En réponse au journal npm et badaboum. Évalué à 5.
npm non plus n'utilise pas de versions flottantes (dans le sens que tu l'entends dans ton commentaire).
npm installinstalle les versions indiquées dans le package-lock.json, qui sont des versions exactes (hash compris), y compris pour les dépendances transitives. Il n'y a que le cas où un package est absent du package-lock que la version flottante est installée (typiquement si un nouveau package a été ajouté manuellement au package-lock).npm cifait la même chose quenpm install, sauf que dans ce dernier cas (besoin d'installer un package absent du package-lock) il retournera une erreur.[^] # Re: Je me demande
Posté par fork_bomb . En réponse au journal npm et badaboum. Évalué à 6.
Le sujet ce n'est pas si la réponse est pertinente ou pas, c'est que n'importe qui peut poser la question à un LLM s'il le souhaite. Donc si l'OP a posé sa question ici, c'est qu'il n'est pas intéressé par une réponse de LLM sans aucun apport humain.
[^] # Re: Obsolescence pas programmée
Posté par fork_bomb . En réponse au journal Brother ne mettra pas à jour les micrologiciels des imprimantes qui utilisent TLS 1.0. Évalué à 3.
J'ai la version usb-only d'un modèle concerné par le problème. Pour le coup on est plutôt sur le contraire de l'obsolescence programmée : l'imprimante a 20 ans, marche très bien, et on peut toujours acheter des consommables.
[^] # Re: Le pas sanitaire
Posté par fork_bomb . En réponse au journal La Quadrature du Net fait-elle fausse route ?. Évalué à 10.
D'excellents arguments ont été donnés, y compris dans les commentaires de ce journal et dans d'autres.
Comme tu n'es pas stupide, cela signifie donc que sois tu mens, soit tu n'as fait aucun effort pour te renseigner.
Dans les deux cas ça ne sert donc à rien que tu continues de poster sur ce sujet.
[^] # Re: Pourquoi Rust ?
Posté par fork_bomb . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 1.
Le problème, en Go, est que tu peux avoir des NullPointerExceptions en écrivant du code normal. En rust, comme tu l’indiques, le « problème » est limité à des sections de code très précises que tu peux analyser avec plus d’attention.
C’est d’autant plus dommage que ce problème n’existe pas dans les autres langages récents (typescript, swift, etc.).
[^] # Re: Non
Posté par fork_bomb . En réponse au journal Prime réparation vélo. Évalué à 3.
Connais-tu l'effet Dunning-Kruger ?