變天了！
value type 改名 InlineType , InlineType 不能 null，要多一層 IndirectType才行 (後面加個 ?)
IndirectType 白話講就是 Boxed Type 吧
primitive 和 boxed type:
int -> Integer
到了 inline 和 indirect 就會寫成這樣
inline class Foo
Foo -> Foo?
所以 inline type 可直接當 primitive 來看，像這種寫法 List<Foo> 是不行的，你得用 indirect type (即Boxed)，也就是 List<Foo?>。
私以為這個設計高竿，只用一個 symbo ? 直接解決原本 value type 模菱兩可的表示 (看不出到底有沒有 boxing)，而這個 ? 可以為了之後的 nullable type 舖路
Boring Tech 的特徵:
- 有 LTS 版本，時間長達三年以上
- 即使沒有明確的 LTS，舊版本也繼續維護到天荒地老
資訊新人都以為學最新最潮的技術是最棒的投資，卻不知道 Boring Tech 學完一用就是十年...
舉例問一個寫 nodejs 的，給他選 SQL 和 GraphQL，他會選哪個？
Internal iteration並沒有如傳統iteration有next()用來指示走訪下一個元素的方法。Internal iteration由你的應用程式決定要被迭代的集合，但該如何走訪集合中的的每一個元素則是由JDK決定；而External iteration則是被迭代的集合及迭代的方式兩者皆由應用程式來決定。
而主要的差別是，External iteration只能以序列方式(serial)迭代集合，而Internal iteration除了可以序列方式，也支援以平行方式(parallel)來迭代集合。
也就是說Sream的forEach可以利用平行計算將迭代的程式拆分為多個子程式來平行處理，最後在將子程式的執行結果組合起來。其意味著Stream的forEach比原本的iteration更彈性且高效
聽起來是個從 iteration 改用 stream 的好處
從 ec2 instance 搬到 k8s 之後發現，現在 cluster 一死掉，就是全部服務一起死。不像以前 ec2 個個虛擬主機是獨立的，隨便掛一個都沒差
k8s 適合跑的應用都是 stateless，更廣泛一點說，就是 cloud native app。因為這樣，所以Pod、Job…等等元件要 scale 和重啟都好輕鬆啊！但其實有另一大塊是 stateful app 很難搞定，許多人乾脆 stateful 的通通不放 k8s 裡了。然後更妙的是 k8s cluster 本身就是個 stateful app，而且不符合 cloud native 的定義。這算是呼應第一點，當 cluster 壞掉時，你沒辦法很容易啟動新的 cluster 原地復活。
k8s 太複雜了，而且未來只會更複雜，因為目前不斷有新的標準產生。依照過去十幾年的經驗，過度複雜的系統最後會被簡化過的新架構取代，感覺 k8s 也是個過渡性產品。
與 k8s 成對的是 microservice，甚至有人還說: 如果沒要要用 microservice，何必用 k8s ? 問題是 microservice 這種分散式泡沫一定很快就會消失，因為前例太多了，像是 EJB、WebService、SOA... 等等
k8s 現在有很多小廠商提供產品和服務，大廠則是不斷推出相關的新產品，然後又有証照可考，未來很多企業都會導入的。從這角度來看似乎很正面，但這個超級像過去的 J2EE，有標準、有証照、有一堆免費和商用 container 可選 (以前 J2EE server 也叫 container，這不是巧合)。你看看 J2EE 現在還剩什麼廠商吧…
當然啦，技術本來就會隨時代迭代，這個十年可能就是 k8s 稱霸，而十年也夠久了，投身這門技術可以讓自己有競爭力，企業也會因為標準化，尋求人材時會簡單許多。要說短期內會出現的缺失，就是因為 k8s 變成顯學、標準化，造成大家不適用 k8s 的系統也會硬套，然後又難學難管理，白白增加成本。
現在k8s好像是顯學，但偶爾也會看到一些如 Maybe You Don't Need Kubernetes1 這類的文章，所以有機會想多方聽聽各種經驗，可以請教一下為什麼嗎?