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

[sxszzhrrt]

rt ，不限语言，你觉得最好用的框架和 ORM 是什么？欢迎交流你的想法

[XCFOX]

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

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

[cloudzhou]

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

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

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

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

[Shinpro]

Ruby on Rails

[CloveAndCurrant]

rust 的 sea-orm

[mryaocom]

odoo

[liuliuliuliu]

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

[XCFOX]

@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 。

[ZENGQH]

@hwdq0012 #6 sqlsugar 也不错

[liuliancc]

@K332 #78 第一个太亮眼了

[dragondove]

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

[11ssss]

JPA

[dssxzuxc]

写过 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 框架经验的新手使用，因为在某些方面太过原始了，空白处都得从零编写。

[songjiaxin2008]

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

[zpvip]

@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 的选择是另一种道路：用更少的人力做出同样甚至更强大的系统。

[Meld]

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

[guoooo00oohao]

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

[chesha1]

首先排除 mybatis

[cloudzhou]

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

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

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

[flybluewolf]

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

[Bluecoda]

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

[COW]

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

[Bluecoda]

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

[cloudzhou]

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

Perl -> Java -> Python -> Go

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

[qiumaoyuan]

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

[MoonLin]

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

[cooooler]

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

[tonic]

@niubee1 sqlalchemy

[815979670]

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

[qiumaoyuan]

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

[jchnxu]

@XCFOX #107 谢谢老哥！

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

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

[jchnxu]

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

[randychan]

Eloquent ORM

[2024]

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

[yx1989]

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

[walterggg]

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

[mizuhashi]

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

[hankli]

ktorm

[dcsuibian]

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

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

[seth19960929]

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

[seth19960929]

拉了接口 + 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 次

[james122333]

@seth19960929

你少了 11. 都是垃圾

[seth19960929]

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

[seth19960929]

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

[james122333]

@seth19960929

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

[raphx]

Diesel ，啊哈哈哈哈哈

[zpvip]

@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 入门陡峭, 入门后一马平川. 你如果想开飞机, 不好意思, 要考证, 骑自行车不用考证.

[lesismal]

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

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

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

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

[mizuhashi]

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

[zpvip]

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

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

[MindMindMax]

pony orm

[dcsuibian]

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

[alinwu05]

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

[chesha1]

@zpvip #114 ruby 部署不友好啊，性能最好、生态最广泛的 serverless 是基于 v8 isolate 的，如果用 ruby ，要么用底层有 vm 的 serverless ，要么用厂商定制的运行时，所以用 js 是部署最好的，而且用 ai 开发也很快了。如果说小规模业务不该用 java ，用 ruby 一把梭更快，那 js 比 ruby 还要快

[dddd1919]

don`t bb, show me code

举个 Rails 的例子，数据库用户表 User(id, name, gender)，对应的 ORM 代码声明


新增用户可以一句 User.create(name: "foo", gender:1)
查询名为 foo 的用户可以 User.find_by_name("foo") 或者 User.where(name: "foo")
要删除所有 gender 为 1 的用户可以 User.where(gender: 1).delete

代码简单到会忘记 sql 的存在

[cloudzhou]

@zpvip 瞧瞧你举得这些组件，是要笑掉大牙吗？ json xml 解析，Captcha 生成？这些 tools 拿出来干嘛？什么语言不能做到？？？你找不到更好例子了吗？你对 ror 不大熟悉啊

还有 rucaptcha Captcha Gem for Rails, which generates captcha image by Rust. 在打自己的脸吗？？？
计算机领域别说操作系统内核、数据库、编译器，最起码也要举个中间件来说道

C/C++ 在底层开发依然兼顾，Java 业务领域稳如磐石，Go/Java/Rust 中间件中流砥柱，Python AI 风生水起
而你，我的朋友，依然坚守一个只会开发爽那么一下下的语言

---
你的评论，足见你根本没参与过大型项目开发：

哪个前后端分离、微服务及其他语言框架的 CRUD 不能用 Rails SSR 搞定?
我用 Perl 都能搞定，要用吗

前后端分离的出现是因为要切分任务, 微服务是切分功能, 都是在没有 AI 的情况下, 人的精力和水平有限, 搞不定.
和你说了千百遍，真正复杂的是业务逻辑，语言那点玩意 1 小时理清，AI 还没到理解业务的地步
天哪，2008 年我参与的项目 ALL IN ONE / Server Template Render ，难道要起死回生了？？？

Rails 根本不需要 DI ，因为类加载直接就是常驻内存，controller 类里直接用 model 类和对象，少一大层 ceremony
DI 是为了常驻内存？？？ DI / IOC 的全称是什么？是为了解决什么问题，两者关系是什么？
先不要 google 和问 ai ，你能否回答出来

[Soar360]

C# 中的 NewLife.XCode

[cloudzhou]

@lesismal 你说的是对的，商业验证优先

只是目前开发来说，不管是 Java/RoR/Django ，其开发效率很大取决开发者熟悉程度，尤其有 AI 支持下，那点开发效率差距微不足道，我是强烈建议不要在脚本语言上投入太多了，除非像学习 AI 下去熟悉 Python ，本质是为了 AI

[tangqiu0205]

kotlin + ktorm

[1wlinesperday]

Ent 虽然没有很完善 但是配合拿到做 GraphQL 是很好用的，这个是 Facebook 内部的 Ent 框架的一个仿品，
个人也感觉代码 ORM 生成的路子才是正道啊

[zpvip]

@cloudzhou #155 鸡同鸭讲, 你根本没有听我在说什么. 我在说铲子好用, 你说你挖掘机力气大. 我说锤子好用, 你说你挖掘机力气大. 我说我们进山挖笋了, 你说你挖掘机力气大.

我说挖笋用不着挖掘机, 你说我就会挖笋.

我从来没说过 “DI 是为了常驻内存”。我的意思是，在 Rails 里一启动程序所有的类都已经自动加载好了，controller 类内部可以直接调用 model 类，不用像 Java 那样 package 、import 写一堆裹脚布，更不用小心翼翼搞个 DI 来“合法化”类之间的依赖。Rails 的哲学是 Convention over Configuration ，你关注业务逻辑就行，不用和框架 ceremony 打架。

你说“复杂的是业务逻辑”。对啊，复杂的是业务逻辑，那你还在那折腾层层架构、满世界抽象干嘛？让你把时间用在业务上，而不是写一堆 ceremony 骗自己做了工程化. 现在 AI 来了, 你那些裹脚布代码每次当 context 都是要花钱的, 花钱事小, 关键还占了 Context window 的字数, 现在又怪 AI 理解不了你的业务. 我不知道你用的什么模型, 我用 Cursor + claud 4 sonnet, 有 1 百万 token 的 context window, 我都直接长篇大论然后发送后去喝咖啡, 比如一个复杂带验证的表单, 前端带 hotwire js, 后端 model 连数据库带联查, 包括数据库 migration, 这么多东西, 几分钟后我回来时, 它就写得差不多了, 再 PUA 几轮, 写个测试就完美搞定了.

你的业务有多复杂, 发个例子看看, 你不会是甩给 AI 几个字, 让它 "写个淘宝" 就不管了吧.

世上没有什么万能的, 都是 Trade off, 有利就有弊, 前后端分离, 微服务相对 monolith 同样有利有弊. 所以要分时期, 知道自己做什么, 如果你真是拿屠龙刀打天下的主, 那你应该更清楚什么时候做什么, 就怕你是个在灶台打转的厨子, 天天大汗淋漓拿屠龙刀切土豆还说人家菜刀太菜了.

[cloudzhou]

#157 修正一下，目前脚本语言，JavaScript 值得投入，甚至以后前端、客户端都是 Js 写的

[zpvip]

@chesha1 #153

以前部署要设置服务器环境, 如 capistrano
https://github.com/capistrano/capistrano

我们用的 k8s, Argo CD

现在有了更简单的:
https://kamal-deploy.org

其实就是 docker

部署就是开始要设置一下, 以后都是一个命令, 并没有什么难的

用 Rails 的好处是, Convention over Configuration, 有强共识, 方便合作, 你加入一个新公司, 打开一个 Rails 项目, 马上就能上手. Js 嘛, 网上评价太多了, 我就不多说了.

[ChainLock]

larave

[cabing]

Laravel ，mybatis-plus 都挺好的，比 gorm 好。

[13240284671]

Laravel Eloquent​​ 最强

[dssxzuxc]

@cloudzhou JavaScript 不值得投入，TypeScript 才值得投入，无类型的脚本语言只适合一个人编写，在团队协作上表现太差了，永远无法知道某个人在某个地方施放了什么恐怖的魔法。

[Hanggi]

@zpvip 竟然在 2025 年还能看到有人鼓吹 Rails ，真是非常钦佩。

Rails 很优秀，但是它的优秀其他框架很容易学走，并且超越。
Ruby 语言本身没啥进步，这是令人惋惜的点。
整个 Ruby 生态长期放缓，现在是 Typescript 、Python 、Go 、Rust 的时代。

Rails 很好，但只能说 Rails 更像一个历史的功臣，后浪已经崛起，就让前浪拍死在沙滩上吧

[cloudzhou]

@dssxzuxc 是这意思，只是说 JavaScript 生态本身
RoR 早期的优点，包括约定大于配置等，大多数语言、开发模式都吸收了

[mizuhashi]

@Hanggi js 能做到 rspec 的 let context shared_examples 嗎

[fred649]

没看到有人批评 Django 的 ORM 我就放心了。因为我在使用过程中没有遇到问题，而且上手简单，所以一直在用。

[cloudzhou]

orm 要用的爽，只要支持反射，增加一点语法糖有多大难度，无非解决映射关系足以

这是我自己开发的 orm ，因为我是 sql 爱好者，基本就做了小小一点语法糖，使用如下：
https://gist.github.com/cloudzhou/b2fb266296589f5c599e987c2ed91c12

[ychost]

EF + LINQ 吧

[CodingIran]

@liuliuliuliu 光这段 c#代码还看不出语法有多简洁，用 Swift Vapor Fluent 可以写出类似的：
```swift
var user = try await User.query(on: db)
.filter(\.$age > 18)
.sort(\.$name)
.all()
.first
user.name = "zhangsan"
try await user.save(on: db)
``

[stone981023655]

Java: Jimmer > JPA(hibernate)
Go: Ent > GORM
C#: EF Core
其他没用过了.

[jackleeforce3615]

fastapi

[quan01994]

相对于 EF Core,我更喜欢 linq2db 。

[redvoilin]

@Hanggi 先不说他有没有鼓吹 rails ，“Rails 很优秀，但是它的优秀其他框架很容易学走，并且超越”，举几个例子，哪些超越了？

[fantasy0v0]

我喜欢 JOOQ 这种能更贴近原生写 SQL 的开发体验，不知道有没有其他类似的框架。

[windyboy]

edgedb ?

[TobiahShaw]

room

[cloudzhou]

@fantasy0v0 你看我这里 https://gist.github.com/cloudzhou/b2fb266296589f5c599e987c2ed91c12
如出一辙，只是 JOOQ 做得更细腻

[kiddyu]

喜欢 Active Record 模式的 ORM:
Ruby: Active Record (Rails)
PHP: Eloquent (Laravel)
JS/TS: Sutando

[wangtufly]

@stone981023655 ent 强于 gorm 的原因

[uni]

我现在最爱的语言是 f#

[Oilybear]

只在 go 和 py 比较熟悉
至少 sqlalchemy 比 go 那边的 orm 强真不是一点半点

[vultr]

有喜欢写 sql 的吗？我喜欢直接写 sql ，orm 太难了。