La Fondation Mozilla publie Rust 0.1

[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]

Envoyé par Uther

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]

Envoyé par 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, ...

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]

Envoyé par _skip

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.

Envoyé par _skip

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)

Envoyé par _MiaowZedong

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]

Envoyé par Gilliard

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]

Envoyé par Gilliard

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]

Envoyé par Hinault Romaric

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.