bakeware VS Halide

I've not used either of them myself, but I think they fit some of your requirements (simple programs, efficient, events, no memory management). There seem to be libraries for constraint programming. It does run on a VM with a GC though. And while programs can be compiled to binaries, they're not tiny.

There’s a couple of approaches to this problem going on:

1. Bakeware “bakes” your application together with the entire Erlang/OTP/Beam/Elixir stack into a single binary. Given the “batteries included” philosophy of OTP, these binaries end up being fairly large, but it works: https://github.com/bake-bake-bake/bakeware

2. Lumen compiles Elixir, Erlang and friends into WASM. This will in time enable small fast cross-platform static binaries, but it is not done yet: https://getlumen.org/

That one is out of date, the one it forked of is not: https://github.com/bake-bake-bake/bakeware

I've read that the Javascript runtime Deno is able to compile to a static binary and has a standard lib that is practically a port of Gos standard library....i feel the static binary deal is quite a game changer today given its portability in devops ....Elixir is able to compile to static binaries as well with bakeware 😊https://github.com/bake-bake-bake/bakeware

It's already possible with https://github.com/bake-bake-bake/bakeware ✌️😊

If CPU/GPU execution speed is the goal while simultaneously code golfing the source size, https://halide-lang.org/ might have come in handy.

This is a task where Halide https://halide-lang.org/ could really shine! It disconnects logic from scheduling (unrolling, vectorizing, tiling, caching intermediates etc), so every step the author describes in the article is a tunable in halide. halide doesn't appear to have bindings for golang so calling C++ from go might be the only viable option.

Probably would have been much easier to do 15 times in https://halide-lang.org/

The idea behind Halide is that scheduling memory access patterns is critical to performance. But, access patterns being interwoven into arithmetic algorithms makes them difficult to modify separately.

So, in Halide you specify the arithmetic and the schedule separately so you can rapidly iterate on either.

It is not the sorting per-se which was improved here, but sorting (particularly short sequences) on modern CPUs with really the complexity being on the difficulty of predicting what will work quickly on these modern CPUs.

Doing an empirical algorithm search to find which algorithms fit well on modern CPUs/memory systems is pretty common, see e.g. FFTW, ATLAS, https://halide-lang.org/

Halide https://halide-lang.org/

It doesn’t apply in this case, but in general if you really want the best vectorization I would suggest using https://halide-lang.org instead of trying to coerce your compiler.

If we drop the "APL" requirement, wouldn't Halide fit your criteria for the third?