@alexkkaa 提供一种最优解这件事本身就是不可能的，随着语言的演进原来的最优解将会不断变成非最优解，这个时候进行改进难道要把以前的东西砍掉吗？老项目、生态和兼容性怎么办？ C# 现在内置了代码分析器，编写代码的时候会自动给出推荐用来自动将老代码翻新，可以把严重等级设置成“错误”那就等同于废弃了老的特性。

而你提到的 go 倒不如说是矫枉过正，虽然目前只有一种解法，但却经常提供的是不好的解法，最典型的就是 go 的不少库实现居然在里面用反射枚举类型（如 fmt 等等），这也注定了这个库的性能和可扩展性都很低，这是典型的语言匮乏导致实现暴力效果还不好的例子。虽然 1.17 加了泛型但不好好做泛型约束和 sum types，却在做类型的枚举，扩展性没有改观；而非约束泛型 any T 底层仍然是 interface{}，性能方面也没有任何改观。此外，鸭子类型本应该是 trait 理论诞生之前的临时替代品，go 诞生于 trait 出现之后的世界却大范围使用这套类型系统，不出意外出现了不少 interface 被意外实现的例子，于是又不得不在类型定义里面添加小写开头的函数或者 i() 来避免，这也本身也是一种类型系统设计失败的表现。那问题来了，除非 go 愿意从头错到尾，如果想要着手解决这些问题，那势必会引入新的特性来改进语言，一件事只有一种解法的状态本身也自然会被打破。

go 自身的设计导致根本不适合用来开发 GUI，因为缺了太多的东西，费尽力气好不容易画出个空白窗口，别人界面都快做完了。开发原生跨平台 GUI 的话（不是 web 套壳那种）还得看 C#（ Avalonia 、MAUI 等等） 或者 C++（ QT 等等）。

@yejinmo 没必要一直跟着学，用到的时候花几分钟查一下文档就知道是怎么回事了。

@pcbl 基础库和语言完全是两个团队负责和更新的，相互并不冲突，况且 .NET 6 也确实给基础库引入了不少新的 API，只不过这篇是介绍语言的所以没有提。

@huang119412 TPM 1.2 在国内违法，2.0 不违法。但是国外生产的 TPM 2.0 违法，国内生产的不违法。

基于 win10 的，ltsc 追随 Windows Server 的 LTS 版本，Windows Server 2022 是 win10 分支的

@ikas 不是的，splash screen 是 uwp 特有的，如果你用 win32 + winui 3 的确可以做到和 uwp 一样的 UI 样式，但是不会有启动时的 splash screen

@ikas 新的系统自带应用全都是 UWP，不是 Win32 的。凡是 Win32 都不会有启动时那一瞬间的 splash screen 。

@SenLief vbox 没法做到 Linux 和 Windows 的互操作。比如在 Linux 内直接调用启动 Windows 里的程序。

HandyControl、MaterialDesignXaml、Panuon.UI.Silver 等等很多呀，都是开源免费的

毕竟直接搜 C#搜不出来，必须得写成 c sharp 才能搜出来