0 - https://github.com/WebAssembly/proposals
1 - https://github.com/WebAssembly/threads
I did a glancing read of the overall spec a while back and I remember seeing a few asides to the effect of "we'll have to tackle this as part of the threads effort."
Take it with a grain of salt though, I'm still digging into this stuff.
Learning Rust at the same time as Rust+WebAssembly might be a bit of a reach, though.
I don't do well with example-driven documentation like these. Resources like the original rust book are excellent though.
Here's one guide: https://hackernoon.com/compiling-rust-to-webassembly-guide-4...
You can just target WebAssembly like this:
cargo +nightly build --target wasm32-unknown-unknown
# Install support for "wasm" command for cargo:
cargo install cargo-wasm
# Install wasm target and wasm-gc tool:
cargo wasm setup
# Create new wasm project:
cargo wasm new hello_world
# Build and run wasm project:
cargo wasm run
"WebAssembly is being designed to support C and C++ code well, right from the start..."
It's output files are very small (~1kb for the toy examples), as it does dead code elimination, which is missing from the mainline Go approach (for now).
Both Go and TinyGo are in very early stages of their Wasm support though, so things are changing and updating fairly quickly. :)
For Wasm output? It really doesn't seem like it. Output binaries from the mainline Go compiler (atm) are ~2MB. Most of which is dead code.
C# doesn’t get a lot of love on HN, but we’re launching our first Blazor app in production this week and it’s been pretty easy to use.
With garbage collection support landing in WebAssembly we might see compilation of .net IL to WebAssembly, but that’s still out in the future.
There are a lot of pros & cons here to this way. Some pros are a fast initial render & small amount of bytes needing to be sent. Cons are you need internet access & render changes aren't as fast as client side.
This biggest pro I see though is being able to develop a front end app that you can later switch to Blazor/Web Assembly with the client taking over part of the logic when Blazor & Web Assembly are less experimental. For internal apps, or apps where you know the internet/network connection should always be good, this is a great way to go.
It’ll make its way into .net core 3.0, so I think it’s more than just a poc.
It’s early of course and not very flexible, if you want to build something it wasn’t meant for, it breaks.
Like a lot of things these days, Blazor has a website way more polished than the actual product. It's very interesting, but I'm surprised you find it ready for use in production.
Rust has a similar footprint at first sight but can be shrinked significantly:
wasm-gc test.wasm # 1.7MB -> 100 bytes
IMHO the rust language is quite ugly, so you might take a fresh look at c++ which became surprisingly readable with its new features (auto, initializer_lists, nice for loops, ...)
This way you can create production-ready code and be ready to move to WebAssembly as soon as it gets feature ready.
The fine control that C++ offers will help you to understand the underlying architecture and put its performance to test.
Adding multi-threading support for WebAssembly is on the roadmap for 2019.1
> Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre. Chrome re-enabled it in v67 on platforms where its site-isolation feature is enabled to protect against Spectre-style vulnerabilities.
- Site Isolation (https://www.chromium.org/Home/chromium-security/site-isolati...)
- Cross-Origin Read Blocking (https://www.chromium.org/Home/chromium-security/corb-for-dev...)
Other browsers are working on rolling out other mitigations they consider security-critical before being OK with re-enabling SharedArrayBuffer.
tl;dr if WASM shared memory is specified to follow the same rules as SharedArrayBuffer, then atomic operations are sequentially consistent. Normal memory accesses in the presence of data races may be inconsistent, but they are still constrained (e.g. they must obey happens-before relationships).
WebAssembly threads mostly depend on SharedArrayBuffer, which was yanked by everyone for security reasons. Chrome rearranged their browser memory model and re-enabled it, which let them deliver this feature while everyone else still has blockers.
> why not pull a Google security style blog post exposing it
Because I don't think publicly exposing specific security problems in shipping software is necessarily the right thing to do.
I'm no security engineer, but isn't it best practice to expose security risks instead of letting them get knowingly exploited, especially if the parent company considers it designed as intended?
There are times when "screw you, I'm going public with this" is in fact the right thing to do. Again, in this particular case I don't think it is.
As other people already wrote, it was disabled at the beginning of the year because of timing attacks related to
Spectre and Meltdown. Details at https://blog.mozilla.org/security/2018/01/03/mitigations-lan...
We had this thread on HN about multithreading Rust with WASM https://news.ycombinator.com/item?id=18283110
I’m assumming all the typical threading problems are inherited by design such as the potential for deadlocks, memory corruption, priority inversion...etc?
Also I’m assumming these threads will allow true parallelism to occur?
But yes, it's basically good old pthreads in WebAssembly, with all the snake pits that implies. Although I would hope the runtimes will be robust enough that this can't take out the browser when you trip over a concurrency bug.