[deleted]
WASM 3.0 Completed
471–480 of 520 posts
Re: WASM 3.0 Completed
#472Earlier quoted context omitted.
The answer was kind of known before hand. It was to enable the use of GCed languages like Python on Ruby to create WASM applications. Meanwhile, non-GCed languages like Rust, C and C++ were supposed to continue to work as before on WASM without breaking compatibility. This is what they seem to have finally achieved. But I needed to make sure of it. So, here are the relevant points from the WASM GC proposal [1]: * Mot…
Note that the high level language needs a sufficient abstraction in its own runtime to allow substituting the Wasm GC for the runtime’s own GC. Work has been done for Java and Kotlin, but Python, C#, Ruby, Go can’t yet use the Wasm GC.
Agreed. That's what I guessed too. WASM GC is probably a low level component which high level languages can wrap to get their native/idiomatic GC behavior.
> Work has been done for Java and Kotlin
I'm unaware of this development. What did they do? Did they create an interface to the GC specification in the draft proposal?
Re: WASM 3.0 Completed
#473[deleted]
Re: WASM 3.0 Completed
#474Earlier quoted context omitted.
I have wanted to try Chrome for the longest time but I cant justify overspending (you need a lot of memory for the modern web) and not being able to install half the Linux apps I would want OOTB (out of the box is a big deal for me). I am still shocked Google has not rubbed two brain cells together and built a serious Google ChromeOS version for developers with a real desktop environment and real access to Linux, and…
That's literally ChromeOS now, it comes with a terminal built in and you can run any Linux apps
Without doing too much fancy stuff can I just run Zed or JetBrains IDEs?
Re: WASM 3.0 Completed
#475I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.
I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more. If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actuall…
The browser has become the operating system for a while now because native OS things were too fragmented and too slow to keep pace with what people wanted.
Re: WASM 3.0 Completed
#476I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.
I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more. If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actuall…
I feel way safer using apps inside web browser than installing / executing them directly on my PC.
Re: WASM 3.0 Completed
#477Earlier quoted context omitted.
That's a different thing. There is still no string type. JS string built-ins are a kludge for web targets only.
Just reimplement those JS string builtins in another host environment and provide it as a Wasm library. Stringref was basically just proposing pushing JS strings down into Wasm, which many in the CG saw as a big chunk of one specific platform just moving down a layer, into the engine.
Having used and implemented stringref and having seen the built-ins proposal I really think stringref is a much better developer experience and the CG is wrong. The built-ins are better than nothing but it's a terrible hack.
Re: WASM 3.0 Completed
#478Re: WASM 3.0 Completed
#479Earlier quoted context omitted.
...in WASM you also call a function to do IO though? That function is just provided by the host environment via the function import table, but conceptually it's the exact same thing as a Linux syscall, a BIOS int-call or calling into a Windows system DLL.
As long as that function doesn't receive any parameter that is like any data actually on the DOM. So you either create a very concrete JS library that translates specific WASM data into IO actions, or one that serializes and deserialize everything all around but can be standardized. At this point, none of those options are much more capable than Java applets... Or, in fact, if you put a network call between the WASM…
That's not really much different from writing a language runtime for any other OS. If you're writing the Linux or Windows IO routines for say Haskell or Python or Scheme, you're writing them in C, and then you either call into them from the language's FFI or invoke platform ABI calls into the runtime from the compiled code.
Re: WASM 3.0 Completed
#480Earlier quoted context omitted.
Non-GCed languages will continue to manage memory themselves. Previously, GCed languages that wanted to run on WASM had to have an implementation of their runtime including GC compiled to WASM. The idea or hope here is that those languages can use the built-in GC instead and slim down the amount of WASM that needs to be delivered to run the application to only include a minimal runtime. The current scenario is closer…
This will probably benefit Java applets targeting Wasm the most considering the huge size of their JVM.
Hopefully Go as well.