3 ms·

I'm curious too. Among the major language implementations I can think of, almost every single one is dogfooded as much as it can be. In other words, dogfoodin

by comex 2y ago

I'm curious too. Among the major language implementations I can think of, almost every single one is dogfooded as much as it can be. In other words, dogfooding is almost always derivative of other technical decisions, not an independent factor. Which makes it hard to distinguish correlation from causation. Fully dogfooded: C++, Rust, Go, D, Zig, [Java with Graal or Jikes], [Python with PyPy] Not dogfooded: JavaScript, Python, Ruby, Lisp, PHP, Lua, Swift Compiler is dogfooded but VM/runtime is not: Java, C#, Haskell, Kotlin Native The compiler (i.e. whatever parses source files and generates either native code or bytecode) is almost always written in the language itself, except for purely interpreted languages where that would be too slow. If there's a VM or runtime, it's written in C or C++ if the language is slow; it's written in the language itself if the language aims to be as fast as C; and for the many languages in the middle, it varies. The biggest exception I can think of is Swift, which is mostly not dogfooded, although it's becoming more so. And even that is explainable by other design decisions. Like C++ or Rust, Swift requires the compiler to do a lot of work to compile it properly. Like Java or Haskell, Swift is really slow at runtime. The combination of those would be deadly for a dogfooded compiler. Besides that, C and Objective-C are technically exceptions because the most popular compilers for them are all written in C++. But I didn't count them because C++ is in the same language family.

neonsunset 2y ago
Compiler and runtime are partially dogfooded now in .NET: - CoreLib is entirely C# (let alone anything outside it) - Low-level facilities like thread-locals, instead of C++, are now C# + compiler idioms + C# to unmanaged exports mostly - Type system facilities have more of their code moved to C# as well - Memmove/memcpy and other performance-sensitive paths, that are part of CoreLib, are either pure C# using its SIMD API or special-cased in compiler (like unrolling of copies, comparisons (including text) of constant lengths and similar last-mile optimizations) In addition, ILC (IL AOT Compiler) is fully written in C#, although uses the same back-end as JIT. JIT could have been reasonably written in C# now that there is NativeAOT but would require more work (also considering that it's a GC-based language), apparently it was considered at some point but ultimately there isn't just capacity to do so - .NET compiler team is fairly small.
kazinator 2y ago
Lisp isn't one language like Ruby or PHP; it is a family. Some members of that family are fully self hosting. E.g. to build SBCL, you need an implementation of Common Lisp. It doesn't have to be SBCL.

by comex 2y ago

neonsunset 2y ago

Compiler and runtime are partially dogfooded now in .NET: - CoreLib is entirely C# (let alone anything outside it) - Low-level facilities like thread-locals, instead of C++, are now C# + compiler idioms + C# to unmanaged exports mostly - Type system facilities have more of their code moved to C# as well - Memmove/memcpy and other performance-sensitive paths, that are part of CoreLib, are either pure C# using its SIMD API or special-cased in compiler (like unrolling of copies, comparisons (including text) of constant lengths and similar last-mile optimizations) In addition, ILC (IL AOT Compiler) is fully written in C#, although uses the same back-end as JIT. JIT could have been reasonably written in C# now that there is NativeAOT but would require more work (also considering that it's a GC-based language), apparently it was considered at some point but ultimately there isn't just capacity to do so - .NET compiler team is fairly small.

kazinator 2y ago

Lisp isn't one language like Ruby or PHP; it is a family. Some members of that family are fully self hosting. E.g. to build SBCL, you need an implementation of Common Lisp. It doesn't have to be SBCL.