加载失败
Skir 是一个新兴的通用 schema 语言，目标与 Protocol Buffers 类似：在 .skir 文件中定义类型、常量和 RPC 接口，然后生成多语言（如 TypeScript、Python、Java、C++）的类型安全代码。讨论围绕 Skir 与现有生态（Protobuf/buf.build、Cap'n Proto、connectrpc、OpenRPC、Apache Arrow Flight 等）的重合与差异展开，重点在序列化格式（特别是 dense JSON）、兼容性检查实现、严格构造器的安全性，以及各语言/平台支持的完整性。评论者既认可 Skir 在设计意见（避免静默默认、统一枚举、提供兼容性工具）上的价值，也反复提醒这些改进需要工程上的 opt‑in 和快照管理才能兑现，并建议根据具体用例（浏览器友好、零拷贝或高吞吐）在现有成熟方案与 Skir 之间权衡。
Skir 被定位为与 Protobuf 同类的通用 schema 语言，但作者与评论者列出了若干有意为之的设计决策：内置兼容性检查、跨项目导入依赖的能力（评论指出 buf.build 提供类似功能但有付费限制）、以及在语言层面对 enum/oneof 的重新设计以更接近 Rust 风格的枚举以简化映射。一个被反复提及的亮点是“严格生成构造器”（strict generated constructors）：当向 schema 添加字段时，所有构造调用点会在编译时暴露并报错，从而避免 Protobuf 那种“静默默认值”导致的生产事故。Skir 还主推一种名为 dense JSON 的序列化格式，声称在效率、向后/向前兼容性与可读性之间提供折中，并支持生成 TypeScript、Python、Java、C++ 等多语言的类型安全代码。
评论聚焦于 Skir 推荐的 dense JSON：它通过密集字段编号/数组形式实现比可读 JSON 更紧凑但比二进制稍大的一种折中格式，并且支持安全重命名字段，有利于 schema 演进。反对意见强调可读性问题——序列化后可能变成无标签的数组（示例为 [3, 4, "P"]），一旦丢失 schema 或需要人工查看日志就难以理解；这在二进制格式中也存在但更常被标注为不可读。关于长期可兼容性的主张也带有条件：兼容性检查要求你显式 opt‑in 使用 stable record IDs 并维护快照，否则 CLI 会警告“无法检测破坏性变更”，也就是说安全性是可用的但依赖工程纪律。评论还提到 Google 内部的 JSPB（用于前端的特殊 Protobuf JSON）有类似初衷但文档稀少且多已被弃用。
多条评论把 Skir 放在已有生态与替代方案的光谱中，提醒读者考虑现有成熟选项：Cap'n Proto（由 proto2 实现者 Kenton Varda 设计）及其面向 web 的 Cap'n Web、connectrpc（针对现代 RPC 的项目）、wrpc（Bytecode Alliance 的尝试）、以及面向高吞吐的 Apache Arrow Flight。也有人提到 OpenRPC（面向 RPC 的规范）和 buf.build（Protobuf 的工具生态）。评论指出这些项目在不同场景上已有优点——例如浏览器友好、promise pipelining、零拷贝、Rust/WASM 支持或高吞吐传输——因此是否采用 Skir 应基于具体用例而非单纯口号式替代。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
评论里有人质疑项目成熟度与市场定位：Skir 仍较新且起初缺少重要语言绑定（如 Go、Rust、C#、Swift），维护者表态会在后续加入这些语言。文档和示例曾出现语法不一致的问题（如常量语法示例与实际解析器不符），作者已修复并更新了 tagline（从“like protos but better”改为“A modern alternative to Protocol Buffer”）。多位评论者认为即便工具提供了“更安全的默认”，工程上仍需遵循 discipline（启用 stable record IDs、保存快照等）才能实现长期兼容，因此不宜把“更好”作为无条件结论，而应强调设计取向与权衡。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
dense JSON: 一种用数组或密集字段编号表示的紧凑 JSON 表示法，在效率、兼容性和可读性之间做折中；比二进制略大但比可读 JSON 更紧凑，允许字段重命名而保持兼容，但丢失 schema 时可读性很差。
strict generated constructors: Skir 的生成器会为记录生成严格的构造器：当向 schema 添加字段时，所有构造调用点在编译时会报错，迫使开发者更新调用以避免隐式默认值导致的生产问题。
stable record IDs: 用于保证序列化兼容性的稳定标识机制：必须显式启用并维护快照以便兼容性检查生效，否则工具会警告某些破坏性变更无法被检测。
JSPB: Google 内部的 JavaScript Protobuf JSON 表示（JSPB），为前端/后端通信实现过紧凑的 JSON 优化，公开文档少且可读性差，现在多半已弃用或不作为首选方案。
enum/oneof 统一（Rust‑style enums）: 把 Protobuf 的 enum 与 oneof 语义在语言层面合并成类似 Rust 的代数枚举，以简化模型并在目标语言中获得更一致的类型映射。