# 2020-1-31 每日新聞
# rust 1.41了！
除了一些功能更新
重要的是不再支援32-bit Apple產品了
http://bit.ly/2S1iam9
# open-source security key
google 使用rust實作了 OpenSK
支援 FIDO U2F, FIDO2 兩種標準
http://bit.ly/2vBMiwS
# Rust編譯模型災難
文章作者Brian Anderson是Rust編程語言
及其姊妹項目Servo Web瀏覽器的共同創始人之一。
他現在在PingCAP擔任高級數據庫工程師。
他希望解決TiKV編譯緩慢的問題
在開發模式下進行完全重建可能需要15分鐘，在發布模式下可能需要30分鐘。
對於大型系統項目的開發人員來說，這聽起來可能並不那麼糟糕，
但是它比許多開發人員對現代編程環境所期望的要慢得多。
TiKV是一個相對較大的Rust代碼庫，
有200萬行程式碼。相比之下，Rust本身包含300萬行，而Servo則包含270萬行。
編程語言設計充滿了權衡利弊。這些基本選擇之一是runtime性能與編譯性能，
Rust團隊幾乎總是選擇runtime性能而不是編譯更快速。
如果快速編譯時間不是Rust設計的核心原則，那麼Rust的核心設計原則是什麼？這裡有一
些：
實用性-它應該是一種可以在現實世界中使用的語言。
實用主義-它應該要讓人覺得可用，並且將其整合到之前的系統中。
內存安全性-它必須強制執行內存安全性，並且不能接受記憶體存取錯誤。
性能-它必須與C++在一樣快。
並發-它必須提供現代的解決方案來編寫並發代碼。
但這並不是說Rust設計師沒有在快速編譯時間中考慮任何因素。
但因為利弊的權衡，編譯器的性能還是愈來愈慢。
當作者每天使用Rust編譯器工作時，
電腦上至少擁有三份程式碼是很常見的，在其他所有版本都在構建和測試的同時。
我將開始在工作區1編寫程式，開始編譯，然後跳到工作區2，
開始在工作區2工作，編譯後再切換回工作區1。不斷進行在不同的工作區中切換。
雖然在2019年Rust的編譯速度有了提升，但目前Rust還是編譯的不夠快。
下一集會是作者如何優化Rust的編譯速度以達到產品經理的期待
http://bit.ly/2vD5I4v
# Bastion 0.34
什麼是Bastion？
Bastion是一個高度可用的容錯runtime系統，具有面向動態調度的輕量級流程模型。
它為輕量級過程實現提供了諸如並發之類的參與者模型，
並有效地利用了所有系統資源，並保證了每次傳送最多的消息。
基於消息的通信與actor model的Mesh網路。
runtime容錯能力使其成為分佈式系統的理想選擇。
具有NUMA感知和仿射緩存SMP執行程序的完全異步runtime。
監督系統使管理生命週期變得容易。
目前哪邊有用到Bastion？
SkyNet (Discord 機器人，用來重新發送已刪除的訊息)
在AWS Lambda中，我們使用Bastion啟用重試機制，並嘗試不同的解析策略來處理數據。
http://bit.ly/2Ua9mgr
# Tide 0.6 了
Tide是一個還不成熟的 web framework
這一版增加了對CORS的支持與新的cookies API
也增加了一些新語法讓人用起來更簡單
http://bit.ly/3aTpglc
# oreboot
oreboot是coreboot的分支
https://zh.wikipedia.org/wiki/Coreboot
來自維基百科的說明
coreboot，原名LinuxBIOS，是一個旨在取代大多數電腦中專有韌體（BIOS或UEFI）的軟
體專案，它採用輕量級韌體設計，只執行載入和執行現代32位元或64位元作業系統所需的
最少量任務。
Oreboot當前僅支援LinuxBoot。
Oreboot想利用Rust的安全性製作一個安全穩定快速的BIOS程式。
http://bit.ly/2S4RuAP
# 改善MSBuild中的並行編譯性能
從Visual Studio 2019 16.3開始，有了Multi-ToolTask（MTT）
通過將MSBuild屬性或環境變量UseMultiToolTask設置為true，使用 MTT。
可以使用平行編譯。
http://bit.ly/2tiAU8o
# Bitsery C++序列化庫 5.03版了
速度很快
序列化的數據很小
可以向前向後相容
http://bit.ly/36HHinl
# 什麼是Spring Framework？ 從依賴注入到Web MVC
花費約15分鐘閱讀本指南，該指南涵蓋了Spring框架中最重要的80％，
如果您的工作有用到Spring 您將在未來獲得超過一百萬次回報。
http://bit.ly/2GA42uO
# Project Loom 的出現會讓 Future 消失嗎？
Project Loom 的出現會讓 Future 跟 CompletableFuture 過氣嗎？
Project Loom具有三個主要目標：
introducing continuations, fibers, and tail-call elimination.
Loom能讓你更簡單的寫出非同步程式碼並使用 fibers。
Kotlin已經有fibers，編譯器支持。 Scala庫具有coroutines。它們與即將推出的JVM
fibers相同嗎？
並沒有因為JVM fibers是底層實現的，並且具有運行時支持。
另一方面，Kotlin中的fibers是一種編譯時機制。在Scala中，coroutines是一種程式庫
實作機制。
http://bit.ly/38U3ITC