WebAssembly 的另一个雄心壮志是脱离 Web ，就像 WebGPU 、WebRTC 一样，成为可以独立存在的技术。

WebGPU 现在已经发展成一个桌面图形技术栈，有自己的 Shader 语言； WebRTC 也成为 P2P 协议的一种了。这个意义上来说，WebAssembly 其实有替代 JVM 、成为原生应用虚拟机的目标。

像 https://wasmtime.dev/ 这样的独立 WebAssembly 运行时，已经比较成熟了。只是「一次编译，到处运行」的需求究竟存不存在，还真不好说。

我是这么助记的，以股票为例：

精确率：说一个人「精」，就是说他投资非常小气，只有算准了绝对涨的时候才会买，所以 精确率=#(真涨了)/#(他看涨)

准确率：说一个人「准」，就是说他是股神，每次不管涨跌都能预测对，所以 准确率=#(真涨或跌了)/#(预测总数)

其他也类似：

召回率：把每次涨的时刻都回忆（ recall ）起来，这人有几次看涨？所以召回率=#(他看涨)/#(涨了)

这里很明显「精」和「召回」是矛盾的，一个人越精、越保守，他就越容易漏掉一些小涨的瞬间；反过来，一个人闭着眼睛投资永远看涨，那他召回率就是 100%，但肯定亏本。所以，要综合衡量这两个方面，就用 F-score 来计算。

> 怎样才能让 Android 用上非阉割版的 java

首先，Java 标准是分得很碎的，至少有 Java SE API 和 JDK API 两部分[1]。Java SE 保证在所有完整的 Java 实现中存在，但 JDK 只是可选。你说的 com.sun.net.httpserver.HttpServer 属于 jdk.httpserver 模块[2]，所以甚至都不属于 Java SE ，而是 JDK 这个可选规范的一部分。

然后，Android 用的根本不是标准 JVM ，各种 Java 8 、11+ API 都是脱糖实现的[3]，所以塞不进额外模块是理所当然的。先不说这些模块的实现可能依赖额外语言功能，光是有 JNI/JNA 就足够喝一壶了。这些平台下的最优解就是换用对应的库，不要想着沿用原来的写法了。

当然如果你钻牛角尖说「我就是要用 com.sun.net.httpserver.HttpServer ，别的库用了我晚上睡不着」，这里[4]也有人试过直接把 runtime 打包塞进 APK 里，至少 HttpServer 看起来能工作。

[1] https://docs.oracle.com/en/java/javase/23/docs/api/index.html
[2] https://docs.oracle.com/en/java/javase/23/docs/api/jdk.httpserver/module-summary.html
[3] https://developer.android.com/studio/write/java11-default-support-table
[4] https://stackoverflow.com/a/70486739

@SunsetShimmer #1 虽然但是，第一个就是楼主的吧

「无栈协程=状态机」这样的思想在 Rust 这种无默认运行时的语言中表现得更明显： https://doc.rust-lang.org/stable/std/future/trait.Future.html

从上面的文档可以看到，Rust 对 Future 的定义就是：「一个有 poll(context) 方法的对象，每次执行返回 Pending 或者 Ready(result) 两种状态之一」。任何实现了 poll 方法的对象都被承认为一种协程。

这很难吗： https://letmegooglethat.com/?q=android+http+server+library

这种库实在太多以至于我不知道先给你推荐哪个……我用得最多的是 https://github.com/ktorio/ktor

Alacritty 和 Kitty 这种实在太 raw 了，除了终端几乎没有任何额外功能：标签页、快速连接 SSH…

我推荐 WezTerm

https://wezfurlong.org/wezterm/ssh.html

@MacsedProtoss #42 Flutter 一般根本接触不到多线程的，能用上 Isolate 的应用少之又少。好奇你说的「重活」是什么？写代码跑 FFT 还是自己实现数据库？

原生代码交互确实很傻逼，Flutter 文档语焉不详，但一般都有现成的跨平台包可以调吧，pub.dev 生态还是很好的。

你说的「不前端」的思维是什么？我看 SwiftUI 和 Flutter 的核心思想也挺像的啊。

@nicaiwss #27 RIL 其实并没有「那么高比例」的 unsafe 代码。除了和 C 对接的接口，其他几乎是完全 safe 的。

=============

另外我发觉很多人阅读能力确实为 0 。就引发争论的这件事而言，Rust in Linux 提交的补丁不是想「重写」内核中的东西，或者把看不顺眼的东西换成 Rust ，他们只是想「使用」 DMA 子系统。

他们提交的补丁主要涉及 DMA 的接口描述。再强调一遍，「并没有往 DMA 的 C 部分中加入任何 Rust 代码，是 Rust 编写的其他子系统需要用 DMA 」。有多少人看到标题就开始闭眼刷 RIIR （ Rust 重写一切）？

但仅这一点，就让负责 DMA 子系统的 C 维护者强烈反对了。这就意味着（一旦驱动依赖该子系统）主线中无法出现可用的 Rust 驱动，所以才让 Martin 沮丧。

@nicaiwss #23 都 2025 年了还有人信这种言论？也就骗骗自己了。

这样吧，你访问 https://github.com/trending/rust?since=monthly ，然后看看是不是重写，好吗？

@tomychen #18 实际上是房子频繁出问题，拆迁队早就赶过来说我给你免费拆，后续建我也包了（会抽人维护接口兼容性），房子主人（ Linus ）既不说好、也不说不好，搞得人家拆迁队走也不是、不走也不是，在旁边心存希望住了两三年，还要天天被某些房客扔狗屎恶心（某内核开发者故意天天改 interface 来恶心 RIL Team ）。

最后拆迁队实在绷不住了，敲门问能不能先改下你家庭院，结果直接被认定为强拆强建，拆迁队愤而跑路。

@XuanYuan #2 乍一看没搞懂上下文，把油猴插件关了才发现这用户早被我 block 了。能在所有技术贴（包括自己发的）下面宣泄火气，不知道谁招惹他了。https://i.imgur.com/krir4IG.png

不错，感觉是一个很好的 tauri + candle 实践，先 star 一下。

看了下代码，感觉主要 platform-specific 的是音频捕获？可以考虑一下 https://crates.io/crates/cpal


p.s. Windows 有系统级实时字幕，功能上是重合的，不过经常识别不准。