4 ms·

Yes, error messages in zig needs improving but that's not surprising. Rust error messages where pretty terrible back in the day. I found zig language reference

Yes, error messages in zig needs improving but that's not surprising. Rust error messages where pretty terrible back in the day. I found zig language reference pretty good[0]. It is simple, lot of example. I would find 80% on there and had to google the rest. And as another commenter said, looking at zig source code is actually not a bad idea. The std lib is pretty clear and with comments. My biggest beef with zig is a lack of a package manager. But apparently, it is high in the list of priority for the author so... [0] https://ziglang.org/documentation/master/ https://ziglang.org/documentation/master/

nkozyra 5y ago
I think zigs documentation is wonderful and explains most seemingly esoteric syntax and language options really well. But if you hit a roadblock it's hard to track down more info. Some of that is due to the lack of adoption, though.
the_duke 5y ago
A potentially huge roadblock to better error messages is lack of generics and interfaces/traits/classes. The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors. It'll be interesting to see how this plays out as the ecosystem grows.
- naasking 5y ago
  > The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors. Why do you think that's the case?
  - jibalt 5y ago
    Because all the semantics for what are the valid parameters for types and other comptime operations are scattered throughout the code that is run at comptime. It's the same problem as with C++ template code, but perhaps worse. For instance, if you do a formatted print and pass an integer to a "{s}" descriptor, the std.fmt code calls @compileError with an informative message, then a dozen lines of stack trace are printed before a line that shows the source code line that invoked the print, and then yet another stack trace because std.fmt returns an error. And that's for std.fmt that is well behaved and calls @compileError when it should ... in many cases the error will be due to a type mismatch or invoking a non-existent member, etc.
    - naasking 5y ago
      I'm still not quite seeing the problem. To my mind, comptime parameters have a direct translation to parametric type parameters in something like system F or a similar parametrically polymorphic type system, and reasonable type errors are possible in those. Do Zig's comptime parameters universally violate parametricity in some way, and this is why the errors are more difficult?

nkozyra 5y ago

I think zigs documentation is wonderful and explains most seemingly esoteric syntax and language options really well. But if you hit a roadblock it's hard to track down more info. Some of that is due to the lack of adoption, though.

the_duke 5y ago

A potentially huge roadblock to better error messages is lack of generics and interfaces/traits/classes. The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors. It'll be interesting to see how this plays out as the ecosystem grows.

naasking 5y ago
> The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors. Why do you think that's the case?
- jibalt 5y ago
  Because all the semantics for what are the valid parameters for types and other comptime operations are scattered throughout the code that is run at comptime. It's the same problem as with C++ template code, but perhaps worse. For instance, if you do a formatted print and pass an integer to a "{s}" descriptor, the std.fmt code calls @compileError with an informative message, then a dozen lines of stack trace are printed before a line that shows the source code line that invoked the print, and then yet another stack trace because std.fmt returns an error. And that's for std.fmt that is well behaved and calls @compileError when it should ... in many cases the error will be due to a type mismatch or invoking a non-existent member, etc.
  - naasking 5y ago
    I'm still not quite seeing the problem. To my mind, comptime parameters have a direct translation to parametric type parameters in something like system F or a similar parametrically polymorphic type system, and reasonable type errors are possible in those. Do Zig's comptime parameters universally violate parametricity in some way, and this is why the errors are more difficult?