On: We rewrote the Ghostty GTK application

[aidenn0]

Hopefully it's improved, but the last time I wrote a GTK binding for a language, it was miserable. 98% of it was sane, but the remaining 2% had things like "whether or not this function takes a reference to this object depends on the other parameters passed" which made liveness analysis "interesting."

[DanielHB → aidenn0]

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

[biorach → DanielHB]

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<Box<dyn SomeTrait>>` 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.

[DanielHB → biorach]

not super familiar with Rust but isn't Option<T> just an union type of null and T? I get the language has special semantics for this compared to a union type but it is conceptionally just an union.

For example this is something you can do with typescript.

  function(args: Arguments) { ... }

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

the Arguments { a: 1, b: 1, c: 1 } is not representable.

[0x457 → DanielHB]

> not super familiar with Rust but isn't Option<T> just an union type of null and T?

Only if there is a niche optimization happens if T is never null, otherwise it's a tagged union.

That's not what you're replying to is about.

[qzzi → DanielHB]

I'm pretty sure they're talking about reference counting that depends on the arguments, not about optional arguments or invalid argument combinations.