首页
开源软件
问答
博客
翻译
资讯
Gitee
众包
活动
专区
源创会
高手问答
开源访谈
周刊
公司开源导航页
登录
注册
资讯
软件
博客
动弹
专区
问答
活动
工具
培训
APP
Gitee
新媒体
OSC 直播栏目
技术领航
OSC 公众号
硬核 + 嬉笑怒骂
OSC 微博
技术圈大 V 出没
OSC 视频号
AI 百科
OSC 今日头条
微头条显行业百态
LFOSSA 公众号
LF 开源软件学园
模力方舟公众号
大模型托管平台
Gitee 服务号
研发管理解决方案
登录
注册
挑逗 Java 程序员的那些 Scala 绝技
有个问题一直困扰着 Scala 社区,为什么一些 Java 开发者将 Scala 捧到了天上,认为它是来自上帝之吻的完美语言;而另外一些 Java 开发者却对它望而却步,认为它过于复杂而难以理解。同样是 Java 开发者,为何会出...
作者:
joymufeng
挑逗 Java 程序员的那些 Scala 绝技
分享
复制链接
README badge(
)
社交分享
微信
QQ
微博
joymufeng
2018/10/25 10:44
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
引用来自“joymufeng”的评论
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄
引用来自“dwingo”的评论
不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.
引用来自“joymufeng”的评论
你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。
引用来自“dwingo”的评论
相比之下还是Java更容易进阶一些, 而且同样也很适用于大工程, 上手也相对简单, 又不像C/Go这样精简的语言虽然语法简单但做大工程就捉襟见肘了(抽象能力低). 我承认Kotlin,Scala确实能把代码写的少些, 但写代码的时间我觉得只占整个工程很小的一部分, 而且有IDE的辅助Java也不会多用多少时间, 过分精简代码容易导致阅读困难, 代码检查也因为代码冗余度低而难于发现代码中的bug. 语法特性过多也容易导致不同的人写法风格迥异, 做大工程难于调和(Python比Ruby流行的一大因素).
引用来自“joymufeng”的评论
目前 Java 的企业级开发地位是任何语言都无法撼动的,所以建议新手还是老老实实学 Java。但是作为经验丰富的老手或是公司技术领导者应该把眼光放远一点,毕竟都进入微服务时代了,不同的语言应该各领风骚。很多场景 Scala 更适合,比如说高并发,流处理,完全异步非阻塞系统的构建。
引用来自“dwingo”的评论
流处理不清楚, 但高并发和异步非阻塞Java也完全支持的很好. Java也有协程库.
引用来自“joymufeng”的评论
其实没必要陷入语言之争,这个话题无解。更不要把Java和Scala摆在对立的位置上,Scala完全拥抱现有的Java生态,并且提供了更多解决问题的工具,比如Macro,DSL,隐式转换,以及完整的函数式支持,这些都是Java不具备的,可以认为Scala是Java的一个有力补充,而不是竞争对手,大家其实是一家人,共同壮大JVM生态才是正道。
引用来自“dwingo”的评论
是你先发文挑起, 我只是摆事实, 说明一下文章回避的Java优势而已. 怎么选择让读者自己分辨. Java所选的特性都是优点明显大于缺点的. 而Macro等特性都是争议性很大的, 大多数语言不支持宏都是有道理的, C都支持的特性并不说明这个特性不好加, 而是说明怕这些特性被滥用宁愿不加而已. 提高开发效率的方式并不是加特性一种途径, 而利于阅读理解,利于查出bug,利于协作统一也是非常重要的环节. 优点不多的特性Java都很谨慎加入, 函数式也是挑重要的支持, Scala的一些写法都能换一种不太麻烦的Java写法实现.
额~,此宏非彼宏,不可同日而语。其实全文的主题都在围绕Scala的"简洁性"展开,如果你阅读了全文,我想你应该能发现 Scala 并没有追求极致短码而导致不可读,而是在简洁和可读之间权衡的很好。所以本文的观点也非常明确,如果希望书写的代码更加简洁并且富有表达力,那么可以尝试下 Scala。Scala的很多设计都是为了改良Java,所以学习Scala的过程其实是对Java的一种深度回顾。真心希望大家可以浏览下《快学Scala》这本书,作者是Java语言大师,全文围绕Java与Scala展开,翻译也很棒,读完一定会大有收获。
回复
举报
joymufeng
2018/10/24 22:06
引用来自“海淀游民”的评论
智商不够,用不了 Scala (逃)
引用来自“漂浪天下”的评论
同感
引用来自“joymufeng”的评论
可以先玩玩试试,也许你会有新发现
引用来自“烟波”的评论
感觉有些特性和Common Lisp有点像,类似函数式编程那套理论,最近接触的几个新语言好像都有这个趋势
嗯,Scala 生态比较成熟。
回复
举报
joymufeng
2018/10/24 22:02
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
引用来自“joymufeng”的评论
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄
引用来自“dwingo”的评论
不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.
引用来自“joymufeng”的评论
你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。
引用来自“dwingo”的评论
相比之下还是Java更容易进阶一些, 而且同样也很适用于大工程, 上手也相对简单, 又不像C/Go这样精简的语言虽然语法简单但做大工程就捉襟见肘了(抽象能力低). 我承认Kotlin,Scala确实能把代码写的少些, 但写代码的时间我觉得只占整个工程很小的一部分, 而且有IDE的辅助Java也不会多用多少时间, 过分精简代码容易导致阅读困难, 代码检查也因为代码冗余度低而难于发现代码中的bug. 语法特性过多也容易导致不同的人写法风格迥异, 做大工程难于调和(Python比Ruby流行的一大因素).
引用来自“joymufeng”的评论
目前 Java 的企业级开发地位是任何语言都无法撼动的,所以建议新手还是老老实实学 Java。但是作为经验丰富的老手或是公司技术领导者应该把眼光放远一点,毕竟都进入微服务时代了,不同的语言应该各领风骚。很多场景 Scala 更适合,比如说高并发,流处理,完全异步非阻塞系统的构建。
引用来自“dwingo”的评论
流处理不清楚, 但高并发和异步非阻塞Java也完全支持的很好. Java也有协程库.
其实没必要陷入语言之争,这个话题无解。更不要把Java和Scala摆在对立的位置上,Scala完全拥抱现有的Java生态,并且提供了更多解决问题的工具,比如Macro,DSL,隐式转换,以及完整的函数式支持,这些都是Java不具备的,可以认为Scala是Java的一个有力补充,而不是竞争对手,大家其实是一家人,共同壮大JVM生态才是正道。
回复
举报
joymufeng
2018/10/24 19:21
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
引用来自“joymufeng”的评论
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄
引用来自“dwingo”的评论
不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.
引用来自“joymufeng”的评论
你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。
引用来自“dwingo”的评论
相比之下还是Java更容易进阶一些, 而且同样也很适用于大工程, 上手也相对简单, 又不像C/Go这样精简的语言虽然语法简单但做大工程就捉襟见肘了(抽象能力低). 我承认Kotlin,Scala确实能把代码写的少些, 但写代码的时间我觉得只占整个工程很小的一部分, 而且有IDE的辅助Java也不会多用多少时间, 过分精简代码容易导致阅读困难, 代码检查也因为代码冗余度低而难于发现代码中的bug. 语法特性过多也容易导致不同的人写法风格迥异, 做大工程难于调和(Python比Ruby流行的一大因素).
目前 Java 的企业级开发地位是任何语言都无法撼动的,所以建议新手还是老老实实学 Java。但是作为经验丰富的老手或是公司技术领导者应该把眼光放远一点,毕竟都进入微服务时代了,不同的语言应该各领风骚。很多场景 Scala 更适合,比如说高并发,流处理,完全异步非阻塞系统的构建。
回复
举报
孤独的探索号
2018/10/24 17:16
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
引用来自“孤独的探索号”的评论
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang
引用来自“dwingo”的评论
简单看了一下, 类似groovy的特性, 不知道比groovy好在哪, 后来者只有优势非常大才可能超越.
语法更接近JSON,尤其是 { key : value } 和 [ key: value ]。
更简单的数据类型,数字只分整数Number和小数Decimal。
https://github.com/TommyLemon/Axis-Lang
回复
举报
joymufeng
2018/10/24 16:43
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
引用来自“joymufeng”的评论
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄
引用来自“dwingo”的评论
不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.
你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。
回复
举报
joymufeng
2018/10/24 16:37
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
引用来自“孤独的探索号”的评论
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang
引用来自“dwingo”的评论
简单看了一下, 类似groovy的特性, 不知道比groovy好在哪, 后来者只有优势非常大才可能超越.
二者还是有比较大区别的。groovy 是动态类型语言,意味着如果你用它编写大型项目,重构将会是一场灾难;而 Scala 虽然使用了动态类型语法,但其实它是静态类型语言。
回复
举报
joymufeng
2018/10/24 16:07
引用来自“Shazi199”的评论
diamond应该是菱形的意思,翻译成钻石有问题
感觉译为钻石比较好,菱形会让人联想到菱形继承。
回复
举报
孤独的探索号
2018/10/24 16:01
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang
回复
举报
joymufeng
2018/10/24 14:51
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄
回复
举报
zqq90
2018/10/24 12:38
引用来自“孤独的探索号”的评论
引用来自“zqq90”的评论
很多时候,都是在 「灵活」和「可控」之间找个平衡
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang
我的是
https://github.com/febit/wit
回复
举报
孤独的探索号
2018/10/24 11:48
引用来自“zqq90”的评论
很多时候,都是在 「灵活」和「可控」之间找个平衡
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang
回复
举报
孤独的探索号
2018/10/24 11:48
引用来自“巴林的狗尾草”的评论
Java之后几乎所有的语言都沿着Java定的方向添添补补,除了python略微不同。没有思想上的突破,这种东西颠覆不了Java
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang
回复
举报
joymufeng
2018/10/24 10:57
引用来自“hsl727261250”的评论
除了语法级别的特性, 我觉得其他特性可以自己魔改一下java也能实现😂😂
Scala 的很多特性是通过编译器实现的,魔改不可行哦! Java 原始的的泛型系统和编译器就是马丁老爹设计的,所以编译器是Scala的强项。
回复
举报
joymufeng
2018/10/24 10:52
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
回复
举报
joymufeng
2018/10/24 10:27
引用来自“海淀游民”的评论
智商不够,用不了 Scala (逃)
引用来自“漂浪天下”的评论
同感
可以先玩玩试试,也许你会有新发现
回复
举报
joymufeng
2018/10/24 10:25
引用来自“zqq90”的评论
很多时候,都是在 「灵活」和「可控」之间找个平衡
👍
回复
举报
jump--jump
2018/10/24 09:21
Scala需要聪明的人理解语言的每个特性,但是更聪明的人就不会用它们。
回复
举报
巴林的狗尾草
2018/10/23 17:56
Java之后几乎所有的语言都沿着Java定的方向添添补补,除了python略微不同。没有思想上的突破,这种东西颠覆不了Java
回复
举报
开源狂人
2018/10/23 17:42
真好,所以我用kt。
回复
举报
Z生生不息
2018/10/23 13:53
很好。但是我们用 kotlin。
#DuiC#
回复
举报
zqq90
2018/10/23 13:23
很多时候,都是在 「灵活」和「可控」之间找个平衡
回复
举报
回复 @
{{ emoji.type }}
{{emojiItem.symbol}}
评论用户
推荐博客
MCP会被谷歌的 A2A“吃掉”吗?
肖滢
·
今天 16:22
0 评论
国产替代 + 大模型推理优化,AI 产业发展需要强大的基础设施
哈哈欧尼OSC
·
今天 14:36
0 评论
从本地部署、推理加速到产业落地,昇腾AI基础设施驱动全栈技术升级
哈哈欧尼OSC
·
今天 14:33
0 评论
AI 狂飙时代,开源项目的新机遇?
削微寒
·
今天 09:07
0 评论
超适合小白!晨章数据 CTO 直播教学,搭建最具性价比 AI Chatbot
肖滢
·
昨天 18:48
0 评论
【LLM与操作系统:协同进化】OSC源创会·上海·113期
osc新媒体
·
昨天 16:25
0 评论
【直播预告】Monibuca V5 :AI 时代下的一站式流媒体解决方案(文末福利)
肖滢
·
昨天 14:58
3 评论
深入浅出 GenAI 关键概念—— 从 RAG、Function Calling、MCP 到 AI Agent
ClouGence
·
昨天 12:50
0 评论
驳“RAG 已死”论:上下文窗口扩展≠RAG 终结
Baihai_IDP
·
昨天 10:19
2 评论
万物皆可MCP?MCP需要做减法
肖滢
·
05/10 22:35
2 评论
删除一条评论
评论删除后,数据将无法恢复
取消
确定
顶部
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.引用来自“joymufeng”的评论
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄引用来自“dwingo”的评论
不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.引用来自“joymufeng”的评论
你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。引用来自“dwingo”的评论
相比之下还是Java更容易进阶一些, 而且同样也很适用于大工程, 上手也相对简单, 又不像C/Go这样精简的语言虽然语法简单但做大工程就捉襟见肘了(抽象能力低). 我承认Kotlin,Scala确实能把代码写的少些, 但写代码的时间我觉得只占整个工程很小的一部分, 而且有IDE的辅助Java也不会多用多少时间, 过分精简代码容易导致阅读困难, 代码检查也因为代码冗余度低而难于发现代码中的bug. 语法特性过多也容易导致不同的人写法风格迥异, 做大工程难于调和(Python比Ruby流行的一大因素).引用来自“joymufeng”的评论
目前 Java 的企业级开发地位是任何语言都无法撼动的,所以建议新手还是老老实实学 Java。但是作为经验丰富的老手或是公司技术领导者应该把眼光放远一点,毕竟都进入微服务时代了,不同的语言应该各领风骚。很多场景 Scala 更适合,比如说高并发,流处理,完全异步非阻塞系统的构建。引用来自“dwingo”的评论
流处理不清楚, 但高并发和异步非阻塞Java也完全支持的很好. Java也有协程库.引用来自“joymufeng”的评论
其实没必要陷入语言之争,这个话题无解。更不要把Java和Scala摆在对立的位置上,Scala完全拥抱现有的Java生态,并且提供了更多解决问题的工具,比如Macro,DSL,隐式转换,以及完整的函数式支持,这些都是Java不具备的,可以认为Scala是Java的一个有力补充,而不是竞争对手,大家其实是一家人,共同壮大JVM生态才是正道。引用来自“dwingo”的评论
是你先发文挑起, 我只是摆事实, 说明一下文章回避的Java优势而已. 怎么选择让读者自己分辨. Java所选的特性都是优点明显大于缺点的. 而Macro等特性都是争议性很大的, 大多数语言不支持宏都是有道理的, C都支持的特性并不说明这个特性不好加, 而是说明怕这些特性被滥用宁愿不加而已. 提高开发效率的方式并不是加特性一种途径, 而利于阅读理解,利于查出bug,利于协作统一也是非常重要的环节. 优点不多的特性Java都很谨慎加入, 函数式也是挑重要的支持, Scala的一些写法都能换一种不太麻烦的Java写法实现.引用来自“海淀游民”的评论
智商不够,用不了 Scala (逃)引用来自“漂浪天下”的评论
同感引用来自“joymufeng”的评论
可以先玩玩试试,也许你会有新发现引用来自“烟波”的评论
感觉有些特性和Common Lisp有点像,类似函数式编程那套理论,最近接触的几个新语言好像都有这个趋势引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.引用来自“joymufeng”的评论
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄引用来自“dwingo”的评论
不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.引用来自“joymufeng”的评论
你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。引用来自“dwingo”的评论
相比之下还是Java更容易进阶一些, 而且同样也很适用于大工程, 上手也相对简单, 又不像C/Go这样精简的语言虽然语法简单但做大工程就捉襟见肘了(抽象能力低). 我承认Kotlin,Scala确实能把代码写的少些, 但写代码的时间我觉得只占整个工程很小的一部分, 而且有IDE的辅助Java也不会多用多少时间, 过分精简代码容易导致阅读困难, 代码检查也因为代码冗余度低而难于发现代码中的bug. 语法特性过多也容易导致不同的人写法风格迥异, 做大工程难于调和(Python比Ruby流行的一大因素).引用来自“joymufeng”的评论
目前 Java 的企业级开发地位是任何语言都无法撼动的,所以建议新手还是老老实实学 Java。但是作为经验丰富的老手或是公司技术领导者应该把眼光放远一点,毕竟都进入微服务时代了,不同的语言应该各领风骚。很多场景 Scala 更适合,比如说高并发,流处理,完全异步非阻塞系统的构建。引用来自“dwingo”的评论
流处理不清楚, 但高并发和异步非阻塞Java也完全支持的很好. Java也有协程库.引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.引用来自“joymufeng”的评论
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄引用来自“dwingo”的评论
不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.引用来自“joymufeng”的评论
你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。引用来自“dwingo”的评论
相比之下还是Java更容易进阶一些, 而且同样也很适用于大工程, 上手也相对简单, 又不像C/Go这样精简的语言虽然语法简单但做大工程就捉襟见肘了(抽象能力低). 我承认Kotlin,Scala确实能把代码写的少些, 但写代码的时间我觉得只占整个工程很小的一部分, 而且有IDE的辅助Java也不会多用多少时间, 过分精简代码容易导致阅读困难, 代码检查也因为代码冗余度低而难于发现代码中的bug. 语法特性过多也容易导致不同的人写法风格迥异, 做大工程难于调和(Python比Ruby流行的一大因素).引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.引用来自“孤独的探索号”的评论
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下https://github.com/TommyLemon/Axis-Lang
引用来自“dwingo”的评论
简单看了一下, 类似groovy的特性, 不知道比groovy好在哪, 后来者只有优势非常大才可能超越.更简单的数据类型,数字只分整数Number和小数Decimal。
https://github.com/TommyLemon/Axis-Lang
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.引用来自“joymufeng”的评论
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄引用来自“dwingo”的评论
不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.引用来自“孤独的探索号”的评论
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下https://github.com/TommyLemon/Axis-Lang
引用来自“dwingo”的评论
简单看了一下, 类似groovy的特性, 不知道比groovy好在哪, 后来者只有优势非常大才可能超越.引用来自“Shazi199”的评论
diamond应该是菱形的意思,翻译成钻石有问题引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.https://github.com/TommyLemon/Axis-Lang
引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.引用来自“joymufeng”的评论
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/引用来自“dwingo”的评论
Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.引用来自“孤独的探索号”的评论
引用来自“zqq90”的评论
很多时候,都是在 「灵活」和「可控」之间找个平衡https://github.com/TommyLemon/Axis-Lang
https://github.com/febit/wit
引用来自“zqq90”的评论
很多时候,都是在 「灵活」和「可控」之间找个平衡https://github.com/TommyLemon/Axis-Lang
引用来自“巴林的狗尾草”的评论
Java之后几乎所有的语言都沿着Java定的方向添添补补,除了python略微不同。没有思想上的突破,这种东西颠覆不了Javahttps://github.com/TommyLemon/Axis-Lang
引用来自“hsl727261250”的评论
除了语法级别的特性, 我觉得其他特性可以自己魔改一下java也能实现😂😂引用来自“dwingo”的评论
写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.引用来自“海淀游民”的评论
智商不够,用不了 Scala (逃)引用来自“漂浪天下”的评论
同感引用来自“zqq90”的评论
很多时候,都是在 「灵活」和「可控」之间找个平衡