Boron Language

[hostilefork]

@WickedSmoke

Slices save tons of memory when parsing

Slices have been suggested, but they seem to make the "hidden index" issue worse than it already is...and the semantics on mutable series feel pretty sketchy:

Working with Sub-Series vs /PART (Series "Slicing")

If you'd like to speak to those issues there, feel free. The main reason I'd like to see it answered would be to get rid of this /PART refinement that spreads all over the place.

@WickedSmoke

Threads can be created with a port! that allows data to be transferred between the private stores. The Copr build tool makes use of threads when the jobs option is used.

Ren-C is now "stackless", which is important for things like being able to yield up the stack to do I/O in the browser. I break down how this affects writing something like a WHILE native in this post:

Stackless Is Here, Today, Now! 🥞 - #2 by hostilefork

Building on that with green threading--like Go--is the direction I think makes the most sense. So something along the lines of "channels" would be used to communicate.

@WickedSmoke

The 'serialize function packs data into a binary image. Series positions, slices, and non-global word bindings are retained.

Red has "Redbin", which I haven't really looked at. In the meantime, their "redbin specification" page seems to have vanished:

Red Programming Language: redbin

But it would seem clear to me that there are much more foundational problems to solve...vs. tailoring hibernation for a system with so many unsolved design issues. Generic hibernation lets it be someone else's problem:

CRIU
Application checkpointing - Wikipedia

I haven't needed to persist a Ren-C session...but I'd use something like that if I wanted to.

@WickedSmoke

My main priority is keeping the system small, so the Boron startup footprint is about 15x smaller than Rebol 3 Alpha. See the start-quit results for actual numbers.

Just about every time I've tackled some weird optimization it has turned out to be too soon for that. I want the design to be something that can truly be composed in interesting ways--and using the interpreter in deep and heavy ways is good testing for that composability.

So I'm more focused on the spirit of dependency control, vs. worrying much about cycle counts or trying to minimize code running at boot. The web build notably minimizes its included extensions to JavaScript interop and the Console...that's it.

That said, it's been a really long time since I've bothered to pick apart performance or memory use (getting a fast new laptop will do that to you). I need to take some time to do it. But when I do, I wouldn't be doing it at the level of "oh, this mezzanine thing should be written as a one-off native in C that makes the boot faster"...I'd only want to be optimizing generic reusable parts.