That's kind of his point, you can't write a GC language interpreter in a GC language forever, eventually you need a non-GC language to actually implement the GC in. So in this way writing a Javascript executor in a GC language wouldn't really make sense, you're just adding needless layers of abstraction (at a serious performance cost). So I think a browser is an excellent example of an application which can't really be written in a GC language. Other examples might be Databases and realtime applications.
Anyway, even if you absolutely had to use a non-GC language to implement a GC, that would not preclude writing 99% of the browser in a GC language and only the GC in something else.
How do they compile/interpret PyPy's GC, is the compiler/interpreter written in a GC language? I said you can't do it forever, eventually you need to drop to a non-GC language (I feel very certain of this, so if I'm wrong I'd really like to know).
Also, why would implement GCs multiple times at different levels of abstraction in the stack, other than for something specific like PyPy which is specific like designing an interpreter to help test language features quickly?
PyPy is originally bootstrapped on the C Python interpreter, but it can then interpret and compile itself without relying on CPythob anymore. If you insist, then once PyPy is bootstrapped, the "drop to a non-GC language" is its process of having compiled the garbage collector's Python code to machine code.
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.
> 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.
Of course you need to drop to some sort of non GC language, or you would need a hardware GC. However look at Iota [0], that can compile LLVM to Common Lisp. So you can run GC and non GC languages within, kind of, Common Lisp. Or look at all the projects that compile a language to javascript, and there is no reason why the reverse could not be done.
