>- As a long time user of Nim (including on really lean embedded targets), compared to hygienic macros, comptime falls way short.
In what way? Comptime should be generally capable of anything macros are.
>- The lack of first class interfaces/traits/typeclasses is not my favorite. The currently suggested alternatives are so un-ergonomic I'd almost call them hostile.
Terribly difficult to implement without breaking a major language tenant of “no hidden control flow”.
But I found that once I left behind OO style of thinking, I haven’t missed this all that much. For the rare time I do generalize like this, you can literally just check at comptime that the passed in type provides the necessary decls. It’s not terribly complex or hostile (although tooling could use some work around it)
> In what way? Comptime should be generally capable of anything macros are.
I started to reply to this with 'Comptime is generally capable of doing anything that Nim's templates can accomplish (but not it's macros)', but I stopped myself because even though Zig's comptime is more akin to Nim's templates than its macros (in my opinion), Nim templates are more powerful as they allow you to embed arbitrary blocks of code to implement constructs similar to python's context managers (which I'm fairly certain you can't do with comptime).
W/R/T Macros vs Comptime, you can't create arbitrarily complex DSLs with comptime the way you can with a Nim's macros as you don't have full control over AST generation.
All that said, the power you'd get from a Macro or Template system like Nim's don't really jive with Zig's whole "no hidden control flow" thing.
>Terribly difficult to implement without breaking a major language tenant of “no hidden control flow”.
I dunno if I agree with that, even very simple rust-like traits that simply enforce that a struct implemented a given interface at compile time (static dispatch only) would go a long way without compromising obvious control flow IMO.
>But I found that once I left behind OO style of thinking, I haven’t missed this all that much. For the rare time I do generalize like this, you can literally just check at comptime that the passed in type provides the necessary decls. It’s not terribly complex or hostile (although tooling could use some work around it)
Respectfully, I don't view it as OO thinking (I think typeclasses come from SML...). Making polymorphism reasonably ergonomic goes a long way towards code reuse and (again, only my humble opinion here) would help with what some of the folks in this comment section are talking about w/r/t code re-use and generalizing a HAL layer in a consistent way without forcing users (or library authors) to write a bunch of ad-hoc code to check that functions exist on a given struct, or manually implementing dispatch tables.
I would generally agree that polymorphism is necessary, except maybe for embedded systems. You want more of a closed world system there, not an open world system that permits arbitrary extensions.
By open world, I'm thinking of abstractions like closures and interfaces which permit arbitrary extension and require dynamic dispatch. Given any fixed set of such abstractions, you can simulate in a closed world system via something like defunctionalization during whole program compilation, which is what you do on embedded systems. You can probably do a defunctionalization transformation with comptime, and that gets you better visibility on the state of the system in a way that's not possible with a truly open world system.
> All that said, the power you'd get from a Macro or Template system like Nim's don't really jive with Zig's whole "no hidden control flow" thing.
Only if you do it wrong.. It's quite simple to mandate a special character which indicates that "something's happening here", for example you could have
y = a #+ b with + being a function operating on matrixes, the # indicating that this is a function called not the regular operator.
In what way? Comptime should be generally capable of anything macros are.
>- The lack of first class interfaces/traits/typeclasses is not my favorite. The currently suggested alternatives are so un-ergonomic I'd almost call them hostile.
Terribly difficult to implement without breaking a major language tenant of “no hidden control flow”.
But I found that once I left behind OO style of thinking, I haven’t missed this all that much. For the rare time I do generalize like this, you can literally just check at comptime that the passed in type provides the necessary decls. It’s not terribly complex or hostile (although tooling could use some work around it)