> 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.
Yeah, it seems like the sweet-spot for this is real-time and embedded because it should be extremely conservative and consistently fast about memory allocation and de-allocation.
Sad that it's got plug-in stuff as a "non-goal", because I'd love to see this as a scripting engine for gaming (since that's Wouter van Oortmerssen's background). But I imagine a "compiles to C" language would at the very least be functionally impossible to sandbox.
Edit: Question for anybody who's playing with this: When he talks about no generics he says that ADTs still work... is that like his example of writing a function "double" that returns "a + a" and works for any type that supports the plus operator?
It sounds like compile-time duck-typing but I'm having trouble working out the boundaries of that in my head. It sounds like it would only work with fully-open-source libraries for one thing since everything would have to compile from source. Anybody have experience with that sort of thing?
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.
Pxtl · · focus · HN ↗
Sad that it's got plug-in stuff as a "non-goal", because I'd love to see this as a scripting engine for gaming (since that's Wouter van Oortmerssen's background). But I imagine a "compiles to C" language would at the very least be functionally impossible to sandbox.
Edit: Question for anybody who's playing with this: When he talks about no generics he says that ADTs still work... is that like his example of writing a function "double" that returns "a + a" and works for any type that supports the plus operator?
It sounds like compile-time duck-typing but I'm having trouble working out the boundaries of that in my head. It sounds like it would only work with fully-open-source libraries for one thing since everything would have to compile from source. Anybody have experience with that sort of thing?