当你的业务足够复杂以后，你会发现 ddd 的一些优势，当七八年以后你再回过头来看你现在想法，也许会有不同的认识，当然在国内系统不考虑任何可维护性可迭代性的情况下，完全靠堆人解决问题，也许确实不需要 ddd

vaex https://vaex.io/

复杂业务基本都是 sql 或者贴近 sql 的 orm mapping ，stackoverflow 也是自己搞了 dapper ，如果 ef 框架好用，他们也不用自己发明轮子了

wps 打开慢很正常，这样对比并不合适，我 16 年的 mac 和公司的 m1 mac 同时在用，并没有感觉有任何性能的差异

通过调用关系定义上下游关系就是错误的，同时在同一软件系统中，在不同的 use case 中有不同的 context ，它们的上下游关系也是不同的，不是以服务来定义的，是以当时的 use case 决定的。

你可以看看 2000 多年以来哪个时间段固定资产是不保值的，不是绝对的，但要么战乱要么经济体系重建

这问题和序列化没有太大关系，go 的 struct 初始化机制就是这样了，这种问题应该在接触 go 的第一天就清楚，很多教程里也写的明明白白，对于 json 的问题，文档也写的明明白白，要么 omitempty 要么看 json 包的注释：
"Pointer values encode as the value pointed to. A nil pointer encodes as the null JSON object."

一个 semaphore 就能解决的问题，不需要写这么多代码

微信这种超级 app 是无解的，不管用安卓还是苹果，我的 iPhone 在微信打开后台刷新的情况下撑不到下班，关掉后台刷新之后可以撑两天正常使用。

其实这东西够牛逼的话用 python 写都没毛病，不够牛逼的话用 c 写出来也是个玩具

pg 的优点远不止这些，多样的扩展类型对很多复杂业务有很好的支持，最近七八年工作的几家公司都在用 pg ，性能确实非常稳定

只做服务端开发时，air 足够，除非涉及复杂的客户端模拟器，一般开发 air 够用，我的 m1 air 开七八个中等项目的 intellij四五十个 chrome tab 没什么压力

ltree 处理多层级结构时很有用，比如复杂的组织关系，可以轻松的实现一些以前需要递归查询的场景

看不懂为什么有人觉得命令行处理不了一些功能，比如 diff 和处理冲突，pr 等，命令行的优势一个是更清晰的知道处理的流程以及更好的理解一些高级的用法，还有就是可以根据自己或者公司的流程自动化，比如 merge queue 保证合并是线性的，减少冲突。

"可是现在问题来了，我如何区分，到底这个 0 是来自默认赋值，还是用户真的输入了一个 0 呢？"
你用任何语言都需要处理这个问题，和语言无关，cs101 的第一节课这些问题都应该解释过，也许你在 java 中数据库使用 null ，那 go 也有对应的数字类型对象可以使用，总之，这个问题和语言一点关系都没有

引用私有成员本身就破坏了封装性

语言本身的生态更重要，在国内 java 开发后端有大把的中文资料和从业人员，本身就处于优势地位，语言本身的优劣并不重要

@yuluoxinsheng 经验就是优势，业务开发就是看的相关业务的设计能力，系统设计能力