[過去ﾛｸﾞ] Rust part31 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1: 07/03(木)21:30 ID:ORBrZxS2(1) AAS
公式
外部ﾘﾝｸ:www.rust-lang.org
外部ﾘﾝｸ:blog.rust-lang.org
外部ﾘﾝｸ:github.com
公式ドキュメント
外部ﾘﾝｸ:www.rust-lang.org
Web上の実行環境
外部ﾘﾝｸ:play.rust-lang.org
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
外部ﾘﾝｸ:doc.rust-lang.org
※Rustを学ぶ際に犯しがちな12の過ち
外部ﾘﾝｸ:dystroy.org
※Rustのasyncについて知りたければ「async-book」は必読
外部ﾘﾝｸ:rust-lang.github.io
※次スレは原則>>980が立てること
前スレ
Rust part30
2chｽﾚ:tech
ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
2chｽﾚ:tech
876: 08/09(土)14:59 ID:Om2mqfPg(1) AAS
お前に相談しても何も解決しないからこんなことになってんねや
877: 08/09(土)15:03 ID:OU6EAzKD(4/4) AAS
複数IDおじさんは死んだのですか？
878: 08/09(土)15:27 ID:vSzyTiPH(1) AAS
>>842
Rustの台頭を招いた戦犯はC++だな
遅いC#がいくら頑張っても無理だが
C++が高速で使いやすいものを築き上げていればRustが入り込む余地はなかった
879(4): 08/09(土)16:20 ID:8jBxYJQq(1/4) AAS
C++ は使い勝手が悪かろうと汚かろうと最悪の場面でなんとかできるという安心感はある。
Rust は良い言語だけど「綺麗に設計できなかったとき」のグダグダな辻褄合わせをフォローする力は弱い。
もちろん最初から全うに設計して全うにコードを整理できれば一番良いに決まってるけど、現実は非情でありプログラマは無能である……。
880: 08/09(土)16:27 ID:5dENg5ap(1) AAS
>>879
プログラミングで辻褄合わせなんて聞いたことがないんだけど具体的に何をするの？
881: 08/09(土)16:56 ID:l1zXGfIU(4/5) AAS
Optionや内部可変を許容すれば辻褄が合うんだろう
けど自分の考えだけで決めるのはアレだから
ヌルや代入をみんな許容しているから自分も許容するという形にできるのがJavaやC++
882: 08/09(土)17:13 ID:hxAIY3kv(1) AAS
ヌル安全でないそれらのダメなプログラミング言語はダメな言語しか使えないダメな人たち専用言語となっている
883: 08/09(土)17:32 ID:8jBxYJQq(2/4) AAS
現実は駄目なのでしゃーない。
884: 08/09(土)17:35 ID:bqtMLqjo(1) AAS
Rustを学ぶとくどくて読みにくい日本語を書くようになる効果でもあるの？
885: 08/09(土)17:50 ID:JJdMnyaw(1) AAS
パターンマッチで全タイプ網羅しないと脳内コンパイルが通らなくなるらしい
886(2): 08/09(土)18:35 ID:pUGHLIhK(1/2) AAS
>>879
理論上はunsafe使えばRustでもどうとでもできるとは思うんだが
あんまり雑にunsafeするための情報が転がってないしね
887: 08/09(土)18:35 ID:93q/kIgN(1) AAS
糖質とRustって親和性が高いんだろうな
888(1): 08/09(土)18:47 ID:Aw+43M+T(1/5) AAS
>>879
逆だろ
C++とは異なりRustならどう書いても設計を変えてもリファクタリングしても安全が保証される安心感がある
889: 08/09(土)18:54 ID:Aw+43M+T(2/5) AAS
>>886
Rustではまず最初に必ずsafeのみで記述するという絶対原則がある
プログラムを完成させ計測した上でネックが見つかりunsafeで安全に記述できる構造が見つかった時のみ検討が行われる
890(1): 08/09(土)19:05 ID:8jBxYJQq(3/4) AAS
>>888
変えるためにはグダグダだろうがなんだろうが一度は形にならなきゃいけないが、そもそも形になんねーんだよ。
安全が保障されるよりも、バグだらけでもまず動かなきゃ話にならんのが現実の要件なんだ。
891(2): 08/09(土)19:09 ID:Aw+43M+T(3/5) AAS
>>890
形にならないとは何だ？
安全でなくバグがある要件なんて現実にないぞ
892(1): 08/09(土)19:19 ID:pUGHLIhK(2/2) AAS
>>891
自分でも安全性が保証されないことと安全でないことの区別付いてないじゃん
893: 08/09(土)19:22 ID:Aw+43M+T(4/5) AAS
>>892
Rustで書けばよい
必ず安全が保証される
894(1): 08/09(土)19:34 ID:8jBxYJQq(4/4) AAS
>>891
納期は要件の中で優先順位が高い。
納期を守れればバグの改修を後回しにする交渉は可能だ。
動くものが無かったらバグもクソもねーんだよ。
895(1): 08/09(土)19:41 ID:Aw+43M+T(5/5) AAS
>>894
そういう時はこういう症状のバグがまだ残っていますと添えて提出するだけの話だろ
Rustと関係なくどの言語でも同じ
896: 08/09(土)19:47 ID:Ab8eMDOi(3/3) AAS
>>895
多重下請けマっぽい物言いだが、だとしても複おじにまともに実務経験があると思えないんだよなあ
底辺クソブラックでロクに仕事もできず病んで数年で退職、以後長期ニートとか？
897(1): 08/09(土)20:07 ID:rQqeE1Vt(1) AAS
>>886
バグを回避するためにunsafeを使おうとしている？そんなアホな
レッドカードや
898: 08/09(土)20:08 ID:l1zXGfIU(5/5) AAS
シンギュラリティには納期がないのに物凄いお金をかけて大丈夫なのかな
899(1): 08/09(土)20:36 ID:Q6/AOvN1(1) AAS
>>897
バグの話なんてしてないけどどこをどう読んだらそうなるんだ
900: 08/09(土)20:42 ID:28rfMcPG(1/5) AAS
>>899
バグをつじつま合わせで回避する話かと
ちゃうん？
901: 08/09(土)21:01 ID:k8Vi1+RP(1) AAS
安全性とは関係ないバグもあるんだけどね
Rustでかくと安全性は保てるのかもしれないけど仕様通りの動作をしないバグとかは防げない
902: 08/09(土)21:27 ID:jMm762NP(1/3) AAS
Rustは読み出し中の書き換えや、書き換え中の別からの書き換えを防止してくれる
そのため知らぬ間に値が変わっていた系のバグも防げる
903(1): 08/09(土)21:48 ID:ZfnYWhel(1/6) AAS
ふーん、並列とかウェブってそんなに実需あるのか
俺は関数呼び出しの情報をそのままデータ化（Requestオブジェクト）するアイデアを思いついたんだけどそれって使える？
要するに関数ポインタ、引数、返り値を格納する変数へのポインタ、と、この3つを構造体に格納して遅延実行したりキューイングしたりするんだけど
904: 08/09(土)21:57 ID:28rfMcPG(2/5) AAS
>>903
目的とメリットは何やろ
クロージャや非同期関数など既にあるけど
905(1): 08/09(土)22:06 ID:ZfnYWhel(2/6) AAS
目的は一応並列
メリットは軽量
906: 08/09(土)22:10 ID:xyhx6hof(2/2) AAS
平凡すぎる
907: 08/09(土)22:11 ID:28rfMcPG(3/5) AAS
>>905
並列には不要かなー
並行には機能不足だね
908(1): 08/09(土)22:19 ID:ZfnYWhel(3/6) AAS
実行リクエストを出してその完了をその場で待つ、というニーズなら十分応えられる
それにこれってゼロコスト抽象じゃない？
それならあって損するものでもない
909(1): 08/09(土)22:19 ID:LF6KHoht(1) AAS
C++を安全に書けない人のために補助輪を付けたのがRustだ
安全に書けばC++の方がいいのだ
910(1): 08/09(土)22:21 ID:28rfMcPG(4/5) AAS
>>908
昔からのコールバック関数と何が違うのかな～
911: 08/09(土)22:24 ID:jMm762NP(2/3) AAS
>>909
使えばわかる
Rustは抽象度がさらに高く
書きやすく読みやすい
C++はメリットがない
912: 08/09(土)22:32 ID:ZfnYWhel(4/6) AAS
>>910
AIが「それ、まだない」って言うんだもん
913: 08/09(土)22:56 ID:KGsTE/3q(2/2) AAS
AIって有能が使うと有能が加速するけど、馬鹿が使うと馬鹿が加速するツールだから頼らないほうがいいよ
914(1): 08/09(土)23:08 ID:ZfnYWhel(5/6) AAS
async/awaitの中身ってじゃあこの三つ組だったりするの？
915: 08/09(土)23:22 ID:28rfMcPG(5/5) AAS
>>914
awaitの地点毎に一旦出て再び戻ってくるよ
つまりステートマシンなコルーチン
スタックレスで実装されているよ
916: 08/09(土)23:46 ID:ZfnYWhel(6/6) AAS
俺はこれを定義して命名しただけで実装は誰がやってもいいと思うんだけど
高速ウェブサーバとか作れそうかな？
917: 08/09(土)23:53 ID:jMm762NP(3/3) AAS
環境キャプチャできるクロージャよりも劣る
918: 08/10(日)15:31 ID:1cj3h1dn(1) AAS
Rust 1.0ってもう10年前なんだ
919(1): 08/10(日)19:32 ID:2D3Ahc3U(1) AAS
>>879
コーディングスタイルは十人十色かもしれないが、
グダグダな辻褄合わせというフェーズの存在は初耳だ。
やり方もしくは能力になんらかの問題を感じる。
920: 08/10(日)19:59 ID:5hMvqzsk(1) AAS
エスパーだけど速いコードを書くことはできても小さいコードを書くことはできないことがあるからじゃない？
921: 08/10(日)22:09 ID:Zg5co2YS(1) AAS
どう
922: 08/11(月)15:40 ID:EC/wLypS(1/2) AAS
>>919
そうだよ。
大抵の場合に無能はいるし問題はあるという現実を前にしてそれでもなんとかしなきゃならないという話をしてるんだ。
923: 08/11(月)15:59 ID:GdF4E6X/(1) AAS
辻褄合わせのプログラミングをしてる人は言語関係なくプログラマーに向いていない
去ってもらうのが業界のため
924: 08/11(月)16:30 ID:3Pi1Vu8v(1) AAS
プログラミングしたら負け
925: 08/11(月)17:25 ID:X2QbX/qC(1/2) AAS
辻褄合わせのプログラム書いてる人がいると聞いて慌てて飛んできた
いったいどういう神経してんのさ、さっさとアーキテクチャー見直さないとかアホなの？
926: 08/11(月)18:04 ID:EC/wLypS(2/2) AAS
知らんわ。
俺にその権限はないし、「今」なんとかしなきゃならないときにそんなこと言っておれんのが現場ってもんだろ。
927: 08/11(月)18:12 ID:UQA5I5Ux(1) AAS
仕事の経験が無い人にはわからんのだよ
928: 08/11(月)18:48 ID:BYBfr1qg(1/2) AAS
>>756の言葉を借りるなら
なにごとも慣れ
取り組んでいればunsafeも上手く取り扱えるようになるよ
しかし避けていればいつまでたっても取り扱えないまま
929(3): 08/11(月)19:35 ID:GpYObhHZ(1/2) AAS
文法を100時間かけて習得しても、ちゃんとした設計でRustのコードをかけるようになるまでが長すぎる…。ChatGPTで解決しないレベルの問題ばかり引く
Builderパターンを使うべきか、new()に与えたくない引数を与えるかで30分も悩んじまった。Rustに変えてからこんなんばっか。別の言語の経験がもっと素直に生きるもんかと思ってた
930: 08/11(月)19:42 ID:oNbTL3km(1) AAS
さすがにそれは別の言語の経験とやらが自分が思っていたよりも浅かったということでは
931(1): 08/11(月)19:48 ID:GpYObhHZ(2/2) AAS
C++の経験がもっとあれば違った気がする
データサイエンティストが使うpythonはけっこう遠かった
932: 08/11(月)20:12 ID:N8nCnSEw(1) AAS
Python経験しかないならそりゃそうなる
言語の複雑さ以前に、そもそもそれらの機能が何故必要なのかが分からないだろうからチンプンカンプンだろうな
そもそもあえてRustなんかやる必要があるのかも疑問
933: 08/11(月)20:14 ID:SuQLHjmT(1) AAS
>>929
どの言語でも共通の概念があり各言語のやり方がある
同じくChatGPTに頼ったとしても個別のやり方だけをコピペして来た人は概念の理解に乏しく応用が利かない
別の言語の経験が生きるかどうかは本人の問題
934(1): 08/11(月)20:36 ID:7BdHEm5E(1/2) AAS
スクリプト屋が意識高い言語やりたいなら、Goとかのほうがいいんじゃね
935(1): 08/11(月)20:46 ID:Kb00poZQ(1) AAS
>>931
C++は不要だが比較的すぐ習得できると言われるC言語くらいはプログラマーを名乗るなら理解しておくべき
いわゆる参照の値渡ししかないPythonの経験のみでは何をするにも最初は時間がかかるだろうが
936(1): 08/11(月)21:05 ID:xz+O0Ovt(1) AAS
Cなんて値渡ししかない
やるならC++にするべきだ
937: 08/11(月)21:35 ID:ZDxIKfeQ(1) AAS
>>934
Goが意味を持つ領域は非常に狭い
今回は書かれてる情報よりPythonから呼び出す高速ライブラリ作成やPythonコードの高速化や省メモリだろうから
Rustが全言語の中でベスト選択肢
>>936
Rustを会得する上でC++の知識は必要ない
似た概念はあるが異なるためRustのために新たに学ぶ利点はない
938: 08/11(月)22:00 ID:BYBfr1qg(2/2) AAS
どんだけC++嫌いなんだ
939: 08/11(月)22:08 ID:dOXmVIim(1) AAS
C++からRustへ来てその違いの多さに右往左往してる人たちのために指南が行われるくらい方向性ちがうよな
940: 08/11(月)22:27 ID:7BdHEm5E(2/2) AAS
まあかぶってるのは最初から用途だけだし
941(1): 08/11(月)22:27 ID:X2QbX/qC(2/2) AAS
辻褄おじって複おじだろうな
C++なら設計不具合を辻褄合わせできるって、、、
それRustと違ってコンパイルエラー回避してるだけで設計なおってないぜ
942(3): 08/11(月)22:37 ID:05Dprm4o(1/2) AAS
>>929
>Builderパターンを使うべきか、new()に与えたくない引数を与えるか
これ他の選択肢は考えなかったの？
その2つで悩むくらいなら与えたい引数だけを取るコンストラクタを用意したほうがいいケースに見えるけど
943: 08/11(月)22:37 ID:AFY6XkLY(1) AAS
辻褄合わせのスパゲッティなプログラムを書く人はどの言語にもいる
Rustはスパゲッティなプログラムの主因でもある参照の競合を防げる言語
辻褄合わせをしてきたスパゲッティなプログラマーは破綻して炙り出される
944: 08/11(月)22:37 ID:oFJRCO1f(1) AAS
今更複おじの称号を他人になすりつけようとか小賢しいことしてもバレバレですよ
945: 08/11(月)22:40 ID:05Dprm4o(2/2) AAS
>>941
どう考えても別人だろ
946: 08/11(月)23:52 ID:DkamCpJM(1) AAS
下手なプログラミングしてきた者がRustは辛いと言い出すから下手さがわかりやすく出ちゃう
947(1): 08/12(火)00:14 ID:G/XPXKyQ(1/5) AAS
>>942
もっと複雑な実装をする時はその選択肢も当然入ってくる
948: 08/12(火)00:22 ID:G/XPXKyQ(2/5) AAS
>>935
Cの経験は独学レベルなら一応あるんだけど。Rustはまだまだきついわ
基本文法を取得してから、実戦投入に慣れるのに、2ヵ月か、下手したら3ヵ月ぐらいかかりそうな具合
俺、今まで関わった機械学習系の開発プロジェクトで、大体どこに行ってもコーディング一番得意な人だったのに
Rustはまだしっくりこない。やっぱ、この言語ちょっと特別な気がする
949: 08/12(火)00:33 ID:a3TkiHxV(1/5) AAS
設計に迷ったならAPIガイドラインっていうのが一応あるけど
そういう話じゃないか
外部ﾘﾝｸ[html]:rust-lang.github.io
950(2): 08/12(火)00:40 ID:i1L5Xnaz(1) AAS
>>947
Builderを使う状況以上に複雑な場合なんてあるの？
いくつかあるオブジェクト生成方法の中で
最も複雑な状況に対応するのがBuilderパターン
逆に最もシンプルな状況に対応するのがnew()
その両極端で悩んだという話だから
new()よりの方法を紹介したつもりだったんだが
951(1): 08/12(火)01:24 ID:G/XPXKyQ(3/5) AAS
>>950
あー。その場限りのcontextの構造体を作るだけの最小構成ならBuilderパターンより軽いのか
コンテキストというと、どうしても汎用的なの、もっと言うとGod的なの想像しちゃった
コンテキストだとある程度は汎用性を持たせた実装にしないと、
最悪の場合、引数で与えたくない値をラップして見えにくくすることで、
罪悪感を和らげる的な実装になってしまう気がする
だから自分は重いコードを想像してしまった
952: 08/12(火)01:24 ID:MtCSZU3d(1) AAS
複おじの複って何の略なの？
オレオレ用語を使われてもよくわからん
953: 08/12(火)01:48 ID:a3TkiHxV(2/5) AAS
複おじの概要
2chｽﾚ:tech
954: 08/12(火)01:50 ID:a3TkiHxV(3/5) AAS
あの頃に比べると複おじは全然コード書かなくなったな
最近は他言語とか初心者をこき下ろしてばっかり
955(1): 08/12(火)02:40 ID:u3A5dRZj(1) AAS
>>950
Rustでnew()の意味は決まっていなくて自由だけど
おおむね最小限のものを与えるものがnew()
つまりnew()の引数は最小限のものを作るのに必要なもののみ
今回はnew()に与えたくない引数を与えるか悩んでるようだから
必要最小限てはない引数であると推測できる
この状況では3つの単純な方法
①new()してからsetxxx()を呼び出す
➁①の2つを一気に行なうxxx()を作る>>942
③ビルダーパターン
956: 08/12(火)08:30 ID:4cospISj(1) AAS
今時そんなパラメータ並べるだけの低次元な単純作業はAIにやらせりゃ一瞬なんだからどうでもいいよ
内部的に使うだけであり、かつAI利用を前提とするなら、>>942案がベター
ユースケースに特化した最小限の実装の方が人間がコードレビューしやすいし、少ないトークンで済むし、AIに余計な混乱を与えない
後で変更する必要が出てきたときの認知負荷の問題もAI前提ならあまり考慮しなくていいしな
957(1): 08/12(火)10:27 ID:uzbu6zoz(1/2) AAS
Rustの仕事って複おじみたいな活動をする仕事しかもうないんじゃね
958(1): 08/12(火)10:32 ID:o6GedXY5(1) AAS
>>951
コンストラクタとコンテキストを空目してる？
959: 08/12(火)10:47 ID:6RAsIQle(1/3) AAS
ビルダにしつつマクロでくるむのもよくあるパターン。
Rust には可変長引数がないから割と気軽にマクロを使う。
それか引数全体を構造体にして基本パターンを Default で生成できるように実装しつつ変更が必要なところは .. で変えるみたいなのもある。
960: 08/12(火)10:56 ID:5BWK9Np7(1) AAS
>>955
いわゆる依存性の注入パターンだから
Constructor Injection
Method Injection
Setter Injection
どれを使ってもよくて大した問題ではないな
しかしこれはどの言語でも起きる共通の話
>>929がRustに変えたら悩んだと言ってることが理解できない
961: 08/12(火)10:58 ID:G/XPXKyQ(4/5) AAS
>>958
はい。空目した
962(1): 08/12(火)11:05 ID:ag9TAHO3(1) AAS
実質ビルダと変わらんけど初期化用の構造体からfromとかintoで変換するのがRustっぽい
impl From<...> for Foo
を複数の型に対して実装すると初期化オーバーロードの代替になる
963(1): 08/12(火)11:09 ID:S3jeW6Sh(1/2) AAS
>>957
システムプログラミング用だけどC/C++と違って組み込みみたいな数こなす仕事がないからね
一部、自動運転のような高度な分野で使われているようだが、Rustを好むような層に作業服着て愛知の工場で働きたい奴がどれだけいるかは激しく疑問だわな
Web系にしてもRustは少ない労力で極めて大きくスケールする部分に限定して用いられるのが現状で、
大量に並んだ業務トランザクションの一覧を一個一個実装してくような性質の仕事じゃないから、Rustの仕事はごく一部の上位層に限られる
964: 08/12(火)11:17 ID:55fYHsEH(1) AAS
>>962
Rustプログラミングはトレイトを用いたジェネリック化が基本だよね
初期化生成が単なる変換で済むなら独自トレイトは不要でFromやTryFromを使うのがRust流
なぜトレイトを使うべきか理由は複数の型に対応できるだけでなくテストの時のテスト用モック型も同様に扱えるため
965(1): 08/12(火)11:20 ID:kIE6XRW2(1) AAS
>>963
生成AIでもライブラリのRust化など色んな分野でRustへ置き換わる方向へ進みつつあるよ
966: 08/12(火)11:34 ID:sCNFFs6h(1) AAS
Rustがネイティブで動くFPGAとか出てこないかな
967: 08/12(火)11:34 ID:G/XPXKyQ(5/5) AAS
個人開発でiphone, android両対応のアプリにcrdtを組み込むのにrustを使ってる
そんな上位層でもないんだけど
968(2): 08/12(火)11:45 ID:qcKUJthg(1) AAS
ビルダーやnewとかfromコンストラクタとかの話は言語機能の貧弱さから来ているんでは？
文法でなくコミュニティ依存のベストプラクティスを学ばないといけないのは弱点だと思う
後で潮流が変わってそのためだけにシグネチャを変えるのがバカバカしい
変えないと古臭いとか勉強不足と言われるのもくだらない
969: 08/12(火)12:08 ID:cacY6MRR(1) AAS
>>968
言語機能が強いからFrom実装だけで任意の型に対して対応できるんよ
エラー型の変換にしても同様
？オペレータで自動的にInto変換されるためこれもFrom実装だけで対応OK
970(1): 08/12(火)12:19 ID:TPXEzVE3(1) AAS
>>965
Rust意味ないじゃんｗ
971: 08/12(火)12:22 ID:IjrX/Wgj(1) AAS
>>968
コミュニティ依存の方法なんてないぜ
全てRust標準ライブラリで用いられている標準の方法だ
Fromを知らずして君はRustの何を勉強したと言うのだ？？
972: 08/12(火)12:49 ID:aUpqhYkf(1) AAS
newはコミュニティで意味をもたせてるだけで、別に言語的に特別な意味を持たないっていうのは
どうなんだろうなとは思う
973(1): 08/12(火)12:55 ID:9RnwCZim(1) AAS
>>970
どの分野でも省メモリ化や高速化が求められる部分があって従来はC/C++で書かれていたんだけど
今は安全性の観点からもRustを使えるならRustを使え、になっていってる
日本でもすぐにそうなるよ
974(1): 08/12(火)13:03 ID:uzbu6zoz(2/2) AAS
>>973
生成AIは安全なの？
975: 08/12(火)13:07 ID:6RAsIQle(2/3) AAS
コンストラクタに元から特別な意味などなかったことに気づいたという話なんじゃねーの。
new は共通するインターフェイスに出来ないからトレイトにする意味もないし。
976(1): 08/12(火)13:14 ID:U2drFIcF(1) AAS
>>863
その仮想スレッドはRustではタスクと呼んでいて既に実現されている
業界がRust支持へ回った背景としてRustの軽量なタスク実装がサーバーの能力を最大限に引き出せることを実証した点が最も大きい
安全なだけでは採用されなかった
977(1): 08/12(火)13:56 ID:tGCKXEeA(1/2) AAS
tokioのtaskのことだと思うけど、あれは仮想スレッドとは違うよ
仮想スレッドというと、 awaitのような中断ポイントを明示せず普通の関数のように書けて、かつIO処理をランタイム側で非同期にやってくれるものを指すと思う
978: 08/12(火)13:57 ID:tGCKXEeA(2/2) AAS
JavaやGoは仮想スレッドを
979: 08/12(火)14:04 ID:S3jeW6Sh(2/2) AAS
わざわざ100レス遡って初心者レベルの間違った知識を披露する
これが複おじの真骨頂よ
980(1): 08/12(火)15:14 ID:tZhL89Xj(1) AAS
>>974
もしかして複おじ
981: 08/12(火)17:12 ID:wTdmXaoa(1/4) AAS
>>977
taskはtokio固有ではなくRust自体の概念
tokioはスケジューラーの1つにすぎない
tokioがなくてもtaskは機能する
軽量スレッドの実現にOSスレッドやOSプロセスと同様のプリエンプティブを求めるべきかどうかは議論が分かれるが
目的は軽量で高速に大量に動けばよく
同一プロセス内の自分自身のコードならば協調型でも支障はない
Rustでもversion 1.0になる前はプリエンプティブな軽量スレッドが採用されていた
しかしオーバーヘッドが大きいため廃止されてからRust 1.0が出た経緯がある
そして真に求められている実用的な軽さと速さから現在の協調型非同期なtaskが採用されその実用性が示された
結果としてRustへの移行が進みこの判断が正しいと証明された
982(1): 08/12(火)17:50 ID:6RAsIQle(3/3) AAS
仮想スレッドの「仮想」は抽象度が高いことを言ってるものと理解してる。
仮想スレッドはスレッドのように動作するが実際に (OS が提供する) スレッドにどう割り当てられるかは実装の都合。
ひとつのスレッドの中で複数の仮想スレッドが協調スレッドのように動作するようなことがあるかもしれないし、
実際には同期的かもしれないが見かけ上はひとつの実行単位として抽象化されたレイヤが与えられている。
そういう意味でなら Rust のタスクは仮想スレッドのような概念だと言っても間違いではないんじゃないかな。
タスクはあくまでも見かけ上のインターフェイスであって、それを実際にどう処理するかはランタイムの選択次第。
983: 08/12(火)18:56 ID:Fr0OCoiD(1) AAS
>>982
君やRustコミュニティがRustのタスクを仮想スレッドと呼ぶのは自由だが、明確に異なるものであることを理解しておく必要がある。
JavaやGoにおいておいて仮想スレッドで実行されるコードは完全に同期的であり、
OSスレッドだろうと軽量スレッドだろうとその上で実行されるコードに違いは生じない。
984(1): 08/12(火)19:11 ID:wTdmXaoa(2/4) AAS
Javaの仮想スレッドもRustのタスクもGoのGoルーチンもOSスレッドに対してM:Nスケジューリングする点で違いはないよ
Rustの場合はスケジューラ依存だがtokioなどで全く同様にM:Nスケジューリングできている
違いはプリエンプティブかどうかスタックレスかどうかなど
Rustは協調的にスタックレスでパフォーマンスを出している
985(1): 08/12(火)19:11 ID:evYq+DIX(1) AAS
仮想スレッドとタスクは別物だろう
タスクは非同期ランタイム上で実行される処理の方に注目したもの
JavaやGoだと「仮想スレッド上で通常の関数やメソッドを呼び出す」、RustやC#だと「非同期ランタイム上でタスクを実行する」という感じ
これらはそもそも違う方式
986(1): 08/12(火)19:24 ID:/yJ0tylT(1/3) AAS
目的は共通して
高速かつ同時に大量に扱えること
CPUが持つ多くのコアスレッド数を偏りなく限界まで使い切れること
そして現実の用途でそのパフォーマンスを発揮すること
Rustのタスク/tokioはこれを満たしていてGAFAMをはじめとしたIT大手各社が採用している
987: 08/12(火)19:32 ID:wTdmXaoa(3/4) AAS
>>985
その書き分けは正しくない
どちらもランタイムが必要な点では同じ
988: 08/12(火)19:43 ID:KkjDCbTs(1) AAS
バカおじは、特に非同期やマルチスレッドでの実行を意図していない通常のコードもスレッドで実行されていることを理解していないのだろう
RustやC#のタスクと比較したJavaやGoの仮想スレッドの最大の特徴は同期的なコードと非同期的なコードの間に違いが無いことであり、
既存の同期的なコードを非同期化しようとする場合にも大規模な書き換えを必要としない
989: 08/12(火)20:17 ID:/yJ0tylT(2/3) AAS
どちらが良いかは明らかで
言語自体も普及が遅れていて不利なRustのタスク方式を各社が採用した
その結果Rust自体も普及することになった
990: 08/12(火)20:28 ID:a3TkiHxV(4/5) AAS
タスクと仮想スレッドは違うと言いたいんだか同じと言いたいんだかブレブレで何言ってるかさっぱり分からん
991: 08/12(火)20:35 ID:a3TkiHxV(5/5) AAS
>>976「その仮想スレッドはRustではタスクと呼んでいて」
→同じ！
>>984「Javaの仮想スレッドもRustのタスクもGoのGoルーチンもOSスレッドに対してM:Nスケジューリングする点で違いはないよ」「違いはプリエンプティブかどうかスタックレスかどうかなど」
→目的が同じだけど違う！
>>986「目的は共通して」
→目的が同じなだけだからね！ 同じとは言ってないよ！
いつものくだらない言い繕いか
992: 08/12(火)20:41 ID:wTdmXaoa(4/4) AAS
大きな違いとしてはRustのタスク方式はスタックレスで他はスタックフル
Rustでは何万ものスタック領域確保が不要でその切り替えも不要という利点がある
993: 08/12(火)20:43 ID:BYPdwzD6(1) AAS
平日にくだらん言い争いやめろ
仕事しろや
994: 08/12(火)21:25 ID:/yJ0tylT(3/3) AAS
それまでマニア向けだったRustが
これによりIT界の実用部門で採用され
普及に拍車をかけた重要な分岐点とみることもできる
995: 08/12(火)22:23 ID:C7FhDLJq(1) AAS
このスレの半分は複おじでできています
複おじレスの半分は嘘・誇張・勘違いでできています
(残りの半分は自演レス)
996: 08/13(水)13:05 ID:8ztXa6qO(1/2) AAS
う
997: 08/13(水)14:21 ID:BMTFnZZ6(1) AAS
複
998: 08/13(水)18:02 ID:8ztXa6qO(2/2) AAS
お
999: 08/13(水)18:47 ID:p1WDfix1(1) AAS
じ
1000: 08/13(水)20:28 ID:G1NFqKcW(1) AAS
Rust最高！！
1001(1): 1001 ID:Thread(1/2) AAS
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 40日 22時間 58分 28秒
1002(1): 1002 ID:Thread(2/2) AAS
5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《UPLIFT会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
4 USD/mon. から匿名でご購入いただけます。
▼ UPLIFT会員登録はこちら ▼
外部ﾘﾝｸ:uplift.5ch.net
▼ UPLIFTログインはこちら ▼
2ch板:login
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.167s*