3 ms·
It’s different because Go is garbage collected. See my other reply.
by skybrian 1y ago
It’s different because Go is garbage collected. See my other reply.
- pjmlp 1y agoNo it is not, that is the anti-GC folks agenda since Xerox PARC days, placing all GC languages into one big basket, not learning what actually makes one specially tick, the language features available for low level coding in each programming language and such. Just sticking to the old ways is why we don't get progress in some industry corners.
- skybrian 1y agoI’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.