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 qui s’appellerait.

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.