I hold a different opinion regarding the self-built compilation backend

[uint]

I. I believe we should focus on these goals:

• Enable more embedded chips to run compiled Zig binaries;

• I do not think any single team can directly adapt their own compiler to support every chip architecture.

II. Abandoning the LLVM backend is equivalent to abandoning all the chip vendor adaptations already built on LLVM.

III. We must be wary of viewpoints that lack end-to-end thinking across the full chain:

source code → compilation → machine code → hardware execution.

IV. I consistently hold the following views:

• Zig’s compile-time execution capabilities can surpass Rust entirely in terms of safety.

• Leveraging more powerful compile-time computation, provide foundational abstractions and primitives for building custom tools: allowing developers to define their own abstractions directly and implement business logic on top of them.

• The core purpose of all the above design and implementation is one thing only: to let developers maintain full control over the entire engineering code they design and write.

[vulpesx]

@uint

I. Core Positioning of Zig Language

• As a statically compiled language, its core value lies in broad compatibility with multiple chip architectures;
• Naturally suited for edge computing, embedded systems, and other scenarios requiring direct hardware connection—this is its key differentiator.

II. Core Controversy of the Current Route

• Abandoning the LLVM backend entirely in favor of a fully custom backend carries critical risks:
• Insufficient hardware compatibility, failing to adapt to various chips required for edge computing;

zig isn’t abandoning LLVM, just making not required for major architectures. It will, for the foreseeable future, support using LLVM as a backend.

Even if/when the ambition of competing with llvm as an optimising backend is achieved, they will likely still support using it.

The main, current, motivation for the custom backend is compilation speed in debug builds, but also release builds when they get that far.

@uint

Deviating from the essence of static languages (“priority to low-level adaptation”), leading to the loss of core application scenarios.

What does this even mean? Do you think LLVM is the only way to make a low level language?

@uint

• In the early stage, to save time, it may promote the selection of “superficially feasible but lacking low-level decoupling” feature implementation schemes;
• While seemingly enabling rapid function landing, the insufficient decoupling between the compilation frontend and backend埋下 major hidden dangers for future architecture iterations and hardware adaptation;
• Ignoring the core requirement of “compilation link integrity” for static languages, leading to the accumulation of technical debt and extremely high later refactoring costs.
• Core principle: The early design of static languages must be based on full-link logic, rejecting short-sighted advice that fails to penetrate the underlying execution principles.

The compiler already separates the front and backend, its what allows it to have llvm and its custom backends. As I said earlier, zig will likely always support LLVM and by extension support multiple backends.

That wouldn’t be possible without separation of the two layers.

I get the impression you just think the zig team is incompetent?

@uint

• Zig’s compile-time computation capability can be completely safer than that of Rust;
• At the same time, it provides stronger compile-time computation capability, as well as abstract tools/primitives for building abstract tools, allowing developers to directly define their own abstract tools and implement business functions based on these tools;
• The core purpose of all the above designs and implementations is only one: to enable developers to take control of the entire engineering code they design and code.

This has nothing to do with the custom backend, or backends in general at all.

Forgive me if I sound hostile, but I’m just confused to what the point of this post is.

I get the impression this is translated, whatever tool was used doesnt seem to have gotten the intent across.

[uint]

I don’t care about the tone.

Building their own compiler backend means the team has to handle compiler adaptation for various chips on their own. I don’t think this workload is manageable by a single team.

I’ve always believed that the implementation of language features should be completely independent of the compiler backend. Any language feature can be implemented without touching the compiler backend at all.

[vulpesx]

@uint

Building their own compiler backend means the team has to handle compiler adaptation for various chips on their own. I don’t think this workload is manageable by a single team.

well it’s a good thing they are getting more and more donations so they can hire more people. Not to mention all the people to contribute for free in their own time. If you think they are or will be struggling, why not help them, via a donation or contributing?

@uint

I’ve always believed that the implementation of language features should be completely independent of the compiler backend. Any language feature can be implemented without touching the compiler backend at all.

Okay… but zig is not implementing a custom backend for any language features.

By that logic I think you should support this, since one of the reasons is that LLVM is hard to work with since it primarily designed for c/cpp.

[lalinsky]

Zig is not abandoning LLVM. The core team just wants to make it possible to have debug builds on major platforms not depend on LLVM. That significantly simplifies development, and allows for more tricks like incremental compilation.

[uint]

I worry that this approach will eventually lead to fragmentation: diving headlong into building a custom, self-contained backend with no dependencies on LLVM whatsoever, which would completely isolate the entire ecosystem.

[lalinsky]

I don’t think that’s going to happen. I honestly don’t think anyone wants to do an optimizing backend at LLVM scale. People want better development experience. Even as a user, I benefit from the faster debug builds, but I wouldn’t be using Zig if it didn’t have LLVM backend for release builds.

[vulpesx]

Divide what ecosystem?? There is no ecosystem of zig compilers.

If you’re talking about backends in general, it is already divided, there are LLVM and GCC as the big ones, and plenty of smaller backends e.g. QBE or tilde etc.

[pierrelgol]

I think your fear is unfounded, you said that we should have an end to end thinking, then try to have an end to end thinking too, why would a team remove itself from LLVM ? What benefits would it bring ? None. They will never abandon the LLVM backend, because there is no reason to do so. What they are trying to do, is create a platform where if needed you can contribute and implement your backend for your target, where all the language doesn’t depend on LLVM being here. If anything that’s super smart, because the time it would take for you to understand LLVM, implement a backend for your target, and on top of that upstream it, is probably a multi year project.

And from a developer perspective what do you prefer ? Obscure mailing list, compile time for each compiler that can take upward of 2h per compilation cycle each time you do something ?

Or would it be nicer to have a compiler capable of compiling everything in less than 10s ?

From a developer perspective, do you think it make sense to have to read some of the most horrid C/C++ code out there into a mess of millions of loc littered with #ifdef #define #elif directives ? Or is it better to have a simpler codebase where you can pretty much just plug your backend into an enum somewhere and start working on it ?

When people ask why I do so much Zig instead of more popular languages like Rust, is because I really believe that an ambitious project like Zig is needed, even Chris Lattner who created LLVM realized that it was not optimal and decided to create MLIR instead of extending LLVM IR for his usecase.

So yeah, Zig should absolutely make their own backend, their own linker, their own build system, their own optimization etc. I think that when the language stabilize and gets more known, that a lot of people, are going to be able to ship a debug backend for Zig faster than their colleagues for C.