3 ms·

Inko used to have a tracing GC (see https://yorickpeterse.com/articles/friendship-ended-with-the-garbage-collector/ https://yorickpeterse.com/articles/friendshi

• aidenn0 2y ago
  Thanks for pointing me to that. Upon reflection, there's a further conversation to be had in PL design: > The rationale for this is that at some point, all garbage collected languages run into the same issue: the workload is too great for the garbage collector to keep up. What this actually means is "The program I wrote is a poor fit for the garbage collector I am using." which can be fixed by either changing the program or changing the garbage collector. People often focus on the latter and forget the former is a possibility[1]. Similarly with single-ownership and borrows, you can write a program that is fighting the memory management system (see e.g. any article on writing a doubly-linked list in Rust). In other structured memory allocation systems (hierarchical, pools &c.), the memory allocation lends itself well to certain architectures of code. As far as I know, nobody has done a comparison of various memory management systems and how they enable and hinder various forms of program design. 1: The "time" special operator in SBCL shows allocation and GC time statistics by default. I think this nudges people into thinking about how their program is allocating at exactly the right time: when they are worried about how long something is taking.