WebAssembly/Rust - and now?

Yes that makes a lot of sense. People who could use Rust can continue to write their C programs for another 3-4 years until Rust reaches some kind of usable state for low level stuff and people who write "hello world" scripts and implement doodle jump in webgl can use a crippled version of Rust to compile their Rust/C/JS/Macro code to some stack based byte/shitcode :slight_smile:

If I filter out some of the sarcasm there, then yeah, pretty much...

If you need to use C for your project, then use C. Sure is great that you have that option.

And yeah, if I was going to implement doodle jump in webGL, I personally would rather do it in Rust. And I can now. That's cool.

I think it's misguided to assume that if the core team decreed with an iron fist that WebAssembly work was done, that all the people contributing to that would immediately redirect their effort to whatever it is in particular that you care about.

If Rust is unusable to you, that's not the fault of the work done to support WebAssembly.

5 Likes

This would give us a nice fancy memory safe isolated Doodle Jump version, running on top of 30 years old core infrastructure, maintained by 2 long bearded guys in a garage :slight_smile:

Sure pal.

Don't really care where it's running or whether the memory safety matters. Just prefer to write Rust code.

(Also I made some other points which I think were more relevant to your argument, not sure why you zeroed in on this quote.)

3 Likes

I’m very excited about the work @alexcrichton, @wycats & co. are doing with WASM and Ember:

2 Likes

Today this may be true, but tomorrow webasm will have threading and inter-thread communications. Rust's thread safety guarantees will help you make the most of those potential performance improvements safely and easily.

I'm sure someone somewhere said that for each 100ms faster a website was it added on X$ profit. If time is money then rust wasm will pay for itself very quickly.

1 Like

FWIW, you don't need to wait for Wasm to get DOM access, in order to get strong static typing for web frontends.
I'm using PureScript in production at my job for web frontends, with Rust in the backend.
It's like Haskell but strict instead of lazy, and compiles to readable JS.
And I'm using this to generate PureScript types from my Rust types.
PureScript has type-classes, row polymorphism, monads, do-notation etc. all the good stuff that Elm lacks.
So PureScript apps don't need the boilerplate that Elm requires.
Elm components don't own their state, the main App owns all the state so it requires a lot of communication to change the state, it has to be threaded through the whole hierarchy, and the lack of type-classes/traits makes everything very verbose.
After being fed up with Polymer, I tried Elm for a week but then was fed up with it too and switched to PureScript, it's very enjoyable to use but I'm also looking forward to using Rust for the frontend to be able to re-use more code etc.
Wasm has no native dom access yet but with stdweb and yew it's already possible to write web frontends in Rust. (The reason why I chose PureScript for the web app at my job is that yew was fairly new and we had to support IE11 which doesn't support Wasm, and the app compiled to asm.js would probably be too slow/big.)

Btw, you can learn PureScript from the free book without having used Haskell before.
Since PureScript is a general purpose language, there exist different UI frameworks (unlike Elm with the one-and-only Elm architecture). The most powerful UI framework (and the one most people (incl. me) are using in production) is Halogen, which has a true component architecture where each component owns and manipulates its own state.
The PureScript community is very active in the #purescript channel on the FP slack.

1 Like

In your opinion, is the performance of frameworks like halogen noticibly worse? Last time I checked benchmarks, Elm was very efficient while Halogen was a bit slower than react. That initially turned me off from PureScript (though I do agree Elm can be very verbose).

Before I started with PureScript, I also looked at the benchmarks, e.g. this one:

But even though PureScript wasn't the fastest in that benchmark, I can't complain about its performance in my huge real-world app, also on IE11 and mobile.
IIRC, the PureScript compiler is optimizing the code now more than when this benchmark was done, also note:

Halogen optimizes for efficient deep updates rather than updates from the root, which is the opposite case from what this benchmark is designed to test.

In Elm, every change of state triggers a dom re-render from the root. In Halogen, it only triggers a re-render of that component. Which means, local changes render much faster than rendering the whole app. And local changes are much more common in real-world apps.

Comment by Nate Faubion: PureScript will never be as fast as optimized JS, but if you build a test that optimizes for the cases this test runs, it can be pretty fast. Halogen uses components to thunk [instead of referential thunking, like Elm]. There’s not a reason to implement referential thunking, which is only an optimization when you are diffing the tree from the root on every change.

So the benchmark is biased towards Elm, and not reflecting real-world apps. Also:

Halogen applications can optimize for speed by focusing on the changes made in components and avoiding overly flat & broad structures.

I didn't even have to pay attention to how nested or flat my app became, because it naturally became hierarchical by re-using components.. But I also have pages that contains long lists/tables, and they also get rendered very fast..

So I would totally recommend PureScript over Elm :slight_smile:

Btw, the company SlamData is probably the most well-known in-production user of PureScript, and they contribute a lot to the ecosystem.
They also wrote PureScript bindings to the echarts library for their analytics platform, which I'm also using in my app.

1 Like

Isn't this how Elm ensures the model does not get out of sync from the view?

Thanks for the in-detail synopsis! Definitely makes me want to give PureScript another shot.

@stevensonmt Yes but it's not the fastest way to do things. It's slower when most state changes are local to some component (which is usually the case in real-world apps). Halogen will only re-render the dom of that component, and doesn't require re-rendering from the root on every localized state change, because it has a true component architecture. The benchmark makes Elm look faster because it always re-renders from the root, but that's not what happens in real-world apps..

Right but I don't think it's quite fair to point out that Elm might be at a speed disadvantage without mentioning that this was an intentional design choice in favor of more safety.

What do you mean by "more safety"?

Maybe safety isn't the right term. Assurance of consistency of state might be the better term.

What do you mean by "consistency of state"?
Do you mean that the view always reflects the state?
The UI frameworks in PureScript (like Halogen) all ensure that!

In Halogen it works like this:
Every component has an eval function and a render function.
The eval function dispatches query messages on that component (not just input messages, but they can also return values, that's why they are actual queries), and it uses a monad stack that includes the State monad, so when your eval function modifies the component's state, it automatically re-renders that component's DOM afterwards.

E.g. check out the PureScript version of the TODO example of my web-view crate.