Bruno Michel a écrit 3285 commentaires

Je n'arrive pas à reproduire le problème avec Chromium (ou Chrome) et je n'ai pas accès à Edge. Si quelqu'un peut proposer un patch, ça m'aiderait bien.

Je suis tombé sur cet article sur les Undefined Behavior : https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html. Je me dis que ça peut intéresser d'autres gens qui lisent ce fil de commentaires.

Les retours ne sont globalement pas très positifs sur le changement de position de la dépêche en une. J'ai fait un retour en arrière.

Oui, c'est prévu de mettre plus en avant cette page (mais ce n'est pas encore fait).

Ils marchent moins bien : maintenant il faut cliquer dans l'article pour que les raccourcis J et K fonctionnent.

Je n'ai pas l'impression d'avoir touché à quelque chose de ce côté là et je ne comprends pas vraiment ce qui ne marche pas. Est-ce que ce serait possible d'avoir plus de détails ?

Même problème sur la page "Les contenus que j'ai lus".

Sur les pages qui listent des contenus (dépêches, journaux, forums, etc.), j et k servent à naviguer entre les contenus pas encore lus. C'est donc normal que ça ne fasse rien sur la page "Les contenus que j'ai lus". Par contre, il y a les raccourcis [ et ']` pour naviguer entre les contenus avec de nouveaux commentaires.

De mon expérience (plus de web que d'apps mobiles ou desktop, mais j'ai quand même été confronté aux deux), la publication d'une app web est quand même d'un incroyable confort par rapport à celle d'une app desktop ou mobile. Voici à titre d'exemples quelques problèmes que l'on a rencontré avec les apps mobiles et desktop :

• L'app desktop est bloquée de temps à autre par tel ou tel anti-virus, il faut contacter l'éditeur de l'anti-virus qui, en général après une période de quelques semaines, finit par faire une mise à jour pour sa base de signatures et débloquer l'app.
• Plusieurs versions de nos apps iOS ont été bloquées sur l'app store pour non-respect des guidelines. Le processus pour débloquer ça est toujours laborieux, la réponse d'Apple est souvent très vague et dans la plupart des cas, le comportement fautif était déjà présent depuis longtemps (donc regarder juste les derniers changements pour voir ce qui bloque est une approche qui nous a fait perdre pas mal de temps).
• Les systèmes de mises à jour automatiques pour les apps desktop ne marchent pas super bien. Par exemple, un utilisateur nous a remonté que la mise à jour cassait les raccourcis quand l'app était installée via AppImage.
• On a publié une fois une version franchement cassée d'une app android, elle a été validée sans problème par Google. On a rapidement fait une autre mise à jour derrière pour corriger ça (dans les 24h), mais plusieurs semaines après, on avait encore des remontées de personnes qui étaient sur la version cassée.

Ça va, les gens savent installer une application native quand ils veulent.

Tu as une source pour dire ça ? Il me semblait avoir lu des études qui montraient le contraire : la majorité des gens ont installé 0 application sur les 12 derniers mois.

tu crois que les gens consultent gmail ou Youtube depuis leur navigateur sur téléphone ?

Ce sont de très mauvais exemples, ces applications sont pré-installées sur les téléphones, il n'y a pas besoin de les installer pour les utiliser.

Sur lobsters, il y a une discussion similaire : https://lobste.rs/s/zw9i1f/should_c_programmers_learn_c_go_rust. L'avis de l'auteur de l'article est que rien ne remplace le C. Dans les commentaires, c'est évidemment plus nuancé et plein d'avis différents. On peut quand même voir une sorte d'adhésion pour apprendre :

• Rust quand on vient du C
• D quand on vient du C++
• Go quand on vient de Python ou comme premier langage

En tout cas, j'ai changé le comportement du scroll. L'animation était avant faite en JavaScript et elle est maintenant faite en CSS, avec la propriété scroll-behaviour.

Pour savoir ce qui est mieux, je me demande si ce n'est pas juste une question d'habitude. Et dans le cas contraire (si d'autres gens se manifestent pour indiquer qu'ils préféraient l'ancienne version), on peut facilement revenir en arrière.

Les chiffres ne viennent pas d'un benchmark mais d'une vraie application en production avec 18 Go de heap, sur plusieurs serveurs (on peut d'ailleurs voir les déploiements avec un canari : un serveur migre vers une nouvelle version de Go avant les autres pour vérifier qu'il n'y a pas de régressions sur les performances).

Enfin, parmi les frameworks qui gagnent à être connus, il faut citer le projet Nerves qui est un vrai OS pour l'IoT entièrement en erlang/elixir.

Je t'encourage très fortement à écrire une dépêche sur Nerves. Ça a l'ait d'être un projet qui t'a plu et il n'y aura personne de mieux placé que toi pour le faire !

J'ai corrigé le commentaire. La syntaxe était bonne, par contre, il faut donner l'URL d'une image, pas celle d'une page HTML qui contient l'image.

Par exemple, en Go, il y a un modèle de programmation parallèle, certes vieux, certes plein de limites, mais qui fonctionnent et offre des garanties sans avoir à manipuler le moindre thread.

De quelles garanties tu parles ?

Le modèle de programmation parallèle de Go est intéressant mais il ne propose pas les mêmes garanties que le typage de Rust. Par exemple, ce programme compile et le résultat dépend d'une race condition : il peut afficher ["foo" "qux" "baz"] ou ["foo" "bar" "baz"].

package main

import "fmt"

func main() {
    c := make(chan []string)

    go func() {
        a := []string{"foo", "bar", "baz"}
        c <- a
        a[1] = "qux"
    }()

    b := <-c
    fmt.Printf("%q\n", b)
}

En rust, ce n'est pas possible de compiler un programme avec ce comportement. Il faudrait dire si le tableau sous-jacent au slice a est modifiable (mutable) et, si c'est le cas, les autres contextes d'exécution ne peuvent pas du tout y accéder. Ou alors, il n'est pas modifiable et peut-être partagé entre plusieurs contextes d'exécution. Si on veut pouvoir modifier le tableau dans un contexte et y accéder depuis un autre contexte, il faut en faire une copie, ce qui résout le problème de la race condition.

En pratique, c'est un problème que je rencontre de temps en temps sur cozy-stack (la partie de Cozy Cloud écrite en Go) et je considère que c'est une faiblesse de Go. Il y a un outil pour détecter les race conditions en Go, race detector, mais je ne le trouve pas très efficace. À l'inverse, le modèle de Rust est plus sûr mais il est plus contraignant (on perd pas mal de temps à se battre avec les types, surtout quand on est un débutant comme moi en Rust).

Pour ce qui est de la question thread / goroutine / futures, ce n'est pas dans le langage (Rust), mais ça s'implémente bien en dehors. Par exemple, actix propose un modèle à base d'acteurs et futures.rs propose des futures.

Pour wasm, il me semblait avoir lu que les fichiers Go compilés vers wasm étaient très gros (plus de 1 Mo pour un hello world) à cause de la nécessité d'inclure un gros runtime (notamment le garbage collector), alors que Rust a un runtime beaucoup plus petit et génère des fichiers wasm beaucoup plus petits (quelques dizaines de ko pour un hello world).

Elles ne sont pas très fiables. Par exemple, si tu prends l'évolution de Go sur TIOBE, ça n'a pas grand sens : https://www.tiobe.com/tiobe-index/go/. Ça aurait baissé entre 2010 et 2012, puis stable jusqu'à mi-2016, ensuite un grand boom sur quelques mois et depuis ça rebaisse. En vrai, ça a plutôt été tout le temps en croissance.

Ça permet quand même d'avoir une petite idée des tendances, surtout qu'on croise ça avec d'autres sources. Redmonk publie un classement à partir de données provenant de Github et de Stack Overflow (ça doit probablement favoriser les langages récents). PYPL a aussi un classement, à partir des données de Google Trends et avec seulement 22 langages.

Ça permet de se rendre compte que JavaScript a beaucoup progressé en une décennie, alors que Perl a beaucoup baissé, ou que Swift est passé devant Objective-C, mais il ne faut pas accorder trop d'importance à tel langage est à telle place.

Tout à fait, j'avais justement cité Go et Python pour ne pas prendre parti sur le fait de commencer par un langage à typage statique ou dynamique. Et si on part sur du typage statique, Go me paraît être un bien meilleur choix que C++ pour commencer. Par exemple, un hello world en C++ fait appel à std::cout, et donc implicitement à la notion de namespace qui n'est intéressante que bien plus tard.

Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire)

Il y a eu récemment un article intéressant sur le blog de Go : https://blog.golang.org/ismmkeynote. Les pauses du GC sont inférieures à la milliseconde, d'après les chiffres de ce billet.

La dépêche est restée longtemps dans l'espace de rédaction. La partie sur le multicore a probablement été écrite fin 2016 / début 2017, et comme Rust évolue assez rapidement, en 18 mois, ça a pas mal changé.

À mon avis, le C++ est un langage complexe et seuls des développeurs déjà un peu expérimentés avec d'autres langages devraient se lancer dans son apprentissage. Pour un premier langage, Python ou Go me semblent plus pertinents : ils permettent de faire beaucoup de choses avec moins de complexité que le C++.

Après, est-ce que j'irais recommander C++ pour des développeurs avancés ? Ça dépend. Déjà, il y a de fortes chances que ces développeurs soient suffisamment matures pour se passer de mes conseils ;-) Mais ça dépend surtout de ce que l'on veut faire avec. C++, bien maitrisé et avec une bonne connaissance informatique bas-niveau, reste le langage de prédilection quand les performances passent en premier. Mais Rust monte petit à petit en puissance et est déjà plus intéressant que le C++ sur pas mal d'aspects : l'outillage, éviter les problèmes de sécurité dus à la mauvaise gestion de la mémoire, etc.

Je suppose que c'est un doublon de https://linuxfr.org/suivi/422-unprocessable-entity-anti-csrf. Si quelqu'un rencontre à nouveau ce bug, je l'encourage très fortement à laisser un commentaire ici (ou à ouvrir une nouvelle entrée de suivi) pour que je regarde ça.

Au vu de la situation actuelle de liberapay, on ne va pas se lancer là-dedans. Par contre, il est possible de faire des dons à LinuxFr.org en passant par En Vente Libre, comme expliqué sur la page Faire un don.

Cette entrée de suivi a un score de 1, je me permets donc de la faire en invalide car elle ne semble pas intéresser grand monde.

Cette entrée de suivi a un score de 0, je vais la fermer sans rien toucher.

Au vu du score de l'entrée de suivi (0 au moment où j'écris ces lignes), on va effectivement laisser en l'état.

Cf https://linuxfr.org/suivi/services-d-api-pour-weboob