本文不會像壹般介紹語言的文章那樣，壹開頭就羅列出語言那些酷炫的特性，我們稍後再來探討這些內容。
首先我將介紹壹些其它的信息，因為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/reduce 等管道結構函數將被編譯成類似於命令式語言的代碼。
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 以及 copy 和 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 類的名字 PathVariableMapMethodArgumentResolver 就是例證。在很長壹段時間裏我沒有考慮 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 這門新語言進入這個世界瞧瞧。