Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun

Re:Why I rewrote my Rust keyboard firmware in Zig: consisten... by lhorie on Sunday March 07, 2021 @08:57AM (#26375848)

I don't think comparing zig's comptime with rust macros is actually that apt of a comparison. I tend to think of rust macros as syntactic sugar. Zig's comptime permeates the language thoroughly and in fundamental (and IMHO very pragmatic) ways. Top level const expressions are automatically comptime, modules are comptime structs, static polymorphism is used all over the stdlib (e.g. std.mem.eql), heck std.debug.print is written without special compiler tricks thanks to how cleanly you can use comptime in zig.

I think the idea that zig is a very sharp knife is true, but the overlap of footguns and comptime is not as big as one would think (@fieldParentPtr mistakes comes to mind, but that's sort of about it)

[ Parent | on HN ]

Re:Why I rewrote my Rust keyboard firmware in Zig: consisten... by ifreund on Sunday March 07, 2021 @09:13AM (#26375963)

The implementation of the pinned keyword proposed here should fix most if not all @fieldParentPtr() footguns https://github.com/ziglang/zig/issues/7769

[ Parent | on HN ]

Re:Why I rewrote my Rust keyboard firmware in Zig: consisten... by zozbot234 on Sunday March 07, 2021 @09:33AM (#26376099)

> Zig's comptime permeates the language thoroughly and in fundamental (and IMHO very pragmatic) ways.

TANSTAAFL. Compile-time evaluation cannot truly "permeate" a language because most practical languages preserve a phase distinction between compile time and runtime. (This phase distinction is somewhat softened, e.g. in interpreted languages as well as in advanced PL's which include such features as dependent types). For a system programming language like Rust which relies on this clear-cut phase separation, macros and proc macros (as well as `const`-marked expressions and functions) are ultimately more elegant.

[ Parent | on HN ]