Perl 程序員學(xué)習(xí) Golang，Go 語言簡單入門、快速使用

flw

回復(fù) 20# laputa73


    為啥要共享？你好好想想這個問題。比如我有知識你有問題，我為啥要和你共享？我的是我的你的是你的，為啥要共享？

傳統(tǒng)的面向過程、面向?qū)ο缶幊�，代碼是死的，上帝是活的。上帝無所不能，所有代碼都是它的工具，然而程序員的智商創(chuàng)造不出無所不能的上帝。于是便有了 BUG。
你把每一段代碼都想象成一個普通的人，活生生的人，人和人之間如何協(xié)作，代碼和代碼就如何協(xié)作，這個叫做［仿生學(xué)］，這段活的代碼，就叫做 Go 程。

多用請求、應(yīng)答模式。

Don't communicate by sharing memory; share memory by communicating.

py

substr函數(shù) 發(fā)表于 2015-12-14 11:59
某種程度上說明：[   ]

        Go語言本質(zhì)上沒有干了什么新的事情
        Go語言本身沒有被良好地設(shè)計
        Go語言是其他現(xiàn)代編程語言的退化



為什么Go語言不是想象中的那么好 [ ]
http://www.techug.com/why-go-is-not-good

1. 沒有哪個語言干了“新鮮事”
2/3. 這種片兒湯話有的事，安在哪個語言上基本都成立。

對于任何一個語言，想找正面和負(fù)面的評論都不是難事。所以，是否選擇一個語言，看的肯定不是誰正負(fù)面評論的多寡。

py

laputa73 發(fā)表于 2015-12-14 15:48
    正好請教一下大神，在go里面，多核模式下，推薦使用何種模式來處理goroutine之間的數(shù)據(jù)讀寫共享問題？
   用channel?還是用鎖?
    比如從一個隊列里面讀數(shù)據(jù)，這個操作是否線程安全？并發(fā)讀是否會出錯？
   還是用一個單獨(dú)go來讀隊列，然后channel?

支持協(xié)程的情況下，系統(tǒng)設(shè)計都推薦用 channel，不推薦用鎖。Coro 也一樣。
Golang 的 blog 有一篇是介紹如何共享數(shù)據(jù)的。其中提到 flw 說的那句。https://blog.golang.org/share-memory-by-communicating

我個人的感覺是，如果整個系統(tǒng)設(shè)計的合理，即使是多核也不會出現(xiàn)數(shù)據(jù)共享的問題。實際做起來，你就想怎么做就怎么做，設(shè)計錯了就會出問題，出問題了就調(diào)整設(shè)計。把坑都踩一遍是非常有價值的。

laputa73

了解
這樣的話，go的協(xié)程模式其實和erlang是一樣的。
只不過erlang比較狠，根本就沒有變量、鎖這些機(jī)制，全靠通信.
以后比較底層的通信框架，就都準(zhǔn)備遷到go去了。

substr函數(shù)

回復(fù) 22# py


請教大神  17樓 那種形式
請問 go 如何實現(xiàn)呢 ？

謝謝了。

py

回復(fù) 25# substr函數(shù)

你 Perl 里用的是什么，Go 里就也用什么。主貼中有基本數(shù)據(jù)結(jié)構(gòu)的對應(yīng)關(guān)系。
   

substr函數(shù)

師兄說

py  只是一個 二楞子

99.9 % 不會寫!
但我不信,
你是大神!
我信你 []

substr函數(shù)

回復(fù) 26# py



大神,
等你呀
一起與大神共同學(xué)習(xí)吧。[ ]

substr函數(shù)

回復(fù) 26# py


大神��！有時間能幫我寫出就好了 [   ]