喜闻乐见。

促进就业和社会安定，吸收阿里向社会提供的人才

从你们选择 java 开始，结果就已经注定了

这是微服务的问题吧，阿里带的好头

做微服务架构后，拆分成 5-6 个领域，一个团队 4-5 个 java 程序员

感觉拆分后沟通成本就暴增了几倍，可能原来一个人能搞定的事，变成要沟通完五六个人才能搞

发人深省 🤔

挺好的

大厂创造工作岗位

创业团队又有生产力

手下人多，跟着 Tilte 也得升，多赢。

感觉是老板被技术 leader 忽悠瘸了

“中台，我信了你的邪” https://36kr.com/p/1725013082113

希望看到后续进展……

问一下，如果用 java 重写，但是不搞微服务，不搞中台化，会不会好很多？

感觉像讲故事，最近用 spring boot 做了一个小项目，在 idea 强大的智能完成加持下，感觉也不比 rails 效率低多少，但静态语言带来的安全感让写代码的心智负担降低很多

哈哈哈，理想与现实。

楼主有没有信心做 rubychina 的第一个连载贴

这不是经常性见到的笑话么。。。功都花在了非解决实际问题的问题上

这个会不会太夸张了啊，

你谈到了“小”，小项目用什么都问题不大

小项目都能感受到 spring boot 的方便，大项目更不用说了，显然静态语言占优势。

估计就是脚手架之类的。。。ror 的脚手架，都没人在生产环境用。。。java 生成一坨，更没法看了。。。

有的人认为 java 开发 web 更高效，比 ror 高效。但如果真问他们一个具体问题怎么处理，他们会说，spring boot 是解决依赖的，不解决这个。。。然后他们依然觉得 java 更适合开发 web。。。

反正就是不跟你说具体问题。。。

既然 java、spring 这么棒。

写个分页查询吧，再写一下，如果解决 n + 1 问题吧。

用什么 orm 都行。

rails 适合编辑器党，作为 ide 党的我，每次用 rubymine 开发 rails 的时候真的很无力，虽然大 JB 家的 IDE 已经非常智能了，对 rails 的智能提醒还是半残废，遇到元编程更没辙。

而用 idea 开发 spring 程序，智能提醒接近 100% 的准确率，简直太爽了，写程序就像做填空题，并且填错了 IDE 会提示。

能把语句写对这是最基础不过的了。。。写多了还没肌肉记忆非要让 IDE 让你生成这生成那的，这不就是因为语言太啰嗦才需要工具支持么

我一直强调，真正影响生产力的是实现业务时的差异，楼上有人问你了，你把这些最基础的在 Java 上实现一下，再看看 Ruby 上怎么做的，更复杂的业务呢？

一线研发的技能树，尤其是软技能点得更多了

老板地盘变大，没困难创造困难也要上，可以拿高绩效晋升了

对公司来说，如果将来业务量起来，要尝试更多方向，更复杂的打法，可以大量堆人了; u1s1, 这个是 Ruby 的痛点，飞快成长的创业公司，今天是几十人的小作坊，一年以后需要千人的研发团队

我打算把这个命名为打工人的悖论。

既然都用 Java，你不堆人，堆什么，我问你。

这个应用是做什么的啊？电商吗 @u1440247613

Java 如果用 JPA 这类的分页没什么难度，N+1 用 left join 或缓存解决。另外，现在更多是用 MyBatis 之类的手写 SQL 加一些小的插件了

RoR 小而美，Java 系更粗旷一些，项目可以靠人堆，其实没什么可比性，就看注重哪点了

就是最简单的分页就行，既然容易，辛苦给一下代码？

如果用到插件，说一下插件是什么？如果是自己写，贴一下插件的代码？

大家还是拿代码说话。

要 java 代码还不简单么，使用 nutz 后的分页方式查询前 20 个

var shops = dao.query(Shop.class, Cnd.orderBy().desc("shopName"), new Pager(1, 20));

left join 解决 n+1？理论上真的可行，但我不信一个普通开发能解决正确，即使看了你的 profile 来自京东…

如果你说的 n+1 只是最简单的 belons to 类型的那其实没有可比性啊，has nany 类型，nested 类型，agg 类型，如果都考虑，你如果可以 show 一点代码我还真挺佩服的

我们先单独比较一下代码

RoR + kaminari

shops = Shop.page(1).per(20).order('name DESC')

var shops = dao.query(Shop.class, Cnd.orderBy().desc("shopName"), new Pager(1, 20));

另外，除了代码，还要 import 依赖，Dao，Shop，Cnd，Pager。dao 还要 Autowired 一下，这个 "shopName" 最好用一个常量。

另外 var 是 java 11 的语法吧？现在绝大多数都用的是 8 吧？或者你用的是 kotlin？

大哥。。。你import org.nutz.*; 一行话不就可以了么。。。

还有这个 name DESC 最好用一个常量

var 是 Java 10 出来的东西，差 4 个月就是 3 年前的出的版本，难道你写 ruby 现在还在用快 3 年前的版本么

@ywjno 完整的代码我贴出来了，你看看有没有问题？ （根据 https://ruby-china.org/topics/40526#reply-364233 做了更改）

import org.nutz.*;
import xxx.xxx.models.Shop;
import java.util.*;

@Inject // nutz 自带注解，不依赖 spring
Dao dao

List<Shop> shops = dao.query(Shop.class, Cnd.orderBy().desc("shopName"), new Pager(1, 20));

RoR + kaminari

shops = Shop.page(1).per(20).order(shop_name: :DESC)

还有这个 name DESC 最好用一个常量

ruby 用 keyword。

var 是 Java 10 出来的东西，差 4 个月就是 3 年前的出的版本，难道你写 ruby 现在还在用快 3 年前的版本么

工业界，多数的项目，都是用 java 8 吧？ https://www.jrebel.com/blog/2020-java-technology-report

import org.nutz.*;
import xxx.xxx.models.Shop;
import java.util.*;

@Inject // nutz 自带注解，不依赖 spring
Dao dao

List<Shop> shops = dao.query(Shop.class, Cnd.orderBy().desc("shopName"), new Pager(1, 20));

别老是看 spring，java 世界还有很多框架用的

你要知道更好的，就写下来。

我这不都是写了么，nutz，欢迎点个 star

少了一行，一开始没看出来，不好意思。

star 还是算了吧

一起加油！！

同意。ruby on rails 属于 scale up，但 scale out 就比较难一点。

而因为 java 有大厂背书和使用场景，java 生态圈的 scale out 能力更强，但会有初期的入门曲线陡峭的问题。

昨天还跟人讨论了这个问题，很多 leader、架构师级的研发同学，仅仅会堆技术，我承认技术牛，技术本身也没有错。但是并没有考虑业务大盘是不是需要用 DF17 打渔船，明明用低成本小投入就能换来高价值的回报，非得摆出大阵仗，这才是矛盾点。。。

import org.nutz.*;
import xxx.xxx.models.Shop;
import java.util.*;

@Inject // nutz 自带注解，不依赖 spring
Dao dao

List<Shop> shops = dao.query(Shop.class, Cnd.orderBy().desc("shopName"), new Pager(1, 20));

对比

shops = Shop.page(1).per(20).order(shop_name: :DESC)

================================================
比起代码的健壮性，ROR 的这点简洁不值一提。并且 java 的那一堆 import 根本不需要手打，IDE 自动引入自动按字母排序。

IDE 对静态语言的提示准确率是无限接近 100%，对动态语言特别是 ruby 这种超级魔幻的动态语言，能提示出来 50% 就不错了，其中还会有大量的提示错误的方法和属性，至于 tabnine 这种所谓的 ai 提示的，其实就是统计了概率，大量的不相干的提示反而会扰乱思维。

用 rails 基本上就别考虑用 IDE 了，妥妥的用编辑器，把 rails 常用的方法记到脑子里，日积月累转变成肌肉记忆，项目中的模型的属性和方法，controller 中的方法，route 中的路径，统统都记到脑子里去。这样反而可以增加对项目整体的理解，写出来的程序更加精炼稳定（前提得是程序员靠谱），不过心智负担会比用 IDE 高几个数量级，适合写自己的创业项目。在公司上班要琢磨跟产品跟前端撕逼，跟领导同事博弈，如果再投入过多的精力去写代码会死人的，能腾出来 30% 的精力思考代码就已经是良心码农了，所以 IDE + JAVA 这一套更适合打工人。

java 生态圈的 scale out 能力更强，但会有初期的入门曲线陡峭的问题。

老实说我第一次知道 Java 还有入门曲线陡峭的问题，毕竟我也看过 Think in Java 快 20 年了。。

能腾出来 30% 的精力思考代码就已经是良心码农了，所以 IDE + JAVA 这一套更适合打工人。

这句倒是没错，写的越多就越可能重写，打工人不要为难打工人，都有活，坑死一家公司是一家吧。。

比起代码的健壮性，ROR 的这点简洁不值一提。

这句话，你是想说 RoR 更简洁？

跟你聊的就是 RoR 和 Java 系列的开发效率高的问题。那段代码，还真扯不出健壮性问题。。。

你想聊健壮性，可以在达成“RoR 更简洁”这个基础下，我们继续聊。

IDE 自动引入

还是要按快捷键的，如果要使用鼠标操作的话，就跟麻烦了。。。重名了，还得选。。。IDE 只不过让自动引入变的不那么麻烦罢了。

用 rails 基本上就别考虑用 IDE 了。。。

因为用不着。

这个 List<Shop> shops = dao.query(Shop.class, Cnd.orderBy().desc("shopName"), new Pager(1, 20)); 需要 IDE 提示，这个 shops = Shop.page(1).per(20).order(shop_name: :DESC) 编辑器就够了。

RoR 之所以 IDE 不流行，是以为没有 IDE 大家写的也挺 happy。IDE 对 Java 来说才是必需品。

所以 IDE + JAVA 这一套更适合打工人

恩，是的，Java 创造了更多的岗位，从这个角度看，确实如此。

项目中的模型的属性和方法

属性，用了 @Data，IDE 可以提示吗？反正我的没提示，你要是知道话，我刚好学习下。

controller 中的方法，route 中的路径

RoR controller 之间不会相互调用，不需要知道有哪些方法。。。

路径有命令行 rake routes 打印所有路径。

java spring 如果想知道有哪些路由，是怎么搞的？这个我确实不知道，想学些下。

JPA 解决 N+1 贼麻烦，套一层 has_many 还好，Entity Graph 能搞定，套两层就只能用 @BatchSize批量查询，虽然还是 N+1 但能减少 SQL 数量

其实最蛋疼的还是 @OneToMany 做不到真正的 lazy, 根据不同场景加 where 也神烦

没说完整。这里的“入门”是指部署这种分布式环境 + 搭这种“大中台小前台”架构 + 组建团队的的初期投入成本。然后部署完之后大家就可以安心地搬砖了。

其实我想吐槽的并不是语言本身的事，rails 和 java 哪一个能用更少的行数写分页数据库查询，其实真不是大问题。现在 spring boot 和 rails 的开发效率已经是同一个数量级的。

而是吐槽我们有一些技术同学，本能的把简单的事搞复杂。产品还没上线，先给你搞个大中台，通用性，可伸缩，搞个技术赋能。很多技术决策已经脱离常识。

我的技术常识是：程序员写代码是为了 build things（交付产品）。而最终检验生产力的标准也就是这个产品给用户创造了多少用户价值，和交付的速度如何。拆微服务，拆所谓的中台，都是无奈之举，因为业务复杂度太高，影响了生产力和系统性能。然后我们才去拆分，然后不得不解决一些额外的技术复杂度。

最近的这件事重新提醒了我这个常识。

第二点是这个“不得不拆分微服务”，阈值究竟是多少？答案是比很多人想象的高很多！你可以用一个单体应用做一个产品，成为全球 top500 的创业公司，甚至被收购。问题是在国内的大环境，很多 java 程序员已经退化到只能写个接口，从表里拿一些数据，然后大量时间花在联调沟通等流程里。能处理一个较复杂的 code base 的都很少了。别说从“用户价值”、“业务价值”等更高维的思考自己正在做的事了

其实就是大厂每做一个项目都要把它当成是可以成功的，因此而耗费的多余的人力是公司完全可以接受的。

大厂会有很多成功的项目，从这些已经成功的项目中可以总结出一套标准开发流程。这套流程可以说能适应大厂内部的组织生态，能保证项目在业务复杂度和整体负载成倍增长的情况下相对平滑地稳步推进，但不一定适合项目本身的规模和定位。

spring 再 idea 中会自动提示所有匹配的路由，准确率接近 100%

rubymine 写 rails 的时候也能提示，只是 ruby 太灵活，写的稍微魔幻一点 IDE 的智商就无能为力了。

今天好热闹~O(∩_∩)O 哈哈~

生产力技术要和公司生产关系匹配

狗头飘过

试试 TabNine 没

个人感觉 Java 比较爽的地方就是 idea 提供的 rename，无论是类、接口、属性都能 100% 的正确修改，快捷键跳转 100% 正确，查看引用 100% 正确。spring 项目查看注入、过滤器、缓存一下子全部列出来，给人很放心的感觉。idea 提示错误或者没有对应的注入显示，100% 是人写出了，而不是 idea 未识别。

TabNine 这种智能提示不如没有，每个选项后面还跟这个 xx%的准确度，难道每打个属性方法还要权衡每个选项的准确度吗？其实这很增加心智负担。智能提示要么不提示，要么就提示 100% 准确的，别提示那些让人心里没底的。

@ericguo @u1440247613

借两位大哥的金句改编一首打油诗。

比通用，争赋能，重写一遍再一遍。 大中台，小前台，坑死一家是一家。

哈哈哈哈～～

不需要 IDE 就得能写对 这不是基本功么...

同学 你一直在说提示的问题... 用记事本默写代码并且保证不写错 这不是基本功么 还需要提示？

额。。。麻烦先看下前后文。

我是说 IDE @Data 默认是不能提示的。。。路由也是。

RoR 没 IDE，是因为多数的时候，不需要。编辑器的自定补全，差不多就够用了。

RoR 和 IDE 的关系是，不用 IDE 大家也能很高效的写代码，但如果有更强大的补全，自然是有帮助的。

Java 和 IDE 的关系是，如果没有 IDE，几乎是写不了代码。。。至少，我只有写 java 的时候，才会去用 IDE。

RoR/Ruby + 编辑器效率多数的时候 >= Java + IDE。

恩，是的，IDE 有很多强大的功能。

一个不成熟的小想法，阿里一天赚的钱比很多公司十年赚的都多，好几个数量级的差距确实没必要忙目模仿。

假如 A、A1、A2 三个表 一个 A 对 N 个 A1，N 个 A2。

我们一般单表查询，不用 join。如果查询条件同时需要关联 A、A1、A2 查询，就使用 ES。

先通过 ES 分页查询到 A 的 id 列表，然后再拿 id 列表去数据库分别查询 3 次，A 表 A1 表 A2 表，再组装起来返回给前端。都通过 id 查询挺快的。

那你的观点是？ 另外，工具不谈生产力，谈什么呢？

其实最根本的是人的问题，我不相信你叫 5 个 P8 用 java 重写会比 ROR 差， 永远记住没有银弹。工具和生产力之间的关系离不开人。

不瞒你说，Java 做的后端没那么复杂，都是直接用 MyBatis 框架手写 SQL，不存在你说的这些 ORM 关系问题了，所以这也是导致开发效率缓慢的一个原因

手写 SQL，分页有什么难的呢，插件给你：https://github.com/pagehelper/Mybatis-PageHelper

@hooopo @yfractal 再补充一下，ORM 框架我个人是非常喜欢的，但是由于你们所说的这些原因，团队中技术水平参差不齐，所以就根本没法用，实际情况下都是直接手写 SQL 的，确实效率慢，但是质量上相对会可靠一些（这个可靠指的是同等技术水平，用 ORM 和手写 SQL 对比）

另外，说到效率，其实写代码能用多长时间呢？更长的时间是梳理逻辑、沟通需求，如果这两项搞得清楚，代码不需要反复修改，时间会大大缩短。现实很多初中级都是沟通不清楚，有很多前因后果没搞明白，导致反复修改，浪费了大量时间。

还有一点 Java 圈和 Ruby 圈不太一样的地方是对待单元测试/集成测试的态度上，我是基本没见过哪本 Java 系入门书中有详细教单元测试的，但是 RoR 入门必有单元测试，这点上真是特别好，尤其对入门来讲，编程方法更系统些。

我主要是针对这句话

感觉像讲故事，最近用 spring boot 做了一个小项目，在 idea 强大的智能完成加持下，感觉也不比 rails 效率低多少，但静态语言带来的安全感让写代码的心智负担降低很多

举的例子，也是开发中比较常见的，也是想说明，RoR web/API 开发这个场景下，开发效率会高很多。

技术栈对软件开发进度的影响，这个是另一个问题。这个问题本身想说明白就很难。比如，反复修改花费的时间这块要不要算，这个大家就有不同的理解。

单单

RoR web/API 开发这个场景下，开发效率比 Java Spring 高很多

这个观点想说明白已经很难了。。。就算是有了具体例子。。。

所以，关于“技术栈对软件开发进度的影响”，我觉得我还是保持沉默比较好。

n + 1 这个问题，我自问自答吧。

Java Spring 要解决这个问题，我手写 sql，同时有两个变量保存，还要把变量的关联关系对应上。。。

大体是

List<User> users = userMapper.findById(1024);
List<Book> books = bookMapper.selectMutiByUserId(users);

return presentUserWithBooks(users, books);

（最好应该加 transaction）

当然，这些代码并不是全部，首先是要写 selectMutiByUserId 这条 sql。

presentUserWithBooks 也要改，要把 user 和他的 books 对应上。。。

往快了说，我需要至少 30min。。。

如果是 RoR，2min 搞定，测都不用测。

user = User.includes(:books).find(1024)
return present_user_with_books(user)

spring-boot 相比 RoR 差距还是有的，但是相比远古时代，已经进步特别大了。

单体应用论效率肯定是比不过 RoR 的，但话说回来，如果是超大型微服务的项目（业务域内核心几十个系统），我不知道现在 RoR 在这方面怎么样

超大型微服务的项目

我没研究过，但现在让我选的话，我不会用 RoR，因为觉得 RoR 缺少微服务方面的实践。

RoR 搞微服务的话，需要一些探索。Java 和 Go 这种，更稳妥一些。

RoR 搞微服务的话，需要一些探索。Java 和 Go 这种，更稳妥一些

嗯，所以还是得看业务场景。

如果是单一产品形应用 RoR 没问题，庞杂的业务系统还是 Java 更适合些 😄

这个是我个人的看法 ，我觉得参考价值不大。。。

不过确实没听过大公司，用 RoR 做微服务

十年前一直在 Java 上寻找和开发高效开发框架，后来碰到了 Rails，觉得这就是我一直寻找的东西，以至于都没有兴趣再继续在 Java 上造轮子，因为不论怎么造都是在朝着 Rails 方向，而 Rails 明明就在那里……

后来有了 spring-boot 才发现，技术还是这些技术，但是高手能用写出花来，让你不断拍手赞绝 😂

每个技术都有适用的场景，效率有些时候也并不是最重要

N + 1 的问题，Java 用 Hibernate，配置二级缓存是很容易解决的，或者说不是解决，而是避免了 sql 落到库上导致缓慢。

找出了一篇十多年前 Rubbin Fan 写的文章可以看下：https://www.iteye.com/blog/robbin-77338

另外，Java 的 Hibernate 我已经小 10 年没用了

恩，是的。

用不用 java 或者 spring 要看场景，每个人的认知都不一样，无关对错，个人选择罢了。

单说 web/API 开发。

如果是大公司，团队选择技术栈，那么我会选 java 和微服务。 如果是小公司：RoR 或者 Phoenix。 如果是个人项目：我会选 RoR。

现在学习 ROR 成本高吗

学习成本因人而异，我自己北大青鸟 Java + .Net 培训班出来，大学期间靠 PHP 写外包，Rails 和 Ruby 从来没学过，工作主要靠 Rails 谋生

工具只谈生产力？那是外包程序员吧？代码的可读性，可维护性，可重构性，快速查重能力，这些都被你们忽视？ 恰恰没人谈论这些

这是中台推广文吗？我居然现在才听说这个词。

java 还是主流语言

代码的可读性，可维护性，可重构性，快速查重能力，这些都被你们忽视？

我一直不是很理解 Javaer 为啥那么喜欢说重构，快速查重。代码不是应该没有重的么。。。代码不是应该一次写对，不需要重构的么？Rails 就写了 2～3 行，为啥 Javaer 那么喜欢说可读性和可维护行？你写了 1000 行，有啥可读性，从头看到尾就是要花时间，就是要维护时间多，这不是常识么。。。

说 Java 生产率高，Rails 写两行的速度难道还比不上 Java 写 100 行？就算你有了自动生成器（其实 15 年前我.NET 的 Code Smith 也玩的很转的），但代码 95% 的时间都是在被人读的呀！写的少才难好嘛？！

这个因和果的关系有时候是反过来的。有些公司技术团队本来就是在堆人，认为软件开发就是堆人运动，自然而然的要选择 Java，Ruby 国内这现状没人可堆。

你会发现这样的团队里只有一颗大脑在运转，其它程序员的大脑被限制不许思考，要思考也必须是在限制的框架内思考不许越界，无论日常讨论问题还是实际的工作过程当中都是如此。

写代码也是先设定条条框框，搞出一套一套的所谓的模式，招进来的人只需要无脑跟着模式抄着写，工作基本上就是在大块地复制粘贴然后改两句代码。当然，这还只是这些人理想中的状况，实际情况比这糟糕得多，开发过程中会遇到许多在设计者意料之外的问题，普通开发人员自然是无权解决，不允许被指出框架设计上的缺陷，只能想着法子绕着写。但这样写出来的代码又往往丑陋不堪，回头等框架的设计者发现了这些代码，首先会把开发者指责一通，让他无限地自卑，完了这个设计者再根据这个开发者遇到的具体问题来完善原来的框架，搞出一个新的模式，然后在群里指导大家：以后大家都这么这么干。我见过的国内 Java 开发的生态基本这样，甚至有些“资深”Java 开发学了 Ruby，在带 Ruby 团队的时候也是这个套路。这种人我觉得回去写 Java 是在对 Ruby 圈子做贡献。

从这些人的工作——无论是代码设计、招聘人员、组建团队——等过程中采用的方法可以看出来他们对编程这件事的态度，这些人对写代码这份工作根本上是不尊重和鄙视的，把编码变成不需要思考的体力劳动并持续往这个方向为之努力。

楼上有几位是在下盲棋啊，逻辑完全看不懂。

例如：“如果是超大型微服务的项目（业务域内核心几十个系统），我不知道现在 RoR 在这方面怎么样”，这句话完全没有表述清楚问题，后面居然也有人能接得下去，你来我往地不亦乐乎。

还有张口闭口 IDE 提示、手写 SQL 的，这些是编程入没入门的问题吧。

其实楼主的主帖内容跟编程语言本身也没有任何关系，你们团队要是用 Rails 也一样可以这么搞，而且要真这样搞也一样能搞出这么多问题，根本上是人的问题。

外包程序员恰恰不谈生产力。什么叫生产力？快速地产生一堆垃圾根本不符合需求叫生产力？速度和质量二者皆有才能谈生产力好吗？

当然我这话这么说也太绝对，不能说外包程序员不谈生产力，应该说大多数外包团队太没追求，只想着应付完需求从客户那边拿钱。

我就是外包程序员。我们公司 13 年成立至今，帮客户做了不少成功的项目。有的已经实现了小目标。其实外包项目也能做得很好的，最重要的是能帮客户赚到钱，很多客户我们帮他们从 0 开始打造他们的产品到他们做得很大，还一直在合作。

生产力是杠杠，但我觉得 Rails 的性能还是要差些，当项目做大了以后，比如我们的一个 API，用 Rails 5.2 + Jbuilder。500 左右的 RPM，在缓存全中的情况下服务器响应时间还是要 400ms 左右，JSON 内容有 400kb 左右。我们对缓存做了很多的扩展还搞了这个 jbuilder_reopen (https://rubygems.org/gems/jbuilder_reopen) gem。定时把所有的内容都读到缓存里，但 400ms 的响应时间还是不太理想。

我对我说的那些话做个总结吧。。。

RoR 比 Java + IDE + Package 生产力更高

那两个 query 的例子，就是为了说明，Java 没有很好的东西处理这些常见的问题。所以需要花人力解决，所以生产力不高。

@rfactor

还有张口闭口 IDE 提示、手写 SQL 的，这些是编程入没入门的问题吧。

我在说生产力。。。举例能证明我的观点就够了。。。

如果是超大型微服务的项目（业务域内核心几十个系统），我不知道现在 RoR 在这方面怎么样

@fengkuok 是想说，这个场景下，Java 是一个选择，RoR 不一定行。

我的回复意思是，RoR 缺少实践，可能不行。但和生产力没啥关系。

为什么我们两个能聊下去？

大公司（有很多内部系统的公司），你的服务要依赖很多不稳定的其他服务和代码，并且要提供稳定的服务。用 Ruby，没有相应的支持（背书），要自己搞。背后隐藏来很多奇奇怪怪的东西。

关于楼主说的这件事

这是楼主他们公司的事，我就是看个热闹。我不了解他们的具体情况，没发言权。

不过可以说一点，人力成本对小公司挺重要的，大公司，人力成本就没那么重要了。

*** 我只是说生产力问题，只针对下面这句罢了。***

感觉像讲故事，最近用 spring boot 做了一个小项目，在 idea 强大的智能完成加持下，感觉也不比 rails 效率低多少，但静态语言带来的安全感让写代码的心智负担降低很多。

最后，脱离场景（不了解情况）谈技术没有任何意义。

生产力是杠杠，但我觉得 Rails 的性能还是要差些，当项目做大了以后，比如我们的一个 API，用 Rails 5.2 + Jbuilder。500 左右的 RPM，在缓存全中的情况下服务器响应时间还是要 400ms 左右，JSON 内容有 400kb 左右。

我们 RPM 比 500 高非常非常多，响应时间 P50 不到 30ms，P95 150ms 左右，供参考。

你的例子我明白，我们大部分 API 都能做到 100ms 以下的，而且这个 API 不是 RPM 最高的，我们也有 RPM 非常高的 API，但业务没这个复杂。单就内容来说，有 400kb 的 JSON，按照标准的 JS 格式的话有 11,000 多行，返回的数据量也大。说实话用别的框架或者 Java 来做，同样的业务会不会更快这点不好说，因为没有试过。

这个 API 的瓶颈也不在数据库，所以只要多加服务器都是没问题的，不会因为流量过大挂掉的问题，但不改 API 的结构这个返回时间在现有框架上是没办法下降了，除非利用多核并行的去计算生成 JSON

能赚到钱就是 nice

上面那些 @我 抬杠的我就不一一回复了，确实没有时间去跟井底之蛙争辩，再简单说 2 点： 1：语言只是工具，适用于不同的场景，生产力效率在于人，不在语言本身，Ruby 写的好的，写 Java 也不会差，那些贬低 Java 的人，估计 Ruby 写的也是很垃圾吧。 2：Java 存在那么多年，目前依然是行业主流，多动脑子去思考一下其中的原因，国内那么多大厂的顶级技术人员的认知难道还比不上你一个键盘侠？

另外我不是针对谁，凡是抬高自己熟悉的语言，去贬低另一门语言的人，在我眼里都是垃圾

java 也不是默认性能就强，都是要好好调教的。ruby 做项目一样，都是要想办法的。这不能证明是语言性能的差异。

从头看到尾你的发言除了贬低大家抬高自己以外，啥有用的也没说啊。

回复不上来和不想回复是两回事吧。

我说的是 Rails，不是 Ruby。这是不一样的，但看语言的话可能是相差无几。

国内 Java 团队确实如此，和你说的都差不多，这是实情。目前软件行业，特别是做业务后台的，大多如此，存在很多问题，三言两语也说不清楚，比如中型，大型公司，内部开发责任划分的过细，有专门写前端的，有专门写后端的，有专门写后端 API 的，甚至有专门写数据库层的，还有产品经理的存在，彻底将普通程序员沦为流水线的工人。很多程序员，一年到头只写 API 接口，其他啥都不做，甚至都不了解公司主营业务，以及行业动态。这种公司的 CTO，大多不写程序，只是管理一下技术经理和测试主管，听听产品经理的汇报，好多居然也不懂业务。当他们招人的时候，其实要求非常低，只要你能用 Java 写简单的程序就可以了，如果你是 985 的，那么你还可以入职后才学习。国内，好多公司，程序员这个名称已经变味了。扯回框架语言上来，其实虽然说的是 Java，但是大家说的都是 Spring：），就像很多人虽然说 Ruby，但是他其实说的是 Rails 一样。Spring 这个框架的发展真的非常快，并且与时俱进，特别是 Springboot 出现后，其开发速度和效率，已经不比 Rails 差了，Rails 其实只是在 AR 和 全栈框架（前端模板，Js）方面还有点优势。

发现遇到 ruby 要和其他语言对比的时候。评论就嗨起来了

国内那么多大厂的顶级技术人员

看了这句话我有点想呵呵～那么多？大厂的 顶级？技术人员

从绝对数量来说，大厂的高水平程序员肯定是多的，因为人口基数就在那摆着。但从相对比例来讲，一个大厂的高水平程序员占比不一定比得过一个初创团队。即使是一个 Java 为主的初创团队。

大厂能大起来是因为当手脚的人多，不是当脑袋的人多。Java 这么多年在大厂是主流那是因为适合堆人，可替换成本低。单纯地比较使用人数，生态圈大小这些都是没有实际参考意义的。盲目崇拜跟风学大厂，基本都把自己玩死了。

代码往往写一次，被别人读很多次，代码量少，意味着阅读维护起来就轻松很多。IDE 可以帮你写得快，但并不能帮你减少代码量，阅读代码的人负担还是很重。 用手写 SQL，简单逻辑可能方便，如果手写 SQL 很复杂，那阅读维护代码的人就比较辛苦了，过个 10 天半个月，如果方法命名不当或缺少注释，维护的人，看着一堆 SQL 语句，估计想骂娘。

解决了 80 余人的就业问题，还凭空多出来一些管理层位置，这算。。。。喜事。。。吧？ 🤣

咋样了吗 这贴不能沉

沉了吧 事就是那些事，问题就是那些问题，都讨论清楚啦。