Assemblyscript: ¿Por qué no transpilar para oxidar?

Creado en 6 ago. 2020 · 5Comentarios · Fuente: AssemblyScript/assemblyscript

Hola,

Me preguntaba por qué no siguió la ruta de hacer un typeript para rust transpiler y luego generar código js con la ayuda de wasm-pack

De:

export greet(){
 let x: boolean = true;
 if(x){
  console.log("Greetings, x is true");
 }
}

(AST atravesando en el medio)

Para:

#[wasm_bindgen]
pub fn greet() {
    let x: bool = true; 
    if x {
        println!("Greetings, x is true");
    }
}

¿Hay alguna razón?

question

Fuente

solidsnail

👎2

Todos 5 comentarios

@solidsnail ¿qué pasa con la gestión automática de memoria (que proporciona AssemblyScript y Rust no)? Para empezar. :guiño:

gabriel-fallen en 6 ago. 2020

@solidsnail inmediatamente a la segunda pregunta. AssemblyScript proporciona cuatro opciones para una biblioteca de compatibilidad en tiempo de ejecución de diferentes tamaños y funcionalidades (https://www.assemblyscript.org/runtime.html). ¿Cuál es tu idea de volver a implementarlo con Rust (supongo que usando no-std)?

gabriel-fallen en 6 ago. 2020

En el caso de AssemblyScript, un lenguaje bastante diferente a Rust, transpilar a Rust reemplazaría efectivamente la capa de bajo nivel de Binaryen IR con una capa de bajo nivel diferente de Rust que no fue diseñada específicamente para la tarea. Se puede hacer hasta cierto punto, con el ligero beneficio de poder canalizar efectivamente a través de LLVM (espero que este beneficio disminuya con el tiempo), pero eso también significaría dos capas de bibliotecas estándar con dos capas de compiladores, que muy probablemente produzcan código final de WebAssembly subóptimo e innecesariamente torpe. Los inconvenientes superan rápidamente los beneficios si los hay, es decir, hacer que todo sea más grande para descargar, más difícil de configurar, hacer que la compilación sea mucho más lenta y, en última instancia, no poder iniciar el compilador.

dcodeIO en 6 ago. 2020

👀2

También es una gran razón descrita por Alon por la que usamos Binaryen en lugar de lenguajes basados en LLVM o LLVM

MaxGraey en 6 ago. 2020

Ya veo, gracias por las ideas.

De hecho, estoy más interesado en ver las cosas desde una perspectiva DX, pensando en algo como esto:

counter.tsx:

import { WASM, Component, i32 } from "./lib";

<strong i="9">@Component</strong>
export class Counter {
  wasm_state = {
    count: 1,
  };

  @WASM({
    getter: true,
  })
  getCount() {
    return this.wasm_state.count;
  }

  @WASM({
    setter: true,
  })
  setCount(count: i32) {
    this.wasm_state.count = count;
  }

  render() {
    return (
      <div>
        <h1>Count: {this.getCount()}</h1>
      </div>
    );
  }
}

AST mecanografiado atraviesa, transforma y genera archivos:

counter.wasm:

extern crate cfg_if;
extern crate wasm_bindgen;

mod utils;

use cfg_if::cfg_if;
use wasm_bindgen::prelude::*;

cfg_if! {
    if #[cfg(feature = "wee_alloc")] {
        extern crate wee_alloc;
        #[global_allocator]
        static ALLOC: wee_alloc::WeeAlloc = wee_alloc::WeeAlloc::INIT;
    }
}


#[wasm_bindgen]
pub struct State {
    count: i32,
}

#[wasm_bindgen]
impl State {
    #[wasm_bindgen(constructor)]
    pub fn new(count: i32) -> State {
        State { count }
    }

    #[wasm_bindgen(getter)]
    pub fn getCount(&self) -> i32 {
        self.count
    }

    #[wasm_bindgen(setter)]
    pub fn setCount(&mut self, count: i32) {
        self.count = count;
    }
}

counter.js:

import {html, render} from 'lit-html';
import { State  } from './counter.wasm';


export class Counter extends HTMLElement{
    constructor(){
        super();
        State.setCount(1)
        this.renderHtml()
    }

    renderHtml(){
      render(html`
        <div>
            <h1>Count: ${State.getCount()}</h1>
        </div>
        `, this);
    }
}

solidsnail en 7 ago. 2020

😕1 👎1

¿Fue útil esta página

0 / 5 - 0 calificaciones