Goose:experimental lang 1.16x faster than C++ and 1.12x than safe Rust, mem safe

bobbydigitales 49 points 59 comments September 18, 2026
github.com · View on Hacker News

Discussion Highlights (20 comments)

MiroslavPokorny

What does Goose change about memory management ?

backlands

> Goose looks familiar like C or Rust, and is built on one idea: there is no heap So it looks like it restricts the memory management to 100% scope based. I expect that makes a lot of designs for programs not translate to it as well as they fit in Rust or Java (for example). There are a bunch more constraining design choices they list further down: > - Nothing ever moves > - ... A string, an array of strings, a record with variable-size fields and an array of those records are each one contiguous block with no pointer in it I'll have to look a bit deeper to decide if it's feasible to write many things in this language.

dadoum

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.

finn888

Faster than C++ is always a head-turner. Curious what "magic" enables that with memory safety.

tom_

So much Claude text. I'm sure this is great (I did a bunch of stuff with/to aardappel's lobster, years ago, and it was pretty tidy, and quite easy to work with), but: Claude's writing makes my brain melt. It's a no from me. I'm sorry.

webprofusion

I'm always fuzzy on this, so 116% faster or 16% faster? The benchmarks suggest 16%.

jlkuester7

All-stack-no-heap Isn't this kind of the point of Java's Project Valhalla or am I just confused???

respectattentio

Great launch! I was thinking about making a language with same thoughts: Safer than C++ and faster than rust (and a 3rd thing: optimized for AI) and you actually did it for me. Hooray! Just the AI language optimization thing is missing..

xdavidliu

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.

karmakaze

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

afgrant

Unfortunate language/protocol name reusal. Watch out for these. https://www.se.com/ww/en/download/document/998-2095-18-12-19...

netbioserror

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.

pizlonator

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

RantyDave

So if nothing moves, you can't make an array that grows?

sodacanner

I just can't understand why you'd let an LLM write your README. The code, the implementation? Sure! That's the purpose of a coding agent. The README, though? That's the first thing I read about your project. Anybody familiar with LLMs is going to pick up that one wrote it in an instant. Surely you understand your own project well enough to write it in your own words, right? If not, what's even the purpose of the project in the first place?

BobbyJo

Am I the only one with a deep aversion to the keyword "let"?

fwlr

This is an interesting idea. It’s a pity it was implemented by LLM instead of explored by someone with curiosity.

thayne

> All elements remain valid at all times. free does not release any memory and does not end any lifetime — it adds an index to a freelist. The slot is still a live, well-typed Item afterwards, and it still belongs to the pool, which still belongs to its owning scope. > > So there is nothing here to be unsafe. A reference to a freed-and-reused slot reads a different Item — a perfectly good one, just not the one you were thinking of. This avoids the dreaded undefined behavior, but it can still be pretty bad. For example, accessing a record that has been freed and re-used could leak sensitive information from one user to another. Granted that kind of bug is possible with any memory safe language, but this pattern is probably more like to be used in goose than languages with automated memory management.

dang

The submitter asked us to take this down because the language is missing some important elements they should have added before posting. I don't think we can do that because the thread is so active, but we'll bury this one so they can repost it when ready.

Mawr

> 1.16x faster than C++ and 1.12x than safe Rust This alone is enough to tell you have no idea what you're talking about, and it's not even about the ambiguous usage of the word "faster". There is no way for performance claims that are a) this accurate, b) this small, to possibly be real. You certainly just cherry-picked favorable benchmarks. Ah, here it is: "Over sixteen benchmarks Goose runs at about...". First, let's make this statement actually correct: "Over sixteen micro benchmarks Goose runs at about...". That's not the same statement as "1.16x faster than C++ and 1.12x than safe Rust". Not by a mile. You need a test suite comprised of a wide variety of real world programs, not 16 microbenchmarks, possibly specifically chosen to play to the strengths of your language.

Semantic search powered by Rivestack pgvector
7,105 stories · 65,136 chunks indexed