1. 49

    1. 4

      Can’t wait for an alpha/beta if he ever plans to release it.

      1. 4

        The slide deck indicates a 1.0 public release in 2024.

      2. 4

        Join the Ghostty Discord server and see if you eventually get invited in the beta. Mitchell has been inviting people regularly for a while now.

    2. 3

      I think that always strikes me as interesting when I see comptime is how the uses feel exactly like Lisp macros. Like all the enum generation, type generation, etc? Yeah, I’d use macros for that. Obviously, I am not getting static types in doing so, but you get the point. The fact that comptime uses a subset of Zig to work? That’s just macros. Macros. Macros. Macros. It’s so good to see it. :)

      1. 4

        Yeah! There is a significant difference, because Zig comptime functions are not working with ASTs in the way Lisp macros do, although the type generation is a little bit like that. You can think about comptime functions in the same way as ordinary runtime functions, semantically. They don’t have access to inspect their arguments as expressions, they can’t cause an argument with side effects to be evaluated twice, etc. So they are limited compared to Lisp macros, but they also don’t introduce funky new semantics that make the language harder to reason about at a glance.

    3. 3

      Looking forward to testing this out. Not really getting the “closed source” until we ship idea though.

      1. 4

        I mean, it’s a personal project. Especially when you’re somewhat well known, opening up a project that you don’t intend to take any practical feedback on can just generate a lot of noise.

    4. 1

      The reason I don’t define the enum up front is because there is additional data associated with each entry that I want to keep packed for easy editing and reference. In this case, each mode has a value.

      Is it just me, or does this (key -> value enum) seem like a poor example? Couldn’t you just write it as:

      const Mode = enum(u8) {
          cursor_keys = 1,
          132_column = 3,
          // ...

      and have the same effect (easy editing/referencing, even moreso because it’s less characters), no type generation function required? I don’t see the practical or theoretical benefits of this specific example, maybe I’m missing something.

      1. 2

        Hello! The reason I don’t do the straight enum is because I also need the default data associated with it.

        1. 1

          Sorry, I’m a bit confused as to what you mean. Maybe we’re talking about the wrong example?

          To clarify, I’n talking about this example, where you just generate an enum from a collection of key-value pairs in a constant struct – I don’t see any defaults going on here.

          1. 3

            Ah, the sample on the slide is not very good. The RawEntry type has additional metadata. Here is the code sample including that. In the video version you can see it because for all of these slides I tabbed over and went through the actual code. The slide text is just bad!

            /// A single entry of a possible mode we support. This is used to
            /// dynamically define the enum and other tables.
            const ModeEntry = struct {
                name: []const u8,
                value: comptime_int,
                default: bool = false,
            /// The full list of available entries. For documentation see how
            /// they're used within Ghostty or google their values. It is not
            /// valuable to redocument them all here.
            const entries: []const ModeEntry = &.{
                .{ .name = "cursor_keys", .value = 1 },
                .{ .name = "132_column", .value = 3 },
                .{ .name = "insert", .value = 4 },
                .{ .name = "reverse_colors", .value = 5 },
                .{ .name = "origin", .value = 6 },
                .{ .name = "autowrap", .value = 7, .default = true },
      2. 1

        He’s defining many enums. What I find odd is the data tables examples generate structs from tuples, but the enum generation generates enum types from structs. Why are structs readable in one place but not the other?

        1. 1

          Not really? He’s defining a constant array that maps a string to a value, and generating an enum for it at comptime. I don’t understand why that can’t be done by defining an enum literal – the reason provided doesn’t really make sense in this case, IMO.

    5. 1

      OT: the intro music is FWLR - How We Win.

      I just had to look it up!