We rewrote the Ghostty GTK application

Post by steveklabnik » Fri, Aug 15, 2025, 10:23 AM UTC

ozgrakkurt wrote: post #118

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.

It is so much more difficult to write c bindings in rust. Maybe they wouldn’t even be able to write gtk bindings in rust

Post by paraboul » Fri, Aug 15, 2025, 10:26 AM UTC

ur-whale wrote: post #128

biorach wrote: post #125

Earlier quoted context omitted.

Might be $TERM needs to be set or you need to add ghostty to terminfo

> Might be $TERM needs to be set or you need to add ghostty to terminfo Yeah, except that the specific terminfo needed for ghostty isn't installed anywhere on the boxes you ssh into ... you need to manually install it on every single one of them. That in and of itself makes it truly painful to switch to ghostty. And there are still a lot of other issues, like e.g. building the tip is a freaking nightmare of dependenc…

Post by ur-whale » Fri, Aug 15, 2025, 10:36 AM UTC

biorach wrote: post #132

ur-whale wrote: post #128

Earlier quoted context omitted.

> Might be $TERM needs to be set or you need to add ghostty to terminfo Yeah, except that the specific terminfo needed for ghostty isn't installed anywhere on the boxes you ssh into ... you need to manually install it on every single one of them. That in and of itself makes it truly painful to switch to ghostty. And there are still a lot of other issues, like e.g. building the tip is a freaking nightmare of dependenc…

> the specific terminfo needed for ghostty isn't installed anywhere on the boxes you ssh into ... you need to manually install it on every single one of them. Yeah this is going to be an issue with any of the newer terminal emulators. No big deal. Updating terminfo is easy. If you can't then just set TERM=xterm > Not ready for prime time by a mile IMO. Nah, the issue is your lack of experience and understanding of th…

Post by DanielHB » Fri, Aug 15, 2025, 10:49 AM UTC

biorach wrote: post #124

DanielHB wrote: post #107

Earlier quoted context omitted.

This is what people mean when they say "make invalid states unrepresentable", languages with union types can easily avoid this problem.

It doesn't sound like they are talking about invalid states, more like they are taking about the kind of thing that in Rust would be represented by `Option >` or suchlike. Maybe your point is that in Rust much less ceremony is necessary to avoid hitting a null pointer when doing this. But still, in either language it's easy to end up with hard to follow logic when doing this.

  function(args: Arguments) { ... }

  type Arguments = { a: number, b: number } | { a: number, b: string, c: number }

Post by gf000 » Fri, Aug 15, 2025, 11:13 AM UTC

troad wrote: post #60

NobodyNada wrote: post #41

Earlier quoted context omitted.

In general: whenever you call into C, you get all the safety of C, because C code can trivially have memory corruption bugs that corrupt memory "belonging" to Rust as well, inducing undefined behavior across your whole program [0]. In addition, it's often considered permissible for C APIs to exhibit undefined behavior if their API contracts are violated. This means that a bug in Rust code that calls into a C API inco…

> The typical approach to using C libraries from Rust is to create a "safe wrapper" around the unsafe FFI calls that uses Rust's type system and lifetimes to enforce the safety invariants. Calling it a "safe" wrapper, when that safety is entirely dependent on (a) the correctness of the hand-written wrapper, (b) the safety of the underlying FFI code, has always been a huge stretch of terminology. It's more like a veil…