Go 1.6 : le langage de Google s'ouvre à Android x86 et HTTP/2

Go 1.6 : le langage de Google s’ouvre à Android x86 et HTTP/2

fmt.Printf("Hello, world\n")

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

01/02/2016 2 minutes
46

Go 1.6 : le langage de Google s'ouvre à Android x86 et HTTP/2

Le langage Go de Google sera bientôt disponible en version 1.6. La première Release Candidate est maintenant disponible, et même si cette mouture ne propose de nouvelles fonctionnalités majeures, elle ajoute tout de même de nouveaux portages, notamment vers Android x86.

Go est un langage lancé par Google en 2012 pour convenir à de nombreux besoins. Conçu pour être simple à prendre en mains, il est fortement inspiré du C++ et de Python, et garde pour mantra de « compiler rapidement du code rapide ». Ses performances sont relativement proches du C, mais sans les atteindre toutefois. Comme son nom le laisse imaginer, il a été créé pour être facilement pris en main.

La version 1.5 avait marqué un tournant dans la vie du langage, puisque le compilateur lui-même était écrit en Go. La version 1.6 a peut-être moins d’ampleur, mais elle s’ouvre sur des plateformes qui n’étaient auparavant pas prises en charge. Dans la Release Candidate apparue en fin de semaine dernière, on trouve donc des portages vers Android x86 32 bits et MIPS 64 bits, avec linking interne uniquement.

Quelques autres modifications sont également prévues. Sur plateforme Linux et architecture PowerPC 64 bits, la compilation supporte cgo et le linking externe, le socle fonctionnel étant presque complet. Sur FreeBSD, le compilateur par défaut change de main et passe de GCC à Clang. Le paquet net/http ajoute quant à lui le support du protocole HTTP/2.

Ceux qui souhaitent en savoir plus pourront lire les notes de version temporaires. Le téléchargement se fera quant à lui depuis cette page. La version finale est prévue pour ce mois-ci et respectera la promesse de compatibilité qui avait été faite lors du lancement de Go 1 : toutes les versions de la branche 1.X sont compatibles entre elles.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Commentaires (46)


Exemple de programme écrit en GO : Heka, un très bon remplaçant de Logstash !!


Pendant un instant, j’ai cru que Heka était un ETL, ce qui m’aurait beaucoup intéressé, mais son usage concerne surtout les logs.


Google. Google partout. Jusque dans le nom du language. <img data-src=" />


GO ?? C’est pour les gogos.. “Comme son nom le laisse imaginer, il a été créé pour être facilement pris en main.”



Du LOGO (lol, language pédagogique, il parait) sans le LO quoi… C’est dans de les vieille soupes qu’on retrouve les meilleures casseroles….


Tu préfères la complexité à la facilité?


Encore un langage de plus, créé par Google non pas pour simplifier la vie des développeurs et améliorer la qualité des applications…. mais plus simplement pour tenter de verrouiller les développeurs dans leur écosystème ! Boycott !


Désolé mais tu fais juste de l’anti-fanboyisme. Du anti-google primaire. Je rappelle que ce langage est open source. Donc parler de verrouillage est totalement stupide.








AlphaBeta a écrit :



Encore un langage de plus, créé par Google non pas pour simplifier la vie des développeurs et améliorer la qualité des applications…. mais plus simplement pour tenter de verrouiller les développeurs dans leur écosystème ! Boycott !







Go n’a aucun lien avec l’écosystème de Google. D’ailleurs le seul lien avec Google c’est que c’est eux qui l’ont créé, le projet étant open source. Le support d’Android x86 est là juste parce que c’est une grande demande des développeurs, comme il y a la même demande pour python.



Si, le nom et les auteurs.








gokudomatic a écrit :



Désolé mais tu fais juste de l’anti-fanboyisme. Du anti-google primaire. Je rappelle que ce langage est open source. Donc parler de verrouillage est totalement stupide.





Tu prends le temps de lui répondre, rien que ça dénote du courage chez toi..



Ca existe des language closed-source ?


Petite pensée émue pour Vincent Hermann, qui pond cet article et qui récolte en retour ces dix onze comms “de qualitay” ci-avant (allez onze douze, incluons le miens, soyons pas chiche) .


Et ?

Ce langage n’apporte rien d’autre que de rajouter de la confusion…. pour enfermer les gens dans les technologies Google, faussement ouvertes….

Pourquoi faire ce Goo quand on le dit tres proche de C++ ? Faites du C++ et basta


Ben voyons! BSD est faussement ouvert? <img data-src=" />


Le premier qui me vient en tête c’est WinDev (si tu veux te marrer va sur leur site, leur communication est assez inhabituelle pour un langage)








gokudomatic a écrit :



Ben voyons! BSD est faussement ouvert? <img data-src=" />



T’as tellement de temps à perdre que tu persistes à lui répondre? <img data-src=" />









Patch a écrit :



T’as tellement de temps à perdre que tu persistes à lui répondre? <img data-src=" />





Oui. Mais j’ai l’impression qu’il m’a filtré. Sinon, si c’est vraiment troll, il m’aurait déjà répondu.



et ?

&nbsp;








AlphaBeta a écrit :



et ?





et rien de plus. J’ai posé ma question entièrement. Libre à toi d’y répondre par oui ou non, ou de ne pas y répondre.









AlphaBeta a écrit :



Et ?

Ce langage n’apporte rien d’autre que de rajouter de la confusion…. pour enfermer les gens dans les technologies Google, faussement ouvertes….

Pourquoi faire ce Goo quand on le dit tres proche de C++ ? Faites du C++ et basta





Réfléchis avant et on en reparle après.



Je t’invite à lire ne serait-ce que la page Wikipédia sur Go, c’est très différent du C++.

Après, si t’aimes pas, t’es pas obligé de l’utiliser.


Un langage simple à prendre en main mais avec des perfs proches du C je prends direct ! Dans le domaine scientifique c’est carrément un plus!



Je passe pas mal de temps à coder, dont une simulation axée sur les performances et je m’arrache souvent les cheveux en C++. Ce langage devient vite ultra complexe dès que l’on s’attarde à “bien coder” et à chercher les performances, sans compter les casse-tête qu’on a à la compilation !



Un langage qui associerait simplicité et flexibilité de Python avec les performances du C me simplifierait tellement la vie pour ma thèse … Il manque juste les libraries scientifiques au Go …


Je vais parler sans savoir, mais je crois que Go peut utiliser des librairies C directement. Donc il peut réutiliser toutes les librairies scientifiques en C.


En effet mais c’est lourd et vraiment pas ergonomique, autant rester sur du C/C++ dans ce cas.








lothoaheur a écrit :



Un langage simple à prendre en main mais avec des perfs proches du C je prends direct ! Dans le domaine scientifique c’est carrément un plus!



Je passe pas mal de temps à coder, dont une simulation axée sur les performances et je m’arrache souvent les cheveux en C++. Ce langage devient vite ultra complexe dès que l’on s’attarde à “bien coder” et à chercher les performances, sans compter les casse-tête qu’on a à la compilation !







C’est une plaisanterie ?



C/C++ est certainement l’un des langages qui permet de garder un style de programmation le plus propre quand on veut un minimum de performances. Comparativement à d’autres langages, il minimise grandement le coût de l’abstraction.



Quand à la compilation, il n’y a rien de spécialement compliqué en C/C++. Mais comme tout langage, le C/C++ a ses spécificités et son style qui doit être appris et compris.



Pour le reste, quand on veut des performances, on est toujours obligé de sortir des styles de programmation “académiques”. Et cela n’a rien à voir avec le langage de programmation utilisé.



Le “bien coder” appris dans les écoles n’est pas orienté performances…





Un langage qui associerait simplicité et flexibilité de Python avec les performances du C me simplifierait tellement la vie pour ma thèse … Il manque juste les libraries scientifiques au Go …





En même temps, il ne faut pas rêver. Pour avoir des performances, il faut taper à bas niveau. Tout le contraire de ce qu’un langage “simplifié” permet…









sr17 a écrit :



En même temps, il ne faut pas rêver. Pour avoir des performances, il faut taper à bas niveau. Tout le contraire de ce qu’un langage “simplifié” permet…





Mais c’est là qu’apparait un paradoxe. Avec un code pragmatique mais sale, tu obtiens une certaine performance. Avec un code académique et lisible, il est possible que tu voies une amélioration possible dans le principe de l’algorithme. Et vu que c’est lisible et propre, la modification peut se faire facilement. Et du coup, il se peut que tu puisses grandement améliorer les performances. Avec un code sale, par contre, vu que c’est peu lisible, c’est aussi difficile de voir un problème dans l’algorithme, et aussi de faire une modification. Du coup, tu es un peu bloqué dans tes choix initiaux.



Maintenant, la différence entre le sale code et le code bas niveau, c’est que le code bas niveau peut être bien pensé. Mais il reste tout aussi peu lisible et coûteux à maintenir/modifier. Tu tombes donc un peu dans la même impasse.









gokudomatic a écrit :



Mais c’est là qu’apparait un paradoxe. Avec un code pragmatique mais sale, tu obtiens une certaine performance. Avec un code académique et lisible, il est possible que tu voies une amélioration possible dans le principe de l’algorithme. Et vu que c’est lisible et propre, la modification peut se faire facilement. Et du coup, il se peut que tu puisses grandement améliorer les performances. Avec un code sale, par contre, vu que c’est peu lisible, c’est aussi difficile de voir un problème dans l’algorithme, et aussi de faire une modification. Du coup, tu es un peu bloqué dans tes choix initiaux.



Maintenant, la différence entre le sale code et le code bas niveau, c’est que le code bas niveau peut être bien pensé. Mais il reste tout aussi peu lisible et coûteux à maintenir/modifier. Tu tombes donc un peu dans la même impasse.







En général un algo tu l’optimises et connais sa complexité avant de l’implémenter. Le genre d’optimisations qui rendent souvent le code moins lisible sont des optimisation d’archi, dépendantes de la plateforme, le plus souvent.



En général, mais pas toujours. Des fois, les idées d’optimisation viennent après, sans que ça ait à voir avec la plateforme.








sr17 a écrit :



C’est une plaisanterie ?



C/C++ est certainement l’un des langages qui permet de garder un style de programmation le plus propre quand on veut un minimum de performances. Comparativement à d’autres langages, il minimise grandement le coût de l’abstraction.



Quand à la compilation, il n’y a rien de spécialement compliqué en C/C++. Mais comme tout langage, le C/C++ a ses spécificités et son style qui doit être appris et compris.



Pour le reste, quand on veut des performances, on est toujours obligé de sortir des styles de programmation “académiques”. Et cela n’a rien à voir avec le langage de programmation utilisé.



Le “bien coder” appris dans les écoles n’est pas orienté performances…







En même temps, il ne faut pas rêver. Pour avoir des performances, il faut taper à bas niveau. Tout le contraire de ce qu’un langage “simplifié” permet…









Dans mon cas, et la plupart des personnes en physique des hautes énergies, je n’ai pas de formation en programmation poussée. Tout au plus des cours de modélisation numérique. 80% de ce que je connais en C++ je l’ai assimilé en tâtonnant.

Et dans cette situation, bien utiliser le C++ est une illusion ! Ça demande plusieurs années de formation et travail !

Parfois pour simplement implémenter un effet dans la simu sur laquelle je bosse, je passe plusieurs jours à me battre pour avoir le résultat attendu. Au prix de manip sales qui rendent mon code brouillon et moins performant.



Ensuite les problèmes de compilation (plus précisément de linkage <img data-src=" /> ) ça devient vite galère quand tu utilises des libs qui dépendent d’une autre libs et celles qui appellent du fortran … tu deviens vite fou !



Donc oui, dans ce cas précis, le gain en simplicité du Go compense largement son manque de perf.



Normal

0





21





false

false

false



FR

X-NONE

X-NONE

































































































































































































































































































































































































































































































































































































































































































































































































































/ Style Definitions /

table.MsoNormalTable

{mso-style-name:“Tableau Normal”;

mso-tstyle-rowband-size:0;

mso-tstyle-colband-size:0;

mso-style-noshow:yes;

mso-style-priority:99;

mso-style-parent:“”;

mso-padding-alt:0cm 5.4pt 0cm 5.4pt;

mso-para-margin-top:0cm;

mso-para-margin-right:0cm;

mso-para-margin-bottom<img data-src=" />.0pt;

mso-para-margin-left:0cm;

line-height:107%;

mso-pagination:widow-orphan;

font-size:11.0pt;

font-family:“Calibri”,sans-serif;

mso-ascii-font-family:Calibri;

mso-ascii-theme-font:minor-latin;

mso-hansi-font-family:Calibri;

mso-hansi-theme-font:minor-latin;

mso-fareast-language:EN-US;}







Hello, oui Heka est principalement dédié au traitement de

très très important volume de logs en temps réel (à la différence de Logstash

qui est en java et donc forcément moins performant et beaucoup plus gourmant qu’une

appli proche du C)







Je ne connais pas ton besoin exact, mais sache que Heka fonctionne de manière

modulaire, en gros, rsyslog est un des modules d’imput, tout comme l’envoi des

infos dans Elasticsearch où InfluxDB / Grapha sont des exemples d’output

module.







Les modules reposent sur LUA, c’est donc relativement facile de développer un

petit module complémentaire pour un besoin spécifique &nbsp;


En parlant de go, il y a un article de prévu sur DeepMind ? <img data-src=" />








lothoaheur a écrit :



Dans mon cas, et la plupart des personnes en physique des hautes énergies, je n’ai pas de formation en programmation poussée. Tout au plus des cours de modélisation numérique. 80% de ce que je connais en C++ je l’ai assimilé en tâtonnant.







En même temps, ce n’est pas une mauvais école même si cela prends du temps.





Et dans cette situation, bien utiliser le C++ est une illusion ! Ça demande plusieurs années de formation et travail !





Il n’y a pas de secret, la programmation, c’est un métier. Et il y a beaucoup de choses à savoir car l’ordinateur est un objet très complexe.



C/C++ est un langage qui est conçu pour donner un maximum de puissance et de contrôle. Mais en contrepartie, il demande plus de connaissances sur le fonctionnement des ordinateurs que d’autres langages. Du moins en apparence, car en réalité, ces connaissances sont également requises pour coder correctement dans n’importe quel langage.



Paradoxalement, un bon moyen de comprendre plus rapidement le C/C++ c’est de faire du langage machine.





Parfois pour simplement implémenter un effet dans la simu sur laquelle je bosse, je passe plusieurs jours à me battre pour avoir le résultat attendu. Au prix de manip sales qui rendent mon code brouillon et moins performant.





Logiquement, vous devriez payer au moins un informaticien, soit pour faire le travail, soit pour vous former et vous enseigner le savoir faire adéquat.



Prenez n’importe quel métier, mettez y quelqu’un qui ne connait pas, vous obtiendrez (au moins au début) un travail perfectible.



On dirait que lorsqu’il s’agit d’informatique, dans l’esprit des gens, un débutant devrait être en mesure savoir tout faire.





Ensuite les problèmes de compilation (plus précisément de linkage <img data-src=" /> ) ça devient vite galère quand tu utilises des libs qui dépendent d’une autre libs et celles qui appellent du fortran … tu deviens vite fou !





Quel que soit le langage utilisé, tu rencontrera des difficultés quand les dépendances sont nombreuses et variées et qu’il faut mixer les langages.



Certains langages modernes peuvent donner l’impression de simplifier la gestion des dépendances, mais cela n’est vrai qu’en apparence, c’est à dire jusqu’au jour ou tu aura un problème et que tu sera encore plus dans la mouise parce que la facilité signifie que tu maîtrisera encore moins les problèmes.





Donc oui, dans ce cas précis, le gain en simplicité du Go compense largement son manque de perf





C’est toujours l’éternel débat en informatique. Est ce qu’on préfère un langage simple ou un langage performant.



Et la vraie réponse est : tout dépends des usages.









gokudomatic a écrit :



Mais c’est là qu’apparaît un paradoxe. Avec un code pragmatique mais sale, tu obtiens une certaine performance. Avec un code académique et lisible, il est possible que tu voies une amélioration possible dans le principe de l’algorithme. Et vu que c’est lisible et propre, la modification peut se faire facilement. Et du coup, il se peut que tu puisses grandement améliorer les performances. Avec un code sale, par contre, vu que c’est peu lisible, c’est aussi difficile de voir un problème dans l’algorithme, et aussi de faire une modification. Du coup, tu es un peu bloqué dans tes choix initiaux.



Maintenant, la différence entre le sale code et le code bas niveau, c’est que le code bas niveau peut être bien pensé. Mais il reste tout aussi peu lisible et coûteux à maintenir/modifier. Tu tombes donc un peu dans la même impasse.







D’une manière générale, quand on écrit du code de bas niveau, c’est parce qu’on écrit un logiciel (ou une portion de code) ou les performances s’avèrent importantes… et que le gain(qui peut s’avérer colossal dans certains cas) en vaut la chandelle.



Mais il va de soi qu’il faut soigneusement étudier l’algorithme au préalable pour être raisonnablement sûr d’avoir épuisé toutes les possibilités de ce côté la.



En pratique il est rare d’utiliser ce style de programmation pour un programme dans son ensemble. D’où l’utilité de langages qui permettent aussi bien de faire du bas niveau que de l’abstraction.



Dites, je veux pas être méchant, mais on s’en tape pas un peu de Go, là ?



Ça devient relou les news sur Chrome, ici Go, ou même Firefox parfois, qui signalent juste qu’une nouvelle mise à jour (même pas majeure !) est sortie, et que sinon, “circulez, rien à voir”, sans grande innovation fondamentale. À ce titre-là il faudrait faire 30 articles par jour pour signaler tous les ajouts de chaque instant dans nombre de technologies, langages, distributions, etc…



L’article ici-même est presque aussi long que celui sur PHP 7, une version majeure, fondamentale, et attendue depuis longtemps, d’un langage bien plus stratégique et important, à qui il aurait fallu, en comparaison, un dossier de 10 paragraphes. <img data-src=" />



Surtout que Next INpact n’a visiblement pas besoin de ce genre d’articles “bateaux” à côté de tant de dossiers de grande qualité sur d’autres technologies, de l’Économie ou de la Politique du numérique, ou les sciences en général.


j’aime pas que l’on site le “C/C++” pour parler du C++. Le C++ pose des centaines de problèmes que le C n’a pas, de plus avec les nouvelles norme du C++ il devient quasiment impossible d’appeler du code compiler avec un ancien compilateur C.



&nbsp;Le C++ est acceptable si tu n’en utilises qu’un sous ensemble (pas de template, éviter le RTTI …). Combien de code ne fonctionne plus parce que tu as juste changé le niveau du compilateur…


Ben non, tout le monde ne s’en tape pas du Go.



Pour mon travail, PHP ne s’applique pas.

Par contre, Go fait partie des langages à surveiller (avec Rust, Swift, Graddle, …).



Question de point de vue donc.

La diversité des articles, c’est bien.








levhieu a écrit :



Question de point de vue donc.





Dans son cas, c’est surtout la question d’accepter la diversité des points de vue, des besoins et des centres d’intérêts qui pose manifestement problème…

&nbsp;









brazomyna a écrit :



Dans son cas, c’est surtout la question d’accepter la diversité des points de vue, des besoins et des centres d’intérêts qui pose manifestement problème…







Pour ma part, je trouve également que c’est intéressant de parler de choses diverses et variées.



D’un autre côté j’aurais aimé un peu plus de recul dans l’article.



Parce que tous les connaisseurs tiqueront sur la comparaison avec le C d’un langage qui utilise le boundchecking et une gestion mémoire par ramasse miettes alors même que ces fonctionnalités font justement partie des points de clivage fort entre le C et d’autres langages tels que C#.



Il y a une lib graphique performante ? Des binds OpenGL ? J’ai un peu regardé la doc mais je trouve rien de pertinent. C’est un environement qui se preterait à du petit jeux vidéo genre Game Jam ?








brazomyna a écrit :



Dans son cas, c’est surtout la question d’accepter la diversité des points de vue, des besoins et des centres d’intérêts qui pose manifestement problème…







Merci de ne pas me faire dire ce que je n’ai pas dit :-)

Je suis toujours ravi d’entendre des trucs à propos de Go, mais il faut quand même qu’un tel article ait un intérêt. Ici c’est assez limité, franchement, pour se retrouver dans la ligne éditoriale de NextINpact, vis à vis de ce à quoi on est habitué.

Ceci dit, ce n’est pas la première fois que je sens une certaine orientation dans des articles sur des technos ; je le comprends tout à fait (on a tous des centres d’intérêts, les rédacteurs aussi), cependant j’ai bien le droit de le faire remarquer.









levhieu a écrit :



La diversité des articles, c’est bien.







Vous ne vous servez peut-être pas de PHP, mais quand même, faire un article sur cette “mise à jour” de Go aussi long ou presque que la mise à jour majeure PHP7, réellement importante dans l’industrie du web, et de l’informatique en générale à cause de l’utilisation massive de PHP, je trouve ça un peu costaud.

Le jour où Go aura également une màj majeure, je serai ravi de lire un article, peu importe sa longueur.

J’ai pris l’exemple de PHP car il m’avait marqué, mais c’est valable avec d’autres articles dans le coin, j’imagine.

Si on me demande le souci selon moi, je répondrais que l’article sur PHP était trop court. Pas que celui-ci sur Go est trop long.









Pazns a écrit :



Merci de ne pas me faire dire ce que je n’ai pas dit :-)

Je suis toujours ravi d’entendre des trucs à propos de Go, mais il faut quand même qu’un tel article ait un intérêt. Ici c’est assez limité, franchement, pour se retrouver dans la ligne éditoriale de NextINpact, vis à vis de ce à quoi on est habitué.

Ceci dit, ce n’est pas la première fois que je sens une certaine orientation dans des articles sur des technos ; je le comprends tout à fait (on a tous des centres d’intérêts, les rédacteurs aussi), cependant j’ai bien le droit de le faire remarquer.



Vous ne vous servez peut-être pas de PHP, mais quand même, faire un article sur cette “mise à jour” de Go aussi long ou presque que la mise à jour majeure PHP7, réellement importante dans l’industrie du web, et de l’informatique en générale à cause de l’utilisation massive de PHP, je trouve ça un peu costaud.

Le jour où Go aura également une màj majeure, je serai ravi de lire un article, peu importe sa longueur.

J’ai pris l’exemple de PHP car il m’avait marqué, mais c’est valable avec d’autres articles dans le coin, j’imagine.

Si on me demande le souci selon moi, je répondrais que l’article sur PHP était trop court. Pas que celui-ci sur Go est trop long.







Je suis d’accord avec toi.



La base d’utilisateurs de ce langage GO doit être relativement faible à l’heure actuelle.












TheDidouille a écrit :



j’aime pas que l’on site le “C/C++” pour parler du C++. Le C++ pose des centaines de problèmes que le C n’a pas, de plus avec les nouvelles norme du C++ il devient quasiment impossible d’appeler du code compiler avec un ancien compilateur C.



 Le C++ est acceptable si tu n’en utilises qu’un sous ensemble (pas de template, éviter le RTTI …). Combien de code ne fonctionne plus parce que tu as juste changé le niveau du compilateur…







La partie C++ a toujours soulevé des grands débats. Et à juste titre IMHO.



Et tous les bons programmeurs sont conscients qu’il faut faire un usage avisé des fonctionnalités de C++ suivant le contexte visé.



Mais cela ne signifie pas pour autant que tout soit à jeter dans C++ ni qu’il faille parler de C et de C++ de manière dissociée (C++ supporte les fonctionnalités de C).



D’ailleurs, depuis le temps que tout le monde critique C++, je note personne n’a été fichu de pondre quelque chose de mieux.

Une pléthore de langages sont apparus, mais rien qui soit en mesure de se positionner en vrai concurrent de C/C++. D’ailleurs, ce n’est pas Go avec son bound checking et son ramasse miette qui pourra prétendre à lui faire de l’ombre.



Pour ma part, je n’ai tenté aucune extrapolation dans les propos du message initial.



&nbsp;En fait, je voulais attirer l’attention sur un point: la difficulté de définir ce que sont les technologies de l’informatique en général, parce que cette notion même est mal définie.



Passer du web à l’informatique en général sous-entend certainement une certaine vision des choses; laquelle, je ne sais pas; mais certainement une interprétation qui laisse de côté toutes lignes de code qui tournent, bien cachées, dans de multiples objets actuel (logiciels de contrôle moteur en tous genres par exemple).



La question peut être posée autrement: Les domaines où les techniques et savoirs de l’informatique sont utilisés sont nombreux, mais l’informatique à propremeent parler recouvre-t-elle tous ces domaines ?








sr17 a écrit :



La base d’utilisateurs de ce langage GO doit être relativement faible à l’heure actuelle.







Je n’irais quand même pas jusque là, et ce n’est pas la question.

Go reste une technologie qui mérite qu’on en parle, mais faut quand même avoir quelque chose à dire, c’est tout.









saladiste a écrit :



Si on crée un langage qui se positionne dans le même segment que le C++, on va juste réinventer le C++.







Des langages qui visent d’autres segments, il y en a une foultitude… et c’est en augmentation constante…



Le segment du C/C++ est le seul segment ou le même langage domine depuis aussi longtemps. Et ça n’est visiblement pas prêt de changer.





Les gens à qui le C++ pose problème ont en général des lacunes en théorie informatique et algorithmique, car on peut très bien faire de la POO en C struct obj; obj_alloc(struct obj); obj_init(struct obj, args); ret_t obj_method(obj*, args); etc….



Globalement, la programmation générique en C++ manque encore de souplesse et de puissance et donne un arrière gout de “beta” prometteuse et puissante, mais mal finie…



Et d’une manière générale, beaucoup de spécialistes du C reprochent aux mécanismes du C++ de faire trop de choses dans le dos du programmeur et de laisser trop de liberté au compilateur d’implémenter des choses de manière peu standardisée. Il est vrai que l’esprit du C aurait pu être mieux respecté.

Tout cela sans compter la norme qui n’évolue pas toujours dans le bon sens (voir la déprecation du mot clé “inline”).



Ma conclusions personnelle, c’est que C++ est un langage fabuleux, indispensable et sans concurrence. Mais le concept dispose encore d’une marge de progression non négligeable…



Dommage que tous les créateurs de langages se battent aujourd’hui pour la palme du langage le plus facile, sécurisé, infantilisant et peu performant.