3 ms·

Something that I learned from listening to Jonathan Blow about his new language Jai is that the implicit assumptions on which traditional C/C++ toolchains are b

Something that I learned from listening to Jonathan Blow about his new language Jai is that the implicit assumptions on which traditional C/C++ toolchains are built are horrendously out-of-date. The whole concept of "discovering" which compiler you have, what your linker is, and then using a DSL to generate a script that triggers shell commands is more than a little bonkers if you stand back and look at it objectively. It's common to see SDKs or APIs with 2-10 functions in them that weigh in at over 100 KB due to the overheads of having to deal with toolchains, platforms, and other sideshows that have no real contribution to the business at hand. Jonathan has demonstrated recompiling, linking, and reloading an entire game engine live, which then lets you escape the tarpit of having to add non-compiled DSLs to everything as a workaround for slow compile times. If your compile times are measured in hundreds of milliseconds, scripting isn't needed any more! No more bytecodes, or JIT, or any of that. Just churn the code through a single process that outputs an executable directly and you can sidestep the need for entire industries. This is why tools like CMake or Meson feel to me like they're solving the wrong problem. It's like selling a better horse when automobiles have been demonstrated by Henry Ford.

schaefer 4y ago
Okay, but I’m not in the Jai beta, and I have to use the tools available to me…
- zbentley 4y ago
  Nim, D, Go, Rust, and several other languages in this space all offer a similarly integrated toolchain without the drawbacks of legacy build systems. And those are all free and available, unlike Jai.
  - georgyo 4y ago
    This is mostly true, but it is also because there is only one implementation of an these languages. Go for example has a gcc compiler as well. And that compiler has very different options than the one written in go.
    - zbentley 4y ago
      That's not really true, I'm afraid. Go/Rust have alternative compilers as you point out; what does "very different options" have to do with anything? The GGP's statement about "discovering" capabilities is, at least to my interpretation, about the behavior of language features under a given compiler (i.e. autoconf rules for things like "are we using this one buggy version of gcc that can't reliably use vectorized instructions for some common task? If so, drop in an alternative implementation of some common library function"), not the options/flags of the compiler itself. D has multiple supported compilers (https://dlang.org/download.html https://dlang.org/download.html). The simplest one is simpler/more pleasant to use because of the lack of legacy baggage. Nim is a bit of an odd one, in that there's one implementation of the language, but the most common compiler mode emits C code to be compiled on the toolchain of your choice, though the behavioral configuration of the toolchain is handled/defaulted well (at least, well enough I've never had to worry about a multi-stage build system) by the "nim" CLI utility.
duped 4y ago
We've had fast dynamic recompilation since the 1970s. The problem that build systems solve is integrating multiple tools and software systems from across languages, runtimes, even operating systems and baking it down into a small set of commands for a programmer to invoke.
- jiggawatts 4y ago
  Jai doesn't use incremental compilation. It compiles the entire program fast enough that there is no need to bother with caching! Languages that don't carry with them baggage from the 1960s can be compiled at millions of lines per second. The issue lies in everything else surrounding the compilation process. On top of that, C and C++ are horrifically inefficient because of the way macros and headers work, resulting in a type of "write amplification" where every kilobyte of code written by a human might take a hundred kilobytes or more of code that has to go through a compiler.
germandiago 4y ago
So you assume that in a game company all have the same skills to the more or less C++ level? What about designers that can program a dynamic lang like Lua or so? No... the problem is not the compile times only or the reloading... it is the user profiles of who are doing scripting, who usually do not have a CS or solid programming background as such.
dig1 4y ago
> The whole concept of "discovering" which compiler you have, what your linker is, and then using a DSL to generate a script that triggers shell commands is more than a little bonkers if you stand back and look at it objectively. This concept is still the only way to go if you port your application on a different platform and OSes. In the past, we had way more unix variations with varying compile vendors and funky CPU architectures. Even today, good luck with making your app compile seemingly across BSDs, various Linux distros (modern and old ones), and Windows. I'll assume JBlow is doing all his development on and for Windows, so IMHO, using anything over simple "make" will be overkill - you already know the platform, you cook the binaries and you already know where your application will be run. What saddens me is the "modern" attitude in development: "if you don't have meson X or cmake Y, fu* off, you don't have to compile my program" vs. was done in the past: "I'll be happy you compile my program on your platform and configure script will make sure to adapt it. But drop me config.log if something happens. You don't need anything except a shell."

schaefer 4y ago

Okay, but I’m not in the Jai beta, and I have to use the tools available to me…

zbentley 4y ago
Nim, D, Go, Rust, and several other languages in this space all offer a similarly integrated toolchain without the drawbacks of legacy build systems. And those are all free and available, unlike Jai.
- georgyo 4y ago
  This is mostly true, but it is also because there is only one implementation of an these languages. Go for example has a gcc compiler as well. And that compiler has very different options than the one written in go.
  - zbentley 4y ago
    That's not really true, I'm afraid. Go/Rust have alternative compilers as you point out; what does "very different options" have to do with anything? The GGP's statement about "discovering" capabilities is, at least to my interpretation, about the behavior of language features under a given compiler (i.e. autoconf rules for things like "are we using this one buggy version of gcc that can't reliably use vectorized instructions for some common task? If so, drop in an alternative implementation of some common library function"), not the options/flags of the compiler itself. D has multiple supported compilers (https://dlang.org/download.html https://dlang.org/download.html). The simplest one is simpler/more pleasant to use because of the lack of legacy baggage. Nim is a bit of an odd one, in that there's one implementation of the language, but the most common compiler mode emits C code to be compiled on the toolchain of your choice, though the behavioral configuration of the toolchain is handled/defaulted well (at least, well enough I've never had to worry about a multi-stage build system) by the "nim" CLI utility.

duped 4y ago

We've had fast dynamic recompilation since the 1970s. The problem that build systems solve is integrating multiple tools and software systems from across languages, runtimes, even operating systems and baking it down into a small set of commands for a programmer to invoke.

jiggawatts 4y ago
Jai doesn't use incremental compilation. It compiles the entire program fast enough that there is no need to bother with caching! Languages that don't carry with them baggage from the 1960s can be compiled at millions of lines per second. The issue lies in everything else surrounding the compilation process. On top of that, C and C++ are horrifically inefficient because of the way macros and headers work, resulting in a type of "write amplification" where every kilobyte of code written by a human might take a hundred kilobytes or more of code that has to go through a compiler.

germandiago 4y ago

So you assume that in a game company all have the same skills to the more or less C++ level? What about designers that can program a dynamic lang like Lua or so? No... the problem is not the compile times only or the reloading... it is the user profiles of who are doing scripting, who usually do not have a CS or solid programming background as such.

dig1 4y ago

> The whole concept of "discovering" which compiler you have, what your linker is, and then using a DSL to generate a script that triggers shell commands is more than a little bonkers if you stand back and look at it objectively. This concept is still the only way to go if you port your application on a different platform and OSes. In the past, we had way more unix variations with varying compile vendors and funky CPU architectures. Even today, good luck with making your app compile seemingly across BSDs, various Linux distros (modern and old ones), and Windows. I'll assume JBlow is doing all his development on and for Windows, so IMHO, using anything over simple "make" will be overkill - you already know the platform, you cook the binaries and you already know where your application will be run. What saddens me is the "modern" attitude in development: "if you don't have meson X or cmake Y, fu* off, you don't have to compile my program" vs. was done in the past: "I'll be happy you compile my program on your platform and configure script will make sure to adapt it. But drop me config.log if something happens. You don't need anything except a shell."