Discussion :

[Neckara]

Code :

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

fn main() { println!("Hello, world!"); }

Dans le playground de Rust, ça fonctionne.
Je ne vois pas bien le mix avec Python du coup.

De tête:

Code :

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

1
2
3
if a == 45 {
    //...
}

[yahiko]

De tête:

Code :

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

1
2
3
if a == 45 {
    //...
}

Les parenthèses sont facultatives. Ca n'empêche pas le compilateur de compiler puisque avec des parenthèses ça reste une expression.
Il semble que tu peux désactiver le warning sur les parenthèses du if si tu veux conserver le style C/C++/JS/Java

[tom_bdp]

Tu vas me dire quels sont les besoins tellement différents entre e.g. un IPhone, un Androïd, et un Window Phone ? Tu vas me dire en quoi ce sont des "secteurs d'activités" tellement différents ?

Pour Android par exemple tu as une variété incroyable d'appareils, et certains appareils low-cost, donc a priori peu puissants, pourraient par contre être accessibles a des marchés très importants comme les marchés émergents par exemple.

Si avec un langage bas-niveau comme Rust tu peux réaliser un certain nombre d'optimisations de performance qui te permettent de bien fonctionner sur ces appareils low-cost, tu élargis ton marché / ta base de clients. Peut-être plus facile d'optimiser au niveau performances avec Rust qu'avec Javascript par exemple.

[Neckara]

Peut-être plus facile d'optimiser au niveau performances avec Rust qu'avec Javascript par exemple.

Non mais le JavaScript, c'est un langage de merde je l'ai toujours dit.

La seule raison pour laquelle je l'utilise, c'est que je suis dans un environnement Web. .

[Invité]

Pour Android par exemple tu as une variété incroyable d'appareils, et certains appareils low-cost, donc a priori peu puissants, pourraient par contre être accessibles a des marchés très importants comme les marchés émergents par exemple.

Si avec un langage bas-niveau comme Rust tu peux réaliser un certain nombre d'optimisations de performance qui te permettent de bien fonctionner sur ces appareils low-cost, tu élargis ton marché / ta base de clients. Peut-être plus facile d'optimiser au niveau performances avec Rust qu'avec Javascript par exemple.

C'est déjà possible depuis longtemps : tu peux coder en C++ avec le NDK. Maintenant, c'est peut-être pas ça le problème mais plutôt que certaines applications sont codées quick & dirty.

[tom_bdp]

Personnellement j'avoue que ce qui m'a intéressé dans le titre de l'article c'est autant le mot "Rust" que l'aspect contribution au noyau Linux, et aux projets open-source en général.

J'ai lu récemment (enfin seulement en partie ) un excellent livre a ce sujet, "Producing open source software" de Karl Fogel, qui a notamment contribué au projet Subversion, et il y a un autre livre sur le sujet que je souhaiterais lire prochainement, "Open source for business" de Heather Meeker.

C'est assez difficile je crois de travailler dans l'open-source, notamment de faire le lien entre le travail open-source et le travail en entreprise, mais si les méthodes de travail open-source sont comprises et contrôlées en entreprise cela pourrait aussi être un formidable levier de performance.

Et c'est à mon sens un des attraits principaux de Rust aujourd'hui, le côté innovant qui pourrait intéresser des programmeurs plus jeunes à participer au mouvement Linux et /ou open-source .

- Edit: peut-être que je pourrais développer un peu plus:

• Concernant Rust : comme le langage est actuellement connoté programmation système et open-source, cela pourrait devenir une référence aussi par exemple pour une recherche d'emploi dans ce secteur (alors que des offres sur des langages plus "généralistes" comme le C ou le C++ induisent un risque supplémentaire pour le chercheur d'emploi de se trouver a faire du C ou du C++ pour du front-end / une application graphique par exemple, alors qu'il recherchait quelque chose dans la programmation système, en tous cas plus proche du back-end).
• Concernant la programmation open-source en entreprise : bien qu'actuellement en activité dans la programmation informatique, j'ai aussi suivi quelques cours de comptabilité et de droit il y a quelques années de cela : et ce qui manque aussi actuellement au mouvement open-source selon moi (ou bien je ne suis juste pas au courant que cela existe déjà : comment concilier une activité professionnelle / un emploi et une activité open-source, de façon a ce qu'il y ait éventuellement une synergie entre ces 2 activités : par exemple l'hypothèse suivante, 3 salariés, dans 3 entreprises différentes, dans le secteur de la banque ou des assurances par exemple, souhaitent construire quelque chose en Rust sur base du noyau Linux. La surcouche Rust pourrait par exemple servir à créer une nouvelle distribution Android, avec des applications bénéfiques pour le Métier / la MOA: quelles sont les contrats / structures juridiques possibles ? Y a-t-il des écrits, sources d'information, livres sur ce sujet ? (on s'éloigne un peu du sujet désolé )

[codec_abc]

Et tu as des langages où tu peux choisir ou non t'utiliser un garbage collector...
Cela n'est donc pas un argument pour dire qu'il faut des langages différents pour des besoins différents, mais que les langages où on ne peut pas désactiver le garbage collecteur ne sont pas top...

C'est uniquement possible sur ceux qui ne sont pas dotés de GC de base (genre C/C++, Rust). Autrement si tu désactives le GC (et ce n'est pas toujours possible) sur les autres langages tu vas justes te retrouver avec des memory leaks de partout.
Faudra que tu m'expliques ce que tu fais dans le développement web alors. Parce que des langages ou tu peux désactiver le GC j'en connais pas des masses qui sont utilisés dans le dev Web.

Et bien évidemment, tu nous fais un réponse complètement à côté de la plaque. Le fait qu'il faille faire du JS n'est pas intrinsèque au langage, mais un choix arbitraire qui a été fait. Si demain on décidait d'utiliser un autre langage, ben ça sera cet autre langage qu'on utilisera.

Le WASM, peut être considéré comme un langage assembleur. Et pour des langages qui compilent vers le WASM... t'as LLVM et emscripten, t'en as une petite floppée. Sachant que là encore, ce n'est pas lié aux qualité du langage intrasèque, mais à des choix arbitraires qui ont fait qu'on a ajouté un langage donné à emscripten. Donc si demain un nouveau langage devient très bon... il est facile à parier qu'il sera ajouté à emscripten.

Donc encore un fois, cela n'est donc pas un argument pour dire qu'il faut des langages différents pour des besoins différents...

Le WASM ne peut pas être considéré comme du langage assembleur. Il est similaire sur la forme mais sur le fond il est différent. Il y a certaines restrictions (interdiction des goto arbitraires, vérification des arguments au runtime, etc...) qu'on ne retrouve pas pour de l'assembleur classique. En plus le WASM est jité.

Va donc devenir expert dans 7 langages différents en comprenant toutes leurs nuances, leurs bibliothèques principales... et on en reparle...
Derrière bien évidemment on rajoute HTML/CSS3, LaTeX, et SQL. Donc bien au moins 10 langages. Et tout en passant sans cesse de l'un à l'autre en fonction des besoins ><.

Personne ne te demande de devenir expert dans plein de langages. Tu n'as qu'à choisir un petit nombre (au hasard juste Js) et t'y tenir. Tu n'arriveras pas à me faire croire qu'une bonne maitrise de Js (et potentiellement HTML + CSS mais qui ne sont pas des langages de programmation) ne suffit plus pour trouver un travail. Si c'est le cas c'est soit que tu habites dans un trou pommé ou que tu n'arrives pas à décrocher un poste (et une remise en question serait la bienvenue)

Le mieux est l'ennemi du bien. On s'en fout d'avoir l'optimal, le tout est d'avoir quelque chose de bien.
Non, ça c'est une bêtise. Déjà un langage évolue et peut lui-même tester des choses.
Ensuite, il y a une différence entre tester une nouvelle chose, et utiliser cette nouvelle chose en production.

Car si la première peut se faire en se greffant sur un langage existant et attendre son implémentation dans le langage, le second conduit à une fragmentation non-productive.

Ce qui est valable pour toi ne l'est pas pour les autre. Je ne m'en fout pas de l'optimal. Je suis content que plein de langages aient été inventés pour éviter de rester coincés avec du Cobol ou de l'asm. Cela vaut aussi pour ceux qui n'existent pas encore mais qui viendront rendre mon travail plus agréable dans le futur. Et ce n'est pas toujours possible ni souhaitable de rajouter des concepts à un langage. Par exemple, c'est impossible de rétro-fiter le système d'ownership de Rust à C++.

Parce qu'il ne faut pas oublier que le but n'est pas d'atteindre le meilleurs langage, mais d'écrire des logiciels. De plus les processus de sélection "naturelle" ne conduire pas à la sélection du "meilleur" langage, c'est une mécompréhension des mécanismes de l'Évolution.

Ça sort d’où ce but ? C'est toi qui le défini pour tout le monde ? Ou alors tu parles uniquement pour un but professionnel? Mais alors les gens de l'INRIA qui développe des langages sont payés pour rien ? Mais alors Dennis Ritchie glandait quand il inventait le C ou là c'était justifié ?

Par exemple pour RUST, je trouve qu'il a fait une grosse bêtise en essayant de se démarquer ainsi des autres langages. Il aurait mieux fait soit de reprendre le formatage du C++ avec parenthèses/accolades, soit du Python avec juste des indentations, mais pas faire un mix choquant des deux.

Là on sent tout de suite que tu n'a pas testé le langage parce que si ce qui te choques le plus c'est les parenthèses optionnelles autour du if (autrement la syntaxe est très C++) c'est que tu n'as jamais fait de "combat" avec le borrow checker qui est la feature centrale de Rust. Autrement dit, tu formules une critique sans avoir testé ni même lu ce que Rust rend possible.

Il reprends le concept de macro qui ont été abandonnés en C++... Il aurait mieux faire de reprendre les fonctions inlines/constexpr, ainsi que d'avoir une prise en charge des variadics comme arguments de fonctions.

Les macros de Rust sont hygiéniques en Rust et beaucoup plus puissante qu'en C++. Les 2 ont rien à voir. Ensuite Rust a aussi l'équivalent des constexpr et d'autre features dans cette lignée sont prévu à l'horizon.

Le format des chaînes de caractère est bizarre, ils auraient mieux fait de reprendre celle du JS

Juste non en fait.

Bref, pour un nouveau langage issue de l'évolution, j'ai déjà quelques critiques à faire, sans même l'avoir encore touché en profondeur. Donc demain un nouveau langage Rust++ pourra apparaître corrigeant cela.

Sauf que c'est bien beau de voir l'évolution des langages... mais derrière faut aussi se rappeler qu'il faut coder avec...

Pour un nouveau langage tu as surtout pas pris le temps de tester et ça se voit au contenu de ce que tu post depuis le début. Respectes les autres (et toi par la même occasion) et essayes Rust (ou au moins documentes toi dessus) avant de sortir un florilège de posts vides de sens qui ne sont même pas lié au topic de base (à savoir l'intégration de Rust dans le Kernel Linux)

[Neckara]

Faudra que tu m'expliques ce que tu fais dans le développement web alors. Parce que des langages ou tu peux désactiver le GC j'en connais pas des masses qui sont utilisés dans le dev Web.

Cf empscripten

Le WASM ne peut pas être considéré comme du langage assembleur. Il est similaire sur la forme mais sur le fond il est différent. Il y a certaines restrictions (interdiction des goto arbitraires, vérification des arguments au runtime, etc...) qu'on ne retrouve pas pour de l'assembleur classique. En plus le WASM est jité.

Tous les langages assembleurs ont quelques différences entre eux... de là en justifier que WASM ne peut pas être considérer comme des langage assembleur, c'est abusif.

Le JIT, ne dépend pas du langage, mais de son "interprétation/utilisation", ce n'est donc pas un argument. Et si on veut aller par là, t'as des formes de "JIT" (si on voit ça de manière très large et abusif) qui sont fait directement sur le processeur avec du code "binaire" (l'ASM n'étant qu'une représentation du ce code binaire).

Personne ne te demande de devenir expert dans plein de langages. Tu n'as qu'à choisir un petit nombre (au hasard juste Js) et t'y tenir.

Mais bien sûr...

Et j'ignore 86% de la recherche actuelle parce que ce n'est pas dans mon langage.
Je vais aller loin ainsi...

Tu n'arriveras pas à me faire croire qu'une bonne maitrise de Js (et potentiellement HTML + CSS mais qui ne sont pas des langages de programmation) ne suffit plus pour trouver un travail. Si c'est le cas c'est soit que tu habites dans un trou pommé ou que tu n'arrives pas à décrocher un poste (et une remise en question serait la bienvenue)

Il n'est pas question de trouver du travail (merci ou passage pour ton hypothèse...), mais juste de travailler.

Quand j'ai des collègues qui ne jurent que par du R, d'autres, dans la même équipe/labo, voire dans un pays complètement différents ne jurent que par Matlab ,etc. etc. ben faut quand même que je puisse bosser avec eux...

Par exemple, c'est impossible de rétro-fiter le système d'ownership de Rust à C++.

Bah, c'est plus ou moins std::unique_ptr.

Ça sort d’où ce but ? C'est toi qui le défini pour tout le monde ? Ou alors tu parles uniquement pour un but professionnel?

... fin réfléchit juste 2 secondes...

La finalité des langages, c'est bien de pouvoir les utiliser...

C'est comme si tu t'amusais à créer des chaises sur lesquelles on ne peut pas s’asseoir, c'est complètement con (à part pour des finalités décoratives, mais dans ce cas c'est un élément de décoration plus qu'une chaise). Si tu t'amuses à créer une chaise, c'est bien derrière pour que des personnes puissent s'asseoir dessus.

Mais alors les gens de l'INRIA qui développe des langages sont payés pour rien ?

Cela dépend de ce qu'ils font exactement. Mais là on est dans des finalités de recherches pour des langages qui ne devraient pas sortir des laboratoires. C'est comme pour ton entreprise de chaises, elle peut avoir un bureau R&D, et tenter des choses, mais elle ne va pas sortir tous ses prototypes sur le marché (et heureusement).


Après, il faut garder une vision de finalité, de savoir pourquoi on fait les choses. Sinon c'est juste de la branlette intellectuelle entre soit.

Là on sent tout de suite que tu n'a pas testé le langage parce que si ce qui te choques le plus c'est les parenthèses optionnelles autour du if (autrement la syntaxe est très C++) c'est que tu n'as jamais fait de "combat" avec le borrow checker qui est la feature centrale de Rust. Autrement dit, tu formules une critique sans avoir testé ni même lu ce que Rust rend possible.

T'as des milliers de langages de programmations, encore heureux que je puisse juger des langages sans les avoir testés ou étudiés en profondeur !

Et ça sera pareil pour chaque projet qui devra décider du langage à utiliser. Il ne peuvent pas passer des mois à étudier chaque langages possibles.

Les macros de Rust sont hygiéniques en Rust et beaucoup plus puissante qu'en C++. Les 2 ont rien à voir.

Oui, et les macros en Rust ressemblent fortement à des fonctions inline...

Juste non en fait.

Si.

Pour un nouveau langage tu as surtout pas pris le temps de tester et ça se voit au contenu de ce que tu post depuis le début. Respectes les autres (et toi par la même occasion) et essayes Rust (ou au moins documentes toi dessus) avant de sortir un florilège de posts vides de sens [...]

[...] qui ne sont même pas lié au topic de base (à savoir l'intégration de Rust dans le Kernel Linux)

Parce que la fragmentation des langages n'est pas du tout lié au choix de pousser un nième nouveau langage ?

[Invité]

Et ce n'est pas toujours possible ni souhaitable de rajouter des concepts à un langage. Par exemple, c'est impossible de rétro-fiter le système d'ownership de Rust à C++.

Ce n'est vraiment pas le bon exemple car l'ownership de Rust vient justement du RAII de C++. Par contre, le borrowing ou les lifetimes explicites, ça oui, ça doit être compliqué à rajouter à C++.

Les macros de Rust sont hygiéniques en Rust et beaucoup plus puissante qu'en C++. Les 2 ont rien à voir.

Oui, les macros Rust sont beaucoup plus propres et puissantes. D'ailleurs les "macros" C/C++ ne sont pas vraiment des macros mais du preprocessing (elles génèrent du texte et non du code/ast).

[codec_abc]

Cf empscripten

La finalité des langages, c'est bien de pouvoir les utiliser...

C'est comme si tu t'amusais à créer des chaises sur lesquelles on ne peut pas s’asseoir, c'est complètement con (à part pour des finalités décoratives, mais dans ce cas c'est un élément de décoration plus qu'une chaise). Si tu t'amuses à créer une chaise, c'est bien derrière pour que des personnes puissent s'asseoir dessus.

Ton analogie avec les chaises est inexacte en plus d'être nul. Rust est utilisable et utilisé aujourd'hui. Donc si on reprend ton exemple, c'est une chaise sur laquelle on peut savoir. A titre d'exemple j'ai écrit ce message depuis Firefox qui est codé, en partie, en Rust.

Cela dépend de ce qu'ils font exactement. Mais là on est dans des finalités de recherches pour des langages qui ne devraient pas sortir des laboratoires. C'est comme pour ton entreprise de chaises, elle peut avoir un bureau R&D, et tenter des choses, mais elle ne va pas sortir tous ses prototypes sur le marché (et heureusement).

Ba non. Je vois pas le problème de les sortir. Justement, ça permet de les tester à plus grande échelle et de faire progresser l'état de l'art. Personne ne te force à les utiliser. Je sais pas d'où vient ton besoin de vouloir anéantir toute diversité. A ce moment là, pourquoi avoir plusieurs OS ? plusieurs fabricants de CPU/GPU ? Mais oui ne gardons que ce que notre grand leadeur Neckara a décidé. Le monde sera forcément meilleur.

Après, il faut garder une vision de finalité, de savoir pourquoi on fait les choses. Sinon c'est juste de la branlette intellectuelle entre soit.

Rust a pour but de faire un langage système qui protège des problèmes classique de sécurité. Ça me parait pas mal comme finalité. Et quant bien même, ça peut faire quoi si des langages sont inventés juste pour le plaisir ? Les gens ne devraient pas le faire parce que ça ne te plait pas ?

T'as des milliers de langages de programmations, encore heureux que je puisse juger des langages sans les avoir testés ou étudiés en profondeur !

Et ça sera pareil pour chaque projet qui devra décider du langage à utiliser. Il ne peuvent pas passer des mois à étudier chaque langages possibles.

On ne parle pas de l'étudier en détail. On parle de savoir dans les grandes lignes de quoi il s'agit. La tu as postés une demi-douzaine de messages tous hors sujet parce que tu n'as pas la moindre idée de quoi tu parles. Alors certes tu as le droit, mais bon niveau intervention pertinente on est à 0 depuis le début. Pour un type qui prône que tout doit avoir une finalité, je ne comprends pas ce qui te pousses à écrire plein de messages sur un sujet que tu ne maitrises pas. Ça fait très branlette intellectuelle et ça manque de finalité...

[Neckara]

Ton analogie avec les chaises est inexacte en plus d'être nul. Rust est utilisable et utilisé aujourd'hui.

...
Si t'es pas foutu de suivre une conversation aussi simple, on va pas aller bien loin...

Pour rappel, je répondais à ta question qui était "mais d'où sort ce but", qui faisait suite à mon affirmation qui disait que le but n'était pas d'arriver au "meilleur" langage, mais d'écrire des logiciels avec.

Je n'ai absolument pas affirmé que Rust n'était ni utilisable ni utilisé.

Ba non. Je vois pas le problème de les sortir. Justement, ça permet de les tester à plus grande échelle et de faire progresser l'état de l'art. Personne ne te force à les utiliser.

Ah mais bien sûr... et puis quand il te faudra se greffer aux travaux d'untel écrit en XYZ, personne me forcera à utiliser du XYZ... ben oui... personne ne me force à travailler aussi si tu veux aller par là...

En quand derrière une autre personne devra s'amuser à maintenir une application écrite dans ton super langage qui n'aura été utilisé que 3 mois le temps de l'étude, 20 ans après... il va s'amuser aussi...

Je sais pas d'où vient ton besoin de vouloir anéantir toute diversité.

Va faire la moindre chose sans aucun standard ou normes... tu vas voir comment tu vas t'amuser...

Ah c'est beau la diversité... aller tout le monde a ses propres ports USB-like propriétaires, qui ne sont pas tous compatibles entre eux, ce qui fait que ton super clavier à 130€ que t'as acheté, tu peux pas l'utiliser sur un autre ordinateur... Ah, quel monde de rêve, qu'est-ce que c'est beau la diversité.

Et puis chaque serveur aura son propre protocole HTTP... ah les navigateurs vont adorer ça... Qu'est-ce que ce sera beau de voir des sites planter parce qu'il n'est pas compatible avec le navigateur...

Qu'est-ce qu'il ne faut pas entendre...

A ce moment là, pourquoi avoir plusieurs OS ? plusieurs fabricants de CPU/GPU ?

Ouais, enfin t'es très content quand t'as des interfaces normées qui te permettent d'utiliser un CPU sur presque toutes les cartes-mères...

Mais oui ne gardons que ce que notre grand leadeur Neckara a décidé. Le monde sera forcément meilleur.

Vive la mauvaise foi...

Rust a pour but de faire un langage système qui protège des problèmes classique de sécurité. Ça me parait pas mal comme finalité.

... cf ma toute première remarque de ce post...

Et quant bien même, ça peut faire quoi si des langages sont inventés juste pour le plaisir ? Les gens ne devraient pas le faire parce que ça ne te plait pas ?

Ah bah oui.... et ton patron va être vachement content de ton application écrite avec ton propre langage pour ton plaisir... Et le jour ou tu quittes la boîte... personne sera capable de maintenir ton logiciel...

Non, c'est vrai qu'il n'y a déjà pas assez de quelques milliers de langages... faut en créer d'autres... Bah, pourquoi pas carrément tous créer sa propre langue tant qu'on y est ?
Ouais, ça serait trop cool, plutôt que de lire toutes les publications scientifiques en anglais, on pourrait apprendre une nouvelle langue à chaque fois qu'on souhaite lire le moindre article.


Et pour la R&D, vu qu'il était question spécifiquement de cela... ils vont être content de te voir créer des langages "juste pour le plaisir"...

On ne parle pas de l'étudier en détail. On parle de savoir dans les grandes lignes de quoi il s'agit. La tu as postés une demi-douzaine de messages tous hors sujet parce que tu n'as pas la moindre idée de quoi tu parles.

Ah bah on s'est bien trouvé alors...

Pour un type qui prône que tout doit avoir une finalité, je ne comprends pas ce qui te pousses à écrire plein de messages sur un sujet que tu ne maitrises pas. Ça fait très branlette intellectuelle et ça manque de finalité...

Je n'ai pas dit que tout devait avoir une finalité, c'est une déformation malhonnête de mes propos.

Et si, en effet, je ne maîtrise pas Rust, sur l'objet principal de ma critique, qui est la fragmentation des langages de programmations, je suis loin de "ne pas maîtriser", contrairement à d'autres...

[Gugelhupf]

Go est langage qui selon moi ne décollera jamais car il est trop focalisé sur un principe de « C haut niveau ». Il n'apporte rien de nouveau, il a un garbage collector, il n'a pas de généricité, il supporte les pointeurs void et sa gestion des erreurs est mal faite.

Vois-tu je pars du principe qu'un langage s'impose en fonction des projets dans lesquels on l'utilise. On ne compte plus les projets qui sont écrit en C aujourd'hui (Linux, PostgreSQL, SQLite, Redis, Wireshark etc). Je suis pro-Rust dans l'âme, mais on ne devrait pas dénigrer Golang pour autant, malgré ses défauts ça reste un langage facilement accessible, il possède une bonne librairie standard, offre des performances similaires à Java/C# sans pour autant consommer autant de mémoire, et il évolue*, c'est le langage qui a été choisit pour Docker, Kubernetes, et Terraform... ça viendra mais aujourd'hui pas grand monde utilise Rust dans de gros projets (à part Mozilla lui-même pour développer quelques modules de Firefox)

*: La généricité sera bientôt implémenté dans Golang.

[Invité]

Personnellement j'avoue que ce qui m'a intéressé dans le titre de l'article c'est autant le mot "Rust" que l'aspect contribution au noyau Linux, et aux projets open-source en général.

J'ai lu récemment (enfin seulement en partie ) un excellent livre a ce sujet, "Producing open source software" de Karl Fogel, qui a notamment contribué au projet Subversion, et il y a un autre livre sur le sujet que je souhaiterais lire prochainement, "Open source for business" de Heather Meeker.

C'est assez difficile je crois de travailler dans l'open-source, notamment de faire le lien entre le travail open-source et le travail en entreprise, mais si les méthodes de travail open-source sont comprises et contrôlées en entreprise cela pourrait aussi être un formidable levier de performance.

Et c'est à mon sens un des attraits principaux de Rust aujourd'hui, le côté innovant qui pourrait intéresser des programmeurs plus jeunes à participer au mouvement Linux et /ou open-source .

- Edit: peut-être que je pourrais développer un peu plus:
...

Je pense que tu devrais mettre à jour tes informations. Le côté open-source de Rust n'a rien de nouveau. Aujourd'hui la plupart des langages ont des spécifications ou implémentations open-source.
"Contribuer à des projets open-source" est extrèmement commun depuis au moins 10 ans, notamment grâce à github.
Quant à l'open-source en entreprise, je ne connais pas bien la situation en France mais il y a de nombreux business models, du GAFAM qui open-source des projets, à la fondation qui subventionne un projet sur la base de dons, en passant par les modèles "code gratuit / service payant", "édition communautaire / édition entreprise", ou tout simplement "entreprise qui utilise de l'open-source et redistribue ses améliorations".

[tom_bdp]

Quant à l'open-source en entreprise, je ne connais pas bien la situation en France mais il y a de nombreux business models, du GAFAM qui open-source des projets, à la fondation qui subventionne un projet sur la base de dons, en passant par les modèles "code gratuit / service payant", "édition communautaire / édition entreprise", ou tout simplement "entreprise qui utilise de l'open-source et redistribue ses améliorations".

Oui en effet "l'open-source en entreprise", je veux dire quand on ne travaille pas dans un GAFAM ni dans une fondation dont c'est l'objet / la raison d'être, ça m'intéresserait de trouver des informations a ce sujet.

Maintenant que je relis la table des matières du livre "Producing Open Source Software" (*), j'ai l'impression que beaucoup de mes questions trouveront réponses justement dans les chapitres que je n'ai pas (encore) lu ... (Chapitre 4 "Social and Political Infrastructure" et suivants)

https://producingoss.com/en/producingoss.html

[manu007]

Ce qui me chiffonne c'est qu'on en soit encore a travailler sur une idée de SO qui date des années 70, soit UNIX était un miracle, soit personne s'est vraiment creusé la tête a faire quelque chose de mieux.

[Invité]

...
https://producingoss.com/en/producingoss.html

Merci pour le lien, il a l'air intéressant. Concernant les modéles économiques, il y a une page wikipedia spécifique : https://en.wikipedia.org/wiki/Busine...ource_software

Ce qui me chiffonne c'est qu'on en soit encore a travailler sur une idée de SO qui date des années 70, soit UNIX était un miracle, soit personne s'est vraiment creusé la tête a faire quelque chose de mieux.

Pourquoi est-ce génant ? Il y a des problèmes particuliers qu'Unix pose ?

Et pour répondre à la question évidemment que d'autres personnes ont réfléchi à la question. Déjà, il y a eu des années de recherche avant Unix (Multics notamment) et de nombreuses alternatives (vms, plan9, dos...).

Ensuite, il faudrait préciser ce qu'on entend par Unix car Linux n'est pas Unix. Et les OS "Posix" ont bien évolué: schedulers, noyaux modulaires, micro-noyaux, pile TCP/IP, OS basés conteneurs (à la fedora silverblue)...

Enfin, il y a beaucoup d'autres vieilles idées "discutables" : l'architecture de CPU von neumann des années 40, les claviers à touches décalées hérités des machines à écrire du 19e siècle...

[Uther]

Tu vas me dire quels sont les besoins tellement différents entre e.g. un IPhone, un Androïd, et un Window Phone ? Tu vas me dire en quoi ce sont des "secteurs d'activités" tellement différents ?

Sauf que là c'est un peu hors sujet : on parle pas des langage préconisés par les propriétaires de plateforme mais dans le domaine de la prog d'un système d'exploitation, où il n'y a pas vraiment de société particulière qui pousse l'adoption de son langage maison. Le Rust propose une approche qui apporte vraiment quelque chose de nouveau a son domaine et pas juste une décoration de surface.

Et tu as des langages où tu peux choisir ou non t'utiliser un garbage collector...

Cela n'est donc pas un argument pour dire qu'il faut des langages différents pour des besoins différents, mais que les langages où on ne peut pas désactiver le garbage collecteur ne sont pas top...

Et si ces langages ne sont pas top c'est pour une bonne raison : on ne peut pas avoir le beurre et l'agent du beurre. Rust pendant sa phase de beta avait expérimenté le GC optionnel, ils ont abandonné l'idée car ça avait trop d'impacts pour un langage système. Pour qu'un GC soit pratique a utiliser, il faut qu'il soit bien intégré au langage, mais s'il est trop intégré au langage, il devient impossible de le désactiver sans lourd impacts.

Par exemple pour RUST, je trouve qu'il a fait une grosse bêtise en essayant de se démarquer ainsi des autres langages. Il aurait mieux fait soit de reprendre le formatage du C++ avec parenthèses/accolades, soit du Python avec juste des indentations, mais pas faire un mix choquant des deux.

Sauf que le choix de Rust est parfaitement raisonné.
Pourquoi on a besoin de parenthèse en C ? Pour délimiter la condition de l'action a réaliser. Car en C le bloc n'est pas obligatoire, ce qui nuit a la lisibilité et a causé pas mal de problème certains graves. D'ailleurs, quasiment toutes les guidelines préconisent d'utiliser systématiquement les accolades même si elles ne sont pas nécessaire.
Rust a fait le choix délibéré de rendre les accolades obligatoires, ce qui rend les parenthèses superflues. Tu peux les mettre si tu veux mais c'est idiot de surcharger le code juste pour être visuellement ressemblant a un autre langage.

Il reprends le concept de macro qui ont été abandonnés en C++... Il aurait mieux faire de reprendre les fonctions inlines/constexpr, ainsi que d'avoir une prise en charge des variadics comme arguments de fonctions.

Les macro de Rust n'ont pas grand chose a voir avec les macros textuelles que C++ a hérité du C. Elles sont énormément plus propres (l'hygiène, manipulation de l'arbre syntaxique) et permettent des choses bien plus avancées qui ne sont pas possible avec des constexpr.
Les fonction inline existent en Rust. Les éléments const (équivalent Rust des constexpr) sont actuellement plus limitées, mais il y a un énorme travail dessus en cours. Ils devraient bientôt offrir les mêmes possibilités qu'en C++.

Sauf que c'est bien beau de voir l'évolution des langages... mais derrière faut aussi se rappeler qu'il faut coder avec...

Les critiques que tu donnes, c'est vraiment du détail. J'ai manipulé pas mal de langage et la syntaxe de surface c'est vraiment pas ça qui te fait perdre de l'efficacité, et c'est au final très vite assimilé. Je suis prêt à entendre des critiques sur la complexité des lifetimes ... qui sont un concept vraiment complexe a intégrer, mais la syntaxe de surface, c'est tout sauf un problème qui impacte sérieusement la productivité. Le temps que l'on passe a taper son code est négligeable comparé au temps que l'on passe a le lire, le penser et le déboguer.

Ce n'est vraiment pas le bon exemple car l'ownership de Rust vient justement du RAII de C++. Par contre, le borrowing ou les lifetimes explicites, ça oui, ça doit être compliqué à rajouter à C++.

Le principe du RAII vient en effet du C++, mais le système de ownership qui valide son bon usage à la compilation est une spécificité de Rust.
C++ a certes le principe du "move semantic", mais il doit être mis en place manuellement et ne fait effet qu'à l’exécution.

[Neckara]

Rust a fait le choix délibéré de rendre les accolades obligatoires, ce qui rend les parenthèses superflues. Tu peux les mettre si tu veux mais c'est idiot de surcharger le code juste pour être visuellement ressemblant a un autre langage.

Au contraire, le rendre visuellement ressemblant aux autres langages permet d'en faciliter la lecture sans nécessiter de temps d'adaptation.

Les parenthèses servent à repérer bien plus facilement le contenu des conditions, c'est une sorte de motif, qui nous permet de repérer les éléments bien plus facilement.

Les critiques que tu donnes, c'est vraiment du détail. J'ai manipulé pas mal de langage et la syntaxe de surface c'est vraiment pas ça qui te fait perdre de l'efficacité, et c'est au final très vite assimilé.

Sauf que lorsque tu vas choisir un langage parmi des milliers, la syntaxe de surface est ce que tu vas voir en premier et va être ton premier critère de pré-sélection. Tu regardes la gueule que ça a, et puis tu rentres plus en profondeur si t'as un bon feeling.

Par exemple, pour les macro, le "!" complexifie inutilement le code. Que ce soit pour la lecture, voire même pour l'apprentissage des langages. L'affichage est l'une des premières fonctions à utiliser, or, on ne va peut-être pas introduire aux étudiants la notion de macro tout de suite.

Cela risque plus de perturber certains étudiants qu'autre chose, pour un gain assez anecdotique.

[disedorgue]

J'ai une question au sujet de rust et de la main mise du C/C++ actuellement:

Imaginons que l'on développe un noyaux complet en rust, comment faire pour intégrer la logithèque gnu ou autre sans au moins une libc et ces headers qui vont avec ?
Car dans les faits, actuellement tout l'utilise (même rust ??? ).

[Invité]

Les critiques que tu donnes, c'est vraiment du détail. J'ai manipulé pas mal de langage et la syntaxe de surface c'est vraiment pas ça qui te fait perdre de l'efficacité, et c'est au final très vite assimilé. Je suis prêt à entendre des critiques sur la complexité des lifetimes ... qui sont un concept vraiment complexe a intégrer, mais la syntaxe de surface, c'est tout sauf un problème qui impacte sérieusement la productivité. Le temps que l'on passe a taper son code est négligeable comparé au temps que l'on passe a le lire, le penser et le déboguer.

Complètement d'accord.

Le principe du RAII vient en effet du C++, mais le système de ownership qui valide son bon usage à la compilation est une spécificité de Rust.
C++ a certes le principe du "move semantic", mais il doit être mis en place manuellement et ne fait effet qu'à l’exécution.

Non, je ne crois pas : le RAII avec la move semantic, c'est vérifié à la compilation. Ou alors on ne parle pas de la même chose.
Par contre on n'est d'accord que le modèle mémoire complet de Rust (ownership + borrowing + lifetime) est assez remarquable et spécifique à Rust (à ma connaissance du moins).

Imaginons que l'on développe un noyaux complet en rust, comment faire pour intégrer la logithèque gnu ou autre sans au moins une libc et ces headers qui vont avec ?
Car dans les faits, actuellement tout l'utilise (même rust ??? ).

Ca existe déjà un noyau en Rust : https://www.redox-os.org/
Pour les outils GNU, je pense qu'il serait justement intéressant de les recoder en Rust (si ce n'est pas déjà fait). Pour la libc, c'est effectivement une bonne question...

edit: pour la libc dans redox "Custom libc written in Rust (relibc)"