推 pot1234: 一開始就是聽同學說golang跑的跟C++一樣快，想說論文用g03/01 11:16
→ pot1234: olang寫。結果golang big被gnu打爛，還要外接c ++librar03/01 11:16
→ pot1234: y03/01 11:16
推 crazycy: Go除了Goroutine這功能之外 寫起來也不像一個現代語言03/01 11:56
推 tsaigi: go跟c差遠了…03/01 13:22
推 MATT1899: 寫C過的人應該會覺得Rust的Thread很直覺 畢竟同樣都是O03/01 13:41
→ MATT1899: S level的東西 Goroutine我到現在還是沒有很懂到底怎麼03/01 13:41
→ MATT1899: 運作的 直到最近看了一本解說底層的書才稍微有些理解03/01 13:41
→ pot1234: c++20跟boost都有類似goroutine的設計。thread跟routine03/01 14:42
→ pot1234: 應該是不同層級的東西03/01 14:42
推 KanzakiHAria: 找工作遇到go基本上就是高併發 其他常見node-ts03/01 14:58
→ KanzakiHAria: c現在定位就是跟asm dsp這類底層指令在一起的語言了03/01 14:58
→ KanzakiHAria: 寫C的人是硬體業 寫go現在就純軟後端03/01 14:59
不一定喔 我現在也是純軟 但project要高效能所以是用C
→ KanzakiHAria: C++把一堆東西搬到編譯器算完是要怎麼比快XD03/01 15:00
→ KanzakiHAria: Go的STW主要靠高併發去藏 併發越高STW藏越好03/01 15:02
推 ILoveAMD: && & 根本是不一樣的東西 不知道 防呆到近乎偏執的 C#03/01 15:33
→ ILoveAMD: 也沒有引進 and or 的關鍵字 (雖然編譯的時候會擋)03/01 15:35
→ ILoveAMD: && & 根本是不一樣的東西 不知道為何混再一起講03/01 15:36
我也不懂為什麼前面要一起講
推 ohmylove347: 有GC的語言沒資格和C/C++比效能03/01 15:59
→ MoonCode: 我還以為 && & 是在講引用或指標03/01 16:56
→ Burwei: 現在沒有人還拿Go跟C對標了吧 戰Go跟Java比較有意思lol03/01 17:44
推 Lhmstu: Go在雲端元件上真的蠻強的03/01 19:32
→ Lhmstu: go強項真的就是高併發03/01 19:35
推 windows2k: high concurrency也不會是c/c++/rust這等級的水準，真03/01 19:39
→ windows2k: 能說的是花費少許精力就能有個還不錯的方案03/01 19:39
我也寫過Go 的確很方便 但高併發也只是一直聽人講 實際跟C比也不知道怎麼樣
→ superpandal: 就是比較好寫的c 外加反射可以少寫很多東西03/01 19:54
→ superpandal: 現在有泛型 基本上cast也很少寫了 雖然編譯速度變慢03/01 19:55
→ superpandal: 效能的話我寫的效能很不錯 fmt包少用 尤其Sprintf方03/01 19:56
→ superpandal: 法 基本上goroutine配channel外加select多工就很不錯03/01 19:57
→ superpandal: 了03/01 19:57
→ superpandal: 強型別寫的很不爽快就是了 外加runtime過大這個缺點03/01 19:59
→ superpandal: 不然其實不錯03/01 19:59
推 KanzakiHAria: rometheus node_exporter也都是go 完全就是超多工專03/01 20:09
→ KanzakiHAria: 門場景03/01 20:09
→ KanzakiHAria: 不夠多工用go拿不到什麼好處03/01 20:10
推 Ekmund: 沒有太多邏輯上的運算或效能要求 Go的輕鬆程度遠超C/C++03/01 20:13
→ Ekmund: 也因此把他講成繼任者就很奇怪 Go犧牲的就是C的強項啊03/01 20:13
→ Ekmund: 你要比記憶體管理還真沒幾個語言能拿來跟C/C++比03/01 20:13
→ Ekmund: 而且這一切都是建立在面向web service的場景下03/01 20:15
→ Ekmund: 脫離這邊就沒Go的事了 連比都沒得比 怎麼繼任w03/01 20:16
→ superpandal: 繼不繼承是使用者角度來說的 gc目前來看也還好03/01 20:21
→ superpandal: 寫系統也不是不可以 現在敏感場景少一些了03/01 20:23
→ superpandal: 一樣配上unsafe也可以快一點03/01 20:26
→ superpandal: 一般常見寫法go效能確實不好03/01 20:34
→ Ekmund: 由我自己出發的話 使用時的直覺上是像的沒錯03/01 21:01
→ Ekmund: C/C++跳Go時有很多即視感03/01 21:01
→ Ekmund: 但回到兩者客群的話 相當程度的不重疊..XD03/01 21:01
→ Ekmund: 在C做過很多奇怪的東西 Go幾乎就純純的backend03/01 21:01
→ superpandal: 奇怪的東西多的是 是台灣整天在backend03/01 21:19
→ superpandal: 多接觸類unix世界會知道更多03/01 21:24
推 KanzakiHAria: 就像上一篇提到有rust寫的os redox 其實也有不少os03/01 21:50
→ KanzakiHAria: 是用go寫的 biscuit, gopher 很多小玩具也是go寫的03/01 21:51
→ kimi112136: 切牛排用牛排刀，野外生存用多功能刀，交換用不是不03/01 22:50
→ kimi112136: 行，但是我為啥要多費工夫用不適合場景的工作？語言03/01 22:50
→ kimi112136: 只是工具，懂得在不同場景用不同工具才是重要的好嗎03/01 22:50
→ cancelpc: Go算是特定領域較好,通用性沒比較好.03/01 22:53
→ cancelpc: c++真的語言過度複雜化,簡單點反而不容易錯誤03/01 22:55
※ 編輯: w180112 (216.232.177.222 加拿大), 03/02/2025 01:49:53
→ BoXeX: 其實那邊我講錯 我應該要講優先級才對 03/02 12:08
→ BoXeX: &| 的優先級直觀上應該要跟 +-之類一樣 03/02 12:08
→ BoXeX: 但現在這樣搞很反直覺 雖然實務上C語言在用的時候 03/02 12:09
→ BoXeX: 括號都加好加滿就是了 03/02 12:10
→ atst2: &|是位元運算，+-是數值運算, 放在一起比較有什麼意義嗎? 03/02 13:17
推 dmeiki: 樓上我想他指的是運算的優先權 03/02 19:24
→ atst2: 所以我想問, 兩種運算的目標就不一樣了，要求優先級一樣 03/02 19:42
→ atst2: 是為了什麼? 03/02 19:43
→ BoXeX: 像是wiki上例子 a & b == 7 直覺上會以為是 (a&b) == 7 03/02 20:13
→ BoXeX: 但實際是a & (b == 7) 03/02 20:13
→ BoXeX: 不用到優先級完全一樣 但至少別在==之後 03/02 20:15
→ labbat: 翻書就知道的東西了，就跟1|2<<3一樣 03/02 20:23
→ BoXeX: 寫熟的當然都知道 但不影響這不是好設計吧 03/02 20:32
推 Bencrie: 也許會有人覺得先乘除後加減不是好設計吧 03/02 20:47
→ BoXeX: 好 你的程式整天會需要把相等判斷結果做位元運算 03/02 21:32
→ BoXeX: 用的比把位元運算結果做相等判斷還多 03/02 21:32
→ atst2: 查了一下, Dennis M. Ritchie 自己就有說明了. 03/02 21:55
→ atst2: 簡單摘錄一下: 1. &|的優先權決定是延用B語言的 03/02 21:56
→ atst2: 2. B語言中，&|的意義是由上下文決定，所以通常情況下會是 03/02 21:57
→ atst2: 位元運算，但放到if()裡面會變邏輯運算. 03/02 21:57
→ atst2: 3. C語言為了處理語&|語意會變化的問題，引入了 && || 03/02 21:58
→ atst2: 4. 在引入&&, ||後，有考慮過重新安排優先權，但當時還要 03/02 21:59
→ atst2: 考慮與B語言的相容性, 認為成本太高所以就維持現狀了. 03/02 22:00
→ BoXeX: 感謝查詢 這樣看來當初設計時也知道是不好的設計 03/02 23:12
→ BoXeX: 只是包袱太大就不管了 03/02 23:12
→ atst2: 與其說是不好，不如說在語言發展初期，能做的選擇就是這些. 03/02 23:26
→ atst2: 畢竟現代的程式語言，能夠參考C/C++/Java/Python/Ruby... 03/02 23:27
→ atst2: 但C發展的當時，能參考的就不多，更何況還有硬體上的限制. 03/02 23:28
推 ILoveAMD: 查了一下 c/c++ golang java javascript 優先度一樣 03/02 23:33
→ ILoveAMD: rust 有改 03/02 23:34
推 ILoveAMD: c# php 也是跟 c 一樣 03/02 23:50
推 aria0520: c/c++寫習慣了 03/03 00:30
→ freeunixer: 從這個小故事我們可以知道,有事沒事都要多讀點書 (~誤 03/03 09:30
推 hobnob: 推討論串，聽各種意見受益良多 03/03 10:59
推 Bencrie: 其實我寫的 code & 跟 == 不會一起出現 XD 03/03 12:58
推 ABuJiuHaoBun: 雲領域已經是go的 03/03 13:36
推 KyuubiKulama: 我會用括號把要先處理的包起來就是，後面compiler 03/03 14:46
→ KyuubiKulama: 會優化的 03/03 14:46
推 jimmytzeng: go 要引入外部套件超方便 03/03 18:13
推 VScode: go可以直接import github link 覺得寫小專案部署很方便 03/03 19:30
→ Ekmund: &|行為牽涉到一組組的邏輯需求 使用時若放一起 就會很自 03/03 21:28
→ Ekmund: 然地把每一組分開括起來...沒太多遇到優先級的場景 03/03 21:28
→ Ekmund: 可能遇過也忘了吧 03/03 21:28
推 gagalala: Go已經沒有在說要繼承C了吧 然後cross compilation 真 03/04 09:26
→ gagalala: 的很方便啊 在cloud native也是到處都是go 尤其是auth 03/04 09:26
→ gagalala: 相關領域 03/04 09:26
推 Litfal: 我也以為&是在說reference 03/04 12:53
→ Litfal: ( )就是要加好加滿阿，長一點的邏輯展開成具名變數更好 03/04 12:55
推 Litfal: is_vaild_state = (b == 7); 後續具名使用就沒有前後問題 03/04 13:01
→ Litfal: 又易讀 03/04 13:01
→ yam276: 有GC的瞬間就不該也不可能說要取代C了 03/04 15:54
推 Serisu: Go 很好寫高併發 但是真的遇到了高併發效能又慘兮兮 03/05 23:53
推 windows2k: c的後繼者可以看看zig，不過未成熟就是了 03/06 10:01
→ Lordaeron: 我很好奇，各位寫Go的是有多高的拼發需求。 03/06 15:56
→ superpandal: 對現代而言gc其實還好 有跑過有gc的系統就知道 03/07 01:00
→ superpandal: zig就runtime更肥 好像還依賴llvm 聽說要拿掉就是 03/07 01:01
→ superpandal: 支持拿掉 llvm巨肥 03/07 01:02
→ superpandal: 各大libc都包一份太瘋狂了 03/07 01:05
→ superpandal: 本來覺得llvm不錯 但害人編譯系統要以小時計就是差評 03/07 01:16
噓 GTR12534: 提先乘除後加減的那個可能要先回去小學重唸乘除的意義 03/07 17:50
推 wulouise: llvm compile有比較久？ 03/07 21:20
推 Bencrie: 那拜託樓上大神教一下。優先級什麼的我只覺得是偏好而已 03/07 21:20
→ Bencrie: 沒有什麼設計好不好的問題 03/07 21:21
→ superpandal: llvm compile其它專案很久 compile自己都很久 03/08 00:25
→ superpandal: gcc也是很慢 一堆參數基本上也沒什麼用 優化感覺 03/08 00:34
→ superpandal: 都不怎麼明顯 03/08 00:35
→ superpandal: 平白增加功耗與需時 與輕量的相比編譯速度完全不是一 03/08 00:40
→ superpandal: 個量級 03/08 00:41
→ wulouise: 所以樓上用過pch跟ccache還是一樣? 03/08 02:21
→ superpandal: ccache無法彌補這差距 03/08 14:36
→ superpandal: 以前我都很沉迷整天搗鼓這些 03/08 14:43