@standchan 你看我正文第一句话 “有些错误不需要特殊处理”，如果我没想过这个函数的使用场景有限，我又怎么会说这句话呢。

@popvlovs

宏观上，AI 的发展对 IT 行业有很大的促进作用，有可能做大蛋糕。

最近 Vultr 好像有免费活动，你可以去申请试试。另外，这样的小网站，在 Vultr 买一个每月 3.5 刀的小鸡也完全够用了（同时加上博客、密码管理器也够用）。我用 Vultr ，图它能用支付宝比较方便，懒得找更便宜的了。

我用 Go 做过两个类似的网站

markdown 我后端只保存原始 md 格式，直接发纯文本给前端，让前端用 js 去将 md 转为 html
可以参考我这个项目 https://github.com/ahui2016/uglynotes

另外我做了一个可以快捷保存一段话，也能保存小文件的网站 https://github.com/ahui2016/go-send
主要功能是临时备忘，定期删除。

这两个项目是几年前做的，已经停止维护了，但应该还有一点参考意义。

@metalman7511

1. 一个国家的市场经济发展是否畸形，普通人（既不是经济学专业的，对政策也没有决定权的人）有多大责任？

2. 你对楼主的发言如何评价？

（如果你不发表自己的意见，只是凭身份、地位等与讨论问题没有直接关系的因素来指责别人，甚至连指责的内容都很笼统，你的发言相当于：“因为我是专家，我说你错你就是错，我不需要指出你具体错在哪里，也不需要说出正确的道理，单凭我的身份就能嘲笑你”，你认为这样的态度礼貌吗，有讨论问题的诚意吗，学经济的人都这样说话的吗？）

@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 的最最基本的语法，仅仅非常简单地包裹了一层而已，这种包裹一下变成一个方便的函数的做法，不是日常编程的常规操作吗？