Je n’ai pas encore décrit Rust sur mon blog. Rust est un langage de programmation (non je ne parlerais jamais du jeu du même nom.) qui vise à fournir un écosystème et des fonctionnalitées qu’on rencontre fréquement dans les langages de haut niveau. Ça c’est si on vient de langages de bas niveau. Si on vient des langages de script/haut niveau, Rust vise à offrir la vitesse d’exécution des langages de bas niveau tout en gardant l’ecosystème si chère à ces langages (npm, pip, …).
Après cette introduction rapide à Rust, je préviens tout de suite que j’apprends Rust depuis l’été dernier en lisant "le livre" (en anglais). Je suis en train de créer une crate qui n’est pas loin d’être publiée… quand je trouverais la motivation de le faire 😅.
J’ai un peu regardé comment utiliser async/await
dans d’autres langages mais je n’ai jamais utilisé cette syntaxe moi même. Je n’ai donc pas d’opinion forte sur celle proposé par l’équipe du langage, je me base dessus.
Donc, pour revenir au sujet de ce billet : l’équipe du langage de Rust a proposé d’introduire une nouvelle syntaxe pour le prochain mot-clé await
. Ils ont choisis la syntax dot await
comme ils l’appellent.
Même si je suis plus habitué à des syntaxes en préfixe (match {}
, if {}
, …) qu’en suffixe, je ne pense pas être compétent pour juger ce débat.
Je ne pense pas que la syntaxe dot keyword
sois parfaite tel quel. Biensûr, si on compare cette écriture à celle des méthodes c’est une version sans parenthèses, et pourquoi pas. Mais dans le même temps c’est exactement la syntax pour accéder à une propriété. Si une fonction retourne une structure : fn get_toto -> struct
, je peux vouloir récupérer seulement une de ses propriété comme get_toto().titi
… et ça ressemble trop à la notation dot await
. Ce n’est peut être pas la façon idiomatique de procéder, mais j’ai déjà bidouillé du JS comme cela.
Pendant ma lecture de l’article j’ai pensé à utiliser la syntaxe commas await
: toto(),await
mais il se peux que ce ne soit ni pratique, ni fesable puisque la virgule est déjà utilisée pour séparer les arguments, même sans espace.
J’aime l’idée de réserver le !
pour tout ce qu’on peux considérer comme magique dans le langage. Lorsqu’on à besoin de faire quelque chose mais un peu d’aide (du compilateur ?) magique est nécéssaire :
macro!()
.!modifiers
ou plus généralement !keywords
..keyMethods!()
ou !keyMethods()
un jour.Pendant que j’y suis, s’il vous plait, ne créez pas !match
ni aucune structure de contrôle avec cette syntaxe. Gardez cette écriture exclusivement sans arguments. Vous voulez introduire !await
comme mot-clé puiqu’on ne pourrait pas créer cette fonctionnalité comme fonction/macro/méthode. Alors restez sur votre intention : un mot-clé n’a pas de paramètres. Peut-être qu’on pourrait créer !loop
pour transformer une fonction en boucle infinie voir !panic
ou !unwrap
si on en éprouve le besoin pour… quelque chose. Mais je ne suis même pas sur que je le veuille vraiment.
Si vous voulez que l’un des prochains mot-clé ai des paramètres, alors je préfèrereais que vous utilisiez l’une de mes propositions de méthode et ainsi pouvoir mettre les arguments entre parenthèses. Comme cela l’écriture en suffixe des mot-clés gérés par le compilateur restera constant avec ou sans paramètres.
Pour éviter de vous faire créer un compte juste pour commenter mon blog, je vous invite à commenter cet article sur son annonce dans le Fédiverse, Reddit /r/rust (en anglais).
J’ai créé ce blog pour parler de technologies et de jeux vidéo qui valent le coup.
Je suis devenu développeur car je suis passionné de technologie. Il peut donc m’arriver de parler de langages de programmation, gadgets, astuces, et logiciel libres. Dans une moindre mesure je pourrai faire des didacticiels, mais je pense plutôt créer une plusieurs pages d’aide mémoire ou astuces sur des commandes et logiciels que j’utilise.
J’aime beaucoup découvrir et jouer à des jeux vidéo. J’en stream d’ailleurs régulièrement. Lorsqu’il est intéressant de suivre l’histoire, je garde les enregistrements et les diffuses sur Peertube et YouTube.
Je précise tout de suite : je ne suis pas journaliste et n’ai aucun intérêt à présenter des jeux qui ne me plaisent pas. Je prévois donc de noter les jeux de 1 à 5 🎮, 1🎮 pour un jeux qui m’a plu malgré des lacunes, c’est comme si je lui mettais un 6/10 voir 16/20, les tests me diront. Si jamais il m’arrivait de parler d’un jeux que je n’ai pas apprécié ou que je trouve mauvais, je le noterais sûrement avec un autre symbole, comme des tomates 🍅.
Évidemment cela reste mon espace d’expression, il évoluera donc au fil de mes envies et découvertes. Par exemple, dans la mesure du possible et de la météo je suis vélotaffeur, je pourrais donc vous parler de mes péripéties à vélo sur le chemin du boulot.
Si vous n’aimez pas la technique ou que l’auto-hébergement ne vous intéresse pas, je vous laisse ici. J’espère vous revoir bientôt sur ce blog pour un nouveau billet.
On commence tout de suite avec les choix techniques que j’ai fait pour héberger ce site.
Cela fait déjà plusieurs années que j’utilise Yunohost et c’est un plaisir. On suit le didacticiel et ça « juste marche ». Le choix d’apps est varié et avant d’installer, on peut savoir si l’app est bien intégrée à Yunohost, dans un état fonctionnel et si elle est bien maintenue.
Plusieurs éléments m’ont fait choisir Grav plutôt qu’un autre CMS / moteur de blog, sans ordre particulier :
Alors si vous ne savez pas ce qu’est le Fédiverse ça mériterait un article à lui tout seul… ce n’est donc pas l’endroit pour détailler cela. Sachez juste que c’est un réseau fédéré qui comprends plusieurs types de sites : microblogging (Mastodon/Pleroma), vidéo (Peertube), image (Pixelfed), audio (Funkwhale), blog (Plume/Write freely)… Pour plus d’info je vous recommande cette vidéo faite avec Mastodon en exemple, pour aller plus loin vous pouvez vous référer à ce Wiki d’un hébergeur de services, ou à cette vidéo (en Anglais) d’un utilisateur faisant une démo entre plusieurs sites.
Maintenant que j’ai déjà passé trop de temps à expliquer ce qu’est le Fédiverse, pourquoi j’ai choisis Grav et non pas un moteur de blog fédéré comme Plume ?
J’ai fait ce choix parce que ceux intégrés au Fédiverse ne sont pas encore aussi matures que les autres, ni aussi bien intégrés à Yunohost.
J’ai choisi le template Hypertext pour aller à l’encontre de ce qui se fait aujourd’hui sur Internet. De nos jours, beaucoup de sites utilisent des thèmes compliqués, avec beaucoup de CSS et JavaScript. Ce thème propose de prendre le contre-pied de cette tendance, il parvient à être le plus minimaliste possible, donc moins lourd et plus rapide. C’est ce que promulgue le brutalist design (en Anglais). Avant même de faire ce choix, j’avais décidé de ne pas afficher de commentaires sur ce site mais de mettre un lien vers l’annonce du billet. Pour que vous puissiez commenter avec votre compte du Fédiverse, plutôt que de vous enregistrer sur un énième blog.
Si vous comprennez l’Anglais et que vous voulez rire, je vous conseille ce site satirique et son homologue. Attention le langage est, pour le moins, familier.
Ce point est très simple : je fais parti de l’équipe « thème sombre », mais je suis assez mauvais artistiquement parlant. J’ai donc choisi un site avec un beau thème que j’ai emprunté, en gardant la philosophie minimaliste du template.
Pour éviter de vous faire créer un compte juste pour commenter mon blog, je vous invite à commenter cet article sur son annonce dans le Fédiverse.