原来也没有啊（逃

@cabing 读别人的 Ruby 还不一定有读汇编来得轻松（逃

我好像就是 LZ 眼里的那种鄙视前端组的后端。
但原因是之前我们前端组的 Leader 水平实在太差了，将熊熊一窝。需求改来改去都是小事，经常自相矛盾。

不过我不觉得重视界面设计是 SB 行为，我也觉得我们的前端界面设计水平太 SB 。所以应该跟 LZ 不一个公司:doge

综合考虑其他条件。比如钱多不多，长期看能不能搞走他等等。
如果还成，那就你说对就对。
如果不成，那就我想怼就怼。

一句话：听说 go 的协程挺不错。

然后学过后觉得……作为 C 的应用软件开发侧的增强算是合格的，但也就仅此而已，目前 go 的工程能力还是有欠缺。

上海没有雾霾（逃

这个大概率不是语句的问题，而是数据分布的问题。
cityId 通常是一个百到千级的数据集，而且分布上往往集中于特定的小几十个 key 下。user 表 LZ 说是百万级，那么相比下这个索引的效果本身就很有限。在分布较为平均的情况下预期查出数据都是 cityId 数 × 10000 级别的。再加上后边 delete_time 判 null 必须遍历，根据 id 倒排又是大概率不被优化直接遍历，不慢才是怪事。

user_info 的 city_id……索引失效概率不低。

这个量一般确实是扛得住的，只要机器不太磕碜。
zrange 方案直观上会觉得很奇怪，因为最大可能你通过时间来取 key，然后你的场景下似乎大量 key 会集中在某个区间内。这就要求你能吃掉自己造出来的峰。
定时任务算是常规方案，它属于慢但是不会有什么坑的选择。特别你担心的是持久化问题，而用数据库做持久化则是最不用担心的。

可惜在北京

做欧美市场

[1, 0, 1] --> [x, 1, y]

支持函数指针 /高阶函数的理论上都能做 FP，无非方便程度的差距
golang 写 fp 的短板主要是它是强类型语言但类型系统又不够强。这本身也并不阻碍做 fp，但是别的 fp 语言或者有泛型，或者有类型推断，或者有偏特化，相比下 go 就显得不那么适合了。

提离职

微服务任何意义上都算不上 DDD 的实践。
微服务的出发点是方便系统的迭代（改需求）和在整体层面增加稳定性。
DDD 的出发点是扫除业务需求和代码实现再到具体实施之间的障碍。

虽然有人说微服务的划分借鉴了 DDD 的上下文边界概念，这只能到有相似的地方。但你不能说 C 语言和英语都用拉丁字母所以 C 语言是英语的实践。

以及 DDD 不一定需要“独立”的领域专家，也不一定非要用于复杂业务系统。

@zanelee 是的。

当然有用，防痴呆。
除了面使用，如果做中间件、游戏开发也经常会用到。