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

WasmEdge

wasmedge.org

Post reply on HN
Print view View original

41–50 of 88 posts

Re: WasmEdge

#41

Post by syrusakbary »

laurencerowe wrote: post #6

Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow. > In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime. http…

Interesting. Have you tried to benchmark it also with Wasmer [1]? I'd be curious to see what the timings might be.

[1] https://wasmer.io/

Re: WasmEdge

#42

Post by galangalalgol »

azakai wrote: post #38
galangalalgol wrote: post #36

Earlier quoted context omitted.

Does the engine store compiled binaries for the next time the page is loaded?

Some (most?) do, yes, here is a V8 article on that for example: https://v8.dev/blog/wasm-code-caching

That seems to imply julia for wasm on chrome wouldn't have the "time to first plot" issue.

Re: WasmEdge

#44

Post by juntao »

rafale wrote: post #43

Why use a WASM VM when there are more mature VMs out there like .net/CLR? What's the benefit?

I can think of a few:

* Lightweight (no GC, under 2MB) * Designed to be a secure sandbox (not just a language runtime) * Modular (add host functions as needed — eg support for Tensorflow) * Multiple languages (esp compiled languages like Rust) * Works with container tools (Docker, k8s etc)

Re: WasmEdge

#45

Post by Existenceblinks »

WASI development is very slow. Bytecodealliance is kinda all the big names but it seems not a lot of investment to hire more people working on the spec (I know at some point more people won't work, but right now there are only a few)

Re: WasmEdge

#46

Post by Matthias247 »

juntao wrote: post #13
cyanydeez wrote: post #3

Seems like the edge is just SaaS microservices. Change my mind.

I am a maintainer at WasmEdge. :) The name “edge” signifies that it is lightweight. We think it is a lightweight and secure alternative to Linux containers. The application use cases include containerization on edge devices, serverless functions on edge cloud, embedded functions for databases or SaaS, stream functions for data pipelines, or even smart contracts for blockchains. All of the above are “edge” use cases i…

Edge typically means that the software is running neither on an end device (e.g. a consumers phone/PC/tablet/TV), nor on the very backend in a big datacenter (like AWS us-east-1 or another region), but somewhere in between. E.g. a "mini-datacenter" close to the user (CDN points-of-presence (POPs) are called edge locations", or some aggregation points in between (e.g. gateway devices in factories that proxy between on-site components and in-cloud components).

The term doesn't have a lot to do with how efficient or non-efficient the software that is run in those places is.

Re: WasmEdge

#47

Post by rdtsc »

intelVISA wrote: post #30
laurencerowe wrote: post #6

Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow. > In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime. http…

Interesting gamble to build a whole company on top of what is effectively a wrapper for Bellard's work (qjs), wonder how it'll play out.

Not OP but I was considering using it as well. I could see it going either way. If Fabrice stays interested in the project and keeps improving it, it could be a great win. If he moves on to other things, perhaps not.

I've been looking at quickjs issues and forks and see a lot of random fixes from various people and most of them don't seem to be accepted or responded to:

* https://github.com/bellard/quickjs/issues/131

* https://github.com/bellard/quickjs/issues/130

* https://github.com/bellard/quickjs/issues/129

* https://github.com/bellard/quickjs/issues/123

* https://github.com/bellard/quickjs/issues/111

* https://github.com/bellard/quickjs/issues/103

* https://github.com/bellard/quickjs/issues/96

The mailing list doesn't seem to have a lot of responses either. So, it's actually hard to say. The first instinct is it's great to base a product on such a talented programmer's work, but it seems you should be proficient enough to debug and fix issues yourself to do that.

No blame or slight to Fabrice, of course, I am always impressed by his work, and he certainly doesn't owe anyone any of his time.

Re: WasmEdge

#49

Post by jeffparsons »

syrusakbary wrote: post #41
laurencerowe wrote: post #6

Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow. > In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime. http…

Interesting. Have you tried to benchmark it also with Wasmer [1]? I'd be curious to see what the timings might be. [1] https://wasmer.io/

I'm impressed — I don't think I've ever seen you miss an opportunity to promote your company. I assume you have some kind of keyword alert set up? Kudos on the mad hustle!

Re: WasmEdge

#50

Post by phickey »

Existenceblinks wrote: post #45

WASI development is very slow. Bytecodealliance is kinda all the big names but it seems not a lot of investment to hire more people working on the spec (I know at some point more people won't work, but right now there are only a few)

I work on Wasi at Fastly, as part of the Bytecode Alliance.

WASI development has indeed been quite slow. Most of our efforts for the past 2 years have been developing and implementing the Component Model proposal. Right now we are working on porting WASI to the component model, which has been pushing all of the new wit tooling more than it has WASI itself.

I can’t really say that adding more people would have sped up the last few years. The vision of the component model is very ambitious - it’s the first credible open (as in, not owned by Oracle or MS) standard for a real cross language VM, and the security posture supports mutually distrustful components by default. If we had just iterated on the witx version of wasi without coming up with the component model first, I believe both the component model and wasi would be worse off for it.

A lot of the foundational spec work and tooling is now (hopefully!) pretty stable. We used to rewrite everything related to the component model (fka interface types or module linking) every 6-9 months because the spec changed really radically, now I genuinely believe you’ll be able to take todays wit-bindgen to production in 6-9 months of polishing. We are approaching the point where we can get those tools in the hands of way more contributors and the ecosystem can grow.

So yes, the contributors to it today are small, but they are growing (I’ve spent a big chunk of the last few weeks bringing on more contributors from other bca companies) and soon will be able to grow even more.

Post reply on HN