#9 说的才是真理，其实要看是要解决问题还是切一块资源。

看自己情况，公司资源丰富的话夸大一点，多争取点资源练手也行。不过建议不要上 hadoop 的船，淘汰了的玩意。

这么一点点数据，duckdb 还没热身。或者存成 Parquet 文件，爱用啥用啥。

感觉区块链不大行了，ipfs 更是上一代的叙事，资本始终在追逐新的叙事，ipfs 成没什么故事的基建了。

如果是我可能守着，只要不马上砍应该能赚回大礼包的钱。

只见过 1 个项目实际用上了，做数据分析做社交图谱。

还没用过，额，10 年开发。

如果能支持桌面端 App 的话，能覆盖我 90% 需求了，在支持桌面端软件之前免谈。

感觉先去掉一个 CPU 试试

C 的生态位目前看还是不可撼动，但是 C++ 的生态位在被 Rust/Go 蚕食，性能不敏感的上 Go ，敏感的 Rust 。

和老的 gateway 没有区别。

别试了，还是老一套，两个撕裂的环境，不同操作系统字体都不一样。

被 vscode 打的找不到北了吧，vscode 那个远程真的是无缝体验。如果能达到 vscode 的水平，我应该会继续付费。

web 框架说白了就是在处理 res 和 req 和它们加入中间件（要不就是过滤器模式要不洋葱圈），用多了就会感觉一个样。所有语言只要是处理 http 的都是近似设计。

不同的场景按需选择就好。不同的语言有不同的生态和利弊。

我最开始工作是纯 sql 然后在我工作第 2-3 年的时候我喜欢用 sql-builder ，工作第 5 年的时候我用 orm ，工作第 8 年的时候我喜欢各种 sql-builder ，现在我几乎回到了纯 sql ，只是加一些模板工具方便写 sql 。

请注意，我们在说 orm 的时候，涉及到 3 个 概念。

orm：类似 java 的 hibernate ，jpa 。php 的 Eloquent ORM ，rust 的 sea-orm ，这层讲究的是对象关系映射，把表结构映射到对象上，完全隐藏 sql 等概念。

sql-builder: 类似 java 的 mybatis ，js/ts 的 kysely 或 knex ，rust 的 sea-query ，这层讲究的是辅助更好的写 sql ，组装 sql 。并处理数据到对象的映射。并不隐藏 sql 概念，只是辅助。

sql-driver: 类似 java 的 odbc ，js/ts 的 node-pg 等，rust 的 sqlx ，这层讲究的是驱动，连接等底层，纯 sql 。 不处理映射等或者简单映射。

各有利弊，按需选择。不同层级的不要一起比较。

啥业务能跑到 springboot 的性能问题，能到上限招人加机器不成问题。

go 写业务也不合适啊，不照样一堆后端业务拿 go 写。

rust 写 web 优势我个人觉得就是性能+可靠吧，糊业务现在用 js/ts 更爽。