[過去ﾛｸﾞ] Rust part16 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
230(1): 2022/07/07(木)20:06 ID:idvDnT2E(2/4) AAS
>>224
クラスはその根幹の継承がデメリットだらけと結論が出ているためGoやRustなどでは採用されていない
メンバー変数やメンバーメソッド等とは構造体で使えるため困ることはない
Rustでは構造体を含む任意の型に対して横断的に共通適用可能なトレイトがあり非常に強力で利便性がよい
231: 2022/07/07(木)20:09 ID:6JbvD3+y(5/5) AAS
>>229
知らんがな。
大抵の専門用語は一般名詞に (その分野における) 明確な定義を与えることで成り立ってるのはごく普通のことだろ。
232: 2022/07/07(木)20:25 ID:idvDnT2E(3/4) AAS
>>229
世間一般なんてものはなくそれぞれがそれぞれの定義域に依る
そしてそれが明確になっていればよい
例えばRustではメモリ競合は防止可能と明確化しつつ、より一般的な競合状態は対象外と明確化している
原理的に無理なものは無理なのだからそこは明確化してあればそれでよい
233(1): 2022/07/07(木)21:01 ID:0wlfNyVX(1) AAS
>>228
aliasingの話してるところにRAIIが来るのもよくわからないがRAIIだと高速という理屈はさらにわけわかめ
234: 2022/07/07(木)21:12 ID:PQWZgdhj(1) AAS
>>222
windows-rsでunsafe祭りになりながら書いたよ。オススメはしないが。
235: 2022/07/07(木)21:39 ID:pHkHW2c/(1) AAS
SwiftのARCとRustのArcの区別がつかない人は論外なので発言を控えてほしい
ただでさえしょうもないのにしょうもなさが倍増するからね・・・
SwiftのARCはAutomatic Reference Counting
外部ﾘﾝｸ[html]:docs.swift.org
RustのArcはAtomically Reference Counted
外部ﾘﾝｸ[html]:doc.rust-lang.org
236(2): 2022/07/07(木)22:03 ID:webRw0a6(2/2) AAS
>>230
継承をやめて委譲にすれば割とまともになると思います
2chｽﾚ:tech
2chｽﾚ:tech
237: 2022/07/07(木)22:05 ID:idvDnT2E(4/4) AAS
>>233
C++とRustはヒープ利用に対してRAIIによるデストラクタ呼び出しによりリファレンスカウンタ無しでメモリ解放するので高速
さらに加えてRustでは所有権と借用のルール明確化により解放の安全性も静的に保証している
一方でSwiftはヒープ利用に対して常にリファレンスカウンタを用いるARCによりメモリ解放の管理をするため低速
238: 2022/07/07(木)22:11 ID:hEh+9Mpq(1) AAS
>>236
その流れで継承不可のクラスベースのオブジェクト指向言語がどういうものになるか思考実験的に考えてみなよ
239(1): 2022/07/08(金)03:25 ID:CKdXv9cu(1) AAS
それよりSQLが超苦手な俺はPRQLにめちゃくちゃ期待しているのだがラスタシアン達はSQLも達者なのかね？
240(1): 2022/07/08(金)03:34 ID:tnmgUx+u(1) AAS
うーん。
このスレ↓では、Rustはメモリーリークしない、Cはリークすると議論してたからなあ。
2chｽﾚ:tech
241(1): 2022/07/08(金)07:13 ID:vMUJBeEa(1) AAS
pijul使ってみたけど、改行コードがCRLFだと非対応で
バイナリファイル扱いになるという謎仕様でまいった
差分とか出せなくなる
ファイルタイプ判別を変えるオプションは無い
それは置いといても、表示もドキュメントも超簡素で
もうすぐ1.0.0リリースを迎えるとは思えない状態
ほとんどの入門記事で使われている重要コマンドpijul statusが
最近のバージョンで削除されたのも謎すぎる
だいじょうぶなのかこれ
242(1): 2022/07/08(金)07:47 ID:ifo4L8le(1) AAS
>>239
今の開発のトレンドが互換性維持で苦労して中途半端なものになるくらいなら好きな仕様にして最後全部トランスパイルすりゃいいじゃん！になってしまったな
世の天才が叡智を絞った結果がRust界隈含めて今まで散々馬鹿にしてたウェブ(JS)の後追いなの草生えるわ
ちなみに英語圏ではSQLはシークェルと発音するから覚えとけ
ラスタシアンの紳士諸君はえすきゅーえるとかクソダサい発音禁止な
243: 2022/07/08(金)08:02 ID:i9Nd4OSx(1/3) AAS
PRQL 書き味が CloudWatch logs Insightと似てそうだけどあれもそんなにいいもんじゃないぞ。
244: 2022/07/08(金)08:04 ID:pMnIhSXO(1) AAS
>>242
外人の禿げたおっさんはだいたいエスキューエル言うてるやろ
245: 2022/07/08(金)08:11 ID:i9Nd4OSx(2/3) AAS
コントロールも無視もできない処理系や既存資産の上でまともな進化や開発体験を維持しようとしたらトランスパイルになるのは必然だったんだろうな。
それが必要になるクソさと、トランスパイルコストの損益分岐点が最初に現れたのがJSってだけだと思うよ。
246(1): 2022/07/08(金)08:44 ID:efA8XUrt(1) AAS
>>240
メモリリークに関しては
まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
ただし、Rustにおいて循環参照は他の言語と大きく異なり、
・意図的に色々と明確に指示して作成しないと、循環参照は自然に発生しない
・強い参照と弱い参照を使い分けることが出来るため、強い参照のみによる循環参照を避けることが可能
・意図的に強い循環参照を作成した場合は、それはRustにとって自動的なメモリ解放の対象とならない
したがって、Rustにおいて強い循環参照を意図的に作成した場合のみメモリリークが起こりうるが、わざと作成したのだから意図通り、という扱い
247: 2022/07/08(金)09:06 ID:ujjjtz1g(1) AAS
ほんと無知って怖いね
248(1): 2022/07/08(金)09:12 ID:1lqt9Ku2(1) AAS
「循環参照は自然に発生しない」なんていう解説狂信者おじさんがいる限り、プロジェクトには絶対Rustは採用しない......
249(2): 2022/07/08(金)09:29 ID:L1lQIkzy(1) AAS
ほんとこの種の信者は迷惑だわ
普通は多人数で作業して、データー構造をRc<T>をWeak<T>にあらかじめしておくようなことはしないし、”わざと作成したのだから意図通り”とか
相手（これから学ぶ人や新人）を騙すために都合の良いことを吹き込んでいるようにしか見えない・・・
それなら自動メモリ管理ではないので、作り方/使い方により自然/意図しない使い方でリークも場合もあると明確に認めて、その分だけ
自動メモリ管理ではないないので速度が速いし、メモリー解放のタイミングもある程度コントロール出来ると誠実に話したほうが余程、印象が良いのに。
胡散臭い宗教の勧誘に見えるような態度だから叩かれる
250: 2022/07/08(金)09:30 ID:Gv4jmnae(1) AAS
>>241
PijulもPRQLなど最近の新たな試みはRustで実装されることが多いが
それらはRust言語のためのものではなく汎用的なものであり
それらの問題点もRustとは直接関係がない
今後Rustで書かれた新たなものがどんどん増えていくだろうがそこは区別すべきところかな
一方でそれらをRust言語で使うためのクレートなどがあれば
Rustプログラミングにおいて使う特有の話なので
それらの話題自体を避けるべきではないね
251: 2022/07/08(金)09:41 ID:v7XD1ZOP(1) AAS
循環参照は自然に発生しないって、コードを何も書かなければ発生しないって意味かな
252: 2022/07/08(金)09:42 ID:QpPOct5C(1) AAS
>>248
新たなプロジェクトが次々とRustを採用している現実を直視しようぜ
>>249
循環参照はRust以外だと知らぬ間に発生してしまう自然なよくあるものだが
Rustでは複雑な操作で意図的に作り出さないと出現すらしない点を理解しようぜ
253(1): 2022/07/08(金)09:58 ID:BqWLp+Ol(1) AAS
RAIIでメモリをケアするのは
GC方式にくらべて高速ってのはまぁそうなんだけど
それよりも
開放タイミングが決定的であることのほうが特徴
オブジェクトの生存期間によってメモリの使用期間もプログラマが管理できて嬉しい
254: 2022/07/08(金)12:01 ID:bBPWEvXX(1/2) AAS
>>236
参照カウント方式と区別したいなら、「GC方式」みたいな曖昧な用語はやめて「トレーシングGC」を使おうぜ。
255(1): 2022/07/08(金)12:37 ID:4Cg/jdLt(1) AAS
>まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
この時点で嘘だらけなんだから、それ以上読む必要無い
日本語ブログだとこういう複オジレベルの人が多数派なので
Rustを本気で学びたいやつは英語のリソースメインで学ぶことを強くすすめる
256(2): 2022/07/08(金)12:39 ID:u4+He/YT(1/2) AAS
>>249
アンチは実際にプログラミングしたことがないのかね
Rc<T>自体は書き換えできないのでRc<T>だけでは循環参照を作ることができない
Rc<T>とWeak<T>は互いに対称ではないため直接置き換える対象ではない
例えばnewもRc::new(T)とWeak::new()で引数Tの有無からして異なる
さらに多人数で作業するから強い循環参照を知らぬ間に作ってしまうとの言い訳も意味不明だ
257(2): 2022/07/08(金)12:42 ID:u4+He/YT(2/2) AAS
>>255
Rustは所有者がいなくなると自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全で合っている
258(1): 2022/07/08(金)14:56 ID:bBPWEvXX(2/2) AAS
>>257
メモリを解放しないCopying GCの方が高速なんだけどなぁ。
Rustもメモリ解放しない実装なのかね？RAIIならスタック領域しかメモリを確保しないとか。
259: 2022/07/08(金)16:11 ID:VZayErSn(1/2) AAS
>>258
C++もRustも仕組みは同じ
RAIIによりスコープを外れた対象のスタック部分が解放される時にそのデストラクタによってヒープ部分が解放される
汎用的にはこれが最も高速かつ利便性>>253が高い
Copying GCは特殊な環境で特殊な使い方に限定する場合は速いこともありうるがデメリットも多く一般的には使われることが少ない
使用メモリが多くなるとかコピーで値を移動させるため非常に遅いなどのデメリットの他に
そこを指す全てのポインタ値をGCのたびに全て修整しなければならないという致命的な欠陥がある
C/C++/Rustなどでスタック上に置かれたポインタ値の全てを的確に書き換えるのは不可能なので使えない
上下前次1-新書関写板覧索設栞歴
あと 743 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.027s