[Go] 閱讀心得 不負責任翻譯 Golang Frequently Asked Questions (FAQ) PART1
https://golang.org/doc/faq
官方FAQ 提供一些有趣的資訊，很認真的試圖都理解一下，由於內容太多，拆成幾個部分來看。
PART1這裡有 Origins Usage Design
What is the purpose of the project?
依賴管理對於現在語言非常重要，C語言有著絕佳的速度，但header file的方式在管理依賴這件事上實在非常糟糕。於是想要一個速度快，依賴管理方面又能滿足我們的語言。
沒有『繼承』的概念，這點可以省略『判斷兩個型態彼此之間的關係』所花的時間。(這點蠻有趣的，我不曉得『繼承』需要這樣的cost)
Go準備完整的garbage-collected ，來足以應付併發與溝通問題。(以目前所學，各處聽到GO的gb機制多少令人詬病ＸＤ)
Go是為了多核心機器所設計的語言。(沒錯，這點非常重要！)
What is the status of the project?
Go 是個開源的poject，有Google撐腰，version 1 是個長期支援的版本。
version 2 改天指日可待！
What’s the origin of the mascot? (吉祥物，略)
What is the history of the project?(歷史，略)
Why are you creating a new language?
這裡說目前主要的程式語言，若達到簡單好上手(直譯式、弱型別)的，那麼就不能滿足安全又快速的條件(我想這是以事先編譯的角度來看)。
Go 想要達到簡單、安全又快速，可以處理併發、多核心的機器。
GO語言目標：在單一一台機器上，可以快速與有效的執行龐大的程式。
What are Go’s ancestors?
Go 主要血統是C語言，但參雜很多語言的概念，還有新的。
What are the guiding principles in the design?(部份不太懂)
捨棄繼承，type就是純粹的type，而不用聲明type和type的關係(講繼承)
保持概念和原則的純粹，method -->實現任何類型; struct–>數據;而interface -->抽象;
Is Google using Go internally?
Google 內部也有使用Go開發產品
Do Go programs link with C/C++ programs?(部份不太懂)
透過cgo可以安心的使用C/C++程式
Does Go support Google’s protocol buffers?
protocol buffers 是Go 推出的新格式型態，也是golang發展途中的另外一個開源分支。
https://yami.io/protobuf/
因為工作上有用到，所以稍微留上點心，這真是不得了的鬼東西。
簡單來說，使用這個格式傳遞資料就是快，神快，對於需要快速溝通的rpc來講，使用與否根本天壤之別。
Can I translate the Go home page into another language?(go語言若要置入到其他語言的品牌授權，略)
Does Go have a runtime?
Go 有個library叫做『runtime』。『runtime』通常用在像是JAVA，有在virtual machine上運行才有這個名詞，
但Go沒有使用virtual machine，編譯出來的東西是原生的machine code直接餵給機器。
Go的runtime只是『runtime』那個library的服務資訊而已。
What’s up with Unicode identifiers?(部份不太懂)
golang 允許出現在程式裡面的文字或數字，必須要符合或定義在Unicode。
查相關資料時，意外知道golang的代碼都是Unicode編碼，所以訂出這個規範好像也不意外。
(也許這樣也好，python2 和python3 對待編碼問題，遇上了真的會煩死人。)
Why does Go not have feature X?
大意是說如果你在GO找不到想要的功能或特點，GO因為堅持自己的設計原則，所以只好跟你say sorry。
Why does Go not have generic types?
Go 認為通用型態，是不迫切需要的，所以沒有。
通用型態會對於型別的系統處理，以及執行程式時造成很高的複雜度，GO目前還未找一個合適解決的方案。
通用型態的issue持續開放中～
Why does Go not have exceptions?
認為try-catch-finally 的機制，會將程式複雜化，而且引起programmer會特地對付許多一般性的錯誤，如開檔讀檔。
golang可以return多個value，這件事可以很好的處理錯誤回報。
golang有復原錯誤的機制，但多餘的結構會影響處理復原這件事情，錯在當下，就該當下復原。
希望專注在每個可能發生錯誤的個體上，對於每個錯誤的發生有乾淨的錯誤處理程式。
Why does Go not have assertions?
這應該在講斷言這件事,我就抓個參考 https://msdn.microsoft.com/zh-tw/library/ttcc4x86.aspx
因為印象我在寫VB.net時有稍微碰過，有段時間還覺得這個東西非常好，沒想到GO就拋棄它，maybe這是我的feature X ?
沒記錯的話，它可以先『斷言』某些資訊，譬如說我斷言傳進來的變數X，一定會小於1000，並且大於10，若不在這範圍就是錯，程式也不用繼續做下去了。
GO說以開發團隊的經驗，這個玩意就好比個拐杖，可以幫助避開錯誤，讓你們不會正視真正的錯誤，錯誤發生時，資訊不夠直接明白。
(蛤?也許我之前的應用方式不夠深入，所以沒啥感覺)
無可否認斷言機制很方便，但GO認為錯誤資訊這件事情非常重要，要慎重處理，並且出來的資訊需要直指問題核心，能夠幫助開發者早日將可能發生的錯誤控制成非致命的，不會導致系統crash。
無可否認的要不要有這項東西，一直也是個爭論點，但GO想試試跟別人不一樣的做法，所以也是很你say sorry啦。
Why build concurrency on the ideas of CSP?(目前不懂這方面)
CSP 是指 Communicating Sequential Processes
這部分學術文章，wiki查到說1985才首次出現，對於電腦科學來說，應該算是非常年輕。
這部分的學科知識，深刻影響golang併發的設計。
Why goroutines instead of threads?(待更深入了解)
gorutines的idea來自於corutines，對岸翻做『協程』。
概念簡單講，就是一個線程上面可以有超多的協程，如果被system call中斷，可以換另一個rutine繼續做，而不用切換出去。
gorutines的stack與記憶體使用，是可變動並且視需要增長的。
CPU開銷平均每個函數調用大約三個廉價指令。 在同一地址空間中創建數十萬個goroutine是確實可行的。
(改天再整理一篇文章分享我所知道的gorutine)
Why are map operations not defined to be atomic?
如果有用gorutine訪問map的資料結構，是不安全，不穩定的，而且可能導致系統crash。(還沒去踩這個坑)
這樣做是艱難的決定，考慮的點在於map的結構可以是非常龐大的，若要對此做安全的存取，會拖慢執行速度。
如果有需要，請各位開發者自行加上讀寫鎖。(我的天呀，這個語言就是各種追求快)
如果只是單純讀map的內容，沒有任何update，還是安全的。
Will you accept my language change?
Go 努力保持向下相容性，而且這個開源的project，之後GO會往什麼方向變更，再說吧。
官方FAQ 提供一些有趣的資訊，很認真的試圖都理解一下，由於內容太多，拆成幾個部分來看。
PART1這裡有 Origins Usage Design
--Origins--
What is the purpose of the project?
依賴管理對於現在語言非常重要，C語言有著絕佳的速度，但header file的方式在管理依賴這件事上實在非常糟糕。於是想要一個速度快，依賴管理方面又能滿足我們的語言。
沒有『繼承』的概念，這點可以省略『判斷兩個型態彼此之間的關係』所花的時間。(這點蠻有趣的，我不曉得『繼承』需要這樣的cost)
Go準備完整的garbage-collected ，來足以應付併發與溝通問題。(以目前所學，各處聽到GO的gb機制多少令人詬病ＸＤ)
Go是為了多核心機器所設計的語言。(沒錯，這點非常重要！)
What is the status of the project?
Go 是個開源的poject，有Google撐腰，version 1 是個長期支援的版本。
version 2 改天指日可待！
What’s the origin of the mascot? (吉祥物，略)
What is the history of the project?(歷史，略)
Why are you creating a new language?
這裡說目前主要的程式語言，若達到簡單好上手(直譯式、弱型別)的，那麼就不能滿足安全又快速的條件(我想這是以事先編譯的角度來看)。
Go 想要達到簡單、安全又快速，可以處理併發、多核心的機器。
GO語言目標：在單一一台機器上，可以快速與有效的執行龐大的程式。
What are Go’s ancestors?
Go 主要血統是C語言，但參雜很多語言的概念，還有新的。
What are the guiding principles in the design?(部份不太懂)
捨棄繼承，type就是純粹的type，而不用聲明type和type的關係(講繼承)
保持概念和原則的純粹，method -->實現任何類型; struct–>數據;而interface -->抽象;
--Usage--
Is Google using Go internally?
Google 內部也有使用Go開發產品
Do Go programs link with C/C++ programs?(部份不太懂)
透過cgo可以安心的使用C/C++程式
Does Go support Google’s protocol buffers?
protocol buffers 是Go 推出的新格式型態，也是golang發展途中的另外一個開源分支。
https://yami.io/protobuf/
因為工作上有用到，所以稍微留上點心，這真是不得了的鬼東西。
簡單來說，使用這個格式傳遞資料就是快，神快，對於需要快速溝通的rpc來講，使用與否根本天壤之別。
Can I translate the Go home page into another language?(go語言若要置入到其他語言的品牌授權，略)
--Design--
Does Go have a runtime?
Go 有個library叫做『runtime』。『runtime』通常用在像是JAVA，有在virtual machine上運行才有這個名詞，
但Go沒有使用virtual machine，編譯出來的東西是原生的machine code直接餵給機器。
Go的runtime只是『runtime』那個library的服務資訊而已。
What’s up with Unicode identifiers?(部份不太懂)
golang 允許出現在程式裡面的文字或數字，必須要符合或定義在Unicode。
查相關資料時，意外知道golang的代碼都是Unicode編碼，所以訂出這個規範好像也不意外。
(也許這樣也好，python2 和python3 對待編碼問題，遇上了真的會煩死人。)
Why does Go not have feature X?
大意是說如果你在GO找不到想要的功能或特點，GO因為堅持自己的設計原則，所以只好跟你say sorry。
Why does Go not have generic types?
Go 認為通用型態，是不迫切需要的，所以沒有。
// 如C++
template
通用型態會對於型別的系統處理，以及執行程式時造成很高的複雜度，GO目前還未找一個合適解決的方案。
通用型態的issue持續開放中～
Why does Go not have exceptions?
認為try-catch-finally 的機制，會將程式複雜化，而且引起programmer會特地對付許多一般性的錯誤，如開檔讀檔。
golang可以return多個value，這件事可以很好的處理錯誤回報。
golang有復原錯誤的機制，但多餘的結構會影響處理復原這件事情，錯在當下，就該當下復原。
希望專注在每個可能發生錯誤的個體上，對於每個錯誤的發生有乾淨的錯誤處理程式。
Why does Go not have assertions?
這應該在講斷言這件事,我就抓個參考 https://msdn.microsoft.com/zh-tw/library/ttcc4x86.aspx
因為印象我在寫VB.net時有稍微碰過，有段時間還覺得這個東西非常好，沒想到GO就拋棄它，maybe這是我的feature X ?
沒記錯的話，它可以先『斷言』某些資訊，譬如說我斷言傳進來的變數X，一定會小於1000，並且大於10，若不在這範圍就是錯，程式也不用繼續做下去了。
GO說以開發團隊的經驗，這個玩意就好比個拐杖，可以幫助避開錯誤，讓你們不會正視真正的錯誤，錯誤發生時，資訊不夠直接明白。
(蛤?也許我之前的應用方式不夠深入，所以沒啥感覺)
無可否認斷言機制很方便，但GO認為錯誤資訊這件事情非常重要，要慎重處理，並且出來的資訊需要直指問題核心，能夠幫助開發者早日將可能發生的錯誤控制成非致命的，不會導致系統crash。
無可否認的要不要有這項東西，一直也是個爭論點，但GO想試試跟別人不一樣的做法，所以也是很你say sorry啦。
Why build concurrency on the ideas of CSP?(目前不懂這方面)
CSP 是指 Communicating Sequential Processes
這部分學術文章，wiki查到說1985才首次出現，對於電腦科學來說，應該算是非常年輕。
這部分的學科知識，深刻影響golang併發的設計。
Why goroutines instead of threads?(待更深入了解)
gorutines的idea來自於corutines，對岸翻做『協程』。
概念簡單講，就是一個線程上面可以有超多的協程，如果被system call中斷，可以換另一個rutine繼續做，而不用切換出去。
gorutines的stack與記憶體使用，是可變動並且視需要增長的。
CPU開銷平均每個函數調用大約三個廉價指令。 在同一地址空間中創建數十萬個goroutine是確實可行的。
(改天再整理一篇文章分享我所知道的gorutine)
Why are map operations not defined to be atomic?
如果有用gorutine訪問map的資料結構，是不安全，不穩定的，而且可能導致系統crash。(還沒去踩這個坑)
這樣做是艱難的決定，考慮的點在於map的結構可以是非常龐大的，若要對此做安全的存取，會拖慢執行速度。
如果有需要，請各位開發者自行加上讀寫鎖。(我的天呀，這個語言就是各種追求快)
如果只是單純讀map的內容，沒有任何update，還是安全的。
Will you accept my language change?
Go 努力保持向下相容性，而且這個開源的project，之後GO會往什麼方向變更，再說吧。
Created Date : 2018/08/01
Last Updated Date : 2018/08/02
留言
張貼留言