@pocketz Idea New UI ，配色是 New Dark ，字体是 Fire Code

文本版，https://gist.github.com/mingyang91/578747e27d0d68553f66ff60405a8827

先帮你等价替换一版，Stream API 其实写起来很漂亮的，只要改换一下思路就好了。
https://i.imgur.com/YqUnElB.png

列举一下我老婆的喜好，仅供参考
鲜花，越大越好（关系没到那份上的话可以从小的送起）
首饰（纯银也不贵，或者其他漂亮手工艺品）
仪式感（包括但不限于气球灯带蛋糕氛围灯等等）

我又问了一下我老婆对于电子表白的看法，答案和我一致：土

建议买实体礼物，电子表白真的土，大学时候写过表白程序，纯粹感动自己

数了一下工作十年以来，正儿八经做过生产项目的语言有以下这些：

万行以上经验的语言
Scala 、TypeScript(含 JavaScript)、Kotlin 、Java 、PHP 、C#、VB
千行以上经验的语言
Rust 、Python 、Swift 、Racket(含 Scheme)、C++(含 C)

我也认同程序员不应该和语言绑定在一起，假如哪天需要我去写 Haskell ，我也很乐意，毕竟学起来也不难。但要是让我去写 Java 、Go ，不给个 50%以上涨幅我不是很乐意去干

All in hooks ✅

@wxf666 可以有递归，但是它这个文法里数组没有起止符，会和其他规则有冲突，如果是写标准 JSON parser 的话，代码能比这还少。
最妖孽的就是他给的这个 options

我写了一堆电子垃圾，勉强能解析但应该无法适应更多情况了，建议批判就行，别学
面对这种数据格式，我建议打爆数据上游的狗头，让它改成标准 JSON 输出

@wxf666

https://gist.github.com/mingyang91/06f4a489c313a16b9285dd375a565808

我的 Scala 应用基本上都是每次链式调用求值一次列表，也没比别人 Java 少快几倍。

而且 JS 有 VM + GC ，除非你跑过 perf 确认这里有性能瓶颈，不然我建议你不要瞎优化，可能适得其反。因为 Lazy evaluation 也是有 overhead 的，数据量小了不如立即求值。

如果数据量真的大到有必要实施 lazy evaluation 的程度，那我也建议一步到位 RxJS

如果这东西生成有规律，建议一步到位写 parser

这不就是 Rust/Haskell 嘛
当然 Scala 里也可以很轻松实现仅用 static (object method) ，typeclass 风格
理论上在 Java 中只用 static 方法也是可行的，相当于你手动展开 typeclass 调用而已，自己一个人的项目随便怎么玩都行

@zed1018 JVM 但是无 Spring ，我是 Scala 😏

https://www.mongodb.com/basics/mongodb-auto-increment
文档里给了一种新开一个 counters collection 的方案，来模拟 rdbms 提供的 sequence ，可以参考

Redis 开 AOF 持久化可以满足要求，只开 RDB 的话可能会造成生成重复 ID 。
但是 AOF 可能对性能影响大，建议放弃 Redis 方案

盲狗递币上没了解过，我说下我在 postgres 上的经验
PostgreSQL 有个函数可以直接用，SELECT nextval( seq_name );
就可以拿到全局唯一的自增序列号。

你这个场景需要考虑两个问题
1. 多实例并行拿 ID 怎么解决
2. 错误重启怎么恢复

单线程是解决不了问题的，考虑到你将来可能部署多个 webflux 进程 /容器做水平扩展。同时服务崩溃后重启的时候计数不能忘了从头开始吧。
盲狗递币可能可以通过触发器或其他手段达成类似效果？这需要懂行的来贴一下文档了

@shilianmlxg @qinggge 我看的原版 Scheme 版，毕竟 JS 师从 Scheme ，不需要 C 语言基础。倒不如说学 SICP 之前应该先忘了 C 语言

Brendan Eich was originally going to embed Scheme into Netscape. But higher-ups said no, it has to be familiar and resemble popular languages like Java to get any traction. (They were right.) So Eich went in and threw something together over a few days, and boom -- JavaScript.

推荐一本 JS 入门教材，补内功专用，这本书帮我收入翻了十倍
《 SICP 》（认真的

你的数据量级我建议直接 count ，除非后面加个万字

我也遇到了类似的场景，需要统计客户在我们平台存放了多少数据，我们是多租户 SaaS 软件。不同租户一般几千到几千万不等，冷热分区明显。根据我的场景我试用了如下方案

1. 行数存单独的表，根据事件消息异步更新行数，这个方案必然会产生不一致，解决方案是每日一点重算昨日新增数据。
2. 客户查询时，优先使用 pg estimate 估算，总行数一万以下走 count ，行数一万以上返回行数表 sum 数值

在我的场景下，客户对数据量个位数增减敏感，但是对数据总量差 1%~10%并不敏感，所以保证最终一致性就足够了，每日校正一遍