[charlesetc]

It seems a bit premature to claim high performance without having a story for memory. I'm sure ocaml, swift, and basically all languages that do any type of runtime garbage collection would be significantly faster without it.

[FBMachine]

Hi Charles,

That's a fair comment. I will say however that the references to performance are more an attempt to keep it in mind from the beginning, rather than being an assertion at this point. I only began working on it shortly after my mom passed away last month (it's dedicated and named after her), so at this stage I'm mostly goal setting and rapidly prototyping.

I hope you can take time to give it another look when its further along. Thanks!

[bunderbunder]

It's complicated. The best runtime GC nowadays tends to take on some of the performance characteristics of a stack, including that finding a new memory slot is O(1). Heap allocation in many non-GC languages, by contrast, ends up involving some sort of relatively gross search for free memory. The same mechanisms also mean that, if you aren't doing anything in particular to manage your memory layout, the GC language is likely to achieve better locality of reference at run time.

This isn't to say that better performance isn't achievable in languages with manual memory management, but doing so often requires a special effort that just isn't going to happen most the time, for reasons of practicality.

That said, there are certain classes of program where the story is different: https://en.wikipedia.org/wiki/The_Computer_Language_Benchmar...

[zokier]

I think the point was that you can make memory allocation very fast if you do not care about ever freeing memory, but obviously that is not exactly sustainable strategy. So that is why making claims about performance before figuring out memory management story is bit premature.