Forwarded from Hacker News (yahnc_bot)
A career ending mistake https://bitfieldconsulting.com/golang/career
Bitfield Consulting
A career ending mistake: time for an exit strategy? — Bitfield Consulting
As software engineers, we're constantly making detailed, elaborate plans for computers to execute. Isn't it weird that we rarely give a moment's thought to the program for our own careers?
Forwarded from 少数派sspai
亲情无断片，网络不掉线——我的家庭网络改造小记 [by EstrellaXD]
https://sspai.com/post/71258
https://sspai.com/post/71258
少数派 - 高品质数字消费指南
过年回家做什么，我的老家网络改造小记 - 少数派
新的一年，希望远在异地的父母们也能用上舒适的网络。
Forwarded from 少数派sspai
年度征文 | 如何高效写出自己认可的文字？ [by 花生酱先生]
https://sspai.com/post/71105
https://sspai.com/post/71105
少数派 - 高品质数字消费指南
年度征文 | 如何高效写出自己认可的文字？ - 少数派
编注：本文是少数派2021年度征文活动#效率21标签下的入围文章。本文仅代表作者本人观点，少数派对标题和排版略作调整。和往年不同，今年文章的数据表现将很大程度上决定征文活动的最终走向，包括「双倍稿酬（ ...
Forwarded from Yachen's Channel
我有一盆冷水想泼给大家。讲两个故事：
一是我14年的时候，创业做智能传感器和智慧商业，天天去给各路几百强的 CxO 做项目展示，雄心壮志觉得很快公司就能颠覆整个零售行业，天天和打了鸡血一样。
退出项目一两周后，就觉得自己很傻逼，不知道是哪来的迷之自信。
类似的情况又出现在了 2020 年，Clubhouse 刚火起来的时候，觉得这产品太牛逼了，简直就是新一代的SNS，每天花大量时间泡在上面，还鼓动朋友立刻搞类似的功能。朋友说他们早已调研过，觉得这个产品不可持续，我当时表示不能理解。
等新鲜劲过了 Clubhouse 也正好被封了，才发觉确实也不过如此。
我自认为还算是一个比较理智和冷静的人，事后来看这两件事，我是无法能够理解我当时的狂热的，而且在狂热之下，我也做出了很多错误的判断。
以这两个小故事劝谏一下现在热衷于 Web3 的朋友。不是说 Web3 不好，可以换个思维和立场冷静一下。
一是我14年的时候，创业做智能传感器和智慧商业，天天去给各路几百强的 CxO 做项目展示，雄心壮志觉得很快公司就能颠覆整个零售行业，天天和打了鸡血一样。
退出项目一两周后，就觉得自己很傻逼，不知道是哪来的迷之自信。
类似的情况又出现在了 2020 年，Clubhouse 刚火起来的时候，觉得这产品太牛逼了，简直就是新一代的SNS，每天花大量时间泡在上面，还鼓动朋友立刻搞类似的功能。朋友说他们早已调研过，觉得这个产品不可持续，我当时表示不能理解。
等新鲜劲过了 Clubhouse 也正好被封了，才发觉确实也不过如此。
我自认为还算是一个比较理智和冷静的人，事后来看这两件事，我是无法能够理解我当时的狂热的，而且在狂热之下，我也做出了很多错误的判断。
以这两个小故事劝谏一下现在热衷于 Web3 的朋友。不是说 Web3 不好，可以换个思维和立场冷静一下。
Forwarded from codedump的电报频道 (老C)
# 推荐
[动态追踪技术漫谈 - OpenResty 官方博客](https://blog.openresty.com.cn/cn/dynamic-tracing/)
火焰图、动态追踪技术（Dynamic Tracing）等这些知识点，最开始我都是从这里学来的。
[动态追踪技术漫谈 - OpenResty 官方博客](https://blog.openresty.com.cn/cn/dynamic-tracing/)
火焰图、动态追踪技术（Dynamic Tracing）等这些知识点，最开始我都是从这里学来的。
blog.openresty.com.cn
动态追踪技术漫谈 - OpenResty 官方博客
什么是动态追踪 动态追踪的优点 DTrace 与 SystemTap SystemTap 在生产上的应用 火焰图 方法论 知识就是力量 开源与调试符号 Linux 内核的支持 硬件追踪 死亡进程的遗骸分析 传统的调试技术 凌乱的调试世界 OpenResty XRay
Forwarded from Rust 视界
Go 语言核心设计开发团队成员 Russ Cox 在推特上针对 AWS 前几天发布的 可持续性 Rust 的相关文章提出了批评。
以下是机翻 Russ Cox 十几条推特中的观点，一句话总结就是：“ AWS 的报告对 Go 语言这几年的改进有点失真，那个多语言能耗统计表格是2017年的，故意忽视 Go 语言这么多年的改进是不负责任的”。总得来说，Russ 的观点是很客观的。他也承认 Rust 是一门优秀语言，他更关心的是，如何让 Rust 和 Go 语言如何相互补充并能很好合作的方式。
1. 首先，“几年前真正有趣的研究”存在明显的问题。首先，它于 2017 年 10 月在 Intel i5-4460 CPU（2014 年第二季度）上使用 Go 1.6（2016 年 2 月）发布。那是永远的过去了。
2. 除此之外，"非常有趣的研究 "假设计算机语言基准游戏是可比程序的来源，如果你知道那个网站的话，这根本就不是真的。
3. 如果你的研究报告声称C++比C多用34%的能量，多用56%的时间，多用14%的内存，那么是时候重新审视你的假设了。大约每一个C程序都是一个有效的C++程序，所以C++不可能输，尤其是不可能输得那么惨!
4. 所有这些都是在说，"真正有趣的研究 "其实并不有趣。事实上，显然应该以一种健康的怀疑态度来看待它。
5. Discord帖子中关于从Go切换到Rust的总结是令人难以置信的误导。
6. 最初的Discord帖子显示了一个单一的图表，绘制了Go服务器和同等的Rust服务器。Rust线的性能更可预测，避免了Go线的延迟峰值，但这两条线大致相当。
7. 相反，AWS的帖子将Go图显示在Rust服务器经过重大改写以使用新的数据结构和更多的内存后的图旁边，圈出了 "ms "与 "μs "的时间尺度。这要么是对Discord帖子的完全误解，要么是公然的不诚实。
8. 作为一个旁观者，我自己以前也用过这种比例变化来说明问题（https://swtch.com/~rsc/regexp/regexp1.html）。当你展示一个诚实的、公平的比较时，这是一个很好的方法来说明问题。但是AWS的帖子并不是这样。
9. 说白了，Discord的帖子是公平的。它展示了Go服务器和同等的Rust服务器的“苹果对苹果“的比较。在帖子的后面，它又把Rust服务器的数据结构和额外的内存改写后，单独进行了图表。AWS的帖子对此进行了歪曲。
10. 也就是说，Discord的帖子也描述了Go 1.10，而Go 1.18也即将发布。这八个版本有很多改进，减少了有非常大的堆或非常多的goroutines的程序中的GC暂停（而Discord服务器两者都有）
11. 所以，使用最近的Go，Discord的延迟峰值会大大减少，我们也有计划进一步减少它们。但是，对于该服务器来说，Rust仍然是一种很好的语言，团队做出了一个合理的决定。(等待Go的改进也是可以的。)
12. AWS的帖子确实对Rust提出了一些诚实、公正的观点，这使得他们把这些关于Go的误导性陈述包括在内更加令人遗憾。他们没有必要这么做。Rust足够好，可以独立存在。
13. 就个人而言，与其阅读那些假装Go与Rust是某种零和游戏的博文，我更愿意关注Go和Rust相互补充并能很好合作的方式。比如这个帖子。https://thenewstack.io/rust-vs-go-why-theyre-better-together/
以下是机翻 Russ Cox 十几条推特中的观点，一句话总结就是：“ AWS 的报告对 Go 语言这几年的改进有点失真，那个多语言能耗统计表格是2017年的，故意忽视 Go 语言这么多年的改进是不负责任的”。总得来说，Russ 的观点是很客观的。他也承认 Rust 是一门优秀语言，他更关心的是，如何让 Rust 和 Go 语言如何相互补充并能很好合作的方式。
1. 首先，“几年前真正有趣的研究”存在明显的问题。首先，它于 2017 年 10 月在 Intel i5-4460 CPU（2014 年第二季度）上使用 Go 1.6（2016 年 2 月）发布。那是永远的过去了。
2. 除此之外，"非常有趣的研究 "假设计算机语言基准游戏是可比程序的来源，如果你知道那个网站的话，这根本就不是真的。
3. 如果你的研究报告声称C++比C多用34%的能量，多用56%的时间，多用14%的内存，那么是时候重新审视你的假设了。大约每一个C程序都是一个有效的C++程序，所以C++不可能输，尤其是不可能输得那么惨!
4. 所有这些都是在说，"真正有趣的研究 "其实并不有趣。事实上，显然应该以一种健康的怀疑态度来看待它。
5. Discord帖子中关于从Go切换到Rust的总结是令人难以置信的误导。
6. 最初的Discord帖子显示了一个单一的图表，绘制了Go服务器和同等的Rust服务器。Rust线的性能更可预测，避免了Go线的延迟峰值，但这两条线大致相当。
7. 相反，AWS的帖子将Go图显示在Rust服务器经过重大改写以使用新的数据结构和更多的内存后的图旁边，圈出了 "ms "与 "μs "的时间尺度。这要么是对Discord帖子的完全误解，要么是公然的不诚实。
8. 作为一个旁观者，我自己以前也用过这种比例变化来说明问题（https://swtch.com/~rsc/regexp/regexp1.html）。当你展示一个诚实的、公平的比较时，这是一个很好的方法来说明问题。但是AWS的帖子并不是这样。
9. 说白了，Discord的帖子是公平的。它展示了Go服务器和同等的Rust服务器的“苹果对苹果“的比较。在帖子的后面，它又把Rust服务器的数据结构和额外的内存改写后，单独进行了图表。AWS的帖子对此进行了歪曲。
10. 也就是说，Discord的帖子也描述了Go 1.10，而Go 1.18也即将发布。这八个版本有很多改进，减少了有非常大的堆或非常多的goroutines的程序中的GC暂停（而Discord服务器两者都有）
11. 所以，使用最近的Go，Discord的延迟峰值会大大减少，我们也有计划进一步减少它们。但是，对于该服务器来说，Rust仍然是一种很好的语言，团队做出了一个合理的决定。(等待Go的改进也是可以的。)
12. AWS的帖子确实对Rust提出了一些诚实、公正的观点，这使得他们把这些关于Go的误导性陈述包括在内更加令人遗憾。他们没有必要这么做。Rust足够好，可以独立存在。
13. 就个人而言，与其阅读那些假装Go与Rust是某种零和游戏的博文，我更愿意关注Go和Rust相互补充并能很好合作的方式。比如这个帖子。https://thenewstack.io/rust-vs-go-why-theyre-better-together/