V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
yazinnnn
V2EX  ›  Java

2022 年冬月, Java 后端工程师拒绝使用 kotlin 的技术原因有哪些?

  •  1
     
  •   yazinnnn · 2022-12-13 20:54:24 +08:00 · 13636 次点击
    这是一个创建于 471 天前的主题,其中的信息可能已经有所发展或是发生改变。

    除去一些非技术的原因(如:领导不让用,同事看不懂,学不会,没时间,不挣钱,对比 java 没优势等)

    可能对比 java 没优势算是一个技术原因

    有哪些技术原因呢? 比如

    • maven 配 kotlin 使用有 bug
    • 换 gradle 后给我下载一堆不同版本的 gradle
    • build 太慢了!
    • java kotlin 混写的时候,空安全了个毛线
    • 使用的插件对 kotlin 支持不好(点艹 lombok?)
    • 毛子语言 /反毛公司的语言,不用(这算政治原因)
    第 1 条附言  ·  2022-12-14 10:27:19 +08:00

    贴一些我认为kotlin对比java的优势

    • 一般不用写分号
    • var和val关键字,不用写final(java可以用lombok实现),以及完整的类型推导(java只有局部变量可以类型推导)
    • 类型系统清晰(方法、变量、lambda统一类型后置,存在函数类型,不需要为了一个函数特地定义一个接口),但是这一点对初学者不友好,如果代码组织的不好,可能会出现看不懂的情况
    • 类型系统的抽象能力及元编程能力比java稍强一些(kotlin没有type class,需要第三方库拯救)
    • 有typealias和import xx as yy语法,不必写全限定类名
    • 无栈协程(jdk19有有栈协程,不过两者并不冲突),现有的几个著名后端框架都对kotlin协程有很好的支持(如spring vertx quarkus等)
    • kotlin协程实现了结构化并发和语义化的结构化并发(java结构化并发在孵化中)(不过结构化并发在后端领域的应用场景还不太明朗)
    • 拓展函数及拓展属性(简化开发的有效手段,通过拓展函数和infix搭配可以组织很简单的dsl)
    • 运算符重载(另一个很有用的简化开发手段)
    • 区分两可变集合与不可变集合(可能是实际中最有价值的优势?)
    • 可以实现函数式中的Monad comprehensions(如arrow通过suspend和context receiver),不清楚java库中是否有类似实现(fsharp、swift、scala都有类似实现,rust大概算半个?不知道csharp中有没有)
    145 条回复    2024-02-04 16:34:10 +08:00
    1  2  
    jeesk
        1
    jeesk  
       2022-12-13 21:02:52 +08:00   ❤️ 2
    这种语言不适合团队,适合个人开发。 类似于 scala,lisp 的感觉。
    tcfenix
        2
    tcfenix  
       2022-12-13 21:06:12 +08:00   ❤️ 8
    要不反过来说....目前值得大家花大力气去推广去使用的 kotlin 有哪些立竿见影的优点?
    zhuangzhuang1988
        3
    zhuangzhuang1988  
       2022-12-13 21:08:20 +08:00
    看不懂
    太多的 dsl
    最近在看 ktor ,简洁是简洁,各种 magic.
    cmdOptionKana
        4
    cmdOptionKana  
       2022-12-13 21:09:12 +08:00
    kotlin 属于特性比较多的语言,学习有一定成本。
    写 kotlin 也许比较爽,但阅读 kotlin 要消耗更多脑力,阅读 Java 很舒服。
    Leviathann
        5
    Leviathann  
       2022-12-13 21:19:44 +08:00   ❤️ 31
    其实主要就是看不懂,上 b 站看一些视频就知道一般路过 java 码农的代码能力有多烂,2022 年学习 stream 的基础用法都跟发现新大陆一样。

    高阶函数,超出 map filter 的都不会,看一个基础的 reduce 要老半天甚至要用 for each 重写一遍才能懂在干嘛
    还有就是不会 immutable 风格的代码,不让他 for each add 或者 put 构造一个集合就是要了他的命

    跟别说让他们理解一个参数为某类型拓展函数的函数了 (type safe builder 基操)

    你说的那些,他们甚至都不知道这回事

    一个一般路过 spring 熟手和一个一般路过 react 熟手,我怀疑 react 熟手对编程语言的理解会比 spring 要高

    hook 搞得那套闭包地狱理解不够 debug 都 bebug 不了

    再加上 typescript 的基本类型体操能力,完全不是 springer 能比的
    kwh
        6
    kwh  
       2022-12-13 21:22:17 +08:00   ❤️ 15
    因为学习 kotlin 并不能带来任何的利益。
    只会带来成本。

    学 Dart 可以使用 flutter 写多端共用的前端。
    学习 C++,比如 QT ,游戏开发,系统 API ,还有其他好处。
    学习 JavaScript Vue ,可以写前端。

    学习 C#,可以怼天怼低,无所不能,前端,后端,游戏,系统 API 。


    而 学习 Java 的子集 kotlin 可以带来什么?
    GTim
        7
    GTim  
       2022-12-13 21:31:08 +08:00
    当我们以为自己需要一个更好的语言的时候,其实,更多的,是需要一个更人性化的工具,比如 Lombok
    YVAN7123
        8
    YVAN7123  
       2022-12-13 21:34:11 +08:00
    java 都学不过来了 求求放我一条生路吧
    knightdf
        9
    knightdf  
       2022-12-13 21:37:24 +08:00
    安卓用不就好了,为啥后端也要用?
    orangie
        10
    orangie  
       2022-12-13 21:43:19 +08:00
    kotlin 我完全喜欢的只有空安全,而其次的 list 重载方括号运算符等等更方便了但也有太明显的负面影响。让我全方面感觉更好的只有空安全这一个改进。
    kran
        11
    kran  
       2022-12-13 21:49:01 +08:00 via Android
    何不先谈谈为何接受。
    jeesk
        12
    jeesk  
       2022-12-13 21:57:56 +08:00   ❤️ 3
    代码是给别人看的, 不是耍酷的。 当我明白了这个道理后,google juice 的源代码历史使用了大量的设计模式,即使是 java 的代码都让很恶心。 太难受了。
    WIN2333
        13
    WIN2333  
       2022-12-13 21:59:41 +08:00
    @Leviathann 对对对,您说的对
    learningman
        14
    learningman  
       2022-12-13 22:00:39 +08:00   ❤️ 1
    @kwh
    “学 Dart 可以使用 flutter 写多端共用的前端。”
    那 Kotlin MultiPlatform 也能用 Jetpack Compose 写“多端共用的前端”啊。。。
    wangfeng3769
        15
    wangfeng3769  
       2022-12-13 22:01:06 +08:00
    买了本 kotlin 的书 一周 就入门了,java 的倒是太臃肿了,不想用 java
    ruiyinjinqu
        16
    ruiyinjinqu  
       2022-12-13 22:01:45 +08:00
    学习 sacla 还能搞搞大数据,写写 spark ,flink ,能有更大的提升
    dreamlike
        17
    dreamlike  
       2022-12-13 22:08:44 +08:00 via Android
    从工作角度来说 积重难返和 java 交互有点问题,在传统的 servlet 里面没有这么多适合 kt 的场景,有时候包含 kt 语法糖的代码,运行时抛错行数其实有点问题
    从个人角度说 kt 爽到炸 搞 dsl 真心好用 我个人又用响应式库多配合 kt corotinue 很不错,ksp 也非常好用 还能凑合用用 compose
    dcsuibian
        18
    dcsuibian  
       2022-12-13 23:15:58 +08:00
    可以学,但是没有必要。

    接触过的编程语言越多,对新语言的兴趣就越少。C/C++、Java 、Python 、JavaScript/TypeScript ,累了,不想学了。
    silentsky
        19
    silentsky  
       2022-12-13 23:17:31 +08:00 via Android
    换了个写法 有啥新意?
    weiweiwitch
        20
    weiweiwitch  
       2022-12-13 23:33:15 +08:00   ❤️ 1
    没有什么太复杂的原因。团队的技术惯性而已。后端天生求稳的特点,导致后端团队的惯性要更大。
    假设团队当前正在做一个项目,有人给他们一套新技术的成熟解决方案,并且后续有强力的技术支持,让他们从开发到上线到后面的维护都没啥坑,他们转新技术的动力会非常的强。
    相反,没有巨大的利益在前面诱导,不管是 Java 转 Kotlin 这种转换系数很低的,还是换一种排名相当靠前的语言,还是只是简单换个框架或组件。让他们改变技术的阻力都会很大。
    想想有多少团队还在坚守 Java 8 ,甚至 7 和 6 。
    urnoob
        21
    urnoob  
       2022-12-13 23:51:38 +08:00 via Android   ❤️ 11
    看到那些迷恋语法糖,搞各种编程风格的我就笑笑。做后端多点朴实的代码,用点简单的语法糖, 程序挂了起码知道挂在哪。一堆 lambada ,搞反应式编程,写的时候爽,最后都不知道问题出在哪一行。
    zu1y
        22
    zu1y  
       2022-12-14 00:13:22 +08:00
    用 kotlin 写了一些 gradle 插件
    Bingchunmoli
        23
    Bingchunmoli  
       2022-12-14 00:14:29 +08:00 via Android
    gradle 每次都是报错不像 maven 慢了点,不至于 spring 初始化 HelloWorld 都会错,要配置一番
    haya
        24
    haya  
       2022-12-14 00:38:28 +08:00
    kotlin 如果有 macros ,我就用它
    Al0rid4l
        25
    Al0rid4l  
       2022-12-14 01:25:59 +08:00   ❤️ 2
    mark ,Java 程序员标本备份
    SeaTac
        26
    SeaTac  
       2022-12-14 01:34:31 +08:00
    取决于 tradeoff ,换语言是有成本的,如果 owner 觉得换语言带来的好处大于坏处那就换呗
    dcoder
        27
    dcoder  
       2022-12-14 01:53:11 +08:00   ❤️ 1
    你排除的就是主要原因啊 "没时间,不挣钱"
    Nnq
        28
    Nnq  
       2022-12-14 01:53:50 +08:00
    不会的时候
    MrHyde
        29
    MrHyde  
       2022-12-14 03:42:25 +08:00
    语法糖太多了,不好记,java 啰嗦,但清晰
    liveoppo
        30
    liveoppo  
       2022-12-14 05:48:45 +08:00
    因为 kotlin 能干的 java 也能干。kotlin 代码表面上看简洁明了,但实际上心智负担比 java 重,后端又是一个稳定重于耍酷的地方,那么何必呢?

    个人项目例外,可以起劲地折腾。
    silvernoo
        31
    silvernoo  
       2022-12-14 06:19:06 +08:00
    编码稍微繁琐一点换来了清晰的代码结构,Java 本身没什么太大的毛病。
    netabare
        32
    netabare  
       2022-12-14 07:24:30 +08:00
    不知道是否有纯粹的基于技术限制而非个人喜好的「拒绝 Java 」的理由。

    除此之外的任何理由,感觉对于一个 Java 技术栈的开发人员 /团队来说,都是纯粹的 red flag 。

    Kotlin 并没有多复杂的语法或者多么花哨的设计,总体来说是一个 pragmatic oriented 的语言,应该不会有多少心智负担吧。
    xuanbg
        33
    xuanbg  
       2022-12-14 07:54:40 +08:00
    我自己用什么语言都无所谓,但代码不是写给自己看的啊。。。
    dbpe
        34
    dbpe  
       2022-12-14 08:26:27 +08:00   ❤️ 3
    @Leviathann +1 ,不接受新事物,还各种美曰其名稳定。。。
    lululau
        35
    lululau  
       2022-12-14 08:26:56 +08:00 via iPhone
    因为对于很多人来说,编程只是一份工作
    wangtian2020
        36
    wangtian2020  
       2022-12-14 08:37:09 +08:00
    我公司后端:“JDK8 什么不能写,稳定!”
    ragnaroks
        37
    ragnaroks  
       2022-12-14 08:38:30 +08:00
    单纯的开发人员无权决定用什么语言、框架,应该问为什么那么多使用 java 的团队领导不愿意使用 kotlin ,我的答复是:团队领导不用写代码只需要看代码。
    ExplodingFKL
        38
    ExplodingFKL  
       2022-12-14 08:49:34 +08:00
    那我 kotlin + rust 岂不是完蛋了 ...
    Nazz
        39
    Nazz  
       2022-12-14 09:13:04 +08:00
    @urnoob 笑了
    thetbw
        40
    thetbw  
       2022-12-14 09:25:26 +08:00
    感觉 kotlin 对写业务代码没有什么帮助,业务代码本来就很乱,这会让以简洁著称的 kotlin 显得格外的丑陋
    MakHoCheung
        41
    MakHoCheung  
       2022-12-14 09:26:59 +08:00
    除了扩展函数(中缀表达式就不说了,乱用的话别人看你的代码会骂娘),Kotlin 有的 Java19 都有了,与其换 Kotlin 还不如升 JDK
    wetalk
        42
    wetalk  
       2022-12-14 09:29:11 +08:00
    因为 kotlin 市场占有率低,国内写后端没多少人用
    iovekkk
        43
    iovekkk  
       2022-12-14 09:30:55 +08:00
    kotlin 写起来是真的爽
    但是作在初期学习过程中
    看项目 kotlin 代码,真的是头大
    阅读性太差了
    fredli
        44
    fredli  
       2022-12-14 09:39:52 +08:00
    还需要特意学么?有个 lead 带头,看看用用不久会了么
    sinnosong1
        45
    sinnosong1  
       2022-12-14 09:41:35 +08:00
    我身边的 java 大部分都是拒绝学习任何东西
    zzlhr
        46
    zzlhr  
       2022-12-14 09:46:45 +08:00
    kotlin 有协程,貌似很吊
    ttimasdf
        47
    ttimasdf  
       2022-12-14 09:48:34 +08:00
    没用。。特别是你身边都是垃圾程序员的时候,格外没用。

    当然有一点好。
    写 JD 还有面试的时候,把 kotlin 加进去,可以有效筛掉一部分低端码农。
    OaO
        48
    OaO  
       2022-12-14 09:48:51 +08:00
    @sinnosong1 太对劲了
    matrix67
        49
    matrix67  
       2022-12-14 09:50:05 +08:00   ❤️ 5
    C 和汇编有如太祖长拳。无名小厮耍起来也就是小朋友乱斗的效果,在萧锋手上,却是招招致命。语法本身极其简单,关键词手脚并用都能数得出来,写个 hello world 更是两分钟就能搞定,但只有你对系统融会贯通,练好各种内功心法,才能发挥其巨大威力。

    PHP/javascript 是吸星大法。练起来不难,没内力的入门很快,网上到处是现成的模块,据为己有后立刻等级提升。不过其致命的缺陷导致你只能在准一流游走,用不好关键时刻还会反噬。

    Python/Ruby 是太极剑,变化多端,小到一个卑微的脚本,大到高逼格的机器学习,都能轻松对付。可是 performance 和解释器实现上的先天不足( Guido/Matz 其实挺冤:我给你们个电钻,你们非要用它来钻钢板,性能不好,怪我咯)是其破绽,导致遇到计算密集 /IO 密集型的问题,处理起来很是伤肾。

    Erlang/Elixir 像是降龙十八掌,大开大阖,刚劲有力。可是入门不易,思想深邃,会的人不多,只能靠自己苦苦钻研。actor model ,supervision tree ,messaging passing ,pattern matching ,光理解透了,便是半载光阴,练出名堂,那出手便是大师风范。

    clojure 好似独孤九剑,「风雷是一变,山泽是一变,水火是一变」,变化多端,核心是以不变应万变。需求纵使千变万化,提纲携领,找到破绽,然后以 macro 和 polymorphic 化之。代码即数据,数据即代码,以轻御重,化烦( object )去简( function ),退则滴水不漏,进则攻无不克。

    Haskell 像是乾坤大挪移,没有深厚的内力修为很难参透。lazy computation/monad 干的就是牵引挪移这样匪夷所思的事情。一个程序,不过是从输入到输出中间经历的一系列 transformation ,你是一招一式传递数据,还是传递运算,斗转星移?回答了这个问题,haskell 也就算是入了门。
    optional
        50
    optional  
       2022-12-14 09:52:14 +08:00 via iPhone
    写起来很爽,用过两个项目,发现还是不太适合团队。
    optional
        51
    optional  
       2022-12-14 09:52:56 +08:00 via iPhone
    一不小心就会开始创造 dsl 然后在这里浪费时间又觉得莫名很爽。。。
    BanGanExpert
        52
    BanGanExpert  
       2022-12-14 09:59:56 +08:00
    @Leviathann 大多数 springer 根本问题其实不是说不懂新特性,而是因为 Java 作为最火的后端开发语言,早期入门门槛过低造成,大量基本的编程能力过差的人员(特别本身也没有兴趣的人)通过 spring 框架能够完成基本的开发工作。他们缺乏的反而是基本的编程的能力,在缺乏基本的编程能力的前提下更自然不会对新的特性,或者语法糖也好有任何学习的动力。当然我不太懂前端,但是我猜测前端出现这种情况估计也不少。
    zapper
        53
    zapper  
       2022-12-14 10:00:35 +08:00   ❤️ 1
    本帖中使用 Kotlin 的我一律视为大神,高端大气上档次;
    使用 Java 的都是 low 逼,老古董,笨蛋胚子
    popil1987
        54
    popil1987  
       2022-12-14 10:10:24 +08:00
    不要看语言要看生态,语言常有,然生态不常有,干什么事就用最适合这件事的库或框架。学语言比造生态容易多了。如果你是普通人的话,如果你是天才也不可能问这问题,早创造生态去了
    yaocai321
        55
    yaocai321  
       2022-12-14 10:10:26 +08:00
    用 kotlin 三四年了。 个人观点,拒绝使用 kotlin 的原因,对个人而言,就是不愿接受新鲜事物,对团队而言,写起来爽,但看起来难受(因人而异)。
    不过话说回来,高版本 java 跟 kotlin 也没多大区别了,使用频率比较高的特性,高版本 java 基本上都有了。
    如果在使用高版本 java ,没用 kotlin 也很正常。
    ylls
        56
    ylls  
       2022-12-14 10:17:12 +08:00   ❤️ 1
    有些人写 Java 已经够烂了,再写 Kotlin 那不得给鬼看呀
    loshine1992
        57
    loshine1992  
       2022-12-14 10:18:58 +08:00
    @zzlhr 如果你用过协程就会知道,在 JVM 上 Kotlin 的协程只是对线程的封装而已。
    chendy
        58
    chendy  
       2022-12-14 10:22:52 +08:00
    因为有成本和风险但是没有收益
    真实世界里别说优秀团队,靠谱开发其实都很难找,能把 java 写明白,不偶尔整个 str != "" 就不错了,用 kt 怕不是原地去世
    自己玩用啥都行,正经项目要考虑稳定性和成本
    mooncakeSec
        59
    mooncakeSec  
       2022-12-14 10:24:16 +08:00
    2022 冬 gradle 都还没推太动呢
    zed1018
        60
    zed1018  
       2022-12-14 10:24:38 +08:00
    @yaocai321 拒绝 kotlin 的人大概率也拒绝高版本 java ,也许用的新 jdk ,但语法还是老一套。
    Aurt
        61
    Aurt  
       2022-12-14 10:37:13 +08:00   ❤️ 2
    kotlin+gradle ,简直是英特尔和 AMD 战略合作伙伴
    TWorldIsNButThis
        62
    TWorldIsNButThis  
       2022-12-14 10:41:21 +08:00 via iPhone
    @loshine1992 主流的无栈协程就是靠编译器 /解释器的科技与狠活编译成 event loop 调用,所以可以做到更低的开销
    这个而已指的是?
    superchijinpeng
        63
    superchijinpeng  
       2022-12-14 10:44:04 +08:00
    我司后端所有项目,全是 Kotlin + Gradle ,包括 Flink 、Spark Jar 任务,连 CI 都是,用了就回不去了
    jklove123bai
        64
    jklove123bai  
       2022-12-14 10:49:32 +08:00
    @superchijinpeng 国内还是国外的公司? gradle 源问题咋解决的?有专线吗
    yazinnnn
        65
    yazinnnn  
    OP
       2022-12-14 10:49:35 +08:00
    append 了一些我个人的认为的 kotlin 技术 /语言层的优势

    然后再说一下对比 java 和其他语言的不足(?)

    1. 没有模式匹配,这点 kotlin 官方貌似对它不感兴趣,目前只有 when 表达式,模式匹配上还不如 java 有进展,更别提 scala 或者 rust 了
    2. 没有三元运算,只能 if ( condition ) a else b , 不知道是编译器实现上有困难还是什么原因
    3. 无法自定义运算符(指望一下 kotlin 2 吧,如果有的话)
    4. kotlin 协程染色问题,java 无法直接调用 kotlin suspend 方法,需要 kotlin 侧工程师拯救

    再补充一下上面漏掉的优点
    空安全和 elvis 表达式(很多语言都有,js ts csharp swift 等等,不过 kotlin 初学者或者 java 工程师对 kotlin 的?非常抵触)
    与 java 的互操作性优秀(对比 scala 和 f#与 c#,不过我不懂.net ,初看 f#和 c#互操作有点麻烦)
    inline 及 refied ,可以把一些多于的工作交给 kotlin 编译器,并且提高了运行时的效率
    object 关键字实现单例,by lazy 实现延迟加载,:InterfaceA by a 实现代理模式(比较高效的开发手段)
    potatowish
        66
    potatowish  
       2022-12-14 11:02:41 +08:00 via iPhone   ❤️ 1
    非技术原因更重要,就是不挣钱。
    相比较 kotlin ,我更愿意去用 go 。

    说用 java 的不愿意换 kotlin 就是保守,这话我不认同,用什么语言那是市场需求决定的。
    TWorldIsNButThis
        67
    TWorldIsNButThis  
       2022-12-14 11:07:57 +08:00 via iPhone
    @yazinnnn pattern matching 这个
    我看 youtrack 的相关讨论是他们目前的主要精力是在忙活新编译器 k2 ,等搞好后再开始加一些 big feature
    不然代码要写两遍 老编译器一份 新编译器一份
    0xZhangKe
        68
    0xZhangKe  
       2022-12-14 11:15:41 +08:00
    @loshine1992 不是对线程的封装,而是协程底层仍然是基于线程的,这一点无论如何没法改变,协程类似于线程池,但是在 Kotlin 中会更优雅。
    0xZhangKe
        69
    0xZhangKe  
       2022-12-14 11:18:22 +08:00
    @kwh 效率提升也是利益。
    而且 Kotlin 结合 Compose 可以写跨平台 UI ,KMM 也可以跨平台。
    superchijinpeng
        70
    superchijinpeng  
       2022-12-14 11:24:32 +08:00
    @superchijinpeng 国内国企,公司内部源
    yty2012g
        71
    yty2012g  
       2022-12-14 11:26:51 +08:00
    最近在搞 JDK8 升级到 JDK17 ,感觉还是蛮简单的。基本不使用高版本的语言特性,只使用高版本的 JVM 特性。成本非常低,基本就是 javax 包添加一下,加一堆 VM 参数就完事儿了。但是如果是加入 kotlin ,那语言特性就多太多了,对于生产环境,语言特性带来的收益“显著低于”JVM 特性带来的收益。
    ClosureEleven
        72
    ClosureEleven  
       2022-12-14 11:27:08 +08:00
    非后端,感觉 kotlin 在安卓上的流行度已经超过 java 了
    gongquanlin
        73
    gongquanlin  
       2022-12-14 11:40:13 +08:00
    因为语法糖太迷了,本来同事的代码写的就和屎山一样看不懂,再来个 kotlin 岂不是……

    曾经有一个同事自认为自己代码非常牛逼,实际上非常垃圾毫无规范,命名变量全部都是 a ,aa ,aa1 这种,胜似混淆。有一次维护他的代码看到一串 类似于“12+421+142+56”纯数字加法,整的我以为混淆过了,问他为啥这样写,这个是干啥用的,答曰“我也忘记了,可能是乱码吧”

    在这种情况下上 Kotlin ,岂不是……
    yjll9102
        74
    yjll9102  
       2022-12-14 11:45:52 +08:00
    看团队吧,现在小项目我用 Groovy ,不离开 Java 生态,写起来还很爽
    flyingghost
        75
    flyingghost  
       2022-12-14 12:07:09 +08:00   ❤️ 4
    我在另一个思路上有所感悟。

    相比于前端、移动端,盘子小,稍微折腾下就遇到了盘子的天花板。于是多余的心智怎么办?
    放在业务领域上,十有八九码农不喜,而且领域之间也缺乏共性缺乏沟通基调,你放了也没法和别人讲。
    放在通用知识上,加解密、音视频、算法、安全等等都算,但说实话确实机会确实少。
    放在内卷和求新求变上。来了!各种语言各种框架它来了!

    而后端,盘子太大,一入后端深似海。抛开毫无探索心智可言的 CRUDboy 不谈,一个后端真的是要深挖的东西太多太多。
    后端语言和框架,这是个好的开始。
    网络,包括 HTTP 以及其他,任何一个网络话题都可以深挖。扩展开来可以从 DNS 开始到服务器网络性能到传输层链路优化,挖都挖不完。
    数据库,CRUDboy 分分钟遇到各种性能墙。尤其是大数据情况下。
    常用基础中间件,项目里随手用个三五种不稀奇,都得懂。
    容器化、DevOps 、云服务、监控报警,大部分知识都和服务器各个环节有关。
    安全,后端的安全要求比前端更高更全面。
    性能挖掘,以上每个环节都有性能优化的空间,涉及了从算法到架构从服务配置到奇技淫巧大大小小各种东西。

    更别忘了还有那该死的业务领域知识。

    以上每个话题的子话题,分分钟埋进去一个专家。

    所以自从我从移动端开发转型技术架构以来,每个领域我最多学一种语言,还得按需排优先级排学习深度和广度。

    既然我已经学了 Java ,对不起,Kotlin 真的没空了。
    chrisia
        76
    chrisia  
       2022-12-14 12:34:49 +08:00
    因为太难
    Pantheoon
        77
    Pantheoon  
       2022-12-14 12:51:57 +08:00
    上家公司用的 kotlin 做的后端,kotlin 本身就是基于 java 的语言,类似可以理解成 java 的二次封装,将 java 很多没有的语言特性给封了进去,所以在生态上,它是和 java 能统一的,java 能用的它都能用,选择 kotlin 其实就是选择了它的语法糖,个人感觉 kotlin 的优势如下:
    1.更强大的函数式编程,比如拓展函数,中缀函数,这些使用起来确实比 java 的伪函数式编程顺手很多,而且它的使用习惯也更贴近一个人正常的思考方式,当然也存在它的缺点,如果对函数式编程一点都不懂的,或者用的很少的同学会有学习成本.
    2.空指针处理,这点我特地把它单独拿出来说,可以说是 kotlin 很大的一个特性,java 当然也有空指针处理,但是对比 kotlin 简直差的太远
    3.文件组织方式,相对于 java9 里面用模块来组织文件,kotlin 用 kt 文件,这样的话相同模块的一些功能可以全部写到 kt 文件里面,会减少很多 java 类的出现,最最最常见的就是 dto 和 vo 这些数据 model,其实单独写一个类很没有必要,组织进 kt 文件,会让项目看起来更简洁也更容易维护
    4.协程,这个东西对于后端来说就是一个线程池,只要把方法写进 launch 里面就可以异步,但是对于客户端的同学来说,帮助会更大,因为涉及到线程切换的问题,kotlin 已经完全封装好了
    5.其他一些特性,比如密封类,数据类等等,都在实际项目中用的很多,尤其是数据类,基本就是用来写 dto 和 vo

    以上提到的一些特性,java 也都能处理,比如函数式编程,它也可以通过自定义接口的方式来实现,协程也可以用线程池来搞,当然它都处理回调的问题,数据类其实就是一个普通的 class,所以当有一个给你封装好了的语言,能够优雅的解决这些问题,为何不尝试以下呢?唯一的问题就是学习成本,kotlin 其实学习成本并不高,难以理解的也就函数式编程和协程,其他特性都是一眼会的那种,建议真的可以尝试下.最后说一句,jetbrain 出品,必属精品
    ayayui
        78
    ayayui  
       2022-12-14 12:58:43 +08:00
    个人看法,替 Kotlin bb 两句:
    Java 其实越来越像 Kotlin 了,比如现在加的 var | Record class | switch 增强等等
    Kotlin 只是个选择,互操作、空安全、协程、扩展函数等,对 Java 来说是个不错的选择;少些不少代码不是;至于可读性见仁见智吧
    Kotlin 并只是个语法糖,把.java Ctrl+Shift+Alt+K 转完就完事了, 写 idiomatic Kotlin 是需要点学习和练习的
    Kotlin 并不是完美的,有些语法也怪怪的,现在摊子也大了,不知道以后咋样,

    总之,Kotlin 还不错,值得一试; C# 这么 NB , 不也是曲高和寡;
    Torpedo
        79
    Torpedo  
       2022-12-14 13:13:37 +08:00
    @Leviathann 根据我 7 年的和后端合作经验,首先各个语音都有水平高的。

    但是只有写 java 遇到过多次。你和他定协议,讲个 http header 啥的,然后他给你讲 spring 没有对应的注解、功能、拦截器没有 xxx 。或者有对应的,他不知道怎么用。还有对 json 字段,直接甩我一段 java 代码
    给我的感觉就是 java 水平不够的,完全就是面向框架编程

    相反,别的语言后端讨论的时候,大家都只聊 http 协议或者 json 的接口格式就行了。基本不会让我一个前端知道他用的啥,怎么实现的
    lchynn
        80
    lchynn  
       2022-12-14 13:34:31 +08:00
    @zapper scala 和 groovy 呢?
    wuyiccc
        81
    wuyiccc  
       2022-12-14 13:45:30 +08:00
    我感觉,java 服务端开发,有时间学 kotlin ,不如学下 c++/go
    magicZ
        82
    magicZ  
       2022-12-14 13:52:31 +08:00   ❤️ 2
    建议大家学学 scala, 还能搞搞大数据,学 kotlin 性价比太低。
    humpy
        83
    humpy  
       2022-12-14 13:59:49 +08:00 via iPhone
    我是实际用 kotlin 写过项目的,同楼上其它朋友一样,基本上只有它的 nullable 语法让我喜欢,其它都无感。
    最主要不喜欢的点是它语法糖太多了,代码看着头疼。而且 idea 运行的时候也没 java 流畅,整体的使用体验不太舒服。
    Slurp
        84
    Slurp  
       2022-12-14 14:01:12 +08:00
    🤔 Kotlin 都算心智负担重,语法糖多。算是知道当今程序员的平均水平了。难怪尬吹 Go 的这么多。大多数人还是适合写无泛型、无宏、无抽象的 CRUD 吧。
    urnoob
        85
    urnoob  
       2022-12-14 14:01:15 +08:00
    @Torpedo
    因为甩给你的 java 代码很好的包含 json 格式数据没有的信息。比如最重要的字段名称,数据类型。要一个包含所有字段的样例数据或者 json schema 是多么浪费的事情。
    Akitora
        86
    Akitora  
       2022-12-14 14:03:36 +08:00
    用 go 组织项目感觉各种不爽后现在用 kotlin 觉得很香
    urnoob
        87
    urnoob  
       2022-12-14 14:09:44 +08:00
    自从 java 8 后 在语言特性上 stream 和 lambda 是不错的,但是大量使用,嵌套使用就是阅读 维护的灾难了。最大的败笔是加入了 var 以后满屏的 var 真是地狱。
    还好有 idea 之类的 IDE 能给你显示对应的类型,方便你阅读,调试。
    换到 C/C++上,你在 sourceinsight VScode 之类的编辑器上去看 还不被恶心死。来个 coredump 用 gdb 调是真累。
    t6gfx4ddv3
        88
    t6gfx4ddv3  
       2022-12-14 14:10:23 +08:00 via Android
    在我看来 kotlin 不只是高糖 java ,感觉已经离不开 data class 、sealed class 、协程、函数参数默认值、扩展函数等特性了,以至于后面用到 dart 和 flutter 的时候非常不适应,看到推上吹 dart 比吹 rust 的还厉害突然陷入了迷惑。
    不愿换到 kotlin 的大部分原因应该还是招人难,特别是小公司,之前亲身经历因为写 kotlin 的人离职后招不到人,组长甚至开始用 java 重写才写了几个月的 kotlin 代码。。。
    大多数人还是更愿意呆在舒适圈里,对新语言新框架抱有抵触情绪。当看到有人说用 kmm 不如用 rust 时,顿时理解那些不愿换到 kotlin 的人,与其在语言和框架里辗转,不如把自己熟悉的学好学精。我也是不知不觉就把这个当做理由麻痹了自己,去年就想学的 rust 到现在连 rust book 都没看过几章,kotlin 、java 水平也没见长进,只能说真是服了自己,想学东西的时候真不能给自己找什么难学没用之类的借口。
    zzzzzzZ
        89
    zzzzzzZ  
       2022-12-14 14:25:41 +08:00
    @flyingghost 👍🏻

    22 年冬月还在争语言优劣的一律视为巨婴,除非你今年才高一
    witcherhope
        90
    witcherhope  
       2022-12-14 14:49:44 +08:00   ❤️ 2
    如果现在还不明白语言只是一个工具,只能说作为开发眼界有点窄
    hewiefsociety
        91
    hewiefsociety  
       2022-12-14 15:22:36 +08:00
    个人感觉不好用
    yazinnnn
        92
    yazinnnn  
    OP
       2022-12-14 15:23:56 +08:00
    @witcherhope

    ---
    举例来说,假设你需要写一个软件。你的经理根本不懂这个软件的运作机制,也不知道各种编程语言有什么区别。但是,他竟然明确要求你一定要使用某一种语言进行开发。没错,他就是要求你一定要用 Java 语言。

    为什么他会提出这种要求?让我们看看他脑袋里是怎么想的。他的想法无非就是,Java 是业界的标准。我知道肯定如此,因为媒体对此有铺天盖地的报道。既然它是标准,那么使用它就不会错。另外,这也意味着人才市场上肯定有无数 Java 程序员,即使现在为我打工的这批人都辞职了(真奇怪,这种事情总是不断发生),我也能够轻易地找到替代者。

    嗯,这听起来也不无道理。但是,它的前提是一个没有说出口的假设,而这个假设实际上是错的。你的经理相信所有编程语言的功能都差不多,可以互相替代。如果这种想法是对的,那么他要求你用 Java 编程就很合理了。反正编程语言之间没有区别,那么就用大家都在用的那种语言吧。

    但是,编程语言是不一样的。就算不探讨各种语言之间的具体区别,我也能向你证明这一点。回到 1992 年,如果你问经理使用什么语言开发软件。他会像今天一样毫不迟疑地回答说 C++。如果所有编程语言都一样,为什么答案变了?进一步说,为什么 Java 语言的设计者要如此麻烦地去创造一种新语言呢?

    一般来说,如果你动手创造一种新语言,那是因为你觉得它在某些方面会优于现有的语言。Java 语言之父詹姆斯·戈斯林在第一份《 Java 白皮书》中说得很清楚,之所以要设计 Java ,就是想解决 C++的一些弱点。所以结论就是,各种编程语言的编程能力是不相同的。如果你接受你的经理的假设,然后一路追溯到 Java 语言的源头,就会得到与他的假设完全不同的结果。

    到底谁对?戈斯林还是你的经理?结果当然是意料之中的,戈斯林是正确的。某些情况下,一些语言就是比另一些语言更出色。可是这样一说又导致了另外的问题。C++不适合解决某些难题,所以 Java 才被设计出来。那么,什么情况下应该使用 Java ,什么情况下应该使用 C++呢?会不会某些情况下其他语言比它们更合适呢?

    ---

    paulg 姑且也能算个开发吧?他的眼界在程序员群体中能排第一不?
    muchenlou
        93
    muchenlou  
       2022-12-14 15:30:38 +08:00
    语言只是我生存的工具,我喜欢的还是躺平。
    yannxia
        94
    yannxia  
       2022-12-14 15:52:10 +08:00
    写过一段时间 kt ,后来使用高版本的 Java 之后就不用了,没有感觉特别大的优势……
    其实自从我升级到 11 ,能用 var 关键字之后就已经好很多了。
    leonshaw
        95
    leonshaw  
       2022-12-14 16:11:16 +08:00
    @yazinnnn #92 老板要的是实现业务需求,你所说的语言功能是啥?
    yazinnnn
        96
    yazinnnn  
    OP
       2022-12-14 16:17:15 +08:00
    @leonshaw
    我什么都没说,这话是 Paul Graham 说的

    我对"语言只是一个工具"这个观点没有看法,我只是觉得不认同这个观点等于眼界差也太扯淡了


    下面的话也是 paulg 说的

    ---
    一旦你开始思考这个问题,就会发现它非常棘手。如果你的经理被迫去想这个问题,当他看到它的复杂性时,脑袋恐怕都会爆炸。如果所有语言真的都一样,那么他只需选择一种看上去获得大部分人拥戴的语言就可以了,因为这实际上是一种流行风尚,而不是技术问题,所以即使像你的经理这样对技术无知的人也有可能轻松得到正确答案。但是,如果语言各有不同,你的经理就会突然发现,有两个互相关联的方程,他必须找到一个能够同时满足两个方程的最佳解,而最要命的却是他对此根本一无所知。第一个方程是找到(相对于要解决的问题)能够适用 20 年左右的最佳语言,第二个方程是(为这种语言)找到合适的程序员、函数库的机会有多大。如果假定所有语言都不同,就会遇到这种苦苦求解的情况,所以难怪你的经理不愿意接受这个假设了。

    认为所有语言都一样的看法的缺点是自欺欺人,但是优点是可以使许多事情变得很简单。我想这就是为什么它被广泛接受的主要原因。它是一个令人舒服的想法。
    ---
    leonshaw
        97
    leonshaw  
       2022-12-14 16:41:51 +08:00
    @yazinnnn 现实情况没有这么复杂,大部分业务场景轮不到语言层面做决定。与其说是选择语言不如说是选择生态,而生态和流行程度是正相关的。20 年后的主流很难把握,也许现在还没出现,也许还是 Java ,考虑这些就是在赌。
    lengyuqu
        98
    lengyuqu  
       2022-12-14 18:13:52 +08:00
    你说 jvm 语言,一届一届换了多少种语法糖了?改过不啦?换汤不换药啊!人家协程也有理由说的,我出名的是什么语言,我带的 golang 。你这批语言是什么执行环境啊?你叫我带!

    jvm 现在什么水平?就这么几个语言,你什么 kotlin 的都想做后端,他能做吗?做不了。没这个能力知道吗?

    再这样下去 Groovy 也要做后端,kotlin 做完 Groovy 做,再 Scala 做。
    liyafe1997
        99
    liyafe1997  
       2022-12-14 18:27:09 +08:00 via Android
    2022 年,使用 kotlin 的理由有哪些?或者说它能解决哪些问题?
    exploreexe
        100
    exploreexe  
       2022-12-14 20:59:01 +08:00
    看了 LS 几位的回复,说的挺好的,学 kotlin 不如学点别的,JAVA 又不是不能干,没啥意义。
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5358 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 36ms · UTC 05:50 · PVG 13:50 · LAX 22:50 · JFK 01:50
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.