Hacker News Reader

Comment by dgb23 | Hacker News Reader

I didn't know WasmGC was a thing yet!

https://developer.chrome.com/blog/wasmgc/

Some things that are at first glance surprising is that GC'ed languages might ship a smaller binary, because they don't need to include the code that manages memory. (The example here was Java.)

When WasmGC is widely adopted, we might hopefully see some languages adopting it as a target instead of JS. I'm thinking of Clojure and Dart specifically but there are plenty of other languages that might benefit here.

This could also have an impact on "edge computing" (isolates etc.) down the line.

View on HN

I work on a Scheme to Wasm GC compiler called Hoot. https://spritely.institute/hoot/

Languages like Kotlin, Scala, and OCaml also target Wasm GC now.

I'm waiting for the "you should run the same code on the front-end and back-end" argument to get thrown on it's head.

golang on the back-end - golang in the browser.

I've been running Scala on both the backend and the frontend (via Scala.js) for years now. It's glorious. Unfortunately few frontend people know about it (and why would they, it's not been well marketed to them and if you don't already know the Scala tooling then it's not obvious how to integrate it into a frontend workflow).

That's already happening with j2cl

https://github.com/google/j2cl

Java everywhere.

Also j2objc

https://github.com/google/j2objc

Write the logic in java and get it on iOS, web and android.

And the dream of Java everywhere is finally realized ... not by shipping a JRE everywhere, but by using Java-the-language and parts of the JRE as a high-level specification and ahead of time compiling it to other languages. The solution wasn't bytecode VMs but multiple implementations of a high-level language.

Is this a case of worse-is-better? I think so.

VMs were fine, everyone ships a VM these days (often it's called electron). The problem was distribution, and apparently the fix is to ship a copy of your VM with each app rather than having a system-wide one. I guess that's a worse-is-better answer.

Your point is taken, but the history of Java / the JRE is important here. The JRE turns out to be an excellent (and continuously-improving) virtual machine, but a horrible sandbox.

A huge value prop for early (pre-1.5) Java was sandboxing, but it ended up being clunky, frustrating, and too slow for the browsers / dial-up modems of the era and lost its chance to be the sandbox of choice - leaving the door open for Javascript to win as the world's most widely deployed sandbox.

That would be my dream. Another comment highlights that Go's memory management may not be a good fit for WasmGC, so we may not get near-native performance, which would be a bummer.

Go also has a runtime that does non-trivial things. If it can dump the GC out of it it'll shrink, but "hello world" would still be fairly large compared to many other languages. Having no tree shaking or similar optimizations also means that using a function from a library pulls the whole thing in.

While I look forward to being able to use things other than Javascript or languages seriously confined to Javascript's basic semantics in the frontend, I expect Go to be a laggard because it's going to be hard to get it to not generate relatively large "executables". I expect other languages to be the "winners" in the not-JS-frontend race.

Go pretty much only does static linking. The whole library does not get linked for a single function

Go makes heavy use interior pointers, which WasmGC doesn't support.

This is an extremely cool project, thank you for sharing!

Edit:

I'm not familiar with scheme/guile (only dabbled with Racket and later Clojure).

Are these real bytes that behave like actual bytes when you manipulate their bits (unlike Java etc.) and are stored as actual bytes?

https://www.gnu.org/software/guile/manual/html_node/Bytevect...

Yeah, bytevectors in Scheme are just some linear chunk of memory that you can get/set however you'd like. Funny that you mention this because this is actually another area where Wasm GC needs improvement. Hoot uses a (ref (array i8)) to store bytevector contents. However, Wasm GC doesn't provide any instructions for, say, interpreting 4 bytes within as a 32-bit integer. This is in contrast to instructions like i32.load that work with linear memory. The workaround for now is that you read 4 bytes, bit shift appropriately, and then OR them together. Wasm GC is fantastic overall but these little issues add up and implementers targeting GC feel like they're not on even footing with linear memory.

As someone who jumps back and forth between Dart and Typescript fairly regularly I can’t tell you how quickly and enthusiastically I’m planning on moving more and more of my stuff to Dart. It’s a huge quality of life improvement overnight.

Do you use Flutter Web, or some other framework for web UI?

I've been keeping an eye on Kotlin's wasm compiler. It's part of their multi platform compiler platform and currently in alpha release. This wasm compiler was designed from the beginning to make use of WasmGC. So, it's one of the first proper compilers for this to emerge. I'm waiting on a few libraries getting wasm support to be able to start targeting wasm with several of my OSS libraries (e.g. ktor client is one of the blockers for me currently). Also interesting to mention that there are two wasm targets: browser and WASI.

Probably one of the more interesting things in that ecosystem is the multiplatform compose framework. This allows you to target IOS, Android, Desktop, and browsers via wasm with the same code base. I expect it will be a good 1-2 years before most of this goes mainstream. It's still early. IOS support is still in beta. But things are looking pretty promising at this point.

Worth a mention in this context because Google just endorsed Kotlin multiplatform in a big way at their latest Google IO. They were also on stage at Kotlinconf last month. And of course they originally developed Jetpack Compose for Android, which this stuff is building on.

Interesting that they developed their own compiler instead of porting the codebase to Kotlin and building on this, which is a fairly common thing to do with legacy Java code these days. Kotlin is becoming quite popular across Google's Java teams apparently. Same at Facebook and AWS.

Reply on news.ycombinator.com