> Rust could be a much more ergonomic language if the compiler wouldn't have to rely on function signatures alone but instead could peek into called function bodies
This path leads to unbounded runtime for the type checker/borrow checker. We’re not happy about build times as is.
Re:Zig's Comptime Is Bonkers Good
by littlestymaar on Tuesday January 07, 2025 @06:38AM
(#42621435)
And also lead to subtle errors for users of crates. Semver is hard enough to do when the compiler only deals with signatures, but if the body of the functions now contain invariants that can be relied on by function callers then it becomes intractable.
> most of those points one only stumbles over after a few thousand lines of Zig and going really deep into the comptime features.
> nothing about it is surprising when working with it
I think there's a contradiction here - when you get deep into using this kind of feature in a complex way is precisely when you most need it to behave consistently, and tends to be where this kind of ad-hoc approach breaks down.
Re:Zig's Comptime Is Bonkers Good
by throwawaymaths on Tuesday January 07, 2025 @09:04AM
(#42622405)
if youve never gone deep into zig comptime... really nothing is surprising, except possibly when you can't do things and usually after a bit of thinking about it you understand why you can't.
And some features in your list are of questionable value IMHO (e.g. the "reasoning over a function type signature" - Rust could be a much more ergonomic language if the compiler wouldn't have to rely on function signatures alone but instead could peek into called function bodies).
There are definitely some tradeoffs in Zig's comptime system, but I think the more important point is that nothing about it is surprising when working with it, it's only when coming from languages like Rust or C++ where Zig's comptime, generics and reflection might look 'weird'.