Discussion :

[OuftiBoy]

Salut Uther. On est pas obligé d'être d'accord, mais c'est sympa de pouvoir dialoguer/débattre avec toi.

Pour la dixième fois (a peu près) : on ne parle pas de réécrire tout Linux mais de permettre d'écrire de nouveaux drivers en Rust.

Je sais, tu l'as dis 10x, j'ai bien vu passer tes réponses. Mais une fois acccepté pour des drivers isolés, ça évoluera et linux deviendra un mixte de code en C et Rust. Une fois le ver dans le fruit, il le mange. On rentre par une petite porte sur le côté, puis ça s'installe partout. C'est peut-etre le danger que resentent les anciens. C'est une situation qui peu étre mal vécue. Ce n'est peut-être pas l'intention de la communauté Rust, mais c'est un reflexe humain.

Je ne dirais pas que le bloc unsafe retire tant de garanties que ça. Les garanties apportées par Rust restent valides sur la très grande majorité du code. Oui il faut être particulièrement prudent à ce que l'on fait dans les bloc unsafe, mais ils restent normalement exceptionnels et le fait qu'ils soient marqué comme tel, fait qu'on sait où concentrer la relecture.

Oui, dans un monde idéal, ça devrais être le cas, mais la nature humaine étant ce qu'elle est, ce mode "unsafe" sera utilisé plus que nécessaire, volontairement ou pas. Mais je suis d'accord avec toi sur le fait qu'ils "marquent" un code auquel il faut faire attention.

Pour le moment on a en est juste a ajouter des nouveaux drivers expérimentaux, principalement pour du matériel qui tourne sur des machines récentes supportées par le compilateur Rust. Si un jour on veut remplacer les driver C actuels par des drivers en Rust ça deviendrait un problème, mais on y est pas encore. D'ici là, il est probable qu'au moins un des deux projets en cours qui visent a avoir un compilateur Rust avec un backend GCC soit fonctionnel.

Si un jour on veut remplacer les driver C actuels par des drivers en Rust ça deviendrait un problème
Oui, ça devriendrait un problème, et pour ma part, je pense que ça arrivera.

Oui mais pour le coup un alpiniste ne s'entraine pas dans les escaliers.

Belle réplique, ça m'a fait sourire, une réplique à la Audiar. Chapeau l'artiste.

Rust est un langage globalement adapté, on le sait, mais au bout d'un moment il faut s'attaquer au vrai problème pour avancer. Le fait que le projet Rust for Linux tourne soit intégré à Linux, a permis d'identifier les problèmes qui sont en cours de correction. Le projet restant optionnel : on peut toujours construire un noyau Linux sans Rust.

Oui, on peut toujours, mais je reste sur ma position, s'il y a trop de code Rust qui entre dans le linux (quelque soit le niveau), il faudra à l'avenir maintenir cela. Vérification du code de deux langages, ainsi que leur intéractions, donc du travail en plus. Puis, on en a vu passer des langages tentant de "remplacer" C, et ils sont maintenant complètement oubliés.

on peut toujours construire un noyau Linux sans Rust.
Pour la onzième fois (à peu près), on ne force à personne à se mettre au Rust. On permet juste a ceux qui le veulent d'expérimenter l'introduction de Rust dans les drivers. Linux c'est construit autour de ce que permettait C pendant 30 ans. C'est normal qu'un langage qui arrive en cours de route ait besoin de travail pour s'intégrer a l'existant, c'est le travail qui est en cours.

On ne force personne à se mettre au 'Rust', je suis bien d'accord. Qu'on l'utilise à la place du C dans de nouveau projets, libre à chacuns de choisir ses outils. Mais si on accepte 'Rust' dans la base de code linux, d'autres risques également d'y entrer. Et quoi qu'on en dise, avoir 2 langages dans une même base de code, c'est pour moi une mauvaise idées.

Pour la douzième fois (à peu près), on exige rien à ce niveau non plus des gens qui travaillent sur le noyau Linux.
Il y a deux projet actuellement en cours avec des gens qui n'ont rien a voir avec le noyau Linux et qui travaillent là dessus, parce que ça les intéresse. Mais faire un compilateur, ça tombe pas du ciel, c'est techniquement aussi complexe que faire un OS, voire plus quand on travaille sur des compilateurs du niveau de GCC.

Je confirme, écrire un OS c'est loin d'être compliqué (je l'ai vécu en créant un petit RTOS), quand au développement d'un compilateur, c'est aussi très compliqué une fois qu'on sort des petits exemples qu'on trouve sur le net. Je suis en train d'en construire un "from scratch", pour un nouveau lanagage, pour le fun quand j'ai le temps, et c'est effectivement très difficile, une multitude de petits détails complique les choses.

Pour la treizième fois (à peu près), les gens du projet Rust for Linux n'exigent rien des développeurs Linux actuels.
Pour continuer l’analogie, on est dans le cas d'un étranger qui fait tout ce qu'il faut pour s'intégrer mais qui est quand même victime de racisme.

Mon analogie ne visait personne en particulier, et je n'ai pas envie de rentrer dans un débat "politique" (qui n'a pas ça place ici). Mais force est de constater que faire cohabiter 2 "choses", (ici 2 langages), n'apporte pas forcément une plus-value.

Pas de soucis, moi aussi sur le forum j'ai tendance a passer du tutoiement au vouvoiement, et inversement, sans m'en rendre compte.

Moi aussi

Oui j'ai oublié de préciser que je parlais dans le contexte du développement d'OS où on a pas encore assez de retour pour être absolument formel. Mais de manière globale je suis totalement d'accord avec votre point de vue.

Yes !

Il évolue, mais de manière rétrocompatible donc pas vraiment dangereuse.

Mais ne dit qu'un jour ce ne sera pas le cas. Le 'C' étant là et pour toujours, c'est une sécurité.

En gros, pas grand chose. De ce que je vois en suivant les rapport d'avancement de rust_codegen_gcc, le back-end gcc est globalement adapté, il y a juste des petits patchs nécessaires pour bien gérer certains détails.

Tant mieux, mais il faut finir ce travail avant de penser à autre chose. Il existe aussi le risque d'un "fork", où on aurait d'un côté un "linux" avec une code de base en 'C', et un autre avec dus 'Rust' en plus dedans. Et en y réfléchissant, c'est ce que devrait faire l'équipe 'Rust'. Faire un fork, le remanier comme ils l'entendent, y faire leur changement, puis laisser choisir qui s'oriente vers quoi. On constatera si l'ajout de 'Rust' apporte plus d'avantage que d'inconvéniants, tout en laissant actuellement la base de code linux en pur 'C'

Ce n'est que la liste des cibles dites de tiers 1, dont le projet Rust garantit lui même un support complet. Si on rajoute les cible Tiers 2 et Tiers 3 ça fait plus. De plus Linux n'est de toute façon pas capable de fonctionner sur tous les microcontrôleurs que tu évoques. Si on fait le croisement entre les cibles que Linux supporte et celles que le compilateur Rust actuel supporte, il ne doit pas en manquer tant que ça.

J'ai du mal m'exprimer. Je ne pensait pas une seule seconde à faire tourner linux sur des petits µControlleur. Je disais juste que le 'C' est la seul offre (et parfois même l'aasembleur), et qu'avoir un compilateur 'Rust' pour une grande majorité des µControlleur reste pour le moment un doux fantasme. Qui de toute façon n'apporterait rien, puisque l'on de devra pratiquement tout faire en mode "unsafe".

Si c'était le cas Rust ne serait pas a la mode, car il faut plus d'efforts pour maitriser le Rust que le C.

Oui, rien qu'en regardant la syntaxe, ça saute aux yeux. Et s'il est plus difficile à apprendre que le 'C', les gens resteront sur 'C'. Là on est un peut dans le 'Pourquoi faire simple quand on peut faire compliqué'.

Tu dis: "Si c'était le cas Rust ne serait pas a la mode". et c'est cela qui est le plus a craindre, c'est qu'il ne reste pas "à la mode" (personne ne peut prédire l'avenir). Le 'C', lui, n'est pas une 'mode'.

BàT et merci d'échanger courtoisement.

Peace & Love.

[floyer]

Tant mieux, mais il faut finir ce travail avant de penser à autre chose. Il existe aussi le risque d'un "fork", où on aurait d'un côté un "linux" avec une code de base en 'C', et un autre avec dus 'Rust' en plus dedans. Et en y réfléchissant, c'est ce que devrait faire l'équipe 'Rust'. Faire un fork, le remanier comme ils l'entendent, y faire leur changement, puis laisser choisir qui s'oriente vers quoi. On constatera si l'ajout de 'Rust' apporte plus d'avantage que d'inconvéniants, tout en laissant actuellement la base de code linux en pur 'C'

L'utilisateur final ne regardera que les fonctionnalités. Si la version avec Rust apporte un driver incontournable pour certains ou un système de fichiers "must-have", cette version aura peut-être plus de succès. Si le fork peine à intégrer les évolutions de la version originale... il ne s'imposera pas. Ceci-dit, il y a déjà des forks ou des choses qui s'y apparente (OpenVZ ? patch RT ?), mais est-ce une bonne chose ? Si je veux les avantages de tel fork et de tel autre, je serais embêté, alors qu'une version unique offrirait toute les fonctionnalités.

J'ai du mal m'exprimer. Je ne pensait pas une seule seconde à faire tourner linux sur des petits µControlleur. Je disais juste que le 'C' est la seul offre (et parfois même l'aasembleur), et qu'avoir un compilateur 'Rust' pour une grande majorité des µControlleur reste pour le moment un doux fantasme. Qui de toute façon n'apporterait rien, puisque l'on de devra pratiquement tout faire en mode "unsafe".

Pas, sûr. Peut-être des fonctions unsafe aux interfaces, mais le coeur du programme en safe. Après, Rust est intéressant lorsqu'il y a des structures de données (avec allocation dynamique), de l'asynchrone (risque de race condition). Sur un µControlleur, j'imagine peu d'applications avec des besoins de gestion mémoire particulier. L'asynchrone, à voir.

Oui, rien qu'en regardant la syntaxe, ça saute aux yeux. Et s'il est plus difficile à apprendre que le 'C', les gens resteront sur 'C'. Là on est un peut dans le 'Pourquoi faire simple quand on peut faire compliqué'.

C++ est plus compliqué que C, pourtant il s'est imposé dans certains contexte. ET l'idée de Rust, est de rendre l'écriture de code buggué plus difficile. Cela peut justifier une écriture plus difficile car les les règles sur les emprunts empêchent de compiler quelque chose sur lequel le compilateur a des doutes.

Tu dis: "Si c'était le cas Rust ne serait pas a la mode". et c'est cela qui est le plus a craindre, c'est qu'il ne reste pas "à la mode" (personne ne peut prédire l'avenir). Le 'C', lui, n'est pas une 'mode'.

Le succès d'un langage dépend des qualités intrinsèques, de l'écosystème (outils, bibliothèques), et des promoteurs derrières (il peut aussi y avoir des aspects coûts qui ont dû plomber ADA avant la disponibilité de GNAT). Derrière Rust, il y a la fondation Mozilla, cela fait quelques gages de pérennité. Il y a un effet oeuf et la poule... le succès d'un langage permet le développement de plus de bibliothèques/outils, ce qui concourt au succès.

[fdecode]

Oui, rien qu'en regardant la syntaxe, ça saute aux yeux.

Un exemple? Cela ne me saute pas aux yeux personnellement.

Et s'il est plus difficile à apprendre que le 'C', les gens resteront sur 'C'. Là on est un peut dans le 'Pourquoi faire simple quand on peut faire compliqué'.

Syntaxiquement et sémantiquement, l'assembleur est plus simple que le C. Et si on veut de la portabilité, un peu de LLVM IR? Curieusement, il n'y a pas foule pour coder dans ces langages.
Mais en réalité, on le comprend très bien: la syntaxe et surtout la sémantique associée sont très utiles d'un point de vue humain; ce sont des outils pour aider les hommes à programmer.

La sémantique de Rust pourrait paraître complexe (de mon point de vue pas tant que ça), mais c'est aussi une aide puissante pour des projets complexes.
Cela demande surtout d’acquérir certains réflexes de programmation, mais cela vient progressivement à force d'être corrigé par le compilateur de Rust (qui est plutôt un bon prof en général).
Pour ce qui est des connaissances de base, si on a utilisé un langage avec gestion directe de la mémoire, on sait très vite utiliser Rust de manière impérative. Et si on est familier des paradigmes de programmation haut niveau des langages "modernes", il est plutôt simple d'utiliser les paradigmes puissants de Rust.

" les gens resteront sur 'C' "
À la bonne heure! Il feront selon leur désir et tant mieux. Les horizons de Rust me semblent plutôt ouverts, sans qu'il y ait besoin de faire des conversions
Éventuellement, je vois plutôt positivement la monté de Rust dans les OS (Linux est un exemple), car cela consolidera et accélèrera peut-être encore plus le développement de Redox, qui est l'OS qui m'intéresse dans le monde du libre.

Tu dis: "Si c'était le cas Rust ne serait pas a la mode". et c'est cela qui est le plus a craindre, c'est qu'il ne reste pas "à la mode" (personne ne peut prédire l'avenir). Le 'C', lui, n'est pas une 'mode'.

Il y a un petit côté sophiste dans l'argumentation. Je ne sais pas ce qu'est une mode. J'utilise un langage quand il m'est utile et agréable.

[fdecode]

Derrière Rust, il y a la fondation Mozilla, cela fait quelques gages de pérennité.

Ce n'est plus Mozilla qui finance Rust, mais la Rust fondation:
https://foundation.rust-lang.org/members/
dont le membres sont:


Mozilla reste identifiée comme membre fondateur, mais n'est que membre "Silver".

[Uther]

Je sais, tu l'as dis 10x, j'ai bien vu passer tes réponses. Mais une fois acccepté pour des drivers isolés, ça évoluera et linux deviendra un mixte de code en C et Rust. Une fois le ver dans le fruit, il le mange. On rentre par une petite porte sur le côté, puis ça s'installe partout. C'est peut-etre le danger que resentent les anciens. C'est une situation qui peu étre mal vécue. Ce n'est peut-être pas l'intention de la communauté Rust, mais c'est un reflexe humain.

Certes mais pour le coup, de l'autre coté, on peu aussi essayer de comprendre les gens qui font un gros travail pour que l'intégration entre C et Rust ce passe au mieux, pour rendre le développement de drivers Linux plus ouvert, plus rapide et plus sûr sans impacter l'existant, et qui se font limite cracher dessus.

Oui, dans un monde idéal, ça devrais être le cas, mais la nature humaine étant ce qu'elle est, ce mode "unsafe" sera utilisé plus que nécessaire, volontairement ou pas. Mais je suis d'accord avec toi sur le fait qu'ils "marquent" un code auquel il faut faire attention.

Rust a déjà presque 10 ans d'ancienneté, il a assez de code publié pour se faire une idée de comment le gens codent avec, et la tendance que vous décrivez n'est clairement pas ce qu'on constate dans la pratique. Le code unsafe n'est clairement pas bien vu quand il est évitable. Dans les projets avec un minimum de suivi, comme c'est le cas pour le noyau Linux, on trouve généralement vite des gens qui vont essayer de retirer les blocs unsafe dispensables.

Oui, rien qu'en regardant la syntaxe, ça saute aux yeux. Et s'il est plus difficile à apprendre que le 'C', les gens resteront sur 'C'. Là on est un peut dans le 'Pourquoi faire simple quand on peut faire compliqué'.

Y'a une question de familiarité avant tout : la syntaxe de C est juste plus naturelle quand on a l'habitude de travailler avec mais elle n'est pas particulièrement simple non plus.
Et si il est plus rapide d'apprendre les concepts de base du C, il est clairement beaucoup plus complexe d'apprendre à bien les maitriser. J'ai beau le connaitre le C depuis plus de 25 ans, je suis bien plus confiant de la qualité de ce que je produit avec du Rust.

[OuftiBoy]

Un exemple? Cela ne me saute pas aux yeux personnellement.

En voici un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
 
#[derive(Debug, PartialEq, Copy, Clone)]
enum ShirtColor {
    Red,
    Blue,
}
 
struct Inventory {
    shirts: Vec<ShirtColor>,
}
 
impl Inventory {
    fn giveaway(&self, user_preference: Option<ShirtColor>) -> ShirtColor {
        user_preference.unwrap_or_else(|| self.most_stocked())
    }
 
    fn most_stocked(&self) -> ShirtColor {
        let mut num_red = 0;
        let mut num_blue = 0;
 
        for color in &self.shirts {
            match color {
                ShirtColor::Red => num_red += 1,
                ShirtColor::Blue => num_blue += 1,
            }
        }
        if num_red > num_blue {
            ShirtColor::Red
        } else {
            ShirtColor::Blue
        }
    }
}
 
fn main() {
    let store = Inventory {
        shirts: vec![ShirtColor::Blue, ShirtColor::Red, ShirtColor::Blue],
    };
 
    let user_pref1 = Some(ShirtColor::Red);
    let giveaway1 = store.giveaway(user_pref1);
    println!(
        "The user with preference {:?} gets {:?}",
        user_pref1, giveaway1
    );
 
    let user_pref2 = None;
    let giveaway2 = store.giveaway(user_pref2);
    println!(
        "The user with preference {:?} gets {:?}",
        user_pref2, giveaway2
    );
}

Des "let" et des accolades partout, des ";" inutiles, que fait "vec!" ?, pourquoi la nécessité d'un "!", ça ne saute pas au yeux, et dans user_preference.unwrap_or_else(|| self.most_stocked()) ? n'est pas limpide... des "symboles" qui partent dans tous les sens. Le "formatage" des string via des {} qui ne fait pas mieux que le printf du 'C', avec juste 40 ans de retard. Bref, (mais ce n'est que mon opinion, je ne prétend pas avoir raison) tout un tas de choses qui aurait pu (et qui aurait du) être faite bien mieux, qui semble d'un autre âge, alors que Rust est jeune/vieux de 10ans.
'Rust' me fait penser à un langage qui a été spécifié par des théoriciens "académique", alors que le 'C' a été écrit d'une façon "pratique". Il y a aussi cette manie de changer les noms de choses juste pour le plaisir (les "crates" ça fait plus smarts que module ou lib), un truc qui s'appel cargo.

En fait sans voulir être méchant, 'Rust' existe depuis bien plus que 10 ans, ça s'apelle Ada (utilisé par les militzires Américains) et ça a 40 ans (et dont "Rust' n'est qu'une ré-implémentation des mêmes concepts).

Attention, je répéte que je n'ai rien contre 'Rust'. Je ne suis pas dans une démarche d'évangeliste pour le C. Franchement, j'ai autre chose a faire du temps qu'il me reste. La Syntaxe de 'Rust' est plus proche du 'C++' qui, au fil de ces évolutions, est devenir un brol imbuvable. Je ne suis anti-rien. Mais mon choix c'est porté sur 2 langages. Le 'C' pour l'embarqué, et 'Python' pour le reste.

Syntaxiquement et sémantiquement, l'assembleur est plus simple que le C. Et si on veut de la portabilité, un peu de LLVM IR? Curieusement, il n'y a pas foule pour coder dans ces langages. Mais en réalité, on le comprend très bien: la syntaxe et surtout la sémantique associée sont très utiles d'un point de vue humain; ce sont des outils pour aider les hommes à programmer.

Non, l'assembleur n'est pas "plus simple que le 'C'". Le 'C' est connus pour rester au plus près de la machine, au début on parlait de 'C' comme étant un assembleur de haut niveau. Et qui est assez portable. Oui, il a des défauts, mais rien de dramatique pour un développeur un peu malin. Il a survécu depuis 40 ans à tout une série de "nouveau langage" qui prétendait le supplenter, mais TOUS on échoué. (le dernier qui le prétendait et que j'ai regardé), c'était D. Où est-on avec ce 'D' ? Nulle part. Il y a aussi 'C3' 'ou 'C4', mais la mayonnaise ne semble pas prendre non plus. Il n'y a pas que le langage en lui même, il y a tout une culture, des outils, des libraires "autours" du C.

Oui, 'Rust' et ses concept sont intéressants, Mias le 'C' est tout simplement incontournable.
C'est un peu le 'COBOL' du domaine banquaire, qu'on a essayé de remplacer par C++, puis par Java, et ça n'a jamais abouti à rien.
Tout comme le 'Fortran' pour le monde des matématiciens.

La sémantique de Rust pourrait paraître complexe (de mon point de vue pas tant que ça)

On peut considérer ça comme un point de vue. Elle t'es peut-être famillière. Mais pour un vieux dinosauore qui a fait du C ça spécialité, 'Rust' est verbeux. Et les mécanismes borrow/lifetime sont plus compliqués que de faire de simple un alloc/free en 'C'.

Mais c'est aussi une aide puissante pour des projets complexes.
Cela demande surtout d’acquérir certains réflexes de programmation, mais cela vient progressivement à force d'être corrigé par le compilateur de Rust (qui est plutôt un bon prof en général).

Mais c'est un peu comme pour tout. Est-il si 'inimaginable' pour un développeur qui 'aime/soutient' 'Rust', qu'un développeur maîtrissant le C n'y voit pas grand intérêt ?

Pour ce qui est des connaissances de base, si on a utilisé un langage avec gestion directe de la mémoire, on sait très vite utiliser Rust de manière impérative. Et si on est familier des paradigmes de programmation haut niveau des langages "modernes", il est plutôt simple d'utiliser les paradigmes puissants de Rust.

Je ne dis pas le contraire. Le point de départ de la discution concernant Rust, c'était de l'introduire dans la base de code 'C' de linux., et que je trouvais que ça apportait plus de difficulté que d'avantage. C'est aussi ce que pensent les mainteneurs 'C' du noyau linux. 'Rust' aura peut être disparu dans 10 ans, mais le C sera toujours là, c'est la brique fondamentable du développement de "l'informatique".

Go a disparu, Kotlin surnage, Java est immonde, tous comme l'est le C++, C# change si vite que les auteurs de l'écosystème qui l'entoure n'arrive plus à suivre et son système "d'intellicense", pousse les dèv C# a écrire trop vote et sans réflexion aucune. Il faut même des outils externe (genre Resharper) pour arriver à l'utiliser un peu plus facilement. Pour le bas niveau, le 'C' fait le taf, et pour le haut-niveau, Python fait le 'taf'.

C++ n'a pas remplacé le C. Java n'a pas remplacé le C++, et 'Rust' ne remplacera pas le 'C', pour la simple et bonne raison qu'il ya pleins de langage de plus au niveau qui sont plus abordables, mieux supportés et plus simple pour des logiciels qui n'ont pas a se rapprocher trop du matériel (et qui ont pleins de "wrapper" autours de libs/fonctions écritent en 'C'). Et 'Rust' fera ou fait déjà cela.

Je connais des dizaines d'ingénieurs (je ne parle même pas de pur développeurs) qui font leur petits truc facilement avec Python et pour qui 'Rust' ressemble à Frankenstein, et qui ne comprennent rien quant ils voient du code 'Rust', alors qu'il comprennent en quelque minute un script Python qui fait la même chose mais avec 10 lignes de code au mieu de 50.

" les gens resteront sur 'C' ". À la bonne heure! Il feront selon leur désir et tant mieux. Les horizons de Rust me semblent plutôt ouverts, sans qu'il y ait besoin de faire des conversions

100% d'accord.

Éventuellement, je vois plutôt positivement la monté de Rust dans les OS (Linux est un exemple), car cela consolidera et accélèrera peut-être encore plus le développement de Redox, qui est l'OS qui m'intéresse dans le monde du libre.

En 30 ans, linux a pris (environ) 5% du marché desktop (les serveurs c'est 50-50 avec Windows). Je ne serais plus là dans 30 ans, mais redox (qui est très certainement un projet intéressant) ne fera pas mieux. Même si Microsoft est en train de devenir fou avec les changements de Windows qui se détériore de version en version. Mais comme je disais dans un autre poste, 99% utilise leur OS pour soit lancer un navigateur web, soit pour lancer une application. Pour eux, l'OS c'est comme la dalle qui supporte leur maison.

J'ai appris que redox existait via des réponses dans ce forum, personne ne m'en n'avait jamais parlé avant.

Il y a un petit côté sophiste dans l'argumentation. Je ne sais pas ce qu'est une mode. J'utilise un langage quand il m'est utile et agréable.

Mais si tu sais ce qu'est une "mode", on y a droit tous les deux ans en "informatique". Des exemples ? "Prolog", "RubyOn Rail", "D", "C3/C4", "Les systèmes experts", "les outils case", la "logique floue", les ORM, les BDD orientée Objet et d'autres dont je ne me rappel même plus le nom (Y'a un 'No' dans le nom), la POO, les langages "fonctionnels" (Ocalm, Haskell), Perl, Javascript qui est utilisé, mais qui est une horreure absolue, "Flash", les sites web fait pour les smarphone mais qui sont pénibles a utiliser sur un "deskop", HTML/CSS dont on dit qu'ils sont des langages de programmation, les "framework" web qui existe 2 mois avant d'être remplacé par s'autres, l'IoT. Là maintenant, c'est la mode "IA", une bulle qui va éclater et faire des ravages.

Mais sinon, je pense comme toi, j'utilise les outils dont j'ai besoin, et en quarante ans, 'C' pour l'embarqué et Python pour le reste.

BàT et Peace & Love.

[Uther]

En voici un : [...]

C'est un bon exemple de ce que je parlais niveau familiarité. Beaucoup de vos critiques viennent du fait que vous êtes habitués à la syntaxe du C. Pour quelqu'un qui ferait uniquement du Python ou du Pascal, la syntaxe du Rust n'est pas beaucoup plus déroutante que le C.

Des "let" et des accolades partout, des ";" inutiles, que fait "vec!" ?, pourquoi la nécessité d'un "!", ça ne saute pas au yeux,

les let c'est juste des déclaration de variable, ça n'a rien de plus complexe que les déclaration en C et C ++, je dirais même que c'est plus simple dans la majorité des cas.
Les point-vigules, pour le coup, c'est quasiment comme le C.
Quant au point d'exclamation ça marque juste l'appel a une Macro, qui est un concept qui existe aussi en C, mais qui est masqué car la syntaxe pour les appeler est identique a celle d'une fonction. Quand on sait ça, c'est pas très difficile de comprendre que vec![] est une macro qui crée un vecteur.

et dans user_preference.unwrap_or_else(|| self.most_stocked()) ? n'est pas limpide... des "symboles" qui partent dans tous les sens.

La lambda, c'est vrai que c'est un concept qui n'existe pas en C, et j'aurais en effet choisi une autre syntaxe que || pour ça. Mais c'est pas si complexe que ça non plus, ça existe dans beaucoup de langages. Là encore, la syntaxe, c'est surtout un problème de familiarité.
Par contre, cette ligne est un très bon exemple de comment Rust, contrairement à C, pousse a bien gérer les choses par défaut. En Rust le type Option oblige a choisir comment traiter le cas invalide. L'équivalent C ressemblerait à quelque chose comme user_preference == -1 ? self.most_stocked() : user.preference qui n'est pas vraiment plus clair et beaucoup omettraient tout simplement le test de validité.

Le "formatage" des string via des {: ?} qui ne fait pas mieux que le printf du 'C', avec juste 40 ans de retard.

Alors non c'est beaucoup mieux pour plusieurs raisons :
- c'est sécurisé d'un point de vue mémoire.
- le système de trait permet à chaque type d'avoir son propre affichage.
- Si on veut afficher la valeur naturelle "{}" suffit. Le ": ?" à l’intérieur indique d'utiliser la valeur technique qui a du sens dans les logs ou un débogueur.
- Ton exemple utilise la syntaxe avec paramètres séparés mais on peut aussi faire : println!("The user with preference {user_pref1:?} gets {giveaway1:?}")

'Rust' me fait penser à un langage qui a été spécifié par des théoriciens "académique", alors que le 'C' a été écrit d'une façon "pratique".

Pour le coup c'est plutôt l'inverse Rust est un langage qui a offert une utilisation pragmatique à beaucoup de concept qui jusque là avaient du mal a sortir du coté académique.

Il y a aussi cette manie de changer les noms de choses juste pour le plaisir (les "crates" ça fait plus smarts que module ou lib), un truc qui s'appel cargo.

Ça n'est pas pour le plaisir. Le concept de module existe en Rust mais c'est un découpage plus fin que la crate. En fait la crate, c'est le module de plus haut niveau qui va produire un exécutable ou une bibliothèque. Le terme de lib est tout a fait admis pour les crates de type bibliothèque, mais ce n'est qu'une partie des crates.
Quant a cargo c'est l'outil de build / gestion de dépendance. Il faut bien qu'il ait un nom, comme on a nmp pour Javascript, pip pour Python ou maven pour Java.

En fait sans voulir être méchant, 'Rust' existe depuis bien plus que 10 ans, ça s'apelle Ada (utilisé par les militzires Américains) et ça a 40 ans (et dont "Rust' n'est qu'une ré-implémentation des mêmes concepts).

Rust et Ada sont des langages très différents sur beaucoup de points fondamentaux. Même s'ils visent tous les deux à améliorer la sécurité du code, ils le font de manière très différente.
par exemple Ada a certaines capacités sur la validation des données qui manquent par défaut à Rust, mais Rust dispose du système de Ownership/Borrowing qui garanti la sécurité mémoire du code sans impacter les performances.

Je connais des dizaines d'ingénieurs (je ne parle même pas de pur développeurs) qui font leur petits truc facilement avec Python et pour qui 'Rust' ressemble à Frankenstein, et qui ne comprennent rien quant ils voient du code 'Rust', alors qu'il comprennent en quelque minute un script Python qui fait la même chose mais avec 10 lignes de code au mieu de 50.

Et c'est normal. Personne ne pense que Rust est le langage le plus adapté a toutes les situations. Pour prototyper rapidement du code sans problématique de maintenabilité et de sécurité, les borrow checker est plus un problème qu'un avantage.

[floyer]

Et les mécanismes borrow/lifetime sont plus compliqués que de faire de simple un alloc/free en 'C'.

Les règles de Rust sont plus strictes, donc oui, il y a des choses qui compilent en C qui ne compileront pas transposées mot à mot en Rust.

Par contre, en C c’est assez simple de se tromper (oublie d’un free par exemple, déreférencement d’un bloc libéré…) là ou Rust te gère l’allocation pour toi. Tous les free sont implicites. C’est l’objectif du système d’emprunt.

[OuftiBoy]

C'est un bon exemple de ce que je parlais niveau familiarité. Beaucoup de vos critiques viennent du fait que vous êtes habitués à la syntaxe du C. Pour quelqu'un qui ferait uniquement du Python ou du Pascal, la syntaxe du Rust n'est pas beaucoup plus déroutante que le C.

Oui, c'est certainement le cas. Je ne vais le nier. Il y'a une question d'habitude. Mais ça faisait partie du problème de l'introduction du Rust dans une base C comme Linux. Je suis certains qu'en faisant un petit effort, y'a moyen de s'adapter. Je ne dis pas le contraire. On s'adapter à toute sorte de langage, quand on en ressent le besoin, quand on ne ressent pas ce besoin, c'est moins évident.

les let c'est juste des déclaration de variable, ça n'a rien de plus complexe que les déclaration en C et C ++, je dirais même que c'est plus simple dans la majorité des cas. Les point-vigules, pour le coup, c'est quasiment comme le C. Quant au point d'exclamation ça marque juste l'appel a une Macro, qui est un concept qui existe aussi en C, mais qui est masqué car la syntaxe pour les appeler est identique a celle d'une fonction. Quand on sait ça, c'est pas très difficile de comprendre que vec![] est une macro qui crée un vecteur.

Je suis d'accord, mais en tant que "nouveau" langage, il y avait d'éviter ce genre de lourdeur. J'attache énormément d'importance à la facilité de lecture d'un code. Les ";", y'a moyen de s'en passer, les let aussi, le "!" pour l'appel d'une "macro", il y avait moyen de faire "plus clair", et c'est d'ailleurs quelques choses (l'équivalant du #define en C) qu'on essaye d'éviter, car oui, en 'C' on peut vite introduire des bugs subtil quand on écrit mal une macro.

La lambda, c'est vrai que c'est un concept qui n'existe pas en C, et j'aurais en effet choisi une autre syntaxe que || pour ça. Mais c'est pas si complexe que ça non plus, ça existe dans beaucoup de langages. Là encore, la syntaxe, c'est surtout un problème de familiarité.
Par contre, cette ligne est un très bon exemple de comment Rust, contrairement à C, pousse a bien gérer les choses par défaut. En Rust le type Option oblige a choisir comment traiter le cas invalide. L'équivalent C ressemblerait à quelque chose comme user_preference == -1 ? self.most_stocked() : user.preference qui n'est pas vraiment plus clair et beaucoup omettraient tout simplement le test de validité.

Oui, le principe de lamda n'existe pas en C. Il existe en Python, mais ce n'est pas une bonne pratique. On peut aussi vite faire une petite fonction, ce que serait bien plus clair. En fait, j'ai un côté "conservateur" et je tente toujours d'écrire un code qui sera le plus simple à relire, par moi ou par un autre. C'est une sorte de familiarité. Par exemple, en Python, faire [CODELINE]a = True if condition else False[/CODELINE] fait la même chose, mais en plus clair (avis subjectif si tu veux), et quand je lis == -1, je considère que c'est une erreur, car je ne sais pas ce que signifie le -1 ? est-ce OK ou ERREUR.

J'évite d'utiliser des "chiffre magique" dans mon code. Et puis, dire que beaucoup de développeur 'C' omettraient tout simplement le test de validité, c'est un jugement au doigt mouillé mon capitaine Certaine "syntaxe" offre la possibilité (par exemple) de faire plus court, mais souvent en plus "cryptique", comme l'opérateur "?:". Un autre exemple, (qui est aussi un défaut en C comme dans 99% des langages), c'est d'utilisé le signe "=" pour l'assignation. En Pascal, on fait a := a et on peut garde le "=" pour tester une condition. En fait, moins il y a de mot clef et d'opérateur dans un langage, plus il est clair. (ce n'est que mon opinion, qui doit certainement être subjective).

Alors non c'est beaucoup mieux pour plusieurs raisons :
- c'est sécurisé d'un point de vue mémoire.
- le système de trait permet à chaque type d'avoir son propre affichage.
- Si on veut afficher la valeur naturelle "{}" suffit. Le ": ?" à l’intérieur indique d'utiliser la valeur technique qui a du sens dans les logs ou un débogueur.
- Ton exemple utilise la syntaxe avec paramètres séparés mais on peut aussi faire : println!("The user with preference {user_pref1:?} gets {giveaway1:?}")

- C'est sécusé d'un point de vue mémoire, très bien, mais sécurisation ne devrait pas venir "de la syntaxe".
- Le système de "trait" permet à chaque type d'avoir son propre affichage. Mais il y'a certainement moyen que chaque type ai son propre affichage sans devroir créer un nouveau concept (le trait).

Pour le coup c'est plutôt l'inverse Rust est un langage qui a offert une utilisation pragmatique à beaucoup de concept qui jusque là avaient du mal a sortir du coté académique.

Je veux bien te croire, et je suis certainement un des plus extémiste/concervateur sur ce point. Mais tout comme j'essaye d'écrire un code simple (sans utiliser une super syntaxe qui pourrait être plus compact, mais moins claire). Je favorise la simplicité en toute circonstance. Je trouve dommage que 'Rust' n'ai pas une syntaxe plus "allégée" que d'autres langage.

Ça n'est pas pour le plaisir. Le concept de module existe en Rust mais c'est un découpage plus fin que la crate. En fait la crate, c'est le module de plus haut niveau qui va produire un exécutable ou une bibliothèque. Le terme de lib est tout a fait admis pour les crates de type bibliothèque, mais ce n'est qu'une partie des crates.

crate, c'est un module. L'appeler "module" serait plus clair. C'est une manie dans beaucoup de langage d'intégrer des "nouveau" mot-clé qui veulent dire la même chose qu'un ancien mot clef, ça fait plus 'smart", mais ça n'apporte rien.

Quant a cargo c'est l'outil de build / gestion de dépendance. Il faut bien qu'il ait un nom, comme on a nmp pour Javascript, pip pour Python ou maven pour Java.

cargo, nmp, pip, maven, etc, c'est un bel exemple d'utilisation de nom différent pour un même concept.

Rust et Ada sont des langages très différents sur beaucoup de points fondamentaux. Même s'ils visent tous les deux à améliorer la sécurité du code, ils le font de manière très différente.
par exemple Ada a certaines capacités sur la validation des données qui manquent par défaut à Rust, mais Rust dispose du système de Ownership/Borrowing qui garanti la sécurité mémoire du code sans impacter les performances.[/B]

Pour le coup, j'aime bien mieux Ada le concept d'Ada que le "Ownership/Borrowing" de 'Rust'.

Bàt. et Peace & Love.
Et c'est normal. Personne ne pense que Rust est le langage le plus adapté a toutes les situations. Pour prototyper rapidement du code sans problématique de maintenabilité et de sécurité, les borrow checker est plus un problème qu'un avantage.[/QUOTE]

[OuftiBoy]

J'avais oublié ce passage:

Et c'est normal. Personne ne pense que Rust est le langage le plus adapté a toutes les situations. Pour prototyper rapidement du code sans problématique de maintenabilité et de sécurité, les borrow checker est plus un problème qu'un avantage.

Oui, on est d'accord la dessus. Mais dans toutes les entreprises (et c'est une erreur), on donne rarement l'occasion de faire un prototype. Et on oblige souvent à améliorer le prototype. Et donc, on commence avec le langage qui sera utilisé au final

Pour en finir, et ne pas tourner en rond, je dirais qu'on a tous un vécu différent, des envies différentes, des reflexes différent, des habitudes différentes, etc
C'est un débat sans fin.

BàT, et Peace & Love.

[floyer]

Oui, c'est
Je suis d'accord, mais en tant que "nouveau" langage, il y avait d'éviter ce genre de lourdeur. J'attache énormément d'importance à la facilité de lecture d'un code. Les ";", y'a moyen de s'en passer, les let aussi, le "!" pour l'appel d'une "macro", il y avait moyen de faire "plus clair", et c'est d'ailleurs quelques choses (l'équivalant du #define en C) qu'on essaye d'éviter, car oui, en 'C' on peut vite introduire des bugs subtil quand on écrit mal une macro.

Ce serait curieux de préférer C car on utilise ; dans Rust !

Enfin le let permet de différentier la définition de variable de l’affectation, ce qui est différent.

Ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
let mut a = 42;
a = 43;

Est l’équivalent C de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int a = 42;
a = 43;

Oui, le principe de lamda n'existe pas en C. Il existe en Python, mais ce n'est pas une bonne pratique. On peut aussi vite faire une petite fonction, ce que serait bien plus clair. En fait, j'ai un côté "conservateur" et je tente toujours d'écrire un code qui sera le plus simple à relire, par moi ou par un autre. C'est une sorte de familiarité. Par exemple, en Python, faire [CODELINE]a = True if condition else False[/CODELINE] fait la même chose, mais en plus clair (avis subjectif si tu veux), et quand je lis == -1, je considère que c'est une erreur, car je ne sais pas ce que signifie le -1 ? est-ce OK ou ERREUR.

Au moins Rust apporte quelques chose puisqu’il propose un type Result qui vaut soit Ok(valeur_de_retour) ou Err(description_de_lerreur). Certaines syntaxes peuvent être pratiques avec (fonction()?.methode()) où le ? Indique une exécution de la méthode qu’en cas de succès.

- C'est sécusé d'un point de vue mémoire, très bien, mais sécurisation ne devrait pas venir "de la syntaxe".

Qu’entendre par «*par la syntaxe*». C’est sécurisé dans le sens où la macro remplace des "{a} {b}" par des appels aux bonnes fonctions (alors qu’en C, les fonction dépendent si tu utilises %s %c %d… et C ne vérifie pas la cohérence). La syntaxe rend les choses plus simples. Pourquoi s’en plaindre ?

- Le système de "trait" permet à chaque type d'avoir son propre affichage. Mais il y'a certainement moyen que chaque type ai son propre affichage sans devroir créer un nouveau concept (le trait).

Rien ne t’empêche de convertir une variable en texte par ta propre fonction et utiliser éventuellement println!("var={}", convert(var))

Je veux bien te croire, et je suis certainement un des plus extémiste/concervateur sur ce point. Mais tout comme j'essaye d'écrire un code simple (sans utiliser une super syntaxe qui pourrait être plus compact, mais moins claire). Je favorise la simplicité en toute circonstance. Je trouve dommage que 'Rust' n'ai pas une syntaxe plus "allégée" que d'autres langage.

La syntaxe de Rust ne me semble pas si lourde. Ils ont même abrégé function en fn ! Mais tu penses peut-être au let (cf exemple plus haut… pas de caractères supplémentaires). Son coté plus haut niveau permet par exemple de donner un tableau en paramètre avec implicitement sa taille. Je ne sais pas ce que tu considères à alléger.

crate, c'est un module. L'appeler "module" serait plus clair. C'est une manie dans beaucoup de langage d'intégrer des "nouveau" mot-clé qui veulent dire la même chose qu'un ancien mot clef, ça fait plus 'smart", mais ça n'apporte rien.

Un crate peut apporter plusieurs modules. Donc des termes différents s’imposent.

D’ailleurs avec certains langages et leur environnement, il peut y avoir 3 niveaux (de manière approché) :

C++ : package (vcpkg Microsoft, ou apt/dnf Linux), library, namespace
OCaml : package, library, module
Java : Module, JAR, package

On note l’inversion Java/OCaml… au moins crate… pas d’ambiguïté !

cargo, nmp, pip, maven, etc, c'est un bel exemple d'utilisation de nom différent pour un même concept.

Même principe, mais pas la même réalisation… pas les mêmes dépôts donc des commandes différentes… de même que tu appelles le compilateur différemment (gcc, rustc…) tout comme tu a des noms différents pour les gestionnaires de versions (git, cvs, sccs, hg…)

Pour le coup, j'aime bien mieux Ada le concept d'Ada que le "Ownership/Borrowing" de 'Rust'.

Oui, mais les allocations dynamiques ne sont pas libérées automatiquement… l’ownerdhip/borrowing n’a pas pour but de t’embêter mais de garantir que la libération automatique soit conforme (pas de fuite mémoire ni libération de ce qui va resservir).

Et c'est normal. Personne ne pense que Rust est le langage le plus adapté a toutes les situations. Pour prototyper rapidement du code sans problématique de maintenabilité et de sécurité, les borrow checker est plus un problème qu'un avantage.

Effectivement, pour prototyper, un langage avec GC est mieux indiqué.

[OuftiBoy]

Bonjour,

Les règles de Rust sont plus strictes, donc oui, il y a des choses qui compilent en C qui ne compileront pas transposées mot à mot en Rust.

C'est un fait et je ne le nie pas.

Par contre, en C c’est assez simple de se tromper (oublie d’un free par exemple, déreférencement d’un bloc libéré…) là ou Rust te gère l’allocation pour toi. Tous les free sont implicites. C’est l’objectif du système d’emprunt.

Oui et non, perso de toute ma vie de programmeur 'C', je n'ai jamais eu le moindre soucis et difficulté avec free/malloc. Oui, on peut en faire un mauvais usage, et personne (moi y compris, je me ferais peut-être avoir un jour) n'est à l'abris d'une erreur.

Tout ce que j'essaye de démontrer, c'est qu'un excellent développeur 'C' (comme ceux du noyau linux) fournira une solution adéquate sans devoir utiliser 'Rust'.

Même si je suis très conservateur (et à mon âge, on ne me changera plus), je regarde autour de moi. Et on a mainte fois tenter de "remplacer" le 'C', et que ça n'est jamais arrivé. Je me suis attardé il y'a des années sur le C++. C'était prometteur, mais c'est vite devenu du code imbuvable et on a l'impression qu'on ajoute des fonctionnalités pour qlq que cas particuliers qui ne se pose que très rarement, et qui on finit par faire de C++ une monstruosité. Java également, c'est verbeux et pompeux au possible. C# également.

Je ne dit pas que 'C' est un langage parfait, loin de là, mais j'ai assez de mal a croire que 'Rust' est LE langage parfait, la révolution attendue depuis 40 ans, et qu'il n'a aucun défaut et est parfait. Que 'Rust' soit de plus en plus utilisé, ça ne me fait ni chaud ni froid, mais de la a dire qu'il va remplacer le 'C', non, ça n'arrivera pas. Il faudra des décennies avant que cela arrive éventuellement.

Et comme on ne peut pas être spécialiste de tous les langages, je pense que l'équilibre le plus parfait, c'est le couple Python/C. C'est ce que j'ai choisi et je n'ai jamais eu a le regretter. Mais je ne prétend pas que cela doit être le cas de tout le monde, chacun est libre de choisir ses outils.

"Moderne ne veut pas dire nouveau",
"Nouveau ne veux pas dire meilleur",
"Meilleur ne veut pas dire adapter à tout"

'Rust' a des avantages, mais aussi des désavantages, (tout comme le 'C' et d'autres langages).

BàV. et Peace & Love.

[OuftiBoy]

Ce serait curieux de préférer C car on utilise ; dans Rust !

Je n'ai pas dit ça, j'ai dis qu'en tant de "nouveau langage", il y aurait eu moyen de s'en passer.

Enfin le let permet de différentier la définition de variable de l’affectation, ce qui est différent.

Ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
let mut a = 42;
a = 43;

Est l’équivalent C de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int a = 42;
a = 43;

Et alors ? dans le code 'C' on voit directement que 'C' est un entier. Et pour différencier l'initialisation de l'assignation (ou affectation), je préfèrerais utiliser '=' pour l'initialisation, et ':=' pour l'assignation, c'est l'approche de j'ai prise dans mon langage (qui n'a pas vocation a devenir mainstream), c'est juste pour le fun), j'ai chois la syntaxe suivante:

int8 a=5 ## initialisation
a := 43 ## affectation

pas besoin de ";", pas besoin de "let" et "mut" pour dire que c'est "mutable", je préfaire de loin le faire à l'envers, et utiliser "const" pour indiquer qu'une variable est une constante. Dans mon petit (enfin, pas si petit que ça), je peux faire:

int8 a, b=3, int16 c, const int8 d=12, e=45, y

Toute les variables avant le "const" sont des "mutable" en jargon 'Rust' (des variables normal quoi), et toutes celles après le "const" sont des constantes.
Et ça ne compilera pas en mettant un message clair que "y" en tant que "const" DOIT être initialisée. Ce qui n'est pas le cas des variables "normal".

Et si après tu fais y := 4, ça ne compilera pas non plus, car y est une "const".

Mais si tu utilise "a" avant de lui assigner une valeur, tu aura un "warning" (qui bloque ou pas la compilation, c'est une option) ça émettra que "a" est utilisé avant d'avoir été assignée. Même si une variable est initialisée par défaut à 0.

Si tu n'utilise pas une variable déclarée, initialisée ou non, "const" ou pas, c'est un "warning" également.
Si tu utilises une variable non déclarée, c'est une erreur et ça ne compile pas.

Et si tu veux écrire:
int8 a, int8 b=3
int16 c
const int8 d=12, e=45

C'est exactement le même résultat. Voilà, y'a moins d'écrire un compilateur qui n' pas besoin d'un "let", d'un "mut", de ";" partout. et qui permet de faire un if a=1 au lieu d'un if a==1. Quatre avantages qui allège le code. Si j'ai pu le faire, l'équipe 'Rust' aurait pu également, ils ont peut-être choisi (pour une raison que je ne connais pas) volontairement leur syntaxe pour une bonne raison, mais je n'arrive pas à savoir laquelle.

Je trouve que c'est plus lisible, moins verbeux, et tout informaticien sait ce qu'est une "const".

Au moins Rust apporte quelque chose puisqu’il propose un type Result qui vaut soit Ok(valeur_de_retour) ou Err(description_de_lerreur). Certaines syntaxes peuvent être pratiques avec (fonction()?.methode()) où le ? Indique une exécution de la méthode qu’en cas de succès.[/B]

Si tu parlerais du 'C', tu dirais que les développeurs 'C' ne teste pas les valeur de retour ;-)

Moi, j'ai choisis l'approche suivante:

fonction exemple(const int8 x,y) <- int8 value, bool err:
... (le code de la fonction)
end

tu peux donc écrire par la suite:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
value, err := exemple(10,11)

et par la suite de faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if not err = False: valeur += 1

Qu’entendre par «*par la syntaxe*». C’est sécurisé dans le sens où la macro remplace des "{a} {b}" par des appels aux bonnes fonctions (alors qu’en C, les fonction dépendent si tu utilises %s %c %d… et C ne vérifie pas la cohérence). La syntaxe rend les choses plus simples. Pourquoi s’en plaindre ?

Je ne m'en pleins pas, j'ai que ce n'était pas meilleur. Dans le cas, print a un nombre variable d'argument.

Je préfaire:
str bonjour := f"Hello {name}"

Y'a pas besoin de plus, et tu peux vérifier à la compilation que la valeur (ici la longueur du nom) ne pourra pas provoquer un OverFlow. C'est peut être une option que 'Rust' a, mais elle ne m'a pas été présentée exemple.

Rien ne t’empêche de convertir une variable en texte par ta propre fonction et utiliser éventuellement println!("var={}", convert(var))

Disons que:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
str name="Toto", int16 taille
print(f"var={name} {taille})

et qu'écrire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
println!("var={}", convert(var))

Pas besoin de "convert" pour convertir une string en int, le compilateur est/devrait être assez malin, pour savoir qu'il doit afficher int en tant que string, car il connait le type de "var" et ces limites, et donc s'assurer à la compilation que le transformation du int en string ne provoquera pas d'OverFlow. Pas besoin d'un "!" pour appelr une macro...

La syntaxe de Rust ne me semble pas si lourde. Ils ont même abrégé function en fn ! Mais tu penses peut-être au let (cf exemple plus haut… pas de caractères supplémentaires). Son coté plus haut niveau permet par exemple de donner un tableau en paramètre avec implicitement sa taille. Je ne sais pas ce que tu considères à alléger.

Si, elle est plus lourde que nécessaire:

Bon ok, fn, c'est cours (trop même) peut-être. Moi j'utilise le mot-clef "routine" qui a l'avantage d'être identique en anglais qu'en Français. Et qu'a chaque fois que j'ai demandé ce que faisait la fonction "machin", la réponse était du genre "c'est une routine qui..." Donc j'ai choisi Routine directement.

Un crate peut apporter plusieurs modules. Donc des termes différents s’imposent.
D’ailleurs avec certains langages et leur environnement, il peut y avoir 3 niveaux (de manière approché) :
C++ : package (vcpkg Microsoft, ou apt/dnf Linux), library, namespace
OCaml : package, library, module
Java : Module, JAR, package

Oui, mais pourquoi encore "inventer" un autre terme (crate) pour nommer des choses qui on déjà été nommée avant ?
C'est comme maintenant on utilise le mot "Application", ou "App", alors qu'on aurait pu en rester à ce que c'est vraiment, soit un "program".
Que d'un point de vue "marketing" on utilise "App" parce que ça fait plus "smart", ne doit pas forcément appeler un programme par un autre nom que programme. C'est de la masturbation intellectuelle.

Moi, j'ai choisit que le fichier "maitre" celui où on place le main() d'habitude, soit un module comme un autre. On peut faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
program test:
.
.
.
main()

C'est le module principale, celui qui contient la fonction main(), mais ça reste le "module" d'un "program".

et j'utilise:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
use mathematique

Pour utiliser les routines du module "math" (on peut spécifier tel ou tel routines uniquement, mais le linker n'importera pas ce qui n'est pas utilisé du module "math") et/ou on peut ajouter ajouter as math.
Enfin, pour un package qui rassemble plusieurs modules, je ne suis pas encore arrivé là.

On note l’inversion Java/OCaml… au moins crate… pas d’ambiguïté !

Ne pas me parler de java, ce brol est une ineptie. Devoir créer une "class" pour y mettre le main() est d'un ridicule pas possible.
et OCaml, je n'en connait que le nom.

Même principe, mais pas la même réalisation… pas les mêmes dépôts donc des commandes différentes… de même que tu appelles le compilateur différemment (gcc, rustc…) tout comme tu a des noms différents pour les gestionnaires de versions (git, cvs, sccs, hg…)

Justement la "réalisation" (ce qu'il y a derrière), ne devrait pas imposer de nom différents pour un même "principe". Ce qui compte, dans un premier temps, c'est ce que font les choses, pas comment elles sont faites. Si on devait trouver un nom différent pour chaque type de "voiture" différente, on s'y perdrait vite... Les gestionnaires de versions, je n'y mets "RIEN". Je fais mes sauvegarde à l'ancienne, avec une copie que je garde chez moi et une seconde chez un ami. Au début, j'utilisait le bête 'rc' de base, mais ça ne m'a jamais été utile. Puis sont arrivé les gestionnaires plus "moderne", genre cvs, remplacer par subversion, remplacer par mercury, remplace par gitHUB, et qui maintenant offrent tous cela gratuitement aux OpenAI ou Autre, pour pousser tout ça dans leur IA. Et j'avoue que ça me ferait du mal d'acheter un accès (on dit token, ça passe mieux) à une IA qui me répondrait avec un code que j'aurais moi-même écrit avant !

Oui, mais les allocations dynamiques ne sont pas libérées automatiquement… l’ownerdhip/borrowing n’a pas pour but de t’embêter mais de garantir que la libération automatique soit conforme (pas de fuite mémoire ni libération de ce qui va resservir).

Oui, j'ai bien compris le principe, mais en étudiant le problème, tu peux avoir un "Garbage Collector" très light, que tu appeles quand tu veux. Y'a même eu un exemple donné ici (dans la colonne de droite), là ou on a parler de JIFF pour RUST et qui a eu 0 commentaire, alors que le sujet consacré à C3 en a un plus de 20. ça ne veut rien dire... ou pas.

Pour la gestion mémoire... Déjà, en passant via un système de "partition" de la mémoire, tu évites 90% des alloc/free, et ceux qui restent, s'ils posent soucis à un développeur, je lui conseil de faire une formation en jardinage, ça lui sera plus utile.

Effectivement, pour prototyper, un langage avec GC est mieux indiqué.

Oui, mais comme j'ai répondu à uther, on a rarement le temps de "prototyper", et si on doit souvent repartir du "prototype" pour avancer, et donc choisir directement le bon outil. Et surtout, lorsque l'on montre un prototype, ne jamais montrer d'images 'trop jolie", parce que ça mets dans la tête du client l'impression que le plus dure a déjà été fait. C'est un cas que j'ai souvent connu, et je ne fait plus cette erreur.

Voilà. C'est mon avis et personne n'est obligé de le partager.

Sur ce,

BàT et Peace & Love.

[OuftiBoy]

Ce n'est plus Mozilla qui finance Rust, mais la Rust fondation:
https://foundation.rust-lang.org/members/
dont le membres sont:


Mozilla reste identifiée comme membre fondateur, mais n'est que membre "Silver".

Et derrière Go, il y avait Google, ça n'a pas empêcher que ça ne soit pas une réussite.
Derrière VisualBasic 6, il y avait Microsoft, ce que n'a pas empêcher de faire une VisualBasic.Net et laisser tomber les utilisateur.
Derrière pleins de projets, y'a des gros mastondons, mais ce n'est pas un signe que ça survivera toujours.

La seule constante dans l'univers de l'informatique, c'est le 'C'.
Même Einstein est d'accord avec moi, il a prouvé que E = mC²

BàT et Peace & Love

[floyer]

J’ai proposé « println!("var={}", convert(var)) » dans le cas où le println!("var={var}") ne te convient pas (tu souhaites utiliser ton propre format et pas le trait fmt par défaut).

[OuftiBoy]

Re Salut floyer,

J’ai proposé « println!("var={}", convert(var)) » dans le cas où le println!("var={var}") ne te convient pas (tu souhaites utiliser ton propre format et pas le trait fmt par défaut).

Non, désolé, je n'ai ni l'envie, ni le besoin d'apprendre 'Rust', et il n'y a donc pas de "chose" qui me convienne ou pas dans 'Rust', vu que je ne l'utilise pas.

Parmi d'autres choses dont on peut discuter des heures et refaire le monde autours d'une bonne bière (Belge bien évidemment ), je voulais juste ici noter qu'il y avait moyen de faire plus simple que println!("var={}", convert(var)).

De un parce que dans l'exemple initiale proposé, il y avait un nombre indéfini d'arguments, chose que je n'aime pas non plus dans le 'C' d'ailleurs.

Si println!("var={var}") affiche "var=123", c'est tout à fait acceptable, mais uniquement si 'Rust'
- peut savoir qu'il n'y aura pas de débordement dans la chaine de caractère,
- qu'il est capable de détecter que var est une variable d'un type bien spécifique et sait convertir cette variable en string,

Mais c'est encore mieux s'il peut se débrouiller pour afficher "123" (et que le var={var} n'est pas là pour lui communiquer le "type" de var).

Comment réagit Rust si j'écrit:

let mut var = 46589999999.99999 # je suppose que ça crée une variable de type "float" grâce à la valeur qui lui est assignée.
str = "var={var}"
println!(str)

"var={var}" étant une chaine de 9 caractère,

Donne-t-il une erreur à la compilation ? (car la variable var ne peut contenir la représentation de la chaine 46589999999.99999) qui dépasse 9.
Fait-il un "agrandissement automatique" de var en une chaine capable d'accepter la représentation de la variable var ? (et qui a donc un coût "caché")

Le meilleur, selon moi, c'est que via un print(f"{var}") le compilo peut savoir que:
1. var est un float,
2. réserver à la compilation la bonne taille de la chaine f"{var}" pour ne rien devoir faire à l'exécution dans le pire des cas.
3. Et bien sur savoir économiser un maximum de ram à la compilation si on peut lui dire de n'afficher que 2 décimal et avoir l'affichage sous la forme de de "46589999999.99".

Un autre avantage, c'est qu'en plaçant directement la variable dans les {} on évite des erreurs d'affichage du type:
println!("x={} et y={}", y, x)

Dans tous les cas, le plus court, le plus lisible et le plus simple, c'est f"{x}{y}".

BàT. et Peace & Love

[Uther]

Je suis d'accord, mais en tant que "nouveau" langage, il y avait d'éviter ce genre de lourdeur. J'attache énormément d'importance à la facilité de lecture d'un code. Les ";", y'a moyen de s'en passer, les let aussi, le "!" pour l'appel d'une "macro", il y avait moyen de faire "plus clair", et c'est d'ailleurs quelques choses (l'équivalant du #define en C) qu'on essaye d'éviter, car oui, en 'C' on peut vite introduire des bugs subtil quand on écrit mal une macro.

Pour le point virgule c'est un choix visuel qui n'a clairement pas de conséquence sur la complexité du langage. Par contre, si on a pas de marqueur de fin d'instruction il faut, soit un marqueur de continuation de ligne à la Basic, soit une indentation significative à la Python, soit un système bâtard d'ajout automatique de point-virgule à la JavaScript qui crée des ambiguïtés dans la syntaxe.
Personnellement j'aurais préféré une solution à la Basic, mais franchement quelque soit le choix, ça n'est qu'un détail auquel on se fait très vite.

Le "let", je vois pas comment s'en passer a moins de faire, soit de la déclaration à la C ce qui n'est pas plus simple, soit de la déclaration implicite ce qui est une saloperie que tous les projets sérieux désactivent si possible.

Pour les macros, en effet elles sont dangereuses en C, et d'autant plus trompeuses que la différence avec une simple fonction n'est pas claire.
C'est justement pourquoi, en Rust, la syntaxe d'appel permet de bien les identifier et il y a un système dit d’hygiène qui évite les effets de bord non souhaités.

Oui, le principe de lamda n'existe pas en C. Il existe en Python, mais ce n'est pas une bonne pratique. On peut aussi vite faire une petite fonction, ce que serait bien plus clair.

Pour moi, c'est faire une fonction déportée pour un tout petit bout de code qui a un usage local unique, qui n'est pas une bonne pratique. Je suis d'accord que avoir un nombre magique n'est pas une bonne pratique mais le limites du système de typage font c'est ce qui se fait couramment en C, y compris dans la libc. Utiliser une constante permet d'améliorer un peu visuellement mais le soucis que la vérification peut trop facilement être ignorée reste.
Le système d'enum de Rust et les type Option et Result qui en découlent permettent justement d'avoir une gestion plus claire des cas d'erreur.

Un autre exemple, (qui est aussi un défaut en C comme dans 99% des langages), c'est d'utilisé le signe "=" pour l'assignation. En Pascal, on fait a := a et on peut garde le "=" pour tester une condition.

Le = pour l'assignation n'est pas un soucis en Rust car le résultat d'une assignation est du type unit (équivalent de void en C). Donc utiliser une affectation à la place d'une égalité entrainera une erreur de type.

C'est sécusé d'un point de vue mémoire, très bien, mais sécurisation ne devrait pas venir "de la syntaxe".

Au contraire, la sécurisation ne vient pas de la syntaxe mais du système de type de Rust qui permet d'utiliser le formatage défini pour le type de l’élément à afficher alors qu'en C le formatage dépend de la syntaxe employée dans le pattern.

Le système de "trait" permet à chaque type d'avoir son propre affichage. Mais il y'a certainement moyen que chaque type ai son propre affichage sans devroir créer un nouveau concept (le trait).

Le concept de trait ne sert pas juste pour le formatage de chaine. C'est un élément central du langage qui permet de gérer la généricité et le polymorphisme. Les traits "Display" et "Debug" sont implémentable par un type pour fournir respectivement l'affichage classique et technique, mais ce n'est qu'un cas particulier. On peut définir et implémenter ces propres traits.

crate, c'est un module. L'appeler "module" serait plus clair. C'est une manie dans beaucoup de langage d'intégrer des "nouveau" mot-clé qui veulent dire la même chose qu'un ancien mot clef, ça fait plus 'smart", mais ça n'apporte rien.

En Rust une crate est un module, mais un module n'est pas forcément une crate. C'est difficile de reprocher à Rust de faire comme les autres, vu que les autres n'ont pas non plus des noms et un ordre de hiérarchisation commun entre les modules/packages/assemblies/objets/fichiers/...

cargo, nmp, pip, maven, etc, c'est un bel exemple d'utilisation de nom différent pour un même concept.

Ça revient à dire: Rust, JavaScript, Python, Java, etc autant de noms différents pour un même concept. C'est des outils différents il faut bien le différencier.

[floyer]

Re Salut floyer,
Parmi d'autres choses dont on peut discuter des heures et refaire le monde autours d'une bonne bière (Belge bien évidemment ), je voulais juste ici noter qu'il y avait moyen de faire plus simple que println!("var={}", convert(var)).

Oui, il y a plus simple si tu te contente du formateur par défaut (qui peut être paramétrable). Si tu veux utiliser ta propre fonction pour une fois afficher une couleur sous forme (R,G,B) et une fois sous forme #FFFFFF, là il faut préciser la fonction explicitement.

De un parce que dans l'exemple initiale proposé, il y avait un nombre indéfini d'arguments, chose que je n'aime pas non plus dans le 'C' d'ailleurs.

Si println!("var={var}") affiche "var=123", c'est tout à fait acceptable, mais uniquement si 'Rust'
- peut savoir qu'il n'y aura pas de débordement dans la chaine de caractère,
- qu'il est capable de détecter que var est une variable d'un type bien spécifique et sait convertir cette variable en string,

Mais c'est encore mieux s'il peut se débrouiller pour afficher "123" (et que le var={var} n'est pas là pour lui communiquer le "type" de var).

Comment réagit Rust si j'écrit:

let mut var = 46589999999.99999 # je suppose que ça crée une variable de type "float" grâce à la valeur qui lui est assignée.
str = "var={var}"
println!(str)

Rust réagit par un "error: format argument must be a string literal".

En effet, comme l'indique le !, println n'est pas une fonction (qui pourrait accéder à la valeur de str à l'exécution), mais une macro qui voit ici une "expression". La macro est exécutée à la compilation et génère du code.

Un println!("{var}") est différent... la macro accède à la chaîne de caractère qui lui est donnée directement, et peut remplacer cette expression par une série de fonctions normales appelées avec l'argument var entre autres.

Pour revenir au nombre indéfini d'arguments, c'est réservé aux macros. EN effet un print(1,2.9,"aa") aurait du mal à traiter les différents arguments vu le typage statique.

En revanche la macro verrait 3 expressions, et pourrait générer à la compilation des echo(arg1.to_string());echo(arg2.to_string());echo(arg3.to_string()); et compiler cela. Le to_string() sera ici différent à chaque fois grâce au système de traits associé au typage statique.

L'avantage de la macro est de pouvoir s'ouvrir à d'autre usages. Cela permettrait des choses comme sql!("SELECT {a}, {b} FROM table WHERE id={id}")... la macro analyse la chaîne SQL et génère une fonction qui prend id en entrée et modifie les variables a et b. Derrière le ! il n'y a pas qu'un truc ad'hoc pour les formatage à la Printf.

OCaml a un système de macro aussi (mais plus complexe), et un package apporte des macros qui fait ces opération sur requêtes SQL (avec le typage fort, conversion chaîne vers type pertinent, etc).

Un autre avantage, c'est qu'en plaçant directement la variable dans les {} on évite des erreurs d'affichage du type:
println!("x={} et y={}", y, x)

Dans tous les cas, le plus court, le plus lisible et le plus simple, c'est f"{x}{y}".

Oui, d'ailleurs, on peut le faire en Rust (println!("x={x} et y = {y}"). C'est juste que Rust donne le choix. Pour de simple variables, cette forme est préférable, mais l'autre forme peut être utile pour println!("somme={} et différence = {}", x+y, x-y).

[OuftiBoy]

Pour le point virgule c'est un choix visuel qui n'a clairement pas de conséquence sur la complexité du langage. Si on a pas de marqueur de fin d'instruction il faut un marqueur de continuation de ligne à la Basic ou une indentation significative à la Python, le pire étant la solution bâtarde de JavaScript avec l'ajout automatique de point-virgules qui crée des ambiguïtés dans la syntaxe. Personnellement j'aurais préféré une solution à la Basic, mais franchement quelque soit le choix, ça n'est qu'un détail auquel on se fait très vite.

On est bien d'accord sur le javascript :-)

Mais, je ne suis pas d'accord, il est tout à faire possible de créer une grammaire BNF, qui ne nécessite pas de ";" pour une fin d'instruction et pas de marqueur de continuation. J'en ai donné un exemple que j'utilise pour mon langage, et ça "clarifie" (selon moi) la lecture. Mais le compilateur, je l'ai fait à la main, du début à la fin, et je ne suis pas rester dans les clous. Je te donne un petit exemple:

Pour déclarer des variables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
int8 a, b=2, int16 c, const pas_toucher=6
int16 bidule, machin
 
routine blabla(int8 x,y) <- int8 x,y,err:
end

ça ce compile très facilement, pour une raison très simple, c'est le parser prend en compte où il est, d'où il vient, et où il va aller. "Techniquement", la première ligne n'attend pas de nouvel variable après le 6, parce qu'il n'y a pas de virgule pour dire qu'on attend un nouveau nom de variable.

la seconde ligne recommence un cycle de déclaration de variable, qui se termine aussi après machin, parce qu'il n'y a pas de virgule pour dire qu'on attend une nouvelle variable.

Pour chipoter, tu peux me dire que la ',' est un "marqueur" de continuation qui n'est pas en fin de ligne, mais du point de vue du développeur, ça parait naturel, mais ce "marqueur de continuation de ligne qui n'est pas en fin de ligne", et qui de plus correspond à la manière de séparer les variables, évite le problème du ";" partout et surtout le pire, un caractère de continuation. Je ne sais pas si on sait utiliser les outils YACC & LEX pour produire le parser à partir d'une définition BNF de la grammaire, mais "à la main", c'est d'une facilité déconcertante.

On pourrait après la routine ne pas avoir de ":" ni de "end" à la fin, mais ça structure le code. Il faut épurer et pas ton faire disparaitre, mais ça me demanderait de changer 2 lignes de code pour dire que le "codebloc" de la routine se termine dès qu'il y a une ligne vide.

Et la routine peut retourner plusieurs variables dont les valeurs et un code d'erreur en une fois.

Dans le "let", je vois pas comment s'en passer a moins de faire de la déclaration à la C qui n'est pas plus simple, ou de la déclaration implicite qui est une saloperie que tous les projets sérieux désactivent si possible.

Oui, la déclaration par inférence de type est une fausse bonne idée, mais apparemment, en 'Rust', on peut faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
let mut a=42

C'est un exemple que m'a donné floyed. Je n'ai pas vérifié ci c'était possible ou pas. De toute manière, en grand défenseur du KISS, je n'utilise jamais une fonctionnalité parce qu'elle existe, mais parce que j'en ai besoin.

Pour les macros, en effet elles sont dangereuses en C, et d'autant plus trompeuses que la différence avec une simple fonction n'est pas claire.
C'est justement pourquoi, en Rust, la syntaxe d'appel permet de bien les identifier et il y a un système dit d’hygiène qui évite les effets de bord non souhaités.

Je ne sais pas ce que tu veux dire par "un système d'hygiène", mais je n'ai pas de raison de ne pas te croire. Mais encore une fois, je trouve qu'une vrai fonction inline (et même générique) pourrait faire le taf.

Pour moi, c'est faire une fonction déportée pour un tout petit bout de code qui a un usage local unique, qui n'est pas une bonne pratique. Je suis d'accord que avoir un nombre magique n'est pas une bonne pratique mais c'est ce qui se fait couramment en C, y compris dans la libc. Utiliser une constante permet d'améliorer un peu visuellement mais le soucis que la vérification peut trop facilement être ignorée reste. Le système d'enum de Rust et les type Option et Result qui en découlent permettent justement d'avoir une gestion claire des cas d'erreur.

En fait, ça dépend si ce "petit bout de code" a un usage local ou pas. Rendre la fonction "inline", c'est aussi pouvoir la transformer en fonction normal si on se rend compte qu'en fait elle est moins local que ce qu'on aurait pu penser au départ. Pour les nombres "magiques", même si c'est couramment utilisé, même dans la libc, n'est pas une raison pour le faire sois même également. Et surtout ce n'est pas une raison pour qu'un nouveau langage refasse les mêmes erreurs que d'anciens. Oui, il y a le système d'Enum et les types Options et Result son une bonne chose, mais ça prouve que même si on a à sa disposition une "bonne manière de faire", on utilise à la place "une moins bonne de faire". C'est pareil pour les bloc "unsafe", c'est réservé pour des cas précis, mais ça sera aussi utilisé même quand ce n'est pas nécessaire, tout comme les chiffres magiques. [/QUOTE]

Le = pour l'assignation n'est pas un soucis en Rust car le résultat d'une assignation est du type unit (équivalent de void en C) et pas boolean. Donc utiliser une affectation à la place d'une égalité entrainera une erreur de type.

Oui, mais je préfère différencier clairement l'initialisation de l'assignation, et pouvoir garder le = pour les conditions du genre if a = 1 au lieu du classique if a == 1.

Au contraire, la sécurisation ne vient pas de la syntaxe mais du système de type de Rust qui permet d'utiliser le formatage défini pour le type de l’élément à afficher alors qu'en C le formatage dépend de la syntaxe employée dans le pattern.

Je ne parlais plus du 'C', mais d'utiliser la syntax de 'Rust', en tant que nouveau langage, de la façon la plus simple possible pour le formatage des strings, et là, on a beaucoup à apprendre de Python qui propose la syntaxe la plus lisible.

Le concept de trait ne sert pas juste pour le formatage de chaine. C'est un élément central du langage qui permet de gérer la généricité et le polymorphisme. Les traits "Display" et "Debug" sont implémentable par un type pour fournir respectivement l'affichage classique et technique, mais ce n'est qu'un cas particulier. On peut définir et implémenter ces propres traits.

Je ne connait par trop, je vais regarder ça de plus près pour mon langage, mais ça ressemble à __repr__ et __str__ de Python. Je laisse ce point en suspend avant d'en savoir plus.

En Rust une crate est un module, mais un module n'est pas forcément une crate. C'est difficile de reprocher à Rust de faire comme les autres, vu que les autres n'ont pas non plus des noms et un ordre de hiérarchisation commun entre les modules/packages/assemblies/objets/fichiers/...

Ça revient à dire: Rust, JavaScript, Python, Java, etc autant de noms différents pour un même concept. C'est des outils différents il faut bien le différencier.

Oui, tu as raison, mais bon, si une "crate" est un module, autant l'appeler "module", je ne reproche pas ça spécifiquement à 'Rust', mais je trouve ça inutile, c'est ajouter des termes inutilement. Je vois ce qu'est un module, mais quand j'ai vu crate, je me suis demandé ce que ça pouvais bien signifier, Tout comme j'ai entendu parlé des "traits". Oui, je suis conservateur. On remplace Program par App et ça n'a aucun avantage. Autant utiliser des mots simple que tout le monde comprend que d'utiliser tous les synonymes possible du dictionnaire. C'est un détail, mais si on veux attirer un max de dev dans son écosystème, il me semble préférable d'utiliser des termes ou un langage familier et non pompeux pour faire du neuf avec du vieux.

BàT. et Peace & Love.

[OuftiBoy]

Oui, il y a plus simple si tu te contente du formateur par défaut (qui peut être paramétrable). Si tu veux utiliser ta propre fonction pour une fois afficher une couleur sous forme (R,G,B) et une fois sous forme #FFFFFF, là il faut préciser la fonction explicitement.

Rust réagit par un "error: format argument must be a string literal".

En effet, comme l'indique le !, println n'est pas une fonction (qui pourrait accéder à la valeur de str à l'exécution), mais une macro qui voit ici une "expression". La macro est exécutée à la compilation et génère du code.

Un println!("{var}") est différent... la macro accède à la chaîne de caractère qui lui est donnée directement, et peut remplacer cette expression par une série de fonctions normales appelées avec l'argument var entre autres.

Pour revenir au nombre indéfini d'arguments, c'est réservé aux macros. EN effet un print(1,2.9,"aa") aurait du mal à traiter les différents arguments vu le typage statique.

En revanche la macro verrait 3 expressions, et pourrait générer à la compilation des echo(arg1.to_string());echo(arg2.to_string());echo(arg3.to_string()); et compiler cela. Le to_string() sera ici différent à chaque fois grâce au système de traits associé au typage statique.

L'avantage de la macro est de pouvoir s'ouvrir à d'autre usages. Cela permettrait des choses comme sql!("SELECT {a}, {b} FROM table WHERE id={id}")... la macro analyse la chaîne SQL et génère une fonction qui prend id en entrée et modifie les variables a et b. Derrière le ! il n'y a pas qu'un truc ad'hoc pour les formatage à la Printf.

OCaml a un système de macro aussi (mais plus complexe), et un package apporte des macros qui fait ces opération sur requêtes SQL (avec le typage fort, conversion chaîne vers type pertinent, etc).

Oui, d'ailleurs, on peut le faire en Rust (println!("x={x} et y = {y}"). C'est juste que Rust donne le choix. Pour de simple variables, cette forme est préférable, mais l'autre forme peut être utile pour println!("somme={} et différence = {}", x+y, x-y).

Oui, mais c'est encore plus simple de faire print("la somme est {x+y} et la différence est {x-y}". Mais j'avoue, je taquine un peut. C'est plus étendus que ce qu'on m'avait dit. Si je sais en tirer parti pour mon langage, je m'y pencherais plus sérieusement.

Merci de l'échange courtois, même si on a des points de vue différents. Je suis TRES conservateur (je pense que tu l'as compris), mais je ne suis pas FERME au changement pour autant que la balance bénéfice/KISS, reste du côté du KISS. Changer pour changer ne m'intéresse pas.

BàT et Peace & Love