本质问题是测试用例管理问题吧，只是在低版本中 skip 掉某些特殊用例而已。

以 Github Action 为例，比如说低版本中已存在的测试用例，只需在版本列表中加入新版本即可。

对于新的泛型测试用例，放在不用的 Go 测试项目中，只是添加一个新的 action YAML 即可。

@firecode 不想用第三方的可以自己实现一个

@FrankHB zig 在做自己的 backend 了，不过目标时间是 1.0 https://kristoff.it/blog/zig-new-relationship-llvm/

zig cc 确实不是主要目标，但是很多公司在用 zig cc 。uber 为此还专门赞助了 zig ，专门签了独家协议优先解决 zig cc 的问题

@binhb zig 可以做 C 后端，平替 gcc/clang

协议解析->协议 handler

bob 很好用

Github 的商业化很明显是有微软的影子在的

联想一下 VSCode 很多闭源插件和特性，后面收费也是指日可待的事情了

第一个问题是生态软件没有一统江湖的选择，然而事实上也不能这么依赖第三方的依赖，毕竟这个选择权归作者所有，作者不用就抓瞎。Go 的第三方库基本这个问题就是看是否有预定抽象接口，替换一下即可。不过这也是作者行为，作者不允许你改，你能做的只有重定向输出。

第二个问题建议使用 context 下传，后面很多东西比较方便处理。如果实在不想，也有 gls 这些第三方方案可以用。但是这些方案不保证兼容性。周边生态基本是 context 兼容的，如果使用 gls 很难和这些方案结合，比如分布式追踪。选择 gls 另外一个问题和 goroutine 有关，新 goroutine 的创建时就需要额外处理很多东西了。这个在并发时会经常遇到。

第三个问题无解，就是辣么烦。不过想偷懒的话，Go1.18 之后有第三方库快速处理一下，比如 https://pkg.go.dev/github.com/samber/lo#readme-try

墙是双向的

只能到 2025 年

一般是放到 stdout, stderr 的话，比较邪典的做法是使用 syscall.Dup2 重定向 fd

让老板加到 OKR 里

没有语法糖实现装饰器

如果是缓存返回结果可以使用中间件

取决于你用不用 Xcode/Docker 之类的

@orzglory 于是现在 uber 换 zig 做 cgo 后端了 233333

CGO 确实体验式最差的，并且尼玛死活没计划改...

不过你说的这个问题倒不是什么比较大的问题，想内嵌不过是 dynamic library loader 的问题...有很多第三方库可以用的 https://github.com/rainycape/dl

@orzglory 差不多吧，我这边是有一些 K8s 还有一些裸 server 。目前我是直接 pulumi 管理的

我也在这么用 Task ，不过一个问题是如果是服务器群的话怎么解决呢？