Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/08/31(土) 08:34:49.06

Rust がどうこうというのを抜きにしてひとつのプロジェクトにいろんな言語が混在するのは面倒さが生じるというのはある。
Linux に乗ろうとするなら Linux の方針に従えというのは当然の判断だろう。
受け入れてしまったらメンテナンスしなきゃならんし、メンテナンスできないものを導入するのは問題だ。
あくまでも Rust の急進的導入をしたいというなら fork するくらいの気概を見せて欲しいところ。

**デフォルトの名無しさん** · 2024/08/31(土) 08:38:08.89

>>527
既にRustのコードが入っている現実を無視して妄想が激しいな

**デフォルトの名無しさん** · 2024/08/31(土) 09:01:31.35

Rustのコード入れたくないまでならまだ分かるが
（Rustドライバ導入の前段階として）既存のサブシステムのバグを直したいと言ったら
今あるドライバではそのバグは踏んでないから直す必要なし、って言われたりしてるらしく
さすがに自分のCのコードのクオリティくらいちゃんと上げろよ、とは思う

**デフォルトの名無しさん** · 2024/08/31(土) 09:13:30.90

考え方が違うんだよね
C/C++では現在のコードの使い方の範囲内では(ギリギリ)バグを回避できているので大丈夫と考える
そして後に機能追加や改修が入ったときにそのギリギリのところを踏んでしまって致命的バグが露呈する
このダメな考えな人がまだ多くいる

**デフォルトの名無しさん** · 2024/08/31(土) 09:22:22.01

RustほどC++と相性の悪い言語はないね。
C++との相性を考えるならNimの方が良い。
勘違いしないで欲しいんだがRustとCの相性はとても良い。

**デフォルトの名無しさん** · 2024/08/31(土) 09:25:59.57

>>529
>今あるドライバではそのバグは踏んでないから直す必要なし、って言われたり

これは酷い
MicsoSoftを嗤えないな

**デフォルトの名無しさん** · 2024/08/31(土) 09:27:58.78

>>530
>そのギリギリのところを踏んでしまって

きみも考え方が間違っている
昔ながらのカーネル開発者は賢いからCで拡張してもそのバグを踏まない自信があるんだよ
(それが良いか悪いかは別として)

**デフォルトの名無しさん** · 2024/08/31(土) 09:38:02.88

各OSで脆弱性報告が無くならないのはなぜか？
思い込みの自信でプログラミングしていてバグを踏むからである

**デフォルトの名無しさん** · 2024/08/31(土) 09:42:22.13

FFIがそもそもCのAPI以外が難しい
C#やGoでも他言語の呼び出しはCのAPIを通すのが一般的で、メソッドをもったクラスや構造体、抽象的なインタフェースなどを言語間で翻訳できるものはあまりない
(C++とPythonを連携させるpybind11や、RustとPythonを連携させるPyO3などはうまくやってる例)

そういう点でC++と相性の良いものってだいぶ限られると思う
C APIを通すならどの言語からでも呼べるけど、C++のAPIを翻訳するには言語あるいはライブラリによるサポートが必要

**デフォルトの名無しさん** · 2024/08/31(土) 09:57:33.39

「RustとC++は相性が悪い」というよりも「C++と相性が良いのはNimなどに限られる」という感じじゃないかと思う
そういやC++の後継を目指してたCarbonってどうなってるんだろ

**デフォルトの名無しさん** · 2024/08/31(土) 10:01:46.87

Nimのような弱小言語を使う人は今後も極少数に限られるから意味がないよな

**デフォルトの名無しさん** · 2024/08/31(土) 10:04:38.88

C++のメモリ管理とNimのメモリ管理はは全く異なっている
相性がいいなんて話はまやかし

**デフォルトの名無しさん** · 2024/08/31(土) 10:08:52.28

>RustとPythonを連携させるPyO3

これはC++要素無いだろ

**デフォルトの名無しさん** · 2024/08/31(土) 10:28:40.41

>>539
C++に限った話ではなく、クラスやメソッドといった概念を異なる言語間 (ここではRustとPython) でうまく翻訳できてる例として書いた

他だと、例えばC#とRustを連携させる csbindgen はFFIをしやすくはしてくれるけど、メソッド付きのクラスなどは作れずAPIはほぼCになるといった感じ

**デフォルトの名無しさん** · 2024/08/31(土) 10:40:19.97

>>530
まだ顕在化していないものに対してあれこれ考えるのは
難しいことができる「才能」とは違った「センス」が必要なんだよね

そして学校でも企業でも才能で判断することはやっているけど
センスに関しては無頓着というか、センスに気づくにもセンスが要るということで
そもそもそういうものがあることを分かっていない人が多い

**デフォルトの名無しさん** · 2024/08/31(土) 11:37:38.42

>>540
>クラスやメソッドといった概念を異なる言語間 (ここではRustとPython) でうまく翻訳

きみは何も判ってないな

**デフォルトの名無しさん** · 2024/08/31(土) 12:39:33.76

カーネルメンテナーの中にはここにいるような
rust信者は死ねとか思ってる人いるんやろ

**デフォルトの名無しさん** · 2024/08/31(土) 12:42:56.23

RustがC++と相性が良いと思ってる(だけじゃなくてそう喚き散らしてる)Rust信者は死ねば良いよ

**デフォルトの名無しさん** · 2024/08/31(土) 13:15:38.97

>>542
中身のない否定じゃなくて役に立つこと書いて
PyO3も内部的にはPythonのC APIを通してFFIしてることは分かってる
それをライブラリ側で抽象化してRustのメソッド付きの型をPythonのオブジェクトに返還してるので、そこそこうまく翻訳できてると言って良いんじゃない？

**デフォルトの名無しさん** · 2024/08/31(土) 14:19:45.17

カーネルデベロッパはRustよりZigが好きだと思うよ
ZigこそCの置き換えを担う
RustはC++の置き換えとして役割を全うしてくれ

**デフォルトの名無しさん** · 2024/08/31(土) 14:34:53.19

企業や国防総省や各ソフトウェアプロジェクト等が解決したい、人間の手に依らない、様々な安全性の保証を、Zigは解決しないことが、企業スポンサーの量質や、政府による支持の差となっています。

**デフォルトの名無しさん** · 2024/08/31(土) 16:51:39.82

言語一決定戦

**デフォルトの名無しさん** · 2024/08/31(土) 18:46:49.67

Rustのライブラリまわりの現況ってどう思ってる？
プロジェクトでライブラリを使うと、他の言語に比べて依存ライブラリが多くなりがち＆1.0未満のライブラリが多いな気がしてるけど、みんな気にしないもの？

**デフォルトの名無しさん** · 2024/08/31(土) 19:46:25.63

>RustはC++の置き換えとして

まだこんなこと言ってる馬鹿がいるのか

**デフォルトの名無しさん** · 2024/08/31(土) 19:47:21.29

>>549
cratesは破綻してる

**デフォルトの名無しさん** · 2024/08/31(土) 20:11:59.68

>>549
考え方を180度変えるとわかりやすい
クレートは可能ならば小さければ小さいほど良い
並行してコンパイルできるメリットがあるだけでなく
重複コードもなるべく無くせるメリットもある
特にunsafeを含む基礎的な汎用な機能の場合に
大きなライブラリにその同じ機能を持つコードが各々に別々に入ると
unsafeの監視も各々で個別に無駄に重複して行う必要となってしまう
この点でも小さく分けたほうが望ましい

**デフォルトの名無しさん** · 2024/08/31(土) 20:44:50.30

メンテナンスコストは増えると思う
Outdatedになってないかチェックしたり、ライブラリ間の依存のせいでバージョン上げられなかったり

**デフォルトの名無しさん** · 2024/08/31(土) 20:53:33.20

え、ここそのレベルの方々だったんだ…
ドン引き

**デフォルトの名無しさん** · 2024/08/31(土) 21:35:41.49

>>553
それって何に比べての話？
PythonでもGoでも結局標準ライブラリだけで全部できるわけではないし
どのみちそのあたりのコストはかかるから大差ないと思うけど

**デフォルトの名無しさん** · 2024/09/01(日) 10:01:28.26

依存の数ならRustは多い方じゃない？
tokioあたりを入れるとそれだけで数十のライブラリに依存するし
Goは知らないけど、Pythonはそこまで多くならないと思う

JSも依存が多くなりがちで、依存パッケージに脆弱性やマルウェアが仕込まれることが時折問題になってるけど、Rust界隈だとその辺りの問題はどう認識されてるのかなと思った次第です

**デフォルトの名無しさん** · 2024/09/01(日) 10:17:26.39

breaking change と semver violation の話じゃないかなぁ < メンテナンスコスト
今はツールができて少しはましとはいえ
メチャクチャ難しい

**デフォルトの名無しさん** · 2024/09/01(日) 10:30:23.05

数個～20個程度の依存と100～200個の依存と同じわけないじゃん
それに鉄板ライブラリと考えられてたものでも2～3年するとメンテ状況が怪しくなったり無駄な破壊的変更がされたりするのが結構あるから他の言語と比べるとはるかに手間がかかるよ
現段階ではRustの最大の弱点
弱点以上にメリットを見出せないなら本格的に使うのはお勧めしない

**デフォルトの名無しさん** · 2024/09/01(日) 10:34:17.81

実体験として、PythonやDartでは依存関係地獄にハマって解決に苦労したことあるけど
Rustは今のところないな

**デフォルトの名無しさん** · 2024/09/01(日) 10:48:37.08

>>558
その説明だとnodejsなんか使い物にならないのでは

**デフォルトの名無しさん** · 2024/09/01(日) 10:50:08.09

chronoなんかも未だに1.0未満だし2年ほどメンテナンス停止にしてたことがあるしな (今は再開してる)
時刻やタイムゾーンを扱いたい場面は多いだろうから、こういうのは安定化または標準ライブラリでサポートして欲しいとは思う

**デフォルトの名無しさん** · 2024/09/01(日) 11:09:10.42

別に致命的な脆弱性でもなければ無理に上げる必要もないしな
普段はdependabotに自動で上げさせといて、
破壊的変更があるやつは年1回くらいで追従する感じにしてるけど
特に手間と思ったこともないな

**デフォルトの名無しさん** · 2024/09/01(日) 11:20:43.92

>>561
バージョン番号1.0未満かどうかという表面上のどうでもいい問題にこだわるのはおかしい
chronoのようなほとんどのプログラムで使われない機能を標準ライブラリに入れようという提案は感覚が変
あとRustで安定化とはstableかexperimentalかの区別でstableになることだよね

**デフォルトの名無しさん** · 2024/09/01(日) 11:30:01.13

表面上って…

**デフォルトの名無しさん** · 2024/09/01(日) 11:33:21.84

APIの破壊的変更を今後行う可能性があるかの表明にはなるだろ
1.0であれば、少なくともメジャーバージョンが変わらないうちは後方互換性を維持するという意思表示になる
仕組みで防いでるわけではないし、「共通認識としてそう受け取られる」という話には過ぎないけど

**デフォルトの名無しさん** · 2024/09/01(日) 11:50:19.16

>chronoのようなほとんどのプログラムで使われない機能を
こんなこと書くやつは何書いても信用度ゼロ
”偽情報注意！”ってやつだな

**デフォルトの名無しさん** · 2024/09/01(日) 12:08:43.54

chronoなんて日時を扱わない限り使うことないだろ
特定の分野だと必須だろうが
Rustが使われる分野は広いからね

**デフォルトの名無しさん** · 2024/09/01(日) 12:21:28.53

>>565
いや、ならんでしょ
結局破壊的変更があれば2.0になるわけで、実際5.0とか10.0みたいなのもあるし
まぁこの作者が1.0を宣言するんならもう十分安定してるんだろう、みたいなのはあるけどな
そういう背景情報なしなら1.0と0.1の違いは特にないと思うよ

**デフォルトの名無しさん** · 2024/09/01(日) 12:26:37.18

バージョン0.x.yは cargo tree | grep v0 で確認できて
大量の基盤ライブラリが見つかるけどそれで困ったことはないな

>>565
そういう守るべきマナーとしては
0.x指定しておけば破壊的変更はないとされているので大丈夫
クレイトを作ってる側は破壊的変更があればx←x+1と上げるため

**デフォルトの名無しさん** · 2024/09/01(日) 12:51:19.19

>>567
chronoとtimeを合わせたダウンロード数見てみ
トップ10レベルだから
regexやserdeやrandやclapよりもずっと多い

君が書いた内容は
「regexなんて正規表現を扱わない限り使うことないだろ
　特定の分野だと必須だろうが
　Rustが使われる分野は広いからね」
とか
「serdeなんてシリアライズ/デシリアライズしない限り使うことないだろ
　特定の分野だと必須だろうが
　Rustが使われる分野は広いからね」
とかと同じレベル

どのくらい馬鹿なこと書いたかわかったかな？

**デフォルトの名無しさん** · 2024/09/01(日) 12:57:25.84

Linusのリンク貼ってた人いたけどそこにも描いてある
バージョン番号に意味は無い
と

**デフォルトの名無しさん** · 2024/09/01(日) 13:02:17.26

>>558
＋１

問題無いと主張してる人は
まともに開発したこと無いんだろうな

**デフォルトの名無しさん** · 2024/09/01(日) 13:06:30.98

>>565
>仕組みで防いでるわけではない

これなんよね
メモリ脆弱性は言語本体で管理してて仕組みで防いでるのを売りにしてるんだから
パッケージマネージャも仕組みで防げと思う

**デフォルトの名無しさん** · 2024/09/01(日) 13:13:51.37

>>571
それは自分のプロジェクト (Linux) におけるバージョン番号の意味を述べてるもので、ソフトウェアライブラリ一般を指して言ったものではなくない？

**デフォルトの名無しさん** · 2024/09/01(日) 13:26:50.54

v2.0が出た後も末永くv1.xブランチでメンテされ続けるなら意味あるけど
そんなの全く期待できないよね

**デフォルトの名無しさん** · 2024/09/01(日) 13:29:19.13

乱数生成ですら外部クレートが必要になるんだから、そういう言語なんだと割り切ってはいるけど

**デフォルトの名無しさん** · 2024/09/01(日) 13:34:18.52

>>573
インターフェイスの互換性はある程度は機械的検証が出来るかもしれないけど挙動の互換性まで検証するのは非現実的だろ。
バグで制約が緩かったのを修正した (ドキュメント通りに使っていれば問題ない) みたいなケースだと機械的には非互換に見えることもあるだろうし。
そこらへんは使う側でバージョンの固定をするしか仕方ない。
いや、もちろん仕組みを構築できるならそのほうがいいよ。でも、出来ないだろ？って話でさ。

**デフォルトの名無しさん** · 2024/09/01(日) 13:57:51.22

>>576
Rustの標準ライブラリにランダムあるよ
HashMapなどのデフォルトハッシュで使われてるのご存知でしょ
use std::hash::{BuildHasher, RandomState};
let random_seed = RandomState::new().hash_one(0_u64);

**デフォルトの名無しさん** · 2024/09/01(日) 14:22:12.72

>>576
playgorund とか paiza とかで use crate 出来ないのがあると面倒やね

**デフォルトの名無しさん** · 2024/09/01(日) 14:23:04.37

>>578
盲点だった
ハッシュマップが乱数を使うのは言われてみればその通りだ
けどこれってHashMapのための機能だし、「この方法でも乱数を得られる」であって、乱数をつくるために提供されてるものではなくない？

英語でも調べたけど、Rustで乱数を生成する方法を調べたらrandクレートの方が最初にヒットする

**デフォルトの名無しさん** · 2024/09/01(日) 14:49:06.86

>>580
いずれも環境に応じて最終的にはgetrandomシステムコールを呼んだり/dev/urandomを読んだりするだけだから機能としては同じだね
何度も使うならそれをシード値としてxorshiftなどするだけなのでstdだけで使えるメリットは大きいよ

**デフォルトの名無しさん** · 2024/09/01(日) 14:58:42.54

必要な乱数の性質は状況によってかなり違うから安易に (ユーザの検討が不十分になりそうな形で) 特定の実装を使わせてしまうのはよくないと思う。
基本的な枠組みを定めたトレイトが標準にあると便利だろうとは思うし
そのトレイトの利用例としてひとつくらいの簡易実装は有っても良いかなとは思うけど
皆でひとつの標準を利用しようという性質のもんじゃないでしょ。

乱数は標準に入れるモチベーションはやや低いんじゃないかなぁ。
標準に入れるべきだと思うものだとなんかもっと他にあるでしょ。

**デフォルトの名無しさん** · 2024/09/01(日) 16:10:10.29

>>５4
RustがCより速くなるベンチマークは見たことがない

Nim2.0のORCは明示的にオブジェクトプールを使ったプログラミングが必要ですが
ベンチマークがCより２倍以上速くなって、特にハードなリアルタイムシステム向け
のチューニングもできるようになってるみたい
https://zenn.dev/dum...icles/af2b2b9f8fd890

Nim2.0がCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？

**デフォルトの名無しさん** · 2024/09/01(日) 16:37:38.74

Cより何倍も速い詐欺の話は他のスレでやろう
Rustと関係ないので

**デフォルトの名無しさん** · 2024/09/01(日) 16:58:53.35

Zigは1.0になってから出直せ！
crateはpre-1.0でもそういうもんなのでヨシ！

はーくだらね

**デフォルトの名無しさん** · 2024/09/01(日) 17:07:22.02

言語とライブラリは流石に違わないか
ライブラリは開発止まっても同分野の別のライブラリがあればそれに差し替えられる (最悪、元のライブラリをフォークしても良い) けど、言語仕様はそうもいかないだろ

**デフォルトの名無しさん** · 2024/09/01(日) 17:08:31.34

比較の対象にすらならない
Zigはasync awaitを断念して削除
Rustはasync awaitによりCPUコアをフル活用できて実際にクラウドやCDNなどネットインフラで使われている

**デフォルトの名無しさん** · 2024/09/01(日) 17:48:17.89

>>584
詐欺の証明ができないのであればRustはNim2.0より劣る言語と
理解してもよろしいでしょうか？

>Rustと関係ないので
ORCでメモリ安全を担保できてCより２倍以上速くなるのであれば、
メモリ安全がありCより遅いRustは言語選択時の比較対象として関係あるだろ

**デフォルトの名無しさん** · 2024/09/01(日) 18:02:28.26

何でもできるC言語より速いと主張しだしたらそれは変な宗教だから相手にしてはダメ
しかもNimはC言語へトランスパイルされるんだろｗ

**デフォルトの名無しさん** · 2024/09/01(日) 18:08:55.61

雑に書いて十分に速いかってのと専門家が気合いを入れてチューニングをすれば最強に速いかってのは違う指標だろうし、仮に速さを比べるにしても想定を合わせないと意味がないよ。

**デフォルトの名無しさん** · 2024/09/01(日) 18:09:09.43

CへトランスパイルされるならCより速くなってても不思議じゃないな

**デフォルトの名無しさん** · 2024/09/01(日) 18:15:39.95

Rustは特殊なケースを持ち出さなくても
実際の実用ケースのほとんどで、Cと同じ速さ、もしくは、ほぼ同じ速さで、凝ったことをせずとも書けるから
IT業界が挙ってRustを支持した

**デフォルトの名無しさん** · 2024/09/01(日) 18:34:18.72

知らないから純粋な質問なんだけどnimって並行処理の安全性に強みはあるの？
個人的にRustで助かる部分だと思ってるので
メモリ周りは問題なさそう＆所有権はRustより楽そう (代わりに意図せぬコピーが起こりやすい？) に思う

**デフォルトの名無しさん** · 2024/09/01(日) 18:40:58.89

それとエラーの扱いやすさ

**デフォルトの名無しさん** · 2024/09/01(日) 19:43:48.04

>>590
じゃあ想定を合わせるためにCでもRustでもどっちでもいいから、下記のNim2.0のORCで明示的にオブジェクトプールを使ったプログラミングのベンチマークより速くできなかったら、今度こそ本当にRustはNim2.0より劣る言語と理解してもよろしいでしょうか？

Memory management strategy Time Peak Memory
object pooling　　　　　　　　　 2.4s　　 251.504MiB

オブジェクトプール（5）
proc main =
let maxDepth = parseInt(paramStr(1))
const minDepth = 4
let stretchDepth = maxDepth + 1
var longLived: Pool # 5行目
let stree = makeTree(longLived, maxDepth)
echo("stretch tree of depth ", stretchDepth, "\t check ",
checkTree(stree))
let longLivedTree = makeTree(longLived, maxDepth)
var iterators = 1 shl maxDepth
for depth in countup(minDepth, maxDepth, 2):
var check = 0
for i in 1..iterators:
var shortLived: Pool # 14行目
check += checkTree(makeTree(shortLived, depth))
echo iterators, "\t trees of depth ", depth
iterators = iterators div 4

main()

**デフォルトの名無しさん** · 2024/09/01(日) 20:00:37.37

はいはい
C/C++/Rustに勝ってから出直してきてね
スレ荒らしはダメよ

**デフォルトの名無しさん** · 2024/09/01(日) 20:08:43.57

わざわざ他言語のスレに来て噛み付かなきゃいけない時点で負けていると宣言しているようなもの
その言語のスレを盛況にすればいいのに

**デフォルトの名無しさん** · 2024/09/01(日) 20:08:50.47

>>596
はあ？日本語嫁内の？
>>59４より速いベンチマークで証明すればいいだけだろ

**デフォルトの名無しさん** · 2024/09/01(日) 20:12:17.24

Cより速い言語が本当に出現したのならば世界的なニュースになるのでここを荒らす必要なし

**デフォルトの名無しさん** · 2024/09/01(日) 20:18:33.83

>>599
証明できないから荒らし判定してるだけだろ

証明できないなら証明できないって正直にRustはNim2.0より劣る言語だと認めればいいだけだろ

**デフォルトの名無しさん** · 2024/09/01(日) 20:34:03.89

CスレやC++スレへ行ってくればいいんじゃね
相手にしてくれるかもよ

**デフォルトの名無しさん** · 2024/09/01(日) 20:36:25.69

RustスレでRust宣伝とかいう意味のないことやり続けた報い

**デフォルトの名無しさん** · 2024/09/01(日) 20:42:24.60

煽りたいだけなら他言語のコードも自分で書いてベンチマークを個人ブログまたはRedditかQiitaかZennに書けばよくない？
>>583はリンク先が無いし >>595 はCPU性能どころか入力の数すら書いてないから、誰かが他の言語で書いたとしても比較しようがない

**デフォルトの名無しさん** · 2024/09/01(日) 20:43:24.75

このスレはNim2.0のORCで明示的にオブジェクトプールを使ったプログラミングのベンチマークより速い事を証明できないカスばっかだな

**デフォルトの名無しさん** · 2024/09/01(日) 20:47:46.74

>>603
https://zenn.dev/dumblepy/articles/af2b2b9f8fd890

Website https://nim-lang.org/
Forum https://forum.nim-lang.org/
Github https://github.com/nim-lang/Nim
IRC https://webchat.freenode.net/?channels=nim

**デフォルトの名無しさん** · 2024/09/01(日) 20:49:35.02

検索してみたがNim 2.0がCより速いという記事が一つも見つからなかったのでガセっぽい
記事が出るまでこのお話はお預けってことで

**デフォルトの名無しさん** · 2024/09/01(日) 20:51:46.74

>>603
https://youtu.be/yA32Wxl59wo

https://github.com/Araq/fosdem2020

**デフォルトの名無しさん** · 2024/09/01(日) 20:53:27.80

>>605
純粋に疑問なんだけどそのページのどこをみてCの2倍速いって言ってるの？
単にNim同士でメモリ管理をいろいろ変えたら速くなったとしか書かれていないと思うんだけど

**デフォルトの名無しさん** · 2024/09/01(日) 21:03:34.87

Nimの過去のものより速くなったとしか読めないし
補足として貼ってるリンクもベンチマークじゃなくて言語自体の説明や公式ページだし
自分で手を動かさずにその記事だけ読んでCより速いと言うのは妄想レベルでは

**デフォルトの名無しさん** · 2024/09/01(日) 21:14:25.35

>>608
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとして、Nim2.0のORCで明示的にオブジェクトプールを使ったプログラミングと比較した場合のベンチマークが2倍以上速くなってるからCより速いと言ってる

それが間違ってると主張したいのであれば、想定を合わせるためにCでもRustでもどっちでもいいから、さっきから何度も言ってるように速いベンチマークで証明すればいいだけだろ

**デフォルトの名無しさん** · 2024/09/01(日) 21:17:33.09

>>610
それはCでもオブジェクトプール使えば2倍速くなるのでは？
オブジェクトプール版のNimから生成したCはまさにそういうコードだと思うけど

**デフォルトの名無しさん** · 2024/09/01(日) 21:24:18.89

言語の差でなくメモリ管理方式の差では
ライブラリにはなるけど同様のものはRustにもあるし大して変わらなさそう

**デフォルトの名無しさん** · 2024/09/01(日) 21:27:22.64

コーディングもベンチもせずに
NimはCより2倍速いと主張していて
心の病をうたがってしまう

**デフォルトの名無しさん** · 2024/09/01(日) 21:38:54.81

そもそもNimがCより速いっていうのが原理的におかしいんだよ…
Nimの最速実装には必ずそこから生成されたCが存在するわけで
それとも生成されたCはCとは認めない、みたいな話なんだろうか

**デフォルトの名無しさん** · 2024/09/01(日) 21:48:04.56

方式の違いを言語の差と思ってるなら
例えば誰かがコストの大きい計算をスレッドプールで高速化した実装をC++やRustで示せばそれでNimより速いと納得するんだろうか

**デフォルトの名無しさん** · 2024/09/01(日) 21:52:21.87

>>611
>それはCでもオブジェクトプール使えば2倍速くなるのでは？
Cは手動メモリ管理しかできないオブジェクトプールの機能はないだろ

>オブジェクトプール版のNimから生成したCはまさにそういうコードだと思うけど
人間がCの手動メモリ管理したプログラムだと限界があるムーブセマンティクスの
アルゴリズムでメモリの最適化をしてるから、人間では到底太刀打ちできない事を
証明した論文があるオブジェクトプール版のNimから生成したCのコードは人間には書けない

Nim2.0のムーブセマンティクスの本当に優れた最適化とORCで明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる

それが間違ってると主張したいのであれば、想定を合わせるためにCでもRustでもどっちでもいいから、速いベンチマークで証明すればいいだけだろ

**デフォルトの名無しさん** · 2024/09/01(日) 21:56:31.28

NimはCより2倍速いと主張している人がまずはその比較コードとベンチ結果を示す義務がありますよ

**デフォルトの名無しさん** · 2024/09/01(日) 22:00:47.66

主張するだけならどの言語でもできますがな
PythonはCよりも速い、違うというならお前らがコードを書いて証明しろ
みたいなのは面倒くさすぎて誰も相手にせんだろ

**デフォルトの名無しさん** · 2024/09/01(日) 22:04:17.16

>>617
https://github.com/Araq/fosdem2020

**デフォルトの名無しさん** · 2024/09/01(日) 22:06:25.77

>>616
別にCでも自分でオブジェクトプール実装するなり既存のarena allocator使えばいいじゃん
まぁ言語組み込みであることで「初心者が何の最適化もしないコードを書いたときにNimが最速」となる可能性はあると思うけど、それならそのように主張してくれ

**デフォルトの名無しさん** · 2024/09/01(日) 22:14:20.69

>>616
>Cは手動メモリ管理しかできないオブジェクトプールの機能はないだろ
はい、ここ笑うところですよ～

**デフォルトの名無しさん** · 2024/09/01(日) 22:18:07.82

>>619
2020年のNimのコードしか見当たりませんね
Cのコードとベンチ結果はどこですか

**デフォルトの名無しさん** · 2024/09/01(日) 22:19:40.68

CとC++の違いも判らない人が主張してもな

**デフォルトの名無しさん** · 2024/09/02(月) 02:02:31.42

最近のやり取りでなんとなくここの層がわかってきたなぁ

**デフォルトの名無しさん** · 2024/09/02(月) 10:14:38.25

MinifyされたJavaScriptのコードをChatGPTで読みやすい形式に戻すことに成功
https://gigazine.net...eering-with-chatgpt/

**デフォルトの名無しさん** · 2024/09/02(月) 11:00:21.39

まあ確かに純粋なCとの置き換えなら別にCでええやんってなるわな