相比高人气的RustGo，为何JavaC在工具层面进展缓慢？

　　2022年StackOverflow开发者调查结果已经正式公布。每当这个时候，开发者们都有一肚子的话要吐槽或表扬，开发者AdamGordonBell也不外如是。Bell最受关注的是最受欢迎和最不招人待见的编程语言。我们先简单看下调查结果：最受欢迎的高人气编程语言（2022）：Rust，Typescript，Python，Go，C，Kotlin，JavaScript最不受待见的高人气编程语言（2022）Ruby，C，Java，PHP，C为什么有的语言受欢迎、有的被讨厌
　　在上一次开发者调查报告时，Bell提到当人们喜爱一种新的编程语言时，大家或多或少会抱有些许偏见，即认为新语言应该拿来开发新项目、旧语言则用于开发旧项目。但这明显忽略了另一个现实：语言工具本身也在不断改进。因此，Bell写了一篇文章来论述了自己的观点，并将编程语言被喜欢的原因归结到了工具性发展上。
　　以Go和Rust为例，业界关于两者的争论从未停止，但两种语言的开发者工具在体验上非常相似：它们都非常现代，无论是测试、模糊测试、打包还是校验，它们都能提供相应的最佳工具标准包。Bell认为，Go和Rust跟不受待见榜单中那些语言的最大区别，并不在于语法细节，而是工具选项和生态系统。正是如此，二者才能双双进入最受喜爱语言名单。
　　Bell认为，随着时间的推移，编程语言的工具和开发者体验正在改善，但这种改善在新语言中体现得更加明显。总体来说，在创新成果出现之后，新语言会更快采用并加以标准化，最终提供超越老牌语言的效果。随着这类增量的积累，曾经的王牌语言就会显得陈旧而腐朽。
　　为什么不能交个朋友？
　　网友crashorbit指出了实际开发中存在的问题。大多数从事系统工作的人都是短期的承包商，他们不了解问题所在，并且在交付了一个测试不佳的系统后很快就离开了。可能忽略了版本控制、自动化测试、文档更新、发布工程和预期的系统开发生命周期的其余部分。
　　crashorbit表示，中层管理者不懂系统工程，高级管理人员更感兴趣的是完成事情，而不是拥有可持续的系统工程实践。坦率地说，我们很难区分一个设计良好的信息系统和一个基本可以工作但‘大风一吹’就会失败的系统。
　　每年从事软件工作的人数都以几个百分点的速度增长。他们中的大多数人在非常垂直的环境中工作，经常在自己的桌面上编写电子表格或杂乱无章的应用程序。一些人编写的脚本只是做简单的事情。或者使用他们不理解的机器学习工具产生具有误导性的结果。
　　我们以这种方式创造即时遗产。没有模块化、没有修订控制、没有部署策略，也没有灾难恢复计划。开发人员早已不在，更不用说系统工程师了。这就是我所说的‘传统阻力’的意思，这就是这个行业如此缓慢的原因。crashorbit表示。
　　开发者fuddlesworth表示自己所在的公司就已经被React16困住，因为整个公司的核心UI组件都在使用Enzyme进行测试，一旦转变就要改动成千上万个测试。我们不能再根据React来更新任何组件了，所以没有bug修复、新特性、性能改进等等。
　　开发者alexiooo98则认为，更好的工具当然非常受欢迎，但仅凭这个并不能完全解释为什么有些语言受到喜爱，而有些则令人恐惧。比如，（现代）PHP有很好的工具，但令人恐惧。Python的管理环境非常混乱，然而Python很受欢迎。
　　下面是Bell文中关于编程语言发展差异的详细描述，我们进行了翻译并做了不改变原意的些许修改。请注意，下文中提到的创新跟语言的语法或语义无关。标准库
　　我不确定这到底是好事还是坏事，但扩展标准库确实让开发者无需安装任何第三方库，就能直接享受到PHP、Python和Go的大量现成功能。它们大部分都带有json、http客户端和服务器，甚至包括数据库访问机制。
　　AmirSaeid
　　所谓标准库，就是语言所附带的常用内容库。C有libc、C有libcpp，但与如今常见的内置电池标准库相比，前面二位的库规模实在小得可怜。
　　我有点记不清了，但是1991年诞生的Python似乎是第一种真正拥有广泛标准库的编程语言。Java1。0（1996年）也附带一个扩展标准库（JavaClass库），随后引发其他人纷纷效仿。
　　这种无需自行构建、又不必接触第三方依赖项的便捷工具交付方式，实在是全世界开发者的一大福音。
　　标准库中的佼佼者：GoLang
　　大部分现代语言（不包括JavaScript）现在都附带丰富的标准库。不过，Go对标准库的强调仍然无人能及，它承诺向下兼容，而且非常关注性能和完善的具体实现。正因为如此，Go开发者对标准库的依赖性远超其他社区，对标准库也普遍更为重视。第三方工具包库
　　就在标准库成形的同时，万维网也开始迅速腾飞。事实证明，互联网确实是一套出色的协作平台。
　　如果我们的需求无法在标准库中得到满足、必须自行构建新功能，该怎么做？Perl通过CPAN推广了全球工具包集合的概念，一切就从那时起彻底改变。公平地讲，任何人用过CPAN并为它做出贡献的朋友，都能感受到它改变游戏规则的重大意义。
　　CPAN于1995年推出（基于CTAN），并于2003年达到顶峰。它的出现为使用软件完成工作的人们开辟出一条新的路径，就是将第三方组件拼接起来。现在，很多现代开发项目都会遵循这种模式。
　　从2003年开始，之后诞生的常用编程语言几乎全部附带某种第三方工具宝库。这股风潮的缔造者就是CPAN，它告诉全世界：真正的编程语言，必须要有第三方工具包管理策略。旁注：向后移植
　　说到这里，有朋友可能会问，既然CPAN让Perl变得更好、也让后来的新语言都接受了第三方工具包管理器这个概念，那为什么之前的语言就没想着亡羊补牢、加上包管理器呢？
　　其实他们有想过，但语言的发展一旦经过特定阶段，之后再想达成一致意见似乎变得越来越难。我不知道为什么会这样，可能大多数人不喜欢做改变吧？
　　反正只要编程语言的习惯表达、基本模式和技术社区一旦建立，就很难再回头调整了。正是因为这个原因，所以JavaScript有NPC、Rust有crates，而C却自己独占dds、cpm、conan、pacm、spakc、buckaroo、hunter和vcpkg。就是因为达不成普遍共识，所以C这边才冒出了八种工具包管理器。
　　但标准库的向后移植倒是比较顺利，C成功把一部分STL招至麾下，虽迟但到底完成了标准库的添加。所以说，老语言也可以搭载工具创新，只是难度会更大一些。
　　总之，在CPAN之后，强大的标准库已经能帮助开发者完成大部分任务。另外，易于使用且接受直接贡献的第三方工具宝库也成了标配。没有这两样，语言将毫无生命力。文档支持
　　有了第三方工具包，接下来就是用简单的方式把它们记录下来。我遇到的最早的文档版本就是Javadoc。它让我能更轻松地在JavaClass中找到自己需要的内容：只需在Web上的Javadocs中单击即可。之后，我们可以把Javadoc和IDE集成结合起来，快速使用自己之前从未见过的代码。由此，探索性编码成为了可能。
　　最强的文档工具：Rust的docs。rs
　　如今，Java的Javadocs已经不再是业界标杆。Go有godoc，Julia有Documeter。jl，就连hackage也有很好的工具包文档。但纵观天下，最强的文档工具还要数Rust的docs。rs。一次编写，随处运行
　　我看到的一项改进是，J2EE和Web服务器的标准化，成就了我们今天赖以生存的计算基础。Java与JVM虽然做出开创，但我觉得它们并没得到充分的认可。在Java普及之后，开发平台与部署平台真正实现了互不干扰。如今每个人都习惯了这样的优势，但在20年前，这绝对是场革命性的颠覆。
　　CdricBeust
　　Java和JVM确实推动了跨平台开发的一路前行。开发环境不再需要跟生产环境紧密匹配。使用JVM，我们可以将内容编译成JAR，并随意运行在任何安装有Java虚拟机的环境当中。
　　后来的虚拟化和容器化进一步拓宽了随处运行的道路，但Java确实是第一种支持这类随处运行工作流的主要编程语言。
　　随处运行中的最强者：Zig
　　Java方法当然不是完美的，首先就是JIT代码的启动速度很慢，另外是无法轻松调用非Java编写的代码。GraalVM声称能够解决这些问题，但目前的主流趋势仍然是提前交叉编译。只要不包含C或libc依赖项，Rust和Go就都能轻松实现随处运行。
　　但目前随处运行中的最强者似乎要数Zig，它不仅能够轻松完成Zig程序的交叉编译，还能兼容由Clang或GCC构建的任何代码。工具包管理器
　　有语言就有编译器，其中提供大量标记可用于灵活调用，但使用过程也是相当麻烦。所以出现了Make和AUtotools这类工具。而后来的第三方工具包生态系统，又让复杂度提升了一个量级。为了解决问题，出现了Maven和pip。但与之对应，我们又遇上了编译器或运行时版本不统一的问题，于是不同的程序就需要匹配不同的工具包版本。Python给出了自己的解决方案，就是pipenv、妙手ualenv以及conda之类我压根理解不了的东西。
　　所有这一切让复杂度继续提升，导致新用户几乎跟不上节奏。因此，新的语言开始尝试把这些一切集中管理起来，简化开发流程。
　　我想说，工具包管理和LSP是我编程职业生涯中见证过的，真正改变游戏规则的两大重要因素。
　　GaneshSittampalam
　　就像内置电池标准库扩展了语言的定义一样，现代工具包管理器也大大提高了开发者对于体验的预期。这种扩展的优势在于易上手、开发体验更好，缺点就是软件的打包、发布和构建会带来相应成本。语言作者需要在工具中投入大量时间来解决这些问题。
　　工具包管理器中的最强者
　　我认为cargo的一大核心优势，在于它与语言相伴而生。而以往的主动构建工具往往缺乏与整个平台的全面集成。
　　RobertMasen
　　工具包管理器正在迅速发展。所以只要舍得投入工程时间，我们就能显著改善自己语言的上手和日常使用体验。于是，新项目在这方面的投入与日俱增。
　　Rust的cargo和rustup文档在体量上已经基本看齐rustbook，而且就这还不足以涵盖所有cargo插件。无论是轻松切换语言的编译器版本、快速运行测试、执行代码覆盖与性能测试、获取供应商代码、生成说明文档、校验代码还是修复校验问题，这些以往存在于语言生态系统中的独立工具，如今都成为Rust中的开箱即用功能。Go的情况也差不多。可以想见，后续出现的新语言要想百尺竿头更进一步，需要付出多少努力。代码格式化器
　　代码格式化器早在gofmt之前就已经出现，就如同CPAN之前就已经出现了第三方工具包，但这一切的最终成熟需要等待一场颠覆社区标准的深刻变革。
　　例如，在Go之前出现的任何语言，都不可能像Go那样实现几乎100的样式一致性。这是因为之前的语言必须兼容原有代码，而gofmt则强制执行单一样式，且不提供任何调整选项。Go之后的语言当然也就站在巨人的肩膀上，于是Rust（rustfmt）和Zig（zigfmt）同样采用强大的默认代码风格与随附的代码格式化器，并由此建立起开发者体验优势。
　　其实可以聊的还有很多，包括运行时改进，其基本相当于对语言的直接改进。IDE、LSP、模糊支持和重构工具等，则把侧重点放在了开发者这一边。但受篇幅所限，我们不可能无限延伸下去。
　　也有一些在语言创造者眼中必将改变世界的成果，最终从未得到广泛采用，或者只在某个特定领域拥有影响力。很明显，Jupyternotebook与REPL就是典型。它们在某些应用领域特别关键，但在其他领域却毫无知名度。Smalltalk基于图像的方法和MathematicaWolfram语言的语言集成数据虽然极具特色，但也更加小众。总结
　　能帮助开发者顺利完成工作的工具，已经是编程语言可用性中的重要组成部分。而工具本身也在持续变化，标准不断提高。
　　整个过程基本就是：在出现新的开发者创新工具时，比较年轻的编程语言更有机会将成果融入自身生态系统，由此形成增量优势。随着时间推移，这些增量优势会推动开发者体验迎来质变。
　　于是乎，较新的语言可以用更明确、更精准的方法解决问题，而旧有语言则面临大量相互矛盾的方法、甚至完全没有可行的解决路线。所以，开发者们才会普遍认为，传统编程语言工具发展进度缓慢。