HN user
We're so close to a full circle moment. Next up is "npm stable", a curated set of packages (a "distribution", say) known to work well that are supported for a couple of years with security patches.
I sympathize with the developers. Mobile OS push notifications are a big impediment to the adoption of p2p technology and it's hard to do anything novel in the chat space because there's a million chat apps.
Hoot is also not a 2 day old vibecoded project.
Such a refreshing take after all the marketing nonsense from Bun. Zig is a glimmer of hope in a world of slop.
This was a nice little experience report. Most of the deficiencies in Hoot can be blamed on me.
The error messages can be cryptic.
Apologies! Happy to receive issue reports about specific things that we can prioritize.
It's even more incredible to know that it's running on a stack the team created themselves, not relying on Emscripten.
Building our own toolchain has proven again and again to have been the right choice. Emscripten would not have been useful for compiling Scheme to Wasm GC. Hoot is one of the few Scheme-to-Wasm implementations that takes advantage of the GC support (and the most mature of them all.)
My initial understanding of Hoot was that it could compile any Guile program to the Web.
This is indeed the goal. However, that's a big compatibility surface area and we are not there yet. Help wanted! When we reach a critical mass of existing Guile code that "just works" then Hoot will be mature enough to become part of Guile itself as its official Wasm backend.
The OCapN group is actively working on a milestone for 1.0, the first interop target. It's getting close! https://github.com/ocapn/ocapn/milestone/2
I was wandering around the expo floor at PAX East last year when I noticed Earthion at the Limited Run demo arcade. I had a lot of fun playing it on the floor so I bought the full game on Steam. It's a quality shmup! For me the difficulty really spikes on stage 3 and that's where I got stuck, though I did make it to stage 4 once or twice. The initial release had some bullet visibility issues that were improved in subsequent updates. The default CRT filter is fun but I turned it off almost immediately for more visual clarity.
Sure am glad I moved everything off of Gitlab awhile ago. Trainwreck of a company.
It's my favorite comedy of all time. It's been going for over 10 years with a lot of little spin offs along the way. For those that want to take the plunge you can watch the first first ten seasons, Oscar specials, Decker, etc. for free on YouTube. Use this playlist to watch everything in chronological order.
https://m.youtube.com/watch?v=qFHLfmoLchI&list=PLRT5PdjVF-ip...
From Decker vs. Dracula
Tim Heidecker... from?
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.
It couldn't get past a vote in the Wasm community group to advance from phase 1 to phase 2.
Here's a quote from the "requiem for stringref" article mentioned above:
1. WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8).
2. The requirement to support fast WTF-16 code unit access will mean that we are effectively standardizing JavaScript strings.
This is my main confusion, too! I have an existing Wasm GC language implementation and I'm not sure how to reconcile it with the component model.
Yeah it's really frustrating and JS string builtins are not a good fit for me as I do not want to deal with 16-bit code units.
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?
I really want stringref to make a comeback.
Combining OpenClaw with sensitive personal data is a recipe for disaster.
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.
[0] https://www.inkandswitch.com/keyhive/notebook/
[1] https://spritely.institute/news/composing-capability-securit...
I'd guess that the Racket internals are now easier to work with than Guile's
Maybe, I couldn't say, but I find Chez's source code very cryptic and hard to read. More so than any other Scheme implementation.
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.
This is not the smallest REPL binary out there but it's far from the largest I've seen. My anecdotal evidence suggests it's somewhere in the middle or maybe smaller than average. We haven't configured our web server to gzip these assets (we should). Gzipped repl.wasm is 339K. This binary hasn't been run through wasm-opt, either.
Hoot is primarily an ahead-of-time compiler, not an interpreter, so this REPL demo has a lot of stuff that a production binary wouldn't have like a macro expander, runtime module system, and an interpreter. A significant chunk of extra code. We have a todo list example [0] in a separate repo, btw. On my machine, todo.wasm is 566K uncompressed, 143K gzipped. And that includes a virtual DOM diffing algorithm implemented in Scheme.
That said, there is quite some room to optimize binary size. For example, we know we're generating too many local variables in functions [1], many of which could be optimized away with an additional compilation pass. We expect that to have a significant impact on binary size. There's also certain workarounds we're doing due to features missing from Wasm at the time of implementation that add to total binary size. Lack of native stack switching for continuations is one example. Adopting the stack switching proposal should shave off some bytes.
Confused Deputy as a Service
The annoying thing about that proposal is having to use 16 but code units instead of 8 bit. I hope the stringref proposal can get beyond phase 1 because that does strings right imo.
The animation on the Syndicated Actors home page [0] does a pretty good job of showing the difference, I think. Goblins is much more similar to the classic actor model shown at the beginning of the animation. The "syndicated" part, as far as I understand, relates to things like eventually consistent state sync being built-in as primitives. In Goblins, we provide the actor model (actually the vat model [1] like the E language) which can be used to build eventually consistent constructs on top. Recently we prototyped this using multi-user chat as a familiar example. [2]
[0] https://syndicate-lang.org/
[1] https://files.spritely.institute/docs/guile-goblins/0.17.0/T...
[2] https://spritely.institute/news/composing-capability-securit...
We should have a FAQ! We get the Erlang question a lot. In short, Erlang actors are not capabilities because processes can be enumerated in Erlang. Capabilities require that the actors/processes have unforgeable/unguessable private addresses.
Yeah those interested in Wasm topics might find https://spritely.institute/hoot/ interesting. It's not only a Scheme compiler but a full Wasm toolchain available as a library.
That's right! We are developing our own stack at Spritely but OCapN is a protocol to be implemented for any and all programming languages so we can have interoperable capability security over the network. Besides our Scheme implementation, there are JavaScript and Dart implementations in active development currently with hopefully many more to follow.