hez2010

@lesismal #10

> 我可从来没说过这个, go 标准库海量并发占用高我自己就知道, 所以我才搞 nbio 之类的方案优化, 而且相对成熟了, 可以替换标准库方案, 但是你们非要"只用标准库方案"的方式来评价整个 golang, 就不合理了

标准库目前有计划改善这个问题吗？毕竟标准库用起来最简单，如果标准库能解决这个问题的话那岂不是不需要 nbio 这类的方案优化了。
另外看了一眼 nbio ，似乎是针对 client-server 网络场景特化的，牺牲了通用性。例如通过 goroutine 来代替多线程进行并行计算也是一个有效的场景。

@lesismal

> 毫无意义的测试, 却顺便拉踩, 捧 java 踩 go, 实在看不下去了我才必须出来澄清下.

跟 Go 的 goroutine 同样是 green thread 方案的 Java virtual thread ，在并没有做任何池化的情况下，只是简单的 new Thread ，在 1M tasks 占用确实比 goroutine 小了很多，这难道不能说明 goroutine 的资源占用确实不佳吗？

况且文章前面也肯定了 Go 在轻量负载时的占用小、否定了 Java 在轻量负载时的占用大，怎么就能被理解成踩一捧一？
如果你认为 Go 就是天下第一，一切 Go 表现不好的测试都是因为测试不好，而 Go 没有任何问题的话那我也没话说。况且这测试也不是我设计的。

没有看到哪里有内存泄露的风险。
调用 Subscribe 的方法所在的对象如果被回收了那对 _messages 的引用也就自动没了，除非你是在哪个具有 static 生命周期的对象中调用了 Subscribe 。

看了一眼你大概是开了 AOT ，然后出现问题所以只有 native 的调用栈，没有 managed 调用栈。
目前 wasm 关于调试这方面的基础设施还很不完善，你可以试试用 AppDomain.UnhandledException 挂一个函数把 stacktrace 用 Console.WriteLine 打印出来，应该能给你一些有用的信息。

因为 $parent[ItemsControl].DataContext 的类型是 object ，而 object 类型并没有叫做 ParentCommand 的成员，所以没法绑定到 ParentCommand 上去。你可以先做一次类型转换再绑定就可以了，就是你发的那个 {Binding $parent[ItemsControl].((vm:ParentViewModel)DataContext).ParentCommand}。
推荐你打开 CompiledBindings ，可能会导致需要在 xaml 里插入一些类型 hint ，但是如果你开了 CompiledBindings 的话你的 app 就是 AOT 兼容的，可以直接编译到本机二进制代码而无需 runtime 就能运行。

@lizhengbo ReFS 在系统升级过程中是会升级文件系统版本的，如果升级文件系统过程被强行中断了那只能自求多福了。
这种问题也不是 ReFS 独有的，换任何一个文件系统你强行中断正在进行中的文件系统升级过程都会这样。

“在系统设置里选择还原重装”
你该不会是这一步选择了清理磁盘吧。清理磁盘会删除所有分区的数据的。

试试 Phi-3.5-MoE 专家模型？参数 16x3.8B 。Benchmark 甚至跑得比 gpt-4o-mini 还高。
https://huggingface.co/microsoft/Phi-3.5-MoE-instruct

PowerShell 在 7.3 版本之前会把输出编码为 UTF16-LE 文本后输出，可能是这个原因导致你导出的 sql 出了编码问题，这个问题在 7.4 开始得到了修复，7.4 以后不额外转换编码而是直接写入数据。
Windows 自带的 PowerShell 还是 5.x 版本自然还是未修复之前的行为。