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. #61
    Nouveau membre du Club
    Citation Envoyé par Astraya Voir le message

    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
    Je n'aime pas les mots "applicatif" et "système", mon intuition me dit qu'ils ne permettent pas d'inférer clairement la définition que nous leur affectons. C'est-à-dire:

    - dois-je être "radicale" et considérer que la programmation système concerne uniquement la création d'OS et de driver?

    - NPM est-il une "logiciel applicatif ou un logiciel système?"

    - Go est utilisé pour manipuler les espaces de noms Linux pour Docker, donc go est un langage....?

    - Dans quelle catégorie de programme tu places les drivers qui décodent des protocoles réseaux et gères la communication avec des périphérique externes? J'en ai codé un en JAVA, un autre en C. Il existe une implémentation de MavLink en Go.

    - Dans quelle catégorie places-tu les drivers de connexion aux bases de données?

    - Le monde est-il blanc, noir, gris ou en full alpha?

    Mais bon, c'est "le jargon". #MachineLearningBigData

    Je place la définition de programmation système à côté selon WikiLove.

    Dans "mes rêves", le JS n'aurait jamais gagné autant en popularité, mais mon esprit tordu ne peut pas s'empêcher d'imaginer qu'un jour les GAFA ou un "génie dans sa cave" décideront d'optimiser(encore) le JS pour satisfaire mes "copins" qui prennent du "plaisir" à l'utiliser pour TOUT et n'importe quoi. #Electron
    Après le coup d'état de nodeJS au nom de "l'uniformité back-front", il est naturel pour mes copins JS friendly de clamer leur "part du gâteau" sur le territoire de la programmation système.
    Enfin, le Go "était" au départ destiné à la programmation système, et il l'est toujours. Il possède juste des attributs(Garbage Collector...) considérés comme discriminants, car dans "l'immaginaire collectif"(ou bien la réalité j'en sais rien - voir les questions en haut), langage de programmation système implique contrôle manuel de la mémoire et blablabla.

  2. #62
    Membre habitué
    Citation Envoyé par Uther Voir le message
    Par contre au niveau du support des architectures, il est vrai que le C est le seul langage a avoir un compilateur pour tout et n'importe quoi, y compris les microcontrôleurs les plus obscurs.
    Sans aller jusqu'au DSP, je parlais effectivement de programmation système, de moteur bas niveau, de traitement de données, de calcul numérique etc... tout ce qu'on a pas intérêt à programmer/industrialiser plusieurs fois...

    Citation Envoyé par Uther Voir le message
    Il existe certes des outils variés pour limiter les risques, qui apportent leur propre complexité et parfois de nouveaux risques s'ils sont mal utilisés, mais aucun n'apporte un niveau de garantie comparable à ce que permet Rust contre les erreurs mémoire.
    Quand on programme un module critique, on programme souvent aussi un stress test, un watchdog avec log, et parfois même un monitoring avec historique...
    alors je ne vois pas bien ce qu'on pourrait pas faire en 'C' pour atteindre le niveau de sécurité maximum ...
    et pour avoir passer plus de temps à debugger boundchecker qu'a réellement l'utiliser, je ne peux que pointer les limites des produits dit "miracles" sur le sujet...

  3. #63
    Membre éprouvé
    Citation Envoyé par Neckara Voir le message
    S'il ne sert à rien, pourquoi existe-t-il alors ?

    Ou plutôt, pourquoi '===' n'a-t-il pas directement remplacé '==' à la conception du langage ?
    Sachant que c'est bien '==' qui est utilisé dans tous les autres langages.

    Regarde du côté de PHP et genre la fonction mysql_connect (enfin, il y a 10 ans, aucune idée s'ils ont pas changé la gestion de la valeur de retour depuis).

    Tout ça pour dire que ce n'est pas que le JS.

    Le '==' et '===' est l'apanage de certain language interprété, car il n'a aucun intérêt dans du compilé.

    A titre personnel, j'utilise que le '==' (vu que je ne stocke pas différent type dans une seul variable) sauf si je dois différencier du un entier (potentiellement 0 ) ou boolean (false) d'un null voir d'un undefined.

    Après le choix de passé du C au Rust professionnellement n'est pas si simple. Si tu dois faire un truc très pointus, tu dois (et ton équipe aussi) maîtriser des aspect très fin du bas niveau déjà en C et en faire aussi bien le parallèle en Rust. Pour peu que tu dois faire du déterministe (au "malloc" près ?) il faut quand même non seulement prouvé (à ton équipe, tes supérieurs) que c'est donc aussi maîtrisable que le C et que ça apporte un avantage car avec le nombre de language qui se prétendait de valloir mieux que le C, il y a de quoi être sceptique si on regarde ça d'un oeil relativement lointain.

    Enfin dans le monde professionnel, tu vas souvent te heurter à "pourquoi changer quelque chose qui marche ?".

  4. #64
    Expert éminent sénior
    Citation Envoyé par walfrat Voir le message
    Regarde du côté de PHP et genre la fonction mysql_connect (enfin, il y a 10 ans, aucune idée s'ils ont pas changé la gestion de la valeur de retour depuis).
    Ouais, ils ont changé la valeur de retour vu qu'ils ont carrément supprimé toute la bibliothèque mysql_ de PHP 7+

  5. #65
    Membre chevronné
    Je veux peut être me faire lyncher, mais je profite de la discussion pour poser plusieurs question.

    Au final ça sert à quoi un pointeur en C/C++ ?
    Car le fond de l'article c'est quand même la gestion de la mémoire en C, qui est source d'erreur.

    Pour resituer mon contexte.
    J'ai fait de l'assembleur en autodidacte sur Amiga 500.
    Puis j'ai fait du C/C++ en BTS d'informatique de gestion sans voir les librairies utiles.
    Avoir fait de l'assembleur m'a bien aidé à comprendre certains concepts.
    Le prof nous avait dit le C est à la fois bas et au niveau d'accord.
    Mais bon je n'ai pas eu l'impression d'avoir fait du bas niveau.

    Pour la gestion de la mémoire je faisais des malloc et après je ne touchais plus à l'adresse.
    En assembleur je réservais des bloques mémoires et je me déplasssait dedans comme je voulais par octet pour faire des tableaux par exemple.
    Mais en C j'ai jamais eu à faire ça.
    D'ou ma question on fait quoi de plus avec un pointeur en C ?
    Pour cette utilisation il vaut mieux avoir un model managé comme en Java ou .net ça évite les erreurs.

    D'ailleurs c'est quoi les erreurs de programmation de pointeur en C c'est de confondre le * et le & ?
    De ne pas initialiser le pointeur ?
    Se tromper de type et de faire un débordement ?

    D'oublier de libérer la mémoire ?
    Pour ce qui est des fuites mémoires en Java le garbage colector c'est bien mais il ne fait pas tout quand même.

    Rust c'est quoi au final un C sans pointeur ?

    Si j'ai abandonné le C, c'est que je suis plutôt orienté informatique de gestion, et C c'est quand même orienté système.
    Je me suis réorienté vers Java aussi car le socle de base est plus complet.
    Le problème que j'avais avec C c'est que j'étais perdu pour choisir mes librairies et ne pas me tromper vis à vis des offres d'emplois.
    Consultez mes articles sur l'accessibilité numérique :

    Comment rendre son application SWING accessible aux non voyants
    Créer des applications web accessibles à tous

    YES WE CAN BLANCHE !!!

    Rappelez-vous que Google est le plus grand aveugle d'Internet...
    Plus c'est accessible pour nous, plus c'est accessible pour lui,
    et meilleur sera votre score de référencement !

  6. #66
    Expert éminent sénior
    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.(.../...)
    Je ne connais rien aux technos dont vous parlez ici(à part JS, dont je n'ai qu'une connaissance que très superficielle), mais ça, ça me parle beaucoup. La "meilleure solution" du point de vue purement technique peut être un piège mortel.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #67
    Expert éminent sénior
    Citation Envoyé par CoderInTheDark Voir le message
    Au final ça sert à quoi un pointeur en C/C++ ?
    Car le fond de l'article c'est quand même la gestion de la mémoire en C, qui est source d'erreur.
    En C, un pointeur ça sert a énormément de choses. Tellement que c'est difficile de toutes les citer. Parmi les plus courantes on a : gérer les tableaux, allouer de la mémoire, passer les arguments à une fonction, accéder directement à des périphériques mappés en mémoire,...

    Citation Envoyé par CoderInTheDark Voir le message
    Pour cette utilisation il vaut mieux avoir un modèle managé comme en Java ou .net ça évite les erreurs.
    En effet mais les environnements managés, ça a un coût, notamment en performance et en capacité d'accès au matériel à bas niveau.
    Donc le managé n'est pas vraiment utilisable pour la prog purement système comme un BIOS, des drivers matériel ou un OS. Et même pour les applications classiques qui requièrent rapidité et prédictibilité des performances, ça peut être un problème.

    Citation Envoyé par CoderInTheDark Voir le message
    D'ailleurs c'est quoi les erreurs de programmation de pointeur en C c'est de confondre le * et le & ?
    De ne pas initialiser le pointeur ?
    Se tromper de type et de faire un débordement ?
    D'oublier de libérer la mémoire ?
    Il y a plusieurs types d'erreurs mémoire, en général on considère que les erreurs de sécurité mémoire sont :
    • use after free : on utilise une zone mémoire qui a été libérée. Ce qui veux dire que si cette zone est réallouée on aura deux pointeur qui écriront des chose complètement différentes dans la même zone mémoire.
    • double free : on libère une zone mémoire déjà libérée ce qui peut provoquer des problèmes. Par exemple, si la zone avait été réallouée, on la libère par erreur et provoque un use after free.
    • data race : plusieurs threads modifient de manière non synchronisée la même zone mémoire.
    • mémoire non initialisée : donne accès a des valeurs qui devraient pas être accessibles
    • buffer overflow : un pointeur qui pointe a une adresse non allouée, généralement par dépassement de la taille d'un tableau, ce qui lui permet d'accéder et/ou modifier des variables auxquelles il ne devrait pas avoir accès.

    Oublier de libérer de la mémoire peut aussi être considéré comme une erreur de gestion de la mémoire, mais il ne s'agit pas d'un problème de sécurité : le programme va juste surconsommer de la mémoire.

    Citation Envoyé par CoderInTheDark Voir le message
    Rust c'est quoi au final un C sans pointeur ?
    Au contraire Rust utilise beaucoup les références (l’équivalent des pointeurs), mais le compilateur n'autorise pas à faire n'importe quoi avec. Dès la compilation il garantit que :
    • Chaque donnée en mémoire a une variable qui en est propriétaire et qui est la seule à pouvoir la libérer. Toute les références à cette donnée doivent être invalidées avant de pouvoir la libérer.
      Cela empêche les "use after free" et "double free".
    • Une donnée peut avoir, soit une seule référence qui permet de la modifier, soit plusieurs référence mais toutes en lecture seule.
      Cela empêche les data-races.
    • Les références (et plus généralement toutes les variables) doivent être initialisées avant toute utilisation.

    Pour prévenir les buffer overflow par contre, ça ne peut être fait qu'a l'exécution. Le code généré contrôle que les accès aux tableaux sont dans les limites, sauf si le compilateur peut prouver que le contrôle n'est pas nécessaire, par exemple dans le cas d'un accès au tableau par itérateur.

    Pour la libération de la mémoire Rust fournit plusieurs type d'outils pouvant aider (destructeurs, comptage de référence,...) mais il ne garantit pas l'absence de fuite mémoire.

  8. #68
    Expert confirmé
    Citation Envoyé par Uther Voir le message
    - Il ne peut y avoir qu'une seule référence qui peut modifier une même donnée, toute les autres doivent être en lecture, ce qui empêche les data-races.
    La contrainte est plus forte. Avec une référence en lecture et une en écriture, on peut avoir un data race si on essaie de lire une donnée qui est en train d'être modifiée.

    En Rust, le code suivant provoque une erreur de compilation :
    Code Rust :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    fn main() {
        let mut my_string = String::from("Hello, world");
        let mutable_ref = &mut my_string;
        let immutable_ref = &my_string;
        mutable_ref.push('!');
    }

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    error[E0502]: cannot borrow `my_string` as immutable because it is also borrowed as mutable
     --> src/main.rs:4:25
      |
    3 |     let mutable_ref = &mut my_string;
      |                       -------------- mutable borrow occurs here
    4 |     let immutable_ref = &my_string;
      |                         ^^^^^^^^^^ immutable borrow occurs here
    5 |     mutable_ref.push('!');
      |     ----------- mutable borrow later used here
    Le langage impose qu'il y ait soit une seule référence muable accessible, soit une ou plusieurs références accessibles mais toutes immuables. Dans mon exemple, let immutable_ref = &my_string; empêche d'utiliser par la suite mutable_ref.

  9. #69
    Expert éminent sénior
    Exact, j'avais un peu trop simplifié, j'ai corrigé.

  10. #70
    Membre expert
    Citation Envoyé par Guntha Voir le message
    L'avantage des créateurs de Rust, c'est qu'ils utilisent leur langage sur un vrai projet, et un gros!
    M'est avis que Mozilla s'est surtout posé les bonnes questions et a mûrement réfléchi à son "C-killer", ce qui donne quelque chose de bien conçu. Ils font ça comme il faut de A à Z et j'espère pour eux que ça va payer !

    De Go je me souviens que le langage était surtout présenté comme quelque chose "qui compile plus vite que C++". Mais au final ce n'est pas ça qui compte, le temps gagné par les développeurs pendant le développement n'étant rien face au temps gagné par les utilisateurs une fois en production.

    C existera encore et fera encore vivre des développeurs dans 100 ans. Mais est-ce que ça sera toujours un langage très utilisé ou bien un langage de niche parce que Rust aura pris sa place ? Mystère.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  11. #71
    Expert éminent sénior
    Citation Envoyé par wallas00 Voir le message
    Je n'aime pas les mots "applicatif" et "système", mon intuition me dit qu'ils ne permettent pas d'inférer clairement la définition que nous leur affectons.
    C'est vrai qu'il n'y a pas de définition officielle sur ce qu'est un langage système, ce qui a permis a Google de présenter Go comme un langage système, alors que tout le monde est aujourd'hui d'accord pour dire que ça n'en est pas.

    Ma définition, qui a le mérite d'être plutôt précise, c'est qu'un langage de programmation "système" est un lange qui permet de faire du code ayant accès direct au ressources sans passer par l’intermédiaire de l'OS (ring 0), ce qui implique qu'ils peuvent fonctionner même sans les fonctions les plus basiques d'un OS (allocation mémoire, fichiers, ...) et n'embarquent pas de Runtime conséquent.

    Ça n’empêche pas qu'il puisse aussi faire des applications classiques exécutées en tant que processus et supervisée par l'OS (ring 3).

    Citation Envoyé par wallas00 Voir le message

    - NPM est-il une "logiciel applicatif ou un logiciel système?"
    Pour moi ça ne fait aucun doute : NPM est applicatif, il est exécuté comme une application complétement classique, sans aucun impact sur l'OS

    Citation Envoyé par wallas00 Voir le message

    - Go est utilisé pour manipuler les espaces de noms Linux pour Docker, donc go est un langage....?
    Alors certes Docker peut avoir des impacts lourds sur le fonctionnement du système, mais techniquement il fonctionne comme toute les autres applications : toutes les manipulations techniques se font via les API de l'OS.
    Docker ne fait pas de Go un langage particulier. Il pourrait avoir être réalisé avec n'importe quel langage, du C au Python en passant par le VB.

    Citation Envoyé par wallas00 Voir le message

    Dans quelle catégorie de programme tu places les drivers qui décodent des protocoles réseaux et gères la communication avec des périphérique externes? J'en ai codé un en JAVA, un autre en C. Il existe une implémentation de MavLink en Go.
    Il faut faire la différence entre les drivers de l'OS qui sont chargés dans le noyau et ont accès direct aux ressources du système, et les "drivers" qui ne sont que l'implémentation d'un protocole au moyen des API système et qui sont chargés par des processus classiques.

    Citation Envoyé par wallas00 Voir le message

    Dans quelle catégorie places-tu les drivers de connexion aux bases de données?
    Les drivers de base de donnée ne sont pas branchés sur l'OS mais sur une application. Donc pas de besoin impératif d'un langage de prog système, même si c'est probablement souhaitable pour les performances.

    Citation Envoyé par wallas00 Voir le message
    Enfin, le Go "était" au départ destiné à la programmation système, et il l'est toujours. Il possède juste des attributs(Garbage Collector...) considérés comme discriminants, car dans "l’imaginaire collectif"(ou bien la réalité j'en sais rien - voir les questions en haut), langage de programmation système implique contrôle manuel de la mémoire et blablabla.
    Malgré d'indéniables qualités, le Go n'a jamais été prévu pour la programmation système. Google a admis que c'était une erreur de communication et ça fait longtemps qu'il ne le qualifie plus ainsi.

  12. #72
    Nouveau Candidat au Club
    je saigne des yeux....
    Franchement, j'ai pas grand-chose à dire sur le fond... mais sinon, mer@#, faîtes un effort d'écriture ou de traduction... c'est à peine lisible, rempli de fautes de syntaxe, grammaire, orthographe... C, Rust, Go... parlez d'abord correctement !

  13. #73
    Expert confirmé
    Citation Envoyé par louisleguignol Voir le message
    Franchement, j'ai pas grand-chose à dire sur le fond... mais sinon, mer@#, faîtes un effort d'écriture ou de traduction... c'est à peine lisible, rempli de fautes de syntaxe, grammaire, orthographe... C, Rust, Go... parlez d'abord correctement !
    "je n'ai pas grand-chose à dire"... parlez d'abord correctement !

  14. #74
    Expert éminent sénior
    Citation Envoyé par air-dex Voir le message
    M'est avis que Mozilla s'est surtout posé les bonnes questions et a mûrement réfléchi à son "C-killer", ce qui donne quelque chose de bien conçu. Ils font ça comme il faut de A à Z et j'espère pour eux que ça va payer !
    C'est vrai qu'il faut reconnaitre à Rust d'avoir pris le temps de peaufiner le langage pour qu'il corresponde complétement aux objectifs fixés, particulièrement l'aspect sécurité sans renoncer aux performance et au bas niveau.
    Ils ont essayé plusieurs solutions issues de langages purement académiques et n'ont pas hésité a en abandonner plusieurs qui se sont révélées inadaptées en route. J'avais découvert Rust à l'époque de la version 0.3 (qui n'avait déjà plus rien a voir avec les toutes premières versions) et les changement jusqu'à la version 1.0 ont été énormes, tant au niveau de la syntaxe qu'au niveau de certaines mécaniques essentielles.

    Citation Envoyé par air-dex Voir le message
    De Go je me souviens que le langage était surtout présenté comme quelque chose "qui compile plus vite que C++". Mais au final ce n'est pas ça qui compte, le temps gagné par les développeurs pendant le développement n'étant rien face au temps gagné par les utilisateurs une fois en production.
    Ça n'est pas négligeable non plus. Le temps de compilation est reconnu, de manière assez consensuelle, comme un des plus gros défauts du Rust. L'équipe du compilateur travaille beaucoup là dessus, mais c'est forcément plus compliqué avec un langage comme Rust qui a un typage avancé (génériques notamment), et beaucoup de contrôles fait à la compilation qu'avec un langage comme Go bâti pour la simplicité.

  15. #75
    Membre expert
    Citation Envoyé par Uther Voir le message
    Ça n'est pas négligeable non plus. Le temps de compilation est reconnu, de manière assez consensuelle, comme un des plus gros défauts du Rust. L'équipe du compilateur travaille beaucoup là dessus, mais c'est forcément plus compliqué avec un langage comme Rust qui a un typage avancé (génériques notamment), et beaucoup de contrôles fait à la compilation qu'avec un langage comme Go bâti pour la simplicité.
    Je pense aux règles de conception de Sid Meier. Il les a énoncé dans le cadre des jeux vidéo mais je pense qu'elles peuvent aller au delà. L'une d'entre elles dit que ce ne sont pas les développeurs qui doivent avoir le fun mais le joueur, donc l'utilisateur. Ce que je dis sur les temps rentre dans le cadre de cette règle, enfin je pense.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  16. #76
    Inactif  
    Rust et Samsung
    Samsung utilise RUST donc Lenovo aussi.

  17. #77
    Expert éminent sénior
    Citation Envoyé par air-dex Voir le message
    Je pense aux règles de conception de Sid Meier. Il les a énoncé dans le cadre des jeux vidéo mais je pense qu'elles peuvent aller au delà. L'une d'entre elles dit que ce ne sont pas les développeurs qui doivent avoir le fun mais le joueur, donc l'utilisateur. Ce que je dis sur les temps rentre dans le cadre de cette règle, enfin je pense.
    C'est marrant parce que c'est une vision complètement opposée à celle de Jonathan Blow, qui a créé le langage Jai justement pour que la programmation soit le plus agréable possible pour lui. Pour lui le plaisir du programmeur est indispensable à la production d'un bon jeu car un programmeur frustré est moins efficace.

    Bien qu'il en comprenne les avantages, Le Rust ne lui plaisait pas car les contraintes du langage (restriction sur les pointeurs, temps de compilation, ...) se mettaient en travers du plaisir qu'il avait à produire son code. Pour lui, ce n'est pas intéressant de s’embêter à garantir qu’il produit un code correct. Il aura juste à le déboguer quand les problèmes se poseront. Je trouve son argumentation partiellement valable. En effet, quand on a pris l'habitude de Rust, les contraintes imposées par le langage sont moins gênantes. De plus cette vision est limitée au domaine du jeux vidéo où l'on se soucie peu de la fiabilité et complètement de la sécurité.

  18. #78
    Membre éprouvé
    Citation Envoyé par air-dex Voir le message
    Je pense aux règles de conception de Sid Meier. Il les a énoncé dans le cadre des jeux vidéo mais je pense qu'elles peuvent aller au delà. L'une d'entre elles dit que ce ne sont pas les développeurs qui doivent avoir le fun mais le joueur, donc l'utilisateur. Ce que je dis sur les temps rentre dans le cadre de cette règle, enfin je pense.
    Il ne s'agit même pas de "fun" mais de productivité. On est beaucoup plus productifs quand le temps d'itération est court.

    Je me suis retrouvé sur plusieurs gros projets en C++ ou en C# où je devais bien réfléchir avant de faire la moindre modif parce que les temps de compil étaient rédhibitoires (même en incrémental), alors que sur un langage qui compile vite j'aurais pu utiliser ce temps pour tester des choses et débugger mes erreurs plusieurs fois, et donc rester concentré sur la tâche, sans interruption. Ça m'arrive même d'oublier ce que j'ai modifié une fois la compil terminée tellement c'est long :p

  19. #79
    Membre confirmé
    Citation Envoyé par louisleguignol Voir le message
    Franchement, j'ai pas grand-chose à dire sur le fond... mais sinon, mer@#, faîtes un effort d'écriture ou de traduction... c'est à peine lisible, rempli de fautes de syntaxe, grammaire, orthographe... C, Rust, Go... parlez d'abord correctement !
    Surveille ton langage

    oh oh oh

  20. #80
    Membre confirmé
    Ecosystème de rust
    Il y a beaucoup de chose qui marquent les différence de rust par rapport au langage existants, essentiellement la protection de la mémoire pour le multi-threading, mais en venant du java, il y a un autre élement qui m'a vraiment convaincu, c'est "cargo", un peut comme maven, mais pour un langage compilé.
    J'ai trouvé ça tellement mieux fait qu'en C, et tellement pratique aussi. J'ai pratiqué les tuto avec pas mal de facilité, beaucoup plus que mes début en C.

    Alors clairement Rust n'est pas un concurrent de Java, et je fais ça plus à titre récréatif, étant donné que mon métier est dans les SI, mais rendre un langage et son écosystème "mieux fichu" si je peux me permettre, ça va encourager son adhésion amha.

    Si je peux me permettre un parallèle vraiment "border-line", le JS lui-même a explosé avec ses framework au moment ou les écosytème reflétaient un ensemble logique: grunt+bower+npm, plus la base de code github hyper fournie.

###raw>template_hook.ano_emploi###