关于 Java 很重有感

@yedanten 不过有人把域名. 分开单独做字段存关系型数据库吗，不都是合起来，

@Joker123456789 你回复了这么多，更好的证明了我第一条回复你的信息：Java 的生态就是鼓励文件夹嵌套，从官方到个人，从第三方库到自己写的库，从上到下都充满了冗余又繁琐的气息。

看得出来你写了很多年的 Java ，所以你已经被 Java 这种繁琐冗长的结构洗脑了，所以你坚定认为 Java 这种是最优美的最正确的。我们说再多也是叫不醒你的。

@wiix #91 楼，你想一下，为什么 IDE 要开发这个功能。如果不是因为这几个文件夹毫无意义，IDE 会把他们聚合起来？

@Joker123456789 看看 npm/pip/cargo 是怎么解决所谓“命名冲突”问题的，一层命名空间能解决的问题套一堆这不是有毛病？至于 go 的去中心化理念虽然不同，但也没这么麻烦，起码人家标准库是啥就是啥，而不是 java.lang.xxx 。
不要说规范可以不遵守，那只是理论上。所有的生态、工具链、库、构建系统都是这么设计的，你说不遵守就能不遵守？

套一堆子项只有一个的目录只是 Java 世界过度设计的代表性体现。要放开了说，OOP （或者说 class oriented programming ）糟粕一大堆。比如 type 和 namespace 混用（ class/ static class ），隐式 this 指针，隐式 this 作用域，多此一举的 constructor ，作用域混淆（ static 和非 static 项作用域不同，但看起来是同一个）、nullability 等等。你看 c#有那么多特性，十有八九都是为这些历史遗留问题擦屁股。然而 Java 连擦屁股的都没有，演进缓慢还有多少项目万年 1.8 。

@Chinsung

spring 的性能是它的缺点之一 运行状况是会慢些 启动的话是慢到怀疑人生
spring 有线程池 连接池用其他的没错 spring 本来不该拿来跟 nio 比没错
那是 tomcat 的锅 用 spring 也没必要一定得使用 tomcat...
graalvm 反射不是要写设定... 反正目前懒得研究

@gjquoiai

不支持 同名的只能有一个 剩下冲突名称的要使用全名

@james122333 其实我是不太理解 spring 启动慢这一说的，我上个公司前端 webpack 启动要 1 分钟（开发环境还有开始白屏），我们后端微服务，一个服务也就十来秒，多个因为不是并行启动确实慢，但是如果是 springboot 应该也至于处处喊打的感觉

@Joker123456789 23333 我也没说我专业啊。。。。你展现出你专业又如何呢。。。你还不是急了。。。

JAVA 虽然啰嗦，包路径很长，但是包管理方面，目前除了 nuget 感觉能和 maven/gradle 有的一拼其它语言都不太行，比如 npm/go module/Conda(pip) 等等

明明是 java 傻逼, 靠 IDE 才能找补一下. 就这, 还有人强行洗地, 开眼了.

果然，世界上只有两种编程语言: 要么充满了抱怨; 要么没人使用。

@james122333

看东西多不多 越多越有感 赶工的话更是
然而我自己弄的是秒开

@plutome 写的行数够多吗？ https://beeruscc.com/

@plutome go env -w GOOS=linux 原来 这句在你眼里 不是配置啊，哈哈哈哈。 果然 是带着有色眼镜的人

这有什么好争论的？ Java 语言就像 Windows 一样，有历史包袱，毛病多，但用的人巨多，资料巨多，生态丰富。
干活的工具只要不出重大问题，该有的东西都有，那就算是优秀的工具。

@mekingname 我解释过为什么 需要这么长的包名了，我也解释过 go 里面的方案也不见得优雅，你自己去看看 go 的 import 后面那一段有多长，

我也解释过 你完全可以不遵守这个规范，只取一层包名，甚至不要包名。

又不是 编译不通过，又不是运行不起来，又不是容易出现安全问题！！ 你完全可以不遵守啊。

而且取个包名 有多复杂 ，你以为跟你家的 go ，nodejs 一样需要一层一层的取吗？？ 完全一步到位，你完全可以把他看做是一个 名字为：com.xx.xx 的文件夹， 完全可以看做是一个文件夹，创建的时候 也确实 只需要花 建一层的 时间。

你自己 带着有色眼镜，你才是装睡的人！！

@Buges 命名空间 也会有重复的 概率， 这也是 java 为什么要规范 把倒置的域名 添加到最前面的原因。

包名 就是 倒置的域名 . 命名空间。

这么说，明白了没？

@lambdaq 喷人 当然要 语气重点， 原来在你眼里这叫急了，哈哈哈。 至于为什么 不是好好反驳，而是采用喷的方式， 是因为你真的很不专业，指出的问题 完全就是瞎扯淡。

@devtiange 原来 写 nodejs ，go 不需要 ide （集成开发环境，不是那个 IntelliJ IDEA ）。哈哈哈哈。

如果都要用，那有什么问题呢？？ 本来就是需要用的东西，又不是为了解决某些问题 而故意绕路去用的东西。

这也能拿来喷？

@Joker123456789 放屁吧你，用过 go 没，交叉编译 GOOS = linux go build xxx 就完了，跨平台简单跟啥一样

@Joker123456789 可以写成一行的

宁可敲 Go 、Rust 代码也不愿意写 java 太哆嗦，不写 java 体验能好一点。

@wiix #91
1. 你光看到图就急吼吼的来反驳，却不看图片下面还有一句话；
2. 你觉得 idea 优化文件夹路径还很光荣？

转 go 语言吧，大厂都转 golang 了。跟上时代的潮流。 golang 的微信群 v(base64 ）: MTg2ODAyOTI0NTA=

go 的包管理让人无语，还是 java 的 maven 大法好

这都能撕起来?

@Joker123456789 nodejs/typescript, nvim 或者 vscode 写起来毫无问题. 你以为都像你一样, 没了 IDEA 就写不来了?
祝你写一辈子 java 8

没人撕 PHP ，我 PHP 不要面子的嘛？

@kran PHP 是公认的世界上最好的语言🐶

java 本身并不重，源码也可以丢根目录一把梭

只不过

java 的几个常见 IDE 一启动，先吃掉 2g 内存再说😂😂

------

常年用 windows 自带记事本手撸 java/js 代码 的泥腿子路过，源码版本管理全靠 WinRAR😂😂

一个 import alias 就能搞定的问题要靠套目录来解决, 楼上的一个个跳着脚维护的样子还真是有意思

@devtiange 原来 vscode 不算集成开发环境，哈哈哈哈哈。 那你怎么不用 nodepad ，editplus 呢？

@Joker123456789 别争了，人只能赚自己认知内的钱，也只能得出认知内的结论。就这样吧。

Java 这个路径的问题本来不是什么大问题，但是实际对一部分人（主要是不用 IDE 的人，或者会用 IDE 的但是暂时没有用 IDE 的人）造成了 ergonomics 的麻烦

比如 GitHub 上面，打开一个 Java 项目，想简单看下源码要点 N 多次，这还是 GitHub 也“优化”了文件夹嵌套的情况下
就算我 clone 下来，直接用 shell 访问也要敲 N 多次键盘（还不说 clone 本来就多一步）
这些情况都可以装插件来缓解，但是在一个比较简单，插件比较少的环境中，这就成为了实际的问题。
一些其他生态中，很大一部分开发者就属于这种情况，那么 Java ，或者 Java 生态对于他们来说就是“麻烦”的。你不得不承认如果没有“专门优化”，处理文件比处理文本要麻烦十倍。

这不是说 GitHub ，shell 或者其他生态做得多“好”，实际上屎的东西很多。Java 世界做出了全面偏向 IDE 的选择，是有利于隔离外面这些屎的。（至于 Java 自己一堆历史包袱和生态内部问题搞出另外一大坨屎那是另一个问题）
但是问题在于某些 Java 开发者的心态——既然自己决定了主动与其他人隔离，就不要在意其他人的想法。但是某些 Java 用户不仅没有这个觉悟，还振振有词“Java 适合做带项目，你看我们的带项目多牛逼”

问题是为了做“带项目”，就一定要抛弃“小项目”么？我认为这就是 Java （或其生态）在不欢迎它的群体眼中的最大问题。一个旁例是 C#，C# 在语言本身的风评上总体比 Java 好（好像越来越齁是一个问题），生态上则主要集中在那个众所周知的问题上面。C# 也能做带项目，这些带项目中一样各种设计模式啰哩啰嗦，一样嵌套一堆文件夹，但是 C# 也有很多小一点的项目，GitHub 上高 star 的 C# 项目中并不难找到文件夹嵌套和其他语言差不多一个水平，目录结构非常简洁的项目，大概和 Swift 项目的感觉差不多吧。而这并没有影响 C# 做带项目。

我的观察是这种现象与项目的 domain 是强相关的，某些领域的项目做得就很 Java ，某些领域就不那么 Java 。所以 Java 这些特点可能与此也有点关系。

ergonomics 的另一个例子是 ... TypeScript 。可以说 TypeScript 设计上是想要把 JavaScript 往 C# 的方向扭（毕竟这俩同源，虽然最近好像没绷住变成了 Scala :P ），有一些 TypeScript 项目也出现了 “Java 味”的雏形（暂且不用“重”这种定义模糊的词，我们就用 Java 来定义 Java 和“不知道哪个时代的 Java 特色编程思想”）。但是人们讨论 TypeScript 时，好像主要是在讨论它的 Scala/C++/Haskell ... 味，而不是“Java 味”，这一方面当然是因为很多人本来就对 JavaScript 有更多的“Java 味”的需求，另一方面就是 TypeScript 的 ergonomics 做得不错——不仅是不错，而且可以说几乎就是 Java 的另一个极端。

TypeScript 解决问题的方式很巧妙，考虑一个问题：TypeScript 的 killer app 是什么？ TypeScript 的 Rails ，Docker/K8s ，Flutter 是什么？
GitHub 的数据告诉你是 VSCode： https://github.com/search?p=1&q=stars%3A%3E1000+language%3Atypescript&type=Repositories （前两个是 Markdown 项目）
这就很有意思了，因为 VSCode 这个项目本身是 TypeScript 开发的，但是领导核心是 Eclipse 正统，代码也挺 C#，内置了（非常不错的，“原生”级别的） TypeScript 支持。和 Eclipse ，IntelliJ 一样，VSCode 不仅仅可以用于 TypeScript ，并且这部分人还不少——VSCode 官方插件市场里面，Python 、C++、C# 都买了热搜（讽刺的是往后一点就能看到 Java 的热搜），后面还有 Go ，PHP ，Dart ...
暂时无法对比这些语言和 TypeScript 的数据，因为 TypeScript 的支持是 VSCode 内置的，内置的，置的，的 ...
反过来想，就是这些语言的用户，都是 TypeScript 的潜在用户！

我个人主力用 VSCode ，写 C++、C#，OCaml ，Python ，当然还有 TypeScript/JavaScript 。JetBrains 做了 Rust 的 IDE ，但是像 Haskell 这种不可能有人给做正经 IDE 的语言，也把支持 VSCode 和 LSP 作为第一优先级，OCaml 官方教程给新手首推的就是 VSCode 。这部分长尾，VSCode 也全吃下了。
虽然 Electron 在资源占用方面也很“重”，但是反正我写其他语言也要装这玩意，从开发其他语言的 VSCode 用户，转到 TypeScript 开发者，在 IDE 方面没有 overhead ，也就是装个 Node.js 和 npm 的事儿。
这就是另一点了——JavaScript 从小做起，人家做小工具也不差，所以我装个 Node.js 跑个小工具也不亏。
赢麻了。

很有意思的是，造成 C# 在特定领域不如 Java 受欢迎的最重要的，众所周知的那个原因，也亲自指挥、亲自部署了 TypeScript 的推广。
而 Java 这边是无法想像这种事情的。Java 这边也有一个“原因”，也要出新东西，但是貌似依然是要收费的？

@Bingchunmoli #107 其实就是不了解，spring 项目启动慢和 spring 的实现关系不大，你用其他的任意方式实现 spring 的功能，难道启动就比现有 spring 快了吗？
用 GravalVM 编译 spring boot demo 启动，只要 0.0 几秒就可以启动好，所以现在 java 应用启动慢的原因，到底是什么呢？
或者说这些人但凡 trace 过 java 应用的启动也知道，启动过程中最耗时的基本就是 JIT 的热编译

@statumer 你说的是 java 提供不了这样的基础设施

@Bingchunmoli 一把梭爽是爽，每次找个类都要找半天。

@Bingchunmoli 东西少启动就快，接口多了，又没重构项目，跑个单元测试都要几分钟

钱给够了，就比酸酸乳还好喝。

吃饭的家伙，哪个好找工作，哪个上手快就差不多了，但是编程语言对你来说是兴趣爱好的话，那就当我没说。

java 9 以后已经支持模块化了，类名随便起