Re: idées en plus ?

Il me semble que Rust essaye de fonctionner avec un minimum de mémoire dynamique, un langage comme Scade/Lustre fonctionne à l'inverse des objets : ce sont les fonctions qui portent la mémoire et non l'inverse. C'est un peu comme si, en C, pour chaque appel de fonction, une mémoire était créée pour toute variable déclarée statique. Pour gérer le cas des boucles, c'est assez simple : elles n'existent pas, il y a juste des map ou des fold sur les tableaux de donnés. C'est assez extrême, cela peut augmenter la consommation mémoire, mais cela tient énormément la charge, et pour le temps réel, c'est top.

Bah on peut déclarer plus de trucs sur la pile que Java ou Python, c’est sûr. ^^ Mais map et fold sont des méthodes qui existent déjà pour certains types en Rust.

Le deuxième point, issue des réflexions autour de Lisaac, était lié à l'énorme liste de conteneur possible (binary tree ou red-black tree ?), voir de type de String (ou "buffer" ou rope) en fonction de l'usage. Un humain peut rarement savoir qu'elle est le meilleur objet à utiliser. L'idée est de laisser choisir le compilateur qui peut simplement utiliser des heuristiques (présence de boucle ou non, ...), qui lui permet d'utiliser un "buffer" au lieu d'un string, si il détecte beaucoup de concaténation. Le principe technique de base serait d'utiliser une classe mère virtuelle, et le compilo se débrouille pour choisir une classe fille.

À mon avis, c’est pas la philosophie de Rust de «modifier» ce que fais le développeur... Un comme le C++ (mais plus sûr, expressif et moderne). Tu peux toujours ouvrir une entrée sur le système de suivi de bogue de Rust.

Écrit en Bépo selon l’orthographe de 1990