@moooookey ......怎么会有这个逻辑……难道 tg 发中国版了

就是国内 app 自己检测在国内就不用 callkit 而已。

@gygesm123 wangyin 那个解读真的太肤浅了。大概就是大家在评红楼梦，他说章节标题没加粗大家不容易找到的感觉。

可读性当然很重要，但是 wangyin 那些东西对 rust 的可读性完全没有意义，如果写过 rust 的人就知道反而会显著降低可读性，因为 rust 里匿名类型太多了。

用 https://crates.io/crates/num，Vec 长度可变并不是类型签名，不需要处理 N

看你现在的心态和我当年很像啊……也是天天折腾不想搞科研……说白了就是拖延症

1. 跟导师和同实验室的人多聊聊，尤其是导师，不论他 /她是否是还在科研一线，导师总是有责任帮你指个方向或者找人带你的。当然方向靠不靠谱也要自己多思考。不行就要求给实验室做的好的人打下手做实验先混个挂名，至少你有点进展，学学科研套路。你要自己主动对导师提想法和要求，不一定是具体科研方向，也可以是如何找到科研方向的啊。
2. 你要给自己设置一个止损的最后时间。如果这个时间到了科研还没有进展果断 quit，如果你是直博，和导师聊聊转硕，你都耗了这么多年了，应该是不难的。
3. 心态要放平。一是止损时间要定好，二是博士没毕业也不是世界末日。车到山前必有路，就算你顺利毕业了，找工作你也不见的就继续博士期间的研究方向。

@xiangyuecn 他绝对不会说语言问题的……

大的开源项目维护很麻烦的，就算是这么关 issue，vue 现在依然有 270+的 open issue，按你的做法分分钟几千个 issue 而且还都需要 maintainer 时刻关注。所以一般都是第一时间 triage 然后就直接关掉了。

开源项目基本就是这样，maintainer 一共没几个，更没有几个是全职，issue 多的一塌糊涂，绝大多数都是问“1+1 你写的计算器怎么返回了 2 而不是二”的，精力实在是顾不过来的。如果你发现他理解错了，你直接回复解释一下一般都会重开的。（ PS：你的两个回复语气确实是太 rude 了）

issue 还算好的，PR 更是麻烦。很多 PR 都是完全没和 maintainer 商量就写了的。也不是不行，但很多时候根本和项目设计理念矛盾，或者是问题百出完全没法 merge，更是难回，所以有时候就先放着，过了就忘了，然后就是楼上说的脾气大了。

brew update

@liuminghao233 这个问题叫 serialization/deserialization

/64 应该算是错误分配了，应该至少 /56 的

不可能的，只要要想一想 B 如何发送数据给 C 就好了

@nozer
你虽然在标题里强调简单（行数少），但简单的主要原因只是因为你没写最重要的东西。当前的实现基本上就是同步的，虽然看起来代码是异步的，但是 IO 几乎没有复用，和同步唯一的区别就是一个线程处理两个方向而不是一个方向。并发只有 128 实在是少了一点。
不过你就算自己做，不用 asyncio，完全 IO 复用，也不会长太多。

这代码连逻辑都不对……

其实 LZ 不就是想给自己懒的学习找个借口么，也没啥好争的不是……

LZ 不要当专家，不要写架构，反正这些东西做业务也用不到。

但是 LZ 又要来问职业规划，“总不能一直搬砖吧？当 CTO ？架构师？” https://www.v2ex.com/t/438476

我就不是特别确定了，既然你觉得反正学什么搬砖都用不上，反正就是有那么多人要搬砖，那又何必问“总不能一直搬砖吧”呢？你不是已经给了自己很明确的定位了么。

@gowl -O 3 一般是不够的，实现底层算法需要考虑的比这个多。

@mathzhaoliang 我相信这些开源的东西不太可能比得上商业版的。

问题是你自己都说了不能看钱，核心竞争力是情怀。可开源的情怀是为了全人类，你的情怀是为了让中国人赚中国人的钱。我觉得竞争力不强啊……

@mathzhaoliang http://www.sympy.org/en/index.html 这个可以用么，我也不搞这个，不确定。

但是现在用 Matlab 的人真心已经很少了，剩下的更多的也还是在用 simulink。

而且你是要搞成啥，如果是开源的，你直接投身现有开源框架添砖加瓦就可以了，我很难想象一个商业软件没有对应的开源版本，唯一的问题是开源的在功能上往往是斗不过商业软件；如果是商业软件，那么只有这两家还是有原因的。