Oui, c'est vrai arduino est un bon exemple, et nous l'utilisons souvent en C++.
Je ne connais pas d'autre exemple d'interface de ce type pour le C++.
Tu as donc raison, si on fait une IDE, qui gère les makefiles, la CrossCompilation, l'upload du Code avec création de script init pour l'avoir au démarrage, alors Go ou C++ pourraient être des alternatives très intéressantes pour le raspberry pi. Seulement, cela resterait très difficile d'inclure d'autre lib de C++/Go car il faudrait trouver un mécanisme qui permettrait de faire tout le makefile ... en pratique cela se limitera pour les non experts au lib packagées pour cet environnement. C'est pour cela que je pense Python est préféré sur les RPi, car si on arrive à installer un package, après ça sera bon pour tout les programmes que l'on fera. De plus les outils comme pip,conda (gestionnaires de paquets python) marchent pas trop mal dans la plupart des cas, ce qui rend l'installation d'une très grande proportion des lib python facile et donc facile à utiliser.
De plus, lorsque il y a des bouts de programmes trop lents, ce n'est pas si dur de faire un cython de base qui peut aider, et encore mieux si tu rajoutes le typage. Du coup le typage statique arrive lorsque tu en as besoin, pour les performances. Si tu veux moins te faire chier tu peux faire ta fonction lente en numba. Et si c'est ton code numpy qui est trop lent, tu n'as quasiment rien à faire pour utiliser pythran.
Avec ces nouveaux outils d'accélération de code, j'ai bien plus de mal à justifier l'utilisation d'un langage de plus bas niveau.
C'est un peu ça mon point de vue.
De plus dans beaucoup de cas, finalement la vitesse n'est pas prépomdérente, mais une mise en donnée rapide permettant de nombreux aller/retour, elle permet d'optimiser son rendement.
Après, encore une fois, je ne rejette pas C/C++/Fortran/Go/Rust, c'est juste que dans mon activit"é quotidienne, je n'y ai pas encore trouver d’intérêt.
S'il s'avère qu'un jour cela devient indispensable, alors je m'y remettrais dans la douleur.
[^] # Re: C sur Raspberry
Posté par freejeff . En réponse à la dépêche Ordinateur à carte unique : Raspberry Pi 4 et consort. Évalué à 2.
Oui, c'est vrai arduino est un bon exemple, et nous l'utilisons souvent en C++.
Je ne connais pas d'autre exemple d'interface de ce type pour le C++.
Tu as donc raison, si on fait une IDE, qui gère les makefiles, la CrossCompilation, l'upload du Code avec création de script init pour l'avoir au démarrage, alors Go ou C++ pourraient être des alternatives très intéressantes pour le raspberry pi. Seulement, cela resterait très difficile d'inclure d'autre lib de C++/Go car il faudrait trouver un mécanisme qui permettrait de faire tout le makefile ... en pratique cela se limitera pour les non experts au lib packagées pour cet environnement. C'est pour cela que je pense Python est préféré sur les RPi, car si on arrive à installer un package, après ça sera bon pour tout les programmes que l'on fera. De plus les outils comme pip,conda (gestionnaires de paquets python) marchent pas trop mal dans la plupart des cas, ce qui rend l'installation d'une très grande proportion des lib python facile et donc facile à utiliser.
De plus, lorsque il y a des bouts de programmes trop lents, ce n'est pas si dur de faire un cython de base qui peut aider, et encore mieux si tu rajoutes le typage. Du coup le typage statique arrive lorsque tu en as besoin, pour les performances. Si tu veux moins te faire chier tu peux faire ta fonction lente en numba. Et si c'est ton code numpy qui est trop lent, tu n'as quasiment rien à faire pour utiliser pythran.
Avec ces nouveaux outils d'accélération de code, j'ai bien plus de mal à justifier l'utilisation d'un langage de plus bas niveau.
C'est un peu ça mon point de vue.
De plus dans beaucoup de cas, finalement la vitesse n'est pas prépomdérente, mais une mise en donnée rapide permettant de nombreux aller/retour, elle permet d'optimiser son rendement.
Après, encore une fois, je ne rejette pas C/C++/Fortran/Go/Rust, c'est juste que dans mon activit"é quotidienne, je n'y ai pas encore trouver d’intérêt.
S'il s'avère qu'un jour cela devient indispensable, alors je m'y remettrais dans la douleur.