Navigation

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

  1. #21
    Expert éminent sénior
    Citation Envoyé par 23JFK Voir le message
    Je n'ai fait que lire l'article : insert ASM , union/structure.
    Ok, tu parles des fonctionnalités expérimentales qui ne sont pas encore disponible dans la version stable du compilateur. C'est vrai qu'il y en a un certain nombre.
    Mais le langage en lui même est stable : le code compilé avec une version stable du compilateur et garanti de continuer à compiler avec les version à venir du compilateur.

    Ça n'a rien de différent du C : lui aussi a ajouté des nouveautés au langage au fur a mesure de son évolution. D'ailleurs sur le problème de l'assembleur inline, le C est même pire que Rust : cette fonctionnalité ne fait pas partie du standard C et chaque compilateur C a sa propre syntaxe.

  2. #22
    Membre éclairé
    Je vais esquiver la discutions JS vs C c'est dangereux

    Pour le rust vs C, ma position et d'attendre de voir.

    Passer sur un nouveau langage c'est une nouvelle syntaxe/grammaire mais aussi de nouveaux paradigmes et souvent une nouvelle API , même élémentaire.
    Je passe sur les lib que l'on a l'habitude d'utiliser et le code historique mais ca représente évidemment un problème.
    En tant qu'utilisateur je serais plus convaincu par une évolution du C qui permette une gestion de la mémoire plus simple et plus sur.
    Mais j'imagine que ca ne doit pas être facile, ca restera sans doute un doux rêve dans ma tête.

    Concrètement un peut de rust dans le futur, c'est plausible. C le nouvel assembleur oui et non, que va devenir l'asm dans ce cas ?
    Vous ne voudriez pas condamner un langage d'une telle simplicité sur l'hotel de l'abstraction tout de même !

  3. #23
    Membre éprouvé
    À mon avis, ce qui rend Rust moderne par rapport au C, ce n'est pas seulement sa gestion de la mémoire, mais surtout le fait qu'il ait été pensé dès le départ pour le multi-threading.

    Citation Envoyé par 23JFK
    Je n'ai fait que lire l'article : insert ASM , union/structure.
    D'accord avec Uther là-dessus: c'est comme dire que la syntaxe du C++ est instable parce que toutes les modifications du C++20 n'ont pas encore été décidées

    Citation Envoyé par Aiekick
    c'est vrai que la gestion mémoire est la 1ere source de bug critique en c et c++. mais j'aimerais bien passer a rust, pourquoi pas. mais 99.9% des lib utiles sont en c ou c++
    Rust permet nativement d'appeler des fonctions C : https://doc.rust-lang.org/book/ch19-...-external-code
    Rust prétend rivaliser avec le C mais n'est pas assez prétentieux pour essayer de s'en passer complètement.

  4. #24
    Membre régulier
    Avant, on devait tout faire avec C/C++. Choix facile, mais développements difficiles.
    Maintenant on a 10 ou 30 choix de langages, C/C++ toujours, Rust, Go, Java, Scala, Clojure, Erlang/Elixir pour les rapides, JS python PHP etc pour les apps. Choix difficile, développement facile.
    Je préfère maintenant. Développer excel ou un webmail en C++, non merci.

    Pire, on est au cloud donc parallélisation : adieu C/C++, merci les Golang et les FP ! Pas pour rien que Google, roi du cloud, avait besoin d'un golang. Et whatsapp d'un erlang.

    Bref , ça n'a rien d'une mode mais d'un besoin réel, une réponse à un vrai blocage. On n'a pas remplacé le cheval par un seul moyen de locomotion non plus... "un peu de tout, beaucoup de rien".

    Par contre, Julia, avec ses bindings a tant d'autres langages, est séduisant... V1 aujourd'hui, on verra dans 10 ans ou il sera. Bravo aux concepteur !
    A quand ces vrais langages propres sur ASM...

  5. #25
    Expert confirmé
    Citation Envoyé par Neckara Voir le message
    Il s'est quand même bien étendu depuis sa création, de côté client, il a gagné côté serveur, et peut même être utilisé pour des applications desktop.
    La programmation web et la programmation d'appli desktop, ce n'est pas de la programmation système.
    Si tu regardes les 20 premières secondes de la vidéo de l'article, il y a des exemples de prog système : bios, firmware, bootloaders, OS, etc
    Perso je connais pas beaucoup de bios codé en JS...

  6. #26
    Expert éminent sénior
    Citation Envoyé par SimonDecoline Voir le message
    La programmation web et la programmation d'appli desktop, ce n'est pas de la programmation système.
    Certes, mais combien auraient pensé il y a quelques années qu'on puisse exécuté du JS côté serveur ?
    Combien auraient pensé utiliser du JS dans de l'embarqué ? ou de l'IoT ?

    Pour le moment, JS suit le chemin : navigateur -> serveur -> IoT -> Embarqué. Combien de temps avant qu'il ne s'attaque aussi à la programmation système ?


    J'en suis le premier attristé, mais le constat est là.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  7. #27
    Expert confirmé
    Citation Envoyé par Neckara Voir le message
    Certes, mais combien auraient pensé il y a quelques années qu'on puisse exécuté du JS côté serveur ?
    Combien auraient pensé utiliser du JS dans de l'embarqué ? ou de l'IoT ?

    Pour le moment, JS suit le chemin : navigateur -> serveur -> IoT -> Embarqué. Combien de temps avant qu'il ne s'attaque aussi à la programmation système ?
    Formidable, il existe deux bibliothèques JS pour l'IOT et l'embarqué... Quel raz-de-marée... Et qui les utilisent vraiment ? Avec quel succès ?

    Autant dire que Rust est en train de supplanter JS parce qu'on peut charger des modules rust dans nodejs ou du webassembly dans une page web.

  8. #28
    Expert éminent sénior
    Citation Envoyé par SimonDecoline Voir le message
    Formidable, il existe deux bibliothèques JS pour l'IOT et l'embarqué... Quel raz-de-marée... Et qui les utilisent vraiment ? Avec quel succès ?
    C'est bien facile d'ironiser.

    Voici ce que je trouve après une rapide recherche Google:
    1. Java
    2. C
    3. JavaScript
    4. Python

    http://www.reseaux-telecoms.net/actu...iot-27697.html

    Capteurs et objet connectés dits contraints >
    1. C
    2. C++
    3. Java
    4. JavaScript

    Passerelles de l’IoT >
    1. Java
    2. Python
    3. C++
    4. C

    Cloud IoT >
    1. Java
    2. JavaScript
    3. Python
    4. PHP

    Il ne faut pas être un génie pour comprendre que si on utilise de plus en plus JS côté serveur, on a de forte chance de le retrouver dans l'IoT, ou nombre d'interfaces de gestion sont des serveurs Web.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  9. #29
    Membre expert
    Je vois beaucoup d'articles qui vont dans le même sens pour Rust, en tout cas c'est un langage qui me tente à l'avenir je fais pas de système ou du C mais ça serait un bon moyen de mettre le pied dedans et en même temps un pari sur l'avenir
    Mon Covid Tracker alias Coronavirus : https://covid.ovh/
    Application 1km qui permet de calculer la distance d'1km autour de son domicile :
    Apps Android
    Apps IOs

  10. #30
    Expert éminent sénior
    Citation Envoyé par Neckara Voir le message
    Certes, mais combien auraient pensé il y a quelques années qu'on puisse exécuté du JS côté serveur ?
    Combien auraient pensé utiliser du JS dans de l'embarqué ? ou de l'IoT ?
    JavaScript est utilisé par le biais de Node sur toutes ces plateformes parce qu'il y a un besoin massif d'utilisation du réseau pour les applications quelle que soit la plateforme. C'est ça le grand changement de ces dernières années et c'est pour ça quand JavaScript (par le biais de node) grignote partout.

    Pour ce qui est de la prog système je vois pas comment JS pourrait s'y insérer les performances sont plusieurs ordres de grandeur en dessous des langages appropriés. L'usage de node c'est le réseau pas le calcul.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  11. #31
    Nouveau membre du Club
    J'ai du mal à comprendre certains développeurs.

    Vous avez de " l'expérience " en programmation et en management de projet logiciel; allez donc tester le langage et faites-vous votre propre opinion.

    Evidemment, le C conserve sa place car il est compliqué voir impossible de migrer vers du pur RUST immédiatement(go and see "are we yet"). Sans oublier que:
    - l'intégration de l'assembleur au RUST est encore instable.
    - l'utilisation de code unsafe nécessite une gymnastique dont certains développeurs d'OS se passeraient bien.

    En outre, j'ai testé RUST et GO; ma conclusion:

    Il n'y a pas photo. RUST est LE langage de programmation système MODERNE. Ce n'est pas juste un langage de programmation, c'est un d'environnement qui offre une ergonomie, ou devrais-je dire, une "expérience utilisateur(développeur)" qui respecte les critères " qu'on adore en 2019" chez les devs. Je parle évidement:
    - d'une installation et une gestion des versions bien faite.
    - du support(librairies) des tests intégré au coeur du langage.
    - un compilateur vachement stylé; avec des messages clairs.
    - de son package manager qui va fera bientôt rougir npm.
    - d'une communauté extrêmement active. Allez check le thread reddit du langage.
    - bref la productivité est ou sera certainement au rendez-vous... que du bonheur.

    Personnellement, lorsque je veux critiquer "sauvagement" le JAVA et son environnement (dont j'ai conscience de l'évolution permanente, mais reste insatisfait), je prend l'exemple de RUST.

  12. #32
    Membre expérimenté

    Je ne comprends pas comment une conversation parlant de Rust et C fini sur JS ou Go...
    'C' et 'Rust' sont des languages de programmation Système, JS et Go non.
    'C++' dans la moindre mesure je le considère également comme un langage de programmation système.

    Ce que sont 'C' et 'C++'

    'C' est un vieux language qui a fait ces preuves et qui à également montré qu'il avait de grosses faiblesses qui coute et ont couté plusieurs millions de dollars aux sociétés. ( Use after free, buffer overflow, null pointer, etc... )
    'C' à une ABI stable.
    'C++' a ajouté 1 élément majeur par rapport au 'C' qui est le destructeur et qui a permit de limiter la casse en libération mémoire, mécanisme 'automatisé' de gestion de mémoire.
    'C++' a également apporté l'Orienté Objet (POO) qui aujourd'hui montre également ces faibles après avoir montré sa force.
    'C' et 'C++' n'ont pas été pensé pour les problèmes d'aujourd'hui ( Processeurs multicoeurs, Sécurité, Ecosystème du développeur )
    'C' et 'C++' ont aux moins 3 compilateurs différents!!! ( GCC, Clang, MSVC)

    Ce qu'est 'Rust'

    'Rust' prend le meilleur et fait une bonne cuisine de tout ça. (D'ou son nom qui veux dire 'Rouille' car l'ensemble des concepts qu'il met en oeuvre sont des concepts qui ont fait leurs preuves)
    - Il autorise l'utilisation de raw pointer, d'allocation dynamique, d'alignement mémoire custom, de 'destructeur' via le trait 'Drop'.
    - Son système de Ownership et Borrowing est très bien pensé. Difficile à prendre en main mais d'une puissance indiscutable.
    - Il est orienté Data Oriented Design afin de répondre au problème d'aujourd'hui (Multiplication du nom de coeur par exemple) qui demande du code cache friendly (Data et Instruction).
    - Il est également orienté Test Driven ( Les tests unitaires et globaux sont parties complètes du language et du compilateur! )
    - Il n'autorise pas des pointeurs null dans le 'Rust' ( Dans le 'Rust' unsafe oui ) car le pointeur null est tout simplement une erreur de conception que l'on traine depuis plusieurs décenies Null References: The Billion Dollar Mistake
    - Il détecte à la compilation les dépassements mémoires, les use after free, les races conditions...
    - Il est basé sur LLVM ce qui lui permet de cibler ce que cible LLVM et également d'utiliser les outils de LLVM et de profiter des optimisations que celui-ci procurent.
    - Il n'a pas de garbage collector.
    - Il dispose d'un gestionnaire de paquage qui nous rappelle de l'éco-système du 'C' et 'C++' est une catastrophe.
    - Il n'y a que 1 seul compilateur rustc!

    J'ai lu beaucoup de bétise ici.
    'Rust' est stable! Son 'ABI' ne l'ai pas mais pour info C++ non plus.
    'Rust' se bind avec 'C' nativement car les OS actuels sont en 'C', ne pas le faire reviendrait à une mort prématuré du language et dire que se n'est pas prétentieux car il bind 'C' montre une incompréhension totale de la réalité.
    Est-ce que tous les languages qui se bind avec 'C' sont je cite "pas assez prétentieux pour essayer de s'en passer complètement"? WTF?
    Pour 'JS' NPM utilise 'Rust' et pas 'JS'... donc...

    'Rust' est actuellement utilisé par et pour

    - Mozilla : Moteur de rendu CSS, Firefox et autres....
    - Amazon : Outils de builds
    - Google : Projet "Fuchsia" de Google
    - NPM : "Replacing C and rewriting performance-critical bottlenecks in the registry service architecture."
    - Atlassian : "We use Rust in a service for analyzing petabytes of source code."
    - Dropbox : https://www.wired.com/2016/03/epic-s...-cloud-empire/
    - Microsoft : Azure IoT Edge
    - RedHat : Système de sockage de fichier Stratis
    - Reddit : Processus de commentaire
    - Twitter, Electronic Arts, Unity, OVH, etc...

    Liste complète ici
    Homer J. Simpson


  13. #33
    Expert éminent sénior
    Citation Envoyé par Marco46 Voir le message
    JavaScript est utilisé par le biais de Node sur toutes ces plateformes parce qu'il y a un besoin massif d'utilisation du réseau pour les applications quelle que soit la plateforme. C'est ça le grand changement de ces dernières années et c'est pour ça quand JavaScript (par le biais de node) grignote partout.
    Pas que, c'est aussi l'aspect langage unique qui a permis à JS de gagner du terrain.

    D'avoir le même langage côté client et côté serveur, nécessitant moins de compétence (pas besoin d'apprendre PHP), et aussi de réutiliser du code.

    Citation Envoyé par Marco46 Voir le message
    Pour ce qui est de la prog système je vois pas comment JS pourrait s'y insérer les performances sont plusieurs ordres de grandeur en dessous des langages appropriés. L'usage de node c'est le réseau pas le calcul.
    Quand ton IoT utilise node pour son interface serveur, tu as de fortes chances de vouloir utiliser le même langage pour le reste de ton IoT, d'où le fait de retrouver un peu de JS en embarqué.

    Même s'il est vrai que C, C++, ou l'assembleur fournissent de meilleures performances, il n'est pas dit qu'un jour on retrouve du JS compilé en byte-code, à la manière du Java et d'avoir des "JavaScript processor".
    Faut croire que je suis trop en avance sur mon temps.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  14. #34
    Membre éprouvé
    Je ne suis pas d'accord avec les derniers commentaires: pour moi, cargo est la plus grosse faiblesse de Rust.
    Pour un langage avec une bonne approche de la build, j'attends Jai (ie: le process de build fait partie du code).

  15. #35
    Expert éminent sénior
    Citation Envoyé par Neckara Voir le message
    Heu... tu as déjà fait des manipulations de bits en JS ? .
    Justement "dans son domaine" (sous-entendu le web je suppose) on ne fait pas énormément de manipulation de bit.

    Citation Envoyé par Neckara Voir le message
    Au niveau des bêtises du JS, tu peux en trouver des pages et des pages.
    Je suis entièrement d'accord que le Javascript est un langage bancal, mais pour un défenseur du C avec ses presque 200 "undefined behavior", c'est un peu l’hôpital qui se moque de la charité.

    Citation Envoyé par Neckara Voir le message
    Tout du moins, c'est l'impression que j'ai ici en suivant les actualités.
    Il y a une grosse différence entre les annonce sur les sites d'actualité qui cherche forcément un peu le sensationnel et ce qui se passe dans les équipes de dev. On ne choisit pas un langage uniquement parce qu'on a vu un joli article mais parce que l'on a pesé les impact positif comme négatif que son utilisation.

    Citation Envoyé par Neckara Voir le message
    Le problème, c'est que tu vas faire un choix à un instant T, mais ce choix, il faudra l'assumer sur une durée qui peut s'étendre à plusieurs années. C'est à dire que l'avenir du langage est très important dans le choix qu'on va faire.
    Clairement, la complexité de maintenance et la durée de vie des technologies, fait partie des élément à prendre en compte dans le choix d'un langage, mais leur importance peut varier en fonction des projets.

    Je ne me jetterais pas, pour le moment sur le Zig ou le C2 dont l'avenir parait très incertain, sauf pour des projets type R&D dont je sais qu'ils auront une courte durée de vie et très peu d'intervenants.
    Par contre quand on voit l’investissement actuel dans le Rust ou le Go, je pense que ces langages peuvent raisonnablement être considérés viables.

    Citation Envoyé par forthx Voir le message

    En tant qu'utilisateur je serais plus convaincu par une évolution du C qui permette une gestion de la mémoire plus simple et plus sur.
    Mais j'imagine que ca ne doit pas être facile, ca restera sans doute un doux rêve dans ma tête.
    Beaucoup ont essayé, mais au final se sont rendu compte que c'est impossible de corriger les principaux défauts du C sans en faire un langage fondamentalement incompatible donc de fait un nouveau langage.
    Même le C++ core guideline qui devaient établir un sous-ensemble et des pratique d'usage sures du C++ ont revus leur ambition à la baisse et ne prétendent plus garantir la sécurité mémoire.

  16. #36
    Membre expérimenté
    Citation Envoyé par Guntha Voir le message
    Je ne suis pas d'accord avec les derniers commentaires: pour moi, cargo est la plus grosse faiblesse de Rust.
    Pour un langage avec une bonne approche de la build, j'attends Jai (ie: le process de build fait partie du code).
    Jai? Google ne trouve rien.
    En quoi Cargo est une faiblesse? Peux-tu argumenter un peu plus avec ton expérience? c'est toujours interessant.
    Cargo n'est pas un compilateur, le compilateur est rustc.
    Je vois les autres outils qui "concurrence" Cargo comme des bêtes mortes.
    De mon expérience les outils de builds C et C++ sont tellements nombreux que cela en devient ridicule.
    En C++ il y a tellement d'outils qui sont nés en urlant qu'il était le futur que au final aucun n'est parfait...
    Rust à l'avantage de fournir un outil unique, qui évoluera avec le language.
    Pour rappelle c'est un language jeune et dire que Cargo est une faiblesse c'est l'équivalent de tuer le bébé parce que il ne sait pas marcher parfaitement en sortant du ventre de sa mère...
    Homer J. Simpson


  17. #37
    Expert éminent sénior
    Citation Envoyé par Astraya Voir le message

    - Il détecte à la compilation les dépassements mémoires, les use after free, les races conditions...
    [...]
    - Il n'y a que 1 seul compilateur rustc!
    Ta présentation de Rust est très bonne, je me permet juste de rectifier ces deux points :

    - Les dépassement mémoire sont contrôles à l'exécution (sauf si le compilateur peut détecter que le contrôle n'est pas necessaire), c'est malheureusement techniquement impossible de faire ça à la compilation.
    Par contre, en effet, tous les autres type d'erreur mémoire sont rendus impossible dès la compilation.

    - En fait il y a bien au moins un compilateur Rust alternatif : mrustc. Il n'a pas le même niveau de finition que rustc (il est pour le moment limité à la version 1.19 et n'a pas de borrow checker). Il possède néanmoins l'avantage de générer du C, ce qui peut être utile pour les plateformes qui n'ont pas de compilateur Rust.

  18. #38
    Membre éclairé
    Citation Envoyé par Astraya Voir le message

    En C++ il y a tellement d'outils qui sont nés en urlant qu'il était le futur que au final aucun n'est parfait...
    Rust à l'avantage de fournir un outil unique, qui évoluera avec le language.
    Pour rappelle c'est un language jeune
    Ca semble un peu contradictoire. Je veux dire, je ne serais pas étonné que dans 2/3 ans certains trouvent cargo pas assez bon ci ou là, créer une alternative et qu'elles deviennent apprécier de la communauté. Et rebelote 2 ans plus tard. Tu le dis toi même Rust est encore jeune ^^.
    Par contre je plussoie totalement le fait que Cargo est l'un des plus gros points positifs de Rust. Sinon autre chose de sympa, comme tu as dis plus haut également, c'est la communauté, ultra active.
    Et pour finir, j'voudrais ajouter un dernier truc qui est excellent : le Rust Book. Ca m'étonne qu'on en ai pas parler, mais c'est l'un des cours les mieux fait que j'ai eu l'occasion de lire. C'est aussi un gros point positif pour les débutants dans le langage.

    EDIT : Uther, juste au dessus de moi, cite mrust que je ne connaissais pas. Ca ne fait que valider mon point, concernant le fait que la communauté va evidemment sortir des alternatives, pour le bon comme pour le mauvais
    "C'est d'un ennui…"

    Shikamaru Nara

  19. #39
    Expert éminent sénior
    Citation Envoyé par Astraya Voir le message
    Jai? Google ne trouve rien.
    Jai est un langage de programmation créé par Jonathan Blow (auteur des jeux-videos Braid et The Witness), qui estimait que la plupart des nouveaux langages ne sont pas adaptés au jeu-video. En gros il veut quelque-chose de plus moderne que le C mais sans les contraintes liées à la sécurité de Rust comme le borrow checker qu'il n'estime pas rentable pour le jeu video. Pour lui le principal est un langage qui compile vite et facile a déboguer.

    Et si tu as du mal a trouver sur Google, c'est normal vu que le langage n'est pour le moment pas distribué publiquement. Jonathan Blow a juste fait quelques présentations video de celui ci que tu dois pouvoir trouver sur YouTube. Le langage n'est actuellement utilisé qu'en interne pour les jeux de Jonathan Blow et il semble plutôt instable : Jonathan Blow a encore annoncé récemment qu'il a modifié des concepts clé du langage.

  20. #40
    Expert éminent sénior
    Citation Envoyé par Uther Voir le message
    Justement "dans son domaine" (sous-entendu le web je suppose) on ne fait pas énormément de manipulation de bit.
    Dès que tu fais un peu de crypto, tu en fais sans le savoir, car tu utilises des bibliothèques.

    Cela dépend aussi de ce que tu implémentes, par exemple sur des systèmes d'authentification multi-facteurs biometriques, des jeux en lignes HTML5, démonstrations en lignes, ... tu peux être amené à manipuler des bits.
    Ce n'est pas parce que tu utilises rarement cette fonctionnalités, que de telles problèmes de langages en sont acceptables pour autant.


    Et si on n'en fait pas, c'est peut-être aussi parce que c'est complètement pêté, et qu'on évite de trop y toucher quand on peut l'éviter.

    Citation Envoyé par Uther Voir le message
    Je suis entièrement d'accord que le Javascript est un langage bancal, mais pour un défenseur du C avec ses presque 200 "undefined behavior", c'est un peu l’hôpital qui se moque de la charité.
    Sauf que la différence est que ces "undefined behavior" sont des choses à ne pas utiliser (généralement erreur de programmation), et sont défini tels quels.
    Pour rappel, le C vise la performances, et donc n'a pas pour objectif de vérifier que tu ne fais rien de "mal".

    Alors qu'en JavaScript, cela fait parti intégrante des fonctionnalités du langage... C'est une erreur de conception/spécification du langage...

    Citation Envoyé par Uther Voir le message
    Il y a une grosse différence entre les annonce sur les sites d'actualité qui cherche forcément un peu le sensationnel et ce qui se passe dans les équipes de dev. On ne choisit pas un langage uniquement parce qu'on a vu un joli article mais parce que l'on a pesé les impact positif comme négatif que son utilisation.
    Ce qui se passe dans les équipes de devs ne sont pas l'objet de ma critique.
    Pour rappel, je critiquais le fait qu'on nous annonce 10 successeurs du C par ans.

    Citation Envoyé par Uther Voir le message
    Par contre quand on voit l’investissement actuel dans le Rust ou le Go, je pense que ces langages peuvent raisonnablement être considérés viables.
    Le problème, c'est qu'on ne sait jamais de quoi l'avenir sera fait. Est-ce qu'un autre langage va les supplanter et siphonner leurs communauté ?
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/