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?
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
What does Goose change about memory management ?
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.
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?
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.
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:
I'll have to look a bit deeper to decide if it's feasible to write many things in this language.
What kinds of things do you think might not translate well?
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.
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
You could write everything if you refactor to continuation passing style
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.
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.
Faster than C++ is always a head-turner. Curious what "magic" enables that with memory safety.
Usually strict aliasing.
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.
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.
I'm always fuzzy on this, so 116% faster or 16% faster? The benchmarks suggest 16%.
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???
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..
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 that used stack for everything.