4 ms·
I’m not anti-GC. There’s nothing wrong with using a garbage collected language. However, if you use a built-in garbage collector, you do need to play by its rul
by skybrian 1y ago
I’m not anti-GC. There’s nothing wrong with using a garbage collected language. However, if you use a built-in garbage collector, you do need to play by its rules, or it’s not going to work. These rules are language-specific and limit what you can do efficiently when writing an interpreter, versus writing your own GC that’s purpose-built.
For example, Go’s garbage collector isn’t going to do as well at JavaScript as V8’s garbage collector, because the only unions it understands are Go interfaces. Also, the garbage collectors for other languages mostly don’t support some features of the Go language, such as taking pointers into the middle of objects.
You can still write an interpreter in any language, but there will be an efficiency cost when the languages are too different.
- pjmlp 1y agoI would say it is a matter of implementation, taking the best advantage of unsafe, Assembly, value types and generics. Not everything has to try to replicate C in language XYZ. But I do agree, among all languages I would rather reach out for D, C#, any of the MLs or Haskell, Lisp or Scheme variants, instead of Go. Also if ultimate performance is the goal, then nothing beats handwriten Assembly, so that places both C and GC languages out of the game, as Android has been doing since Android 7, in case there is no PGO data available for the JIT.