Discussion :

[Uther]

Sauf que le but de Boot2Gecko est de ne pas recourir au natif : les applications B2G seront entièrement des application HTML5 / Javascript. Dans ce contexte là, Rust n'a pas vraiment sa place dans un SDK B2G. Il irait à l'encontre des objectifs du projet.

Faire une environnement de Dev complet est certes indispensable, et la question se posera forcément un jour si le projet fonctionne. Mais quand on en est a travailler sur la spécification du langage, c'est mettre la charrue 100 kilomètres devant les bœufs.
Dans un premier temps, une bonne solution serait certainement de faire des wrapper avec une ou des API existantes comme Qt, wxWidget, ...

[_skip]

Faire une environnement de Dev complet est certes indispensable, et la question se posera forcément un jour si le projet fonctionne. Mais quand on en est a travailler sur la spécification du langage, c'est mettre la charrue 100 kilomètres devant les bœufs.
Dans un premier temps, une bonne solution serait certainement de faire des wrapper avec une ou des API existantes comme Qt, wxWidget, ...

Le problème c'est que c'est un tout. Un toolkit sérieux ça amène de l'intérêt, et donc des utilisateurs et donc des nouvelles libs (ce qui fait la richesse du langage en entreprise de nos jours). Le truc c'est que tant que ça reste dans un état notepad + compilateur en ligne de commande qui sert à faire des "hello world" et des "class Foo extends Bar" ça n'amènera que peu d'intérêt et c'est un cercle vicieux.

Si tu prends le cas de D, c'est un peu à mon impression ce qui s'y passe. Le langage est là, il est très bien, mais ça reste dans un état où personne ne veut s'y risquer. En dehors des problèmes de librairies standards qu'il y a eus, tu as plein d'IDE faits par des contributeurs, les 3/4 ont été abandonnés dans un état alpha ou pre-bêta car tout le monde semble y être allé de sa petite initiative et à tous il manque la même chose : un éditeur puissant avec un support débugger etc...
Donc pour moi, pas d'IDE et pas de bon support d'une techno GUI = projet mort né. Toutes les technos de qualité entreprise doivent avoir ça.

En revanche, mono a beaucoup mieux gérer ça: un ide de référence, un toolkit graphique (Gtk#), du coup forcément plus d'intérêt.

[MiaowZedong]

Sauf que le but de Boot2Gecko est de ne pas recourir au natif : les applications B2G seront entièrement des application HTML5 / Javascript. Dans ce contexte là, Rust n'a pas vraiment sa place dans un SDK B2G. Il irait à l'encontre des objectifs du projet.

Faire une environnement de Dev complet est certes indispensable, et la question se posera forcément un jour si le projet fonctionne. Mais quand on en est a travailler sur la spécification du langage, c'est mettre la charrue 100 kilomètres devant les bœufs.
Dans un premier temps, une bonne solution serait certainement de faire des wrapper avec une ou des API existantes comme Qt, wxWidget, ...

Sans vouloir t'offenser, je pense que ton raisonnement fait fi d'une des préconditions nécessaires à tout projet: répondre à un besoin.

Je te brusque un peu mais j'exagère à peine quand je dis que ton post peut se résumer à "de toute façon, on n'a pas besoin d'IDE puisque notre projet ne sert à rien". S'il n'y a de toutes façons aucune raison d'utiliser ce language, le projet reste purement académique et anecdotique, non?

En fait tes posts me donnent l'impression que le but est de créer un language de programmation pour créer un language de programmation

[Uther]

Le problème c'est que c'est un tout. Un toolkit sérieux ça amène de l'intérêt, et donc des utilisateurs et donc des nouvelles libs (ce qui fait la richesse du langage en entreprise de nos jours). Le truc c'est que tant que ça reste dans un état notepad + compilateur en ligne de commande qui sert à faire des "hello world" et des "class Foo extends Bar" ça n'amènera que peu d'intérêt et c'est un cercle vicieux.

Tout compilateur en passe forcément par là a un moment, il faut bien avoir un langage avant de faire son IDE et son API, sinon, on va dans le mur.

La situation de Rust n'est pas comparable avec D ou Go. Cette version 0.1 est juste un point sur le travail en cours, Mozilla contrairement a Google ayant fait le choix de ne pas cacher les développement en cours. Cette version a seulement pour but d'avoir des retours de la part de la communauté sur le langage lui même, pas de produire des applications, le projet n'en est pas encore à ce stade.
C'est pour ça qu'il s'agit uniquement d'un petit billet sur le blog d'un membre du projet, pas d'une communication officielle, l'équipe de Rust ne cherche pas encore des utilisateurs, juste des testeurs.

Si tu prends le cas de D, c'est un peu à mon impression ce qui s'y passe. Le langage est là, il est très bien, mais ça reste dans un état où personne ne veut s'y risquer. En dehors des problèmes de librairies standards qu'il y a eus, tu as plein d'IDE faits par des contributeurs, les 3/4 ont été abandonnés dans un état alpha ou pre-bêta car tout le monde semble y être allé de sa petite initiative et à tous il manque la même chose : un éditeur puissant avec un support débugger etc...
Donc pour moi, pas d'IDE et pas de bon support d'une techno GUI = projet mort né. Toutes les technos de qualité entreprise doivent avoir ça.

Au risque de me répéter, je suis d'accord qu'une API riche et un support d'un IDE est indispensable de nos jours si on veut se faire une place dans le développement applicatif. Mais avoir une spécification du langage à peu près stable est un minimum avant de se lancer la dedans.

Ensuite, il reste à se poser la question : comment on fait ça?
Solution 1 : On programme tout ça en Rust. Certes, ça fait une belle vitrine pour les possibilités du langage, mais ça peut prendre de très longues années avant d'avoir un environnement utilisable dont la qualité approche l'existant pour d'autres langages.
Vu que les moyens de l'équipe Rust sont limités, ça finirait probablement comme tous les outils pour D, dont tu parles.

Solution 2 : On adapte des outils préexistants comme (Eclipse, CodeBlocks, ...) et on fait des wrappers vers des API existantes (wxWidget, Gtk, Qt, ...), ce qui permettrait d’avoir rapidement un environnement fonctionnel.

Le compilateur étant basé sur LLVM, les gens qui font ça n'ont pas l'air de naïf qui pensent tout refaire de 0, et je suppose qu'ils partiront vers la seconde solution (du moins dans un premier temps)

Sans vouloir t'offenser, je pense que ton raisonnement fait fi d'une des préconditions nécessaires à tout projet: répondre à un besoin.

Au contraire, j'ai bien analysé les besoins auquel Rust répond : apporter plus de souplesse et de sécurité dans le développement d'applications ou de systèmes.
A terme il pourrait remplacer le C++ dans le code de Mozilla, ou de n'importe quelle application native. Il permettrait même de coder un OS.
Par contre il ne répond pas du tout aux besoins d'un SDK pour B2G, vu que le but de B2G est d'avoir uniquement des applications Web.

[Flaburgan]

Quand je vois les besoins auxquels Rust est sensé répondre, je pense à l'Ada...

[Gilliard]

Encore un langage nouveau, peut-être académiquement intéressant, mais qui ne me semble pas répondre à un besoin. Vieil informaticien nourri à l'Algol, Pascal(s) etc, puis ayant usé ses dents vieillissantes sur Java et C#, je me suis penché sur les "couples" HTML, PHP, et autres ASP.
Mais quelle horreur, c'est là qu'il faut INVENTER quelque chose. Ces imbrications entre langages de description (HTML, CSS, variantes-XML etc) et langages "d'action" (PHP, .NET, d'un côté, JavaScript de l'autre), sont affreusement lourdes, impossibles à tester statiquement (en tout cas pas autant qu'un C#). La preuve qu'il s'agit d'infâmes bricolages, c'est le nombre d'outils genre Joomla ou autres libres ou non qu'on a vu inonder le marché - avec le problème de trouver un hébergeur qui utilise justement le "truc" qu'on a choisi ... et d'être compatible avec tous les navigateurs: là est le vrai problème.
A quand mon application en Z# (Z = Le dernier langage à inventer) aussi facile à développer que du C# , intégrant les aspects présentation, serveur et client ? Bien sûr c'est ce que cherche plus ou moins à atteindre les implémentations de Microsoft avec les descriptions en XML, mais on est (à ma connaissance) loin d'une totale intégration: Le jour ou on l'atteindra, bien sûr, les Citrix et autres auront du soucis à se faire.
Ou bien, retraité que je suis, n'ai-je rien compris aux derniers développement de mon ex-métier ?

[_skip]

Encore un langage nouveau, peut-être académiquement intéressant, mais qui ne me semble pas répondre à un besoin.

Vous êtes nombreux ici à ne pas voir à quels besoins il pourrait répondre. De mon côté un langage à compilation AOT qui m'offre un compromis entre la vitesse du C/C++ et la productivité de java, c'est intéressant.

J'ai souvent dans ma branche des projets ayant des exigences en performances/mémoire élevées que java peine à satisfaire (en cause les nombreuses vérifications du compilateur, l'auto boxing, le GC etc..), mais dont la réalisation en C/C++ est très pénible.

S'il y avait un compromis entre la sécurité, l'homogénéité et la productivité offerte par java et la vitesse du code natif, franchement je serai enchanté d'en profiter.

Mais quelle horreur, c'est là qu'il faut INVENTER quelque chose. Ces imbrications entre langages de description (HTML, CSS, variantes-XML etc) et langages "d'action" (PHP, .NET, d'un côté, JavaScript de l'autre), sont affreusement lourdes, impossibles à tester statiquement (en tout cas pas autant qu'un C#). La preuve qu'il s'agit d'infâmes bricolages, c'est le nombre d'outils genre Joomla ou autres libres ou non qu'on a vu inonder le marché - avec le problème de trouver un hébergeur qui utilise justement le "truc" qu'on a choisi ... et d'être compatible avec tous les navigateurs: là est le vrai problème.

Là tu me fais plaisir! J'ai d'ailleurs été très critique quant à l'arrivée de html5 sur ce forum ce qui m'a valu bien des votes négatifs. Pour moi continuer sur cette base html/css/javascript c'est bétonner sur des sables mouvants. On a le javascript qui était chouette pour faire des petits bricolages DOM à son époque et on essaie d'en faire tout et surtout n'importe quoi en empilant les spécifications sans se poser la question si c'est vraiment la bonne solution pour de la RIA et du code métier.

[Gilliard]

J'ai souvent dans ma branche des projets ayant des exigences en performances/mémoire élevées que java peine à satisfaire (en cause les nombreuses vérifications du compilateur, l'auto boxing, le GC etc..), mais dont la réalisation en C/C++ est très pénible.

S'il y avait un compromis entre la sécurité, l'homogénéité et la productivité offerte par java et la vitesse du code natif, franchement je serai enchanté d'en profiter.

D'accord. Mais n'est-ce pas une question d'implémentation du langage, (compilation totale ou via une machine virtuelle) et du niveau de test à l'exécution que l'on va laisser dans l'appli finale ? On pourrait compiler du C# pour obtenir du langage machine (donc non portable) comme on le fait pour C/C++ (et bien d'autres), et permettre d'activer ou non les tests à l'exécution. (p.ex. débordement d'array). Le "Pascal" sous OpenVMS de Digital Equipement à l'époque permettait une foule d'options de ce genre: On optimisait seulement une fois qu'on avait confiance dans l'appli.
Mais il y a aussi un autre aspect: bien des programmeurs aujourd'hui ne "sentent" plus (ou simplement ne savent pas) ce que fait la machine: J'ai vu des gens faire des images comme des tableaux de 2000x2000 objets pixels, chaque pixels contenant deux objets. Ou bien les gens qui vous font des "new Machin(...)" a tout bout de champs, alors qu'ils abandonnent à chaque fois le précédent objet.
Bref, même (à mon avis surtout) en C++ on peut écrire du code inefficace !

[_skip]

D'accord. Mais n'est-ce pas une question d'implémentation du langage, (compilation totale ou via une machine virtuelle) et du niveau de test à l'exécution que l'on va laisser dans l'appli finale ? On pourrait compiler du C# pour obtenir du langage machine (donc non portable) comme on le fait pour C/C++ (et bien d'autres), et permettre d'activer ou non les tests à l'exécution. (p.ex. débordement d'array). Le "Pascal" sous OpenVMS de Digital Equipement à l'époque permettait une foule d'options de ce genre: On optimisait seulement une fois qu'on avait confiance dans l'appli.

C'est exactement comme tu dis, un langage avec une bonne librairie, pas trop bordélique et qui laisse une porte ouverte à ceux qui veulent rechercher la vitesse (suppression des checks runtime, utilisation ou non du garbage collector) en sacrifiant un peu de sécurité dans les sections du code où la vitesse est critique.
C'est ce qu'il me faudrait et ça pourrait tout à fait avoir une base existante, l'important serait de pouvoir, nous développeur, choisir notre propre compromis.

Mais il y a aussi un autre aspect: bien des programmeurs aujourd'hui ne "sentent" plus (ou simplement ne savent pas) ce que fait la machine: J'ai vu des gens faire des images comme des tableaux de 2000x2000 objets pixels, chaque pixels contenant deux objets. Ou bien les gens qui vous font des "new Machin(...)" a tout bout de champs, alors qu'ils abandonnent à chaque fois le précédent objet.
Bref, même (à mon avis surtout) en C++ on peut écrire du code inefficace !

Oui ben on peut louper son steack avec les meilleures casseroles du monde.

[Hinault Romaric]

Rust 0.2 disponible : la nouvelle version du langage de Mozilla supporte FreeBSD
et apporte de nouvelles fonctions

Mise à jour du 18/04/2012


Juste quelques mois après la publication de la version 0.1 de Rust et de ses premiers outils de développement, Mozilla fait encore évoluer son langage de programmation.

La communauté en charge du développement de Rust vient d’annoncer la publication de la version 0.2 et de son compilateur qui intègre plus de 1500 changements.

Avec cette version, Mozilla met à la disposition des développeurs un nouveau port des outils de Rust pour les systèmes FreeBSD 64 bits.

Cette mise à jour apporte des améliorations de performances pour le compilateur, la transmission de messages et introduit un ordonnanceur explicite. Les fonctions C-callback, les boucles infinies et les caractéristiques expérimentales comme les classes, les surcharges des opérateurs et les pointeurs ont subi également quelques modifications.

Pour rappel, Rust met beaucoup l’accent sur la sécurité par rapport à la performance. L'objectif de Mozilla est de "concevoir et implémenter un langage orienté objet statique, typé, sûr, concurrentiel et efficace".

Rust 0.2 est considéré comme une version Alpha et vise principalement les early adopters. Il est disponible sous une licence open source MIT pour Linux, Windows, Mac OSX et FreeBSD.

Télécharger RUST 0.2

[Uther]

Pour rappel, Rust met beaucoup l’accent sur la sécurité par rapport à la performance. L'objectif de Mozilla est de "concevoir et implémenter un langage orienté objet statique, typé, sûr, concurrentiel et efficace".

L'objectif de Rust n'est pas de sacrifier les performance à la sécurité. Les accès bas niveau sont permis, ils sont juste encadrés pour pousser à les utiliser avec prudence.

Rust n'est pas un langage principalement orienté objet, je dirais même que son support de l'objet est assez limité pour l'instant, il serait plus juste de dire qu'il est multi-paradigme.
Comme le dit son site officiel :

It supports a mixture of imperative procedural, concurrent actor, object-oriented and pure functional styles. Rust also supports generic programming and metaprogramming, in both static and dynamic styles.

[Hinault Romaric]

Rust 0.3 disponible : le langage de Mozilla dérivé du C/C++
gagne en maturité avec 1900 changements

Mise à jour du 13/07/2012


Rust le langage de développement de la fondation Mozilla évolue rapidement et atteint sa version 0.3.

Pour rappel, Rust a été développé comme une alternative aux langages C et C++, et reprend une grande partie de la syntaxe de ceux-ci, avec un point d’honneur accordé à la sécurité par rapport à la performance. L'objectif de Mozilla est de "concevoir et implémenter un langage orienté objet statique, typé, sûr, concurrentiel et efficace".

La version 0.3 de Rust apporte 1900 changements par rapport à la version 0.2 qui avait été publiée en avril dernier, dont un nettoyage sémantique du langage, l’amélioration de l’expérience utilisateur lors du codage, de nouvelles caractéristiques linguistiques encore en phase expérimentale et la suppression de certaines fonctions obsolètes.

Le nombre de types supporté par le langage évolue avec des nouvelles fonctions de temps. Rust dispose désormais des extensions de syntaxe pour la création des chaines à partir des expressions, et est même capable d’utiliser le contenu d’un fichier comme une expression Rust.

De nouvelles fonctionnalités expérimentales dont le support de nouveaux types de vecteurs ont été ajoutées. La prise en charge du shebang (#! - Indicateur en entête d’un fichier sous Unix, pour spécifier au système que ce fichier est un script, tout en fournissant le nom de l'interpréteur) permet désormais de définir des scripts Rust.

Rust 0.3 offre également un contrôle plus granulaire sur les avertissements et les erreurs générées par le compilateur.

Rust 0.3 est considéré comme une version Alpha et vise principalement les early adopters. Il est disponible sous une licence open source MIT pour Linux, Windows, Mac OSX et FreeBSD. Rust a été utilisé par Mozilla pour développer le moteur de rendu expérimental pour navigateur Servo.

Télécharger Rust 0.3

Source : Notes de version

[xetqL]

Encore un langage qui vient s'ajouter à la panoplie que l'on possède déjà ...
Je n'ai pas tous lu, mais qu'apporte-t-il de plus ?
Certes j'y vois une synthèse de plusieurs langage (on peut distinguer une philosophie plus Python, une syntaxe C...) mais est-il vraiment plus approprié d'utiliser un langage comme celui ci ? J'en doute..

Wait & see ...

[Uther]

Tu auras la réponse a la plupart de tes question là:
- https://github.com/mozilla/rust/wiki/Doc-project-FAQ
- https://github.com/mozilla/rust/wiki/Doc-language-FAQ

C'est difficile de donner un avis définitif sur le langage alors que la syntaxe et les fonctionnalités de base continuent d'évoluer lourdement.
Le langage me semble avoir un réel intérêt. Il me semble clairement plus tourné vers la sécurité que le D ou le Go, et plus vers les performances que l'ADA.

[abriotde]

Il est vrai qu'entre le Google Go et le Rust les différences me semblent mineures. Cependant il est certain que l'on a besoin d'un langage plus puissant et souple que le C/C++ (Plus rapide à compiler et interpréter aussi).

Pour moi le Go est meilleurs parce que Google à son habitude cherche l'hyper-optimisation. Or c'est là-dessus qu'on l'attend. La langage de la souplesse moderne est certainement un Python.

[codeallergy]

Tu auras la réponse a la plupart de tes question là:
- https://github.com/mozilla/rust/wiki/Doc-project-FAQ
- https://github.com/mozilla/rust/wiki/Doc-language-FAQ

C'est difficile de donner un avis définitif sur le langage alors que la syntaxe et les fonctionnalités de base continuent d'évoluer lourdement.
Le langage me semble avoir un réel intérêt. Il me semble clairement plus tourné vers la sécurité que le D ou le Go, et plus vers les performances que l'ADA.

Ada (et non ADA) a rien a envier au C ou Fortran.

[gangsoleil]

J'ai l'impression que ce qu'ils veulent faire, c'est du C (ou du C++) pour les nuls

C'est a dire que tu as de la gestion memoire, mais on verifie le truc parce que vraiment les dev ils font n'importe quoi. Et puis pareil avec le reste.

M'est avis que c'est trop bas niveau pour le dev haut-niveau, et pas assez permissif pour le dev bas-niveau. Donc que ca restera un langage de plus dans la mer des langages tres peu utilises.

[Firwen]

J'ai l'impression que ce qu'ils veulent faire, c'est du C (ou du C++) pour les nuls

C'est a dire que tu as de la gestion memoire, mais on verifie le truc parce que vraiment les dev ils font n'importe quoi. Et puis pareil avec le reste.

M'est avis que c'est trop bas niveau pour le dev haut-niveau, et pas assez permissif pour le dev bas-niveau. Donc que ca restera un langage de plus dans la mer des langages tres peu utilises.

Pas vraiment, non.
La syntaxe est basé sur OCaml, c'est à dire un des langages les plus concis qui existe et des plus haut niveau qui existe ( le ML pour "meta-langage" n'est pas là pour décorer ).
OCaml comme Rust propose l'heritage structurel, le pattern matching, l'inférence des types et une VRAI généricité qui sont des fonctionnalités de très haut niveau.

Je pense au contraire qu'ils essaient de faire du Ocaml avec un typage un peu moins nazi / un peu plus permissif : le support du polymorphisme et la surcharge vont dans ce sens.
Et au passage avec une VRAI gestion de la programmation concurrente ( ce qui est le talon d’Achille d'OCaml ).

Il y a de forte chance qu'il y ait un marché pour ce langage ou un langage du même type, des tas de projets d'envergure ont besoin d'un langage compilé qui fournit une approche pragmatique entre sécurité et performance.

[Uther]

J'ai l'impression que ce qu'ils veulent faire, c'est du C (ou du C++) pour les nuls

C'est a dire que tu as de la gestion memoire, mais on verifie le truc parce que vraiment les dev ils font n'importe quoi. Et puis pareil avec le reste.

En effet les développeur C et C++ font n'importe quoi car ces langages font qu'il est très facile de faire des bêtises sans s'en rendre compte.
Et même les meilleurs peuvent se faire avoir.

M'est avis que c'est trop bas niveau pour le dev haut-niveau, et pas assez permissif pour le dev bas-niveau. Donc que ca restera un langage de plus dans la mer des langages tres peu utilises.

J'ai du mal à voir en quoi le langage serait pas assez permissif. A priori, tout est réalisable avec seulement la contrainte de devoir utiliser des blocs "unsafe" si on veut briser les contrôles de sécurité en connaissance de cause.

Pas vraiment, non.
La syntaxe est basé sur OCaml, c'est à dire un des langages les plus concis qui existe et des plus haut niveau qui existe ( le ML pour "meta-langage" n'est pas là pour décorer ).
OCaml comme Rust propose l'heritage structurel, le pattern matching, l'inférence des types et une VRAI généricité qui sont des fonctionnalités de très haut niveau.

Je dirais que Rust comme C++ est à la fois de haut et bas niveau car il offre clairement les fonctionnalités que tu as cités mais permet un accès direct au ressources du systèmes et reste orienté performances.

[_skip]

Laisser le pilote automatique s'occuper des trucs généraux et garder la possibilité de prendre le contrôle manuel lorsque les performances doivent vraiment primer sur le reste.

Je trouve que ça correspond bien à la phrase qui dit que bien souvent, seul un faible pourcentage du code est réellement significatif pour les performances alors que le reste (GUI, configuration) tend à privilégier la sécurité et la lisibilité du code.

Si on compte qu'utiliser du code C dans un programme .Net, python ou Java a souvent quelques inconvénients, notamment de conversion de type, ne serait-il pas super d'avoir tout en un et même langage?