On one hand atproto has content-addressed storage and portable identity that AP still lacks (but could have!), on the other hand atproto is far more centralized. The data layer is decentralized but everything on top is effectively centralized. Phrases like "practical decentralization" and "credible exit" are used to describe this design.
I am excited by the prospect of booting Wasm binaries without any JS glue, but when I've looked at the documentation for the component model and WIT it says that resources are references passed using a borrow checking model. That would be a serious downgrade compared to the GC-managed reference passing I can do today with Wasm GC. Do you know if there are any plans to resolve this mismatch?
In my experience people are often disappointed by the shared-nothing architecture of the component model. I guess that shared-nothing architecture makes it impossible to properly share GC objects across component boundaries. But they can still be shared across core module boundaries.
A lot of the time I think you just won’t want to use multiple components. It’s nice to be able to compose them together, I guess, but in general it seems to me that a toolchain will typically just want to generate a single big component so that everything can interact without limits internally.
I'm building a new Wasm GC-based language and I'm trying to make as small as binaries as possible to target use cases like a module-per-UI-component, and strings are the biggest hinderance to that. Both for the code size and the slow JS interop.
I have a compiler flag to switch from wtf-8 and wtf-16 so if you compiler for your host you don't have to reencode strings. That means that strings in my language hide their byte representation, don't allow indexed access, and only have code point iterators.
Permissions can be handled with capability systems. Keyhive [0] is the furthest along on this. I've also made my own prototype [1] showing how certificate capabilities can be composed with CRDTs.
Guile, being a bytecode VM with JIT currently, loses to Chez/Racket overall but it's honestly quite fast. I can make games that run at a smooth 60fps with infrequent GC pauses. Plenty of room to grow but Guile isn't slow by any means. I've never been a Gauche user but Guile has lots of nice libraries these days.
That's how I see it, too. I used these benchmarks early in Hoot's development as a rough measure of r7rs compliance and only occasionally as a guide for improving performance. I never published my results but I had Hoot passing more of the benchmarks than Guile itself, which I found funny.
reply