Faire un gang Rust à la finale

Salut !

Très peu de personnes ont utilisés un autre langage que Python ou C++ l'année dernière : https://prologin.org/archives/2018/final/report

Est-ce que ça intéresse quelqu'un qu'on apprenne à se servir de Rust et de l'utiliser à la finale ? (En étant 3/4 personnes à faire ça j'imagine, pour l'instant je suis seul). C'est dans un peu près deux mois donc ça laisse suffisement de temps pour apprendre sa syntaxe et ses spécificités, puis c'est l'occasion de découvrir un nouveau langage (je connais pas du tout).

Si ça vous intéresse laissez un message pour qu'on s'organise (j'imagine qu'on peut s'organiser sur ce topic sur "quoi lire comme ressource" et ainsi de suite).

Les vrais codent en C.

Salut,

L'an dernier y'avait quelqu'un qui codait en rust et qui s'est occupé de rendre dispo le langage en finale, c'est cool de voir que ça intéresse du monde.

@Nuxe, rust > c :) :)

@Nuxe Tu as raison, les vrais masochistes codent en C.

Plus sérieusement, Rust a quand même beaucoup de potentiel je trouve : assez d’accessibilité pour pouvoir être pris en main en quelques mois (contrairement à C++ quoi qu’on en dise), et puis quand même des performances qui rivalisent avec du C donc surpassent largement Python.

Je ne m’y connais pas tellement en IA. Par contre, pour débuter le Rust, il n’y a pas mieux que le Livre, il y a déjà là une énorme partie du langage et de ses spécificités. Après ça... eh bien je pense qu’il ne reste plus qu’à se familiariser avec l’écosystème ? 😅

Gogo Rust Power. Ferris ftw

Le Rust c'est juste du Go en moins bien :p

Le Rust c'est juste du Go en moins bien :p

Aïe aïe aïe, ça y est, on oublie que Go a un garbage collector alors que Rust n'en a pas

De la même manière qu'il existe des objets garbage collectés en Rust, il existe des pointeurs non garbage collectés en Go, c'est pas là dessus que se fait la différence.

Je dirais que Go se rapproche plus de Python par sa simplicité : un programme en Go est beaucoup plus simple à écrire qu’en Rust, c’est sûr. En revanche, même s’il y a des pointeurs non GC’d en Go, il y a quand même le GC qui tourne derrière et qui amoindrit les perfs (entre autres bien sûr, je cite le GC parce que Rust n’en a pas du tout). Rust en revanche est proche de C++ dans ses perfs.

J’ai jamais fait de finale, je ne connais pas l’importance des performances dans ces épreuves-là. Mais si c’est vraiment important, Rust reste plus efficace que Go.

Le GC du go tourne entièrement sur un thread à part de celui qui exécute le code, par conséquent, à moins d'utiliser 100% de chaque cœur, il n'a pas d'impact sur les performance puisqu'il n'engendre aucune interruption.

Le go est un langage beaucoup plus minimaliste que le python tout en ayant des performances nettement plus importantes (mais il est plus long de coder en Go)

(NB: le go n'aime pas le récursif, le Rust, oui.)

Cependant, on perd en mémoire le temps que le GC passe, et dans des utilisation intensives, on peut avoir des problèmes de mémoire avec le Go. En Rust, il faut penser à free, mais on a une utilisation mémoire plus fine. Le go a une implémentation du parallélisme beaucoup plus élégante (je trouve) et qui permet de paralléliser des problèmes plus facilement.

Le Go se compile plus vite.

Le Rust est un peu plus rapide mais pas énormément, mais j'ai jamais fait les finales non plus donc je sais pas.

En Rust, il faut penser à free,

Je croyais qu'un des avantages du Rust par rapport au C et au C++ était qu'on a (au moins presque) jamais besoin de gérer manuellement la mémoire parce que le "borrow checker" ou les "lifetimes" (je crois) permettent au compilateur de free dès qu'il peut ?

Alors, le Rust ce n'est pas mon langage maternel du tout xD

De ce que j'en comprend, il faut free, mais le langage est fait de telle manière que la plupart des fuites de mémoire sont détectées à la compilation.

De ce que j'en comprend, il faut free

En Rust, tout est régi par des règles d'ownership. Quand une variable sort de la portée dans laquelle elle est visible, elle est freed. On peut free manuellement en appelant une fonction spéciale (drop()), mais on ne le fait que très rarement : Rust le fait à notre place à la fin de chaque bloc.

le langage est fait de telle manière que la plupart des fuites de mémoire sont détectées à la compilation

Pas que les fuites de mémoire ! C'est ça qui est génial. La plupart des erreurs qu'on peut faire en C ou en C++ sont irréalisables en Rust safe (on peut les faire mais en Rust unsafe).

• Use after free : impossible, le compilateur nous empêche d'utiliser une variable après l'avoir drop, ou après en avoir transféré la possession à un autre bloc qui se chargera de la drop, et en plus il nous empêche de créer une référence invalide
• Double free : impossible, une variable ne peut être drop que par son owner, et elle n'a qu'un seul owner à chaque moment de l'exécution du programme
• Data races : on ne peut avoir à un moment de l'exécution du programme seulement une référence mutable ou des références immutables. Jamais les deux. Même en multithreaded