22/07/07 10:54:08.79 LNwVrqhE.net
shared pointerじゃね？
215:デフォルトの名無しさん
22/07/07 11:14:16.23 xmv5m6Ag.net
結局参照カウント方式なのは一緒なんでしょ
216:デフォルトの名無しさん
22/07/07 12:48:02.98 kuHYrppG.net
>>212
だとするとshared pointer方式ってどんな方式？？
リファレンスカウンタを利用しないshared pointer方式もあるってことだよね？
217:デフォルトの名無しさん
22/07/07 14:09:00.32 1csywUpz.net
>>214
shared pointerはc++のが有名すぎるからなんとも言えないなぁ。
参照カウント以外でポインタを共有するのはリンクリスト方式とかあるよ。
218:デフォルトの名無しさん
22/07/07 15:30:16.82 jjCeBJbE.net
ARCで管理してる時点でRustはガベコレじゃないからすごい！って理論は破綻してるんじゃありませんかね？
219:デフォルトの名無しさん
22/07/07 15:41:53.87 6JbvD3+y.net
>>216
誰がそんなこと言ってんの？
静的に管理できるものは静的に管理するし、実行時にしかわからないものは実行時に管理するってだけのことだ。
参照カウンタの適用範囲を間違えてるプログラマがいるならそれはそいつが無能。
220:デフォルトの名無しさん
22/07/07 16:01:25.39 HUExG/fK.net
Rust公式の日本語意訳にはしっかりRustはガベコレじゃないから高速って書いてあるね
221:デフォルトの名無しさん
22/07/07 16:16:37 I5wN0SQd.net
>>216
Objective-C/SwiftのARCとRustのArcは同じ3文字略語だけど別のものだよ
それを理解した上で言ってるのなら別にいいんだけどさ
222:デフォルトの名無しさん
22/07/07 18:43:04.02 u5IGnUan.net
>>216
そもそもRust公式が「メモリリークはメモリ安全の範疇」と言っているしな。
223:デフォルトの名無しさん
22/07/07 18:52:31.81 pAImJ0Xg.net
>>220
それはRustの定義がおかしい
一般的にはメモリリークがあるとメモリ安全だとは言わない
224:デフォルトの名無しさん
22/07/07 18:55:30.53 V91F8QUY.net
流れぶった切りだけど単純にRustの人たちはGUIどうしてんの？
225:デフォルトの名無しさん
22/07/07 19:11:09.29 Efq0h4+x.net
なんだ、じゃあ、バグはセーフティと定義したら、Rustは安全高めなのか。
226:デフォルトの名無しさん
22/07/07 19:29:21.10 webRw0a6.net
rust にクラスはないのですか？
227:デフォルトの名無しさん
22/07/07 19:39:16.69 6JbvD3+y.net
>>221
Rust が言語の仕組みによって防ごうと努力する範囲にメモリリークは含まないという定義だよ。
それを表すのに「Rust の仕様の中では」メモリ安全という用語を使っているのであって、
定義におかしいもクソもない。 定義なんだから。
228:デフォルトの名無しさん
22/07/07 19:46:35.34 6JbvD3+y.net
>>224
クラスと名付けられている概念はない。
あなたにとってクラスとは何のこと？ 何が出来ればクラス？
229:デフォルトの名無しさん
22/07/07 19:48:37.87 UC7ZSmFv.net
型クラスの事を聞いてるんじゃない？
230:デフォルトの名無しさん
22/07/07 19:49:32.87 idvDnT2E.net
>>216
ARCで管理しているのはSwift
RustはC++と同じくRAIIなので高速
どうしても共有メモリを使いたい時のみshared_ptrやRc/Arcを用いる
231:デフォルトの名無しさん
22/07/07 20:00:40.75 pAImJ0Xg.net
>>225
そのRustの仕様の中でメモリ安全性を達成できていないんだから
Rustの仕様の中でメモリ安全性という用語を使うのは不適切
Rustの謳うメモリ安全性は世間一般のメモリ安全性とは異なる概念なんだからそれを表すには他の用語を使うのが適当かと
232:デフォルトの名無しさん
22/07/07 20:06:09.82 idvDnT2E.net
>>224
クラスはその根幹の継承がデメリットだらけと結論が出ているためGoやRustなどでは採用されていない
メンバー変数やメンバーメソッド等とは構造体で使えるため困ることはない
Rustでは構造体を含む任意の型に対して横断的に共通適用可能なトレイトがあり非常に強力で利便性がよい
233:デフォルトの名無しさん
22/07/07 20:09:54.71 6JbvD3+y.net
>>229
知らんがな。
大抵の専門用語は一般名詞に (その分野における) 明確な定義を与えることで成り立ってるのはごく普通のことだろ。
234:デフォルトの名無しさん
22/07/07 20:25:04.56 idvDnT2E.net
>>229
世間一般なんてものはなくそれぞれがそれぞれの定義域に依る
そしてそれが明確になっていればよい
例えばRustではメモリ競合は防止可能と明確化しつつ、より一般的な競合状態は対象外と明確化している
原理的に無理なものは無理なのだからそこは明確化してあればそれでよい
235:デフォルトの名無しさん
22/07/07 21:01:30.61 0wlfNyVX.net
>>228
aliasingの話してるところにRAIIが来るのもよくわからないがRAIIだと高速という理屈はさらにわけわかめ
236:ﾌ名無しさん
22/07/07 21:12:46.12 PQWZgdhj.net
>>222
windows-rsでunsafe祭りになりながら書いたよ。オススメはしないが。
237:デフォルトの名無しさん
22/07/07 21:39:23.64 pHkHW2c/.net
SwiftのARCとRustのArcの区別がつかない人は論外なので発言を控えてほしい
ただでさえしょうもないのにしょうもなさが倍増するからね・・・
SwiftのARCはAutomatic Reference Counting
URLﾘﾝｸ(docs.swift.org)
RustのArcはAtomically Reference Counted
URLﾘﾝｸ(doc.rust-lang.org)
238:デフォルトの名無しさん
22/07/07 22:03:40.09 webRw0a6.net
>>230
継承をやめて委譲にすれば割とまともになると思います
ｽﾚﾘﾝｸ(tech板:51番)
ｽﾚﾘﾝｸ(tech板:84番)
239:デフォルトの名無しさん
22/07/07 22:05:44.36 idvDnT2E.net
>>233
C++とRustはヒープ利用に対してRAIIによるデストラクタ呼び出しによりリファレンスカウンタ無しでメモリ解放するので高速
さらに加えてRustでは所有権と借用のルール明確化により解放の安全性も静的に保証している
一方でSwiftはヒープ利用に対して常にリファレンスカウンタを用いるARCによりメモリ解放の管理をするため低速
240:デフォルトの名無しさん
22/07/07 22:11:56.95 hEh+9Mpq.net
>>236
その流れで継承不可のクラスベースのオブジェクト指向言語がどういうものになるか思考実験的に考えてみなよ
241:デフォルトの名無しさん
22/07/08 03:25:18.13 CKdXv9cu.net
それよりSQLが超苦手な俺はPRQLにめちゃくちゃ期待しているのだがラスタシアン達はSQLも達者なのかね？
242:デフォルトの名無しさん
22/07/08 03:34:35.68 tnmgUx+u.net
うーん。
このスレ↓では、Rustはメモリーリークしない、Cはリークすると議論してたからなあ。
ｽﾚﾘﾝｸ(tech板)
243:デフォルトの名無しさん
22/07/08 07:13:21.57 vMUJBeEa.net
pijul使ってみたけど、改行コードがCRLFだと非対応で
バイナリファイル扱いになるという謎仕様でまいった
差分とか出せなくなる
ファイルタイプ判別を変えるオプションは無い
それは置いといても、表示もドキュメントも超簡素で
もうすぐ1.0.0リリースを迎えるとは思えない状態
ほとんどの入門記事で使われている重要コマンドpijul statusが
最近のバージョンで削除されたのも謎すぎる
だいじょうぶなのかこれ
244:デフォルトの名無しさん
22/07/08 07:47:38 ifo4L8le.net
>>239
今の開発のトレンドが互換性維持で苦労して中途半端なものになるくらいなら好きな仕様にして最後全部トランスパイルすりゃいいじゃん！になってしまったな
世の天才が叡智を絞った結果がRust界隈含めて今まで散々馬鹿にしてたウェブ(JS)の後追いなの草生えるわ
ちなみに英語圏ではSQLはシークェルと発音するから覚えとけ
ラスタシアンの紳士諸君はえすきゅーえるとかクソダサい発音禁止な
245:デフォルトの名無しさん
22/07/08 08:02:14.74 i9Nd4OSx.net
PRQL 書き味が CloudWatch logs Insightと似てそうだけどあれもそんなにいいもんじゃないぞ。
246:デフォルトの名無しさん
22/07/08 08:04:43.63 pMnIhSXO.net
>>242
外人の禿げたおっさんはだいたいエスキューエル言うてるやろ
247:デフォルトの名無しさん
22/07/08 08:11:32.47 i9Nd4OSx.net
コントロールも無視もできない処理系や既存資産の上でまともな進化や開発体験を維持しようとしたらトランスパイルになるのは必然だったんだろうな。
それが必要になるクソさと、トランスパイルコストの損益分岐点が最初に現れたのがJSってだけだと思うよ。
248:デフォルトの名無しさん
22/07/08 08:44:10.67 efA8XUrt.net
>>240
メモリリークに関しては
まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
ただし、Rustにおいて循環参照は他の言語と大きく異なり、
・意図的に色々と明確に指示して作成しないと、循環参照は自然に発生しない
・強い参照と弱い参照を使い分けることが出来るため、強い参照のみによる循環参照を避けることが可能
・意図的に強い循環参照を作成した場合は、それはRustにとって自動的なメモリ解放の対象とならない
したがって、Rustにおいて強い循環参照を意図的に作成した場合のみメモリリークが起こりうるが、わざと作成したのだから意図通り、という扱い
249:デフォルトの名無しさん
22/07/08 09:06:34.18 ujjjtz1g.net
ほんと無知って怖いね
250:デフォルトの名無しさん
22/07/08 09:12:01.24 1lqt9Ku2.net
「循環参照は自然に発生しない」なんていう解説狂信者おじさんがいる限り、プロジェクトには絶対Rustは採用しない......
251:デフォルトの名無しさん
22/07/08 09:29:57.41 L1lQIkzy.net
ほんとこの種の信者は迷惑だわ
普通は多人数で作業して、データー構造をRc<T>をWeak<T>にあらかじめしておくようなことはしないし、”わざと作成したのだから意図通り”とか
相手（これから学ぶ人や新人）を騙すために都合の良いことを吹き込んでいるようにしか見えない・・・
それなら自動メモリ管理ではないので、作り方/使い方により自然/意図しない使い方でリークも場合もあると明確に認めて、その分だけ
自動メモリ管理ではないないので速度が速いし、メモリー解放のタイミングもある程度コントロール出来ると誠実に話したほうが余程、印象が良いのに。
胡散臭い宗教の勧誘に見えるような態度だから叩かれる
252:デフォルトの名無しさん
22/07/08 09:30:47.62 Gv4jmnae.net
>>241
PijulもPRQLなど最近の新たな試みはRustで実装されることが多いが
それらはRust言語のためのものではなく汎用的なものであり
それらの問題点もRustとは直接関係がない
今後Rustで書かれた新たなものがどんどん増えていくだろうがそこは区別すべきところかな
一方でそれらをRust言語で使うためのクレートなどがあれば
Rustプログラミングにおいて使う特有の話なので
それらの話題自体を避けるべきではないね
253:デフォルトの名無しさん
22/07/08 09:41:28 v7XD1ZOP.net
循環参照は自然に発生しないって、コードを何も書かなければ発生しないって意味かな
254:デフォルトの名無しさん
22/07/08 09:42:55 QpPOct5C.net
>>248
新たなプロジェクトが次々とRustを採用している現実を直視しようぜ
>>249
循環参照はRust以外だと知らぬ間に発生してしまう自然なよくあるものだが
Rustでは複雑な操作で意図的に作り出さないと出現すらしない点を理解しようぜ
255:デフォルトの名無しさん
22/07/08 09:58:58.97 BqWLp+Ol.net
RAIIでメモリをケアするのは
GC方式にくらべて高速ってのはまぁそうなんだけど
それよりも
開放タイミングが決定的であることのほうが特徴
オブジェクトの生存期間によってメモリの使用期間もプログラマが管理できて嬉しい
256:デフォルトの名無しさん
22/07/08 12:01:11.06 bBPWEvXX.net
>>236
参照カウント方式と区別したいなら、「GC方式」みたいな曖昧な用語はやめて「トレーシングGC」を使おうぜ。
257:デフォルトの名無しさん
22/07/08 12:37:51 4Cg/jdLt.net
>まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
この時点で嘘だらけなんだから、それ以上読む必要無い
日本語ブログだとこういう複オジレベルの人が多数派なので
Rustを本気で学びたいやつは英語のリソースメインで学ぶことを強くすすめる
258:デフォルトの名無しさん
22/07/08 12:39:17 u4+He/YT.net
>>249
アンチは実際にプログラミングしたことがないのかね
Rc<T>自体は書き換えできないのでRc<T>だけでは循環参照を作ることができない
Rc<T>とWeak<T>は互いに対称ではないため直接置き換える対象ではない
例えばnewもRc::new(T)とWeak::new()で引数Tの有無からして異なる
さらに多人数で作業するから強い循環参照を知らぬ間に作ってしまうとの言い訳も意味不明だ
259:デフォルトの名無しさん
22/07/08 12:42:18 u4+He/YT.net
>>255
Rustは所有者がいなくなると自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全で合っている
260:デフォルトの名無しさん
22/07/08 14:56:50.59 bBPWEvXX.net
>>257
メモリを解放しないCopying GCの方が高速なんだけどなぁ。
Rustもメモリ解放しない実装なのかね？RAIIならスタック領域しかメモリを確保しないとか。
261:デフォルトの名無しさん
22/07/08 16:11:26.76 VZayErSn.net
>>258
C++もRustも仕組みは同じ
RAIIによりスコープを外れた対象のスタック部分が解放される時にそのデストラクタによってヒープ部分が解放される
汎用的にはこれが最も高速かつ利便性>>253が高い
Copying GCは特殊な環境で特殊な使い方に限定する場合は速いこともありうるがデメリットも多く一般的には使われることが少ない
使用メモリが多くなるとかコピーで値を移動させるため非常に遅いなどのデメリットの他に
そこを指す全てのポインタ値をGCのたびに全て修整しなければならないという致命的な欠陥がある
C/C++/Rustなどでスタック上に置かれたポインタ値の全てを的確に書き換えるのは不可能なので使えない
262:デフォルトの名無しさん
22/07/08 16:24:07.17 atE4xqm8.net
短時間で終了するプログラムはfree呼ばずにexitした方が高速な場合がある
copy gcも条件付きだが高速な場合がある
常にRAIIによるメモリ解放が他の手段より高速というのは誤り
100%正しいという風に断言するから枝葉の議論になるし最初から論理的に厳密な文章書いた方が良いよ
263:デフォルトの名無しさん
22/07/08 16:35:35 VZayErSn.net
>>260
これは特殊な使い方限定の話を持ち出したら意味がない話
既に書いたようにCopying GCは汎用的には使いものにならない
一般的にはRAIIによる解放が最も高速かつ利便性が高い
そのためC++でもRustでもその方法がとられている
264:デフォルトの名無しさん
22/07/08 17:23:29.15 cRmlWf2z.net
copying GCはJavaで使われているのだが
解放しない、以外でスタックの解放(malloc的なものに対する)freeより速いものはあるの？
265:デフォルトの名無しさん
22/07/08 18:32:33.29 r9xh0XFc.net
>>246
C++にもweak_ptr<>あるけど。
266:デフォルトの名無しさん
22/07/08 18:32:40.38 IcalP2aj.net
RAIIがGCより高速なら
RAIIの一例であるshared_ptrはGCの一例であるARCより高速ということになるが
どういう原理で高速になるの？
267:デフォルトの名無しさん
22/07/08 18:42:02.74 r9xh0XFc.net
でも、Firefox良く落ちるじゃん。
268:デフォルトの名無しさん
22/07/08 18:45:00.33 r9xh0XFc.net
でも、JavaはC++も20倍速いってサイト無くなったじゃん。
269:デフォルトの名無しさん
22/07/08 18:50:36.37 r9xh0XFc.net
>>261
だって、RustはC++0xのパクリじゃん。
270:デフォルトの名無しさん
22/07/08 18:52:55.66 hlO59OkW.net
>>264
shared_ptrではRAIIによって解放しない
RAIIによってデクリメントするだけ
SwiftなどでのARCが遅い理由は参照型の全てにおいてshared_ptrを使用しているような状況であるためコストが高い
271:デフォルトの名無しさん
22/07/08 18:54:07.09 r9xh0XFc.net
じゃあ、unique_ptr<>でいいじゃん。
272:デフォルトの名無しさん
22/07/08 19:10:19.78 hlO59OkW.net
>>269
unique_ptrとshared_ptrの役割の違い、動作の違いを理解できていない君が
間違えて用いてもC++ではコンパイルが通ってしまったりして実行時に問題を引き起こす
Rustは間違えて用いるとコンパイルエラーとなり通らないから安全側に救われる
273:デフォルトの名無しさん
22/07/08 20:02:01.67 A8oltmgp.net
>>268
参照型の全てにshared_ptrを利用したら何で遅くなるの？
274:デフォルトの名無しさん
22/07/08 21:48:50.65 i9Nd4OSx.net
>>257
即座に開放というのがOSに返却とか認識してたらアウトだぞ。
アロケーターなに使うかで実際の挙動は変わってくるからな。
普通しないがクソアロケーター使ったら、OSからみたらリーク同然になったりするし。
275:デフォルトの名無しさん
22/07/08 21:53:34.22 G/CdBPp1.net
所有者がいないとメモリ解放って間違ってるよね？
所有者がいてもブロックから出たら解放されるからコンパイルエラーが出てコンパイルされない
276:デフォルトの名無しさん
22/07/08 22:05:32.56 h7kEq7Ot.net
OSSでうっかり強循環参照作ってしまってた例が過去スレにあったようなと掘り返してみたところ、Part11にて発見
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
277:デフォルトの名無しさん
22/07/08 22:23:05.26 RqLk9Xjf.net
>>272
そんなバカな認識するのはオマエだけだろｗ
278:デフォルトの名無しさん
22/07/08 22:38:42.99 J0vSCVey.net
>>273
所有者がいなくなるとメモリ解放であってるよ
スコープを抜けると所有者がいなくなりデストラクタが呼ばれて管理していたヒープ領域があれば解放される
279:デフォルトの名無しさん
22/07/08 22:51:41.26 j0PLF9Z7.net
所有権とは？の話に戻っちゃうな
複製おじさんネタで散々繰り返したやつ
280:デフォルトの名無しさん
22/07/08 23:06:47.48 QSUHt/6/.net
お前ら何回同じ話ループさせたら気が済むの？
281:デフォルトの名無しさん
22/07/08 23:08:26.12 h7kEq7Ot.net
なんか合ってるのか分からんけど最近思うこと
Rustの言語仕様内に明確に含まれているのはlifetimeだけで
所有権とか所有者ってのは実はただのメタファーでしかない？
282:デフォルトの名無しさん
22/07/08 23:12:47.70 r9xh0XFc.net
C++はコンテナのアロケータと積み荷のアロケータが別とかできるくらい柔軟ですよ。
283:デフォルトの名無しさん
22/07/09 00:08:13.16 Xo3+Ls6P.net
コンセプトをコンパイラにハードコーディングして変えられないようにしたのがRustってこと？
284:デフォルトの名無しさん
22/07/09 03:43:55.29 dAPednzC.net
>>256
こいつのような気持ち悪い反吐が出る輩がいるからRustがいまいちメジャーにならない。公式ドキュメント書き換えてこいゴミ
上の文章読んでどの辺が「アンチ」だ？ゴミのくせにイキって恥かいてんじゃねーわｗ
The Rust Programming Language 日本語版
循環参照は、メモリをリークすることもある
循環参照を回避する: Rc<T>をWeak<T>に変換する
URLﾘﾝｸ(doc.rust-jp.rs)
285:デフォルトの名無しさん
22/07/09 06:36:52.71 x6eGZQ2/.net
>>276
間違ってることを合ってると強弁するのいい加減辞めなよ
286:デフォルトの名無しさん
22/07/09 07:31:04 O4my42l1.net
認める事を全くせず、大したコードも書いてないのにRustやってる事だけが自尊心だから勝手にアンチだの決めつけて
いつも人を見下して偉そう。プロジェクトチームの雰囲気はそいつがいるだけで常に最悪、チームの重荷・会社の害悪。
口癖は「意味不明」
287:デフォルトの名無しさん
22/07/09 10:34:16.63 OnqDT6DB.net
>>282
実際にコードを自分で書いて理解したほうがいいよ。
その公式Bookに書かれている内容はもちろん正しいし、
その相手>>256の書き込み内容も正しくて、
両者に矛盾はないよ。
288:デフォルトの名無しさん
22/07/09 11:42:59.26 lwwTn4Ql.net
理解してないと書いてる人間が理解してないことは多いですよね
289:デフォルトの名無しさん
22/07/09 11:50:07 lwwTn4Ql.net
どちらにしてもRust使っても気楽にコーディングできるわけでもなく
メモリ構造考えなければいけないんですね
290:デフォルトの名無しさん
22/07/09 13:10:56.08 g+WH1rkE.net
結局、C++0xのパクリじゃないですか。
C++はそこからさらに10年以上進んでるのに。
291:デフォルトの名無しさん
22/07/09 13:14:26.15 lwwTn4Ql.net
それはないかな…
どっちも一長一短で視点がぼやけます
292:デフォルトの名無しさん
22/07/09 13:41:18.89 ByPaZ1uJ.net
>>279
説明用に作った概念ではあるけどRustの根幹に関わる重要な概念なので
「ただのメタファーでしかない」という言い方は微妙
自分の好き勝手に解釈した内容を公式見解かのように流布する輩を助長することになるから
293:デフォルトの名無しさん
22/07/09 14:19:07.01 g+WH1rkE.net
パクリ元のC++で所有権と呼ばれてるからでしょ。
294:デフォルトの名無しさん
22/07/09 14:21:22.91 g+WH1rkE.net
C++は高機能すぎて分けワカメなので、初心者用に出来ることを減らしますという、ジェネリクス界のPythonがRustでは？
295:デフォルトの名無しさん
22/07/09 14:57:08.15 gD3yh/Bo.net
>>283
見たけど正しいやん
間違ってる！とウソをつくけど間違ってる点を指摘できないいつもの人かね？
296:デフォルトの名無しさん
22/07/09 15:04:05.66 g+WH1rkE.net
誰も所有してないのに解放されないなら意味ないじゃん。
297:デフォルトの名無しさん
22/07/09 15:25:00.91 3oDyg2LH.net
>>294
ヒープ領域に対して誰も所有(利用)しなくなった時に
・自動解放しない(要手動解放) ← C C++(下記除く)
・即座に自動解放する ← Rust C++(unique_ptrなど使用時)
・GCする時になってから自動解放する ← ほとんどのGC言語
298:デフォルトの名無しさん
22/07/09 15:36:21.95 lXmK1DKz.net
Cで書くにしても、今時のCLIツールならヒープなんか解放せず放置しても実用上問題ないよね
299:デフォルトの名無しさん
22/07/09 16:18:04 y0LX8Rgp.net
そもそも間違ってるとは何と照らし合わせて間違ってるという主張なのか
「そうあるべきではない」というべき論なら前提を明確にしない限り知らんがなとしか言えん
300:デフォルトの名無しさん
22/07/09 16:36:33 g+WH1rkE.net
>>295
いや、C++はアロケート時にアロケータを選択するから。
デフォルトが準備されてるだけで。
当然、GCもあり得るから。
301:デフォルトの名無しさん
22/07/09 16:39:05 g+WH1rkE.net
だめだ、こいつに聞いても無駄だ。
誰かわかるやつ居ないのか。
302:デフォルトの名無しさん
22/07/09 16:52:06 3+oPDqor.net
この板で最も勢いのあるスレになりましたな
303:デフォルトの名無しさん
22/07/09 17:15:21.88 ziCGmT1x.net
>>284
アンチ君は皆に論破されると毎回
思い込みの仮想敵を作り人格攻撃を始めて逃避するようだが
そんな下らないことはアンチスレでやってほしい
304:デフォルトの名無しさん
22/07/09 17:29:07.29 g+WH1rkE.net
自分より詳しいやつは全部アンチか。
それじゃダメだろ。
305:デフォルトの名無しさん
22/07/09 17:45:35.96 bJtJfEbP.net
Rust信者スレ作ったらそっちに移動してくれますか？
306:デフォルトの名無しさん
22/07/09 17:54:41.59 g+WH1rkE.net
つまり、C++0xをパクって機能限定して簡単にしたのがRustだろ？
307:デフォルトの名無しさん
22/07/09 17:58:46.63 QKZ/1qEu.net
>>295
プログラミング言語の進化の中で、
そのメモリ自動解放における高速性と安全性の両立をRustが初めて実現したってことになるのかな
308:デフォルトの名無しさん
22/07/09 18:04:41.00 SVLGLpJF.net
Region-based Memory Management の構想は Cyclone から始まってる。
この段階では実用化したとは呼びにくいが、実現は出来ていた。
309:デフォルトの名無しさん
22/07/09 18:22:19.04 HoR4NOuF.net
>>304
C++以外からもいろいろパクってるからその言い方だと不正確に思う
310:デフォルトの名無しさん
22/07/09 18:46:05.22 hyXSHlQu.net
正確にはこうだな
プログラミング言語の進化の中で
メモリ自動解放における高速性と安全性の両立を実現した初めての実用的な言語がRust
311:デフォルトの名無しさん
22/07/09 18:55:55 FBd+xess.net
実用的の定義が無いので不正確です
312:デフォルトの名無しさん
22/07/09 18:58:45 g+WH1rkE.net
C++0xがなかなか標準化されないので、それなら自分で作ろうと立ち上がったと本人が言ってるじゃん。
313:デフォルトの名無しさん
22/07/09 19:05:24 hyXSHlQu.net
>>309
そこは常識の範囲内で実用的をどのように定義しても>>308を満たすのはRustだけだから問題ない
314:デフォルトの名無しさん
22/07/09 19:22:48.72 kZfneOfi.net
別にC/C++でもちゃんと作れば高速性と安全性は両立してるよ
ちゃんと作るのが難しいかどうかの話でしかないだろ
315:デフォルトの名無しさん
22/07/09 19:29:47.99 TbjkUF4v.net
>>312
C/C++では不可能
うっかり危険なコードを書いてもコンパイラが通してしまう
Rustはコンパイラが指摘して通さないため安全
316:デフォルトの名無しさん
22/07/09 19:30:20.48 6ug5/LDh.net
難しさを度外視してちゃんと作ればいいと言うならアセンブラでも同じわけで。
317:デフォルトの名無しさん
22/07/09 19:36:03.58 hyXSHlQu.net
>>312
残念ながらCとC++は安全性を満たしていない
現状Rustだけが安全性と高速性を両立させている
318:デフォルトの名無しさん
22/07/09 19:48:49.13 HoR4NOuF.net
>>315
rustだけが満たしている根拠教えて
319:デフォルトの名無しさん
22/07/09 19:51:24.99 zb7jG/MW.net
じゃあChromeやSafari、Edgeじゃなく、お前のブラウザーふぁいあーふぉっくすにしろよ？安全じゃないんだろ？ぷゲラ
320:デフォルトの名無しさん
22/07/09 19:52:51.29 FBd+xess.net
うっかり前提条件が保証できていないunsafe fnの呼び出しを書いてもRustコンパイラは通してしまうではないですか
321:デフォルトの名無しさん
22/07/09 20:07:34 kZfneOfi.net
>>313,315
ああ、Rustが決めた安全性か
まあ>>274みたいなのには目をつぶるならそれでいいんじゃねw
はたから見たらオナニーにしか見えないけど
>>314
そうだよ、突き詰めたらレベルの違いでしかない
普通のひとは突き詰めること自体が馬鹿らしいって思うからこんなことで揉めたりしないけど
322:デフォルトの名無しさん
22/07/09 20:08:04 TbjkUF4v.net
>>318
うっかりunsafe関数を呼び出しのは不可能
Rustコンパイラが通さない
323:デフォルトの名無しさん
22/07/09 20:29:03 r2wQepG1.net
C++が敗北した理由が安全性を疎かにしたことは事実だけど
当時は安全性なんてそこまで重視されていなくて速ければよい時代だった
さらに安全性と速さを両立させる使い物になるプログラミング言語が出てくるとは想像できなかった
ここ数年でC++がようやく退場する時代となったたけでありそれ以前はC++の天下であった
324:デフォルトの名無しさん
22/07/09 20:47:42.85 FBd+xess.net
― フクオジ書 12:4-5
325:デフォルトの名無しさん
22/07/09 21:21:56.68 6ug5/LDh.net
>>319
そのレベルの違いが重要なわけじゃん
326:デフォルトの名無しさん
22/07/09 21:26:07.86 rB16NsHU.net
>>318
実際にプログラミングをしたことがないからアンチはそんな間違った発言をうっかりしてしまう
327:デフォルトの名無しさん
22/07/09 21:36:29.93 TbjkUF4v.net
>>319
天と地ほどの差がある
コンパイル時点でエラーとして弾いてくれてコンパイラが修整すべき点をアドバイスしてくれるRust
コンパイラは何も言わずに通してしまい実行運用中に問題が発覚するC/C++
328:デフォルトの名無しさん
22/07/09 21:37:18.68 FBd+xess.net
「前提条件が保証できていない」に触れていないのはうっかり読み飛ばしたのかな？それともわざとかな？
329:デフォルトの名無しさん
22/07/09 21:40:36.28 N6dBVNoC.net
マ板のコテハンが常駐するとどのスレも不毛地帯になるな
330:デフォルトの名無しさん
22/07/09 21:51:31.23 8h5AdXRe.net
>>323
レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ
>>325
> まあ>>274みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない
331:デフォルトの名無しさん
22/07/09 22:07:58.78 dPnpzXnF.net
アンチ連呼おじさんの主張は「おまえらはプログラミングしたことが無い」
332:デフォルトの名無しさん
22/07/09 22:17:01.66 5J/+jd/X.net
話は単純
RustはC++における問題のうちみんなが挙げてるような重要な部分を解決してしまった
それにプラスしてC++よりpRustの方がプログラミングしやすい点も非常に大きい
333:デフォルトの名無しさん
22/07/09 22:18:10.11 GNVCknQf.net
コテハンとは一体
334:デフォルトの名無しさん
22/07/09 22:29:14.97 FBd+xess.net
>>330
そうだな
そしてRustが解決したという「問題」の範囲を大きく見せて誇大広告している人がいたのでぶっ叩かれたと
単純な話だ
335:デフォルトの名無しさん
22/07/09 22:30:12.39 dcG9hbvO.net
>>329
「おまえらはもうプログラミングしていないだろ」
じゃないのか
若い時はしていたんだろうが、おっさん・爺になって仕事ではもうプログラミングしていない
比較は必死にするが実際のRustプログラミング話が無いおじさん・爺のRustスレだからな
336:デフォルトの名無しさん
22/07/09 22:36:53.48 qKBLdUt5.net
年寄りはRustに構わないで欲しい
黙ってCでも書いてて
337:デフォルトの名無しさん
22/07/09 22:44:39.49 3KUXTO+D.net
>>332
Linus含めたLinux開発陣も同じ結論
C++はダメな言語なので不採用
Rustは良い言語なので採用
338:デフォルトの名無しさん
22/07/09 22:46:38.67 dcG9hbvO.net
>>334
歳をとってもうプログラミングしていないん(実質現役引退)だから
Cすら仕事で書いていないだろ
339:デフォルトの名無しさん
22/07/09 22:59:01.59 hVKa6Imk.net
> 287 名前：デフォルトの名無しさん [sage] 投稿日：2022/07/09(土) 11:50:07.31 ID:lwwTn4Ql [2/3]
> どちらにしてもRust使っても気楽にコーディングできるわけでもなく
> メモリ構造考えなければいけないんですね
読んでなるほどなと思った
よくわかんないけどとりあえず動けばいいという人と、
ちゃんと理解して自分の思う通りに動かしたい人の違いだなと
340:デフォルトの名無しさん
22/07/09 23:05:49.23 dcG9hbvO.net
>>335
俺,win使っているが
そのよい言語のRustをコンパイルするのに(C/C++する気ないのに)駄目な言語のmsvcを入れないと
とコンパイルできないてのがな
で、なんでmsvc必要なんだ？
ひょっとしたら、linuxでもgccとかを入れないと駄目なのか
341:デフォルトの名無しさん
22/07/09 23:15:33.27 yHOdCoxc.net
>>337
その人があまりにも知識不足の可能性が高い
Rustでも他の言語と同様に(C互換FFIを除いて)メモリ構造なんて公開も保証もしていない
ほとんどのプログラミング言語はメモリ構造なんて低いレベルで使うものではなくもっと抽象度の高い部分でその定義と保証がなされるもの
だからRustでも他の言語と同様にメモリ構造は考えなくて良いし考えてはいけない
メモリ構造は言語として保証していないし保証しないからこそ大胆なコンパイル最適化を行なっている
話を戻してその人はメモリ構造ではなくデータ構造と言いたかったのではないか？
データ構造は他の言語と同様にRustでも考えなければならない
それがプログラミングの中心だから
342:デフォルトの名無しさん
22/07/09 23:30:15.11 hVKa6Imk.net
>>338
そんなこと知らずに、そういうレスしているところにドン引きだな
自分で調べた？
調べたら、その結果をここで報告よろしく
343:デフォルトの名無しさん
22/07/09 23:45:37.10 yHOdCoxc.net
>>338
Rust批判派があまりにも知識不足で驚いた
ちなみにこちらはLinuxだがrustc(＝Rustコンパイラ)だけあればコンパイルできる
344:デフォルトの名無しさん
22/07/10 00:12:02.83 VXHYDjJa.net
>>339
SwiftとかABI stabilityを実現してるやつは仕様としてメモリレイアウトを定義して公開してるやろ
345:デフォルトの名無しさん
22/07/10 00:13:44.27 ZPTgd3k2.net
>>341
["rust linker cc not found"] [検索]
346:デフォルトの名無しさん
22/07/10 00:16:59.60
347:CjJVLv20.net
348:デフォルトの名無しさん
22/07/10 00:18:51.99 z1Ut0loV.net
隔離スレ復活させないとノイズだらけできつくなってきた
349:デフォルトの名無しさん
22/07/10 00:30:08.21 tvXCky2C.net
>>342
そのABIはコンパイル後のバイナリのフォーマットの話だぜ
今回の『気楽にコーディングできるわけでもなくメモリ構造考えなければいけないんですね』はプログラミングの際の話だから関係ない
プログラミングする上でメモリ構造は考えなくていい
例えばRustの型VecやStringなども各々のがどんなメモリ構造になるかは規定も公開もない
もちろんソースコードを読めば内部のデータ構造までは分かるがそれに依存してコードを書いてはいけないし依存できないよう抽象化されたインタフェースのみ規定公開されている
350:デフォルトの名無しさん
22/07/10 00:33:22.94 tvXCky2C.net
>>345
同感
アンチ活動は別のスレでやってほしい
ここ本スレでやるのはマナー違反だと思う
今後Rustへのアンチ活動は以下のスレへ書くこと
Rustアンチスレ
ｽﾚﾘﾝｸ(tech板)
351:デフォルトの名無しさん
22/07/10 01:01:37.00 /Pm6re6i.net
複オジに絡んだ俺がバカだったわw
352:デフォルトの名無しさん
22/07/10 01:02:48.63 qjKEOyYX.net
>>343
なるほど、
>341
>ちなみにこちらはLinuxだがrustc(＝Rustコンパイラ)だけあればコンパイルできる
は、比較的新しいrustを使えばgcc(リンカ)イラネってことか
rustでリンカ作った方がgccのリンカよりずっと良いものになるだろうからな
353:デフォルトの名無しさん
22/07/10 01:09:37 ZPTgd3k2.net
ｽﾚﾘﾝｸ(tech板)
隔離対象をアンチに限定しない汎用隔離スレ立てた
もう全部こっちでやってくれ
354:デフォルトの名無しさん
22/07/10 01:48:41.75 LxkGLd0V.net
>>350
おまえ低能だな
そんな内容と設定ではそのスレは過疎って終わることくらい予測できるだろ？
355:デフォルトの名無しさん
22/07/10 04:45:49.56 T5qatPVB.net
荒らしてるのはLinux板の連中か。
356:デフォルトの名無しさん
22/07/10 08:32:10.98 VKvLuEGz.net
Cellを使っていて思ったんだが例えば
trait CellUpdateWith<T> {
fn update_with(&self, f: impl FnOnce(&mut T));
}
impl<T: Default> CellUpdateWith<T> for Cell<T> {
#[inline]
fn update_with(&self, f: impl FnOnce(&mut T)) {
let mut inner = self.take();
f(&mut inner);
self.set(inner);
}
}
このようにメソッドupdate_with()を用意しておけば
内部更新もわかりやすく記述できるな
let foo = Cell::new(vec![1, 2, 3]);
foo.update_with(|v| v.push(7));
身代わりにself.take()でdefault値を入れてCellから取り出し
self.set()でCellへ戻すという無駄な操作は最適化で消えるようだ
URLﾘﾝｸ(godbolt.org)
357:デフォルトの名無しさん
22/07/10 12:00:25.54 oYFJk9+G.net
>>351
それをわざと狙ってんだろうなww
いかにもやりそうなこと
358:デフォルトの名無しさん
22/07/10 13:59:32.22 blpABUiA.net
>>354
この手の人は自分が排除されることを最も恐れてるんだよ
そうならないための策ならなりふり構わず何でもやる
自分が排除される側にいる自覚がなければそんなことやらない
359:デフォルトの名無しさん
22/07/10 19:54:18.59 /ZDhY4rW.net
>>308
糞言語で自意識過剰の公開オナニーをする信者、マジきもい
360:デフォルトの名無しさん
22/07/10 23:37:14 nSquZ6Rt.net
>>308
プログラミング言語界に大革命をもたらした画期的な言語だな
361:デフォルトの名無しさん
22/07/11 00:14:06.35 triNevnR.net
15年近くc/c++触ってなくて(ずっとjava触ってた)
rustの所有権とか何故こんな仕様になったのか経緯がわからなくて
最近のc11以降の仕様の？unique_ptrとかshared_ptrとかstd::moveとかstd::forward学んで
(元々boost にスマートポインタがあった記憶があるけど記憶が曖昧)
どうしてこう言う機能が出来たのか少しわかった
今のc++はconst 地獄だしとにかくコードが汚くなる
こりゃrust の方が良いわ
あと型名の付け方が好き。u32とかf32とか
昔cで書いてた頃typedefでわざわざ定義してたよ
362:デフォルトの名無しさん
22/07/11 10:40:05.73 1W23UOpt.net
const 地獄 ← 判る
static_cast うぜー ← 判る
Rust 万歳 ← 判らん
363:デフォルトの名無しさん
22/07/13 23:59:24.88 qlTJEO+a.net
>>353
もっと便利にできるぜ
use std::cell::Cell;
trait CellWithMethod<T> {
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R;
}
impl<T: Default> CellWithMethod<T> for Cell<T> {
#[inline]
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R {
let mut inner = self.take();
let result = f(&mut inner);
self.set(inner);
result
}
}
fn main() {
let foo = Cell::new(vec![1, 2, 3]);
foo.with(|v| v.push(7));
assert_eq!(4, foo.with(|v| v.len()));
assert_eq!(7, foo.with(|v| v[3]));
assert_eq!(vec![1, 2, 3, 7], foo.with(|v| v.clone()));
}
364:デフォルトの名無しさん
22/07/15 21:39:01.85 qV4GyRtM.net
>>360
CellでVec使えるのか
何か間違って学習していた
URLﾘﾝｸ(qiita.com)
＞ 1. Cellの中身の型はCopyをimplしていなければならない
URLﾘﾝｸ(dev.classmethod.jp)
＞ ・Cellの中の型はCopyトレイト実装が必須
URLﾘﾝｸ(qiita.com)
＞ Cell は値の "移動" によって内部可変性を実装するため <T> は Copy 可能な "値" 向けのコンテナーで、
＞ i32 や Copy trait を実装した何かを扱うのに"適した"コンテナーです。
URLﾘﾝｸ(zenn.dev)
＞ Cell<T> の大きな制約として， T は Copy トレイト境界があることです．
実際にはCellはCopyを要求していない
やってみたら>>360のコードが動いてCell<Vec<_>>が使えた
365:デフォルトの名無しさん
22/07/15 22:48:49.30 fFdw7/F8.net
#[derive(Clone)]のコーナーケースに遭遇した
URLﾘﾝｸ(play.rust-lang.org)
366:デフォルトの名無しさん
22/07/15 22:50:32.95 SBkpZpFk.net
やっぱりrustcはバグが多いね
367:デフォルトの名無しさん
22/07/15 23:12:58.85 nxNpCMHU.net
>>362
標準ライブラリのderiveは型パラメータに無条件にトレイト制約課すようになってるから
derivativeみたいな制約を自分で指定できるcrateを使うと良いよ
URLﾘﾝｸ(github.com)
368:デフォルトの名無しさん
22/07/16 00:28:56.56 730D9OZt.net
>>361
get()がCopyを要求するからってのもあるけど
古いThe BookにはCellはCopy専用・RefCellはCopy以外も使えるという説明があったので
それが日本語訳とかで残ってたんじゃないかな
369:デフォルトの名無しさん
22/07/16 23:27:56 MG4+BxCd.net
>>360
!Syncで参照無しならデータ競合を起こさない、という点を使った用法だな
便利だから公式サポートすればいいのにな
370:デフォルトの名無しさん
22/07/20 00:26:56.65 XqWqiApN.net
StackOverflowで「好きな言語No.1」だそうだが、調査方法に問題が有り、
二位以下も聞いた事が無いような言語ばかり。
371:デフォルトの名無しさん
22/07/20 01:36:05.55 bF1qPY0V.net
>>367
お前の観測範囲が狭いだけ。
372:デフォルトの名無しさん
22/07/20 08:04:49 XbfHqe9W.net
CarbonとかいうRustとC++のあいのこみたいなのが出てきた
373:デフォルトの名無しさん
22/07/20 12:35:25 FCfDFeLf.net
Carbonは最強言語ぞ
374:デフォルトの名無しさん
22/07/20 12:39:05 MUkQlR/e.net
RustがCarbonに勝ててるところが見つからないな
375:デフォルトの名無しさん
22/07/20 12:45:18 ThH+Z+BW.net
Rust vs Carbonスレ立ててそっちでやれ
376:デフォルトの名無しさん
22/07/20 13:30:14 S6pSKHOi.net
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい
377:デフォルトの名無しさん
22/07/20 13:30:16 S6pSKHOi.net
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい
378:デフォルトの名無しさん
22/07/20 14:11:36.68 xLuB33a9.net
1.0が出てからにしてください
379:デフォルトの名無しさん
22/07/20 14:52:25.57 IMMZUJf4.net
CarbonとRustは名称の紛らわしさではどっこいどっこいだな
380:デフォルトの名無しさん
22/07/20 14:54:39.84 igxVbWbR.net
ほーん
URLﾘﾝｸ(github.com)
381:デフォルトの名無しさん
22/07/20 17:02:14.65 xLuB33a9.net
とりあえずcarbon自体のコードの8割がcarbonで書かれるエコシステムが確立してからだろう
382:デフォルトの名無しさん
22/07/20 19:50:56 hGf+NvAH.net
JSのTypeScript
C++のCarbonって感じかね
どうなるんだろうね
確かにC++を無くすのは勿体ないがまだ0.1か いつ1.0になるかなぁ 10年後くらいか
Rustよりも難しくはなくメモリ管理も楽になるのかな
383:デフォルトの名無しさん
22/07/20 20:00:37 xdIX6xM1.net
Rustはあらゆる面で安全と高速の両立する抽象化を実現した言語だから
現在のCarbonのドキュメントを見る限りRustの領分に入ってきていないでしょう
それよりもC++と書き方がかなり変わっていて互換性がなく別言語の様相でCarbonは中途半端な立ち位置に見える
384:デフォルトの名無しさん
22/07/20 20:01:46 sReX4jGj.net
Carbonは「Rustが難しすぎるから簡単にしたい」とは言ってなくて、C++と相互運用できる言語を目指してるだけっぽいからなぁ
結果的にRustより難しくなっても驚かないけど
385:デフォルトの名無しさん
22/07/20 20:33:50.16 sReX4jGj.net
そもそもCarbonの使い所ってC++のレガシーコードが大量にあるところだから
C++も当然マスターしてないといけなくて、学習量は明らかに増えてる気もする
386:デフォルトの名無しさん
22/07/20 20:52:36.69 oyesoq1v.net
ドラゴンボールのゲームでドドリアの色違いでカーボスと言うのがいたのを思い出した
どちらかと言うとザーボンの色違いがカーボスなら納得なんだけど…
387:デフォルトの名無しさん
22/07/20 21:27:24.19 mJssGRdK.net
Carbonって中途半端すぎね？
まともな言語設計者ならオブジェクト指向もう採用しないと思うんやけどなんか継承機能もあるみたいだし
なんでこういう中途半端のところもC++参考するんだよこういうところこそRust参考にしろよ
388:デフォルトの名無しさん
22/07/20 21:44:56.66 qLBZujX3.net
>>384
C++とシームレスに相互運用することが最優先課題だから、そこはC++と同じにしておかないとそもそも存在意義がなくなる
389:デフォルトの名無しさん
22/07/20 22:16:07.31 gROTqHCf.net
ま、2-3年後にどうなってるかだな
バックにGoogleいるらしいから開発終了なんてことはなさそうだが
390:デフォルトの名無しさん
22/07/20 22:21:24.71 9oJrmZpV.net
>>386
逆じゃね？企業だからこそ開発者の熱意とか関係なくコストに見合わないとなれば容赦なく切られるかと
Goみたいに社内で使うことが確定してしまえば安泰だけど
391:デフォルトの名無しさん
22/07/20 22:28:16.35 3tivAU0I.net
SDGsの流れ的にCarbonは使われなくなる運命
392:デフォルトの名無しさん
22/07/20 22:43:27.67 xLuB33a9.net
なる、元素記号Cからの名称か
393:デフォルトの名無しさん
22/07/21 00:45:01.09 g1dckGB4.net
5年たったらまたオブジェクト指向が再燃してるかもしれない
と言うか業務では大規模開発にはオブジェクト指向が必須なんだな
モジュールでは全体が見通せない
394:はちみつ餃子
22/07/21 00:52:44.62 /hG5LMVG.net
話題が逸れるが >>384 が C++ の型システムをオブジェクト指向と呼んでるっぽいのが気になる。
オブジェクト指向はオブジェクト同士がメッセージを送りあう形でプログラムを構成する思想のことで、
それを言語機能としてどのように支援するのかには様々なバリエーションが有りうる。
型システムとは独立した概念だよ。
ふんわりした概念なので定義によるが Rust もオブジェクト指向 (をサポートする) 言語に分類されることはある。
それはそれとして、 C++ の型システムもベストとは言えないが最悪というわけでもない。
実際にかなり多くの場面で活用されている実績は認めないといけない。
要するに「この程度で十分」ではあるんだよ。
C++ の本当につらいところは C から引き継いだガバガバさや歴史的事情のワケわからんところであって、
型システムの根本的な改善はそれほど切実に必要だとは思わないな。
C++ が駄目だと否定するんじゃなくて C++ みたいなことを C++ より上手くやるという方向性はアリだろう。
395:デフォルトの名無しさん
22/07/21 00:54:52.22 0vTmbBj3.net
話題が逸れるが、...で読む気失せたわ
396:デフォルトの名無しさん
22/07/21 00:58:24.47 MOkaWH3B.net
>>391
前半は正しいが
後半のクラス継承システム程度で十分という点には賛同しかねる
今までの現実の多くのケースはクラス継承システムしか使えない環境だったから無理矢理にそれを使っているだけである
397:デフォルトの名無しさん
22/07/21 01:00:56.06 g1dckGB4.net
似たような機能のものを大量に書く場合どのように実装するのが楽かどのように管理するのが楽か
モジュールではないな
398:デフォルトの名無しさん
22/07/21 01:15:53.78 MOkaWH3B.net
>>394
その点ではRustもC++も同じオブジェクト指向なので何を主張したいのかわからない
Rustの基本はselfに見られるようにオブジェクト指向
違いはC++がクラス継承なのに対してRustはトレイト
ジェネリックから見るトレイト境界による型制約となり
逆の視点から見るとトレイト付加によるメソッド拡張となる
399:デフォルトの名無しさん
22/07/21 03:25:39.61 DiLbgRco.net
いくらRustが有望だと言われていても、ポインターがないと使いづらい場面ってあるよな
ツリー構造とか、ポインターなしで大して実行速度も落とさず記述する技があるようだけど・・・・大掛かりなことをするのなら労力を割くのもいいけど、ちょっと使うだけには労力がかかりすぎる
400:デフォルトの名無しさん
22/07/21 04:26:36.96 VmE9g8Ff.net
ポインタあるじゃん
401:デフォルトの名無しさん
22/07/21 05:01:15.84 hbmQrHo+.net
>>396
Rustにも様々なポインタがあり
様々な仕様と様々な安全度合いで記述できる
402:デフォルトの名無しさん
22/07/21 08:09:40 HHuzACnI.net
>>385
Rustからわかるように、求められているのは膝を打ち抜く自由の無いc++であり、コーダーに使わせる言語。
unsafeはc++で実装すりゃいいので、継承とかは使うだけに限定するという手もある。
403:デフォルトの名無しさん
22/07/21 13:48:15.98 xy799ZfA.net
>>391
話し手がなにをオブジェクト指向の言語としているのかどうか判断する程度の読解力は持ち合わせてくれないかな？
RustはC++のように継承を導入することによってもたらされる問題を回避するためにclassじゃなくてtraitを基本的なプログラムの構成要素として採用することで既存のオブジェクト指向言語と一線を画すというプログラミング言語史に残る進歩を達成していた
404:デフォルトの名無しさん
22/07/21 15:49:13.07 Q1uK5/Rv.net
>>400
Haskellの型クラスの方が先だろ。
「プログラミング言語史に残る進歩」とかさすがに恥ずかしいレベル。
405:デフォルトの名無しさん
22/07/21 16:58:11.12 xy799ZfA.net
>>401
RustのtraitをただのHaskellの型クラスの類似物としてしか認識できないのはお前が単に馬鹿だから
Rustのtraitは本来継承もmixinとも違ったC++のclassより洗練された新たなプログラムの構成要素だっていう側面が理解できていない馬鹿が多すぎる
ただRustではこのtraitという構成要素に実用上の面から今度は型クラスという機能も持たせているというだけで話の順序が違う
こんぐらいRust書いていたらtraitには単に型クラスだけの意義だけじゃないってわかると思うんやがお前にはそういった才能もないただのネット上で繰り返し喧伝されている宣伝にしか注目する脳がないいわばにわかの部類の奴だということがわかった
406:デフォルトの名無しさん
22/07/21 17:50:57.39 eNA5340i.net
traitの画期的な部分はc++のabstract classで実現できないの？
407:デフォルトの名無しさん
22/07/21 17:54:16 F7Gtvv1S.net
>>402
何が言いたいのかよくわからないけど型クラスになくてtraitにあるものって何？
associate typeはrustの発明だと思うけど、そういうこと言いたいわけでもなさそうだし
408:デフォルトの名無しさん
22/07/21 18:07:36 ySHdWcK4.net
自分が崇拝する神だけが唯一正しいと妄信して
他人の考え方を徹底的に糾弾排斥するのがカルト
カルト化した人間とまともな議論ができると思うな
409:デフォルトの名無しさん
22/07/21 18:19:30.67 xy799ZfA.net
>>404
公式サイトにすら出典付きで載ってあることなんだけどなんでここで聞くの？
繰り返しになるがtraitの型クラス以外の側面に気づけないのはお前が単に馬鹿なだけ
410:デフォルトの名無しさん
22/07/21 19:01:28.92 HGs+QJMA.net
>>406
そういうのを誘導しないからお前はダメなんだよ。
prev.rust-lang.org/ja-JP/faq.html#how-do-rust-traits-compare-to-haskell-typeclasses
How do Rust traits compare to Haskell typeclasses?
Rust traits are similar to Haskell typeclasses, but are currently not as powerful, as Rust cannot express higher-kinded types. Rust’s associated types are equivalent to Haskell type families.
411:デフォルトの名無しさん
22/07/21 19:15:30.44 F7Gtvv1S.net
>>407
traitの方が表現力低いって言ってるじゃねーか
412:デフォルトの名無しさん
22/07/21 20:10:50.68 SY914jbi.net
レスバスレ使ってくれませんか？
413:デフォルトの名無しさん
22/07/21 20:48:28.30 rGFlKcYB.net
>>407
それURLがprevで始まっているように古い情報ページ
わざわざそれを出すのは何か意図がある？
414:デフォルトの名無しさん
22/07/21 21:43:04.55 vaotA28G.net
>>408
正しい情報を啓蒙するのは面倒だということを知らしめる意図じゃない？
415:デフォルトの名無しさん
22/07/21 21:59:42 vJeGD7jb.net
>>404
Rustのトレイトは
トレイト境界を実装で指定できるだけでなく
トレイト境界を型宣言でも指定できるなど
様々な点で型クラスと異なるよね？
416:デフォルトの名無しさん
22/07/21 22:56:58.50 crFoTo11.net
幽霊型🥺
417:デフォルトの名無しさん
22/07/21 23:06:53.32 XUR5FOR
418:i.net
419:デフォルトの名無しさん
22/07/21 23:56:47.54 vrEITS91.net
>>412
トレイトに関しては当然Haskellの型クラス由来の部分が多いけど互いに片方にしかないものもあり異なる側面があるわけか
420:デフォルトの名無しさん
22/07/22 00:02:56.00 Dec8FkF+.net
>>412
よくわかんないからコードで書いて
421:デフォルトの名無しさん
22/07/22 00:07:23.73 3PGiuxDq.net
今のところ型システムは完全下位互換だよ
422:デフォルトの名無しさん
22/07/22 00:22:12.08 hXBfLf2I.net
>>416
普通のこれだろ
struct Foo<T: Trait1 + Trait2> {
inner: T,
}
423:デフォルトの名無しさん
22/07/22 00:32:54.07 /9LzCqck.net
>>418
これが>>402が言う型クラス以上の意義があるものなの？
424:デフォルトの名無しさん
22/07/22 00:45:08.67 hXBfLf2I.net
402の話は402に聞け
少なくとも>>418は型定義の時点で制約できるから意義がある
425:デフォルトの名無しさん
22/07/22 00:46:45.91 Dec8FkF+.net
>>418
-XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language.
426:デフォルトの名無しさん
22/07/22 01:09:40.70 hXBfLf2I.net
>>421
いきなり何かわからない話を向けられても困る
解説せよ
427:デフォルトの名無しさん
22/07/22 01:43:49.12 kvE65+oR.net
トレイトのどの辺が「洗練された新たなプログラム構成要素」と感じるのか全然分からん
俺の中ではインターフェースと一緒の扱い
Rustが画期的だったのはOwnership/Referenceルール + Borrow Checker
この点に異論ある人はいないよね？
428:デフォルトの名無しさん
22/07/22 02:15:42.10 g+hZIhYV.net
>>423
一般的なインタフェースなんて
Trait Boundsもimpl Traitもdyn Traitもないゴミ
>>419
その点でも差異があるだけでなく
Rustのトレイトは基本概念こそHaskellの型クラスと同じだがそれ以外は各々の言語に適応してかなり異なる
429:はちみつ餃子
22/07/22 03:26:24.88 fX2QhDiX.net
>>424
そりゃ言語に合わせて変えるところがあるのは当たり前だが、
基本概念が同じだというなら類似物ではあるだろう。
カテゴリ分けしたらおおよそ同じところに分類するよ……。
430:デフォルトの名無しさん
22/07/22 03:47:26.49 u1/oKmBi.net
>>425
それは違うのではないかな
例えばHaskellはRustのtraitでのdyn(動的解決)とimpl(静的解決)といった重要な基本概念を欠いているよ
431:デフォルトの名無しさん
22/07/22 05:52:26 FhKnOINS.net
C++の欠点は、何でもできること。
その欠点をなくして、わかりやすくしたのがRust。
バイナリ界のJavaと言い換えても良い。
ほとんどのプログラマはC++よりRustを使うほうが良い。
432:デフォルトの名無しさん
22/07/22 08:04:03.49 FDKNW5k7.net
>>410
だから最新情報に誘導しろよ。
無能か？
433:デフォルトの名無しさん
22/07/22 09:31:13.18 8cs6kRrX.net
>>427
これからRustはIT土方専用言語になっていくんだろうなあ
434:デフォルトの名無しさん
22/07/22 09:55:09.86 aK9LU/qI.net
>>424
>一般的なインタフェースなんて
>Trait Boundsもimpl Traitもdyn Traitもないゴミ
言語化できてないから本質を理解できていように見える
Trait Boundはジェネリック型の型制約で一般的なインターフェイスも型制約として機能する
一般的なインターフェイスは動的ディスパッチなのでdyn Trait相当
impl Traitがmonomorphizationのことを言ってるならそれはTraitの機能じゃなくGenericsの機能
C++で20年前から使えるよね？
C++以外でもSwiftみたいに一部の言語はGenericsのspecialization機能があるけど一般的にはオーバーロード使ってstatic dispatchにすることが可能
435:デフォルトの名無しさん
22/07/22 10:57:57.42 GQh1j6M0.net
>>418
javaのgenericsでextends使うとできるやつかな？
436:デフォルトの名無しさん
22/07/22 11:30:46.07 emgmw9dd.net
Java厨は出て来ないで下さいうざいだけです
437:デフォルトの名無しさん
22/07/22 11:34:22.85 LVIZaCij.net
>>429
msとかgoogleとかの狙いはそうだろ。
土方がコーティングしてもバグが入り込まない。
その代わり難易度が上がっているからコーダーの単価上がりそうだけど、msとかgoogleはそんなの気にしないだろうし。
438:デフォルトの名無しさん
22/07/22 13:14:37.08 GQh1j6M0.net
>>432
rustの画期的な部分なんだろ？言い返せないのかよダサいなお前
本当に革新的なのは>>423あたりなんじゃないの
439:デフォルトの名無しさん
22/07/22 14:36:57 ZDp8+ZKO.net
kumagiとか見てると、google社員でもc++触らせたらあかん奴ってのが結構いるのがわかる。
440:デフォルトの名無しさん
22/07/22 14:59:23.46 hnGDX2CP.net
>>431
Javaのジェネリクスは変な制限が多く
インタフェース指定していって問題があってもコンパイルエラーとならず実行時エラーとなるものがあるなどJavaは論外
他にも問題多すぎてRustに何ひとつ勝てないから新システムを機会にJava→Rustとなったものも出てきている
441:デフォルトの名無しさん
22/07/22 15:43:33.15 yLavWCdC.net
>>434
Ownership/reference自体はc++にもあるからあんまり革新的とは思えないな。
コールスタック&RAIIを中心にしてメモリ管理ルールを再構築して、厄介なヒープメモリの管理をできるだけ避けて高速化しているのが特徴だと思う。
革新的なのはそのルールを徹底していることくらいかと。
442:デフォルトの名無しさん
22/07/22 17:12:05.71 efNbKFVE.net
安全性とゼロコスト抽象化の制約下で開発効率を高める仕組みを導入していることがRustの特徴だよね
言語仕様や処理系実装上での苦労や工夫はいろいろあるが、それらによって実現される機能自体が目新しいものというわけではない
443:デフォルトの名無しさん
22/07/22 17:40:06.82 whw2xWQR.net
Rustが発明したのかどうかはしらんけど、Borrow Checkerは他の普通の言語にはない仕組みで、目新しく感じるけどなあ
Borrow Checkerが効かないようなコードを書くんだったらRustを使う意味が感じられないぐらいにはね
444:デフォルトの名無しさん
22/07/22 17:44:11.14 t0V8WW9J.net
>>436
インターフェースの問題とJavaの問題を混同するのが論外
445:デフォルトの名無しさん
22/07/22 18:05:15.33 K++ItniC.net
Borrow checker自体は2000年頃のCycloneの時点でほぼできていたっぽい
Rust独自なのは多分shared xor mutableとmove by defaultじゃないかな
446:デフォルトの名無しさん
22/07/22 19:11:51.06 yoEBUVfk.net
>>437
そう。
C++には何でもある。
それが欠点。
必要なものに厳選して誰でも使えるようにしたのがRust。
C++のアイデアとJavaの実用性、二つの遺伝子を組み合わせたのがRust。
ちなみにお母さんがJava、お父さんはHaskellという建前だけど、本当のお父さんはC++。
Haskellさんは、自分の子供だと信じてる。
447:デフォルトの名無しさん
22/07/22 21:06:16.19 UonvlDt9.net
キモいな
Javaは遺伝子引き継いでないから代理出産に違いない
448:デフォルトの名無しさん
22/07/22 21:16:25.55 i57cd+Nw.net
>>442
javaの立ち位置なんて、無関係な癖に建物の影からチラチラこちらをうかがって変な妄想してる気味悪い知らない奴だよ。
449:デフォルトの名無しさん
22/07/22 21:29:36.07 zWgtMzpY.net
>>435
あの人はプログラミング能力だけの人じゃなくてDBとか分散システムのアルゴリズムが主戦場の人でしょ。
プログラム読み書き堪能に越したことはないけど、そこだけで人を評価するのは視野が狭いよ。
450:デフォルトの名無しさん
22/07/23 04:53:27 Yc68YnRu.net
>>444
意味不明なこと言わないで
451:デフォルトの名無しさん
22/07/23 05:40:41.12 xoLMiefm.net
>>435
C++だけでなくRustも理解できてない？
＠
純粋に疑問なんですけどRust使ってる中で「値オブジェクトマジ助かる！」って事あるんですか。
適当に参照で渡したデータが意図せず書き換えられて伝搬して困る典型ケースはコンパイラが潰してくれる認識なんですが。
452:デフォルトの名無しさん
22/07/23 08:37:27.70 0xKT+wLu.net
>>447
それはRustじゃなく値オブジェクトを理解できてない
院卒の新人だったりしない？
453:デフォルトの名無しさん
22/07/23 09:37:03.85 bR39w9BX.net
Googleは金の亡者
454:デフォルトの名無しさん
22/07/23 11:55:37.32 8Uydd8B4.net
>>448
低レイヤーのプログラマーは値オブジェクトとか知らないほうが普通
アーキテクチャ設計といったらCPUやメモリアーキテクチャの事だと思ってたりするw
455:デフォルトの名無しさん
22/07/23 13:10:56 RBxCW/xN.net
OwnershipルールとReferenceルールがWhat
Borrow CheckerはHowに相当
Howにももちろん価値はあるが
それと同じくらいWhatをシンプルに絞り込んだものにしたことにも価値がある
後知恵で見れば当然に見えるようなシンプルなルールを作るのはものすごく難易度が高い
456:デフォルトの名無しさん
22/07/23 16:15:20.09 tefRxlpq.net
>>451
わかる
Rustのメモリ周りや、UnixとかRISC-Vみたいに、システムを動作させるに必要な機能の数をできるだけ小さくするのって難しいけど、完成品を見ると当たり前じゃんみたいな印象を受ける
457:デフォルトの名無しさん
22/07/23 18:34:20.81 u2Y0Vizw.net
>>445
残念ながらスパナーとか普通に実装してるgoogleにおいてはあんまり価値のある能力ではないよ。
458:デフォルトの名無しさん
22/07/23 19:04:05.94 ehQy/P8s.net
ISO、C++標準化委員のグレイドン・ホアレ氏はC++0xの標準化過程で、後方互換性を削ぎ落せば理解しやすくなることに気が付く。
そして私的プロジェクトとして実装し始めた。
2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
459:デフォルトの名無しさん
22/07/23 19:21:14 NE7ljYY1.net
C++標準化委員の人でもあったんか
それにしてもRustっていいネーミングだよな
なんかしっくりくる
460:デフォルトの名無しさん
22/07/23 19:57:02.71 uphZtYPd.net
正直なところ一般的な単語とか1文字とかの言語名はやめて欲しいと思わなくもない。
461:デフォルトの名無しさん
22/07/23 20:43:26.21 PgM2fTTz.net
>>453
逆じゃね。自分たちで作ってるからこそアルゴリズム方面の知識の意味があるのでは
462:デフォルトの名無しさん
22/07/23 21:05:19 IDFlcwhf.net
>>454
Hoareはホーアかホアだと思うんだが
ホアレはどこの国の読み方？
463:デフォルトの名無しさん
22/07/23 21:18:57.29 91gi6HhK.net
日本じゃね？
464:デフォルトの名無しさん
22/07/23 21:28:49.17 zqWGCIwO.net
>>456
昔は大変だったけど今時はグーグルさんもだいぶ賢くなって来たから〇 言語や〇 langでいける
465:デフォルトの名無しさん
22/07/23 22:37:12.56 SkYdpzS6.net
>>454
>2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
2006年の間違いじゃない？
ちなみに>>451に書いてるReferenceルールやBorrow CheckerはGraydon時代にできたものじゃないよ
466:デフォルトの名無しさん
22/07/24 09:21:08.56 lG8qI40d.net
>>461
じゃあいつできたの？
467:デフォルトの名無しさん
22/07/24 09:29:10.51 TkuAh24s.net
RustじゃなくてHoareの方が検索性は高かったと思う
言語に自分の名前つけたっていいじゃん、最初だけイタい人扱い受けるだけだし
468:デフォルトの名無しさん
22/07/24 12:23:10 A2ivE9+A.net
でも本当にHoareなんて名前付けたら絶対Tony Hoareのほうだと思われるやろな
469:デフォルトの名無しさん
22/07/24 12:53:11.52 lG8qI40d.net
>>464
ほんこれ
あんな有名人とfamily nameが一緒とかすごい偶然だよな
470:デフォルトの名無しさん
22/07/24 13:06:01.37 hnBeY/7d.net
木村拓哉と苗字が同じ木村君みたいな。
471:デフォルトの名無しさん
22/07/24 13:06:50.57 iVL8opWs.net
すごい偶然ですねえ・・・ えっ
472:デフォルトの名無しさん
22/07/24 13:35:38.58 q7gbemmZ.net
Rust-Oneとか見たいな感じの名前が良かったんじゃないかとｗ
473:デフォルトの名無しさん
22/07/24 13:48:30.68 q7gbemmZ.net
新言語を作る際にはありふれた言葉を使うなってコンセンサスがあれば…
C java go Perl Ruby Rust ...
474:デフォルトの名無しさん
22/07/24 13:53:14.16 iVL8opWs.net
せめて後ろに +lang した名前を正式名称にしてくれりゃなあ
Javalang、Clang、Golang、Rustlang...
clangは名前衝突するから今更ムリだけど
475:デフォルトの名無しさん
22/07/24 14:08:13.51 6QULAMze.net
RustとかGoはもう今じゃメジャーだから大分マシだけど
上の方に出てるCarbon？だのみたいな新しい知名度低いようなのにとっちゃ検索されづらいのって結構大きいデメリットじゃないのかね
476:デフォルトの名無しさん
22/07/24 14:11:15.69 q7gbemmZ.net
Car-bonおすすめ
477:デフォルトの名無しさん
22/07/24 17:26:22 AIK5SBoS.net
Rustでは検索にこまったことないけどなぁ
CやGoではそれなりに困ったことある
特にC
478:デフォルトの名無しさん
22/07/24 17:35:43.91 nz/s3YoW.net
>>469
perlは違うくね
入れるならpython
479:デフォルトの名無しさん
22/07/24 18:34:31.10 kd/zxSl1.net
Pythonはまさかちょっとしたイタズラ心で命名した言語が
30年経ってこれほどまでに普及するとは思ってないだろうなぁ。
480:デフォルトの名無しさん
22/07/24 20:35:51.30 T5Io3liY.net
ゲームのRustが人気になっていても問題なく検索できてるなぁ
481:はちみつ餃子 ◆8X2XSCHEME
22/07/25 09:42:55 OE8E5RfU.net
パーソナライズ (その人のアクセス傾向を検索結果に反映する) がそこそこ機能してるっぽいという話はあるなぁ。
個人情報保護の法律との兼ね合いが難しいみたいだが。
482:デフォルトの名無しさん
22/07/25 11:46:03.92 fotNOYOj.net
RustはCやC++の後継にはならないな。
483:デフォルトの名無しさん
22/07/25 12:46:43.99 /yXgS7y/.net
CはC言語で検索してもC++が出てきやがるからな
迷惑な言語だわC++
484:デフォルトの名無しさん
22/07/25 14:10:01.30 fotNOYOj.net
全然、思想や人柄が違う人を後継者に立てようとしても無理が有るな。
485:デフォルトの名無しさん
22/07/25 19:30:13.93 qs4kuyp6.net
>>456
その例でいってとにかくクソダメなのが Go
言語仕様も前時代的なウンコみたいな仕様だが何がだめといって名前がクソすぎ
ついでにいうとマスコットが致命的にキモすぎる
486:デフォルトの名無しさん
22/07/25 20:08:08.67 uz33IoOs.net
goはgolangって呼び方が一般化してるから問題なくね？
親会社もalphabetだし、仮に一般名詞でも検索してやんよっていう自信の現れなのかも。
あとlisp monsterのほうが可愛いよね
487:デフォルトの名無しさん
22/07/25 21:31:20 o3/zkeTE.net
langってなに？
488:デフォルトの名無しさん
22/07/25 21:42:28 GF1rw+EH.net
ゴラン高原はイスラエルが不法に占領してるシリアの土地であり、日本政府
489:はシリア高原と呼称するそうだぞ。
490:デフォルトの名無しさん
22/07/26 07:10:48 4TZ4RWr2.net
今ちいかわってキモいキャラが流行ってるように
Gopherくんもいずれ世界的なマスコットキャラクターになるよ
491:デフォルトの名無しさん
22/07/26 08:04:10.89 B/e7/0Va.net
>>484
それはGolan
492:デフォルトの名無しさん
22/07/26 08:15:07.77 RlhOzjvN.net
今マイコン用クレートでメジャーなのってどのあたり？
自分で作るにあたり参考にしたいのだが
493:デフォルトの名無しさん
22/07/26 08:36:59.30 +EhcIf+H.net
>>487
おれたちが知るわけないだろバカか？
494:デフォルトの名無しさん
22/07/26 08:37:23.50 jFWmtimM.net
言語の名前がGopherだったらよかったのに
495:デフォルトの名無しさん
22/07/26 09:10:32.87 gGUkeHRo.net
プロトコルの方のgopherについて調べる人が困るでしょ
496:デフォルトの名無しさん
22/07/26 09:38:10.98 hAg2HYen.net
プロトコルはイーサリアムとビットコインで実現出来ます
この2種類以外は今後不要になります
497:デフォルトの名無しさん
22/07/26 09:42:41.59 xvJteLGG.net
😲
498:デフォルトの名無しさん
22/07/26 09:57:43.88 khPn0eWd.net
>>491
草
499:デフォルトの名無しさん
22/07/26 11:19:17.05 wEdk200U.net
Web3なんて流行るわけねーだろ
スマートコントラクトの開発コスト高すぎ＆不便すぎ
500:デフォルトの名無しさん
22/07/26 11:50:54.04 m36KkBXx.net
それに引き換えBorrow Checkerは開発コスト低くて便利だね
501:デフォルトの名無しさん
22/07/26 11:55:05.12 xpFZew7X.net
Rust=Web3 だからWeb3業界の勢いが無くなったら影響受けるよ
502:デフォルトの名無しさん
22/07/26 11:59:58.82 EbLORSqB.net
>>496
意味不明
503:デフォルトの名無しさん
22/07/26 12:14:19.05 /Gebh7sM.net
Etherはイーサーだけど
Ethereumはァセーリアム
日本語読みだと外人に通じないから注意な
504:デフォルトの名無しさん
22/07/26 12:46:34 NppJ7uYb.net
>>487
AVR-HALとかいうやつ使ってる
505:デフォルトの名無しさん
22/07/26 14:54:22.29 6ZBHWj0q.net
３年以内にMoveが天下取るとか言われてるけど本当かね
506:デフォルトの名無しさん
22/07/26 14:58:00.69 m36KkBXx.net
本当だから高くなる前にいっぱい買っておけ
507:デフォルトの名無しさん
22/07/26 21:01:19.60 WAPUil1D.net
ʕ◔ϖ◔ʔ
508:デフォルトの名無しさん
22/07/27 00:16:39.59 Zq3V4Tcb.net
>>500
Moveってなに？
509:デフォルトの名無しさん
22/07/27 01:54:06.44 qGGsA3uX.net
>>503
最新のブロックチェーン言語も知らない奴はここから消えて
510:デフォルトの名無しさん
22/07/27 05:50:23.11 Zq3V4Tcb.net
>>504
あれLibraってまだ生きてんの？
ぜんぜん音沙汰聞かないけど
511:487
22/07/27 07:28:03.29 6+JEeGDS.net
>>499
ありがと。見てみます
どのくらいのさじ加減が使いやすいのかが難しい・・・
512:デフォルトの名無しさん
22/07/27 07:32:05.65 6nSf0k+r.net
>>503
ダイハツの軽自動車
513:デフォルトの名無しさん
22/07/27 10:27:27.45 IW7fj0uw.net
>>505
名前変えた後継含めて公式に死んでる
514:デフォルトの名無しさん
22/07/27 19:19:33.01 U29fl458.net
>>505
世界に殺された
もし生まれたら恐ろしいことになってただろうしな
515:デフォルトの名無しさん
22/07/28 00:38:58 z/Vvst4i.net
アレはAptosとして生き残った
大型の資金調達を連発して次の投機の標的になってる
516:デフォルトの名無しさん
22/07/30 22:19:27.63 wZaxY20D.net
std::io::Result<()>
↑の()ってなんすか？
Ok(());
↑の()も。
「空」を意味してるってことでいいんですか？
517:デフォルトの名無しさん
22/07/30 22:34:27.43 PnFWbFUc.net
5つの何かを返す関数なら
return (a, b, c, d, e);
0つの何かを返す関数なら
return ();
と考えてもよく何も返さないこと
518:デフォルトの名無しさん
22/07/30 22:39:27.64 xUdiS2xM.net
URLﾘﾝｸ(doc.rust-lang.org)
519:デフォルトの名無しさん
22/07/30 22:41:59.23 wZaxY20D.net
>>512
>>513
どうもありがとう
520:デフォルトの名無しさん
22/08/01 16:04:37.53 ElZDPbmW.net
Meta社のバックエンドにRust推奨だってよ。
URLﾘﾝｸ(www.publickey1.jp)
521:デフォルトの名無しさん
22/08/02 02:20:06.29 M8Mca9lV.net
bevy 0.8
URLﾘﾝｸ(bevyengine.org)
522:デフォルトの名無しさん
22/08/02 23:33:57 FkNkpg49.net
bevyとFyrox Engineはどちらの方が良いのかな
人気度はbevyな気がするが
523:デフォルトの名無しさん
22/08/04 02:28:39.18 xaY+36ag.net
Rustでプラグインシステム組むならwasiが安牌かな
524:デフォルトの名無しさん
22/08/04 09:59:47.35 CkQzFtco.net
プラグインシステムとは
525:デフォルトの名無しさん
22/08/04 12:38:32.91 pLEfRi/j.net
エディタとかツールの機能拡張だよ。
RubyとかJVMとかある程度の動的さを持つランタイムがあると開発楽だけど、GoやRustみたいにスタティックリンク、シングルバイナリが基本になると
たしかにwasmベースで作るのが筋が良いのかねぇ。
526:デフォルトの名無しさん
22/08/04 12:57:45 qyv7p4eK.net
おいおいww
527:デフォルトの名無しさん
22/08/04 13:50:49.10 ck4xiQdl.net
クロスプラットフォームで同一バイナリが動いてそこそこ高速で組み込み用途に向いてる
という条件だとLuaかwasm
528:デフォルトの名無しさん
22/08/04 13:51:05.48 ck4xiQdl.net
JSでも良いが
529:デフォルトの名無しさん
22/08/04 15:10:31.96 b+TNnTjV.net
プラグインというよりマクロの実行環境の話だな
Luaやwasmはホストアプリにランタイムを同梱する必要がある
530:デフォルトの名無しさん
22/08/04 15:23:41.09 1k9fnhsy.net
Luaやwasmを使うようなスクリプト型(スクリプト言語のことではなくて、上位レイヤのシナリオだけをユーザーに書かせる方式)の拡張って、
よほどホスト側にプラットフォームとしての魅力がない限りは成立しないよ
ホストがスクリプトに対して提供している機能以上のことはできないわけだからな
そうじゃなくて、やりたいのはホストにない機能を追加できるプラグイン機構じゃないの？
531:デフォルトの名無しさん
22/08/04 15:39:46.71 9TNfUmNd.net
>>520
Rustでやりたいってことは実行速度を重視してるんだろうし動的リンクしかないだろ
しかしwasmにしてもいいっていうならJavaScriptやらLuaの活用も検討しろ
532:はちみつ餃子
22/08/04 15:55:10.42 hPtMGH66.net
そういえば Rust の proc macro を wasm としてコンパイルしたらどないやという話はあったんじゃなかったっけ？
最終的にどういう結論になったのか追ってないんやが……。
必要な機能は Rust コンパイラの中に全部あってシステムの外とやり取りする必要もないから良い案に思える。
533:デフォルトの名無しさん
22/08/04 17:17:23 KbhCPu0a.net
>>525
Luaやwasmからホストの用意した機能を呼び出す形だけでなく
ホストからLuaやwasm側の処理を呼び出す形も実装可能だよ
DLLに比べると相当手間がかかるけど
534:デフォルトの名無しさん
22/08/04 17:19:43 ck4xiQdl.net
動的リンクするにしてもABIがunstableだからインターフェースはextern "C"で公開せざるを得ないし
それなりの量のグルーコードが必要になるかと
その辺良い感じにどうにかしてくれるcrateがあるかもしれないけど
535:デフォルトの名無しさん
22/08/04 17:29:05.26 1k9fnhsy.net
>>528
そうしたとしてもホスト側に存在しない(ホストからスクリプトに対して公開されていない)機能は使えないでしょ？
536:デフォルトの名無しさん
22/08/04 17:46:52.95 CkQzFtco.net
URLﾘﾝｸ(qiita.com)
コメント欄も含めるとなかなか情報がまとまっています
537:デフォルトの名無しさん
22/08/04 17:49:06.27 8PPO9uzK.net
良さげ記事
538:はちみつ餃子
22/08/04 17:58:11.58 hPtMGH66.net
>>530
ホスト側を経由せずに外にアクセスするのは禁止できたほうが嬉しいことも多いだろ？
俺が使っているソフトでプラグイン機構があるものというと画像ビューアとかメッセンジャとかだが
それほど自由に外の世界にアクセスする必要はないし、不必要ならアクセスさせないに越したことは無い。
(悪意あるプラグインを作り難くなるので。)
制限があるというのと制限を付けられるのは表裏一体なのでそんなの場合によるとしか……
539:デフォルトの名無しさん
22/08/04 18:01:34.69 9TNfUmNd.net
>>529
> 動的リンクするにしてもABIがunstable
あー、そうだったわ
めんどくさいんだった
540:デフォルトの名無しさん
22/08/04 18:42:08.03 pLEfRi/j.net
野良プラグイン入れて環境壊して上等！って時代でもないからねえ。
ある程度、できること制限できるようにしたプラグイン機構も大事な時代よ。
そういう点でwasmがセキュリティとパフォーマンスのバランスが取れていて魅力という層もあるでしょ。
541:デフォルトの名無しさん
22/08/04 18:42:45.33 KbhCPu0a.net
>>530
そりゃ広い意味で言えばどんな機能だってホスト側に存在してなければ使えない
「ホストにない機能を追加できるプラグイン機構」ってどんなものイメージして言ってるの？
542:デフォルトの名無しさん
22/08/06 12:18:12.84 z/fLyAW1.net
今の環境で正しくレンダリングされる10年前に作られたWebサイトは多くない
同様にTauriで作成されたアプリが10年後でも問題なく使用できるのだろうか
543:デフォルトの名無しさん
22/08/06 20:40:11.73 6gQA87rg.net
Tauriはバックとフロントが明確に分離されているからOS標準ブラウザに変更があっても修繕はしやすそう
Macとかだと突然仕様変えてきそうで怖いな
544:デフォルトの名無しさん
22/08/07 00:00:20.59 pGypWfdH.net
Rustでライブラリをどうやって選定してんの？
crate.io見て人気のを選んでんの？
GETだけのためにhttpclient使おうとしたらtokio入れて使えとか全然意味わからんしコンパイルしたら
これを使うには2018使えと2022使えが出てくる…
他のに変えても変わらず
GETなんてコピペ産業で実現させてくれよ
use
初期化
GET
これで終わらせてくれ
545:デフォルトの名無しさん
22/08/07 00:05:00.47 pGypWfdH.net
別に
use
GET
の2行でもいい
546:デフォルトの名無しさん
22/08/07 00:19:22.87 thO2Aez3.net
>>539
まあ今はそういう人向けの言語じゃないからね
とりあえずreqwestのblocking clientでやってみて合わなそうならあきらめろん
547:デフォルトの名無しさん
22/08/07 00:27:13.75 pGypWfdH.net
crate.ioにwebclient一覧が並べてあるけど結局最近のダウンロード数見て判断なんだろうなと
どれもtokio使ってるしCurlコマンドみたいに一発でGETやPOSTって感じでもない
tokio必須と言うことは標準でasyncライブラリの完成度が低いんだろうけど
憶測が当たってるかどうかもよくわからない
548:はちみつ餃子
22/08/07 00:48:31.33 yGip1YMx.net
>>542
Rust は標準ライブラリの中に非同期ランタイムを持ってない。
言語として非同期を扱えるようにしつつ具体的な部分は外部のクレートに任せられるように
分離に成功しているという意味では十分に完成度は高いとも言える。
549:デフォルトの名無しさん
22/08/07 01:05:02.63 nCVSRdWl.net
>>539
簡単これだけ
#[async_std::main]
async fn main() {
let uri = "URLﾘﾝｸ(httpbin.org)
let s = surf::get(uri).recv_string().await.unwrap();
assert_eq!(s, "Hello, World!");
}
Cargo.tomlの[dependencies]に適当に
async-std = { version = "*", features = ["attributes", ] }
surf = "*"
550:デフォルトの名無しさん
22/08/07 05:20:01.36 FgVTxKNL.net
簡単に使いたいなら、非同期じゃなくて同期版のhttpクライアントライブラリ使いなよ
551:デフォルトの名無しさん
22/08/07 08:15:04.13 PrNdTuny.net
Goを素直に使っとけ
標準ライブラリでそのままできる上に非同期もGoroutineを使うだけ
テスト用のライブラリも用意されてるからクライアントサーバーもそのままテストできる
552:デフォルトの名無しさん
22/08/07 08:22:19.17 nCVSRdWl.net
>>546
Goなんていうものは不要
Rustで簡単に使える
553:デフォルトの名無しさん
22/08/07 08:29:14.86 PrNdTuny.net
標準ライブラリでHTTPクライアント・サーバー・テスト・非同期を全て統一的に扱えるってのはかなり強みではある
Rustはランタイムコストをゼロに近づけるためライブラリ化しているが、それは必ずしも利用者にとってメリットがあるわけではない
あくまでもOSやドライバなどを作る上でランタイムコストを削らないと適さないからそうなっているだけ
>>539 みたいな人にはまず用途を考えた上で高レイヤーのプログラムを作りたいのであれば素直にRust以外の言語を使うことをお勧めする