Hacker News Reader

Comment by creata | Hacker News Reader

> This makes them much easier to reason about and debug.

Can you give an example of something that's easier to reason about (e.g., an error that's easier to spot) with Zig's comptime than with macros?

> it makes other language features redundant

I'm guessing (so I might be wrong) that IDEs and users still need to be aware of the common idioms, so why does it matter whether or not those common idioms are implemented in the compiler or using comptime? (I'm not saying it doesn't matter, I'm wondering what benefits you have in mind.)

View on HN

> Can you give an example of something that's easier to reason about (e.g., an error that's easier to spot) with Zig's comptime than with macros?

Rust proc_macros takes a stream of tokens and return a stream of tokens. If your macro meant to return an instance of a specific type, it must output the correct tokens which create that instance via existing interfaces. There's some really ugly indirection in trying to understand what's going on.

This is always harder to reason about than Zig's equivalent, because in Zig you just return the thing that you want to return.

How does it work if I wanted to construct a type (and maybe a set of helper types. some related functions, etc.), rather than an instance of a type?

If I just wanted to construct an instance of a specific type at compile time in Rust, I'd probably be using a const fn instead of a macro.

You return the type directly. You can then declare things to be of this type. Eg, from the Zig docs, here's how to construct a generic List type (note the comptime declaration of the generic parameter):

  fn List(comptime T: type) type {
      return struct {
          items: []T,
          len: usize,
      };
  }

  // The generic List data structure can be instantiated by passing in a type:
  var buffer: [10]i32 = undefined;
  var list = List(i32){
      .items = &buffer,
      .len = 0,
  };

You can't reason about macros, that's not how they work.

You can read their definition, you can expand them, but there's no way to look at a macro call and reason about it, it can do anything at all. In C you don't even know what is and isn't a macro, so Rust has a modest edge in that respect.

Zig just doesn't have this problem to begin with.

Reading a macro's definition and reasoning about its effect is... reasoning. It's not the same as reasoning about something using its inherent limitations, which is the kind of reasoning that I think you're referring to, but it's still reasoning.

Ok, sure, we can reason about anything. We could reason about machine code, if we had the time and inclination.

I barely participate in Hacker News anymore because it seems to have collectively lost the ability to extract meaning from words, unless an exhausting and totally excessive amount of attention is put into satisfying a misplaced sense of precision. There's no intellectual charity left and it sucks.

I have difficulty debugging proc macros. If I need to output some data to aid in debugging a derive macro, the only way I could think of to make that happen was to make it panic with the data as part of the message. This feels like a very clunky way to debug.

Reply on news.ycombinator.com