為何是Kotlin:

很多人對Kotlin沒有一個正確的定位,可能大家第一反應是拿它去和scala,groovy比較，從語法的角度而言,kotlin豐富且嚴謹到恰到好處的語法糖,表達能力強但不啰嗦,極少的代碼冗余。

但老實講能做到這些的語言也不算少，單看語法，事實上Kotlin比scala還是要略差一籌的，他們都是非常優秀的jvm語言,總體來說是難分伯仲,Kotlin也沒辦法將他們甩出一個身位。

但我必須得說,絕大部分情況下(指常規開發),如果你選擇Kotlin作為你的第二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生態的前提下學習Kotlin，成本是非常低的。

其實我給人安利時候，一般給C#的人說Kotlin，就是“jvm屆的C#”

給Java的人說：“你別把它當新語言，你就把他當Java9”，當然9現在已經發布了，我可以換成10了，哈哈。

學習新語言總是會給人帶來一些壓力，但也要注意語言和語言之間的學習成本的不同，

我曾開玩笑說：我學習scala(入門)花的功夫，足夠我學會js，php，python這三門語言了。

而Kotlin的低成本高收益，才是我對它如此推崇的最大原因。

生態支持

最后,也是最重要的優勢:jetBrains爸爸全方位無死角超貼心的配套支持

(畫外音:用過Resharper,IDEA,WebStorm,PyChrome的朋友,讓我看到你們的雙手!!)

熟悉jetBrain的朋友,應該能夠感覺到,這是一家非常有特色和魅力的公司,其在ide和pl工程領域的積累,大家應該也心里有數.

j系ide都有一個特點,就是對開發者極其友好,

基于語法(AST?)而非文本的代碼分析,帶來的超高的智能提示準確率和極度便利的重構,

對可能的異常代碼的警告和解決方案的提示.jetBrains總是傾向于讓開發者寫出嚴謹又簡潔且魯棒的代碼。

幸運的是,Kotlin也繼承了爸爸的這些特質,不僅僅是語法的嚴謹,還體現在了開發過程中。

比如maven配置,java交互,nullable的注解提示,idea配套插件.

而且Kotlin是他們內部很早就立項的語言，他家的各路ide都是用Kotlin寫的。

各種插件個ide的支持，基本可以和語言版本同步迭代。

說了這么多文字,且廢話占多數,想必大家也有點煩了,那我下面就以java和Kotlin的比較為切入點,介紹一些Kotlin的特點吧。

其實就是過一遍Kotlin/kotlin-koans,建議有興趣的可以clone個玩玩。

val 定義的變量不可變

var 同C#,val和var都是隱式強類型推斷,

val的作用在于,我前面定義一個orderState,即表示,這個變量就只做取值用途,你別再拿來干別的事情了,避免了一值多用的bad small.

默認參數,及參數名傳參:

減少無意義多態的使用,但又比js的一值多用直觀的多.

labmda寫法改進

必須在一個花括號中,如果以lambda為參數,可省略(),看起來很舒服

如果只有一個參數,則可以省略聲明,用it代替,(同scala的 _ )

scala的一個參數對應的_只能出現一次,第二個_代表第二個參數,更簡潔的寫法但帶來更模糊的語義,孰優孰劣不談,但兩者的風格差異在這個細節中可見一斑.

nullable

Kotlin對null pointer 問題非常敏感,任何可能的npr都需要顯示的處理,如果不處理,nullable會一直往后傳染并給出一個警告,

這時候你要么用!!表示我tm確定這里肯定不為null,要么用?:表示如果為空,則表達式的值為后面提供的缺省值. 這個設計基本和C#那邊的一樣

tems是訂單詳情的集合,詳情包含ActualWeight,但未發生實提則為null,如果是傳統寫法,需要先判斷find出來的是否是null,再判斷這個find是否有實提,如果有則返回實提,沒有則返回double 0(lambda可省略return)

大家可以體會下這省了多少工夫?

擴展方法,

這是我覺得所有靜態語言都應該提供的特性,原理非常簡單,但帶來的寫法上的優化非常有價值

Kotlin和C#擴展方法原理大致類似，就是this作為第一個參數傳給靜態方法的一個語法糖，但Kotlin不要求強制定義在一個靜態方法中

表示所有的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方法.

談談激進技術的風險和收益,與不同階層人員關注點的不同.

我最早推進Kotlin的時候,最大的阻力就是來自公司的架構師團隊,他們的關注點是:

Kotlin相比java,能提高性能嗎?(不能,Kotlin的性能與java極度接近但略小與java)

Kotlin解決了什么java并不能解決的問題嗎?(沒有,Kotlin只是讓你更快更好的寫java代碼)

Kotlin能減少項目bug,提高項目穩定性嗎?(某種程度上來說有一定幫助,但更多是看人,這理由也不夠強力)

那時候我只是個開發 leader,這種層面肯定是沒有太大的決策權的,他們的想法我也理解,公司幾百號開發,提高一點點效率,相比引入新技術棧的風險,肯定是穩定壓倒一切啦.

后面在我的爭取下,我在一個簡單項目上少量使用kotlin作為試點,后來一些原因我離開了這個公司,去小公司當技術合伙人去了,現在那段kotlin代碼應該還跑在公司的tomcat上面,其他人不去翻代碼,他們也不會知道這是用kotlin寫的吧?