Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Rust
D
Go
C3
Autre langage (à préciser)
Aucun langage ne peut remplacer le C
Je n'ai pas d'avis
Discussion :
Rust perce parce qu'il s'est posé les bonnes questions pour ne pas être un C-killer de plus qui finira aux oubliettes de l'Histoire.
Oui il y aura toujours du C à maintenir dans 50 ans. Mais est-ce qu'il y en aura autant que maintenant ? Mystère.Envoyé par steel-finger
+1000. Rust est un langage objet refoulé. Il en fait sans en faire et du coup ce n'est pas idéal.
"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).
Ou ptêt qu'on revient du paradigme «tout est objet partout tout le temps, seul le mécanisme d'héritage compte, et de toute façon si on crée un langage c'est pour des experts, etc.»
+1000. Rust est un langage objet refoulé. Il en fait sans en faire et du coup ce n'est pas idéal.
La POO a été inventée dans un Bureau de Complication des Affaires Simples. On en reviendra, oui.
Il y aura peut-être un Rust++ plus tard.Sauf qu'il n'y a pas vraiment de classes et d'héritage en Rust.
En tout cas, on est très loin des possibilités de C++
Quand à la protection qu'apporte Rust sur certains points par rapport au C, c'est bien pour les débutants (plus simple), et pour les plus expérimentés (gain de temps, et limitation de risque du à de l’inattention), on espérant que ça ne va pas créer une génération de développeurs moins bons à cause du travail maché. Il y a un mode unsafe, certains programmeurs pourront être tenté de l'utiliser pour des questions de facilité et créeront même une situation pire : un logiciel faillible comme une mauvaise programmation C, mais avec une fausse idée de sécurité car développé en Rust.
Au niveau difficulté : j'ai regardé vite fait la syntaxe, quand on fait du c, ça ne me parait pas inabordable. Mon avis reste un avis de non développeur ayant des notions de C. Ca reste moins déroutant que la syntaxe Python par rapport au C. Après il faut savoir s'adapter.
L'idée n'est pas de refaire un projet existant en C, mais d’envisager l'utilisation de Rust sur un nouveau projet.
Comme il a déjà été dit : il n'y a pas de bons ou mauvais langages, mais des langages plus ou moins adaptés à une situation.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
Non je n'ai pas cette approche.
La POO, comme l'approche procédurale, doit être utilisée à bon escient et d'ailleurs on peut parfois mixer les deux quand c'est nécessaire.
Que soit le style de programmation, ou le langage (et même parfois le système d'exploitation), le choix doit être fait en fonction de la nature du projet et du résultat visé.
Ceci dit, bien souvent, c'est pas possible dans certaines entreprises où une culture informatique définie depuis des lustres va contraindre le développeur...
C'est ce qui a toujours guidé mes choix quand c'était possible...
Y'a pas de null en rust que je sache ou je me trompe?
Je ne comprends pas bien ce que fait C3 d'après cet article, puisqu'on nous dit que le successeur naturel de C devrait être Rust. Pas un mot sur C3. Bizarre, non ?
A part ça, sur l'argument d'un commentateur de la base de code existante, si on va par là on se retrouve en COBOL pour les applications. On survivrait, mais bon...
Non tu ne te trompe pas Zig a repris les type de retours de Rust qui lui même les a repris des langages fonctionnel comme OCaml.
C'est juste que l'article cite les propos du créateur du langage C3.
Aucun langage n'a le statut de successeur naturel du C, même si il y a plusieurs prétendants comme Rust, Zig ou C3.
Aucun langage ne remplacera le C mais le RUST a déjà commencé à s'intégrer dans des systèmes (Google avait réécrit le module bluetooth pour Android qui est devenu plus rapide et stable, il y a une implémentation de SSL aussi, ...)
J'ai testé Rust pour un projet perso au départ. Pour moi le C et le C++ (à l'ancienne façon C objet) restaient les langages les plus puissants.
J'ai un peu galéré parce que ça change, mais ensuite je ne me suis pas senti enfermé par rapport au C. J'ai bien eu l'impression de toujours gérer ma mémoire, juste un peu différemment.
Puis j'ai eu besoin de mon projet perso pour sauver un projet pro et là je dois dire que j'ai quand même été épaté, ça tourne aussi vite qu'en C (du même ordre en tout cas), et c'est d'une stabilité qui fait plaisir (le moteur tourne pendant longtemps avec forte charge sur des serveurs sans aucun souci).
J'ai quand même un peu galéré faute de connaissance du langage pour trouver la structure sans jamais utilisé de unsafe.
Et je suis toujours un débutant en Rust, il y a encore beaucoup de choses à voir.
C'est multi-threads, multi-user avec les sockets réseau, super rapide et puissant là où les autres solutions pétaient sous la charge (pourtant gros serveurs 32 à 40 coeurs et RAM énorme).
J'ai été conquis par le langage et je m'y retrouve vraiment par rapport à du C.
Est-ce que ça le remplace ? Pour de nouvelles choses oui peut-être (en tout cas pour moi),
mais j'aimais bien le C quand même parce que je trouve qu'il reste très proche du langage machine et je suis peut-être maso mais j'ai toujours aimé les pointeurs (de pointeurs de ...).
Et je trouve qu'on programme mieux si on comprend ce qui se passe. Alors le C reste sans doute important comme part de l'apprentissage ?
On peut faire l'équivalent de l'héritage avec la composition. Avec les risques du multi-héritage. l'Idéal serait que le langage introduisent un langage macro qui support l'héritage pour gérer les risques.
L'héritage n'est pas existant dans tout les langages de programmation. Oberon ne supporte pas l'héritage.Ou ptêt qu'on revient du paradigme «tout est objet partout tout le temps, seul le mécanisme d'héritage compte, et de toute façon si on crée un langage c'est pour des experts, etc.»
Ou par quelqu'un qui voulait réduire au maximum les variables et les constantes globales.
En C, il n'y a pas vraiment de besoin de variables globales, et il n'est pas objet. Je ne vois pas le lien entre POO et réduction du nombre de variables globales.
Et tu fais comment pour gérer les signaux sous Unix ?
(enfin je dis sous Unix, mais j'imagine que sous Windows, ça doit être pareil)
Les amateurs de RUST, vous avez un peu essayé GO ? Avantages/Inconvénients ?
Je bosse sur de l'embarqué donc langage C en priorité et je dois dire que lorsque je bosse sur de gros microcontrôleurs (qui supportent un linux), je fais de plus en plus mes programmes en GO : j'aime bien la syntaxe, la création/gestions simple des threads, les bibliothèques disponibles nativement et l'accès à leur code source, la rapidité de compilation, la possibilité de pouvoir facilement changer de plateforme (linux/windows : je développe au départ sous Windows pour gagner en rapidité de développement et ensuite je teste mon programme sur mon système embarqué... mais tout n'est pas testable sur Windows vu que ce n'est pas la même plateforme matérielle).
... par contre, je trouve que sur les forums FR, c'est un peu compliqué d'avoir de l'aide sur le GO.
Il y a une «légère» différence de popularité, tant professionnelle qu'hobbyiste, entre C++ et Oberon.
L'héritage n'est pas existant dans tout les langages de programmation. Oberon ne supporte pas l'héritage.Ou ptêt qu'on revient du paradigme «tout est objet partout tout le temps, seul le mécanisme d'héritage compte, et de toute façon si on crée un langage c'est pour des experts, etc.»
Si on regarde un tout petit peu l'évolution de C++, on remarque assez rapidement que le succès de C++ ne vient pas de ses caractéristiques OO. Si cela avait été le cas, C++ s'appellerait toujours C with classes. Le succès de C++ vient principalement de ses caractéristiques «non objets» comme le polymorphismes, la généricité, etc ; tout ce qui a été rajouté à C with classes par la suite.
C++ traîne l'héritage C (pun intended) qu'il s'impose lui-même comme un boulet. C'est une réelle relation amour/haine. C++ ne peut s'en détacher et il essaye de l'entraîner dans cette folle course à la création d'un langage de plus en plus hermétique (au sens alchimiste du mot) voulant atteindre le «Langage Philosophal».
Ce qui m'étonnera toujours, est que les principaux paradigmes en programmation (procédural, fonctionnel, structuré, oo, modulaire) existent depuis la fin des années 70. Et 40 ans plus tard on en est toujours à ce poser des questions à la con ? Et on s'étonne d'avoir des discussions sur «mais qu'est-ce qui pourrait remplacer le C ?» ! On se réjouit que C++20 intègre les modules !
Après, malgré ce mes propos pourraient laisser entendre, je ne déteste pas C++. Je déteste avant tout ce qu'on en fait, ce qu'on en a fait également.
Quant à C3 … ok, ça fait un peu parler ici mais c'était déjà un «combat d'arrière-garde» il y a 30 ans.
Go et Rust (en minuscule, ce ne sont pas des acronymes) sont des langages que l'on essaie souvent de rapprocher, pour de mauvaises raisons, car leur philosophie est vraiment différente. Ça vient probablement du fait qu'ils ont été présentés publiquement à peu près à la même période, et qu'ils se présentaient tous les deux comme des langages système, ce qui est complètement faux pour le cas de Go qui a depuis renoncé a ce qualificatif.
Rust est un tentative de faire un langage moderne à la fois système et de haut niveau, un peu comme le C++ a son époque, mais en plus cadré et sans l'héritage du C.
Go se situe plus dans la lignée de Java dont il est une simplification supplémentaire, Java étant déjà une simplification de C++. De fait c'est un langage simple en prendre en main et très efficace dans son domaine de prédilection : les application web et la mise en place rapide de solution parallélisée.: Bien que compilé en exécutable, il garde un runtime impactant avec notamment un ramasse-miettes intégré, ce qui l'exclut de pas mal d'usage en tant que langage de bas niveau et le met donc immédiatement hors course en tant que remplaçant du C.
L'objet ne complique pas mon code, il le simplifie.
Tout est encapsulé, les intéractions sont réduites au nécessaire.
La plupart des personnes que j'ai vu s'opposer à l'objet le lient principalement aux éléments graphiques et événements (je reste plutôt autant que possible CLI, à l'ancienne).
DATA DIVISION, langages divisions ?
Bonjour SVE,
Je ne savais pas mais je suis assez surpris qu'on remplace un langage compilé par un langage interprété qui même avec toutes les techniques de caches, JIT et autres, restera moins efficace ce qui veut dire plus lent et consommateur de ressources qu'un langage compilé (la portabilité n'est plus vraiment un critère vue l'homogénéité des parcs informatiques de la fonction publique).
Et les bibliothèques de Python, apparemment argument du choix, sont écrites en natif, vraisemblablement en C ou C++.
Qu'un langage interprété soit utilisé en front office peut se comprendre (contraintes d'efficacité plus faibles et facilité d'adaptation notamment) mais en back office, là où œuvre COBOL, me laisse perplexe.
Salut
Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)
L'efficacité (comprendre "performances d'exécution" ici) ne peut pas être le seul critère pour choisir un langage de programmation.
Je ne suis pas recruteur, mais je crois qu'en 2022, trouver des développeurs.ses COBOL commence à être un sacré challenge. Ce seul argument peut justifier un changement de technologie.
C forever
Bonjour,
Le C a une cible : la programmation de bas niveau en remplacement de l'assembleur. Cela suppose des possibilité et des risques.
L'utiliser pour d'autres usages résultent, je crois, des circuits de formations. Avant la profusion de langages non dépendants des machines (interpréteurs et codes intermédiaires pour machines virtuelles), l'existence de nombreux compilateurs C pour toutes les cibles matérielles de l'époque était un fort moteur pour en faire un outil d'apprentissage.
Il se trouve que le milieu professionnel hérite de ces situations : c, basic puis java en sont les illustrations. C'est assez inévitable, si la majeure partie des gens qui sortent de formation (donc peu chers) connaissent une technique, elle devient un standard de facto et s'impose même dans des domaines où elle n'est pas la mieux adaptée.
C est bien tel qu'il est. Qu'il ait des successeurs mieux adaptés à tel ou tel usage pour des profils divers de développeurs n'est pas choquant.
Plutôt que le remplacer, il y a quelques améliorations que j'espère certainement en vain. Le switch est manifestement du domaine. Il est étonnant qu'un langage aussi élidé soit aussi verbeux dans ce cas. Les cases avec range seraient bienvenus (je crois qu'il y a eu des tentatives) : le mot clé case pourrait alors devenir facultatif. Une alternative aux break, genre si {...} derrière le case pas de passage en séquence sauf s'il y a un continue dans le block). Des fonctions imbriqués pourraient être pratiques (ne serait ce que pour diminuer l'incitation aux variables globales). Le code de non duplication #ifndef... devrait pouvoir être supprimé. Etc.
Salutations
Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)
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.
Répondre avec citation
Partager