4 ms·
> Both Nim and Kotlin Native have a runtime in the form of a GC/automatic memory management, so you'd still need another language "beneath" them to get the job
by simiones 7y ago
> Both Nim and Kotlin Native have a runtime in the form of a GC/automatic memory management, so you'd still need another language "beneath" them to get the job done.
That is not necessarily true. Not sure in the case of Nim or Kotlin Native, but the GC itself can be written in Nim/Kotlin Native in principle as well.
- guggle 7y agoFor reference: https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html
- jerf 7y agoIn that case, the "language below" Nim or Kotlin would itself be Nim or Kotlin, but you'd still need that additional layer. It's not a crazy idea. Go actually works that way already; the runtime of Go is implemented in Go. For example, here's the sweeping component of the gc: https://github.com/golang/go/blob/master/src/runtime/mgcsweep.go https://github.com/golang/go/blob/master/src/runtime/mgcswee... But that doesn't mean you can get a Go without a runtime; the final executable's GC may have come from compiled Go rather than something else, but it still irreducibly has GC in it. The whole thing is bootstrapped, so at any given time when some bit of Go code is running, it is supported by GC and the rest of the non-optional runtime, even when compiling code that itself is going to be the runtime of some other executable in the future.