There are still some commits under review. I would wait until the tracking issue is closed.
Go gets preliminary WebAssembly support
41–50 of 99 posts
Re: Go gets preliminary WebAssembly support
#42What are the challenges to provide a standard GC interface that all managed languages can leverage.
Tracing objects in the heap (and/or stack). The GC has to be able to find all the outgoing pointers from any object, and usually the types of the objects pointed to by those pointers as well. Different language runtimes store objects in memory in different ways.
I think the interface can provide the semantics - pass by reference or value etc. Which can be standardized. Then it is upto the languages to implement the interface.
IMO the languages designers and developers are better off by looking at the GC solution from top-down rather than bottom-up.
Re: Go gets preliminary WebAssembly support
#43How are features like go routines and channels etc going to be supported? or they are not?
They are supported. Similar to how they're supported on other architectures, by having a runtime with a scheduler.
Re: Go gets preliminary WebAssembly support
#44How are features like go routines and channels etc going to be supported? or they are not?
Dig a little deeper: https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0... Mentions: > Currently WebAssembly has no threads, but they are on the roadmap. Most Go code can run fine on a single thread. The only drawback is that “sysmon” is not available, thus there is no preemption of goroutines.
"thread" here refers to logical thread. A single logical thread can be used to run any number of goroutines, just one at a time.
Re: Go gets preliminary WebAssembly support
#45Can this be used with CGO_ENABLED=1 if CC is emscripten?
In theory (if someone does the non-trivial work), probably.
Re: Go gets preliminary WebAssembly support
#46Earlier quoted context omitted.
Split stacks are no longer used, as of Go 1.3 (2014).
Off topic: is it possible to build a JIT compiler for Go or does the runtime prevent that?
I think it's certainly possible. The Go compiler is AOT and there are Go interpreters (in various stages of completeness), it would be a matter of interpreting the application - finding hot functions in execution traces - and swapping them out with background-compiled versions.
Some work would be needed to keep the GC happy between interpreted and compiled functions, but no more complex than JS JITs have to do. Go's GC at least already has the capability to move objects, that's a help.
In reality, JITs are used to infer typing information that dynamic languages only discover at runtime. Go doesn't have this problem, and an AOT can probably discover stronger optimizations.
Re: Go gets preliminary WebAssembly support
#47I really wish WebAssembly did not use the word "Assembly". It doesn't really resemble any actual assembly language. And if you look at the comments in this thread, for example, a lot of people think it's letting you have something like arbitrary machine code.
I really wish WebAssembly didn’t use the word “Web”. Its best usecase is for the server. It just happens to also be great for challenging JavaScript in the browser.
It doesn't challenge JS in the browser, it augments it.
Though I guess you could say it challenges stopgap measures like asm.js.
Re: Go gets preliminary WebAssembly support
#48Re: Go gets preliminary WebAssembly support
#49Will the binaries be compiled for size optimization, or will they be the same size as usual golang bins? Go binaries, being static and embedding the whole go runtime, tend to be quite big. Now, I don't care about it because 5 or 10MO on my server filesystem is nothing. If I ask every visitor to download 10MO before running my webpage, that will be a problem, though. Is this something we will have to deal with? Or wil…
If you read the document link seen in the article you will see that one of their priorities is focusing on efficiency and size output of wasm.
Re: Go gets preliminary WebAssembly support
#50This is great; looks like it's still fairly rough but interesting that GC languages are making due with what's there in the MVP of WebAssembly right now. Wonder how it works? does it use the regular call stacks or construct it's own and so on?
From this: https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0... > Go’s garbage collection is fully supported. WebAssembly is planning to add its own garbage collection, but it is hard to imagine that it would yield a better performance than Go’s own GC which is specifically tailored to Go’s needs. Presumably a runtime will be compiled into the wasm output, including Go's garbage collector.
But Go's garbage collector can't traverse the DOM.