IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Commentaires

  1. Avatar de sekaijin
    • |
    • permalink
    pourquoi le choix d'un IDE et pas de plugin pour les IDE du marché ?

    Quand je vois le truc j'ai 'impression que vous refaites VS Studio.

    ne serait-il pas judicieux de se concentrer sur la toolchain et l'intégré à un ou deux IDE existant ?
    Les développeurs n'aime pas jongler avec les IDE et le développement d'une appli web est très bien outillé dans certains d'entre eux.
    Partir sur un nouvel IDE c'est certes très bien prendre en charge WASM mais c'est dégrader l'outillage pour le reste. ou alors vous devrez consacrer de très gros effort pour refaire ce que les autre font déjà. Je crains que ce ne soit un frein.


    Mais très beau boulot!
    A+JYT
  2. Avatar de Songbird
    • |
    • permalink
    Bonjour,

    La coloration syntaxique n'est pas fournie par RLS.
    Effectivement, ce n'était absolument pas comme ça que je voulais tourner ma phrase. C'est corrigé, merci !
  3. Avatar de Mickael_Istria
    • |
    • permalink
    La coloration syntaxique n'est pas fournie par RLS. Chaque editeur l'implemente comme il le souhaite, mais la specification Language Server sur laquelle s'appuie RLS ne supporte pas la coloration syntaxique. En pratique, la plupart des editeurs utilisent maintenant des grammaire TextMate pour faire ca, mais c'est encore une fois independanct du Language Server Protocol et de RLS.

    Rust disposant dès maintenant de son propre module pour IntelliJ, nous pourrions espérer que cette plateforme rejoigne bientôt la liste !
    Pour l'instant, il semblerait que JetBrains boude l'utilisation du Language Server Protocol et de ses implementations dans leurs outils. Il y a une extension communautaire, mais JetBrains a tendance a preferer utiliser leurs modeles internes plutot que de reutiliser des composants tout faits. Donc il est peu probable qu'IntelliJ se mette a officiellement supporter Rust via RLS d'ici peu.

    N’étant "qu’une" amélioration de ce qui existe déjà, cette préversion sera un prétexte comme un autre pour tester la chaîne et certainement l’adopter.
    Les Language Servers et RLS ne sont pas particulierement des technologies qui sont dediees aux utilisateurs finaux mais plutot aux integrateurs, fournisseurs de langages ou d'outils. Donc a l'usage, utiliser RLS ne devrait pas changer grand chose dans un premier temps. Cependant, avec la diversite d'outils majeurs qui l'utilisent justement parce qu'il se base sur le Language Server Protocol et qui du coup contribuent a son amelioration collectivement, il ne fait aucun doute que la popularite va grandir et que RLS va devenir la brique standard pour l'edition de code en Rust.
  4. Avatar de Songbird
    • |
    • permalink
    Citation Envoyé par Dhafer1
    Excellent projet ! Manque plus que le support de Python
    En effet, mais honnêtement quand je vois déjà le boulot à faire pour les trois langages ciblés, je pense qu'il va falloir attendre un bon moment.

    Stratégiquement, le support de Python pourrait être une très bonne nouvelle.
  5. Avatar de Dhafer1
    • |
    • permalink
    Excellent projet ! Manque plus que le support de Python
  6. Avatar de Songbird
    • |
    • permalink
    Bonjour,

    Effectivement, y'a eu une petite méprise. Je corrigerai ça dans la journée, merci !

    Maintenant que tu le dis, ça coule de source en effet.

    En te souhaitant une bonne journée !
  7. Avatar de gb_68
    • |
    • permalink
    Merci pour ces informations.

    Juste une petite précision sur Emscripten et Binaryen ; ce sont deux outils complémentaires : Emscripten utilise Binaryen comme back-end pour générer du wasm - même si un back-end LLVM wasm est aussi prévu (le but de Binaryen est, d'après ce que j'ai compris, essentiellement d'être un ensemble d'outils/bibliothèques pour aider à réaliser des compilateurs/outils supportant wasm). C'est d'ailleurs une bonne chose que des projets modulaires pouvant se réutiliser les uns les autres apparaissent plutôt qu'une prolifération d'outils monolithiques dont les rôles se chevauchent ; car même si les acteurs majeurs du Web sont favorables à WebAssembly, c'est un projet ambitieux qui nécessitera d'importantes ressources pour arriver à terme (autant ne pas trop les gaspiller).

    Emscripten
    Citation Envoyé par Emscripten
    Emscripten’s WebAssembly support depends on Binaryen
    Binaryen
    Citation Envoyé par Binaryen
    Integrate with Emscripten in order to provide a complete compiler toolchain from C and C++ to WebAssembly.