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

Wasmer 1.0

medium.com

Post reply on HN
Print view View original

131–140 of 168 posts

Re: Wasmer 1.0

#131

Post by acje »

I like web-assembly for the same reason I like Rust, actor-model and compile time checked state machines. It makes it more plausible that we can build robust services in the future. And it even feels like Computer Engineering when I'm working with these concepts. To me the web-assembly runtime is the next iteration of isolated applications, after containers which came after VMs, and I'm sure HN could come up with a bigger picture, but this is OK for my purpose.

And I know nothing about browsers, GUI and front-end stuff, but Web-assembly is never the less very interesting for me, and I consider it the biggest thing since Docker.

Re: Wasmer 1.0

#132

Post by singularity2001 »

CyberRabbi wrote: post #95
robbywashere_ wrote: post #91

'For everyone asking, but why use a browser technology server side? Just run a binary' or 'Whats old is new again, java etc' - I am sure you've heard of a browser technology that is used server side, javascript, ever hear of nodejs? The rise of javascript and its server side runtime is due to the immense pressure that language had to evolve to make the web what it is today. Web-assembly is the next step and evolution…

You don’t need webassembly to run JavaScript on the server side. You don’t need webassembly to run C++ on the server side. You don’t need webassembly to run Rust on the server side. Etc. Node was necessary because you need node (or compatible) to run JavaScript on the server side.

You DO need webassembly to run C++ on the server AND client(browser) side.

(unless you want to use some hacky c++ to js transpiler)

Re: Wasmer 1.0

#133

Post by flohofwoe »

apitman wrote: post #2

Browsers are not the right tool for sandboxing applications. I don't think it was a mistake, but it's time to take what we've learned and move to the next level. With a bytecode like wasm, you can create an "app runner" program that's at least an order of magnitude less complicated than current browsers. Just ship apps as wasm binaries with a simple interface (maybe WASI, haven't taken the time to dig into it yet) fo…

The idea makes a lot of sense, but it all comes down to the system-level APIs that this application-runner would provide. Should it be Web-APIs? Then you're essentially rewriting the browser, maybe minus the DOM, CSS and JS. Should it be the Windows APIs? Then you're essentially rewriting Windows above the kernel. Just POSIX? Then what about applications that need rendering and sound. Do you invent your own cross-platform APIs? It's a massive undertaking, and without the momentum that the web had and has, it'll be tough to make this application runner popular among devs and users.

Re: Wasmer 1.0

#134

Post by pjmlp »

sagichmal wrote: post #128
pjmlp wrote: post #109

Earlier quoted context omitted.

Just like CLR, JVM and GraalVM, nothing new besides WebAssembly marketing.

Wasm is structurally similar to those things, yes, but is so much faster that it is actually categorically different.

Of course it is so much faster, it does almost nothing.

Re: Wasmer 1.0

#135

Post by flohofwoe »

kaba0 wrote: post #101
nine_k wrote: post #93

Earlier quoted context omitted.

No need to recompile means you can run the same, guaranteed known, signed, etc code everywhere. Purpose-built sandboxing means you can run untrusted code more safely — e.g. at the network edge, like a Cloudflare worker, a lambda, etc. Same for third-party plugins in apps, etc. An open standard and open implementations gives you some assurance against lock-in, licensing changes, patent suits, etc.

All of it already exists with the JVM.

Isn't the JVM too high level for compiled languages without garbage collection? E.g. can I efficiently compile C to the JVM without asm.js-style hacks which degrade performance?

Re: Wasmer 1.0

#136

Post by k__ »

coldtea wrote: post #85
anderspitman wrote: post #50

Earlier quoted context omitted.

> First, Stockholm syndrome isn't a thing. Have you ever had a useful conversation by starting with this?

Yes. The information that "Stockholm syndrome" is a bogus pop psychology theory disputed as to its reality today, has proven extremely useful anytime the core argument of the other side is that something was/is "bad" and has only been retained "because of Stockholm syndrome".

yes, thanks

Re: Wasmer 1.0

#137

Post by [deleted] »

alexhutcheson wrote: post #123
higerordermap wrote: post #106

Earlier quoted context omitted.

> offer the functionality it has today while balancing with security and sandboxing. LoL, LoL, LoL You can say this only because every other operating system sucks at sandboxing. There is no reason you have to be inefficient as browser to provide security and sandboxing. In return there is also a huge attack surface, with all the code running below, and corner cases in web standards. AFAIK any js click event can allo…

What existing sandboxing systems are you thinking of that are more efficient? Would you be confident using them to run possibly malicious code on your system?

[deleted]

Re: Wasmer 1.0

#138

Post by KronisLV »

coldtea wrote: post #82
anderspitman wrote: post #26

Earlier quoted context omitted.

Sorry, but I think there's some stockholm going on here. People use the web for apps because people use the web for apps. It was in the right place at the right time and an extinction event chose JavaScript. That doesn't mean we can't make something better (doesn't mean we can, either).

No, people use the web for apps because: (a) AWT was shitty and Swing an overengineered mess. (b) GTK+ was never decent cross platform. (c) QT was more decent, but had its own issues, and still in an uncanny valley (neither native enough, not its own thing like the web UI is). (d) Cocoa and whatever Windows has this week are not cross platform. (e) Most other alternatives are buggy, understuffed, and just don't look…

I really wanted to like Swing - despite it really being an overengineered mess, with some IDE GUI tools for creating UI layouts (a crutch that you might want to use, given how messy the code-first approach would be), it was actually a passable way of creating cross-platform GUI apps. Though you'd still need JDK, which was a drawback (and it wouldn't look or feel native, but then again, at least it worked). JavaFX/OpenJFX, despite its advantages, somehow feels worse integrated into the development workflow that some people like me used to have.

Never really got into GTK+ or Qt, or other tools that are more wieldy in the lower level languages, i'm afraid, though i'm sure that with enough time investment, bindings for other languages could be found and you could use them well enough.

Though the closest i've seen to "easy" cross-platform GUI development that actually respects the underlying platform (unlike Electron), but that also doesn't make your hair go gray, was the way FreePascal + Lazarus handled it, by attempting to support multiple frameworks in a transparent manner, where possible ( https://en.wikipedia.org/wiki/Lazarus_Component_Library ). Now, normally something like that would fail, since abstractions are leaky, but it seems like a number of useful pieces of software was actually written that way ( https://wiki.freepascal.org/Projects_using_Free_Pascal ).

It's just sad that the language is kind of dead nowadays, as is the idea of having up-to-date tooling around it, or even many tools for developing web APIs. :/

Re: Wasmer 1.0

#139

Post by fulafel »

skybrian wrote: post #8
apitman wrote: post #2

Browsers are not the right tool for sandboxing applications. I don't think it was a mistake, but it's time to take what we've learned and move to the next level. With a bytecode like wasm, you can create an "app runner" program that's at least an order of magnitude less complicated than current browsers. Just ship apps as wasm binaries with a simple interface (maybe WASI, haven't taken the time to dig into it yet) fo…

It depends on what kind of application you mean. Headless servers doing basic file and network I/O are pretty reasonable to sandbox. This is what Docker does. But GUI applications are a whole different thing. The standards simply don't exist to make that easy. It's not just basic graphics. Things like internationalized text rendering, text input, and accessibility are ridiculously hard and only a few mostly-complete…

Docker doesn't provide a strong security boundary. It's a sandbox only in the sense that it separates the container from the host from inadvertent entanglement (mostly).

(And the nonportability of images is another thing)

Re: Wasmer 1.0

#140

Post by higerordermap »

alexhutcheson wrote: post #123
higerordermap wrote: post #106

Earlier quoted context omitted.

> offer the functionality it has today while balancing with security and sandboxing. LoL, LoL, LoL You can say this only because every other operating system sucks at sandboxing. There is no reason you have to be inefficient as browser to provide security and sandboxing. In return there is also a huge attack surface, with all the code running below, and corner cases in web standards. AFAIK any js click event can allo…

What existing sandboxing systems are you thinking of that are more efficient? Would you be confident using them to run possibly malicious code on your system?

>> because every other OS sucks at sandboxing

And I won't be confident using browser too. Pretty sure at any given time there will be quite a few javascript/wasm attacks which can escape browser sandbox and run arbitrary code, then my files won't be safe. When I am running potentially malicious website I am creating a separate user on my linux box anyway.

Post reply on HN