Windows support is huge. One of the barriers to me considering QBE for a project in recent memory was that it had no story for proprietary OSes (Windows, MacOS), and whether I like it or not, those make up the overwhelming majority of desktop-like market share. (this is the same reason I find Hare, a language that builds with QBE, interesting but not practical for my own uses - targeting only Linux and the BSDs is a non-starter, even if I personally am a Linux-only guy)
One of the benefits of this new QBE feature of supporting windows could be that this allows a language like Hare to be used for windows too, all the more power to Hare and other programming languages built on top of QBE!
In theory, sure, but there's no way Hare is going to ever officially support Windows. Even if the compiled backend supports the target, the language still needs to abstract over the OS interfaces and implement syscalls.
I really want to like QBE, but declaration blocks like this make it feel like 1970s Unix code more than a modern hackable piece of software:
int t, x, r, rf, rt, nr;
bits rs;
Ins *i, *i1;
Mem *m;
Ref *ra[4];
I think it deters some users by making it hard to read and understand the relatively subtle code in the 300 line function that follows. (Skill issue, I know)
It is hard for me to fully trust a compiler backend that isn't self hosted. There is a discipline that self hosting imposes that would both improve the quality of their ir as well as the backend itself. A self hosted backend can always be updated to have performance meeting or exceeding the best that llvm or any other backend can offer.
(* Normally a thread that recent with significant comments would count as a dupe (https://news.ycombinator.com/newsfaq.html), but it didn't get that much frontpage time so I've made an exception.)
One of the benefits of this new QBE feature of supporting windows could be that this allows a language like Hare to be used for windows too, all the more power to Hare and other programming languages built on top of QBE!
QBE – Compiler Back End - https://news.ycombinator.com/item?id=48059633 - May 2026 (28 comments*)
Blaise – A modern self-hosting zero-legacy Object Pascal compiler targeting QBE - https://news.ycombinator.com/item?id=48058644 - May 2026 (55 comments)
Qbecc – QBE based C compiler - https://news.ycombinator.com/item?id=45461195 - Oct 2025 (3 comments)
Let's write a peephole optimizer for QBE's ARM64 back end - https://news.ycombinator.com/item?id=45099348 - Sept 2025 (1 comment)
QBE – Compiler Back End - https://news.ycombinator.com/item?id=40346320 - May 2024 (37 comments)
cproc – Small C11 compiler based on QBE - https://news.ycombinator.com/item?id=32466098 - Aug 2022 (1 comment)
QBE 1.0 - https://news.ycombinator.com/item?id=31846433 - June 2022 (3 comments)
I wrote a peephole optimizer for QBE - https://news.ycombinator.com/item?id=30864448 - March 2022 (5 comments)
Cproc C Compiler - https://news.ycombinator.com/item?id=28242024 - Aug 2021 (45 comments)
Cproc – a C11 compiler using QBE as a back end - https://news.ycombinator.com/item?id=25273918 - Dec 2020 (1 comment)
QBE vs. LLVM - https://news.ycombinator.com/item?id=25273907 - Dec 2020 (99 comments)
Show HN: QBE – a new compiler back end - https://news.ycombinator.com/item?id=11555527 - April 2016 (68 comments)
(* Normally a thread that recent with significant comments would count as a dupe (https://news.ycombinator.com/newsfaq.html), but it didn't get that much frontpage time so I've made an exception.)