Discussion :

[redcurve]

Pour moi l'avenir c'est un système du type S# + Bartok

[Uther]

Le projet de R&D de Microsoft dont on ne sait pas grand chose et qui a été en grande partie abandonné?

[Iradrille]

Inconvénients de D

Manque du soutien de grandes firmes : il est notoire que plusieurs langages de développement ont été fortement adoptés du fait du soutien de grandes entreprises. Malheureusement, D ne bénéficie pas de ce coup de pouce. Son développement est donc laissé entre les mains de sa communauté fortement peuplée d’ingénieurs qui font plus preuve de perspicacité que de leadership, charisme ou vision à long terme.

D est (était ?) utilisé chez Facebook.

M'enfin je vois plus D comme un concurrent au C++ qu'au C. Rien que la présence d'un garbage collector (désactivable, certes) peut gêner pour les projets sur embarqué et / ou avec contraintes de temps réel.
La syntaxe est par contre agréable, contrairement au bordel qu'on a en C++. =)

[nirgal76]

Suffit de ne pas les remplacer et le problème est réglé pour trouver leurs successeurs

[nevada51]

Ah oui on va remplacer le C avec des langages à GC, bravo....

[grim7reaper]

Ah oui on va remplacer le C avec des langages à GC, bravo....

Rust n’a pas de GC.
Pour Go et D, le GC est désactivable (après, qu’est ce qui reste utilisable avec le GC désactivé, je ne sais pas…)
Faudrait voir à prendre le temps de lire…

[Gugelhupf]

La question "Quel langage pourrait remplacer C ?" ou ses dérivés ("Est-ce que le C va mourir ?" etc) revient tout les ans, dans 20 ans on aura toujours du C et niveau concept il n'aura pas bougé d'un poil.

[Uther]

Rust n’a pas de GC.
Pour Go et D, le GC est désactivable (après, qu’est ce qui reste utilisable avec le GC désactivé, je ne sais pas…)
Faudrait voir à prendre le temps de lire…

• En Go, le ramasse-miettes n'est pas du tout désactivable.
• En D, le ramasse miette est théoriquement désactivable, mais personne n'ose le faire parce que la bibliothèque standard repose presque entièrement dessus, on perd énormément des fonctionnalités. Visiblement ils essayent de corriger ce point.
• En Rust, il n'y a aucune notion de ramasse-miette, ni dans le langage, ni dans les bibliothèques standard.

[grim7reaper]

• En Go, le ramasse-miettes n'est pas du tout désactivable.

Tu es sûr de ça ?
Moi j’ai l’impression que ça se désactive via une variable d’environnement :

The GOGC variable sets the initial garbage collection target percentage. A collection is triggered when the ratio of freshly allocated data to live data remaining after the previous collection reaches this percentage. The default is GOGC=100. Setting GOGC=off disables the garbage collector entirely.

Ou via la fonction SetGCPercent (avec une valeur négative) :

SetGCPercent sets the garbage collection target percentage: a collection is triggered when the ratio of freshly allocated data to live data remaining after the previous collection reaches this percentage. SetGCPercent returns the previous setting. The initial setting is the value of the GOGC environment variable at startup, or 100 if the variable is not set. A negative percentage disables garbage collection.

[Uther]

J'avais supposé que vu que Go a été intégralement conçu pour fonctionner avec un ramasse-miette, on ne pouvait désactiver le GC.
Mais il seblerait que ça soit possible. Cela dit, c'est a éviter absolument sauf cas très particulier, vu que contrairement au D, Go n'a aucun mécanisme de libération explicite de la mémoire.
Si on désactive le ramasse-miette, le programme va marcher comme si de rien n'était, mais la mémoire alloué ne sera jamais libérée : le programme va consommer de plus en plus de mémoire et finir par la saturer. Bref c'est juste utilisable pour des programmes à très courte durée de vie qui se termineront avant d'avoir consommé trop de mémoire.

En D quand on n'utilise pas le ramasse miette, on se rabat sur une gestion manuelle de la mémoire quitte à se passer d'une grande partie des bibliothèques (y compris la bibliothèque standard) qui ne le supportent pas.

[YingYan]

"Andrei Alexandrescu (un des co créateur du langage D)"

Article biaisé de base car il propose comme alternative un langage dont il est un des co créateur.

Donc aucun intérêt sur les avantages/inconvénients car il y a forcément un parti pris.

Et puis quel langage pourras remplacer tel autre ? aucun. chaque langage à ces spécificités et chacun est intéressent suivant les besoins, difficultés à résoudre ...

C'est comme si on se pose la question de quel langage pourras remplacer l'assembleur. Aucun puisqu'au final tout langage compilé devient de l'assembleur, ou un bit code interprété par une machine virtuel qui elle est finalement en assembleur.

Donc si on suit un tel résonnement le seul langage valable est l'assembleur.

Alors chacun sont langage, avec ces avantages et inconvénients et nos moutons seront bien gardés.

[imperio]

@YingYan: Je t'assure que des langages sont devenus désuets au fur et à mesure que de nouveaux sont sortis. On peut même considérer que la nouvelle version d'un langage est un tout autre langage, rendant l'autre désuet. D'ailleurs, certains langages ne se basent pas sur l'assembleur pour se compiler (bien que le bytecode généré soit toujours le même sur une plateforme donnée).

[air-dex]

Ce qui est sûr c'est que le C ne disparaîtra pas de sitôt. Même s'il disparaissait de tous les nouveaux projets du jour au lendemain, il y aura toujours 43 ans de code en C à maintenir ou bien à porter sur son ou ses successeurs. De quoi assurer de l'Emploi pour des dizaines d'années.

Si l'un des langages devait ici prendre la place du C alors je vois bien Go le faire.

• Le D a raté le train. C'est trop tard pour lui.
• Go a la chance d'avoir Google derrière lui et Docker en guise d'énorme publicité.
• Rust est à mon avis le meilleur des trois mais 1°) ce n'est que Mozilla derrière et 2°) aucun projet le met en avant, Servo restant relativement confidentiel à mon avis.

La "guerre" entre Go et Rust n'est pas finie, les avantages de Go ne sont pas décisifs (Dart ), mais n'empêche qu'à l'heure actuelle c'est Go le mieux placé. C'est un plutôt pro-Rust qui le dit.

Après iront-ils jusqu'à remplacer progressivement le C ? Seul le temps nous le dira. Le C a 43 ans et il en a vu des "C-killers" s'effondrer devant lui (D ?), ou au mieux cohabiter avec lui (C++). Il a aussi vu des langages majeurs s'effondrer et devenir de niche quand ils n'ont pas disparu ou presque (COBOL, Fortran...). Le C est increvable et le restera jusqu'à ce qu'on trouve le langage qui l'éclipsera pour de bon (ou presque).

[Uther]

Si l'un des langages devait ici prendre la place du C alors je vois bien Go le faire.

• Le D a raté le train. C'est trop tard pour lui.
• Go a la chance d'avoir Google derrière lui et Docker en guise d'énorme publicité.
• Rust est à mon avis le meilleur des trois mais 1°) ce n'est que Mozilla derrière et 2°) aucun projet le met en avant, Servo restant relativement confidentiel à mon avis.

La "guerre" entre Go et Rust n'est pas finie, les avantages de Go ne sont pas décisifs (Dart ), mais n'empêche qu'à l'heure actuelle c'est Go le mieux placé. C'est un plutôt pro-Rust qui le dit.

Je pense que cette façon de comparer n'est pas vraiment la bonne.

Go à certes du succès mais il prend plutôt la place de langages comme Java, Ruby, Python, ... Il ne peut tout simplement pas prendre la place de C car il n'est juste pas utilisable dans la plupart des domaines ou on utilise aujourd'hui le C. Le Go n'a pas été pensé pour faire des applications où le contrôle de ce qui se passe à bas niveau est essentiel, comme un navigateur ou un moteur de jeu vidéo AAA. Il est même carrément inutilisable pour la programmation système comme les drivers, les OS ou des machines embarqués minimales.

Enfin comparer directement le taux d'adoption de Go et Rust n'est pas tout a fait juste non plus. Ça fait moins d'un an que Rust est en version stable alors que Go l'est depuis 6 ans. Un an après sa sortie Go avait encore mois de gros projets le supportant que Rust n'en a aujourd'hui.

[grim7reaper]

Si l'un des langages devait ici prendre la place du C alors je vois bien Go le faire.

Je vois mal comment, ils ne jouent pas dans la même cour.
Même avec Google derrière qui le présentait comme un remplaçant au C et C++, il n’a jamais décollé dans ces communautés là…
Il a certain succès, mais pas dans ce domaine.

[CodeurPlusPlus]

Les amateurs de C sont comme les membres d'une secte (dont je fais partie). On ne les convaincra pas que leur langage fétiche peut être remplacé par untel ou untel.

Les amateurs de C++ sont encore plus fanatiques.

[Artemus24]

Salut à tous.

Ayant été inventé dans les années 70, ce langage jouit encore aujourd’hui d’une forte communauté. Toutefois, en raison de certains inconvénients qu’on lui connait, plusieurs solutions ont été proposées en vue de remplacer ce langage.

Le cobol a été inventé en 1959 et est toujours d'actualité. Il a aussi quelques inconvénients mais dans l'ensemble, il est adapté à l'informatique de gestion.
Tous les langages qui ont voulu s'imposer n'ont jamais détrôné le cobol. C'est ce genre de question qu'il faut se poser, à savoir la raison de son succès.

Go a été conçu afin d’offrir un langage de programmation simple pour le développement des applications système. Ce domaine a été longtemps dominé par Java.

C'est totalement faux ! La plupart des systèmes d'exploitation et de surcroit des applications systèmes sont encore développés en C et surtout en C++ et non en java.

le fait que Go a été développé par Google représente selon Andrei un élément essentiel pour attirer les développeurs vers cette plateforme, même s’il n’est pas foncièrement extraordinaire.

Encore faux ! La réputation d'un langage n'a rien à voir avec celui qui le commercialise. Ce sont les développeurs, au final, qui auront le dernier mot, car ce sont eux qui aimeront ou pas l'utiliser.

La seule image de Google est suffisante pour inciter les développeurs à adopter le langage.

Je ne voie pas la relation de cause à effet.

Cette perception complique davantage les choses dans le milieu professionnel, car les ingénieurs et décideurs sont réticents à adopter un langage qui ne parvient pas à décoller depuis toutes ces années.

Je voie plusieurs problèmes dans l'acceptation d'un nouveau langage :
1) si vous connaissez déjà un langage équivalent à ce nouveau langage, il n'y a aucune raison de basculer vers ce nouveau langage.
2) une entreprise doit se concentrer dans son existant et non se diversifier en terme de langage car niveau maintenance, vous risquez de ne pas toujours trouver des développeurs maitrisant ces langages.
En d'autre terme, plus un langage est rare et plus cela coute cher pour trouver les compétences.
3) un nouveau langage propose de nouveaux concepts. La maitrise de ces nouveaux concepts peut à long terme être source de problèmes s'ils ne sont pas assimilés par tout le monde.
Qui dit concept, dit justement une phase d'acceptation par les développeurs avant de devenir la nouvelle norme de demain.
4) un langage ne se résume pas à sa performance ou à la gestion de sa mémoire, sinon tout le monde ferait de l'assembleur.
Plus on passe de temps à développer et plus cela coûte de l'argent. C'est souvent cette caractéristique qui est considéré par les entreprises et qui manque dans la dimension du langage.
J'ai bien aimé le concept du langage de quatrième génération. Concis, facile à développer, à mettre en œuvre et à maintenir. Sauf que le langage était interprété et non compilé.
D'où une très mauvaise performance en terme de temps d'exécutions.

Pour Andrei, les caractéristiques d’introspection statique, le temps de compilation assez rapide ainsi que les nombreux atouts uniques au langage D font de celui-ci le remplaçant idéal à C.

La véritable question est : "un nouveau langage pour faire quoi avec" ?
Il existe beaucoup de langages dans le monde informatique résolvant des tas de problèmes.
Il y a des langages de programmations, genre procédurale ou orienté objet.
Il y a des langages de commandes qui viennent encapsuler les exécutables qui ont été développés avec les langages de programmations.
Il y a des langages de présentation servant à la mise en page des données.
Il y a des langages tournés vers le système, d'autre vers la résolution de problèmes mathématiques ...

On s’aperçoit que les nouveaux langages sont presque toujours des langages de programmations qui n'amènent rien de nouveaux, juste un concept qui pourra faire de son auteur une célébrité ou un inconnu.
Mais des langages vraiment utiles, comme par exemple les langages de commandes, il y en a très peu, et souvent ils sont très vieux.

Je ne voie pas trop l'intérêt de créer un nouveau langage alors que l'on ne maitrise pas toujours très bien, ceux déjà existant.

Partant de ce fait, il trouve que Go est dépassé et n’a même pas saisi le problème, tandis Rust s’essaye à donner quelques éléments de solutions. Et pour aller encore plus loin, Andrei estime que comparativement à D même C++ « s’est égaré dans les bois ».

C'est trois langages, à savoir Go, Rust et D n'ont aucun avenir car le succès d'un langage se fait dans ses premières années ou bien jamais.
Je prends aussi comme exemple Ada qui était très prometteur en son époque ou encore Prolog. Hors d'un contexte universitaire, je n'ai jamais vu ces langages en entreprise.
D'où mon sentiment que ces langages ont été écrits d'abord par l'auteur pour se faire plaisir et non pour répondre à un réel besoin.

Je dirais que le successeur de C/C++ est lui-même.

@+

[grim7reaper]

Je prends aussi comme exemple Ada qui était très prometteur en son époque ou encore Prolog. Hors d'un contexte universitaire, je n'ai jamais vu ces langages en entreprise.
D'où mon sentiment que ces langages ont été écrits d'abord par l'auteur pour se faire plaisir et non pour répondre à un réel besoin.

Il faut vraiment ne pas connaître Ada pour sortir qu’il n’est pas utilisé en entreprise et qu’il n’a pas été créé pour répondre à un besoin (il suffit de se renseigner sur l’histoire de la création du langage…).

[doublex]

Pour moi, le C est le "Latin" des langages programmation. On le retrouve d'ailleurs comme ossature de certains langages, C++, bien sûr, mais aussi Java.
Je dois confier que le Java J2SE est plus aisé à manipuler que le C. Mais le C sera toujours le C.

(Petit rappel: avec Flex et Bison, n'importe qui peut créer un langage)

[Uther]

Je ne voie pas trop l'intérêt de créer un nouveau langage alors que l'on ne maitrise pas toujours très bien, ceux déjà existant.

Justement l’intérêt est parfois de simplifier les concepts a appendre. Le C++ est une horreur a ce niveau : il est inutilement complexe. Le but de langage comme le Go est justement d'être bien plus simple a maîtriser.

Rust, même s'il introduit des concepts de propriété, vise a encadrer l'utilisateur pour éviter les erreurs.

D'où mon sentiment que ces langages ont été écrits d'abord par l'auteur pour se faire plaisir et non pour répondre à un réel besoin.

Je remarque que la majorité de ceux qui critiquent les autres langages que leur chouchou ne les connaissent pas:

• Google a été clair : Go répond a un véritable besoin pour eux. Ils ont beaucoup de jeunes recrues qu'ils veulent rapidement productifs. La simplicité d'apprentissage de Go et ces performance correctes (bien que inférieures au C) leur est d'une grande aide dans beaucoup de leur projets internes.
• Mozilla quant a lui avait besoin d'un langage de bas niveau avec des performance comparables au C++, mais qui l'aide à produire du code plus sur au niveau de la gestion de ressources (notamment la mémoire) et la concurrence. Là encore Rust a été créé spécifiquement pour répondre à ces besoin et y répond très bien.

Petit rappel: avec Flex et Bison, n'importe qui peut créer un langage

On va certes arriver à avoir un parseur très rapidement, mais après si on veut faire un langage complet avec des concepts évolués et des performances correctes, il faudra quand même énormément plus de travail.