Boiethios a écrit 129 commentaires

Pareil pour Haskell. C'est juste LA référence des langages fonctionels.

Toute l'extrême-droite israélienne pousse à la guerre avec l'Iran depuis bien avant Trump… Maintenant qu'ils ont un président suffisamment complaisant, ou pour je ne sais quelle raison géo-stratégique, ils avancent leurs pions.

Ce n'est pas pour défendre Trump, mais de toute évidence, il n'est qu'un exécutant. On assiste à un n-ième acte de la guerre américano-sioniste contre les pays "arabes", après l'Irak, l'Afghanistan, la Syrie, etc.

nil n'est pas du tout équivalent à unwrap en Rust. Dans un cas, on peut avoir un panic sans le savoir (on croit avoir un objet valide, mais pas de chance, c'est un nil), dans l'autre cas, on a un type Result qu'on peut choisir d'ignorer explicitement (ce qu'on ne fait pas dans un code en production, normalement).

De plus, ce n'est pas parce qu'on peut passer nil comme paramètre de méthode qu'il est typé. Un nil dans ce genre de langage n'est pas typé, puisque rien de distingue un nil d'un autre, si je puis m'exprimer ainsi. En revance, en Rust, pour garder cet exemple, un None a un type qui est Option<T>, donc un Foo "nul" et un Bar "nul" n'ont pas le même type: Option<Foo>::None vs Option<Bar>::None. Le fait d'avoir des références nulles fait qu'il y a un typage faible localement.

Pour avoir utilisé les 2 types de gestion d'erreur, je fais tout pour éviter les langages avec référence nulle qui obligent à vérifier tout le temps qu'on a bien un objet valide.

C'est le premier truc que je regarde: y a-t-il de références nulles ? Malheureusement, c'est le cas dans ce langage. En fait, après avoir jeté un coup d’œil, j'ai du mal à voir ce qu'il propose de neuf. Pas de types algébriques, des références nulles… je ne vois pas où est la "joie de programmer".

J'ai une NVidia sur mon fixe avec le pilote propriétaire (ouh le vilain) et ça va, j'ai survécu à cette blague ;)

Je ne connais pas le Vala, et je n'ai pas trop envie de m'y mettre. Je préfère utiliser un langage que je connais bien.

De plus, s'il y a des problèmes de blocage, je pense que c'est toute l'architecture qui est à revoir. Si je pars sur une organisation totalement asynchrone dès le départ, je n'aurai pas ce genre de problèmes.

La dernière fois que je l'ai utilisé, il était affreusement beugué, et il manquait des fonctionnalités dont j'avais besoin.

Merci pour la réponse !

Alors, oui, il existe déjà des clients mails, mais aucun à ma convenance. Le plus proche de mes goûts est Geary, mais il a un défaut rédhibitoire, c'est qu'il n'est pas asynchrone. Quand il y a une erreur de connexion, il bloque l'interface en tentant de se reconnecter. Il a aussi des fonctionnalités manquantes qui vraisemblablement ne seront pas ajoutées, comme le fait de ne pas avoir une adresse d'envoi par défaut.

Peut-être qu'il existe déjà un client à mon goût, mais je n'ai pas trouvé ce que je cherche (et pourtant j'en ai testé beaucoup), à savoir :

• un client intégré aux dernières versions de Gnome-Shell, c'est-à-dire avec l'interface GTK-3, les notifications, etc.
• qui utilise les comptes en ligne de GNOME: je ne veux pas tout reconfigurer pour chaque changement,
• avec une interface légère, qui ne fasse pas "usine à gaz",
• qui permette de gérer facilement les dossiers,
• qui permette de configurer de manière fine les adresses d'envoi.

Pour les daemons, c'est noté.

Je code mon client en Rust, donc je suppose que je vais me tourner vers:

• pour la réception: tokio-imap
• pour l'envoi: mail qui utilise new-tokio-smtp

Ça me fera beaucoup de choses à faire à la main, du coup si quelqu'un a une autre idée, je suis toujours preneur.

Au passage, si quelqu'un est intéressé par mon binding de libgoa en Rust, c'est ici : https://gitlab.com/Boiethios/goa-rs/. Pour le moment, je ne gère que les courriels, mais on peut ajouter des fonctionnalités maintenant que le squelette est fait.

Pour 1 + 2, le mieux c'est d'avoir le choix, comme avec Rust:

• si on utilise l'opérateur +, c'est qu'on s'en fiche du comportement de l'overflow, et le comportement va dépendre de la machine,

• si on veut un comportement spécifique, on a tout un tas de méthodes:

  • https://doc.rust-lang.org/std/primitive.usize.html#method.checked_add
  • https://doc.rust-lang.org/std/primitive.usize.html#method.overflowing_add
  • https://doc.rust-lang.org/std/primitive.usize.html#method.saturating_add
  • https://doc.rust-lang.org/std/primitive.usize.html#method.wrapping_add

Le langage supporte les "sum types": pourquoi avoir mis des exceptions au lieu du Maybe de Haskell ou Option de Rust?

On en est arrivé à un tel point qu'il y a maintenant un marché pour pouvoir récupérer ses propres données sur ses propres serveurs.

J'ai du mal à voir la différence entre les rançongiciels et les éditeurs qui demandent de payer si on veut récupérer ses données dans un format exploitable.

Pour les allergiques à l'angliche:

Laisser la plus grande boîte de publicité au monde avoir le navigateur Web le plus populaire est à peu près aussi intelligent que de laisser des enfants gérer un magasin de bonbons.

Je ne suis pas sûr. Les États sont dépendants de l'argent, et qui détient l'argent ? CQFD.

On est en 2019, avec le CSS3, HTML5, etc. et certains développeurs (de grosses boîtes en plus) ne sont pas fichus de faire une application web avec une interface de tablette pour les tablettes, et une interface de PC pour les PCs.

N'importe quel frèmouorque permet de faire ça en 3 lignes en plus…

C'est vraiment le strict minimum. Là où je bosse, ils ont surtout des prestataires, c'est dans les 12k€ par mois pour un développeur. C'est clair qu'une mise-à-jour du matériel est moins chère.

Si tu veux bosser dans les moteurs de jeux AAA, je penses que le C++ est un passage obligé.

Pour moi, ça prouve surtout que la bibliothèque standard ne satisfait pas les développeurs C++.

Il faut passer pas mal de temps à faire du Rust avant d'être efficace, mais je trouve qu'on code très rapidement. Moins qu'en Python, ceci dit. Le grand avantage, c'est qu'on n'a pas d'erreur au runtime, donc on gagne du temps là-dessus.

Le client est souvent prêt à perdre quelques millisecondes de CPU à la requête contre quelques mois de développement.

D'après mon expérience dans le monde professionnel, c'est généralement le cas. A part mon stage de fin d'étude qui était dans un domaine bien spécifique (la robotique), je n'ai jamais rencontré de client pour qui la performance était primordiale. Ils veulent tous un code qui fonctionne, avec des retours les plus nombreux et les plus rapides possibles. Si c'est (vraiment) trop lent, on change de matériel, et c'est bon.

On peut regretter cet état des faits, mais dans le monde réel, c'est très souvent comme ça.

Pareil pour moi, j'ai fait du C++ pendant quelques années, et puis j'ai fini par être dégoûté par la qualité des bases de code existantes, la complexité du langage, toujours prêt à se retourner contre le développeur. La dernière chose qui a achevé de me détourner du C++, c'est le prix d'un développeur C++ sur le marché qui n'est pas du tout en corrélation avec la difficulté de la techno.

Du coup, je me suis mis au C# (c'est très facile quand on vient du C++). J'en fait depuis 2/3 ans professionnellement. En parallèle, je me suis mis au Rust. J'ai maintenant un bon niveau, et je suis prêt à partir sur ma première expérience professionnelle dans ce langage (les premiers entretiens se passent bien) :)

En résumé, tout peut aller très vite : il faut juste se lancer et montrer qu'on en veut et qu'on apprend vite pendant les entretiens.

Et pourquoi le ton est-il (relativement) agressif ?

Le texte ne précise pas s'ils ont essayé de régler ça à l'amiable avant.

J'utilise Signal, d'ailleurs après en avoir entendu parler sur ce site.

J'ai cru au poisson, mais la phrase "Il s'agirait notamment du support de xkbcomp sous Wayland afin de pouvoir appuyer sur F2 pour cacher les fenêtres IRC quand son boss arrive." m'a convaincu du contraire. Je pense que c'est une fonctionnalité longtemps attendue en entreprise (en tout cas c'est mon cas), et donc IBM s'adapte tout simplement au marché.

Site