Pour moi l'avenir c'est un système du type S# + Bartok
D
Rust
Go
Autre langage (lequel ?)
Aucun langage ne peut remplacer le C
Pas d'avis
Pour moi l'avenir c'est un système du type S# + Bartok
Le projet de R&D de Microsoft dont on ne sait pas grand chose et qui a été en grande partie abandonné?
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++. =)
Suffit de ne pas les remplacer et le problème est réglé pour trouver leurs successeurs
Ah oui on va remplacer le C avec des langages à GC, bravo....
Rust n’a pas de GC.Envoyé par nevada51
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…
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.
N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java
Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI
- 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.
Tu es sûr de ça ?Envoyé par Uther
Moi j’ai l’impression que ça se désactive via une variable d’environnement :
Ou via la fonction SetGCPercent (avec une valeur négative) :Envoyé par https://golang.org/pkg/runtime/
Envoyé par https://golang.org/pkg/runtime/debug/#SetGCPercent
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.
"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.
@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).
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).
"Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain
Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).
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.
Je vois mal comment, ils ne jouent pas dans la même cour.Envoyé par air-dex
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.
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.
Salut à tous.
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.Envoyé par Olivier Famien
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.
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.Envoyé par Olivier Famien
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.Envoyé par Olivier Famien
Je ne voie pas la relation de cause à effet.Envoyé par Olivier Famien
Je voie plusieurs problèmes dans l'acceptation d'un nouveau langage :Envoyé par Olivier Famien
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.
La véritable question est : "un nouveau langage pour faire quoi avec" ?Envoyé par Olivier Famien
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.
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.Envoyé par Olivier Famien
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.
@+
Si vous êtes de mon aide, vous pouvez cliquer sur .
Mon site : http://www.jcz.fr
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…).Envoyé par Artemus
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)
Pour vivre heureux, vivons cachés. Proverbe alien.
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.
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.
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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager