Discussion :

[commandantFred]

...
b/ garbage collector qui se lance a un moment non approprié et provoque un 'lag' sur l'equipement.
etc.
bref des choses qu'on maitrise parfaitement en C, mais qu'on subit en C#.
Alors oui l'interet du C pour moi a toujours ete de pouvoir maitriser parfaitement tout ce que tu fais (memoire, pointeurs etc), mais jugé trop compliqué on a inventé le C# pour des devs qui veulent faire du C a la sauce Visual Basic (sans se prendre la tete). Ceci dit les pbs de memoire on les a maintenant en C# car il faut savoir quand bien faire des Dispose() et autres operations du genre.

Alors oui on parle de temps de reponse qui doivent etre largement inferieurs a la seconde (un usager qui se pointe devant notre equipement et qui attend plus d'une seconde est inacceptable).

On peut forcer le garbage collector :https://msdn.microsoft.com/en-us/lib...(v=vs.71).aspx

Idéalement juste après dispose() sur de grandes plages mémoire mais on peut aussi oublier le dispose , la GC libérera toutes les ressources qui n'ont plus de référence active. J'ignore si c'est propre ou non. C# ne fonctionnera jamais sans GC mais il se peut que le code soit porté vers un langage sans GC ...


Pour moi, l'intérêt du C est sa vitesse d’exécution et l'absence de runtime sujet à engorgements. Difficile de dire combien d'applications utilisent le .Net Framework à l'instant T et ça peut poser questions dans le cas d'un driver. La vitesse d'exécution reste le critère primordial pour le traitement de signal.

Je crois que les développements de gestion ont tendance à considérer le traitement de signal comme une sorte de curiosité métier très verticale. Pour ma part, elle a la même priorité que la gestion des données.
Ce qui m'agace un peu, c'est qu'on parle uniquement de "programmation système" alors qu'en l'espèce, ce sont plutôt des traitements virgule flottante lourds. Le système n'a rien à voir...

[VivienD]

Je rejoins plus ou moins Kannagi. Le C a encore toute sa place dans la programmation embarquée, même s'il y a une couche Embedded Linux intermédiaire; il en va de même que la programmation système. D'autre part, le langage qui peut véritablement faire de l'ombre au C n'est autre que le C++ qui, si on s'y prend correctement, nous permet les mêmes joyeusetés tout en ajoutant 'encapsulation et les templates dans l'équation. Enfin, le C oblige, certes, à se soucier de la gestion de la mémoire mais cela permet, entre autres, de gérer la dite mémoire comme on l'entend, sans compter sur le fait que cette gestion, aussi basique puisse-t-elle être, ne devrait pas relever de la gageure pour quiconque avec déjà quelques décennies d'expérience en C.

[commandantFred]

Je rejoins plus ou moins Kannagi. Le C a encore toute sa place dans la programmation embarquée, même s'il y a une couche Embedded Linux intermédiaire; il en va de même que la programmation système. D'autre part, le langage qui peut véritablement faire de l'ombre au C n'est autre que le C++ qui, si on s'y prend correctement, nous permet les mêmes joyeusetés tout en ajoutant 'encapsulation et les templates dans l'équation. Enfin, le C oblige, certes, à se soucier de la gestion de la mémoire mais cela permet, entre autres, de gérer la dite mémoire comme on l'entend, sans compter sur le fait que cette gestion, aussi basique puisse-t-elle être, ne devrait pas relever de la gageure pour quiconque avec déjà quelques décennies d'expérience en C.

Okay, je suis un fan absolu de C. C'était mon premier job, mes premières émotions de developpeurs...

J'ai loué sa simplicité et son rapport simple avec le système jusqu'à ce que...
...je comprenne que c'est aussi sa principale faiblesse ! C n'installe pas de framework compliqué, arbitraire, son framework à lui, c'est le CPU et c'est là que le bas blesse. Car s'il sait très bien optimiser la vitesse en adressant les registres, la pile système (celle qui est pointée par CPU->SP), il n'est pas moins très standardisé dans leur usage et il n'a pas été difficile aux pirates d'utiliser cette simplicité à leur avantage. Stocker les adresses de retour de fonctions sous la pile du CPU était limpide dans les 70's. Aujourd'hui, c'est une faille de sécurité majeure.
Ne pas vérifier le dépassement des chaines et des tableaux, se contenter de les ajouter sur le tas était tellement logique... Aujourd'hui c'est devenu la première porte d'entrée des trojans !!

Alors, j'ai déchanté un peu.

Sur le C++ , je suis plus mitigé. Je crois qu s'il était vraiment réussi, il n'y aurait pas autant de prétendants à la même filiation avec le vénérable ancêtre de Kernighan et Ritchie.

Sa seule spécificité consistait à hériter le link statique mais Go s'est justement invité dans cette singularité en ajoutant une vraie couche de gestion mémoire. C++ est terriblement hypersensible aux versions de compilateur, versions de dll.... Dés qu'on change un byte du système, il faut recompiler...

[CaptainDangeax]

Trois remarques après ce post très intéressant :
1 - Difficile de perdre ses habitudes.
2 - Sauf si on est maso...
3 - Utiliser le bon langage adapté au projet

Par exemple, dans mon boulot, on bosse sur des microcontrôleurs où la place et la puissance sont "just"
donc C (et parfois asm !!) Pour le reste de nos softs (IHM, workers, etc.) c'est Python.

Je préfère de très loin le C/C++ à Python, mais bon, dans certains cas, faut arrêter de se faire du mal.

Après pour la mort du C, heu... Comment définir "proche" sachant que depuis plus de 40 ans, toute l'infra. soft (ou presque) tire ses racines du C.
C'est un peu comme renier sa mère.

Je ne peux que plussoyer au poste de Stef. Il ne faut pas oublier que quand les fondeurs vendent 1 µP (pour PC ou smartphone), les mêmes fondeurs vendent 10µC ! Le moindre bidule électronique, même le thermostat de mon radiateur à 50€ chez Leroy-lenchanteur embarque un µC. Quel est le processeur qu'Intel a le plus vendu, en volume ? Plus d'un milliard de µC 8048 dans les claviers de PC et autres micros, justement. Et en quoi programme-t-on un µC si on n'a pas trop envie de s'embêter la vie avec de l'ASM ? Bah en C pardi, parce que justement sa gestion de mémoire permet d'écrire dans un registre précis du µC où la place est limitée.
Je bidouille des trucs électroniques avec des µC, je commence un nouveau projet de pilotage de circuit ICSP pour les AT89 parce que je n'ai pas trouvé dans le commerce de truc valable et surtout fonctionnel. En quoi vais-je développer ? En Python/Linux et si je n'ai pas la lib pour adresser directement le port parallèle, je l'écrirai en C.

[commandantFred]

Globalement d'accord avec ça néanmoins :

... même le thermostat de mon radiateur à 50€ chez Leroy-lenchanteur embarque un µC.
Quel est le processeur qu'Intel a le plus vendu, en volume ? Plus d'un milliard de µC 8048 dans les claviers de PC et autres micros, justement. Et en quoi programme-t-on un µC si on n'a pas trop envie de s'embêter la vie avec de l'ASM ? Bah en C pardi, parce que justement sa gestion de mémoire permet d'écrire dans un registre précis du µC où la place est limitée.
Je bidouille des trucs électroniques avec des µC, je commence un nouveau projet de pilotage de circuit ICSP pour les AT89 parce que je n'ai pas trouvé dans le commerce de truc valable et surtout fonctionnel. En quoi vais-je développer ? En Python/Linux et si je n'ai pas la lib pour adresser directement le port parallèle, je l'écrirai en C.

Pour le thermostat qui fait "clic" quand on tourne le potar, il y a beaucoup moins cher et plus fiable q'un µC. Ca s'appelle un bilame (cf. wiki) et ça fait le job même en l'absence de toute alimentation. C'est juste une petite pièce de métal qui fait à la fois interrupteur et sonde de température... M'enfin c'est juste pour l'exemple qui tombe mal. Pour le reste je suis amplement d'accord. Pour les controleurs genre atmel , y'a pas mieux que C.

Par contre, C a quand même une longue histoire qui ne s'arrête pas aux petits systèmes.

J'ai cité le traitement de signal (dont la part est vouée à croître avec les neurones et l'IA en général) , tu cites les micro-contrôleurs et d'autres avant on cité les drivers.
Je suis sûr que cette liste n'est pas complètement exhaustive néanmoins l'ensemble ne pèse pas très lourd dans le vaste monde du software et plaide pour la seconde réponse au sondage. Clairement ,l'avenir du C est majoritairement derrière lui même si sa carrière et son apport sont extraordinaires.

Je me rappelle du vieux temps où des équipes codaient de grosses applis windows en C-SDK, bien avant l'arrivée des fondations de classes. C'était quand même ardu !
Pour rien au monde je ne voudrais me palucher les messages windows dans un mega switch() case comme on le faisait à l'époque.

D'ailleurs ce fameux switch case est complètement caché dans les frameworks modernes (C#, Java). On n'y accède que par l'intermédiaire de delegates (pointeurs sur fonctions) qu'on ajoute ou enlève dans un tableau parcouru par une couche du framework inaccessible par code et c'est beaucoup mieux comme ça.
A l'époque , les éditeurs avaient appelé ça la "programmation événementielle", ça sonnait bien !

[Obsidian]

Pour le thermostat qui fait "clic" quand on tourne le potar, il y a beaucoup moins cher et plus fiable q'un µC. Ca s'appelle un bilame (cf. wiki) et ça fait le job même en l'absence de toute alimentation.

Ce n'est pas tout-à-fait vrai et c'est pour cela que c'est important, car il est bien question ici de seuil critique.

Il y a quelques années, j'avais acheté un jeu de PIC12C508 à… 3€ pièce ! Et pour le prix, j'avais un circuit DIP8 d'un 1 cm de côté avec six lignes d'entrées/sorties, 512 mots de 12 bits pour le programme, une trentaine d'octets de RAM et un oscillateur interne. Même pas besoin de condensateur anti-parasite, même si cela restait recommandé. Il suffisait de le brancher pour qu'il marche. À ce compte, avec zéro composant annexe, même en grande série, il devient difficile de battre ce genre de produit. Et même avec une poignée d'octets de mémoire vive, on peut faire des choses relativement sophistiquées, peut-être même un peu de virgule flottante. Il serait tout-à-fait concevable de coder un thermostat, par exemple.

Évidemment, il faut toujours une alimentation stabilisée, mais disons qu'à partir du moment où on a besoin d'allumer une LED sur le dispositif, ça devient envisageable.

[LordMacharius]

Pour ma part, je pense bien que le C a encore de beaux jours devant lui.
Il sera terriblement difficile à remplacer tant son équilibre entre performance/stabilité/lisibilité du code reste ce qu'il est. Je vois mal un langage moderne venir trouver le même équilibre avant un moment.

Le C n'est pas la réponse à tout mais à pas mal de chose mine de rien. Pour ceux qui râle de la complexité du C et de sa gestion mémoire, je pense surtout que cela vient d'un manque de formation mais surtout de rigueur. C'est bien de cela dont on parle lorsque l'on compare le C à des nouveaux langages. Il demande une telle rigueur de travail que peu de personnes sont capables d'obtenir des résultats satisfaisant dans leur projet.
Je l'ai encore entendu ces derniers jours… ils voulaient faire du python pour du transfert de gros volumes de fichiers (genre 80/100To avec une charge serveur proche de 100%) au titre que le C est trop « relou ».

Au final, la bonne réponse est un peu le mélange de ce qui a été dit. Les décideurs choisissent autre chose que le C lorsque c'est possible. Cela permet de fermer les yeux sur la qualité de ce qui est produit et des compétences des personnes qui travaillent sur le projet (8 ans que je le vois au quotidien )
J'aime le C pour cette rigueur qui devrait être celle de tous les développeurs, commencer par le C m'a permis de produire du code de qualité supérieure à ce que font mes collègues dans un temps similaire.

[commandantFred]

...Pour ceux qui râle de la complexité du C et de sa gestion mémoire, je pense surtout que cela vient d'un manque de formation mais surtout de rigueur. C'est bien de cela dont on parle lorsque l'on compare le C à des nouveaux langages. Il demande une telle rigueur de travail que peu de personnes sont capables d'obtenir des résultats satisfaisant dans leur projet.
...

Comme dit plus haut, le problème du C n'est pas sa complexité mais plutôt son incroyable simplicité ! Il utilise le CPU comme framework et présume que l'espace adressable est contigü dans son tas et sa pile...

La comparaison avec python est hasardeuse puisque on a affaire à l'architecture la plus rapide (link statique, arithmétique sur pointeurs, contigüité mémoire, ...) et la plus lente (langage interprété, variables dynamiques)

Les vrais remplaçants du C sont Java, C#, Objective ... et surtout Go (non exhaustif) parce que ces langages ont été conçus en partant d'une analyse critique du C++. Contrairement à Python qui consacre beaucoup de CPU à simplifier le travail de développement, ces langages répondent aux problèmes de sécurité introduits par C(++) qui sont les mêmes que ceux de Pascal parce que conçus à la même époque où l'internet était encore classé secret défense.

Pour les applications système dont vous parlez, Go est certainement le meilleur compromis entre le link statique (performance), robustesse face aux bugs/intrusions (GC) et sécurité. Il faut dire qu'il a été conçu par le plus gros propriétaire de datacenters au monde pour répondre précisément à la perte de performances qu'induisent les langages comme python, qui lui, n'a pas été conçu pour répondre à un besoin d'exploitation spécifique mais plutôt pour une grande diversité d'usages.

[foetus]

Go est certainement le meilleur compromis

Go c'est de la m$rd$ en boite

Il arrive avec une bibliothèque qui permet de coder un serveur en quelques lignes certes. Mais c'est quand même très restrictif : où sont les structures de données ? les algos de tris ? l'unicode ? par exemple.
Il avait une histoire comme quoi tous les passages de paramètre sont de type "string"
Il avait une histoire avec le "packager" par défaut tout pourri. (si j'ai bien compris le problème, il mettait à jour toutes les bibliothèques en même temps)

Et en Go, il n'y a plus de notion de pointeurs il me semble : c'est bête de faire du C sans les pointeurs. Autant prendre du Java ou C#

[commandantFred]

Go c'est de la m$rd$ en boite

Il arrive avec une bibliothèque qui permet de coder un serveur en quelques lignes certes. Mais c'est quand même très restrictif : où sont les structures de données ? les algos de tris ? l'unicode ? par exemple.
Il avait une histoire comme quoi tous les passages de paramètre sont de type "string"
Il avait une histoire avec le "packager" par défaut tout pourri. (si j'ai bien compris le problème, il mettait à jour toutes les bibliothèques en même temps)

Et en Go, il n'y a plus de notion de pointeurs il me semble : c'est bête de faire du C sans les pointeurs. Autant prendre du Java ou C#

Ok, bien que je ne pratique pas Go, votre post m'a interpellé. Une fois googlé , j'ai trouvé tout ce dont vous parlez : Les paramètres acceptent tous les types, j'ai vu une dizaine de tris, notamment de collections (listes chaînées), unicode etc...

Quant aux pointeurs, ce sont évidemment des références çàd qu'on est obligé de déclarer sur quelle cible ils pointent (puisqu'ils sont mis à jour lors de la garbage collection) et il est interdit de faire de l'arithmétique dessus. Autoriser l'arithmétique sur pointeur revient à poser les mêmes problèmes de sécurité que le C (le pentagone a communiqué là dessus).

Bon, je dois dire que j'adore les pointeurs C aussi mais je dois faire auditer la sécurité dans mes missions.
Je n'ai pas pu confirmer ni infirmer votre histoire de packagers mais par défaut, je suis plutôt confiant là dessus même si je n'ai pas la démonstration formelle.

Je crois que Go est bien. Hélas, j'ai besoin d'IHM plus réactives que html5/svg/canvas. Je reste en C# pour l'instant mais je crois que Go est nettement plus rapide (et meilleur ratio volume traité par kilowatt heure)

Liste des packages https://golang.org/pkg/

https://golang.org/search?q=Sort

[foetus]

Il y a cette vidéo Pourquoi Maurice ne doit surtout pas coder en GO (Jean-Laurent de Morlhon) (<- youtube, en 2016, postée sur ce forum "je ne sais plus où") (<- le gars semble n'avoir jamais codé en C parce qu'il y a pleins de remarques typiques C : tests manuels, pleins de répétitions, programmation défensive avec des if else, ...)


Édit : l'indentation qui semble être imposée

[Kannagi]

Les vrais remplaçants du C sont Java, C#, Objective ... et surtout Go (non exhaustif)

Je crois que tu n'as pas compris en quoi en utilise le C de nos jours
Ces langages ne peuvent remplacer le C parce que justement il ne permettent pas d'utiliser de pointeur et donc d’être bas niveau.

Si j'écris ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
int *pointeur = 42;
*pointeur = 1;

Il est impossible de dire que j'écris sur la mémoire RAM (sauf si on c'est sur de quel machine cela est destiné) , ce code signifie que je pourrait écrire en RAM mais aussi dans la mémoire vidéo , dans la sortie sonore , un DMA ,etc etc.
De plus l'arithmétique sur pointeur est très pratique si on fait du bas niveau.
C'est pour cela aussi que le C est aussi bas niveau entre autre que le langage C représente le fonctionnement d'un CPU (les fonctions , les calcul arithmétique et logique sont des choses que le CPU fait nativement) , c'est aussi pour cela que l'assembleur n'est plus utilisé depuis un certain moment.
Sauf si volonté d'utiliser une instruction particulière qui n'est pas utilisé par le compilateur l'asm n'apporte plus grand chose.

Conclusion beaucoup pense que le langage qui est le successeur du C c'est le C++.
Je rajouterai un note assez personnelle , je trouve que dans le bas niveau le C remplit absolument bien son rôle , d'ailleurs pour cela que pour ma part je ne regarde pas vraiment les nouvelles normes , je dois codé encore en C99 pour dire !

[CaptainDangeax]

Pour le thermostat qui fait "clic" quand on tourne le potar, il y a beaucoup moins cher et plus fiable q'un µC. Ca s'appelle un bilame (cf. wiki) et ça fait le job même en l'absence de toute alimentation. C'est juste une petite pièce de métal qui fait à la fois interrupteur et sonde de température... M'enfin c'est juste pour l'exemple qui tombe mal. Pour le reste je suis amplement d'accord. Pour les controleurs genre atmel , y'a pas mieux que C.

Désolé commandantfred mais tu te plantes. La bilame, c'était sur les convecteurs d'il y a 30 ans avec une température qui variait en 15 et 25 degrés dans une heure. Regarde ton chauffage électrique aujourd'hui : plus de clic parce qu'il y a un TRIAC et la petite led clignote, la régulation de température se fait par le rapport cyclique. Et comment fait-on pour avoir une régulation de température avec le rapport cyclique ? On utilise un microcontrôlleur. Le moindre Microchip PIC (tm) à quelques pouièmes de centime en volumes embarque un timer/counter qui peut être utilisé en PWM, plusieurs ADC et même un comparateur. Ajoute une bête CTP à ton circuit et ton programme est tout simple : Si température < consigne augmente rapport cyclique sinon diminue rapport cyclique. Avec le bon taux d'amortissement sous la forme d'une moyenne des températures sur un temps donné, même pas besoin de quartz le circuit rc interne à 32,768 kHz suffit amplement.
Quant à la question du coût, le procédé industriel pour faire coller ensemble 2 métaux sans utilisation de métal d'apport pour la fabrication de ta bilame n'a rien de trivial, et n'oublie pas les contacts anti-corrosion à mettre au bout. Quant à la compatibilité d'un contact ouvert à l'air libre qui commute du 220 V AC avec une atmosphère potentiellement explosive, je préfère ne pas m'étendre sur le sujet. Donc ta bilame, elle est au musée.

[VivienD]

je crois que tu n'as pas compris en quoi en utilise le C de nos jours
Ces langages ne peuvent remplacer le C parce que justement il ne permettent pas d'utiliser de pointeur et donc d’être bas niveau.

Si j'écris ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
int *pointeur = 42;
pointeur = 1;

Il est impossible de dire que j'écris sur la mémoire RAM (sauf si on c'est sur de quel machine cela est destiné) , ce code signifie que je pourrait écrire en RAM mais aussi dans la mémoire vidéo , dans la sortie sonore , un DMA ,etc etc.
De plus l'arithmétique sur pointeur est très pratique si on fait du bas niveau.
[...]

J'aurais plutôt défini des macros pour éviter d'utiliser des "nombres magiques".

[...] d'ailleurs pour cela que pour ma part je ne regarde pas vraiment les nouvelles normes , je dois codé encore en C99 pour dire !

Je me sens moins seul, d'un coup, mais j'ai encore du mal à recourir directement aux booléens...

[Kannagi]

@VivienD
Absolument d'accord mais ce code n'est qu'un exemple , si j'utilise un define dans cet exemple on peut deviner a quoi cela sert
Pour les booléen tu n'est pas le seul aussi

[commandantFred]

Ok, à vous lire , on vous croirait fâchés... Précisons quand même que cette discussion n'aura pas de répercussion sur l'incroyable carrière du C et que j'ai beaucoup programmé en C, y compris de grandes applications complètes (avec IHM). Comme je l'ai dit plus haut, je l'utilise maintenant pour faire du traitement de signal (environ 70 000 lignes de C pur)

Concernant le bilame, aucun µC ne rend le service pour un prix aussi bas. Je rappelle qu'un µcontrôleur doit être alimenté en tension continue et que cette alim est un composant cher et fragile. Il faut aussi ajouter une sonde de température et un relais pour allumer et éteindre l'appareil, lequel fonctionne avec une bobine sujette à échauffement.

Le µC se justifie dans le cas d'une chaudière moderne parce qu'on va utiliser la logique très finement et surtout parce qu'on peut reprogrammer le seuil sans intervention humaine de façon très subtile. Mais pour une plaque de cuisson, un radiateur ou un thermostat d'ambiance manipulés avec un bouton manuel, le bilame est impossible à remplacer (tous mes appareils chauffants en possèdent un, y compris le thermostat d'ambiance de ma chaudière haut de gamme). Facile à vérifier : S'il n'y a pas d'alim, c'est un bilame.

Cela n'enlève rien aux capacités géniales des µC ni n'affectera le futur mirobolant des objets connectés bien que la suite pourrait être moins simple :

Concernant le C, je me suis agacé qu'on le cantonne au système ou aux drivers puisque je fais du traitement de signal avec et que ça apporte une lecture précise du monde analogique à mon software. Cette dimension n'est apparemment pas tolérée par Google puisque Tensorflow n'est publié que dans sa version python ce qui est quand même limitant, surtout quand on sait à quel point les neurones font hurler les ventirads et tournent mieux en CUDA ou OpenCL ....

Après on peut disserter sur midi à sa porte mais il faut aussi admettre que si les grands éditeurs ne publient rien en C, le langage ne pourra pas dominer l'industrie software et que ce problème nous dépasse un peu... (ou en tous cas moi car je suis absolument sûr de ne jamais devenir grand Ceo d'un éditeur international)

Enfin , je suis soumis à des audits de sécurité , certes pas trop pénibles mais quand même... Or il se trouve que dans ce domaine - que certains négligent complètement - Le C et le C++ n'ont pas bonne presse. Je l'ai dit plus haut, le problème provient de la structure du compilateur qui n'intercale rien entre le kernel et le hardware ce qui fait toute sa puissance mais aussi sa vulnérabilité.
Je vous avoue que j'ai eu du mal avec ça aussi. Mon vieux C dont j'ai défendu les aspects les plus radicaux auprès de grandes boites - pex : la capacité à mettre à zero un nombre indéfini de structures mémoire avec un seul memset()...
Ben , il n'a plus la cote chez les pros et ça me chagrine grave !!!

Pour info, une des attaques mondiales récentes a utilisé précisément les objets connectés en IP pour saturer les plus grands serveurs mondiaux, y compris ceux des aéroports, centrales nucléaires, banques.... Bref, les µC sont devenus un enjeu de sécurité militaire pour les pays développés et il faut s'attendre à ce que les organismes de certification deviennent de plus en plus stricts sur la sécurité des très petits systèmes.

Bon, j'arrête là. Je ne cherche pas à imposer un point de vue, je témoigne de ce qui se passe par chez moi...

[SurferIX]

Nous avons remplacé le C++ par du Python pour un résultat plus rapide!!! En fait C++ n'est pas plus rapide dès lors qu'il y des erreurs de conception (utilisation de listes au lieu de dictionnaires).
Résultat tous les collègues dont certains en sont enchantés.
D'autres collègues continuent de s'acharner en C++, alors qu'une interface SWIG permet d'écrire la majorité de l'application en quelques lignes de Python tout en utilisant des APIs C/C+. Il reste vrai que lorsqu'il apparaît des goulots d'étranglement, cette partie est vite porté en C++ et le tour est joué.

Vive Python ! C'est ce que je dis depuis 2 ans !

Il faut toujours adapter la solution au problème et éviter de réinventer la roue. Être un peu (voir beaucoup) fainéant aide parfois. Réfléchir plutôt que coder.

Exactement ! Par contre si c'est plus rapide en Python, c'est que tes développeurs C++ sont vraiment, vraiment des branquignols, parce que par essence même, le C++ est forcément plus rapide que Python... et le seul gros handicap de Python, justement, c'est sa lenteur... même si les PCs aujourd'hui sont tellement puissants que ce n'est plus trop un problème.

Je me pose par contre beaucoup de questions pourquoi nodejs qui était écrit en C a migré en C++. Peut être quelques fanatiques de "variadic template" https://en.wikipedia.org/wiki/Variadic_template ou comment rendre un programme compact et complètement illisible.

Dans tous les cas NodeJS fait développer en JavaScript. Par l'essence même qu'est le langage JavaScript, sa syntaxe, et les callbacks imposés (pour NodeJS), on ne peut pas faire de "gros" programmes maintenables (d'où l'essor de ce qu'on appelle les microservices, qui sont nés pour pallier à ce handicap, bref...).

Bref pour en revenir au sujet, je pense que le Go, en tant que langage bas niveau, c'est l'avenir. Ce langage me plaît énormément et de par sa conception, permet d'avoir une rapidité de programme impressionnante.
Si j'avais deux outils à conseiller à apprendre aujourd'hui ce serait pour du haut niveau, Python, et pour du bas niveau, Go.

[gangsoleil]

Pour info, une des attaques mondiales récentes a utilisé précisément les objets connectés en IP

Oui, et le soucis ne vient absolument pas du langage utilisé, mais bien de la conception qui est (complètement) foireuse dans la plupart des cas : pas de cryptographie correcte, voir pas du tout, pas de mise à jour possible, mots de passe en dur... Tu peux être en Scheme, en C ou en Go, tu auras les mêmes problèmes et les mêmes attaques.


Professionnellement, j'utilise le C sur de gros programmes qui ont des besoins de performance. Un gain de 1ms sur un traitement, ça peut paraître négligeable, mais sur un traitement que tu fais 1,6 millions de fois par jour, c'est un gain de plus de 4h de calcul...

Oui, on pourrait ré-écrire les centaines de milliers de lignes de code dans un autre langage, mettons aussi performant. Mais qui va payer la ré-écriture ?

[commandantFred]

Oui, et le soucis ne vient absolument pas du langage utilisé, mais bien de la conception qui est (complètement) foireuse dans la plupart des cas : pas de cryptographie correcte, voir pas du tout, pas de mise à jour possible, mots de passe en dur... Tu peux être en Scheme, en C ou en Go, tu auras les mêmes problèmes et les mêmes attaques.


Professionnellement, j'utilise le C sur de gros programmes qui ont des besoins de performance. Un gain de 1ms sur un traitement, ça peut paraître négligeable, mais sur un traitement que tu fais 1,6 millions de fois par jour, c'est un gain de plus de 4h de calcul...

En traitement de signal, le C me permet de diviser la latence par deux. Ce gain me permet de gérer des situations impensables autrement. Les contraintes de sécurité ne sont pas affreuses : pas de char* ni de tableaux[] en variables locales, tronquage des paramètres en entrée et quelques trouvailles personnelles (...)

Pour les petits objets IP, je crains que les certificateurs ne fassent pas la distinction entre mauvais usage et défaut structurel d'un langage. D'un autre coté, maintenant qu'on a établi que des millions de petites stacks IP peuvent mettre un continent à terre, même si on crypte correctement et qu'on utilise des mots de passe hashés à grain de sel et random seed , il restera encore les défauts structurels du langage pour les attaques futures...

La bonne nouvelle, c'est qu'on peut modifier le code pour le rendre plus résistant. Mais au moment du design de projet, on sera tenté (ou forcé par l'assureur) de n'exposer que des programmes écrits en langage costaud, et de garder le C pour quelques tâches spécifiques...
L'autre bémol, c'est qu'une fois le code C durci à l'extrème, ça ne ressemble plus vraiment à du C optimisé. Or c'est l'optimisation qui est intéressante dans ce langage.

Oui, on pourrait ré-écrire les centaines de milliers de lignes de code dans un autre langage, mettons aussi performant. Mais qui va payer la ré-écriture ?

L'assurance responsabilité civile ?

Ou plus exactement, l'assurance fera auditer le logiciel et calculera sa prime en fonction de la vulnérabilité? Dans ce cas, vus que les auditeurs ne vont pas analyser vraiment le code, il y a de fortes chances pour que le seul usage du C fasse exploser la prime.
C'est pourquoi je parlais plus haut des publications du pentagone .. C'est plus facile à lire que 100 000 lignes de C ! Je ne pense pas qu'ils feront dans le détail.

C'est aussi pourquoi il est important d'avoir de bonnes certifications.

[Kannagi]

Après on peut disserter sur midi à sa porte mais il faut aussi admettre que si les grands éditeurs ne publient rien en C, le langage ne pourra pas dominer l'industrie software et que ce problème nous dépasse un peu... (ou en tous cas moi car je suis absolument sûr de ne jamais devenir grand Ceo d'un éditeur international)
[... )
Ben , il n'a plus la cote chez les pros et ça me chagrine grave !!!

Je comprend mieux ton point de vue et tes arguments , mais la plupart ici savent deja que le C ne dominera plus jamais en software et qu'il sera cantonné que dans quelque domaine ou il n'a pas vraiment de concurrence.
Pour ma part cela fait belle lurette que le C a était abandonné dans plein de domaine , dans le jeux vidéo c'est un langage qui était utilisé il y'a presque 20 ans !

Oui, on pourrait ré-écrire les centaines de milliers de lignes de code dans un autre langage, mettons aussi performant. Mais qui va payer la ré-écriture ?

Je rajouterai un autre argument , et pourquoi ?
Le C c'est un langage correct quand les programmeurs derrière le sont et puis former des programmeurs sur d'autre langage c'est long sans parlé le temps qu'il devienne bon dans celui ci (traduit par : il faudrait qu'il apprenne a pas faire de bêtise sur le nouveau langage).
Sans parler (moi y compris) de ne pas vouloir changer de langage dans les domaines ou je l'utilise parce que le C me convient parfaitement , d'ailleurs par exemple même Linus Torvalds ne voulait pas changer de langage (pour mettre le code source Linux en C++ ) , je le vois mal changer pour du Go

Un autre point le C est a ma connaissance aussi le seul langage quasi-universel , dans le sens ou il y'a un compilateur C pour n'importe quel processeur (c'est pas le cas pour Rust ou Go par exemple).