go 可以，容易上手，做 API 服务很合适，你看看这个 https://opencat.app/docs/zh-CN/opencat-for-team API 后端就是 go 写的。

@leimao initializer_list 不放个数，表示调用默认构造。

赶上末班车

分母

618 新攒的：
CPU: i9-9900kf
主板：华硕 m11h
显卡：2080super
RAM：64G
硬盘：1 个三星 970 EVO Plus 1TB, 2 个西数 m.2 1T

@jaleo 买个转接卡，可以插 PCIE 上

已下单，这个价格很香！

@lbp0200 看了下这个支持的数据结构也有限，我们已经支持 zset, list, hash 等，还有 ttl 过期等。

@lbp0200 跟这个架构类似的（持久化 kv，redis 接口，强一致），我们目前已经有一套系统在线上跑着了。

@zoe1016aaa 哈哈，加上股票应该差不多（近期股价还行的）。

@kuro1 轻量级使用应该很好。大规模和密集使用下持保守态度，另外 KV 分离导致的 value log gc 资源占用也比较不太可控。

@wellsc 同感，只是目前团队对 C++熟悉的人多。

@wellsc 以我以前大量使用 goleveldb 的经验来看，是这样的，存储引擎 C++还是有优势的。
go 在海量小对象时 gc 的问题比较大，其他像服务质量的稳定性、可调优空间等 C++也有优势。

@lbp0200 暂时没有开源计划，欢迎大佬投递简历👏

@lbp0200 badger 主要思路应该是 kv 分离，大 value 下表现会好一些。
rocksdb 下也有类似方案的。kv 分离方案也有自己的缺陷（范围查询、读时多一跳）

早已弃用，虽然会员还剩几年

感觉不错

这类游戏数字版更好，不然得频繁换卡带。我就是受不了这点，专门又在任天堂官网买了数字版，导致手里有两套。