I think it is supposed to be stacks in the general sense of the data structure, not the literal `sp` register. I imagine they could be arbitrarily sized up to physical limits if you do some mmap magic. I'm still a bit fuzzy about how you could make useful programs with that, but it seems interesting.

If I am reading it correctly, the compiler creates N bump allocators per function (or possibly globally) - where N is (I'm guessing at this point) determined by liveness or similar.

it is, but more specifically it’s an eliminator for a coinductive step.

[delayed]

Might as well go back to ye olden days and put 100% of your memory in a giant preallocated block and instead of stack locals you just use the block. No allocation cost at runtime, cheese benchmarks by making the super arena.

CPS is an intermediate representation, humans shouldn’t have to tolerate it.

Embedded people are well used to this.

Dynamic memory management is a performance enhancement. It lets you more efficiently utilize memory vs static allocation at the cost of, well, lots of types of bugs.

You can always preallocate MAX_NUM_ELEMENTS * SIZE_OF_OBJECT for all your arrays. If someone tries to send you more objects then you have buffer space for you just reject the request.

Latency sensitive programs already do this, since memory allocation is rarely deterministic (although it can be in .NET and other similar languages). Likewise a bunch of destructors going off when an object is freed in C++ also takes a, practically, non-deterministic amount of time. (Really well profiles and controlled programs can make this deterministic if allocation patterns are always identical, but that is rarely the case.)

Of course having fixed sized buffers means you have to have protocols that are aware of size limitations. Most protocols now days assume infinite memory. Everything just fails, badly, when memory does run out.

After having worked in embedded for awhile I grew to deeply appreciate planning around memory limits. Really everyone should be doing it but almost nobody is.

I am researching a similar idea but which allowed moves if the compiler was able to fix the resulting structure, but mine will probably stay a small side project for a long time.

If it's just strict aliasing then you can't be as fast as C++ in all cases. So you have to either provide an escape hatch like Rust (making the memory safety claim only mostly true), or accept worse performance in some cases (making the performance claim only mostly true).

Lest it seem like I'm patting myself on the back for my ability to detect Claude's writing style, as if this instance would be evidence of any particular skill in that department: I did skim the README enough to note that bit.

116% would be 2x which will break the laws of physics. 16% is possible if you're not allocating heap memory, which I believe is the main selling point here.

Evergreen: https://randomascii.wordpress.com/2018/02/04/what-we-talk-ab...

(Feels like it should probably say "1.16x as fast" or "1.16x the throughput" - or something like that.)

All-stack-no-heap

Isn't this kind of the point of Java's Project Valhalla or am I just confused???

The AI optimization is to put it in distribution. So... make it look like python or js?

a flagged-dead comment in this thread:

https://news.ycombinator.com/item?id=49749113

I genuinely wonder how this style minimized the loss function or got the most upvotes in RLHF and yet is so universally hated that it gets flagged to death almost every time, and similar to Reddit. If I were to describe it, it's "snappy" and information-dense, without fillers. I dislike it too of course.

Cluould be viewed like a fancy evoultion of CHICKEN (Cheney on the MTA) that used stack for everything.

Unfortunate language/protocol name reusal. Watch out for these.

https://www.se.com/ww/en/download/document/998-2095-18-12-19...

Nim defaults to this kind of stack management and value semantics, except the `ref` and `ptr` trapdoors are there whenever you need them. So like this, Nim requires no memory annotations or semantics for good, safe default behavior.

Goose is a straightjacket by comparison. I've never enjoyed languages that plant a flag on one mechanism and force users to adapt.

This is neat.

But the benchmarks are tiny, and it’s likely that Goose was tuned on them.

So, I think I would read this as: Goose has competitive performance to C and Rust and I’ll take them at their word that it’s as memory safe as Rust

https://github.com/aardappel/goose/blob/master/samples/02_me...