L'article est quand même bien daté et une bonne partie n'est plus trop pertinente au regard de la situation actuelle. A l'époque, le LSP et son implémentation en Rust(RLS) étaient encore a leur début. Depuis, RLS a été supplanté par rust-analyser : une nouvelle implémentation from scratch conçue spécifiquement pour l'analyse rapide de source, même incomplet, ce qui est bien mieux taillé pour les IDE. De plus le protocole LSP s'est aussi étoffé et offre plus de fonctionnalités, notamment pour mieux gérer un projet dans son ensemble.
Le seul IDE qui à fait le choix du plugin Rust spécifique et qui s'est donné les moyens de le maintenir est Intellij IDEA/CLion. Il faut reconnaitre que c'est un travail de qualité mais qui n'est clairement pas a la portée de la plupart des mainteneurs d'IDE. De nos jours, le support de Rust dans Kdevelop n'est plus maintenu alors que tous les éditeurs qui supportent le LSP ont une gestion plutôt bonne du Rust quasiment au niveau d'Intellij IDEA.
J'aime beaucoup le principe. J’apprécie énormément que ça ne se contente pas d'afficher individuellement les cases les unes après les autres mais que ça déplace la vue sur la page complète : cela permet de ne pas faire disparaitre totalement la notion de cadrage. C'est bien de pouvoir alterner entre le mode page et case, mais l'IHM pour faire ça n'est pas pratique.
En fait l'idée gagnerait énormément intégrée dans un lecteur de BD complet pour tablette/téléphone. On aurait la possibilité de passer du mode case au mode page en pinçant/écartant deux doigts. Ça permettrait aussi de calculer les pages à venir pendant la lecture de la page en cours. En effet le temps de calcul et un peu long. S'il devait se produire à chaque page ça serait vite ennuyeux.
Le problème c'est justement qu'il se présente comme un indice de "popularité" et que le lien de cause a effet avec le nombre de résultats retourné pour des requêtes très précises dans les moteurs de recherche est tout sauf clair.
Par ce que ça n'est pas un classement des langages les plus aimsé, mais de ceux qui retournent le plus de résultat quand on recherche un tutoriel. Le TIOBE est un indice très mauvais, et c'est fou que tout le monde le prenne encore pour une référence de popularité.
En effet Apple, bien qu'il fasse partie du Kronos group qui a établi la spécification de Vulkan, n'a pour le moment rien annoncé a propos d'un éventuel support par iOS et MacOS X.
Depuis le succès des iBudules la politique globale de Apple et de dire autant que possible merde au cross plateforme. Et comme ils possèdent leur propre API graphique : Metal, il est probable qu'ils n’implémenteront pas Vulkan, à moins d'y être obligé par un échec de Metal et un succès fulgurant de Vulkan.
Il serait plus exact de dire que "Tiens, Dropbox utilise Rust en production". Parce qu'ils ne l'utilisent encore que pour une partie de leur nouvelle infrastructure, certes essentielle au niveau des performances, mais très limitée.
Sauf que ça c'est pas nouveau, ça date de 2007. Un site a fait un article là dessus, des dizaines d'autres l'on repris bêtement et tout le monde semble penser que ça vient de tomber.
Personnellement je trouve le nouveau système bien plus adapté. Ça devrait enfin être la fin des programmes qui changent discrètement tes associations contre ton gré. Je pense que celui qui va souffrir le plus de ce système va être Chrome qui à la fâcheuse tendance de s'installer avec des applications tierces.
Là ou Mozilla ferait mieux de râler c'est contre l'installation de Edge par défaut et la disparition du ballot screen qui en effet fausse la concurrence.
C'est tout a fait ça. Copy sert juste a dire au compilateur que le type peut être copié de manière brute via un memcpy. Ceci dit si l'optimiseur détecte il n'a pas besoin de copier, il ne le fera pas.
Il en parlent assez vite fait a la fin de la conf de sortie de rust ou ils présentent quelques idée sur le sujet : https://air.mozilla.org/rust-release-party/
Mais ça n'a l'air d'être encore vague, il n'y a encore rien de concret pour le moment.
En fait au début c'était explicite, mais ça c'était révélé trop lourd à l'usage. Ils ont donc opté pour ce système qui est, il est vrai, déroutant au début, mais auquel on finit par s'habituer.
Ça existe aussi en C++, depuis C++03 avec auto_ptr (mais qui était une catastrophe), et correctement depuis C++11 avec la sémantique de mouvement / unique_ptr.
La différence c'est qu'en Rust c'est géré à la compilation. Alors qu'en C ça provoque une erreur à l'exécution.
pas de support de la programmation par contrats
C'est dans les cartons. Lors de la conférence de présentation de la 1.0.0, ils ont justement discuté des idées qu'ils avaient à ce propos.
Je ne connais pas les détails exacts du bug, mais si la description du problème dans l'article correspond bien à la réalité:
une lecture mémoire en dehors des limites lors de validation asm.js.
Ça veut bien dire que c'est le code C++ réalisant la validation du asm.js qui provoque le dépassement et pas le code qui a été généré.
Ce n'est pas pour rien que Mozilla travaille sur le langage Rust qui garantit la sécurité mémoire. Il reste évidement plein d'autres types de risques, mais c'est quand même une avancée certaine au niveau de la sécurité, vu que ce type d'erreurs est très souvent critique et que l'expérience continue toujours de prouver qu'elles finissent fatalement par arriver, même aux meilleurs programmeurs.
En garantissant la sécurité de la mémoire, ce type d'erreurs ne peut plus arriver. Valgrind reste en effet utile à cause des bibliothèques externes et des blocs de code "unsafe". Mais ce n'est pas non plus un outil magique qui fait disparaître les bugs, donc avoir la garantie que la grande majorité du code est saine niveau mémoire, c'est bon à prendre.
Ça y est, Rust 1.0 alpha est sorti ! Cela signifie que le langage et les bibliothèques ne recevront plus de changements majeurs.
Petite erreur sur ce point. Le langage ne devrait plus avoir de changement incompatibles, sauf si un problème manifeste était trouvé. Cependant des évolutions importantes mais rétrocompatibles sont déjà prévues dans le futur.
Par contre pour ce qui est des bibliothèques standard, il est encore prévu pas mal de changements non rétrocompatibles au moins jusqu'à la sortie de la version Beta. Il y a entre autre en ce moment une refonte complète de la partie io dans la "stdlib".
Je dirais plutôt que, à la lumière des résultats de Go, les stats de Rust sont plutôt bonnes. Comme tu le signales, Rust n'est même pas encore en version 1.0. Il n'est pas vraiment utilisable pour le moment en production (à part pour quelque masos qui n'ont pas peur de devoir réparer en permanence leur code) et il a pourtant déjà une forte communauté derrière lui.
De plus il faut voir que Rust et Go ne sont que partiellement en concurrence. Il peuvent être tous les deux utilisable dans pas mal de domaines communs. Mais Go, notamment grâce avec son GC intégré est plus simple a prendre en main, au prix de performance brutes moindres.
Rust de son coté met bien plus l'accent sur la sécurité et est un langage vraiment capable de faire de la programmation système (OS, drivers, …). En fait Rust concurrence plus le C/C++ que le Go.
Et encore, sur les personnes avec des adresses en "@mozilla.com", une bonne partie sont des gens qui travaillent principalement sur Servo et Firefox et ne contribuent qu’occasionnellement à Rust. Le nombre de global de plein temps sur Rust ne doit pas dépasser la dizaine.
Si je me souviens bien, à la base la licence était uniquement MIT mais ils ont ajouté la APL 2.0 parce qu'elle a une clause pour prendre en compte les brevets.
Ça ne résoudrait de toute façon pas tous les problèmes. Toute utilisation de Firefox (dans une distribution Linux par exemple) dans un pays qui reconnais les brevets logiciels pourrait être attaquée en justice.
Posté par Uther Lightbringer .
En réponse à la dépêche Firefox 27.
Évalué à 7.
Dernière modification le 07 février 2014 à 09:25.
Les sorties de Firefox ne dépendent plus du nombre de nouveautés depuis la version 4. Maintenant une nouvelle version sort tous les 6 semaines avec tout ce qui est prêt a être intégré.
Donc la version 4212 est normalement prévue pour 2497. Ca laisse le temps de voir venir.
D'abord, parce que ça reste plus discret. Ca s'affiche quand on veut vraiment lancer quelque chose. Ou savoir ce qui tourne. Pas non stop.
Une barre de tache s'affiche aussi en permanence en général. On peut la mettre en masquage automatique, mais il en va de même pour les docks.
Enfin, et la critique s'applique à plein d'autres éléments d'interface, j'en ai marre de ces trucs faits (même si ils supportent autre chose) pour aller en haut ou en bas de d'écran, sur des écrans toujours plus larges (et donc toujours moins haut). Ça rejoint le débat sur les barres d'outils (ou les rubans).
Là aussi, je trouve la critique assez injuste vu que dans tous les environnements à dock que j'ai testé, c'est facilement réglable (sauf sous Unity ou c'est déjà sur le coté) et on peut le mettre aussi bien en haut en bas qu'a gauche ou droite.
Pour s'en convaincre, quelques jours sous Windows 8. Puis quelques jours sous MacOS. Et je reviens en courant à mon KDE/Gnome/WindowsXP.
Moi j'ai testé et j'ai été plutôt convaincu par le dock de MacOS X, même si je comprend très bien qu'on puisse préférer une barre de taches classique. Par contre, j'ai remarqué que le dock est beaucoup plus intuitif pour Madame Michu pour qui le concept d'application en cours d'exécution est difficile.
Dans Windows 8 le plus gros problème n'est pas le dock mais surtout ce fonctionnement à deux niveau avec deux interfaces parallèle et horriblement mal intégrés.
Je dirais chacun sa vue de l’environnement parfait. L'avantage sous Linux c'est qu'on a le choix (parfois même un peu trop mais c'est un autre problème).
Le compilateur a bien détecté que c'est un entier, c'est d'ailleurs bien précisé dans la seconde partie du message. Mais il n'a pas le nom du type exact car ça pourrait être n'importe quel des divers types d'entiers (int, uint, i32, …)
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Uther Lightbringer . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 5.
Si les brevets sont rédhibitoires, une comparaison avec l'AV1 pourrait être intéressante.
[^] # Re: Points de vue alternatifs
Posté par Uther Lightbringer . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 8.
L'article est quand même bien daté et une bonne partie n'est plus trop pertinente au regard de la situation actuelle. A l'époque, le LSP et son implémentation en Rust(RLS) étaient encore a leur début. Depuis, RLS a été supplanté par rust-analyser : une nouvelle implémentation from scratch conçue spécifiquement pour l'analyse rapide de source, même incomplet, ce qui est bien mieux taillé pour les IDE. De plus le protocole LSP s'est aussi étoffé et offre plus de fonctionnalités, notamment pour mieux gérer un projet dans son ensemble.
Le seul IDE qui à fait le choix du plugin Rust spécifique et qui s'est donné les moyens de le maintenir est Intellij IDEA/CLion. Il faut reconnaitre que c'est un travail de qualité mais qui n'est clairement pas a la portée de la plupart des mainteneurs d'IDE. De nos jours, le support de Rust dans Kdevelop n'est plus maintenu alors que tous les éditeurs qui supportent le LSP ont une gestion plutôt bonne du Rust quasiment au niveau d'Intellij IDEA.
# Concept intéressant qui gagnerait beaucoup dans un lecteur complet
Posté par Uther Lightbringer . En réponse à la dépêche Kumiko, découpe de bande dessinée et lecture case par case. Évalué à 7.
J'aime beaucoup le principe. J’apprécie énormément que ça ne se contente pas d'afficher individuellement les cases les unes après les autres mais que ça déplace la vue sur la page complète : cela permet de ne pas faire disparaitre totalement la notion de cadrage. C'est bien de pouvoir alterner entre le mode page et case, mais l'IHM pour faire ça n'est pas pratique.
En fait l'idée gagnerait énormément intégrée dans un lecteur de BD complet pour tablette/téléphone. On aurait la possibilité de passer du mode case au mode page en pinçant/écartant deux doigts. Ça permettrait aussi de calculer les pages à venir pendant la lecture de la page en cours. En effet le temps de calcul et un peu long. S'il devait se produire à chaque page ça serait vite ennuyeux.
[^] # Re: De l'engouement pour Python
Posté par Uther Lightbringer . En réponse à la dépêche Python dépasse Java en popularité selon l’indice TIOBE de novembre. Évalué à 3.
Le problème c'est justement qu'il se présente comme un indice de "popularité" et que le lien de cause a effet avec le nombre de résultats retourné pour des requêtes très précises dans les moteurs de recherche est tout sauf clair.
[^] # Re: De l'engouement pour Python
Posté par Uther Lightbringer . En réponse à la dépêche Python dépasse Java en popularité selon l’indice TIOBE de novembre. Évalué à 10.
Par ce que ça n'est pas un classement des langages les plus aimsé, mais de ceux qui retournent le plus de résultat quand on recherche un tutoriel. Le TIOBE est un indice très mauvais, et c'est fou que tout le monde le prenne encore pour une référence de popularité.
[^] # Re: Le titre de la news...
Posté par Uther Lightbringer . En réponse à la dépêche John Conway n’avait plus assez de cases noires dans son voisinage. Évalué à 4.
Vu qu'il est décédé suite au Covid19, donc contaminé par proximité, la seconde option correspond d'ailleurs mieux.
[^] # Re: Waw !
Posté par Uther Lightbringer . En réponse à la dépêche Un nouveau moteur de rendu ultra‐rapide pour Firefox : Quantum Render. Évalué à 3.
Tu peux la créer si elle n'est pas disponible de base.
[^] # Re: MacOSX / iOS
Posté par Uther Lightbringer . En réponse à la dépêche La nouvelle API graphique Vulkan. Évalué à 10. Dernière modification le 25 mai 2016 à 20:55.
En effet Apple, bien qu'il fasse partie du Kronos group qui a établi la spécification de Vulkan, n'a pour le moment rien annoncé a propos d'un éventuel support par iOS et MacOS X.
Depuis le succès des iBudules la politique globale de Apple et de dire autant que possible merde au cross plateforme. Et comme ils possèdent leur propre API graphique : Metal, il est probable qu'ils n’implémenteront pas Vulkan, à moins d'y être obligé par un échec de Metal et un succès fulgurant de Vulkan.
# A propos de Rust
Posté par Uther Lightbringer . En réponse à la dépêche Firefox 46 (version suédée). Évalué à 9.
Il serait plus exact de dire que "Tiens, Dropbox utilise Rust en production". Parce qu'ils ne l'utilisent encore que pour une partie de leur nouvelle infrastructure, certes essentielle au niveau des performances, mais très limitée.
[^] # Re: Pendant ce temps là
Posté par Uther Lightbringer . En réponse à la dépêche Parution de Firefox 43. Évalué à 0.
Sauf que ça c'est pas nouveau, ça date de 2007. Un site a fait un article là dessus, des dizaines d'autres l'on repris bêtement et tout le monde semble penser que ça vient de tomber.
# Nouveau système d'association
Posté par Uther Lightbringer . En réponse à la dépêche Lettre ouverte de Mozilla au CEO de Microsoft. Évalué à 10. Dernière modification le 01 août 2015 à 08:53.
Personnellement je trouve le nouveau système bien plus adapté. Ça devrait enfin être la fin des programmes qui changent discrètement tes associations contre ton gré. Je pense que celui qui va souffrir le plus de ce système va être Chrome qui à la fâcheuse tendance de s'installer avec des applications tierces.
Là ou Mozilla ferait mieux de râler c'est contre l'installation de Edge par défaut et la disparition du ballot screen qui en effet fausse la concurrence.
[^] # Re: Très bonne nouvelle, je vais m'y adonner je pense
Posté par Uther Lightbringer . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 1.
En fait ils ont arrêté il me semble, et ca a énervé pas mal de monde
[^] # Re: Premières impressions
Posté par Uther Lightbringer . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 1. Dernière modification le 24 mai 2015 à 10:22.
C'est tout a fait ça. Copy sert juste a dire au compilateur que le type peut être copié de manière brute via un memcpy. Ceci dit si l'optimiseur détecte il n'a pas besoin de copier, il ne le fera pas.
[^] # Re: Premières impressions
Posté par Uther Lightbringer . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Il en parlent assez vite fait a la fin de la conf de sortie de rust ou ils présentent quelques idée sur le sujet : https://air.mozilla.org/rust-release-party/
Mais ça n'a l'air d'être encore vague, il n'y a encore rien de concret pour le moment.
[^] # Re: Premières impressions
Posté par Uther Lightbringer . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2. Dernière modification le 20 mai 2015 à 09:25.
En fait au début c'était explicite, mais ça c'était révélé trop lourd à l'usage. Ils ont donc opté pour ce système qui est, il est vrai, déroutant au début, mais auquel on finit par s'habituer.
[^] # Re: Premières impressions
Posté par Uther Lightbringer . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 1. Dernière modification le 20 mai 2015 à 09:21.
La différence c'est qu'en Rust c'est géré à la compilation. Alors qu'en C ça provoque une erreur à l'exécution.
C'est dans les cartons. Lors de la conférence de présentation de la 1.0.0, ils ont justement discuté des idées qu'ils avaient à ce propos.
[^] # Re: Développeur en C++
Posté par Uther Lightbringer . En réponse à la dépêche Firefox : version 38. Évalué à 8.
Je ne connais pas les détails exacts du bug, mais si la description du problème dans l'article correspond bien à la réalité:
Ça veut bien dire que c'est le code C++ réalisant la validation du asm.js qui provoque le dépassement et pas le code qui a été généré.
Ce n'est pas pour rien que Mozilla travaille sur le langage Rust qui garantit la sécurité mémoire. Il reste évidement plein d'autres types de risques, mais c'est quand même une avancée certaine au niveau de la sécurité, vu que ce type d'erreurs est très souvent critique et que l'expérience continue toujours de prouver qu'elles finissent fatalement par arriver, même aux meilleurs programmeurs.
En garantissant la sécurité de la mémoire, ce type d'erreurs ne peut plus arriver. Valgrind reste en effet utile à cause des bibliothèques externes et des blocs de code "unsafe". Mais ce n'est pas non plus un outil magique qui fait disparaître les bugs, donc avoir la garantie que la grande majorité du code est saine niveau mémoire, c'est bon à prendre.
# Pas encore vraiment stable
Posté par Uther Lightbringer . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 10.
Petite erreur sur ce point. Le langage ne devrait plus avoir de changement incompatibles, sauf si un problème manifeste était trouvé. Cependant des évolutions importantes mais rétrocompatibles sont déjà prévues dans le futur.
Par contre pour ce qui est des bibliothèques standard, il est encore prévu pas mal de changements non rétrocompatibles au moins jusqu'à la sortie de la version Beta. Il y a entre autre en ce moment une refonte complète de la partie io dans la "stdlib".
[^] # Re: Rust vs Go
Posté par Uther Lightbringer . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 7.
Je dirais plutôt que, à la lumière des résultats de Go, les stats de Rust sont plutôt bonnes. Comme tu le signales, Rust n'est même pas encore en version 1.0. Il n'est pas vraiment utilisable pour le moment en production (à part pour quelque masos qui n'ont pas peur de devoir réparer en permanence leur code) et il a pourtant déjà une forte communauté derrière lui.
De plus il faut voir que Rust et Go ne sont que partiellement en concurrence. Il peuvent être tous les deux utilisable dans pas mal de domaines communs. Mais Go, notamment grâce avec son GC intégré est plus simple a prendre en main, au prix de performance brutes moindres.
Rust de son coté met bien plus l'accent sur la sécurité et est un langage vraiment capable de faire de la programmation système (OS, drivers, …). En fait Rust concurrence plus le C/C++ que le Go.
[^] # Re: Rust vs Go
Posté par Uther Lightbringer . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 4. Dernière modification le 03 novembre 2014 à 13:05.
Et encore, sur les personnes avec des adresses en "@mozilla.com", une bonne partie sont des gens qui travaillent principalement sur Servo et Firefox et ne contribuent qu’occasionnellement à Rust. Le nombre de global de plein temps sur Rust ne doit pas dépasser la dizaine.
[^] # Re: Une petite question
Posté par Uther Lightbringer . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 2.
Si je me souviens bien, à la base la licence était uniquement MIT mais ils ont ajouté la APL 2.0 parce qu'elle a une clause pour prendre en compte les brevets.
[^] # Re: Intérêt limité de OpenH264 ?
Posté par Uther Lightbringer . En réponse à la dépêche Firefox : dites 33, comme chez le docteur. Évalué à 2.
Ça ne résoudrait de toute façon pas tous les problèmes. Toute utilisation de Firefox (dans une distribution Linux par exemple) dans un pays qui reconnais les brevets logiciels pourrait être attaquée en justice.
[^] # Re: En somme
Posté par Uther Lightbringer . En réponse à la dépêche Firefox 27. Évalué à 7. Dernière modification le 07 février 2014 à 09:25.
Les sorties de Firefox ne dépendent plus du nombre de nouveautés depuis la version 4. Maintenant une nouvelle version sort tous les 6 semaines avec tout ce qui est prêt a être intégré.
Donc la version 4212 est normalement prévue pour 2497. Ca laisse le temps de voir venir.
[^] # Re: J'aime pas
Posté par Uther Lightbringer . En réponse à la dépêche Cairo-Dock 3.3 prêt à s'installer sur votre bureau !. Évalué à 4.
Une barre de tache s'affiche aussi en permanence en général. On peut la mettre en masquage automatique, mais il en va de même pour les docks.
Là aussi, je trouve la critique assez injuste vu que dans tous les environnements à dock que j'ai testé, c'est facilement réglable (sauf sous Unity ou c'est déjà sur le coté) et on peut le mettre aussi bien en haut en bas qu'a gauche ou droite.
Moi j'ai testé et j'ai été plutôt convaincu par le dock de MacOS X, même si je comprend très bien qu'on puisse préférer une barre de taches classique. Par contre, j'ai remarqué que le dock est beaucoup plus intuitif pour Madame Michu pour qui le concept d'application en cours d'exécution est difficile.
Dans Windows 8 le plus gros problème n'est pas le dock mais surtout ce fonctionnement à deux niveau avec deux interfaces parallèle et horriblement mal intégrés.
Je dirais chacun sa vue de l’environnement parfait. L'avantage sous Linux c'est qu'on a le choix (parfois même un peu trop mais c'est un autre problème).
[^] # Re: Quel type
Posté par Uther Lightbringer . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 4.
Le compilateur a bien détecté que c'est un entier, c'est d'ailleurs bien précisé dans la seconde partie du message. Mais il n'a pas le nom du type exact car ça pourrait être n'importe quel des divers types d'entiers (int, uint, i32, …)
Si tu ajoute la précision du type :
il t'indique bien que tu as un int