No GC

[sirinath]

A new functional language with a GC is not a earth shattering. If you can do static analysis to figure out the lifetimes without having to specify them at all, this would be a breakthrough. Also see: https://github.com/carp-lang/Carp

[brendanzab]

Doing a safe functional language with currying and nicely composable functions is super challenging to do without a GC. There's only so much ground you can break in a single language! 😄

[sirinath]

It is not easy but perhaps if you track memory usage effects it might be possible.

[brendanzab]

What do you mean by 'track memory usage effects'?

[sirinath]

See https://github.com/Microsoft/dafny and perhaps https://www.fstar-lang.org/

[sirinath]

My Bad. It is Koka - http://rise4fun.com/Koka/tutorial/guide through the above languages also has effects.

[sirinath]

Also http://rise4fun.com/SLAyer and other reasearch projects at http://rise4fun.com/ has some relavence. Also Nim has effect system which track memory related items: http://nim-lang.org/docs/manual.html#effect-system

[Marwes]

Having no gc would be interesting and very fitting for an embeddable language as the gc pauses can be a big detractor for applications such as games which need predictable throughput. I do however hope that having one heap for each executing thread I gluon can help out by letting the pause times be shorter

I will have to brush up on the linked languages but from what I remember they all come with both additional restrictions and they also are quite complex.

[sirinath]

Also this might be of interest for static analysis: http://flix.github.io/

I feel static whole program analysis you might be able to get rid of GC. Starting point would be escape analysis with GCed heap and a non GCed heap where part of the variable's lifetimes are infereded. Iteratively improve it until you are able to infer all usages. Also when each new reference is created the number of references can be counted as part of static analysis. Based on this you can collace which and allocate memory in regions.

[Marwes]

I definitely want escape analysis at some point (though that is still some ways of). Even a coarse analysis could go a long for native functions if they could mark whether their arguments escape or not (native_set_position { x = 1.0, y = 0.0 }, the allocation of the record is likely not necessary since for such a small type it could be directly marshalled to a Vec2<f64> or similiar in Rust).

Static whole program analysis may be rather tricky as I hope to eventually have some sort of hot-swapping of code (ala Erlang) and gluon is currently quite close to dynamic languages when it comes to module loading for that reason. This it means that the concept of "the whole program" may be quite malleable which means additional complications when it comes to static analysis (not saying it is impossible though, just more complicated).

[erlend-sh]

Having no gc would be interesting and very fitting for an embeddable language as the gc pauses can be a big detractor for applications such as games which need predictable throughput.

There’s recently been a good conversation about that regarding Mun: mun-lang/mun#206