@FrankAdler Windows Admin Center 、PowerShell 里应有尽有。

@seaiaddca Azure 整套都是构建在 Windows Server 上的。

@FrankAdler 同理，把小拇指放到 ctrl 上一样非常省力

用 .NET 能帮你省掉很多事情和时间，多出的精力可以用来多去研究其他感兴趣的东西提升自己。润美的话，国外确实 C# 很多，而且薪资也高于 Java （数据来自 StackOverflow 近几年的开发者统计）。

@dcsuibian Rider 只是 UI 这层皮是 Java 写的，因为要兼容 IntelliJ 生态上的插件，但是 Rider 除了 UI 之外的 backend 是纯 C# 做的。

@pengtdyd 看历史的话，C# 到今天都是占有量前 5 的语言，历史上也从来没有出过前 10 ，有什么问题吗？

不是的，C# 里面非泛型的集合类接口和类型是已经淘汰的类型，一般不会使用。

顺带附一个 Windows 系统开发者写的 C++ coroutine 教程系列：
https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=105178

OP 里的测试之所以比回调慢 10%，估计也是因为有部分代码没被编译器成功 inline 掉，这个需要钻一下写法或者等待后续编译器的改进。
说“半成品”也是不妥当的，async/await 在语言层面上已经是完全体了，只不过 STL 里面没提供一个实现好的 Awaitable 罢了。并且在 Windows 上 WinRT API 里也有 `IAsyncAction` 和 `IAsyncOperation<T>`，都是按照 C++ 20 的 coroutine type trait 封装的 Awaitable ，因此如果你是做 Windows 开发（ C++）的话，那也不需要等 STL 的 Awaitable 的，因为 Windows 的现代 API 本身就天然是异步的，并且已经提供了相关的实现。

async/await 这套原理上是非常高效的，并且是通用的异步方案，调度也并不依赖线程池。
MSVC 团队的人之前在 CppCon 上展示了用 C++ 20 的 coroutine 做 CPU prefetch 来提升 CPU 缓存命中率，性能和你人工写的高度优化的状态机没有任何差距： https://isocpp.org/blog/2019/09/cppcon-2018-nano-coroutines-to-the-rescue-using-coroutines-ts-of-course-g
这种层面的东西是 goroutine 、project loom 等 stackful coroutine 根本没法企及的，他们的作用只是减少 blocking ，而 async/awaiit stackless coroutine 出发点是设计出一套通用的异步方案。

GC 不会立即 decommit 掉分配的内存的，因为很可能刚刚使用的内存很快又会被使用。
如果代码中没有内存泄漏的 bug 的话，这个数值不会一直往上增长，而是最终会维持在一个稳定的范围内。

一门语言只需要支持顺序、判断和跳转就能表达任何逻辑了，那照这么说其他任何特性全都是语法糖。

@hez2010 发布命令用的是 dotnet publish -c Release -r win-x64 /p:PublishTrimmed=true /p:PublishSingleFile=true

试了一下，使用 asp.net core 包含完整的 runtime 进行自包含发布，然后服务端渲染出一个完整的 HTML 页面出来，编译后体积 32mb ，运行之后占用内存 34mb 。所以你这个有 128mb 内存的话我觉得还是没问题的。


StackOverflow 就是 ASP.NET Core ，现在已经升级到了 .NET 5

.NET 7 会加入新的 NativeAOT 工具链，可以将应用程序像 C++、Rust 那样直接编译到本机代码，不含任何的 IL 代码，因此无法被反编译。不过首个版本应该会有不少兼容性问题，只能应对一部分代码。ASP.NET Core 可能还比较好办，但是 EF Core 这种重度依赖反射和表达式树的不一定能 works out-of-box 。

NTFS 完全没有开源过，macOS 和 Linux 的 NTFS 驱动都是第三方逆向做出来的，自然会有各种兼容性问题。相当于 macOS 和 Linux 的驱动把硬盘数据给损坏了，但他们以为自己没损坏，于是到了 Windows 的官方实现里认为数据是错误的。这怎么看都是 macOS 以及 Linux 的 NTFS 驱动实现有 bug 。

可以用 USB over TCP

这是一个古老的问题： https://github.com/PowerShell/PowerShell/issues/1908 ，PowerShell 的 > 会把东西转换成文本导致原数据被破坏，只不过因为为了兼容性一直没有进行这个破坏性更改。
另外 PowerShell 的 cat 也是默认转换成字符串数组，要用 Get-Content -AsByteStream xxx 或者 cat -AsByteStream xxx 才能获取到源数据。

不过下一个版本 PowerShell 7.3 应该会给出解决方案。