Hacker News Reader

Hacker News

Comment by davexunit | Hacker News Reader

Parent Full thread

davexunit

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.

View on HN

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.

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.

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).

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.

Reply on news.ycombinator.com