Discussion :

[OuftiBoy]

fdecode,

J'utilise Rust depuis 2016, et on perçoit que la stabilisation de l'ensemble converge.

J'ai du mal a comprendre cette remarque fdecode, car si depuis 2016, je cite "on perçoit que la stabilisation de l'ensemble converge", cela veut dire pour moi que cette "convergence" (et donc la stabilisation) n'est pas aboutie, mais je comprend peut-être mal votre propos. Ne vous méprenez pas, je n'ai rien contre Rust, j'ai même dans le cadre du développement de mon petit langage, étudié de près le mécanisme de sécurisation mémoire, et donc le Borrow Checker.

Pourriez-vous donner un exemple de stabilité insuffisante pour la librairie std?

Non, je n'ai pas développé d'application en Rust d'ampleur suffisante, et je n'ai pas rencontré d'instabilité. Je réagissais juste aux propos d'Uther, qui disait (et il s'y connait nettement mieux que moi en Rust, sans aucun doute possible), que des "éditions" pouvaient permettre de modifier la syntaxe. Je ne parle pas d'instabilité technique, mais d'instabilité syntaxique, même si je suppose qu'il y'a moyen de maîtriser ces éditions. A ce propos, pourquoi faire apparaître différentes éditions à large diffusion ? Cela reste un peu confus. Tous les langages évoluent, mais entendre parler de différentes éditions public, cela est rare, non ? Ou alors je n'ai pas compris quelque chose, ce qui est sans doute le cas.

Pour ma part, le changement d'édition ne m'a jamais posé de problème et il reste assez naturel, même pour les anciennes éditions.

Je n'en doute pas une seule seconde. Comme je l'ai expliqué, j'ai plus étudié le langage que je ne l'ai utilisé et je manque très certainement de pratique, d'où peut-être une certaine confusion de ma part sur certains sujets. Je l'ai étudié principalement pour comprendre son mécanisme de sécurisation de la mémoire. Rust est, me semble-t-il, une très bonne avancée, mais on ne peut pas (du moins, moi je ne peux pas) connaître, étudier ni utiliser 25 langages en en maîtrisant toutes les arcanes.

De part mon parcours, j'ai plus d'expérience en C, Assembleur, et en Python.

Je ne me permet pas de remettre en cause le jugement de personnes plus compétentes que moi sur un sujet, mais il m'arrive, lorsque des sujets sont débattu, de m'interroger et donc de questionner.

C'est quoi un développement classique? Il m'est arrivé d'utiliser des fonctionnalités de C++ jusqu'au standard C++23. Je ne les ai pas trouvées artificielles. Je regarde aussi avec un certain intérêt les ajouts faits au système de template et les possibilités qui émergent relativement aux coroutines. Je les trouve pour ma part plutôt bienvenues.

Oui, j'avoue que je n'ai pas été très précis en utilisant le terme "développement classique". C'était à mettre en perspective avec le fait que, par expérience, j'évite d'utiliser les fonctionnalités trop spécifiques à un langage. Je suis plutôt adepte de m'en tenir aux bases, afin que le code que j'écris reste lisible et facilement compréhensible même par d'autres qui n'auraient pas encore atteint (et c'est un processus bien normal, cela ne se fait pas en 1 jour) le même niveau.

Par exemple, en Python, il y'a moyen d'utiliser des decorators pour des propriétés, mais on peut avoir le même résultat en utilisant simplement une fonction qui en appelle une autre. Appeler une fonction, tout le monde comprend vite, utiliser les decorators (même s'ils ont des avantages), c'est une petite couche de complexité en plus dans le code. Oui, je suis plutôt très conservateur en cela.

J'ai laissé tombé le C++ justement à cause des templates. Le livre de 700 pages d'Andrusescu, il y'a bien longtemps, m'a tout simplement dégoûté du C++ (dont j'aimais les premières versions (on le nommais à l'époque encore le C avec des class)), tant cela était démesuré par rapport aux besoins qu'étaient les miens. De la même manière le livre GoF, traitant des "Design Patterns" (qui ne sont que la formalisation de techniques récurrentes et déjà largement répandues à l'époque) m'a semblé un rien Too much... Je me suis tourné vers Python, avec lequel 75% de ces fameux "Design Patterns" sont tout simplement inutiles, de par la nature même de Python.

Et je préfère la composition à l'héritage. Je vois plus un objet comme une entité qui fait des choses, et le définir en tant qu'entité possédant certaines données ET coupler les deux, n'est pas, de mon point de vue la bonne approche POO. Cela s'éloigne de la POO tel que décrite initialement par son créateur (Alan Kay si j'ai bonne mémoire - je vieillis tout doucement :-))

Alors, oui, j'aime simplifier les choses au maximum, cela m'a permit de maintenir sans soucis des projets durant des dizaines d'années. Je ne prétend pas que ma façon de faire et LA bonne méthode, mais dans mon cas, tant sur des projets Pro que sur des projets Perso, c'est une méthode que je n'ai jamais eue a regretter.

Pour les coroutines, ce n'est pas un concept nouveau, loin de là. Mais (je travail dans l'embarqué), lorsqu'on utilise un RTOS (même un µRTOS), les "coroutines" perdent beaucoup de leur intérêts. Je ne me prononce pas pour d'autres domaines.

La critique que je ferais serait sur la rétrocompatibilité trop forte. Sans doute le langage pourrait être allégé et rationalisé par un système d'édition qui réformerait davantage certaines formes anciennes.

Là, je ne suis pas trop en accord. Soit le langage a intégré des choses non essentielles (puisqu'on pourrait les retirer, pour rationaliser), soit, et ce serait surprenant (car ce n'est tout de même pas le premier langage développé), les bases du langage n'ont pas été assez pensées. C'était peut-être une obligation à l'époque des débuts de Rust, dont l'équipe qui l'a développé avait très certainement des contraintes a respecter, je n'en sais rien. Mais cela reste tout de même un petit mystère pour moi, car l'équipe derrière Rust est sans aucun doute d'un niveau supérieur au mien, je n'en doute pas une seconde. Peut-être qu'une autre solution, (que celle de créer un nouveau langage), aurait été de faire évoluer Ada (sans "casser" d'anciens code), car Rust s'inspire (et ce n'est pas un reproche, c'est même un compliment) assez fortement d'Ada par bien des aspects.

Comme beaucoup, j'ai appris Rust en autodidacte. Un mois de souffrance en 2016 avant de comprendre la démarche du langage. Mais cela se fit sans trop de problème; le compilateur aide beaucoup pour l'amélioration du code et la compréhension des règles. Sincèrement, la difficulté est plus grande pour le C++. Mais, les IA aident beaucoup désormais.

Il n'y a pas plus autodidacte que moi, j'ai commencé avec le BASIC du C64 ;-) et les IAs, ce n'est pas pour moi. Elles sont peut-être de plus en plus performantes, mais insidieusement, elles éloignent ceux qui les utilisent, de plus en plus des bases. Et sans bonnes bases, les choses peuvent vite vous glisser entre les doigts, et le château de carte s'écrouler. Certaine des catastrophes relatées dans les informations récentes sont plus dues à une utilisation non maîtrisée/surveillée des IAs, qui ne devraient être vue que comme un outil, et non une fin en soit. Je ne vois pas comment, sans bonne bases on peut utiliser l'outil qu'est l'IA correctement et en étant capable de comprendre les solutions qu'elle propose. La tendance du Vibe Coding peut donner des résultats à court terme, mais sur le long terme, je ne pense pas, vraiment pas... Cela donne aussi l'illusion à certains qu'ils peuvent faire des choses, mais ils ne se rendent pas compte (il y a toujours des exceptions, je ne le nie pas) qu'ils jouent avec une bombe et non pas avec un petit pétard...

Voilà voilà, ce n'est que mon point de vue, que je partage et avec lequel je suis d'accord
Mais mon avis n'a pas plus d'importance que celui de n'importe quel développeur, je ne suis pas ici pour imposer mes idées, mais pour en débattre, tout simplement.

BàV et Peace & Love.

[fdecode]

Soit le langage a intégré des choses non essentielles (puisqu'on pourrait les retirer, pour rationaliser), soit, et ce serait surprenant (car ce n'est tout de même pas le premier langage développé), les bases du langage n'ont pas été assez pensées. C'était peut-être une obligation à l'époque des débuts de Rust, dont l'équipe qui l'a développé avait très certainement des contraintes a respecter, je n'en sais rien. Mais cela reste tout de même un petit mystère pour moi, car l'équipe derrière Rust est sans aucun doute d'un niveau supérieur au mien, je n'en doute pas une seconde. Peut-être qu'une autre solution, (que celle de créer un nouveau langage), aurait été de faire évoluer Ada (sans "casser" d'anciens code), car Rust s'inspire (et ce n'est pas un reproche, c'est même un compliment) assez fortement d'Ada par bien des aspects.

Je ne vois pas de problème à faire évoluer un langage et à rendre progressivement 'obsolete' certains concepts.
Les connaissances sur les langages évoluent; cela suscite des besoins qui finissent par être assez lourds à gérer dans la configuration initiale du langage.
Et en réalité, la plupart des langages le font.
Je ne vais pas m'attarder là dessus, car cela demanderait d'aller chercher de l'information, mais même le C++ a introduit des changements progressifs et des ajustements qui ont dégradé certaines retro-compatibilités.
Si on devait parler de la migration Python2 -> Python3 ou Scala2 -> Scala3, les ruptures sont bien plus visibles.
Les éditions de Rust permettent d'encapsuler les changements: par exemple, on peut utiliser une librairie de l'édition 2021 avec un code de l'édition 2024. Cela amortie la transition.
Quant à l’idée de faire évoluer Ada à la place, pourquoi pas en théorie. Mais c’est un autre sujet. Personnellement, Ada ne m’attire pas du tout, donc je préfère que Rust existe comme nouveau langage.

Je ne parle pas d'instabilité technique, mais d'instabilité syntaxique

Je pense qu'on parle bien de la même chose: les releases stables de Rust visent à fixer des évolutions dans le langage, le noyau et la librairie standard, alors que les releases nightly sont expérimentales.

car si depuis 2016, je cite "on perçoit que la stabilisation de l'ensemble converge", cela veut dire pour moi que cette "convergence" (et donc la stabilisation) n'est pas aboutie, mais je comprend peut-être mal votre propos.

Notre philosophie des langages n'est pas la même: pour moi, un langage doit évoluer.
La question est éventuellement de savoir si cette évolution converge, c'est à dire si on a un mouvement d'ensemble cohérent qui va vers quelque chose de suffisamment stable, ou si le langage est instable syntaxiquement.
Et Rust est suffisamment stable syntaxiquement de mon point de vue et cette stabilité s'accroit. On le voit d'ailleurs avec le faible nombre de fonctionnalité qui sont stabilisées à chaque update.
On va vers un langage qui évoluera progressivement, et cette évolution sera assez facile à gérer avec les mécanismes d'édition, qui permettent l'utilisation trans-édition des librairies (crates).

Je te suggère d'ailleurs de regarder la doc officielle qui t'explique la démarche générale:
https://doc.rust-lang.org/edition-guide/editions/
Et notamment de bien prendre en compte les mentions:

• In May 2015, the release of Rust 1.0 established “stability without stagnation” as a core Rust axiom. Since then, Rust has committed to a pivotal rule: once a feature is released through stable, contributors will continue to support that feature for all future releases.
  
  However, there are times when it’s useful to make backwards-incompatible changes to the language. A common example is the introduction of a new keyword. For instance, early versions of Rust didn’t feature the async and await keywords.
  
  If Rust had suddenly introduced these new keywords, some code would have broken: let async = 1; would no longer work.
  
  Rust uses editions to solve this problem.
• When creating editions, there is one most consequential rule: crates in one edition must seamlessly interoperate with those compiled with other editions.

Je m'aperçois décidément que c'est vraiment très proche de ce que j'attends d'un langage de programmation.

Il n'y a pas plus autodidacte que moi, j'ai commencé avec le BASIC du C64

Si on en vient à remonter le temps comme ça, mes premiers pas sont en BASIC sur VIC20 et en 6502 (avec l'utilisation des interruptions pour rafraichir l'affichage...).

Ceci étant dit, si cela a pu être formateur pour une certaine génération, les concepts d'ingénierie logiciel viennent avec avec des langages introduisant des abstractions structurantes.
Autrement dit, ma programmation sérieuse a commencé avec le pascal et le C. Mais je ne renie pas le fait que ces petits ordinateurs personnels étaient très bien pour acquérir certaines intuitions et qu'ils forçaient à la programmation.

J'ai laissé tombé le C++ justement à cause des templates.

Je comprends. Les templates C++ sont très puissants, mais assez peu structurés: ça ouvre la porte à des trucs assez tordus.
Dans des langages comme Java, Scala ou Rust, la généricité est mieux encadrée dès le départ.
Ce que je trouve positif dans C++20/23, c’est justement l’ajout de mécanismes comme requires et les concepts, qui permettent de contraindre plus proprement les templates.