Android 剛剛推出咗一個 Android Rust Introduction Page，入面有好多好值得睇嘅資訊去了解 Rust。

  • Rust in the Android platform - 了解更多你自己平時做緊嘅 Android (Kotlin/Java) 只係其中一部份係 High Level；Android 去到 Low Level System Programming 都係會用番 C/C++，現在有一個新寵準備力推就係 Rust。
  • Rust/C++ interop in the Android Platform - Rust Language 有  C/C++ interoperability 特性，可以睇到有啲經驗之談分享。
  • Fearless Concurrency - 在現世代的硬件進展史中，二十年前由主流的 Single Thread 時代進化到 Multi-Thread 時代，要用一隻 Programming Language 寫 Concurrency，大多數都係 unsafe 同埋好難 debug，Rust 就係呢點跑出咗而受大部份 Developers 喜愛。

睇咗啲 Android Rust Team 準備嘅資訊去解釋「點解要轉用 Rust？」，令我諗起自己經常同朋友都係咁講嘅一句話⋯⋯

推 Kotlin 的自我反思

啲嘢用 Java 總做到，但真正識運用 Kotlin 特性設計 Software Architecture 去 Abstract Business Logic，做到嘅話可以相差一個 Magnitude of Development Complexity, i.e. O(n^2)  v.s. O(nlog n)

可惜嘅係，Programming Language 已經不斷變革，但喺香港環境仲係以不變應萬變，好多 Senior 會因為職能上變咗 Business/Management Driven 先會搵到更多收入，導致好少人會主動去深入去了解一個 Language。

坦白講，如果連寫出黎嘅 Java 設計上都有咁多改善空間要執，更難去談得上可以用盡 Kotlin，咁嘅情況去轉 Kotlin ，99.99% 只會係 Kotlin in a Java Way，遇到呢個情況大多數情況下只會弊多於利。

見到呢個 Android Rust Introduction Page，令我反思到要推一個技術必先與 Kotlin 潛在用家同行，透過寫大量指引、經驗之談、連結相關讀物，先有機會一步步推動 Kotlin 發展，來年會寫多啲 Kotlin 相關嘅文章，力推 Kotlin/JVM Backend，請大家多多指教。

我的 Kotlin 歷史

當年受 Scala 啟發的我意識到一個 Programming Language 的重要性，在 2016 年剛剛 Kotlin 1.0  (Google 未正式 Official Support Kotlin 時)，公司有意 Clone iOS 去 Android。

有幸公司相信我嘅判斷用 Kotlin 取代 Java，於是我帶著 2 名 Developers用 Kotlin 於 3 個月時間內由零開始做一隻 FX Exchange Android Application，邊做邊深信用 Java 寫應該要多至少兩倍 Source Codes 多一倍時間，雖然最後整個業務(Startup) 只有幾千個 Trader，但用過嘅朋友同事都會覺得寫得好好冇乜 Bugs。

開發 Android 技術嚟講當時用到 Full RxJava + MVVM 去做算係走得好前，嗰陣算係第一水用 Kotlin 寫 Production App，2017 年針對 Kotlin 所寫的相關讀物：

其後再去到同一個金主所 Fund 嘅 Startup 去 Lead 一小隊用一年時間做一整個 Crypto  Trading Platform，帶領整個 Tech Team 寫 Kotlin/JVM Backend, Kotlin/Android, Swift/iOS, Typescript/Web，當時長時間要做 Kotlin Code Review 將 Kotlin 深入知識傳授俾更多人；

最後整個 Infrastructure 連 Platform 可以承受 10,000 trades/s over 24 hours within average 300ms response time，可惜 Business 原因而出唔到街；不過我敢講，冇 Kotlin 同埋相信 Kotlin 一齊成長嘅隊友話，冇可能 1 年内做到，具體咁講：

因為我可以透過 Kotlin 的優勢於一個幾千行至上萬行嘅 Application， 做到寫 ~500 行 Kotlin、Compile 到、Run 起之後 1 個 Bug 都冇，半日完成一個 Computational Intensive Feature。

Java/Typescript/Javascript/PHP/C++ 全部做唔到呢個信心。

不過，現時由做 Startup 到幫公司處理不同 Enterprise 客戶的需求，對使用新技術有了新想法。

既得利益環境下，推新技術並不容易

「既得利益環境」下就是指在一間相對大的公司，以 Kotlin 為例，所有人都係寫緊 Java，要推 Kotlin/JVM 不是一件容易嘅事。

  1. Business 從來都少理 Technical Details - 只要可以提升 Efficiency / Productivity (即係 Cost 低咗）基本上都歡迎，但好多時香港主要係欠缺一啲 Tech 高手真正發揮到新技術特性，真正提升 Efficiency；所以，Technical 無能力寫包單而且又會好易會扯到因為請唔到人令個 Cost 變大。
  2. 要成功使用新技術必定會涉及 Learning & Development (L&D)，任命具能力者做一些 Proof-of-Concept 去証明新技術在不同的 Business Use Case 都可以慳錢，呢個 L&D 成本究竟應該 Business Department 承擔還是 Technical Department 承擔呢 ？
  3. 最後而且最寫實，無論係 Startup 做 Product / Agency 幫人做 Solution，只要 Business 層面「冇對比」，唔知「原來可以做得咁 Efficient」- 基本上 Business 層面就冇可能會有一個推動力去迫 Technical 用新技術*，最後就會變成「有雞先定有蛋先嘅問題」。

* Business 硬推新技術會衍生其它問題，遲啲會寫一篇文去講多少少。

打破「既得利益循環」的方法

要打破「既得利益循環」只能靠外力，現在我諗到嘅唯一有效的解決方法：

  1. 首先與「既得利益者」同行，即是將「既得利益者」正在使用的技術磨練至極緻，令他們感受到尊重及同行者的角色。
  2. 發掘「既得利益者」會感到困擾的問題，讓「既得利益者」了解大家係同一條船，並設計一個最佳方案，帶出「既有的方法下只能做到咁」。
  3. 滲入新技術所設計的最佳方案，展述新技術的特點及提升 Efficiency / Productivity 的效果，讓他們逐漸成為自己的同行者。
  4. 時機成熟時，建議使用新技術去做下一個目標。

我自小對最新科技都有一顆熱情的心，若果我有幸可以好好發揮自己這一份熱情，將最新科技及技術推而廣之，也是寫我這一篇文章的目的。

無論使用新技術與否，相信大家都會聽過別人說：「做到就得啦！」這類說話⋯⋯

Non Functional Requirements (Quality)

最後我想分享一個想法：

「做到」只是基本要求，「點樣做好」先係 Software Engineer 應該要花一輩子氣力去深究嘅事。

希望香港會愈來愈多同行者，一齊做好 Software Engineering，為此介紹一篇由 JetBrains Kotlin Team Lead 寫嘅一篇文章 - Intentional qualities ，文中有一句話相信觸碰到很多有心做 Software Engineering 的同行者：

Qualities are often lost by an accident, but are never accidentally acquired.