8 ms·

Write your Rust app. Compile to a binary on the backend, wasm on the frontend, using asyncio to communicate transparently between the two. Update the DOM direct

by adwhit 10y ago

Write your Rust app. Compile to a binary on the backend, wasm on the frontend, using asyncio to communicate transparently between the two. Update the DOM directly from wasm, with 60fps rendering from Servo's WebRender. Totally typesafe and lightening fast. It could all be so beautiful.

oblio 10y ago
And it will never happen (ok, maybe "never" is too strong - it will happen 10-15 years from now, at best and even then it will be unstable/unreliable/slow/half baked on some platforms, because reasons). The best we've got is the piece meal approach of HTML/Javascript/CSS. And before you blame those standards, blame the Unix vendors^W^W, pardon me, the platform owners (Microsoft, Apple, Google).
- wtetzner 10y ago
  Why won't it happen? If wasm can talk to the DOM, then you'll still be using HTML and CSS, and wasm in place of JS. There's no reason this couldn't be done already by just compiling to JS, and plenty of languages already do that. You could also render everything to a canvas to avoid HTML and CSS, but at that point there are a lot of things to re-implement, especially around accessibility.
  - oblio 10y ago
    Well, first of all wasm needs to be implemented in all major browsers on all major platforms for it to be widely adopted. Since the major browser vendors are backing it, that should happen quite soon. But that's just the initial implementation. It needs to be implemented fully, debugged, optimized and then it needs to trickle down to user devices, including those sold 3-4-5 years ago and still in use. And then, in the second stage, wasm needs to get DOM access (as far as I know v1 won't have it). See stage 1, all over again. I'd say that the mass adoption cycle for 1 stage is roughly 5 years (where 80%+ of the browsers out there support a major feature well). So 2 stages x 5 years = 10 years. Maybe I'm too pessimistic...
    - dbaupp 10y ago
      Given the history of the web and what I know of the people/companies behind wasm, it seems very likely that there'll be a graceful degradation/shim in the form of a wasm interpreter written in JS/asm.JS (or even a JIT from wasm to one of them), so there'll be no need to wait for all browsers to have implemented it, it just won't live up to its performance on all platforms.
      - markdog12 10y ago
        There already is: https://github.com/lukewagner/polyfill-prototype-1 https://github.com/lukewagner/polyfill-prototype-1
    - vanviegen 10y ago
      I think you are being too pessimistic about the speed of mass adoption. On the desktop: Firefox, Chrome and Edge auto-update. On mobile: Android 4.4+ (over 80% and rising fast) auto-updates its webview component. iOS receives yearly updates that are applied by a very large majority - though Apple's browser development does seem to have stagnated a bit. So it seems to me that non-updating browsers are going extinct, and that we won't be dealing with another IE6 anytime soon. We're living in the future! :-)
      - Freak_NL 10y ago
        The age of the evergreen-browsers is dawning. Although it will be years before the last corporate holdouts let go of their pinned IE9/IE10/IE11 browsers.
    - mcbits 10y ago
      Why is 80% the magic number? 5% would reach more than 100 million people. That's enough to keep a team busy and a product growing while the competition sits on its butt waiting for the next 75%.
    - themihai 10y ago
      There is a shim so you don't need to wait for all the browsers to implement wasm
  - rubber_duck 10y ago
    I hate JS but replacing it with Rust for front end is a bad idea, Rust is a low level systems programming language, it's very suboptimal for high level front end code from productivity standpoint and it adds no value because it's advantages (mem safety with 0 cost abstractions) don't really matter in frontend (JS is super bad at being optimizable but it's still more than sufficiently fast).
    - Manishearth 10y ago
      memory safety isn't the only advantage. 0 cost abstractions do matter a bit. In general abstractions let you do high level programming in lower level languages. The type system matters a lot. I used to do a lot of scripting. One thing I really missed was having a good static type system. These days I miss ADT enums in all languages. Scripting is already moving in the direction of being more type safe (typescript, python type annotations), which is awesome, but I'd love to use something like Rust in that sphere.
    - adwhit 10y ago
      Rust is indeed known for memory safety and zero cost abstractions. But there is another side to Rust which is even more interesting - a type system that is almost as powerful as those of functional languages like OCaml and Haskell, but wrapped in approachable imperative syntax. With such a type system, it is possible to encode the invariants of your application in types (using generics and algebraic data types). Then you can get very close to "if it compiles, it works". JS, in particular, is the opposite. I am never really convinced that any JS I have written is "correct". It works, until one day it doesn't. This is such a problem that there have been multiple attempts to retrofit type-systems on top of it. Rust needn't be the only language that brings strong typing to the frontend (Elm has been around for years now). But I think the prospect of speed and correctness both front and back is pretty exciting.
      - rubber_duck 10y ago
        >But there is another side to Rust which is even more interesting - a type system that is almost as powerful as those of functional languages like OCaml and Haskell, but wrapped in approachable imperative syntax. That type system is pretty verbose because it's aimed at manual memory management which you don't really care about in front end, and the compile times are huge compared to say TypeScript or something along those lines so yeah - I agree static typing is nice - but saying you should use Rust for front-end because it has static typing is like saying every gardener should have an excavator because digging holes with hands sucks - shovels exist.
  - deleted 10y ago
    [deleted]
- CryZe 10y ago
  There doesn't seem to be anything unstable about it, even now. I've compiled tons of Rust code to asm.js over the last few months and there's not a single thing that didn't work. Modifying the DOM also works fairly well (you have to write wrappers though). And the code is 10x to 40x faster than the equivalent JS code. And you can run the exact same code natively on tons of platforms too. So it's already quite amazing.
  - steveklabnik 10y ago
    One package that doesn't work yet, last I heard, is regex. That's a big one.
    - CryZe 10y ago
      I'm not 100% sure if I tried it in any of my apps, but I think I did, and can't recall it not working. I'll try again soon and will tell you if it works.
      - burntsushi 10y ago
        Please fill me in too, possibly filling an issue on the regex repo if there's anything I can do to help. (This is the first I'm hearing of the problem.)
        steveklabnik 10y ago
        I had only heard of it second hand; I thought it was already communicated upstream. Oops!
msie 10y ago
Yeah, if your app happens to be the same on the frontend and backend.
- kbenson 10y ago
  There are benefits even if you aren't sharing the entire back-end. I develop an internal Mojolicious webapp, and there's been quite a few times where I would have loved to just have one or two of the backend libraries I've written available to JS, so I wouldn't have to write it again in JS or pass it to the server. Just knowing that I could write it once and have it be the same in both places, even if I changed it later, would be a real boon.
  - paulddraper 10y ago
    Exactly. Everytime I write a feature, I have to decide whether it's a backend feature or a frontend feature. Sometimes I get it wrong. I'd like to not lock myself into my choice.
Cyph0n 10y ago
That's a better fit for Scala imo. ScalaJS is great as is, and I'm sure a wasm Scala backend would be amazing. Rust is way too low-level for that imo. It works for Emscripten because of legacy code, but Rust is still ways off in that regard (i.e. adoption).
- danjoc 10y ago
  My impression was that wasm doesn't provide GC. Since Scala needs GC, Rust seems better positioned to have a first mover advantage.
  - Cyph0n 10y ago
    I did not know that. There is work being done in this area through the Scala Native project, so it's still feasible.
- kodablah 10y ago
  Having attempted this "isomorphism" across Scala and ScalaJS, it is not quite that easy. That goes for all setups (node -> JS, Java -> GWT, etc) that I have tried. There are a lot of what some might call "impedance mismatches" between the two targets especially when it comes to communication and DOM work. IMO only frameworks/middleware built to bridge the gap will make it seamless.
  - premium-concern 10y ago
    In my experience Scala(.js) works way better than "(node -> JS, Java -> GWT, etc)". There is a large gap between those and the way Scala _just works_ across platforms. The huge difference is that you can depend on libraries and have them "just work" regardless of whether they are implemented identical on each platform, or need specific variations to implement the expected features. Neither JS/Node nor Java/GWT have that.
15155 10y ago
> using asyncio Don't hold your breath. Unfortunately, the community seems to be going the way of Ruby/Python/C++: massive fragmentation.
- steveklabnik 10y ago
  What evidence do you have of this? Almost everyone is rallying around tokio.
  - bluejekyll 10y ago
    Yeah tokio and futures-rs rock. Have there been talks of futures becoming part of std?
    - steveklabnik 10y ago
      Many feel that it's likely that the future trait itself could become part of libcore. It's still far too early days to tell, though.
      - 15155 10y ago
        > the future trait itself could become part of libcore _Please_ make this so. > still far too early I've waited 3 years, more time probably couldn't hurt.
  - 15155 10y ago
    > Almost everyone is rallying around tokio. Sure - just as everyone "rallies" around EventMachine in Ruby. This discussion has been going on for almost 3 years now. It's great that tokio is making community headwinds, Twisted, Gevent, Celluloid, EventMachine all did too. The problem is, they've never reached critical mass, and their respective languages refused to bless them as "official." > What evidence do you have of this? The issue is inter-library compatibility. https://github.com/tailhook/rotor https://github.com/tailhook/rotor https://github.com/tokio-rs/tokio https://github.com/tokio-rs/tokio Totally incompatible, even though they build on the same low level library. https://github.com/mitsuhiko/redis-rs https://github.com/mitsuhiko/redis-rs Oh wow, a great redis library - objectively the most popular. Completely incompatible with all of the above AIO implementations. Let's take it to the extreme: - Incompatible memcached client implementations: - https://github.com/aisk/rust-memcache https://github.com/aisk/rust-memcache (sync) - https://github.com/zonyitoo/memcached-rs https://github.com/zonyitoo/memcached-rs (sync) - https://github.com/samphippen/decachedmem https://github.com/samphippen/decachedmem (tokio, partially implemented) - Incompatible redis client implementations: - https://github.com/tokio-rs/tokio-redis https://github.com/tokio-rs/tokio-redis (async via tokio) - https://github.com/mitsuhiko/redis-rs https://github.com/mitsuhiko/redis-rs (sync) - https://github.com/AsoSunag/redis-client https://github.com/AsoSunag/redis-client - Incompatible HTTP client implementations: - https://github.com/matt2xu/async-http-client/ https://github.com/matt2xu/async-http-client/ (tokio, new) - https://gitlab.com/imp/requests-rs.git https://gitlab.com/imp/requests-rs.git (hyper, sync) - https://crates.io/crates/reqwest https://crates.io/crates/reqwest (hyper) - https://crates.io/crates/request https://crates.io/crates/request The list goes on. There are countless libraries implemented with synchronous I/O, there are countless (good) popular libraries implemented with non-Tokio-based concurrency primitives. Let me just say it: I really, really like Rust. But I cannot feasibly use it for network/server-related tasks until a single solution is blessed by the Rust team. The "let's let the community handle standardizing async IO and concurrency" approach has _never_ worked in the somewhat brief history of programming languages. A blessed solution though? - Erlang, Golang, Node/JS* All work flawlessly. I would use Rust full-time for every server-related task if I could, but I've been observing for 3 years and unfortunately haven't seen much development after the abandonment of builtin green threading. *- codestyles sometimes incompatible, but there was _never_ a litany of sync libraries or otherwise fundamentally incompatible systems.
kibwen 10y ago
The question then is whether Servo will be ready for primetime before wasm gains GC support. :)
- bluejekyll 10y ago
  Is a GC planned for wasm? I was hoping not.
  - markdog12 10y ago
    It is, but not in the first release: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md

by adwhit 10y ago

oblio 10y ago

And it will never happen (ok, maybe "never" is too strong - it will happen 10-15 years from now, at best and even then it will be unstable/unreliable/slow/half baked on some platforms, because reasons). The best we've got is the piece meal approach of HTML/Javascript/CSS. And before you blame those standards, blame the Unix vendors^W^W, pardon me, the platform owners (Microsoft, Apple, Google).

wtetzner 10y ago
Why won't it happen? If wasm can talk to the DOM, then you'll still be using HTML and CSS, and wasm in place of JS. There's no reason this couldn't be done already by just compiling to JS, and plenty of languages already do that. You could also render everything to a canvas to avoid HTML and CSS, but at that point there are a lot of things to re-implement, especially around accessibility.
- oblio 10y ago
  Well, first of all wasm needs to be implemented in all major browsers on all major platforms for it to be widely adopted. Since the major browser vendors are backing it, that should happen quite soon. But that's just the initial implementation. It needs to be implemented fully, debugged, optimized and then it needs to trickle down to user devices, including those sold 3-4-5 years ago and still in use. And then, in the second stage, wasm needs to get DOM access (as far as I know v1 won't have it). See stage 1, all over again. I'd say that the mass adoption cycle for 1 stage is roughly 5 years (where 80%+ of the browsers out there support a major feature well). So 2 stages x 5 years = 10 years. Maybe I'm too pessimistic...
  - dbaupp 10y ago
    Given the history of the web and what I know of the people/companies behind wasm, it seems very likely that there'll be a graceful degradation/shim in the form of a wasm interpreter written in JS/asm.JS (or even a JIT from wasm to one of them), so there'll be no need to wait for all browsers to have implemented it, it just won't live up to its performance on all platforms.
    - markdog12 10y ago
      There already is: https://github.com/lukewagner/polyfill-prototype-1 https://github.com/lukewagner/polyfill-prototype-1
  - vanviegen 10y ago
    I think you are being too pessimistic about the speed of mass adoption. On the desktop: Firefox, Chrome and Edge auto-update. On mobile: Android 4.4+ (over 80% and rising fast) auto-updates its webview component. iOS receives yearly updates that are applied by a very large majority - though Apple's browser development does seem to have stagnated a bit. So it seems to me that non-updating browsers are going extinct, and that we won't be dealing with another IE6 anytime soon. We're living in the future! :-)
    - Freak_NL 10y ago
      The age of the evergreen-browsers is dawning. Although it will be years before the last corporate holdouts let go of their pinned IE9/IE10/IE11 browsers.
  - mcbits 10y ago
    Why is 80% the magic number? 5% would reach more than 100 million people. That's enough to keep a team busy and a product growing while the competition sits on its butt waiting for the next 75%.
  - themihai 10y ago
    There is a shim so you don't need to wait for all the browsers to implement wasm
- rubber_duck 10y ago
  I hate JS but replacing it with Rust for front end is a bad idea, Rust is a low level systems programming language, it's very suboptimal for high level front end code from productivity standpoint and it adds no value because it's advantages (mem safety with 0 cost abstractions) don't really matter in frontend (JS is super bad at being optimizable but it's still more than sufficiently fast).
  - Manishearth 10y ago
    memory safety isn't the only advantage. 0 cost abstractions do matter a bit. In general abstractions let you do high level programming in lower level languages. The type system matters a lot. I used to do a lot of scripting. One thing I really missed was having a good static type system. These days I miss ADT enums in all languages. Scripting is already moving in the direction of being more type safe (typescript, python type annotations), which is awesome, but I'd love to use something like Rust in that sphere.
  - adwhit 10y ago
    Rust is indeed known for memory safety and zero cost abstractions. But there is another side to Rust which is even more interesting - a type system that is almost as powerful as those of functional languages like OCaml and Haskell, but wrapped in approachable imperative syntax. With such a type system, it is possible to encode the invariants of your application in types (using generics and algebraic data types). Then you can get very close to "if it compiles, it works". JS, in particular, is the opposite. I am never really convinced that any JS I have written is "correct". It works, until one day it doesn't. This is such a problem that there have been multiple attempts to retrofit type-systems on top of it. Rust needn't be the only language that brings strong typing to the frontend (Elm has been around for years now). But I think the prospect of speed and correctness both front and back is pretty exciting.
    - rubber_duck 10y ago
      >But there is another side to Rust which is even more interesting - a type system that is almost as powerful as those of functional languages like OCaml and Haskell, but wrapped in approachable imperative syntax. That type system is pretty verbose because it's aimed at manual memory management which you don't really care about in front end, and the compile times are huge compared to say TypeScript or something along those lines so yeah - I agree static typing is nice - but saying you should use Rust for front-end because it has static typing is like saying every gardener should have an excavator because digging holes with hands sucks - shovels exist.
- deleted 10y ago
  [deleted]
CryZe 10y ago
There doesn't seem to be anything unstable about it, even now. I've compiled tons of Rust code to asm.js over the last few months and there's not a single thing that didn't work. Modifying the DOM also works fairly well (you have to write wrappers though). And the code is 10x to 40x faster than the equivalent JS code. And you can run the exact same code natively on tons of platforms too. So it's already quite amazing.
- steveklabnik 10y ago
  One package that doesn't work yet, last I heard, is regex. That's a big one.
  - CryZe 10y ago
    I'm not 100% sure if I tried it in any of my apps, but I think I did, and can't recall it not working. I'll try again soon and will tell you if it works.
    - burntsushi 10y ago
      Please fill me in too, possibly filling an issue on the regex repo if there's anything I can do to help. (This is the first I'm hearing of the problem.)
      - steveklabnik 10y ago
        I had only heard of it second hand; I thought it was already communicated upstream. Oops!

msie 10y ago

Yeah, if your app happens to be the same on the frontend and backend.

kbenson 10y ago
There are benefits even if you aren't sharing the entire back-end. I develop an internal Mojolicious webapp, and there's been quite a few times where I would have loved to just have one or two of the backend libraries I've written available to JS, so I wouldn't have to write it again in JS or pass it to the server. Just knowing that I could write it once and have it be the same in both places, even if I changed it later, would be a real boon.
- paulddraper 10y ago
  Exactly. Everytime I write a feature, I have to decide whether it's a backend feature or a frontend feature. Sometimes I get it wrong. I'd like to not lock myself into my choice.

Cyph0n 10y ago

That's a better fit for Scala imo. ScalaJS is great as is, and I'm sure a wasm Scala backend would be amazing. Rust is way too low-level for that imo. It works for Emscripten because of legacy code, but Rust is still ways off in that regard (i.e. adoption).

danjoc 10y ago
My impression was that wasm doesn't provide GC. Since Scala needs GC, Rust seems better positioned to have a first mover advantage.
- Cyph0n 10y ago
  I did not know that. There is work being done in this area through the Scala Native project, so it's still feasible.
kodablah 10y ago
Having attempted this "isomorphism" across Scala and ScalaJS, it is not quite that easy. That goes for all setups (node -> JS, Java -> GWT, etc) that I have tried. There are a lot of what some might call "impedance mismatches" between the two targets especially when it comes to communication and DOM work. IMO only frameworks/middleware built to bridge the gap will make it seamless.
- premium-concern 10y ago
  In my experience Scala(.js) works way better than "(node -> JS, Java -> GWT, etc)". There is a large gap between those and the way Scala _just works_ across platforms. The huge difference is that you can depend on libraries and have them "just work" regardless of whether they are implemented identical on each platform, or need specific variations to implement the expected features. Neither JS/Node nor Java/GWT have that.

15155 10y ago

> using asyncio Don't hold your breath. Unfortunately, the community seems to be going the way of Ruby/Python/C++: massive fragmentation.

steveklabnik 10y ago
What evidence do you have of this? Almost everyone is rallying around tokio.
- bluejekyll 10y ago
  Yeah tokio and futures-rs rock. Have there been talks of futures becoming part of std?
  - steveklabnik 10y ago
    Many feel that it's likely that the future trait itself could become part of libcore. It's still far too early days to tell, though.
    - 15155 10y ago
      > the future trait itself could become part of libcore _Please_ make this so. > still far too early I've waited 3 years, more time probably couldn't hurt.
- 15155 10y ago
  > Almost everyone is rallying around tokio. Sure - just as everyone "rallies" around EventMachine in Ruby. This discussion has been going on for almost 3 years now. It's great that tokio is making community headwinds, Twisted, Gevent, Celluloid, EventMachine all did too. The problem is, they've never reached critical mass, and their respective languages refused to bless them as "official." > What evidence do you have of this? The issue is inter-library compatibility. https://github.com/tailhook/rotor https://github.com/tailhook/rotor https://github.com/tokio-rs/tokio https://github.com/tokio-rs/tokio Totally incompatible, even though they build on the same low level library. https://github.com/mitsuhiko/redis-rs https://github.com/mitsuhiko/redis-rs Oh wow, a great redis library - objectively the most popular. Completely incompatible with all of the above AIO implementations. Let's take it to the extreme: - Incompatible memcached client implementations: - https://github.com/aisk/rust-memcache https://github.com/aisk/rust-memcache (sync) - https://github.com/zonyitoo/memcached-rs https://github.com/zonyitoo/memcached-rs (sync) - https://github.com/samphippen/decachedmem https://github.com/samphippen/decachedmem (tokio, partially implemented) - Incompatible redis client implementations: - https://github.com/tokio-rs/tokio-redis https://github.com/tokio-rs/tokio-redis (async via tokio) - https://github.com/mitsuhiko/redis-rs https://github.com/mitsuhiko/redis-rs (sync) - https://github.com/AsoSunag/redis-client https://github.com/AsoSunag/redis-client - Incompatible HTTP client implementations: - https://github.com/matt2xu/async-http-client/ https://github.com/matt2xu/async-http-client/ (tokio, new) - https://gitlab.com/imp/requests-rs.git https://gitlab.com/imp/requests-rs.git (hyper, sync) - https://crates.io/crates/reqwest https://crates.io/crates/reqwest (hyper) - https://crates.io/crates/request https://crates.io/crates/request The list goes on. There are countless libraries implemented with synchronous I/O, there are countless (good) popular libraries implemented with non-Tokio-based concurrency primitives. Let me just say it: I really, really like Rust. But I cannot feasibly use it for network/server-related tasks until a single solution is blessed by the Rust team. The "let's let the community handle standardizing async IO and concurrency" approach has _never_ worked in the somewhat brief history of programming languages. A blessed solution though? - Erlang, Golang, Node/JS* All work flawlessly. I would use Rust full-time for every server-related task if I could, but I've been observing for 3 years and unfortunately haven't seen much development after the abandonment of builtin green threading. *- codestyles sometimes incompatible, but there was _never_ a litany of sync libraries or otherwise fundamentally incompatible systems.

kibwen 10y ago

The question then is whether Servo will be ready for primetime before wasm gains GC support. :)

bluejekyll 10y ago
Is a GC planned for wasm? I was hoping not.
- markdog12 10y ago
  It is, but not in the first release: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md