5 ms·

I didn't know WasmGC was a thing yet! https://developer.chrome.com/blog/wasmgc/ https://developer.chrome.com/blog/wasmgc/ Some things that are at first glance

by dgb23 2y ago

I didn't know WasmGC was a thing yet! https://developer.chrome.com/blog/wasmgc/ 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.

mdhb 2y ago
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.
- alexhutcheson 2y ago
  Do you use Flutter Web, or some other framework for web UI?
davexunit 2y ago
I work on a Scheme to Wasm GC compiler called Hoot. https://spritely.institute/hoot/ https://spritely.institute/hoot/ Languages like Kotlin, Scala, and OCaml also target Wasm GC now.
- dgb23 2y ago
  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/Bytevectors.html https://www.gnu.org/software/guile/manual/html_node/Bytevect...
  - davexunit 2y ago
    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.
- avisser 2y ago
  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.
  - Tyr42 2y ago
    That's already happening with j2cl https://github.com/google/j2cl https://github.com/google/j2cl Java everywhere. Also j2objc https://github.com/google/j2objc https://github.com/google/j2objc Write the logic in java and get it on iOS, web and android.
    - svieira 2y ago
      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.
      - lmm 2y ago
        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.
      - bradleybuda 2y ago
        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.
  - biomcgary 2y ago
jillesvangurp 2y ago
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.

by dgb23 2y ago

mdhb 2y ago

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.

alexhutcheson 2y ago
Do you use Flutter Web, or some other framework for web UI?

davexunit 2y ago

I work on a Scheme to Wasm GC compiler called Hoot. https://spritely.institute/hoot/ https://spritely.institute/hoot/ Languages like Kotlin, Scala, and OCaml also target Wasm GC now.

dgb23 2y ago
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/Bytevectors.html https://www.gnu.org/software/guile/manual/html_node/Bytevect...
- davexunit 2y ago
  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.
avisser 2y ago
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.
- Tyr42 2y ago
  That's already happening with j2cl https://github.com/google/j2cl https://github.com/google/j2cl Java everywhere. Also j2objc https://github.com/google/j2objc https://github.com/google/j2objc Write the logic in java and get it on iOS, web and android.
  - svieira 2y ago
    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.
    - lmm 2y ago
      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.
    - bradleybuda 2y ago
      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.
- biomcgary 2y ago

jillesvangurp 2y ago

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.