It's not moving goalposts. If nobody is using it, not even the developers who put in the effort to make it work, it's a pretty good sign it's not a production ready solution.
Like "technically works enough for a demo" isn't what I'd call full support.
The whole point of this thread was that implementing a GC is possible with what WebAssembly provides today, no need to wait for an API that might never come.
Yes there are bugs in some implementations and others could have been better done, it happens.
Discussing technicalities of who is using what in production is moving goalposts.
Not a big fan of having lost PNaCL in favour of WebAssembly craziness, but that is what we have to work with, GC might come in 5 years time or even never, who knows.
What I know is that despite the flaws, many developers are eager to implement something with what we have now and kudos to them for trying it out.
“They did not know it was impossible so they did it”
― Mark Twain
Like, a no-op GC is a valid implementation as long as your code doesn't allocate too much in the first place. If you ran into that would you consider their implementation buggy and just give them time? Similarly reference counting based GCs _can't_ do anything other than leaking object graphs with circular references, fundamentally. It's not a buggy implementation, it's a fundamental limitation of the technique.
Also, I looked into it. PNaCl couldn't run OCaml, only NaCl. PNaCl (and wasm) doesn't really let you scan stacks, but NaCl does, so they had to drop a real GC with the semantics you'd expect on the transition to PNaCl.
"They did know it was impossible, so they didn't bother" ~ monocasa
And once again, explaining why your examples aren't valid and refuting them isn't "moving goalposts".
Sure it is, because you keep focusing on the few buggy implementations, instead of those that actually work.
There are plenty of leaking object graphs with circular references implementations in native CPUs, and yet people do use them, starting with C++ standard library collection types or Objective-C ARC.
So your point on refuting whatever I present instead of appreciating the work of the implementations that actually work is kind of moving goalposts.
Because apparently people bother with native CPU implementations, even with those bugs, so why should WebAssembly be any different?!?
You don't want to bother, fine go watch tv, play football, whatever is your fancy.
Me, I will be supporting anyone that with the WebAssembly we get to play with, decides to implement their favourite language.
Enjoying moving goalposts?