11–20 of 87 posts
One of my favorite ways to learn a new language or framework is via "koans"[1], which this reminds me of. It's a gentle ramp up from basic to advanced features, and the TDD-like workflow of seeing a test fail, understanding why, and fixing it, is really conducive to learning, while giving you that dopamine jolt from "a-ha!".
[1]: https://github.com/ahmdrefat/awesome-koans/blob/master/koans...
While it's an interesting (and effective) approach to learn something, what is the point of learning WebAssembly? After all, I thought that WASM was supposed to be something like "LLVM for web", a low-level IR for webdev languages to target and for browsers to execute efficiently, and not something that you'd write manually. Or am I wrong?
Author here! My initial motivation to learn WASM (as someone from a primarily web background) was that I had a pretty poor understanding of WASM in general and so I had a lot of difficulty working with WASM builds in just about any capacity other than a heavy JS wrapper. There are aspects to how WASM works that are quite different from other kinds of assembly formats that make learning the basics pretty important. e.…
While it's an interesting (and effective) approach to learn something, what is the point of learning WebAssembly? After all, I thought that WASM was supposed to be something like "LLVM for web", a low-level IR for webdev languages to target and for browsers to execute efficiently, and not something that you'd write manually. Or am I wrong?
That's a record with 3 fields, its constructor and getters using the GC extension:
;; A `struct` with 3 fields, all immutable.
(type $testStruct
(struct
(field $first i64)
(field $foo f32)
(field $baz f64)))
;; Constructor. `ref` is a reference
(func $mkTestStruct
(param $a i64) (param $b f32) (param $c f64) (result (ref $testStruct))
(struct.new $testStruct (local.get $a) (local.get $b) (local.get $c)))
(export "mkTestStruct" (func $mkTestStruct))
;; Getter function for the three fields:
(func $getTestStruct1 (param $rs (ref $testStruct)) (result i64)
(struct.get $testStruct 0 (local.get $rs)))
(export "getTestStruct1" (func $getTestStruct1))
(func $getTestStruct2 (param $rs (ref $testStruct)) (result f32)
(struct.get $testStruct 1 (local.get $rs)))
(export "getTestStruct2" (func $getTestStruct2))
(func $getTestStruct3 (param $rs (ref $testStruct)) (result f64)
(struct.get $testStruct 2 (local.get $rs)))
(export "getTestStruct3" (func $getTestStruct3))Pretty cool. I haven't really explored WASM hands-on (I'll give this guide a try) but, given that it's already been a few years, I think it's been hugely beneficial for web development. Not the "JavaScript killer" some where hoping for, though it was never meant to be one. Instead it integrates pretty nicely within the existing ecosystem, optimizing existing use-cases and allowing new ones when heavy computations are…
I've been watching WASM from afar, and it's my understanding that it's not a JS killer because it doesn't have direct access to the DOM or to most DOM APIs. I'm curious if there's another reason I'm missing?
And currently using anything but C, C++ or Rust isn't feasible, as the runtime needed for a GC is way too big. A Haskell "Hello World" for example is about 1MB (even after running `wasm-opt` on the generated WASM binary).
While it's an interesting (and effective) approach to learn something, what is the point of learning WebAssembly? After all, I thought that WASM was supposed to be something like "LLVM for web", a low-level IR for webdev languages to target and for browsers to execute efficiently, and not something that you'd write manually. Or am I wrong?
Sometimes you may need to debug the actual wasm code or understand what the compiler is outputting. Depending on the flags you set during compilation, you may want to optimize for size of binary or for performance. You may also want to compare the wasm produced by two different languages or different versions of the language compiler. Maybe you want to verify what libraries are actually getting bundled with your wasm…
By limitations I mean things that a POSIX program would expect that aren't generally available from WASM, like network programming, file system access, processes and threads, pipes and signals. Emscripten and WASI help to some extent, but the replacement APIs are rarely fully compatible.
This is great, thanks! One of my favorite ways to learn a new language or framework is via "koans"[1], which this reminds me of. It's a gentle ramp up from basic to advanced features, and the TDD-like workflow of seeing a test fail, understanding why, and fixing it, is really conducive to learning, while giving you that dopamine jolt from "a-ha!". [1]: https://github.com/ahmdrefat/awesome-koans/blob/master/koans...
Earlier quoted context omitted.
I've been watching WASM from afar, and it's my understanding that it's not a JS killer because it doesn't have direct access to the DOM or to most DOM APIs. I'm curious if there's another reason I'm missing?
It doesn't have access to _anything_ (in the browser, in other runtimes there is WASI with POSIX functions). Everything has to be imported from or exported to JS. And currently using anything but C, C++ or Rust isn't feasible, as the runtime needed for a GC is way too big. A Haskell "Hello World" for example is about 1MB (even after running `wasm-opt` on the generated WASM binary).
This is kind of subjective, and in the context of "is this a JS killer" which is what you're answering, I'd agree, it makes sending the Wasm to the browser a bit of a non-starter that it requires a large bundle most of which is simply boilerplate for whatever runtime, without some type of local storage and persistent cache it's difficult to imagine using Ruby in a Wasm for example. If you're deploying to a container, where you're able to use a cache warmer to ensure the wasm is ready before it's called, then a 1mb binary might not be such a big issue.
(I mean, it is still a big issue because the point was fast cold starts, and big assemblies mean no fast cold starts, but again, subjective value judgments... 1mb isn't too big in many cases and I'd wager most of the cases that I'd really care about. But in a browser...)
But if you're not trying to run the Wasm in a browser then it's still potentially quite useful. You might not be running all of your Wasm in a browser and it might still be a JS killer, and all of those might not be in conflict.
While it's an interesting (and effective) approach to learn something, what is the point of learning WebAssembly? After all, I thought that WASM was supposed to be something like "LLVM for web", a low-level IR for webdev languages to target and for browsers to execute efficiently, and not something that you'd write manually. Or am I wrong?
Eventually I moved the whole game engine into wasm & at that point it all got ported to Rust
https://github.com/serprex/openEtG/blob/8b7069cc52ec8db3406a...
Gave WASM a try and ran into problems exposing connections to a SQLite database I wanted to connect to locally. Has anyone done something like that before and can point to good resources?