❶ 如何學習Kotlin編程語言
為什麼說 Kotlin 是優秀的
本文不會像一碰頌般介紹語言的文章那樣，一開頭就羅列出語言那些酷炫的特性，我們稍後再來探討這些內容。
首先我將介紹一些其它的信息，因為2013 年一項研究顯示，當開發者評估一種編程語言時生態系統要比語言特性更重要。這符合我個人的經驗，下面就讓我開始介紹吧：
Kotlin 被編譯成 JVM 位元組碼或者 JavaScript 代碼。Java 開發者將會是對它最感興趣的人，不過對於使用垃圾收集運行時語言畝信的開發者而言它也具有一定的吸引力，比如 Scala、Go、Python、Ruby 和 JavaScript 等語言。
Kotlin 來自業界，而不是學術界。它解決了開發者現今面臨的實際問題。例如它的類型系統可以幫助你避免空指針異常。
切換到 Kotlin 無需成本！它是開源的但這不是重點，重點是它提供了一個高質量的一鍵從 Java 轉換到 Kotlin 的工具，並且十分關注 Java 二進制文件的兼容性。你可以將現有 Java 項目的一次性轉換成 Kotlin 項目，而該項目仍將可以正常編譯，即使這是一個包含上百萬行代碼的復雜程序。
顯然你可以從上文得知，Kotlin 程序能夠使用所有現存的 Java 框架和庫，甚至那些依賴註解處理的高級框架。它們之間的交互是無縫的，不需要包裝或者適配層。Kotlin 可以整合 Maven，Gradle 以及其它構建系統。
它十分平易近人，語法精煉直觀，僅僅是閱讀語言參考文檔幾個小時就能學會使用。Kotlin 看起來十分像 Scala 但是更加簡潔並且兼顧了可讀性。
它不遵循特定的編程哲學，例如極度的函數式編程或者面向對象編程風格。
它不會增加運行時的開銷。Kotlin 的標准庫十分小巧緊湊：專注於擴展 Java 標准庫，編譯階段的大量內聯操作意味像 map/filter/rece 等管道結構函數將被編譯成類似於命令式語言的代碼。
Anko 與 Kovenant 等框架的出現意味著在 Android 開發者中 Kotlin 開始變得流行起來。如果你正在從事 Android 相關的工作，相信你笑耐鄭很快就會獲得好的工作。你可以閱讀這份 Square 公司開發者 JakeWharton 的報告，了解用 Kotlin 進行 Android 開發的體驗。
Kotlin 允許你繼續使用你的工作效率提升工具。IntelliJ 的 IDE 對 Kotlin 的支持十分完善：你可以對代碼進行重構、搜索、導航以及使用自動完成，而且 IDE 充分支持調試、單元測試、性能分析等等功能。
除了 Android，我認為 Kotlin 還非常適用於企業中 Java 的應用場景。如果你的工作是整天埋頭於大公司的代碼庫中，那麼當 Kotlin 1.0 版本正式發布時你應該盡快去了解一下：
由知名公司為它提供強大的商業支持。 JetBrains 這家公司 有一個高度稱職的大團隊致力於該項目，有穩定的商業模式甚至在自己的部分旗艦產品中使用 Kotlin，這表明短期內 Kotlin 不會被放棄。
使用 Kotlin 風險較低：可以由一兩個感興趣的團隊成員在項目中小范圍的試驗 Kotlin，這並不會擾亂你的項目，因為 Kotlin 的類對外提供的 Java API 看起來就與普通的 Java 代碼一樣。
因為 Kotlin 十分注重語法的可讀性，代碼審查不會成為問題，對 Kotlin 不熟悉的團隊成員仍然能夠完成該工作。
Kotlin 基於 Java 6，所以假如你難以在項目中升級使用新版本的 JVM，你可以使用 Kotlin。
今年早些時候我向 Swiss Re 這家瑞士再保險公司的團隊（他們使用 Java 和 .NET）展示了 Kotlin。首先我定義了一個簡單的 Java 類包含一些欄位以及 toString、equals、hashCode 等方法，大概有 50 行代碼。然後我將它轉換成 Kotlin 代碼（大部分是自動完成的），結果僅剩 1 行代碼，接著我還演示了其它節省時間的特性。他們看過後對 Kotlin 充滿了熱情並且認為 Kotlin 是它們項目中 C# 語言的一個潛在競爭對手。
我認為 Kotlin 正中企業 Java 開發者的紅心，所以盡管 Kotlin 是免費的，JetBrains 還是能夠通過它增加商業版本 IDE 的銷售來賺大錢。這將激勵他們根據用戶的意願持續改進它。
與此相比，對於那些由不相關產品資助的語言開發者來說，當用戶需求與之前的設計理念沖突時，他們很少會因此作出調整。
特性
Kotlin 作為一門新的編程語言能夠脫穎而出，是因為它關注生態系統：JetBrains 懂得生產力的高低更多的取決於生態系統而不是便捷的語法。
盡快如此，Kotlin 還是有許多有用的特性能讓你編碼的過程變得愉快：
我們已經提過 null 安全（可選），它能夠讓編譯器系統的標記潛在的空指針引用。與一些語言不同的是它不涉及 option 類，因此是零開銷的，並且還有其它語言特性確保它不會造成不便。
精煉的語法：無處不在的類型推斷、簡單的函數只需要一行、簡單的結構以及 JavaBeans 也只需要一行就能聲明、真正的屬性——可以在背後自動生成 getFoo/setFoo 方法用於與 Java 進行交互、函數可以獨立存在於類之外。
異常均為非檢查型。（譯者註：感興趣的可以閱讀一下Java 理論與實踐: 關於異常的爭論）
使用 data class 關鍵字創建數據類會自動生成通用方法，例如 equals、hashCode、toString 以及 和 componentN（同時聲明多個變數時會調用該方法）。這將幫助你在不使用構建器的情況下便捷的獲得不變類（immutable classes）。
但如果你需要構造復雜的結構體，藉助類型安全的構建器這個特性可以簡潔的實現。如果你使用 Google Protocol Buffers 來存儲結構化數據， 通過 KBuilders 這個庫也能很輕易做到。
支持函數式編程以及零開銷的 lambda 表達式，能夠在 Java 的集合中做 Map、Filter、Folder 等處理。Kotlin 的類型系統能夠自動識別可變或者不可變的集合。
擴展函數特性能夠讓你在不改動源碼的情況下為類添加方法。乍眼一看以為是為了避免寫出像 FooUtils 這種風格工具類的語法糖，不過隨著使用的加深，你會認識到它不僅能幫你更加容易的通過自動完成使用方法，還能協助你集成現有的 Java API 以及藉助其它 Kotlin 特性構建功能強大的擴展。
支持運算符重載，但是不會像 Scala 或者 Perl 那樣出現難以理解的代碼。運算符被映射成相應名字的方法，通過重寫這些方法改變運算符的行為（包括函數調用），但是不能定義新的運算符。這使得程序能夠兼顧功能與可讀性。
Kotlin 沒有宏或者其它的方式來重定義語言，但是通過這些精心設計的特性能夠使第三方庫自由的對它進行擴展，官方對集合類進行的擴展也只是小試牛刀而已，請看以下例子。
想使用 fibers、actors 和 Go 風格的 channels？一個名為 Quasar 的庫已經為你實現了。
使用 Markdown 替代 HTML 來編寫 API 文檔，這樣編寫 JavaDocs 可比以前舒適多了。（譯者註：JetBrains 提供了相應的文檔生成器 Dokka）
更好用的泛型。如果你沒有完全掌握泛型參數中 super 以及 extends 的含義，別擔心，這不是你的錯。Java 的泛型的確令人費解，Kotlin 解決了這個問題。
委託是一個大家都知道的設計模式，Kotlin 原生支持它。
== 運算符的行為符合預期（譯者註：簡單來說 a == b 相當於 a.equals(b)；新增了 === 運算符，用來判斷運算符兩邊是否指向同一個對象）
想快速便捷的進行非同步編程嗎？當然！
字元串插值「可以使用這樣的寫法在字元創中直接引用變數 {this.example}」
函數中的參數可以指定默認值、使用可變長度以及通過參數名傳參。
還有許多的調整與優化。假如 Java 中有某些讓你覺得困擾的問題，我相信 Kotlin 一定已經把它處理好了。
現在就來試用一下！
跟很多現代編程語言一樣，Kotlin 可以通過網頁瀏覽器來進行體驗。不過跟其他語言不一樣的是，Kotlin 的實驗網站提供了一個成熟的 IDE，包括響應很快的自動完成，實時的後台編譯，甚至還有在線的靜態分析！
在線試用一下吧
好了，讓我們繼續接下來的內容
目前存在哪些問題？
生活中沒有什麼是完美的，包括 Kotlin。以下是我嘗試這門語言時遇到的一些問題。
最大的問題是不夠成熟，因為 Kotlin 目前還處於 Beta 階段，這意味著：
每更新一個版本，語法、ABI 以及標准庫就變一次。好消息是這些變化通常比較微小，可以藉助 IntelliJ IDE 來自動升級你的代碼，所以這個過程並不會太麻煩。
Java-to-Kotlin 的轉換工具（J2K）還沒有完成。它偶爾會大規模的破壞和默默地擦除 Java 8 中的 Lambdas（修改：2015 年 10 月：M13 版本的轉換工具已經可以正確地處理 Java 8 的特性了）。由它轉換而成的代碼並不總是最好的寫法，但是 JetBrains 為這個工具付出了大量努力，它已經是我用過的語言轉換工具中最好的了。所以我並不太擔心這個問題，這個轉換器正在迅速的改進中，變得越來越成熟。
你會遇到編譯器錯誤。盡管我的程序並不大，但還是會發生無法編譯的情況，甚至錯誤的編譯結果。診斷這些問題並不難，但終歸還是影響了開發的體驗。
你會遇到 IDE 內部錯誤。當這個錯誤發生時，IntelliJ IDE 會彈出一個懸浮窗口，附帶向 JetBrains 報告的選項。大部分錯誤無需理會，不過依然會使人厭煩。
偶爾會出現無法載入提示文檔的錯誤（修改：M14 版本發布後，這個問題已被修復）
目前 JetBrains 正致力於完善發布 1.0 版本而不是添加新的功能，期待這些問題能夠得到修復。
第二個我遇到的比較大的問題是，有時與 Java 的交互會受到局限。
一個典型的 Bug 是 Java 的類型系統無法防止你改變 Map 中 Key 的類型。按理來說，這樣操作應該導致編譯器報錯，例如使用類型錯誤的 Key 刪除元素。有些 JDK 中的集合使用了泛型，它們某些重要方法的泛型參數是 Obejct，所以編譯器不會提示。當在 IntelliJ IDE 中編寫 Java 代碼時會有靜態分析的警告，但是目前 Kotlin 環境還沒有這個功能。因為 Kotlin 使用的是 Java 的集合框架沒有自己實現，所以這導致了一些類型安全方面的問題，我已經遇到好幾次了。
（修改：1.0 Beta 版本中這個問題已經解決了，Java 中集合框架的類型安全缺陷在 Kotlin 已經不復存在。喲呵！）
另一個例子是，當調用或使用 Java 代碼時 Kotlin 的 Null 安全特性無法發揮作用（可以藉助註解彌補）。作為 Kotlin 的初學者，剛開始你可能會寫許多調用 Java 庫的代碼，但是因為以上的問題它們並沒有你想像中那麼好用。這種情況的改善只能等待 Kotlin 使用人數的增長。JetBrains 一直在嘗試使 Null 安全特性能體現在 Java 交互中，這種想法是好的，但有時考慮並太周全。（修改: 從 M13 版本開始，在 Java 代碼中將自動以 @NotNull @Nullable 等註解實現 Kotlin 的 Null 安全特性）
雖然有以上的問題存在，但同時也使得我們能更流暢的使用 Java API，我覺得這種權衡是值得的，只是在開發中要注意。
其它需要考慮的問題:
Kotlin 的社區還比較小。雖然目前沒有多少 Kotlin 的庫可以使用，但是憑借優秀的 Java 交互能力，Kotlin 可以使用現有成熟的 Java 庫。
如果你喜歡看書來學習，那麼你需要等到今年晚些時候才能看到 Kotlin 開發者寫的書（譯者註：Kotlin in Action）
純粹的函數編程風格開發者可能會覺得類型系統中缺乏一些 Scala 或 Haskell 擁有的高級功能。如果你對類型系統一些功能比較看重，那麼 Kotlin 可能不適合你。
Kotlin 還能編譯成 Javascript 代碼，但是比較少用，所以可能會遇到更多的問題，這是我從論壇中得到的印象。（修改: 目前 Kotlin 的開發重心在於完成 1.0 版本並使其穩定運行在 JVM 中，Javascript 方面的問題將會在 1.0 發布後著手解決）
沒有標準的編程風格指南，目前 Kotlin 提供了多種語法可供選擇。不同人寫出來的 Kotlin 代碼很可能完全不一樣。這與 Go 嚴格的風格形成了鮮明的對比。（修改: Kotlin 1.0 版本開始，一些靈活的語法已經被移除了，例如現在重載運算符以及定義中綴函數時必須分別使用 operator 和 infix 關鍵字進行標記）
Kotlin 的編譯速度稍稍慢於 Java，以及 IntelliJ IDE 的智能提示反應有點緩慢，不算嚴重而且比 Scala 快多了。（修改：Kotlin 1.0 開始編譯速度有了明顯提升）
Kotlin 有一個 Eclipse 插件，但是很明顯沒有 IntelliJ 的好用。
Kotlin 在某些方面比 Java 要嚴格。它不會自動將 Int 轉換為 Long 類型，需要開發者顯示的轉換。這是因為 Kotlin 關注正確性和試圖解決《Java Puzzlers》一書中提出的問題。JetBrains 聲稱他們已經搞定一半了。
Kotlin 基於 Java 6，因此會受到它的局限。Kotlin 與 C# 在很多領域都很相似甚至比 C# 做得更好，但是它缺少一些功能，例如 Java 平台尚未支持的某些數據類型。
為什麼應該開始考慮使用 JVM
最近一段時間我遇到了很多使用動態腳本語言（JavaScript 或者 Go —— 譯者註：Go 應該是靜態編譯型語言）的創業公司。
我在 Bitcoin Space 工作的時候，使用動態語言是非常痛苦的事情。在這些語言里沒有安全性的類型，這已經導致了巨大的貨幣損失。Go 比較少出錯，但是在基礎層面上給人的體驗依然很差，比如說缺少好的調試工具，快速 GC 機制，穩健的管理器以及可靠的分析工具。
過去 15 年或者更長時間里，Java 變得越來越健壯，越來越冗長，甚至有過度設計的跡象，這些變化很大程度上源於它的聲譽。企業級 Java 類的名字 就是例證。在很長一段時間里我沒有考慮 JVM，我確信這種環境並不適合我。
最終我因為 Android 被迫回到 Java，發現 Java 的開發環境已經改變了。雖然 XML 仍然不合時宜的頻繁出現在各種場合，但是一些基礎功能十分完善，令人印象深刻。 IntelliJ 是比 Eclipse 更快並且更智能的 IDE。Maven 一出現就得到了迅速的發展，擁有許多原本我想要其它構建 / 依賴系統增加的功能。較新的 Web 框架像 Ninja 和 Play 從類似 Ruby on Rails 的框架中學到了輕量簡潔。有大量的庫可供使用。硬體性能變得更高以及 JVM 變得更有效率，等等轉變。
沒有真正改變的是語言本身，Java 代碼寫起來依然是令人不快的冗長。
現在有了 Kotlin，完全無需承受離開 Java 現有的生態系統的疼苦。你可以編寫更富有表現力的代碼，但是卻比腳本語言更簡潔，同時擁有更好的性能和更少的錯誤。
如果你喜歡 JavaScript，可以嘗試 Kotlin 的 JS 後端，或者在 Nashorn JS 引擎里運行你現有的代碼。
最後，如果你喜歡 Go 語言是因為它可以編譯獨立運行的程序，那麼試試 javapackager 工具。Kotlin 在本地為每個平台創建了捆綁包，這意味著在 linux 上不需要 JRE 的依賴就可以獨立自主的獲取 DEBs（linux 的安裝包）或者壓縮包。當然，它拆包之後不是單個文件而是單個目錄，從部署的角度來看並不難操作。
簡而言之：如果你之前因為看 Java 不順眼而忽略了 JVM 的生態系統，那麼你應該借著 Kotlin 這門新語言進入這個世界瞧瞧。
❷ kotlin可以連接mysql嗎
可以。但我會建議使用純JAVA。而不要去考慮Kotlin。否則，你將失去兩大優勢。
首先要搞清楚，kotlin與JAVA之間，其實並沒有任何關系。kotlin是那個做IDE的Jetbrains公司創造的語言，它只和intellij IDEA這個IDE有關系。只是這個IDE，會在編譯的時候，把kotlin轉換成JAVA代碼。所以kotlin無形中，便把使用者與這個IDE捆綁在了一起。而並不是與JAVA捆綁在了一起。
失去的第一個優勢，便是從此無法自由選擇IDE。。。對於kotlin來講，將永遠只有一個IDE可以選擇。用戶會成為Jetbrains公司的奴隸。如果有一天，你必須離開這個IDE，那你將會淪為廢物，因為如果沒有IDEA，kotlin無法做到任何事，哪怕僅僅一個「hello world」都不能。
失去的第二個優勢則更加致命，也是JAVA可以獲得成功的原因之一。。。JAVA能做的事情，其實很多其他語言也能做到。。但為什麼JAVA可以如此受歡迎？除了JAVA本身的強大之外，還有一個原因在於，JAVA與C#語言，幾乎是一模一樣的。只有非常細微的差別，不僅語法一樣，而且連編程思想都一樣。只要掌握其中一門，完全可以在幾天之內，無師自通另外一門。然後就可以對照api文檔，去開發另外一門語言的程序了。所以學習JAVA的一大亮點就在於「學一門，會兩門」。
C#很了不起嗎？沒錯，非常了不起。。它本就可以視作JAVA獲得成功的最大幕後英雄。。但我不是來講故事的，因此微軟與sun公司的恩怨情仇不在此深究。
我只說三個關鍵點，你自然明白其中利害關系。
1，它是微軟的官方編程語言，微軟的親兒子，天生的富二代，Visual Studio便是為它量身設計。並且是微軟唯一可以跨平台的兒子。。微軟前不久又為它專門設計了輕量開發工具VS code。。不遠的未來，它將成為微軟的獨子。未來幾年，微軟幾乎全部工作都將與它有關。
2，它是游戲開發行業的第一大編程語言。佔有60%以上的份額。Unity3D，CE5，寒霜，夜光，這四大游戲引擎的標准語言。《口袋妖怪Go》《使命召喚》《FIFA》《極品飛車》《最終幻想14》等數以萬計的游戲都是由它開發而成。還包括國內最火的手游《王者榮耀》
3，它是虛擬現實（VR）設備開發的第一大語言。
扔掉JAVA，改用kotlin，也就等於與C#分道揚鑣。。。所付出的代價，在我看來是無與倫比的。