Get Started with Rust, WebAssembly, and Webpack
medium.com
medium.com
Not sure why the guide is using nightly Rust, stable has worked pretty well on Emscripten for a while. If you need to pass custom linker flags(which emscripten sometimes requires) you can do it via rustflag directive in .cargo/config.
We've been using Rust + Emscripten for some cross-platfrom targets(web, win32, osx, android and linux) and been pleasantly surprised with how straightforward+stable it's been.
1: EDIT: looks like it https://github.com/rust-lang/rust/pull/42571
Those where you have a significant amount of computation. Image/audio/video processing, neural networks, text analysis, games fall there too. Generally, those things are not done in the browser currently, but wasm will change that, so I'd say it will rather open new doors then fix existing ones.
I have written large parsers and code beautifiers in JavaScript that blow the shit out of anything I have seen written in other low level languages. There are a couple of advantages that JavaScript provides for this.
First of all you get immediate execution without a separate build or compile step. You can see that execution (on really large applications) is a bit slower the first time due to JIT compilation, but successive executions are faster because the code is already compiled in memory.
Secondly JavaScript runs almost everywhere. I don't need a special run time or execution context. I can run JS apps on the command line or browser without having to push data to a server location and await a response.
Finally, JavaScript is fast now. It executes almost as fast as Java and is only about 4x-8x slower than C++.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
The biggest limitation I have found with JavaScript is memory management. Trying to parse a 180mb (or larger) XML file in my JavaScript application can result in an application crash due to excess memory requirements.
No, you can't. If you manage your code properly, you can have code without the kind of errors that would be prevented by static typing, but JavaScript does not have static typing, period. (I mean, you can have it via type annotations in comments and a separate static analyzer, but that's a type language on top of JS, not JS proper.)
> The difference is that nothing yells at you when you mess that up.
Which means you don't have static typing; static typing is when the types are statically verified prior to runtime, and something does yell at you when they are wrong.
> Instead the application just runs a little bit slower.
Performance problems are the least issue with uncaught type errors. Crashes and incorrect results are the more common results.
Using any number of languages that compile to javascript can give you just as strong typing in js as in any language.
(I will grant you that you technically don't "get" strong typing in js, but rather in the language above it - but for practical purposes, you can have a language quite like js, with "actual" strong typing).
If, in an application, all your references are of a single data type and those data types never change the types in that application are static. This remains true even though the language is not statically typed. The language may be dynamically typed but all data types are static at execution, which is what static typing is.
Also don't confuse static/dynamic type classifications for strong/weak type classifications.
> Performance problems are the least issue with uncaught type errors. Crashes and incorrect results are the more common results.
Absolutely not in this language.
Static languages don't solve the kinds of problems large projects have over small projects.
Static code analysis has its place, but it makes awfully weak guarantees itself. Can you ship a product because you got it to compile?
Larger projects of any stripe will want unit tests and other automated tests to ensure it does what it is intended to do. They're also usually going to want linters and other tools to enforce policies.
I think when you compare where you are with:
1. static language + linters + decent automated test coverage
2. dynamic language + linters + decent automated test coverage
you are in the same place.
This is useful for optimizing DOM usage, such as using a virtual dom to avoid excessive real DOM access.
So while it does not attack the bottle necks directly, it will increase the overal perceivable performance of a webapp.
Some may not get a lot of improvement, if the bottleneck is in the browser engine, e.g. DOM manipulation. But there are many where the browser engine doesn't really do much - OpenGL, audio, any internal computation, etc.
If you tried to implement OpenGL in WASM, it would be incredibly slow and take a long time to load. You will always be constrained by the browser painting the DOM, or changing canvas, whatever. You can't display info to the user from javascript without modifying the DOM.
This seems like there could be even more stuff automated.
Because Rust is statically typed, a rust-loader could "overload" import() so it initialises and extracts the exported/non-mangled function signatures and create the JS equivalents automatically.
const {add} = await import("./main.rs");
add(2,2)The Haskell crowd seemed to think that was how it would work for them: https://www.reddit.com/r/haskell/comments/5ydqrc/compiling_t...
So? To WASM, how is the GC different from manual allocation, since it's just explicit manual allocation/deallocation in the underlying runtime that gets compiled to WASM.
From what I understand, the WebAssembly team is working on their own GC and the Go team would like to use that rather than rolling their own for this target. Also, WebAssembly doesn't have threads yet, which is pretty important for Go.
In short, Go in WASM isn't there yet, but it is most likely coming at some point. I expect most popular languages will be ported to WebAssembly at some point, but IMHO Go itself is far more suited to running backend services than in the browser.
Consider WebGL, which is very impressive yet seldom used. There are some very nice demos, most of them several years old, and some half-finished indy games. Other than that, not much. Kind of like VRML.
Browsers need a "disable WebAssembly" option. It should require user interaction to turn it on.
I want to like it, and do confess it is nice way to prototype shaders.
Yet thanks to the way it works, blacklisting GPUs, it means all my mobile devices are OpenGL ES 3.x capable and yet they can hardly display many WebGL pages.
While most games just work.
Regular users won't be going into browser settings to enable WebGL content, 99% of them won't even know such configuration does exist.