> But you're still wrong on this drop being necessary, I think. You can do it just fine in a language with GC that also allows you to allocate a block of memory that is not considered by the GC.
I think it's a bit disingenuous to say a "GC language compiled a GC language" when the compiler used non-GC portions of the language to do it. You're right, I should have said "A language which can work without a GC" instead of "a non-GC language;" but I think the spirit of my comment was clear.
That said I think what you said above is right, and non-GC code is really only necessary in the hot parts of an application (and applications that can't use dynamic allocation for whatever reason, but that's another discussion). Rust is even working on adding GC support [1] (albeit very slowly, as they should). That said non-GC languages (or at least the ability to write code that doesn't use a GC) is still necessary in many industries for many reasons; that isn't going to change for a long time, if ever.
I think it's a bit disingenuous to say a "GC language compiled a GC language" when the compiler used non-GC portions of the language to do it. You're right, I should have said "A language which can work without a GC" instead of "a non-GC language;" but I think the spirit of my comment was clear.
That said I think what you said above is right, and non-GC code is really only necessary in the hot parts of an application (and applications that can't use dynamic allocation for whatever reason, but that's another discussion). Rust is even working on adding GC support [1] (albeit very slowly, as they should). That said non-GC languages (or at least the ability to write code that doesn't use a GC) is still necessary in many industries for many reasons; that isn't going to change for a long time, if ever.
[1]: https://manishearth.github.io/blog/2016/08/18/gc-support-in-...