> 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.
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.
The goose language has dynamic allocation via builtin types, like most systems for the past 40 years (Folks were using dynamic allocation on systems back when 640k was a lot of memory). Most embedded systems these days far exceed the capabilities of 40 year old desk top computers and also use extensive dynamic allocation.
The distinction for goose is that it has fixed locations where the free must occur (function return, effectively), not that it doesn't have dynamic allocation (because it does have dynamic allocation)
People working on cortex m series chips still static alloc though. :D
Them and game programmers. Also the HFT people from my understanding.
The latter two are due to latency concerns.
Still though, it is something that I think more engineers should try out once or twice. Thinking about how buffers actually need to be is a useful exercise.
backlands · · focus · HN ↗
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 · · focus · HN ↗
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.
codys · · focus · HN ↗
The distinction for goose is that it has fixed locations where the free must occur (function return, effectively), not that it doesn't have dynamic allocation (because it does have dynamic allocation)
com2kid · · focus · HN ↗
People working on cortex m series chips still static alloc though. :D
Them and game programmers. Also the HFT people from my understanding.
The latter two are due to latency concerns.
Still though, it is something that I think more engineers should try out once or twice. Thinking about how buffers actually need to be is a useful exercise.