News for hackers. Stuff that matters.
Re:Inside D's GC by pjmlp on Tuesday June 20, 2017 @01:08PM (#14596375)
As a former Oberon user and a Modula-3 fan, I would rather see the GC being improved.

History is full of GC enabled systems programming languages since the Xerox PARC days, the latest example being System C# for Midori.

Most projects failed more due to political reasons than technical ones.

Which is why I appreciate Apple, Google and Microsoft's attitude regarding forcing automatic memory management on developers for their OSes, to a certain extent.

Re:Inside D's GC by jacquesm on Tuesday June 20, 2017 @04:24PM (#14598265)
Garbage collection is very hard to combine with real time, and at the kernel level it is unacceptable (because it introduces a pathway with very hard to bound latency).

Since that is the exact use case that interests me when it comes to languages such as C, Rust and D I would rather see the whole thing taken care of at compile time with very strict rules about how long it can take to traverse a certain piece of code, especially when it runs on the other side of the syscall interface.

Re:Inside D's GC by pjmlp on Wednesday June 21, 2017 @01:55AM (#14601079)
Garbage collection at kernel level is just yet another kernel daemon with the same constraints as all the others.