Je suis d'accord avec toi que la technologie reste un simple moyen et non pas un but.
Concernant le C++, j'en ai fais de nombreuses années et dans un contexte amusant ou il est vraiment justifié : celui du calcul haute performance pour le cinéma d'animation. Sans entrer dans les détails, mais un contrat avec un client peut se perdre si tu es 5% plus lent que la concurrence. Quand le budget alloué aux fermes de rendus pour un film est non négligeable par rapport au budget total du film, on parle de millions d'euros qui se jouent sur 5% de performance.
Tu parles de reconversion, c'est ce que j'ai fais. Il y tout juste un an, j'ai décidé de quitter ce domaine et de faire autre chose, je voulais changer.
Depuis, je fais principalement de l'embarqué pour l’aéronautique. Un domaine pour lequel le C++ est sensé être aussi le roi. Sauf qu'en fait non. Dans ce contexte, le C++ est un langage intermédiaire généré par un langage de plus haut niveau (ici Haskell) pour au final avoir un code plus simple (on profite de la souplesse d'Haskell) et plus robuste (On peut prouver de nombreuses choses statiquement pendant la phase de génération du code, choses qu'il nous aurait été impossible de prouver en C++).
Mes anciennes compétences C++ sont ici utilisées dans l'outil de génération de code C++.
En ce qui concerne les outils pour le C++, je suis biaisé car je travaille pour une société de consulting qui vend du bazel et du nix, ( https://www.tweag.io/) donc :
Bazel, dont tu parles, est un très bon outil pour gérer le build sur une grosse base de code hétérogène. Il saura autant faire cohabiter du C++, que du python, du haskell, du node et que sais-je encore, et ce sur plusieurs architectures. À titre d'exemple, le générateur de code C++ dont je parlais avant est écrit en Haskell, le code C++ est généré sur x86_64 puis compilé en cross compilation pour différentes architectures pour l'embarqué. Tout cela dans bazel.
Nix (https://nixos.org/nix/) pour ta gestion de dépendance. En gros, nix va te créer un environnent reproductible contenant les dépendances de ton projet.
L’expérience windows est correct dans le subsystem for linux. En dehors, j'ai déjà cross compilé des binaires natif windows avec, mais jamais essayé de faire plus. Tout ce qui se lie statiquement facilement doit pouvoir être faisable.
Le problème de la distribution est réglé avec nix si ta cible peut installer nix. Sinon, tu es dans la même situation que pour tous les autres outils de gestion de dépendance / build et je ne connais qu'une unique solution: faire un binaire statiquement lié qui contient tout. Et nix peut t'aider à faire ça.
# La technologie est juste un outil
Posté par Guillaum (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 7.
Je suis d'accord avec toi que la technologie reste un simple moyen et non pas un but.
Concernant le C++, j'en ai fais de nombreuses années et dans un contexte amusant ou il est vraiment justifié : celui du calcul haute performance pour le cinéma d'animation. Sans entrer dans les détails, mais un contrat avec un client peut se perdre si tu es 5% plus lent que la concurrence. Quand le budget alloué aux fermes de rendus pour un film est non négligeable par rapport au budget total du film, on parle de millions d'euros qui se jouent sur 5% de performance.
Tu parles de reconversion, c'est ce que j'ai fais. Il y tout juste un an, j'ai décidé de quitter ce domaine et de faire autre chose, je voulais changer.
Depuis, je fais principalement de l'embarqué pour l’aéronautique. Un domaine pour lequel le C++ est sensé être aussi le roi. Sauf qu'en fait non. Dans ce contexte, le C++ est un langage intermédiaire généré par un langage de plus haut niveau (ici Haskell) pour au final avoir un code plus simple (on profite de la souplesse d'Haskell) et plus robuste (On peut prouver de nombreuses choses statiquement pendant la phase de génération du code, choses qu'il nous aurait été impossible de prouver en C++).
Mes anciennes compétences C++ sont ici utilisées dans l'outil de génération de code C++.
En ce qui concerne les outils pour le C++, je suis biaisé car je travaille pour une société de consulting qui vend du bazel et du nix, ( https://www.tweag.io/) donc :
Bazel, dont tu parles, est un très bon outil pour gérer le build sur une grosse base de code hétérogène. Il saura autant faire cohabiter du C++, que du python, du haskell, du node et que sais-je encore, et ce sur plusieurs architectures. À titre d'exemple, le générateur de code C++ dont je parlais avant est écrit en Haskell, le code C++ est généré sur x86_64 puis compilé en cross compilation pour différentes architectures pour l'embarqué. Tout cela dans bazel.
Nix (https://nixos.org/nix/) pour ta gestion de dépendance. En gros, nix va te créer un environnent reproductible contenant les dépendances de ton projet.
L’expérience windows est correct dans le subsystem for linux. En dehors, j'ai déjà cross compilé des binaires natif windows avec, mais jamais essayé de faire plus. Tout ce qui se lie statiquement facilement doit pouvoir être faisable.
Le problème de la distribution est réglé avec nix si ta cible peut installer nix. Sinon, tu es dans la même situation que pour tous les autres outils de gestion de dépendance / build et je ne connais qu'une unique solution: faire un binaire statiquement lié qui contient tout. Et nix peut t'aider à faire ça.