开战了

说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系参数顺位并不统一
:

一开始就是听同学说golang跑的跟C++一样快，想说论文用golang写。结果golang big被gnu打烂，还要外接c ++library

Go除了Goroutine这功能之外 写起来也不像一个现代语言

go跟c差远了…

写C过的人应该会觉得Rust的Thread很直觉 毕竟同样都是OS level的东西 Goroutine我到现在还是没有很懂到底怎么运作的 直到最近看了一本解说底层的书才稍微有些理解

c++20跟boost都有类似goroutine的设计。thread跟routine应该是不同层级的东西

找工作遇到go基本上就是高并发 其他常见node-tsc现在定位就是跟asm dsp这类底层指令在一起的语言了写C的人是硬件业 写go现在就纯软后端C++把一堆东西搬到编译器算完是要怎么比快XDGo的STW主要靠高并发去藏 并发越高STW藏越好

&& & 根本是不一样的东西 不知道 防呆到近乎偏执的 C#也没有引进 and or 的关键字 (虽然编译的时候会挡)&& & 根本是不一样的东西 不知道为何混再一起讲

有GC的语言没资格和C/C++比效能

我还以为 && & 是在讲引用或指标

现在没有人还拿Go跟C对标了吧 战Go跟Java比较有意思lol

Go在云端元件上真的蛮强的go强项真的就是高并发

high concurrency也不会是c/c++/rust这等级的水准，真能说的是花费少许精力就能有个还不错的方案

就是比较好写的c 外加反射可以少写很多东西现在有泛型 基本上cast也很少写了 虽然编译速度变慢效能的话我写的效能很不错 fmt包少用 尤其Sprintf方法 基本上goroutine配channel外加select多工就很不错了强型别写的很不爽快就是了 外加runtime过大这个缺点不然其实不错

rometheus node_exporter也都是go 完全就是超多工专门场景不够多工用go拿不到什么好处

没有太多逻辑上的运算或效能要求 Go的轻松程度远超C/C++也因此把他讲成继任者就很奇怪 Go牺牲的就是C的强项啊你要比内存管理还真没几个语言能拿来跟C/C++比而且这一切都是建立在面向web service的场景下脱离这边就没Go的事了 连比都没得比 怎么继任w

继不继承是使用者角度来说的 gc目前来看也还好写系统也不是不可以 现在敏感场景少一些了一样配上unsafe也可以快一点一般常见写法go效能确实不好

由我自己出发的话 使用时的直觉上是像的没错C/C++跳Go时有很多即视感但回到两者客群的话 相当程度的不重叠..XD在C做过很多奇怪的东西 Go几乎就纯纯的backend

奇怪的东西多的是 是台湾整天在backend多接触类unix世界会知道更多

就像上一篇提到有rust写的os redox 其实也有不少os是用go写的 biscuit, gopher 很多小玩具也是go写的

切牛排用牛排刀，野外生存用多功能刀，交换用不是不行，但是我为啥要多费工夫用不适合场景的工作？语言只是工具，懂得在不同场景用不同工具才是重要的好吗

Go算是特定领域较好,通用性没比较好.c++真的语言过度复杂化,简单点反而不容易错误

其实那边我讲错 我应该要讲优先级才对&| 的优先级直观上应该要跟 +-之类一样但现在这样搞很反直觉 虽然实务上C语言在用的时候括号都加好加满就是了

&|是位元运算，+-是数值运算, 放在一起比较有什么意义吗?

楼上我想他指的是运算的优先权

所以我想问, 两种运算的目标就不一样了，要求优先级一样是为了什么?

像是wiki上例子 a & b == 7 直觉上会以为是 (a&b) == 7但实际是a & (b == 7)不用到优先级完全一样 但至少别在==之后

翻书就知道的东西了，就跟1|2<<3一样

写熟的当然都知道 但不影响这不是好设计吧

也许会有人觉得先乘除后加减不是好设计吧

好 你的程式整天会需要把相等判断结果做位元运算用的比把位元运算结果做相等判断还多

http://cm.bell-labs.co/who/dmr/chist.html查了一下, Dennis M. Ritchie 自己就有说明了.简单摘录一下: 1. &|的优先权决定是延用B语言的2. B语言中，&|的意义是由上下文决定，所以通常情况下会是位元运算，但放到if()里面会变逻辑运算.3. C语言为了处理语&|语意会变化的问题，引入了 && ||4. 在引入&&, ||后，有考虑过重新安排优先权，但当时还要考虑与B语言的相容性, 认为成本太高所以就维持现状了.

感谢查询 这样看来当初设计时也知道是不好的设计只是包袱太大就不管了

与其说是不好，不如说在语言发展初期，能做的选择就是这些.毕竟现代的程式语言，能够参考C/C++/Java/Python/Ruby...但C发展的当时，能参考的就不多，更何况还有硬件上的限制.

查了一下 c/c++ golang java javascript 优先度一样rust 有改c# php 也是跟 c 一样

c/c++写习惯了

从这个小故事我们可以知道,有事没事都要多读点书 (~误

推讨论串，听各种意见受益良多

其实我写的 code & 跟 == 不会一起出现 XD

云领域已经是go的

我会用括号把要先处理的包起来就是，后面compiler会优化的

go 要引入外部套件超方便

go可以直接import github link 觉得写小专案部署很方便

&|行为牵涉到一组组的逻辑需求 使用时若放一起 就会很自然地把每一组分开括起来...没太多遇到优先级的场景可能遇过也忘了吧

Go已经没有在说要继承C了吧 然后cross compilation 真的很方便啊 在cloud native也是到处都是go 尤其是auth相关领域

我也以为&是在说reference( )就是要加好加满阿，长一点的逻辑展开成具名变量更好is_vaild_state = (b == 7); 后续具名使用就没有前后问题又易读

有GC的瞬间就不该也不可能说要取代C了

Go 很好写高并发 但是真的遇到了高并发效能又惨兮兮

c的后继者可以看看zig，不过未成熟就是了

我很好奇，各位写Go的是有多高的拼发需求。

对现代而言gc其实还好 有跑过有gc的系统就知道zig就runtime更肥 好像还依赖llvm 听说要拿掉就是支持拿掉 llvm巨肥各大libc都包一份太疯狂了本来觉得llvm不错 但害人编译系统要以小时计就是差评

提先乘除后加减的那个可能要先回去小学重唸乘除的意义

llvm compile有比较久？

那拜托楼上大神教一下。优先级什么的我只觉得是偏好而已没有什么设计好不好的问题

llvm compile其它专案很久 compile自己都很久gcc也是很慢 一堆参数基本上也没什么用 优化感觉都不怎么明显平白增加功耗与需时 与轻量的相比编译速度完全不是一个量级

所以楼上用过pch跟ccache还是一样?

ccache无法弥补这差距以前我都很沉迷整天捣鼓这些