wuffs

binary data. The handful of non-trivial examples I found only used wuffs-the-library, as a vendored component in a larger project. The lack of wuffs-the-language use after several years seems a strong sign that I shouldn't look to wuffs for my project. Given the 'workarounds' in #24 are still present after 3 years, it doesn't even seem that widely internally at Google. Does anyone here have experience to share, or pointers to related projects?

you also have access to some low-level stuff, so if you were E.G. trying to come up with a little language that had super-good performance, C might be a good choice. (See also, [Wuffs](https://github.com/google/wuffs), by Nigel Tao et al at Google). A suggestion, if you do target C -- don't work too hard to find isomorphisms between C's data structures and YourToyLang's data structures. Back around 1990, I did my C-generating compiler for Modula-3, and a friend at Xerox PARC used C as a target for Cedar Mesa, and Hans used it in a lower-level way (so I was mapping between M-3 records and C structs, for example, Hans was not) and the lower-level way worked better -- i.e., I chose poorly. It worked, but lower-level worked better. If you are targeting a higher-level language, Rust and Go both seem like interesting options to me. Both have the disadvantage that they are still changing slightly but you get interesting "services" from the underlying VM -- for Rust, the borrow checker, plus libraries, for Go, reflection, goroutines, and the GC, plus libraries. Rust should get you slightly higher performance, but I'd worry that you couldn't hide the existence of the borrow checker from your toy language, especially if you wanted to interact with Rust libraries from YTL. If you wanted to learn something vaguely publishable/wider-interesting, that question right there ("can I compile a TL to Rust, touch the Rust libraries, and not expose the borrow checker? No+what-I-tried/Yes+this-worked") is not bad. I have a minor conflict of interest suggesting Go; I work on Go, usually on the compiler, and machine-generated code makes great test data. But regarded as a VM, I am a little puzzled why it hasn't seen wider use, because the GC is great (for lower-allocation rates than Java however; JVM GC has higher throughout efficiency, but Go has tagless objects, interior pointer support, and tiny pause times. Go-the-language makes it pretty easy to allocate less.) Things Go-as-a-VM currently lacks: - tail call elimination (JVM same) - don't ever construct a pointer to Object+sizeof(Object) (i.e., to the first byte past the end) (JVM same) - defined semantics for racy programs that don't use atomics (structures can tear; there is a race detector, use it). (JVM same-ish; racy programs suck) - integer overflow checking (JVM same) - consistent conversion from +/-FPInf to integers, - if you're not careful about expressing floating point a+b*c, you'll get the platform multiply-add rounding - signaling/quiet NaN representation follows the platform Some of these are on my list of Would-Be-Nice to fix, but that doesn't mean they will happen, because there are O(zero) people using Go as a VM, as far as I know, so their problems have zero weight. Tail-call-elimination in particular would be hard, and I see no substantial benefit in solving the pointer-past-end problem (it's a minor issue in our own code generation, and we deal with it).