Re: [討論] Rust 2024 發佈正式版

看板Soft_Job (軟體人)作者 ([NOOB]我超RETARD我超廢 )時間1月前 (2025/03/01 10:23), 1月前編輯推噓29(30198)
留言129則, 34人參與, 1月前最新討論串3/3 (看更多)
開戰了 說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://www.ptt.cc/bbs/Soft_Job/M.1740795788.A.5B9.html

03/01 11:16, 1月前 , 1F
一開始就是聽同學說golang跑的跟C++一樣快,想說論文用g
03/01 11:16, 1F

03/01 11:16, 1月前 , 2F
olang寫。結果golang big被gnu打爛,還要外接c ++librar
03/01 11:16, 2F

03/01 11:16, 1月前 , 3F
y
03/01 11:16, 3F

03/01 11:56, 1月前 , 4F
Go除了Goroutine這功能之外 寫起來也不像一個現代語言
03/01 11:56, 4F

03/01 13:22, 1月前 , 5F
go跟c差遠了…
03/01 13:22, 5F

03/01 13:41, 1月前 , 6F
寫C過的人應該會覺得Rust的Thread很直覺 畢竟同樣都是O
03/01 13:41, 6F

03/01 13:41, 1月前 , 7F
S level的東西 Goroutine我到現在還是沒有很懂到底怎麼
03/01 13:41, 7F

03/01 13:41, 1月前 , 8F
運作的 直到最近看了一本解說底層的書才稍微有些理解
03/01 13:41, 8F

03/01 14:42, 1月前 , 9F
c++20跟boost都有類似goroutine的設計。thread跟routine
03/01 14:42, 9F

03/01 14:42, 1月前 , 10F
應該是不同層級的東西
03/01 14:42, 10F

03/01 14:58, 1月前 , 11F
找工作遇到go基本上就是高併發 其他常見node-ts
03/01 14:58, 11F

03/01 14:58, 1月前 , 12F
c現在定位就是跟asm dsp這類底層指令在一起的語言了
03/01 14:58, 12F

03/01 14:59, 1月前 , 13F
寫C的人是硬體業 寫go現在就純軟後端
03/01 14:59, 13F
不一定喔 我現在也是純軟 但project要高效能所以是用C

03/01 15:00, 1月前 , 14F
C++把一堆東西搬到編譯器算完是要怎麼比快XD
03/01 15:00, 14F

03/01 15:02, 1月前 , 15F
Go的STW主要靠高併發去藏 併發越高STW藏越好
03/01 15:02, 15F

03/01 15:33, 1月前 , 16F
&& & 根本是不一樣的東西 不知道 防呆到近乎偏執的 C#
03/01 15:33, 16F

03/01 15:35, 1月前 , 17F
也沒有引進 and or 的關鍵字 (雖然編譯的時候會擋)
03/01 15:35, 17F

03/01 15:36, 1月前 , 18F
&& & 根本是不一樣的東西 不知道為何混再一起講
03/01 15:36, 18F
我也不懂為什麼前面要一起講

03/01 15:59, 1月前 , 19F
有GC的語言沒資格和C/C++比效能
03/01 15:59, 19F

03/01 16:56, 1月前 , 20F
我還以為 && & 是在講引用或指標
03/01 16:56, 20F

03/01 17:44, 1月前 , 21F
現在沒有人還拿Go跟C對標了吧 戰Go跟Java比較有意思lol
03/01 17:44, 21F

03/01 19:32, 1月前 , 22F
Go在雲端元件上真的蠻強的
03/01 19:32, 22F

03/01 19:35, 1月前 , 23F
go強項真的就是高併發
03/01 19:35, 23F

03/01 19:39, 1月前 , 24F
high concurrency也不會是c/c++/rust這等級的水準,真
03/01 19:39, 24F

03/01 19:39, 1月前 , 25F
能說的是花費少許精力就能有個還不錯的方案
03/01 19:39, 25F
我也寫過Go 的確很方便 但高併發也只是一直聽人講 實際跟C比也不知道怎麼樣

03/01 19:54, 1月前 , 26F
就是比較好寫的c 外加反射可以少寫很多東西
03/01 19:54, 26F

03/01 19:55, 1月前 , 27F
現在有泛型 基本上cast也很少寫了 雖然編譯速度變慢
03/01 19:55, 27F

03/01 19:56, 1月前 , 28F
效能的話我寫的效能很不錯 fmt包少用 尤其Sprintf方
03/01 19:56, 28F

03/01 19:57, 1月前 , 29F
法 基本上goroutine配channel外加select多工就很不錯
03/01 19:57, 29F

03/01 19:57, 1月前 , 30F
03/01 19:57, 30F

03/01 19:59, 1月前 , 31F
強型別寫的很不爽快就是了 外加runtime過大這個缺點
03/01 19:59, 31F

03/01 19:59, 1月前 , 32F
不然其實不錯
03/01 19:59, 32F

03/01 20:09, 1月前 , 33F
rometheus node_exporter也都是go 完全就是超多工專
03/01 20:09, 33F

03/01 20:09, 1月前 , 34F
門場景
03/01 20:09, 34F

03/01 20:10, 1月前 , 35F
不夠多工用go拿不到什麼好處
03/01 20:10, 35F

03/01 20:13, 1月前 , 36F
沒有太多邏輯上的運算或效能要求 Go的輕鬆程度遠超C/C++
03/01 20:13, 36F
還有 53 則推文
還有 1 段內文
03/03 00:30, 1月前 , 90F
c/c++寫習慣了
03/03 00:30, 90F

03/03 09:30, 1月前 , 91F
從這個小故事我們可以知道,有事沒事都要多讀點書 (~誤
03/03 09:30, 91F

03/03 10:59, 1月前 , 92F
推討論串,聽各種意見受益良多
03/03 10:59, 92F

03/03 12:58, 1月前 , 93F
其實我寫的 code & 跟 == 不會一起出現 XD
03/03 12:58, 93F

03/03 13:36, 1月前 , 94F
雲領域已經是go的
03/03 13:36, 94F

03/03 14:46, 1月前 , 95F
我會用括號把要先處理的包起來就是,後面compiler
03/03 14:46, 95F

03/03 14:46, 1月前 , 96F
會優化的
03/03 14:46, 96F

03/03 18:13, 1月前 , 97F
go 要引入外部套件超方便
03/03 18:13, 97F

03/03 19:30, 1月前 , 98F
go可以直接import github link 覺得寫小專案部署很方便
03/03 19:30, 98F

03/03 21:28, 1月前 , 99F
&|行為牽涉到一組組的邏輯需求 使用時若放一起 就會很自
03/03 21:28, 99F

03/03 21:28, 1月前 , 100F
然地把每一組分開括起來...沒太多遇到優先級的場景
03/03 21:28, 100F

03/03 21:28, 1月前 , 101F
可能遇過也忘了吧
03/03 21:28, 101F

03/04 09:26, 1月前 , 102F
Go已經沒有在說要繼承C了吧 然後cross compilation 真
03/04 09:26, 102F

03/04 09:26, 1月前 , 103F
的很方便啊 在cloud native也是到處都是go 尤其是auth
03/04 09:26, 103F

03/04 09:26, 1月前 , 104F
相關領域
03/04 09:26, 104F

03/04 12:53, 1月前 , 105F
我也以為&是在說reference
03/04 12:53, 105F

03/04 12:55, 1月前 , 106F
( )就是要加好加滿阿,長一點的邏輯展開成具名變數更好
03/04 12:55, 106F

03/04 13:01, 1月前 , 107F
is_vaild_state = (b == 7); 後續具名使用就沒有前後問題
03/04 13:01, 107F

03/04 13:01, 1月前 , 108F
又易讀
03/04 13:01, 108F

03/04 15:54, 1月前 , 109F
有GC的瞬間就不該也不可能說要取代C了
03/04 15:54, 109F

03/05 23:53, 1月前 , 110F
Go 很好寫高併發 但是真的遇到了高併發效能又慘兮兮
03/05 23:53, 110F

03/06 10:01, 1月前 , 111F
c的後繼者可以看看zig,不過未成熟就是了
03/06 10:01, 111F

03/06 15:56, 1月前 , 112F
我很好奇,各位寫Go的是有多高的拼發需求。
03/06 15:56, 112F

03/07 01:00, 1月前 , 113F
對現代而言gc其實還好 有跑過有gc的系統就知道
03/07 01:00, 113F

03/07 01:01, 1月前 , 114F
zig就runtime更肥 好像還依賴llvm 聽說要拿掉就是
03/07 01:01, 114F

03/07 01:02, 1月前 , 115F
支持拿掉 llvm巨肥
03/07 01:02, 115F

03/07 01:05, 1月前 , 116F
各大libc都包一份太瘋狂了
03/07 01:05, 116F

03/07 01:16, 1月前 , 117F
本來覺得llvm不錯 但害人編譯系統要以小時計就是差評
03/07 01:16, 117F

03/07 17:50, 1月前 , 118F
提先乘除後加減的那個可能要先回去小學重唸乘除的意義
03/07 17:50, 118F

03/07 21:20, 1月前 , 119F
llvm compile有比較久?
03/07 21:20, 119F

03/07 21:20, 1月前 , 120F
那拜託樓上大神教一下。優先級什麼的我只覺得是偏好而已
03/07 21:20, 120F

03/07 21:21, 1月前 , 121F
沒有什麼設計好不好的問題
03/07 21:21, 121F

03/08 00:25, 1月前 , 122F
llvm compile其它專案很久 compile自己都很久
03/08 00:25, 122F

03/08 00:34, 1月前 , 123F
gcc也是很慢 一堆參數基本上也沒什麼用 優化感覺
03/08 00:34, 123F

03/08 00:35, 1月前 , 124F
都不怎麼明顯
03/08 00:35, 124F

03/08 00:40, 1月前 , 125F
平白增加功耗與需時 與輕量的相比編譯速度完全不是一
03/08 00:40, 125F

03/08 00:41, 1月前 , 126F
個量級
03/08 00:41, 126F

03/08 02:21, 1月前 , 127F
所以樓上用過pch跟ccache還是一樣?
03/08 02:21, 127F

03/08 14:36, 1月前 , 128F
ccache無法彌補這差距
03/08 14:36, 128F

03/08 14:43, 1月前 , 129F
以前我都很沉迷整天搗鼓這些
03/08 14:43, 129F
文章代碼(AID): #1dmc-CMv (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1dmc-CMv (Soft_Job)