不限语言，你觉得最好用的框架和 ORM 是什么？

@bowencool #74
可以看一下 kysely-codegen ，直接从数据库把表结构以 TypeScript 类型定义的形式拉下来。

https://github.com/RobinBlomberg/kysely-codegen

@zpvip 你要讨论技术呢，我就给你认真讨论；扯别的那就算了
世界上排名 top 的大型互联网公司，别管国内 bbat 还是国外 FAANG ，主流语言都是静态语言
更别提规模大了之后，更多从动态语言转向静态语言

但这些都不是关键，对于大规模项目来说，那点脚本、语法糖带来的快捷，相对项目复杂度不值得一提
举个当前讨论的 orm 话题吧，对于一个大型一点的项目：
1. 出于统一入口需要，我需要把所有访问数据库的地方集中一处，不能散落各处，否则以后重估难道满世界翻代码？
2. 我需要以 lib 方式发布，以便共用和统一维护，最好以方法方式暴露
3. 需要比较直观，比如对应什么 sql 语句，是否合理走了索引等，审计和拦截等

ok ，所以看到了吗，所有的语言，orm 对我来说都是差不多的：
func listXXXByYYY(int yyy) XXXList {}
是的，很有 Java 的影子

要说业务开发，这些脚本语言，真别碰瓷 Spring Boot 以及背后的 DI 、DDD
连一点点挑战的可能都没有

Ruby on Rails

rust 的 sea-orm

odoo

@dragondove #96 我说的是“很丑”不是无法实现，如果你觉得他很“美”那就你说的对

@jchnxu #59

Drizzle, Kysely 和 上一代 ORM 的根本差别是，Drizzle, Kysely 希望在 TypeScript 尽可能舒服地写 SQL ，并提供 TypeScript 的一切功能（类型安全、智能提示）。
Prisma, TypeORM 设计一堆 Repository API: find, create, save... ；而 Drizzle, Kysely 选择完全还原 SQL: selece, insert...。
对于熟悉 SQL 的选手来说，使用 Drizzle, Kysely 读写数据库就像呼吸一样简单；而使用 Prisma, TypeORM 则需要反复查阅文档，不停学习 ORM 自创的 Repository API ，同时把握不住 Repository API 生成的 SQL 语句，对于复杂查询可能最终还是需要放弃 Repository API 使用 Raw SQL 。

@hwdq0012 #6 sqlsugar 也不错

@K332 #78 第一个太亮眼了

@liuliuliuliu 你觉得 EF 的写法和我写的这两种有区别吗？基本连源代码字符串都差不多一样了。

JPA

写过 java 、kotlin 、c#、rust 、typescript ，使用过 30 款以上的 orm (mybatis, mybatis-plus, hibernate, jpa, ktorm, jooq, exposed, dapper, typeorm, prisma, sequelize 等等等等)，对我个人来说 typescript+drizzle 是目前的最优解。
因为近年来全面转向了 typescript ，nodejs 的全部 web 框架也都玩了一遍，我最喜欢 honojs ，elysiajs 也很好，不过不建议没有其他 web 框架经验的新手使用，因为在某些方面太过原始了，空白处都得从零编写。

@1wlinesperday #15 互联网业务，表层面不做联表，处理单表业务感觉挺好用的。

@cloudzhou #102

你举 FAANG 大都用静态语言这一点没错，(Facebook 用 PHP), 但那不是“因为静态语言一定优于动态语言”，而是看 CTO 或创始人用的是什么. 有点像 "今天世界上最先进的运输系统的设计，是由两千年前两匹战马的屁股宽度来决定的".

大公司的发展必然加入形形色色的人, 人多了, 组织架构也会带来更多的技术选择。但真正有几个公司能有成千上万的开发团队，中小公司开几个 VPS 的业务就在东施效颦, 这是完全没必要的.

Rails 在大公司真实案例多了去了：

- GitHub ，最初就是 Rails 单体，支撑过数亿级用户，直到今天核心依然是 Rails 。
- Shopify ，全球电商 SaaS 巨头，业务量之大足以秒杀国内绝大多数 Java 项目，照样用 Rails 单体架构搞定，直到后来业务实在复杂有少量拆分。
- Basecamp 就不说了，人家直接靠 Rails 吃饭，而且能养活一个公司二十年。现在任性直接写 Vanilla JS, 也不 uglify, 也不压缩, 不搞那些 KPI 业务.

你说 ORM 要 `集中入口`, `lib 化`, `方法暴露`，Rails 的 `ActiveRecord` 天然就做到了。

你想把 DB 访问收敛？`Service Object` + `Concern` 分层就行。

审计、拦截？ ActiveSupport callback 直接挂，全局生效。

查看 SQL ？ Rails 的日志本来就打印出来所有 sql ，development 模式下就能清清楚楚看到走没走索引。索引这种事都能拿到台面上讲? 我在跟大一新生聊天吗?

而你们那套 Java DI 、Spring Boot 的套路，那些引以为傲的单一功能原则，解耦, 很多情况下只是自 High ，说白了就是写一大堆配置和样板代码，把简单的问题复杂化, 最后一定会过度工程化, Rails 根本不需要 DI ，因为类加载直接就是常驻内存，controller 类里直接用 model 类和对象，少一大层 ceremony ，不香吗？当然我不排斥适度地解耦, 比如用 Service Object, PORO (Plain Old Ruby Object), 但不要有洁癖.

所谓“统一、可维护”，不是靠框架强迫出来的，而是靠团队 discipline 。Rails 的 Monolith 可以让你把精力放在业务逻辑本身，而不是在造一堆“防止程序员犯错”的样板层。复杂度应该放在业务里解决，而不是放在架构里自嗨。

Spring Boot 确实是大厂的选择，但那只是“企业级官僚组织”的选择, 你们继续沉迷在 接口、DTO 、Service 、Repository 、Factory 的样板代码的海洋吧。Rails 的选择是另一种道路：用更少的人力做出同样甚至更强大的系统。

@dragondove #110 我也感觉你写的和这个层主写的没啥区别，也没懂层主说他写的很美的点在哪里

@zpvip 有什么类似于 nextjs 之余 vercel 的 SAAS 可以快速体验的托管产品么？想尝试一下

首先排除 mybatis

@zpvip 在你发言之前，我就知道你要举 GitHub 、Shopify ，Basecamp 就不说了，是理念的领先，规模太小，GitHub 的话，用你自己的发言来反驳，岂不是刚刚好（而是看 CTO 或创始人用的是什么）
第一，Facebook 早多数用 Hack 系统，其中突出静态化检查等，Hack 可以说是运行 PHP 的环境，类似虚拟机

但凡，但凡，你去了解 GitHub 、Shopify 最近招聘，核心组件都在用 Go 等去重构

我评价一个语言的工业级，习惯是广泛使用的中间件
比如大数据下 Kafka Flink ，运维革命性 Docker K8s 等
很抱歉，没有找到 ror 的影子

@cloudzhou 😊，看看 ruby 这几年的 stack overflow 的排名状况就知道了，他还在吹 Rails 就不知道为啥了。

rails 的 active record 应该无人能出其右吧，用起来最简单，最傻瓜，最贴近自然语言。如果要复杂，也可以结合 Arel 一起用，可以做很复杂的查询。

SQLAlchemy ，我之前写过一个支持十几个主流数据源的测试工具，就用的这个，基本没遇到什么坑

不得不感慨这些举着 js ORM 对比人，用过 rails 的都知道，prisma drizzle 就是半成品。
这里不是说什么工业不工业，只是说 ORM 哪个用起来爽，和工业有什么关系？半成品就是半成品

@flybluewolf 其实我可以说相当喜欢动态语言，我的学习过程是：

Perl -> Java -> Python -> Go

我至今还感受到脚本语言的优美
但是如果让我开发严肃项目，肯定 Java/Go 选一个

@zpvip 其实很多时候理念不同，追到根本上似乎是“扁平化团队还是金字塔团队”的问题：你要的是编码机器还是合格的程序员。两种理念的人最终没法聊到一块去。

@zpvip 好奇你们业务没有小程序和移动端只有 web 页面吗？前后端分离可以很容易复用接口，不分离怎么写移动端 + 小程序呢？

Laravel 的 Eloquent 天下无敌，一个能打的都没有，虽然我现在不写 php 了

@niubee1 sqlalchemy

Yii 的也挺好用，尤其是 where 数组，个人感觉完美贯彻了 PHP 的精髓，可以用数组构建出任意复杂的 SQL 条件

@MoonLin Rails 也天生支持前后端分离，无非就是 Controller 在向客户端渲染结果的时候选择渲染 HTML 还是 XML 、JSON 。Rails 甚至有个纯 API 模式，可以专门建一个纯 API 的项目。所以前后端分离对 Rails 来说不是个“做不做得到”的问题，主要是个人/团队的选择吧。Rails 社区可能有自己主流的，或者官方推荐的选项，但不限制你选择其它选项。

@XCFOX #107 谢谢老哥！

我看了一下，感觉其实 drizzle 的做法就是类似 zod ，我的理解对吗？从这个角度来说确实是 typescript native 的，而 prisma 这种本质上和 mybatis 写 xml 然后生成文件是没区别的。

不过 drizzle 这么搞，那也就意味着只能 ts 用了。其他的 feature ，edge friendly 和 speed 我看了一下感觉都挺 promising 的。如果生态和入手文档能起来那确实像你说的应该就是第一梯队了。

@XCFOX #98 这是实话。。我就印象中手写了好多 sequalize typing

Eloquent ORM

@niubiman #76 虽然我也有用 C#，但是对比而言真没有 php 好用，你说的无非是语言集成查询统一了函数签名而已，这些在 SDK 层也能对齐的，但是其他语言都没有 C#这么统一，但是功能是接近的，C#的问题是可观测性，没有 laravel 的集成高和好用。哪怕 go 很诟病 orm 太简单，但是配置代码生成也是很接近的 C#的； 但是 php 的语言层的动态特征配合起来的 ORM 真的强

@zpvip 这么好用看的我好想学一下

@isSamle 已经用了一年的 Django ，觉得它对不懂编程的人来说比较友好，我到现在也不懂什么是前后端分离，也不会写一条 sql 语句

@qiumaoyuan 其實 activerecord 有個很重要的優點沒人說，model persisted 和沒 persisted 有一樣的接口，可以被同一套業務代碼操作

ktorm

@zpvip
你举得这几个例子，Java 高并发不是随随便便吊打
说了这么多，结果没人用就已经证明他不怎么样了
大家又不是傻子，好用的东西早就有人用了，真以为众人皆醉你独醒啊？

自嗨的骗骗自己就得了。一个排名 20 名开外的编程语言都不够上桌吃饭的

叠甲，
FastAPI(SQL Model) 方法设计太奇怪， 重复名字太多
GORM(gen) 生成的模型使用起来很不错，使用起来也挺好， 缺点就是写测试不方便
GoFrame(dao) 手感写起来最舒服， 但是关联关系写起来不舒服
Flutter （ Floor ） 有些残废写起来
Laravel (Eloquent) 真神， 不过嵌套 repository 的玩花了

拉了接口 + GPT 分析了一下， 现在战果如下：
1. ​​Ruby on Rails - ActiveRecord​​: 18 次
2. ​​PHP - Laravel Eloquent​​: 12 次
3. C# - Entity Framework (EF)​​: 9 次
4. ​​TypeScript - Drizzle​​: 6 次
5. Python - SQLAlchemy​​: 5 次
6. ​​Java - MyBatis/MyBatis-Plus​​: 4 次
7. TypeScript - Prisma​​: 4 次
8. ​​Java - Spring JPA/Hibernate​​: 3 次
9. ​​Kotlin - Ktorm/Jimmer​​: 3 次
10. ​PHP - Yii2 ORM​​: 2 次

@seth19960929

你少了 11. 都是垃圾

印象里 created_at ，updated_at 这个就是从 ActiveRecord 来的， 这是一件很好的事， 我去看了一下 ActiveRecord 的代码， 很难相信这是 2025 的语法， 太让人难以理解了
https://guides.rubyonrails.org/active_record_basics.html#crud-reading-and-writing-data

@james122333 上热门看看， 统计有多少

@seth19960929

我觉得我加上的都是一个选项

Diesel ，啊哈哈哈哈哈

@cloudzhou #118
但凡，但凡，你去了解 GitHub 、Shopify 最近招聘，核心组件都在用 Go 等去重构
---------------------------------------------------------------------------------------------------
Github 我不知道他们是不是在用 go, 招聘的说明里, 含有各种语言, ruby, go, python, rust, c.
https://www.github.careers/careers-home

Shopify 根本没看到 go
https://www.shopify.com/careers/disciplines/engineering-data

就算用 go 也没问题啊, 如果一项工作涉及密集计算, Ruby/Rails 的做法就是单独开发一个 gem, Ruby 的 gem 本来就可以用 C/C++, Rust, go 开发, Ruby 只做 Ruby 该做的事.

例:
https://github.com/sparklemotion/nokogiri
https://github.com/ohler55/oj
https://github.com/huacnlee/rucaptcha

我评价一个语言的工业级, 习惯是广泛使用的中间件
比如大数据下 Kafka Flink ，运维革命性 Docker K8s 等
很抱歉，没有找到 ror 的影子
---------------------------------------------------------------------------------------------------
你是谁? 你评价工业级? Shopify 处理的是全球几百万商户的电商交易，GMV 千亿美金量级； Github 世界级的交友平台, 这不叫工业级，还要什么叫工业级？ Kafka 、Flink 、K8s 这些项目多是系统级、分布式基础设施，天然会选择 Go/Java 这类静态编译语言。但这并不说明 Ruby/Rails 不是工业级，而是 Rails 专注点在业务开发，CRUD, 而非造分布式中间件。

Kafka 、Flink 解决的是分布式系统的问题； Rails 解决的是应用交付的问题。Rails 在 Shopify 、GitHub 这种量级上的实践，早就证明它的工业级价值。你拿高铁去耕田吗? 拖拉机不香吗?

==================================================

我的核心观点是, 不是说 Ruby/Rails 多牛, 能搞定 Github 和 Shopify 这种大网站, 恰恰相反, 我的意思是, 99%的网站都达不到 Github 和 Shopify 的级别, 就开始焦虑大雁是蒸着吃还是煮着吃, 你先快点射下来再说啊, 大雁都飞走了, 你还在那折腾 DI, Servcie, Interface, 跟前端讨论返回 String 还是 Array, 还在 diss Microservice 团队没给你准备好支付队列.

我提到的 IoT 平台开发已经算是一个中大型应用了, 我们用了 K8s, Argo CD 动态调整 Rails 服务器数量, 同时启动了几个 Sidekiq 分布式队列做数据入库, 还有 Redis 做缓存, 服务器常年压力在 10% - 30%, Ruby 性能是差, 但服务器便宜啊, 内存白菜价啊.

说回原话题, 从 ORM 的角度, Active Record 用了 Ruby 的元编程, 极其优雅, 做到了零样板代码, model 自动生成, 代码极简:
class User < ApplicationRecord
end

然后就你在全网站内不用声明, 不用引用, 就可以随便写:
User.find(1)
User.where(name: "Alice")
User.find_by_name("Alice")
user = User.find_by_email("[email protected]")
user.save
user.update(email: "...")
user.destroy

model 里面也是元编程, 把数据库关系和校验逻辑变成声明式语法，开发者写起来就像在说人话。
class User < ApplicationRecord
has_many :articles
validates :email, presence: true, uniqueness: true
end

Active Record 背后的哲学就是 Convention over Configuration 。不用写映射文件, 不用手动指定列到属性的映射。

最后给大家泼一下冷水, Ruby 学校没教, 要自学, 考验自学能力, Rails 入门陡峭, 入门后一马平川. 你如果想开飞机, 不好意思, 要考证, 骑自行车不用考证.

@zpvip @cloudzhou github 的用户群体、在线和并发对应的业务类型的技术需求特点是：重存储，cpu 消耗不是最优先（相比于其他大社交、电商、搜索、多媒体之类的大厂），所以确实不是好例子。FB 的 PHP 跟阿里当年 LAMP 后来搞 Java 和去 IOE 都是一个道理。

多数团队当下的技术选型是商业目的优先（如果都能做，选个技术团队熟悉的），做起来之后再根据可行性尽量去换更好的，这些道理，与新结婚买小婚房、有钱了再买改善房，或者日常折腾各种升级升配的电子产品车子玩具，没什么区别。
所以，当初选的，如果只考虑技术角度，并不能代表就是最好的。

对性能、透明性之类的没有什么要求的团队，用 ORM 方便就行，有这方面要求的团队对 ORM 的态度基本都是禁止的。

我个人对所有语言的 ORM 的态度都是星爷电影里大师兄的名句：我不是针对谁，在座的全是垃圾。

@dcsuibian 啊哈哈 我倒是覺得語言的排名看薪資比較有意義，多不多人用好像無所謂 https://survey.stackoverflow.co/2023/#section-top-paying-technologies-top-paying-technologies

@lesismal 在射大雁这件事上, 我相信 Rails 在网站开发方面是最快梯队的, 以前来说, 手写代码量也是最少的, 代码少 Bugs 也少, 不写代码就没有 Bug :) 现在加上 AI, 我几乎都是用 Cursor 写提示词 + PUA Claude-4, Rails 代码量少就可以省 token, 也就是省钱省时间, 把 Java 那堆裹脚布放到上下文, 慢不说, 钱包要受更大的伤害了.

"在座的全是垃圾" 这句话没问题, 薯条也是垃圾食品中的战斗机, 但全世界都爱吃. 尊重你这种这手搓 SQL, 时间大把的极客, 那, 做人呢, 开心最重要了.

pony orm

@mizuhashi 这个不好说，真这样的话 Zig 就是最好的语言了
进入这个排行榜至少得是找到了工作吧。以就业来看的话，粥多僧也多，粥少粥也少。所以没有如果不能确认两者的比例，我一般不讨论这个，说不好的
我觉得看一个语言值不值得学，得看是否有持续的新鲜血液注入。如果新的程序员不学了，连培训班都不愿意教了，那多半也就没啥生命力了。

Yii2 自带的 active record, 太好用了，复刻 Rails