YHK - yet another hacker news clone

the rest of the thread yes but not the thread before

The link to the github works. Everything else opens google play store page for twitter for me.

The Twitter/X link doesn't show the full thread without a login. It also doesn't tell you that something is missing, so I guess it's normal for people to think they're seeing everything.

What X shows me: https://celsoazevedo.com/files/2026/x.webp

With a login/nitter: https://celsoazevedo.com/files/2026/nitter.webp

Most of my current Goose projects are games, not surprisingly, but I have some language/tooling ideas as well.

As for Amiga E, I am very proud of having made it way back when obviously, but it doesn't stack up against my more modern languages (Goose and Lobster), so I think I'll leave it be :)

The compiler automatically optimally allocates all arrays currently in scope that are able to grow to "stacks" (address spaced reserved areas).

The programmer choose what to store where, so you typically store things in arrays by lifetime. Goose gives you many more tools to do that, it can store entire variable sized trees of an enum type in a single array.

You try to avoid having to deallocate in mixed/random order, but if you absolutely must, you can turn arrays into pools, basically.

A big part of this making it base the code of this new compiler on my previous compiler for the Lobster Programming Language. I had it go thru that codebase, distill an elaborate code style guide from it, and used that to make it write the new code pass by pass in that style. That made me feel "at home" as if it is my code, easier to review etc, and easier to know we're going in the right direction by seeing similar structure to my past compiler work.

Once the initial compiler was there it became easier, as Fable is rather good of working within the context of what is already there.

In this particular combination, most certainly.

There is lots of prior art on the individual parts of the design, e.g. "regions" and various stack languages etc, see: https://github.com/aardappel/goose/blob/master/docs/design/p...

Part of this is that 64-bit address spaces make this design practical, and almost all languages in use today were designed with the limitations of 32-bit in mind. Once you can assign arrays huge amounts of address space, you don't have to realloc, which gets you stable pointers, and a lot of the other Goose features.

Yes, the compiler guarantees references to data structures can't escape. I believe it does that "perfectly" :)

It certainly requires the programmer to rethink how they structure their data, as you have to think of where it is going to be stored, and how to store it in a way such that it will have similar lifetimes to what it is stored with, to get the most out of the language.

I parsed it as "A record that is ((160 bytes and an allocation) in C++) is ((29 bytes and none) in Goose)."

So, I read it as, "C++ uses 160 bytes and an allocation, when Goose requires 29 bytes and no allocation".

It means that to do variable sized things like vectors and strings, C++ often ends up having to allocate their contents dynamically. Which results in data structures with lots of 64-bit pointers over multiple allocations.

Even Rust's "enum" feature, which can store different sized things all in the same space, does that at the cost of the smallest variant being just as big as the biggest.

Goose can do all of that not only inline (no pointers), but with variable size, meaning small items take less space. It's like a serialized data representation, but iterable. It makes for big space savings vs these languages.

I think they have slightly different places on the "speed vs ease of use" pareto frontier.

With Goose, the core design favors speed over everything else. Though not only was I able to make that safe, it is fairly pleasant to use. But it remains a low level systems language that requires you to think hard about data organization.

Lobster is a waaay more high level language made to be pleasant to use first, fast second. Surprisingly though, it can get pretty close in speed to C++/Rust nowadays too, but still a lot slower than Goose.

The copy is made by the runtime, which obviously does use atomics underneath, but you don't ever use these yourself.

The workers are threads. The separate memory is the concurrency model, but it's still single process, multiple threads.

The "faster than" is on average, and both in my own benchmarks and independent benchmarks you can find examples of algorithms where it is slower, but they tend to be the exception. "substantially" slower I haven't found yet.

https://kostya.github.io/LangArena/#/top_tab