标签：#zig

Originally published on tamiz.pro . Introduction Zig's innovative approach to package management through its build system represents a paradigm shift in software development. By eliminating external dependency managers, Zig offers a streamlined workflow that prioritizes determinism, performance, and simplicity. Understanding the Shift Traditional package managers often introduce complexity with version conflicts, global state management, and ecosystem fragmentation. Zig's build system, powered by the build.zig configuration file, directly handles dependency resolution, compilation, and linking. This integration removes the need for tools like Cargo (Rust) or Go Modules, creating a unified interface for project lifecycle management. Key Capabilities of Build-Driven Package Management Deterministic Dependency Resolution : Zig's build system uses checksums for dependencies, ensuring identical builds across environments. Version conflicts are mitigated via semantic versioning baked into the build logic. Zero-Configuration Compilation : With @import("std").fetch , dependencies are automatically fetched and compiled without requiring separate installation steps. Cross-Platform Consistency : The build system abstracts platform-specific details, ensuring dependencies compile correctly on Windows, Linux, and macOS without manual configuration. Minimal Runtime Overhead : No virtual environments or global state: dependencies are embedded directly into the project structure during compilation. First-Class Testing Support : Built-in test runners execute tests from dependencies alongside your code, ensuring compatibility at build time. The Impact on Developer Workflow Dependency Declaration : Developers define dependencies in build.zig using URLs or Git repositories with semantic version pins. Automated Fetching : The build system downloads dependencies to a zig-cache directory, validating checksums before use. Incremental Builds : Changed dependencies trigger recompilation only

In December 2025, Anthropic acquired Bun , the JavaScript runtime written in Zig. In April 2026, the Bun team announced a 4× compile-time improvement on their fork of the Zig compiler — "parallel semantic analysis and multiple codegen units to the llvm backend" , in their phrasing. They also announced they would not be upstreaming the work, "as Zig has a strict ban on LLM-authored contributions." The framing landed badly with Zig observers, for two reasons. The first was that the framing made Zig's contribution policy the obstacle. The second, pointed out shortly afterwards by a Zig core contributor in the Ziggit thread, was that the patch had separate engineering reasons it would not have been merged regardless: "Parallel semantic analysis has been an explicitly planned feature of the Zig compiler for a long time" , with "implications not only for the compiler implementation, but for the Zig language itself" . The AI-ban explanation was, on a closer read, a tidy way of declining to litigate the engineering disagreement in public. Both readings are useful. They are also both downstream of the actual rationale, which is one of the most carefully argued OSS-governance documents to appear in 2026. What the policy actually says The relevant clauses, in the Zig code of conduct under the section heading Strict No LLM / No AI Policy , are three: No LLMs for issues. No LLMs for pull requests. No LLMs for comments on the bug tracker, including translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words. The translation clause is the surprising one. It is also the one that disambiguates the policy from a code-quality rule. A blanket ban on LLM-mediated communication, including translation, is not a heuristic about whether agentic tools produce good code. It is a stance about what the project's communication channels are for . Contributor poker Lor

Blog no. 03 Accessing environment variables Environment variables are key-value pairs given to a process by the operating system right before it starts. They are mainly used to configure the process on runtime. In C/C++, the environment variables are passed to the main function as arguments. In zig, the environment variables are can be accessed from the init object which is passed to the main function as argument. Let's see how that works. Program - Printing all inherited environment variables using zig. To print out all the environment variables, we will utilize the environment variable iterator. // environment_vars1.zig const std = @import ( "std" ); pub fn main ( init : std . process . Init ) ! void { var env_vars_iterator = init . environ_map . iterator (); // setup stdout writer var buffer : [ 1024 ] u8 = undefined ; var file_writer = std . Io . File . Writer . init (. stdout (), init . io , & buffer ); var stdout_writer = & file_writer . interface ; while ( env_vars_iterator . next ()) | env_var | { try stdout_writer . print ( "{s} \n {s} \n\n " , . { env_var . key_ptr .* , env_var . value_ptr .* }); } try stdout_writer . flush (); } You can run the program using zig run environment_vars1.zig . This will print out all the environment variables to console. To build executable zig build-exe -O ReleaseSafe environment_vars1.zig Program - Printing the value of a user selected environment variable using zig. In this program we are going to setup a Reader which can read from stdin . We will first print out the names of all the environment variables using the iterator we used in the above program and then using aforementioned reader instance, we will let the user type in the name of an environment variable. If they entered a existing environment variable name, we will retrieve the value of that environment variable using the get function and print the value of that environment variable. If the user entered a non-existing environment variable name, we will error out u

Smart Lighting Protocol Showdown: Zigbee vs Matter vs BLE Mesh (2026) After deploying thousands of Zigbee smart lights through our manufacturing line at nexLAMP, and watching countless customers struggle with protocol selection, I decided to write this practical comparison. The Real Problem "My smart lights keep disconnecting! I think I chose the wrong protocol..." This is the #1 complaint I see on Reddit, Xiaohongshu, and Zhihu. The fix isn't a better router — it's choosing the right protocol from day one. Protocol Deep Dive Zigbee — The Workhorse Frequency : 2.4 GHz (separate from WiFi) Topology : Star + Mesh hybrid Max devices : 200+ per coordinator Latency : 50-200ms Cost/unit : ~$3.5-5.0 (Tuya Zigbee drivers) Why it wins for lighting: Each node is a repeater → self-healing mesh Ultra-low power → years on coin cell for sensors Mature ecosystem → Tuya, Hue, Aqara, Xiaomi all ship Zigbee The catch: You need a Zigbee gateway (~$15-20). This is the only upfront cost. BLE Mesh — The Budget Option Frequency : 2.4 GHz (shared with WiFi/BLE) Topology : Managed flood mesh Max devices : ~50 (practical limit ~30) Latency : 100-500ms (increases with node count) Cost/unit : ~$2.0-3.5 The flooding problem: Every command is broadcast to every node. With N nodes, you get O(N²) message propagation. Past 30 devices, you'll notice visible lag. Good for: Small apartments (≤ 6 lights), budget projects. Matter — The Future Transport : Thread (preferred) or WiFi Topology : Thread mesh (similar to Zigbee) Max devices : 250+ (theoretical) Latency : 30-150ms (Thread), variable (WiFi) Cost/unit : ~$7.0-11.0 (currently higher) Matter's promise is genuine cross-platform control. But in 2026: Pros: Native HomeKit, Alexa, Google Home support Thread mesh is excellent (when it works) IP-based → easier cloud integration Cons: Thread Border Routers aren't ubiquitous yet Advanced lighting features still evolving Premium pricing for early adoption Cost Analysis (20-Fixture Deployment) Protocol Driv

Why Manual Memory Management Still Matters ? It is now easier than ever to write software...