如果出了，先看看评测，去实体店试试看，然后再决定买不买。还没出呢，究竟好不好用无法预测啊。

@leonshaw

楼主说 “应当立法禁止加班，不但应该处罚企业，也应该处罚加班的雇员。” 我反对这个说法。

如果楼主说不处罚雇员，而是处罚企业，我就不反对了。

@leonshaw 我没有说不加以限制。

你再看看我表达的内容，我说的是要限制，但要限制垄断的一方。

我反对的是去指责、惩罚打工人，我的理由是打工人没有垄断地位。

@yujinchn776 是呀，所以我的看法是，不能指责打工人加班。如果要指责打工人加班，那按照同样的逻辑就必然能指责打工人不去挥洒鲜血争取权利，那么谁去争取，在座的谁能不被指责？

@Biluesgakki 我主要是想说不能指责打工人。

立法禁止加班 => 立法禁止加班不惩罚企业却惩罚个人

唉…… 讲讲道理。

什么是市场行为？

自由定价是市场经济最宝贵的特点，不支持自由定价就是不尊重市场。

通常只有垄断才会扰乱市场，一家公司，只要它没有垄断地位，那么它定高价也好、定低价也好、免费也好，都不会扰乱市场。

因此，个人加班不会扰乱市场，因为个人没有垄断地位。

============

要指责个人加班，必须有一个大前提：有真正的 GH （不用字母发不出来）。

有 GH ，打工人才有可能聚集在一起讨论，才有可能达成共识，然后才有可能指责违背共识。

没有 GH ，你连共识都没有，一盘散沙，有的人家境殷实，或者家庭负担小，就在那高喊 BG ，不 BG 就是叛徒，但是另一个人可能家里真的穷，或者家里有病人等各种困难，他跟着你 BG 他就全家等死（如果有工会可以组织人员调查、组织捐赠）。

而且，不管抵制 996 也好，BG 也好，都需要共同进退才有效，没有 GH 就从根本上不可能共同进退。

============

立法禁止加班，这不妥，既不尊重法律，也不尊重市场，这样子拍脑袋立法，很容易好心办坏事。法律会引起很多副作用，连锁反应，只看直接效果不考虑间接影响是立法的大忌。

我最近买了佳明手环（一千块钱出头那个），优点：

- 长续航，用三天电量还剩超过 50%, 我一般两天一充，洗澡时充，洗完澡就戴上，完全不影响使用。
- 能测血氧
- 睡眠分析很详细

缺点：

- 没有 GPS ，要蹭手机的 GPS
- 只能记录晚上睡眠，不能记录午睡

但如果贵点的佳明智能手表，应该没有这些缺点吧，没仔细看，我自己手环够用了。更详细的体验可以看我博客 https://geeknote.net/SuperMild/posts/2144

@dragonsunmoon 我一直很敬佩 Rob Pike

他超过 65 岁了，但他毫不墨守成规，他敢反主流。他不会问主流是什么，如果大家不符合主流会不会沟通困难，他设计的 Go 语言就极大胆地反主流，一个新语言，静态类型的，敢没有 try-catch 处理异常，没有泛型，敢加进指针，没有标准的面向对象，而是用隐性接口，这一大堆设计都是非常大胆的。

按照上面很多人的说法，完全可以说 Go 语言本身就有一大堆不伦不类的设计。但是，为什么要这样想问题呢，连 60 多岁的老人都敢勇于“标新立异”。

============

题外话，Go 官方网站的文档 pkg.go.dev 是当今极罕见，代码不带语法高亮的，但是我们也许并未感觉有啥特别不方便。因为 Rob Pike 发现，语法高亮其实没啥用。

我自己的体验是，写代码时语法高亮有点帮助，但阅读代码时，一旦沉浸进去，是绝对感受不到有没有高亮的区别的。

@dragonsunmoon 刚好我也想更详细一点说说这个问题。

上面我提到 “我记得 Go 语言之父说过，error 就是一个普通的值，他建议大家用自己的方法写一些函数来处理这个值，怎么方便怎么来”

凭着记忆，我找到了来源。

先看这篇发表在 Go 官方博客，Rob Pike 写的文章 https://go.dev/blog/errors-are-values

拉到文章最后，他总结道：

> Use the language to simplify your error handling.
> But remember: Whatever you do, always check your errors!

意思是，建议大家灵活使用 Go 语言去简化错误处理，只要别漏掉错误就行。

===============

然后他推荐了一篇文章 https://jxck.hatenablog.com/entry/golang-error-handling-lesson-by-rob-pike

这篇文章是日英双语的，讲述了一个活动上，博客作者 jxck 对 Go 的错误处理有疑惑，受到 Rob Pike 指导的过程。

jxck 遇到了需要写大量 if err != nil {return err} 的情况，向 Rob Pike 请教，Rob Pike 当场就给他写了一个 Wrapper, 也就是包裹了一层，把 error 先集中记录下来，后续再一次性处理。

===============

因此，Rob Pike 写了那篇官方博客，标题就是 Errors are values ，意思是不要把错误处理看成什么特殊的事情，error 就是一个普通的值，你如何对待别的任何数值、变量，就如何对待 error, 大胆去用常规编程技巧处理它。

各位，不要执着于是否使用 panic, 重点应该是现在有了泛型，有些错误处理可以简化了，panic 只是其中一个例子而已，上面给出了 lo 和 mo 两个库，里面有 TryOr, Option 等多种方便的函数，根据需要选用。

@dragonsunmoon

以前没有泛型没办法，现在原本三行错误处理可以轻松简化为一行，为什么要“老老实实”？

也没有不伦不类啊，用的都是 Go 的最最基本的语法，仅仅非常简单地包裹了一层而已，这种包裹一下变成一个方便的函数的做法，不是日常编程的常规操作吗？

@CC11001100 对呀，我也没说无脑一律 panic ，我第一句话说的就是 “有些错误不需要特殊处理，就能用这些简单方便的函数”，自己看情况用，另外我也附言给出了一个流行库，里面除了有 Must, 还有 TryOr 等多种不同的处理错误的方式，各有不同的使用场景。

我不理解，上面很多人很鄙视用 panic 处理错误，意思是

A. 只要用了 panic, 就该被嘲笑，Go 语言就不该有 panic 这个函数。
B. 如果要用 panic, 就只能这样用 if err != nil {panic(err)}，其他方法比如包裹一层 Must1(val, err) 就不行

究竟是 A 、B 哪个意思？

@Hanggi 我也很好奇，你为什么说我无法接受 Go 的语法？

if err != nil {panic(err)} 能处理错误，Must1(val, err) 也能处理错误，都符合 Go 的语法。

注意两点：

1. 看我的正文第一句话 “有些错误不需要特殊处理，就能用这些简单方便的函数”，我并没有说每一个错误都这样处理，只是有时候能偷懒，就这样偷懒，比如程序初始化阶段的一些很应该出错就崩溃的错误。

2. 我记得 Go 语言之父说过，error 就是一个普通的值，他建议大家用自己的方法写一些函数来处理这个值，怎么方便怎么来。

@yyf1234 对。

另外有时候时间紧或者写 demo 的时候就先 panic 偷懒，后续再好好处理错误，反正有 web 框架兜底，程序不会真的崩，向前端返回 500 而已。

@lance6716
@rrfeng

确实，我这个函数名搞错了。原本我用的函数名是 Panic, 但看着太让人紧张于是改成 Try 。然后刚刚才知道有 lo 这个库。

@fengjianxinghun 泛型是天生类型安全的，interface{}要自己写一堆判断才能确保类型安全。