Uther (./7399):

Lionel Debroux (./7379) :
En tout cas, mauvais point pour le langage d'implémentation: fournir une API externe en C reste bien sûr nécessaire pour des raisons d'interopérabilité, mais pour de nouvelles bases de code, continuer à tout écrire en C est de plus en plus inacceptable.

Le C garde quand même un avantage sur tous les autre langages: c'est qu'il y a des compilateurs C pour quasiment toutes les architectures existantes. Et comme Linux est en C, PipeWire est potentiellement portable partout ou est Linux.

Certes, il y a des ISA qui n'ont pas de bon compilo C et encore moins de compilo C++ acceptable, par exemple Z80 et eZ80: non seulement l'ISA, même améliorée, se prête mal à la programmation en C, mais de plus, le compilo de Zilog est une vraie bouse.
Cependant, Linux a des dépendances dures vers des extensions GCC au langage C, donc GCC ou quelque chose de suffisamment compatible (Clang sur certaines architectures, même si mainline Linux met des bâtons dans les roues en rendant inconditionnelles les dépendances vers des extensions GCC non universellement appréciées sur des architectures aussi majeures que x86/x86_64...) est un prérequis pour toutes les plate-formes où Linux s'exécute. Il ne me semble alors pas y avoir de (bonne) raison pour que PipeWire soit moins portable avec une implémentation interne en C++ et une API externe en C qu'avec une implémentation interne en C et une API externe en C.
Si une mini-libc et libstdc++ n'ont pas été portées sur certaines des plate-formes qui peuvent tourner Linux, c'est un gros problème d'utilisabilité desdites plate-formes, car le C++ se répand (beaucoup trop) lentement dans les deps core d'un système Linux bien élevé. Et je pense que certaines (la plupart ?) de ces éventuelles plate-formes bizarres ne seraient pas les cibles des utilisations clairement desktop et DAW visées par PipeWire.

Uther (./7399):

squalyl (./7398) :
c++ tu changes de version de gcc et toutes tes libs dynamiques deviennent inutilisables...

Dans le cas de PipeWire, ça ne serait pas un problème. Vu qu'il va falloir que la bibliothèque s'interface avec d'autre langages, Rust ou C++ utiliseraient l'ABI C de toute façon.

De plus, recompiler + upgrader le système cible + redéployer doit maintenant être une fonctionnalité de base sur la plupart des devices, y compris de l'embarqué assez dur, puisque justement, à cause de la sur-utilisation de C et C++ mal écrits qui donnent du code trop vulnérable, les mises à jour de sécurité doivent être réalisées fréquemment...