Jetpack compose 有实时预览（ Live Preview ）和热重载（ Hot reload ）啊。你确定你不是看漏了？或者你说的「热重载」是特指「写完代码后一瞬间更新界面」？

@NSAgold 感谢推荐。你觉得 Cloudflare Redirect 的国内访问质量怎么样呢？

@bli22ard #17 理论上是这样，但实际上有很多依赖根本无法静态链接（作者写 Makefile 就没考虑到，比如 GNUStep ），或者依赖极其繁杂（例如 libcurl ），或者使用了 musl-libc 不支持的扩展（例如 onnx ）。感觉一切的坏头都是 glibc 起的……

@fcten 比现状好吧，现状是「只允许同时用一个运行时，兼容性问题用户自己想办法」。在「让用户装多个运行时」和「让用户自己学习编译知识从头编译，或者为了你的软件升级整个系统」，我觉得还是前者方便点。

@pursuer @unused #12 我也越来越觉得这个更是 Linux 的问题了。就像包管理和 init 的选择，永恒的碎片化……

@unused #13 是的，但作为最终用户和开发者其实都不用考虑这些，相当于有人做兼容了。而且只要有一个人做好兼容，其他用户都能获益。

@yanqiyu

> 想要用 rust 做整个操作系统的 userspace ，大范围用上了动态链接（节约磁盘之类的理由），到时候 C++遇到的 ABI 的鸡毛蒜皮一个也跑不掉

我觉得比较好的形式可能是 Windows 的 Visual C++ Distributable 那样，把标准库按年代打包成运行时，然后让用户安装。这样既可以保证不需要向前兼容，又能兼容较新的程序，还能节省硬盘空间。

@InkStone 是的，但对于静态编译，glibc 是 strongly discouraged ，musl libc 也会有各种问题（例如不兼容 glibc 的一些代码、部分实现性能低），其他 libc 就更不用说了。

至于 libc++/libstdc++，我似乎都没看到有人静态编译过……

@w568w 另外协程的这些问题不影响吞吐量，只影响延迟。所以说其实只有延迟敏感的应用才需要担心

我总结你说的三点，其实都是一个问题：单线程的协程模型是否会被 内在（本身写的同步代码太复杂）或外在（调用了阻塞的第三方库）的 CPU 密集过程卡住事件循环？

答案是有可能，并且我遇到过不止一次了。

对策也是三个：

1. 取决于你 asyncio 的实现，是可以开多个 worker 线程进行池化调度的。并不是所有实现都是真的「单线程」。有一些高级运行时还有 work-stealing 之类的机制帮助多线程调度；

2. 人工检查可能卡住的地方，繁重任务放到新线程去做；

3. web 这种可能涉及高并发的情况，如果担心此类问题，还是用线程模型的框架较好。

@xiaoyangdkj 正想推荐这个来着，用了它两年，最后又换回 Jetbrains Mono 了。两个一对比就会发现 Intel One Mono 有点太宽、太细了，反而辨识度低

@Leviathann KotlinConf 2025 说的，到 2.4 应该还是 experimental 。

X 帖子： https://x.com/joreilly/status/1925451874116817181

这俩语言都是用来快工出糙活的。

不是说你考虑错误处理不对，而是语言设计者就不希望你这么写，最自然的方式就是 let it crash 。

如果希望严谨处理，你应该看 Rust 之类的有强错误标记的语言，或者等等接下来的 Kotlin 2.4 。

@wsseo 我记得我 22 年参加保密测试的时候就有「所有权」了，不知道现在又拿出说是什么意思。不过这个 Effect Handler 看着不错

@angrylid 有的果粉是真离谱，全天 24 小时监测全站手机言论，即使帖子和苹果半毛钱关系没有，也要强行岔开话题维护果爹

@lihang1329 嗯嗯。worker 我帖子里提到了，有那几个问题吗

@susandownes 谢谢，我现在用的就是这个工具来暴露服务。

这个工具的功能里和问题有关的应该只有 IP4P 功能？如果我没记错的话，这个功能应该是作者自己提出的非标准，支持的软件比 SRV 还少，必须用作者自己魔改的 frp 才能访问

> Cloudflare Tunnel

@ERvISTyP 这个能绑定自己的域名吗？国内速度怎么样？

> lucky

@SenLief 看了一下这个好像是软路由软件？不知道是怎么解决问题的？我看了一下文档里的「网友教程/经验分享」，里面相关教程的用法还是配置 Cloudflare Redirect 。这个和我自己手动配置有什么区别？

@yulon

> 首页最多的不是 LLM 相关吗

不是哥们，你一会说「 2025 年的新技术」，一会说「有 native 技术栈的」，现在又变成「 LLM 开发」了？你到底想找什么？

我是严格按照 native 技术栈在筛选啊，你 LLM 辅助开发的有几个是写 native 技术栈的？不全是你喷的「只会写 web 的人」？

首页切换到创意-分享创造，以下是最近 16 页里和 web/小程序 无关、有 native 技术栈的帖子：

- https://www.v2ex.com/t/1022439：Golang
- https://www.v2ex.com/t/1138399：Golang
- https://www.v2ex.com/t/1136900：C++
- https://www.v2ex.com/t/1136401：Rust
- https://www.v2ex.com/t/1136109：C
- https://www.v2ex.com/t/1135416：Golang
- https://www.v2ex.com/t/1133835：Rust
- https://www.v2ex.com/t/1133741：Rust
- https://www.v2ex.com/t/1133376：Rust

（翻了我 10 分钟，就找到这几个。V 站还是前端开发太多了……）

这就是你说的「 C++ 的杀手级别优势」？我看 C++ 也没几个啊。倒是很符合我的预期：Golang 和 Rust 平分秋色。正好，我自己也是写这两个的。

> LLM 主流几个底层和几个落地是 C++

……还提 AI Infra ，那你还真撞枪口上了，这跟我的研究方向密切相关。Huggingface 知道吧？他们的 tokenizer 、transformers 、safetensors ，还有最近新出的 xet ，要不你查查用什么写的？

说到推理落地，那就不得不提 Candle （也是 Huggingface ）和 mistral.rs 。至于你说的 Python 前端库底层用 C++，什么 PyTorch 、numpy 、pandas ，有没有可能人家刚开始开发的时候 Rust 才刚刚起步？尽管如此，今天我们也有 tch-rs （ PyTorch 的官方 Rust 绑定）、ndarray （ BLAS 加速的张量计算）和 polars ，都非常成熟了。尤其是 polars ，我了解的一些国内的大型 AI 实验室都在用，处理大型数据集的速度比 datasets （基于 Apache Arrow 和 Python ）快几十倍到上百倍。

> Ollama 这种应用层也是 Go 的，算上之前很多年的 Docker 也是 Go 的

你都知道 Docker 了，也知道他「之前很多年」了，为什么不动动小手去了解一下更新的 Podman 呢？ netavark 网络层隔离栈、composefs 虚拟文件系统、libkrun 虚拟化库，哪个性能关键的模块不是 Rust 写的？也就 crun 这个主要调系统 libc 和 Linux API 的，为了兼容性和方便用 C 写了。

> 其实都是 Rust 适合的领域，为啥社区没有掀起波澜呢

我就说说我了解的 LLM 开发：
uv 现在有成为 LLM 实验环境管理的黄金标准趋势，体验吊打之前所有工具，一些大型 Python 库（例如 JAX ）官网甚至都把 pip 安装说明给删了，只建议使用 uv 。
ruff 同理，现在绝大部分项目的标准 linter 。
ty 也有取代速度极慢、内存占用极高的 pyright 的趋势。

那还要怎么波澜？ Rust 都能和好多年的 Go 打平手，还已经成为你口中的天天 hype 的语言了，群体都成为最 fantic 的群体了，这还不算波澜？真天天说革新你又不乐意了。

@w568w #1 另外，为什么不直接看 https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers ？