61–70 of 99 posts
Earlier quoted context omitted.
Hmm, maybe language runetimes can be dynamically linked and hosted by the language maintainers. Everyone imports the official library so the odds of the user already having most of everything cached is high.
Aren't cache gained savings a myth? Browsers have cache in magnitude of tens of megabytes and most sites have different versions of everything.
Hey so question - WebAssembly can't access the DOM right? What's the whole point then, avoid Javascript? If we can't just swap out all the gnarly JS garbage whole-hog, I don't see where the business value is, given that there's plenty of language-to-js libraries.
As weird as this might sound, I see WebAsssembly more like a portable shared library format than a JavaScript replacement.
It seems running reasonml/ocaml under nodejs with wasm (and in the browser) should be a great fit for ocaml modules?
Earlier quoted context omitted.
Half the size of Go binaries you encounter in the wild are debugging symbols. Compile without them and use `upx --ultra-brute` and the binary will be about ~15% of its original size. You still get goroutine stack traces from panics without the debugging symbols.
I didn't know go compiler allowed to build without those, thanks. I've just tried on a go binary that was 2.4MO. After building it with `go build -ldflags=-s .`, it's 1.6MO. After stripping with upx, it's 480ko (and still works, and has panic stack traces).
When downloading a WASM file over HTTP, the server can gzip it transparently. It'd be interesting to compare the effects on the size with what upx does (which is more specialized than gzip).
Earlier quoted context omitted.
I didn't know go compiler allowed to build without those, thanks. I've just tried on a go binary that was 2.4MO. After building it with `go build -ldflags=-s .`, it's 1.6MO. After stripping with upx, it's 480ko (and still works, and has panic stack traces).
Please note that upx also compresses your binary contents and decompresses it at runtime. When downloading a WASM file over HTTP, the server can gzip it transparently. It'd be interesting to compare the effects on the size with what upx does (which is more specialized than gzip).
Indeed, given how browsers already handle gunziping resources, it's probably best to rely on it. My binary, stripped by the go compiler and gziped, is 525ko (against 480ko using upx).
Earlier quoted context omitted.
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.
https://en.wikipedia.org/wiki/Cooperative_multitasking
How this works in Go ? Thoroughly simplified it happens because at every flow control statement in Go, including function calls, what really happens is that, first, Go asks it's runtime to switch goroutines, and only then goes into the if, or subroutine, or ...
Earlier quoted context omitted.
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.
Every language designer would have to completely redesign it's runtime system just to be able to run on this one backend (in addition to having a new compiler target and linker and debugger and ...). Hoping, of course, that this is possible at all, as many languages have various ways to store pointers to things in memory, which including not storing one at all (ie. pointer arithmetic).
Why would they do this ? Why should they do this ? You could simply make the existing runtime libraries run.
I 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.
Hey so question - WebAssembly can't access the DOM right? What's the whole point then, avoid Javascript? If we can't just swap out all the gnarly JS garbage whole-hog, I don't see where the business value is, given that there's plenty of language-to-js libraries.
Earlier quoted context omitted.
Thus solving Go's dependency management problem once and for all.
Solving it by giving it a worse one.
Npm has issues, but it's still way better than the state of the art of dependency management in Go.
Left-pad was bad but the problem was fixed on npm's side after a couple hours. Go's equivalent isn't fixable: https://mobile.twitter.com/davecheney/status/855049071307792...
Hey so question - WebAssembly can't access the DOM right? What's the whole point then, avoid Javascript? If we can't just swap out all the gnarly JS garbage whole-hog, I don't see where the business value is, given that there's plenty of language-to-js libraries.
So there's a lot of other things that can be done on the client other than interacting with the DOM. In particular, applications that render intense graphics, or manage a local database could GREATLY benefit from more efficient compiled code, and this would open up possibilities that the current JS engine wouldn't be able to deliver.