还有必要用 scala 吗

[leiuu]

RT.

很多团队内写数据流，分为用 java 、scala 、python 三波。

鉴于目前 scala 不温不火，甚至热度有下降的趋势。

是否有必要在公司内部鼓励用 scala ？

是否有必要统一使用 java 开发，减少开发语言的技术栈的复杂度（ scala 较复杂且应用不广泛）？

困扰了挺长一段时间的问题，发出来供大家讨论一下。

[leiuu]

@Pangurban 表达能力强+1 我也觉得 scala 写起来感觉不错 但无奈 scala 在数据团队不能一个语言都吃掉全部需求 但 java 是差不多的 例如数据团队一般会写一些微服务 这部分 scala 做是不合适的

[leiuu]

@ClericPy 不谋而合 多语言经常切换太麻烦了

[szuwl]

我的建议是强推 kotlin

[lmshl]

@leiuu Scala 国内用的人可能越来越少，但全球用户其实在增长。而且近两年社区越来越完善，工具链已经能覆盖 95%以上搬砖场景了，剩下的 5%从 Java 生态白嫖就够了

[leiuu]

@lmshl
我也希望是这样的结果，这样可以安心继续学 scala 并强推了 。
但看了 tiboe 趋势：
https://www.tiobe.com/tiobe-index/scala/
google 趋势：
https://trends.google.com/trends/explore?date=all&q=scala

scala 大概在 18-19 年热度是顶峰，和我的主观感受一致。之后就下坡了。

[ainimuyan]

如果没有全面深入的学习实践过 scala ，直接在生产中写 scala 会让你感觉 scala 很难很复杂，不能像 java 那样游刃有余的实现逻辑，需要在思考逻辑的同时考虑较多语言层的问题，巧的是 scala 语言的特性很多。

scala 有多种应用场景，用来写数据处理任务时一般逻辑集中外部协同少——仅需要熟悉框架 API 和较少语言特性，用来写持续运行的但基本不需要现协同开发的服务——用于练习如果将 scala 集成到原来的 java 生态，用来开发自己的玩具项目、side project ，参与 scala 生态的开源项目等等。

如果一个团队中不少人都喜欢且愿意在生产中应用 scala ，算是具备了 scala 上生产的前提条件。然后是你要用 scala 做什么项目，CRUD 没必要，只有那些能够充分发挥 scala 语言、生态优势且收益不小的项目，才真正值得，因为 Scala 小众是事实，人员风险需要考虑。

最后，我从 15 年开始使用 scala ，最近两年没在用了，因为我现在接到的需求要么是 CRUD ，要么是老板只关心任务是否完成，就是说，需求方或需求本身对技术不追求无预期、或不需要考虑过多，那就没必要。但 scala 本身和生态对我的设计实现过程影响很深。

所以，如果喜欢就尝试写点啥，写多了自己就知道答案了，还有，具体想要使用 scala 做项目的初衷是啥，单纯的喜欢语言，还是想储备技能提市场升竞争力，当前来看显然 scala 没有 rust golang 的市场需求大。

其实，学点啥都是有益的，短期的、长期的，显式的、隐式的，肉体的、精神的。。。

[leiuu]

@szuwl 看到过一些介绍 哈哈哈 不过 kotlin 写大数据好像用的比较少

[leiuu]

@ainimuyan 谢谢 大佬的长文回复 scala 设计有值得借鉴的地方的 其实一直在断断续续看 《 scala 编程》 里边的一些点是对语言理解有提升的 毕竟是新设计的语言 可谓是吸收了众家之长

[lmshl]

@leiuu 那些趋势统计的是社区讨论热度，比如 SOF 新问题等等，但社区代码质量并没有考虑进去。
如果你指的是 Spark boy ，那确实比过去少多了。
但如果你指的是真正的 Scala 开发者，应该比过去人数要多一些的。
最近两年比较热门的是有个叫 De Goes 的光头开发了一套纤程生态，名叫 ZIO 。和 Cats Effect 竞争的非常火热，我目前手里的几个应用就是 ZIO + Akka 做的，都经过生产环境检验了

[lmshl]

@leiuu 于我来说选用 Scala 最大的好处是，睡得踏实。
不用半夜被各种 NullPointException 和 RuntimeException 报警惊扰到，也几乎不用担心有什么漏洞。细数最近的 Spring 漏洞，log4j2 / Spring Cloud Function RCE / Spring Beans RCE 以及各种序列化反序列化库的数不清的漏洞，无一不指向 Java 佬们最喜欢的危险特性，“反射”。

但 Scala 不需要反射也能做的比 Java 更灵活，编译器还可以证明你的代码是没有漏洞的😏

[xianzhe]

我记得之前在某个地方看到大佬的观点，写 scala 时能用 java 的方式写出来就不要去追求其他写法

[agagega]

Scala 是不是小众语言另说，我觉得追求单兵作战能力的小团队用小众语言不是坏事，反而在招人的时候自动多了一层筛选

[lmshl]

@xianzhe 说这话的人是不是 Java 大佬我不知道，但肯定不是 Scala 大佬，😏
入乡随俗这一点应该是人类共识了，如果团队里新来的同事在 Java 里写 if err != nil return err ，我相信不用我动手，其他同事会把他打死的。

[hepin1989]

@leiuu 您可以列举下你的队友写的过于复杂化的代码吗？我觉得为了装逼而装逼的话，用 Java 我也可以装啊，这个更多的我觉得是个代码风格的问题。
单纯从编码效率来说，Scala 会快捷不少。

我个人建议是你们统一下代码风格，限制下什么可以用，什么不可以用，用一个团队都可以接受的平均水平来做，这样大家都舒适。使用 Scala 的话编码的速度会快一些，也就是 可能 KPI 的产出会高一些。

如果没有 KPI 的压力，单纯的靠时间挣钱的卷，那么 Java 这样更加适合。Scala 我觉得是个非常简洁的语言，这个就和沙子一样，你可以用沙子制作芯片，也可以用沙子制作瓷器，也可以用来做手工，修房子或者玩泥巴。

[leiuu]

@lmshl 反射确实引起很多安全性问题。 受教。

[leiuu]

@agagega 这个观点很有意思！ 哈哈～

[Pangurban]

@lmshl 睡得踏实 +1 。不过新手写 scala 还是有很多 null ，尤其是从 Spark 开始接触 scala 的人。个人觉得新接触 scala 的同学在业务代码中不用刻意追求 fp / 语法糖，只要能有意识做到 type safety ，多用点 Option ，Try ，模式匹配，已经相当不错了。

[leiuu]

@Pangurban Try 、case class 很好用！

[xianzhe]

@lmshl https://www.zhihu.com/answer/222581715 ，我是在这看到的，可能是我转速的不够清楚吧，但是这是马丁都赞成的说法

[lmshl]

@xianzhe
一条一条看，杨博转述的太子博客
1. 尽量用不可变值（相当于 Java 的 final 变量）
这已经是 Scala 的方式了，在 Scala 当中优先使用 val 而不是 var ，优先使用 immutable 而不是 mutable 。
2. 采用静态函数和内置数据结构设计 API
尽量用 object 和 scala.collection ，也是 Scala 的方式
3. 尽量使用 JavaSE 和 Scala 标准库的内置数据结构
同上。多说一句，李太子是写库的人，他们对 0 依赖看的比搬砖工们更重要
4. 用 Option 代替异常处理和 null
也是 Scala 的方式，并且 Scala 的 Option 也是 Monad 哦
5. 尽量让函数立即返回值，而不要用异步编程
这是说尽可能，而不是一定不要。不管是谁，在 2022 年的今天实现一个数据库驱动或者 RPC 调用，这种 IO 任务首选当然是被 Future[T] 包裹起来，依然是 Scala 的方式
6. 手动传递参数，不要搞依赖注入
依赖注入不分什么方式，从库 /框架作者角度来看，依赖越少，用户依赖冲突的可能性就越低。当然最好是 0 依赖