开早会的意义在于明确每日目标，应该和晚上小结会配合一起开。

不然来上班很可能不知道该做点啥，最后摸鱼结束一天。

你得说说原始需求，你的问题抽象不可解

解决方案：拍完照就整理好，不要积攒到一堆再搞

这就是为啥互联网大裁员。以前资本入驻互联网，为了全面垄断的预期，拼命砸钱耗死对手，所以什么人都养得起。现在政策变了，不允许全面垄断了，互联网即将转变为成熟的行业 —— 计较成本，不追求全面垄断了。所以这种人不一定会养得起了 lol

看上去 JDK 相当不给力啊。不过也对，毕竟 JVM 有很多 JIT 技术，大概在 ARM 上还不行。

反正我用 pytorch 跑神经网络，m1 pro 对比 2018 年 i5 的 macbook pro ，可以快 2 倍。

"9.00 ～ 10.30csgo" 去掉就行

@leeolsen 像我的性格，别说体制内了，我都受不了互联网大厂的约束。除了创业成功我想不出我能如愿的第二条路。

@leeolsen 你这算是活通透了。可是大部分人根本来不及活通透就得选择了。

好办法就是上传源码（滑稽

@lxdlam 你说的很对，所以虽然我个人不喜欢 2333 ，虽然 Go 是一种工程妥协（ Go 到处是工程妥协，比如现在还没完全上线的泛型），但是它毫无疑问是有用的。可以说 Go 语言这种编译器抽象对于大部分 Web 应用都是有效的，这本就是它的专长。

无效的领域，其实倒也不少。比如追求精确控制延迟的 real-time system 、高频交易之类的低延迟系统；比如本来就需要精确控制所有开销的游戏引擎、OS 内核、数据库系统。比如各种传统计算机算法。比如科学计算…… 但说实话这些本来就不是 Go 的专长。

我对于本楼有些微词的地方是，明明有这么多不同的场景，很多 Go 语言拥蹙就只知道互联网业务这一亩三分地，以为 Go 的协程就是圣经。。。互联网程序员现在网上的声音太大了，以至于 “技术” 就只有互联网并发 hhh

@statumer C# 那种可以通过一个线程池（专门排队做阻塞任务） + 非阻塞的 IO 。不过确实，非阻塞 IO 的库开发需要时间。所以这就造成了 Go 语言在网络微服务等领域特别被人追捧，因为在这里面编译期自动插入 hook 确实省事得多，一下子就可以适配所有阻塞的库。

这其实就是工程性的妥协了。C++ 和 C# 没有编译器的 hack ，导致大家不得不开发真正的非阻塞库。但是反过来，这样就倒逼 C++ C# 这种语言用户开发出真正高性能的非阻塞库了。然而毕竟真正需要高性能非阻塞的库不多，Network IO, MySQL / PostgreSQL / MongoDB ，加上一定的 File IO 和基础框架，就解决了。

其他的并不需要处理这种事情。应用逻辑方面需要解决“锁”的阻塞问题，其实“不阻塞”才是更正确的方案。逻辑复杂的应用从多线程并发阻塞模型换成 Actor model ，你会发现写起来就是第二次工业革命和第三次工业革命的区别。

Go 语言编译器允许大家偷懒，大家自然没有动力去精益求精，“够用就行”。反而抑制了更精巧的程序 —— 当然这也是做 “工作” 和做 “艺术品” 态度的差别吧 hhh

@lxdlam 在我看来 f(n) 就应该也是 async 的，虽然对于这方面 js 我不太熟。

我的技术背景是 C++、Python 比较熟，曾经用 Scala 写过 Future / Promise 的程序不过已经很久没有用了。C++ 自己写过 Actor framework ，Python 曾经用过 tornado 和 gevent ，现在挺喜欢用 async / await 。

因为我的这些背景，所以我觉得程序员非常准确明白所有这些并发方法（线程池、event loop 、callback 、future promise 、async await ）是基本功，而且不同任务可能偏重于不同的技术。当一个任务需要特别准确把握延迟的时候，随意上下文切换是不可接受的，那么就得手撸 event loop ，顶多在 event loop 上自己封装一下比如 actor model 或者 future / promise 呗。

所以我比较 anti go 语言这种类似于线程的协程吧，总感觉它管得太多了。

@statumer 我原先也完全是你这个理解思路，直到我在这一楼层里面看到了有人说 Go 语言的协程是可以切换上下文的——

https://www.jianshu.com/p/fb1ccbd0d0ff

我 tm ，瞬间五雷轰顶，并且明白了为啥 Go 吹那么多的原因。引用我 125L 的观点：

> Go 这种内置协程时间片切分的机制，在我看来，是一种工程实践上的妥协。
> 无论多轻量级的切换，一定是耗时的。减少不必要的切换可以使得总体耗时降到最低。
> 如果能控制 IO 非阻塞让渡控制权，而且每对 IO 之间的操作都比较轻量（微妙级），就完全可以只在 IO 上切换。这样总体效能是最高的。
> 但是工程上不能保证所有类库都这样，也不能保证所有程序员都写的对，所以 Go 的这种协程才有用吧 hhh

所以本质上这是一个，因为不会用 event loop 的程序员太多了，Go 语言大爷们就说：算了，你们这群傻逼，干脆我语言创造一个比系统线程更轻的协程给你们用算了。

----

所以总结一下，Go 语言的协程和其他语言的协程是不同的。C++、Python 这种经典语言的协程 tm 根本不可能内置 Go 虚拟机的时间线分片。JVM 和 C# 也从未想过要这么干。微软的 Fiber 还差羽而归。因为它们发现，替程序员越俎代庖搞这种抽象，吃力不讨好。反正追求性能的有 event loop 或者基于 event loop 的单线程协程，为啥还要搞个不上不下的多线程（有上下文切换）的协程呢？

毕竟任何上下文切换，哪怕你说 Go 协程切换只要三个寄存器，tm 还是实打实有这个耗时的啊。
----

但是在一个没有泛型被认为是大道至简的语言里面，这种独一份的奇葩设计也没啥可奇怪的。

（强烈怀疑它没有优化好
（要用 transaction batch insert

你用了啥工具导入。。。有区别的