Kotlin 的缺點
- compile 會有點慢，慢 30% 吧
- IDE 有時候會頓頓的
- 然後和 Spring cglib 混合時，開發階段有時會有靈異現象。(有一段 code 居然不會被呼叫… 不管 rebuild 幾次都沒用，重開機才會好…)
上面是比較困擾的小問題，但如你說見，都是 tooling 相關的。語言本身反而沒有遇到什麼障礙。tooling 的話就是隨時間會慢慢改進。
Scala 把 collection 標準函式都翻了，所以轉來轉去很煩，還用一些 implicit 去轉，越補越大洞。Kotlin 它的 std library 有夠小的，Java 有的通通都沒有翻，用 kotlin collection 就是順順順。你可以感覺就是用另一個 sugar 語言寫 Java 而已，寫出來的成品還是 Java。
至於效能面我還沒評估，但我也不太擔心就是，JVM 本來就超快，可以容許你寫沒效率的程式。如果未來遇到 bottleneck 就那段用 Java 重寫就好了。
要學 kotlin ，不會太難學，但也要一段時間才能寫出有 kotlin 味道的程式，但是比學 scala 快多了。
學 kotlin 最快的方式是安裝 kotlin-koan1 plugins ，然後花一個下午走一遍，就會對 kotlin 很有感覺，也算是有了初步的評估。
團隊要導入就是:
- 安排一個下午大家一起寫 kotlin-koan，一起討論
- 隔天開始從 unit test 開始改起
- 一週後沒人會再想寫 Java :-)
Android 的新的開發架構指南。
基本上有用 RxJava 的話，LiveData 和 Life cycle 可以跳過，是一樣的東西。
Room 這個 persistent library 看起來不錯，最少 query 時是自己寫 sql。開發者也不用再煩惱該選哪個 Android ORM 了，選這個官方的算長期飯票。
ViewModel 的話見人見智，如果有寫測試的話那大概很需要這個 pattern，如果沒有的話那多這一層有點煩…
自從 Kotlin 1.1 之後，它開始導入了 coroutine ，然後我就跳坑了。 原本冀望可以爽爽寫 async/await，不過看起來還太早。
不過寫了 kotlin 二、三個月下來，寫起來的確爽，超越我個人最愛的 Dart。現在就是什麼寫 Android 或是寫 Server 都是 kotlin 為主，不寫 Java 了。
Kotlin 也讓我對 ?, ! null operator 改觀，原本最早接觸這種 operator 是在 Swift，但我寫的很痛苦。不過在 Kotlin 裡就沒有類似的困擾，原因大概是從 Java 來的程式碼，不需要特別處理 ? 吧。這個決定是比較正確的。
因為我們還在導入的前期，目前 Kotlin 用的功能不多: null operator, data class, collections 三者是最常用的功能，而 extension 是遇到 Android API 太爛才會去用。另外，.let{}, .apply{} 這幾個小工具真是讓人愛不釋手，可以預想未來其他語言會開始模仿類似的功能。
嘛，之後還要慢慢挖掘更多 kotlin 的進階功能。
如果你寫 Java 會動用到 lombok1 或是 AutoValue2 這種改造 Java 語法弱點的工具，那直接跳 Kotlin 吧，不要再浪費時間了。
不過，開發 Mobile 我個人的美夢是 Flutter ，而不是 swift/kotlin。後者兩個語言再好，也解決不了平台 API 太難寫的問題。而且開發 Mobile 要寫兩份程式實在太傷太傷了…
- Gradle - checked
- Spring 5 - checked
- Android - checked, finally
不用猜也知道 Java 界未來五年都是 kotlin 的天下了，所以這其實沒什麼好討論的。
Kotlin 未來的真正挑戰是如何跨出 Jvm，也就是 kotlin-native, kotlin-js 等計畫，kotlin 還想跑在 iOS 上咧！
不過基本上我不樂觀就是，跨 eco-system 是很困難的事，因為各家的用戶都很保護 (挺) 自家的平台，不喜歡外來種，即使自家的語言一堆缺點…
你可以繼續用 obj c 寫啦, 反正 apple 自家的程式全部是 obj c. 死不了的
但寫 app 要看 library 多不多, 新不新, 還有你找開發者的話, 死守 objc 你可能招不到寫 swift 的人...
語言沒問題, 只是去寫 server 的話, 生態系沒起來, 還要擔 break change 的風險.
寫 server 很多選擇, 沒必要像 ios 一樣只能選一種
swift 3 只有說之後會有 ABI 相容1 。
但 swift 4 仍然保留了可能會 break change 的說法。
不過我覺得可以入坑了，之後改的會越來越少吧。而且你寫 iOS 的話一定要會用 swift，因為新的 library 可能都只有 swift 版了，不能再等。
然後處理 break change 是工作的一部份，躲也躲不掉的。回報給你上級，說這是 iOS 開發成本的一部份。說實在的，Apple 把語言設計錯誤的責任轉嫁給用戶 (開發者)，實在是不可取。
如果不是寫 iOS 就不要碰 Swift 了，浪費生命。
我 android 蠻順的啊，只覺得動畫的速度太快而已。
flutter 能夠接受用 material design 的 UI 就能採用。不過現在還早的很，至少要開始看到 Google 本家的 app 開始用 flutter 改寫才算數 (google map, photo, youtube... etc)
嘛，Google 打的算盤是 -- 可以開始用同個程式產生兩大平台 Android, iOS 的 app，然後之後可以 native 的跑在 ChromeOS 上，而那時的 ChromeOS 可能已經蓋在 Fuchsia 上了。最後的最後則是 Web。
iPhone 剛出時，微軟/Blackberry 紛紛取笑 Apple，結果 iPhone 打趴所有做手機的。
AppleWatch 剛出時，這次錶商就挫咧等，結果 AppleWatch 節節敗退。
有人說 smart watch 電量撐不到一天是致命傷，可是在 iPhone 之前手機的待機時間也是一週以上啊，智慧手機撐不了一天還不是襲捲全球…
結論：成功無法複製，即使已經是超級成功的事業。
復活的咒文是 日文五十音去 encode 過關和參數的 flag。新一代的怎麼可能放的下？我猜大概 XI 代應該是資料存到雲端而已，咒文只是 key (看沒網路的時候能不能用就知道… )