这是一个创建于 964 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT.
很多团队内写数据流，分为用 java 、scala 、python 三波。
鉴于目前 scala 不温不火，甚至热度有下降的趋势。
是否有必要在公司内部鼓励用 scala ？
是否有必要统一使用 java 开发，减少开发语言的技术栈的复杂度（ scala 较复杂且应用不广泛）？
困扰了挺长一段时间的问题，发出来供大家讨论一下。
 |
1
zmal 2022-03-31 12:17:28 +08:00
scala 写 flink 比用 java 舒服一些。
|
|
2
zmal 2022-03-31 12:20:37 +08:00  1
至于 scala 比较复杂的问题，把 scala 当做扩展版的 jdk17 ，只是写流式代码的话，学习成本不高。
|
 |
3
knightdf 2022-03-31 12:40:17 +08:00
我只有写 spark 才用 scala ，虽然 scala 灰常好，但是一般项目还是没用
|
 |
4
arewei 2022-03-31 14:08:57 +08:00
scala + spring boot ，回不去了~
|
 |
5
cheng6563 2022-03-31 14:10:45 +08:00
scala 复杂度感觉跟 c++有的一比
|
 |
6
jiangbao888 2022-03-31 14:14:08 +08:00
你体验一下斯卡拉写数据处理业务有多爽
|
 |
7
nicevar 2022-03-31 14:16:51 +08:00
有些开源项目原来是 scala 写的，一段时间没去看，再看的时候发现变成 Kotlin 的了。。。
|
 |
8
cco 2022-03-31 14:31:01 +08:00
除了写 spark ，打死也不用 scala 。自己写的代码过几个月不关注再打开看不懂了。
|
 |
9
exceldream 2022-03-31 14:37:12 +08:00 via Android
当然是 scala 啦
|
 |
11
leiuu OP @jiangbao888 是挺爽的 但可读性感觉不是很高 内部其实 scala 、java 代码量可能各占一半 现在感觉是两个技术栈都学成本过高了
|
 |
12
Huelse 2022-03-31 16:19:04 +08:00
如果是 fp 的话 scala 还是很香的
|
 |
13
huang119412 2022-03-31 16:28:47 +08:00
不是自己的公司，别说 kotlin ，scala ，搞 c++都行，建议别用 stl ，自己实现 list ，map ，反正要突出自己重要地位，别人取代不了。如果是自己的公司，建议 java ，其次 go 。
|
|
14
leiuu OP @huang119412 同倾向这个观点。Java + Go + Python +Bash 足够应付了。
|
 |
16
lizytalk 2022-03-31 19:41:00 +08:00 via iPhone
Scala 写起来确实爽，尤其是和 Java 一比
|
 |
17
hepin1989 2022-03-31 19:50:24 +08:00
我不知道 Scala 复杂在哪儿了，大家都是 CRUD boy ，if else 搞来搞去的，怎么复杂了呢，或者你可以换成 kotlin ，我觉得也不错，反正比 Java 写起来快。如果干不完的活就还是用 Java ，至少可以让自己变得看起来很努力。
|
 |
18
Pangurban 2022-03-31 20:35:38 +08:00
个人特别喜欢 scala ，表达力强，满足代码洁癖。无奈团队中每人写出的 scala 代码风格都不一样。学习函数式编程需要成本，和 java 类似的部分语法又容易让新人产生“已经会了”的错觉。可能还是使用主流语言好一点…
|
 |
19
ClericPy 2022-03-31 20:48:21 +08:00
虽然不懂, 不过大多数情况不都是先统一, 然后根据瓶颈再二次选型么. 虽然能一条道走到黑的语言里面, Java 也确实亲儿子
|
|
20
leiuu OP @hepin1989 大佬好 复杂与否确实是因人而异 这里的复杂暂且理解为其语法多变吧 有很多关键字和写法 容易写出难懂的代码 另外一个点是 scala 有越来越小的趋势 大数据团队的语言技术栈过多 就想着能否去掉 scala 主用 java
|
|
21
leiuu OP @Pangurban 表达能力强+1 我也觉得 scala 写起来感觉不错 但无奈 scala 在数据团队不能一个语言都吃掉全部需求 但 java 是差不多的 例如数据团队一般会写一些微服务 这部分 scala 做是不合适的
|
 |
23
szuwl 2022-03-31 21:11:31 +08:00
我的建议是强推 kotlin
|
 |
24
lmshl 2022-03-31 21:14:10 +08:00
@leiuu Scala 国内用的人可能越来越少，但全球用户其实在增长。而且近两年社区越来越完善，工具链已经能覆盖 95%以上搬砖场景了，剩下的 5%从 Java 生态白嫖就够了
|
|
25
leiuu OP @lmshl
我也希望是这样的结果，这样可以安心继续学 scala 并强推了 。 但看了 tiboe 趋势： https://www.tiobe.com/tiobe-index/scala/ google 趋势： https://trends.google.com/trends/explore?date=all&q=scala scala 大概在 18-19 年热度是顶峰，和我的主观感受一致。之后就下坡了。 |
 |
26
ainimuyan 2022-03-31 21:21:45 +08:00
如果没有全面深入的学习实践过 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 的市场需求大。 其实，学点啥都是有益的，短期的、长期的，显式的、隐式的，肉体的、精神的。。。 |
|
28
leiuu OP @ainimuyan 谢谢 大佬的长文回复 scala 设计有值得借鉴的地方的 其实一直在断断续续看 《 scala 编程》 里边的一些点是对语言理解有提升的 毕竟是新设计的语言 可谓是吸收了众家之长
|
|
29
lmshl 2022-03-31 21:40:22 +08:00 1
@leiuu 那些趋势统计的是社区讨论热度，比如 SOF 新问题等等，但社区代码质量并没有考虑进去。
如果你指的是 Spark boy ，那确实比过去少多了。 但如果你指的是真正的 Scala 开发者，应该比过去人数要多一些的。 最近两年比较热门的是有个叫 De Goes 的光头开发了一套纤程生态，名叫 ZIO 。和 Cats Effect 竞争的非常火热，我目前手里的几个应用就是 ZIO + Akka 做的，都经过生产环境检验了 |
|
30
lmshl 2022-03-31 21:44:56 +08:00
@leiuu 于我来说选用 Scala 最大的好处是，睡得踏实。
不用半夜被各种 NullPointException 和 RuntimeException 报警惊扰到，也几乎不用担心有什么漏洞。细数最近的 Spring 漏洞，log4j2 / Spring Cloud Function RCE / Spring Beans RCE 以及各种序列化反序列化库的数不清的漏洞，无一不指向 Java 佬们最喜欢的危险特性，“反射”。 但 Scala 不需要反射也能做的比 Java 更灵活，编译器还可以证明你的代码是没有漏洞的😏 |
 |
31
xianzhe 2022-03-31 22:22:56 +08:00 via Android
我记得之前在某个地方看到大佬的观点，写 scala 时能用 java 的方式写出来就不要去追求其他写法
|
 |
32
agagega 2022-03-31 22:35:22 +08:00 via iPhone
Scala 是不是小众语言另说，我觉得追求单兵作战能力的小团队用小众语言不是坏事，反而在招人的时候自动多了一层筛选
|
|
33
lmshl 2022-04-01 14:27:01 +08:00
@xianzhe 说这话的人是不是 Java 大佬我不知道，但肯定不是 Scala 大佬，😏
入乡随俗这一点应该是人类共识了，如果团队里新来的同事在 Java 里写 if err != nil return err ，我相信不用我动手，其他同事会把他打死的。 |
|
34
hepin1989 2022-04-01 16:13:28 +08:00
@leiuu 您可以列举下你的队友写的过于复杂化的代码吗？我觉得为了装逼而装逼的话，用 Java 我也可以装啊，这个更多的我觉得是个代码风格的问题。
单纯从编码效率来说，Scala 会快捷不少。 我个人建议是你们统一下代码风格，限制下什么可以用，什么不可以用，用一个团队都可以接受的平均水平来做，这样大家都舒适。使用 Scala 的话编码的速度会快一些，也就是 可能 KPI 的产出会高一些。 如果没有 KPI 的压力，单纯的靠时间挣钱的卷，那么 Java 这样更加适合。Scala 我觉得是个非常简洁的语言，这个就和沙子一样，你可以用沙子制作芯片，也可以用沙子制作瓷器，也可以用来做手工，修房子或者玩泥巴。 |
|
37
Pangurban 2022-04-01 21:16:16 +08:00
@lmshl 睡得踏实 +1 。不过新手写 scala 还是有很多 null ，尤其是从 Spark 开始接触 scala 的人。个人觉得新接触 scala 的同学在业务代码中不用刻意追求 fp / 语法糖，只要能有意识做到 type safety ，多用点 Option ，Try ，模式匹配，已经相当不错了。
|
|
39
xianzhe 2022-04-02 23:09:43 +08:00 via Android
@lmshl https://www.zhihu.com/answer/222581715 ，我是在这看到的，可能是我转速的不够清楚吧，但是这是马丁都赞成的说法
|
|
40
lmshl 2022-04-04 15:50:58 +08:00
@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 依赖 |
|
41
lmshl 2022-04-04 16:06:01 +08:00
@xianzhe 事实上太子的建议几乎都是说，尽可能使用 Scala 写法😂，我不知道是怎么理解成“写 scala 时能用 java 的方式写出来就不要去追求其他写法”。
他还建议用 ADT 呢 https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html#simple-sealed-trait |
Select Language