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

bbobbydigitales about 2 hours ago 36 commentsRead Article on github.com

ES version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

80% Positive

Analyzed from 980 words in the discussion.

Discussion (36 Comments)Read Original on HackerNews

tom_•about 1 hour ago

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.

bobbydigitales•41 minutes ago

Yeah it's very clear at the bottom that it's created by AI. I think this is an interesting case where someone with some great ideas they never got to can actually implement them. I personally hate the Claude style, but just looking at the samples was enough to get a feel for the language.

tom_•32 minutes ago

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.

backlands•about 1 hour ago

> 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.

com2kid•10 minutes ago

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.

skew-aberration•about 1 hour ago

You could write everything if you refactor to continuation passing style

eyegor•38 minutes ago

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.

cmrx64•32 minutes ago

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

bobbydigitales•about 1 hour ago

What kinds of things do you think might not translate well?

tombert•about 1 hour ago

Not the OP, but I'm thinking about like closures?

Say you wanted to make a Node.js framework with callbacks that react to an event. The callback might be a closure that captured some of its surrounding variables. At that point, any of the captured variables are not trivially stack-allocated.

You might be able to do something similar to what Rust does with moving though.

com2kid•7 minutes ago

Nah we did something similar on Microsoft Band. I wrote about how - https://meanderingthoughts.hashnode.dev/cooperative-multitas...

The tldr is you had to preallocate a struct with anything you wanted captured ahead of time.

skew-aberration•about 1 hour ago

You could predefine your event handlers within your context, then call 'enter framework' and pass your event handlers as arguments. this is continuation passing style

pizlonator•22 minutes ago

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

finn888•about 1 hour ago

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

wmf•about 1 hour ago

Usually strict aliasing.

Ohentis•7 minutes ago

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).

afgrant•33 minutes ago

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

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

xdavidliu•35 minutes ago

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.

t3r•4 minutes ago

My read: it's not the style per se, it's the association. People are just sick of AI slop and react badly to anything that smells like it. The summary itself was reasonably informative, I'd say.

respectattentio•41 minutes ago

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..

elromulous•27 minutes ago

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

RantyDave•21 minutes ago

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

bobbydigitales•17 minutes ago

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

karmakaze•35 minutes ago

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

jlkuester7•about 1 hour ago

All-stack-no-heap

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

dadoum•about 1 hour ago

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.

webprofusion•about 1 hour ago

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

tom_•about 1 hour ago

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.)

levkk•about 1 hour ago

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.

MiroslavPokorny•about 2 hours ago

What does Goose change about memory management ?

zamalek•about 1 hour ago

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.

kenferry•about 1 hour ago

A lot - title could probably use editing. The language has no heap, only stack memory, so the only deallocation is returning from a call stack frame.

yndoendo•about 1 hour ago

How big is the stack? Too often large data will blow the top and destroy adjacent stacks in multi-thread environments. Are memory barrier fences used to check against overflow?

gcoakes•37 minutes ago

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.

netbioserror•28 minutes ago

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.