Andrewrk在Zig语言项目的GitHub仓库中提交了一个名为“Writergate”的Pull Request（#24329），旨在改进代码编写或相关功能。该请求涉及代码审查、讨论等功能，具体内容未详细说明。

这篇文章主要介绍了Zig编程语言中关于I/O（输入/输出）系统的一次重大更新，名为“Writergate”。该更新由开发者andrewrk提出，旨在通过引入新的std.io.Reader和std.io.Writer接口来取代现有的I/O读写器，从而优化性能和简化代码结构。

主要内容总结：

1. 新API的引入：

   • 新的std.io.Reader和std.io.Writer接口不再使用泛型，而是将缓冲区放在接口层，而不是实现层。这使得接口函数在操作缓冲区时具有更高效的热路径，只有在缓冲区满时才会调用虚表函数。
   • 这些新接口提供了更便捷的API，性能更好，且不再依赖泛型。

2. 现有API的弃用：

   • 所有现有的std.io读写器都被弃用，并提供了替代方案。例如，std.fs.File.reader被替换为std.fs.File.deprecatedReader，std.fmt.format被替换为std.fmt.deprecatedFormat等。
   • 这些变化是破坏性的，开发者需要根据升级指南进行代码迁移。

3. 格式化打印的改进：

   • 引入了新的格式化选项，如{t}用于@tagName()和@errorName()，{b64}用于输出标准base64编码的字符串。
   • 格式化方法的签名也发生了变化，例如anytype被替换为*std.io.Writer，错误集被明确为error{WriteFailed}。

4. 新特性：

   • 丢弃（Discarding）：在读取时允许高效地忽略数据，例如在解压缩流中跳过整个帧的解压缩。
   • 溅射（Splatting）：在写入时允许逻辑上的“memset”操作，避免内存复制，提升性能。
   • 文件发送：在写入时允许直接进行文件描述符到文件描述符的复制，提升效率。
   • 缓冲区管理：流用户提供缓冲区，但流实现决定最小缓冲区大小，将状态从流实现转移到用户缓冲区。

5. 文件读写器的改进：

   • std.fs.File.Reader和std.fs.File.Writer现在会缓存文件的关键信息，如文件大小、当前寻址位置等，提升了文件操作的效率。

6. 未包含的内容：

   • 该分支并未包含对TLS、HTTP、JSON、ZON、ZSTD、FLATE、ZIP等模块的重构，也未涉及异步/等待（Async/Await）的复活。这些内容将在后续的PR中逐步引入。

7. 合并检查清单：

   • 包括修复行为测试、标准库测试、解决TODO项等任务。

总结：

“Writergate”是Zig语言中I/O系统的一次重大更新，旨在通过引入新的非泛型读写器接口来提升性能和简化代码结构。尽管这些变化是破坏性的，但开发者可以通过提供的升级指南逐步迁移代码。该更新为Zig的I/O系统带来了多项新特性，并为未来的进一步优化奠定了基础。

评论内容总结：

1. 对Zig语言的不满与担忧：

   • 观点：Zig语言频繁的语法更改和破坏性更新使其不适合用于实际项目，尤其是需要稳定性的项目。
   • 论据：blippage提到，Zig的版本更新导致其代码无法正常运行，最终决定放弃使用Zig，转而使用C或C++。他还指出，Zig的频繁更改表明它尚未成熟。
     • 引用1："The fact that another breaking change has been introduced confirms my suspicion that Zig is not ready for primetime."
     • 引用2："My conclusion is to just use C. For low-level programming it's very hard to improve on C."
   • 观点：Zig可能陷入了“完美主义综合症”，导致其不断重新设计，而其他语言如Odin早已稳定发布。
   • 论据：brabel认为Zig似乎一直在追求完美，导致其无法像Odin那样快速稳定发布。
     • 引用1："Is Zig suffering from perfectionism syndrome where things are never good enough??"

2. 对新语言的谨慎态度：

   • 观点：新语言虽然吸引人，但在项目中引入新语言可能会带来不必要的麻烦。
   • 论据：lpapez引用了一位资深开发者的比喻，认为软件像千层面，最好在放置一段时间后再使用，暗示新语言需要时间成熟。
     • 引用1："Software is just like lasagna. It has many layers, and it tastes best after you let it sit for a while."
   • 观点：Zig的频繁更改使其不适合用于严肃项目，尽管其潜力令人期待。
   • 论据：GolDDranks表示，尽管他喜欢Zig，但由于其频繁的破坏性更改，他暂时不会在严肃项目中使用它，而是继续使用Rust。
     • 引用1："Zig having breaking changes has made me wary of not starting anything serious it with – yet."

3. 对Zig未来发展的期待：

   • 观点：尽管Zig目前存在不稳定问题，但仍有开发者对其未来发展持乐观态度。
   • 论据：GolDDranks表示，他愿意等待Zig的稳定版本，并在此期间继续使用Rust。
     • 引用1："I'm still happy that these changes happen, because I'm willing to wait for a stable version."
   • 观点：Zig需要类似Go的自动化工具来帮助开发者应对语言和标准库的更改。
   • 论据：Aissen提到，Go有go fix工具来处理语义更改，并建议Zig也应有类似的解决方案。
     • 引用1："This is why it's good to have automated tooling that can do semantic changes on your language and standard library use."

4. 对Zig的彻底否定：

   • 观点：Zig的开发方式让一些开发者彻底放弃使用它。
   • 论据：adastra22表示，如果Zig以这种方式开发，他将永远不会使用它。
     • 引用1："Whelp, I ain't ever touching Zig if this is how it is developed."

总结：评论中对Zig语言的态度呈现两极分化，一方面有开发者对其频繁的破坏性更改表示不满，认为其尚未成熟，不适合用于实际项目；另一方面，也有开发者对其未来发展持乐观态度，愿意等待其稳定版本。同时，一些开发者对新语言持谨慎态度，认为需要时间验证其稳定性。