前言
這是我之前在知乎上的一些回答的匯總，感覺還是博客園寫這些東西方便一點，也算是理下我的一些思路，現將文章整理后，發布在園子里。
為何是kotlin:
很多人對kt沒有一個正確的定位,可能大家第一反應是拿它去和scala,groovy比較.
從語法的角度而言,kotlin豐富且嚴謹到恰到好處的語法糖,表達能力強但不啰嗦,極少的代碼冗余。
但老實講能做到這些的語言也不算少，單看語法，事實上kt比scala還是要略差一籌的，
他們都是非常優秀的jvm語言,總體來說是難分伯仲,kt也沒辦法將他們甩出一個身位.
但我必須得說,絕大部分情況下(指常規開發),如果你選擇kt作為你的第二jvm語言,比用scala,groovy等,
開發工程中的收益要多的多的多...成本亦低的多的多的多(注意我不是單單在說語言層面了)
首先，最重要也是讓kotlin與其他jvm語言有本質不同的地方在於：無縫和java程序的銜接以及極低的交互成本。
- 老項目想嘗新？在maven或gradle里面加個配置，就能開寫kotlin了.
- 不敢直接用？先用來寫UT啊,UT寫順了，你自然會忍不住想繼續寫。
- 已有java代碼怎么辦？直接用啊，封裝都不用，兩者可以直接調用，智能提示也都在，反過來kotlin寫的庫java同樣能用。
kotlin的一些典型特征:
靜態強類型
這個不多說，java，C#，kotlin都是典型，稍微上點規模的項目，都應該用靜態強類型來打底子。TypeScript越來越火也可見一般。
當然我不是說靜態就優於動態，這是看場景的，比如需求相對復雜和穩定的后端和隨業務迅速迭代的前端，他們的技術訴求肯定就不一樣。
比如做gateway，我就覺得動態類型的語言更適合，參考阿里的node.js使用場景。
學習成本
其實大家回憶下學習語言的過程,是花在語法上的時間多,還是花在熟悉標准庫上的時間多?
而kotlin則完全沒有后者的成本,time還是用的joda,http還是Apache的HttpClient,或者OkHTTP，
也會糾結netty，tomcat，akka 的方案選型，同樣需要注意集合類的時間復雜度和線程安全情況。
可以說在熟悉java生態的前提下學習kt，成本是非常低的。
其實我給人安利時候，一般給C#的人說Kotlin，就是“jvm屆的C#”
給Java的人說：“你別把它當新語言，你就把他當Java9”，當然9現在已經發布了，我可以換成10了，哈哈。
學習新語言總是會給人帶來一些壓力，但也要注意語言和語言之間的學習成本的不同，
我曾開玩笑說：我學習scala（入門）花的功夫，足夠我學會js，php，python這三門語言了。
而kt的低成本高收益，才是我對它如此推崇的最大原因。
生態支持
最后,也是最重要的優勢:jetBrains爸爸全方位無死角超貼心的配套支持
(畫外音:用過Resharper,IDEA,WebStorm,PyChrome的朋友,讓我看到你們的雙手!!)
熟悉jetBrain的朋友,應該能夠感覺到,這是一家非常有特色和魅力的公司,其在ide和pl工程領域的積累,大家應該也心里有數.
j系ide都有一個特點,就是對開發者極其友好,
基於語法(AST?)而非文本的代碼分析,帶來的超高的智能提示准確率和極度便利的重構,
對可能的異常代碼的警告和解決方案的提示.jetBrains總是傾向於讓開發者寫出嚴謹又簡潔且魯棒的代碼。
幸運的是,kt也繼承了爸爸的這些特質,不僅僅是語法的嚴謹,還體現在了開發過程中。
比如maven配置,java交互,nullable的注解提示,idea配套插件.
而且kt是他們內部很早就立項的語言，他家的各路ide都是用kt寫的。
各種插件個ide的支持，基本可以和語言版本同步迭代。
說了這么多文字,且廢話占多數,想必大家也有點煩了,那我下面就以java和kt的比較為切入點,介紹一些kt的特點吧。
其實就是過一遍 Kotlin/kotlin-koans,建議有興趣的可以clone個玩玩。
val 定義的變量不可變
var 同C#,val和var都是隱式強類型推斷,
val的作用在於,我前面定義一個orderState,即表示,這個變量就只做取值用途,你別再拿來干別的事情了,避免了一值多用的bad small.
默認參數,及參數名傳參:
減少無意義多態的使用,但又比js的一值多用直觀的多.
labmda寫法改進
必須在一個花括號中,如果以lambda為參數,可省略(),看起來很舒服
如果只有一個參數,則可以省略聲明,用it代替,(同scala的 _ )
scala的一個參數對應的_只能出現一次,第二個_代表第二個參數,更簡潔的寫法但帶來更模糊的語義,孰優孰劣不談,但兩者的風格差異在這個細節中可見一斑.
nullable
kt對null pointer 問題非常敏感,任何可能的npr都需要顯示的處理,如果不處理,nullable會一直往后傳染並給出一個警告,
這時候你要么用!!表示我tm確定這里肯定不為null,要么用?:表示如果為空,則表達式的值為后面提供的缺省值. 這個設計基本和C#那邊的一樣
tems是訂單詳情的集合,詳情包含ActualWeight,但未發生實提則為null,如果是傳統寫法,需要先判斷find出來的是否是null,再判斷這個find是否有實提,如果有則返回實提,沒有則返回double 0(lambda可省略return)
大家可以體會下這省了多少工夫?
擴展方法,
這是我覺得所有靜態語言都應該提供的特性,原理非常簡單,但帶來的寫法上的優化非常有價值
kt和C#擴展方法原理大致類似，就是this作為第一個參數傳給靜態方法的一個語法糖，但kt不要求強制定義在一個靜態方法中
表示所有的string實例,在lastChar的可訪問范圍內,都多了一個成員函數,其實就是
static StringHelper.lastChar(str:String)
的變種,在不支持em的java看來,就長剛才這個樣子,用起來就是如下形式:
H3.em3(H2.em2(Helper1.em1(what)))
low爆了是吧? 下面是我封裝的一個操作poi的代碼
next是移動到下一單元格,設置樣式是復制第一行的樣式,其實還可以封裝,為了顯示表達出我的操作意圖,這里就留着了.
說到這里就差不多了,再說也就是抄襲koans,也沒啥大的意思了,最后扯點其他的作收尾吧.
談一談我對語法糖的看法:
我個人對語法糖的評價是非常高的,也許這個糖的原理並不復雜,比如我之前提到的擴展方法,但我們認識它的原理是遠遠不夠的,還得理解,為什么要有這玩意.
H3.em3(H2.em2(Helper1.em1(what))) VS what.em1().em2().em3()
上面后者省略了import H1 H2 H3的過程,綜合起來工作量也沒差太多
但真的就僅僅是寫法和視覺上的優化嗎?其實遠遠不止.
前者是,XXHelper里面有個方法,可以操作what這個類型並做一些事情,
后者是,what既然有這樣的特質,那么它就應該擁有某樣的能力
前者是思維先找到Helper,再找到具體方法,
后者是what自然而然的提示出,what就有這樣的能力(ide的智能提示),我敲下what+ . 后,它的能力就展示在我面前了,而不需要我還去翻箱倒櫃的找helper方法.
談談激進技術的風險和收益,與不同階層人員關注點的不同.
我最早推進kt的時候,最大的阻力就是來自公司的架構師團隊,他們的關注點是:
kt相比java,能提高性能嗎?(不能,kt的性能與java極度接近但略小與java)
kt解決了什么java並不能解決的問題嗎?(沒有,kt只是讓你更快更好的寫java代碼)
kt能減少項目bug,提高項目穩定性嗎?(某種程度上來說有一定幫助,但更多是看人,這理由也不夠強力)
那時候我只是個開發 leader,這種層面肯定是沒有太大的決策權的,他們的想法我也理解,公司幾百號開發,提高一點點效率,相比引入新技術棧的風險,肯定是穩定壓倒一切啦.
后面在我的爭取下,我在一個簡單項目上少量使用kotlin作為試點,后來一些原因我離開了這個公司,去小公司當技術合伙人去了,現在那段kotlin代碼應該還跑在公司的tomcat上面,其他人不去翻代碼,他們也不會知道這是用kotlin寫的吧?