Zig as an Intermediate Language for EiffelStudio
Finnian Reilly
A Case for Replacing the C Backend — Discussion Paper for Review by Eiffel Software Engineering
(20-25 minutes: 5000 words on eiffel.org)
- Preface
- Introduction
- Prior Art and Community Context
- The C Backend: A Structural Assessment
- The .NET Backend as Proof of Concept
- Why Zig Rather Than LLVM IR Directly
- The Macro Problem: A Significant Technical Challenge
- Zig's Incremental Compilation: The Central Argument
- The Zig Project: Credibility and Sustainability
- Implementation Considerations and Risks
- A Proposed Path Forward
- Conclusion
- See Also
- References and Notes
Eric Bezault
I'm not an Eiffel Software engineer, but here are a few
remarks anyway:
With the Melting Ice Technology, the generation of C code for
the frozen mode is incremental (only generates the C code
of the modified classes) thanks to the way the Eiffel calls
are implemented in C. Whereas in finalized mode the C is
regenerated from scratch, with optimizations. This means that
moving to Zig would allow to take advantage of the Zig
incremental compilation, but the compilation from Eiffel to
Zig would be slower than the combination melt/freeze because
there won't be any incremental compilation at this stage
(equivalent of Degree -2 and -3).
Your article does not mention that with `zig cc` we already
gain some C compilation speed improvement thanks to the caching
mechanism provided by the Zig toochain. Indeed, it will not
recompile a C file if it has not been modified since the last
compilation. It will just reuse the corresponding object file
stored in its cache. The Gobo Eiffel compiler takes advantage
of that, and it works well.
A lot of Eiffel libraries have external routines to call
existing C libraries. Your article does not mention how
easy it is to call C code from Zig.
EiffelStudio has its own GC implemented in C. Your article
does not mention how GC would be handled in Zig. What are
the solutions? Is there a need to implement a GC for Eiffel
objects in Zig? Is it even possible, with the way Zig handles
memory management? Can we use a Zig binding of the Boehm GC?
--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com
On 30/05/2026 17:53, Finnian Reilly wrote:
> Zig as an Intermediate Language for EiffelStudio <https://
> www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio>
>
> /A Case for Replacing the C Backend — Discussion Paper for Review by
> Eiffel Software Engineering/
>
> /(20-25 minutes: 5000 words on eiffel.org) /
>
> *CONTENTS*
> # Preface <https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-
> intermediate-language-eiffelstudio#Preface>
> # Introduction <https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-
> intermediate-language-eiffelstudio#Introduction>
> # Prior Art and Community Context <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Prior_Art_and_Community_Context>
>
> 1. John Wolter's 2024 Proposal <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#John_Wolter's_2024_Proposal>
> 2. Eric Bezault's Practical Validation <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Eric_Bezault's_Practical_Validation>
> 3. What This Paper Adds <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#What_This_Paper_Adds>
>
> # The C Backend: A Structural Assessment <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#The_C_Backend:_A_Structural_Assessment>
>
> 1. The Three-Tier Problem <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#The_Three-Tier_Problem>
> 2. Frozen and Finalised Behavioural Divergence <https://www.eiffel.org/
> blog/Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Frozen_and_Finalised_Behavioural_Divergence>
> 3. The Design by Contract Penalty <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#The_Design_by_Contract_Penalty>
>
> # The .NET Backend as Proof of Concept <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#The_.NET_Backend_as_Proof_of_Concept>
> # Why Zig Rather Than LLVM IR Directly <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Why_Zig_Rather_Than_LLVM_IR_Directly>
>
> 1. Readability and Debuggability of Generated Code <https://
> www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-intermediate-
> language-eiffelstudio#Readability_and_Debuggability_of_Generated_Code>
> 2. No Undefined Behaviour <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#No_Undefined_Behaviour>
> 3. Cross-Compilation as a First-Class Feature <https://www.eiffel.org/
> blog/Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Cross-Compilation_as_a_First-Class_Feature>
> 4. The zig cc Stepping Stone <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#The_zig_cc_Stepping_Stone>
>
> # The Macro Problem: A Significant Technical Challenge <https://
> www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#The_Macro_Problem:_A_Significant_Technical_Challenge>
>
> 1. What the Macro Layer Actually Does <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#What_the_Macro_Layer_Actually_Does>
> 2. What Zig Offers Instead <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#What_Zig_Offers_Instead>
> 3. The Real Implication: The Code Generator Must Be Smarter <https://
> www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-intermediate-
> language-
> eiffelstudio#The_Real_Implication:_The_Code_Generator_Must_Be_Smarter>
>
> # Zig's Incremental Compilation: The Central Argument <https://
> www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Zig's_Incremental_Compilation:_The_Central_Argument>
>
> 1. The 50ms Claim: From the Founder's Own Words <https://
> www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-intermediate-
> language-eiffelstudio#The_50ms_Claim:_From_the_Founder's_Own_Words>
> 2. Collapsing the Three Tiers into One <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Collapsing_the_Three_Tiers_into_One>
> 3. Design by Contract Restored <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Design_by_Contract_Restored>
>
> # The Zig Project: Credibility and Sustainability <https://www.eiffel.org/
> blog/Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#The_Zig_Project:_Credibility_and_Sustainability>
>
> 1. Financial Independence <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Financial_Independence>
> 2. Community Reception <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Community_Reception>
> 3. The No-AI Policy: A Signal About Code Quality <https://
> www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-intermediate-
> language-eiffelstudio#The_No-AI_Policy:_A_Signal_About_Code_Quality>
> 4. Moving to Codeberg <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Moving_to_Codeberg>
>
> # Implementation Considerations and Risks <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Implementation_Considerations_and_Risks>
>
> 1. Zig Is Not Yet at Version 1.0 <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Zig_Is_Not_Yet_at_Version_1.0>
> 2. The Existing C Backend Investment <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#The_Existing_C_Backend_Investment>
> 3. Community and Ecosystem Size <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#Community_and_Ecosystem_Size>
>
> # A Proposed Path Forward <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#A_Proposed_Path_Forward>
> # Conclusion <https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-
> intermediate-language-eiffelstudio#Conclusion>
> # See Also <https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-
> intermediate-language-eiffelstudio#See_Also>
> # References and Notes <https://www.eiffel.org/blog/
> Finnian%20Reilly/2026/05/zig-intermediate-language-
> eiffelstudio#References_and_Notes>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com <mailto:eiffel-
> users+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-
> users/99d1d943-6153-4bbb-90ab-0ec9af2e616fn%40googlegroups.com <https://
> groups.google.com/d/msgid/eiffel-
> users/99d1d943-6153-4bbb-90ab-0ec9af2e616fn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.
Ian Joyner
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/cc8221cf-b0da-4d00-80c3-fa502052e2ab%40gobosoft.com.
Eric Bezault
> I thought there was a project to move away from C as an intermediate code?
Do you mean for the EiffelStudio compiler?
I sometimes mentioned in private discussions my wish to
use Rust and/or Zig as intermediate code for the Gobo Eiffel
compiler, but it is just a wish so far. It's too much work
if there is no funding to support this kind of project.
I also sometimes mentioned my wish to let the Gobo Eiffel
compiler also generate Python and/or other mainstream languages
like Dafny does. But again it's just a pie in the sky.
I don't think there is any plan to do something like that in
the EiffelStudio compiler. I'd be happy to be proven wrong.
Bertrand Meyer
Dear Finnian,
Thanks for this carefully argued proposal.
(I note that you entered it as a blog article; great. Here is the link for those who might not have seen it: https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-intermediate-language-eiffelstudio.)
Disclaimer: I know little about Zig -- only what I have found in your message, in Wikipedia and a few other places.
It looks like the retargeting to Zig could technically be done, but it is likely to be a significant effort. The basic question to me is the rationale for it:
- One of your major arguments is the existence of several compilation modes in the current EiffelStudio. It does not seem so bad to me conceptually to use different schemes for development and actual operation. Cases of semantic discrepancy between melted, frozen and finalized code are rare in my experience and, when they arise, are characterized as bugs and should be fixed. Maybe others have had a different experience and find the problem serious.
- C has the advantage that it is available on essentially any platform, with compilers that are maintained.
- Another advantage is that over the years we have mastered what we can (and cannot) do with C and honed the generated code. It is scary to throw away this experience and start with a new technology which will probably have its own quirks. While I have no doubt that we could produce a basic version that “kind of” works, getting to the right level of reliability and stability is another challenge.
- As Eric Bezault has pointed out, the advertised incrementality benefit of Zig may not apply to the Eiffel-to-Zig part.
- He also asked about the GC and I haven’t seen an answer.
- A particularly hard nut to crack is the run time, and within it concurrency. The .NET retargeting has hit this obstacle.
I should also point out that for all the effort put into .NET retargeting, and all the good technical arguments for it, we have not seen much traction there. Most people seem still to prefer the good old C-based platform, even if they do not use SCOOP. I do not fully know why but the reality is undeniable.
I do not necessarily believe that C as a target language will be with us forever, and as a result I welcome this discussion, but the choice of replacement has to be made very carefully. We have to start with the basic question: what should we do to increase the attractiveness of Eiffel? It seems to me that a key technical obstacle at this point, rather than the melt/freeze/finalize split, is the difficulty of writing completely seamless applications that work throughout desktop platforms (Windows, Linux, MacOS), the browser, and mobile platforms (iOS, Android), with everything supported across all of them, including graphics and concurrency. Does Zig retargeting help here?
But let’s continue the discussion.
Thanks again,
-- BM
From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Finnian Reilly
Sent: 30 May, 2026 8:53
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] Zig as an Intermediate Language for EiffelStudio
A Case for Replacing the C Backend — Discussion Paper for Review by Eiffel Software Engineering
[Rest of quoted message removed since it is in the blog article at https://www.eiffel.org/blog/Finnian%20Reilly/2026/05/zig-intermediate-language-eiffelstudio -- BM]
.
Finnian Reilly
Finnian
Finnian Reilly
Dear Bertrand,
Thank you for your thoughtful and detailed response. Having the designer of Eiffel engage directly with the paper within 24 hours was more than I could have hoped for.
Your points have caused me to revise my position in two places. On the frozen/finalised divergence argument, I examined my own commit history across 1,891 commits and found only three genuine behavioural discrepancies — all on EiffelStudio 16.05, all in 2021, and all likely fixed in subsequent releases. You are right that the problem is rare. The paper overstated that pillar and I have withdrawn it as a primary justification.
On the .NET backend precedent, I had no good answer and have said so plainly. If a mature, well-resourced target with a large developer ecosystem failed to attract adoption, it is a sobering caution for any backend proposal.
Your reframe of the real obstacle — seamless cross-platform development across desktop, browser, and mobile — is the most important contribution your response made. The paper was addressing a real but secondary problem. That primary question deserves its own discussion and I hope this one prompts it.
I have incorporated your observations into a new Bertrand Meyer's Response section in the article, and rewritten the conclusion in light of both your input and Eric Bezault's earlier technical corrections. The revised conclusion is considerably more modest than the original — which I think makes it more honest.
What survives scrutiny is a limited but actionable recommendation: adopting zig cc as the C compiler for freeze and finalise, which Eric has already validated in Gobo Eiffel and which requires no changes to the code generator. Everything beyond that is, as you say, a question that must be approached carefully and from first principles.
Thanks again for taking the time.
Finnian
João Rocha
On 2 Jun 2026, at 10:53 AM, Finnian Reilly <frei...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/b26472c0-c83c-4ecc-b73d-8fcffe35bdfcn%40googlegroups.com.
Finnian Reilly
that was precisely the video that inspired my discussion paper
and I linked to it in the paper.
regards
Finnian