没有实际用过 Java ，理论上 CRUD 初期 POJO 的结构可以一路传到任何地方，只需要在前端接口变更 /数据库结构变更等情况发生时再创建对应的对象做转换就可以了。
问题是如果一开始没做这件事，等问题发生时去处理的人又没能意识到这里需要一个现在没有的对象，项目就会逐渐变得无法理解……

工程化的目的是降低参与者自己的认知负载，我觉得这是必然要做的，至于用什么方式做，做到什么程度……那还是要人根据实际情况来决定的，也许没有标准答案。

ubuntu --> debian --> deepin

说实话 fork 一次也不是不行，完全可以不请求合并的

Hexo 的 Next 主题

示例 https://blog.yeningxue.com/

主题地址 https://theme-next.org/

有什么好的跨平台书签管理方案吗……我现在同时使用 Firefox 和 Safari ，需要在 iOS ，macOS 和 Linux 上同步，很头疼这个问题。
顺便推荐一个翻译用的插件 https://immersive-translate.owenyoung.com/

因为 slice 底下是固定大小的数组，不够了要扩容+copy ，你可以试试用 make 来指定底层数组的大小，只要不超过这个大小就不会出现问题。
但归根结底，不知道这个就容易踩坑。

快一年半了，还没怎么打理过，蹲个分享心得的老哥

@lanlanye 表名 -> 表明

按它的说法应该是这样的，隐私问题除了传输中的隐私外还要考虑存储时的隐私，以及用户是否信任服务的提供商，直接选择不保存既可以表名自己对用户的数据不感兴趣，还能省钱。
我觉得省钱才是主要因素……

@GeruzoniAnsasu 我想了想，开辟一个用于保存结果的数组，启动 worker 的时候传入对应顺序的数组下标，直接把结果写进对应位置……应该可行吧

@fioncat 我一开始也是这么认为的，但它确实造成了不便，可以参考我在楼上的回复。另外 Rust 的处理方式就很好，它同样强迫你处理每一个 error 。

@xuyang2 很有问题啊，因为大多数需要异常处理的函数都得返回至少两个结果 (result, error) ，深层调用时每一层做的事就是执行函数，如果有 error 就往上一层抛，也会导致链式调用无法正常写出来，比如 `person.Pet().Name()` ，如果 Pet()方法是一个可能失败的 lazy load ，调用时就根本写不成这样。
目前我只见过 Gorm 那样把 error 直接放进返回值结构里的做法可以缓解这个问题，或者希望 Go 学一学 Rust 。

难说，工程实践的结果是越写越像 Java ，然后越来越觉得那个异常处理反人类……

我认为 Google 的压缩算法是 gRPC 的优势，其他诸如强类型和一些额外的功能支撑之类的都不是重点。
另外因为不是纯文本协议，传输过程中不透明，不可读，通用性也明显不足，就我个人的意见来说一般场景使用纯文本应该更好。

我觉得你要是本身不熟悉 Python 的话说明不是特别在意版本，那 macOS 原装的就可以直接用了吧……

直接使用 python3 就行，什么都不用安装

如果大家都换了怎么办？

非常需要一个等宽并且支持 CJK 的字体，Noto Sans 能用但不好看

轻量级……分布式……感觉好微妙