23/02/25 09:49:46.74 VRyB88xR.net
C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな？
2:デフォルトの名無しさん
23/02/25 11:00:27.52 9NhnUjd2.net
いうほどでもない
3:デフォルトの名無しさん
23/02/25 13:27:35.74 P9AUzv0x.net
うだうだ言ってないで仕事で必要なのをやればいいんだよ
趣味なら好きなのやればいい
4:デフォルトの名無しさん
23/02/25 13:38:44.05 QyjTyTMe.net
>>3
そうなんだけど、今後の流れが気になったので
5:デフォルトの名無しさん
23/02/25 17:13:51.27 lt8vujMQ.net
もう10年ぐらい前ぐらいからここはじめネット、SNSで
何か急にある言語をプッシュして他を異様にディスるムーブメントある場合
それは情報商材売りたい勢のゴリ押しってのが判明してる
そんなものに右往左往してたら話にならんよ
6:547
23/02/25 18:15:55.88 VqXFnbZE.net
>>5
どの言語がプッシュされたんですか？
7:デフォルトの名無しさん
23/02/25 20:03:19.10 bUASXHz9.net
c -> c++ のが自然に学べるってのはあるけど、c++の余計な仕様を覚えるのもどうかなってのはある。
rustからいきなり入る奴が本当に理解できるのか正直わからん。
8:デフォルトの名無しさん
23/02/26 08:44:07.54 NKFFZ0EI.net
rusty nail
9:デフォルトの名無しさん
23/02/26 10:30:55.37 W2bio7pu.net
結論から言うと
少しずつRust縛り(必須)となっていく
C/C++だと気付かないうっかりミスが紛れ込んでセキュリティにも影響してきた確固たる暗い実績が様々なソフトウェアにある
Rustはコンパイル時点でエラーや警告として示し防止する
この差を非常に大きくそしてそれを満たすのは現状Rustしか現実的な選択肢がなく代替候補もない
Rustを書ける人員を揃えることができたところから既に移行は少しずつ始まっており着実に進んでいる
市場的にも公的にもRust製とC/C++製どちらがセキュリティ含めて信頼できるか明確なためいずれは必須指定要件となるだろう
10:デフォルトの名無しさん
23/02/26 11:58:18.24 R0VbvaR9.net
>>9
詳しい説明ありがとうございます。
少しずつRustも勉強していこうと思いました。
11:デフォルトの名無しさん
23/02/26 13:02:29.94 E7NCL2qF.net
>>6
Rust,Python,UnrealEngine
12:デフォルトの名無しさん
23/02/26 14:38:46.87 0HNO0Bah.net
しゃぶれよ
13:デフォルトの名無しさん
23/02/26 16:48:37.69 M2zxuPcR.net
とりあえずC/C++は小さなワンチップマイコンからスパコン富岳、そしてハードウェアの高位合成まで使える共通言語になってるから、使えれば利用できる範囲が広いかな？
オブジェクト指向が求められてCからC++が出てきたように、C/C++の構文スタイルをとりながらメモリ安全を実装したものが出てくるかもね。
学習コストとしても文法的に新規性が少ない方が好まれるだろうし。
14:デフォルトの名無しさん
23/02/26 17:26:20.61 32xuZUXu.net
>>13
C/C++系言語の可能性を試みる時間は既に終わった
ここ10年間でC/C++拡張やその系統では無理だと結論が出たためGAFAMなどIT大手がこぞってRustへ舵をきった
15:デフォルトの名無しさん
23/02/26 20:14:35.53 DFLJCTJ6.net
Rust案件なんかないやろw
時期尚早
16:デフォルトの名無しさん
23/02/26 21:44:33.99 GQhuf+Lw.net
アーリーアダプタ(?)的な人って、新しいものが出てきたときに良い面ばかりを
見てしまう癖が有るらしい。それでしばらくして別のものが出てくると絶賛し、
前のものを批判に変える。
17:デフォルトの名無しさん
23/02/26 22:00:08.16 32xuZUXu.net
大昔のRustはそうだったが実績を積み重ねて今はIT大手どこもが採用する言語となった
世界中のインフラが次々とRust製へ変わりつつある
例えばAWSなどのクラウドもそう
18:デフォルトの名無しさん
23/02/26 22:11:58.45 GQhuf+Lw.net
企業の中の一部で使われてきたというだけであって、言語そのものを良く見てみると
そこまですばらしい言語ではないと思えるぞ。
19:デフォルトの名無しさん
23/02/27 01:07:20.97 uT3J6RSV.net
>>17
嘘つけ
20:デフォルトの名無しさん
23/02/27 01:48:26.87 O9/5cYsg.net
>>19
URLﾘﾝｸ(japan.zdnet.com)
Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、Rust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。
AWSのソフトウェアエンジニアで、Rustの普及に取り組む
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。
Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。
「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
21:デフォルトの名無しさん
23/02/27 13:40:42.65 csXgFZ4x.net
rusty nail
22:デフォルトの名無しさん
23/02/27 16:14:37.34 dFRgN5US.net
>>20
それでどれくらいがRustで書かれているのかな？
23:デフォルトの名無しさん
23/02/27 16:27:08.91 NzhKA4cT.net
>>20
>CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
実に疑わしい。
Cは高級アセンブラ。
基本的に効率がよいプログラムがエネルギー効率も良いはずで、だとしたら、
高級アセンブラより効率がよい言語が存在しないといけないことになるが、
あらゆる言語が高級アセンブラを越えることは不可能であるはずなので、
矛盾しているように思える。
24:デフォルトの名無しさん
23/02/27 16:30:03.92 NzhKA4cT.net
>>23
[補足]
手書きアセンブラだと超えることが出来る場合が有る。
C言語レベルで最も良いアルゴリズムで書いた場合、最終的にはコンパイラの
バックエンドの最適化次第ということになる。
そしてバックエンドは Rustもclang(C)も同じLLVMのものを使っているので、
Rustがclang(C)が到達できないように効率がよくなる可能性は数学的に
有りえないはず。
Rustでできるなら、Cでも出来るはずだからだ。
25:デフォルトの名無しさん
23/02/27 17:32:52.43 NzhKA4cT.net
>>24
[補足2]
C言語は、ノイマン型コンピュータでできる限りどんなアルゴリズムでも
使えて、使えるアルゴリズムに制限が無い。
だから、発見されている中での世界最良のアルゴリズムを使うことができる。
そしてその場合に、世界最速になれない可能性があるとしたら、
バックエンドの最適化層の最適化の能力が人間の手作業の最適化に劣る
ような場合だけである。
それに対してRustがCを速度で上回るというのは数学的に矛盾している。
むしろ、Rustのsafeモードでは、使えるアルゴリズムに強い制限が掛かっている。
26:デフォルトの名無しさん
23/02/27 17:55:34.32 jgoAw3Ga.net
>>24
もちろんRustとCと全く同様の低レベル記述もできるしCと同様にインラインアセンブラが書けてRust変数との連携もできるしそれらを安全に閉じ込めることができる
一方でRustはプログラム全体の安全性を大域的にコンパイラが保証することが出来るため仮に局所的にunsafeな部分かあっても人間はそこだけに注力できる点でCとは異なり決定的で革新的な変化をもたらした
そしてRustとCが他のプログラミング言語と決定的に異なるのはガベージコレクション(GC)無しで動きプログラミング言語の中で最も高速であり電力消費面でもCPUメモリリソース面でも最も有利な言語である
27:デフォルトの名無しさん
23/02/27 18:16:27.45 NzhKA4cT.net
>>26
>安全に閉じ込めることができる
Rustでは、これは不可能なケースが有ることが分かってる。
28:デフォルトの名無しさん
23/02/27 18:17:38.69 NzhKA4cT.net
Rustでそういうことができるのは、一部のアルゴリズムだけで、閉じ込めきれない
アルゴリズムが存在することがいくつも知られている。
29:デフォルトの名無しさん
23/02/27 18:31:59.25 BUZw0Bcx.net
>>27 >>28
プログラム全体に非安全が散らばっているアルゴリズムを考えることは可能だがバカな行為
非安全な部分を局所的に閉じ込めて安全なインターフェイスを公開するライブラリを作るのが正しい道
そうすればRustはプログラム全体の安全性を規模に関わりなく保証することができるためGAFAMなど大手ITを筆頭にその方法へと次々に切り替え始めた
30:デフォルトの名無しさん
23/02/27 18:36:09.13 NzhKA4cT.net
>>29
ですから、そのように閉じ込めることが絶対に出来ないアルゴリズムが存在しているのです。
31:デフォルトの名無しさん
23/02/27 18:36:32.74 NzhKA4cT.net
これは数学の問題です。
32:デフォルトの名無しさん
23/02/27 22:09:41.53 LP8T7WNZ.net
Rustの安全性って言語を乗り換える際に払うコストほど
大きなメリットはないのでね
Rustは使う人も少ないし仕事も全くない
CのUNIXやC++のMFCのようなものがないと
Rustをやろうという人は増えないだろう
33:デフォルトの名無しさん
23/02/27 22:13:22.96 3K/qRK7o.net
結局どっちも使えるくらいのやつじゃないとどっちにしろまともな仕事にはならん。
どっちかだけと言ってるやつは仕事になってないやつだろ。
34:デフォルトの名無しさん
23/02/27 22:37:20.68 KG8RKFb2.net
両方使いこなせるようになると一目瞭然で
Rustは洗練されていてモダンな便利な機能も含めて開発効率も良い
もちろん安全性の保証なども付いてくるため比較するとRustが大差で有利
唯一の問題はまだRustを使える人が少ないこと
しかし着実にRustも使える人が増えていってるため
人数を揃えられたところからRustを使うところがどんどん増えている
この流れは逆になりようがない
35:デフォルトの名無しさん
23/02/27 23:35:53.90 LP8T7WNZ.net
Rustの仕事なんてないんだが?
36:デフォルトの名無しさん
23/02/27 23:38:16.05 LP8T7WNZ.net
最近だとpythonユーザがAIの流行で増えたように
Rustも牽引する何かがないと増えることはないよ
37:デフォルトの名無しさん
23/02/28 00:08:33.64 pH6hfy6B.net
Cじゃないとダメだと長年C++を拒絶していたLinuxもRustの導入を始めた
Google ChromeやMicrosoft Edgeで使っているChromiumもC++での多発するセキュリティ問題に耐えかねてRust採用を発表した
クラウドTOPのAmazonも>>20の記事にあるようにインフラをRust製にしている
Meta(旧Facebook)もRust製の基幹システムに変えたとの記事が出ている
この世界的な動きは日本でも少しずつ進み始めている
38:デフォルトの名無しさん
23/02/28 11:57:56.87 xNmaYcy8.net
>>18
>>33
ほんそれ
C/C++ 使えるがどうしても Rust 嫌いって人は
Nim を使うと幸せになれる
39:デフォルトの名無しさん
23/02/28 14:09:00.41 e51yPnPZ.net
>>37
>Cじゃないとダメだと長年C++を拒絶していたLinuxもRustの導入を始めた
$ wget 'URLﾘﾝｸ(cdn.kernel.org)'
$ tar xJf linux-6.2.1.tar.xz
$ find linux-6.2.1 -name *.c | wc -l
32329
$ find linux-6.2.1 -name *.rs | wc -l
37
37ファイルもある!
最後の | wc -l を取るとRustが何に用いられているか分かるよ!
いずれにしても>>37が列挙しているように
現状ではRustにキラープロダクトは無いので
増えることはないと断言できる
40:デフォルトの名無しさん
23/02/28 15:53:29.33 5HrxdEqK.net
>>36 >>38
Rust嫌いは無知が多いな
NimもPythonもGCのあるプログラミング言語であり代替になれない
超遅いPythonは論外としても
NimはNull安全すらなくC/C++と同様に安全性を保証できない言語
41:デフォルトの名無しさん
23/02/28 16:39:39.54 eD9OZA2Z.net
rusty mail
42:デフォルトの名無しさん
23/02/28 17:12:23.08 e51yPnPZ.net
>>40
無知はお前さんじゃないかな?
都合の良い記事ばっかり検索して貼っとらんで
>>39のようにソースを見なさい
43:デフォルトの名無しさん
23/02/28 18:20:57.50 Owe2yvkD.net
Linux Kernel 6.1はRustyというコード名前だしRust宣言だね
URLﾘﾝｸ(codezine.jp)
> Linus Torvalds氏は、Linux OSのカーネルの最新バージョンである「バージョン6.1」を公開したと2022年12月11日に明らかにした。
> バージョン6.1は、カーネルの記述にRust言語を一部使用した最初のバージョンとなる。
> 従来、LinuxカーネルはC言語とアセンブリ言語で記述していたことから、Rustの採用は大きな変化と言える。
44:デフォルトの名無しさん
23/02/28 18:25:06.29 ilYsCf2n.net
>>43
プログラマならソースコードをみなよw
45:デフォルトの名無しさん
23/02/28 21:39:14.49 y7e/yQA5.net
>>43
C++は中途半端でクソなことがLinux界でも結論出たのは大きいな
人間チェックで安全を保証するCか
コンパイラによるチェックで安全を保証するRustか、どちらかしかないな
46:デフォルトの名無しさん
23/02/28 21:43:01.23 e51yPnPZ.net
LinuxカーネルにC++が使われたことはない
47:デフォルトの名無しさん
23/02/28 21:46:42.30 e51yPnPZ.net
ところRustってllvmだと思うけどRustでドライバ書きたい場合は
カーネルはclangでビルドするのかな?
gccとバイナリ互換じゃなかったような気がするんだけども?
というかカーネルってclangでビルドできるようになったのかな?
48:デフォルトの名無しさん
23/02/28 21:47:06.07 y7e/yQA5.net
>>46
そのことだよ
C++は中途半端でクソだから使う意義がないので採用しないとLinux界からも却下されていた
ところがRustは意義があるとして採用された
49:デフォルトの名無しさん
23/02/28 21:48:12.02 e51yPnPZ.net
>>48
全く違う
50:デフォルトの名無しさん
23/02/28 21:54:59.06 e51yPnPZ.net
37 / (37 + 32329) = 0.0011431749366619293
00.11% だからな...
プログラムの隆盛を見るとCにおけるUNIX
C++におけるMFC
PythonにおけるAIのようなキラープロダクトが出て
コードを書ける人が増えないと
メモリ安全ごときでRustが流行ることはあり得ない
51:デフォルトの名無しさん
23/03/01 02:20:06.43 Mc7FdiYo.net
>>18
Rustを本格的に始めたら言語仕様が秀逸だと分かった
これまでの言語の既成の固定観念に引きずられてるうちは分からなかったことが見えてきた
52:デフォルトの名無しさん
23/03/01 03:16:12.01 1Oup3Ez2.net
仕事でCを使ってきた
Pythonは苦労せず使えるようになった
でもrustは無理くさい
書き方が違いすぎるのと脳が老化して覚えられないw
53:デフォルトの名無しさん
23/03/01 04:54:30.39 HcVT2tre.net
>>52
モダンな言語なんでもいいけど
何らか抽象的なプログラミングをサポートしている言語でそういう保守性の高い書き方したことがない場合
どの言語でもまずは抽象的なプログラミングに慣れて習得しないままだと
仮に長年プログラミングやってきたとしても初心者止まりのままになっちゃうのでどこかへ進むとよいかも
CやってきたのならばRustはあとその部分を習得するだけだね
54:デフォルトの名無しさん
23/03/01 08:01:08.42 82Husj9h.net
>>52
C/C++のリプレースで使われることで騒ぐしかないんじゃ、できること自体はCと変わらないってことだしね。
小規模なプログラムだと一番のウリのメモリ安全も利益感じられないし。
制御関係とかでC++のClassや継承とかは部品の組み合わせと対応させられて便利だったけど、Rustでは継承はバッサリ切り捨てちゃったみたいだしなあ。
そういえば、脳科学者が言うには脳は老化しない、何歳になっても海馬は大きくなるらしいよ。
自分はChatGPTで掛け合い漫才しながらチュートリアル眺めてるけど、以前三日坊主だった時の壁は越えられた気がする。
55:デフォルトの名無しさん
23/03/01 10:16:16.06 BrtIIoCo.net
>>51
C#のほうが言語仕様秀逸だよ
56:デフォルトの名無しさん
23/03/01 10:16:52.64 BrtIIoCo.net
正直クラス無いと頭こんがらがってダメだわ
57:デフォルトの名無しさん
23/03/01 10:20:08.76 68s28u+f.net
>>45
なんで二択なんだよ
Nimがあるじゃないか
58:デフォルトの名無しさん
23/03/01 10:23:04.35 BrtIIoCo.net
Rustってドライバとかにも使えるの？
組み込みで使われてる？
59:デフォルトの名無しさん
23/03/01 10:24:39.92 68s28u+f.net
>>52
脳の老化じゃなくて過学習が始まった年頃なんじゃね
60:デフォルトの名無しさん
23/03/01 10:35:28.60 jxeZ0t7/.net
GoogleのCarbonが完成したら覇権とりそう
あとはZigとかはどうなんだ
61:デフォルトの名無しさん
23/03/01 10:39:50.76 NalgN/NX.net
Rustは継承じゃなくて合成みたいだけど、そもそも継承ってそんなに危険だったっけ？
62:デフォルトの名無しさん
23/03/01 10:41:08.58 jxeZ0t7/.net
>>57
上でも言われてたけどNimでGC無効メモリ手動管理でやったらどれくらい使い物になるんだってのは気になる
まあふつうNimならもうメモリ管理せずにORCでやるだろうけど
63:デフォルトの名無しさん
23/03/01 17:09:50.12 FMM19mI8.net
>>55 >>57
C#もNimもGCが基本の言語
このスレに持ち出すのは場違い
>>60
Carbonは公式ページに「Rustを使える状況ならばRustを使った方が良い」と明記されてる位置付けの言語
CarbonはC++記述遺産のメンテ用が目的
Zigは手動でメモリ解放する言語
Rustは自動でメモリ解放する言語
そしてRustではメモリ安全性がコンパイル通れば保証される信頼性が大きな差
64:デフォルトの名無しさん
23/03/01 17:19:17.03 FMM19mI8.net
>>58
もちろんRustはC言語と同じく低レベル記述も可能
必要ならばインラインアセンブリもサポートしておりRustの変数を使ってその場でasm挿入記述もできる
組み込みもRustのメインターゲットの一つ
URLﾘﾝｸ(www.rust-lang.org)
65:デフォルトの名無しさん
23/03/01 23:46:27.72 YuYxAjXZ.net
>>63
>C#もNimもGCが基本の言語
>このスレに持ち出すのは場違い
ここはどういう場なんでしょうか?www
66:デフォルトの名無しさん
23/03/01 23:58:04.67 Faf+SNlo.net
>>65
スレタイ見ればわかるようにガベージコレクション使う遅い言語は対象外だと思うよ
67:デフォルトの名無しさん
23/03/02 00:15:37.04 4/ee2SHc.net
>>66
>スレタイ見ればわかるように
飛躍し過ぎていて「結局C++とRustってどっちが良いの？」で
GC使う言語がスレの対象外になるのがサッパリわからん
68:デフォルトの名無しさん
23/03/02 02:30:04.05 bqXvu2FA.net
より良いものを否定し
伝統ばかりに固執する人らに
過去の栄華はあっても
未来など無い
69:デフォルトの名無しさん
23/03/02 05:01:47.34 s9foVenT.net
>>67
プログラミング言語は大きく2つに分かれていて
GCのある遅くてメモリ消費も多い言語と
GCのない速くてメモリ消費も少ない言語に分かれる
そこには決定的な違いがある
次にスレタイというのはいちいち説明しなくても
例えば「Vue vs React vs Angular vs Svelte Part.11」というスレはそれら比較対象からJavaScriptフロントフレームワークのスレだと分かる
そしてここはスレタイが非GC言語の既存代表例C++と非GC言語の新興代表例Rustの比較的となっているから
基本的にその両者が対象でおまけとしても同じ非GC言語のCやZigなどが対象ギリギリかなと思う
70:デフォルトの名無しさん
23/03/02 05:13:35.95 MiifFeAk.net
いい加減にほんに何言ってんだこのバカ
71:デフォルトの名無しさん
23/03/02 05:44:38.60 6fagNnHa.net
Cと名前が似てるだけで狭い範囲でしか役に立たないC#の話をされてもそりゃ困るわな
最低限ガベージコレクション無しと低レベル記述可を備えた最高速クラス言語じゃないと比較の土俵にも上がらんわ
72:デフォルトの名無しさん
23/03/02 06:35:13.17 M8IdVdds.net
一言で言えば、リアルタイム性を要求されるアプリケーションでも使える言語ってことだね。
73:デフォルトの名無しさん
23/03/02 07:12:21.96 ZOdXc5Gl.net
>>67
猫と犬とどっち飼ったらいいかな？
の質問に「金魚が良いよ」と回答しても意味ないだろ
74:デフォルトの名無しさん
23/03/02 07:14:53.01 D5BhE+0S.net
書こうと思えばどの分野でも書くことができるプログラミング言語だね
例えばC#やPythonではまともなOSを作ることができない
GoogleがRustで書かれたセキュアなOS「KataOS」を発表
URLﾘﾝｸ(japan.zdnet.com)
75:デフォルトの名無しさん
23/03/02 11:41:51.38 v0ZnzcWP.net
>>72
高い性能や高い応答性くらいの意味でリアルタイム性という用語を使ってるのかもしれないけど意味違うからね
76:デフォルトの名無しさん
23/03/02 12:13:29.31 4/ee2SHc.net
>>69,74
そういうのは飛躍と言う
お前が>>1でそのつもりでこのスレを立てたのならスレタイは不適切
77:デフォルトの名無しさん
23/03/02 12:17:03.65 4/ee2SHc.net
>>72
「リアルタイム性」も知らんようだし
お前はRustについてGCのあるなしくらいしか語れないのかな?
ちなみにこの板読んでる人でGCを分からん人はほぼいないと思う
78:デフォルトの名無しさん
23/03/02 12:57:49.07 D5BhE+0S.net
そういうアホ相手にしか反論できない時点で辛そう
最近は新たなものが出てくるとRust製
Webpackの後継となる新バンドルツール「Turbopack」が登場。Rust製のネイティブアプリケーションでWebpackの700倍高速に！
URLﾘﾝｸ(www.publickey1.jp)
79:デフォルトの名無しさん
23/03/02 13:19:48.65 2W3DfR3d.net
>>1です。色々と混乱させてしまってすみません。
C++で今まで作られてきたものがどれだけRustに変わっていくのか気になってスレ立てしました。
メモリ安全性という観点だとRustになりますが、C++にはRustより優れている点があって、今後もまだ残り続けるのかどうかです。
80:デフォルトの名無しさん
23/03/02 13:47:49.79 9x7ptNRV.net
VB6やCOBOLみたいに進化を止めたゴミにならない限りはC++も残り続けるでしょう
今のところC++がそういったゴミになる兆候は無いと思います
Rustが優れているかどうかは一切関係がありませんね
81:デフォルトの名無しさん
23/03/02 13:48:50.41 BxgVYWtl.net
C++は残り続けるけど徐々にメインストリームはRustかそれと同等のメモリ安全性を備えた言語に移っていく
既存のコードベースが大きいから急激には変化しない
残る理由はCOBOLが残っているのと同じで優れてるという理由からではない
82:デフォルトの名無しさん
23/03/02 14:11:06.82 4/ee2SHc.net
試しにChatGPT先生にRustにキラーアプリがあるか聞いたらSolanaやRayonだって
>SolanaやRayonがUNIXやMFCのようにプログラミング言語を新たに習得しようと
>する人を爆発的に増やすことは、現時点では考えにくいと言えます。
>UNIXやMFCが広く普及した理由の一つは、それらが当時の主流であったプラッ
>トフォームやアプリケーションの開発に必要不可欠であったためです。一方、
>SolanaやRayonは、それぞれ特定の分野において高いパフォーマンスを発揮す
>るためのライブラリやプラットフォームであり、必ずしも全ての開発プロジェ
>クトに必要不可欠なものではありません。
>また、Rust自体がまだ比較的新しい言語であるため、多くのプログラマがRust
>を習得する必要性を感じているわけではありません。ただし、Rustの安全性や
>パフォーマンスが注目されるにつれ、より多くのプログラマがRustに興味を持
>ち、学習する可能性はあります。
>つまり、SolanaやRayonがプログラミング言語を新たに習得しようとする人を
>爆発的に増やすことに貢献するかどうかは、それらが必要不可欠なライブラリ
>やプラットフォームとして広く普及するかどうかにかかっていると言えます。
83:デフォルトの名無しさん
23/03/02 14:16:45.49 4/ee2SHc.net
例えばRustで書かれたOSをAndroidやiOSの後継にするとか
携帯に匹敵する新たな情報端末が出現して
それがRustで制御されているとか
84:デフォルトの名無しさん
23/03/02 14:23:37.36 N97puPhx.net
質問がバカだと回答もバカになるいい例
ググり力と同じくジピり力が求められる
85:デフォルトの名無しさん
23/03/02 14:36:25.48 4/ee2SHc.net
「ジピり力」かぁw 大事だね
SolanaやRayonが返ってきた質問は以下
>あるプログラミング言語が流行るにはC言語におけるUNIXやC++のMFC、最近だ
>とpythonがAIによって流行ったようにキラープロダクトが重要だと思います。
>キラープロダクトがあれば、その言語を習得したプログラマが一気に増えます。
>Rustにそのようなキラープロダクトはありますか？
Rustの爆発的普及にはキラープロダクトが不可欠
86:デフォルトの名無しさん
23/03/02 14:38:15.81 D5BhE+0S.net
>>79
C++は今も違法増改築を続けて無数に部屋(仕様)が作られていくような言語
そして新たな増改築が決まっても、完成(実装)されなかったり、新たな部屋の存在が知られていなかったり、ほとんどの部屋は極一部の人しか使われていない
結果的に良い機能があっても使われないのは無駄に大きく重複もある複雑な言語仕様のせい
例えばC++20で導入されたstd::rangesはRustでいうとIteratorなどの基本的なデータ取り扱い機能で超重要だが今後も広まらないのだろう
歴史的な事情でC++の全容は複雑怪奇となっていて理念の一貫性もなくどうしようもない状態
Rustは洗練された言語仕様となっていてC++と比べれべるとシンプルで分かりやすい
全体の理念も統一されており特に安全性に関する保証が与える信頼性はこのセキュリティ重視の時代に完全にマッチしている
今後Rust人口が増えてくると企業案件でC/C++が使われてきたものはRust指定(必須)となっていくだろう
87:デフォルトの名無しさん
23/03/02 14:45:55.72 4/ee2SHc.net
>>86
普及して長いことたてばRustもご多分に漏れずいずれ複雑怪奇になるってw
若いと分からんかもしれんが
C++は複雑怪奇に見えるかもしれんが規格変更には慎重の方だと思うよ
ところでRustって規格あるの? 仕様しかない?
88:デフォルトの名無しさん
23/03/02 15:24:09.80 4/ee2SHc.net
実装が1つしかないから規格はないかな
89:デフォルトの名無しさん
23/03/02 15:30:29.97 o+lCraYI.net
C++もスマートポインタでメモリ安全を取り込んできているけどね。なんでも飲み込む奴だからなあ。
90:デフォルトの名無しさん
23/03/02 15:41:34.24 4/ee2SHc.net
例えばstd::shared_ptr相当のものは
90年代中盤から後半にかけて使われ始めたと思うけど
（boost::shared_ptrはいつからだっけ？）
std::shared_ptrが規格に入ったのはC++11
規格の拡張は無節操というより慎重というかクソ遅いよ
91:デフォルトの名無しさん
23/03/02 15:59:19.04 dC3Ayx4m.net
>>86
Javaが出た時に聴いたことあるような文句だな
割とマジでフラッシュバック
92:デフォルトの名無しさん
23/03/02 16:08:40.39 eS6QMQkY.net
>>79
それは分類が非常に簡単
既に作られており穴も発見されないものをわざわざRustに移植する意味はない
穴が多く悩まされてるものはChromiumのようにRust併用やRustへ切り替えが進んでいる
新たに作ったり大きく作り直す場合はRust一択
93:デフォルトの名無しさん
23/03/02 16:24:01.58 eS6QMQkY.net
>>89
C++はスマートポインタがあっても言語システムとして安全を保証する枠組みがない
まともなIT企業からRustへ移動し始めている根本的な理由がそこ
94:デフォルトの名無しさん
23/03/02 16:40:50.78 4/ee2SHc.net
>>93
Rustプログラマを支障なく確保できなければ企業は
試験的採用こそすれど本格採用はしない
Rustプログラマが多い -> Rust生態圏が良くなる ->
Rustプログラマが増える -> （最初に戻る）
※Rust生態圏が良くなるとはライブラリやtipsが増えRustの仕事が増えること
この好循環を作らないことにはRustが流行りだすことはないだろう
そのためのキラーコンテンツ
>>37で上げてるようなソフトはしょぼすぎて該当しない
>>83くらいの状況になれば変わる
95:デフォルトの名無しさん
23/03/02 16:53:27.06 eS6QMQkY.net
Rust自体がプログラミング言語史上でも革新的なキラーコンテンツ
まともなIT企業からRustを導入していっている理由がそこにある
非GC言語でメモリ安全性を言語システムが保証する初で唯一のプログラミング言語がRust
96:デフォルトの名無しさん
23/03/02 17:10:59.88 oc1UgWLG.net
ダメダコリャ
97:デフォルトの名無しさん
23/03/02 18:47:07.82 9x7ptNRV.net
なんだかんだで置き換えられずにユーザ空間ソフトの基礎ライブラリになってるC言語の奴らすげーよな
98:デフォルトの名無しさん
23/03/02 19:04:35.27 o+lCraYI.net
とりあえずC/C++は今ところほぼ全てのCPUで環境が整備されているし、
メーカーさんのサンプルにしても、過去の資産も（FreeRTOSだのもArduinoなんかも）膨大。
それらが全て使われなくなったり、他の言語でで書き換えられるということが仮に
にあるとしても相当先の話になるだろう。
と考えると、C/C++はほぼ基礎教養かな？
あとは実務で要求されたものを身につけるっていう感じなんだろうな。
パラパラ眺めた範囲ではRustもC++知っていればさほど難しくなさそうだけど
個人で趣味レベルでやってますといっても、実務経験ないとキャリアとしてのアピール度は低いしな
99:デフォルトの名無しさん
23/03/02 19:14:16.94 OHJUJNoL.net
>>98
Cの基礎は必要だがC++は要らん
特殊な組み込み環境などでない通常利用ならば対応していてRustが使える
100:デフォルトの名無しさん
23/03/02 19:20:18.08 OAWE1K4h.net
でもお前組み込みエアプじゃん
101:デフォルトの名無しさん
23/03/02 19:22:55.17 OAWE1K4h.net
ルビキチも自分の実績とは関係なく人工衛星がどうのと褒めそやす奴だった
これもいずれはあのような壊れたレコードに成り果てるのだろう
102:デフォルトの名無しさん
23/03/02 19:42:00.55 +4hIkzuc.net
Firefoxだけかと思っていたらChromeもRustなのかよ
Google Chrome、プログラミング言語「Rust」の採用を発表
URLﾘﾝｸ(news.mynavi.jp)
103:デフォルトの名無しさん
23/03/02 23:06:33.64 4/ee2SHc.net
>>102
それでRustプログラマが増えることはないな
>>83くらいの状況にならんと
104:デフォルトの名無しさん
23/03/03 06:56:09.99 3EPD3050.net
>>99
その「特殊な組み込み環境」とやらでもC/C++は使えるからね。
C++はフルには要らんかもだけど、
クラスと継承は組み込みとかでも便利に使われてたりするね。
できることが大差ないとすると、仕事でRustを使えと言われない限り、個人レベルで積極的に使う理由に乏しいかなぁ。
個人でメンテできる程度だとメモリ安全ってそれほど重要ポイントではないし。
PythonにとってのAIみたいに、こういうアプリケーションなら、C/C++より遥かに楽で簡単に実現できるというものが必要なのではないかな。
今の段階じゃ、メモリ安全にするために制約やチェックを厳しくしたC/C++ってだけって感じだもの。
105:デフォルトの名無しさん
23/03/03 07:13:09.62 5+VE8dsn.net
Rustは後発なアドバンテージで
洗練されたモダンな言語仕様のため非常に書きやすい
これが一番大きなメリット
おまけとしてメモリ安全性の自動保証とデータ競合なしの保証
これらにおかげでC/C++で書いてた時に無駄に必要だった実行時デバッグが激減して消えた
Rustは開発効率が大きく向上する
106:デフォルトの名無しさん
23/03/03 09:31:41.76 oC7cFOXy.net
>>95
Dが出た時に聴いたことあるような文句だな
割とマジでフラッシュバック
107:デフォルトの名無しさん
23/03/03 13:09:51.97 t7eEMnCD.net
>>106
どこが似てんだよ何も区別付かないアフォ
108:デフォルトの名無しさん
23/03/03 13:21:04.67 mNTxopBi.net
おちんちんランドへおいでよ！
109:デフォルトの名無しさん
23/03/03 13:21:58.74 PdMH/ctM.net
altJSブームが落ち着いたせいで下火になっちゃったけど
やっぱりHaxeは復活すべきだよな
110:デフォルトの名無しさん
23/03/03 13:26:08.63 HbtHbRsb.net
>>107
凄い似てるよ
Javaが出たときにも聞いたぞ
「C/C++を置換する！」は人間の性なんだろうw
長くやってると何度も見るし結果もだいたい分かる
111:デフォルトの名無しさん
23/03/03 16:49:35.55 lJwnZSPr.net
>>110
しかも、Javaの普及速度は物凄く速かったが、Rustは伸びてない。
112:デフォルトの名無しさん
23/03/03 19:36:46.54 NsCHD7Iu.net
>>91 >>110
プログラミング言語の一般的な基礎知識を持たない人がRustのアンチをやっているのかしら
JavaがCやC++に置き換わらなかった理由の一つはJavaがガベージコレクション必須の言語だからですよ
CやC++の置き換えとなるためにはGCを必要としないプログラミング言語でないとダメなんですよ
GCを必要としない言語も数少ないながら今までいくつか出て来たのになぜCやC++を置き換えられなかったか分かりますか？
CやC++で問題となってきたのはメモリ操作の安全性とデータ競合の安全性です
それらを完璧に対応して言語自体が安全性を保証する言語が今までなかったからですよ
Rustが初めて対応して初めて真にCやC++を置き換えられるようになりました
だからIT大手各社がライバル関係を超えて共同してRustを支援そして採用しているのですよ
113:デフォルトの名無しさん
23/03/03 20:45:25.65 56kfvkVg.net
>>112
>>77
お前はそればっかりだなw
そんなものはこの板の住人が知らん訳ないやろw
GCくらいしか語る知識がないんだろうな
114:デフォルトの名無しさん
23/03/03 21:06:34.40 NsCHD7Iu.net
>>113
その>>77を見てみましたがリアルタイム性の話ですか
それは直接はプログラミング言語とは関係ない話ですが少し関係がありますね
言語に関わらず作成したシステム側の話でOSからゲームのようなアプリまで必要とされる時間的制約があることをリアルタイム性と言います
もちろんガベージコレクションはリアルタイム性の障害となりますのでそれを軽減する手法を取ったりリアルタイム性を必要としないタイミングでGCを実行します
しかしそれでも現実的なOSや基幹システムでGC言語の利用は厳しいでしょう
そのためOSなどの記述にはCやC++やRustが使われます
メモリ安全性などの保証をプログラマーではなく言語システムに任せることができるRustがベストとなります
115:デフォルトの名無しさん
23/03/03 21:20:32.28 qLiBhaKu.net
エアプするにしてもせめてthe embedded bookくらいざっくり読んでからにすればいいのに
116:デフォルトの名無しさん
23/03/03 21:26:29.88 HbtHbRsb.net
>>114
リアルタイム性の話ではなく
GCの話しかしないことを言っている
GCくらいしか語る知識がないと俺は推測している
117:デフォルトの名無しさん
23/03/03 21:48:53.60 IWtB3OsL.net
C++とRustの比較スレだからGCない言語が前提だもんな
Javaとか持ち出す>>110や>>111はアホすぎ
118:デフォルトの名無しさん
23/03/03 21:51:10.69 HbtHbRsb.net
>>118
>>76
119:デフォルトの名無しさん
23/03/03 21:51:28.18 HbtHbRsb.net
>>117
>>76
120:デフォルトの名無しさん
23/03/03 22:54:44.50 3xVHehJY.net
ここが新しい隔離スレちゃんですか
121:デフォルトの名無しさん
23/03/03 23:40:18.48 DSH9vzOS.net
ここは純粋にC++とRustの比較スレ
しかし無関係なGC言語を持ち出してくるバカがいてそれを邪魔をしているようだ
122:デフォルトの名無しさん
23/03/03 23:41:20.65 kiJ4JQPs.net
実務経験の乏しい人が言語機能だけで頭でっかちなアピールしてるのを見ると狙ってアンチ活動してるのかと勘繰りたくなるよね
まぁ隔離ファイト続けてくれ
123:デフォルトの名無しさん
23/03/03 23:57:24.37 gZNQib4P.net
それらの言語を実際に書いて使っていればガッべージコレクションのある言語がC言語系を置き換えできないことくらい分かるはずだもんなー
124:デフォルトの名無しさん
23/03/04 02:04:08.56 OUzFL/z0.net
WinAPI/ATL/MFCの系譜をWinFormsが現れて.NETが置き換えていった歴史は無かったことにされたらしい
125:デフォルトの名無しさん
23/03/04 05:09:33.55 zMMeSguG.net
CやC++に置き換わる言語の話でWinAPIやWinFormsを持ち出してくるとは頭おかしいな
126:デフォルトの名無しさん
23/03/04 10:37:16.20 4/pts6A0.net
C#もGCないネイティブでビルドするオプションがあったら天下取れたかもな
VB6はGC無かったのになぜこうなった
127:デフォルトの名無しさん
23/03/04 10:41:49.65 CDmz22lO.net
>>125
君はてをにはがおかしい
寝ぼけた頭で脊髄反射で書き込むのはやめたほうがいいな
128:デフォルトの名無しさん
23/03/04 10:54:13.03 RFNVa0Qi.net
>>114
chatGPTの回答に似てるなωωω
129:デフォルトの名無しさん
23/03/04 10:59:11.20 RFNVa0Qi.net
>>127
何処が可笑しいか指摘してくれ
おれには判らん
130:デフォルトの名無しさん
23/03/04 11:05:58.63 54Un32Sk.net
>>129
「CやC++に置き換わる言語の話」なんて誰もしていない
「CやC++に取って代わる」あるいは「CやC++を置き換える」と言いたいのだろう
あるいは本気で「CやC++に置き換わる言語の話」をしているのなら今度こそ本当に頭がおかしいな
131:デフォルトの名無しさん
23/03/04 11:14:10.28 RFNVa0Qi.net
それがてにをはどどう関係あるの？
132:デフォルトの名無しさん
23/03/04 11:23:10.42 33wAkDSd.net
>>126
VB6はトレースGCではないけど参照カウンタGC方式のGC言語
VB6オブジェクトは裏で参照カウンタが自動的に使われていてそれにより使われなくなったメモリを回収している
ちなみにC++のshared_ptrなども参照カウンタ方式だが裏で勝手に使われることはなく必須でもなくプログラマー裁量なのでC++はGC言語ではない
133:デフォルトの名無しさん
23/03/04 11:59:27.29 Ss9j+0Cw.net
Rustに期待している人のフラストレーションを解消したいなら
フルスクラッチでOSを書くくらいしか方法はないだろうね
OSの普及は更に至難の技だけども
134:デフォルトの名無しさん
23/03/04 12:08:40.51 2fdiw2OM.net
(実務経験ゼロ + 論理的思考力の欠落 + 自己愛性パーソナリティ障害) * Rustへの執着 = 通称複製おじさん
135:デフォルトの名無しさん
23/03/04 12:51:29.76 SdQ3Tgr2.net
|
| 彡⌒ミ
＼ (´･ω･`)またGCの話してる
(| |)::::
(γ /:::::::
し ＼:::
＼
136:デフォルトの名無しさん
23/03/05 00:54:23.16 OH6jTTZv.net
うるせー馬鹿
137:デフォルトの名無しさん
23/03/05 00:59:18.56 eidG4gk+.net
>>133
フルスクラッチの新たなOSを普及させるのは難しいだろうが
>>74に記事があるようにGoogleがRustのみで新OSを作ってるな
あとAndroidもLinuxもWindowsもRustの一部採用を始めて
この流れはOSに限らず全てのシステムでRust化が進んでいくのだろう
GoogleとMicrosoftがRust言語でOS開発
URLﾘﾝｸ(xtech.nikkei.com)
138:デフォルトの名無しさん
23/03/05 09:30:23.81 B0+xSixt.net
>>137
次第に現行プロジェクトを置換して増えていくなんて展開はありえないっての
AndroidやWindowsをRust製のOSで置換するくらいしかストーリとしてはない
Linuxに入っているRustコードは>>39で書いた通り
139:デフォルトの名無しさん
23/03/05 10:00:51.19 N4QaJnep.net
私はRustで年収1億稼ぎましたみたいな話はないのかよ
マイナープロジェクトでちょっと使われたら勝利なのかよ
140:デフォルトの名無しさん
23/03/05 11:14:29.69 /Qd0pRlS.net
Winnyの作者みたいに逮捕されるかと思ったら怖くて無理
141:デフォルトの名無しさん
23/03/05 11:34:54.12 ukOUhlGm.net
話し飛躍しすぎでしょ
142:デフォルトの名無しさん
23/03/05 11:49:22.14 nmaj3sub.net
Rustで検証してうまくいったらそのままCにコンバートすれば余計なチェックコードが削れてる速く動く
とかね。
143:デフォルトの名無しさん
23/03/05 14:28:35.02 FAqgXVt3.net
てかGCって別に悪いもんじゃねぇしな
144:デフォルトの名無しさん
23/03/05 14:30:11.56 FAqgXVt3.net
>>133
それよりもグラフィックソフト作ったほうが広まると思うけどね
Blender参考に3Dモデリングソフトつくってよ
145:デフォルトの名無しさん
23/03/05 14:54:49.80 B0+xSixt.net
>>144
それでは心が満たされないんだよ
GCの話しかしない人とか
146:デフォルトの名無しさん
23/03/05 15:15:15.70 WdTi9AcG.net
>>143
GCの有無はその言語がカバーできる範囲の差となり優劣関係が明白
GCのない言語は全てをカバーできる
147:デフォルトの名無しさん
23/03/05 15:45:42.10 09jM8Cxo.net
>>146
UEとかのゲームエンジンは当たり前だがついてる
うまく付き合ってくほうが大事
148:デフォルトの名無しさん
23/03/05 15:50:56.78 7nv7saAE.net
本当にGCの話しかしないんだね
GC以外のことを語る知識がない
GCはこの板見てる人はほぼ誰でも知っているだろう
149:デフォルトの名無しさん
23/03/05 15:58:09.36 Y+o3TKYe.net
色んな言語のライブラリがC++(や最近はRust)で書かれているのを考えると
C++とRustが王者決定戦になるのは当たり前じゃね？
150:デフォルトの名無しさん
23/03/05 16:07:43.53 RiJu3w7U.net
入力にゴミデータを与えるとゴミしか出力されないことの好例
151:デフォルトの名無しさん
23/03/05 18:26:02.22 xsWqtK1g.net
いつのまにかPythonやJavaScriptのライブラリがRustで作れるようになってるのな
152:デフォルトの名無しさん
23/03/06 00:49:06.50 pFRSokg0.net
そりゃラップするだけなんだから作れるだろ
アホか
153:デフォルトの名無しさん
23/03/06 09:19:45.87 93HR+LQR.net
そして我が道をいくLISP
154:デフォルトの名無しさん
23/03/06 09:45:52.37 4Z2NP+rF.net
LISPといえばGCの元祖だな
155:デフォルトの名無しさん
23/03/06 13:40:13.02 diWxUEyJ.net
|
| 彡⌒ミ
＼ (´･ω･`)またGCの話してる
(| |)::::
(γ /:::::::
し ＼:::
＼
156:デフォルトの名無しさん
23/03/06 15:05:53.11 diWxUEyJ.net
memo
URLﾘﾝｸ(zenn.dev)
157:デフォルトの名無しさん
23/03/06 17:14:45.53 93HR+LQR.net
ふと思ったんだけど、Rustのmutableな構造体の中にimmutableなフィールドって持てるんだっけ？
158:デフォルトの名無しさん
23/03/06 20:00:50.97 BPh5rEIJ.net
>>157
そういえば、C++のcv属性は、論理和方式で、constは足し算の様に0から1に
変わるが、mut 属性はそうはならないだろうから、どうなるんだろうな。
constは意味的に考えてもcastしない限りは、、constなものはいくらやっても
書き込めるようにはならない、というのは安全性から当然なんだけど、
mutだとそうはいかない。
159:デフォルトの名無しさん
23/03/06 20:09:02.49 BPh5rEIJ.net
>>158
mutとconstは逆さまの働きみたいだから、どっちで行くかは言語設計者の自由と
思われがちだけど、constな構造体のメンバは勝手に全てconst扱いになるという
単純な論理に出来るけど、mut方式の場合は、constキーワードも別に必要になりそう。
160:デフォルトの名無しさん
23/03/06 21:18:31.55 HKTArltY.net
>>157
他の言語と同じでsetter相当をなくしてgetterだけにすればいい
専用のラッパーを作る方法もあるができて当然の機能なので誰もやらないだろうね
161:デフォルトの名無しさん
23/03/06 21:44:09.47 l1NoBYC6.net
>>159
C++でconstを誤用しているのとは異なり
Rustではconstを正しく定数の意味で使っているので注意
つまりconstは定数でありコンパイル時に静的に定まる
もちろんconstとは別の概念としてmutableとimmutableがあり、これらは可変性の有無を表す
さらにそれらと別の概念として所有権があり、所有権を持っていればimmutableであろうと関係なくmutableな変数へ移すことで可変性を得られる
一方で所有権を持たないimmutableな参照からは可変性を得られない
162:デフォルトの名無しさん
23/03/06 21:51:25.41 1935XsNt.net
>>161
>C++でconstを誤用しているのとは異なり
誤用なの?
163:デフォルトの名無しさん
23/03/06 22:01:32.22 l1NoBYC6.net
>>162
そうだよ
実行するたびにあるいは関数を呼ぶたびに値が変わりうる変数(＝静的に値が定まらず変わりうること)に対して、
変数がimmutableであることを間違えてconstと付けてしまった
そのためC++では定数(＝静的に値が定まること)の場合は苦肉の策でconstexprと変な名前を付けることになった
164:デフォルトの名無しさん
23/03/06 22:21:12.53 1935XsNt.net
>>163
C++では単に値が`constant'って意味で使っただけではないのかな?
それを誤用とは言わんと思う
ところで何でconstexprではないconst変数は
静的に定まらないことになってるの?
165:デフォルトの名無しさん
23/03/06 22:37:19.16 l1NoBYC6.net
>>164
もちろんC++は整数などに限ればconstで静的な定数となるが
それ以外C++のconstは定数ではなく静的にコンパイル時に定まらない
そのため真のconstを表すためにconstexprというキーワードを新たに用意する本末転倒な状況となった
166:デフォルトの名無しさん
23/03/06 22:52:19.69 1935XsNt.net
以下の2つは矛盾してないかい?
>>163
>実行するたびにあるいは関数を呼ぶたびに値が変わりうる変数(＝静的に値が定まらず変わりうること)に対して、
>変数がimmutableであることを間違えてconstと付けてしまった
>>164
>もちろんC++は整数などに限ればconstで静的な定数となるが
2つ目はなるんだっけ?
167:デフォルトの名無しさん
23/03/06 22:53:11.95 1935XsNt.net
>>165
>そのため真のconstを表すためにconstexprというキーワードを新たに用意する本末転倒な状況となった
「本末転倒」とは違うと思うよ
168:デフォルトの名無しさん
23/03/06 23:09:16.19 h8dbx3na.net
>>166
C++で何らかのクラスのインスタンスを作ってconstに入れることを考えてみるとわかりやすいよ
もちろんこのconstのインスタンスはコンストラクタの引き数の値によって変わるから静的な定数じゃないよね
つまり単なるimmutableな変数に過ぎないわけだけどC++はそれに対してconstと間違えて名付けちゃった
だから本当の定数に対してconstexprと名付けることになった有名な話だよ
169:デフォルトの名無しさん
23/03/06 23:20:34.22 1935XsNt.net
>>168
>つまり単なるimmutableな変数に過ぎないわけだけどC++はそれに対してconstと間違えて名付けちゃった
C++のconstは単なる`constant'の意味で
静的な定数という意味でないというだけなのでは?
本当に「間違えて」名付けたのかな?
俺にはC++のconstにあなたが「間違えて」静的な定数という意味を
期待しているだけに見えるのだが?
170:デフォルトの名無しさん
23/03/06 23:31:32.57 l1NoBYC6.net
>>169
環境によって実行毎に、または、関数の引き数によって関数が呼ばれるごとに、>>168の示してる例だと値が変わりうる
その変わりうるものに対して、C++がconstと付けたのは失敗としか言いようがないのではないか
そしてC++は本当にconstantなものに対して、後からconstexprと付けざるをえなかったことが、C++の失敗を誰の目にも明らかにしている
171:デフォルトの名無しさん
23/03/06 23:33:40.69 1935XsNt.net
>>170
>環境によって実行毎に、または、関数の引き数によって関数が呼ばれるごとに、>>168の示してる例だと値が変わりうる
これはどいう状況か分かりにくい? ソースで書いてみて
172:デフォルトの名無しさん
23/03/06 23:42:46.60 l1NoBYC6.net
>>171
関数に渡ってきた毎回変わりうる引き数を使ってそれを渡してインスタンス作成してconstに突っ込む場合でもよい
あるいは環境変数やargv使ってインスタンス作成でもよい
いずれも毎回インスタンスの値が変わりうるため定数ではないがC++ではconstと付けてしまった
そして本当の定数にconstexprと付けた
173:デフォルトの名無しさん
23/03/06 23:47:46.47 1935XsNt.net
>>172
曖昧さを避けたいのでソースで書いて
反論する
174:デフォルトの名無しさん
23/03/06 23:52:15.11 p7JhiTtQ.net
ただし*const Tのconstだけはコンパイル時定数の意ではなく、C++と同じで書き換えを行えないという意味です
一貫性がありませんね
175:デフォルトの名無しさん
23/03/06 23:56:33.22 h8dbx3na.net
>>169
数字でも物理でも定数は静的に定まるものだよ
でもC++はconstをimmutableの意味で間違えて名付けてしまいました
そして定数を表すためにconstを使えなくなりconstexprと名付けたという誰でも知ってる有名な話だよ
176:デフォルトの名無しさん
23/03/07 00:01:46.05 gZ1LpnCS.net
>>175
>でもC++はconstをimmutableの意味で間違えて名付けてしまいました
とあなたが思っているだけではないかな?
C++のconstにあなたなが「間違えて」静的に定まるものを期待しているだけでは?
177:デフォルトの名無しさん
23/03/07 00:09:47.95 6eBCzRN0.net
言われてみれば数字や物理で定数は静的に定まる値だな
どうせC++で静的に定まる値を示すキーワードも必要となるんだから素直にそれをconstにしておくべきだったか
設計ミスだな
178:デフォルトの名無しさん
23/03/07 00:57:00.01 UNnBBHt0.net
>>175 >>177の頭が設計ミス
179:デフォルトの名無しさん
23/03/07 01:08:45.38 gZ1LpnCS.net
>>177
>言われてみれば
www
180:デフォルトの名無しさん
23/03/07 01:27:52.75 phr7A4jU.net
immutableとconstantの違いを区別できていない人がimmutableに対してconstと命名してしまったのかな
そのためconstantに対してconstと命名できなくなってconstexprと命名したと
181:デフォルトの名無しさん
23/03/07 01:31:47.04 CjRtBzJ1.net
同じ言葉や字句でも言語ごとにその概念が指すものは異なる
相対主義的に考えなさい
相手の価値観を理解しなければ説得力は生まれません
182:デフォルトの名無しさん
23/03/07 02:21:18.68 oSHTm7sl.net
・y = ax (a=10である)
aをimmutableと呼ぶかconstantと呼ぶか
・y=f(a) (a=10である)
f(a)をconstantと呼ぶかconstant expressionと呼ぶか
まあ考え方次第だよな
183:デフォルトの名無しさん
23/03/07 02:29:20.82 phr7A4jU.net
>>182
上はxが実行時に値がわかる変数なんでしょ？
それならconstantには成りえないんじゃない？
184:デフォルトの名無しさん
23/03/07 08:05:58.19 oSHTm7sl.net
>>183
かかるaについてなんと呼ぶかって話だから別にxについて気にする必要は無いよ
185:デフォルトの名無しさん
23/03/07 08:10:06.41 X5urLXgj.net
>>182
理解できていなさ過ぎだろｗ
186:デフォルトの名無しさん
23/03/07 08:16:15.53 X5urLXgj.net
>>182
あと例を出すにしても
整数は特殊でconstexprでなくconstでも静的定数になる例外だから例として最も不適切
187:デフォルトの名無しさん
23/03/07 09:21:06.13 hj+ftEk+.net
自演してRustゴリ推し他言語叩きをしてるのは
複製おじさんと呼ばれてるRustスレでは有名な荒らし
しかもそいつが「RustJP公式 」の中の人で間違いなさそうって話だから手に負えない
188:デフォルトの名無しさん
23/03/07 10:27:35.30 QCj9HjAv.net
>>187
「RustJP自称公式 」なのでなんの問題もない
189:デフォルトの名無しさん
23/03/07 11:40:31.33 gZ1LpnCS.net
>>180
それはお前用語なんじゃね?
190:デフォルトの名無しさん
23/03/07 11:55:27.75 CdvGJ9oA.net
y = ax
y も a も x も変数としか言いようがない
191:デフォルトの名無しさん
23/03/07 12:47:12.28 CHI/c7S+.net
aを10としたときにコンパイル時
最適化してしまうかaという入れ物残しとくか更にはf(a)も計算して結果だけ使うか
192:デフォルトの名無しさん
23/03/07 21:59:54.08 6AJw5hNk.net
整数はconstやconstexprの有無に関係なくコンパイル時に最適化されるから整数を持ち出して来ても意味がない
C++ならクラスのインスタンスを生成する場合などを考えるとわかりやすい
コンパイル時点でそのインスタンスを定数化できる時にconstexprを使い静的に定数となる
そうでなく実行時にならないと値が定まらない変数となる時はconstexprを使えない
その変数がimmutableつまり生成以降は値を変更できない時はconstを使う
193:182
23/03/07 22:28:59.56 oSHTm7sl.net
constというものの表現を語るうえで言語依存しない形で書いただけなので
少数でも文字列でも適当に読み替えてね
194:デフォルトの名無しさん
23/03/08 00:26:55.95 Ax/TB2dR.net
>>192
C++の命名ミスだな
定数にconstと命名すべきであり
immutableな変数にconstと命名すべきでなかった
195:デフォルトの名無しさん
23/03/08 00:36:06.87 o1WhyvRq.net
壊れたテープレコーダは生まれてくるべきでなかった
196:デフォルトの名無しさん
23/03/08 00:46:11.75 +ZMcnEdg.net
事後諸葛亮
197:デフォルトの名無しさん
23/03/08 01:01:29.10 qkb67oYH.net
同じ事しか書けない命名君はGC連呼厨なのか
198:デフォルトの名無しさん
23/03/08 01:22:37.49 9h+oJZcX.net
結果的に後からみればC++の命名ミスなんだろうが歴史的経緯で仕方ないだろ
昔はimmutableとconstantの概念の区別が曖昧だった
199:デフォルトの名無しさん
23/03/08 01:53:12.26 CbNEQcSB.net
どうしても`immutable'を使いたければマクロ定義すれば?
#define immutable const
200:デフォルトの名無しさん
23/03/08 02:01:56.79 3vDDzLqz.net
Rustはconstをimmutableとcompile-time constantの両方の意味で使うので一貫性が無い
>>174
201:デフォルトの名無しさん
23/03/08 07:29:50.16 OMAPV4fU.net
>>200
Rustでconstは常に静的な定数を表す
*constはconstとは全く別のものであり予約語を最小限にするための使い回し組み合わせ
両者は種別も異なるため混乱することもない
constは定数の定義なのでこの位置に来る
let foo: i32 = 12345;
const FOO: i32 = 12345;
*constは生ポインタの型を示すのでこの位置に来る
const BAR: &i32 = &FOO;
const BAZ: *const i32 = &FOO;
このように両者は全く別物で出現位置も異なり共存もでき混乱することもない
この生ポインタはunsafe Rustでしか使わないため通常は出て来ない
そのために新たな予約語を消費するのは馬鹿げているため既存の組み合わせという合理的な選択をした
202:デフォルトの名無しさん
23/03/08 07:30:57.28 /qygPgTx.net
constはCからの流れだしな。
元々Cがシステムプログラミング向けだったことを思えば、「リードオンリーセクションに置け」っていうくらいのつもりだったんだろ。
定数は#defineで指定しろって感じかな。
203:デフォルトの名無しさん
23/03/08 08:49:19.07 w2ee/I/N.net
>>201
> この生ポインタはunsafe Rustでしか使わないため通常は出て来ない
safeの範囲で普通に使うけど
参照の同一性比較とか書いたことないの？
204:デフォルトの名無しさん
23/03/08 09:00:01.62 OMAPV4fU.net
>>203
参照の比較は生ポインタ直接比較ではなくstd::ptr::eqを使うのが行儀良いマナー
参照を渡せば*constに自動でcoerceされるためコードに*constを記述する必要はない
205:デフォルトの名無しさん
23/03/09 14:43:18.74 lc0skjdv.net
本題に戻ろう
206:デフォルトの名無しさん
23/03/09 19:02:01.89 33ubz+zP.net
Rustは優秀なんだろうけど、言語仕様が難解なのと、「～の分野ならRust」と言えるものがないから広がりにくいんだろうね
207:デフォルトの名無しさん
23/03/11 11:27:51.97 E47xdjIQ.net
それにRustは左翼的な弱者救済的な雰囲気が漂う。
VBも同じ理由で使ってるだけで駄目プログラマとみなされていったから、
同じようにRustを使ってるだけで駄目プログラマ決定されてしまう気がする。
208:デフォルトの名無しさん
23/03/11 11:29:57.74 E47xdjIQ.net
Excelもそうだ。Excelを使ってるだけで弱者扱いされてしまうようになっている。
VBもそうなったから、中味はそう変わってないのに名前を変えてC#にされた。
しかし、だんだんと、C#もVBと同じように馬鹿プログラマ専用言語とみなされる
ようになってきてる。
Rustもきっとそうなるだろう。
209:デフォルトの名無しさん
23/03/11 14:27:01.34 lvldJuuV.net
Rustも悪くないけど日本語のドキュメントが酷すぎるかなあ。
たとえば第七章のパッケージとグレートの話とかでも
-------
最初に学ぶモジュールシステムの要素は、パッケージとクレートです。 クレートはバイナリかライブラリのどちらかです。 クレートルート (crate root) とは、Rustコンパイラの開始点となり、クレートのルートモジュールを作るソースファイルのことです
--------
英文の方は版が新しいこともあってか
The first parts of the module system we’ll cover are packages and crates.
A crate is the smallest amount of code that the Rust compiler considers at a time. Even if you run rustc rather than cargo and pass a single source code file (as we did all the way back in the “Writing and Running a Rust Program” section of Chapter 1), the compiler considers that file to be a crate.
と、いう具合で以下だいぶ丁寧に解説してる。
パッケージにはa library crateとあるから一つだけなの？とChatGPTに尋ねたら複数入ることもあると断言されたけど。
210:デフォルトの名無しさん
23/03/11 14:31:08.67 +PZMhSrI.net
面倒ならとりあえずDeepLに掛ければ良いのにね
> モジュールシステムで最初に取り上げるのは、パッケージとクレートです。
>
> クレートは、Rustコンパイラが一度に考慮する最小のコード量です。cargoで
> はなくrustcを実行し、1つのソースコードファイルを渡したとしても（第1章
> の「Rustプログラムの作成と実行」でやったように）、コンパイラはそのファ
> イルをクレートと見なします。
211:デフォルトの名無しさん
23/03/11 16:27:23.47 BtFFfdHV.net
>>209
ひどすぎるのには同意するが
それはボランティアによる非公式な翻訳で
識者による監修や査読がされてないから
質が低いのは当然といえば当然
一部専門用語を除くと機械翻訳のほうが
それよりはマシな訳になることが多いので
多少英語が苦手でも公式を見たほうが断然効率がいいよ
212:デフォルトの名無しさん
23/03/11 16:39:48.49 47WJOH0Y.net
>>209
7章の最初のページ見ればそれぞれどういう関係なのか一目瞭然
単数形複数形の違いを丁寧に訳してなければ重要な意味が日本語訳では消えてるかもね
・Packages: A Cargo feature that lets you build, test, and share crates
・Crates: A tree of modules that produces a library or executable
・Modules and use: Let you control the organization, scope, and privacy of paths
・Paths: A way of naming an item, such as a struct, function, or module
213:デフォルトの名無しさん
23/03/11 17:28:34.44 /GMTezZ0.net
>>209
そのページは原文の2年半以上前の状態止まってる
日々改善されてるOSSで数年単位の遅れがあると全く役に立たないから
現状はRustの日本語ドキュメントは無いものと思っておいたほうがいい
214:デフォルトの名無しさん
23/03/11 18:00:56.32 bkYlWMhE.net
>>213
原文のいつの状態を反映した訳なのか全然管理できてないらしいからね
アップデートは望み薄
215:デフォルトの名無しさん
23/03/11 19:45:03.63 +PZMhSrI.net
規格がないので二流感が拭えない
かと言ってC++が登場したときのように
今はプログラミング言語の実装が
いくつも出てくる状況でもないのかな?
216:デフォルトの名無しさん
23/03/11 22:12:18.37 GtLfWJGz.net
>>215
C++での混乱と失敗を繰り返さないことが重要
217:デフォルトの名無しさん
23/03/11 22:59:17.84 +PZMhSrI.net
実装は複数あった方がメリットが大きいよ
218:デフォルトの名無しさん
23/03/11 23:05:20.16 2/rFH0pr.net
>>214
マジかよw
たかだか100個程度のファイルが管理できないってどんだけよ
219:デフォルトの名無しさん
23/03/11 23:19:14.88 ChsfUoNW.net
実装が複数あることはメリットもあるがデメリットも多くユーザを混乱させてきた
一方で言語仕様とその実現方法が確定して枯れた時は複数実装のメリットが上回る
Rustについては更なる理想の言語に向けて公開todoリストも多くまだ発展段階なので複数実装は向いていない
もちろん従来的な使い方ならば現状のRustで既に十分に利用できる
220:デフォルトの名無しさん
23/03/11 23:24:45.49 uRw385pv.net
>>218
ユーザーフォーラムのしかもたった二人の回答を「公式コミュニティの見解」にしてしまうオツムの人達だからさ一般常識があると思ったら大間違い
221:デフォルトの名無しさん
23/03/11 23:30:52.30 +PZMhSrI.net
>>219
3行目は全否定しておく
CやC++に複数の実装があった第一の要因は開発ツールが売れたという背景がある
Rustに限らず開発ツールは最早ビジネスとしては成り立たなくなってしまった
222:デフォルトの名無しさん
23/03/11 23:34:33.13 2T5UBlcf.net
>>220
あれ痛いよね
でもピン留めして晒し上げるのはさすがにどうかと思うわ
223:デフォルトの名無しさん
23/03/11 23:39:25.95 ChsfUoNW.net
Rustは公式が提供するcargoやrust-analyzerで開発環境は十分だもんな
もちろんrust-analyzerはLSPなのでVScodeなどの既存の統合開発環境で使える
224:デフォルトの名無しさん
23/03/11 23:51:17.37 3ENT9RfU.net
>>220
Rustユーザーの大半は英語のドキュメントを直接見てるからな
同じRustユーザーというだけであのリテラシーレベルと同類扱いされるのは誠に遺憾
225:デフォルトの名無しさん
23/03/12 06:07:53.91 b0Zzr0Fl.net
>>212
一目瞭然ってことはないよ。
わかってるやつにはわかるっていうレベル。
特にmodule and use以下で戸惑うと思うよ。
Rustはプログラミング言語としてはCとかで神経使っていたところで楽させてくれる感じだけど、新人を呼び込むにはドキュメントがまずいかなあ。
226:デフォルトの名無しさん
23/03/12 09:19:37.91 XJpeOWKz.net
前にもこれどこかで同じレスしたことあるけど
Javascriptってドキュメントすっごい充実してるよな
2000年以前はHTMLとJavascript一緒になった解説本の最後の方に申し訳程度に乗ってたくらいで
あとは某とほほサイト見るくらいしかなかったけど
最近ちらっとみたらすごいのな
URLﾘﾝｸ(developer.mozilla.org)
これは適当にクリックした特に選んでない一例だけど
ちょっと過剰なくらい説明と例が乗っててスゴイと思ったわ
Rustにここまでを要求したほうがいいとも思わんけど
いつかみんなが使う言語になったときはそうなってるのかもしれん
227:デフォルトの名無しさん
23/03/13 09:18:51.45 65XUJIc/.net
udemyからrust勉強すれば良いと思う
228:デフォルトの名無しさん
23/03/13 11:30:57.14 QpsvkUdl.net
C++は既に意味不明な域に来ていて、誰も新規に習得しようとはしないだろう
229:デフォルトの名無しさん
23/03/13 12:04:07.60 wwEuDEVq.net
>>226
ほんと。自分もノーマークだったけどすごいね。
Rustも「英文ドキュメント読め」みたいに突っぱねいようにしなくちゃね。
Rustのサイトで各国語にトランスレートされたもののリンク先の更新日付を眺めてると、中国語版に負けてる感じだね。
230:デフォルトの名無しさん
23/03/13 12:11:38.79 CJ8zcgHs.net
中国なんてどうでもいい
231:デフォルトの名無しさん
23/03/13 12:13:17.03 bP2+YJD9.net
MDNもMDNで英語読まないとやってられない記事はちょいちょいあるけどね
CSSのpositionとか
232:デフォルトの名無しさん
23/03/13 14:43:06.35 wwEuDEVq.net
少なくとも手解き用として、TheBookの日本語版ではねえ。
で、メモリ安全ってことだけをひたすらリピートするだけでは、新しい人は来ないでくださいと言ってるようなもん。
まあ、その方がチンケな優越感に浸れて良いのかもしれないけど。
233:デフォルトの名無しさん
23/03/13 15:10:59.37 cwbZasxH.net
>>231
Wasmのところも日本語版は古い情報のままなので肝心なAPIが足りていなくて英語版を見ないと致命的
リンク先が訳せてなくて英語版を指しているのは次善策としてまだマシ
英語版
URLﾘﾝｸ(developer.mozilla.org)
日本語版
URLﾘﾝｸ(developer.mozilla.org)
234:デフォルトの名無しさん
23/03/13 15:27:59.03 kyo182dJ.net
メモリ安全ってのは個人が始める動機としては弱い
スマートポインタで充分なんだし
チームで書くときにメモリ管理が怪しい奴が混ざり得るときに
Rustで書くことを強制されるってシチュエーションはありえるかもね
235:デフォルトの名無しさん
23/03/13 15:42:51.26 sbzZb6rB.net
>>234
両方書いてると差は歴然
Rustは可読性もよいし開発効率もよく
特に実行時デバッグが激減するのも大きい
やむをえない場合を除いてC++を使い続けるメリットはない
236:デフォルトの名無しさん
23/03/13 15:54:03.52 kyo182dJ.net
>>235
>Rustは可読性もよいし開発効率もよく
そんなのは人によるとしか言えない
所有権に割と馴染みがあるC++プログラマはともかく
他の言語からだと文法の解離に抵抗はあるだろうね
これからプログラミングを始めようという人は
特にRustだからという抵抗はないだろう
実績が増えればRustからって人が増えるかもね
237:デフォルトの名無しさん
23/03/13 16:03:04.23 UI2Ct8M3.net
C++はコンパイラ買う時にデバッグツールもあって、そこでメモリリーク含む大体の解析が出来ることが多いから、今の所メモリ安全で困ったことはないな。
それよりもRustはまだ新しいから、何かしら思わぬ脆弱性が潜んでいることも考えて、まだ弄りながら様子見って感じ
238:デフォルトの名無しさん
23/03/13 18:05:23.37 QpsvkUdl.net
C++の有料コンパイラってそんなすげえのか？
239:デフォルトの名無しさん
23/03/13 18:37:31.12 cwbZasxH.net
>>236
初心者や素人はC++でもRustでもなくBASICやPythonをやっていればいい
C++もRustも書きこなせる人なら自明なようにRustがはるかに効率いい
240:デフォルトの名無しさん
23/03/13 19:04:23.67 sbzZb6rB.net
>>237
デバッグツールを持ち出さなくてもRustはコンパイル時点でほとんど解決する点で圧倒的に優れている
Rustはメモリ安全性だけでなくデータ競合がないことがコンパイル時点で保証される
ポインタ以外の汎用的なヌル安全とエラー処理忘れ防止もRustは標準ライブラリ全体でOptionとResult利用により保証される
C++と比べて開発効率が段違いに良くなる
241:デフォルトの名無しさん
23/03/13 19:17:45.07 9XZC5W3h.net
C/C++のメモリリークと隣合わせなスリルがいいんだよ
Rustなんて補助輪付きの言語はプロのプログラマッには温すぎる
コーディングに自信がない奴や素人向けだな、Rustは
242:デフォルトの名無しさん
23/03/13 19:49:16.47 zhi7FkgJ.net
>>241
C/C++はプログラマとして成長させてくれるよね
243:デフォルトの名無しさん
23/03/13 19:51:01.09 cwbZasxH.net
>>241
C++はデバッグ時間のムダ
244:デフォルトの名無しさん
23/03/13 20:02:48.32 lNJwESa5.net
別にスマートポインタでええがな
245:デフォルトの名無しさん
23/03/13 20:04:22.18 lNJwESa5.net
Rustは規格が出てからだな
246:デフォルトの名無しさん
23/03/13 20:07:14.22 4NzLTP/2.net
マ板でやれバカども
247:デフォルトの名無しさん
23/03/13 20:22:48.71 4VuAJC20.net
>>239
変わった言語なので
まず初めに学んだほうが先入観がなく覚えられるよ
そのためにも日本語のドキュメントは
整備したほうが良い
248:デフォルトの名無しさん
23/03/13 20:39:22.66 RfKK3GLn.net
トラ枝 5月号 Rust 特集
249:デフォルトの名無しさん
23/03/13 20:45:38.95 sbzZb6rB.net
>>243
その通りでC++は無駄なデバッグ時間が必要となるけど
テストで発見できなかった分はデバッグもされず実行時のセキュリティ含めたバグとして残ってしまう
Rustならばコンパイル時点ですべて排除できる
>>244
勉強不足すぎだ
C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
250:デフォルトの名無しさん
23/03/13 21:04:50.75 kyo182dJ.net
>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
他は?
251:デフォルトの名無しさん
23/03/13 21:41:54.90 Lx/25M/K.net
>>250
そんなことも知らずにこのスレで書き込み続けているのかよ
他の人たちの書き込みを読んでないのかよ
252:デフォルトの名無しさん
23/03/13 21:46:41.78 kyo182dJ.net
>>251
他は? GCしか書けない人なのかな?
253:デフォルトの名無しさん
23/03/13 22:00:51.65 sbzZb6rB.net
>>250
既にたくさん書いて伝えた
理解できなかったのか？
254:デフォルトの名無しさん
23/03/13 22:16:19.15 P8sbSRo2.net
絵に描いたような負け犬のセリフw
255:デフォルトの名無しさん
23/03/13 22:35:49.32 kyo182dJ.net
>>253
本当にGCしか知らないんだな
>>249
>勉強不足すぎだ
熨斗をつけてそのままお返ししよう
256:デフォルトの名無しさん
23/03/13 22:38:39.16 Lx/25M/K.net
>>252
C++もRustもGC無いぞ
257:デフォルトの名無しさん
23/03/13 22:43:20.72 kyo182dJ.net
>>256
んなことぁ誰でも分かってる
258:デフォルトの名無しさん
23/03/13 23:26:56.50 sbzZb6rB.net
>>255
GC言語も使うしC/C++/Rustも使う
速さと省メモリの点でGC言語は不利だから使い分ける
259:デフォルトの名無しさん
23/03/13 23:40:00.84 kyo182dJ.net
>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
だから他は?
260:デフォルトの名無しさん
23/03/13 23:52:11.42 9+eE28f9.net
>>244
C++スマートポインタは
unique_ptrは使わずともRustでは標準で全て自動解放されるよ
shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
261:デフォルトの名無しさん
23/03/14 00:08:40.65 nARWep6y.net
>>260
別にunique_ptrやshared_ptrでええがな
難しくないよ
>shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
効率的をも少し詳しく!
262:デフォルトの名無しさん
23/03/14 00:17:28.43 g2aa4i95.net
C/C++でスレッドセーフな並列処理を作ろうと思ったら一苦労だけど、Rustだとそうでもないんかな。
263:デフォルトの名無しさん
23/03/14 00:51:48.86 mRkuEIyQ.net
>>261
shared_ptrは常に排他制御されコストが高い
共有を増減すると排他制御のコストがかかる
さらに単なる受け渡しも要注意でmoveしないとそのコストが無意味に余分にかかってしまう
一方でRustは排他制御するArcとしないRcの2つが用意されていてそれらの問題なく使い分けられる
>>262
Rustはコンパイルが通った時点でデータ競合がないことを保証されるのでかなり楽
264:デフォルトの名無しさん
23/03/14 00:58:40.53 Ff/IlIXh.net
うわっw
排他制御の意味も知らないのかよこいつw
265:デフォルトの名無しさん
23/03/14 01:09:54.31 gRogmLJe.net
shared_ptrは排他制御してリファレンスカウンタの増減を行うからスレッドセーフ
その代わり重い
266:デフォルトの名無しさん
23/03/14 01:26:54.27 nARWep6y.net
>>263
なるほどね
std::shared_ptrには参照カウンタの排他制御をオフにする機能はなかったかな?
boost::shared_ptrだと美しくないけどBOOST_SP_DISABLE_THREADSマクロで切り替えられる
最近使ってないがLoki::SmartPtrは確かテンプレートパラメータで切り替えできたかな?
267:デフォルトの名無しさん
23/03/14 01:58:37.91 gRogmLJe.net
Rustでは共存可能
スレッド内のみの共有はRc
スレッド間での共有はArc
切り替えでなく最初から二種類が用意されるべき
268:デフォルトの名無しさん
23/03/14 02:06:25.73 nARWep6y.net
>>267
同意
std::shared_ptrもLoki::SmartPtrみたいに
テンプレートパラメータで切り替えできれば良いのにね
ただしstd::shared_ptrを規格に入れた時点で
既にboost::shared_ptrもLoki::SmartPtrもあったことを考えると
参照カウンタが競合する機会はほとんどないという見立てで
実装を単純化したのかなと予想する
誰か経緯を知らんかな?
269:デフォルトの名無しさん
23/03/14 02:13:23.45 nARWep6y.net
苦肉の策としては
#include <memory>
#define BOOST_SP_DISABLE_THREADS
#include <boost/shared_ptr.hpp>
template <typename T> using Arc = std::shared_ptr <T>;
template <typename T> using Rc = boost::shared_ptr <T>;
270:デフォルトの名無しさん
23/03/14 02:59:21.97 u9OB+g2b.net
shared_ptr単独では完全なスレッドセーフではない、という問題もある。
shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
C++ではプログラマーがこれらの誤解や見落としやミスを全くしないことを求められ、それに依存するためプログラムの安全品質は危うい。
Rustではその点も安全で、Arc<T>はTへの書き込みが出来ないため、排他制御の問題は起きない。
書き込みしたいならば、Arc<Mutex<T>>やArc<RwLock<T>>など必要となる排他制御の種類に合わせて選び、組み合わせて利用する。
それら組み合わせにより、Tへの書き込みができるようになるが、必ずロックで排他制御されるため問題は起きない。
たとえプログラマーが見落としやミスや使い間違えをしても、Rustコンパイラがエラーを出し、該当箇所を教えてくれるため、常に安全性が保証される。
271:デフォルトの名無しさん
23/03/14 03:15:26.07 nARWep6y.net
>>270
Mutex <T>を書けば良いのではないかな？
272:デフォルトの名無しさん
23/03/14 03:19:38.24 nARWep6y.net
>>270
>shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
>したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
想定してるレベルが低すぎる
マルチスレッドで書くやつにそんなやつはいない
議論が無理やり過ぎ
273:デフォルトの名無しさん
23/03/14 03:33:56.57 u9OB+g2b.net
>>272
その件に限らずすべてにおいて、勘違い、見落とし、ミスなどは発生する。
複雑化したときにmutex忘れも、shared_ptr忘れも、間違えてunique_ptr使いも、その他のミスも、何でも実際に起きている。
Rustではそれらが起きてもコンパイラが通さないことで、常に安全性が保証され、無駄なデバッグを避けられる。
C++では無駄なデバッグを招くか、もしくは、そのままリリースしてセキュリティの穴が生じてしまう。
現実にC++が多数の問題を引き起こしてきた。
274:デフォルトの名無しさん
23/03/14 12:05:32.83 CPf3ZEOa.net
暇を持て余すニートの日記
275:デフォルトの名無しさん
23/03/14 12:21:44.83 nARWep6y.net
>>273
「Rustはコンパイルが通っていればマルチスレッドで
競合問題が起きないことが保証される」
これで正しい? 正しいとすれば
マルチスレッドを習得したときの苦労を考えると有用なので
新しくプログラミングを始める人には勧めたい動機になる
俺自身は困ってないので使おうとはあんまり思わんけどね
276:デフォルトの名無しさん
23/03/14 12:39:04.29 RkFbHwTA.net
Rustが流行るとすればどの分野になるんだろうか？
一番は安全装置とかに使われる小規模な組み込みソフトかな。
CPUとか開発環境とかがまだ整ってないだろうから、ゆっくりだと思うけど
277:デフォルトの名無しさん
23/03/14 12:50:59.56 nARWep6y.net
普及するのにはキラープロダクトが必要
UNIX（C）やMFC（C++）や.NET（C#）のように
大手がプロダクトに採用してトップダウンで流行らせるしか
普及の道はないと思う
ゆっくり普及なんてのはないと思う
278:デフォルトの名無しさん
23/03/14 19:34:32.70 /poSvH9Z.net
Visual Studio Rust .Netがでるまで待とう
279:デフォルトの名無しさん
23/03/14 19:40:00.62 //qYwEcn.net
あらためてJavaって良い言語だなって思うわ
ここ十数年だと人類一番の功績じゃね
良い点：
シンプルさ。C#で言う値型を入れようかどうか迷ったときもあったんだろうけど（想像）、
プリミティブと参照型変数の二個だけでやってくという線引がセンスある。
悲しい点：
立てまし。個人的にはジェネリクスもいらんかった。
C++のテンプレートを潔く排除して出てきたのすごいすっきり感あった。
でもあとでジェネリクスは押し負けて？付いてきちゃったけど。
あと貧相な貧相なラムダ式。クロージャを期待したけど結局はanonymous classのといっしょ。
異論は無いと思う
280:デフォルトの名無しさん
23/03/14 22:31:24.61 CPQICLea.net
>>275
Rustはマルチスレッド時でもマルチタスク時(＝グリーンスレッドをRustではタスクと呼ぶ)でも
データ競合を起こさないことが静的に保証されている
唯一のプログラミング言語
281:デフォルトの名無しさん
23/03/14 23:07:45.86 5gRl/D4e.net
んなわけねえだろ
282:デフォルトの名無しさん
23/03/14 23:17:29.22 CPQICLea.net
>>281
Rust以外の言語があるならば教えて
283:デフォルトの名無しさん
23/03/14 23:54:49.43 AgG33ThB.net
Ownershipの元ネタのCycloneはやってねーのけ？
284:デフォルトの名無しさん
23/03/15 02:10:25.53 itMePwRG.net
Rust、コンパイル遅いっていうけどどれ程なの？C++と比べて遅い？
285:デフォルトの名無しさん
23/03/15 02:53:43.28 aLgn/lBf.net
コンパイル後の実行デバッグ時間が激減したのでトータルで要する時間は減少した
286:デフォルトの名無しさん
23/03/15 03:26:18.55 DXTHIxnh.net
現状はバカがイキる為だけに持ち上げられるRust
万一普及したとしてバカが使いこなせるはずもなく
287:デフォルトの名無しさん
23/03/15 07:08:24.89 SNoM8taV.net
今まで C++ で制御して成功率 99.99% だった
ロケットをわざわざ Rust で描き替えて墜落しても
Rust は悪くない悪いのは GC のせいだと言い張るのが
Rust 信者
288:デフォルトの名無しさん
23/03/15 09:03:13.60 n0l+w21l.net
>>277
Android(Java)
iOS(Objective-C++)
289:デフォルトの名無しさん
23/03/15 09:51:38.96 d2iGalsS.net
ロケットでGCは無いわ
290:デフォルトの名無しさん
23/03/15 10:13:26.89 aLgn/lBf.net
>>287
C++もRustもGCないよ
291:デフォルトの名無しさん
23/03/15 10:52:34.36 d/hulDPr.net
プログラミング言語「Rust」は世界のセキュリティレベルを底上げする
URLﾘﾝｸ(wired.jp)
Androidでは今、暗号鍵を管理する機能の多くがRustで書かれているとGoogleのクライダーマーカーは話す。
たとえば、暗号化したインターネット通信の機能である「DNS over HTTPS」、新バージョンの超広帯域無線（UWB）チップスタック、
そしてグーグルの独自のチップである「Tensor G2」で使用される新しい「Android 仮想化フレームワーク（AVF）」 などもRustで書かれている。
また、BluetoothやWi-Fiなどの通信接続に使われるスタックも、Androidの開発チームによってRustへの変換が積極的に進められている。
理由は、これらが業界の複雑な標準規格に基づいており、脆弱性を多く含む傾向にあるからだとGoogleのクライダーマーカーは付け加える。
つまり最も狙われやすい、あるいは最も重要なソフトウェアの部分からRustに書き換えて、
そこから徐々にRustで書く範囲を広げることで段階的にセキュリティ上の恩恵を受けようという戦略である。