bhelx

This speaks to the general problem with using LLMs for writing. The audience they are writing for us you, but you're trying to write for a totally different audience. In code, this manifests as comments in the code that are hyperspecific to the conversation you are having, and not the long term benefit of having those comments in the code.

I see this in docs a lot. I've been reading a lot of docs these days where it feels like the LLM is trying to hype up the person writing the docs. It's like it has no conception that the writing is meant for a 3rd party audience.

Agree about Graal being really good. there are some different use cases for embedding wasm in an application. chicory / endive is not just for embedding another language. the main use case was always secure plugin-systems. but there are other use cases. also it's not controlled by Oracle and works well outside of their ecosystem, which i think some people value. this question came up a few times and were addressed in talks and blog articles:

https://github.com/dylibso/chicory#on-the-press

the "redline" compiler is cranelift which is written in rust, but i think it's being compiled to Wasm first then JVM bytecode so it still works zero dependency. not sure if that will continue to be the case.

if i understand correctly, the new redline compiler doesn't have these limitations. it's not based on asm. (edit: but this hasn't been merged to mainline yet)

yeah that is roughly the concern, many runtimes didn't want to continue on past wasip1, mostly because of the component model.

Just wanted to chime in to say this is really cool. I dreamed of building something like this for the Extism ecosystem but it was a huge lift to unlock all the pieces. This looks like lots of innovation all the way down the stack. Kudos!

Glad to hear you’re enjoying it! Would love to meet up some time if you ever get the chance.

welcome! if you're looking for some people to connect to or get help from check out the local dev community site: http://noladevs.org/

yes, the local security community punches above their weight i think.

Hack night is the generic networking meetup at the rusty nail. It's way more casual. No presentations or organizing. below-c-level and frontend party are generally more organized and have talks. All the meetups happen before (and geographically near) to hack night on the same night. So you can generally do both. See a meetup then walk to the bar with everyone for the networking event.

Speaking of community, there is a really nice little tech community going strong in New Orleans that I think reflects the culture talked about here. If you are ever in town you should stop by an event https://www.noladevs.org/.

Feel free to reach out to me if you want some intros.

This is the first i've heard of people using the SSE transport locally. What purpose what that serve? Is this by design because the chrome extension could not talk to it otherwise?

BTW, you should really run your MCP servers in a sandboxed environment, esp if they don't need to do things like `exec` or read from the filesystem. We do this with the https://mcp.run ecosystem by wrapping them in wasm. Because they are wasm you could also run them right in the chrome extension!

I'm not sure where they congregate, but I've encountered some minecraft people using chicory probably for this purpose. IDK how minecrafts plugins currently work but i'd imagine chicory is more secure and the overhead may be worth it for some cases.

Glad you appreciate it! On top of being a Java joke it’s an homage to my home, New Orleans. We still drink coffee with chicory here due to some events during the civil war and then a changed cultural taste. Though the history in this isn’t exactly clear I think https://neworleanshistorical.org/items/show/1393

wait, was the question running scala in wasm or running chicory in scala?

Yes i think so. it's just a jar

This is distributed as just a jar, should you can invoke it from Clojure, if that is what you mean.

Some more interesting use cases in production:

Running python UDFs in Trino: https://trino.io/docs/current/udf/python.html

Running the Ruby parser in Jruby: https://blog.enebo.com/2024/02/23/jruby-prism-parser.html

Even in interpreter mode, rust wasm programs seem very fast for me on Chicory. I'm not sure if we have any specific benchmarks but the graal team did some and i think it's based on a rust guest program https://chicory.dev/blog/chicory-1.0.0/#the-race-day

WASI does open up some holes you should be considerate of. But it's still much safer than other implementations. We don't allow you direct access to the FS we use jimfs: https://github.com/google/jimfs

I typically recommend people don't allow wasm plugins to talk to the filesystem though, unless they really need to read some things from disk like a python interpreter. You don't usually need to.

There are a few! But also there is lots of Java software out there and Wasm is a great way to extend it and bring new functionality.

It's very amusing to me as well. The first thing i did was run and SNES emulator and definitely made me chuckle https://x.com/bhelx/status/1809235314839281900

Also note, we have the AOT compiler which can target the JVM bytecode directly as well as Dalvik/Android which is experimental but nearly spec complete :)

There are a few, and they are really interesting! The reason we wrote Chicory though is we're interested in extending the capabilities of existing Java applications through plugins. The intro of this talk explains some of this reasoning: https://www.youtube.com/watch?v=00LYdZS0YlI

yes it's certainly possible. i don't know if it exists but there are many things like it. not exactly what you describe, but many blockchains use wasm as the contract execution runtime. also, it kind of sounds like filecoin but with compute. i'm sure "protocol labs" has a project close to what you are talking about.

edit: the hard part to note is probably the "trust" part. might be trickier to solve than just giving incentives.

Same tip here. We did this with Chicory: https://github.com/dylibso/chicory

I'd follow on that, the earlier you can get this test-suite running the better for the iteration speed and correctness of your project.

It took a bit of time to make everything work, but once we did, we very quickly got to the point of running anything. The test-suite is certainly incomplete but gets you 95% there: https://github.com/WebAssembly/testsuite

yes, it's regularly done. But I think you are misunderstanding. WASM GC isn't a GC implementation.

Exciting to see this finally reach 1.0 :)

If you have a Java library, take a look at Chicory: https://github.com/dylibso/chicory

It runs on any JVM and has a couple flavors of "ahead-of-time" bytecode compilation.

> If the goal was pure Java SQLite¹, a VFS from scratch would be better.

agreed, though this was more an experiment to test Chicory once we built initial wasi support. I'd love to see it picked up and improved. I think that's the direction I'd go if i want some kind of production ready library.