Re:Web Assembly and Go: A look to the future
by eklitzke on Sunday June 24, 2018 @01:48AM
(#17385142)
This just means you won't debug things using a browser console, but using a debugger designed for the host language instead. And that would be a blessing: I'm far more proficient in GDB than I am in the Chrome/Firefox developer tools.
Why won't WASM really work with the "source map paradigm"? Is there something fundamentally different about bytecode that means it cannot be traced back to its original source, given tooling support?
Re:Web Assembly and Go: A look to the future
by slimsag on Saturday June 23, 2018 @08:52PM
(#17384348)
WASM will have source map support, if it does not already. There is already support on Firefox nightly it seems: https://github.com/yurydelendik/wasm-source-map-emscripten
Re:Web Assembly and Go: A look to the future
by kreetx on Saturday June 23, 2018 @02:57PM
(#17382775)
But there's an upside, no? There is no way to reference an undefined variable in go? So if the compiler is correct, so will be the result, and errors would be found compile time.
(written by a non-go-expert)
While you cannot reference an undefined variable in Go, you can still dereference nil pointers and invoke other operations that result in a panic (some of the standard library functions can panic).
Instead, projects are mostly using "light" transpilers built to have clean mappings to JS semantics, like TypeScript, where the original source can be recovered and traced by the browser as long as the transpiler generates a source-map.
WASM really won't work with the "source map" paradigm, and so a move to a web where most development uses languages that compile to WASM, is a move to a more opaque, less learnable web. (And also one that browser extensions have far less of an ability to intercede in.)