Un diseñador de un nuevo lenguaje de programación plantea una pregunta abierta sobre arquitectura de compiladores: ¿por qué los lenguajes modernos optan por compiladores paralelos en lugar de generar procesos independientes por cada archivo, como hace C? La motivación es pragmática: persigue tiempos de compilación rápidos como objetivo explícito de diseño, y observa que Zig y Rust comparten ideas similares pero presentan velocidades de compilación muy distintas, mientras que C es conocido por su rapidez y los templates de C++ resultan lentos.
El núcleo técnico de la cuestión gira en torno a dos estrategias de paralelismo. La primera, multiproceso, consiste en lanzar un compilador por archivo fuente; es viable cuando cada archivo se compila de forma totalmente independiente, propiedad que cumple C y que permite que make o ninja escalen casi linealmente con los núcleos. La segunda, en proceso (in-process), ejecuta toda la compilación dentro de un único proceso que reparte el trabajo entre hilos; es la elección de lenguajes como Rust y Zig, donde la información fluye entre unidades de compilación (tipos, macros, módulos) y un archivo no puede cerrarse sin conocer lo que declaran los demás.
El autor señala que la segunda estrategia parece obligada por la presencia de imports circulares o, en términos más generales, por dependencias cruzadas entre módulos, algo habitual en lenguajes con módulos, genéricos o sistemas de macros avanzados. Aun así, admite no haber encontrado recursos canónicos que nombren o comparen ambos enfoques, y pregunta a la comunidad por referencias y lecturas recomendadas sobre el diseño de compiladores paralelos.