Gooey: A GPU-accelerated UI framework for Zig

A year ago it would have taken someone months of nights and weekends effort to get this much code up and running. That person would have developed a good intuition for the architecture and where it should go.

Now Codex or Claude can bang it out in a couple days. You can try to have it do spec documents, code reviews, and cleanup passes but with today's tools these projects reach a point where it's just a swirling mess of pieces duct taped together in a way that passes tests. In my experiments, you quickly reach a point where the usable context depth (which is less than the 1M limits) keeps overflowing before you can get usable refactors in, and you're just going in circles. I know it's theoretically possible to avoid these problems, but in practice you get spaghetti projects like this.

There should be some way to measure (and display) how much of a project is understood by the humans behind it.

> Gooey is in better shape than most ~140 KLOC Zig codebases — every directory has a mod.zig, namespaces are layered, and core/interface_verify.zig provides compile-time platform-backend checks. But the architecture has drifted in a few

I too have used AI to plan cleaning up its own mess, and this self-congratulatory prose is extremely consistent ("every directory has a mod.zig", whoop dee woo!).

In my experience, AI is largely incapable of fixing its own mess to an actually competent degree (and full disclosure: I still ask it to, not pointing fingers here) and it's probably due to it walking on egg shells around its own feelings. I've had to tell it to completely change course during cleanup at least 30 times this week.

Also: https://xcancel.com/mitchellh/status/2060088112257372610

Have seen it from jobseekers trying to boost their profile with fake projects, founders trying to make their product more attractive to VCs, consultants trying to advertise their services...

I don't always have time for OSS, but every PR I've ever sent has always been hand written, and tested, and has taken into consideration the project coding style and architecture choices – I don't like this new world where developers can't even be bothered to write the docs.

You can optimize a library to make it comparatively simple to draw a circle on a screen. But that tells me nothing about binding state, signals, styling, widget hierarchy, etc. Maybe these frameworks look complicated to you because doing something more than drawing a circle is actually more complicated.

However, you need to remember that these simpler tools were a product of a much simpler set of requirements. Fixed themes, fixed screen size, fixed aspect ratios. I imagine a wysiwyg editor that gives you all the power of, say, CSS, and yet remains simple for simple things, sounds like a much more difficult task. I haven’t worked on UI in 20 years, so maybe such tools do exist.

https://www.reddit.com/r/rust/comments/1tql7uf/microsofts_wi...

    #include <QApplication>
    #include <QWidget>
    #include <QPainter>

    class widget : public QWidget {
    void paintEvent(QPaintEvent*) override {
        QPainter(this).drawEllipse(QPoint(320, 240), 100, 100);
    }
    };

    int main(int argc, char *argv[]) {
        QApplication app(argc, argv);
        widget w;
        w.resize(640, 480);
        w.show();
        return app.exec();
    }

Compared to the effort:quality of something like tkinter, LibertyBASIC put it to shame! Not to throw shade, tkinter is perfectly fine but I don't think I would have cared for it at that age.

It also taught me how to pirate software, when I found out the borland compiler required to make .exe's I could give my friends was $200 :)

I agree. GUI these days are largely driven by how HTML works and we now have a whole generation of UI Devs (frontend devs) who've never known any other way.

I missed the good old ways of GUI.

Like, all of that should be expressable with just

  <graph>
    <circle />
  </graph>

[1]: https://github.com/creativescala/gooey

And in early 2000, I was in a mailing list for designing a successor/replacement to X11, code-named "Gooey" that never went anywhere.

It's a real problem, so many projects are adding features at breakneck speed, but with so many bugs and so little understanding.

Maybe that's just how it all works now, but I don't like it.

GPUI is for rust, not zig

That said, it fills a legit hole in the ecosystem and the author seems to be hands-on with the technical direction.

What's so special about Zig dev that puts them aside from the giants they stand on?