><i>the initial version of WebAssembly is a terrible target if your language relies on the presence of a garbage collector.</i><p>Lack of GC was one of the appealing parts of WASM to me. Keep it simple. It is good to be careful about utilizing memory on your visitors machines, so you better spend a lot of thought on memory management.
Andy Wingo's blog is awesome. A great resource for those interested in PL design and development. I learned a bunch of stuff about delimited control from this blog, among other things.<p>Also, Andy implements delimited control in this post! What a legend
Rust targets WebAssembly, which apparently works well because Rust is not garbage-collected.<p>When will WebAssembly get real threads, not just shared memory between processes? I've seen articles from years ago talking about it as a future feature. Current status?
I would refer to Kelsey Hightower's random twitter space[1]. The last 15 min will do.<p>On paper it's nice and all but it's just not there yet. I've seen so many hype around WASM since 20 but the promised vision is always "any time soon", this triggers my hype alarm a lot.<p>Say what you will about Frontend/js ecosystem, at least most js project tells you exactly what value it will bring within 3 screen scrolls. I believe it's better for rest of the SWE community take a page or two from js.<p>[1]: <a href="https://twitter.com/kelseyhightower/status/1636786572673814528" rel="nofollow">https://twitter.com/kelseyhightower/status/16367865726738145...</a>
cloudflare did a piece on how WASM supports it. ~18% of all websites on the web run through cloudflare.<p><a href="https://blog.cloudflare.com/big-pineapple-intro/" rel="nofollow">https://blog.cloudflare.com/big-pineapple-intro/</a><p>(I'm not a software developer)
It seems this is the current doc about the GC:<p><a href="https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md">https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP...</a><p>Looking at the "instructions" section... is it going to be slow again, bringing back the speed of interpreted code to the WASM?
This is awesome, always great to read Andy Wingo blogposts.
Eager to see what the future of Scheme in Wasm looks like!<p>Here's a bit more or info on the Spritely side on why they want Scheme in Wasm (it's both funny and great to see how the money on decentralized/web3 projects is leaking back to the real world!)
<a href="https://spritely.institute/news/guile-on-web-assembly-project-underway.html" rel="nofollow">https://spritely.institute/news/guile-on-web-assembly-projec...</a>
All I hear when someone writes "WebAssembly is coming" is "more RCE exploits are coming - via the thousands of lines of new code I have to hook up to the Internet by using a browser".<p>The industry has barely finished debugging the monstrosity that was browsers before - XML, JavaScript, CSS, WebGL, WebRTC, ... so now let's add another giant source of security issues to them!<p>When will this madness stop? When will browsers actually be capable of doing <i>enough</i> and be moved into maintenance-only mode where only security issues are fixed and no new code is added?<p>Surely some will say "well, WebAssembly will deliver that precisely - browsers now can run <i>all</i> the code".<p>But wasn't this the promise with JavaScript already, a Turing-complete language in the browser to end the need for more features of HTML?<p>Anyway, to deliver some value by this comment:<p>To disable WASM in Firefox, set "javascript.options.wasm = false" in about:config.<p>Some websites say you also need to set "javascript.options.wasm_baselinejit = false" and "javascript.options.wasm_ionjit = false" but I don't understand what the point of disabling JIT would be if the whole of WASM is disabled anyway?
>" Where are the F#, the Elixir, the Haskell compilers? "<p>I think it makes a lot of sense sense to target WebAssembly with high performance "native" languages like C/C++/Rust/Zig/etc for certain types of apps looking for high performance computations. As for the rest it is simpler to just use JavaScript as the browser already makes a great platform for it.
A place where this is relevant that hasn't been mentioned so far is in proxies using the ProxyWASM spec. Instead of loading random libraries into the main code of say, Envoy, you instead load it as a WASM module (so you must target WASI or wasm32-unknown) and all you're allowed to do is specify a set of pre-determined entry points for when traffic connects, sends headers, sends body, and on the return path responds with headers, then body and then disconnects. This means that you can do practically all the things you need to do in a pretty portable way, without breaking into the actual program.
It's been so long since webassembly was announced, I don't remember why I was ever excited about it. I don't think it serves much of a purpose in 2023, as Javascript JITs are quite fast.
How do browser standards work w.r.t ensuring things like wasm are still here and functional in 10 years time? What if our friends at Google, controllers of the most popular browser, decide they can't be bothered with WebAssemnly anymore? I'm extremely wary to invest resources in things they control. I know they don't technically have control here, but is there any cause for concern?
One question that really bugs me the the sandbox security model. I'm sure the model protects us from memory and IO hazards. But, what about CPU-time sharing protection? I have yet to know if WebAss (or any abstract machine out there) could provide protection from a rouge module, running at 100% CPU in an infinite loop. I'm sure a true virtual machine could limit such thing.<p>Edit: spelling
Sorry for the noob question but what can you do with web assembly that you wouldnt otherwise do with other web frameworks? What are people using web assembly for generally?
Can we bring back java applets? It was unsafe back in the day, but if we can do wasm surely we can do applets? Lots of good languages and libraries for jvm.
WASM was cool but then all the trouble came. I am more reluctant to use WASM in production today than a couple of years ago. Seems like the biz agrees...