Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASI 0.2.0 and Why It Matters

wasmcloud.com

Post reply on HN
Print view View original

81–90 of 110 posts

Re: WASI 0.2.0 and Why It Matters

#81

Post by shadowgovt »

0x457 wrote: post #76
shadowgovt wrote: post #33

At a glance (at this blog post, and at the WASI project on GitHub) I still can't quite wrap my head around what WASI is and why it matters. What problem is it solving?

WASM is a language. By itself, it's not very useful because you're limited to what language constructs provide - not much. There are extensions to the core spec for embedding wasm. For example, there is "WebAssembly JavaScript Interface" for working with wasm inside JavaScript, which is what used by browsers today. Spec we use in browser today is really just about how to interact with JS, so JS must provide everythin…

Ah, okay. That is cool. It doesn't solve a problem I have (if I'm compiling to a target outside the browser, I'm going to compile to LLVM --> native, not wasm) but I respect why that's exciting.

Re: WASI 0.2.0 and Why It Matters

#82

Post by marwis »

elviejo wrote: post #48
PedroBatista wrote: post #6

About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical p…

I'm in the same boat. I've been looking at this space since (P)NaCL With a nagging question in my mind: What does this do that we couldn't do with Java Applets? So far the response is very few things and a lot less. On the few things that it does differently is: + it focus on multi language support. as opposed to the JVM which was focused in getting all of us in writing Java. Here they want to actually use different…

Security. Applets exposed massive API surface while wasm exposes almost nothing.

Also applets were too slow to start with Sun's implementation of the day while wasm works reasonably well in all browsers from day one. That matters a lot for adoption.

JVM improved but applets missed their chance. You only get one.

Re: WASI 0.2.0 and Why It Matters

#83

Post by ramses0 »

dns_snek wrote: post #66
ramses0 wrote: post #44

Earlier quoted context omitted.

So..... think of it this way: HTML was built for the "internet", but works just as well for plain local files (eg: file:///one.html => file:///two.html). JS was added to HTML, and much gnashing of teeth ensued. JS (minified), HTML (generated), CSS (compiled), Flash, Java Applets, etc... move away from the "original" internet (Hyper-Text DOCUMENTS) into Web2.0 "Apps" and Web3.0 "Walled Gardens". What if instead of shi…

> As a thought experiment, we're almost there! We could technically have `win95.img + bochs86vm.wasm + autorun.inf + msword.exe` wrapped in a "browser evaluator" I looked into this and... holy crap! We are there. Not for modern programs quite yet, sure, but this is amazing. You can use Windows 2000 from your browser, running inside an x86 emulator for WASM. https://copy.sh/v86/?profile=windows2000

Yup! ...and noodling around with their `wordpad.exe`, you could pretty easily imagine `My Network => My Workgroup => ...etc...` to samba-share in your local filesystem (provided by the bochs86vm "container") ....... or since it's turtles all the way down, just map your local computer drive as `D:\...` and let the VM "think" it has access to all your files on the vm-local disk.

Re: WASI 0.2.0 and Why It Matters

#84

Post by rockwotj »

mc_woods wrote: post #18
rockwotj wrote: post #14

Earlier quoted context omitted.

I have compiled JQ to wasi (in terms of moderately complex ( and useful )). Took me a couple of hours, mostly because of some pthread stuff I had to noop. And that's being fixed with wasi-threads https://github.com/rockwotj/jq-wasi

unfortunately wasi-threads is deprecated. You'll need to wait for threading support from "core-wasm" and that's a while off, there is no date on the horizon for this, as far as I know. WASI-threads is not compatible with WASI-Preview2

Thanks for the correction! It's hard to track all of this :)

Re: WASI 0.2.0 and Why It Matters

#85

Post by v7n »

shadowgovt wrote: post #81
0x457 wrote: post #76

Earlier quoted context omitted.

WASM is a language. By itself, it's not very useful because you're limited to what language constructs provide - not much. There are extensions to the core spec for embedding wasm. For example, there is "WebAssembly JavaScript Interface" for working with wasm inside JavaScript, which is what used by browsers today. Spec we use in browser today is really just about how to interact with JS, so JS must provide everythin…

Ah, okay. That is cool. It doesn't solve a problem I have (if I'm compiling to a target outside the browser, I'm going to compile to LLVM --> native, not wasm) but I respect why that's exciting.

You can write a program that has the capability to run isolated WASM modules written by others, without caring about the source language. Export some functions from your host program and you have a neat system for, say, user-written extensions.

Re: WASI 0.2.0 and Why It Matters

#86

Post by MR4D »

> "The simplest “hello world” example looks like..."

And then gives code that reminds me of Enterprise JavaBeans from the early 2000's.

Thankfully, later on we get:

> "Let me show you an example of the ideal Wasm hello world application..."

And then have code that's clean, logical, and simple to read.

TBH, I almost gave up after seeing that first bit of code, but thankfully I kept reading. Having a standard interface will go a long way to creating a very nice future.

Re: WASI 0.2.0 and Why It Matters

#87

Post by jraph »

pjmlp wrote: post #54
jraph wrote: post #28

Earlier quoted context omitted.

From your first link: > Microsoft and its partners hold patents for CLI. Ecma and ISO/IEC require that all patents essential to implementation be made available under "reasonable and non-discriminatory (RAND) terms." It is common for RAND licensing to require some royalty payment, which could be a cause for concern with Mono. As of January 2013, neither Microsoft nor its partners have identified any patents essential…

Doesn't change the fact it was done before, and it is only the most recent example, plenty of bytecode formats to explore since 1958.

I'm answering a comment of yours that exclusively mentions CLI. You can't blame anyone for not reusing the un-reusable. You are not contradicting me on this so let's forget about CLI, it doesn't matter it was done before since it's not a viable option or wasn't at the time WASI was being created. Or actually refute this if you think this is wrong.

Now, you are extending the scope to "all bytecode formats ever created" but that's not what I replied to and it makes your point a moving target. But fine, let's extend the scope, though I don't have a particular opinion on WASI, I haven't looked into it much.

How do you feel about the existence of multiple programming languages? CPU instruction sets? serialization formats?

Maybe WASI was specifically designed with the use case at hand and a new design was the better option. Saying previous work exists is not nearly enough. Most things are like this. They build on top of existing stuff taking inspiration from prior work.

I know nothing much about WASI. Convince me that an existing bytecode would have been better. Describe specific and detailed flaws.

Until then I'll just consider you just hate it for some unknown reason, so much you want others to join you.

Re: WASI 0.2.0 and Why It Matters

#88

Post by flohofwoe »

boomskats wrote: post #63
flohofwoe wrote: post #20

Earlier quoted context omitted.

Might be part of the nerd kingdom for you, but I recently made pretty cool use of WASM+WASI in a VSCode extension: https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html Also quite a few 'CPU nerds' found my 'visual6502 remixes' useful so far: https://floooh.github.io/visual6502remix/ https://floooh.github.io/visualz80remix/ Development experience with Emscripten and WASI SDK is fine really (in the sense that thes…

I read your post on WASM debugging with Emscripten and VSCode[0] just last week, thought it was amazing! Not quite the same, but tangentially related since we're talking WASM+WASI and VSCode extensions - I have high hopes for the vscode-wasm[1] project. The VSCode extension host is a massive hog, and this seems like a big step in the right direction. [0]: https://floooh.github.io/2023/11/11/emscripten-ide.html [0]: h…

Yeah, this vscode-wasm thingie is exactly what I'm using to run a command line assembler tool in VSCode. Pretty neat, only downside currently is that it is only available as pre-release, which makes installing extension which depend on vscode-wasm awkward for the user.

Re: WASI 0.2.0 and Why It Matters

#89

Post by jraph »

pjmlp wrote: post #61
spankalee wrote: post #55

Earlier quoted context omitted.

WASI isn't an academic paper.

Pardon me, I thought there was some rigor involved, my mistake.

Papers are not the only way to show rigor and are not even sufficient.

Should we insult you with a huge list of rigorous enough things that were not designed in a paper? Or perhaps a list of unrigorous papers?

I hope you are not using a computer with a common OS and the tools it comes with because you might be in for some sadness and sorrow.

Or maybe your snark is unwarranted and you should take a step back on this.

I think nobody is claiming WASI is a brand new idea that is built from scratch without taking inspiration from anything old. On the contrary, it is immediately obvious to anyone with the most basic culture on the topic reading about WASI that it takes inspiration from previous work. And it's fine.

Re: WASI 0.2.0 and Why It Matters

#90

Post by andybug »

Props to the team, this is great work.

I've been trialing Preview 2 for the last couple of months to good results.

I do have one problem though and can't seem to find a good way forward. My use case is to use WASM for the data processing modules in a tile-based simulation game/engine. This involves passing around large (many MB) buffers. For any semblance of performance the data cannot be copied between modules and needs to be passed by reference.

To that end, I've implemented Resources. However, getting data out of a resource still requires copying (wasm-bindgen makes the return types from accessors owned Vec). I've resorted to just passing u32 memory offsets since all of the modules are sharing one Memory.

Would love some guidance on this as I've scoured the Internet and simply can't find the right solution, if there even is one.

Post reply on HN