Rust part20

**デフォルトの名無しさん** · 2023/03/03(金) 00:45:28.73

公式
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 part19
https://mevius.5ch.net/test/read.cgi/tech/1673926892/

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

**デフォルトの名無しさん** · 2023/06/05(月) 18:33:55.89

Rustの良い面が多面的であり
どの面を重視するかは人によって様々だが
Rustに行き着く点では同じだ

**デフォルトの名無しさん** · 2023/06/05(月) 18:54:42.77

まーたクソみたいな複オジ節が連投されてんなw

**デフォルトの名無しさん** · 2023/06/05(月) 20:04:46.68

>>497
>>527
他の言語の標準ライブラリでも戻り型をOptionとResultにしてほしい

**デフォルトの名無しさん** · 2023/06/05(月) 20:12:05.32

ML系言語やればいいよ思うよ

**デフォルトの名無しさん** · 2023/06/05(月) 20:50:22.82

先日のStableのリリースでやっとOnceCellが安定化されたんですね。
Lazyはまだっぽいけど嬉しい。

**デフォルトの名無しさん** · 2023/06/06(火) 02:17:44.23

去年から始めたけど、ここ2～3年で標準化された機能が必須に感じるので、最適なタイミングで始められたなと思う

**デフォルトの名無しさん** · 2023/06/06(火) 07:22:24.29

>>542
＞書き心地のよさ
ｗｗｗ

**デフォルトの名無しさん** · 2023/06/06(火) 07:54:49.95

書き心地も良いが開発効率の高さだな
スクリプトで済むのはスクリプト言語を使うとして
プログラミングするならRust一択となった

**デフォルトの名無しさん** · 2023/06/06(火) 10:54:53.70

何の数字を比べて開発効率が上がったと言ってるんだ？

**デフォルトの名無しさん** · 2023/06/06(火) 11:12:32.78

ありがとうRustAnalyzer

**デフォルトの名無しさん** · 2023/06/06(火) 19:31:13.22

>>545
それは反対だ。副作用がない関数コールでOptionやResultはオーバースペックで邪魔でしかない、Rustだって-> i32とか出来るのは理由があるからで意味のないResultラッピングしてしまうのは邪悪でしかない。

**デフォルトの名無しさん** · 2023/06/06(火) 19:35:17.52

>>553
多言語で単に言語仕様の限界から来る異常を示すのに
nullとか-1とか例外とかなんとかならんかねえという
話では

**デフォルトの名無しさん** · 2023/06/06(火) 21:19:28.43

>>553
「他の言語の標準ライブラリでも」とあるから「(Rustと同じように)」の意味だろうね
Rustで書くと戻り型がOptionやResultとなるような関数のみが対象でしょう
具体的には>>554やerrnoなど

**デフォルトの名無しさん** · 2023/06/06(火) 22:39:17.85

>>553
絶対にエラーが起きない場合も含めてインターフェースの戻り型を統一しなきゃいけない時に、
Resultで統一することで非効率になるのを恐れているのだと思うけど、
エラーが起きない場合の実装のみエラー型をstd::convert::Infallibleつまり戻り型をResult<Xxx, Infallible>とすれば、
最適化されるため気にせずResultラッピングのコードを書いても大丈夫だよ

**デフォルトの名無しさん** · 2023/06/07(水) 02:16:00.81

Rustは文字列やネット系のライブラリが充実しているため、書き易いと
感じるのかもしれないが、言語自体の書き心地は悪い。

**デフォルトの名無しさん** · 2023/06/07(水) 02:25:13.42

>>557
スクリプト以外でRustより書き易い言語ある？

**デフォルトの名無しさん** · 2023/06/07(水) 02:41:53.93

>>558
色々有るな。例えばJavaやC#とか。

**デフォルトの名無しさん** · 2023/06/07(水) 02:52:36.10

Javaは言語が古すぎ
機能不足で書くのが苦痛
今どきの言語を知っていてJavaを書きやすいと言う人はいない

**デフォルトの名無しさん** · 2023/06/07(水) 03:13:16.86

お前ら本当にシステム屋か？

“描きやすい”ってのは人それぞれで定義が曖昧やん
なぜその定義や認識の統一をせずに議論始めるん？

**デフォルトの名無しさん** · 2023/06/07(水) 03:15:24.35

例えばだけどJavaは古くてというが昔からJavaやってるやつは慣れから書きやすいと感じる

Java歴15年
Rust歴1年

とかで比べたらどっちに軍配上がるか分かるやん

**デフォルトの名無しさん** · 2023/06/07(水) 03:23:10.65

議論を成立させるのが無理なの分かってるから隔離スレでやれっつってるんですよ

**デフォルトの名無しさん** · 2023/06/07(水) 03:35:20.85

まあ言語スレで具体的なコードも出さずに議論しちゃう馬鹿ばかりだしな

せめて○○言語じゃこう書くけどRustではこう書ける
だから書きやすいってぐらいはして欲しいもんだ

**デフォルトの名無しさん** · 2023/06/07(水) 03:35:24.21

>>562
それは言語の書きやすさではなく
その個人が慣れか不慣れかだろ

言語の書きやすさはその言語に十分慣れた上で
言語の機能が不足していて書きにくい点がないかどうかなどで決まる
その比較例だとJavaとRust両方に慣れた人たちにとって全員がJavaに❌をつける

**デフォルトの名無しさん** · 2023/06/07(水) 04:14:00.36

別の言語を長くやってても面倒臭いなって思う点は出てくるじゃん
例えばJavaやってるとC#のあの機能欲しい
なんでJavaには追加されないんだろとかさ

**デフォルトの名無しさん** · 2023/06/07(水) 04:15:46.17

だから全員がJavaに✕をつける

**デフォルトの名無しさん** · 2023/06/07(水) 10:36:40.93

>>562
わかるやん、てあなたが勝手に言ってるだけですやんw

**デフォルトの名無しさん** · 2023/06/07(水) 15:06:17.70

でも、多数決では、Rustが最下位なんだよな。

**デフォルトの名無しさん** · 2023/06/07(水) 15:44:42.75

Rustの問題点を指摘すると、「それはあなたが・・・」
「馬鹿だから」「老害だから」「じじいだから」「化石みたいな人だから」
みたいな事言って人いるけど、それは
「若くて頭のいい人々が使うんだから、老害/馬鹿は黙っとけって」ことになるが、
それでは一般人に普及する言語には成れないであろう。
そもそも、高級言語の目的とは、簡単に安全にやりたいことが出来ると言う
ことであり、しかも、一部の人を除いては簡単にも思えないようなものであっては
普及は遠い。

**デフォルトの名無しさん** · 2023/06/07(水) 15:54:04.41

>>564
あなたは、そうやって、ここで、市場調査をして、次なる改良言語のネタに
したいということですね。
帰れ。

**デフォルトの名無しさん** · 2023/06/07(水) 16:20:31.76

書きやすいか否かという話より、rustは意外にタイピング量は多い思想は考え直してほしい。
std::fmtなどの「::」だとか引数名・変数の後の型の「:」だとか、むろんmutも、戻り値の「->」もなぜ引数の「:」と戻り値の「->」を同じにしなかったのか？思想面が分かる人に教えてほしい。
ほかにもなぜマクロ呼び出しに「!」をいちいち付けるのかとか、関数はfnやpubで省略しているのに？アトリビュートも#[xxx]と異様に見える。なぜ@xxxでは駄目だったのか？
まあセミコロンはC/C++からの移行を重視したのだろうけど。言語をディスってる訳じゃなく完全論破されることを願う

**デフォルトの名無しさん** · 2023/06/07(水) 16:59:17.90

細かい構文は互換性やらが重視されて一定の思想が徹底してないことも多いでしょうよ
暇ならissue掘り返してみればいい

とりあえず::はC++由来でattributeはC#由来

**デフォルトの名無しさん** · 2023/06/07(水) 18:36:58.20

Rustが難しいと感じるのは経験不足だと思うわ
困難に立ち向かった経験が少ない

**デフォルトの名無しさん** · 2023/06/07(水) 18:50:18.58

>>572
マクロ呼び出しに「!」を付けるのはコンパイラと人間の両方がマクロ呼び出しをすぐに識別できるようにするため
コンパイラの実装方法によっては無くすことは不可能ではないだろうけど効率が悪くなるし実装も難しくなる

最初は俺も無いほうが良いと思ってたけど
「!」をつけないといけないから不必要にマクロを作らなくて
結果的にメンテしやすいコードにつながってるので考え方変わった

**デフォルトの名無しさん** · 2023/06/07(水) 19:54:20.54

>>572
タッチタイピングできない人？
もしくはVSCode使ってない人？
文字数なんて気にするやつ初めて見たぞ

::はC++由来
->はHaskell由来だよ
マクロの!や?はおそらくRuby由来だが別の意味で使ってる
#[]はわからん

**デフォルトの名無しさん** · 2023/06/07(水) 20:20:10.95

>>576
煽るなら最低限公式ドキュメントの内容はすべて頭に入れてからにしたまえ
https://doc.rust-lang.org/reference/influences.html

>>572が言いたいのはTypeScriptのごとくfn f(x: T): Uとかけないのは何故かということだろう
trait boundとの曖昧性が生まれる状況があるのかなと思ったが、ちょっと具体例が思いつかないので違うかも

**デフォルトの名無しさん** · 2023/06/07(水) 21:01:38.64

というかRustは元々めっちゃタイプ数気にする系言語だったんだよねむしろ
1.0以前にはreturnがretだった頃もあった
今日まで残るfnとかimplとか、比較的新しいdynもそうだが
実際かなり略したがりな言語ではあると思うよ

**デフォルトの名無しさん** · 2023/06/07(水) 22:03:46.79

>>572
あらゆる言語で同じことが言えるが
基本的な文法記述方法を考え直してほしいと要求しても
今から変わるわけがないし変わったら利用者が困る
無意味な破壊的な要求をしていることになる

タイピング量が多いといってもわずかな誤差であり
ほとんどの記述方法は既存のメジャーな言語で実績があるものと同じ
現在のメモリCPU開発環境からも余裕で許容される範囲でもある
個人的に気に入らないと主張しているのと変わらない

**デフォルトの名無しさん** · 2023/06/07(水) 22:23:55.97

記述方法が気に入らないのであれば
自分で変換器を作ればいいだけなのでは?

**デフォルトの名無しさん** · 2023/06/07(水) 22:42:25.08

>>577
>TypeScriptのごとくfn f(x: T): Uとかけないのは何故かということだろう
基本的には視認性の問題
TypeScriptも関数の型を明記するときはファットアローを使ってる

**デフォルトの名無しさん** · 2023/06/07(水) 23:12:17.03

気に入らない部分くらいあってもいいだろうに過剰に攻撃的な人は落ち着いて欲しい
どんな人もある程度は興味があってきてるんだろうから建設的に話をしましょうよ
気に入らない部分も背景知ると納得できたりするしそういう情報知るの楽しいから書いてくれてる人はありがたい

**デフォルトの名無しさん** · 2023/06/07(水) 23:20:10.61

戻り値型指定の->には returns や maps to 的なニュアンスを感じられるから個人的には好き

**デフォルトの名無しさん** · 2023/06/07(水) 23:44:37.64

->ってでも実際は不要でしょ？
無駄

**デフォルトの名無しさん** · 2023/06/07(水) 23:52:00.89

>>572が、Rustの思想を考え直して欲しい、と攻撃的にスタートしたのはマズかったかもね。
戻り値の型指定がなぜ「:」ではなく「->」なのかと、素直に質問すればよかったかも。
理由は視認性の良さに加えて、C++の関数の戻り型の後置記法「-> int」と、同じ記法にしたためでしょう。
例えばCarbonでは「-> i32」と、Rustと同じになります。

**デフォルトの名無しさん** · 2023/06/07(水) 23:58:55.09

int foo() {}　C/C++前置
auto foo() -> int {}　C++後置
fn foo() -> i32 {}　Carbon
fn foo() -> i32 {}　Rust

**デフォルトの名無しさん** · 2023/06/08(木) 02:28:36.11

Cと似ても似つかない。

**デフォルトの名無しさん** · 2023/06/08(木) 02:35:35.53

嘘つき大国アメリカには、良いソフトウェアは作れない。
独占によって維持するのみ。

**デフォルトの名無しさん** · 2023/06/08(木) 02:36:59.06

日本人を大量虐殺したことを反省せず、今度はウクライナとロシア人を
殺している。
そんな国に良いものは作りえない。ずるするのみ。

**デフォルトの名無しさん** · 2023/06/08(木) 02:48:48.98

平均寿命がアメリカは日本より5歳も低いことをみんな知らない。
そんな後進国を先進国扱いしている。

**デフォルトの名無しさん** · 2023/06/08(木) 02:53:24.84

特に、githubなんかは、わけの分からんソフトを作ってる人に別の左翼が
寄付する。左翼は相互扶助で虚構世界を作るのが好き。一般需要が全く無い
ソフトウェアに大金が寄付される。
このように、左翼は日本やアメリカにあってもお互いに虚構を流し合うことで
脳内で言論統制し合い虚構世界を生きている。

**デフォルトの名無しさん** · 2023/06/08(木) 03:00:18.36

アメリカのやり口:
・需要が無いのに無理やり使わせる。
・不便なのに無料化することで構造上それしか存在しない状態になっている。
・無料化することでどんなに粗悪品でも対抗製品が現れ得ないからである。
・からくりは、検索エンジンの広告料で大金を永遠と稼ぐことで、ソフトを
　無料化し、検索エンジンを持たない通常企業の参入を永久阻止しているのである。

**デフォルトの名無しさん** · 2023/06/08(木) 03:40:00.34

うーん
やはりﾜｯﾁｮｲなしスレは放棄する他ないか

**デフォルトの名無しさん** · 2023/06/08(木) 03:57:30.29

>>592
各プログラミング言語の本スレを無関係な話で荒らすのはマナー違反なので止めなさい
この一線だけは守りなさい

**デフォルトの名無しさん** · 2023/06/08(木) 04:06:08.75

>>594
アメリカは、基本ルールを守ってないので個別製品の話にまで進まない。
中国の知的財産権違反や著作権違反、不正コピーを言う前に、アメリカこそ、
まずは、基本ルールを守らないと。

**デフォルトの名無しさん** · 2023/06/08(木) 04:07:01.06

アメリカは基本ルールが守れて無いのに、Rustの仕様なんて語る権利が無い。

**デフォルトの名無しさん** · 2023/06/08(木) 04:10:05.28

要は、アメリカは人殺しが刑務所で書いた本が売れて億万長者になっているようなものだ。

**デフォルトの名無しさん** · 2023/06/08(木) 07:29:01.96

C言語の戻り型の前置記述だとC++で色々と不便なことがわかり
C++11では戻り型を"->"により後置できるようになった
ラムダ式でも戻り型を指定する時に同じく"->"で後置する
つまりC++11の時点で"->"による戻り型の後置記法が導入されている
そして>>586のようにRustとCarbonもC++11の"->"を踏襲している

**デフォルトの名無しさん** · 2023/06/08(木) 08:51:14.64

他言語とか視認性置いておいてもfn f(x: T): Uは一貫性ないんだよな
Tはxの型だがUはfの型ではないわけで
:の左辺が名前で右辺が型という原則に従うなら fn f: (x: T) -> U となるはず

**デフォルトの名無しさん** · 2023/06/08(木) 08:52:05.56

うちはインターンの女子大生すらRust使い始めたわ
ﾍﾟﾁﾊﾟｰには辛い世界になっていくだろうな

**デフォルトの名無しさん** · 2023/06/08(木) 09:22:42.20

>>572
お爺ちゃん🥺

**デフォルトの名無しさん** · 2023/06/08(木) 13:15:19.62

>>599
左辺が式だと思えば筋は通るやん？

**デフォルトの名無しさん** · 2023/06/08(木) 14:14:27.48

>>572
関数を評価した結果の型と関数の型は違うものだから表現も異なる。
同じであると誤解するような説明がどこかにあるのならそれを指摘してほしい。

**デフォルトの名無しさん** · 2023/06/08(木) 14:32:27.10

隔離スレにコピペしたからあとはあっちで頼むわ

**デフォルトの名無しさん** · 2023/06/08(木) 15:00:38.73

>>602
どう見ても式ではないが
仮に式っぽい何かだとしても関数宣言にだけ特別に書けるならやっぱり一貫性はないってことになるし

**デフォルトの名無しさん** · 2023/06/08(木) 20:13:04.97

関数型言語から拾っただけで深い考えはないだろ
関数型言語は　引数　-> 戻り値　とか　引数 ->　引数　-> 戻り値でカリー化したら引数の数が減ったりするので意味は通じるけど…

**デフォルトの名無しさん** · 2023/06/08(木) 20:15:30.41

オレオレ一貫性w
全然一貫してない

**デフォルトの名無しさん** · 2023/06/08(木) 20:45:27.43

「-> 戻り型」を批判してる人は先に採用したC++に対しても批判しているの？
ML系で何十年も使われて来た実績と視認性の良さからベストな記法

**デフォルトの名無しさん** · 2023/06/08(木) 21:09:50.06

ML系は関数呼び出しにかっこを使わないし
関数定義と型注釈を分けて書くし
Cスタイルとはだいぶ違う文法体系だよね
同じ記号を使っているという以外に共通点はないと思うよ

そしてx: TはPascalスタイルの型の付け方なんですね
TypeScriptの他にもScala、Kotlin、HaxeなどがPascalに従って(x: T): Uのように戻り値型注釈をつけます
参考までに

**デフォルトの名無しさん** · 2023/06/09(金) 02:12:57.64

sigplan noticeではindentationとlexical syntaxの話は禁止だったw

**デフォルトの名無しさん** · 2023/06/09(金) 17:20:52.23

syntaxで言うならライフタイムのsyntaxは今でも違和感あるわ。
具体的に使うわけでもない変数を定義するようなのはどうにかならんかったのか。

**デフォルトの名無しさん** · 2023/06/09(金) 18:41:37.13

>>611
型変数と同じじゃない？
あれも変数として使ってるわけじゃなく、こことここの型は同じってことを示すだけの変数なわけで

**デフォルトの名無しさん** · 2023/06/09(金) 18:57:57.14

変数として使ってないわけじゃないな
具体的なインスタンスが生成されるときに具体的なライフタイムが代入されると思うべきか

**デフォルトの名無しさん** · 2023/06/09(金) 18:59:26.79

型パラメータは変数じゃありません

**デフォルトの名無しさん** · 2023/06/09(金) 19:10:21.66

違和感あるようにしてるんだぞ
Bad Partsはあえて汚くなるような構文を選んでる

**デフォルトの名無しさん** · 2023/06/09(金) 19:42:24.19

>>609
Haxe草
君のバックボーンはなんとなくわかったよ

**デフォルトの名無しさん** · 2023/06/09(金) 20:20:27.29

rustのstructってなんで中身をカンマで区切るんですか？
C/C++/C#/Swiftはセミコロンだし、影響受けたとされるhaskellの直積型はスペースですよね、デフォルトでメモリースペースが最小になるように再配置されるから？
でもそれだと配列のように直線的に配置されるように感じてしまう気がするのだが

**デフォルトの名無しさん** · 2023/06/09(金) 20:32:17.49

内容の列挙だからカンマの方が自然だと思うけどセミコロンが使われがちなのは
構文解析（エラー復帰）しやすいからなのかな

let Point { x; y; } = p;
だと気持ち悪いからパターンマッチと関係あるかもしれない

**デフォルトの名無しさん** · 2023/06/09(金) 22:10:43.24

>>618
なるほど?構文解析が楽だからという理由はある程度は納得できるが、自然と感じる理由が個人的な嗜好で何となくなのかな?
ほかにカンマを使う場面は分割代入(destructuring)があるので、structを分解するときに対称性が良いからなのかと考えたり

**デフォルトの名無しさん** · 2023/06/10(土) 08:59:06.95

cでエンディアン確認するとき

unsigned long x = 0x12345678;
for( int i = 0; i < sizeof(long); i++ ){

**デフォルトの名無しさん** · 2023/06/10(土) 09:07:47.23

cでエンディアン確認するとき

unsigned long x = 0x12345678;
unsigned char *px = (unsingned char *)&x;
for( int i = 0; i < sizeof(long); i++ ){
　fprintf(stderr, "%X ", *px++ );
}
fprintf(stderr, "\n" );

てのをrustならどー書いたらええの>

**デフォルトの名無しさん** · 2023/06/10(土) 09:44:12.87

それと同じこともできるけど、単にエンディアン知りたいだけならこんな感じで

if cfg!(target_endian = "big") {
// big endian
} else {
// little endian
}

**デフォルトの名無しさん** · 2023/06/10(土) 09:56:44.54

>>622
エンディアンと書いたのは一例で
実際用意された型にバイトデータがどう格納されてるかを知りたい
ポインタキャストどー書くの?

forとかも変なことなってるけど
条件判断と goto ラベルさえあれば繰り返しは実行できるんだが,
rustにC/C++にあるgotoとかラベルってあるの?

**デフォルトの名無しさん** · 2023/06/10(土) 10:05:08.69

>>623
その場合はtransmuteかな
https://doc.rust-lang.org/std/mem/fn.transmute.html

gotoはない
ラベルはネストしたループから脱出するためのはある

**デフォルトの名無しさん** · 2023/06/10(土) 10:07:35.39

>>621
let x: i32 = 0x12345678;

// 直訳すると生ポインタなのでunsafe
use std::mem::size_of;
let mut px = &x as *const i32 as *const u8;
for _i in 0..size_of::<i32>() {
print!("{:x} ", unsafe { *px });
unsafe { px = px.add(1); };
}
println!();

// byte列とみなすメソッドを使うとsafe
for b in x.to_ne_bytes() {
print!("{b:x} ");
}
println!();

**デフォルトの名無しさん** · 2023/06/10(土) 10:13:46.29

エンディアン君を、ウッカリ助平と命名したい....

**デフォルトの名無しさん** · 2023/06/10(土) 10:25:42.92

>>624
>>625

**デフォルトの名無しさん** · 2023/06/10(土) 10:26:30.43

>>624
>>625
わざわざありがと
勉強になります

>>626
何ソレ?

**デフォルトの名無しさん** · 2023/06/10(土) 10:35:25.62

to_ne_bytesのneはnative endianの意味でleやbeもある
neを使ってlittle endian環境ならば
assert_eq!(0x12345678_u32.to_ne_bytes(), [0x78, 0x56, 0x34, 0x12]);
assert_eq!(0x12345678, u32::from_ne_bytes([0x78, 0x56, 0x34, 0x12]));

**デフォルトの名無しさん** · 2023/06/10(土) 15:12:50.25

テキストデータを画像にレンダリングして最終的に2値モノクロ画像を得たいんだけど
今だとどんなクレートを使うのがいいかな？
フォントレンダラはfont-rs・・・は放置されているしからfontdueとか？
2値化に影響するディザリングのオプションとかを指定できるとありがたい

**デフォルトの名無しさん** · 2023/06/10(土) 15:48:41.24

rusttypeとかab_glyphってのがダウンロード数多いみたい

**デフォルトの名無しさん** · 2023/06/12(月) 12:58:17.77

ただの思いつきだが、CやC++はメモリセーフではないだろ。ってことはプログラム中で結構無駄なメモリを消費してたりしないの？Rustはそこの所最適化されてるから究極的にはRustの方がCやC++よりも高速に動作するのでは？

**デフォルトの名無しさん** · 2023/06/12(月) 13:04:11.65

？

**デフォルトの名無しさん** · 2023/06/12(月) 14:15:17.58

ちょっと何言ってるかわからない

**デフォルトの名無しさん** · 2023/06/12(月) 16:35:03.90

メモリセーフかどうかと
メモリを無駄使いしてるかどうかに直接の関係はない

**デフォルトの名無しさん** · 2023/06/12(月) 16:47:01.05

メモリ安全性とメモリの利用効率に関係はないが、
安全性のために導入したライフタイム管理が最適化に影響する部分がないとは言えない。
依存関係が明瞭だからエイリアス解析がしやすく、
結果的に効果的に最適化しやすい可能性は高い。

しかし実行時でないと安全なアクセスであるかどうか検出が不可能な場合もあるから
それも込みで考えると Rust のほうがやや不利であると言える要素もある。
全体的な性能は互角か Rust のほうがやや遅いくらいじゃないの。知らんけど。

性能が互角くらいでより安全ならそのほうがいいじゃろ。

**デフォルトの名無しさん** · 2023/06/12(月) 18:28:52.16

メモリ安全にするために過剰なコピーや長いライフタイムになる実装をしてしまうことがあり、それをコンパイラがガードしてあげるからルールに従って書いてねってのがRustの思想だと思う。
逆に適当に書いても安全にするし出来るだけメモリ効率も配慮するよってのが他のGC言語

**デフォルトの名無しさん** · 2023/06/12(月) 18:44:13.30

そんな話一般論で語れる訳ないぞ
コードを出しな？

**デフォルトの名無しさん** · 2023/06/12(月) 20:02:49.65

>>636
そんなことはなくRustも適切な方法を選べる
そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん

**デフォルトの名無しさん** · 2023/06/12(月) 21:33:36.66

>>639
ここではメモリ安全性が実行効率に寄与するわけではないというのがトピックなので
安全性 (自動的な安全性の検証) を捨てることも出来るというのは話題の外。

**デフォルトの名無しさん** · 2023/06/12(月) 21:39:50.33

意味のない議論がほんと好きだねー

**デフォルトの名無しさん** · 2023/06/12(月) 21:44:05.58

コードが一切出てこないのが本当不思議