作者w180112 ([NOOB]我超RETARD我超废 )
看板Soft_Job
标题Re: [讨论] Rust 2024 发布正式版
时间Sat Mar 1 10:23:06 2025
开战了
说Go是C继任者真的是很难接受欸
一堆地方不好用Go写吧
k8s/docker并不是真的效能很吃紧而是需要并发度够高又稍微方便的语言
但很多地方Go的效能都不够吧
而且Go的自由度也低
就说平常需要对structure pointer cast就很不方便
现在上班在写的c project 很在意cache hit rate /memory management/system call耗时?
些 Golang都很难做到高效与方便的管理
效能分析Golang也难以像C可以高度最佳化
GC就是一个最好的例子
至於C的&& 跟&
套一句Jserv的话：C假设使用者都是成熟的大人
※ 引述《PosetMage》之铭言
: ※ 引述《Rust (lang)》之铭言：
: : https://blog.rust-lang.org/2025/02/20/Rust-1.85.0.html
: : 知道Rust这个程式语言也超过十年了，
: : 自从1.0稳定版推出之後，
: : 就以每三年一个大版本的方式演进，
: : 今年则是轮到了Rust 2024
: : （对，因为延迟了一段时间到2025才发布）。
: : 不过我看了一下看起来是这次最大的改动RPIT，
: : 然後根本不知道在写什麽OTZ，
: : 只能说Rust的复杂性越来越高了......
: : 啊对了Future也进Prelude了～
: 好像蛮多人想问为什麽rust要存在XD
: 简单说可以看看kotlin kotlin使用了JVM 换言之就是复用已经发展成熟的语言後端
: rust复用的是成熟的LLVM IR後端 前端C++已经发展到乱七八糟的 早就该重新设计
: 就如同kotlin是一个现代前端 rust也是现代前端
: 推文有人说C C也是古老不良设计的语言 比如file系参数顺位并不统一
: --
: 至於问我喜欢哪个语言喔 我不会rust 我只会c++23
----
Sent from
BePTT
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 72.143.218.142 (加拿大)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1740795788.A.5B9.html
1F：推 pot1234: 一开始就是听同学说golang跑的跟C++一样快，想说论文用g03/01 11:16
2F：→ pot1234: olang写。结果golang big被gnu打烂，还要外接c ++librar03/01 11:16
3F：→ pot1234: y03/01 11:16
4F：推 crazycy: Go除了Goroutine这功能之外 写起来也不像一个现代语言03/01 11:56
5F：推 tsaigi: go跟c差远了…03/01 13:22
6F：推 MATT1899: 写C过的人应该会觉得Rust的Thread很直觉 毕竟同样都是O03/01 13:41
7F：→ MATT1899: S level的东西 Goroutine我到现在还是没有很懂到底怎麽03/01 13:41
8F：→ MATT1899: 运作的 直到最近看了一本解说底层的书才稍微有些理解03/01 13:41
9F：→ pot1234: c++20跟boost都有类似goroutine的设计。thread跟routine03/01 14:42
10F：→ pot1234: 应该是不同层级的东西03/01 14:42
11F：推 KanzakiHAria: 找工作遇到go基本上就是高并发 其他常见node-ts03/01 14:58
12F：→ KanzakiHAria: c现在定位就是跟asm dsp这类底层指令在一起的语言了03/01 14:58
13F：→ KanzakiHAria: 写C的人是硬体业 写go现在就纯软後端03/01 14:59
不一定喔 我现在也是纯软 但project要高效能所以是用C
14F：→ KanzakiHAria: C++把一堆东西搬到编译器算完是要怎麽比快XD03/01 15:00
15F：→ KanzakiHAria: Go的STW主要靠高并发去藏 并发越高STW藏越好03/01 15:02
16F：推 ILoveAMD: && & 根本是不一样的东西 不知道 防呆到近乎偏执的 C#03/01 15:33
17F：→ ILoveAMD: 也没有引进 and or 的关键字 (虽然编译的时候会挡)03/01 15:35
18F：→ ILoveAMD: && & 根本是不一样的东西 不知道为何混再一起讲03/01 15:36
我也不懂为什麽前面要一起讲
19F：推 ohmylove347: 有GC的语言没资格和C/C++比效能03/01 15:59
20F：→ MoonCode: 我还以为 && & 是在讲引用或指标03/01 16:56
21F：→ Burwei: 现在没有人还拿Go跟C对标了吧 战Go跟Java比较有意思lol03/01 17:44
22F：推 Lhmstu: Go在云端元件上真的蛮强的03/01 19:32
23F：→ Lhmstu: go强项真的就是高并发03/01 19:35
24F：推 windows2k: high concurrency也不会是c/c++/rust这等级的水准，真03/01 19:39
25F：→ windows2k: 能说的是花费少许精力就能有个还不错的方案03/01 19:39
我也写过Go 的确很方便 但高并发也只是一直听人讲 实际跟C比也不知道怎麽样
26F：→ superpandal: 就是比较好写的c 外加反射可以少写很多东西03/01 19:54
27F：→ superpandal: 现在有泛型 基本上cast也很少写了 虽然编译速度变慢03/01 19:55
28F：→ superpandal: 效能的话我写的效能很不错 fmt包少用 尤其Sprintf方03/01 19:56
29F：→ superpandal: 法 基本上goroutine配channel外加select多工就很不错03/01 19:57
30F：→ superpandal: 了03/01 19:57
31F：→ superpandal: 强型别写的很不爽快就是了 外加runtime过大这个缺点03/01 19:59
32F：→ superpandal: 不然其实不错03/01 19:59
33F：推 KanzakiHAria: rometheus node_exporter也都是go 完全就是超多工专03/01 20:09
34F：→ KanzakiHAria: 门场景03/01 20:09
35F：→ KanzakiHAria: 不够多工用go拿不到什麽好处03/01 20:10
36F：推 Ekmund: 没有太多逻辑上的运算或效能要求 Go的轻松程度远超C/C++03/01 20:13
37F：→ Ekmund: 也因此把他讲成继任者就很奇怪 Go牺牲的就是C的强项啊03/01 20:13
38F：→ Ekmund: 你要比记忆体管理还真没几个语言能拿来跟C/C++比03/01 20:13
39F：→ Ekmund: 而且这一切都是建立在面向web service的场景下03/01 20:15
40F：→ Ekmund: 脱离这边就没Go的事了 连比都没得比 怎麽继任w03/01 20:16
41F：→ superpandal: 继不继承是使用者角度来说的 gc目前来看也还好03/01 20:21
42F：→ superpandal: 写系统也不是不可以 现在敏感场景少一些了03/01 20:23
43F：→ superpandal: 一样配上unsafe也可以快一点03/01 20:26
44F：→ superpandal: 一般常见写法go效能确实不好03/01 20:34
45F：→ Ekmund: 由我自己出发的话 使用时的直觉上是像的没错03/01 21:01
46F：→ Ekmund: C/C++跳Go时有很多即视感03/01 21:01
47F：→ Ekmund: 但回到两者客群的话 相当程度的不重叠..XD03/01 21:01
48F：→ Ekmund: 在C做过很多奇怪的东西 Go几乎就纯纯的backend03/01 21:01
49F：→ superpandal: 奇怪的东西多的是 是台湾整天在backend03/01 21:19
50F：→ superpandal: 多接触类unix世界会知道更多03/01 21:24
51F：推 KanzakiHAria: 就像上一篇提到有rust写的os redox 其实也有不少os03/01 21:50
52F：→ KanzakiHAria: 是用go写的 biscuit, gopher 很多小玩具也是go写的03/01 21:51
53F：→ kimi112136: 切牛排用牛排刀，野外生存用多功能刀，交换用不是不03/01 22:50
54F：→ kimi112136: 行，但是我为啥要多费工夫用不适合场景的工作？语言03/01 22:50
55F：→ kimi112136: 只是工具，懂得在不同场景用不同工具才是重要的好吗03/01 22:50
56F：→ cancelpc: Go算是特定领域较好,通用性没比较好.03/01 22:53
57F：→ cancelpc: c++真的语言过度复杂化,简单点反而不容易错误03/01 22:55
※ 编辑: w180112 (216.232.177.222 加拿大), 03/02/2025 01:49:53
58F：→ BoXeX: 其实那边我讲错 我应该要讲优先级才对 03/02 12:08
59F：→ BoXeX: &| 的优先级直观上应该要跟 +-之类一样 03/02 12:08
60F：→ BoXeX: 但现在这样搞很反直觉 虽然实务上C语言在用的时候 03/02 12:09
61F：→ BoXeX: 括号都加好加满就是了 03/02 12:10
62F：→ atst2: &|是位元运算，+-是数值运算, 放在一起比较有什麽意义吗? 03/02 13:17
63F：推 dmeiki: 楼上我想他指的是运算的优先权 03/02 19:24
64F：→ atst2: 所以我想问, 两种运算的目标就不一样了，要求优先级一样 03/02 19:42
65F：→ atst2: 是为了什麽? 03/02 19:43
66F：→ BoXeX: 像是wiki上例子 a & b == 7 直觉上会以为是 (a&b) == 7 03/02 20:13
67F：→ BoXeX: 但实际是a & (b == 7) 03/02 20:13
68F：→ BoXeX: 不用到优先级完全一样 但至少别在==之後 03/02 20:15
69F：→ labbat: 翻书就知道的东西了，就跟1|2<<3一样 03/02 20:23
70F：→ BoXeX: 写熟的当然都知道 但不影响这不是好设计吧 03/02 20:32
71F：推 Bencrie: 也许会有人觉得先乘除後加减不是好设计吧 03/02 20:47
72F：→ BoXeX: 好 你的程式整天会需要把相等判断结果做位元运算 03/02 21:32
73F：→ BoXeX: 用的比把位元运算结果做相等判断还多 03/02 21:32
75F：→ atst2: 查了一下, Dennis M. Ritchie 自己就有说明了. 03/02 21:55
76F：→ atst2: 简单摘录一下: 1. &|的优先权决定是延用B语言的 03/02 21:56
77F：→ atst2: 2. B语言中，&|的意义是由上下文决定，所以通常情况下会是 03/02 21:57
78F：→ atst2: 位元运算，但放到if()里面会变逻辑运算. 03/02 21:57
79F：→ atst2: 3. C语言为了处理语&|语意会变化的问题，引入了 && || 03/02 21:58
80F：→ atst2: 4. 在引入&&, ||後，有考虑过重新安排优先权，但当时还要 03/02 21:59
81F：→ atst2: 考虑与B语言的相容性, 认为成本太高所以就维持现状了. 03/02 22:00
82F：→ BoXeX: 感谢查询 这样看来当初设计时也知道是不好的设计 03/02 23:12
83F：→ BoXeX: 只是包袱太大就不管了 03/02 23:12
84F：→ atst2: 与其说是不好，不如说在语言发展初期，能做的选择就是这些. 03/02 23:26
85F：→ atst2: 毕竟现代的程式语言，能够参考C/C++/Java/Python/Ruby... 03/02 23:27
86F：→ atst2: 但C发展的当时，能参考的就不多，更何况还有硬体上的限制. 03/02 23:28
87F：推 ILoveAMD: 查了一下 c/c++ golang java javascript 优先度一样 03/02 23:33
88F：→ ILoveAMD: rust 有改 03/02 23:34
89F：推 ILoveAMD: c# php 也是跟 c 一样 03/02 23:50
90F：推 aria0520: c/c++写习惯了 03/03 00:30
91F：→ freeunixer: 从这个小故事我们可以知道,有事没事都要多读点书 (~误 03/03 09:30
92F：推 hobnob: 推讨论串，听各种意见受益良多 03/03 10:59
93F：推 Bencrie: 其实我写的 code & 跟 == 不会一起出现 XD 03/03 12:58
94F：推 ABuJiuHaoBun: 云领域已经是go的 03/03 13:36
95F：推 KyuubiKulama: 我会用括号把要先处理的包起来就是，後面compiler 03/03 14:46
96F：→ KyuubiKulama: 会优化的 03/03 14:46
97F：推 jimmytzeng: go 要引入外部套件超方便 03/03 18:13
98F：推 VScode: go可以直接import github link 觉得写小专案部署很方便 03/03 19:30
99F：→ Ekmund: &|行为牵涉到一组组的逻辑需求 使用时若放一起 就会很自 03/03 21:28
100F：→ Ekmund: 然地把每一组分开括起来...没太多遇到优先级的场景 03/03 21:28
101F：→ Ekmund: 可能遇过也忘了吧 03/03 21:28
102F：推 gagalala: Go已经没有在说要继承C了吧 然後cross compilation 真 03/04 09:26
103F：→ gagalala: 的很方便啊 在cloud native也是到处都是go 尤其是auth 03/04 09:26
104F：→ gagalala: 相关领域 03/04 09:26
105F：推 Litfal: 我也以为&是在说reference 03/04 12:53
106F：→ Litfal: ( )就是要加好加满阿，长一点的逻辑展开成具名变数更好 03/04 12:55
107F：推 Litfal: is_vaild_state = (b == 7); 後续具名使用就没有前後问题 03/04 13:01
108F：→ Litfal: 又易读 03/04 13:01
109F：→ yam276: 有GC的瞬间就不该也不可能说要取代C了 03/04 15:54
110F：推 Serisu: Go 很好写高并发 但是真的遇到了高并发效能又惨兮兮 03/05 23:53
111F：推 windows2k: c的後继者可以看看zig，不过未成熟就是了 03/06 10:01
112F：→ Lordaeron: 我很好奇，各位写Go的是有多高的拼发需求。 03/06 15:56
113F：→ superpandal: 对现代而言gc其实还好 有跑过有gc的系统就知道 03/07 01:00
114F：→ superpandal: zig就runtime更肥 好像还依赖llvm 听说要拿掉就是 03/07 01:01
115F：→ superpandal: 支持拿掉 llvm巨肥 03/07 01:02
116F：→ superpandal: 各大libc都包一份太疯狂了 03/07 01:05
117F：→ superpandal: 本来觉得llvm不错 但害人编译系统要以小时计就是差评 03/07 01:16
118F：嘘 GTR12534: 提先乘除後加减的那个可能要先回去小学重念乘除的意义 03/07 17:50
119F：推 wulouise: llvm compile有比较久？ 03/07 21:20
120F：推 Bencrie: 那拜托楼上大神教一下。优先级什麽的我只觉得是偏好而已 03/07 21:20
121F：→ Bencrie: 没有什麽设计好不好的问题 03/07 21:21
122F：→ superpandal: llvm compile其它专案很久 compile自己都很久 03/08 00:25
123F：→ superpandal: gcc也是很慢 一堆参数基本上也没什麽用 优化感觉 03/08 00:34
124F：→ superpandal: 都不怎麽明显 03/08 00:35
125F：→ superpandal: 平白增加功耗与需时 与轻量的相比编译速度完全不是一 03/08 00:40
126F：→ superpandal: 个量级 03/08 00:41
127F：→ wulouise: 所以楼上用过pch跟ccache还是一样? 03/08 02:21
128F：→ superpandal: ccache无法弥补这差距 03/08 14:36
129F：→ superpandal: 以前我都很沉迷整天捣鼓这些 03/08 14:43