開戰了

說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無法彌補這差距以前我都很沉迷整天搗鼓這些