重新思考数据库编程

总体反响

• 许多人觉得这门新的函数式查询语言在审美上很吸引人，在概念上也很令人兴奋，尤其是函数式编程和类似 Elm 设计的爱好者。
• 另一些人则认为，它只是把简洁的 SQL 变成了更冗长、可读性更差的代码，并怀疑它相较于原生 SQL 或现有工具并没有带来足够的收益。
• 还有不少评论指出，在 SQL 已经相当成熟、生态完善的情况下，另一种“SQL 替代品”很难获得广泛采用。

SQL vs. 函数式查询语言

• 支持者认为 SQL 显得笨拙、过时、基于字符串，而且难以组合或进行静态分析；他们希望使用流水线、类似 map/filter 的组合方式，以及端到端类型检查。
• SQL 的维护者强调它的数学基础（关系代数）、成熟度、强大特性（CTE、窗口函数）以及无处不在的地位，包括对非程序员也相对友好。
• 有人指出 SQL 与纯关系理论之间存在偏离（多重集语义、NULL），但仍认为它是进行数据存储和查询的正确工具。

ORM、模式管理与表达能力

• 争论的焦点之一是这是不是“披着 ORM 外衣的东西”。从用户角度看，很多人说它的行为很像 ORM，尽管宣传上并非如此。
• 对“把模式写进代码”的 ORM 式方案的批评者认为，这类层会落后于数据库特性（分区、压缩、高级约束），最终还是会被迫回到 SQL。
• 另一些人更偏好把 SQL 作为事实来源，并从中生成类型化绑定的方案。

类型安全与前后端集成

• 支持者强调从数据库到后端再到前端的端到端类型安全，包括 sum type 和可复用流水线，这是一个重要的附加价值。
• 怀疑者反驳说，SQL 本身就是强类型的（SQLite 之类的引擎除外），而且通过代码生成和“describe”机制也可以实现跨层类型安全。

数据库所有权、架构与长期可用性

• 有些人担心由某种语言“拥有”数据库，尤其是使用自定义编码（例如用于 sum type）会让互操作性和长期数据访问变得复杂。
• 不少人强调，数据库和 SQL 模式往往会比任何特定应用或语言活得更久；他们更希望数据库作为稳定中心，而不是编译目标。
• 也有人怀疑，把数据表示紧密绑定到一种封闭、细分的小众语言，对于长期运行的系统是否明智。

许可、融资模式与信任

• 闭源、订阅制的许可引发了很大担忧。引用的一条条款暗示订阅到期后用户可能失去对数据的访问权，很多人认为这对关键系统来说不可接受。
• 过去类似项目的经历让多位评论者担心“bus factor”和长期维护问题；依赖单一小团队被视为风险很高。
• 也有人欢迎为可持续开发探索新的融资模式，但仍然不会在专业项目甚至个人项目中采用它，因为风险太大。

替代方案与前人工作

• 评论者指出，类似思路此前已有不少尝试：LINQ、Haskell 库如 Selda、基于 Datalog 的系统、SQL 代码生成器（例如 sqlc、Ormin）以及其他“数据库编程语言”。
• 有经验的实践者认为，几十年来在数据库集成语言和 ORM 上的尝试，大多没能胜过“直接用 SQL + 驱动”，尤其是在性能和透明度方面。

可用性、文档与未解问题

• 人们希望看到更复杂的多表连接示例，以及分组/聚合是如何表达的，因为简单示例并不具有说服力。
• 一些人对强制行级安全和代数数据类型等特性很感兴趣，但觉得语法乍看之下不太容易阅读。
• 文档被形容为偏薄弱（例如提到了某些关键字，却没有充分解释），这让人很难深入评估这个系统。
• 目前仍不清楚这门语言对 PostgreSQL/SQLite 全部能力的暴露程度如何，以及迁移和模式演进（尤其是高级类型）在实践中是如何处理的。