syrusakbary

I'm a technical founder working in a deep-tech startup.

If I am completely honest, I think the recommendation of having a technical cofounder while useful for startups in the past might not be as useful for the startups of the future.

Why? I strongly believe AI will cause a paradigm shift, and I'll adventure stating that AI will make non-technical people be able to do more and more with less. Which will make the requirements for differentiation in the tech side even harder to accomplish (very few people reaching the god-tech realms), but at the same time it would make the bases reachable for almost anyone. Basically, a more polarized order where less people will have access to "technical founders" that can differentiate themselves enough outside of the AI realms.

I'd love to get more thoughts on this!

Good point! I believe none of the other Edge platforms are fully open source yet (I don't mean their runtime being OSS, but the Edge Platform itself). Clouflare Workers is the only one that gets there half way with Workerd (they are missing KV, other APIs and the glue-code).

Right now the Wasmer Edge product usage is not in a stable enough point to make it open-source. I'd love to share the timelines, but anything that I say now will likely be wrong (as we are still iterating hard on the product).

> I would be interested in restricting specific requests to certain regions

I can see this being an issue if you plug the workload with data that is located in a specific region (for example, via a DB connection or doing API calls to an API in a specific region). Is that your use case?

I was pleasantly surprised to see this, but it seems that the JS context in each run of the cron script is cloned so cron jobs are actually run in a separate "process".

Namely, I ran this example.

  let s = 0, r = 0;
  Deno.cron("Add second", "* * * * *", async () => {
    console.log(`Add second ${s++}`);
  });
  Deno.serve(async (_req) => {
    return new Response(`Seconds Running: ${s} / Number of requests: ${r++}`);
  })

Example deployed here: https://weak-stoat-26.deno.dev

So, effectively, it seems that Deno.Cron clones the JS context but any changes done to that context will not be reflected in the Deno.serve. And, if that's the case, why don't handle Cron jobs in a different flow rather than mixing them with Deno.serve? (I think it can lead to unintended side-effects)

I'd love if someone from the Deno team could provide more context here, maybe I missed something?

Indeed. Yeah, there are many. Thanks for the comment!

How do you think they compare against other Edge providers leveraging on Wasm such as Cloudflare Workers [1] and Wasmer Edge [2]?

In my opinion, they have way worse developer experience... but that may be my taste. I'd love to hear your thoughts!

[1] https://developers.cloudflare.com/workers/

[2] https://wasmer.io/products/edge

I loved this compilation of his funniest moments: https://www.youtube.com/watch?v=gHLA64sh4WE

Without entering in any detail on what you mentioned (other than sincerely thank you for the belief in the potential upside for Wasmer!), I think we may have very different definition of what a hater is.

A hater, for me, is someone that lacks of constructive criticism.

Hope you feel better!

> I think that the decision is a good one

I'm incredibly happy to hear that

I'm happy to see some convergence here :)

I wish the votes in the comments were public, so maybe you could actually get a grasp of what the community really feels like!

Just to be clear, and to reinforce what I mentioned.

WASI Preview 2 doesn't officially support threads. There are some ways to get it running as you mentioned, but threads are NOT part of WASI Preview 2. Which is what you initially stated and I corrected.

We don't want to have competing standards either, and we'd love to merge things upstream. However, based on my interactions with the WASI subgroup it seems clear they want to keep some of this things that WASIX needs out of the spec (and that's ok!). If you would not like to have that, then you shall probably direct your requests towards them, not us.

> I want good tech to win

Me too! I now understand this over-idealistic belief is the root of the issue. Good tech doesn't win, a good product does.

I wrote more about this, if you are curious, here: https://wasmer.io/posts/is-not-about-wasm-is-about-what-you-...

I'm not even going to enter into the flame-bait. I obviously disagree with your points.

Hope you have an awesome day

> The issue isn't with WASIX, but with you and your actions.

Is refreshing to see at least some honesty. Haters gonna hate, so I personally don't mind. Have a great day!

I'm not sure what roadmap you are talking about. Threads are actually removed from WASI Preview 2.

WASI Preview 2 still doesn't support threads, fork, subprocesses or longjmp/setjmp (among others). Not even that, when WASIX was created not even sockets were supported in WASI.

I'd recommend trying to compile bash or curl to WASI Preview 2 and WASIX and see how far you get in each before trying to polarize the readers between WASI Preview 2 and WASIX.

I think you may be a bit confused on what's the purpose behind WASIX, Stephen. And you are mistakenly polarizing between two very valid options for different use cases.

We are not trying to push WASIX, we are trying to move forward sockets, threads, subprocesses so they can run fully in Wasm environments. And WASIX is the solution to that problem.

WASI Preview 2 on the other hand seems to be focused on other set of problems and doesn't solve any of the needs that got WASIX started in the first place.

I'll address the first non-clickbait question and try to provide some insight, as I think you might be a bit confused on how COSS startups work.

We don't plan to monetize WASIX. WASIX is just an enabler to allow any program compile to WebAssembly. If other open-source technology existed and fulfilled what we want to accomplish is more than certain we would not have created WASIX.

In our case, the community was asking to have sockets, threads, forking, subprocesses and more fully working on Wasm. And there was nothing that supported that (or that aimed to support it), so we worked on it.

Now, let me give more insight on what we actually plan to monetize: Wasmer Edge [1]. Wasmer Edge is the alternative to the expensive big-tech providers that allows any person or company to host their websites at a fraction of the cost.

Hope the insight was useful!

[1] https://wasmer.io/products/edge

I'm incredibly curious to hear more on how you think WASIX helps on the company pockets (since is open-source, and even it's governance model is open).

I'd love to hear your thoughts, maybe we are missing on some nice business opportunities here!

WASIX is similar to the JVM in the sense that is able to use a common abstraction for all operating systems, and it uses a VM under the hood (Wasm).

But the main difference is that it has sandboxed capabilities (similar to docker), do you can granularly add permissions to only certain directories or even disable networking when running.

WASIX will enable to run biome fully sandboxed at close to native speeds.

Imagine you can safely assume that the formatter program will only have access to the directory you provide, and not anything outside of it (not even the network!).

In summary, Wasmer + WASIX is like Docker, but much more lightweight :)

I'm incredibly excited for this. The Biome team has been remarkably fast on achieving 95% compatibility with Prettier [1].

This will help to bring maximum speed to formatting Javascript thanks to Rust, following the ruff (Python formatter) trend.

Just as a note, as it was not mentioned in the article, Wasmer [2] also participated with a $2,500 bounty to compile Biome to WASIX [3], and it has been awesome to see how their team has been working to achieve this as well... hopefully we'll get Biome running in Wasmer soon!

Also congrats to the Algora team, as they have been doing very good work with their landing and trying to help on the challenge moving forward [4].

Keep up the great work!!

[1] https://github.com/biomejs/biome/issues/720

[2] https://wasmer.io/

[3] https://wasix.org/

[4] https://console.algora.io/challenges/prettier

It's funny how WebAssembly can help overcome most of the issues mentioned on the blogpost (packaging, configuration, portability) if addressed properly.

That's the main reason Wasmer [1] was created :)

[1] https://wasmer.io

Wasmer & Wasmer Edge might be a good option for you!

https://wasmer.io/products/edge

The people from Algora have created a great homepage for the bounty: https://console.algora.io/challenges/prettier

Note: Guillermo Rauch and Wasmer also joined, adding $12,500 extra to the mix (total bounty is $22,500)

Congrats on the work... it's an impressive demo!

It may be worth researching to add support of it into the Wasmer WebAssembly runtime [1]. (Note: I work at Wasmer!)

[1] https://wasmer.io/

Thanks for the mention to Wasmer.

I'll put here a link in case is useful for future readers: https://wasmer.io/

WASIX might come in handy for that!

https://wasix.org

It does solve many of the issues, namely:

  * Memory isolation (memory can't be executable, and thus you reduce injection attacks).
  * Sandboxing: by default Wasm has no access to the outer universe where is being called, this makes quite trivial to properly sandbox almost any kind of program (on the systemcall layer)

And it does so without requiring hardware virtualization

This looks awesome, congrats on the launch!

Do you any plans supporting Wasm? (Let’s say, via Wasmer! ;) )

Yes, in a similar fashion to Cloudflare Workers :)

This is an incredible feat. Also, love the attitude

  > But making a new browser engine is impossible!

  No. It. Isn’t! (Also I don’t really care how possible/feasible something is.)