3 ms·

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 br

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
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.
- jerf 2y ago
  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.
  - ptman 2y ago
    Go pretty much only does static linking. The whole library does not get linked for a single function
- ncruces 2y ago
  Go makes heavy use interior pointers, which WasmGC doesn't support.
lmm 2y ago
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).
deleted 2y ago
[deleted]

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

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.

jerf 2y ago
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.
- ptman 2y ago
  Go pretty much only does static linking. The whole library does not get linked for a single function
ncruces 2y ago
Go makes heavy use interior pointers, which WasmGC doesn't support.

lmm 2y ago

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

deleted 2y ago

[deleted]