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.
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]
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.
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.
reply