https://github.com/shopspring/decimal?tab=readme-ov-file#faq
搜索 decimal 的库时看到这段 README 很有意思，介绍了为什么在金融应用中不能用有理数（Rational）来替代 decimal。
都知道浮点数只能表示近似值，一般不用于金融领域。而 Golang 中没有内建的 decimal 类型，有些人就提议说可以使用有理数 big.Rat 来代替。但是此文中举了一个通俗易懂的例子来反对这一观点，假设有三个等于 1/3 的有理数
说到底就是有理数本身虽然没有精度损失，但是将其转换为 float 时会导致精度损失，毕竟你不可能直接给用户显示一个有理数。所以在金融应用中，最好不要使用有理数，而是直接使用整数。而 decimal 存储的实际上就是整数和小数点位置的偏移量。
搜索 decimal 的库时看到这段 README 很有意思，介绍了为什么在金融应用中不能用有理数（Rational）来替代 decimal。
都知道浮点数只能表示近似值，一般不用于金融领域。而 Golang 中没有内建的 decimal 类型，有些人就提议说可以使用有理数 big.Rat 来代替。但是此文中举了一个通俗易懂的例子来反对这一观点，假设有三个等于 1/3 的有理数
a、b、c，使用 .FloatString(3) 将其转化为 float64 后的值为 0.333，可以看到它们相加后的总额中的 0.001 就消失了。说到底就是有理数本身虽然没有精度损失，但是将其转换为 float 时会导致精度损失，毕竟你不可能直接给用户显示一个有理数。所以在金融应用中，最好不要使用有理数，而是直接使用整数。而 decimal 存储的实际上就是整数和小数点位置的偏移量。
[ On | No ] syntactic support for error handling - The Go Programming Language
持续了数年之久的 Go Error Handling 之争，算是官方盖棺定论了，结论就是：摆烂。
自从放弃 Go2 方案后，兼容性就成了第一要务，非必要不修改语法。而 Error Handling 虽然长期以来都是社区最不满意的设计，但是关于具体的改进方案始终无法形成压倒性的共识，所以，官方决定，就这样吧，不改了。所有的历史讨论都到此为止，提案也逐步关闭。
并且对一些广受诟病的设计，做出了一些很牵强的解释：
* 语法啰嗦？反正你们有 AI 补全了
* 看起来碍眼？反正现代 IDE 都可以折叠。
* 没有 stack traces？打日志的时候多加一点参数嘛。
写 Go 的朋友喜欢怎么处理 error？我还在用古早的
持续了数年之久的 Go Error Handling 之争，算是官方盖棺定论了，结论就是：摆烂。
自从放弃 Go2 方案后，兼容性就成了第一要务，非必要不修改语法。而 Error Handling 虽然长期以来都是社区最不满意的设计，但是关于具体的改进方案始终无法形成压倒性的共识，所以，官方决定，就这样吧，不改了。所有的历史讨论都到此为止，提案也逐步关闭。
并且对一些广受诟病的设计，做出了一些很牵强的解释：
* 语法啰嗦？反正你们有 AI 补全了
* 看起来碍眼？反正现代 IDE 都可以折叠。
* 没有 stack traces？打日志的时候多加一点参数嘛。
写 Go 的朋友喜欢怎么处理 error？我还在用古早的
github.com/pkg/errors 😂。「Here's how CockroachDB keeps your database from collapsing under load」
其实是一篇关于 Golang Goroutine Scheduler 的文章。众所周知，Go 的 Goroutines 并没有优先级，对于类似于数据库这样的应用，如何在高并发的情况下保证重要任务的执行就会面临挑战。这篇文章就是介绍了 CockroachDB 的做法，通过在原生的 Go Scheduler 外增加一层名为 Admission Control 的调度层，来实现了 Goroutines 的优先级调度。
核心思想就是不要再将大量的 Goroutines 直接交给 Go Scheduler 去排队。而是先在应用层的 Admission Control 内的优先级队列里排队，只将当前系统能够负载的高优先级任务交给 Go Scheduler 去执行，这样就可以保证在高负载下系统仍然能保证重要任务的可用性。
具体的优先级实现有很多很巧妙的设计。比如优先级系统区分为 Token Based 和 Slot Based。对于 CPU 型任务，采用令牌桶算法，根据可用资源的情况来生成令牌，并且分发给任务使用，如果有任务超额使用了令牌，则扣减总的令牌数。而对于 I/O 型任务，因为 I/O 操作会阻塞 Goroutine，所以采用了 Slot Based 的方式，根据当前系统的 I/O 负载情况来动态调整 slot 的数量。而且动态调整的时间间隔也是动态变化的，尽量减少 CPU 消耗。
还观察到，即使使用这个优先级系统提交任务，偶尔也还是会导致 Go Scheduler 过载。而优化方法是将调度下一个任务的逻辑放到 task 的执行逻辑中，这样就只有在 task 被 Go Scheduler 实际交给 P & M 运行时，才会进行调度下一个任务的逻辑，从而确保了 task 不会在 Go Scheduler 堆积。
Refs:
* Source Code: cockroach Admit
* Go scheduler: Ms, Ps & Gs
其实是一篇关于 Golang Goroutine Scheduler 的文章。众所周知，Go 的 Goroutines 并没有优先级，对于类似于数据库这样的应用，如何在高并发的情况下保证重要任务的执行就会面临挑战。这篇文章就是介绍了 CockroachDB 的做法，通过在原生的 Go Scheduler 外增加一层名为 Admission Control 的调度层，来实现了 Goroutines 的优先级调度。
核心思想就是不要再将大量的 Goroutines 直接交给 Go Scheduler 去排队。而是先在应用层的 Admission Control 内的优先级队列里排队，只将当前系统能够负载的高优先级任务交给 Go Scheduler 去执行，这样就可以保证在高负载下系统仍然能保证重要任务的可用性。
具体的优先级实现有很多很巧妙的设计。比如优先级系统区分为 Token Based 和 Slot Based。对于 CPU 型任务，采用令牌桶算法，根据可用资源的情况来生成令牌，并且分发给任务使用，如果有任务超额使用了令牌，则扣减总的令牌数。而对于 I/O 型任务，因为 I/O 操作会阻塞 Goroutine，所以采用了 Slot Based 的方式，根据当前系统的 I/O 负载情况来动态调整 slot 的数量。而且动态调整的时间间隔也是动态变化的，尽量减少 CPU 消耗。
还观察到，即使使用这个优先级系统提交任务，偶尔也还是会导致 Go Scheduler 过载。而优化方法是将调度下一个任务的逻辑放到 task 的执行逻辑中，这样就只有在 task 被 Go Scheduler 实际交给 P & M 运行时，才会进行调度下一个任务的逻辑，从而确保了 task 不会在 Go Scheduler 堆积。
Refs:
* Source Code: cockroach Admit
* Go scheduler: Ms, Ps & Gs