Introduction de 30 minutes au langage Rust. (Un meilleur C)

https://doc.rust-lang.org/intro.html

Exemple de problème du langage C a écrit:
All good? Let's go over a similar, but subtly different example, in C++:

Code:

#include<iostream>
#include<vector>
#include<string>

int main() {
    std::vector<std::string> v;

    v.push_back("Hello");

    std::string& x = v[0];

    v.push_back("world");

    std::cout << x;
}

It's a little more verbose due to the static typing, but it's almost the same thing. We make a std::vector of std::strings, we call push_back (same as push) on it, take a reference to the first element of the vector, call push_back again, and then print out the reference.

There's two big differences here: one, they're not exactly the same thing, and two...

$ g++ hello.cpp -Wall -Werror
$ ./a.out
Segmentation fault (core dumped)
A crash! (Note that this is actually system-dependent. Because referring to an invalid reference is undefined behavior, the compiler can do anything, including the right thing!) Even though we compiled with flags to give us as many warnings as possible, and to treat those warnings as errors, we got no errors. When we ran the program, it crashed.

Je n'ai jamais réussi à accepter le langage C. Et pourtant je l'ai enseigné.
Le typage y est incohérent, les raccourcis de langage le rendent difficile à comprendre. Enfin, c'est comme de l'anglais comparé à des langues plus logiques.

En programmation, il est rare qu'on ait vraiment besoin de coller aux ressources système. Aussi en général je crois que des langages logiques, tels Caml ou Haskell, sont beaucoup plus prometteurs.

Il faudrait un language qui a a la fois est capable d'executer de très petites taches codé sur mesure et a côté faire appel a de multiples fonctions complexes intégré au language.

Ca pourrait permettre d'allier simplicité du codage et performances extreme du code juste la ou il faut.

En gros mélanger la PDO la plus complète mais tout en étant capable de coder en language processeur, sans avoir besoin de faire de modifications particulière au niveau de la compilation.

@Pieyre : Je me pose une question ... vous avez lu un peu de quoi il s'agit (le langage rust), ou vous répondez au hasard ??

https://stackoverflow.com/questions/29184358/requiring-implementation-of-mul-in-generic-function

Code:


fn cube<T>(x: T) -> T
    where T: Mul<Output=T> + Copy
{
    x * x * x
}


Une fonction qui demande d'avoir surchargé la multiplication ainsi que "copy" (duplication) au sein d'un type passé en paramètre. La copy est indispensable ici du fait des mécanisme particulier du langage.

Complètement illisible pour moi le Rust et sans réel intérêt.

(oui il s'occupe d'eviter que les mauvais programmeurs fassent n'importe quoi, mais les mauvais programmeurs font du php pas du C/C++)

Aucun langage ne sera jamais assez bon pour donner miraculeusement du talent à un mauvais programmeur, ni assez mauvais pour empêcher un bon programmeur de construire des programmes fonctionnels (il pourra le forcer à pousser de gros soupirs et à perdre beaucoup de temps sur des tâches basiques, mais c'est tout).

Scoop: les mauvais programmeurs parviennent à faire des cochonneries truffées de bugs avec tous les langages, et les bons programmeurs à faire des trucs qui fonctionnent avec tous les langages -- même les plus atrocement mauvais (il y en a -- mais il y a surtout des groupies d'un langage qui croient malin de dénigrer tous ceux dont ils ne savent pas se servir). On appelle ça le Turing-complete, c'est quand même un petit peu à la base de l'art de programmer depuis que l'informatique existe, de sorte que je suis toujours sidéré qu'il y ait des programmeurs professionnels qui discourent comme s'ils l'ignoraient et prétendent que tant qu'on ne travaille pas avec Chose on est nul et qu'il suffit de travailler avec Bidule pour être nul.

Il y a sans doute des langages meilleurs que d'autres. Mais il y a surtout des langages plus adaptés que d'autres à certaines tâches, certains besoins, certaines façons de travailler, et il n'existe pas, il ne pourra jamais exister, de langage qui possède toutes les qualités de tous les autres langages (quand ce ne serait que parce qu'on ne peut pas à la fois être innovant -- c'est une qualité -- et connu de tout le monde -- c'est aussi une qualité). Là encore, ce que je dis est complètement élémentaire, et il faut vraiment n'avoir jamais touché à plus d'un langage de programmation pour en douter.

Il faut aussi prendre en compte des réalités déplaisantes: il y a de très bons langages que personne n'utilise (en tout cas à un instant t) et dont la communauté est (encore) inexistante -- et auxquels on peut donc légitimement préférer des langages médiocres et prétendument dépassés qui ont le tort capital... de tourner sur un peu tout ce qui se présente depuis des décennies, et pour l'étude desquels on trouve très facilement des gens disposés à vous donner des coups de main, des ouvrages d'initiation de bonne qualité, des tonnes de librairies disponibles, etc. Un langage, c'est aussi et peut-être même d'abord une communauté, et les qualités du langage ne peuvent guère compenser la minceur d'une communauté quand ce n'est pas carrément son inexistence.

Cela dit, peut-être que Rust c'est très bien et que sa communauté est hyper-dynamique, je ne demande qu'à le croire -- mais franchement, ce ne serait pas la première fois que j'entendrais ce genre de promesses électorales pour des langages voués à tomber dans l'oubli deux ou trois ans à peine après être sortis de l'anonymat. Je souhaite donc à Rust plus de succès qu'à Go (par exemple), qu'à OCaml, qu'à Haskell, qu'à Scala, qu'à Ruby ou même Ada. A vrai dire, depuis une trentaine d'années que je m'intéresse à la programmation, le seul langage que j'aie vu présenté comme innovant à sa sortie et qui ne se soit pas cantonné à un rôle au mieux marginal... c'est Java. Or franchement, dans le lot, c'est de très loin celui qui m'enthousiasmait le moins.

Les langages C et C++ sont de vieilles cochonneries, c'est vrai -- mais ces vieilles cochonneries sont assez vieilles pour avoir donné naissance à des tas d'outils fonctionnels, à des tonnes de librairies (libres, en plus), à des tonnes de bouquins et de documentation libre en toutes les langues de la planète, et quand on veut les apprendre on trouve très facilement des copains qui ne demandent pas mieux qu'à vous aider à les maîtriser -- ce qui, ô surprise, est non seulement possible mais même pas particulièrement difficile. En comparaison de ça, les langages tout nouveaux tout beaux... ça peut être intéressant, ça peut même être enthousiasmant, mais ça reste très casse-gueule et d'un avenir incertain.

Servo : Le rendu de Mozilla écrit en Rust

Je n'ai encore regardé que le premier quart d'heure de la vidéo. J'espère trouver le courage de regarder le reste, même si le gars parle horriblement vite et articule mal.

Les idées d'ownership et de borrowing m'ont l'air originales et pas du tout sottes, même si, faute d'habitude sans doute, j'ai un peu l'impression qu'on me donne tous les moyens de gérer proprement des situations dans lesquelles je n'aurais jamais eu l'idée de me placer auparavant!

Mais ça, ce n'est rien. Ce qui me gêne beaucoup plus, c'est que le conférencier justifie l'emploi de ces techniques déconcertantes par le fait que ça évite des "common mistakes" que l'on est supposé faire en C et C++. Je ne voudrais pas être méchant, mais un programmeur C/C++ qui commettrait couramment, et même rarement, de telles erreurs, serait de toute évidence un très mauvais programmeur car il est flagrant que ces pratiques dénoncées sont fautives et mènent à des plantages, et qu'il ne faut jamais écrire de telles horreurs; même un débutant doit le savoir. Certes, un compilateur C/C++ n'alerterait pas forcément en cas d'emploi de ces techniques aberrantes, mais ce n'est pas vraiment son rôle que de signaler aux incompétents qu'ils s'y prennent comme des manches.

"Mon langage est tellement bon que même si vous êtes nul vous arriverez à vous en servir" est à mes yeux un très mauvais argument, pour tout un tas de raisons: 1) si tu y tiens vraiment je veux bien croire que tu ne sais pas te servir de C/C++, coco, mais t'es gentil, tu évites de présumer que je suis nécessairement aussi incompétent que toi; 2) si j'étais incompétent je chercherais à m'améliorer, pas à trouver de nouveaux outils me permettant de troquer une incompétence contre une autre; 3) (je l'ai déjà dit dans un post précédent) ce n'est pas un langage qui me donnerait du talent si je n'en avais pas; si j'étais mauvais en C/C++, je resterais mauvais en Rust ou n'importe quoi d'autre, simplement il me faudrait peut-être plus de temps pour en prendre conscience...

Je serais nettement plus sensible à des arguments du genre "si vous savez faire ça proprement en C, vous savez aussi à quel point c'est galère de le faire proprement, et donc vous serez enchanté que ce soit cinquante fois plus facile en Rust". Mais c'est déjà à peu près comme ça qu'on m'a convaincu d'essayer Java et ça ne m'a pas empêché d'y identifier ensuite des tonnes de lourdeurs que je ne rencontrais pas en C... auquel j'ai donc fini par revenir tellement je le trouve moins bavard et bureaucratique. Ne pas oublier que quand on veut corriger un défaut, il faut se demander si la correction elle-même est exempte de défauts...

Cela dit, Rust commence à titiller ma curiosité.

Petitagore a écrit:
Mais ça, ce n'est rien. Ce qui me gêne beaucoup plus, c'est que le conférencier justifie l'emploi de ces techniques déconcertantes par le fait que ça évite des "common mistakes" que l'on est supposé faire en C et C++. Je ne voudrais pas être méchant, mais un programmeur C/C++ qui commettrait couramment, et même rarement, de telles erreurs, serait de toute évidence un très mauvais programmeur car il est flagrant que ces pratiques dénoncées sont fautives et mènent à des plantages, et qu'il ne faut jamais écrire de telles horreurs; même un débutant doit le savoir. Certes, un compilateur C/C++ n'alerterait pas forcément en cas d'emploi de ces techniques aberrantes, mais ce n'est pas vraiment son rôle que de signaler aux incompétents qu'ils s'y prennent comme des manches.

Objectivement je n'ai jamais été très doué pour la programmation (comparé aux gourous). Mais ce besoin d'éviter les commons mistake, on est nombreux à l'avoir. Des qu'a t'a écrit plus d'un million de lignes de code dans ta vie, tu te prends d'une envie irrépressible d'éviter automatiquement les Commons mistake. Come one !  L'ennui de ces commons mistake, c'est qu'il suffit d'une faire une seule erreur sur un million de lignes (et des fois tu n'écris pas tout seul les un million de lignes !) pour que ça soit vraiment la merde : tu te retrouves avec un bug aléatoire, très difficile à reproduire et à documenter, identifier etc. Ou alors tu te retrouves avec une faille de sécurité monstrueuse.

L'autre force de Rust, c'est qu'il propose les facilités d'un langage moderne (pattern matching entre autres). Enfin je dis ça, je n'ai toujours rien écrit en rust ...

Naturellement pour les petits projet de moins de 10 000 lignes, C fonctionne assez bien. L'assembleur aussi.

Stauk a écrit:Mais ce besoin d'éviter les commons mistake, on est nombreux à l'avoir. Des qu'a t'a écrit plus d'un million de lignes de code dans ta vie, tu te prends d'une envie irrépressible d'éviter automatiquement les Commons mistake. Come one !

Si tu n'es pas pris d'une envie irrépressible d'éliminer les bugs dès ton tout premier bug, je pense que tu n'es pas fait pour la programmation.

L'ennui de ces commons mistake, c'est qu'il suffit d'une faire une seule erreur sur un million de lignes (et des fois tu n'écris pas tout seul les un million de lignes !) pour que ça soit vraiment la merde : tu te retrouves avec un bug aléatoire, très difficile à reproduire et à documenter, identifier etc. Ou alors tu te retrouves avec une faille de sécurité monstrueuse.

Ça c'est vrai. Mais c'est tellement vrai et vrai depuis tellement longtemps que l'argument a déjà servi pour justifier le passage à des dizaines de langages tous plus ultra-minoritaires les uns que les autres. Des groupies d'Ada me l'ont encore servi il y a moins de six mois... or Ada, qui a plus de trente ans, est toujours cantonné dans une niche et ne me paraît vraiment pas parti pour en sortir.

Il y a un langage (que je n'aime pas du tout) qui a réussi à percer sur la promesse d'éliminer les fuites de mémoire et les erreurs de pointeur: c'est Java. Java est très chiant et bureaucratique, mais il marche. Si on se place sur le même créneau, le vrai bon argument serait d'expliquer pourquoi on est moins chiant et bureaucratique que Java. C'est comme ça qu'on a réussi à m'intéresser à Haskell, par exemple. Peut-être que Rust va réussir à me faire le même effet, mais jusqu'ici ça ne me paraît pas flagrant.

Naturellement pour les petits projet de moins de 10 000 lignes, C fonctionne assez bien. L'assembleur aussi.

Tut tut tut, quand on commence à employer les arguments de basse polémique, c'est le signe qu'on n'en a pas beaucoup de bons en réserve...

Petitagore a écrit: Java est très chiant et bureaucratique, mais il marche.

Nan java ne fonctionne pas : le garbage collector vient t'emmerder en permanence. Après on pourrait réécrire l'ensemble des bibliothèques pour qu'elles deviennent garbage collector friendly. Mais ça ne semble pas plus réaliste que de passer directement à un autre langage. L'autre problème de Java, c'est que quand une fonction renvoie un résultat qui n'est pas un type de base, il faut passer par les références java.  Et finalement, le Java a le même problème que le C++ : c'est un langage ancien, qui est étendu doucement, et n'est donc pas très satisfaisant (java tout en demandant pratiquement autant d'investissement que d'apprendre un nouveau langage.

Ada a été pas mal utilisé dans l'industrie. Il existait des offres d'emplois et tout.

Après oui, quand on tente un nouveau langage, y a toujours une part de risque qu'il reste confidentielle. La question est surtout de savoir si nous on a le besoin/ l'envie de l'utiliser, pour nos projets personnels. Et en ce qui concerne Rust, c'est le cas pour moi. Par ailleurs il se place d'emblée sur la même niche que le C++ et le c. Qui ont quand même bien besoin d'un petit coup de jeune (tabula rasa). Le Rust apporte les 20 ans d'expérience de la communauté entre le moment ou le C++ a commencé à bien prendre, et notre époque moderne.

Stauk a écrit:Nan java ne fonctionne pas : le garbage collector vient t'emmerder en permanence.

Il est possible que ça te gêne toi pour ce que tu fais toi (ça dépend peut-être aussi de ton style de programmation: quand on vient comme moi à Java avec déjà des habitudes de rigidité acquises en se battant contre C, je crois que le garbage collector n'a rien de déconcertant), mais personnellement je n'ai jamais eu à m'en plaindre (il est vrai que je n'ai jamais utilisé Java quand j'avais besoin que les choses aillent très vite... parce que dans ce cas-là je préférais travailler directement en C). En revanche, j'ai rarement réussi à écrire douze lignes de Java sans me dire que sa rigidité bureaucratique m'exaspérait.

L'autre problème de Java, c'est que quand une fonction renvoie un résultat qui n'est pas un type de base, il faut passer par les références java.

C'est une contrainte et en effet Java est très contraignant, mais je n'appellerais pas ça un problème: on peut trouver ça chiant, mais ça ne mériterait le nom de problème que si ça menait en droite ligne au plantage (dans cet esprit, on peut considérer que l'emploi des pointeurs en C/C++, lui, est bien un problème même si il ne faut pas confondre problème sérieux et problème ingérable).

Ada a été pas mal utilisé dans l'industrie. Il existait des offres d'emplois et tout.

Il y en a encore, mais ça a été et ça reste une niche (douillette, mais toute petite). Cela dit, je me serais volontiers mis à Ada si on m'avait payé pour ça! Je peux en dire autant pour Rust ou un peu n'importe quoi d'autre: c'est fou ce que j'accepte de faire quand on me paye (j'ai même mis mon nez dans du Fortran quand on m'a payé pour ça!). Mais quand c'est moi qui m'impose mes galères... ben je préfère embarquer sur des trucs moins marginaux.

La question est surtout de savoir si nous on a le besoin/ l'envie de l'utiliser, pour nos projets personnels. Et en ce qui concerne Rust, c'est le cas pour moi.

Et tu as ma bénédiction.   N'hésite pas, d'ailleurs, à expliquer sur quoi tu travailles, on comprendra probablement mieux pourquoi ça te convient particulièrement. Je pourrais te dire des choses assez similaires à propos de Haskell, auquel je me suis intéressé non pas parce que j'en avais besoin mais parce que je le trouvais intellectuellement stimulant -- en revanche je ne suis pas sûr que je chercherais à y convertir même mon pire ennemi: trop de risques de charger mon karma en incitant le gars à dépenser beaucoup d'énergie sur un truc qui passera peut-être très vite de mode.

Par ailleurs il se place d'emblée sur la même niche que le C++ et le c. Qui ont quand même bien besoin d'un petit coup de jeune (tabula rasa). Le Rust apporte les 20 ans d'expérience de la communauté entre le moment ou le C++ a commencé à bien prendre, et notre époque moderne.

Tu fais un peu flèche de tout bois: on ne peut pas à la fois dire que le langage profite de vingt ans d'expérience (au point d'être couvert de rouille, d'où son nom) et prétendre qu'il fait table rase du passé. Rust s'inscrit dans une tradition, et même il le revendique, et c'est très bien, c'est assurément une qualité -- mais du coup c'est sans doute moins rajeunissant de s'y mettre que de changer complètement de paradigme. Passer d'un langage procédural à la C à un langage fonctionnel à la Haskell, ça, pour le coup, c'est vraiment faire table rase, perdre tous ses réflexes, les bons comme les mauvais. Je ne suis pas sûr que ce soit une qualité, d'ailleurs, mais si on aime les tables rases (pour le plaisir de se triturer les méninges), c'est plutôt dans ce genre de directions qu'il faut s'orienter.

Petitagore a écrit:
Tu fais un peu flèche de tout bois: on ne peut pas à la fois dire que le langage profite de vingt ans d'expérience (au point d'être couvert de rouille, d'où son nom) et prétendre qu'il fait table rase du passé. Rust s'inscrit dans une tradition, et même il le revendique, et c'est très bien, c'est assurément une qualité -- mais du coup c'est sans doute moins rajeunissant de s'y mettre que de changer complètement de paradigme. Passer d'un langage procédural à la C à un langage fonctionnel à la Haskell, ça, pour le coup, c'est vraiment faire table rase, perdre tous ses réflexes, les bons comme les mauvais. Je ne suis pas sûr que ce soit une qualité, d'ailleurs, mais si on aime les tables rases (pour le plaisir de se triturer les méninges), c'est plutôt dans ce genre de directions qu'il faut s'orienter.

Je crois y a incompréhension là.

Il profite de 20 ans d'expérience  :  tous les retours et les essais de langages que les développeurs ont fait, que ça soit des langages fonctionnels ou procéduraux, les designs patterns, bref 20 d'expériences de l'ingénierie dans son ensemble.

Il fait table rase : il n'y a pas de retro compatibilité à respecter, on peut donc implémenter tous et n'importe quoi qui serait pratique, et tout de même conforme aux objectifs du langage.

L'objectif du langage est :   Eviter les failles de sécurités et les bugs aléatoires, et permettre d'écrire des programmes aussi performant que des programmes C, tout en permettant d'utiliser les meilleures pratiques et conceptions (objets et fonctionnelles).

Bref ... pour pouvoir me faire les dents un peu sur le langage, je vais avoir besoin de faire des exercices. J'ai donc créé un fil avec quelques idées d'exercices :

https://www.zebrascrossing.net/t21204-exercices-d-informatiques-pour-gens-qui-s-ennuient-ou-qui-veulent-apprendre-un-nouveau-langage

Il serait bien que j'implémente tout ce bazard en Rust, sur un dépot publique, et que je vous permette de suivre (si y a des gens que ça intéresse). Pour le moment je ne veux naturellement pas m'embarquer sur des gros projets, et les projets sur le fil que je vous donne sont de taille réduite. Par ailleurs les IHMs posent tout un tas de problèmes de dépendances de librairie, et donc je préfère faire des programme de type "ligne de commande" pour commencer. Et puis ça sera une bonne occasion de m'intéresser à ces programmes "ligne de commande", car si j'en ai utilisé parfois, je n'ai pas tellement d'expérience de leur réalisation.

Personnellement je trouve que Rust est une grande arnaque, tous ses arguments anti C++ se basent sur le C++ norme 2003, hors la norme 2011 introduit tout ce qu'il faut pour ne pas faire n'importe quoi, on appel ca le C++ moderne.
L'histoire de owner et de borrowing existe complètement en C++, on appel ca le shared_ptr et le weak_ptr.
J'ai aussi vu que les partisans de Rust aiment venter les mécanisme super utile pour la programmation concurrente, j'ai même vu une conférence de 45 minutes sur ce que j'ai finis par comprendre était simplement un scoped_lock, une primitive ultra simple qui existe bien en C++. Ils aiment aussi parler de leur systeme de queue pour passer des messages entre les threads (whouhou un pattern producer/consumer que c'est nouveau !) qui existe en C++.

On peut meme se taper des barres en voyant que eux meme se rendent compte qu'ils pompent C++11 : http://doc.rust-lang.org/0.12.0/std/sync/atomics/

En gros "rust c'est genial, regardez comme c'est bien si on compare a une version de C++ qui a 12 ans et que plus personne n'utilise".

@ Darth Mitch :

http://www.mistybeach.com/articles/WhyIDontLikeCPlusPlusForLargeProjects.html

The following is a list of all publicly disclosed vulnerabilities discovered by TippingPoint Zero Day Initiative researchers. While the affected vendor is working on a patch for these vulnerabilities, TippingPoint customers are protected from exploitation by IPS filters delivered ahead of public disclosure. TippingPoint customers are additionally protected against 0day vulnerabilities discovered by our own DVLabs researchers. A list of published advisories discovered by TippingPoint's DVLabs research group is available from:

http://www.zerodayinitiative.com/advisories/published/
(Tu peux remarquer qu'il y a "buffer overflow" à presque chaque ligne de vulnérabilité !!! ) Peut être C++ 11 c'est génial, et personne ne l'utilise ?


Je sais pas te répondre, je n'ai pas suffisamment d'expérience avec C++ 11 (j'en ai aucune ..). Après s'il y a l'équivalent du pattern matching en C++ 11, je veux bien voir. Est ce qu'il y a aussi  les traits ?  J'ai acheté le bjarne Soustrup sur C++ 11, mais ça prend un peu de temps à lire .. je pense que quand j'aurais fini le bouquin, ils  en seront au C++20

Ah oui, un truc qui me gonfle avec C++ 2003, ce sont les fichiers multiples. Les .h c'est chiant.

Article de 2001 donc C-with-classes ! Meme pas la norme 2003, article sans intérêt donc.

Pour ce qui est de ZDI tu noteras que dans beaucoup de cas les exploit touche des programmes Java, que les exploit native que l'on peut trouver sont souvent dans les noyaux ou dans du legacy code donc generalement du C ou du C++ qui a 20 ans.

Il n'y a pas de pattern matching en C++ car ca ne sert a rien, on se propose de travailler sur un langage objet et donc d'abstraire le contenu d'un object, pouvoir acceder au contenu n'a donc aucun sens.

Les traits existent http://www.cplusplus.com/reference/type_traits/
Et comme ils se basent sur la meta programmation, n'importe qui peut étendre les traits très facilement.

Ce que je reproche au C++ moderne :
- Le temps de compilation, qui devrait être adressé dans le C++17
- L'absence d'IO standard, C++17 également
- La volonté de ne jamais vouloir casser la compatibilité avec les versions précédentes, malheureusement je doute que cela change un jour.
- La rigidité de certains programmeurs système qui ne veulent pas utiliser les nouveautés.

Il y a encore les fichiers .h, ou de ce coté là ça va mieux ?

Il y a encore les header c'est bien ca le probleme du temps de compilation, il existe des mécanisme permettant de precompiler tous les headers pour augmenter les performances (ce qui n'est pas négligeable, on est passe de 6h de compilations de 15 minutes ou je bosse).
Mais ce n'est pas standard et on espere se debarasser des headers au profit des modules dans C++17.

De haute lutte, j'ai réussi à implémenter une fonction qui "reverse" une string.
On peut executer le programme directement dans le navigateur, via un bouton, ce qui est rigolo (bon il faut que le programme tienne en un seul fichier, ce qui n'est pas si pratique que ça, mais ça fonctionne pour tester une fonction très simple)
http://is.gd/aFi5zO

http://ideone.com/UEf2sG

C'est plus rapide en C++ :s

Darth Mitch Connor a écrit:http://ideone.com/UEf2sG
C'est plus rapide en C++ :s

Je pense qu'il doit y avoir des façons plus courtes. Mais j'ai déjà bien galéré. Mmm, je me disais qu'il faudrait que j'essaye le C++, mais si tu traduis mes programmes rust, c'est nickel en fait

Est ce qu'il marche avec du Mandarin ton programme au fait ?
http://is.gd/JVUBet

Je viens d'essayer de vérifier si le tien fonctionnait : "Standard input is empty" mouhahahaha !  
nah ! Enfin si ça se trouve c'est le site web qui merdoie mais bon

Chez moi ca fonctionne enfin ca me sort des ????????? car il n'a pas la locale.

Darth Mitch Connor a écrit:Chez moi ca fonctionne enfin ca me sort des ????????? car il n'a pas la locale.

Ce sont des chaînes UTF aussi en C++ ? Bon bon, admettons.

ah mais j'ai copié le input, les outputs c'est "???????" effectivement. C'est suspect que ça s'affiche correctement dans le programme, mais pas en sortie tout de même.

J'ai un peu tourné dans ma tête l'argument -- au demeurant fort classique -- du bug introuvable parmi des millions de lignes en C++, rendant absolument nécessaire l'adoption de langages plus sûrs. Et je me dis:

- qu'il correspond bien à une réalité qui a été constatée en pratique (des failles de sécurité énormes dans des outils puissants et très répandus);

- qu'il est quand même largement fallacieux.

Premièrement, parce qu'il n'est pas si courant que ça de travailler sur des programmes ayant des millions de lignes. Statistiquement, l'analyste-programmeur qui gagne sa croûte est plus souvent occupé à écrire le petit script PHP qui va bien pour alimenter ou exploiter un petit bout d'une base SQL de taille moyenne, voire modeste, qu'à revoir de fond en comble un système d'exploitation ou, plus modestement, un gros logiciel de bureautique. Donc, d'emblée, on pourrait remarquer que la nécessité absolue de ne jamais écrire de bug indétectable au milieu d'un million de lignes est beaucoup plus prégnante pour de très très gros projets que pour ceux qu'en pratique un analyste-programmeur lambda a des chances de rencontrer (et même si l'analyste-programmeur finit par être recruté pour bosser sur un projet pharaonique, ce sera vraisemblablement après s'être fait la main sur des projets sensiblement moins ambitieux).

Deuxièmement, parce qu'en pratique, les très très gros projets sont très majoritairement écrits en C, C++ ou à la rigueur Java, ce qui semble indiquer que ces langages ne mènent pas aussi infailliblement aux plantages dramatiques qu'on le prétend. C'est à leurs fruits qu'on juge les arbres, a dit le Seigneur Jésus (qui ne disait pas que des conneries), or les fruits de C/C++ sont quand même très très abondants et loin d'être aussi radicalement pourris que le prétendent les ennemis de ces langages.

Troisièmement, parce qu'un très très gros projet intègre toujours des tripotées de librairies qui n'ont pas été spécifiquement pensées pour ce très très gros projet-là, et qui en pratique plantent quand même très peu (il y a des exceptions notoires, mais ce sont des exceptions), ce qui n'est sans doute pas sans rapport avec deux considérations: 1) ces librairies ont été écrites par des gens qui avaient du talent (je maintiens que c'est le noeud du problème); 2) ces librairies ont déjà été archi-testées et déboguées au fil des ans, en sorte que leur réputation de fiabilité correspond à une réalité éprouvée dans la pratique, non à de simples promesses enthousiastes.

Un langage très fiable reste en théorie nettement préférable à un langage faillible. Il n'empêche qu'en pratique, on construit de plus grands projets informatiques avec des langages médiocres, mais répandus et employés par des programmeurs géniaux, qu'avec des langages irréprochables mais marginaux, employés par des programmeurs simplement talentueux voire médiocres.

Ou pour le dire autrement: si les mauvais ouvriers ont toujours de mauvais outils, les bons outils ne suffisent pas à faire les bons ouvriers, et les très bons ouvriers arrivent à bosser très bien avec des outils de qualité moyenne mais acceptable. C'est pas le Seigneur Jésus qui l'a dit, mais ça a quand même été maintes fois constaté. Or C/C++ sont des outils de qualité moyenne mais acceptable, et ça fait des dizaines d'années qu'ils le prouvent tous les jours. Ca fait aussi des dizaines d'années que des outils de meilleure qualité, type Ada, ne percent pas.

Certes, l'idéal reste le très bon ouvrier travaillant avec le très bon outil. C'est vrai, mais c'est une affirmation à peu près aussi stupéfiante et constructive que le fait d'énoncer qu'il vaut mieux être riche et bien portant que pauvre et malade.

Petitagore a écrit:
- qu'il est quand même largement fallacieux.

Premièrement, parce qu'il n'est pas si courant que ça de travailler sur des programmes ayant des millions de lignes. Statistiquement, l'analyste-programmeur qui gagne sa croûte est plus souvent occupé à écrire le petit script PHP qui va bien pour alimenter ou exploiter un petit bout d'une base SQL de taille moyenne, voire modeste, qu'à revoir de fond en comble un système d'exploitation ou, plus modestement, un gros logiciel de bureautique. Donc, d'emblée, on pourrait remarquer que la nécessité absolue de ne jamais écrire de bug indétectable au milieu d'un million de lignes est beaucoup plus prégnante pour de très très gros projets que pour ceux qu'en pratique un analyste-programmeur lambda a des chances de rencontrer (et même si l'analyste-programmeur finit par être recruté pour bosser sur un projet pharaonique, ce sera vraisemblablement après s'être fait la main sur des projets sensiblement moins ambitieux).

Deuxièmement, parce qu'en pratique, les très très gros projets sont très majoritairement écrits en C, C++ ou à la rigueur Java, ce qui semble indiquer que ces langages ne mènent pas aussi infailliblement aux plantages dramatiques qu'on le prétend. C'est à leurs fruits qu'on juge les arbres, a dit le Seigneur Jésus (qui ne disait pas que des conneries), or les fruits de C/C++ sont quand même très très abondants et loin d'être aussi radicalement pourris que le prétendent les ennemis de ces langages.

Troisièmement, parce qu'un très très gros projet intègre toujours des tripotées de librairies qui n'ont pas été spécifiquement pensées pour ce très très gros projet-là, et qui en pratique plantent quand même très peu (il y a des exceptions notoires, mais ce sont des exceptions), ce qui n'est sans doute pas sans rapport avec deux considérations: 1) ces librairies ont été écrites par des gens qui avaient du talent (je maintiens que c'est le noeud du problème); 2) ces librairies ont déjà été archi-testées et déboguées au fil des ans, en sorte que leur réputation de fiabilité correspond à une réalité éprouvée dans la pratique, non à de simples promesses enthousiastes.

Je ne comprends strictement rien à ce que tu essayes de dire. A moins que le propos ne soit de dire qu'il est possible d'utiliser C++, et que C++ est très utilisé. Oui c'est vrai. Java aussi est très utilisé. Tes propos concernant les bons ouvriers c'est de la politique, ou alors carrément de la théologie, et je ne comprends pas le rapport avec le thème du fil.

Stauk a écrit:Je ne comprends strictement rien à ce que tu essayes de dire. A moins que le propos ne soit de dire qu'il est possible d'utiliser C++, et que C++ est très utilisé. Oui c'est vrai. Java aussi est très utilisé.

Eh bien tu vois que tu comprends! (en revanche, tu ne réponds guère)

Tes propos concernant les bons ouvriers c'est de la politique, ou alors carrément de la théologie, et je ne comprends pas le rapport avec le thème du fil.

C'est de la théologie si tu y tiens, ça ne me vexe pas... Pour ma part, j'aurais juste dit "jus de crâne", mais si tu préfères des mots plus glorieux, ça me va.

Tu sais, il m'arrive couramment de parler pour ne rien dire d'important, c'est même à peu près la seule raison pour laquelle je fréquente ce forum. Mais si tu préfères que je te foute la paix sur ton fil, OK, OK, je me casse, pardon pour le bruit, bonne journée.

Petitagore a écrit: Mais si tu préfères que je te foute la paix sur ton fil, OK, OK, je me casse, pardon pour le bruit, bonne journée.

Disons que je préfère qu'on reste dans le sujet : le langage Rust. A la rigueur le langage C++ 11 (concurrent donc, et bien mieux implanté dans l'industrie)

Je viens lâcher mon petit commentaire, étant pour ma part un fan assumé de Rust.

Je replace un petit contexte sur ma personne : Je suis familier du C++ depuis 7 ans (en autodidacte), et ça inclut le C++11 que j'ai pas mal suivi également.
Je pratique Rust depuis l'été dernier de manière assez intensive, et j'ai également un petit peu participé au compilateur Rust.

Je vais donc me contenter d'exprimer mon point de vue, et pourquoi je préfère (de très loin) Rust à C++.

Rust est un langage qui force à la rigueur. Le compilateur est très chiant sur ce plan, et n'hésitera pas à vous envoyer paître si vous lui demandez de la merde.

En Rust, la memory-safety (je sais pas quel serait le meilleur terme français pour ça) est là par défaut, il faut explicitement demander au compilateur pour passer outre (avec des blocs unsafe). En C++, c'est le contraire, il faut explicitement demander de la memory-safety pour en avoir (avec std::unique_ptr et es copains).

Rust intègre naturellement des éléments de programmation fonctionnelle. De même sa programmation orientée objet est très différente du C++ (il n'y a pas d'héritage, uniquement des traits, que l'on pourrait assimiler aux interfaces de Java). Ça le rend un peu déconcertant au début, mais dans l'ensemble beaucoup plus élégant que C++.

Et oui, les principes de RAII et de traits de Rust forcent à concevoir les programmes très différemment de C++, mais je trouve que ça leur donne une structure plus claire, plus explicite.

Et maintenant que je regarde C++14 et C++17, avec les nouveautés qu'ils apportent, je trouve que C++ ressemble de plus en plus à de la magie noire.

Donc pour résumer, ce qui me fait aimer Rust, c'est que je trouve le langage très confortable. Quand on veut refactorer un morceau du programme par exemple, souvent il suffit de faire la modification là où on veut la faire puis suivre les erreurs du compilateur jusqu'à ce que ça compile à nouveau.

Le fameux troll « ça compile donc ça marche » du C/C++ se révèle souvent vrai avec Rust. Et quand ça compile mais que ça ne marche pas, c'est très souvent que la logique sous-jacente est fausse. Je n'ai pas encore rencontré de situations sournoise comme les « use after free » du C/C++ dans Rust.

Rust est un langage qui force à la rigueur. Le compilateur est très chiant sur ce plan, et n'hésitera pas à vous envoyer paître si vous lui demandez de la merde.

C++ le permet tout autant suffit d'ajouter une analyse statique a sa toolchain et ca fera le meme chose, j'ai juste pas envie de me taper une analyse statique sans arret, surtout que l'analyse statique que peut faire le compilateur peut empecher de faire des choses legales car il n'est pas parfait.
Avec C++ j'ai donc le choix et plus de flexibilite.

En Rust, la memory-safety (je sais pas quel serait le meilleur terme français pour ça) est là par défaut, il faut explicitement demander au compilateur pour passer outre (avec des blocs unsafe).

Y a rien de pire pour un programmeur systeme que de ne pas pouvoir gerer sa memoire comme il le veut, par exemple quand je veux optimiser mes allocations je vais faire de l'allocation in place dans un gros block poubelle, en rust je peux pas le faire je perds en performance car le compilateur est chiant.

Ça le rend un peu déconcertant au début, mais dans l'ensemble beaucoup plus élégant que C++.

L'elegance c'est subjectif, je trouve les interfaces et les traits ignobles.

Je n'ai pas encore rencontré de situations sournoise
comme les « use after free » du C/C++ dans Rust.

Moi non plus mais je ne l'ai jamais rencontre en C++ non plus car je sais programmer.

Du coup on en revient a ce que je disais, le Rust est concu pour lutter contre l'incompetence de certains, mais pour moi les incompetents ont pas leur place dans la programmation systeme je ne comprends donc pas cette recherche de garde fou.

Samplet a écrit:je suis presque sûr que les apports n'ont rien de révolutionaires. Juste une époque voire une lubie.

Ben non, et ils n'ont jamais prétendu l'être. Rust se veut être une alternative moderne au C et au C++, qui sont de très vieux langages dont l'évolution est contrainte par des choix ayant été faits il y a 20 ans. L'informatique a beaucoup évolué depuis.

C est un langage tout à fait pertinent si on cherche de la performance pure, mais ce n'est plus le seul objectif aujourd'hui, on note une demande croissante en terme de sécurité. Et si on regarde rapidement, la plupart des failles de sécurité sont dues à des buffer-overflows, des use-after-free, des data-races ou des non-zeroed-memory. Ce sont en effet des erreurs de programmeur, en général des oublis, ou un design mal conçu.

Mais Rust lui fait ça tout seul, plutôt que de laisser le programmeur se démerder avec. Et c'est ça son cheval de bataille : laissons le langage s'occuper des erreurs courantes et parfois vicieuses à détecter, pour laisser le programmeur s'occuper du véritable problème.

Et là clairement, oui, la productivité du programmeur dépend du langage qu'il utilise. Certains langages sont plus adaptés que d'autres à certaines tâches, il faudrait être stupide pour ne jurer que par un seul langage. Et en l'occurence, C/C++ et Rust n'ont pas les mêmes objectifs de design. Et même si dans ses moutures récentes, C++ essaie tant bien que mal d'intégrer certains designs récents, le langage est surtout très vieux, et ça donne une ignoble soupe de templates incompréhensibles.

Edit: pour Mitch : ton argumentation se résume à « Il suffit de savoir programmer. », mais dans ce cas, pourquoi ne fais-tu pas tout en assembleur ?

Mon argumentation se resume a "quand on travaille sur des choses complexes qui demandent de la programmation systeme il faut savoir ce qu'on fait".

Je fais beaucoup d'assembleur, mais uniquement quand je sais que je suis meilleur que le compilateur (par exemple pour tout ce qui est extension du processeur SIMD et autres), le compilateur C++ est tres performant et je peux faire tout ce que je pourrais faire en assembleur en C++ donc je ne vois pas pourquoi perdre du temps a le faire en assembleur.

Le rust m’empêcherai de faire des choses que je peux faire en C++ et en assembleur et je doute fort qu'il soit capable de battre les performances du C++ avec un memory model dit safe.

Levans a écrit:Edit: pour Mitch : ton argumentation se résume à « Il suffit de savoir programmer. », mais dans ce cas, pourquoi ne fais-tu pas tout en assembleur ?

C'est vraiment un argument très très polémique. Tu sais parfaitement que "pour la portabilité", qui est la réponse originelle des tout tout débuts du langage C, il y a plus de quarante ans, reste totalement pertinente. Il y en a plein d'autres et plein de meilleurs, mais celui-là reste absolument valide, tandis que l'argument du "fais donc ça en assembleur", c'est vraiment le point Godwin de la discussion informatique. Un peu de sérieux.

Petitagore a écrit:

Levans a écrit:Edit: pour Mitch : ton argumentation se résume à « Il suffit de savoir programmer. », mais dans ce cas, pourquoi ne fais-tu pas tout en assembleur ?

C'est vraiment un argument très très polémique.

Oui, c'est ce qu'on appelle un troll. À son argument pourri « Il suffit de savoir programmer. », je lui réponds par un encore pire « Tu n'as tout faire en assembleur. ».

Darth Mitch Connor a écrit:le compilateur C++ est tres performant et je peux faire tout ce que je pourrais faire en assembleur en C++ donc je ne vois pas pourquoi perdre du temps a le faire en assembleur.

Le compilateur Rust est très performant et je peux faire tout ce que je voudrais faire en C++ en Rust, donc je ne vois pas pourquoi perdre du temps à le faire en C++.

Ah oui, et au passage:

Darth Mitch Connor a écrit:je doute fort qu'il soit capable de battre les performances du C++ avec un memory model dit safe.

Levans a écrit:C est un langage tout à fait pertinent si on cherche de la performance pure, mais ce n'est plus le seul objectif aujourd'hui, on note une demande croissante en terme de sécurité.

Oui, Rust ne permet pas d'abuser des monstrueuses optimisations que l'on pourrait faire en C/C++. Et alors ?
Dans beaucoup de situations aujourd'hui, les projets sont prêts à sacrifier une partie de leurs performances inutiles pour gagner en sécurité et en lisibilité de code, afin que ce dernier puisse facilement être repris par les successeurs.

Avec tes argument Mitch, au vu des bugs qui ont été découvert ces dernières années, on en conclurait que ceux qui ont programmé OpenSSL, le noyau Linux, et de nombreux autres projets sont des incompétents, puisque ce sont des bugs qui auraient été attrapés par le compilateur d'un langage comme Rust.

@Stauk : Attaque gratuite ... Attaque gratuite ...   Attaque gratuite  ... Attaque gratuite ...

Levans a écrit:Oui, Rust ne permet pas d'abuser des monstrueuses optimisations que l'on pourrait faire en C/C++. Et alors ?
Dans beaucoup de situations aujourd'hui, les projets sont prêts à sacrifier une partie de leurs performances inutiles pour gagner en sécurité et en lisibilité de code, afin que ce dernier puisse facilement être repris par les successeurs.

Ne peut-on pas dire rigoureusement la même chose pour défendre Java? Je sais que le bytecode Java étant interprété, la dégradation des performances que cela entraîne est plus que notable (quoique pas forcément insupportable), mais il est désormais possible de compiler du Java directement en langage machine, avec GCJ. Est-ce que le compilateur Rust bat GCJ à plate couture?

C'est une vraie question. Si la réponse est oui, ça me donnera envie de m'intéresser à Rust (je déteste Java). Si la réponse est non, en revanche... l'abondance des librairies disponibles en Java risquerait de me faire préférer Java (et j'en serais bien triste car je déteste Java, bis).

Samplet a écrit:@Levans : je vois que tu n'es gros débutant naïf... Tu n'y connais rien en système d'exploitation pour sortir des âneries pareilles ! L'os t'empêche de faire n'importe quoi depuis 10 ans au moins.

• buffer overflow
  
• use after free
  
• data race
  
• use of non zeroed memory
  

Ces 4 erreurs sont à la source de la majorité des failles de sécurité qui ont été découvertes ces dernières années (coucou openSSL ). Fait intéressant : elles tombent toutes sous le coup de l'« undefined behavior » du C et du C++.

Par ces 4 erreurs, je serais curieux de savoir lesquelles sont empêchées par le système d'exploitation.

Petitagore a écrit:Ne peut-on pas dire rigoureusement la même chose pour défendre Java?

Bien sûr que si, et ce serait pertinent. Le reproche que je fais à Java, personnellement n'est pas d'être semi-interprété, mais d'être un langage à garbage-collector où tout est implicitement passé par référence.

Samplet a écrit:Nan et puis SSL, je te rappelle que cela reste encore le meilleur protocole utilisé pour les chiffrages sur la toile http.

On parle bien de ce protocole obsolète et dépassé que tout le monde est en train d'abandonner au profit de TLS ?



Et sinon mon cher Simplet, à part brasser du vent, tu pourrais apporter des trucs constructifs à la discussion ?

Nan parce que ok, dans les cas très particuliers que du as cité, Rust n'est peut-être pas pertinent, mais il n'a jamais prétendu l'être.

Vous êtes bien gentil les gens, à attaquer Rust sur ce qu'il n'a jamais prétendu faire et être, mais c'est un peu comme si vous reprochiez à une scie de ne pas être pratique pour enfoncer un clou. Ben non, ça n'a pas été fait pour ça.

Alors peut-être que vous, vos ordinateurs personnels et le serveur sur lequel vous hébergez vos mails et votre blog sont en RISC (ce qui d'ailleurs, est à opposer à X86 et non à Linux ou Windows, si je ne m'abuse), mais ce n'est pas mon cas, ni celui de beaucoup de gens.

Samplet a écrit:Oui mais y'a que les gros ignorant qui ne savent que linux c'est forcément non risc.

https://github.com/riscv/riscv-linux

Samplet a écrit:Désactive sur ton navigateur les SSL et tu feras moins le malin, même si tu n'achètes rien... Donc il est pas dépassé et c'est toi qui repasseras avec tes preuves.

Firefox a désactivé le support de SSLv3 à partir de la version 34.0 (https://www.mozilla.org/en-US/firefox/34.0/releasenotes/). J'utilise cette version ou une plus récente depuis sa sortie, donc depuis décembre 2014. Ma navigation se fait donc en TLS uniquement depuis, sans aucun problème.

Ah oui, et pour suivre ton edit, que tu as si joliment ajouté après coup, si TLS = SSL 3.1, alors que sont TLS 1.1, et TLS 1.2 et TLS 1.3 ?
C'est si joli de déformer la réalité pour la faire coller à ses propos... Si le nom a été changé, il y a peut-être une raison, tu ne crois pas ?


Permets donc moi de ne pas prendre pour parole d'évangile ce que tu affirmes sans aucune justification.

À son argument pourri « Il suffit de savoir programmer. », je lui réponds par un encore pire « Tu n'as tout faire en assembleur. ».

Pour ma part je trouve toutes les conferences sur Rust pathetique, ca va passer des heures a vendre des concepts qui existent depuis super longtemps. Je trouve l'argument du "ca va empecher les gens qui font n'importe quoi de faire n'importe quoi" encore plus ridicule, les mauvais programmeurs ont rien a faire sur des projets de prog systeme c'est tout, si dans mon equipe y a un mec qui fait des erreurs aussi stupide qu'un double free, je le vire tout simplement.

Le Rust a aussi comme désavantage d’être illisible je trouve.

Si tu n'as pas besoin des optimisations que le C++ t'offre tu n'as pas besoin d'un langage de programmation système, va faire du python ou du java. Si tu utilises un langage de programmation système c'est que tu veux absolument TOUT contrôler, je peux pas taper dans un block de mémoire et allouer in place ? Et bah ca degage, pas besoin de compilateur nazi, je veux vérifier que ca passe une analyse statique, je lance une analyse statique, c'est pas complique.

Pour moi oui si il y a des erreurs aussi simple qu'une analyse statique peut soulever alors on est face a quelqu'un qui ne devrait pas faire ca. Le fait que les gens soient pas bons et ne sachent pas utiliser les outils qu'on leur donne ne fait pas d'un langage un mauvais langage.

Un compilateur a comme travail de compiler pas de faire attention a ce que fais le programmeur, c'est de l'analyse statique et ca n'a rien a faire dans un compilateur.

Donc on résume :
Tu choisis un langage de programmation parce qu'il inclue de l'analyse statique dans sa compilation au détriment des performances, des libertés d’implémentation et d'une des plus grandes communauté parce que tu ne savais pas que l'analyse statique existe (si tu l'avais su tu te serais rendu compte a quel point l'argument de la securite est idiot).

Soon : Les perceuses qui empêchent de percer tant qu'un ingenieur n'est pas venu verifier qu'on peut percer.

Darth Mitch Connor a écrit:Le Rust a aussi comme désavantage d’être illisible je trouve.

Le C++ a aussi comme désavantage d'être illisible je trouve.

On tourne en rond, tu ne crois pas ?

On a bien compris que tu voues une haine viscérale à tout ce qui n'est pas C++, et que tout ce qui n'est pas le domaine dans lequel tu travailles n'est pas de la vraie programmation, mais un travail d'incompétents.

Comme je l'ai dit précédemment, je ne choisis pas Rust pour son analyse statique, mais pour son modèle mémoire pertinent (il fait de la vraie RAII contrairement à C++), son système de traits et de génériques à la fois élégant et puissant (et qui est je trouve beaucoup propre que les templates et l'héritage du C++), pour son intégration d'éléments de la programmation fonctionnelle de manière naturelle et agréable à utiliser, ainsi que son support immédiat de l'ABI C, qui efface de nombreux soucis de compatibilité.

Maintenant, si pour toi ce ne sont pas de bons critères pour choisir un langage, et bien je suis fier d'être un abruti incompétent à tes yeux.

Darth Mitch Connor a écrit:
Je trouve l'argument du "ca va empecher les gens qui font n'importe quoi de faire n'importe quoi" encore plus ridicule, les mauvais programmeurs ont rien a faire sur des projets de prog systeme c'est tout

Petitagore a écrit:
1) ces librairies ont été écrites par des gens qui avaient du talent (je maintiens que c'est le noeud du problème);
[...]

Si je comprend bien, au vue de ces seuls arguments, cela veut dire que ce qui justifie le non abandon d'un outils complexe c'est le fait que des gens doués l'utilisent sans faire d'erreurs et que donc, il vaut mieux ne rien changer parce que l'on est de ce fait sûr que la méritocratie en place ne sera pas dérangée et que le mec un peu moins doué n'arrivera pas à décrocher des résultats équivalent au mec super doué ? Ca sonne un petit peu comme lorsque l'on propose une modernisation des outils de travail en usine, que l'employé pour lequel la qualification n'est plus utile vient crier parce qu'on lui vole son job, non ?

Petitagore a écrit:
Il n'empêche qu'en pratique, on construit de plus grands projets informatiques avec des langages médiocres, mais répandus et employés par des programmeurs géniaux, qu'avec des langages irréprochables mais marginaux, employés par des programmeurs simplement talentueux voire médiocres.

L'historicité n'est pas un argument.
En pratique, on doit se lever pour aller gagner de l'argent le matin, donc c'est ce qu'il faut faire.

Petitagore a écrit:
Certes, l'idéal reste le très bon ouvrier travaillant avec le très bon outil. C'est vrai, mais c'est une affirmation à peu près aussi stupéfiante et constructive que le fait d'énoncer qu'il vaut mieux être riche et bien portant que pauvre et malade.

Parce qu'un argument est évident il est mauvais ?

Bibo a écrit:Si je comprend bien, au vue de ces seuls arguments, cela veut dire que ce qui justifie le non abandon d'un outils complexe c'est le fait que des gens doués l'utilisent sans faire d'erreurs et que donc, il vaut mieux ne rien changer parce que l'on est de ce fait sûr que la méritocratie en place ne sera pas dérangée et que le mec un peu moins doué n'arrivera pas à décrocher des résultats équivalent au mec super doué ?

En ce qui me concerne, ce n'est absolument pas le seul argument que j'ai cité, je ne sais pas si ta précaution oratoire visait à l'admettre ou à me faire un reproche -- en l'occurrence injustifié.

Il ne s'agit pas de méritocratie, mais d'abondance de librairies disponibles (notamment sous licence libre), la richesse d'un socle sur lequel on peut s'appuyer pour construire autre chose. Ce socle est plus abondant avec un vieux langage très répandu qu'avec un nouveau qui se lance, ce n'est pas stupéfiant mais ce n'est pas pour ça que l'argument ne vaut rien. Je mentionnais aussi -- et ça me paraît une raison aussi classique que légitime de se méfier d'un nouveau langage -- le risque de dépenser de l'énergie sur un truc qui peut tomber dans l'oubli comme avant lui pas mal d'autres langages, que j'ai cités, les exemples ne manquent pas. A part ça, j'affirmais la nécessité du talent dans tous les langages, les nouveaux comme les anciens -- je veux bien qu'on m'accuse en l'espèce de faire de l'enfoncement de portes ouvertes, mais ce n'est pas une raison pour faire comme si on le talent algorithmique était un truc secondaire pour faire une carrière de développeur. Il faudra aussi du talent en Rust, non?