From 1/8/2014, 12:31:45 AM till now, @syrusakbary has achieved 4006 Karma Points with the contribution count of 397.
Recent @syrusakbary Activity
I'm ultra excited about Bun being finally open sourced, congrats on the amazing progress here Jarred!
Since JSC is actually compilable to Wasm [1] and Zig supports WASI compilation, I wonder how easy would be to get it running fully in WAPM with WASI. Any thoughts on how feasible that should be?
The interesting thing about Virgil is that it doesn't use LLVM under the hood: it has its own IR that can compile to native code, JVM/jar's or Wasm
I was able to find a link to examples in the main README, although it's true that in the Documentation markdown file itself is missing the reference.
In case it's useful for future readers, here are some samples: https://github.com/titzer/virgil/tree/master/doc/tutorial/ex...
I discovered this project when I was taking a look on Wizard, a fast and low-resource Wasm interpreter [1].
One of the things that excites me about Virgil is that is completely self-hosted (the runtime is fully implemented in Virgil, and it can compile itself).
Curiously enough, the person that created Virgil (programming language) and Wizard (Wasm runtime) was Ben L. Titzer, who worked on the V8 team at Google and co-created Wasm. I'm pretty excited with what he can bring to the table :)
Update: I'm trying to have virgil to self-compile into Wasm/WASI, and will try to upload it to WAPM [2] so everyone can use it easily (as the first compilation of v3c currently requires the JVM)... stay tuned!
[1]: https://github.com/titzer/wizard-engine
[2]: https://wapm.io/
I second that, entirely!
Virgil: A fast and lightweight programming language that compiles to WASM
154 points • 79 comments
We even created a $B business plan for PitPet, so it's just a matter of time...
https://docs.google.com/presentation/d/1l4VDbhTeiv1bnUtof3Op...
Props to Colin on the survey. It's always super useful to have more insights on where the market is going.
I'm super happy to learn that Wasmer (https://wasmer.io) is the most popular runtime (regarding most people having heard of it). But I would like to cheer all the other runtimes for their awesome work, it's always good for the ecosystem to have a healthy amount of competition on the runtime space :)
Companies that own other runtimes used for running Wasm server-side:
* Intel (WAMR) - Market cap: $105B
* Fastly (Wasmtime) - Market cap: $1.2B
* Google (V8) - Market cap: $1.5T
* Tetrate Labs (Wazero) - Market cap: ~$200M (guesstimate)We support them fully in the `context_api` branch, which is not yet merged into master but will be very soon as part of the Wasmer 3.0 release
Hey Conlectus, let me address your technical comments (note: I work at Wasmer)
> 1. Lack of support for `externref`, AKA opaque references to host data.
We do support `externrefs`, but had to partially disable it due to big impacts on performance due to how we did the initial implementation. We are refactoring this in Wasmer 3.0 and this shall be completely addressed in the Wasmer 3.0 release.
> 2. An awkward context API for host calls.
This is probably the point I agree most with. This is already being worked on. Please take a look on this PR if you are interested on knowing how things will look like for Wasmer 3.0 [1]
> 3. It took me about 2 weeks of development to run into a use-after-free bug bubbling up into Rust.
Sorry to hear that! We are working hard make sure there are no such leaks/bugs in Wasmer
> 4. The performance, at least for my use case, was not meaningfully better than Wasmtime
In general, being able to have to have a pluggable compiler infrastructure I think makes the runtime infrastructure way more resilient and with almost zero effort we should be able to support more chipsets (such as RISC-V). In the case of Wasmtime they are using the partially-optimized compiler Cranelift, but they only support for x86_64 and aarch64. They are doing super interesting things such as the ISLE initiative but IMHO they are far from having the robustness that projects like LLVM already have. Which is why Wasmer chose a pluggable compiler infrastructure rather than tying itself to only one.
> 5. Lack of support for instance resource allocation pools.
Yup, this is on our plans!
> 6. Lack of support for the module linking proposal
This have been very intentional. IMHO module linking is an over-engineered solution that can be solved more easily with a static spec definition outside of Wasm. I personally think it's unlikely that it will reach broad adoption. But I can assure you that Wasmer will implement this once browsers do (if they ever do, of course)
> Hoping there's some general potential benefit for async-related capabilities
Will be, stay tuned!
Wasmer 2.3
37 points • 4 comments
This is great. Syrus here, from Wasmer.
I think WAPM and Wasmer could help a lot on the extensibility using Wasm plugins. I'd love to chat further, please feel free to reach me at syrus[at]wasmer[dot]io!
Running Intel Binaries in Linux VMs with Rosetta
13 points • 1 comments
Small update from the creator of the twitter handle [1]:
Working on getting @newsycombinator
unsuspended(!) – got hit with a trademark infringement
Here's the latest "working" snapshot from the Internet Archive on May 28th (they had around 242k followers) https://web.archive.org/web/20220528044528/https://twitter.c...
It seems they suspended the account on June 4th, based on the most recent snapshot from Internet Archive. https://web.archive.org/web/20220604050840/https://twitter.c...
Twitter has suspended YC Hacker News account
16 points • 16 comments
X64 modular exponentiation bug in OpenSSL and BoringSSL introduced in 2013
3 points • 0 comments
LIVE++: C/C++ hot reload
4 points • 1 comments
site design / logo © 2022 Box Piper