I've also been looking into how to add resource logic / linear logic to ghc Haskell / languages with a similar internal rep as ghc core. Still need to write that stuff up mind you.
There's a long history of no gc free functional language research. Mlkit and clean are probably two of the older but accessible implementations in the wild
[0] https://github.com/wolfgangj/bone-lisp
[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.40...
ATS: https://bluishcoder.co.nz/2011/02/27/linear-datatypes-in-ats...
Stalin does global static life time analysis and MLKit uses GC only to augment it's region based scheme, but you can turn it off (at the cost of guaranteed space safety).
Of course Rust is a bastard child of ML as well.
I've done game development in C++, C#, and JS, and I had to worry about memory management far more in JS than in C# or C++, simply because even something as innocent as adding two vec3s requires you come up with a space for the result first, if you want to avoid gc hitches.
C#'s struct types help here, but it still has plenty of its features increase GC pressure.
I'm curious how did you expect Racket to work without a GC or any Lisp like language for that matter or did you just assume because of video game usage?
> - And regarding Haskell and OCaml, which I only vaguely know about, I had never asked myself how they handle memory. Which makes me ask: are there non-GCed functional programming languages? Does it make sense? (Especially given the kinds of deep complex data structures produced by immutability.)
Rust and C++ depending on your definition of FP. I believe there are some old ML languages as well (and even some old lisps).
I honestly was curious if the OP had some insight that I did not. I realize re-reading the comment it sounds snide but I didn't want to assume the OP's knowledge.
For all I knew Racket could have some ability to avoid GC.
Just because of video game usage and my perception of Carmack as a performance freak who wouldn't compromise on performance. (Sloppy reasoning, I know! Thus, my questions on where GC makes sense in games)
Yes, C++. For the last 18 years the C++ standard has been busy adding functional features to the language. With mixed success, but still the result is quite impressive.
I understand the fact that not everything in a game belongs to the critical 16ms budget (and know about e.g. Unity, which lets you talk C# to it), but I'm still puzzled; can someone expand on:
- Which are these non critical parts? Rendering / physics / animation are certainly in the critical path. That leaves only simple "client" game logic out of it, right? What else?
- For these non critical parts, what are the typical acceptable time boundaries? For example, the article mentions "maximal latencies of around 22ms" for Racket. How is it acceptable for non-critical-path parts? How much would still be acceptable? 50ms? 100ms? "That depends"?
- And regarding Haskell and OCaml, which I only vaguely know about, I had never asked myself how they handle memory. Which makes me ask: are there non-GCed functional programming languages? Does it make sense? (Especially given the kinds of deep complex data structures produced by the immutability that often comes with these languages.)