从产品的角度看Scala如何从神坛掉落的？
Author：zhoulujun Date：
Scala开始也作为一个学术项目，Martin Odersky创建于2001年，正式诞生于 2005 年，是一种通用用途、面向对象、函数式的JVM语言，是瑞士洛桑联邦理工大学教授Martin Odersky的心血结晶。
什么函数式编程是一个大事情？
清晰：没有副作用的编程范式创建的代码更容易遵循:一个函数完全由从哪里来和到哪里去所描述。一个今天产生正确结果的函数明天还会产生正确的结果。这样创建的代码更容易调试，更容易测试，并且更容易使用。
.简洁：在函数语言中，数据通过一个通用的集合数据类型，隐式地从一个嵌套函数传递给它的父函数。这使得函数式程序比其他范式更紧凑，其他范式需要大量的“管家”代码来实现数据从一个函数传递到下一个函数。
高效：由于函数没有副作用，可以重新排序或并行执行，从而优化性能。如果结果不被使用任何其他函数使用可以完全跳过。
Scala 的设计深受 Haskell 的影响，把函数作为了一等公民设计，而函数式在并发编程领域有巨大的优势，随着多核、并发编程成为主流，函数式编程已经成了新兴语言的标配：函数式、高阶函数、柯里化、模式匹配、函子等概念。
2019 年，当 Twitter 决定将其平台从 Ruby 切换到 Scala 时，引起了 Web 开发界许多开发人员的关注。这种从 Ruby 到 Scala 的转变迅速传播开来，其他公司也开始效仿向 Scala 的转变。随后，Netflix、eBay、LinkedIn 和 The Guardian 等知名网站都使用 Scala 进行后端开发。
设计比Java更好的语言+改善Java时所受的约束
Martin Odersky: 此刻，在Pizza和GJ的经验中，我常常感到沮丧，因为Java是一门具有硬性约束的语言。因此，我做很多事情时都不能用我本来想用的方式，不能用我确信正确的方式来做。毕竟那时候我的工作重点是改善Java。所以，在那段时期过去以后，我决定，我该退一步了。我想从一张白纸开始，看看我能不能设计出比Java更好的东西。但同时我又知道我不能完全从头开始。 我必须利用上现有的基础设施，不然的话，光是无中生有的自举，没有任何库，工具之类的东西，根本就不现实。所以我决定，即使我想设计不同于Java的语言，总归得连接到Java的基础设施——即JVM和Java库。
在java虚拟机（JVM）中运行Scala代码。这意味着它可以很容易地部署在任何运行java的机器上（大约85%的PC机）。这也意味着Scala代码理论上可以与java代码互操作，提供一个java开发团队轻松切换到Scala的桥梁。
Scala的语法类似于java，像java一样在编译的时候执行类型，而不是在运行时检查，从而消除类型不兼容导致运行时出现错误的可能性。这些相似性降低java程序员最初的学习曲线。
理想是好的，现实是骨感的！相比于 Java 诞生的 1995 年，但是Scala 这门语言还是相当小众的，市场上除了 Spark 也基本没有 Scala 的需求。
2012 年的 TIOBE 编程语言受欢迎度排行榜上，Scala 排名第 13 位；2016 年 8 月竟下降到第 32 位，现在只有不到 6% 的编程社区在使用它。
Apache Spark 横空出世之后，Scala简直就是语言界的一颗璀璨新星，惹得大家纷纷侧目，连Kafka这类技术框架也选择用Scala语言进行开发重构。
Apache Flink抛弃Scala的主要原因是因为，社区缺少Scala相关的人员，并且新的Api都是Java的，另外因为兼容性问题，Scala和JavaApi的发展并不同步。综上，Flink抛弃Scala
一门语言、一套技术栈如果要让开发者用得好，并不是要有多好的设计理念，而是要做好开发者体验，这其中包括以下几点：
语言低门槛：这恰恰是 Scala 的天然劣势，无论是函数式、隐式转换、复杂的类型系统、宏、运算符重载这些特性还是 Actor 并发编程都是让人望而却步的东西。
工具链友好：Scala 兼容 JVM 的工具链，但是 java 生态的工具链只能说是丰富谈不上好用，而 Scala 也有自己的构建工具叫 sbt，属于“甲之蜜糖，乙之砒霜”，甚至会有人直接高呼“ sb tool”。
生态丰富：Scala 虽然可以依托 Java 的生态，看上去很丰富，但绝大部分 Java 包和 Scala 的风格都是不搭的， Java 库的作者也不会去考虑 Scala 用户的感受。同时，由于 Scala 设计 Option、Function 的时候 Java 8 还没出来，等 Java8 出现之后这些类型又和 Java 原生的 Optional、Function 不兼容，一起使用无比别扭。还值得一提的是，Scala 的 Collection 和 Java Collection 也不是一套类型，这使得很多使用标准 Java Collection 接口的库都无法直接用。
轻量级的使用：用过 Go 和 Python 的同学们，应该都有体会，编译及运行一个简单的程序是多么容易的事情。Scala 则相反，需要依赖 jvm、scala-library、scala-reflect、scala-runtime、scala-compiler 等几十 M 的 jar 包，要写稍微复杂一点的程序，下载几十个依赖是最基本的配置，这样一来就没法像 Go 或 Python 直接一个命令启动，肯定需要 Maven 或 sbt 管理复杂无比的工程。
强大的商业公司或社区支持：Go 就非常适合写高并发的后端，Python 非常适合 AI 领域，同时他俩在其他方向干得也不差。而对 Scala 而言，貌似 Java能 做的场景它也可以，但几乎没有强有力的公司在背后进行支持，社区里倒是有些大佬把它移植到 Android、Native、Web 开发等领域，demo 看起来酷炫无比，但稍微复杂的场景需要其他库配合的时候就难受了。
Scala社区有很多优秀的技术人才， 但没有多少优秀的产品经理，如果语言也是一种产品的话。
Spark的成功带动了Scala的接受程度， 但Spark的成功来自它的API设计之简洁和使用之简单， 而不是它背后的实现用了多少Scala的高级特性、类库甚至编程框架。
语言的成功比拼的是生态的繁荣， 现在很多技术人员其实可以使用各种语法工具构建自己的计算机语言，但只有被大规模接受和使用才能体现语言的价值。
转载本站文章《从产品的角度看Scala如何从神坛掉落的？》,
请注明出处：https://www.zhoulujun.cn/html/Operation/Promotion/9209.html