Does this scheme give a way to progressively load slices of an array? What I want is something like this:

    ["foo", "bar", "$1"]

And then we can consume this by resolving the Promise for $1 and splatting it into the array (sort of). The Promise might resolve to this:

    ["baz", "gar", "$2"]

And so on.

And then a higher level is just iterating the array, and doesn't have to think about the promise. Like a Python generator or Ruby enumerator. I see that Javascript does have async generators, so I guess you'd be using that.

The "sort of" is that you can stream the array contents without literally splatting. The caller doesn't have to reify the whole array, but they could.

EDIT: To this not-really-a-proposal I propose adding a new spread syntax, ["foo", "bar", "...$1"]. Then your progressive JSON layer can just deal with it. That would be awesome.

I've seen this a lot when someone wants to add "workflow automation" or "scripting" to their app. The most success I'd had is embedding either Lua or Javascript (preferably Lua) with objects/functions from the business domain available to the user's script. This is what games do too. I think it's a great way to dodge most of the work. For free you can support flow control, arbitrary boolean expressions, math, etc.

SEEKING WORK - Portland, OR or Remote

I'm a full-stack developer with 20+ years experience. My specialties are deep Postgres consulting, web development in Rails/Django, and devops with Kubernetes, AWS, Azure, Terraform, Ansible, etc. From time to time I've done projects in Javascript/Typescript (React, Vue, Angular, Node), Java, C#, C, Go, Rust, Elixir, Perl, etc.

I am reliable, easy to work with, quick to turn things around, and a good communicator. I can work solo or on a team, either as lead or a team member. I value client satisfaction as highly as technical excellence.

You can see some of my recent work here:

https://illuminatedcomputing.com/portfolio

https://commitfest.postgresql.org/49/4308/ (Adding SQL:2011 application-time to Postgres)

https://commitfest.postgresql.org/31/2112/ (Adding multiranges to Postgres)

https://github.com/pjungwir/aggs_for_arrays

https://github.com/pjungwir/aggs_for_vecs

https://github.com/pjungwir/active_model_serializers_pg

If you'd like to work together, I'd be happy to discuss your project!: pj@illuminatedcomputing.com

Great article! I'm looking forward to reading the rest of the series.

I noticed a couple details that seem wrong:

- You are passing `context` to `log_then_get` and `get`, but you never use it. Perhaps that is left over from a previous version of the post?

- In the fiber example you do this inside each fiber:

    responses << log_then_get(URI(url), Fiber.current)

and this outside each fiber:

    responses << get_http_fiber(...)

Something is not right there. It raised a few questions for me:

- Doesn't this leave `responses` with 8 elements instead of 4?

- What does `Fiber.schedule` return anyway? At best it can only be something like a promise, right? It can't be the result of the block. I don't see the answer in the docs: https://ruby-doc.org/3.3.4/Fiber.html#method-c-schedule

- When each fiber internally appends to `responses`, it is asynchronous, so are there concurrency problems? Array is not thread-safe I believe. So with fibers is this safe? If so, how/why? (I assume the answer is "because we are using a single-threaded scheduler", but that would be interesting to put in the post.)

How did JFrog know this github token was so powerful, compared to all the other ones I'm sure their scanner detects? What caused a human to get involved?