- 主题:goroutine 之间是不是最好别共享数据？
要求 goroutine 不使用外部的变量，所有的动作都使用 chan 来通信是不是比较好的实践？
你们现实中写程序是这样的吗？
--
FROM 110.84.122.*
那现实中，你们是选择使用锁，还是使用 chan 呢？
【 在 abadcafe 的大作中提到: 】
: 显然没必要如此啊。那些锁啊，waitgroup啊，都可以用的。只是说理论上chan都可以模拟这些机制，但直接用已经封装好的不是更好吗。
--
FROM 47.243.39.*
那，假如，，我说假如，golang 官方要求 goroutine 不能访问外部的变量，不搞闭包，所有与其它模块的数据交换要么通过 chan 要么通过简单直接的函数调用。
你们会同意吗？
我在仿 golang 设计一门语言。
【 在 abadcafe 的大作中提到: 】
: 哪个方便用哪个，如果都方便就选自己最熟的那个，不纠结。
--
FROM 110.84.122.*
这种情况下，是不是可以为这个数据库连接池单独开个 goroutine. 从 chan 里面接收消息，需要个连接时，就向 chan 投递消息，返回一条连接，不需要这条连接了，就通过 chan 把消息退还给连接池？
同理，一个远程 RPC 的连接也是类似。
【 在 CKevin 的大作中提到: 】
: rust不能修改全局变量，rust启动线程后，线程中修改的变量其所有权会移交给线程，其他线程、主线程无法再修改，多个线程之间需要使用channel通信。
: （虽然rust允许通过锁机制动态获取一个变量的所有权）
: 听起来很像你想要的效果？
: ...................
--
FROM 110.84.122.*
是 erlang 啊。不过 erlang 那种是 Actor 模型。而 goroutine 是 CPS 模型。
不过你这么一说也对。整个确实没啥必要。像 goroutine 这样，使用到外部的变量就自己维护好锁就行了。
goroutine 主要是会被调度到多个线程，如果不调度，所有 goroutine 确定性地只跑在一个线程里面，那么，连锁都不需要，直接使用就是了。
【 在 milksea 的大作中提到: 】
: erlang这种？这世上的语言已经很多了，函数式语言并发一开始就是这个路子。go的并发形式c++用库都能做个八九不离十的，搞语言还是要解决现实痛点的（比如go就是为了并发简单）
--
FROM 110.84.122.*
那实际上大家是怎么做的？
官方的这个要求，在实际工作中会碰到很多麻烦吗？
【 在 nextworld8 的大作中提到: 】
: 官方是这样要求的 通过通信来共享数据，而不是通过共享数据通信
--
FROM 47.243.39.*
所以才我才问，一般 go 程序员，遵从这个理念的多吗？
【 在 nextworld8 的大作中提到: 】
: 也不好说是要求 只能说是理念了 规范了
: 没有强制
--
FROM 47.243.39.*