@MeatIndustry 感兴趣就应该去做，不辜负这个时代！面试没有做题：）主要取决于你的经历，所以问的问题会不一样。

@nagatoism 我们想要做与这个时代相匹配的顶级性能。我们还有一个引擎在这[1]，ClickHouse 的 lead Alex 贡献了第一个 PR, 我想 Alex 是认可 TensorBase 的工作的。只是当我们最近 pivot 到 Arrow+DataFusion 引擎后，高性能的引擎比较复杂，现在暂时 break 中，未来修复后会渐进开源。

对于你说的 datafuse，我自己的理解，他们是 Arrow+定制执行引擎，我们是 Arrow+DataFusion 。他们的定制执行引擎，我个人认为在架构上和 DataFusion，乃至和之前的很多开源大数据执行引擎相比，区别不大。未来可以看看真实数据集的评测结果。另外，他们还在做执行引擎阶段，我们已经接近 TPC-H 的完整流程（本来五一就能完成，我把几个简单功能打包到一个五一长假贡献者活动中，希望大家能体验，不过目前只有一位外国小哥参加...）。


[1] https://github.com/tensorbase/tensorbase_frontier_edition

@1499402309 你的想法其实很没有问题。每周一天如果从工作角度是过短的，但不影响做点事情，其实很多开源项目做事情正是你的这种模式，我们是一个开源项目，所以随时欢迎你到项目里寻找有趣的方面并做点事情，很高兴为你提供可以提供的任何帮助！ Let's rock :clap:

@monkeyNik 误会：）我留一些信息供大家参考，同时顶顶贴，哈哈：）

@junglereal1 好问题。其实项目页面上有写，再简化一下就是：简单高效。这个目标，说起来容易做起来难。举一个我昨晚的例子，从终端用户看，什么是简单：花 5 分钟把自己的一台 Windows 10 Home 笔记本装上了 wsl2[1]，花 2 分钟把 TensorBase 下载，解压进入 bash 命令行，就可以按项目的 1 分钟动图 demo 操作了（懂 SQL 的话几乎不需要学习）[2]。你说的这几个产品，都做不到这一点。高效是一个更大的话题，多高是高效？ TensorBase 正想回答这个问题，我在项目的网站留下了一些信息，我等的就是对这个问题有兴趣的“一群人”！


[1] https://docs.microsoft.com/en-us/windows/wsl/install-win10#manual-installation-steps
[2] https://github.com/tensorbase/tensorbase/blob/main/docs/get_started_users.md

@monkeyNik Linux 社区，好：） Rust 即将进入（ Linux ） Kernel，顶级 C 程序员 Linus 对 Rust 也是拭目以待（ wait and see ），C 程序员真可以对 Rust 感点兴趣：）

@monkeyNik 总结的挺好的。系统调用还是调用到系统的逻辑：）如果系统不安全，理论上整个成品还是不安全的。其实 Rust 的标准库也有大量 unsafe 代码，其安全性是由编码人所决定。但从语言层面看，安全性增强还是确定的。如果发散一点，这是个“依靠人还是依靠机制”的问题。放眼看一个大的开源工程，有很多人贡献代码，对贡献者的基本功，应该有怎样的要求好呢？：）

@byteli 谢谢，v2 现在人少啊

@francisdu 是：）奇博士就是我们的合伙人！

@monkeyNik 你这种方案是否是强制转换？技术上成立，但不安全，不安全就是工程上的缺陷。

@monkeyNik ：） C 上的一些工作很赞！即便是现代，C 其实也还是有空间的，可以控制范围使用。但在大型工程来说，还是有些缺陷，比如范型 /模板的需求：你这个 mln_hash 的 api 是作用在指针上，但对于基本类型，这个效率就低了，怎么办，回到老办法...

@mnssbe 是的：）不过我这已经可以不用“用爱发电”，快闪活动主要是针对假期想充充电、玩玩票的同学。对于有兴趣真想做一个数据仓库的同学，[点这里]( https://www.v2ex.com/t/774674)，we are hiring!

@contractswif 太欢迎，这么多年、这么多语言用下来，其实 Rust 最棒的还是社区

@ltoddy 比 Rust 语言层的所谓 async 快，是很有可能的。现在 Rust 的 async 默认似乎是 thread local （不同版本可能有不同），对于大规模的 bench 肯定是不适合的，你需要调优。

但你现在这种同步式比真正高性能意义上的“异步”，那肯定是弱鸡的。

原因很简单，同步式调用在消息没返回之前线程时间片是浪费的，增加线程不改变这一点。这也和 CSP 无关，你 socket 读写是系统调用，任何用户态机制下，你这调用都必须浪费。CSP 和 coro/generator/future 本质是等价的，所以 CSP 并不会比 async 高明，且 Rust 不（完全）支持尾递归优化，写成 CSP 性能可能更弱。简单说，简单多线程效率比真正利用系统 /驱动层的异步机制效率至少差量级以上。我最近写 server，techmpower 的 plaintext 测试单机都是每秒一千万 request[1]，但 http 比 redis 说复杂 100 倍还是有的。

你可以把你的多线程+CSP 代码放出，我和你细品一下，当然时间是个问题，我们可以慢慢细品。

分析的挺对的。说到语言必然会引战，就像今天的 HN 某热帖[1]。

我认为 Rust 的定位决定了其确实难以取悦所有人。大会时我正巧和一位 hw 的工程师谈到这个问题，我说我其实还挺喜欢 Java 的，内核很简单，但稍加学习你也能写出较快的系统（如你说所），如果快速开发上层业务系统，我还是建议 Java 。但和 C/C++/Rust 这类系统语言比，Java 语言的性能上界是明显的，jni 和 jna 都是 work around，如果大量采用和直接基于 native 语言构建系统并无太多区别，这个在大系统中看就能有比较明显的展示（小系统不否认有可能只在关键路径上解决速度问题即可），这也是 Spark 为什么在这么多年高性能改进后，还要内部用 C++搞一个引擎的原因。

其他的不敢多谈，一定会引战：）


[1] [Rust is now overall faster than C in benchmarks]( https://news.ycombinator.com/item?id=25623634)

@jinmingjian 忘了一点，“听说很难写的”的小伙伴都是来自其他领域来大会看看（比如 C++），上船了的小伙伴都说香，哈哈

@jinsongzhao 乐见好的评估结果：） orm 如果是指 object-relational mapping，这个是和 jdbc 不同的层次，更偏应用。但 orm 是两面性比较强的，我个人建议是不要用（在那个 Eclipse 时代，我用过太多 EMF/JPA 组合，不知道现在 Java 的 ORM 是谁家天下）。Rust 至少能做到 ODBC 所做的，跨平台的考量应该不是太大问题，当然数据库驱动问题我没有特别了解。

@victor 同意，单从用词来说，是有点装的：）我用在这里，主要是想说，我们做一些项目如果能帮助广泛的开发者或者人群，那么它的价值就会凸显，就比如是各种工业改变了普通人的生活。但再比如一个 http 库搞个 10 个、100 个，我觉得有点浪费。

@felixin 有点吧：）我从本次大会上看，对语言的反映是两极，有人是你这么说的，有人觉得特别好，因为不让你乱搞，他们说特别适合工程。绝对的自由带来绝对的混乱，通常还是有点控制比较好，哈哈。