Pourquoi Tonari a choisi Rust pour mettre en œuvre la visioconférence en 3K, 60 fps et 130 ms

Retour d’expérience de Tonari sur la mise en œuvre d’une visioconférence « en temps réel »

→ La latence de Zoom et de WebRTC est de 315 à 500 ms

Plutôt que de toucher aux 750 000 lignes de la stack WebRTC pour atteindre une latence de 130 ms, proche du temps réel, ils ont décidé de concevoir toute la stack depuis zéro et de la réimplémenter en l’adaptant au matériel visé

→ Choix de Rust pour la sécurité, les performances et la maintenance

Principales crates utilisées

→ Mieux que la bibliothèque standard : crossbeam, parking_lot, bytes, socket2

→ Pour de beaux logs et une jolie CLI : fern, structopt

→ Outils d’aide autour de cargo : cargo-release, cargo-udeps, cargo tree, cargo-geiger, cargo-flamegraph

Les points difficiles avec Rust

• Les temps de compilation sont longs

• La couverture des bibliothèques est insuffisante

• Le langage exige d’écrire dès le départ un code exact et explicite

• L’inférence de types est tellement puissante qu’on a parfois l’impression d’utiliser un langage à typage dynamique

• Le langage est encore en évolution

Résultats du choix de Rust

• Aucune interruption de service liée au logiciel n’a été constatée

• Il a été facile d’écrire un code performant grâce à une utilisation efficace des ressources

• L’utilisation du CPU et de la mémoire est prévisible et cohérente

• Une latence et une fréquence d’images stables sont garanties

• L’expérience de maintenance de la base de code est elle aussi excellente

• Au final, ils ont construit un produit fiable et maintenable, offrant d’excellentes performances en fréquence d’images, latence et efficacité des ressources

→ Cela aurait été difficile sans Rust