L'étiquette go est masquée (et c'est qui était étiqueté go a aussi été réétiqueté golang). golang est l'étiquette pour le langage go. jeu_de_go est l'étiquette pour le jeu de go.
The main reason is to expand the number of platforms our Mender client can support to increase compatibility with platforms aimed at the embedded market. These include the common RTOS platforms: QNX, Zephyr, FreeRTOS, and VxWorks
Donc ils choisissent de faire du C++ pour être compatibles avec plus de cibles. Ce n'est pas un abandon complet car la partie serveur reste en Go :
Please note: Our server will remain developed in Go; This change only affects the Mender client
Donc effectivement l'article est un genre de rétrospective?
Mais vraissemblablement il a suffi d'un (ou plusieurs) client prêt à payer assez cher pour avoir une version du client fonctionnant sur QNX ou un autre système embarqué où c'est compliqué de faire du Go pour convaincre Mender de changer d'avis. Ils n'avaient pas du tout imaginé ce cas de figure lors de l'écriture de l'article, je pense? En tout cas ce n'est pas listé dans les arguments pour ou contre dans la comparaison.
Je vais faire le vieux… ça fait 20 ans que je fais du C++, ça fait 20 ans que je lis qu'il faut arrêter de faire du C++ pour faire plutôt du (mettre ici le langage à la mode du moment).
Et PowerPC allait même mettre Intel en faillite.
Il n'y a pas de version de Rust pour QNX il me semble. Il y a donc deux options:
Si on est Google, on peut réécrire QNX en Rust et dire à tous ses clients d'utiliser ce nouveau système et d'abandonner toute leur expérience avec QNX et C ou C++,
Si on est pas Google, on peut choisir un autre langage de programmation, et dire à ses clients qu'on est d'accord pour porter une application vers l'OS qu'ils ont choisi.
Tout ce qu'on peut en conclure, c'est que Mender n'est pas Google.
Mon autre petit doigt me dit que quand même Google qui ne sont pas que des branquignoles a fait un choix différent dans un contexte un peu similaire
Google est une entreprise qui essaye pleins de choses, mais n'hésite pas à les abandonner; les prendre comme guide, c'est un peu comme faire un lemming dans le jeu du même nom; y'a beaucoup de sacrifice pour arriver aux niveaux suivants.
Récemment c'est Stadia, mais on a aussi eu leur tentative avec google plus, les différentes mouture de google talk, hangout…
Et ils ont des directive de codage d'un autre âge, au moins sur la limite des colonnes 80 caractères sur des écrans de plus en plus large c'est ridicule. Je ne code pas sur un téléphone portable.
Mon petit doigt me dit que pour l'embarqué, Rust va encore pour pas mal de temps ne pas être le premier choix pour cette raison.
L'embarqué comprend de très nombreux domaines d'applications mais dans les domaines normés, quand le logiciel est dit "sécuritaire", il parfois obligatoire d'utiliser des langages éprouvés. Dans ces domaines, pour les logiciels sécuritaires, il faudra donc attendre que les usages de Rust soient plus répandus, que les normes évoluent et que cela soit intégré/accepté par les équipes de développement. Le cycle est en marche avec une intégration dans le kernel Linux mais j'ai du mal à croire que cette évolution se fasse en moins de 10 ans donc le C et le C++ ont encore de belles années devant eux dans certains domaines de l'embarqué.
# Message pour la modération
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
étiquettes à fusionner: go et golang
[^] # Re: Message pour la modération
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 7.
Ça fait gogolang ça ?
--->[]
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Message pour la modération
Posté par Pol' uX (site web personnel) . Évalué à 5.
Go-go-gadget à l'étiquette !
Adhérer à l'April, ça vous tente ?
[^] # Re: Message pour la modération
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
L'étiquette go est masquée (et c'est qui était étiqueté go a aussi été réétiqueté golang).
golang est l'étiquette pour le langage go.
jeu_de_go est l'étiquette pour le jeu de go.
# Pas vraiment un abandon
Posté par nico4nicolas . Évalué à 8.
Donc ils choisissent de faire du C++ pour être compatibles avec plus de cibles. Ce n'est pas un abandon complet car la partie serveur reste en Go :
[^] # Re: Pas vraiment un abandon
Posté par Glandos . Évalué à 5.
C'est pas vraiment le cas d'utilisation de tous les logiciels là non plus.
Et puis, je comprends pas un truc. L'article parlant du choix de Go vs C/C++ date … d'avril 2022 : https://stackoverflow.blog/2022/04/04/comparing-go-vs-c-in-embedded-applications/
Et 9 mois plus tard, on réécrit tout dans un autre langage ? Ou alors l'article original n'est paru que longtemps après le choix de Go ?
[^] # Re: Pas vraiment un abandon
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Le client Mender était écrit en Go au moins depuis 2016 d'après https://github.com/mendersoftware/mender/commits/69da9a6a90c73fd218ad0d34addfc7617371c246/client.go?browsing_rename_history=true&new_path=client/client.go&original_branch=master
Donc effectivement l'article est un genre de rétrospective?
Mais vraissemblablement il a suffi d'un (ou plusieurs) client prêt à payer assez cher pour avoir une version du client fonctionnant sur QNX ou un autre système embarqué où c'est compliqué de faire du Go pour convaincre Mender de changer d'avis. Ils n'avaient pas du tout imaginé ce cas de figure lors de l'écriture de l'article, je pense? En tout cas ce n'est pas listé dans les arguments pour ou contre dans la comparaison.
# Pourquoi pas Rust ?
Posté par tisaac (Mastodon) . Évalué à 5.
Alors que C'est le moment d'arrêter d'initier de nouveaux projets en C ou C++ et de passer à Rust, on pourrait s'étonner du choix de l'équipe de Mender.
Leur justification est la suivante:
Mon petit doigt me dit que pour l'embarqué, Rust va encore pour pas mal de temps ne pas être le premier choix pour cette raison.
Mon autre petit doigt me dit que quand même Google qui ne sont pas que des branquignoles a fait un choix différent dans un contexte un peu similaire
Mon troisième petit doigt remarque qu'en tout cas cela confirme que Go n'est pas le plus adapté des langages pour ces contextes.
Mon dernier petit doigt n'a pas d'avis du tout. Et vous ?
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Pourquoi pas Rust ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Je vais faire le vieux… ça fait 20 ans que je fais du C++, ça fait 20 ans que je lis qu'il faut arrêter de faire du C++ pour faire plutôt du (mettre ici le langage à la mode du moment).
Et PowerPC allait même mettre Intel en faillite.
Alors ces phrases…
[^] # Re: Pourquoi pas Rust ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Il n'y a pas de version de Rust pour QNX il me semble. Il y a donc deux options:
Tout ce qu'on peut en conclure, c'est que Mender n'est pas Google.
[^] # Re: Pourquoi pas Rust ?
Posté par fearan . Évalué à 5.
Google est une entreprise qui essaye pleins de choses, mais n'hésite pas à les abandonner; les prendre comme guide, c'est un peu comme faire un lemming dans le jeu du même nom; y'a beaucoup de sacrifice pour arriver aux niveaux suivants.
Récemment c'est Stadia, mais on a aussi eu leur tentative avec google plus, les différentes mouture de google talk, hangout…
Et ils ont des directive de codage d'un autre âge, au moins sur la limite des colonnes 80 caractères sur des écrans de plus en plus large c'est ridicule. Je ne code pas sur un téléphone portable.
https://google.github.io/styleguide/jsguide.html
Bref google c'est pas une boussole, ils ont énormément de projets; de grande réussites, mais ils leur arrivent de se planter.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pourquoi pas Rust ?
Posté par nico4nicolas . Évalué à 4.
L'embarqué comprend de très nombreux domaines d'applications mais dans les domaines normés, quand le logiciel est dit "sécuritaire", il parfois obligatoire d'utiliser des langages éprouvés. Dans ces domaines, pour les logiciels sécuritaires, il faudra donc attendre que les usages de Rust soient plus répandus, que les normes évoluent et que cela soit intégré/accepté par les équipes de développement. Le cycle est en marche avec une intégration dans le kernel Linux mais j'ai du mal à croire que cette évolution se fasse en moins de 10 ans donc le C et le C++ ont encore de belles années devant eux dans certains domaines de l'embarqué.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.