The output from this tool handles the serialization/deserialization process automatically, meaning our client-side devs can continue to work in their language of choice while interacting with the Rust library and can be free from the concerns of JSON parsing over the foreign function interface (FFI)
好奇這邊的FFI是啥，就是 產生 target language 的 source code1 嗎？但repo有點舊了。
gradle/groovy 弄太多魔法才會變這樣，跟 Ruby 生態一樣。
還好現在不流行這一套想法了。但 gradle kotlin 現在還不夠成熟…
對 gradle 而言，最好把它當成是 bash 來看待。 你可以找到一堆範例來貼，但要開始自己寫/debug 時就會很痛苦，直到你學會為止。即使很難學， bash 還是最多人用的，你也不得不去學。
一個 build 系統變很多人用之後，不可避免會變得非常複雜，看看 webpack 現在長成什麼樣子吧。這個 pattern 只會不斷的循環，即使突然冒出了一個新星說它很簡單好用，等它過了三年後就會開始變得噁心了。
不是說新的 build 系統不會記起前代的問題，沒有進步。新系統通常會在安全性、正確性上做很多改良，但是期望它能簡單使用我覺得不切實際啦，build 系統就是要花時間去學，因為這個問題本身就很複雜，簡單不了。但通常也不會太難學，買一本書讀個前幾章就好了。只能說現在大家都不看書了，都期望直接從 stackoverflow 解決。
但我能理解這個blog...就像我第一次看到
task greeting(type: GreetingTask){
}
我一直會想知道到底怎麼變成 groovy call1 ...
project.tasks.create([name: 'greeting', type: GreetingTask]) { ... }
不然實在不知道自己寫時該怎麼下手，尤其只看 API document...
Gradle 真的讓人覺得在寫程式，各種寫法，DSL讀時是蠻方便馬上了解大概想幹什麼，但要自己改動時就痛苦多了。
另外讓我想到 討論如何Tagging sub projects1（離題）
gradle 的官方文件確實不太適合新手
不過他提到的 gradle 概念, 其實買一本 gradle 的書, 看個前幾章就會講到 gradle 運作原理.
他自己寫書然後都不買書來看嗎