Go语言是一个极容易上手的语言，而且Go程序的优化套路基本上被大家莫得清清楚楚的，如果你有心，可以在互联网上搜出很多Go程序优化的技巧，有些文章可能只介绍了几个优化点，有些文章从CPU的架构到Slice预分配，再到通过pprof找性能的瓶颈点等等全面介绍Go程序的优化，所以说可见的手段基本上被大家摸得门清，最近老貘出了一道题，如下所示，可以看到大家对Go语言的优化已经摸的多深了。
Rust 并发编程实战课
Rust 越来越得到广泛的应用，尤其对于追求性能的系统编程领域，最近还正式进入了Linux 内核的主干，并预计在 6.1 版本中正式使用。
Rust 虽然设计理念独树一帜，性能也是那么的优秀，但是学习起来并不简单，学习曲线很陡。同时由于Rust不像Go语言一样，不受某一家公司的控制，看起来在开源方面貌似很“Open”,所以也得到了广大开发者的青睐，贡献了许多库，不乏高质量的库，甚至比标准库的质量和使用率还高，这也带来了一些问题。其他语言，比如Go语言，它的标准库相当的优秀，比如一堆优秀高质量的并发原语，在开发者在开发并发程序的时候，需要同步控制和任务编排时，脑海中第一选择就是标准库的并发原语，实在找不到合适的并发原语才去找第三方的库。但是Rust不一样，虽然标准库也提供了一些优秀的并发原语，但是限于语言的特性，使用起来相当的复杂，也有很多第三方的库提供性能更好或者特性更多或者更易使用的功能，所以在使用Rust开发并发程序的时候，很多开发者对并发逻辑的控制无从下手，或者有“选择困难症”，所以我专门开了一个序列，准备系统的介绍 Rust的并发编程的知识，通过一百多个简短而明确的例子，全面介绍Rust的并发编程和相关库的使用：rust programming via rust .
十多年了，这个最容易犯错的Go语法终于要改了
Go 语言中你最容易犯错的语法是什么？很多人可能都有不同的答案，但是最多的答案之一就是 for 循环中变量的使用问题了。即使是 Go 团队的开发者，我也曾看到他们提交的代码犯过这种错误，更不用说其他的 Go 开发者了,比如this problem at Let’s Encrypt,几乎每个Go开发者都犯过这个错误，这种类型的错误已经在我的心里留下了阴影，每次写for循环我都心头一紧，经常使用局部变量shade一下循环变量，即使没有问题。
Go CPU profiler 内幕
原文: Inside the Go CPU profiler,作者 Sümer Cip。我猜测 Felix Geisendörfer 肯定会进行评论，果不其然。
Go 是那种自带 profiler (分析器)的语言之一。它的运行时包含强大的自成一派的各种 profiler。其它语言，比如 Ruby、Python 和 Node.js, 它们也包含 profiler或者一些用来编写profiler的API，但是与Go的开箱即用的 profiler相比，它们提供的profiler功能有限。如果你想多了解Go提供的这些可观察工具的情况，我强烈推荐你阅读 Felix Geisendörfer的 The Busy Developer’s Guide to Go Profiling, Tracing and Observability。
作为一个好奇的工程师，我喜欢挖掘事物在底层上的工作方式，我一直想去学习Go CPU profiler底层·是怎么工作的。这篇文章就是此次探索的结果。每当我阅读Go运行时代码时，我总是学到到一些新东西，这次也不例外。
多年老司机，面对这些Go并发问题，也迟疑了
Go一向以它的简单易学而著称，我也遇到过同学说只需半天就能掌握Go语言了，两三年的Go开发经验就称专家了。
想比较Rust等编程语言，Go语言的确容易上手，查看Go语言的规范你也会看到，它的语言规范相比较其它编程语言非常的简短，的确可以一个小时就可以读完。但是如果你深入了解这门语言(其它语言也是类似情况)，就会发现很多细节的地方，需要花谢心思和时间仔细琢磨琢磨。这不，我先来几道Go并发的源代码考考你，看看你能回答上来不？
与日俱进，在 Go 1.20 中这种高效转换的方式又变了
在 Go 1.19 的开发中, string.SliceHeader和string.StringHeader经历了一个生死存亡的争斗，这两个类型一度被标记为弃用(deprecated),但是这两个类型经常用在 slice of byte 和 string 高效互转的场景中，如果被标记为弃用，但是目前还没有可替代的方法，所以这两个类型又把弃用标记去掉了，如无意外，它们也会在 Go 1.20 再次被标记为弃用。
一个线程安全的泛型支持map库
orcaman/concurrent-map是一个非常高效的线程安全的map库，正如它的文档中所说的那样，标准库sync.Map更适合append-only的场景，或者说少写大量的读的场景，如果针对多读多写的场景，concurrent-map可能会更有优势。它是通过分片的方式，将锁的粒度减少，从而提高性能。
今年初的时候，这个库做了改造，开始支持泛型，但是不幸的是，它只支持Value值泛型，它的key只能是string类型，这就限制了它的应用场景。
