troywinter

DI 啊，跟服务端的 spring 作用一样啊，因为国外那帮程序员得写测试代码啊，所以需要 DI

感觉明基的护眼系列都还可以，至于有人说 4k 更清晰更不费眼的，我觉得不一定，之前显示器由 2k 偶然跳到了 1080p，感觉眼睛舒服了很多，虽然看着模糊，但眼睛不累，我觉得每个人感受都不一样吧，看人，看得累了就休息休息，最主要还是从补充营养和休息入手吧

没必要过度设计，snowflake 已经是相当广泛应用过的 id 生成算法，碰撞不用考虑，对外暴露 id 加 salt 加密就可以了，只要不把原始 id 暴露出来就可以，等有人攻击你们系统了，也就有钱搞这些了

RocketMq 和 Kafka 的性能基线就不在一个水准上，Kafka 利用顺序读写已经把一个 MQ 的性能压榨到比较极限的水准了，超高的性能也带来了一些问题，每一个 topic 在硬盘上用一个 logfile 表示，通过顺序读写可以使性能非常高，但当多个 topic 的多个 partition 分布在同一台机器上时，原本的顺序读写就变为随机读写，partition 越多，随机就越严重，apache pulsar 解决了这个问题是使用 bookkeeper 做 store，这样做同时也降低了性能基线，业务需要很高的性能时，用 Kafka 没错，堆机器就行了，没钱堆机器时也不需要那么高的性能。

引流，涨粉，拉新。算是灰产，但利益庞大，很有钱景，新媒体行业的标准玩法。

@hardware 确实，一份价钱一分货，我的 16 年的 mbp 用了三年多没出过任何问题，除了有一次把水泼键盘上了，以为完了，结果放了一天又自己好了，从此稳定用了好几年。

一朋友年轻时不懂事，买了 kinesis，然后疯狂码代码，手指受伤了，遂退烧。。。

无意引战，目前在 web 开发领域 go 还是没法和 java 相比，如果你是那种完全不写测试的人，认为自己写的代码都可以手工测试或者不需要测试，那你用什么语言其实都没有区别，java 语言提供的动态性以及 jvm 的 jit 和一系列的运行时优化，都使得一是做 di 非常简单快速并有庞大的库帮助你在十几分钟内构建完善的单元测试流程，二是 jit 的优化，在一些 critical path 上的性能可以达到非常高的水平。在开发关键大型系统时，良好的测试覆盖可以有效减少 bug。

一些人总是提出直接 go 是直接机器码运行，比 java 快，其实不全对，没有 jit 加持的 java 确实性能很差，go 的方式是通过确定性的机器码的运行方式，使得性能是可预见的，不会出现 java 那种 jit 优化之后性能极速上升的例子，但性能可以维持在比较平稳的状态。

至于配置麻烦的问题，你如果不用 di，那也不需要什么配置，反正我司都是一套 bazel 构建到底，构建也都不用操心。

换语言时，要考虑到方方面面的问题，以及很多问题可选的解决思路，不应该迷失在别人的观点中。

如果你决定转 go 了，那么祝你找到心怡的工作，可以多交流，我也在写 go。