AlexZ 🦀

28.8K posts

AlexZ 🦀 banner
AlexZ 🦀

AlexZ 🦀

@blackanger

System in Rust, Application in AI. Slow down. Have fun. Live well. INTJ-A. No ism. Lifelong Programmer and Writer. Study in Public, Building in Public. 🦀 保命

Earth Katılım Temmuz 2007
1.7K Takip Edilen20K Takipçiler
AlexZ 🦀
AlexZ 🦀@blackanger·
过于真实
中文
3
0
0
175
AlexZ 🦀
AlexZ 🦀@blackanger·
好消息。 我这边有个岗位,会 Rust 最好,不会也没关系,但一定要重度 AI Coder,有自己的 AI 工作流。 可远程,但需要现场的时候也得在现场。 短期岗位,只限今年(看情况明年再说),适合喜欢 AI Coding ,挑战困难,今年还未找到工作的朋友。
中文
2
0
0
308
AlexZ 🦀
AlexZ 🦀@blackanger·
@damian_b 你以为的简单直观,只不过是你留下的技术债罢了
中文
0
0
0
45
Damian Barabonkov
Damian Barabonkov@damian_b·
I wasn't expecting that Go vs Rust tweet to hit a nerve. Quick elaboration based on what I've actually seen. I build a distributed sandbox system that has both Go and Rust components. I have effectively unlimited access to the strongest models, so I've spent a stupid amount of time reviewing and cleaning up LLM-generated code in both languages. The difference in reviewability is stark. Go was designed for thousands of engineers at Google to collaborate without stepping on each other. It has very few concepts, so the code ends up looking similar no matter who (or what) wrote it. You see the same patterns everywhere. The err returns are verbose, but at least they're predictable. Channels are about as fancy as it gets. GC removes an entire class of mental overhead. Goroutines + mutexes just work for most concurrency needs. As a result, LLM-written Go usually reads like a novel. You can understand what’s going on quickly. Rust is the opposite. More power, more ways to do the same thing, more concepts you have to hold in your head. When an LLM writes it, you often can't tell if something is elegantly minimal or just over-engineered. Arc> vs Go's atomic.Pointer[RoutingTable] is a perfect example. One makes you pause; the other one is obvious. You also have to know the de facto Rust standard library that lives outside the standard library (tokio, serde, anyhow, parking_lot, etc.). Moreover, Rust's concurrency model is excellent, but there’s just more surface area to reason about. So my upshot is that 95% of the time, if something is in Rust today, it probably would be clearer, faster to review, and easier to maintain in Go. What I meant by the "rewrite it in Rust" meme should mostly be "rewrite it in Go." That said, Rust has its place (I’ll do a follow-up post on the 5%). But picking it because it’s trendy is the wrong move.
Damian Barabonkov@damian_b

the "rewrite it in rust" meme should be "rewrite it in go" like 95% of the time the remaining 5% are for projects like: - the linux kernel - sqlite - chromium

English
29
25
424
42.1K
AlexZ 🦀
AlexZ 🦀@blackanger·
你以为的简单直观,实际上只是技术债而已
AlexZ 🦀@blackanger

无意与你争论什么。 但你认为的 atomic.Pointer[RoutingTable] 的"显而易见",是把不变量藏起来换来的; Arc> 的"令人犹豫",是把不变量摊开给你看。 在人肉评审成为瓶颈、agent 成为主要产码者的时代,让人犹豫三秒的诚实类型,胜过让人放心十秒、竞争三个月后才爆的简洁指针。 atomic.Pointer[RoutingTable] 之所以"显而易见",是因为它把三件最难的事都留白了: 1. 旧表何时回收? Go 靠 GC。复杂度没有消失,只是搬进了运行时。不可见、不可审计、也不出现在 diff 里。 Arc 不是过度设计,它是在没有 GC 的世界里把回收策略写进类型,做的正是 GC 的工作。 2. 读者拿到指针后,表还会变吗? Go 的答案是一条约定:"RoutingTable 发布后不可变",写在注释里、活在 reviewer 脑子里,编译器不管。谁在共享后改了一个字段,就是数据竞争,race detector 只能动态碰运气。 Rust 的答案是:Arc 之后没有 &mut,共享即不可变,违反直接编译不过。 3. 读路径的代价是什么? ArcSwap 存在的意义就是让读侧接近 wait-free、避免每次 load 都撞引用计数。这是一个有明确语义的、可查证的 RCU 式惯用法,不是花活。 所以 Arc> 不是啰嗦版的 atomic.Pointer,它是把 Go 藏在 GC 和口头约定里的三条不变量,全部写成了机器可查的合同。 原文说看不出 LLM 写的 Rust 是"简洁优雅还是过度设计"。 但优雅与否是风格问题,共享可变状态有没有竞争是正确性问题。 Go 把两个问题都留给人看代码时的直觉;Rust 把第二个问题整个交给编译器,只剩第一个给人。 在两种语言里你都要做风格评审,但只有一种语言让你不必在评审时逐行推演"这个指针被 swap 之后旧的 reader 会怎样"。 而且风格判断在 Rust 里反而更容易,不是更难: Arc> 是一个可以直接搜索、有唯一 crate 语义的具名模式。 看到它你就知道作者(或 agent)声明了"读多写少、整表原子替换"。 看到 atomic.Pointer[T],你知道的只是"这有个指针",设计意图在类型里根本没出现,你得去读调用方。词汇量大不等于歧义大;每个词更精确,恰恰是歧义更小。

中文
2
0
0
494
AlexZ 🦀
AlexZ 🦀@blackanger·
fable5 蹬完了,静等重置。
中文
1
0
0
241
AlexZ 🦀
AlexZ 🦀@blackanger·
类型即意图
AlexZ 🦀@blackanger

无意与你争论什么。 但你认为的 atomic.Pointer[RoutingTable] 的"显而易见",是把不变量藏起来换来的; Arc> 的"令人犹豫",是把不变量摊开给你看。 在人肉评审成为瓶颈、agent 成为主要产码者的时代,让人犹豫三秒的诚实类型,胜过让人放心十秒、竞争三个月后才爆的简洁指针。 atomic.Pointer[RoutingTable] 之所以"显而易见",是因为它把三件最难的事都留白了: 1. 旧表何时回收? Go 靠 GC。复杂度没有消失,只是搬进了运行时。不可见、不可审计、也不出现在 diff 里。 Arc 不是过度设计,它是在没有 GC 的世界里把回收策略写进类型,做的正是 GC 的工作。 2. 读者拿到指针后,表还会变吗? Go 的答案是一条约定:"RoutingTable 发布后不可变",写在注释里、活在 reviewer 脑子里,编译器不管。谁在共享后改了一个字段,就是数据竞争,race detector 只能动态碰运气。 Rust 的答案是:Arc 之后没有 &mut,共享即不可变,违反直接编译不过。 3. 读路径的代价是什么? ArcSwap 存在的意义就是让读侧接近 wait-free、避免每次 load 都撞引用计数。这是一个有明确语义的、可查证的 RCU 式惯用法,不是花活。 所以 Arc> 不是啰嗦版的 atomic.Pointer,它是把 Go 藏在 GC 和口头约定里的三条不变量,全部写成了机器可查的合同。 原文说看不出 LLM 写的 Rust 是"简洁优雅还是过度设计"。 但优雅与否是风格问题,共享可变状态有没有竞争是正确性问题。 Go 把两个问题都留给人看代码时的直觉;Rust 把第二个问题整个交给编译器,只剩第一个给人。 在两种语言里你都要做风格评审,但只有一种语言让你不必在评审时逐行推演"这个指针被 swap 之后旧的 reader 会怎样"。 而且风格判断在 Rust 里反而更容易,不是更难: Arc> 是一个可以直接搜索、有唯一 crate 语义的具名模式。 看到它你就知道作者(或 agent)声明了"读多写少、整表原子替换"。 看到 atomic.Pointer[T],你知道的只是"这有个指针",设计意图在类型里根本没出现,你得去读调用方。词汇量大不等于歧义大;每个词更精确,恰恰是歧义更小。

中文
1
0
0
446
AlexZ 🦀
AlexZ 🦀@blackanger·
无意与你争论什么。 但你认为的 atomic.Pointer[RoutingTable] 的"显而易见",是把不变量藏起来换来的; Arc> 的"令人犹豫",是把不变量摊开给你看。 在人肉评审成为瓶颈、agent 成为主要产码者的时代,让人犹豫三秒的诚实类型,胜过让人放心十秒、竞争三个月后才爆的简洁指针。 atomic.Pointer[RoutingTable] 之所以"显而易见",是因为它把三件最难的事都留白了: 1. 旧表何时回收? Go 靠 GC。复杂度没有消失,只是搬进了运行时。不可见、不可审计、也不出现在 diff 里。 Arc 不是过度设计,它是在没有 GC 的世界里把回收策略写进类型,做的正是 GC 的工作。 2. 读者拿到指针后,表还会变吗? Go 的答案是一条约定:"RoutingTable 发布后不可变",写在注释里、活在 reviewer 脑子里,编译器不管。谁在共享后改了一个字段,就是数据竞争,race detector 只能动态碰运气。 Rust 的答案是:Arc 之后没有 &mut,共享即不可变,违反直接编译不过。 3. 读路径的代价是什么? ArcSwap 存在的意义就是让读侧接近 wait-free、避免每次 load 都撞引用计数。这是一个有明确语义的、可查证的 RCU 式惯用法,不是花活。 所以 Arc> 不是啰嗦版的 atomic.Pointer,它是把 Go 藏在 GC 和口头约定里的三条不变量,全部写成了机器可查的合同。 原文说看不出 LLM 写的 Rust 是"简洁优雅还是过度设计"。 但优雅与否是风格问题,共享可变状态有没有竞争是正确性问题。 Go 把两个问题都留给人看代码时的直觉;Rust 把第二个问题整个交给编译器,只剩第一个给人。 在两种语言里你都要做风格评审,但只有一种语言让你不必在评审时逐行推演"这个指针被 swap 之后旧的 reader 会怎样"。 而且风格判断在 Rust 里反而更容易,不是更难: Arc> 是一个可以直接搜索、有唯一 crate 语义的具名模式。 看到它你就知道作者(或 agent)声明了"读多写少、整表原子替换"。 看到 atomic.Pointer[T],你知道的只是"这有个指针",设计意图在类型里根本没出现,你得去读调用方。词汇量大不等于歧义大;每个词更精确,恰恰是歧义更小。
Damian Barabonkov@damian_b

I wasn't expecting that Go vs Rust tweet to hit a nerve. Quick elaboration based on what I've actually seen. I build a distributed sandbox system that has both Go and Rust components. I have effectively unlimited access to the strongest models, so I've spent a stupid amount of time reviewing and cleaning up LLM-generated code in both languages. The difference in reviewability is stark. Go was designed for thousands of engineers at Google to collaborate without stepping on each other. It has very few concepts, so the code ends up looking similar no matter who (or what) wrote it. You see the same patterns everywhere. The err returns are verbose, but at least they're predictable. Channels are about as fancy as it gets. GC removes an entire class of mental overhead. Goroutines + mutexes just work for most concurrency needs. As a result, LLM-written Go usually reads like a novel. You can understand what’s going on quickly. Rust is the opposite. More power, more ways to do the same thing, more concepts you have to hold in your head. When an LLM writes it, you often can't tell if something is elegantly minimal or just over-engineered. Arc> vs Go's atomic.Pointer[RoutingTable] is a perfect example. One makes you pause; the other one is obvious. You also have to know the de facto Rust standard library that lives outside the standard library (tokio, serde, anyhow, parking_lot, etc.). Moreover, Rust's concurrency model is excellent, but there’s just more surface area to reason about. So my upshot is that 95% of the time, if something is in Rust today, it probably would be clearer, faster to review, and easier to maintain in Go. What I meant by the "rewrite it in Rust" meme should mostly be "rewrite it in Go." That said, Rust has its place (I’ll do a follow-up post on the 5%). But picking it because it’s trendy is the wrong move.

中文
1
0
3
1.5K
Jun Jiang
Jun Jiang@jasl9187·
之前说了用Codex的goal来做一个经营酒馆的SLG,图一是Codex生成的概念图,plan 文档数万行(superpowers协助),全程 Sol Ultra,最终使用 67,105,606 tokens(明显不准,我一共用了四次重置,当然中间还干了别的工作),历时约 4 天 17 小时 2 分钟。 图二是成品,这连垃圾都算不上了。
Jun Jiang tweet mediaJun Jiang tweet media
中文
6
0
1
403
AlexZ 🦀
AlexZ 🦀@blackanger·
华盛顿大学 + AI2 团队在本月做了一件对 Harness 自进化 "泼冷水"的工作: 质疑自动 harness 进化(automatic harness evolution)这条技术路线目前报告的收益,可能大部分是重复采样(repeated sampling)的功劳,而不是真的进化出了更好的 harness 设计。 作者指出当前 harness evolution 研究(Meta-Harness、AHE、AEVO 这类系统)的评估方法有两个根本性漏洞: 第一,harness 进化本质上是一个迭代搜索过程。反复评估、修改候选 harness,消耗大量推理预算。那么它就必须和同等预算下的 test-time scaling 基线对比,否则无法区分收益来自"更好的设计"还是"更多的尝试次数"。 第二,搜索和评估用的是同一个 benchmark。在 Terminal-Bench 上搜索 harness,再在 Terminal-Bench 上报告成绩,收益可能只是对任务分布的过拟合。 他们自己设计了一个控制变量实验,得到的三组结果,也是基本坐实了"进化"学到的是任务特定的适配,而非可迁移的设计原则。 即,现在所谓的 Harness 自进化还做不到真正的泛化增益。
Yike Wang@yikewang_

Automatic harness evolution appears to be a promising path toward AI self-improvement, but we find that its gains still largely come from repeated sampling and show limited generalization. Blog post: yikee.github.io/harnessevoluti… Code: github.com/rethinking-har…

中文
5
13
58
11.2K
Ken W
Ken W@kenw_2·
广西省级拉力赛,七月赛公开组,车手小威,9岁。
中文
38
2
60
24.4K
老鬼
老鬼@laogui·
男人的快乐
中文
3
0
4
697