Rustアンチスレ (202レス)
Rustアンチスレ http://mevius.5ch.net/test/read.cgi/tech/1509028624/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
67: デフォルトの名無しさん [sage] 2021/09/04(土) 03:57:00.95 ID:kn1l/Q+t >>24 いや、自走車椅子だろ http://mevius.5ch.net/test/read.cgi/tech/1509028624/67
68: デフォルトの名無しさん [] 2021/09/04(土) 04:05:22.28 ID:iqtSb51S >>24 C++より便利で安全だから 例えると醤油とソースかな http://mevius.5ch.net/test/read.cgi/tech/1509028624/68
69: デフォルトの名無しさん [] 2021/09/06(月) 13:53:51.27 ID:kq9rR1L5 Rustスレでは場違いなので、イテレータというか高階関数の話にもう一度食いつくとする。 Juliaなんかだと並列・分散処理するために@distributed forなんて書くが、Erlangだとループ中に spawnをして、Goもgoroutineを起動する。map/reduceなんかだと明らかにメニ―コアを使った方が 速いが、標準ではそうなっていなくて、外部ライブラリのrayonなどを使用する。 GoでもRustでもこれをさらに分散処理させるにはgRPCなど規格化されたインターフェースを通すが やりたい事はJuliaの@distributed forなのに手間を感じさせる。 Rustにライトウェイトスレッドが言語仕様として入るとは思えないが、やはり言語には向き不向きが 存在する。近年のjavascriptを発端とするasync/awaitにも疑問が生じる。あまりにも多くの言語が 同期実行のライブラリと整合性が無さすぎる http://mevius.5ch.net/test/read.cgi/tech/1509028624/69
70: デフォルトの名無しさん [sage] 2021/09/06(月) 14:51:17.48 ID:6RpN+EMp DSLと同等の使い勝手を汎用的な言語に求めるのはつらいのでは http://mevius.5ch.net/test/read.cgi/tech/1509028624/70
71: デフォルトの名無しさん [] 2021/09/06(月) 16:49:04.49 ID:7r7RF488 >>69 たしかにJavaScriptのasync/awaitとRustのは最も対照的ですがどちらも良い特徴があると思います JavaScriptはブラウザも外部のNode.jsもその言語実行環境として非同期ランタイムが組み込まれasync/await導入以前から非同期関数が標準として装備 そのため非同期関数が呼ばれたら次のスケジュールで即座に実行が始まりますね 一方でRustは標準の非同期ランタイムがなく用途に合わせて自由に非同期ランタイムを用意することが出来ます さらにRustのasync/await自体はゼロコストで設計されており非同期関数が呼ばれても自動的にスケジューリングされない特徴があります Rustはこれらに関して「何ができない」のではなく「何でもできる」わけなので あとは記法の簡易性を求めるのならばその呼び出し関数等の設計とマクロでお好みの方面へ寄せることも可能です http://mevius.5ch.net/test/read.cgi/tech/1509028624/71
72: デフォルトの名無しさん [] 2021/09/11(土) 00:36:45.81 ID:YO3o85Uj >>71 これは良い書き方をしているが非同期ランタイムを自由に選べるのではなく、適切に選ばないと インターフェースをサポートしない場合があるため、互換性が保てないでしょう。Rusterは ゼロコストという話を良くしますが、Rustの非同期はタスクごとにステートマシンを作るために 確かにNode.jsなどと比べるjavascriptと比べれば、全体で非同期をスケジューリング管理する ものと比べアロケーションや実行コストなどは小さいですが、それほど喧伝すべきことでもありません。 いずれにせよ多くの非同期はI/Oバウンドでありepollベースなどで管理されます。当然ながら (Cに代わるようなハードウエア近い)システム言語なので出来ない事があってはイケていません。 私が言っているのは、Rustに限りませんがasync/awaitの記述が普通に考慮されてない設計の悪い ライブラリが沢山あるという事です。Rustのマクロは最低だと思います、なぜわざわざ学習コストを 引き上げるのか理解できません http://mevius.5ch.net/test/read.cgi/tech/1509028624/72
73: デフォルトの名無しさん [sage] 2021/09/11(土) 01:17:56.12 ID:PRM8i6LA >>72 あなたの主張は意味がわからない まず「互換性が保てないでしょう」は何との何の互換性が保てないのか?意味不明 次に「それほど喧伝すべきことでもありません。」は結局のところあなたは反論すら出来ずに同意してしまっている さらに「Rustに限りませんが(略)設計の悪いライブラリが沢山あるという事です。」はRust言語に対する批判にすらなっていない それぞれ具体的に問題点を述べましょう http://mevius.5ch.net/test/read.cgi/tech/1509028624/73
74: デフォルトの名無しさん [sage] 2021/09/11(土) 01:24:36.44 ID:Q/hQI3Xf 唐突にマクロが登場するのも分かりませんね async-awaitがマクロだった頃の話をしているのですか? http://mevius.5ch.net/test/read.cgi/tech/1509028624/74
75: デフォルトの名無しさん [] 2021/09/11(土) 01:41:58.05 ID:YO3o85Uj あんたの方が意味不明だけど(笑) まず文書の書き方にケチを付けてロンパーする癖を直しましょう。 最初から非同期ランタイムの互換性と書いているでしょう。例えばasync-stdと tokioは互換性がありません。今は互換性がほぼあるようになってきていますが それでも完全ではありません。 ゼロコストFeatureという話は、VS Javascriptという言語のランタイムではその 通り認めていますが、コンパイル型の言語でコストが高い非同期は稀です。 Rust言語に対する批判しか書かないわけではありません。あなたは攻撃されたと 思い込む癖が強すぎる。「近年のjavascriptを発端とするasync/awaitにも疑問が 生じる。あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」 という大本も読めない。まあそういう人間が増えすぎて居る訳で、こんな雑談で 怒り心頭になり、それぞれの具体的な問題点はあなたの性格でしょう。 言語的な反論をせずに文書の読解も出来ず、条件反射で相手を貶す。とてもでは ないですが近寄りがたいですね またマクロについても「マクロでお好みの方面へ寄せることも可能です」という 返答に関して感想を述べてるのに過ぎないのに、全く話を辿れていません。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/75
76: デフォルトの名無しさん [sage] 2021/09/11(土) 02:11:46.06 ID:w5S7rLqj >>75 具体的な問題点を述べましょう 例えばtokioの上に構築されたhttpモジュールであるhyperも互換レイヤーによりasync-std 上でも動作します RustアンチスレでなぜJavaScriptを問題にしているのかも謎ですが JavaScriptのasync/await/Promiseもあの環境で非常に優れて設計されています この件についても具体的な問題点を述べておられないですね http://mevius.5ch.net/test/read.cgi/tech/1509028624/76
77: デフォルトの名無しさん [sage] 2021/09/11(土) 11:03:00.32 ID:LLoV+Okg >>75の勝ち 以上 http://mevius.5ch.net/test/read.cgi/tech/1509028624/77
78: デフォルトの名無しさん [sage] 2021/09/11(土) 13:53:10.45 ID:zUj2TAiQ >>75 >「近年のjavascriptを発端とするasync/awaitにも疑問が生じる。 >あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」 意味がちょっと不明です。 JavaScriptでそれらが用いられうる通信分野では、基本的に同期実行のライブラリは存在しません。 例えばhttpなどで取得してくるfetch()も非同期ですし、もっと低水準のモジュールも非同期です。 同期実行のライブラリと整合性が無さすぎるとは、何を意味しているのでしょうか? http://mevius.5ch.net/test/read.cgi/tech/1509028624/78
79: デフォルトの名無しさん [sage] 2021/09/11(土) 13:59:42.94 ID:QGVH5OH8 発端と言ったらC#の方が古くね http://mevius.5ch.net/test/read.cgi/tech/1509028624/79
80: デフォルトの名無しさん [] 2021/09/12(日) 14:45:35.48 ID:dsndgRWH Rustって組み込み開発向いて無くね? どう考えてもLinuxなりBSDなりある程度高度なOSがある事前提だ、OSのメモリーコンパクションが 無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。 マイクロコントローラのメモリー付きSoCでブーストラップローダーがあるだけの組み込みには使えない ま、サポートプラットフォームにTier1/Tier2でも、そういうのに使えるとは書いてないけど http://mevius.5ch.net/test/read.cgi/tech/1509028624/80
81: デフォルトの名無しさん [sage] 2021/09/12(日) 15:02:08.52 ID:raaoGYn7 >>80 その文章だけならCにいれかえてもあってそうなんだが? http://mevius.5ch.net/test/read.cgi/tech/1509028624/81
82: デフォルトの名無しさん [sage] 2021/09/12(日) 15:22:52.56 ID:lBuMyCBZ >>80 つまりC/C++/Rustは組み込みやOSに向いていないとw http://mevius.5ch.net/test/read.cgi/tech/1509028624/82
83: デフォルトの名無しさん [sage] 2021/09/12(日) 15:26:04.82 ID:Cf6Jz1Ay そこで組み込みのために開発されたJavaですよw http://mevius.5ch.net/test/read.cgi/tech/1509028624/83
84: デフォルトの名無しさん [sage] 2021/09/12(日) 21:57:41.77 ID:UrK9UNLE それはリソースがたっぷりある組み込みのケースで感覚としてはアプリ開発に近い 組み込みはピンキリだからスクリプト言語が動く環境まである 一方でC/C++/Rustじゃないと厳しい環境もある http://mevius.5ch.net/test/read.cgi/tech/1509028624/84
85: デフォルトの名無しさん [sage] 2021/09/12(日) 22:17:14.89 ID:Zjk1d74X >>75 同期実行ライブラリと整合性が無いというのはウソです Rustでstd利用の同期とasync-std利用の非同期のプログラムはほとんど同じように書けます 例えば複数のファイルのチェックサム計算を同期と非同期の2通りに書いた以下の記事を参考にすると https://qiita.com/osanshouo/items/671c45072a79c7b27aba メイン部分の両者のdiffを取ると以下のような感じです for entry in entries { let entry = entry.unwrap(); if entry.file_type().unwrap().is_file() { + let handle = async_std::task::spawn(async move { let filepath = entry.path(); - let mut file = fs::File::open(&filepath).unwrap(); + let mut file = fs::File::open(&filepath).await.unwrap(); let bytes = { let mut bytes = Vec::new(); - file.read_to_end(&mut bytes).unwrap(); + file.read_to_end(&mut bytes).await.unwrap(); bytes }; let checksum = bytes.iter().fold(0u8, |acc, b| acc.wrapping_add(*b)); println!("{:?}: {}", filepath.file_name().unwrap(), checksum); + }); + handles.push(handle); } } つまり差は2点のみ 非同期実行では不可欠なspawnがが入ることと 非同期を同期風に書けるようにするためのawaitが入ることだけです おっしゃる『同期実行のライブラリと整合性が無さすぎる』との主張は間違っています http://mevius.5ch.net/test/read.cgi/tech/1509028624/85
86: デフォルトの名無しさん [sage] 2021/09/12(日) 22:19:55.41 ID:s09Gb+ph 設計にバカが関わってなければC++で十分 http://mevius.5ch.net/test/read.cgi/tech/1509028624/86
87: デフォルトの名無しさん [sage] 2021/09/12(日) 22:44:56.06 ID:Q5FBinyU コードの規模が大きくなると複雑さが増して相対的に知性下がるからバカが開発することを前提にした方が良い http://mevius.5ch.net/test/read.cgi/tech/1509028624/87
88: デフォルトの名無しさん [sage] 2021/09/13(月) 20:47:01.12 ID:dBMpD8or >>87 それは自覚症状が無いだけで自分が馬鹿なだけかも知れんが。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/88
89: デフォルトの名無しさん [sage] 2021/09/13(月) 20:51:25.89 ID:9PNw/wOW >>88 自分は馬鹿と思ってコード書いた方が良いよ本当に これはバカにしてるとかじゃなくて心構えとして http://mevius.5ch.net/test/read.cgi/tech/1509028624/89
90: デフォルトの名無しさん [] 2021/09/14(火) 19:27:55.83 ID:kyozNdb6 >>89は賢いお人 本来馬鹿は馬鹿を自覚できないから 平気でウンコを顔面につけたまま歩き回り いろんなものを糞まみれにしてケロっとしてる http://mevius.5ch.net/test/read.cgi/tech/1509028624/90
91: デフォルトの名無しさん [sage] 2021/09/14(火) 20:13:08.96 ID:Wng5bteL >>89 お前と俺を一緒にスンナよ。 人間の頭脳は画一敵意ではなく差が大きい。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/91
92: デフォルトの名無しさん [sage] 2021/09/14(火) 23:33:28.66 ID:9cp1Eg6y 微笑ましい http://mevius.5ch.net/test/read.cgi/tech/1509028624/92
93: デフォルトの名無しさん [sage] 2021/09/14(火) 23:52:38.24 ID:BSh8VTqx 少なくともある程度以上の大きさの開発したことある人や 複数案件を同時進行した人なら いくら完璧にしていても確率的にミスが入り込むとわかるはず そしてC++とRustとの比較ならどちらが良いかも冷静に判断できる http://mevius.5ch.net/test/read.cgi/tech/1509028624/93
94: デフォルトの名無しさん [] 2021/09/15(水) 02:02:19.36 ID:x4RgVtnC >>85 そんな事を言ってるんじゃないと思いますよ、「複数のファイルのチェックサム計算」なんて単純な事なら 当然ながら同期と非同期でそれほど違いは出ないでしょうし互換性があるように見えるでしょう。なぜなら チェックサム計算は一瞬で終わり非同期はファイル毎に区切っているから。チェックサム計算は同期コードで いずれも書かれていて1つも違いがありません。 これをいくつかのファイルは巨大でファイル長が不明(無限では無い)が大きいファイルのチェックサム計算や より複雑で時間のかかる計算を非同期で行いたいとすればどうしますか?チェックサム計算で、read_to_endは 使えずストリームを非同期に読み続けて計算することになるでしょう。という事はbytes.iter().foldも使えません 「同期実行ライブラリと整合性が無いというのはウソです」このように言い切ること自体に"気持ち悪い信仰"を 持っているのは良く分かりますが、元が「整合性が無さすぎる」と言っているのは、整合性がある1パターンを 示しても意味が全く無いという事です。多くの問題は「ウソです」と言い切れる浅はかさが問題です http://qiita.comの記事なんて初心者のサンプルに過ぎません http://mevius.5ch.net/test/read.cgi/tech/1509028624/94
95: デフォルトの名無しさん [sage] 2021/09/15(水) 11:47:44.97 ID:PYzW5a+n >>93 確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/95
96: デフォルトの名無しさん [sage] 2021/09/15(水) 20:26:11.48 ID:77IP/X5S >>95 rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ? http://mevius.5ch.net/test/read.cgi/tech/1509028624/96
97: デフォルトの名無しさん [sage] 2021/09/15(水) 21:21:02.30 ID:PYzW5a+n rustcで検出できるバグよりcとのバインディングでの勘違いで生じるバグのが多いわな http://mevius.5ch.net/test/read.cgi/tech/1509028624/97
98: デフォルトの名無しさん [sage] 2021/09/16(木) 00:37:37.41 ID:Efcezeu+ まあ静的チェックに過剰な期待してる奴は大抵クソだよ http://mevius.5ch.net/test/read.cgi/tech/1509028624/98
99: デフォルトの名無しさん [sage] 2021/09/18(土) 06:51:34.59 ID:pceSJQ2d >>93 そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね http://mevius.5ch.net/test/read.cgi/tech/1509028624/99
100: デフォルトの名無しさん [sage] 2021/09/18(土) 07:04:45.25 ID:WtcFUHdh Rustのスレで何を頓珍漢な http://mevius.5ch.net/test/read.cgi/tech/1509028624/100
101: デフォルトの名無しさん [] 2021/09/25(土) 03:20:19.87 ID:r08K7R9X コンパイルチェックがゼロになるコードを書けるまでウンコ呼ばわりされる http://mevius.5ch.net/test/read.cgi/tech/1509028624/101
102: デフォルトの名無しさん [sage] 2021/10/20(水) 16:37:55.38 ID:rOkBuggn >80 >無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。 ヒープも使わない(ことが多いから)、メモリーの断片化も起きない 当然GCなんかいらない rustが組み込みに向かないのは同意する http://mevius.5ch.net/test/read.cgi/tech/1509028624/102
103: デフォルトの名無しさん [] 2021/10/20(水) 19:56:54.98 ID:VGECjsMp 小さなの規模にもよるけど スタックや初期化時以外で動的なメモリ確保がそもそもできなくない? Unix風のプロセスモデルでもないとmallocし続けるだけでアウト http://mevius.5ch.net/test/read.cgi/tech/1509028624/103
104: デフォルトの名無しさん [sage] 2021/10/20(水) 20:18:24.99 ID:rOkBuggn 組み込みの世界ではヒープじゃなくて、 リンクリストのノードを固定長メモリブロックとして使ったりする 例えばuItronのメモリプールの実装とかそんな感じ ヒープはリアルタイム性がないから で、rustはstatic mutが使い辛過ぎて、組み込みでは難しそう http://mevius.5ch.net/test/read.cgi/tech/1509028624/104
105: デフォルトの名無しさん [] 2021/10/20(水) 20:22:41.04 ID:VyYhhIkP D言語も忘れないで下さい。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/105
106: デフォルトの名無しさん [sage] 2021/10/20(水) 20:37:31.19 ID:rOkBuggn アンチスレとはいえ 将来性を考えると、さすがにD言語よりはrustの方が…… http://mevius.5ch.net/test/read.cgi/tech/1509028624/106
107: デフォルトの名無しさん [] 2021/10/20(水) 22:36:34.87 ID:VyYhhIkP D言語:「忘れないで・・・」 http://mevius.5ch.net/test/read.cgi/tech/1509028624/107
108: デフォルトの名無しさん [sage] 2021/10/20(水) 22:52:38.54 ID:UtWr6ljA Deprecated Dormant Dead 縁起悪いよ…(´・ω・`) http://mevius.5ch.net/test/read.cgi/tech/1509028624/108
109: デフォルトの名無しさん [] 2021/10/21(木) 18:37:53.89 ID:wlIxx6Dc 言語と関係ないがrusterのこういう陰湿さが嫌、goに頻繁に嫌がらせしてるし、gcが選べるD言語など まだまだマイナーな言語へ嫌がらせする http://mevius.5ch.net/test/read.cgi/tech/1509028624/109
110: デフォルトの名無しさん [sage] 2021/10/21(木) 20:22:29.58 ID:s+sF4o2E Dのことマイナーって呼ぶなよ http://mevius.5ch.net/test/read.cgi/tech/1509028624/110
111: デフォルトの名無しさん [sage] 2021/10/22(金) 20:07:55.54 ID:BGSpAusK >>106 将来を考えるなら、文字列でだらだら書くというスタイルが古臭いってなるかもね。 今のプログラミングは、分厚い本を読まされてる、書かされてるみたいなもん。 映像なら3秒でですむことを延々と書き連ねているようなもんだし。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/111
112: デフォルトの名無しさん [sage] 2021/10/22(金) 21:52:45.50 ID:v3Yxx0iq 永遠に可能性が無いとは言わないが、テキスト以外の方法は生まれては消えてを繰り返してるのでどうも期待出来無い。 人間がコード書く役割が終わる方が先に来るんじゃないかな。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/112
113: デフォルトの名無しさん [sage] 2021/10/23(土) 08:17:48.59 ID:126WIPxs >>112 AIでも同じようなことが言われていて、 囲碁で人間に勝つには100年かかるなんて言われてたからね。 >人間がコード書く役割が終わる まさにそれ。 人間は「こうしたい」というのを表現できればそれで良いわけで、それをわざわざ文字列で延々と書き連ねるというのが古臭いことになるんじゃない?ってことね。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/113
114: デフォルトの名無しさん [sage] 2021/10/23(土) 08:56:15.06 ID:3BoTC/ER 現状人間同士である程度厳密に情報を伝えようとすると言葉に頼るわけでコンピューター相手でもそこは変わらない気がする http://mevius.5ch.net/test/read.cgi/tech/1509028624/114
115: デフォルトの名無しさん [sage] 2021/10/25(月) 17:46:30.13 ID:a6PpXdhO >>114 わざわざ人間が翻訳機になってるっていうのが古臭いって思うんよね。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/115
116: デフォルトの名無しさん [sage] 2021/10/25(月) 17:54:38.98 ID:a6PpXdhO >>114 文字によるプログラムっていうのが結局いつまで経っても1.5次元みたいなもんで、どことどこが関連しているのかということすらパッと見てわからないしね。 まあ、世の中には何百万行もあるプログラムでも簡単に目を通して全体像を把握できるような天才的な人もいるんだろうけど、私には無理だわ。 トシヨリガーとか、老害だとか言ってる割には旧来の手法に固執するんだな。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/116
117: デフォルトの名無しさん [sage] 2021/10/25(月) 20:15:43.78 ID:cubP7NbG >>116 グラフィカルなプログラミング環境とか、設計手法だけどUMLとかあるにも関わらず一般的なプログラミング言語を置き換えるには至ってないよね 旧来の手法を置き換えるには何かしらのブレークスルーが必要なんだと思う 現状プログラミングが主に言葉で書かれているのは、人間がプログラムを考えていることと、人間の考えを厳密にコンピューターに伝える必要があることに由来していると思う 人工知能が発達して人間の曖昧な指示に従ってコンピューターがプログラミングするとか、脳波読みとりなど言語化なしで人間の考えを伝える手段が現れれるなどすれば状況は変わるかも知れない http://mevius.5ch.net/test/read.cgi/tech/1509028624/117
118: デフォルトの名無しさん [sage] 2021/10/25(月) 20:53:20.91 ID:IG0eAPOa どの程度の複雑さをコンピュータ側に持って行っても、要求なり目的なりを記述する必要は残る。 いわゆる "プログラミング" では無いかもしれないが。 そこの記述はグラフィカルでどうのこうのと言っても汎用性を求めると結局はテキストになるんじゃないかな。 まあ要求記述のテキスト、というとSQLがその一つなんだけどさ。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/118
119: デフォルトの名無しさん [sage] 2021/10/28(木) 17:10:44.11 ID:nJ3D7u2B >>118 で、現実にやってるのは、やれCだなんだと、それぞれの方言に合わせて人間が一生懸命翻訳作業をして文字列で書き起こしている。 客観的に見れば実に珍妙な記号とあるふぁべっの羅列でね。 そして、流行りの方言が出るたびにその方言を覚えては翻訳作業。 でも、結局のところコードが大幅に減るわけでもなく、肥大化するにつれて誰も正しい全体像を把握できなくなるのは同じこと。そして、いつまで経っても無くならない誤訳…バグの山。 やはりこのスタイル自体に無理がきているんだと思うわ。まあ、究極はコンピュータそのものの考え方から変えないとダメかもしれないけどね。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/119
120: デフォルトの名無しさん [sage] 2021/10/28(木) 17:37:46.17 ID:oV3TAAYO >>119 そのレベルの話だとコーディングと言うよりも設計の問題なのでは http://mevius.5ch.net/test/read.cgi/tech/1509028624/120
121: デフォルトの名無しさん [sage] 2022/02/26(土) 07:53:14.27 ID:BV4vpVpG 自分がどうしたいってことしか考えないから、言語が要らないなんて言い出す。 受けとる方を考えてみろ。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/121
122: デフォルトの名無しさん [age] 2022/04/27(水) 15:55:20.74 ID:1aIRuPS7 CとリリースモードのRustは、どちらも実行時間が最小限です。 Cは未定義の動作でそこに到達します。 Rustは、非常に堅牢な言語定義を使用して、コンパイラーが多くの危険なプラクティスを拒否し、多くの望ましい結果を安全で比較的便利にすることを可能にします。 しかし、Rustは、多くの人が望ましくないと考える特定の動作も許可します。許可されるように言語を定義するだけです。たとえば、整数のオーバーフローを考えてみましょう。デバッグモードでは、Rustは整数のオーバーフローでパニックになります。良い。リリースモードでは、2の補数としてラップします。悪い。つまり、それは言語定義に含まれているので、非常に優れていますが、私に関する限り、これは、符号付き整数のオーバーフローを未定義の動作として参照するCおよびC++言語定義とほぼ同じくらい悪いものです。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/122
123: デフォルトの名無しさん [sage] 2022/04/27(水) 16:14:27.17 ID:fXEX2s7j >>122 Rustはそのために例えば足し算でも checked_add overflow_add wrapping_add saturating_add など用途毎に使い分けられるようになっている http://mevius.5ch.net/test/read.cgi/tech/1509028624/123
124: デフォルトの名無しさん [] 2022/04/27(水) 18:36:40.62 ID:HjqqO7sC sssp://img.5ch.net/ico/2iyou_2.gif あかんところ列挙 ・コンパイル型言語らしいけど、C++の方が速い(GCC万歳) ・CPLから派生した言語とかなり系統が違う(習得しづらい) ・関数宣言でわざわざfnをつけないといけない(文脈で理解できないのかコンパイラ) 以下、C++のあかんところ ・最近のは遅い->STL使わんかったらいい、もしくは自作 ・バッファオーバーランとか、危ないことが起こる->そんな阿保プログラムを書かなかったらいい http://mevius.5ch.net/test/read.cgi/tech/1509028624/124
125: デフォルトの名無しさん [sage] 2022/04/27(水) 18:45:52.15 ID:kbMyQ47R >>124 RustとC++はほぼ同等の速度 その上でRustは様々な安全性とC++より便利な機能によりプログラミング生産性も良い http://mevius.5ch.net/test/read.cgi/tech/1509028624/125
126: デフォルトの名無しさん [] 2022/04/27(水) 18:53:45.96 ID:DngKLmNp >>123 そういうことを言いたいんじゃない。releaseとdebugで動きが異なることを言いたいのだ。例えばGoなどはどちらも動きはわからない。 Rustはどう考えても、プログラムの1つ1つを完全に知りえていなければプログラムを書いてはならず、安全な側へ倒すのではなく、releaseでオーバーフローを省略するのにそれで速いとゴマカしている。計算系のベンチマークテストなどまさにそう また上のように「用意している」という表現も、限りなく敷居をわざと高くしているだけで、何の利点でもない。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/126
127: デフォルトの名無しさん [sage] 2022/04/27(水) 18:55:26.96 ID:j3SjDNhs >>123 checked_add (=足し算でoverflowするとOption::Noneを返す) 便利だな 例としてすぐオーバーフローするi8型(符号付き8bit整数)を使って フィボナッチ数列イテレータを書いてみた fn fibonacci_i8() -> impl Iterator<Item=i8> { itertools::unfold((0_i8, 1), |(m, n)| m.checked_add(*n).map(|f| { *m = *n; *n = f; f }) ) } fn main() { for f in fibonacci_i8() { print!("{f} "); } } 出力結果: 1 2 3 5 8 13 21 34 55 89 確かに上限127を超えて溢れる寸前まで求まっている http://mevius.5ch.net/test/read.cgi/tech/1509028624/127
128: デフォルトの名無しさん [] 2022/04/27(水) 18:57:07.63 ID:DngKLmNp このようにわざと貼り付けなくても良いことを書いて、不都合を指摘すると流すようにするのは本当に良くないコミュニティの態度 http://mevius.5ch.net/test/read.cgi/tech/1509028624/128
129: デフォルトの名無しさん [sage] 2022/04/27(水) 19:00:24.43 ID:QwtQyiYP >>127と同じ関数を他のプログラミング言語で書くとどんなコードになるの? 具体的にコードを比較して客観的に判断したい http://mevius.5ch.net/test/read.cgi/tech/1509028624/129
130: デフォルトの名無しさん [sage] 2022/04/27(水) 22:32:13.33 ID:Xa5DwGtB >>126 release buildでもチェック有効にできるよ https://doc.rust-lang.org/cargo/reference/profiles.html#overflow-checks プログラムの一つ一つを理解しなくても書ける言語ってどういうものだろう http://mevius.5ch.net/test/read.cgi/tech/1509028624/130
131: デフォルトの名無しさん [] 2022/05/19(木) 17:01:33.84 ID:YoVN/Jlg >>125 今どきのC++は遅いっていうけど、新しいC++の仕様を使うからである。 つまり、Better Cみたいな使い方をすればRustより速くなる(実際そういう結果もある)。 まあ、体感はどっちもかわんねえべってとこだから、RustよりJava,C#とかスクリプト言語をアンチすればいいと思う。Rustで慣れてる人はRustで書けばいい。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/131
132: デフォルトの名無しさん [sage] 2022/05/21(土) 23:22:45.63 ID:zNzebGu9 C++が遅いってコンパイル時間の話ちゃうん http://mevius.5ch.net/test/read.cgi/tech/1509028624/132
133: デフォルトの名無しさん [sage] 2022/05/23(月) 00:46:57.32 ID:Fl/zPM6P なんでJavaやC#がスクリプト言語に入ってんだ? C#にはC#スクリプトがあるが実行時に中間言語にコンパイルするだけだろ http://mevius.5ch.net/test/read.cgi/tech/1509028624/133
134: デフォルトの名無しさん [sage] 2022/05/23(月) 00:55:18.95 ID:Fl/zPM6P 一度だけ必要なメモリを確保して使い回せるものを オブジェクトとして生成、消滅繰り返すようなプログラム組むと(普通にC++でかくとこっちになる)遅くなるよ 挙句の果てにメモリフラグメントが避けられない 普通にCで書くとよほどの馬鹿でも無い限り無駄なメモリ確保開放を繰り返すなんてことはしないから http://mevius.5ch.net/test/read.cgi/tech/1509028624/134
135: デフォルトの名無しさん [sage] 2022/05/23(月) 01:27:08.69 ID:aUQlcplw >>134 領域使い回せるってことは生成・解放するオブジェクトのサイズはだいたい一定なんだと思うけど そうだとしたら最近の普通のmalloc実装ならそうそうフラグメント起こすことはない気がするけどどうなんだろ ベンチマークとかあるの? http://mevius.5ch.net/test/read.cgi/tech/1509028624/135
136: デフォルトの名無しさん [sage] 2022/05/23(月) 01:35:14.45 ID:Fl/zPM6P >>135 行列クラス考えてみろ while(1) E = A*B+C/D C++なら一行でかけるが http://mevius.5ch.net/test/read.cgi/tech/1509028624/136
137: デフォルトの名無しさん [sage] 2022/05/23(月) 01:45:51.46 ID:Fl/zPM6P 誤送信 >>135 行列クラス考えてみろ while(1) E = A*B+C/D; C++なら一行でかけるがテンポラリ領域を演算子の多重定義の中で確保開放繰り返さざるをえない ETでなんとかなる部分もinverseがあるとそれもお手上げ 一時領域をwhileの外で確保してそれを使い回す方法と比べて早くしようがない。 http://mevius.5ch.net/test/read.cgi/tech/1509028624/137
138: デフォルトの名無しさん [sage] 2022/05/23(月) 01:48:39.79 ID:Fl/zPM6P >>135 >普通のmalloc実装ならそうそうフラグメント起こすことはない ヒープの動的確保でフラグメント興さないなら RTOSでメモリプール確保する必要なんてないよなww http://mevius.5ch.net/test/read.cgi/tech/1509028624/138
139: デフォルトの名無しさん [sage] 2022/05/23(月) 02:08:18.18 ID:aUQlcplw >>137 速度に関してはC++の方が不利なことに対しては異論ないよ ただフラグメントについては本当にそうなのか気になってた 今時のmallocなら直近にfreeされた領域再利用するから>>137みたいな例なら毎回同じ領域が割り当てられると思うよ 寿命が異なる複数のオブジェクトの確保・解放を繰り返すようなケースでも、オブジェクトが同サイズであればmalloc自体のフラグメントを防ぐ機構がうまく働いてくれるはず まあ確かにRTOSのmalloc実装では問題起こるかもしれないけどね ただ、そういうのは "最近の普通のmalloc" ではないと思う http://mevius.5ch.net/test/read.cgi/tech/1509028624/139
140: デフォルトの名無しさん [sage] 2022/05/23(月) 02:25:01.02 ID:Fl/zPM6P >>139 なんで同じ領域が確保されると保証されるのさ。今時のOSでww そのエリアが外のタスクで割り当てられなかったことがなんで保証できるんだ? とにかく動的確保、削除してフラグメント起こさないと思ってる方がどうかしてる。 そういう思い込みが通用するなら、所有権なんてもんは必要ないだろ。 あれはデフラグの対象にするかどうかが細大の目的 あと、普通のとか今時のとか、お前のあたのなかこっちは見られないんだから使うのやめろ http://mevius.5ch.net/test/read.cgi/tech/1509028624/140
141: デフォルトの名無しさん [sage] 2022/05/23(月) 02:44:22.59 ID:Fl/zPM6P >>137 >速度に関してはC++の方が不利 これもちょっと違うだろ 上で>>131が言ってるようにBetter cに留めて。 過度な見やすさや書きやすさを追求しなければ C++はC機能包含してるんでC++で不利になることなんてない。 機能を使わなければいいんで不利になりようがない。 Pure C流ででもかけるわけだし http://mevius.5ch.net/test/read.cgi/tech/1509028624/141
142: デフォルトの名無しさん [sage] 2022/05/23(月) 08:16:07.89 ID:aUQlcplw >>140 とりあえずglibcのmallocでいいや >>137のような解放直後に同じサイズで領域を確保する場合は領域再利用されるよね http://mevius.5ch.net/test/read.cgi/tech/1509028624/142
143: デフォルトの名無しさん [sage] 2022/05/23(月) 09:11:41.94 ID:n2ZPTBPD // ヒープを使う型Testを作って実証実験 #[derive(Debug)] struct Test(Box<isize>); // Test型が作成される時に使われるnew()を実装 impl Test { fn new(n: isize) -> Self { let new = Test(Box::new(n)); // その時にヒープで確保されたアドレスを表示 println!("{:p} = Test::new({n})", new.0); new } } // Test型の足し算を実装 impl std::ops::Add for Test { type Output = Self; fn add(self, rhs: Self) -> Self::Output { Test::new(*self.0 + *rhs.0) } } // 足し算の途中で使われる一時領域のアドレスはどうなるか? fn main() { let a = Test::new(1); let b = Test::new(10); let c = Test::new(100); let d = Test::new(1000); let e = Test::new(10000); println!("{:?}", a + b + c + d + e); } http://mevius.5ch.net/test/read.cgi/tech/1509028624/143
144: デフォルトの名無しさん [sage] 2022/05/23(月) 09:17:13.61 ID:n2ZPTBPD 実行結果 0x55790623d9d0 = Test::new(1) 0x55790623d9f0 = Test::new(10) 0x55790623da10 = Test::new(100) 0x55790623da30 = Test::new(1000) 0x55790623da50 = Test::new(10000) 0x55790623da70 = Test::new(11) 0x55790623d9d0 = Test::new(111) 0x55790623da70 = Test::new(1111) 0x55790623d9d0 = Test::new(11111) Test(11111) つまり足し算で中間生成される一時的な領域は再利用されて使い回されていることが確認された したがって>>140の主張がおかしい http://mevius.5ch.net/test/read.cgi/tech/1509028624/144
145: デフォルトの名無しさん [sage] 2022/05/23(月) 09:54:21.07 ID:n2ZPTBPD 一般的に、今回のような多段の計算の場合は、中間領域が少なくとも2つ必要となる なぜなら、一般的には「中間値2=中間値1+次の項目」と順に計算していくためである つまり一般的な場合は、5つの変数の足し算ならば、中間値2つを加えて、計7つの領域を必要とする しかし>>144の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目 5つの変数の領域は避けられないから、余分に確保されたのは1つのみで済んでいる これがRust 今回用意したTest型はCopyを実装しなかったため、最初の「中間値1=a+b」を計算した時点てaとbは消費されてそれらの領域は解放される そのため次の「中間値2=中間値1+c」の時に、中間値2の領域として既に解放されたaの領域が使われた 実際に中間値2のアドレスがaと同じになっていることで確認できる 同様に中間値3は中間値1と同じアドレスとなっている 結論 Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため、 >>137のようなケースでも最小限のメモリしか必要とせずに済む http://mevius.5ch.net/test/read.cgi/tech/1509028624/145
146: デフォルトの名無しさん [sage] 2022/05/23(月) 11:54:34.12 ID:n+tkR/ue glibc mallocの仕様なのでCやC++でも同じです http://mevius.5ch.net/test/read.cgi/tech/1509028624/146
147: デフォルトの名無しさん [sage] 2022/05/23(月) 14:37:05.11 ID:GiQn/B1E Rubyを長期間動かすとGCがメモリを 細分化してしまうという話かなんかと 混同してんのかな http://mevius.5ch.net/test/read.cgi/tech/1509028624/147
メモ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 55 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.010s