3 ms·

There are already talks about compiling Go to wasm: https://github.com/golang/go/issues/18892 https://github.com/golang/go/issues/18892

• stymaar 10y ago
  I'm not sure I see any interest in that tbh: what's the point of porting a memory-safe (with GC and runtime) on a VM especially dedicated to remove the costly memory safety part of JavaScript. Plus, the concurrent model of Go doesn't really shine if you run it in a single threaded configuration (which is most likely to be the case in wasm). I might be missing something but to me it sounds like pure hype to put go and wasm together.
  • themihai 10y ago
    >> I'm not sure I see any interest in that tbh: Running other languages(than JS) in the browser is interesting for sure.
  • bradfitz 10y ago
    You're confusing concurrency and parallelism. Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code.
    • stymaar 10y ago
      > You're confusing concurrency and parallelism. I'm not, it's just that the most appealing feature of Go is it's ability to use parallelism for concurrency with a decent overhead, which makes it straightforward to scale vertically. > Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code. IMO, Async/await is a much cooler pattern than Goroutine + channels do do concurrent stuff on one thread. I find it way easier to use, and less error prone. The drawback is that you need a different paradigm when you want to take advantage of parallelism. Of course it's a matter of personal preferences, but the prevalence of async/await in different programming languages indicates that at least I'm not the only one thinking this way :).
      • emn13 10y ago
        async/await is possibly simpler to implement. At least: in go effectively every method is async (at least the api doesn't show what is and is not), and that means you can't afford the inefficiencies that typical async/await implementations have because you'd be paying them all over the place.
  • rubber_duck 10y ago
    >what's the point of porting a memory-safe (with GC and runtime) on a VM especially dedicated to remove the costly memory safety part of JavaScript. a) binary portability - compile and ship WASM link/run on any machine with WASM VM - eg. package up to NPM and run trough any V8 target b) extra sandboxing layer for security (it's designed for browsers where you are supposed to run non-trusted code) c) portable APIs (assuming WASM targets expose the same underlying platform like node or w/e) d) WASM is single threaded right now but from what I've seen it's a top priority for next release to spec out shared memory threads
    • stymaar 10y ago
      I agree with d), but I'm quite skeptical about the other 3. a) and c) means it's portable on everything a JS VM runs on, which is not that much more than what Go runs on. b) is legit, but that really sounds like an overkill.
      • rubber_duck 10y ago
        Well a) and c) also means you can run in the browser - client/server code sharing and such can be a really big win.