NintendojoFR : Le forum

meduz' a écrit : 17 mars 2021 15:58 Je sais plus si on l'a déjà partagé :

Il y en a un qui a essayé, il a eu des problèmes.
Aux États-Unis un type a acheté la plaque d'immatriculation "NULL" pour le fun.
Un an plus tard il s'est mis à recevoir tous les PVs de véhicules non identifiés, pour des infractions datant parfois d'avant son achat.

Le poussin a écrit : 20 mars 2021 02:55 Il y en a un qui a essayé, il a eu des problèmes.
Aux États-Unis un type a acheté la plaque d'immatriculation "NULL" pour le fun.
Un an plus tard il s'est mis à recevoir tous les PVs de véhicules non identifiés, pour des infractions datant parfois d'avant son achat.

Sinon : https://www.journaldunet.com/web-tech/c ... urg200321/

#FrenchTech xD

Je suis obligé de faire du Python au taf

L’absence de contrôle sur les erreurs, la gestion des dépendances, etc… quel putain de langage de normie

Ouaip.
Du coup ça perce.

Python is the new JS

Tu es méchant, c'est quand même moins pire

Même si perso je ne suis pas un grand fan non plus mais bon je fais du cthon aussi donc je ne vais pas trop m'avancer sur le sujet

Mortal a écrit : 23 mars 2021 09:13L’absence de contrôle sur les erreurs

Qu'est-ce que tu appeles par "contrôle sur les erreurs" ? Il y a du typage fort, des exceptions, et la philosophie est de péter quand ça ne va pas plutôt que d'essayer de planquer les problèmes sous le tapis. Tu peux tout intercepter en fonction de tes besoins, pour contrôler ce que tu veux.

la gestion des dépendances

Les problèmes dans la gestion de dépendance vient plus souvent des écosystèmes et des mainteneurs des différents paquets que du langage lui-même.
- pip n'est pas parfait mais je le préfère largement à npm qui, les quelques fois où j'ai dû l'utiliser, ne garantissait même pas que les dépendances précisées étaient installées.
- C++ ne propose rien ; il existe une myriade de solutions concurrentes.
- Rust/cargo est un genre de mélange entre pip et npm : ça marche mais il n'y a pas de partage des dépendances, tout est compilé d'un bloc (statiquement ?) quitte à avoir 10 versions du même code (à compiler autant de fois)... Et si tu as des dépendances en C à compiler, tu te retrouves avec les galères usuelles de version de lib, link, etc. (sous Windows j'en parle même pas).
- PHP, Perl, Ruby ont des équivalents de pip (jamais trop testé, mais je ne doute que ça soit beaucoup mieux).
- Java/C# j'en sais rien.
- Go... même le versionning de protobuf par Google est incompréhensible.

La philosophie de tout péter quand un truc ne leur plait pas est vraiment un des points que j'aime le moins dans ce langage.
Autant c'est une bonne chose pour la cohérence langage strictement parlant, autant c'est juste un enfer pour la maintenance et ça motive à adhérer à une version ce qui pour un langage interprété est un peu dommage.
Ce n'est pas pour rien que les version 2.x ont étés maintenues en parallèle des 3.x pendant autant de temps et que seule la fin du support a forcé les gens à faire l'effort de la migration.

Niveau Rust, le fait de compiler statiquement à notre époque n'est pas spécialement rédhibitoire je trouve. Ce n'est pas comme si on était à quelques Kio prêt de nos jours...
Et celà enlève tellement d'emmerdes de gestion des dépendances que je trouve que c'est une bonne orientation perso.
Pour les dépendances C, même histoire en python si tu t'amuses à wrap du C donc ce n'est pas vraiment un argument je trouve

Façon l'enfer des dépendances c'est un peu ce qui fait que les container c'est si bien au final...

Après comme je le disais plus haut je suis loin d'être un expert en python donc je ne m'avancerais pas trop sur le langage en lui même.
Ce qui m'énerve le plus là dessus c'est des trucs débiles de fanboy de typage statique, de { et ; :drinking:

Golden cube a écrit : 23 mars 2021 22:59 Ce qui m'énerve le plus là dessus c'est des trucs débiles de fanboy de typage statique, de { et ;

COPAIN !
Je ne conçois même pas qu'on puisse faire une formation d'info sans jamais entendre parler de types (ouep, ça existe).
Du coup tu te retrouves avec dans les pattes des gens qui ne comprennent rien quand on leur donne une doc sur des règles de codage où dès qu'ils voient passer un pointeur ^^'

Golden cube a écrit : 23 mars 2021 22:59La philosophie de tout péter quand un truc ne leur plait pas est vraiment un des points que j'aime le moins dans ce langage.

Il y a eu le passage de Python2 à Python3 qui a été très mal géré. Mais en dehors de ce cas isolé très particulier, les cassages de compatibilités du langage et de sa lib standard sont assez rares, portent sur des éléments assez marginaux, et sont d'abord dépréciés pendant plusieurs versions. À part le C, je n'ai jamais vu de langage assurant une backward compatibilité forte (même le C++ qui y tient pourtant beaucoup a fait des concessions). En général c'est du niveau de Python : on évite, avec passage par une phase de dépréciation, avec parfois une version qui casse plus que d'habitude.

Là encore, le passage Python2 vers 3 est un cas très particulier ; il y a une retrospective du créateur de Python qui explique bien les problèmes. Leur erreur a été de penser que la transition serait rapide et que les utilisateurs migreraient rapidement vers Python 3. Ils ont clairement sous-estimé l'inertie, grave erreur...
Fun facts : les autres langages de script qui ont essayé n'ont pas fait mieux. Le projet Perl 6 s'est complétement enlisé et a même fini par forker (en Raku), après plus de 15 ans ! Le projet d'ajouter à PHP le support de l'unicode (un des gros enjeux de Python3) s'est soldé par un échec : après 5 ans, PHP 6 a été abandonné ; conclusion : on est en 2021 et il n'est toujours impossible de gérer correctement du texte en PHP (ironique pour un "hypertext processor").

Niveau Rust, le fait de compiler statiquement à notre époque n'est pas spécialement rédhibitoire je trouve. Ce n'est pas comme si on était à quelques Kio prêt de nos jours...

Quelques Kio pour des petits programmes... mais quand tu as des grosses applications ça peut vite faire beaucoup ; pour de l'embarqué c'est plus problématique. Et il y a aussi (surtout ?) le temps de compilation qui s'en trouve rallongé.
Je pense aussi que tout grouper est une bonne idée, c'est d'ailleurs comme ça que tu es obligé de fonctionner sous Windows (chaque programme arrive avec ses DLLs pour ne pas avoir de problèmes). N'empêche que ça n'est pas pour autant la solution parfaite, ça reste un compromis, probablement le meilleur pour les cas usuels.

Ce qui m'énerve le plus là dessus c'est des trucs débiles de fanboy de typage statique

Pour ce qui est du typage statique, les langages dynamiques travaillent sérieusement à fournir des alternatives, parce qu'il y a une réelle demamnde des développeurs, pour la maintenabilité. Que ça soit PHP, Python ou même JS (via TypeScript), le typage reste dynamique (parce que c'est tout de même pratique pour un langage de script), mais tu peux fournir une information qui sera vérifiée au runtime, ou alors par les outils de dev (linter, IDE, ...). Si les outils suivent, je trouve que c'est un bon compromis.

Le temps de compilation avec les machines actuelles franchement je ne pense pas que ce soit vraiment problématique.
Mon utilisation de Rust reste assez marginale mais j'imagine que dans tous les cas la chaine de compilation ne s'amuse pas à tout recompiler à chaque fois.
Du coup je ne pense pas que cela soit trop méchant quand tu développes dessus de manière régulière.
Pour la génération from scratch de toute façon sur les grosses applications le temps de compilation n'est pas vraiment ce qui coute le plus de temps dans la génération d'une distribution.

Pour Windows tu peux quand même être emmerdé avec les libs système (et là, oh boy) même si c'est vrai que la gestion des dépendance est beaucoup plus "simple" que sur Linux vu qu'elle est extrêmement primitive.

Pour les surcouches de typage statique sur des langages à typage dynamique je suis moyennement fan.
J'ai un peu l'impression que c'est des rustines pour cacher de mauvais choix technologiques.
Le typage dynamique est très pratique dans certains cas d'utilisation et le statique dans d'autres.
Souvent on fait le choix de rester sur la mauvaise technologie par facilité ou ignorance, ce n'est pas vraiment au langage de s'adapter à la connerie de ses utilisateurs je trouve.
Sans parler que les notions de typage sont souvent assez floues dans la tête de pas mal de développeurs.

Après c'est vrai que les langages à typage dynamique étant relativement en vogue pas étonnant que la demande doit soit forte pour ce genre d'outils.

Le poussin a écrit : 23 mars 2021 19:24
Mortal a écrit : 23 mars 2021 09:13L’absence de contrôle sur les erreurs
Qu'est-ce que tu appeles par "contrôle sur les erreurs" ? Il y a du typage fort, des exceptions, et la philosophie est de péter quand ça ne va pas plutôt que d'essayer de planquer les problèmes sous le tapis. Tu peux tout intercepter en fonction de tes besoins, pour contrôler ce que tu veux.

Le typage fort, je vois pas comment on le fait et faire des blocs try/except imbriqués, c’est le cauchemar quand tu compares au vulgaire ? de Rust où tu renvoies quand y’a besoin de renvoyer et tu gères ça dans les fonctions appelantes.

Les try/catch, c’est vraiment des méthodes archaïques avec lesquelles j’ai de plus en plus de mal. Une fois que tu as goûté au Result<>/Option<>, c’est compliqué de revenir en arrière.

Le poussin a écrit : 23 mars 2021 19:24
la gestion des dépendances
Les problèmes dans la gestion de dépendance vient plus souvent des écosystèmes et des mainteneurs des différents paquets que du langage lui-même.
- pip n'est pas parfait mais je le préfère largement à npm qui, les quelques fois où j'ai dû l'utiliser, ne garantissait même pas que les dépendances précisées étaient installées.
- C++ ne propose rien ; il existe une myriade de solutions concurrentes.
- Rust/cargo est un genre de mélange entre pip et npm : ça marche mais il n'y a pas de partage des dépendances, tout est compilé d'un bloc (statiquement ?) quitte à avoir 10 versions du même code (à compiler autant de fois)... Et si tu as des dépendances en C à compiler, tu te retrouves avec les galères usuelles de version de lib, link, etc. (sous Windows j'en parle même pas).
- PHP, Perl, Ruby ont des équivalents de pip (jamais trop testé, mais je ne doute que ça soit beaucoup mieux).
- Java/C# j'en sais rien.
- Go... même le versionning de protobuf par Google est incompréhensible.

Et on parle de poetry ? Pipx ? Setuptools ? Ou la combo de tout ça ?

C’est pas tellement pip (ou ses potes) qui est une purge (me suis mal exprimé, finalement, il fait son boulot), c’est tout le bordel qu’on a ajouté derrière (

virtualenv) pour arriver à faire un truc qui marche. Quand tu n’as qu’un seul programme en Python qui tourne, ça va. Si tu en as plusieurs, à un moment, t’es pratiquement obligé d’avoir un venv par appli

Donc peut-être que c’est simple pour le développeur, mais pour le couillon de sysadmin qui doit se débrouiller pour déployer et maintenir tout ce bordel, c’est l’angoisse totale

(et ne venez pas me dire que la solution, c’est Docker hein… rajouter une couche de complexité sur un truc déjà complexe, ça ne fait que déporter les emmerdes, pas les régler).

De ce point de vue, je trouve que Go ou Rust avec leur compilation statique ont un ÉNORME avantage : une fois que ça compile pour tes archi cibles, tu sais que ça fonctionnera quoiqu’il arrive. Et franchement, le temps de compilation de Rust, c’est peanuts par rapport au confort que tu gagnes derrière. Donc certes, tout est compilé statiquement, certes, c’est un peu le merdier dans l’exé quand t’as effectivement 10 versions différentes de la même librairie, mais au final, ça s’exécute toujours 1000 fois plus vite que du Python, ça ne casse pas en cours de route et ça se déploie facilement.

Finalement, le seul vrai défaut d’un Go/Rust, c’est que tu ne peux pas corriger un machin vite fait comme ça en le patchant à la volée. Ta CI devient vraiment capitale pour arriver à faire un truc. Mais de nos jours, qui peut dire que sa CI il s’en tape de toutes manières ?

EDIT: side note, le poids des exécutables Rust quand tu le compares à l’exécutable Python + tout son venv, ça fait vraiment rigoler derrière

Mortal a écrit : 24 mars 2021 09:55
Le poussin a écrit : 23 mars 2021 19:24
Mortal a écrit : 23 mars 2021 09:13L’absence de contrôle sur les erreurs
Qu'est-ce que tu appeles par "contrôle sur les erreurs" ? Il y a du typage fort, des exceptions, et la philosophie est de péter quand ça ne va pas plutôt que d'essayer de planquer les problèmes sous le tapis. Tu peux tout intercepter en fonction de tes besoins, pour contrôler ce que tu veux.
Le typage fort, je vois pas comment on le fait et faire des blocs try/except imbriqués, c’est le cauchemar quand tu compares au vulgaire ? de Rust où tu renvoies quand y’a besoin de renvoyer et tu gères ça dans les fonctions appelantes.

Les try/catch, c’est vraiment des méthodes archaïques avec lesquelles j’ai de plus en plus de mal. Une fois que tu as goûté au Result<>/Option<>, c’est compliqué de revenir en arrière.

Je ne sais pas gérer les erreurs inattendus autrement que par try/catch d'exceptions. Quelle est cette sorcellerie de "Result<Option>" ?

De mon coté tout ce que je peux dire, c'est que (quasiment) tout notre scripting est fait en python et que c'est un "framework technique" assez raisonnable pour une équipe de non-développeurs, sachant qu'on en garde la maintenance. Après c'est aussi parce que la majeur partie du code consiste juste à créer des méthodes qui seront facilement appelables, par contre dès qu'il faut débug un peu plus profondément il n'y a plus grand monde...

nazlurf a écrit : 24 mars 2021 10:28 Je ne sais pas gérer les erreurs inattendus autrement que par try/catch d'exceptions. Quelle est cette sorcellerie de "Result<Option>" ?

Result<T, E> et Option<T> sont des smartpointers. En gros Result<T, E> contient soit un type (Ok(T)) soit une erreur (Err(E)) et y’a plein de fonctions permettant de décapsuler ça intelligemment.

Donc pour faire de la gestion d’erreur, il suffit d’avoir une fonction qui renvoie un Result<T, E> (en précisant T et E bien évidemment) et d’utiliser l’opérateur ? (opérateur qui est en gros l’équivalent de : si la fonction appelée renvoie Ok(T), je décapsule le T, si la fonction renvoie un Err(E), je return immédiatement le E en question).

Du coup, ça te permet de faire du code de ce type :

Code : Tout sélectionner

fn cache_media(u: &str, t: &str) -> Result<String, Error> {
    // create dir
    if !Path::new(t).is_dir() {
        create_dir_all(t)?;
    }

    // get file
    let client = Client::new();
    let mut response = client.get(u).send()?;

    // create local file
[…]
    let mut dest_file = File::create(&dest_filepath)?;

    copy(&mut response, &mut dest_file)?;

    Ok(dest_filepath)
}

Chaque fois que tu vois un ?, c’est une fonction qui renvoie un Result<T, E> et qui peut donc interrompre l’exécution de la fonction en cours et lui permettre de renvoyer Err(E). Et du coup, c’est la fonction appelante qui a le contrôle complet : elle peut décider que l’erreur est grave et paniquer ou décider que l’erreur est récupérable et brancher autre chose. Et évidemment, tu peux aussi avoir du contrôle en local en n’utilisant pas ? mais en gérant directement le Result<T, E>.

Comment tu sais si tu reçois T ou E ?

Je crois que le .net a une gestion équivalente des exceptions dans les Tasks (appels asynchrones), où tu reçois soit le résultat du "return" de la Task, soit l'exception qui a été levée. Mais dans l'objet retourné par la Task, tu as 2 propriétés (en plus d'autres choses bien sûr), où l'une est forcément null et l'autre pas, ce qui permet de savoir si une exception a eu lieu ou si ça s'est bien fini.

nazlurf a écrit : 24 mars 2021 18:30 Comment tu sais si tu reçois T ou E ?

Un T est forcément dans un Ok() alors qu’un E est forcément dans un Err(). D’où le renvoi de Ok(T) à la fin de la fonction. Tu peux même renvoyer Ok(()) si tu veux juste dire que ça a marché sans renvoyer quoique ce soit.

Le temps de compilation avec les machines actuelles franchement je ne pense pas que ce soit vraiment problématique.

La compilation en rust est lente, c'est un problème (re)connu par la commuanuté de Rust.
Et même avec les machines actuelles, ça reste un problème. Faire de Go un langage compilé rapidement était d'ailleurs un des objectifs de Google, parce que ça a des effets bénéfiques sur le développement en général (et pas uniquement de rentabiliser le temps des ingénieurs).

Mon utilisation de Rust reste assez marginale mais j'imagine que dans tous les cas la chaine de compilation ne s'amuse pas à tout recompiler à chaque fois.
Du coup je ne pense pas que cela soit trop méchant quand tu développes dessus de manière régulière.

En Rust, l'unité de compilation est la "crate". Il y a des optimisations du compilateur qui peut parfois reconnaître que certains bouts n'ont pas changé, mais ça n'est pas révolutionnaire non plus. Le temps de link est également assez important. Sur un petit projet perso avec du code un peu générique, ça prennait du temps. Tout dépend ce que tu es prêt à accepter bien sûr...

Souvent on fait le choix de rester sur la mauvaise technologie par facilité ou ignorance, ce n'est pas vraiment au langage de s'adapter à la connerie de ses utilisateurs je trouve.

Les informations de type aident à détecter des erreurs humaines, qu'on fait tous. Sachant qu'elles sont facultatives, pourquoi s'en priver ? Elles ont un deuxième rôle très important : elles permettent de mieux documenter les interfaces.
Ça n'est pas une fonctionnalité pour s'adapter aux mauvais développeurs. C'est aussi (surtout ?) plébicité par des développeurs aguerris, qui en voient les avantages. Sachant que le but n'est pas non plus de vouloir en mettre partout. Comme tout, c'est à utiliser à bon escient, quand c'est justifié.

---

Le typage fort, je vois pas comment on le fait

Le typage en Python est fort, c'est un fait. Pour faire court il l'est parce qu'il n'y a pas de conversions implicites de types, ou la possibilité de comparer des choux et des carottes. PHP, Javascript ou le shell ont un typage faible : typiquement, `"42" == 42`.

et faire des blocs try/except imbriqués, c’est le cauchemar quand tu compares au vulgaire ? de Rust où tu renvoies quand y’a besoin de renvoyer et tu gères ça dans les fonctions appelantes.

Là où tu utilises `?` en Rust, tu peux juste laisser l'exception, c'est l'équivalent (tu "forwardes" l'erreur sans t'y intéresser ou chercher à la convertir).
Si tu veux tester/vérifier l'erreur, tu fais un try/except en Python et un match sur le type d'erreur en Rust, c'est kif-kif.
Au passage, la gestion d'erreur en Rust est... peu claire. Il n'y a pas de consensus sur les bonnes pratiques (j'ai cru lire qu'un groupe allait se former pour répondre au besoin), définir ses erreurs est assez lourd, ... Mais le langage est jeune, il faut le temps que ça se mette en place.

C’est pas tellement pip (ou ses potes) qui est une purge (me suis mal exprimé, finalement, il fait son boulot), c’est tout le bordel qu’on a ajouté derrière

Ok, je comprends mieux ton point.

C'est plus un problème d'écosystème que j'évoquais dans mon premier post, qu'un problème du langage en lui-même. Je n'ai jamais utilisé poetry/pipx mais je vois le genre, et oui c'est chiant.

Pour les venv, si tu veux être tranquille il te faut effectivement un venv (ou docker) par appli. C'est ce vers quoi tout le monde s'oriente (y compris Rust, en compilant tout en statique).

Je pense que les besoins ne sont pas les mêmes. Tu as clairement plus des besoins de sys-admin là où j'ai surtout des besoins de développeur qui travaille en local, sans avoir à déployer sur N serveurs. Pas les mêmes besoins, pas les mêmes problèmes, pas les mêmes solutions. Et clairement, la partie sysadmin/devops je ne la connais pas assez pour donner un avis pertinent.

Le poussin a écrit : 24 mars 2021 20:13
Le temps de compilation avec les machines actuelles franchement je ne pense pas que ce soit vraiment problématique.
La compilation en rust est lente, c'est un problème (re)connu par la commuanuté de Rust.
Et même avec les machines actuelles, ça reste un problème. Faire de Go un langage compilé rapidement était d'ailleurs un des objectifs de Google, parce que ça a des effets bénéfiques sur le développement en général (et pas uniquement de rentabiliser le temps des ingénieurs).

Je te crois volontiers j'ai juste fait quelques merdouilles dessus pour tester rapidement.

Le poussin a écrit : 24 mars 2021 20:13
Mon utilisation de Rust reste assez marginale mais j'imagine que dans tous les cas la chaine de compilation ne s'amuse pas à tout recompiler à chaque fois.
Du coup je ne pense pas que cela soit trop méchant quand tu développes dessus de manière régulière.
En Rust, l'unité de compilation est la "crate". Il y a des optimisations du compilateur qui peut parfois reconnaître que certains bouts n'ont pas changé, mais ça n'est pas révolutionnaire non plus. Le temps de link est également assez important. Sur un petit projet perso avec du code un peu générique, ça prennait du temps. Tout dépend ce que tu es prêt à accepter bien sûr...

Ah... c'est pas foufou en effet

Le poussin a écrit : 24 mars 2021 20:13
Souvent on fait le choix de rester sur la mauvaise technologie par facilité ou ignorance, ce n'est pas vraiment au langage de s'adapter à la connerie de ses utilisateurs je trouve.
Les informations de type aident à détecter des erreurs humaines, qu'on fait tous. Sachant qu'elles sont facultatives, pourquoi s'en priver ? Elles ont un deuxième rôle très important : elles permettent de mieux documenter les interfaces.
Ça n'est pas une fonctionnalité pour s'adapter aux mauvais développeurs. C'est aussi (surtout ?) plébicité par des développeurs aguerris, qui en voient les avantages. Sachant que le but n'est pas non plus de vouloir en mettre partout. Comme tout, c'est à utiliser à bon escient, quand c'est justifié.

Là je dirais que ça dépend des approches. Quand je commence à me rendre compte qu'il me faut des surcouches sur la technologie que j'utilise (langage, protocole, etc) pour que ce soit fonctionnel et maintenable je me dis que je ne suis peut être pas parti sur la bonne architecture.
Par exemple, j'ai des devs dans ma boite plutôt pas mauvais dans leur domaine mais avec un adhérence forte à une technologie en particulier.
Ils sont capables de faire des trucs assez crétins comme par exemple faire un programme one shot pour parser un fichier en C-- ou un module d'acquisition protocolaire pour du modbus série pour de l'embarqué en python.
Oui tu peux le faire, mais bon est ce que c'était la bonne approche pas sur...

Le poussin a écrit : 24 mars 2021 20:13
Le typage fort, je vois pas comment on le fait
Le typage en Python est fort, c'est un fait. Pour faire court il l'est parce qu'il n'y a pas de conversions implicites de types, ou la possibilité de comparer des choux et des carottes. PHP, Javascript ou le shell ont un typage faible : typiquement, `"42" == 42`.

Je rajouterais la famille C dans le pot des langages faiblement typés

Le poussin a écrit : 24 mars 2021 20:13
et faire des blocs try/except imbriqués, c’est le cauchemar quand tu compares au vulgaire ? de Rust où tu renvoies quand y’a besoin de renvoyer et tu gères ça dans les fonctions appelantes.
Là où tu utilises `?` en Rust, tu peux juste laisser l'exception, c'est l'équivalent (tu "forwardes" l'erreur sans t'y intéresser ou chercher à la convertir).
Si tu veux tester/vérifier l'erreur, tu fais un try/except en Python et un match sur le type d'erreur en Rust, c'est kif-kif.
Au passage, la gestion d'erreur en Rust est... peu claire. Il n'y a pas de consensus sur les bonnes pratiques (j'ai cru lire qu'un groupe allait se former pour répondre au besoin), définir ses erreurs est assez lourd, ... Mais le langage est jeune, il faut le temps que ça se mette en place.

Pareil, j'ai l'impression que c'est la fusion de la remontée d'erreur par code fonction du C et les exceptions. C'est peut être génial à l'usage mais je n'ai pas assez pratiqué la chose pour avoir l'illumination.

Mortal a écrit : 24 mars 2021 18:57
nazlurf a écrit : 24 mars 2021 18:30 Comment tu sais si tu reçois T ou E ?
Un T est forcément dans un Ok() alors qu’un E est forcément dans un Err(). D’où le renvoi de Ok(T) à la fin de la fonction. Tu peux même renvoyer Ok(()) si tu veux juste dire que ça a marché sans renvoyer quoique ce soit.

ça j'avais saisi ... j'ai pas compris comment, à l'utilisation de la méthode, tu sais s'il y a eu erreur ou pas. t'as que montré des appels où osef, si exception il y a, renvoie là à la couche du dessus.

Si tu veux gérer ça finement, tu peux bêtement le mettre dans un match ou utiliser une fonction valide sur le Smart Pointers Result. Deux exemples pris dans Scootaloo :

Code : Tout sélectionner

// get user timeline feed (Vec<tweet>)
let mut feed = get_user_timeline(&config, token, last_tweet_id).unwrap_or_else(|e|
    panic!("Something went wrong when trying to retrieve {}’s timeline: {}", &config.twitter.username, e)
);

Là, au lieu de décapsuler le résultat directement avec ?, j’utilise unwrap_or_else (j’aurais aussi pu utilisé unwrap_or) qui me permet de dire directement : si c’est bon, tu décapsules, sinon, tu exécutes ce qu’il y a dans la chaîne d’après (et en l’occurence, comme je ne peux rien faire sans cette fonction, bah je préfère paniquer et arrêter le programme).

Code : Tout sélectionner

// build basic status by just yielding text and dereferencing contained urls
let mut status_text = match build_basic_status(tweet) {
    Ok(t) => t,
    Err(e) => {
        println!("Could not create status from tweet {}: {}", tweet.id ,e);
        continue;
    },
};

Là, c’est un exemple avec une structure match : basiquement match te force à spécifier tous les résultats possibles d’un Smart Pointers ou d’une énumération. Donc je lui dis simplement : si tu vois que c’est Ok(), tu renvoies ce qu’il y a dans le T, si tu vois que c’est Err(), tu affiches un message à logguer à l’écran et tu fais autres choses (en l’occurence, on passe juste à l’item suivant dans la boucle). J’aurais évidemment pu appliquer un traitement supplémentaire en cas de Ok() ou carrément repartir sur autre chose. Pareil pour le Err() : je pourrais très bien derrière matcher sur le type d’erreur (avec un autre match) et essayer de corriger ou logguer plus précisément ce qui s’est mal passé.

merci pour les explications.

et donc, quelque soit le cas, tu exécutes nécessairement l'instruction suivante. Donc plus besoin d'un bloc finally ? Je sais pas si ça se retrouve dans d'autres langages, mais en C#, en plus du try/catch, tu peux ajouter un bloc finally qui, quoiqu'il arrive, s'exécute dans tous les cas. ça permet notamment de libérer les ressources non managées, fermer proprement les connexions aux bases de données qui auraient été ouvertes dans le bloc try, ...

j'ai l'impression que c'est la fusion de la remontée d'erreur par code fonction du C et les exceptions

Sous le capot c'est uniquement de la remontée de code d'erreur, mais typée, ce qui permet d'avoir un fonctionnement homogène.
Le `?` te permet de remonter l'erreur à l'appelant, et donc peut faire penser aux exceptions qui remontent la pile d'appel. Néanmoins il y a une différence fondamentale (et qui rejoint le point de nazlurf), et est probablement au cœur des nombreuses différences d'opinion sur le sujet (notamment en C++).

Le `Result` de Rust est le type de retour de la fonction et fait donc partie de son prototype. Et l'erreur elle-même est typée (même si tu peux aussi accepter un pointeur vers une implémentation opaque).

Les exceptions ne font pas partie du prototype (~~sauf exception~~ en général) et peuvent surgir de n'importe où. En Python tu peux/dois t'attendre à pouvoir te prendre une exception de n'importe quel type venant de n'importe quelle fonction. La philosophie est de throw ce qui t'arrange quand ça t'arrange, et l'appelant intercepte s'il en a besoin. C++ avait une manière de pouvoir énumérer les exceptions pouvant être throw par une fonction mais c'était bancal et n'a jamais pris (la fonctionnalité a d'ailleurs été retirée).

Rust se veut explicite pour éviter les mauvaises surprises : pas de cast implicites, pas de copie coûteuses implicites, pas de polymorphisme, ... Il était logique d'utiliser une gestion d'erreur explicite (plutôt que des exceptions), où chaque fonction indique si elle peut retourner une erreur.
D'ailleurs, si tu appelles une fonction qui retourne un `Result` mais que tu ignores son résultat (et donc potentiellement une erreur), tu auras un warning.

Donc plus besoin d'un bloc finally ?

Rust utilise l'idiome RAII (Resource Acquisition Is Initialization), qui veut qu'une variable est détruite (avec appel du destructeur) quand elle sort du scope.
En général, tu n'as donc pas besoin d'un finally. Et au besoin ça s'implémente assez facilement via un objet bidon dont le destructeur appelle une fonction donnée. La crate scopeguard fait ça, et ici tu peux voir une implémentation minimale.
Le RAII fonctionne bien pour des langages sans garbage collector, pour lesquels la durée de vie des variables est gérée par la pile (sauf allocations dynamiques bien sûr). C'est d'ailleurs la même chose en C++ : il y a un try/catch mais pas de finally.

NintendojoFR : Le forum

Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd:

Re: Le coin des codeurs :nerd: