Plugins as dylibs

Nothing new in the image below! Under the hood though, the code changed...

From

Build and run Rust plugins as processes.

Pass parameters in as a JSON string to the command-line. Receive output as YAML on stdout.

Simple but not the most efficient encoding and limited to one fixed output on stdout.

⟶

To

Build and run Rust plugins as dynamic libraries.

Pass parameters via JSON still, but plugin functions return structs as bitcode-encoded byte arrays.

Still fairly simple, bitcode seems (not that surprisingly) more efficient. The dynamic library can have multiple entry points for more flexibility.

It's somewhat interesting to note this is my third "try" at plugins already. Maybe I should plan more in advance? Maybe this is part of the learning experience?

#3 Rust dynamic libraries: once I had a better understanding of what I wanted to do, this seems like a more natural fit. Leaves room for more generic plugins, including ones that stay in memory. May want a process/"service"-based mode for added decoupling in the future, but for now, this is a very easy approach for single-file, run-once plugins.

#2 Rust processes: moved to this to get the type checking. As I'm still learning Rust, more or less dove straight into hacking this together just to get something to work. Stuck with the JSON/YAML exchange formats since it let me postpone worrying about them.

#1 Deno-based node plug-ins: had some old JS code for generating terrains. Thought it might be nice to allow the imprecision of JS and just rely on JSON/YAML formats for data exchange. Moved on what I quickly realized I wanted the type-checking of Rust, including on the interchange formats.