Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gooey: A GPU-accelerated UI framework for Zig

github.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Gooey: A GPU-accelerated UI framework for Zig

#81

Post by hiccuphippo »

henry_bone wrote: post #42

It's not particularly revelatory to point out that this project has been generated largely by LLM (claude most likely, given the CLAUDE.md in the repo). Also looks like a bit of introspection has happened ... https://github.com/duanebester/gooey/blob/main/docs/architec... I wonder if this is just what we get now: low quality code, expressed rapidly. We are excited by the promise only to be disappointed by the reality…

Funny you mention ghostty since they use a lot of AI, but they review and make sure they understand every line.

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

Re: Gooey: A GPU-accelerated UI framework for Zig

#82

Post by willtemperley »

elcritch wrote: post #64
Aurornis wrote: post #49

Earlier quoted context omitted.

We're in the messy transition period where our old indicators of a promising GitHub project are too easily replicated by someone letting Claude Code run for a few days. 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 c…

I don’t know, GPT-5.5 has been very effective for me. It’s not perfect but the quality of refactoring it can do is awesome. Previous models both GPT and Claude would struggle with the larger picture more. Pretty quickly they’d do one off hacks. Eventually they’d code themselves into a wall if you weren’t careful. Haven’t hit that wall with GPT-5.5 yet. New changes or improvements on a GUI library I’m building seem to…

> Haven’t hit that wall with GPT-5.5

I’m seeing a similar improvement with Opus 4.8, which is acting like an engineer that cares about correctness. The harder the problem the better it seems to do.

I think a golden age of software is just starting for indie software. It’s just going to take a while to see the first really good results.

Re: Gooey: A GPU-accelerated UI framework for Zig

#83

Post by Simran-B »

Gerharddc wrote: post #72
1matin wrote: post #66

Earlier quoted context omitted.

Zig still lacks a proper GUI framework that you can actually rely on.

Fair enough. I was referring to the GUI framework space in general, not specifically for Zig

In what general direction would the innovation be?

I'm not sure if it's actually needed - a lot of things have been tried and the paradigms that persisted you can choose between but it seems to be a matter of taste. I often feel that the real issue is the lack of maturity and stability. I rather want a complete UI toolkit including learning resources (not reference docs!), no matter how boring, instead of super clever implementation that is never in a usable state.

Re: Gooey: A GPU-accelerated UI framework for Zig

#84

Post by danielvaughn »

Pxtl wrote: post #58
danielvaughn wrote: post #48

Earlier quoted context omitted.

To be fair, "excited by the promise only to be disappointed by the reality of the implementation" describes ~95% of my experiences with all software over the last 20 years. In fact only a few exceptions really come to mind - git, treesitter, ffmpeg, and sqlite.

Hah, that describes my relationship with git itself, actually.

lol I'm more speaking to reliability than the quality of the interface. git and ffmpeg are not exactly known for the most intuitive API surface, but I don't think I've ever encountered a bug with them in my 17 years. That's a pretty extraordinary thing when you think about it.

Re: Gooey: A GPU-accelerated UI framework for Zig

#85

Post by mgerb »

1matin wrote: post #66
Gerharddc wrote: post #61

At first I was very excited about this project. After reading the comments, I'm now deeply saddened by it... Given how much competition there already is in the GUI framework space, it's very difficult to see why something hastily thrown together by AI would get much traction. To really make an impact in this space, I think we'll need to see something thoughtfully designed that really tries to innovate in some profoun…

Zig still lacks a proper GUI framework that you can actually rely on.

ImGui is reliable and Zig makes it trivial to use.

Re: Gooey: A GPU-accelerated UI framework for Zig

#86

Post by Pxtl »

danielvaughn wrote: post #84
Pxtl wrote: post #58

Earlier quoted context omitted.

Hah, that describes my relationship with git itself, actually.

lol I'm more speaking to reliability than the quality of the interface. git and ffmpeg are not exactly known for the most intuitive API surface, but I don't think I've ever encountered a bug with them in my 17 years. That's a pretty extraordinary thing when you think about it.

Fair point. My problem with git is actually mostly the flaw in the object model itself, more than the dismal API. The fundamental mismatch between "to get a clean history you have to edit/destroy history with squashes and rebases and whatnot" and "editing history destroys the ability to do comparisons of two branches, which basically ruins half of git's functionality from top to bottom when you encounter that problem".

Like even the basic question of "hey did I already merge this branch?" becoming unknowable if you autosquash-on-merge is just nasty.

I've got a million ideas on what the "correct" fix for that problem might be, but imho it's a flaw deep in the heart of git that creates a massive amount of pain.

But I'll give it credit for being rock solid and blazing fast, as you say.

Re: Gooey: A GPU-accelerated UI framework for Zig

#87

Post by elcritch »

reactordev wrote: post #78
SkiFire13 wrote: post #74

Earlier quoted context omitted.

This is what people say after every new model is released though.

You have to drink the koolaid if you want to keep tokenmaxxing

Who cares about tokens?

I'm wanting to build pieces of software that I've been wanting and often working on for years. These new models are making it possible for me to scale my work to build it.

Re: Gooey: A GPU-accelerated UI framework for Zig

#88

Post by zamalek »

henry_bone wrote: post #42

It's not particularly revelatory to point out that this project has been generated largely by LLM (claude most likely, given the CLAUDE.md in the repo). Also looks like a bit of introspection has happened ... https://github.com/duanebester/gooey/blob/main/docs/architec... I wonder if this is just what we get now: low quality code, expressed rapidly. We are excited by the promise only to be disappointed by the reality…

That plan smells AI generated:

> 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

Re: Gooey: A GPU-accelerated UI framework for Zig

#89

Post by henry_bone »

hiccuphippo wrote: post #81
henry_bone wrote: post #42

It's not particularly revelatory to point out that this project has been generated largely by LLM (claude most likely, given the CLAUDE.md in the repo). Also looks like a bit of introspection has happened ... https://github.com/duanebester/gooey/blob/main/docs/architec... I wonder if this is just what we get now: low quality code, expressed rapidly. We are excited by the promise only to be disappointed by the reality…

Funny you mention ghostty since they use a lot of AI, but they review and make sure they understand every line. There should be some way to measure (and display) how much of a project is understood by the humans behind it.

Yeah, I'm aware. MitchellH posts about it quite a bit, most recently about AI "psychosis". Also, much of ghostty was created without the use of AI, I think. More recently, they've been using it to find bugs, improve performance, and generally refine and enhance ghostty and libghostty.

The LLM is the finishing tool, not the architect or core developer.

Post reply on HN