maxgraey

Ah shit, here we go again. I just link to my previous comment which quoted in WasmWeekly News

https://news.ycombinator.com/item?id=32564105

> If you don't do frontend stuff, you don't have to use WASM, you know?

WebAssembly is excellent for:

- Game's scripting engine (UE plugin example: https://www.reddit.com/r/unrealengine/comments/na6hfx/integr...)

- Rule engine for ServerLess scenarios (See Lucet)

- For node.js plugins instead native plugins. Webpack uses AS for hash calculations: https://github.com/webpack/webpack/tree/main/assembly/hash

- For smart contracts of blockchain. AssemblyScript uses for Near Protocol, The Graph Protocol, Cosmos and many others

TypeScript has completely different goals. It will always just be a semantic checker on top of JS and nothing more. This has been mentioned more than once:

https://github.com/microsoft/TypeScript/issues/9202#issuecom... https://github.com/microsoft/TypeScript/issues/10386#issueco... https://github.com/microsoft/TypeScript/issues/375#issuecomm...

The main advantage of using Binaryen directly bypassing LLVM is firstly very fast codegen and optimization (Binaryen architecture perfectly utilizes multithreading as opposed to LLVM). In addition, clean and fast debug builds are not clogged with SSA and mSSA noise. That makes debug/release performance not more than 2-4x slower, unlike LLVM where this ratio is 20x-40x as already mentioned. The Binaryen optimizer is improving all the time. It is already better in many places than the same Go's codegen

> It isn't designed for or suitable for large projects.

Why? The compiler itself is written in AssemblyScript and is capable of bootstrapping. The AS code base is quite large. In addition, there are other quite large projects. For example: https://github.com/acutmore/type-off. It's port of "sucrase" project (which functionally equivalent to esbuild or swc)

old topic: https://github.com/WebAssembly/WASI/issues/401#issue-8177488...

The problem with WASI is that it is a some kind of truncated copy of CloudABI and POSIX. With all the goodies like abbreviated error codes like "fbig", "idrm", "srch" and etc. See: https://github.com/WebAssembly/WASI/blob/0ba0c5e2e37625ca5a6...

The main problem of WASI in my opinion is that it's based on a standard which is 30 years old. And yes, the idea was cool, to let you run even C without having to rewrite libc. But the reality is that we can't do this now and it's still a big question whether we can in the near future. Besides, C is probably the only one that needs such a low level api, but everyone has to suffer because of it, essentially reinventing libc based on WASI with their own language runtime on top of it. This is simply a waste of binary space.

Also it lead to fragmentation into the WebAseembly ecosystem. A compiled program in wasm32-wasi cannot run in a browser, only in wasmtime, wasmer or node.js. WASI-polyfill.js is very limited, adds a bunch of kilobytes of glue code and is still not even officially introduced.

The article is relatively old. But I have the most complaints about the performance measurements. The WebAssembly should be tested in a way that eliminates the interop time, which is very expensive. That's why sorting and simple multiplication will always be slower if tested outside WebAssembly. Sorting in AssemblyScript is actually faster than in Rust or JavaScript: https://twitter.com/MaxGraey/status/1414867216676368384

> Iraq, Afghanistan, Libya, Syria, all within the very recent history, plus countless more US-backed color revolutions - including the one in your very own country, which realistically is the very reason for the current state of affairs in there.

Oh God! You and your conspiracy theories are annoying. If the U.S. is so powerful, why hasn't it organized a color revolution in Russia or at least in Serbia, maybe in pro-Russian Hungary? I was at both revolutions in Ukraine and I know why they arose, they were supported by the Ukrainian people, self-organized. And it's been like that all through our history. You don't know shit about the political situation in Ukraine and its history, but you think you have it all figured out. I'm sure you don't even know your own history. So don't talk bullshit!

> And there's been talk of exposing the JS GC to wasm for a few years. Hopefully when that stuff lands, it'll get easier to marshal objects across the gap.

You don't need a Wasm GC to do this. If you only need js objects to pass on to, say, the host's function or check is null or not, then reference types that are opaque external references: https://github.com/WebAssembly/reference-types/blob/master/p...

You can even do many more things if you export `Reflect` to WebAssembly: https://github.com/AssemblyScript/assemblyscript/blob/main/t...

Reference Types are available almost everywhere already (In Safari will be available after 15.0): https://webassembly.org/roadmap

Are you sure UTF-8 is the ideal format? After all, we have grapheme clusters that cannot be rendered as text units using UTF-8. Maybe UTF-8 is already obsolete and never took over the world? I am more than sure that soon we will see the new Unicode format ;)

So basically even in UTF8 you can create malformed string. For example ðŸŒ. It miss one byte and may cause to problems in some editors / text viewers which doesn't handle or pre-verify such cases . Valid UTF8 has a specific binary format. If it's a single byte UTF8 character, then it is always of form '0xxxxxxx', where 'x' is any binary digit. If it's a two byte UTF8 character, then it's always of form '110xxxxx10xxxxxx'. Similarly for three and four byte UTF8 characters it starts with '1110xxxx' and '11110xxx' followed by '10xxxxxx' one less times as there are bytes.

So it's not just UTF16 that has problems and can cause security problems. I just wanted to emphasize that

Yeah, WebAssembly have i64/u64 types as first class citizens unlike JavaScript which should emulate it or use BigInt which drastically slower than native 64-bit types. That's why crypto algorithms got a lot of speed benefits. AssemblyScript also show this. See this:

https://github.com/FriendlyCaptcha/friendly-pow https://github.com/hugomrdias/rabin-wasm

latest benchmarks with wasm3, wasmer, wasmtime, wavm and etc: https://www.00f.net/2021/02/22/webassembly-runtimes-benchmar...

That's true. But wasm also required some extra codegen and optimizations for i64 types for example (also simd and atomics). In addition, wasm will have more specific CFG optimizations for WebAssembly. For example https://bugs.chromium.org/p/v8/issues/detail?id=11298

It's unnecessary with AssemblyScript due to AS is just subset of TypeScript and can transpile to ordinal idiomtic javascript. Also AS already uses binaryen under the hood and can produce asm.js via --jsFile, -j command line.

Ruffle - A Flash Player emulator over WebAssembly: https://github.com/ruffle-rs/ruffle

There site which aggregate prod use cases: https://madewithwebassembly.com/

Here a great example of how SIMD brings WebAssembly closer to native speed:

https://medium.com/@robaboukhalil/webassembly-and-simd-7a7da...

WebAssembly still not reaching their full potential in browsers. For example: https://bugs.chromium.org/p/v8/issues/detail?id=11085&q=comp...

On Firefix and Safari we have the same missing optimizations. Basically wasm in all browsers reuse the same codegen from JS. But this will improved in the future.

Also, don't forget about SIMD, multi-threading with stared buffers and atomics and multi-values, a lot of special instructions like popcnt, ctz, clz, rotl/rotr and etc which not supported by JS and usually emulate not in the best way that complicates or make impossible to optimize this by the JS compiler.

In some points JS is really fast, so much that it is not inferior, for example, to the C language with the LLVM compiler without vectorization (-O2). Obviously WebAssembly can't outperform JS in such cases.

Yes, indeed. All points are valid.

Opaque anyref (externref) or reference-types WebAssembly proposal not yet in all browsers, but after it interop will become much easier. At least you don't need glue code for JS side any more.

You're right WebAssembly hasn't provide seamless interop for compound objects. AS expose special utility called loader: https://www.assemblyscript.org/loader.html#usage

There are also exists other projects which simplify this: https://github.com/torch2424/as-bind

This is a temporary limitation which mean you can't capture free vars from outer scope (except global scope). One of the main goal of AS is performance but closure elimination required some extra efforts like Middle IR, eta/beta-reductions, lambda lifting / dropping. Without all of this closures will produce significant overhead. So at first need to implement all this things

Great dev story about using AssemblyScript in production: https://engineering.q42.nl/webassembly

Not only syntax, but also standard library, ecosystem and etc. You could easily transpile AssemblyScript project to JavaScript via tsc if use portable glue code. From C it I guess it borrows AOT compilation, ability to use low-level intrinsics and more granular and sound types. Btw many people still thought AS has manual memory management, but it's not true. By default it use hybrid ARC and GC approach called PureRC: https://github.com/dcodeIO/purerc/blob/master/papers/Bacon03...

> I don't think AssemblyScript will be the answer for you, as the goals of that language seem to be entirely different from "fixing" old JS cruft. Apart from the i32, i64 stuff I guess.

Basically AssemblyScript try to fix JS runtime as well. See this: https://twitter.com/AssemblyScript/status/114604718874680934... and https://twitter.com/AssemblyScript/status/114466636945316659...

Probably Blazor is immature, but not WebAssembly? Blazor btw run in interpreted mode for CIL modules. Full AOT compilation was planned for .NET 5 but canceled. But you could check rust's frameworks like Yew. That's real world demo: https://github.com/jetli/rust-yew-realworld-example-app

> but they haven't been implemented in any browser, much less standardized yet.

Reference types already implemented. GC is not really needed for non-managed languages like C++ or Rust. Interface types in progress.

See this: https://webassembly.org/roadmap

> To get code blocks you have to indent it with four spaces

I'll keep that in mind in next time. Thanks for the tip!

Btw you could speedup your AssemblyScript code: https://bit.ly/2FW2iyN

``` const eps: f64 = 2.3283064365386963e-10; const m: u64 = 6364136223846793005; const inc: u64 = 1442695040888963407;

let state: u64 = 1;

export function random(): f64 { let oldstate = state * 6364136223846793005 + 1442695040888963407; state = oldstate; const xorshifted = u32(((oldstate >>> 18) ^ oldstate) >> 27); const out_int = rotr(xorshifted, u32(oldstate >> 59)); return eps * out_int; } ```

I recommend return f64 instead f32. This has slightly faster interop

Perhaps if you like TypeScript and still want compile to WebAssembly you might be interested in AssemblyScript which stricter subset of TypeScript which compile to wasm