That is pretty wild, it took me a hell of a lot more coaxing and persevering to get to a similar point with eryx [0] (we spoke a bit about this before on Mastodon) using Opus, Fable seems to have a more optimistic 'sure, let's proceed as if this is possible' mindset based on your transcript. Looking forward to trying it out for some hairier problems.
True, but while CPython does have a reputation for slow startup, completely re-implementing isn't the only way to work around it - e.g. with eryx [1] I've managed to pre-initialize and snapshots the Wasm and pre-compile it, to get real CPython starting in ~15ms, without compromising on language features. It's doable!
I'm not super familiar with how pyodide works but I think it uses CPython compiled with Emscripten then needs to be run from a Javascript environment, and uses the browser's (or Node's) Wasm engine.
This uses CPython compiled to WASI and can (in theory) be run from any WASI-compatible Wasm runtime, in this case wasmtime, which has bindings in lots of languages. WASI uses capability based security rather than browser sandboxing and lets the host intercept any syscalls which is pretty cool. Wasmtime also lets you do things like epoch-based interruption, 'gas' for limiting instruction count, memory limits, and a bunch of other things that give you tons of control over the sandbox.
Pyodide/Emscripten might offer something similar but I'm not sure!
I posted this elsewhere in the thread, and don't want to spam it everywhere (or take away from Amla!), but you might be interested in eryx [1] - the Python bindings [2] get you a similar Python-in-Python sandbox based on a WASI build of CPython (props to the componentize-py [3] people)!
Hah, that is exactly the same approach I landed on. Fortunately the most common tools either seem to have Rust ports or are fairly easy to port 80% of the functionality! Conch's Wasm file is around ~3.5MB and only has a few tools though so I can see it growing. I think for the places where size really matters (e.g. the web) it should be possible to split it using the component model and `jco` (which I think splits Wasm components into modules along interface boundaries, and could defer loading of unused modules) but I haven't got that far yet.
I did something very similar to you for networking in eryx too (no networking in conch yet); defined an `eryx:net` interface in WIT and reimplemented the `urllib` module using host networking, which most downstream packages (httpx, requests, etc) use far enough down the stack. It's a tradeoff but I think it's pretty much good enough for most use cases like this, and gives the host full control which is great.
Oh full transparency, the vast majority of conch and eryx were written by Opus 4.5. Being backed by wasmtime and the rather strict Rust compiler is definitely a boon here!
Cool to see more projects in this space! I think Wasm is a great way to do secure sandboxing here. How does Amla handle commands like grep/jq/curl etc which make AI agents so effective at bash but require recompilation to WASI (which is kinda impractical for so many projects)?
I've been working on a couple of things which take a very similar approach, with what seem to be some different tradeoffs:
- eryx [1], which uses a WASI build of CPython to provide a true Python sandbox (similar to componentize-py but supports some form of 'dynamic linking' with either pure Python packages or WASI-compiled native wheels)
- conch [2], which embeds the `brush` Rust reimplementation of Bash to provide a similar bash sandbox. This is where I've been struggling with figuring out the best way to do subcommands, right now they just have to be rewritten and compiled in but I'd like to find a way to dynamically link them in similar to the Python package approach...
One other note, WASI's VFS support has been great, I just wish there was more progress on `wasi-tls`, it's tricky to get network access working otherwise...
Yes, in fact this is exactly what it was written for! If you're writing a Grafana app plugin (using Grafana Scenes, a library to help write dashboard-like experiences in Grafana apps) you can use Scenes ML to add outlier detection, forecasting or changepoint detection pretty easily: https://grafana.com/developers/scenes/scenes-ml/outlier-dete....
Most of the algorithms in augurs were chosen to solve problems we've had at Grafana, which tend to require a solution that doesn't require tweaking too many parameters and deals with higher frequency series than many other time series algorithms are designed to deal with. For example, the DBSCAN clustering algorithm works without having to choose the number of clusters, and MSTL/Prophet work with multiple seasonalities and sub-daily data.
The other criteria is that they needed to be fast and cheap, which ruled out many of the deep learning/neural net based models, although I'd still like to try some foundation models using Burn or some other Rust deep learning framework!
I started writing this library a while ago after I couldn't find a time series library that really fit my needs (either in Rust or elsewhere, really). Specifically I wanted something that was:
- fast
- portable (I want to be able to run it in the browser, in Python, and in Rust)
- maintainable (please don't write libraries in Jupyter notebooks...)
Augurs meets all three of those for me, and was a lot of fun to write. Plus it has a fun name and I managed to nab the augu.rs domain.
A few things I think are cool:
- the MSTL/ETS implementation is very snappy and can produce forecasts in well under 100ms for quite large time series. This was the initial motivation for writing the library.
- the Prophet implementation includes the option to use a WASM component which wraps the Stan Bayesian framework compiled to WebAssembly, run inside Wasmtime, making it an easy-to-deploy single binary. Interestingly the benchmarks show the Wasmtime version running almost as fast as the native version.
- the whole library can be run in the browser using the npm library - see the demo below for an example
[0]: https://github.com/eryx-org/eryx