結局C++とRustってどっちが良いの？ 3traits

**デフォルトの名無しさん** · 2023/05/04(木) 07:49:56.33

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/05/04(木) 15:59:17.58

さらに5つ目の方法
ファイルは分けなくて
mod foo{...}という形でfooは分けるけど
そのfooは見せない！
と一見すると矛盾した方針がある

その場合は>>6と>>10からのご推測の通り
mod foo {
　ここにFooの定義など
}
pub use foo::Foo;
とすればよい
利用者は直接Fooまたはクレート名::Fooとして使える

しかしそれならば
mod foo{...}を使わずにそのまま直接Fooの定義を書いたのと同じじゃないか！
との疑問が湧く

ほぼその通りだが
この方法によりmod foo{...}の中は名前空間が分離されているため
他とのコードの分離もしっかりできる
もし外部との結合があれば
mod foo{...}の中で改めてその使用宣言が必要になる
逆に外部から使われるものはpub宣言が必要となる
mod foo{...}の中に敢えて入れることでそれら他との関係が明示させられる

つまりまとめると3つの自由度がある
・mod fooとして分けるかどうか
・それをfoo.rsとしてファイルに分けるかどうか
・そのfooを外部に見せるか隠蔽するか
それらを多段foo::bar::bazそれぞれ含めて自由に決めればよい

**デフォルトの名無しさん** · 2023/05/04(木) 16:03:32.18

Rustの用語に「名前空間」なんてあるの？

**デフォルトの名無しさん** · 2023/05/04(木) 16:04:11.41

あるよ

**デフォルトの名無しさん** · 2023/05/04(木) 16:09:29.50

>>12
Rustは継承を使わずに合成だが
動的ディスパッチ自体はほぼ変わらない
vtable部分が合成した各メソッドを含む一覧になる程度

**デフォルトの名無しさん** · 2023/05/04(木) 16:21:16.61

この話興味ない人は今のうちにCpp2見とくと良いよ(思ってたより動きが早い)
https://herbsutter.com/2023/04/30/cppfront-spring-update/

Carbonと違ってこっちは動かせるしC++へのバックポートを視野に入れているから
結果的にRustの立ち位置に影響する

細かいところだと、この辺、Zigに通じるものがある
https://github.com/hsutter/cppfront/wiki/Design-note:-Postfix-operators
https://i.imgur.com/bkjsYG4.png

unsafe印籠(monolithic hammer)は否定してる
https://github.com/hsutter/cppfront/wiki/Design-note:-Unsafe-code

**デフォルトの名無しさん** · 2023/05/04(木) 16:21:47.50

ほとんどのmoduleは
自分の今のprojectから分離して別のcrateに移動しても
module内のpub関数はuse cratename;すればそのまま変更無しで参照出来るが
module内のmacroはuse cratename;するだけでは参照出来ない
#[macro_export] だけでは不十分でmoduleに
pub use macroname;
を書き足す必要がある

**デフォルトの名無しさん** · 2023/05/04(木) 16:22:57.02

>>9
ごめん
proc_macro が共存出来なかったって事だった
ていうか proc_macro が共存出来ないのは昔からだな

**デフォルトの名無しさん** · 2023/05/04(木) 17:29:00.42

ITの世界は短期決戦の世界。知名度がこんなに上がってるのに使用者数が1%未満
のRustには一般言語にまで普及する可能性はほぼ無い。

**デフォルトの名無しさん** · 2023/05/04(木) 17:31:09.86

今までの蓄積ではなく、新しく書かれているコードの量ですら1%未満であることの
意味は、絶対に普及しない路線に入っていると言うことだ。

**デフォルトの名無しさん** · 2023/05/04(木) 17:38:32.86

商品が売れない原因の9割は知名度不足だと言われているが、Rustは既に最高レベル
の知名度になった。なのに「売れてない」。それは商品自体に問題があると考え
なければならない。俺はRustが嫌いなので、それでいいと思っているが。

**デフォルトの名無しさん** · 2023/05/04(木) 17:48:43.01

結論としてはRustはC++に比べるとファイル分轄が非常にめんどくさいと言うことだな
ルールが複雑でめんどくさい

言語仕様なのかcargoの仕様なのかしらないけどフォルダ構造が縛られるし…

**デフォルトの名無しさん** · 2023/05/04(木) 17:52:33.78

よくわからんけど自分でstruct沢山作ってcore/modelフォルダ作ってそこに全部突っ込んでフラットに使おうとすると障害があると
implをcore/implに突っ込もうとしても問題があると
それかそれを参照する何かを別に作らないといけないと
自由度が低い

**デフォルトの名無しさん** · 2023/05/04(木) 17:56:09.35

いやーさすがにC++に比べたらRustのが超シンプルなのでわかりやすい
C++のモジュール知っててRustのモジュールを理解出来ない人はいないと思う

**デフォルトの名無しさん** · 2023/05/04(木) 17:58:28.21

>>24
障害？

**デフォルトの名無しさん** · 2023/05/04(木) 18:03:56.15

/struct、/impl、/traitみたいな分け方をしたかったのかぁ
できなくはないけどやめといたほうがいいんじゃないか

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

したいんじゃなくてそれは仮に書いただけ
自由度が低いと言うことを示したかっただけ

ファイル名やフォルダ名が縛られたり

なんで自由度が低いのに顔を真っ赤にして自由度が高いと書くのか不明なんだけど

**デフォルトの名無しさん** · 2023/05/04(木) 18:12:40.50

>>25
C++は至ってシンプルやろ?

**ななし** · 2023/05/04(木) 18:16:37.43

Javaしかやったことない
C++っていいの？

**デフォルトの名無しさん** · 2023/05/04(木) 18:16:44.50

既存のC++のプロジェクトに書き足していくかたちでCargoとかが使われてるんだろ？
C/C++の作法に併せたRustのフォルダ構成の裏ルールがあるとしか思えない

**デフォルトの名無しさん** · 2023/05/04(木) 18:21:23.60

モジュール名とファイル名（パス）は↓みたいな書き方で一応切り離せるよ
ややこしくなるから基本使わないけど

#[path="platform/foo_windows.rs"]
mod foo;

自由度が高いってのはたぶん外面を維持したまま内装を変更しやすいって意味で使ってたと思う
（長文だったからちゃんと読んでない）

モジュールの構成は可視性に関わるからそこまで自由ではないと思う
全部にpubつければ自由になるけどそんな自由はいらない

**デフォルトの名無しさん** · 2023/05/04(木) 18:34:14.75

自分が使ってる中ではC#が一番自由度が高い気がする
classの分割自由
名前空間の分割自由
プロジェクト内ではフォルダ空間自由
ファイル名自由

**デフォルトの名無しさん** · 2023/05/04(木) 18:38:46.37

global usingと言うものが出来て各ファイルでusingもしなくて良くなった
これはいらない機能だと思うけど

**デフォルトの名無しさん** · 2023/05/04(木) 18:42:44.88

C#はまじめに使ったことないけど拡張メソッドとかいうのが自由すぎて若干引いた記憶がある
どこで何を足されるか分からない恐怖を感じた

**デフォルトの名無しさん** · 2023/05/04(木) 18:48:25.91

プロジェクト内のファイル位置も当然自由
一ファイルに複数の名前空間含めるのも自由

**デフォルトの名無しさん** · 2023/05/04(木) 19:14:36.30

Rustがなぜファイル名やフォルダ名でモジュール固定になってるかと言えば
それしかモジュール位置を決定する仕組みがないから
ルートのコードからたどれる物しか名前を解決できないから
それが良くないんじゃないの？

>>35
既存のクラスすべてで必ず拡張されるわけじゃない
本当は拡張などしてなくてただのstaticメソッドだし
どこかそれを他で使われていてもそれをusingしなければ使えないから関係ない
usingしててもpublicじゃなければ見えないので影響はない

**デフォルトの名無しさん** · 2023/05/04(木) 19:37:12.64

proc_macro で黒魔術やりたい放題出来る様になりますた
おまいらのお蔭です本当にありがとうございますた

っていうか proc_macro::TokenStream と proc_macro2::TokenStream と
同時に使うと違うと判ってても混乱するな

**デフォルトの名無しさん** · 2023/05/04(木) 19:41:38.84

>>35
>どこで何を足されるか分からない恐怖を感じた

これは Rust の trait や後付けの impl にも同じ臭いを感じる

**デフォルトの名無しさん** · 2023/05/04(木) 20:43:05.13

一応Rustのimplは型（trait）を定義したクレート内に制限かけてるけどそれでも気になる人はいるか
自由な場所で定義を足せるとどうしても散らかりやすくなる

**デフォルトの名無しさん** · 2023/05/04(木) 21:36:06.92

>>38
---- lib.rs 側 ----
use proc_macro::TokenStream;
use proc_macro2::TokenStream as PM2TS;
(略)
#[proc_macro]
pub fn mk_ts(_item: TokenStream) -> TokenStream {
let mut ts: PM2TS = PM2TS::new();
Ident::new("let", Span::call_site()).to_tokens(&mut ts);
Ident::new("x", Span::call_site()).to_tokens(&mut ts);
Punct::new('=', Spacing::Alone).to_tokens(&mut ts);
Literal::u8_suffixed(255u8).to_tokens(&mut ts);
Punct::new(';', Spacing::Alone).to_tokens(&mut ts);
ts.into()
}

---- main.rs 側 ----
fn main() {
mk_ts();
println!("{}", x);
}

これで実行は出来たけど TokenStream がぶつかってるのが気に入らない

**デフォルトの名無しさん** · 2023/05/04(木) 21:37:41.16

main.rs の方は
mk_ts!(); だった

**デフォルトの名無しさん** · 2023/05/05(金) 01:53:22.17

>>30
基本的に、JavaとC++は兄弟言語で、共通点がとても多い。
classの概念もほとんど同じだし、とても良く似ている。
一方、RustとC++は全く違う言語。

**デフォルトの名無しさん** · 2023/05/05(金) 01:56:43.74

全く違うんだが現状は C からの置換を目指さなきゃいけない
その辺りがフォルダ構成にも反映されてしまっている

当然だがマッチの箇所はプロログなどの方が近い

**デフォルトの名無しさん** · 2023/05/05(金) 02:10:01.68

現にデコンストラクトによるパターンマッチはlispかhaskelくらいでしか見かけない

**デフォルトの名無しさん** · 2023/05/05(金) 02:29:13.44

似てたら置き換えやすいけど、置き換える意味も薄まりそうだけどな

**デフォルトの名無しさん** · 2023/05/05(金) 04:24:21.70

「みんなが使ってないものが使いたい」という心理を持っている人が一定数いて、
Rustはそういう人に受けてる可能性もある。

**デフォルトの名無しさん** · 2023/05/05(金) 05:02:21.75

Microsoft「Windows 11がまもなくカーネル内でRustを用いて起動」
https://www.neowin.net/news/senior-microsoft-exec-says-windows-11-kernel-will-soon-be-booting-with-rust-inside/

BlueHat IL 2023 カンファレンスにおいて、マイクロソフトのエンタープライズおよび OS セキュリティ担当バイスプレジデントである David Weston が登壇し、
Windows セキュリティの進化について話し合い、最新の進歩と今後の道のりについての洞察を講演しました。

プレゼンテーションの中でWeston氏は、MicrosoftがWindowsカーネルの一部としてRustを使用して行ってきた進歩について説明しました。
いくつかの理由でこの言語に興味を持っており、そのうちの11つはRustが提供するメモリの安全性とセキュリティを中心にしています。

Weston氏は次のように述べています。
「おそらく今後数週間または数か月以内に、カーネルでRustを使用してWindowsが実際に起動することになりますが、これは本当にクールです。
ここでの基本的な目標は、これらの内部C ++データ型のいくつかをRustの同等のデータ型に変換することでした。」

**デフォルトの名無しさん** · 2023/05/05(金) 05:36:12.75

前スレにも書いたけど、ブートローダってDOSアプリみたいなもんで、劇的に画期的じゃないんだよ

APIが早くRust化してほしいそうすれば、C++も恩恵を受ける

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

マイクロソフトがわざわざC++を捨ててまでRustを採用するとはよっぽどのことだよな
Linuxの方は元からC++さえ排除してC言語だけの純血主義だったのにRustを採用し始めてる

**デフォルトの名無しさん** · 2023/05/05(金) 06:30:56.10

>>49
記事を読んだがブートローダーなんて書かれてなかった
Rustを使った場合のWindows OSのパフォーマンス比較でOffice apps使用の場合が出てくるからブートローダーの話ではないね

**デフォルトの名無しさん** · 2023/05/05(金) 06:37:43.26

昔、マイクロソフトはわざわざJAVAを捨ててJ++を開発したんだよなあ

**デフォルトの名無しさん** · 2023/05/05(金) 06:58:16.61

これまで多数の言語が登場したけど求められてる条件はたった二つだけ
「C/C++と同等のパフォーマンスが出ること」
「C/C++の各種安全性の問題が解決されていること」
Rustが最初で唯一の言語

**デフォルトの名無しさん** · 2023/05/05(金) 08:25:55.79

>>53
どこの異世界にすんでるんだ？

**デフォルトの名無しさん** · 2023/05/05(金) 08:50:30.82

>>53
安全にするにはGC言語にするしかないと思われていたからね
Rustだけが勝者となった

**デフォルトの名無しさん** · 2023/05/05(金) 09:46:15.52

Rust以外でGC採用せずにメモリやリソースの後始末をちゃんとしてくれるよう設計された言語って何があるの？

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

お! GC君だ（この人が複製おじさん?）
GC君は他人のことを初心者呼ばわりするけど
技術的な話が全くできないんだよなぁ...

**デフォルトの名無しさん** · 2023/05/05(金) 10:21:16.98

>>50
$ tar xJf linux-6.3.1.tar.xz
$ find linux-6.3.1 -name *.c -o -name *.h | wc -l
55806
$ find linux-6.3.1 -name *.rs | wc -l
38
0.07%未満! 前回v6.2.1のとき37だったから1ファイルは増えてるね
何が増えたかは
$ diff -uNr <(cd linux-6.2.1; find . -name *.rs) <(cd linux-6.3.1; find . -name *.rs)

**デフォルトの名無しさん** · 2023/05/05(金) 10:43:09.36

>>52
JavaScriptをわざわざパクッてJscriptってのも作ったな
今やIEブラウザごと滅んだが
アップルとかソニーとか独自規格を作りたがる連中はいつの時代も迷惑

**デフォルトの名無しさん** · 2023/05/05(金) 10:47:34.91

Rustはメモリリークには割と寛容なんだよね
野生の参照（ダングリングポインタ）は目の敵にするけど

**デフォルトの名無しさん** · 2023/05/05(金) 10:52:02.55

>>56
Rustしか現存しない
他に出てきそうにないため今後Rustの時代が続くのだろう

**デフォルトの名無しさん** · 2023/05/05(金) 11:08:39.58

>>45
>デコンストラクトによるパターンマッチ
聞かない用語ですねぇ～
デコンストラクト

**デフォルトの名無しさん** · 2023/05/05(金) 11:27:48.85

>>56
Nim

**デフォルトの名無しさん** · 2023/05/05(金) 11:29:46.84

>>60
ヒモさえ付いてれば無駄遣いしてもOKみたいな

**デフォルトの名無しさん** · 2023/05/05(金) 11:58:16.34

RustってNimに対して何か優位なところはあるの?

**デフォルトの名無しさん** · 2023/05/05(金) 12:01:00.00

>>63
NimはGC言語
GCに頼らず済ませられる部分のみ使わないで済むというだけ

**デフォルトの名無しさん** · 2023/05/05(金) 12:15:37.38

>>56

間違い：メモリやリソースの後始末をちゃんとしてくれる
正解：メモリやリソースの後始末をちゃんとしてくれる(リーク除く)

**デフォルトの名無しさん** · 2023/05/05(金) 12:17:42.38

Nimはnilが存在していてヌル安全ですらない

**デフォルトの名無しさん** · 2023/05/05(金) 12:18:25.68

基本GCでも充分な性能が出れば別にいいよ
最適化が必要なところだけ手動でやるのはRustも同じだから

手動ライフタイム管理とのトレードオフ

**デフォルトの名無しさん** · 2023/05/05(金) 12:22:56.73

>>69
RustはNimのような逃げをしていない点で全く異なるよね
NimはGC言語という点でも誰も異論はなく

**デフォルトの名無しさん** · 2023/05/05(金) 12:28:44.39

>>56
Factorかね。

**デフォルトの名無しさん** · 2023/05/05(金) 12:37:44.37

FactorはForthとLispの子みたいな動的型付け言語
ガベージコレクションあり

**デフォルトの名無しさん** · 2023/05/05(金) 16:12:43.08

GCの有無は指標になるけど、現状のC++の、なんでもかんでもヒープに置く習慣は、
GCとそんなかわらないんじゃ…と思わなくもなかったり

**デフォルトの名無しさん** · 2023/05/05(金) 16:21:47.02

C++はコンパクションが行えないので、GC付きのJavaのほうが速いのです

って言ってなかった？

**デフォルトの名無しさん** · 2023/05/05(金) 17:13:23.83

感覚的にはプリミティブでない単純なデータ（xyz座標とか）の配列を直接作れるかどうかがボーダーな気がする
ポインタの配列を作ってるようだとGCしなくてもGC言語
C#は微妙なライン

変なタイミングで大掃除始める問題もあるけどこっちを気にする機会は少ないような

**デフォルトの名無しさん** · 2023/05/05(金) 18:05:31.65

結局、RustはC++より速くても、Javaよりは遅いってことですね

**デフォルトの名無しさん** · 2023/05/05(金) 19:01:02.92

もう少し待てはマイクロソフトがR++を出すと思うから
それまで待って

**デフォルトの名無しさん** · 2023/05/05(金) 23:04:16.37

JAVAが速い！？

**デフォルトの名無しさん** · 2023/05/05(金) 23:05:51.16

>>76
Rustはスタックを多用する言語なのでJavaより速い

**デフォルトの名無しさん** · 2023/05/05(金) 23:35:38.70

>>79
証拠は？

**デフォルトの名無しさん** · 2023/05/05(金) 23:47:38.29

>>80
スタック上のメモリ領域はCPUレジスタであるスタックポインタを足し算引き算するだけでメモリ確保と解放できるため最も速い

**デフォルトの名無しさん** · 2023/05/05(金) 23:50:40.76

>>81
CPUの仕組みを知っててそういう認識の人はいないと思いますよ

**デフォルトの名無しさん** · 2023/05/05(金) 23:56:37.63

もうみた～

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

>>81のスタックメモリ利用が一番速いで合ってるけど
スタックメモリは関数から戻ると自動的に開放されその部分は無効になっちゃう
そのため従来の言語ではスタックメモリの利用を抑え気味にすることでその問題を過剰に回避してた
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになったことが違いかな

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

CPUのレジスタ利用が一番速いがレジスタ割り付けの最適化が非常に難しいので
スタックを使ってお茶を濁してる

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

スタックメモリが主記憶と別の場所にあると思ってない？

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

もしかしてヒープは主記憶、スタックはプロセッサの中にあるとか思ってない？
いま検索中？

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

メモリの確保の仕方の違いでの速さの比較の話でレジスタの話を持ち出すのは違うでしょ
そしてレジスタの数は限界がありその退避先もスタックメモリですよ
スタックメモリに割り当てられた変数は最適化によりレジスタ割り当てが可能であればレジスタのみ利用になりますね

>>86
スタックメモリは単なるメインメインの一部にすぎません
しかしメモリ確保と解放が最も速いだけでなくメモリキャッシュに載る点でアクセスも速いです

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

キャッシュメモリは主記憶に含めておいた方がいい？

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

頭のおかしい人間がずっと一般的な事実に基づかない頓珍漢な独自妄想理論を展開してる

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

スタックを積極的に利用しているからrustがjavaより速いと言われて
納得する馬鹿はいないだろ

もっと根本的な理由があるだろと
javaはVMでスタックマシンをエミュレートしてるから遅い

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

通常はレジスタ一発で出来ることもわざわざスタックマシンでエミュレートしてるので遅い

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

Rustもたいがい遅いだろ

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

頭のおかしい人間がもう一人増えてた…

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

スタックメモリが確保の点でもキャッシュされてる点でも非常に速いのは常識
そのためGC言語であってもGoのようにまずはスタックメモリ利用を優先する
(他へ渡すときだけGC対象になるヒープを利用)

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

でもJavaのほうが速いんでしょ？

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

>>95
Rustはそこからさらに一歩進めて他へ渡すときもスタックメモリを使えるように改善してますね
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになりました

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

変な人大集合だね
それがrustよりjavaが速い理由だと思い込んで疑わない変な人たち

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

おっと逆だ
それがjavaよりrustが速い理由だと思い込んで疑わない変な人たち

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

RustはJavaより遅いだろ

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

そなの?

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

>>101
それはない。

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

C++とRustに比べればJavaは当然遅いしどうでもいい

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

スタックってそんなでかくない、っていう世界もCの領域なんだよね
そんときの感覚を今でも引きずってる気はする

アプリケーションの起動時に、がつんとデカく確保しちゃえばいいんだろうけどね
なんとなく、ね

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

>>103
Javaが一番速くて、少し遅れてRust、かなり離されてC++だろ

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

>>95
いわゆるエスケープ解析と呼ばれているテクニックだな
スタックメモリ利用が断トツに速いのでできる限り使うようにする
GoだけでなくJava含めていくつかの言語で行われてるが適用に限界がある
単純には各ポインタのライフタイムが関数内に閉じてればスタックメモリを利用
他の関数に渡した時は確実に追い切れないので難しい
それを可能とするには言語自体がライフタイムをサポートする必要がある
それを実現したのがRustでありライフタイムを完全に追うことができて現在最強

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

RustよりJavaのほうが速くなることも多々あるけど
unsafeやarena使ったりして最適化すればJavaより遅い状況はなくなる

でもJavaもネイティブコンパイルできるようになってるから起動速度含めてシェルスクリプトの代わりに使えるくらいには十分速いよ

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

ほとんどのベンチマークでRustが圧倒的に速い
自分でunsafeする必要なんかない

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

JavaやGoより明らかに高い性能を得ようと思ったら面倒臭いRust特有の最適化が必要になるから
自分用のツールに速度目的でRustを使うのは生産性的におすすめしない

製品開発やそれに準ずるライブラリ開発であればRustも有り

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

>>109
根拠なくそういうデマはよくないと思うよ
「面倒臭いRust特有の最適化が必要になる」なんて聞いたことも体験したこともない

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

Javaはないわー
なんだかんだいって、Oracleのドル箱なんでしょ、あそこの法務はなめちゃだめだ＞＜

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

chatGTPのいい加減なときの答えみたいなレスが増えたな

しょうもない細部にこだわって全体を一切見ない
事実を使って嘘を作るようなレス

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

複オジの一人妄想エコーチェンバースレだからね