Rocky Road

Rocky Road is the first prototype of the "Doublespeak architecture", a scripting and runtime architecture that prioritizes hot-reload-driven programming and runtime observability and inspection. The name represents the challenges associated with implementing this archtiecture for the first time in public.

Design Goals

The #1 priority of Rocky Road is to create an immediately usable (although maybe not useful yet) implementation of the Doublespeak architecture in order to prove its improvements in observability and runtime modification over Hearth's capability-based system.

Methodology

THIS IS A PROTOTYPE, we will be throwing anything out that doesn't work and we will be recycling the stuff that does work for future prototypes. Don't worry about making things last, and develop things quick and loose.

No CI; things should be proven to work with hands-on interaction.

New features can be experimented with as needed without calling for much foresight since long-term architecture mistakes are not as huge of a mistake in a prototype.

There is no need for lasting documentation. This is a code-driven project where strong UX comes first, and the nitty-gritty details of how individual components of the system are up in the air and up to change depending on the users. We're building a bazaar, not a cathedral.

This project gains value from use, so it's important to onboard new people into using this system in order to get feedback and seed some initial users of the architecture.

Open Questions

Doublespeak architecture is an experimental successor to Hearth, so there are several specific questions that we need to focus on answering over Rocky Road's development.

Is guest-side code made meaningfully simpler over guest-side code using Flue and Hearth's capability model? Is it easier to write and compose Rocky Road code?

Is event-based control flow overall a more useful model for process execution when compared to Erlang-style serial control flow and in-place message receiving?

Further Research

Some problems should not be addressed by Rocky Road but should be addressed in a future Doublespeak prototype.

• host plugins or rich integration into an existing native runtime
• CI
• unit testing
• message schemas, validation, and backwards compatibility
• having multiple objects be defined in a single Wasm module
  • general idea: initialize some bindings-internal singleton as a dyn Reactor or something, and use a function pointer to a monomorphization of an entrypoint function that is generic over a Reactor. then, wire all of the reactor function exports and hot reload functions exports to be polymorphic over that singleton
• inspecting the host- and guest-side log output of processes
• limiting use of process resources
  • lunatic's resource limits are super comprehensive
  • timing limits?
  • memory page limits?
  • use Semaphores to represent concurrent, limited, shared resources
• securing the registry
  • capability-based permissions before made security relatively straight-forward
  • could we turn registries into general-purpose resource kinds in the future?
  • maybe they could work sort of like watch channels but indexed by strings and with update events