Sortie de Rust en version 0.3

Posté par claudex le 23 juillet 2012 à 13:20. Édité par Bruno Michel, Pierre Jarillon, tuiu pol, Florent Zara, Benoît, Benoît Sibaud, Nils Ratusznik et Xavier Teyssier. Modéré par Benoît Sibaud. Licence CC By‑SA.

Étiquettes :

juil.

2012

Rust est un langage développé par la fondation Mozilla qui implémente les paradigmes procédural, orienté objet, concurrent et fonctionnel. C'est un langage compilé plutôt orienté bas-niveau et qui concurrence le C ou le C++. Il est multiplates-formes et tourne sous Linux, Mac OS X et Windows. Pour rappel, Rust est un langage de programmation système fortement typé. L'accent est mis sur la sûreté des accès mémoire et la concurrence.

Vu les orientations de la fondation Mozilla, le but est de pouvoir développer un navigateur Web avec ce langage et les travaux ont déjà commencé, ce navigateur alternatif s'appelle Servo.

logo

Beaucoup d'exemples ci-dessous sont tirés de la documentation de Rust

Hello World!

Le traditionnel Hello World :

import io::println;

fn main() {
    println("Hello World !");
}

Définition de variable

Les variables peuvent être définies localement (avec le mot-clef let) ou globalement. Pour les variables locales, il est possible d'utiliser l'inférence de type. Par défaut les variables locales sont définies immutables mais cela peut être changé grâce au mot-clef mut :

use std;
const repeat: uint = 5u;
fn main() {
    let hi = "Hi!";
    let mut count = 0u;
    while count < repeat {
        io::println(hi);
        count += 1u;
    }
    let fl: float = 57.8;
}

Il est aussi possible de définir une assignation conditionnelle :

let x = if the_stars_align() { 4 }
        else if something_else() { 3 }
        else { 0 };

Les fonctions

Il est possible de définir des fonctions. Un point intéressant est que si vous définissez un type de retour de la fonction, le compilateur vérifiera que tous les chemins d'exécutions retourne bien un type. Une fonction sans type de retour est aussi possible, comme ci-dessus dans le Hello World.

Voici une fonction qui additionne deux entiers et qui renvoie le résultat :

fn add(x: int, y: int) -> int {
    ret x + y;
}

Il est aussi possible de définir des fonctions qui échouent tout le temps, ce sont des fonctions divergentes. L'intérêt est de pouvoir définir une fonction qui exécute une série d'instruction en cas d'erreur et de pouvoir l'utiliser dans une fonction qui a un type de retour sans que le compilateur râle.

fn my_err(s: str) -> ! {
    log(info, s);
    fail;
}

fn f(i: int) -> int {
   if i == 42 {
     ret 42;
   }
   else {
     my_err("Bad number!");
   }
}

Dans l'exemple ci-dessus le compilateur ne râlera pas même si la branche du else ne retourne aucun type. fail est utilisé en cas d'erreur et arrête l'exécution du programme.

Les boucles

Les boucles while sont très classiques :

while i < 10 {
    println("hello\n");
    i = i + 1;
}

Par contre, il existe un type de boucle infinie en utilisant le mot-clef loop, par exemple :

fn count() -> bool {
  let mut i = 0;
  loop {
    i += 1;
    if i == 20 { ret true; }
  }
}

Il existe aussi des boucles for qui sont moins traditionnelles car elle itèrent sur un vecteur ou une chaîne de caractères (semblable à ce qu'on trouve en Ruby ou Python par exemple) :

for 5.times {
    println("Here's some Rust!");
}

let v: ~[foo] = ~[a, b, c];

for v.each |e| {
    bar(e);
}

Les tâches

Rust utilise des tâches légères similaires à ce qu'on retrouve dans Erlang. Les tâches ne partagent pas de mémoire et la communication se fait par passage de message. Il est cependant possible de transmettre des données d'une tâche à l'autre via le tas d'échange, dans ce cas, la tâche qui donne les données ne peut plus y accéder.

Les pointeurs

Rust fonctionne comme le C/C++ pour l'allocation de mémoire, c'est-à-dire que si vous déclarez une variable, elle sera allouée sur la pile et si vous copiez un enregistrement, tout l'enregistrement est copié, pas uniquement le pointeur. Pour les petits enregistrement, c'est souvent plus performant mais ça peux poser des problèmes de performances si la quantité de données à copier est importante. Heureusement, il est quand même possible d'utiliser les pointeurs, il en existe de différents types :

Les boîtes partagées

Ce sont des pointeurs alloués sur le tas et gérés avec un ramasse-miettes, il s'écrivent avec un @. La copie d'une boîte partagée ne copie que le pointeur, pas les données :

let x: @int = @10; // Nouvelle boîte, le compteur de référence est à 1
let y = x; // Copie le pointeur, incrémente le compteur de référence
// Quand x et y sont hors de portée, le compteur de référence est à 0 et la boîte est libérée.

Les boîtes uniques

Ce sont des boîtes qui ne peuvent être référencées que par une seule variable. Grâce à cela, elles peuvent être allouées sur un tas d'échange commun à toutes les tâches et peuvent être échangées entre les tâches. Lors de cet échange, la tâche qui donne le pointeur abandonne sa possession de la boîte. À cause de leur unicité, la copie d'une boîte unique ne peut se faire qu'explicitement en copiant toutes les données :

let x = ~10;
let y = x; // erreur, copie implicite d'une boîte unique

let y = copy x; // copie d'une boîte unique

Il est possible de déplacer l’appartenance d'une boîte à l'aide de l'opérateur de déplacement ->, lors de cette opération, la boîte n'est plus accessible par la variable initiale.

let x = ~10;
let y <- x;

Les pointeurs empruntés

Ce sont l'équivalent des références en C++ mais avec la garantie de pointer vers une zone mémoire valide. Les pointeurs empruntés n'impliquent jamais la possession du pointeur comme c'est le cas avec les boîtes partagées. L'intérêt de ce type de pointeur est de pouvoir faire du passage d'argument par référence pour les pointeurs :

let foo = "foo";
work_with_foo_by_pointer(&foo);

Mutabilité

Comme pour les variables, il existe une version mutable pour les pointeurs, cela permet de modifier les données pointées en déférençant le pointeur.

fn increase_contents(pt: @mut int) {
    *pt += 1;
}

Aller plus loin

Site officiel (479 clics)
Notes de version (30 clics)
DLFP : Sortie de la version 0.1 de Rust (65 clics)

# explications?

Posté par octane le 23 juillet 2012 à 14:23. Évalué à 3.
```
let x = if the_stars_align() { 4 }
        else if something_else() { 3 }
        else { 0 };
```
Je trouve pas ça clair. Cela se produit à l'assignation uniquement ou la variable change dynamiquement à chaque appel?
- [^] # Re: explications?
  
  Posté par claudex le 23 juillet 2012 à 14:34. Évalué à 4.
  
  Si je comprend bien, c'est uniquement à l'assignation http://dl.rust-lang.org/doc/tutorial.html#expression-syntax
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: explications?
  
  Posté par LupusMic (site web personnel, Mastodon) le 23 juillet 2012 à 15:33. Évalué à 3.
  C'est vrai que ça manque de clarté par rapport à une version C++ :-D
```
auto x = the_stars_align() ? 4 : something_else() ? 3 : 0 ;
```
  - [^] # Re: explications?
    
    Posté par feth le 23 juillet 2012 à 16:14. Évalué à 3. Dernière modification le 23 juillet 2012 à 16:16.
    La bonne manière de faire, qu'on peut ainsi faire lire à un humain, même à un humain qui ne saurait pas quel langage de programmation est utilisé, même un humain qui saurait à peine programmer :
```
    if the_stars_align():
        x = 4
    elif something_else():
        x = 3
    else:
        x = 0
```
    Mais on peut toujours abuser du sucre syntaxique pour minimiser le nombre de lignes, si on veut faire le mal :
```
    x = (lambda : 4 if the_stars_align() else (3 if something_else() else 0))()
```
    Quelle horreur.
    - [^] # Re: explications?
      
      Posté par feth le 23 juillet 2012 à 19:14. Évalué à 6.
      
      (mais pourquoi ai-je mis cette lambda ?)
    - [^] # Re: explications?
      
      Posté par Enjolras le 23 juillet 2012 à 20:39. Évalué à 10.
      
      Ce n'est pas du sucre syntaxique. D'ailleurs, le but n'est pas de minimiser le nombre de ligne.
      
      Ce n'est pas du sucre syntaxique, parce que ce n'est pas la syntaxe qui change, mais la sémantique. En C/C++, la conditionnelle est une instruction.
      En Rust, la conditionnelle est une expression. Je ne vois pas en quoi c'est une expression plus complexe que (a && b) || ( x == 2).
      Vous allez dire qu'en pratique, ça ne change rien. Pourtant, si, ça change que les membres de la conditionnelle doivent s'évaluer vers un même type. L'avantage ? On est certain que x a une valeur, quelque soit la branche.
      
      Quant à parler de «Bonne façon» et de «mauvaise façon» il serait temps que les gens comprennent que leur manière de faire n'est pas une vérité unique et qu'il existe divers paradigmes de programmation : impératif et fonctionnel par exemple.
      - [^] # Re: explications?
        
        Posté par stopspam le 23 juillet 2012 à 21:46. Évalué à 2.
        
        Quant à parler de «Bonne façon» et de «mauvaise façon» il serait temps que les gens comprennent que leur manière de faire n'est pas une vérité unique et qu'il existe divers paradigmes de programmation : impératif et fonctionnel par exemple.
        
        C'est plus souvent une question de lisibilité, compréhension et courbe d'apprentissage du langage.
        Les gens ne pensent pas détenir l'unique vérité mais plutôt que leur code est meilleur sur l'un ou plusieurs des points ci-dessus.
        
        [^] # Re: explications?
        
        Posté par Enjolras le 23 juillet 2012 à 23:49. Évalué à 6.
        
        La lisibilité est subjective. Un programmeur ocaml va préférer
        
        let factorielle n = let tail_fact acc = function | 0 -> acc | k -> fact (k*acc) (k-1) in tail_fact n (n-1)
        
        et un programmeur C
        
        int factorielle(int n) { for (unsigned int i = (n-1); i > 0 ; --i) { n *=i; } return acc; }
        
        Y en a t'il vraiment un de plus lisible ?
        
        [^] # Re: explications?
        
        Posté par spider-mario le 24 juillet 2012 à 01:31. Évalué à 6.
        
        (Juste pour information.)
        
        Perl 6 :
        
        sub factorielle(Int $n) returns Int { return [*] 2 .. $n; }
        
        Haskell :
        
        factorielle n = product [2 .. n]
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 08:02. Évalué à 3.
        
        Ouai, la tu compares surtout les lib standards. Tout le monde sait que Haskell sait tout faire, mais product, c'est déjà factorielle.
        
        [^] # Re: explications?
        
        Posté par barmic le 24 juillet 2012 à 09:29. Évalué à 5.
        
        Je ne pense pas qu'il cherchait à comparer perl6 et haskel, juste à donner la solution en 2 autres langages que le C et Ocaml. D'ailleurs ce que l'on peut voir c'est que les versions C et Ocaml sont très simples dans un cas on fait une boucle dans l'autre une fonction récursive. C'est pour chacun d'eux une construction de base de leur paradigme respectif. La version perl6 utilise un mécanisme de réduction qui reste impératif (ça construit une liste et ça fait une réduction dessus, si je ne m'abuse) et haskel le gère via sa bibliothèque standard.
        
        Ces deux dernières versions sont particulièrement bien car non contente d'être plus courtes elles évite les bugs. La version c est particulièrement peu fiable : d'ailleurs il y a si je ne m'abuse 2 petites fautes dedans :
        
        return acc; devrait être return n; ça le compilateur le vois
        
        l'autre surviens quand on demande le factoriel de 0. Il itère alors sur 4294967295. Ça donne le bon résultat, mais c'est particulièrement lent (en rapport au calcul demandé). Oui un unsigned est rarement en dessous de 0.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 09:45. Évalué à 2. Dernière modification le 24 juillet 2012 à 09:48.
        
        Oui en effet, j'avais imaginé qu'on devait pas calculer factoriel de 0, mais bon sémantiquement c'est autorisé, ça fait 1.
        
        Pour les versions de perl6/haskell je dis juste que c'est pas une bonne manière de comparer la lisibilité de la syntaxe, parce que ça utilise des fonctions de lib standards. Après, on peut arguer du fait que la lib standard joue dans la lisibilité… Mais ton argument sur les bugs évités n'a pas de sens.
        
        Bien sûr qu'utiliser une fonction testée de la lib standard est plus safe… Mais ça n'augmente pas la lisibilité de la syntaxe.
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 09:54. Évalué à 1. Dernière modification le 24 juillet 2012 à 09:55.
        
        D'ailleurs, tu noteras que j'ai fait la même supposition pour le code ocaml. Si tu l'appelles avec 0, tu pars en récursivité infinie.
        
        Et les versions de spider-mario demandent n > 1 si je ne m'abuse.
        
        [^] # Re: explications?
        
        Posté par spider-mario le 25 juillet 2012 à 14:46. Évalué à 3.
        
        Non, ni la version Perl 6, ni la version Haskell ne le demande.
        
        En Perl 6 : le méta-opérateur de réduction, si la liste est vide, appelle l’opérateur sans paramètre, ce qui peut ou non être défini selon l’opérateur. Pour infix:<*>, c’est défini à 1 (alors que pour le modulo, par exemple, on obtiendrait une erreur ressemblant à « No zero-arg meaning for infix:<%> »).
        
        En Haskell, similairement, le cas particulier product [] vaut 1.
        
        [^] # Re: explications?
        
        Posté par Zylabon le 25 juillet 2012 à 17:43. Évalué à 1.
        
        Ces fonctions sont mal typées, la factorielle usuelle n'est définie que pour les entiers naturels.
        
        Please do not feed the trolls
        
        [^] # Re: explications?
        
        Posté par spider-mario le 26 juillet 2012 à 11:02. Évalué à 2.
        
        Cette contrainte est exprimable en Perl 6, même si elle ne sera généralement vérifiée qu’à l’exécution.
        
        subset Nat of Int where 0 .. *; sub factorielle(Nat $n) returns Nat {[*] 2 .. $n} say factorielle(5); # → 120 say factorielle(-2); # Constraint type check failed for parameter '$n' # in sub factorielle at factorielle.pl:3 # in block <anon> at factorielle.pl:6
        
        [^] # Re: explications?
        
        Posté par barmic le 26 juillet 2012 à 11:26. Évalué à 2.
        
        Au mon dieu, ce que perl6 donne envie ! :)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: explications?
        
        Posté par lendemain le 24 juillet 2012 à 14:36. Évalué à 3.
        
        Une factorielle parallèle en clojure:
        
        (defn fact [n] "factorielle parallèle traitant 20 multiplications par thread" (if (= 0N n) 1N (reduce #(* %1 %2) (map deref (map #(future (reduce * %)) (partition-all 20 (range 1N (+ n 1N)))))))) (fact 5000N)
        
        Une normale:
        
        (defn fact-a [n] (if (= 0N n) 1N (reduce * (range 1N (+ n 1N)))))
        
        [^] # Re: explications?
        
        Posté par khivapia le 24 juillet 2012 à 09:29. Évalué à 3.
        
        Euh mon OCaml date un peu, mais la factorielle ce ne serait pas plus simplement :
        
        let rec factorielle = function |0 -> 1 |n -> n * (factorielle (n-1) )
        
        (pas besoin de fonction imbriquée) ?
        
        [^] # Re: explications?
        
        Posté par Shuba le 24 juillet 2012 à 09:37. Évalué à 4.
        
        Tu n'as pas une version récursive terminale si tu fais ça, donc tu ne profiteras pas de l'optimisation d'appel récursif, et seras moins efficace qu'une boucle (alors que la version précédente est tout aussi efficace).
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 09:44. Évalué à 5.
        
        tu risque de faire rapidement un stackoverflow. Enfin, tu n'as pas tout à fait tort dans ce cas, parce que dans le cas de la factorielle, la profondeur d'appel est pas énorme, on tombe d'abord sur un int overflow, du coup le fait d'être récursif terminal n'est pas forcément primordial.
        
        [^] # Re: explications?
        
        Posté par khivapia le 24 juillet 2012 à 09:58. Évalué à 2.
        
        Oups oui bien sûr, merci à tous les deux.
        
        [^] # Re: explications?
        
        Posté par zebra3 le 24 juillet 2012 à 11:36. Évalué à 3.
        
        Bien sûr, celle-ci :
        
        def factorielle(n): if n == 1: return n else: return factorielle(n-1) * n
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 11:44. Évalué à -2.
        
        Trop bien, une fonction récursive en python ! T'as pas plus lent ?
        
        [^] # Re: explications?
        
        Posté par zebra3 le 24 juillet 2012 à 12:10. Évalué à 2.
        
        C'est quoi le rapport ? La question était :
        
        Y en a t'il vraiment un de plus lisible ?
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: explications?
        
        Posté par feth le 24 juillet 2012 à 13:58. Évalué à 2.
        
        Si c'est un problème, on la réécrira en Cython. Cela dit, la règle n°1 de l'optimisation, si ma mémoire est bonne, c'est "ne le fais pas".
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 14:03. Évalué à 2.
        
        Il y a une différence entre "optimisation qui fait gagner 1%" et "optimisation qui permet de renvoyer un résultat". La fonction n'est pas Récursive terminale, et de toute manière, python n'optimise pas les appels récursifs terminaux.
        
        J'admets que la factorielle est pas un bon exemple, à cause d'int overflow, mais mettons que ça soit des big int ou que tu veuilles la factorielle modulo MAX_INT.
        
        Ce code ne fonctionnera pas pour n assez grand. Stack overflow. Moi j'appelle pas ça une optimisation, mais du debug.
        
        En quoi ça un rapport avec la lisibilité ? Bah un code lisible qui ne marche pas, je n'en vois pas trop l'intérêt.
        
        [^] # Re: explications?
        
        Posté par feth le 24 juillet 2012 à 15:34. Évalué à 2.
        
        python n'optimise pas les appels récursifs terminaux.
        
        Python non, mais Cython si : c'est du cpp généré, appelé depuis Python, et la syntaxe d'écriture ressemble beaucoup à celle de Python, avec un typage facultatif : plus on spécifie de types, plus ça va vite. Il y a aussi des bibliothèques "toutes faites" pour le calcul ou le rendu graphique, et au final, dans le code applicatif, les portions de code qu'il reste à optimiser sont généralement assez petites.
        Je ne tiens pas à promouvoir Python par dessus tout, je suis certain que tous les bons langages+environnements de haut niveau proposent un excellent compromis entre l'ergonomie du langage, la richesse des bibliothèques et l'optimisation.
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 16:39. Évalué à 0.
        
        Là tu racontes des choses qui n'ont rien à voir. On ne parle pas de rendu graphique ou de bibliothèque, on parle de l'exemple, qui n'en utilise pas.
        je sais bien qu'ils y a d'autres implémentations de pythons, mais, il n'empêche que le code en lui même n'est même pas récursif terminal. On peut toujours espérer que le compilateur le fera, mais c'est pas garanti, même avec Cython.
        
        Sans compter que dépendre d'une implémentation pour le fonctionnement du programme, c'est pas bien :>.
        
        Donc au final, tu es en train de me dire que python est un bon langage en réponse à ma remarque sur le fait que l'exemple est un mauvais code. Je n'ai jamais dit le contraire. Tu appris mon "les fonctions récursives en python sont lentes" par un "python est lent", tu extrapoles un peu je trouve.
        
        [^] # Re: explications?
        
        Posté par zebra3 le 24 juillet 2012 à 16:48. Évalué à 1.
        
        Ben si tu voulais dire que l'exemple est un mauvais code, il fallait l'écrire directement.
        
        J'ai compris la même chose que lui. Quand tu écris :
        
        les fonctions récursives en python sont lentes
        
        C'est bel et bien une assertion générale, ça ne parle pas du code que j'ai écrit (qu'il soit bon ou non).
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 16:52. Évalué à 0. Dernière modification le 24 juillet 2012 à 16:53.
        
        Bah, oui, les fonctions récursives en python sont lentes. Donc ce code est lent. C'est pas la peine de faire un discours général sur le fait que python est pas lent…
        
        [^] # Re: explications?
        
        Posté par zebra3 le 24 juillet 2012 à 17:05. Évalué à 1.
        
        Si ce code est lent, c'est la faute de python et non de lui-même. Donc il n'est pas mauvais en soi.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 17:19. Évalué à 2.
        
        Vas dire ça à ton product manager :>
        
        [^] # Re: explications?
        
        Posté par barmic le 24 juillet 2012 à 16:57. Évalué à 2.
        
        J'admets que la factorielle est pas un bon exemple, à cause d'int overflow, mais mettons que ça soit des big int ou que tu veuilles la factorielle modulo MAX_INT.
        
        Si je me souviens bien CPython sabre au dessus d'une profondeur de 1000 appel récursif.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: explications?
        
        Posté par Enjolras le 24 juillet 2012 à 23:05. Évalué à 2.
        
        C'est bien le cas de python en tout cas :
        
        def sum(n): if n == 1: return 1 else: return sum(n-1) + n
        sum(998) 498501 sum(999) RuntimeError: maximum recursion depth exceeded in comparison
        
        Donc, encore une fois, j'appelle pas ça de l'optimisation.
        
        [^] # Re: explications?
        
        Posté par neil le 30 juillet 2012 à 21:31. Évalué à 1. Dernière modification le 30 juillet 2012 à 21:32.
        
        Ou alors sans ré-écrire en utilisant PyPy.
        
        % pypy sum.py
        498501
        499500
        
        Pour reprendre l’exemple ci-dessus.
        
        [^] # Re: explications?
        
        Posté par Antoine le 26 juillet 2012 à 18:22. Évalué à 2.
        
        Ou plutôt celle-ci :
        
        >>> from math import factorial >>>
        
        [^] # Re: explications?
        
        Posté par Zylabon le 24 juillet 2012 à 15:31. Évalué à 4.
        
        Sinon :
        
        int factorielle(int n){ return (n == 0) ? 1 : n * factorielle(n-1); }
        
        C'est la définition mathématique, et les compilo modernes savent faire tourner ça en espace constant (en tout cas clang et gcc).
        
        Please do not feed the trolls
        
        [^] # Re: explications?
        
        Posté par FantastIX le 24 juillet 2012 à 16:34. Évalué à 1.
        
        Ou encore
        
        unsigned factorielle(unsigned n) { return n > 2 ? n * factorielle(n-1) : (n >> 1) + 1; }
        
        Je pinaille, je sais.
        
        Mais bon, pour moi, lisible ou pas, on s'en moque un peu; il faut faire attention à ce qu'on écrit et à ce qu'on lit, C ou pas. Je préfère me servir du plein potentiel du langage, quitte à réduire la lisibilité du code. Pour le reste, il y a les commentaires…
        
        [^] # Re: explications?
        
        Posté par Antoine le 26 juillet 2012 à 18:17. Évalué à 2.
        
        Y en a t'il vraiment un de plus lisible ?
        
        Je ne sais pas, mais il y en au moins un des deux qui avale silencieusement les débordements arithmétiques (l'autre aussi peut-être, je ne sais pas :-)).
# avantage ?

Posté par Nicolas Boulay (site web personnel) le 23 juillet 2012 à 15:18. Évalué à 10.

J'ai du mal à voir l'intérêt d'un tel langage, il faudrait au moins parler de ce que cela apporte de plus à ce qui existe.

Si je compare avec ocaml, Rust ne parait pas terrible. Ocaml utilise un seul mot clef "let" pour les fonctions et les variables, cela allège la syntaxe. Les mutables avec mut semble plus léger que la version ocaml "let plop = Ref 10" qui utilise des opérateurs d'affectation différent.

La gestion par copie est horrible, on dirait revenir les horreurs de java sur le mélange type boxé ou pas. Dans ocaml, tout est boxé, et le compilo unbox quand il veut. Cela évite d'avoir 2 types de données différentes. En plus, cela réintroduit cette merde de pointeur qui n'existe plus sous ocaml.

ocaml utilise un gc générationel bien plus efficace qu'un compteur de référence.

Le typage linéaire utilisé pour le passage de message à l'air par contre très innovant, c'est la première fois que je le vois (à part linearML).

Les complexités des "type" mis en oeuvre est pour simplifier l'écriture du compilateur, ou est-ce qu'il y a vraiment des performances derrières ? (ocaml n'arrive pas toujours à unboxer quand il le faudrait)

"La première sécurité est la liberté"
- [^] # Re: avantage ?
  
  Posté par reno le 23 juillet 2012 à 16:50. Évalué à 9.
  
  Si je compare avec ocaml, Rust ne parait pas terrible.
  
  D'un point de vue syntaxe/typage, c'est une comparaison valide, mais après tu compare la gestion mémoire et là je ne suis pas d'accord: Rust est un C++-like: pas de GC donc c'est logique que ça ait des conséquences sur la gestion des copies.
  
  ocaml utilise un gc générationel bien plus efficace qu'un compteur de référence.
  
  Tout les GC sont mauvais, ils le sont juste de manière différente: trouve moi un GC qui soit
  1) précis 2) temps réel 3) ne perturbe pas le swap(*) 4) Free
  et on discute, en "attendant" les langages sans GC gardent leur utilité..
  
  *: pour (3), il faut "juste" patcher le noyau:
  http://lambda-the-ultimate.org/node/2391
  - [^] # Re: avantage ?
    
    Posté par Antoine le 26 juillet 2012 à 18:25. Évalué à 2.
    
    1) précis 2) temps réel 3) ne perturbe pas le swap(*) 4) Free
    et on discute, en "attendant" les langages sans GC gardent leur utilité..
    
    Oui mais sont-ils vraiment utiles pour un navigateur Web (plutôt que, disons, un noyau ou un démon bas niveau dans l'embarqué) ?
- [^] # Re: avantage ?
  
  Posté par rogo le 23 juillet 2012 à 17:38. Évalué à 10.
  
  J'ai moi aussi du mal à comprendre l'intérêt de ce langage, mais pour des raisons indépendantes de sa syntaxe.
  
  Un langage créé par Mozilla pour développer un navigateur de Mozilla, il y a peu de chance qu'il attire une large communauté. Surtout quand l'offre en langages de programmation est déjà pléthorique. J'imagine que ce sera plutôt une barrière à l'entrée de ce nouveau navigateur web : si vous voulez collaborer, il faut d'abord apprendre le langage maison. Ça risque d'en refroidir plus d'un. Moi en tout cas je ne propose des patches que dans les langages que je connais déjà.
  
  Mais surtout, j'ai des doutes sur la pérennité de ce choix. La dépêche met en avant des impératifs de sécurité et de performance. Ce sont des domaines qui requièrent des experts. Est-ce que la fondation Mozilla disposera toujours de plusieurs experts en compilateurs ? Quand je vois sa position sur XUL ou Thunderbird, je suis d'autant plus dubitatif.
  
  Je me demande s'il n'aurait pas été possible d'adopter un langage déjà présent, avec une communauté déjà formée et si possible des experts déjà au travail sur l'implémentation. Je pense bien sûr à Go qui a beaucoup de points communs avec Rust, et sur lequel Google apporte une certaine garantie de qualité et de pérennité. Est-ce qu'un fork du compilateur accompagné de quelques bibliothèques n'aurait pas suffit ? Idem avec OCaml, D, ou Scala, voire Haskell. Malheureusement, je ne suis pas assez compétent pour répondre à mon interrogation.
  
  Bref, j'ai un peu peur que Mozilla soit victime du syndrome "Not Invented Here".
  - [^] # Re: avantage ?
    
    Posté par barmic le 23 juillet 2012 à 17:46. Évalué à 3.
    
    Je pense bien sûr à Go qui a beaucoup de points communs avec Rust
    
    Je crois que Go n'est pas aussi typé. Par contre il reste les langages fonctionnels comme Haskel et OCaml. Mais ces derniers n'ont pas des threads léger à la Go. Peut être qu'erlang aurait était un bon choix ou Elixir (mais il n'avait peut être pas encore commencé quand Rust a était lancé).
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: avantage ?
      
      Posté par Chaddaï Fouché le 23 juillet 2012 à 18:05. Évalué à 9.
      
      Haskell a l'un des modèle de threads léger les plus avancé, ainsi qu'un large choix de librairies de gestion du parallélisme dont les classiques mutex/locks, de la STM (mémoire transactionnelle logicielle), des canaux pour les agents, une modèle de stratégie qui permet de décrire de façon non-invasive et déterministe comment exécuter du code purement fonctionnel en parallèle ainsi qu'une librairie de vectorisations des opérations (DPH data parallel Haskell, voir Repa) à la pointe de la recherche.
      
      Mais clairement Haskell n'a pas du tout le même objectif que Rust : Haskell est bien plus haut niveau et met l'accent sur un cœur purement fonctionnel (discernable par les types). Est-ce un bon choix pour écrire le browser du futur… pourquoi pas, mais cela aurait impliqué un très grand effort des développeurs Mozilla pour changer leur perspective du paradigme impératif au paradigme fonctionnel.
      - [^] # Re: avantage ?
        
        Posté par Nicolas Boulay (site web personnel) le 24 juillet 2012 à 08:30. Évalué à -1.
        
        Haskell a aussi réussi à être encore moins lisible que Ocaml :)
        
        "La première sécurité est la liberté"
    - [^] # Re: avantage ?
      
      Posté par zaurus (site web personnel) le 25 juillet 2012 à 05:38. Évalué à 1.
      
      La lib async de janestreet core pour OCaml n'est-elle pas l'equivalent
      des threads legers de Go?
      - [^] # Re: avantage ?
        
        Posté par Enjolras le 25 juillet 2012 à 07:54. Évalué à 1.
        
        je ne connais pas trop libasync, parce que c'est assez récent (enfin, sa publication), mais il me semble que c'est un peu comme lwt. Oui c'est un peu comme les goroutines, sauf que ça peut pas être exécuté dans plusieurs threads. C'est forcément sérialisé. À mois, qu'ils embarquent une autre implémentation d'ocaml, mais ça m'étonnerai.
        
        Cela dit, je crois qu'il y a eu des implémentations d'ocaml sans GC avec un lock global.
  - [^] # Re: avantage ?
    
    Posté par claudex le 23 juillet 2012 à 17:50. Évalué à 4.
    
    Un langage créé par Mozilla pour développer un navigateur de Mozilla, il y a peu de chance qu'il attire une large communauté.
    
    Je crois que le but est plus d'avoir un langage C-like, et comme la fondation développe un navigateur qui est un programme très complexe et polyvalent actuellement, ils prennent comme objectif de pouvoir développer un navigateur avec car cela permettra sans doute de faire beaucoup d'autres programmes.
    
    Je pense bien sûr à Go qui a beaucoup de points communs avec Rust
    
    D'après Wikipédia, Rust a commencé en 2006, Mozilla s'est impliquée en 2009 et est officiellement annoncé en 2010. Pour Go, il a commencé en 2007 et a été officiellement annoncé en 2009. Ils ont donc plutôt été créé parallèlement.
    
    Est-ce qu'un fork du compilateur accompagné de quelques bibliothèques n'aurait pas suffit ?
    
    Je pense que ça aurait créé deux langages semblables mais incompatible avec finalement une incompréhension pour les gens de l'extérieur sur la différence entre les langages. Surtout qu'un fork aurait sans doute frusté la communauté initiale du langage.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: avantage ?
    
    Posté par Ontologia (site web personnel) le 23 juillet 2012 à 21:40. Évalué à 4.
    
    Est-ce qu'un fork du compilateur accompagné de quelques bibliothèques n'aurait pas suffit ?
    
    Je complèterai la réponse de Xavier en précisant que C et surtout C++ a un système de type qui relève plus de la passoire que de l'architecture (bien qu'il y ait un effort en C++ si on se restreint aux dernières moutures).
    
    Si l'affirmation de la news
    
    le compilateur vérifiera que tous les chemins d'exécutions retourne bien un type.
    
    est exacte, cela signifie que le compilateur effectue une analyse de flot. Bref une analyse de type un peu précise.
    
    C ou C++ par design (arithmétique des pointeurs et trop grande complexité pour C++) ne permettent absolument pas cela !
    Et cela te vire 50% des bugs au moins.
    
    De plus, l'immutabilité par défaut est une très bonne idée, bien que ce soit stupide d'utiliser ça dans des boucles. Mais bon, je suppose qu'ils ont des lambda et du map/fold/filter.
    
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
    - [^] # map
      
      Posté par Ontologia (site web personnel) le 24 juillet 2012 à 00:44. Évalué à 3.
      Ils ont ;-)
      
      fn map<T, U>(vector: ~[T], function: fn(T) -> U) -> ~[U] { let mut accumulator = ~[]; for vector.each |element| { vec::push(accumulator, function(element)); } ret accumulator; }
      
      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
  - [^] # Re: avantage ?
    
    Posté par Enjolras le 24 juillet 2012 à 08:23. Évalué à 10.
    
    Il n'y a pas besoin d'être expert en compilateur pour écrire un compilateur en 2012. Il y a des outils performant qui fournissent des backends déjà fait, il suffit d'écrire le frontend, ce qui revient souvent à définir la sémantique du langage. Exemple d'outil : LLVM.
    
    De plus, dire que Mozilla n'a pas d'expert en navigateurs, c'est un peu exagéré, parce qu'ils ont écrit déjà au moins 3 compilateurs javascripts, dont le dernier, ionMonkey, est un vrai navigateur avec frontend/backend et MIR/LIR.
    
    En outre, Rust ne se compare avec aucun langage sus-cité, parce qu'il emprunte un peu de chaque. Et c'est l'idée. Avoir un langage avec des contraintes de types fortes, des pointeurs avec une sémantique forte, qui permet plusieurs paradigmes de programmation, tout en n'affectant pas les performances, et permettant une sorte de cargo programming pour que les gens qui n'ont jamais fait que du C ne tombent pas sur Haskell et ne rehjettent le langage.
    
    Donc :
    - haskell ? → performances non prédictibles, trop complexe pour la conversion de la code-base
    - ocaml ? → ocaml utilise un GC avec biglock, et ne permet pas de gérér la mémoire, je vois mal comment on peut écrire un GC javscript en Ocaml ni même un navigateur multithreadé.
    - C/C++ → pas assez de contraintes sur les types et les pointeurs, C++11 fournit vaguement des routines légéres, mais, ça existait pas au début de rust.
    - scala → JVM. Je ne pense pas que Mozilla veuille dépendre techniquement de la JVM, a fortiori pour des raisons philosophie. Puis, la JVM est connue pour consommer de la mémoire, Déjà que les gens trouvent firefox lourd…
    - [^] # Re: avantage ?
      
      Posté par djano le 24 juillet 2012 à 08:35. Évalué à 6.
      
      s/navigateurs/compilateurs/ ?
      
      Déjà que les gens trouvent firefox lourd…
      
      Trouvaient? Je trouve qu'il assure bien maintenant et j'ai vu passer des benchmarks en faisant les premiers en terme d'utilisation réduite de la mémoire.
      - [^] # Re: avantage ?
        
        Posté par Enjolras le 24 juillet 2012 à 08:49. Évalué à 2. Dernière modification le 24 juillet 2012 à 08:53.
        
        Il assure bien, et même si on veut bien donner une quelconque crédibilité aux benchs, on peut prétendre que c'est le meilleur.
        
        Il n'empêche que les gens le trouvent toujours lourd.
        
        [^] # Re: avantage ?
        
        Posté par reno le 24 juillet 2012 à 10:31. Évalué à 3.
        
        Il n'empêche que les gens le trouvent toujours lourd.
        
        Le problème vient de FF ou des sites web?
        Je connais un blog ( http://bertrandmeyer.com/ ) qui utilise environ 150Mo de RAM avec Chrome et pourtant ce n'est que du texte!
        Firefox évalue ce blog à 10Mo ce qui parait bien plus raisonnable..
        
        [^] # Re: avantage ?
        
        Posté par djano le 24 juillet 2012 à 14:28. Évalué à 3.
        
        Moi je te dis que je le trouve bien plus rapide qu'avant.
        
        Maintenant si "les gens" le trouvent lourd, je ne peux que leur conseiller de publier un bench qui le montre. Tu peux être sûr que les gens de Mozilla y seront attentifs si ce bench est représentatif.
        
        Si "les gens" disaient aussi à quoi ils le comparent pour le trouver lourd, ça pourrait être pas mal.
        
        Pour finir, "lourd" n'est pas une bien bonne description. Si "les gens" disaient par exemple que Firefox utilise trop de mémoire, de CPU ou bien qu'il lagge ou se bloque, ça permettrait peut être mieux de résoudre les problèmes "des gens".
        
        Bref, ça ressemble juste à des "weasel words".
        
        [^] # Re: avantage ?
        
        Posté par Enjolras le 24 juillet 2012 à 14:30. Évalué à 1.
        
        Tu sais je suis entièrement d'accord avec toi. J'ai juste dit que les gens le trouvaient lourds. J'y suis pour rien…
        
        [^] # Re: avantage ?
        
        Posté par zebra3 le 24 juillet 2012 à 15:39. Évalué à 4.
        
        C'est pas parce qu'il est plus rapide qu'avant qu'il n'est pas encore trop lourd.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: avantage ?
        
        Posté par djano le 24 juillet 2012 à 17:04. Évalué à 4.
        
        Merci, mais je n'ai pas besoin de cours de logique.
    - [^] # Re: avantage ?
      
      Posté par Nicolas Boulay (site web personnel) le 24 juillet 2012 à 08:40. Évalué à 2.
      
      Il est sur que ocaml va avoir du mal à faire des threads avec son GC. Certain pense qu'un modèle multiprocess serait plus intéressant + lwt (comme chrome ?).
      
      Les types linéaires semblent être l'avenir pour l'échange de message entre taches.
      
      LLVM n'est pas magique, il ya un tas d'optimisation de très haut niveau impossible à faire au niveau llvm (deforestation, canonisation automatique, unboxing, changement du layout mémoire)…
      
      "La première sécurité est la liberté"
      - [^] # Re: avantage ?
        
        Posté par Enjolras le 24 juillet 2012 à 08:52. Évalué à 2.
        
        Le multi process n'est pas magique non plus. Ca veut juste dire que tu laisses faire le message passing à l'OS via les IPC. Et comme chaque OS a différents IPC c'est pas si simple. Dans l'état actuel des choses, ça alourdit considérablement.
        
        LLVM n'est pas magique, mais il évite de coder le lowering. Ce qui et pas mal d'optimisations comme le LICM, etc. Il fournit quand même beaucoup d'outils qui facilitent grandement l'écriture du compilateur, la grande majorité du travail ayant lieu sur le frontend.
      - [^] # Re: avantage ?
        
        Posté par Enjolras le 24 juillet 2012 à 09:01. Évalué à 1.
        
        J'ai oublié de parler de LWT.
        
        Lwt peut répondre à beaucoup de problématiques en effet, mais ce qu'il ne faut pas oublier, c'est que le navigateur veut tirer partie de tout les cœurs. La tendance actuelle des choses est de tout mettre dans des threads, la compilation JavaScript, la composition, le rendu, la compression/décompression des images et des sources,… Force est de constater que ça améliore les performance. Maintenant, la question qui se pose est "est ce que des coroutines ne suffiraient pas ?". Vu que C++ n'en a pas, personne n'a testé. (Non, boost n'est pas une option)
        
        [^] # Re: avantage ?
        
        Posté par khivapia le 24 juillet 2012 à 09:54. Évalué à 2.
        
        Non, boost n'est pas une option
        Peux-tu détailler ?
        
        Merci,
        
        [^] # Re: avantage ?
        
        Posté par Enjolras le 24 juillet 2012 à 09:59. Évalué à 2.
        
        Demande à Mozilla.
        J'imagine que c'est historique, et qu'ils ont pas envie d'introduire des nouvelles dépendances sans vraie raison.
        
        [^] # Re: avantage ?
        
        Posté par Nicolas Boulay (site web personnel) le 25 juillet 2012 à 10:08. Évalué à 2.
        
        Chrome fait du multiprocess. On est aujourdh'ui à maximum 12 cores par PC. Il ne me semble pas idiot d'avoir qq process pour son application et plein de lwt pour le découpage en tâche. Cela utilisera tout autant les cores disponibles.
        
        "La première sécurité est la liberté"
        
        [^] # Re: avantage ?
        
        Posté par barmic le 25 juillet 2012 à 15:06. Évalué à 1.
        
        On est aujourdh'ui à maximum 12 cores par PC.
        
        Ma meilleure machine est à 3. Ne pas confondre les plus grosses CPU actuelles avec le standard. Il y a quelques années d'écart (en fait je suis pas sur qu'Intel vende plus que 8 cœurs * 2 threads au grand public). Mais on parle de CPU à 1 300 € minimum.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: avantage ?
        
        Posté par Nicolas Boulay (site web personnel) le 25 juillet 2012 à 16:50. Évalué à 3.
        
        Les core i7 sont déjà à 4*2. Cela monte vite. AMD propre des 6 et des 8 cores.
        
        "La première sécurité est la liberté"
        
        [^] # Re: avantage ?
        
        Posté par CrEv (site web personnel) le 26 juillet 2012 à 09:23. Évalué à 2.
        
        On est aujourdh'ui à maximum 12 cores par PC.
        
        Ma meilleure machine est à 3. Ne pas confondre les plus grosses CPU actuelles avec le standard.
        
        D'où le principe d'avoir indiqué maximum, non ?
        
        De mon côté, une machine classique c'est 4 coeurs et entre 4 et 8Go de RAM…
        (après je parle de machine de boulot, pas perso)
    - [^] # Re: avantage ?
      
      Posté par Antoine le 26 juillet 2012 à 18:33. Évalué à 2.
      
      En outre, Rust ne se compare avec aucun langage sus-cité, parce qu'il emprunte un peu de chaque. Et c'est l'idée.
      
      En même temps, c'est l'idée de chacun des dizaines de langages créés ces dernières années. Chacun croit avoir trouvé son assortiment idéal (optimum local) de fonctionnalités piquées ça et là, et pense que faire son bidule dans son coin a plus de valeur que de se greffer sur un projet existant. Bonne chance à chacun d'eux…
- [^] # Re: avantage ?
  
  Posté par Jux (site web personnel) le 23 juillet 2012 à 18:52. Évalué à 2.
  
  Je me pose aussi des questions de l'intérêt de Rust par rapport a C++11 (qui a rendu C++ vraiment plus utilisable dans un style moderne avec les lambda, auto, le foreach, le multithreading).
# Une stratégie bizarre.

Posté par david.g le 23 juillet 2012 à 21:12. Évalué à 10.

J'ai un peu de mal à comprendre la stratégie de Mozilla, d'un coté elle dit, se recentrer sur ses activités Mobile/OS. Elle se décharge au passage des évolutions sur Thunderbird.

De l'autre on développe son propre langage.

Personnellement je trouve que l'on manque plus de client de messagerie de qualité que de langage de programmation, mais pourquoi pas.
- [^] # Re: Une stratégie bizarre.
  
  Posté par claudex le 23 juillet 2012 à 23:58. Évalué à 5.
  
  Je crois qu'il faut voir la différence entre Thunderbird qui était un projet avec plusieurs personnes à plein temps dessus et Rust qui a l'air de ne pas avoir de personnes officiellement payés pour ça, uniquement une mise à disposition de ressource (mailing list, forge…).
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Une stratégie bizarre.
  
  Posté par Enjolras le 24 juillet 2012 à 08:07. Évalué à 2. Dernière modification le 24 juillet 2012 à 08:07.
  
  Parce que la fondation Mozilla est assez intelligente pour préparer l'avenir… On critique souvent à Mozilla de ne pas innover, c'est faux.
  
  Ils ont bien compris que les nouveaux navigateurs devaient être hautement paralèles, et qu'il ya de grosses problèmatiques de gestion de la mémoire et du passage de mémoire. Actuellement, ils utilisent des threads et XPCOM pour passer des messages. Ce n'est pas satisfaisant. Rust est un projet d'avenir à long terme, qui ne mobilise pas énormément de ressources, et il est couplé avec un prototype de moteur.
  
  Il faut voir ça comme le département Recherche/Innovation de Mozilla. Ça n'a pas d'intérêt dans les mois qui viennent, mais ça pourrait s'avérer crucial dans 7 ou 8 ans.
  - [^] # Re: Une stratégie bizarre.
    
    Posté par djano le 24 juillet 2012 à 08:30. Évalué à 3. Dernière modification le 24 juillet 2012 à 08:32.
    
    Oui d'ailleurs, je ne peux m’empêcher de voir de grosses similitudes entre le C++ et Rust:
    
    Les boîtes partagées, les boîtes uniques et les pointeurs empruntes ressemblent follement au std::shared_ptr, std::auto_ptr et std::unique_ptr. Le mot clé "let" me fait furieusement penser au Javascript. L'exemple cité dans https://linuxfr.org/news/sortie-de-rust-en-version-0-3#comment-1370156 est un beau mélange entre du C++ (l'API de vector) et du Javascript (vector.each similaire à Array.forEach).
    
    Ils y ont ajoutés des petits trucs sympas comme l'immutabilité, mais ils reconnaissent qu'elle n'est pas satisfaisante dans tous les cas (boucles) et permet donc de s'en passer.
    
    Bref, je trouve que c'est un langage très intéressant pour Mozilla: Un mélange entre le meilleur du C++, le meilleur du Javascript, et des emprunts ciblés sur d'autres langages qui ont fait leurs preuves tels Erlang (immutabilités, lightweight threads, passage de messages). Cela permet de ne pas trop perturber les anciens et de réutiliser leurs compétences au maximum!
    C'est un langage parfait pour Mozilla, ça ne m’étonnerait que ce soit eux qui l'aient fait. Ah… ben oui! ;)
- [^] # Re: Une stratégie bizarre.
  
  Posté par Julien Wajsberg le 24 juillet 2012 à 16:53. Évalué à 3.
  
  Le but avoué de Mozilla, c'est de faire évoluer le Web. D'être le futur du Web.
  
  Thunderbird ne fait clairement pas partie de ce bug, c'est logique de le mettre de côté. Et pareil pour XUL d'ailleurs… (et je suis le premier à le déplorer)
# typage strict

Posté par pseudovalide le 24 juillet 2012 à 10:38. Évalué à 2.

En matière de typage il me semble que la référence est Ada
ma question est donc : les avantages de ce langage sur Ada ?
- [^] # Re: typage strict
  
  Posté par zebra3 le 24 juillet 2012 à 11:39. Évalué à 8.
  
  Il n'est pas sexiste, son nom n'est pas celui d'une femme.
  
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: typage strict
  
  Posté par reno le 24 juillet 2012 à 14:43. Évalué à 3.
  
  En matière de typage il me semble que la référence est Ada
  
  Euh, ça dépend de ce que tu appelle comme "référence" Ada a un typage strict maintenant vu l'age du langage ça m'étonnerait qu'il ait un système de typage "moderne".
  
  Après pour répondre à ta question, je dirais qu'Ada n'est pas à la mode, j'ignore pourquoi..
  - [^] # Re: typage strict
    
    Posté par Jean-Yves LENHOF (site web personnel) le 24 juillet 2012 à 15:26. Évalué à 0.
    
    Tu t'es peut-être arrêter à Ada 83… avec lequel on pouvait faire de l'objet mais en trichant un peu.
    mais il y a de l'Ada 2005 avec une vision objet plus complète, cela ne me semble pas si vieux.
    
    Maintenant pourquoi ce langage n'est pas aussi aimé de tous les développeurs…cela doit être parce
    que les développeurs doivent penser avant d'écrire du code dans ce langage plus que dans un autre. Le
    compilateur étant particulièrement pointilleux par rapport à d'autres.
    - [^] # Re: typage strict
      
      Posté par Nicolas Boulay (site web personnel) le 25 juillet 2012 à 10:16. Évalué à 2.
      
      C'est surtout que ce langage n'avait qu'un runtime très couteux pendant très longtemps, d'où son usage restreint.
      
      "La première sécurité est la liberté"
      - [^] # Re: typage strict
        
        Posté par barmic le 25 juillet 2012 à 15:07. Évalué à 2.
        
        Il est compilé en code machine il est où le runtime couteux ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: typage strict
        
        Posté par lendemain le 25 juillet 2012 à 15:32. Évalué à 0.
        
        Les tests au runtime qui lèvent des exceptions sans doute.
        
        [^] # Re: typage strict
        
        Posté par Nicolas Boulay (site web personnel) le 25 juillet 2012 à 20:50. Évalué à 3.
        
        gnat est récent, avant les compilo ada + la couches pour les OS (gestion de tache, etc…) coutait un bras. J'avais eu une discussion avec un chef de projet de MBDA autour de l'an 2000, il passait de Ada au C, en parti à cause de ça.
        
        "La première sécurité est la liberté"
    - [^] # Re: typage strict
      
      Posté par Mildred (site web personnel) le 30 juillet 2012 à 21:53. Évalué à 1.
      
      Tu t'es peut-être arrêter à Ada 83… avec lequel on pouvait faire de l'objet mais en trichant un peu. mais il y a de l'Ada 2005 avec une vision objet plus complète, cela ne me semble pas si vieux.
      
      Il y a maintenant Ada 2012 avec encore d'autres améliorations, qui cherchent entre autre à rendre le langage un peu moins verbeux.
  - [^] # Re: typage strict
    
    Posté par pseudovalide le 24 juillet 2012 à 16:23. Évalué à 0.
    
    Si la qualité d'un langage est en proportion inverse à son âge,
    le C ne devrait être qu'un mauvais souvenir.
    
    Au fait, ce langage se décline maintenant selon la norme Ada2012 : 2012, c'est presque contemporain non ? ;)
    - [^] # Re: typage strict
      
      Posté par reno le 24 juillet 2012 à 20:09. Évalué à 3.
      
      Si la qualité d'un langage est en proportion inverse à son âge,
      le C ne devrait être qu'un mauvais souvenir.
      
      Dommage d'ailleurs que ce ne soit pas le cas, cf par exemple:
      http://blog.regehr.org/
      
      Au fait, ce langage se décline maintenant selon la norme Ada2012 : 2012, c'est presque contemporain non ? ;)
      
      On parlait des types, ont-il été modifié dans les nouvelles versions d'Ada?
      - [^] # Re: typage strict
        
        Posté par Zylabon le 24 juillet 2012 à 22:12. Évalué à 1.
        
        Le but du C n'a jamais été de faciliter l'écriture de code certifié. C'est un langage simple, élégant, proche de la machine et dont les implémentation sont hyper performantes. On ne peux pas tout avoir. Le temps qu'on gagne en apprenant C à cause de sa simplicité, on le perd très partiellement en se penchant sur les choses à éviter (et les compilateurs modernes en repèrent pleins).
        
        Please do not feed the trolls
        
        [^] # Re: typage strict
        
        Posté par pseudovalide le 25 juillet 2012 à 09:26. Évalué à 3.
        
        un langage simple et élégant^[réf.^souhaitée]
        
        [^] # Re: typage strict
        
        Posté par wilk le 25 juillet 2012 à 09:51. Évalué à 1.
        
        un langage simple et élégant[réf.souhaitée]
        
        Par rapport au langage machine (c'est pas péjoratif, je déconne pas).
        
        [^] # Re: typage strict
        
        Posté par reno le 25 juillet 2012 à 09:36. Évalué à 3.
        
        simple
        
        Par rapport à quoi? Pascal? Non..
        
        élégant
        
        Hum, ça se discute, avoir des types entiers qui par défaut ont des comportements "déviants"(opération non définie, débordement silencieux) au nom de la performance, ça s'appelle de l'optimisation prématurée!
        Un langage élégant aurait des types entiers avec un comportement sain par défaut (à la Ada) tout en ayant des types prévu pour la performance a utiliser dans les (rare) cas ou on s'aperçoit que les tests additionnels ont un coût en performance pas acceptable.
        
        Pour le reste, on gagne du temps à apprendre le C par rapport aux Pascals ou à Python? Première nouvelle!
        
        La vrai raison d'apprendre le C est la base installée et comprendre comment ça marche "pour de vrai", mais bon ça ne fait pas de C un bon langage..
        
        [^] # Re: typage strict
        
        Posté par Nicolas Boulay (site web personnel) le 25 juillet 2012 à 10:19. Évalué à 4.
        
        "Le but du C n'a jamais été de faciliter l'écriture de code certifié."
        
        Ada n'ont plus. C'était juste une tentative d'uniformisation des langages utilisés par le DoD de mémoire.
        
        Il y a infiniment plus de code certifié en C qu'en Ada (je pense même qu'il y a plus de code certifié en Scade qu'en Ada).
        
        "La première sécurité est la liberté"
        
        [^] # Re: typage strict
        
        Posté par pseudovalide le 25 juillet 2012 à 10:31. Évalué à 0.
        
        En effet, il y a des applications pour générer du C à partir d'un code Ada.
        
        [^] # Re: typage strict
        
        Posté par Nicolas Boulay (site web personnel) le 25 juillet 2012 à 16:48. Évalué à 3.
        
        1) je ne parle pas de ça. Le gros du code est fait un C, la plus part du temps.
        2) Je n'en connais aucun, as-tu un lien ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: typage strict
        
        Posté par pseudovalide le 25 juillet 2012 à 21:25. Évalué à 0.
        
        Je plaisantais, manière de dire que seul du code généré à partir d'Ada pouvait être propre.
        
        [^] # Re: typage strict
        
        Posté par Nicolas Boulay (site web personnel) le 26 juillet 2012 à 09:25. Évalué à 1.
        
        Et ton compilateur Ada vers C, il est qualifiable ou qualifié DO330 ?
        
        Tu connais Scade ?
        
        "La première sécurité est la liberté"
      - [^] # Re: typage strict
        
        Posté par pseudovalide le 25 juillet 2012 à 10:22. Évalué à -1.
        
        Je parlais des types, puis "on" a parlé d'autres choses.
        
        Non, les types n'ont pas été modifiés : c'est tout de même un langage pour les systèmes critiques et la roue n'a pas connu de version 2.0
        
        [^] # Re: typage strict
        
        Posté par Nicolas Boulay (site web personnel) le 25 juillet 2012 à 16:55. Évalué à 3.
        
        Non, c'est un langage pour le Dod. Les équipements fait pour la défense ne sont en général pas certifié par les normes civiles. L'A400M est un des seul avion militaire à être qualifié comme un airbus (DO178b).
        
        Mais je veux bien croire qu'il y a une communauté forte de codeurs Ada dans le domaine notament en Uk, mais c'est loin d'être une majorité.
        
        "La première sécurité est la liberté"
# Servo

Posté par Tit le 27 juillet 2012 à 11:47. Évalué à 2.

Vu les orientations de la fondation Mozilla, le but est de pouvoir développer un navigateur Web avec ce langage et les travaux ont déjà commencé, ce navigateur alternatif s'appelle Servo.

Servo serait plutôt un "Gecko" alternatif: http://paulrouget.com/e/servo/
- [^] # Re: Servo
  
  Posté par Antoine le 28 juillet 2012 à 23:13. Évalué à 1.
  
  Et pour préciser un peu : Servo is a research project. It is not aimed to replace Gecko.
  (citation de la page ci-dessus)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.