We rewrote the Ghostty GTK application • Hacker News Board

Re: We rewrote the Ghostty GTK application

#11

Post by mitchellh » Thu, Aug 14, 2025, 10:18 PM UTC

Lerc wrote: post #6

> Whatever your feelings are about OOP and memory management, the reality is that if you choose GTK, you're forced into interfacing in some way with the GObject type system. You can't avoid it. In the past this has also been my assessment of GTK. It lead me to decide to take the other path, to never directly use GTK. I appreciate the value in having a unified user interface between applications, but I have always tho…

> That lead me to think that GTK and the GObject system is opinionated in a way that are not terribly compatible with my own opinions.

This might be amusing for me to say but... I also feel this way. I disagree a lot with the Gnome ecosystem's point of view. Funny!

Using GTK for Linux was a pragmatic choice. A goal of Ghostty is to be "platform-native" (defined here because there's no such thing on Linux: https://ghostty.org/docs/about#native). GTK is by various definitions the most popular, widespread GUI toolkit on Linux that makes your app fit into _most_ ecosystems. So, GTK it is.

I hope `libghostty` will give rise to other apprts (maintained by 3rd parties, it's hard enough for me to maintain macOS and GTK) so that you aren't forced into it. See https://ghostty.org/docs/about#libghostty For example Wraith is a Wayland-native Ghostty frontend (no GTK): https://github.com/gabydd/wraith Awesome.

Re: We rewrote the Ghostty GTK application

#12

Post by schmichael » Thu, Aug 14, 2025, 10:24 PM UTC

I'm curious if Rust would have prevented the memory correctness errors assuming it replaced Zig in this scenario. It sounds like the vast majority were due to Zig/C interactions which makes me believe Rust would have had the same issues, but as a Go developer I am only guessing. I'm curious if there is a language that provides more tools to ensure correctness even when you're interacting with a huge amount of C.

Re: We rewrote the Ghostty GTK application

#13

Post by WD-42 » Thu, Aug 14, 2025, 10:25 PM UTC

Very nice writeup! I was actually just wondering what was going on with Ghostty, I've been daily driving it since initial release but I haven't noticed any updates since then (not that anything is particularly lacking, it's a great terminal!)

Good to hear the Mitchell and the team are still hacking away at it! Thanks for the great software!

Re: We rewrote the Ghostty GTK application

#14

Post by WD-42 » Thu, Aug 14, 2025, 10:27 PM UTC

schmichael wrote: post #12

I'm curious if Rust would have prevented the memory correctness errors assuming it replaced Zig in this scenario. It sounds like the vast majority were due to Zig/C interactions which makes me believe Rust would have had the same issues, but as a Go developer I am only guessing. I'm curious if there is a language that provides more tools to ensure correctness even when you're interacting with a huge amount of C.

I think one of the main points of the article was about how shockingly few memory issues they have encountered. He talks about how great of a fit zig + valgrind is.

Re: We rewrote the Ghostty GTK application

#15

Post by rvrb » Thu, Aug 14, 2025, 10:28 PM UTC

I haven't worked with GTK, but what you are describing here sounds reminiscent of what we have been dealing with trying to build Godot bindings in Zig with a nice API. the project is in mid-flight, but Godot:

  - has tons of OOP concepts: classes, virtual methods, properties, signals, etc
  - a C API to work with all of those concepts, define your own objects, properties, and so on
  - manages the lifetimes of any engine objects (you can attach userdata to any of them)
  - a whole tree of reference counted objects

it's a huge headache trying to figure out how to tie it into Zig idioms in a way that is an optimal API (specifically, dealing with lifetimes). we've come pretty far, but I am wondering if you have any additional insights or code snippets I should look at.

working on this problem produced this library, which I am not proud of: https://github.com/gdzig/oopz

here's a snippet that kind of demonstrates the state of the API at the moment: https://github.com/gdzig/gdzig/blob/master/example/src/Signa...

also.. now I want to attempt to write a Ghostty frontend as a Godot extension

Re: We rewrote the Ghostty GTK application

#16

Post by mitchellh » Thu, Aug 14, 2025, 10:28 PM UTC

schmichael wrote: post #12

I'm curious if Rust would have prevented the memory correctness errors assuming it replaced Zig in this scenario. It sounds like the vast majority were due to Zig/C interactions which makes me believe Rust would have had the same issues, but as a Go developer I am only guessing. I'm curious if there is a language that provides more tools to ensure correctness even when you're interacting with a huge amount of C.

Hi @schmichael ;) Rust would've prevented one. The rest Rust wouldn't have prevented since as you already noticed, it was in the boundary layer and semantics of a C API. It would've only been as safe as the Rust wrapper. One argument is that the richer, more proven ecosystem of wrapper libraries may have prevented it versus my DIY wrappers.

The one Rust would've prevented was a simple undefined memory access: https://github.com/ghostty-org/ghostty/pull/7982 (At least, I'm pretty sure Rust would've caught this). In practice, it meant that we were copying garbage memory on the first rendered frame, but that memory wasn't used or sent anywhere so in practice it was mostly safe. Still, its not correct!

Re: We rewrote the Ghostty GTK application

#17

Post by schmichael » Thu, Aug 14, 2025, 10:31 PM UTC

WD-42 wrote: post #14

schmichael wrote: post #12

I'm curious if Rust would have prevented the memory correctness errors assuming it replaced Zig in this scenario. It sounds like the vast majority were due to Zig/C interactions which makes me believe Rust would have had the same issues, but as a Go developer I am only guessing. I'm curious if there is a language that provides more tools to ensure correctness even when you're interacting with a huge amount of C.

I think one of the main points of the article was about how shockingly few memory issues they have encountered. He talks about how great of a fit zig + valgrind is.

Indeed, but I'm curious about the second class of memory correctness issue he mentions:

> 2. All other memory issues revolved around C API boundaries.

Is this something Rust, or any other language, has the ability to prevent any more than any other language? Or once you introduce a C API boundary is it back to tools like Valgrind?

Re: We rewrote the Ghostty GTK application

#18

Post by alberth » Thu, Aug 14, 2025, 10:31 PM UTC

corsica wrote: post #2

I don't get the hype around this application. The only UI Ghostty has is tabs and the context menu, is it really worth the integration pain and now this rewrite? Maybe they're planning for more, like those GUI configuration dialogs that iterm2 has? Kitty uses OpenGL for everything and draws its own tabs, they're fully customizable and can be made to look however you want. By not wasting time on integrating with massi…

In addition to what others have said (positively), ‘libghostty’ is also a game changer.

It’s like the “WebKit” for terminal, as I understand it.

Anyone could drop-in libghostty, and immediately have a fully functional terminal.

Re: We rewrote the Ghostty GTK application

#19

Post by schmichael » Thu, Aug 14, 2025, 10:32 PM UTC

mitchellh wrote: post #16

schmichael wrote: post #12

I'm curious if Rust would have prevented the memory correctness errors assuming it replaced Zig in this scenario. It sounds like the vast majority were due to Zig/C interactions which makes me believe Rust would have had the same issues, but as a Go developer I am only guessing. I'm curious if there is a language that provides more tools to ensure correctness even when you're interacting with a huge amount of C.

Hi @schmichael ;) Rust would've prevented one. The rest Rust wouldn't have prevented since as you already noticed, it was in the boundary layer and semantics of a C API. It would've only been as safe as the Rust wrapper. One argument is that the richer, more proven ecosystem of wrapper libraries may have prevented it versus my DIY wrappers. The one Rust would've prevented was a simple undefined memory access: https:/…

Hey Mitchell! Leave it to me to bait the comments. :)

Thanks for validating my assumption that once you introduce a big blob o' C all bets are off and you're back to Valgrind (or similar tooling).

> One argument is that the richer, more proven ecosystem of wrapper libraries may have prevented it

Yeah but where's the fun in that? ;)

Re: We rewrote the Ghostty GTK application

#20

Post by WD-42 » Thu, Aug 14, 2025, 10:37 PM UTC

hyperbolablabla wrote: post #4

corsica wrote: post #2

I don't get the hype around this application. The only UI Ghostty has is tabs and the context menu, is it really worth the integration pain and now this rewrite? Maybe they're planning for more, like those GUI configuration dialogs that iterm2 has? Kitty uses OpenGL for everything and draws its own tabs, they're fully customizable and can be made to look however you want. By not wasting time on integrating with massi…

Agreed, seems like a lot of unnecessary girating just to implement something that would've been much simpler + cross-platform with a custom UI toolkit and something like opengl. Tabs are like UI 101

Luckily the UI and the core (libghostty) are separate so you can girate out your own UI 101 version without GTK if you'd like.