Delphi vs FPC?

[Cooler2]

The future of Apus Game Engine — Delphi vs FPC/Lazarus

Historically the engine has been compiler-agnostic: the same code compiles under both Delphi and FPC. Delphi was the main compiler for a long time — all development happened in Delphi, while FPC was the fallback for independence and cross-platform reach. But the situation is changing, and changing decisively.

First, CI and automated tests are practically only possible with FPC — you need a freely scriptable command-line compiler; Delphi only ships one in its paid editions, and it isn't available on GitHub. Second — and this is the main point — the shift to AI-assisted development. The problem isn't just that the Delphi IDE doesn't always pick up external edits and may overwrite them (that's only half the trouble). The key blocker is different: an AI agent needs to invoke the compiler itself and read the result — build, see the errors, fix, repeat. Delphi's IDE-centric model doesn't provide that loop; FPC's open command-line compiler gives it out of the box.

Plus the perennial dependency question: Delphi's fate is entirely in Embarcadero's hands (policy, pricing, licensing), and there's nothing you can do about it. FPC is open and isn't going anywhere — the worst case is a fork, not a dead end.

So I want to discuss where to go from here. There are 4 options, from "how it was" to "as radical as it gets". The further down the list, the more language power and the narrower the compatibility.

1. Delphi primary (where we came from — and won't go back to)

Pros: convenient IDE and debugger, a mature optimizer, a large Win audience.

Cons: an AI agent can't run the "compile → check the result" loop on its own — the main blocker of today's development; dependence on a single proprietary vendor you have no influence over; expensive licenses; no CI on GitHub → essentially no longer a live option, kept on the list as history.

2. FPC primary (the de-facto current mode)

Rationale: we develop on the open toolchain, keep Delphi as a periodic compatibility audit, and write code as before — in the subset common to both compilers.

Pros: the AI agent builds and checks the code itself; we actively use tests and CI; the second compiler is kept as a comparison tool — Delphi/FPC discrepancies catch real bugs, UB and performance differences; the decision is reversible — no door has been burned, the engine can still be used with Delphi.

Cons: the discipline of writing in the Delphi-compatible subset (giving up FPC-only sugar); periodically before releases you have to fix Delphi compatibility; most of the time upstream doesn't build under Delphi.

3. FPC-specific (write to the FPC dialect, Delphi compatibility lost)

Rationale: freely use FPC's whole arsenal, stop paying the "compatibility tax" (small as it is).

Pros: cleaner, more modern code; no compat shims; a single compiler to reason about; still 100% open-source, cross-platform, with free CI.

Cons: irreversibly burns the two-compiler comparison asset (the correctness/performance diff is gone for good); the Delphi door is closed, and reopening it is already a migration; the gain must justify the loss, and most FPC-only sugar is convenience, not new capability.

4. FPC+ (an advanced maintained fork, e.g. Unleashed; compatibility with "classic" FPC lost)

Rationale: get the most powerful language possible while keeping the core codebase (sugar + a path to custom syntax).

Pros: the most expressive option; potentially maximum performance; with a live fork — ergonomics beyond mainline FPC.

Cons: requires dragging a special compiler along with the engine, which raises the barrier to entry and potentially breaks the familiar ecosystem; compatibility with classic FPC is lost too → the pool of potential contributors narrows sharply (not that there ever were any), and the code's value for reuse in other projects drops noticeably.

---

Question for you: which path is preferable — (2), (3) or (4)? And if you're for (3) or (4), which specific capability, in your view, justifies the loss of compatibility? Share your arguments in the comments.