alexboehm

Just try opencode, it comes with 1.3 contributor free.

Fair point, but name one thing you can't do with bash.

I too was frustrated with needing npm and slow startups or huge rust compile times for agents. I tried getting agents to write a tool like this with proper raw mode content pasting/ interruptions, but they just kept screwing it up without a framework like ratatui, so I wrote one in c by hand https://gist.github.com/fourlexboehm/a60e4ef9306744483731cd1... the only dependency is libcurl.

This binary is ~40kb and uses much less ram than fx.

Interesting, I've been building the inverse of this project, to enable running Linux binaries on macOS, as that's not something I've seen in an active project. It works an a very similar way but it's in Zig.

I'll post it soon!

It's already sort of possible. https://codeberg.org/fellowtraveler/flux here is my Zig DAW. It has been amazing for the audio engine, but the ui is currently using imgui.

I think this period of false positives is ending, https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/ that's according to the curl maintainer that initially blew the lid on the false positives problem.

I have been playing with it, it's very cool to be able to run anywhere. Do you have plans to implement wasi-http? One of my concerns is the free tier only offers Compute as a trial, and $50 is pretty steep for a hobby project, are there plans to add Compute usage to the free tier?

The difference is Wasm provides the security boundary so it can be multi tenanted. The real magic is that wasi will be hostable anywhere much like Docker containers are today, but it's much more efficient than docker containers because there are less overheads and startup latency.

Well at that point you'll obviously start having to think about it. The point is you can easily move to self-hosting without rewriting everything.

A more descriptive word would been self-hostable function as a service, that's why faas is in the name!

The point of serverless is you don't have to think about hosting, and ideally it's cheaper.

The problem is if the hosting provider goes away you're screwed. In the case of Faasta, it's a single static binary with minimal configuration so if that happens, you can host it your self or move to another provider.

Thanks for the feedback, I've added the URL to about, I originally supported path prefix and subdomains, but I found it slightly more confusing to communicate to users. I'm definitely planning on more example.

The plan is for it to be an opensource project, currently the cli and interface crates are MIT, I have been considering a copyleft license for the server, or a dual licensing strategy.

I'm not discounting WASIX or what you guys are doing I'd love to just use wasm today for everything instead of waiting, I started this project by trying to use WASIX, I just found it quite difficult to actually develop for as many of the essential rust crates, seemed reluctant to merge your changes, and having to use dependency versions from a year ago with patches is very frustrating.

For self hosted, if you use porkbun for DNS it will automatically pull a wildcard SSL cert using the API at startup.

I plan to also support multiple custom domain certs on a multi tenanted instance like faasta.xyz. For now I'd recommend a reverse proxy though.

After delving into this, it seems Wasmer tried, but as they weren't standards compliant, adoption/ecosystem support never followed.

The Bytecode alliance is taking their time stabilizing wasi. wasip2 which is needed for the wasi-http realm this relies on has only really existed for a few months as a stable Rust target, and still misses a lot of the really cool features that will come with wasip3 like full async support.

I suspect Cloud providers will adopt wasi after 1.0, but that is likely years away. I don't think wasi-http will change much before then so now is the time to start building with it.