The LDC D language compiler can now generate WebAssembly | Hacker News Reader

The LDC D language compiler can now generate WebAssembly

wiki.dlang.org

165 pointsingve30 comments

Cool, great that you can now do this with LDC directly.

There was a way to compile D to WASM before (using the dscripten package), however that was more akin to a collection of loose pieces strung together.

As with Go, a big obstacle for running typical D code in browsers is reliance on a garbage collector, which requires scanning stacks and temporaries for reachable heap object. Though it's possible to overcome in theory with just compiler support, garbage collection in WASM itself seems to be an ongoing discussion.

> There was a way to compile D to WASM before (using the dscripten package), however that was more akin to a collection of loose pieces strung together.

Also carried the large Emcripten runtime. Sure it gives you a lot of things like posix impls, but the unknown triple is very lightweight (at the cost of sys/OS abstractions of course).

> Also carried the large Emcripten runtime. Sure it gives you a lot of things like posix impls

And also, SDL2 + opengl bindings. Which makes it very adapted to compiling the same project for both targets: native and web. For video games, this is a killer feature (e.g try the game in your browser, and if you like it, download the native app (smoother, less input latency)).

Please no, leave that to js.

Why can't they just let devs embed their own garbage collector? Isn't he role of an assembly language to let the developer do stuff at a low level?

I'd wager there's a lot of lower level optimisations - especially for different architectures - that you just can't get with platform agnostic 'assembly'.

I also think its better for everyone if you don't need to load/download, decode, compile and run a full language runtime on every page load. Imagine a JVM running on web assembly: Every page load first has to decode and compile a full many-MB JVM, then the JVM can start booting - without any platform/architecture specific optimizations.

The more stuff that's common for webasm-targeting-languages that we can move into the browser, the less effort wasted overall.

Somebody wake me up when we move beyond reimplementing Java applets and Flash once more. We had nice batteries-included VMs in the browser, and we turned our backs on them and went back to square one. Again, and again, and again. So we could bang rocks together with javascript.

Almost makes me wish VBScript IE had won. We might be writing browser apps in .NET now...

One might be seen as sleeping back then too if they considered proprietary, complicated, insecure behemoths with large, sometimes shitty standard libraries and forced high-level constructs as "nice batteries-included VMs".

> sometimes shitty

I still have to do .stream() and .toList() (or .collect(Collectors.toList())) back and forth in Java all the time just to get reliable access to map/filter lambdas while still having a valid return value.

Java's shittiness is a problem, but for the mid 2000s, it wasn't extra shitty in comparison. That long stagnation after 1.6 really hurt.

Flash's demise is 100% Adobe's fault. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash

Yeah, there are 1098 Flash related CVEs, but Google Chrome itself also has 1608 CVEs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chro...

Better stop using Chrome now.

Are those CVEs still active or has google/adobe fixed them already?

They generally only get published in any detail once they've been fixed.

Chrome seem to have a bunch of 2018 vulnerabilities that aren't listed here though...

Yes, the fact that Google Chrome is written in C++ is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.

Yes, the fact that the Linux kernel is written in C is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.

You can cache runtimes with IndexDB, no need to keep downloading them.

But IDB follows the same-origin policy, so you can't share the cached runtime between different apps.

At least not unless you can load it from the same public CDN.

Edit: Actully, I'm not sure you could do that even with the public CDN.

Sure, but you can cache it between invocations of the same app, meaning one can make PWAs with WebAssembly help.

I disagree, I would like WASM impls to offer one that you can optionally leverage for many reasons. Regardless, here is a recent thread that does a good job discussing pros/cons: https://github.com/WebAssembly/gc/issues/36

> Why can't they just let devs embed their own garbage collector? Isn't he role of an assembly language to let the developer do stuff at a low level?

I believe the big obstacle is that the stack is managed by the VM and isn't accessible directly (at least, in the form of one continuous memory region per thread). A likely constraint that led to this was to allow interoperability with the JavaScript stack.

The core issue is that WebAssembly VMs use the host’s native stack for return addresses and local variables, without providing wasm code any way to inspect or manipulate that data. Thus, there’s no way to scan the stack for GC roots, as would be possible in a ‘real’ assembly language. Programs do typically maintain a second, separate, stack, located within wasm-accessible memory, for things like local variables that have their address taken. In theory, you could make the compiler store all locals there across function calls; I think that might be what Go does. But that’s a performance waste. In any case, a manual approach won’t solve the use case of accessing JS/DOM objects from WebAssembly; that requires interoperating with the existing JS garbage collector.

If you and I join forces, we can get the stack exposed in WASM2. Or we can run our WASM on WASM and hope the JIT can handle the inner interpreter.

The full stack will never be exposed for safety and verification reasons, though it's possible you could get some sort of read-only stack walk primitive... it might be very slow. The wasm stack intentionally does not live in the heap so that it's impossible-ish for exploits to target the stack.

What if a complicated Javascript object is passed to WASM, and a reference stored in a WASM object? How would the GC trace the reference across the language boundary?

> There was a way to compile D to WASM before (using the dscripten package), however that was more akin to a collection of loose pieces strung together.

Indeed :-)

The toolchain building scripts were a maintainance nightmare ; I'll be happy to drastically simplify them, especially if it means I can now use the vanilla LDC compiler (instead of having to integrate fastcomp and clang-fastcomp (Emscripten's forks of llvm and clang, respectively)).

The title is misleading : only a small subset (-betterC) of the D langage currently is supported, and that's too bad!

It's a start and ideally eventually all of D will be able to run under -betterC or just enough of it at least is what I understand is the goal.

Yeah, I'd like to see some examples of passing anything other than doubles, for example Arrays, and I'd like to know how GC works after the Array has been passed, and if the Array is passed by reference (instead of being copied), and things like that.

This was already technically possible by compiling to llvm bitcode and then using emscripten to compile that to wasm (or asm.js). Still cool though!

This is great news!

Reply on news.ycombinator.com