之前看到的一个知乎回答： https://www.zhihu.com/question/653896828/answer/3480752444
> 简单来说游戏服务器这种架构设计就是为了低延迟而牺牲服务可用性。而这个业务的特性决定了这么做是可行（甚至是必须的）。
我的理解是游戏服务器更重视低延迟，而不太需要高可用。可用性低一点没关系，发补偿就行，玩家也不是随时都在玩（高峰集中在晚上和周末）。
互联网产品更重视高可用，为了可用性可以牺牲延迟。

FBReader

喷的人越多说明用的人越多，真正没人用的语言没人关注
任何编程语言都有优点和缺点，都是取舍，看应用场景选择就好
知乎的推荐机制挺奇怪的，容易产生信息茧房，一部分人慢慢就不发言了。不如多关注几个平台，例如微信公众号、掘金

被人举报了？我 cf 托管域名未备案，国外服务器，跑自己的服务，自己用浏览器访问，没啥问题。
但我用了非 80 非 443 端口，自签 https 证书 + http basic auth 鉴权。

用 Wix 之类的工具拖吧： https://sspai.com/post/59504

写点自用小工具、小脚本

这是逼迫你更细致的处理错误，在使用异常的语言中，如果要细致处理错误，代码量并不比 Go 这样的小。

Go 的错误处理思想继承自 C ，有点“程序的性能消耗和代码量成正比”的意思。比如错误不自带堆栈，因为堆栈有性能开销，如果确实需要的话程序员就要手动加，手动加的时候还可以加上更多上下文信息，有时候比异常更好。

个人认为应该将错误分成两类：意料之外的，属于程序 bug 的，直接 panic ；意料之内的用户输入错误，上游 API 错误，用 error 处理。

推荐看看这篇 The Error Model: https://joeduffyblog.com/2016/02/07/the-error-model/

首先，这两种写法语义上并不等价，第一种写法多出一个 Status ，第二种写法要加上 Status 的话得返回一个 std::tuple<Status, Student> 或 std::variant<Status, Student>

两者的区别在于，第一种写法，Student 占用的内存由调用方分配，适用于对性能要求较高的场景；第二种写法，每调用一次 Get ，都会为返回的 Student 分配内存（尤其是 Student 包含了一个 string ，string 是动态分配），好处是用起来更方便。

考虑在一个循环中调用 Get ，如果用第一种写法，可以在循环外初始化 Student 并且复用 Student ，从而减少内存分配次数：

Student stu;
for (...) {
Get(key, &stu);
}

https （自签证书） + http basic auth

s3 套 aws cdn

推荐一些我最近在看的 blog：

Go 核心开发者 Russ Cox: https://research.swtch.com/
Google 安全大佬 Adam Langley: https://www.imperialviolet.org/
关注编程语言的 Bob Nystrom: https://journal.stuffwithstuff.com/

项目 blog:

The Go Blog: https://go.dev/blog/
V8 Blog: https://v8.dev/blog

还有阮一峰的网络日志

想起一个东西：ExtJS ，当年很火

可以从多个角度思考：

* 宏观角度：一些有正外部性的东西，可能最好是政府 / 国企来牵头，普通组织很难负担这种成本
* 个体角度：免费的可能是最贵的

如果是我的话可能会选择 pop 函数为空时 panic ，因为你已经提供了 IsEmpty ，为空时还要 Pop 可以认为是程序的逻辑错误（需要改程序）。
程序逻辑错误（需要程序员改程序）：用 panic
外部错误（用户输入、上游第三方系统，程序员无法控制）：用 error

有些安全补丁安装完只需要重启相关服务就行了，不用重启系统，比如之前的 ssh 安全漏洞

somekey, somekey2 的类型改为自己实现的 json.Unmarshaler 然后外面加上自定义验证逻辑？

主要手机上用，简单可靠，电脑上还是习惯 chrome