5 ms·

While nothing you said is technically wrong, my experience has been that languages that force themselves to dogfood are generally much more pleasant to use than

by TylerE 2y ago

While nothing you said is technically wrong, my experience has been that languages that force themselves to dogfood are generally much more pleasant to use than those that are not, both as languages and as tooling. I strongly feel this is not a coincidence. Today's "ease of bootstrapping" is 3 years from now "incoherent library hell".

regularfry 2y ago
It is fiendishly hard to disentangle cause from effect here. The sort of person to implement a dogfooded language is likely also the sort of person to care deeply about the quality of that language. It may be that just being in a position to use the language a lot (because you're implementing it) and to change that language (because you're the one building it) is enough to get the effect you've observed, but I wouldn't be at all surprised if you would only start down that path in the first place if you already had strong opinions about what a good language looks like.
nickpsecurity 2y ago
Another counterpoint is the mismatch between the intended use of languages. Languages are designed for many types of goals. The language you’re building should be tested against the goals it’s designed to achieve. Whereas, some languages are really good at making compilers. Then, some tools are specifically designed for program transformation and analysis. Using those languages can dramatically improve your compiler which might indirectly increase the number of goals the other language hits.
wavemode 2y ago
I'm curious about specific examples you are referring to, going in either direction. Off the top of my head, Java is not implemented in itself yet has perfectly fine tooling. Whereas Haskell is implemented in itself and its tooling leaves much to be desired (despite my love for the language overall).
- 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.
  - 2y ago

by TylerE 2y ago

regularfry 2y ago

It is fiendishly hard to disentangle cause from effect here. The sort of person to implement a dogfooded language is likely also the sort of person to care deeply about the quality of that language. It may be that just being in a position to use the language a lot (because you're implementing it) and to change that language (because you're the one building it) is enough to get the effect you've observed, but I wouldn't be at all surprised if you would only start down that path in the first place if you already had strong opinions about what a good language looks like.

nickpsecurity 2y ago

Another counterpoint is the mismatch between the intended use of languages. Languages are designed for many types of goals. The language you’re building should be tested against the goals it’s designed to achieve. Whereas, some languages are really good at making compilers. Then, some tools are specifically designed for program transformation and analysis. Using those languages can dramatically improve your compiler which might indirectly increase the number of goals the other language hits.

wavemode 2y ago

I'm curious about specific examples you are referring to, going in either direction. Off the top of my head, Java is not implemented in itself yet has perfectly fine tooling. Whereas Haskell is implemented in itself and its tooling leaves much to be desired (despite my love for the language overall).

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.
- 2y ago