Brian Kernighan, informaticien de renom et co-créateur d'Unix, s'exprime après avoir testé le langage Rust

Citation:

---

Envoyé par OuftiBoy

j'ai juste étudié son système de protection de la mémoire, qui même s'il est efficace, me semble inutilement "compliqué".

---

"inutilement compliqué" par rapport à quelle utilisation?
On n'est peut-être plus contraint aux seuls fork du C, mais faire de la programmation multithread ou concurrente bas niveau reste une tâche complexe. Rust avec son typage avec sémantique de prêt a grandement facilité ces paradigmes de programmation. Je parle de bas niveau ; car sinon, de nombreux langages à GC offrent des facilités pour la programmation multithread/concurrente (Erlang, Go, Clojure, Java, Scala/Akka, .NET, ...).

Citation:

---

Envoyé par OuftiBoy

Les développeurs qui ont des problèmes avec les pointeurs sont souvent des développeurs ayant été formés sur des langage avec GC, et n'ont qu'une vague connaissance du bas-niveau des choses.

---

J'ai commencé assez jeune avec du 6502, du 86 en mode réel et du C. Pour autant, je reconnais honnêtement qu'il m'arrive de faire des erreurs dans ma gestion de la mémoire, lorsque j'en ai la responsabilité (C / C++). Ne soyons pas prétentieux!

:coucou: fdecode

Citation:

---

Envoyé par fdecode

"inutilement compliqué" par rapport à quelle utilisation?
On n'est peut-être plus contraint aux seuls fork du C, mais faire de la programmation multithread ou concurrente bas niveau reste une tâche complexe. Rust avec son typage avec sémantique de prêt a grandement facilité ces paradigmes de programmation. Je parle de bas niveau ; car sinon, de nombreux langages à GC offrent des facilités pour la programmation multithread/concurrente (Erlang, Go, Clojure, Java, Scala/Akka, .NET, ...).

---

Tout dépend des besoins, on est bien d'accord, la sécurité qu'apporte Rust peut même rendre les choses plus facile, je parlais plutôt des "concepts" utilisés pour cette sécurisation. Mais pour du "bas niveau", C reste indispensable, non pas que Rust ne puisse pas y être très utile, mais tout simplement parce que l'on est (actuellement) toujours certains d'avoir un compilateur C pour tout microcontrôleur, ce qui n'est pas (à l'instant) le cas de Rust. Je parle ici de très petits microcontrôleurs...

Citation:

---

Envoyé par fdecode

J'ai commencé assez jeune avec du 6502, du 86 en mode réel et du C. Pour autant, je reconnais honnêtement qu'il m'arrive de faire des erreurs dans ma gestion de la mémoire, lorsque j'en ai la responsabilité (C / C++). Ne soyons pas prétentieux!

---

Je me suis mal expliqué, tout le monde fait des erreurs, moi aussi évidemment, ce n'est pas ce que je voulais dire. Sans prétention aucune, une personne qui n'a été formé qu'avec des langages avec GC ont plus de soucis avec le bas niveau. Je n'ai pas voulu être prétentieux, du tout.

BàV et Peace & Love.

Citation:

---

Envoyé par fdecode

Il y a de « l'héritage multiple » au sens des traits, et ils ne sont pas limités en nombre de niveaux. Mais dans la pratique, on utilise beaucoup la composition en Rust.

---

Oui, la composition est a préférer sur l'héritage, et l'héritage multiple est a éviter autant que possible.

Citation:

---

Envoyé par fdecode

Comprendre qu'on n'avait pas besoin de classes et d'héritages, ça a aussi été une découverte pour moi, avec Rust.

---

Je suis étonné que vous ayez découvert cela avec Rust, car de nombreux excellent bouquin traitant du C++ (par exemple), mettent très vite en avant qu'il faut privilégier la composition à l'héritage, et coder pour des interface et non pour des types "concrets".

Attention, ce n'est pas un "jugement" (je ne me permettrait pas), mais un "étonnement".

BàV et Peace & Love.

Citation:

---

Envoyé par OuftiBoy

Je suis étonné que vous ayez découvert cela avec Rust

---

Il y a une marge entre le fait de ne pas utiliser des héritages multiples de classes (hors classes abstraites pures) tout en limitant sa hiérarchie de classe -- discipline qu'on acquière très vite avec la pratique -- et le fait de ne pas utiliser de classe du tout et de passer à une philosophie trait. C'est une manière assez différente de coder. On ne le perçoit pas si on fait peu de programmation objet, mais quand on a une certaine habitude des classes, il y a quelques réflexes à changer.

En fait, j'avais aussi en tête les mécanismes de conditionnement de type de Rust qui donnent sa puissance à la composition, mais qui sont plus riches que ça, car permettent aussi des implémentations et définitions conditionnelles. Tout cela se complète bien, et constitue ce paradigme un peu exotique qui m'avait surpris par rapport aux langages à classes.

Prenons un exemple de la librairie std:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

pub trait From<T>: Sized { fn from(value: T) -> Self; }   pub trait Into<T>: Sized { fn into(self) -> T; }   impl<T, U> Into<U> for T where U: From<T>, { fn into(self) -> U { U::from(self) } }

---

Qu'est-ce que cela nous dit? On a deux mécanismes de conversion de types qui sont définis par les traits From et Into. Ils sont tout à fait équivalents, mais duaux.
Par contre, sur cet exemple, la librairie définit une implémentation automatique de Into<U> pour des types T a priori inconnus, si U implémente From<T> ; c'est le impl<T, U: From<T>> Into<U> for T ....
Donc, ce n'est pas un mécanisme d'héritage au sens où on n'a pas de relation d'héritage "From hérite de Into" (ici, cela n'a pas de sens), par contre, on obtient le comportement de Into<U> par une sorte de mixin contractuel automatique.

:coucou: fdecode.

Citation:

---

Envoyé par fdecode

Il y a une marge entre le fait de ne pas utiliser des héritages multiples de classes (hors classes abstraites pures) tout en limitant sa hiérarchie de classe -- discipline qu'on acquière très vite avec la pratique -- et le fait de ne pas utiliser de classe du tout et de passer à une philosophie trait. C'est une manière assez différente de coder. On ne le perçoit pas si on fait peu de programmation objet, mais quand on a une certaine habitude des classes, il y a quelques réflexes à changer.

---

Je suis 100% d'accord.

Citation:

---

Envoyé par fdecode

En fait, j'avais aussi en tête les mécanismes de conditionnement de type de Rust qui donnent sa puissance à la composition, mais qui sont plus riches que ça, car permettent aussi des implémentations et définitions conditionnelles. Tout cela se complète bien, et constitue ce paradigme un peu exotique qui m'avait surpris par rapport aux langages à classes.

Prenons un exemple de la librairie std:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

pub trait From<T>: Sized { fn from(value: T) -> Self; }   pub trait Into<T>: Sized { fn into(self) -> T; }   impl<T, U> Into<U> for T where U: From<T>, { fn into(self) -> U { U::from(self) } }

---

Qu'est-ce que cela nous dit? On a deux mécanismes de conversion de types qui sont définis par les traits From et Into. Ils sont tout à fait équivalents, mais duaux. Par contre, sur cet exemple, la librairie définit une implémentation automatique de Into<U> pour des types T a priori inconnus, si U implémente From<T> ; c'est le impl<T, U: From<T>> Into<U> for T ....

Donc, ce n'est pas un mécanisme d'héritage au sens où on n'a pas de relation d'héritage "From hérite de Into" (ici, cela n'a pas de sens), par contre, on obtient le comportement de Into<U> par une sorte de mixin contractuel automatique.

---

Je n'ai pas encore suffisamment de maîtrise de Rust. Mais si ces mécanismes peuvent réduire voir éliminer l'héritage en grande partie, et privilégie la "composition", ça ne saurait qu'être une bonne chose. C'est un peu la même chose que mon idée "d'apis" et de types "respectant cette apis", me semble-t-il. Bon, la syntaxe est "barbare", mais comme tout syntaxes, il faut un peu d'habitude pour s'y faire et ce n'est pas un obstacle insurmontable.

BàT et Peace & Love.

Les traits sont surtout une approche plus légère de l'héritage, avec moins de hiérarchies contraignantes.
La principale différence technique entre les classes et les traits est que ces derniers n'embarquent pas d'état, ce qui évite les principaux problèmes engendrés par l'héritage multiple.

:coucou:

Citation:

---

Envoyé par Uther

Les traits sont surtout une approche plus légère de l'héritage, avec moins de hiérarchies contraignantes.
La principale différence technique entre les classes et les traits est que ces derniers n'embarquent pas d'état, ce qui évite les principaux problèmes engendrés par l'héritage multiple.

---

C'est une bonne chose, l'héritage multiple je n'ai jamais été fan, j'ai toujours évité. Il faudrait que je me penche plus sur les traits de Rust, et voir ce qu'ils peuvent apporter à Home sans que celui soit trop compliqués à **comprendre** pour le développeur, et que le code source reste lisible et limpide.

Merci de participer Uther, je prend bien note de vos remarques à tous et je tente d'en faire un "ensemble" cohérent dans Home.

Là je suis en train de me pencher sur l'implémentation du **concept** de coroutines... Ce n'est pas un concept compliqué en apparence pour l'utilisateur, mais cela n'est pas la chose la plus aisée a ajouter au compilateur...

Merci de vos retours, cela m'aide beaucoup, et me "recadre" parfois. J'avance bien, mais l'ensemble "nouveau langage" / "compilateur 100% fait main", c'est un gros boulot, sans oublier la documentation. Mais je suis persévérant ;) En tout cas, j'apprend énormément, et rien que ça, ça vaut la peine.

BàV et Peace & Love les amis.

Les traits ressemblent aux interfaces Java et à tes api… tu définis des traits (signature d’un ensemble de méthodes), puis les implémentent librement pour les classes que tu souhaites.

Après, si tu souhaites créer une fonction dont l’argument doit implémenter deux traits

Code:

---

1 2 3 4

fn util<T: TraitA + TraitB>(obj: T) { obj.foo(); // accès à TraitA obj.bar(); // accès à TraitB }

---

La principale différence est peut-être que tu ne souhaites pas définir explicitement un trait par fonction mais que ce soit implicite.

Pour les coroutines, cela nécessite en général de l’assembleur, la commande qui commute d’une coroutine à l’autre doit sauver l’état de la pile (registre SP/Stack Pointer), et le return passe alors automatiquement dans l’autre coroutine (registre PC/Program Counter sauvé sur la pile). Après tu as aussi des appels systèmes à réimplémenter (faire des read/write non bloquants. Si erreur EWOULDBLOCK et s’il y a une coroutine non bloqué on commute dessus… et sinon, un select ou poll pour attendre que que quelque chose se passe dans une des entrées/sorties, puis commuter sur la coroutine qui peut lire ou écrire.

Les coroutines peuvent être implémentées en bibliothèque… pas besoin de toucher le compilateur… juste qu’il y ait une porte vers l’assembleur (FFI…) mais cela sera de toute manière utile.

:coucou:

Citation:

---

Envoyé par floyer

Les traits ressemblent aux interfaces Java et à tes api… tu définis des traits (signature d’un ensemble de méthodes), puis les implémentent librement pour les classes que tu souhaites.

---

Oui, c'est très proche des traits tel que tu me les présente, mis à part que je n'ai pas la notion de "classe". Je n'ai que des types, dont les méthodes se voient ajouté un 1er argument "me", pour désigner une instance de type en particulier,

Citation:

---

Envoyé par floyer

Après, si tu souhaites créer une fonction dont l’argument doit implémenter deux traits

Code:

---

1 2 3 4

fn util<T: TraitA + TraitB>(obj: T) { obj.foo(); // accès à TraitA obj.bar(); // accès à TraitB }

---

---

Actuellement, ce n'est pas une via une fonction qui implémente la notion de "traits", mais le simple respect par un type d'une méthode ou plusieurs méthodes d'une api. Mais une api/mtd peuvent (naturellement) appeler d'autres méthode ou api.

Citation:

---

Envoyé par floyer

La principale différence est peut-être que tu ne souhaites pas définir explicitement un trait par fonction mais que ce soit implicite.

---

Si, c'est en effet explicite, une api est implémentée via une méthode du type.

Citation:

---

Envoyé par floyer

Pour les coroutines, cela nécessite en général de l’assembleur, la commande qui commute d’une coroutine à l’autre doit sauver l’état de la pile (registre SP/Stack Pointer), et le return passe alors automatiquement dans l’autre coroutine (registre PC/Program Counter sauvé sur la pile).

---

Là ou j'en suis, je n'ai pas besoin de l'assembleur au niveau du code utilisateur (et s'il en faut, je repenserai la manière de faire ou même de ne pas faire, car cela serait trop compliqué pour Home, dont le code source doit rester lisible, ce qui ne serait plus le cas s'il faut de l'assembleur dans le code de l'utilisateur, qui de plus rendrait le code difficilement portable pour une autre "architecture"). C'est au final de l'assembleur, car le code source est "compilé" vers un "assembleur" pour un CPU "virtuelle" (en passant par un IRC).

Citation:

---

Envoyé par floyer

Après tu as aussi des appels systèmes à réimplémenter (faire des read/write non bloquants. Si erreur EWOULDBLOCK et s’il y a une coroutine non bloqué on commute dessus… et sinon, un select ou poll pour attendre que que quelque chose se passe dans une des entrées/sorties, puis commuter sur la coroutine qui peut lire ou écrire.

---

Le langage "repose" sur un µKernel RTOS, dont les "appel système" se feront via une INT software. Le µKernel pourrait devoir supporter cela, via des mutex et ou des sémaphores.

Citation:

---

Envoyé par floyer

Les coroutines peuvent être implémentées en bibliothèque… pas besoin de toucher le compilateur… juste qu’il y ait une porte vers l’assembleur (FFI…) mais cela sera de toute manière utile.

---

Actuellement, j'utilise des **mots-clefs**, pas de bibliothèque. Comme toujours, je ferais le constat de mes choix, et s'ils ne sont pas les bons, je réfléchirais à un meilleur système.

J'ai parfois l'impression que je joue à l'équilibriste, entre "lisibilité" et "possibilités" du langage. Honnêtement, c'est parfois difficile de trouver le juste milieux. Cela allonge le temps de développement, mais je n'ai pas de "date" butoir, mais j'avance quand même plus que je ne recule...

Merci à Vous.

BàV et Peace & Love.

Rust n’est POO au sens classique. Les traits peuvent être associés à des structures (struct).

Que tu utilises une bibliothèque FFI avec de l’assembleur ou un mot clé spécial du language qui provoque l’échange de pile ne change pas grand chose (c’est du language machine au final et ce n’est pas portable). RTOS est multithread… il n’y a alors qu’à utiliser les appels systèmes disponibles. Mais c’est du multithread et non des coroutines. Chaque approche a ses avantages.

Un exemple de bibliothèque de coroutine est Lwt pour OCaml… en fait, tous les appels systèmes bloquant sont encapsulés par la bibliothèque pour permettre d’éviter qu’une coroutine bloque tout le monde sur un tel appel.

Citation:

---

Envoyé par OuftiBoy

Oui, c'est très proche des traits tel que tu me les présente, mis à part que je n'ai pas la notion de "classe". Je n'ai que des types, dont les méthodes se voient ajouté un 1er argument "me", pour désigner une instance de type en particulier,

---

Pour le coup, j'ai l'impression que tu as exactement reproduit le fonctionnement de Rust sur ce point. En Rust, il n'a pas de classe non plus. Par contre les types de base (struct, enum et union) peuvent implémenter des méthodes soit directement, soit via un trait ce qui permet le polymorphisme.
Et comme pour toi la différence entre une méthode et une fonction classique se fait en passant l'élément en premier paramètre (qui se nomme "self")