4 ms·
The amount of vigor you espouse an opinion with is astounding relative to how little you know. The point of WASM isn't for you to hand-edit things. It's to prov
by banachtarski 9y ago
The amount of vigor you espouse an opinion with is astounding relative to how little you know. The point of WASM isn't for you to hand-edit things. It's to provide a unified IR that many lanugages can target (C, C++, Rust being just the beginning). Any language that compiles to LLVM bytecode today can theoretically target the browser now. One thing those languages I mention have in common? They don't use a garbage collector. AKA, you can now write code that will run in the browser with predictable latency semantics.
Then again, I could just be feeding a troll right now, I really can't tell.
- pjmlp 9y agoNot having a GC is just an implementation detail. Anyone can implement one and ship it with the statically compiled WASM code, it is no different than targeting an actual machine code, unless we are speaking of CPUs like Intel iAPX 432. The only issue is having a little bigger download, which is irrelevant in the age where web pages to display static text are bigger than the whole Quake installation.
- banachtarski 9y agoYes I'm aware. It's a side-consequence that I just happened to single out. GC is opt-in, not mandatory. As for the bigger download, I'm hoping we'll be able to load libraries dynamically through WASM so you can cache things like the C runtime separately
- pjmlp 9y agoAh ok, sorry I thought it was another kind of remark relating GC just because the interoperability with JavaScript's GC is not yet baked into WASM. The idea of caching runtimes looks good, but we need some kind of versioning, otherwise it will be yet another WASM.so hell. Maybe tying them to the origin would be a possible solution.