No GC about gluon HOT 10 OPEN

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.

from gluon.

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! 😄

from gluon.

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

from gluon.

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

from gluon.

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

from gluon.

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

from gluon.

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

from gluon.

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.

from gluon.

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

from gluon.

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

from gluon.