Discussion :

[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.

[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.

[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.

[progdebutant]

Atha (dans un des six premiers posts) a écrit :

Edit : @Niark13 : effectivement, désolé de l’imprécision. +1 à tout ce que tu as dit.

Je ne vois pourtant pas le message de @Niark13 avant le sien.

Pour en revenir au topic, je suis par rapport à vous tous un débutant mais je trouve que le C est super au vu de tout ce qu'on peut faire avec (jeux rapides, systèmes, etc) et le fait qu'il puisse être dans des micro-contrôleurs.
Et que sa syntaxe me semble facile à comprendre et mémoriser.

D'après une grande partie des messages que j'ai lu je ne pense pas que le C soit actuellement remplaçable donc c'est ce que j'ai voté.

[Artemus24]

Salut à tous.

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…).

Il ne faut pas supposer des choses avant de savoir de quoi on parle. Voici ce que j'ai dit au sujet d'Ada :

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.

Si je parle de ce langage, c'est qu'il y a fort longtemps, je l'ai appris croyant qu'il deviendrait un langage commun aux entreprise, genre langage universel comme PL1 à son époque.
Il se trouve que j'ai travaillé d'abord en gros système BULL et ensuite en IBM, dans le secteur bancaire, sans avoir jamais rencontré le langage Ada.
Si je ne m'abuse pas, c'est bien dans les années 1980 et chez Bull que ce langage a été créé.
Or il se trouve que j'ai travaillé sous GCOS 7 et 8 des systèmes d'exploitations de chez BULL, fort utilisés par les banques à une certaines époques, avant d'être remplacé par de l'IBM MVS/OTSO/ISPF, voire même par de l'AS400.

Et quand je parle du besoin, c'est celle des entreprises. En tout cas, cela n'a jamais répondu au besoin des banques !
Donc il fait relativiser le soi-disant succès d'un langage quand la grande majorité des entreprises ne l'utilisent pas.

Justement l’intérêt est parfois de simplifier les concepts a appendre.

Je ne suis pas contre cette idée, mais ce n'est pas la simplification d'un concept que recherche les entreprises.
Il s'agit bien du temps nécessaire pour développer un projet qui est le nœud gordien des projets. Et comme vous le savez, le temps c'est de l'argent.
Sinon pourquoi le cobol aurait autant de succès en entreprise alors que c'est un très vieux langage ? Avez-vous au moins entendu parlé de PacBase ?

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.

Je ne trouve pas si compliqué que cela le C++. Cela dépend des langages que vous avez pratiquez avant, enfin je suppose.
Il est sûr, que si vous avez pratiqué en premier du Python, le C++ doit vous paraître très compliqué, voire même préhistorique comme langage.

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

vous tombez mal par votre réflexion. Je connais environ un trentaine de langage, surtout en gros système et sous Unix.
Ils ont tous des avantages et des inconvénients, mais aucun ne sort du lot.
Certains répondent à un besoin spécifique pour lesquels ils ont été développés.
Maintenant si vous les utilisez en dehors de ce pourquoi ils ont été crées, je peux comprendre la volonté de changer de langage.

Google a été clair : Go répond a un véritable besoin pour eux.

Là encore Rust a été créé spécifiquement pour répondre à ces besoin et y répond très bien.

Dans ces deux exemples, on voie nettement qu'un besoin se fait ressentir.
D'où la création d'un langage spécifique pour répondre à ces besoins.
Et vous croyez qu'en partant du besoin spécifique à ces entreprises, on va généraliser cela à tout le monde ?
Mais quand est-il des autres qui n'appartiennent pas à Google ou à Mozilla ?

Désolé de le dire, mais vous êtes très enthousiaste !

@+

[Uther]

Et quand je parle du besoin, c'est celle des entreprises. En tout cas, cela n'a jamais répondu au besoin des banques !
Donc il fait relativiser le soi-disant succès d'un langage quand la grande majorité des entreprises ne l'utilisent pas.

En même temps le langage universel parfait n'existe pas. Ada n'a jamais prétendu être le langage parfait pour réponde a tous les besoins.
De plus il faut voir que le bancaire dans lequel vous semblez travailler, c'est un domaine très particulier ou le poids de l’existant est souvent énorme. Dans d'autres domaines, il est moins déterminant (même s'il reste généralement important) et on peut plus facilement se permettre d'utiliser de nouvelles technologies.

Je ne suis pas contre cette idée, mais ce n'est pas la simplification d'un concept que recherche les entreprises.
Il s'agit bien du temps nécessaire pour développer un projet qui est le nœud gordien des projets.
Et comme vous le savez, le temps c'est de l'argent.

A court terme peut-être, mais une base de code vieillissante sur des technologies mal maîtrisées ça peut coûter encore plus cher à long terme. On a plusieurs projet chez nous qui auraient gagné à être refondus il y a longtemps.

Sinon pourquoi le cobol aurait autant de succès en entreprise alors que c'est un très vieux langage ? Avez-vous au moins entendu parlé de PacBase ?

Oui j'ai entendu parler de PacBase, bien que je n'en ai jamais fait personelement. Chez nous, je ne dirais pas que le Cobol est un succès : on a des gens qui font avec dans certains projets bancaires, mais c'est généralement par contrainte et non par choix. On essaie de le remplacer par autre chose dès que c'est faisable sans trop de surcoût.

Je ne trouve pas si compliqué que cela le C++. Cela dépend des langages que vous avez pratiquez avant, enfin je suppose.
Il est sûr, que si vous avez pratiqué en premier du Python, le C++ doit vous paraître très compliqué, voire même préhistorique comme langage.

En général si on trouve le C++ simple, c'est qu'on l'utilise mal. Les concepts ne sont pas foncièrement complexe au premier abord, mais si on ne les connais pas bien toutes les implications parfois subtiles, on se retrouve très facilement avec des erreurs sournoises.

Dans ces deux exemples, on voie nettement qu'un besoin se fait ressentir.
D'où la création d'un langage spécifique pour répondre à ces besoins.
Et vous croyez qu'en partant du besoin spécifique à ces entreprises, on va généraliser cela à tout le monde ?
Mais quand est-il des autres qui n'appartiennent pas à Google ou à Mozilla ?

J'ai cité Google et Mozilla comme exemple et car se sont les créateurs des langages et que s'ils pris la peine de faire ça c'est bien avant tout pour répondre a leur besoins. Mais la simplicité, l'efficacité et la sécurité, c'est des besoins somme toute assez communs, il est évident qu'ils sont partagés par bien d'autres entreprises.

Désolé de le dire, mais vous êtes très enthousiaste !

Je ne vois pas ce que l'enthousiasme a à faire là dedans. Je ne parie pas sur le vainqueur d'une course de chevaux. Comme tout le monde ici, je sais bien que le C n'est pas prêt de disparaître. Mais tout comme le Cobol n'est plus la référence indispensable pour les nouveaux projets, je pense qu'il y a clairement de la place dans les projets bas niveau a venir pour des langages plus modernes qui apportent plus de simplicité, sécurité, ...

[Traroth2]

"Quel langage pour remplacer le C ?"

Je trouve la question mal posée. Le C est un langage fantastique, qui n'a pas besoin d'être remplacé. Si quelque chose de réellement mieux se présente, pourquoi pas, mais il faut vraiment que ça apporte un plus.