Discussion :

[floyer]

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.

Regarde https://en.wikipedia.org/wiki/Hygienic_macro (avec un exemple en C)

EN bref, il s'agit d'éviter des conflits et effets de bords entre des variables générées par la macro et les variable de l'environnement d'appel de la macro.

C'est le langage Scheme qui a apporté les macros hygiénique pour pallier au défaut de celles de LISP.

Mais en C, on n'a pas un vrai système de macro.

Code :

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

1
2
#define DEUX 1+1
a = DEUX*2

Te calculera 3 au lieu de 4.

Ainsi, il faut anticiper les usages :

Code :

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

#define ADD(a,b) ((a)+(b))

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.

Un crate n'est pas un module, mais une arborescence de modules. Voir https://web.mit.edu/rust-lang_v1.25/...d-modules.html

Il faut plutôt voir le crate comme une unité de déploiement (comme les packages vcpkg de Microsoft). La commande cargo peut chercher les crates déclarées en dépendance et l'installer. Ensuite, ton programme pourra utiliser mon_crate::fonction1, mais aussi mon_crate::sous_module1::fonction1, etc. Le crate peut comporter plusieurs modules, d'où deux termes. (module est plutôt un namespace C++).

Pour les traits, ce sont comme des interface Java, avec peut-être une différence, la possibilité de définir des méthodes par défaut.

[floyer]

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.

Idem... balance bénéfice / KISS pour moi.

Je regarde Rust avec intérêt. Il y a une bonne communauté. Près de 157 000 crates sur https://crates.io/ (après, parfois, il vaut mieux quelques bons crates/packages que beaucoup de moins bons... pas testé). Mais je n'ai pas fait le pas. En pratique, mon choix actuel est plutôt sur OCaml. Qui présente certaines caractéristiques similaires (typage fort, types algébriques, inférence de type, pattern matching...). Le côté typage fort fait que l'on détecte tôt les erreurs bêtes, et l'inférence de type est pratique avec les types complexes. Par contre OCaml utilise un Garbage Collector (pas d'histoire d'emprunts...). Les performances sont très bonnes (même si on n'est pas au niveau de Rust et C). Il faut aussi se contenter de moins de package (4860).

J'ai trouvé https://blog.darklang.com/first-thou...rust-vs-ocaml/ sur la comparaison entre les deux...

Je n'ai pas de projet multithread... s'il m'arrivait d'en faire, je ne sais pas quelle voie privilégier (Rust intègre des block/fonction async. OCaml l'a ajouté en v5).

[Uther]

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'.

Le problème c'est que ta démonstration repose sur des intuitions, qui résistent mal à l'épreuve des faits. Un rapide regard a l'interminable liste de CVE(dont la grande majorité sont liées à la sécurité mémoire) concernant Linux depuis le début de cette année suffit à la battre en brèche.
Malgré tout le respect que j'ai pour les développeurs qui travaillent sur Linux, ils ne sont clairement pas immunisés contre les erreurs, et particulièrement pas contre les erreurs mémoire.

pas besoin de ";", pas besoin de "let" et "mut" pour dire que c'est "mutable", je préfère de loin le faire à l'envers, et utiliser "const" pour indiquer qu'une variable est une constante.

Moi aussi au début je trouvais surprenante la syntaxe de déclaration dans Rust, mais à l'usage j'ai très vite été convaincu que c'était pour le mieux.
J'avais peur que l'inférence de type face perdre en lisibilité mais j'ai constaté l'inverse, ça évite de trop surcharger la déclaration, surtout qu'en Rust les types sont souvent plus complexes qu'en C car il embarquent plus d'information. Le typage de Rust reste bien plus strict qu'en C et l'inférence reste limitée à la déclaration de variables à l’intérieur d'une fonction.

Pour l'immutabilité par défaut, même si le mot clé mut surprend au premier abord, j'étais dès le début convaincu que c'était pour le mieux. En C, oublier de rendre une variable const peut peut faire passer à coté d'erreurs logiques ou d'optimisations, alors qu'en Rust si on a oublie de rendre une variable mutable, on a une erreur de compilation facile à corriger. Dans le cas particulier de Rust privilégier l'immutabilité est d'autant plus utile car ça apporte beaucoup plus de souplesse vis a vis du borrow checker dont on pourrait résumer le fonctionnement à : "Sur une valeur, il peut y avoir, soit autant de références immuables que l'on souhaite, soit une seule référence mutable."

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

Encore une preuve que la syntaxe est quelque chose de personnel et une question d'habitudes. Pour moi, cette ligne est une horreur absolue en terme de lisibilité.
C'est une construction qui fait vraiment penser a du vieux C ou on déclarait tout en début de block. Depuis le C99 (et même certaines extensions avant) on peut déclarer où l'on souhaite. Ça permet de rapprocher la déclaration de l'usage, ce qui est plus lisible.
Déclarer plusieurs variable en une seule ligne n'est vraiment intéressant d'un point de vue lisibilité que si les valeurs sont intimement liées. Dans ce cas là en Rust le pattern matching peut servir : let (x, y) = (10, 3);

Moi, j'ai choisis l'approche suivante:
fonction exemple(const int8 x,y) <- int8 value, bool err

Je sais pas si c'est volontaire ou non, mais c'est le mécanisme employé par Go (comme pas mal de vos choix de design).
Les cas d'erreurs ne sont plus invisibles, ce qui est un progrès par rapport au C.
Cependant, il me semble avoir lu que cette façon de traiter les erreurs faisait partie des critiques récurrentes des utilisateurs de Go sur le langage (avec l'absence de génériques). C'est très verbeux à l'usage et ignorer l'erreur reste le plus simple syntaxiquement.

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

Et bien tu seras heureux d'apprendre qu'en Rust on peut tout à fait faire :let bonjour = format!("Hello {name}").
On peut, au choix, mettre le nom de la variable dans les crochets, où laisser les crochets anonyme et passer sa valeur en paramètre

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.

L’hygiène fournit une certaine isolation entre le contenu interne de la macro et le reste du code. Par exemple un élément déclarée a l'intérieur de la macro ne sera pas accessible de l'extérieur sauf si son nom est passé en paramètre à la macro.

[floyer]

Je lis : fonction exemple(const int8 x,y) <- int8 value, bool err:

Curieux le sens de la flêche… la fonction sort un type (int8, bool), la flêche naturelle me semble vers la droite comme en OCaml ou Rust.

Le problème avec un tuple en retour est que l’on a vite fait d’oublier de tester l’erreur. Et un boolean peut être pauvre en information.

En Rust comme en OCaml, on a un type algébrique enum Result<T,E> { Ok(value) , Err(err) }. Le principe est d’utiliser le pattern matching pour accéder à la valeur, ce qui oblige à tester si la valeur est Ok… sinon la valeur est inaccessible !

Rust a une notation let v = function(x,y)? qui est un
Raccourci pour

Code :

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

1
2
3
4
 let v = match fonction(x,y) {
        Ok(i) => i,
        Err(e) => return Err(e),
    };

En un caractère, on teste l'absence d’erreur et on accède à la valeur si tout se passe bien. On ne peut pas faire plus concis !

[OuftiBoy]

Idem... balance bénéfice / KISS pour moi.

Je regarde Rust avec intérêt. Il y a une bonne communauté. Près de 157 000 crates sur https://crates.io/ (après, parfois, il vaut mieux quelques bons crates/packages que beaucoup de moins bons... pas testé). Mais je n'ai pas fait le pas. En pratique, mon choix actuel est plutôt sur OCaml. Qui présente certaines caractéristiques similaires (typage fort, types algébriques, inférence de type, pattern matching...). Le côté typage fort fait que l'on détecte tôt les erreurs bêtes, et l'inférence de type est pratique avec les types complexes. Par contre OCaml utilise un Garbage Collector (pas d'histoire d'emprunts...). Les performances sont très bonnes (même si on n'est pas au niveau de Rust et C). Il faut aussi se contenter de moins de package (4860).

Oui, c'est souvant le cas, quelques soit le langage. Mais certains s'en tire mieux que d'autres. Python est très bon avec tous les "wrapper" que tu veux. On entend souvent dire que python est "lent", mais ce n'est pas vrais dans la pratique, il offre une interface vers des lib en C qui vont avec la vitesse qui va avec. NumPy en est un des meilleurs exemples. Et puis lent ou rapide, tout est relatif. Quelque chose de "lent" peut être siffisament rapide suivant les besoins...

Je vais regarder 'Rust' d'un peu plus prêt, pas pour remplacer le 'C' mais pour y puisser d'éventuelles bonnes idées pour mon langage.

Il y a garbage collector et garbage collector. La qualité d'un garbage collector dépend de son implémentation. En gros, soit il se déclenche à un mauvais moment et tu sent le ralentissement, soit il veut tout nettoyer d'un coup, mais on peut aussi faire un GC qui fait son travail petit à petit. Dans un RTOS, si tu veux un GC, tu mets un GC incrémentale dans une tâche de basse priorité, et il s'exécutera que si rien de plus important n'est à faire, et si une task de plus haut priorité est réveillée, elle reprendra la main directement, et le GC sera invisible, laissant toujours la priorité au reste.

J'ai trouvé https://blog.darklang.com/first-thou...rust-vs-ocaml/ sur la comparaison entre les deux...

Désolé, mais je ne connais de Ocaml que le nom. On ne peut pas s'intéresser à tout.

Je n'ai pas de projet multithread... s'il m'arrivait d'en faire, je ne sais pas quelle voie privilégier (Rust intègre des block/fonction async. OCaml l'a ajouté en v5).

Si tu veux faire du multithread, je te conseillerais de regader du côté des RTOS, tu peux regarder à FreeRTOS pour te faire une idée de ce que ça propose, mais si tu veux, avec un peut d'effort, tu peux aussi te faire ton petit RTOS tailler sur mesure pour tes besoins (j'en ai fait une pour un µControlleur Fujitsu qui n'avait que 16k de RAM, et le kernel configurable n'occupait que entre 1 ou 2 Ko suivant les options voulues. Si tu veux avoir un soutient, embOS est intéressant. ça coûte un peu, mais y'a un vrai support derrière.

En plus, ça te donne une découpe "naturelle" de ton donc en regroupant les fonctionnalités par sujet dans une même task.

Y'a aussi le livre µC/OS qui explique très bien les concepts. Je l'avais utilisé pour qu'un bête PC base de gamme ait une résolution de 1ms au lieu des 18,6 par défaut, et ça permettait vraiment de faire des choses intéressantes sans grande difficulté.

Et le multithread, n'est pas toujours la réponse la meilleur quand on pense a faire du code multithread, parfois les coroutines sont suffisantes et plus légères. Tu peux regarder dans Python juste pour te faire une idée. La doc Python est la meilleur doc que j'ai rencontré.

Tu me dis que tu n'as pas sauter le pas pour Rust, et je ne le ferais sans doute pas non plus. On a eu un jour une "rupture de stock" et on a du adapter notre produit phare très vite (en qlq semaines) pour éviter la rupture de stock vers un autre µControlleur. Et on était bien content qu'on avait fais le code en C, car il n'y avait que le C de proposé. Sinon, si on l'avait fait en Rust, on était mort question délais, on aurait du tout réécrire, et la boite aurait perdu des centaines de milliers si pas de millions d'euro. Voilà pourquoi je tiens tant au C, il est toujours là. C'est tout simplement trop dangereux de ne pas utiliser C dans l'embarqué. C'est le seul langage que tu es certains de retrouver partout.

BàT et encore merci pour les franches discutions faites dans le respect.

et biensur Peace & Love

[floyer]

Oui, c'est souvant le cas, quelques soit le langage. Mais certains s'en tire mieux que d'autres. Python est très bon avec tous les "wrapper" que tu veux. On entend souvent dire que python est "lent", mais ce n'est pas vrais dans la pratique, il offre une interface vers des lib en C qui vont avec la vitesse qui va avec. NumPy en est un des meilleurs exemples. Et puis lent ou rapide, tout est relatif. Quelque chose de "lent" peut être siffisament rapide suivant les besoins...

Oui, l’usage de bibliothèques Python reposant sur du C permet d’avoir de bonnes performances même si le langage est plus tôt lent par lui même.

Je vais regarder 'Rust' d'un peu plus prêt, pas pour remplacer le 'C' mais pour y puisser d'éventuelles bonnes idées pour mon langage.

Le système de type (type algébrique notamment) est à récupérer. Cf https://doc.rust-lang.org/book/ch06-...g-an-enum.html (je note que ton language a déjà les tuples.

Il y a garbage collector et garbage collector. La qualité d'un garbage collector dépend de son implémentation. En gros, soit il se déclenche à un mauvais moment et tu sent le ralentissement, soit il veut tout nettoyer d'un coup, mais on peut aussi faire un GC qui fait son travail petit à petit. Dans un RTOS, si tu veux un GC, tu mets un GC incrémentale dans une tâche de basse priorité, et il s'exécutera que si rien de plus important n'est à faire, et si une task de plus haut priorité est réveillée, elle reprendra la main directement, et le GC sera invisible, laissant toujours la priorité au reste.

GC générationel sur OCaml. Donc incrémental.

Désolé, mais je ne connais de Ocaml que le nom. On ne peut pas s'intéresser à tout.

C’est un langage fonctionnel. C’est assez particulier. Il me semble que c’est la famille ML qui a apporté les types algébriques, le pattern matching, le polymorphisme, et l’inférence de type…. En 1973, c’était assez innovant à l’époque.

La syntaxe est cependant très particulière. On écrira à la place de f(a+1,b), f (a+1) b. (Cela permet l’évaluation partielle de fonction…)

Si tu veux faire du multithread, je te conseillerais de regader du côté des RTOS, tu peux regarder à FreeRTOS pour te faire une idée de ce que ça propose, mais si tu veux, avec un peut d'effort, tu peux aussi te faire ton petit RTOS tailler sur mesure pour tes besoins (j'en ai fait une pour un µControlleur Fujitsu qui n'avait que 16k de RAM, et le kernel configurable n'occupait que entre 1 ou 2 Ko suivant les options voulues. Si tu veux avoir un soutient, embOS est intéressant. ça coûte un peu, mais y'a un vrai support derrière.

J’utiliserais plutôt les caractéristiques de Windows ou Linux. Mais bon à savoir si je prends un micro-controlleur.

Et le multithread, n'est pas toujours la réponse la meilleur quand on pense a faire du code multithread, parfois les coroutines sont suffisantes et plus légères. Tu peux regarder dans Python juste pour te faire une idée. La doc Python est la meilleur doc que j'ai rencontré.

Oui, OCaml a des bibliothèques dans ce genre. Elles réimplémente les appels systèmes bloquant pour initier la requête auprès de l’OS et commuter sur une autre coroutine. Depuis OCaml v5, multithread, une bibliothèque peut utiliser un pool de thread pour exécuter des coroutine.

Tu me dis que tu n'as pas sauter le pas pour Rust, et je ne le ferais sans doute pas non plus. On a eu un jour une "rupture de stock" et on a du adapter notre produit phare très vite (en qlq semaines) pour éviter la rupture de stock vers un autre µControlleur. Et on était bien content qu'on avait fais le code en C, car il n'y avait que le C de proposé. Sinon, si on l'avait fait en Rust, on était mort question délais, on aurait du tout réécrire, et la boite aurait perdu des centaines de milliers si pas de millions d'euro. Voilà pourquoi je tiens tant au C, il est toujours là. C'est tout simplement trop dangereux de ne pas utiliser C dans l'embarqué. C'est le seul langage que tu es certains de retrouver partout.

Pour chaque usage, le choix pertinent sera différent… voire il n’y a pas vraiment de choix. il y a le compilateur mrustc qui génère du C… mais pas sûr que cela fonctionne bien avec le C des micro-contrôleurs. Et la finalité est plus le bootstrap de Rustc que de permettre la portabilité.

[NotABread]

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'.

Le problème, c'est les intéractions entre les codes de plusieurs personnes et s'assurer de couvrir tous les cas possible. Même sshd avec un code exmplaire a eu une faille de sécurité à cause d'une concurrence d'évènement et de l'usage d'une fonction non thread safe pour libérer la mémoire.
L'apport de Rust ici est de garantir que le code ne puisse pas être mal utilisé sans le vouloir, ce qui en théorie permet aux revus de code de se concentrer sur le fonctionnel plutôt que la technique.

[OuftiBoy]

Je lis : fonction exemple(const int8 x,y) <- int8 value, bool err:

Curieux le sens de la flêche… la fonction sort un type (int8, bool), la flêche naturelle me semble vers la droite comme en OCaml ou Rust.

J'ai repris la notation de Python. La fléche pointe vers la gauche, car on récupère la sortie de fonction à gauche.

a := fonction(int8 x,y) <- int8, je note ta remarque rien n'est encore figé à l'heure actuel.

Le problème avec un tuple en retour est que l’on a vite fait d’oublier de tester l’erreur. Et un boolean peut être pauvre en information.

Actuellement, ce n'est pas un tuple, mais une simple suite de variables, non liés/groupée entre elles. ça peut être un tuple, mais alors l'utilisateur devra le spécifier. Si la fonction retourne un code d'erreur dans la suite de variable, et que cette variable n'est pas utilisée, une erreur ou un warnign sera levé. J'hésite encore a créer un type "error" bien spécifique, c'est en rélextion dans mon petit cerveau.

En Rust comme en OCaml, on a un type algébrique enum Result<T,E> { Ok(value) , Err(err) }. Le principe est d’utiliser le pattern matching pour accéder à la valeur, ce qui oblige à tester si la valeur est Ok… sinon la valeur est inaccessible !

Je comprend l'approche. L'idée que l'erreur soit un des type de valeur a traiter comme une autre, via le pattern matching, j'adhère et j'y avais pensé, c'est de là que vient l'idée de retourner plusieurs valeur. Mais l'idée derrière le langage, c'est de rester simple à lire sans mettre trop de fonctionnalités.

Rust a une notation let v = function(x,y)? qui est un
Raccourci pour

Code :

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

1
2
3
4
 let v = match fonction(x,y) {
        Ok(i) => i,
        Err(e) => return Err(e),
    };

En un caractère, on teste l'absence d’erreur et on accède à la valeur si tout se passe bien. On ne peut pas faire plus concis !

Oui ça semble bien fait, mais je n'ai pas la prétention de créer un langage de l'envergure de Rust/C++ ou Python. Le But ptemier de ce langage, c'est de facilité la création de jeux en 2D style Rétro année 80's. Ainsi que de pouvoir faire des program style "mode texte" (pas de type console, mais dans l'idée de pouvoir se passer complètement de souris)

Merci du retour, si tu veux, quand j'aurais quelque chose d'assez "fournit" pour être utilisable, je t'en dirait plus.

BàT et Peace & Love.

[pcdwarf]

ouais... alors les "mégalomanes pédants et condescendants", il sont peut-être désagréables, mais en général, ils maitrisent leur sujet. C'est d'ailleurs la raison pour laquelle ils sont vu comme pédants et condescendants alors que souvent ils sont juste compétant et exigents.

Simple curiosité, j'ai un peu regardé ce que c'était que Rust. Et j'avoue que j'ai pas été convaincu que ça présente tellement d’intérêt par rapport à du C.
Je m'attendais à un langage ressemblant à C mais avec plus de garde-fous. Finalement, j'ai eu du mal ne serais-ce qu'a en lire.

En fait, je m'attendais à ce qu'une part de C++ finisse par entrer dans le noyau malgré les réticences de Torvalds mais pas à ce qu'il pousse un langage aussi différent.

Le problème va être la maintenabilité.
ça suppose que beaucoup de dev deviennent compétents dans ce langage...
Il y aura des spécialistes de l'un et de l'autre. ça ne me semble pas être une bonne chose question organisation.

[OuftiBoy]

ouais... alors les "mégalomanes pédants et condescendants", il sont peut-être désagréables, mais en général, ils maitrisent leur sujet. C'est d'ailleurs la raison pour laquelle ils sont vu comme pédants et condescendants alors que souvent ils sont juste compétant et exigents.

Je n'ai pas fréquenté la communauté 'Rust'. Ici sur développer.com, il y a des participants de tout niveau, ça va des fanatiques décérébrés à des gens très compétants. Et oui, des fois, quand on a raison (et si c'est contre l'avis d'une majorité), c'est parfois difficile de se faire entendre. Je ne prétend pas avoir LA vérité, mais il me faut de solides arguments pour me convaincre. On peut être compétant, mais ce n'est pas une raison pour rabaisser les autres. Il faut garder un seine humilité sincère, car on tous des choses à apprendre des autres. Tant que la discution reste polie et non fanatisée, j'aime bien participer.

Simple curiosité, j'ai un peu regardé ce que c'était que Rust. Et j'avoue que j'ai pas été convaincu que ça présente tellement d’intérêt par rapport à du C. Je m'attendais à un langage ressemblant à C mais avec plus de garde-fous. Finalement, j'ai eu du mal ne serais-ce qu'a en lire.

Oui, Rust (que je connais pas profondément, mais dont j'essaye de comprendre les forces, et les faiblesses) apporte des "avançées" par rapport au 'C', mais oui, c'est via des concept et construction assez éloignée du C. Rust s'imposera peut-être dans la séries des grands langages reconnus, mais je reste persuadé qu'il ne remplacera pas le 'C'. Mais il apporte de bonnes idées, mais qui ne sont pas aussi révolutionnaire que ça. ça dépend de ton niveau en C.

En fait, je m'attendais à ce qu'une part de C++ finisse par entrer dans le noyau malgré les réticences de Torvalds mais pas à ce qu'il pousse un langage aussi différent.

Honnêtement, si il doit y avoir 2 langages dans la base de code linux, je ne pense pas que C++ soit une bonne idée. ça aurait pu l'être, j'adorait le C++ à ces début. Mais maintenant, je suis dégouté de ce qu'il est devenu.

Le problème va être la maintenabilité.
ça suppose que beaucoup de dev deviennent compétents dans ce langage...
Il y aura des spécialistes de l'un et de l'autre. ça ne me semble pas être une bonne chose question organisation.

Oui, c'est le danger, il faudra des développeurs de haut niveau autant en C qu'en 'Rust'. Perso, même si Rust propose de bonnes chose, une base de code avec un seul langage (le C), ça reste plus sécure. Rust est encore jeune, il évolue encore. Mias le C est là pour longtemps, et est disponible partout, c'est la "brique" fondamentale de l'informatique, et il n'est pas près de disparaître. Il évite des erreurs qu'on peut facilement faire un 'C', mais c'est comme quand on élève un enfants, il faut laisser faire des erreurs pour en tirer des leçons et progresser. Les devs qui ne connaissent pas le bas niveau, sont souvent moins compétants que ceux qui sont passés par l'assembleur et le C.

BàT. et Peace & Love.

[floyer]

Effectivement, Rust est loin d’un C amélioré… il emprunte pas mal de choses à différents langages (types algébriques et pattern matching ML, async Javascript, tableau ADA (la taille du tableau est échangé acec le tableau s’il est de taille variable), traits ?, macro Scheme?, RAII C++). Avec des choses originales (emprunts, gestion des erreurs). S’il est positionné comme une alternative au C c’est plus car il a de bonnes performances aussi. Il possède aussi des constructions facilitant l’interface au C.

[Uther]

Simple curiosité, j'ai un peu regardé ce que c'était que Rust. Et j'avoue que j'ai pas été convaincu que ça présente tellement d’intérêt par rapport à du C.
Je m'attendais à un langage ressemblant à C mais avec plus de garde-fous. Finalement, j'ai eu du mal ne serais-ce qu'a en lire.

Oui Rust n'est pas une surcouche de C comme C++. Il faut apprendre ses particularités, qui ne sont tout de même pas si complexes que ça en ce qui concerne la syntaxe elle même. Ça reste un langage impératif, techniquement plus simple que le C++ moderne.

Le problème va être la maintenabilité.
ça suppose que beaucoup de dev deviennent compétents dans ce langage...

C'est pas faux, mais il faut aussi prendre en compte que Rust a quand même un avantage pour la maintenabilité par rapport au C : dans la plupart des cas le code techniquement problématique ne compile juste pas.
Un développeur avec peu d'expérience en Rust risque de mettre plus longtemps qu'un expert avant d'arriver au résultat qu'il veut, mais la fiabilité devrait être au rendez vous. Alors qu'avec d'autre langages il y aurait clairement plus de risques.

[OuftiBoy]

Le problème c'est que ta démonstration repose sur des intuitions, qui résistent mal à l'épreuve des faits. Un rapide regard a l'interminable liste de CVE(dont la grande majorité sont liées à la sécurité mémoire) concernant Linux depuis le début de cette année suffit à la battre en brèche. Malgré tout le respect que j'ai pour les développeurs qui travaillent sur Linux, ils ne sont clairement pas immunisés contre les erreurs, et particulièrement pas contre les erreurs mémoire.

Ce ne sont pas des intuitions, c'est mon vécu. Je ne dis pas que C est meilleur que Rust ou l'inverse, ça n'aurait aucun sens. Je ne dis pas qu'on ne peut pas faire d'erreur en 'C', j'ai simplement dis que, personellement, je n'ai jamais eu de soucis a utiliser alloc/free.

Je ne suis contre ni pour rien, et je n'ai pas tenté de faire une démonstration, j'ai juste exprimé un point de vue: Le fait d'avoir 2 langages dans une base de code rend forcément la chaine de production plus lourde, et que si 'Rust' veut entrer dans le noyau 'linux', c'est à eu de faire la démarche et pas l'inverse.

Moi aussi au début je trouvais surprenante la syntaxe de déclaration dans Rust, mais à l'usage j'ai très vite été convaincu que c'était pour le mieux.

Voilà, on y est, tu as peut-être regarder Rust bien avant moi, et les questions que je me pose tu semble te les avoir poséee aussi. Tu as peut-être simplement plus d'avance sur moi, et que je rendrais plus tard que j'avais tord (ou pas), tout comme toi.

J'avais peur que l'inférence de type face perdre en lisibilité mais j'ai constaté l'inverse, ça évite de trop surcharger la déclaration, surtout qu'en Rust les types sont souvent plus complexes qu'en C car il embarquent plus d'information. Le typage de Rust reste bien plus strict qu'en C et l'inférence reste limitée à la déclaration de variables à l’intérieur d'une fonction.

Tu as toi même déclaré que tout bon langage qui se respecte évite l'inférence de type, et là tu me dis le contraire, j'ai un peux de mal à suivre. Si ce n'était pas toi (beaucoups de post en se moment, je mélange peut-être, dans ce cas, excuse-moi d'avance). Je ne suis ni pour ni contre l'inférence de type. Mais je trouve plus clair de savoir explicitement quel est le type de la variable que je crée. Avec l'inférence de type, on peut vite penser qu'une variable est d'un type alors qu'elle est d'un autre ou qu'on voudrait qu'elle soit d'un autre, même si le compilateur provoquera une erreur en cas d'utilisation d'un mauvais de ce type par après.

Ce n'est pas parce que l'on crée une variable via a = 12, qu'on veut que cette variable soit un byte, on peut vouloir créer un word et lui affecter la valeur 12.

Pour l'immutabilité par défaut, même si le mot clé mut surprend au premier abord, j'étais dès le début convaincu que c'était pour le mieux. En C, oublier de rendre une variable const peut peut faire passer à coté d'erreurs logiques ou d'optimisations, alors qu'en Rust si on a oublie de rendre une variable mutable, on a une erreur de compilation facile à corriger. Dans le cas particulier de Rust privilégier l'immutabilité est d'autant plus utile car ça apporte beaucoup plus de souplesse vis a vis du borrow checker dont on pourrait résumer le fonctionnement à : "Sur une valeur, il peut y avoir, soit autant de références immuables que l'on souhaite, soit une seule référence mutable."

Le "mut" ne fait pas que surprendre au début, il alourdi la lecture du code.
Peut-être, mais c'est comme le "let", ça alourdi la lecture, une chose qui moi me dérange.
On utilise plus de variable mutable (d'ou le nom variable) que de constante, et donc, il me semble plus logique pour un code clair, d'utiliser const uniquement quand c'est nécessaire. Et, franchement, dire qu'en C on peut oublier de déclarer une variable en tant que constante, c'est un peu léger. SI on pousse le bouchon, on peut aussi dire qu'on peut oublier de mettre en "mut", vu qu'il en faut partout. L'important, c'est que le compilo détecte l'erreur pour toi.

Mais bon, même si c'est possible, c'est de facto un argument pour 'Rust', mais qui ne peut motiver un changement de langage quand même, faut pas exagérer...

Encore une preuve que la syntaxe est quelque chose de personnel et une question d'habitudes. Pour moi, cette ligne est une horreur absolue en terme de lisibilité. C'est une construction qui fait vraiment penser a du vieux C ou on déclarait tout en début de block. Depuis le C99 (et même certaines extensions avant) on peut déclarer où l'on souhaite. Ça permet de rapprocher la déclaration de l'usage, ce qui est plus lisible.
Déclarer plusieurs variable en une seule ligne n'est vraiment intéressant d'un point de vue lisibilité que si les valeurs sont intimement liées. Dans ce cas là en Rust le pattern matching peut servir : let (x, y) = (10, 3);

J'ai juste, par cet ligne, démontré qu'il y avait moyen de ne pas avoir des ";" ou de caractères de continuation, ce que tu semblait sous entendre pour justifier des ";" partout. C'était le point de la discution. Ce n'est pas quelque chose que j'écrirai.

De plus, tu fais des suppositions, car dans mon petit langage on peut aussi déclarer une variable où on le souhaite, et rapprocher la déclaration de l'usage. On peut regrouper les variables suivant leur type et/ou leur relation. Et on peut forcer l'utilisation de majuscule pour le nom d'une constante.

Et quant bien même, un bloc ne devrait jamais être aussi long qu'une déclaration seulement permise en début de bloc ne pose problème. Evidemment, si on écrit des fonctions de 1000 lignes, ça poserait soucis. Une fonction ne devrait pas dépasser un certains nombre de ligne, et en tout cas être visible en une seul fois sur l'écran. D'ailleurs, je compte bien imposer une limite de ligne de code dans une fonction, ainsi qu'une longeur de ligne.

Le let (x, y) = (10, 3); peut s'écrire [CODEINLINE]x,y := 10,3[CODEINLINE] dans mon petit langage, et ce n'est pas via un tuple. C'est (de mon point de vue) plus lisible et moins sujet à une mauvaise lecture. Et moins verbeux, c'est évident me semble-t-il.

Dans ton ton exemple, un débutant on pourrait croire qu'on teste une équivalance entre (x,y) et (10,3), d'où lidée d'avoir prit ':=' pour l'assignation et le "=" pour l'initialisation. ça permet de faire un if x = 1 ou lieu de if x == 1. Ce qui est plus naturelle pour un débutant que le '==' (que je n'aime pas non plus en C) pour un test d'équivalance. Et on peut évidemment écrire les variables comme on le souhaite et même imposer un certains formalisme via des options. C'est un langage en développement, rien n'est encore figé actuellement. J'explore des pistes pour avoir un langage simple, mais lisible et "complet" pour le but que je me suis fixé pour ce langage.[/QUOTE]

Je sais pas si c'est volontaire ou non, mais c'est le mécanisme employé par Go (comme pas mal de vos choix de design).
Les cas d'erreurs ne sont plus invisibles, ce qui est un progrès par rapport au C.

Et bien tu suppose mal. Je n'ai jamais regardé le moindre code en "Go", mais je prend comme un compliment le fait que j'ai eu dans ma petite tête, seul, trouver quelque chose qu'une équipe entière de dév Google on pensé.

Cependant, il me semble avoir lu que cette façon de traiter les erreurs faisait partie des critiques récurrentes des utilisateurs de Go sur le langage (avec l'absence de génériques). C'est très verbeux à l'usage et ignorer l'erreur reste le plus simple syntaxiquement.

Je veux bien tout entendre, mais dire que c'est verbeux, non. Et ce mécanisme n'est pas là que pour "traiter" les erreurs.

[QUOTE=Uther;12042938]
Et bien tu seras heureux d'apprendre qu'en Rust on peut tout à fait faire :let bonjour = format!("Hello {name}").
On peut, au choix, mettre le nom de la variable dans les crochets, où laisser les crochets anonyme et passer sa valeur en paramètre

Très bien le let bonjour = format!("Hello {name}"), mais c'est encore plus court et clair de faire:
bonjour := f"Hello {name}", ne trouve tu pas ?

L’hygiène fournit une certaine isolation entre le contenu interne de la macro et le reste du code. Par exemple un élément déclarée a l'intérieur de la macro ne sera pas accessible de l'extérieur sauf si son nom est passé en paramètre à la macro.

Je suis anti macro autant qu'anti macron

Les macro ne sont en rien nécessaires pour pouvoir écrire un code correct, clair et lisible. Quand tu dis "sauf si son nom est passé en paramètre à la macro", tu accepteras donc volontier que cette "erreur" est possible même pour utilisateur Rust à la pointe, tout comme un excellent développeur 'C' peut lui aussi commetre ce genre d'erreur ? C'est pourquoi il n'y aura pas de "macro" dans mon petit langage, car on ne peut pas se tromper sur quelque chose qui n'existe pas.

BàT et Peace & Love.

[floyer]

Quand tu dis "sauf si son nom est passé en paramètre à la macro", tu accepteras donc volontier que cette "erreur" est possible même pour utilisateur Rust à la pointe

Non, il n’y a pas erreur. Si tu tapes en Rust println!("{}",a); tu souhaites que la macro accède à la variable a, mais sans conflit avec une éventuelle variable interne et homonyme de la macro.

Tu souhaites aussi qu’elle n’accède pas aux autres variables. C’est ce que t’assure les macros hygiéniques où il n’y a pas d’effet de bord entre les variables internes à la macro et les variables du code appelant si par hasard elles avait le même nom.

Reprend l’exemple de la page Wikipedia:

#define INCREMENTE(i) { int a=0; ++i; }

Tu vois tout de suite qu’en appelant INCREMENTE(a)… tu ne vas pas avoir le bon résultat. Les macros hygieniques (Scheme, Rust), font comme si les variables internes (ici a) étaient renommées pour éviter tout conflit.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
macro_rules! incremente {
  ($variable:expr) => {
    let a = 1;	  
    $variable = $variable + a;
  }
}
 
fn main()
{
  let mut a = 7;
  incremente!(a);
  println!("{}",a);
}

Il y a deux variables a... et Rust ne se mélange pas les pinceaux. (On n'a pas une bête substitution par a = a + a; )

SI on pousse le bouchon, on peut aussi dire qu'on peut oublier de mettre en "mut", vu qu'il en faut partout. L'important, c'est que le compilo détecte l'erreur pour toi.

En C++, si tu ne déclare pas tes variables "const" lorsqu'elles pourraient l'être, le compilateur ne te dira rien... C'est l'intérêt de l'approche inverse. Si le compilateur ne détecte pas de problème avec ta variable immuable, autant qu’elle le reste. Sinon, il te prévient et peut même te suggérer la modification.

Code :

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

1
2
3
4
5
 
help: consider making this binding mutable
   |
10 |   let  mut a = 7;
   |        +++

[Uther]

Ce ne sont pas des intuitions, c'est mon vécu. Je ne dis pas que C est meilleur que Rust ou l'inverse, ça n'aurait aucun sens. Je ne dis pas qu'on ne peut pas faire d'erreur en 'C', j'ai simplement dis que, personellement, je n'ai jamais eu de soucis a utiliser alloc/free.

Je ne remet pas en cause tout ton vécu personnel, mais il n'est pas forcément généralisable au noyau Linux. Dans les faits, les CVE due aux erreur mémoires sont là et en grand nombre.

Tu as toi même déclaré que tout bon langage qui se respecte évite l'inférence de type, et là tu me dis le contraire, j'ai un peux de mal à suivre.

Je pense en effet que tu dois confondre avec quelqu'un d'autre ou que tu a mal compris ce que je disais. Je suis pas fan du typage dynamique(le type peut changer après la déclaration) et les déclarations implicites(pas besoin de déclarer le nom d'une variable avant de l'utiliser) sont un conneries, mais je suis pas contre l'inférence (le type défini à la compilation et ne bougera pas. On est juste dispensé de le préciser sur la ligne let, tant que le compilateur peut le déterminer sans ambiguïté.)

Mais je trouve plus clair de savoir explicitement quel est le type de la variable que je crée. Avec l'inférence de type, on peut vite penser qu'une variable est d'un type alors qu'elle est d'un autre ou qu'on voudrait qu'elle soit d'un autre, même si le compilateur provoquera une erreur en cas d'utilisation d'un mauvais de ce type par après.
Ce n'est pas parce que l'on crée une variable via a = 12, qu'on veut que cette variable soit un byte, on peut vouloir créer un word et lui affecter la valeur 12.

Si on le souhaite, on peut tout a fait forcer un type, mais c'est rarement nécessaire. La plupart du temps le compilateur n'a pas de problème a inférer la taille nécessaire, en évitant au passage les erreurs qui pourraient survenir d'un mauvais choix qui entrainerait une conversion auto. L'inférence détermine à la déclaration le bon type pour la variable en fonction des endroit ou elle sera utilisée et en cas d'incohérence, on a une erreur de compilation et pas de conversion automatique qui pourraient engendrer un bug.

Peut-être, mais c'est comme le "let", ça alourdi la lecture, une chose qui moi me dérange.

Au contraire let est un mot unique de trois lettres, utilisé en tout début de ligne pour toutes les déclarations : clair et efficace. En C, il faut obligatoirement faire précéder le nom de la variable par le type qui fera probablement souvent plus de 3 lettres. Les types en Rust étant plus souvent plus complexes(générique, lifetime,..) et donc verbeux il est d'auant plus pratique de ne pas avoir a les écrire a chaque fois, surtout que l'on a le plus souvent pas besoin de connaitre dans tous les détails.

Le "mut" ne fait pas que surprendre au début, il alourdi la lecture du code.

Pas vraiment plus que si on utilise const partout où c'est possible en C. A l'usage je me suis rendu compte que j'avais bien moins besoin de variables mutable que je le croyais.

Mais bon, même si c'est possible, c'est de facto un argument pour 'Rust', mais qui ne peut motiver un changement de langage quand même, faut pas exagérer...

Je ne dis évidement pas pas que ça suffit à motiver un changement de langage, c'est toi qui disais que c'était un problème pour changer. Mon argument c'est que ça n'en est un que si on refuse de voir au delà des habitudes du C, ça peut même être vu comme un avantage.

Et bien tu suppose mal. Je n'ai jamais regardé le moindre code en "Go", mais je prend comme un compliment le fait que j'ai eu dans ma petite tête, seul, trouver quelque chose qu'une équipe entière de dév Google on pensé.

Pour le coup tu devrais jeter un coup d'oeil, il y a pas mal d'autres trucs dans le langage Go qui ressemblent à ton langage perso.

Je veux bien tout entendre, mais dire que c'est verbeux, non. Et ce mécanisme n'est pas là que pour "traiter" les erreurs.

N'ayant pas fait moi même de Go, je ne pourrais être totalement affirmatif mais c'est la seconde complainte que j'ai lu le plus à propos de Go derrière l'absence de générique (qui a été maintenant corrigée il me semble).

Très bien le let bonjour = format!("Hello {name}"), mais c'est encore plus court et clair de faire:
bonjour := f"Hello {name}", ne trouve tu pas ?

Là on est dans le pur chipotage. j'aurais de quoi répondre, mais on est assez hors sujet. C'est quasiment équivalent.

Les macro ne sont en rien nécessaires pour pouvoir écrire un code correct, clair et lisible.

Je préfère aussi éviter les macro, mais il faut reconnaitre que parfois si, c'est utile pour améliorer le code. Ça peut par exemple permettre, d'éviter des cas de code recopié.

Quand tu dis "sauf si son nom est passé en paramètre à la macro", tu accepteras donc volontier que cette "erreur" est possible

Pas vraiment car l'utilisation du paramètre d'une macro peut difficilement être accidentelle. Pour te donner un exemple d'une macro bidon qui définit une variable dont le nom est passée en paramètre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
macro_rules! def_var {
    ($variable:ident) => {
        let interne = 10;
        let $variable = interne;
    }
}
fn main() {
    def_var!(externe);
    println!("{externe}"); // affiche 10
    // println!("{interne}"); // erreur la variable interne n'est pas accessible hors de la macro
}

même pour utilisateur Rust à la pointe, tout comme un excellent développeur 'C' peut lui aussi commettre ce genre d'erreur ?

Même si dans ce cas là ça ne marche pas, il reste bien sur des erreurs possibles en Rust et des chose auxquelles faire attention, mais le langage est quand même bien pensé pour en éviter le plus possible, là ou la philosophie du C, c'est que le programmeur se débrouillera.

C'est pourquoi il n'y aura pas de "macro" dans mon petit langage, car on ne peut pas se tromper sur quelque chose qui n'existe pas.

Ou on peut se tromper en ne corrigeant que partiellement un code dupliqué alors qu'avec une macro on aurait tout corrigé partout.
Même si je suis d'accord qu'il serait trop complexe pour un projet solo de faire des macro hygiéniques et que du coup il vaut mieux s'en passer que de recourir au système cassé du C.

[OuftiBoy]

Je ne remet pas en cause tout ton vécu personnel, mais il n'est pas forcément généralisable au noyau Linux. Dans les faits, les CVE due aux erreur mémoires sont là et en grand nombre.

Je pense en effet que tu dois confondre avec quelqu'un d'autre ou que tu a mal compris ce que je disais. Je suis pas fan du typage dynamique(le type peut changer après la déclaration) et les déclarations implicites(pas besoin de déclarer le nom d'une variable avant de l'utiliser) sont un conneries, mais je suis pas contre l'inférence (le type défini à la compilation et ne bougera pas. On est juste dispensé de le préciser sur la ligne let, tant que le compilateur peut le déterminer sans ambiguïté.)

TU as dis ceci quelques post plus haut : 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.

J'en ai déduis que tu parlais de ce que l'on nomme communément "l'inférence de type".

Si on le souhaite, on peut tout a fait forcer un type, mais c'est rarement nécessaire. La plupart du temps le compilateur n'a pas de problème a inférer la taille nécessaire, en évitant au passage les erreurs qui pourraient survenir d'un mauvais choix qui entrainerait une conversion auto. L'inférence détermine à la déclaration le bon type pour la variable en fonction des endroit ou elle sera utilisée et en cas d'incohérence, on a une erreur de compilation et pas de conversion automatique qui pourraient engendrer un bug

C'est une question de point de vue, je préfère l'explicite à l'implicite. let mut a = 12 et qu'on veut que 'a' soit au final un word, je préfère écrire int16 a=12. Oui, le compilateur détectera l'erreur si tu utilise ton 'a' comme un word par après. Que fera-tu ? Où vas-tu intervenir pour effectuer la correction ?

Au contraire let est un mot unique de trois lettres, utilisé en tout début de ligne pour toutes les déclarations : clair et efficace. En C, il faut obligatoirement faire précéder le nom de la variable par le type qui fera probablement souvent plus de 3 lettres. Les types en Rust étant plus souvent plus complexes(générique, lifetime,..) et donc verbeux il est d'auant plus pratique de ne pas avoir a les écrire a chaque fois, surtout que l'on a le plus souvent pas besoin de connaitre dans tous les détails.

C'est peut-être un mot unique de trois lettres, mais qui est répétitif, donc "loud et pénible". Tu dis que c'est clair et efficace, je dis que c'est inutile et lourd. Je ne pense pas qu'on tombera d'accord là deçus. Et oui, je préfère voir clairement le type d'une variable, au moins ça sert a quelque choses. Si de plus les types de sont souvent plus complexe et verbeux en Rust (c'est toi qui le dit), je trouve encore plus important de bien les préciser lorsque l'on crée une variable.

Pas vraiment plus que si on utilise const partout où c'est possible en C. A l'usage je me suis rendu compte que j'avais bien moins besoin de variables mutable que je le croyais.

Euh, la j'ai un peut de mal a accepter ton argument. Je n'ai jamais vu une base de code pour un projet (petit ou grand), où il y avait plus de constantes que de variables. De plus, une constante, je l'exprime uniquement en MAJUSCULE, donc pas besoin d'aller voir plus loin si c'est une variable ou une constante, et si j'essaye d'utiliser la constante et de lui assigner une valeur, j'irais vite consulter un occuliste, en plus du message d'erreur que me donnera même le compilateur 'C'.

Je ne dis évidement pas pas que ça suffit à motiver un changement de langage, c'est toi qui disais que c'était un problème pour changer. Mon argument c'est que ça n'en est un que si on refuse de voir au delà des habitudes du C, ça peut même être vu comme un avantage.

Je ne refuse pas de voir plus loin que le 'C', puisque l'on discute de Rust depuis pas mal de temps Et cela dans le cadre d'une éventuelle utilisation de ce dernier dans Linux, construit en C depuis 30 ans. Que ce soit Rust ou n'importe quoi d'autre, mélanger 2 (puis plusieurs une fois que la porte sera ouverte), risque de rendre la base de code plus difficile a maintenir.

Il y a une part d'émotionnelle dans l'histoire, je ne le nie pas, mais je le comprend. Voilà une équipe d'anciens et talentueux développeurs 'C' qui ont fait de linux ce qu'il est aujourd'hui, en y mettant beaucoups d'énergies. Ils tentent de garder la main sur leur projet, face à des développeur "Rust" qui pour le moins, ne font pas preuve d'une grande humilité.

.
Pour le coup tu devrais jeter un coup d'oeil, il y a pas mal d'autres trucs dans le langage Go qui ressemblent à ton langage perso.

Je me base sur ce que je connais bien: "C", "Pascal", "Python", "Assembleur", et "Ada/Rust (que j'essaye de découvrir)" pour le côté sécurité. Je n'irais pas voir plus loin. C'est comme avec la théorie, j'ai regarder le "Dragon Book" et un ouvrage de Knuth sur Oberon. Une fois que j'ai bien eu en tête la théorie suffisante, je n'ai plus ouvert un seul bouquin, pour ne par être "influencé", quitte a redécouvrir des techniques qui existent déjà, mais qui me permet aussi d'explorer des possibilités qui ne sont pas "inscrite dans le marbre" et/ou rejetée part la majorité des "théoriciens" des langages. Si je me trompe, et bien j'en tirerais des leçon et je me remettrai à l'ouvrage. Parce que c'est plus amusant de (re)découvrir des choses, des idées, que de mettre en pratique des théories établient par d'autres personnes. Parce que si je faisait comme ça, je n'apprendrais pas grand chose, ce serait moins amusant, et ça aurait peux d'intérêt pour moi. A ce compte là, autant utiliser une IA. Se dont je me refuse à faire, tout comme je ne veux pas utiliser YACC ou LEX. Je veux être responsable de la moindre ligne de code de mon projet/langage.

Une petite anecdote. Très jeune, sur mon C64 (je devais avoir 14 ans), sans accès à aucun bouquin, j'ai fait une routine de tri en basic). Oh, rien de magique, et j'ai remarqué que plus la liste a trié était grande, plus le tri prenait du temps. Je ne comprenais pas pouquoi. Le tri ne devait se faire que sur des listes assez courte, et ma "technique" de tri était suffisante pour ce qu'elle devait traiter. 1 ou 2 ans plus tard, je me suis rendu compte que j'avais réinventer le "Bubble Sort", de loin la mois bonne solution, mais j'étais quand même fier d'avoir trouver tout seul une "technique de tri" déjà découverte par d'autres.

N'ayant pas fait moi même de Go, je ne pourrais être totalement affirmatif mais c'est la seconde complainte que j'ai lu le plus à propos de Go derrière l'absence de générique (qui a été maintenant corrigée il me semble).

Désolé, mais si tu ne mets pas en citation à quel partie de message tu me réponds, j'ai du mal a te répondre.

Là on est dans le pur chipotage. j'aurais de quoi répondre, mais on est assez hors sujet. C'est quasiment équivalent.

Oui, c'est du chipotage, mais des fois tu chipote aussi, alors je me permet de le faire

Mais je prend TOUT ce qui peut améliorer la lisibilité d'un code (même un rien), même le moindre "chipotage". J'ai peut-être un toc de ce côté, mais ça m'a tellment été profitable, que c'est un réflexe. Si on peut écrire 1 ligne de moins, ou même éviter de devoir écrire 1 ligne en repensant la manière dont j'ai implémenter quelque chose, je le fais. C'est par exemple quelque chose qui est fréquent en code Python. Tu peux vite écrire une routine qui fait le taf et avoir quelques chose qui "fonctionne" (c'est quand même le but premier). Mais ensuite, avec un peu de réflection, tu peux simplifier ta première solution qui prenais 20 lignes en une solution plus clair, plus lisibile qui n'en prend plus que 5.

Oui, j'ai un côté "perfectionniste à l'extrême", je suis comme ça. Mais une chose est certaine, c'est moins de code tu écrits, moins de bugs tu fais. Le code à ne pas devoir écrire est le code parfait

Je préfère aussi éviter les macro, mais il faut reconnaitre que parfois si, c'est utile pour améliorer le code. Ça peut par exemple permettre, d'éviter des cas de code recopié.

Je te rasssure, je ne fais jamais de copier/coller. C'est une horreur absolue. J'ai eu un collègue qui ne faisait que ça, qui nommait ces variables de v1 à v14, et qui pour une nouvelle version d'un outils, copiait carrément le code source entier de la version précédente de l'outil en question avant d'apporter les modifications demandée. J'ai alerté mon N+1 que si on l'autorisait a pratiquer de la sorte, il ne faudra pas me demander de réparer les dégâts. Mais les camas des camas dans une entreprise, si tu t'y attaque, t'es mort, t'es le gars qui cherche les problèmes. C'est malheureux, mais c'est ainsi.

Pas vraiment car l'utilisation du paramètre d'une macro peut difficilement être accidentelle. Pour te donner un exemple d'une macro bidon qui définit une variable dont le nom est passée en paramètre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
macro_rules! def_var {
    ($variable:ident) => {
        let interne = 10;
        let $variable = interne;
    }
}
fn main() {
    def_var!(externe);
    println!("{externe}"); // affiche 10
    // println!("{interne}"); // erreur la variable interne n'est pas accessible hors de la macro
}

Même si dans ce cas là ça ne marche pas, il reste bien sur des erreurs possibles en Rust et des chose auxquelles faire attention, mais le langage est quand même bien pensé pour en éviter le plus possible, là ou la philosophie du C, c'est que le programmeur se débrouillera.

Oui, je vois bien, mais par principe, faisant souvent du C, je n'utilise pas de macro. Point. Donc je n'ai jamais eu de problème de macro.

Ou on peut se tromper en ne corrigeant que partiellement un code dupliqué alors qu'avec une macro on aurait tout corrigé partout.

Le code dupliqué, je ne connais pas, je ne fais jamais de copier coller, et je débranche toute forme d'aide de l'éditeur qui pourrait me proposer la suite d'un mot que j'écrit dans le code. L'intellisence en C# dans VisulStudio, je débranche. ça me prend moins de temp de coder le tout que de choisir la suite a écrire dans une liste qu'on me propose. Dès que je "sens" que je réécrit quelque chose pour la deuxième fois, ça devient automatiquement une fonction. Je ne veux pas de code dupliqué. En Python j'ai mis à 3 le nomde de ligne qui serait semblables pour détecter une duplication.

Même si je suis d'accord qu'il serait trop complexe pour un projet solo de faire des macro hygiéniques et que du coup il vaut mieux s'en passer que de recourir au système cassé du C.

Mon petit projet de compilateur et écrit from strach en python. Le but sera, une fois terminé, que je puisse écrire le compilateur en utilisant mon langage lui-même. Mais bon, on ne peut pas tout faire en même temps. Une chose à la fois, et si possible dans le bon ordre.

BàT. et Peace & Love.

[Uther]

TU as dis ceci quelques post plus haut : 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.

Il y a en effet eu une incompréhension. La déclaration implicite des variables est un mécanisme distinct de l'inférence de type.
La déclaration implicite, c'est quand il n'y a pas besoin de déclarer les variables avant de les utiliser, n'importe quel identifiant valide est considérée comme une variable, ce qui fait que la moindre faute de frappe peut provoquer une erreur silencieuse vu qu'on ne manipule pas la bonne variable.
c'est ce qui se passe en Basic (à moins d'utiliser la directive "Option Explicit") ou dans certain langages de script comme Bash.

C'est peut-être un mot unique de trois lettres, mais qui est répétitif, donc "loud et pénible". Tu dis que c'est clair et efficace, je dis que c'est inutile et lourd. Je ne pense pas qu'on tombera d'accord là deçus.

On ne tombera probablement pas d'accord, en effet. Mais sait on jamais : j'avais a peu près les mêmes avis que toi il y a quelques années. La pratique d'autre langages m'a fait reconsidérer mes opinions. Je peux juste dire qu'en faisant l'effort de prendre un langage en le considérant comme il est, et pas comme on voudrait qu'il soit, la plupart des choix de syntaxe qui paraissaient problématiques deviennent logiques.
C'est pour ça que j'évite d'être trop critique sur un langage juste sur la syntaxe. C'est bien souvent juste du détail, les fonctionnalité sont plus importantes.

Euh, la j'ai un peut de mal a accepter ton argument. Je n'ai jamais vu une base de code pour un projet (petit ou grand), où il y avait plus de constantes que de variables. De plus, une constante, je l'exprime uniquement en MAJUSCULE, donc pas besoin d'aller voir plus loin si c'est une variable ou une constante, et si j'essaye d'utiliser la constante et de lui assigner une valeur, j'irais vite consulter un occuliste, en plus du message d'erreur que me donnera même le compilateur 'C'.

Ça dépend certainement du style de codage, ce que je peux te garantir c'est qu'en Rust les déclaration de variables mutables ne sont normalement par majoritaire.
J'ai fait une recherche dans le code du compilateur, car c'est la plus grosse base de code que je connais, il y a environ dix fois plus de let seuls que de let mut. Dans les projets que j'ai sur mon ordinateur le rapport oscille entre 2 et 4.

Une petite anecdote. Très jeune, sur mon C64 (je devais avoir 14 ans), sans accès à aucun bouquin, j'ai fait une routine de tri en basic). Oh, rien de magique, et j'ai remarqué que plus la liste a trié était grande, plus le tri prenait du temps. Je ne comprenais pas pouquoi. Le tri ne devait se faire que sur des listes assez courte, et ma "technique" de tri était suffisante pour ce qu'elle devait traiter. 1 ou 2 ans plus tard, je me suis rendu compte que j'avais réinventer le "Bubble Sort", de loin la mois bonne solution, mais j'étais quand même fier d'avoir trouver tout seul une "technique de tri" déjà découverte par d'autres.

Bien sur qu'il n'y a pas de mal a réinventer la roue pour un projet perso, je me disais juste que ça pouvait être intéressant pour toi de regarder à quoi ressemblait Go, juste par curiosité, vu qu'il y a des points similaires.

Désolé, mais si tu ne mets pas en citation à quel partie de message tu me réponds, j'ai du mal a te répondre.

Je parlais du fait que le système de gestion d'erreur de go, similaire au tien, faisait partie des retours négatifs que j'avais le plus lu sur le langage, après l'absence de génériques. Après je ne veux pas sous-entendre non plus que le système est ingérable, le Go marchant encore pas trop mal de nos jours.

Le code dupliqué, je ne connais pas, je ne fais jamais de copier coller, et je débranche toute forme d'aide de l'éditeur qui pourrait me proposer la suite d'un mot que j'écrit dans le code. L'intellisence en C# dans VisulStudio, je débranche. ça me prend moins de temp de coder le tout que de choisir la suite a écrire dans une liste qu'on me propose. Dès que je "sens" que je réécrit quelque chose pour la deuxième fois, ça devient automatiquement une fonction. Je ne veux pas de code dupliqué. En Python j'ai mis à 3 le nomde de ligne qui serait semblables pour détecter une duplication.

On est d'accord que quand on peut c'est ce qu'il faut faire, Sauf que pour certains types de répétitions, par exemple sur les déclarations, c'est pas possible ou pas optimal de faire une fonction.

[floyer]

Oui, pour 3 lettres qui mettent plus en évidence la déclaration de variable… curieux de trouver cela lourd. (Idem pour le ; )

Si tu souhaites réellement définir un word, rien ne t’en empêche :

Code :

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

1
2
let a:u16 = 12;
let b = 12u16;

Pour les variables immuables, c’est un concept différent des constantes.

Certes avec let pi = 3.1415926; on a bien une constante, mais let s = tableau.iter().sum(); tu récupères la somme dans une variable immuable. Mais la variable peut prendre des valeurs différentes selon l’appel de la fonction. La convention des capitales n’est pas pertinente ici.

Tu notes ici, que l’on récupère une somme de nombres sans utiliser de variables mutables. C’est le principe de la programmation fonctionnelle qui permet de s’en affranchir. Certains langages sont même allés très loin : en Haskell, tu n’as même pas de notion de variable mutable. Il suffit d’avoir des bonnes fonctions et structures et les variables mutables sont moins utiles.

C’est vrai qu’en C tu ne sais pas faire sans (ex : for(int i=0;i<10;i++)… mais en Rust, sans problème : for i in 0..10 { … }. Et il y a beaucoup de constructions (comme avec le .sum() plus haut) qui permettent de s’en passer. Je ne prétends pas que tu puisses t’en passer complètement. Mais prenons un parcours de liste chaîné… obligé d’avoir une variable mutable. Mais tu peux définir un itérateur de liste chaîné (qui repose sur une variable mutable), et ensuite l’utiliser avec uniquement des variables immuables. À l’utilisation, cela donnerait : for i in liste.iter() { … } ou liste.iter().find( … ) etc

[thal1]

Et combien coûte cette étude en énergie , qu'elle en est l'impacte ?
Et combien coûte en énergie la résolution des multiples bugs ?
Et combien coûte en energie le remplacement du matériel hardware suite
aux upgrades informatiques sensés apporter des miracles à des tas de personnes
qui n'en n'ont pas besoin et qui son obligées de suivre le mouvement ?
Voilà qui serait réellement intéressant ...

[floyer]

Oui, effectivement, il y a un aspect coût. D’où l’approche pragmatique (adaptation du noyau à des extensions nouvelles en Rust : driver, système de fichier)… ou verra pour plus tard ou jamais pour des éléments plus internes.

Des coûts aussi… quel est coût d’un système de fichiers vérolé, d’une attaque à cause d’une CVE, d’une mise à jour malheureuse (Crowdstrike) ? (Sans compter en amont, le coût du débugage dans les versions de développement).

Quand au coût matériel, Rust est connu pour être très performant. Cela ne devrait pas impacter significativement les performances.