Well, I'll believe you about fp debugger, so only problem left with OcaML and Clojure, each of them have GC with non-linear complexity (Clojure as I understand using BEAM GC which claimed soft-realtime, meaning 90% of GC work will look like realtime, but OcaML using some typical GC), and what all these mean for games - they will suffer framedrops or even short freezing, when GC running.
Exist two approaches to overcome GC problem, but if somebody will again minus my comment I will not bother to find links in my records.
1. Here on HN mentioned GC-free fp platform.
2. Few years ago appeared GC algorithm with linear complexity (sure, with limitations, but good enough for example for 16-bit consoles level games).
Unfortunately, haters minusing comments, but don't add anything valuable, and author was not mentioned these problems.
> Unfortunately, haters minusing comments, but don't add anything valuable
Tell me about it. It happens so often that I am very reluctant to leave comments now, especially on topics that I know people have already made up their mind and are not willing to discuss it with an open mind. That said, I did just leave a comment about something I probably should not have, but oh well.
Is it really Clojure that uses BEAM? I thought it was a JVM-based language, I would have to look this up.
BTW OCaml finally has multicore support, which was a long time coming.
[1] Especially this part: "OxCaml gives programmers tools to control allocations, reducing GC pressure and making programs more cache efficient and deterministic.".
Unfortunately, I see very familiar things from Perl world - many people made really interest things alone, but for some reason, they don't organize to make one direction really on par with commercial platforms (even when with current technologies could make efficient distributed governance, and even could make significant sells for sustainable development). I mean, people disperse resources, making many good small things, but most Open Source software recessing or even in crisis without moving ahead.
I've seen JVM, BEAM, CLR at field with heavy load, they all have significant drawbacks, but from my opinion, CLR ecosystem developing faster than other mentioned.
Clojure is not a "JVM-based" language, it's a hosted language - means Clojure is designed as an abstract language that can be implemented on different runtime platforms. The language's core abstractions (persistent data structures, protocols, vars, etc.) are not tied to any particular host - it's just that JVM variant was first and remains the main focus. Clojurescript run on JS VMs, ClojureCLR on .NET, ClojureDart - targets DartVM, babashka is great for scripting, SCI - for small embedded Clojure DSLs. There is also Clojerl - that runs on BEAM, and Jank for native compilation. You can run Python in Clojure and Go, and it just keeps growing. Seriously, one could learn only Clojure and write code for [almost] any platform.
Exist two approaches to overcome GC problem, but if somebody will again minus my comment I will not bother to find links in my records.
1. Here on HN mentioned GC-free fp platform.
2. Few years ago appeared GC algorithm with linear complexity (sure, with limitations, but good enough for example for 16-bit consoles level games).
Unfortunately, haters minusing comments, but don't add anything valuable, and author was not mentioned these problems.