syrusakbary

Oops, will add the license right away!

Edit: MIT license added! We had it on the Cargo.toml and wasmer.toml, but forgot to add the LICENSE file to the repo https://github.com/wasmerio/winterjs/blob/main/LICENSE

This is awesome, I'm incredibly happy to see more alternatives on the Javascript Runtime Space!

In a nutshell: LLRT aims to have incredibly fast startup times compared to Node, Bun or Deno (which is critical in Lambda environments).

LLRT is built using Rust, Tokio and QuickJS under the hood. Here's their compatibility with Node.js APIs [1]

We (at Wasmer), have been working on a very similar approach: WinterJS, which is using SpiderMonkey instead (but also built on top of Rust and Tokio) [2]. HN announcement was just three months ago [3]

Really excited to see how the ecosystem is evolving!

[1] https://github.com/awslabs/llrt?tab=readme-ov-file#compatibi...

[2] https://github.com/wasmerio/winterjs

[3] https://news.ycombinator.com/item?id=38047872

Happy to see RustPython making awesome progress!

Note: I just realized that they mention wapm in their homepage. We phased out the WAPM CLI in favor of Wasmer (https://wasmer.io), so you can simply run in your shell:

  wasmer run rustpython

Or, if you want to try it using the Wasmer JS SDK:

  import { Wasmer } from "@wasmer/sdk";

  let rustpython = Wasmer.fromRegistry("rustpython");
  let instance = await rustpython.entrypoint.run({
    args: "-c \"print(1)\""
  });
  let output = await instance.wait();

Will send a PR soon it can be updated!

A few months ago Wasmer tried add WASIX support to Zig so anything on Zig ecosystem could target the browser easily, which is quite relatable of what the TCC compiler is trying to achieve. I'm sure at some moment the community will pick it up.

I'll drop a link to WASIX in case is useful for the reader!

https://wasix.org

So Juice was the WebAssembly from the Netscape era?

Just suggested as well Wasmer on Twitter! https://github.com/wasmerio/wasmer

Looking forward to seeing the results :)

Beeper open sourced the iMessage bridge about 2 days ago: https://blog.beeper.com/p/imessage-and-phone-registration-ar... (although I realized one hour ago, that's why I posted it!)

Thanks!

I sometimes assume people have the same context as I do, and your comment made me realize that it was not the case. Here's some context: https://wasmer.io/posts/wasmer-and-trademarks

Regarding standards, I assume the mention is referring to Wasmer push for WASIX [1]. Which is a specification & implementation that welcomes anyone to participate (even on it's governance model), so I don't think the stance of the previous comment is accurate.

[1] https://wasix.org/

In the browser not yet, but support for TCP is on the roadmap! Feel free to email me at syrus@wasmer.io so I can keep you in the loop for the first trials :)

Usually it adds an extra 10-25% of overhead when the WASIX program uses systemcalls that require unwind/rewind functionality (this is for fork and subprocesses mainly, the multithreaded ones doesn't require asyncify and as such should not experience a performance hit)

Thanks, I'm a big fan of your work in Trealla. Is true that there's still room to improve sizes, as right now the bundle size is not ideal.

Hopefully it will not take long for Wasmer to serve packages with a minimum bundle size, stay tuned for updates!

No intend of trashing (in marketing pages titles tend to be more flashy).

In any case I just updated it. Happy holidays!

That would be awesome! Although there are still a few edges to resolve to be able to run a full headless browser with Wasmer.

It should be possible though, see: http://trevorlinton.github.io/

I wish to live the day where we can incentivize one ecosystem without having to trash another.

This is not a zero-sum game.

If you find Wasmer useful, use it! If you don’t and you prefer others, feel free to use them. There are plenty of choices.

Happy holidays!

Agreed, the work that Ash and team are doing with Unum is excellent!

If the article was summarized with a TL;DR or phrase along the lines you mentioned "it's basically an adaptor from the Kubernetes world of YAML to the fly.io world of Machines" that would have made it way easier to understand.

In my opinion, the concept is not trivial to grasp by oneself (meaning: is not trivial to drive into that conclusion even after reading the article). So, being explicit first, and guide the reader through that concept along the article would have made a big difference.

It seems I misunderstood the article. I'm happy to read this in any case, thanks for the follow up!

This is one of the biggest footguns of a tech company I've seen in the last decade.

Time will tell if embracing the complexity of Kubernetes was a good play for them or not. But, in all honesty, I'm pretty sad to see this happening, although I'm sure they had their reasons.

I'm sad to hear this to be honest. Wasm3 is (was?) an awesome Wasm interpreter that was ahead of the rest in terms of performance (about 3-5x slower than native, and about 3x faster than the typical Wasm interpreters).

I hope Volodymyr the best as he tries he keep things afloat with the Russia invasion in Ukraine. Hope the war will be soon behind us.

Sure thing: https://github.com/wasix-org/wasix-libc/blob/main/libc-top-h...

In WASIX we fully solved that, so is definitely doable to run fork on the browser.

Although I'm extremely curious the WALI fork strategy would work in the browser. Maybe the creators can chime in here?

I love seeing this.

The more work we do on top of WASI the more I realize their design flaws when trying to run already existing programs on top of it. WASIX aims to fix many of these flaws, but the underlying problems from WASI always arises (such as mandatory relative paths).

I welcome WALI with open hands and excitement. If anyone wants to add support for it in Wasmer I’d be more than happy to integrate it there!

For those interested, as is not trivial to find it, the source code of WALI is here: https://github.com/arjunr2/WALI

Thanks a lot for the info, I'll relay to the team to investigate further

Oh no! Do you mind providing the paths where the errors occurs or the requests ids returned by Wasmer, so we can investigate further?

Thanks!

Awesome, thanks!

I'd love to see how this compares against Llama.cpp on speed. Do anyone any benchmarks that compare PyTorch.compile vs Llama.cpp?

Interesting. If I put it in other words, the argumentation is that AI will just propel the already existing qualities of the people. And because people are different (and the distribution of intellectual qualities remains constant as we grow), the AI will not make any difference on that point.

I'd agree on that.

However, let's imagine the scenario of two people have the similar qualities, with one main difference between them: one have worked longer on those than the other (but their "base" is the same). Do you think AI will propel them at the same speed? (or said in other way: where will be the biggest delta on speed between their pre-AI and post-AI versions?)

How so? If you think I'm missing something important, I'd love to hear it!

AI usage is trending up. I don't see any signs of deceleration in our company. Right now is mostly trivial, but as AI is able to get more context on the space, it will go up.

I foresee AIs learning from the code of your repo, your language, your dependencies... and most importantly, your competitors (if they have open-source code of course). The more context, the better it will get, the faster you will iterate and the bigger you may get.

Got it, thanks for the info!