转了语言后 回过头来回忆下以前的做过的项目
感觉到 Java 项目的优点就是结构稳定吧
Spring 提供官方脚手架，自己公司也可以基于脚手架进行定制化开发。
无论是新的项目还是以前老的项目包层次划分统一整齐。
Maven 官方统一固定了文件路径
代码放 src 资源放 resousrce
有人想动这个路径 直接不支持 而且代码 review 直接骂的狗血淋头
我是没见过这年头有人不用 maven 做包管理的
至于业务层次包 大家好像也形成了统一的规范？
Api/RPC
Service
Dao
Mdeol
这几层大体结构
有没有同样的感想？

统一的规范，写法上也没有太多的魔法

确实啰嗦，语言特性太弱。尤其是 orm 框架，在查询语法上和 C＃比起来弱了一个层级

其实有 IDE 自动补全加强 语法啰嗦点真不是坏事，

我看 typescript 跟 ant-design 写的那个 rule 检测表达式，简直就跟鬼画符一样，贼鸡儿难理解

我再让你看看 swift 的不啰嗦 怕不是要把新手往死里坑

stackoverflow.com/a/68696283/7250073

i.stack.imgur.com/sJs9j.png

缺点很多。
不支持协程，并发吞吐差
只支持一个包名的一个版本，不能共存，时常版本被覆盖
操作复杂 json 想吐
没有原生热更新
没有 async await

一种功能写法越少越好, 要不然有个一二十种方法写循环, 你最多用个两三种, 剩下的根本不用, 其他人用上了你还得重新学.

而且语法糖越多，越容易坑人，少写的那点几个字符 根本省不了多少时间，让新手阅读起来那是真的坑人，而且大部分简写方式的语法糖 在 IDE 增强辅助下，根本不会降低效率，但是语法糖会直接降低 新手或者不熟练这门语言的程序员的心智负担。

"有人想动这个路径 直接不支持" - 其实支持的。
只是遵循约定大于配置。

是啊，抽象能力是一回事，有模板跟范型可以进行抽象，提供这种抽象能力无可厚非，

但是其他很多东西真的没必要搞几个回字的写法，像 js 里面的拉曼达表达式有好几种写法，

最后的结果就是造成不熟练这门语言程序员的心智负担，而大部分时候多种写法并没有任何效率提升，

除了带来不必要的心智负担

stackoverflow.com/a/68696283/7250073

以 Swift 为例，我光是看 Swift 这个 UI 声明，就浪费了大半天，其中至少包含了 3 个语法糖

最开始用 node.js 的时候感叹 js 的灵活和便捷，用 swift 的时候感受写代码居然还能这样炫酷

可是时间长了发现，这样的语言给每个人施展拳脚的空间实在太大了，每个人都在炫技，这写人完全不考虑读代码的人的感受，可是真正好的代码不应该是清晰明了简单易懂的吗？

据说 C++的作者故意提高了写代码的难度，而 java 却确实降低了写代码的难度。

你说的包名问题，自定义 classloader 没接触过？很多人都是这种半桶水，连 se 基础都没掌握好就来跟风吐槽

说 java 啰嗦的人估计是没有写过 c++

swift 的炫技 真的是难懂 trailing closure 以及 last param trailing closure 还有 setter 的省略写法...
真的是无语 真不知道为啥 要加这么多语法糖 是为了干啥

萌新发抖

论最佳实践是否有必要

想动就动被 只要脸皮够厚 不怕代码 review 被怼死。

1. 支持多线程就要支持协程？
   并发吞吐差 哪个场景？哪个框架对比 直接贴链接
2. 操作复杂 json 想吐
   官方的简陋 开源的方便
3. 没有原生热更新

jdk 提供热更新 不过你要热更新干嘛？直接不发版部署？

4 没有 async await

jdk futureTask 了解一下
5 只支持一个包名一个版本

go 就支持？ 我不理解 一个包名多个版本你到底想干嘛？热更新？

还有 java 不负责管理包 目前是 maven 管理

工作中少玩点花活行吗？

Java 这种语言就是下限高，瞎写，也能跑，也凑合能看懂，当然这方面，我觉得 C＃比 Java 更好。

其他比如 JavaScript ，来个变量连类型都不确定，c/cpp 的指针 void*又是万能指针，都需要对代码有相当的了解程度才能看懂意图。

Java 至少没 errlang 那么啰嗦吧

說的像 Java 的 Lambda 只有一種寫法（沒有語法糖）. 我一樣可以用 Java 寫出兩種 Lambda.

// Java 沒有語法糖
Multiset<Integer> lengths = HashMultiset.create(
 FluentIterable.from(strings)
 .filter(new Predicate<String>() {
 public boolean apply(String string) {
 return CharMatcher.JAVA_UPPER_CASE.matchesAllOf(string);
 }
 })
 .transform(new Function<String, Integer>() {
 public Integer apply(String string) {
 return string.length();
 }
 }));

// Java8 加語法糖
Multiset<Integer> lengths = HashMultiset.create(
 FluentIterable.from(strings)
 .filter(string -> CharMatcher.JAVA_UPPER_CASE.matchesAllOf(string))
 .transform(string -> string.length()));

有多少人喜歡第一種沒有語法糖的 0.0

你学过 swift 吗
如果没学过 那看不懂很正常
我会 kotlin 不会 swift
除了 some 关键字和 getter 省略没见过其他都很清楚啊
如果所有语言语法都要和 java 一样那还发明新语言干嘛

具体说说，
最后一个 lambda 可以写在括号外面，
如果只有一个 lambda 参数直接可以省略小括号
如果 lambda 是无参数的可以省略参数声明和箭头
lambda 最后一行就是返回值
Scala 就有，kotlin 也学的 scala

构造函数不用 new
新语言很多都这样 new 就是多余的 构造函数就是普通的函数 不需要特殊对待

你这样杠就没意思了，能简洁的地方 简介并不是坏事，而且第一种并不是拉曼达 第一种是匿名类的方式
这两种写法 并不会造成太大的理解困难

我抨击的是 swift 跟 js 那种 会造成令人困惑的写法

这就是通常程序员挑起语言圣战的起源，

说实话 我根本不想争论这些东西，既然选择要吃 iOS 这个饭，肯定要吃这个屎，全盘接受是没办法的

你提到的那几个省略，除了带来心智负担以及编译器 语法令牌树难以实现外 跟 程序员炫技之外

我看不到任何好处在哪里，节省的那几个字符，在 IDE 补全下，也根本不是问题

java 啰嗦也导致代码很容易看懂

想要工程化，就必须牺牲一些灵活性。
JVM 栈，目前依然还是工程化程度最高的开发工具之一。

首先最后一个拉曼达可以写在括号外面，这个特性 我实在看不到好处在哪里，除了心智负担，另外写在外面就算了 把括号()都省了，那前面那个被调用的函数 就更难理解

var body : some Scene {
WindowGroup { ContentView() }
}
在一个不是很熟悉的 swift 语言的我，看 WindowGroup ContentView 结构体的定义 看了几遍，硬是没理解明白

而且这些语法糖大多是没有提示 也没有解释的，只能去翻语法书，而且提出这个问题的人不仅是我
stackoverflow.com/questions/65384567/swiftui-is-this-code-instantiating-a-new-scene-object

不支持协程这个倒是...导致一堆异步的操作需要类似 callback 回调..写起来真特么恶心

swift 为了声明式 UI 的确有点过了，不过 Java 离这个阶段还远着呢，现在完全用不着害怕语法糖影响可读性。别的不说，getter setter 到现在还得靠 lombok ，就算用了 lombok 也得 a.setX(a.getX+1)，比较字符串还得 Object.equals ，List 和 Map 也只能 get, set ，不能用方括号直接取值赋值。目前来看，改掉这些东西完全不会影响可读性，反而会增加可读性。

不知道大家去看 Groovy 、Scala 写的大一点项目的代码是什么感想，我是想抽写代码的人。

别的就先不说，啰嗦居然成了优点？
如果真的优秀，那为什么 Java 也在加语法糖？

是的，这点我也赞成，但是语法糖这个口子 一旦打开，很多时候就会走向反面，目前 lombok 这样的解决方案也没有那么难懂，而且很多历史原因 不少框架还依赖 java bean 的 getter setter 约定

就是为了 SwiftUI 能用 DSL 写界面啊。就 Java 这种语法基本做不了声明式 UI ，就算利用上了 lamda 也是无论写起来跟读起来都很不好看（可以参考 JaFu github.com/spring-projects-experimental/spring-fu/tree/main/jafu)。尾随闭包之前一直有的，后面为了 SwiftUI 还加上了多尾随闭包，看过讨论说都是为了 SwiftUI

其实扩展函数、尾随闭包这些语法很有利于编程语言作为 DSL ，作为类型安全的描述语言代替 XML 、HTML 、SQL

以及为什么那么多基于 jvm 的“方言”？
还有 Java 就不能整花活了？那可真小瞧 Java 了

上面说的很多都是 library 层的事情，只是语言提不提供官方实现和语法糖的问题，尤其是 java 生态已经有那么多编译时改代码和改 class 的工具，不存在什么功能实现不了的问题。倒不如说是 Spring 生态太一家独大，新技术懒得在 java 上下功夫

1.我寻思 async await 和 futureTask 有啥关系？ async await 是用同步的写法来实现异步回调，简便了开发成本，拒绝回调地狱或者链式回调。async await 就是语法糖而已。

2.只支持一个包名一个版本，如果 [email&＃160;protected] 依赖 [email&＃160;protected], [email&＃160;protected] 依赖 [email&＃160;protected] 并且 pack_B 的 1.0.0 到 2.0.0 有完全破坏性更改，请问如何同时安装 [email&＃160;protected] 和 [email&＃160;protected] ，并保证流畅运行 ？

多版本包共存在 npm/pnpm/yarn 管理下是很常见的，但是 java 的模块机制已经决定很难 多版本共存

第我没觉得这种方式有什么优势在哪里，该用 DSL 应该就发明 DSL 去做，就像 HTML 用来描述结构，CSS 用来描述样式，各施其职，javascript 负责逻辑跟交互

不支持协程可以理解。并发吞吐差是什么鬼，底层有线程池和 Netty ，再往上层就是 Vert.x 、Quarkus 、Spring Flux ，这些一样可以做到高并发高吞吐，只是没这么流行而已😂

无所谓，谁给钱多就听谁，给我 200 万一年写 C 语言都行，C++, 150 万，Java go C＃ 100 万

而且 C 时代，用宏创建 DSL 也不是新鲜事，但是读起来是真的难懂，当然 C 那个时代 连范型都没有，也可以理解

你不觉得优势而已，但是现在就是这种潮流，JSX 、Flutter 、Jetpack Compose 、SwiftUI 都是这种。Gradle 的 build.gradle 就是用 Groovy DSL 或者 Kotlin DSL 代替 Maven 的 pom.xml 。Spring 的 Java Config 代替旧版本的基于 XML 的配置

你用 angluar 会发现....写 ts 也能写得和 java 一样啰啰嗦嗦 哈哈哈

真有劲呀，各位，都在家隔离着不能出门吗？

直接 kotlin 大一统就完了，不要太舒服

对比 OC 写 UIKit ，SwiftUI 的花活是有点多

就地过年呢，没事干

JavaConfig 并没有那么难理解，也没有突破原先的语法，最多算是 SpringBoot 提供的一种特性，

把拉曼达放外面，实在是不敢苟同这种做法，如果有需要，干脆为这种需求定制一种声明式语法都可以。

npm 这种弱鸡拿什么跟 maven 比？同包多版本可以实现，前面已经有人回答了，自定义 classloader 就行，轻量级重量级轮子都有

是的，你是对的

你们要求太高了，语法糖少嫌写着啰嗦，加点语法糖又嫌对新手不友好

在企业里面, 特别是当团队成员水平各异时, 啰嗦不是坏事, 为了灵活而引入的宽松往往是 bug 的来源

很方便啊
只是占位用的语法元素，如果没歧义的话直接就删掉好了
减少语法噪音，让人专注于逻辑本身

写 js 、ts 的时候总要写一大堆的 () =>，又丑又麻烦 ，然而大括号已经被 object literal 用了没法化简

JVM 的并发吞吐差？ Golang 在同等吞吐下能和 Java 一样 low pause 吗？

java 也在不断发展，汲取其他语言的优点，我觉得挺好的

＃6 思维模型反过来说就是心智负担。除非你不要任何思维模型，否则你总有心智负担。语法糖最多不过是把设计模式做到了编程语言里（在不要任何思维模型的情况下，的确没有心智负担，但还有设计模式等着你）

行吧，有人说 ()=> 丑和麻烦，那话就没法聊了

确实 Swift 正在变成下一个 C++, 新手上来如果不通读官方教程, 很多写法看的是一头雾水.
但是再回头写 Java 就太痛苦了.

真做工程，语法糖太多真没必要
idea 花点钱 语法糖省的时间自动提示都出来了。

啰嗦？也可以说是明确吧。
一段代码，写的时候复杂点，但是真的很稳定，易查错，很多问题，从问题找到代码很快就落实了。
心智负担确实少一些

缺点是谁都能挣大钱，优点是能挣大钱。

有人搞错了一点，kotlin 的很多 dsl 语法之类的并不是标准库的东西，而是 kotlinx 库的，比如协程

kotlin 因为语法的强大，可以自行写出来很多 java 做不到或者实现很困难的语法糖

与其说看不懂语法糖，不如说不想学新的类库而已

何况用 dsl 写程序就是未来趋势，毕竟广大 spring boy 天天在用的 spring 都有 router function 了

今天写的一点代码

fun coRoutes() = coRouter {
GET("/queryLog") { req ->
val ipMono = nullable {
val ip = req.queryParamOrNull("ip").bind()
val vo = loggerService.queryLogByIp(ip)
vo?.let { ok().bodyValue(it) } ?: status(404).build()
}
val codeMono = nullable {
val code = req.queryParamOrNull("code").bind()
val vo = loggerService.queryLogByCode(code)
vo?.let { ok().bodyValue(it) } ?: status(404).build()
}
val badMono = status(400).bodyValue("bad request")
[email&＃160;protected] (ipMono ?: codeMono ?: badMono).awaitSingle()
}

GET("/sse") {
val flux = loggerService.sse().map { it.t2 }
ok().contentType(MediaType.TEXT_EVENT_STREAM)
.body(flux).awaitSingle()
}
}

Java 的好处才不是啰嗦，是 Java 几乎堵死了所有可以玩魔法的路子，高手和普通人写的代码差不多。所以 Java 在软件工程化这个领域才能成为第一语言。

＃4
不支持协程，并发吞吐差 ---------这两者是一回事吗？并发吞吐差体现在哪里？
只支持一个包名的一个版本，不能共存，时常版本被覆盖 -------------我挺好奇哪个语言支持同一个同名类多版本存在。。
操作复杂 json 想吐 --------------如果 JSON 序列化框架你全用 map 接，那大概和你想要的效果差不多，而且 fastjson 封装了一些 json 对象来操作，我觉得便利性还可以
没有原生热更新 ----------------------真的吗真的吗，你要是了解 jvm 的 classloader ，你就会知道这个恰恰是比较优雅的热更新
没有 async await ------------juc 的包是写的不够好吗。。。能看到内部实现的并发工具类难道不比语言直接提供的一个关键字要靠谱点？

要不要来了解下 modern c++

我们就不用 maven ，用 gradle+kotlin ，后端确实美滋滋

第五点这个 go 真的支持…

一个包名多个版本，是希望避免依赖冲突吧。可能是个 X Y 问题，虽然依赖冲突麻烦，但是一包多版本可能更麻烦

反正写过 Kotlin 或者 C＃之后就再也不想写 Java 了，真的脏

就是酸葡萄心理。
等以后新语法出来了还不是要吹得飞起。

kotlin 是真的舒服，生态也有

能挣钱的才是好东西，管他有啥缺点🐶

就像国内的软件,非要花拳绣腿什么都搞,真正核心的少的可怜.
各种神奇语法符号,越怪异,越与众不同越会得到期待与满足.
保持克制,发展核心.而不是乱搞什么语法.
随手说几个上面的问题
1.怎么内部隔离依赖?使用 module,不导出即可
2.java 没有 await,
保持使用线程池,同步代码,没必要大改,因为 java 虚拟线程后,不需要关心太多异步,你可以开上万个线程
3.热更新?看看 tomcat 都可以随时加载,卸载 war,为啥..就算是安卓的官方热更新,那也是提供了一个接口给你 classloader,更不说没有限制的 jvm
4.操作 json 复杂,确实,用 js 就是方便,然后随意点,然后出问题狂骂,谁 tm 加的属性...

java 语言就不改么..推荐看看 jep 列表

比如一个草案:

var query = connection."SELECT * FROM {table}";

编译后,相当于
connection :
T apply(String template, List