25/08/09 19:05:23.53 8jBxYJQq.net
>>888
変えるためにはグダグダだろうがなんだろうが一度は形にならなきゃいけないが、そもそも形になんねーんだよ。
安全が保障されるよりも、バグだらけでも�
911:ﾜず動かなきゃ話にならんのが現実の要件なんだ。
912:デフォルトの名無しさん
25/08/09 19:09:10.78 Aw+43M+T.net
>>890
形にならないとは何だ？
安全でなくバグがある要件なんて現実にないぞ
913:デフォルトの名無しさん
25/08/09 19:19:50.51 pUGHLIhK.net
>>891
自分でも安全性が保証されないことと安全でないことの区別付いてないじゃん
914:デフォルトの名無しさん
25/08/09 19:22:49.98 Aw+43M+T.net
>>892
Rustで書けばよい
必ず安全が保証される
915:デフォルトの名無しさん
25/08/09 19:34:03.38 8jBxYJQq.net
>>891
納期は要件の中で優先順位が高い。
納期を守れればバグの改修を後回しにする交渉は可能だ。
動くものが無かったらバグもクソもねーんだよ。
916:デフォルトの名無しさん
25/08/09 19:41:04.68 Aw+43M+T.net
>>894
そういう時はこういう症状のバグがまだ残っていますと添えて提出するだけの話だろ
Rustと関係なくどの言語でも同じ
917:デフォルトの名無しさん
25/08/09 19:47:31.13 Ab8eMDOi.net
>>895
多重下請けマっぽい物言いだが、だとしても複おじにまともに実務経験があると思えないんだよなあ
底辺クソブラックでロクに仕事もできず病んで数年で退職、以後長期ニートとか？
918:デフォルトの名無しさん
25/08/09 20:07:08.42 rQqeE1Vt.net
>>886
バグを回避するためにunsafeを使おうとしている？そんなアホな
レッドカードや
919:デフォルトの名無しさん
25/08/09 20:08:29.79 l1zXGfIU.net
シンギュラリティには納期がないのに物凄いお金をかけて大丈夫なのかな
920:デフォルトの名無しさん
25/08/09 20:36:20.23 Q6/AOvN1.net
>>897
バグの話なんてしてないけどどこをどう読んだらそうなるんだ
921:デフォルトの名無しさん
25/08/09 20:42:43.33 28rfMcPG.net
>>899
バグをつじつま合わせで回避する話かと
ちゃうん？
922:デフォルトの名無しさん
25/08/09 21:01:25.43 k8Vi1+RP.net
安全性とは関係ないバグもあるんだけどね
Rustでかくと安全性は保てるのかもしれないけど仕様通りの動作をしないバグとかは防げない
923:デフォルトの名無しさん
25/08/09 21:27:23.11 jMm762NP.net
Rustは読み出し中の書き換えや、書き換え中の別からの書き換えを防止してくれる
そのため知らぬ間に値が変わっていた系のバグも防げる
924:デフォルトの名無しさん
25/08/09 21:48:17.59 ZfnYWhel.net
ふーん、並列とかウェブってそんなに実需あるのか
俺は関数呼び出しの情報をそのままデータ化（Requestオブジェクト）するアイデアを思いついたんだけどそれって使える？
要するに関数ポインタ、引数、返り値を格納する変数へのポインタ、と、この3つを構造体に格納して遅延実行したりキューイングしたりするんだけど
925:デフォルトの名無しさん
25/08/09 21:57:58.06 28rfMcPG.net
>>903
目的とメリットは何やろ
クロージャや非同期関数など既にあるけど
926:デフォルトの名無しさん
25/08/09 22:06:39.52 ZfnYWhel.net
目的は一応並列
メリットは軽量
927:デフォルトの名無しさん
25/08/09 22:10:32.49 xyhx6hof.net
平凡すぎる
928:デフォルトの名無しさん
25/08/09 22:11:56.03 28rfMcPG.net
>>905
並列には不要かなー
並行には機能不足だね
929:デフォルトの名無しさん
25/08/09 22:19:05.11 ZfnYWhel.net
実行リクエストを出してその完了をその場で待つ、というニーズなら十分応えられる
それにこれってゼロコスト抽象じゃない？
それならあって損するものでもない
930:デフォルトの名無しさん
25/08/09 22:19:58.74 LF6KHoht.net
C++を安全に書けない人のために補助輪を付けたのがRustだ
安全に書けばC++の方がいいのだ
931:デフォルトの名無しさん
25/08/09 22:21:53.61 28rfMcPG.net
>>908
昔からのコールバック関数と何が違うのかな～
932:デフォルトの名無しさん
25/08/09 22:24:43.56 jMm762NP.net
>>909
使えばわかる
Rustは抽象度がさらに高く
書きやすく読みやすい
C++はメリットがない
933:デフォルトの名無しさん
25/08/09 22:32:22.44
934:ZfnYWhel.net
935:デフォルトの名無しさん
25/08/09 22:56:30.31 KGsTE/3q.net
AIって有能が使うと有能が加速するけど、馬鹿が使うと馬鹿が加速するツールだから頼らないほうがいいよ
936:デフォルトの名無しさん
25/08/09 23:08:49.86 ZfnYWhel.net
async/awaitの中身ってじゃあこの三つ組だったりするの？
937:デフォルトの名無しさん
25/08/09 23:22:31.78 28rfMcPG.net
>>914
awaitの地点毎に一旦出て再び戻ってくるよ
つまりステートマシンなコルーチン
スタックレスで実装されているよ
938:デフォルトの名無しさん
25/08/09 23:46:59.37 ZfnYWhel.net
俺はこれを定義して命名しただけで実装は誰がやってもいいと思うんだけど
高速ウェブサーバとか作れそうかな？
939:デフォルトの名無しさん
25/08/09 23:53:35.88 jMm762NP.net
環境キャプチャできるクロージャよりも劣る
940:デフォルトの名無しさん
25/08/10 15:31:38.50 1cj3h1dn.net
Rust 1.0ってもう10年前なんだ
941:デフォルトの名無しさん
25/08/10 19:32:55.30 2D3Ahc3U.net
>>879
コーディングスタイルは十人十色かもしれないが、
グダグダな辻褄合わせというフェーズの存在は初耳だ。
やり方もしくは能力になんらかの問題を感じる。
942:デフォルトの名無しさん
25/08/10 19:59:07.22 5hMvqzsk.net
エスパーだけど速いコードを書くことはできても小さいコードを書くことはできないことがあるからじゃない？
943:デフォルトの名無しさん
25/08/10 22:09:28.11 Zg5co2YS.net
どう
944:デフォルトの名無しさん
25/08/11 15:40:24.74 EC/wLypS.net
>>919
そうだよ。
大抵の場合に無能はいるし問題はあるという現実を前にしてそれでもなんとかしなきゃならないという話をしてるんだ。
945:デフォルトの名無しさん
25/08/11 15:59:02.43 GdF4E6X/.net
辻褄合わせのプログラミングをしてる人は言語関係なくプログラマーに向いていない
去ってもらうのが業界のため
946:デフォルトの名無しさん
25/08/11 16:30:48.22 3Pi1Vu8v.net
プログラミングしたら負け
947:デフォルトの名無しさん
25/08/11 17:25:34.81 X2QbX/qC.net
辻褄合わせのプログラム書いてる人がいると聞いて慌てて飛んできた
いったいどういう神経してんのさ、さっさとアーキテクチャー見直さないとかアホなの？
948:デフォルトの名無しさん
25/08/11 18:04:11.30 EC/wLypS.net
知らんわ。
俺にその権限はないし、「今」なんとかしなきゃならないときにそんなこと言っておれんのが現場ってもんだろ。
949:デフォルトの名無しさん
25/08/11 18:12:09.66 UQA5I5Ux.net
仕事の経験が無い人にはわからんのだよ
950:デフォルトの名無しさん
25/08/11 18:48:11.52 BYBfr1qg.net
>>756の言葉を借りるなら
なにごとも慣れ
取り組んでいればunsafeも上手く取り扱えるようになるよ
しかし避けていればいつまでたっても取り扱えないまま
951:デフォルトの名無しさん
25/08/11 19:35:04.21 GpYObhHZ.net
文法を100時間かけて習得しても、ちゃんとした設計でRustのコードをかけるようになるまでが長すぎる…。ChatGPTで解決しないレベルの問題ばかり引く
Builderパターンを使うべきか、new()に与えたくない引数を与えるかで30分も悩んじまった。Rustに変えてからこんなんばっか。別の言語の経験がもっと素直に生きるもんかと思ってた
952:デフォルトの名無しさん
25/08/11 19:42:07.67 oNbTL3km.net
さすがにそれは別の言語の経験とやらが自分が思っていたよりも浅かったということでは
953:デフォルトの名無しさん
25/08/11 19:48:10.80 GpYObhHZ.net
C++の経験がもっとあれば違った気がする
データサイエンティストが使うpythonはけっこう遠かった
954:デフォルトの名無しさん
25/08/11 20:12:48.42 N8nCnSEw.net
Python経験しかないならそりゃそうなる
言語の複雑さ以前に、そもそもそれらの機能が何故必要なのかが分からないだろうからチンプンカンプンだろうな
そもそもあえてRustなんかやる必要があるのかも疑問
955:デフォルトの名無しさん
25/08/11 20:14:46.95 SuQLHjmT.net
>>929
どの言語でも共通の概念があ�
956:闃e言語のやり方がある 同じくChatGPTに頼ったとしても個別のやり方だけをコピペして来た人は概念の理解に乏しく応用が利かない 別の言語の経験が生きるかどうかは本人の問題
957:デフォルトの名無しさん
25/08/11 20:36:59.84 7BdHEm5E.net
スクリプト屋が意識高い言語やりたいなら、Goとかのほうがいいんじゃね
958:デフォルトの名無しさん
25/08/11 20:46:19.85 Kb00poZQ.net
>>931
C++は不要だが比較的すぐ習得できると言われるC言語くらいはプログラマーを名乗るなら理解しておくべき
いわゆる参照の値渡ししかないPythonの経験のみでは何をするにも最初は時間がかかるだろうが
959:デフォルトの名無しさん
25/08/11 21:05:12.32 xz+O0Ovt.net
Cなんて値渡ししかない
やるならC++にするべきだ
960:デフォルトの名無しさん
25/08/11 21:35:06.71 ZDxIKfeQ.net
>>934
Goが意味を持つ領域は非常に狭い
今回は書かれてる情報よりPythonから呼び出す高速ライブラリ作成やPythonコードの高速化や省メモリだろうから
Rustが全言語の中でベスト選択肢
>>936
Rustを会得する上でC++の知識は必要ない
似た概念はあるが異なるためRustのために新たに学ぶ利点はない
961:デフォルトの名無しさん
25/08/11 22:00:32.02 BYBfr1qg.net
どんだけC++嫌いなんだ
962:デフォルトの名無しさん
25/08/11 22:08:22.37 dOXmVIim.net
C++からRustへ来てその違いの多さに右往左往してる人たちのために指南が行われるくらい方向性ちがうよな
963:デフォルトの名無しさん
25/08/11 22:27:35.71 7BdHEm5E.net
まあかぶってるのは最初から用途だけだし
964:デフォルトの名無しさん
25/08/11 22:27:41.34 X2QbX/qC.net
辻褄おじって複おじだろうな
C++なら設計不具合を辻褄合わせできるって、、、
それRustと違ってコンパイルエラー回避してるだけで設計なおってないぜ
965:デフォルトの名無しさん
25/08/11 22:37:24.77 05Dprm4o.net
>>929
>Builderパターンを使うべきか、new()に与えたくない引数を与えるか
これ他の選択肢は考えなかったの？
その2つで悩むくらいなら与えたい引数だけを取るコンストラクタを用意したほうがいいケースに見えるけど
966:デフォルトの名無しさん
25/08/11 22:37:41.46 AFY6XkLY.net
辻褄合わせのスパゲッティなプログラムを書く人はどの言語にもいる
Rustはスパゲッティなプログラムの主因でもある参照の競合を防げる言語
辻褄合わせをしてきたスパゲッティなプログラマーは破綻して炙り出される
967:デフォルトの名無しさん
25/08/11 22:37:56.35 oFJRCO1f.net
今更複おじの称号を他人になすりつけようとか小賢しいことしてもバレバレですよ
968:デフォルトの名無しさん
25/08/11 22:40:04.28 05Dprm4o.net
>>941
どう考えても別人だろ
969:デフォルトの名無しさん
25/08/11 23:52:30.33 DkamCpJM.net
下手なプログラミングしてきた者がRustは辛いと言い出すから下手さがわかりやすく出ちゃう
970:デフォルトの名無しさん
25/08/12 00:14:37.40 G/XPXKyQ.net
>>942
もっと複雑な実装をする時はその選択肢も当然入ってくる
971:デフォルトの名無しさん
25/08/12 00:22:19.92 G/XPXKyQ.net
>>935
Cの経験は独学レベルなら一応あるんだけど。Rustはまだまだきついわ
基本文法を取得してから、実戦投入に慣れるのに、2ヵ月か、下手したら3ヵ月ぐらいかかりそうな具合
俺、今まで関わった機械学習系の開発プロジェクトで、大体どこに行ってもコーディング一番得意な人だったのに
Rustはまだしっくりこない。やっぱ、この言語ちょっと特別な気がする
972:デフォルトの名無しさん
25/08/12 00:33:40.13 a3TkiHxV.net
設計に迷ったならAPIガイドラインっていうのが一応あるけど
そういう話じゃないか
URLﾘﾝｸ(rust-lang.github.io)
973:デフォルトの名無しさん
25/08/12 00:40:04.46 i1L5Xnaz.net
>>947
Builderを使う状況以上に複雑な場合なんてあるの？
いくつかあるオブジェクト生成方法の中で
最も複雑な状況に対応するのがBuilderパターン
逆に最もシンプルな状況に対応するのがnew()
その両極端で悩んだという話だから
new()よりの方法を紹介したつもりだったんだが
974:デフォルトの名無しさん
25/08/12 01:24:50.74 G/XPXKyQ.net
>>950
あー。その場限りのcontextの構造体を作るだけの最小構成ならBuilderパターンより軽いのか
コンテキストというと、どうしても汎用的なの、もっと言うとGod的なの想像しちゃった
コンテキストだとある程度は汎用性を持たせた実装にしないと、
最悪の場合、引数で与えたくない値をラップして見えにくくすることで、
罪悪感を和らげる的な実装になってしまう気がする
だから自分は重いコードを想像してしまった
975:デフォルトの名無しさん
25/08/12 01:24:59.60 MtCSZU3d.net
複おじの複って何の略なの？
オレオレ用語を使われてもよくわからん
976:デフォルトの名無しさん
25/08/12 01:48:28.10 a3TkiHxV.net
複おじの概要
ｽﾚﾘﾝｸ(tech板:5番)
977:デフォルトの名無しさん
25/08/12 01:50:32.88 a3TkiHxV.net
あの頃に比べると複おじは全然コード書かなくなったな
最近は他言語とか初心者をこき下ろしてばっかり
978:デフォルトの名無しさん
25/08/12 02:40:56.87 u3A5dRZj.net
>>950
Rustでnew()の意味は決まっていなくて自由だけど
おおむね最小限のものを与えるものがnew()
つまりnew()の引数は最小限のものを作るのに必要なもののみ
今回はnew()に与えたくない引数を与えるか悩んでるようだから
必要最小限てはない引数であると推測できる
この状況では3つの単純な方法
①new()してからsetxxx()を呼び出す
➁①の2つを一気に行なうxxx()を作る>>942
③ビルダーパターン
979:デフォルトの名無しさん
25/08/12 08:30:19.04 4cospISj.net
今時そんなパラメータ並べるだけの低次元な単純作業はAIにやらせりゃ一瞬なんだからどうでもいいよ
内部的に使うだけであり、かつAI利用を前提とするなら、>>942案がベター
ユースケースに特化した最小限の実装の方が人間がコードレビューしやすいし、少ないトークンで済むし、AIに余計な混乱を与えない
後で変更する必要が出てきたときの認知負荷の問題もAI前提ならあまり考慮しなくていいしな
980:デフォルトの名無しさん
25/08/12 10:27:16.64 uzbu6zoz.net
Rustの仕事って複おじみたいな活動をする仕事しかもうないんじゃね
981:デフォルトの名無しさん
25/08/12 10:32:04.33 o6GedXY5.net
>>951
コンストラクタとコンテキストを空目してる？
982:デフォルトの名無しさん
25/08/12 10:47:11.93 6RAsIQle.net
ビルダにしつつマクロでくるむのもよくあるパターン。
Rust には可変長引数がないから割と気軽にマクロを使う。
それか引数全体を構造体にして基本パターンを Default で生成できるように実装しつつ変更が必要なところは .. で変えるみたいなのもある。
983:デフォルトの名無しさん
25/08/12 10:56:03.75 5BWK9Np7.net
>>955
いわゆる依存性の注入パターンだから
Constructor Injection
Method Injection
Setter Injection
どれを使ってもよくて大した問題ではないな
しかしこれはどの言語でも起きる共通の話
>>929がRustに変えたら悩んだと言ってることが理解できない
984:デフォルトの名無しさん
25/08/12 10:58:44.65 G/XPXKyQ.net
>>958
はい。空目した
985:デフォルトの名無しさん
25/08/12 11:05:02.51 ag9TAHO3.net
実質ビルダと変わらんけど初期化用の構造体からfromとかintoで変換するのがRustっぽい
impl From<...>
986:for Foo を複数の型に対して実装すると初期化オーバーロードの代替になる
987:デフォルトの名無しさん
25/08/12 11:09:29.01 S3jeW6Sh.net
>>957
システムプログラミング用だけどC/C++と違って組み込みみたいな数こなす仕事がないからね
一部、自動運転のような高度な分野で使われているようだが、Rustを好むような層に作業服着て愛知の工場で働きたい奴がどれだけいるかは激しく疑問だわな
Web系にしてもRustは少ない労力で極めて大きくスケールする部分に限定して用いられるのが現状で、
大量に並んだ業務トランザクションの一覧を一個一個実装してくような性質の仕事じゃないから、Rustの仕事はごく一部の上位層に限られる
988:デフォルトの名無しさん
25/08/12 11:17:08.27 55fYHsEH.net
>>962
Rustプログラミングはトレイトを用いたジェネリック化が基本だよね
初期化生成が単なる変換で済むなら独自トレイトは不要でFromやTryFromを使うのがRust流
なぜトレイトを使うべきか理由は複数の型に対応できるだけでなくテストの時のテスト用モック型も同様に扱えるため
989:デフォルトの名無しさん
25/08/12 11:20:36.03 kIE6XRW2.net
>>963
生成AIでもライブラリのRust化など色んな分野でRustへ置き換わる方向へ進みつつあるよ
990:デフォルトの名無しさん
25/08/12 11:34:03.77 sCNFFs6h.net
Rustがネイティブで動くFPGAとか出てこないかな
991:デフォルトの名無しさん
25/08/12 11:34:46.25 G/XPXKyQ.net
個人開発でiphone, android両対応のアプリにcrdtを組み込むのにrustを使ってる
そんな上位層でもないんだけど
992:デフォルトの名無しさん
25/08/12 11:45:54.31 qcKUJthg.net
ビルダーやnewとかfromコンストラクタとかの話は言語機能の貧弱さから来ているんでは？
文法でなくコミュニティ依存のベストプラクティスを学ばないといけないのは弱点だと思う
後で潮流が変わってそのためだけにシグネチャを変えるのがバカバカしい
変えないと古臭いとか勉強不足と言われるのもくだらない
993:デフォルトの名無しさん
25/08/12 12:08:53.37 cacY6MRR.net
>>968
言語機能が強いからFrom実装だけで任意の型に対して対応できるんよ
エラー型の変換にしても同様
？オペレータで自動的にInto変換されるためこれもFrom実装だけで対応OK
994:デフォルトの名無しさん
25/08/12 12:19:28.82 TPXEzVE3.net
>>965
Rust意味ないじゃんｗ
995:デフォルトの名無しさん
25/08/12 12:22:14.20 IjrX/Wgj.net
>>968
コミュニティ依存の方法なんてないぜ
全てRust標準ライブラリで用いられている標準の方法だ
Fromを知らずして君はRustの何を勉強したと言うのだ？？
996:デフォルトの名無しさん
25/08/12 12:49:05.48 aUpqhYkf.net
newはコミュニティで意味をもたせてるだけで、別に言語的に特別な意味を持たないっていうのは
どうなんだろうなとは思う
997:デフォルトの名無しさん
25/08/12 12:55:21.80 9RnwCZim.net
>>970
どの分野でも省メモリ化や高速化が求められる部分があって従来はC/C++で書かれていたんだけど
今は安全性の観点からもRustを使えるならRustを使え、になっていってる
日本でもすぐにそうなるよ
998:デフォルトの名無しさん
25/08/12 13:03:36.49 uzbu6zoz.net
>>973
生成AIは安全なの？
999:デフォルトの名無しさん
25/08/12 13:07:23.74 6RAsIQle.net
コンストラクタに元から特別な意味などなかったことに気づいたという話なんじゃねーの。
new は共通するインターフェイスに出来ないからトレイトにする意味もないし。
1000:デフォルトの名無しさん
25/08/12 13:14:49.76 U2drFIcF.net
>>863
その仮想スレッドはRustではタスクと呼んでいて既に実現されている
業界がRust支持へ回った背景としてRustの軽量なタスク実装がサーバーの能力を最大限に引き出せることを実証した点が最も大きい
安全なだけでは採用されなかった
1001:デフォルトの名無しさん
25/08/12 13:56:44.32 tGCKXEeA.net
tokioのtaskのことだと思うけど、あれは仮想スレッドとは違うよ
仮想スレッドというと、 awaitのような中断ポイントを明示せず普通の関数のように書けて、かつIO処理をランタイム側で非同期にやってくれるものを指すと思う
1002:デフォルトの名無しさん
25/08/12 13:57:24.16 tGCKXEeA.net
JavaやGoは仮想スレッドを
1003:デフォルトの名無しさん
25/08/12 14:04:54.70 S3jeW6Sh.net
わざわざ100レス遡って初心者レベルの間違った知識を披露する
これが複おじの真骨頂よ
1004:デフォルトの名無しさん
25/08/12 15:14:44.73 tZhL89Xj.net
>>974
もしかして複おじ
1005:デフォルトの名無しさん
25/08/12 17:12:45.82 wTdmXaoa.net
>>977
taskはtokio固有ではなくRust自体の概念
tokioはスケジューラーの1つにすぎない
tokioがなくてもtaskは機能する
軽量スレッドの実現にOSスレッドやOSプロセスと同様のプリエンプティブを求めるべきかどうかは議論が分かれるが
目的は軽量で高速に大量に動けばよく
同一プロセス内の自分自身のコードならば協調型でも支障はない
Rustでもversion 1.0になる前はプリエンプティブな軽量スレッドが採用されていた
しかしオーバーヘッドが大きいため廃止されてからRust 1.0が出た経緯がある
そして真に求められている実用的な軽さと速さから現在の協調型非同期なtaskが採用されその実用性が示された
結果としてRustへの移行が進みこの判断が正しいと証明された
1006:デフォルトの名無しさん
25/08/12 17:50:01.63 6RAsIQle.net
仮想スレッドの「仮想」は抽象度が高いことを言ってるものと理解してる。
仮想スレッドはスレッドのように動作するが実際に (OS が提供する) スレッドにどう割り当てられるかは実装の都合。
ひとつのスレッドの中で複数の仮想スレッドが協調スレッドのように動作するようなことがあるかもしれないし、
実際には同期的かもしれないが見かけ上はひとつの実行単位として抽象化されたレイヤが与えられている。
そういう意味でなら Rust のタスクは仮想スレッドのような概念だと言っても間違いではないんじゃないかな。
タスクはあくまでも見かけ上のインターフェイスであって、それを実際にどう処理するかはランタイムの選択次第。
1007:デフォルトの名無しさん
25/08/12 18:56:38.02 Fr0OCoiD.net
>>982
君やRustコミュニティがRustのタスクを仮想スレッドと呼ぶのは自由だが、明確に異なるものであることを理解しておく必要がある。
JavaやGoにおいておいて仮想スレッドで実行されるコードは完全に同期的であり、
OSスレッドだろうと軽量スレッドだろうとその上で実行されるコードに違いは生じない。
1008:デフォルトの名無しさん
25/08/12 19:11:01.80 wTdmXaoa.net
Javaの仮想スレッドもRustのタスクもGoのGoルーチンもOSスレッドに対してM:Nスケジューリングする点で違いはないよ
Rustの場合はスケジューラ依存だがtokioなどで全く同様にM:Nスケジューリングできている
違いはプリエンプティブかどうかスタックレスかどうかなど
Rustは協調的にスタックレスでパフォーマンスを出している
1009:デフォルトの名無しさん
25/08/12 19:11:36.92 evYq+DIX.net
仮想スレッドとタスクは別物だろう
タスクは非同期ランタイム上で実行される処理の方に注目したもの
JavaやGoだと「仮想スレッド上で通常の関数やメソッドを呼び出す」、RustやC#だと「非同期ランタイム上でタスクを実行する」という感じ
これらはそもそも違う方式
1010:デフォルトの名無しさん
25/08/12 19:24:15.59 /yJ0tylT.net
目的は共通して
高速かつ同時に大量に扱えること
CPUが持つ多くのコアスレッド数を偏りなく限界まで使い切れること
そして現実の用途でそのパフォーマンスを発揮すること
Rustのタスク/tokioはこれを満たしていてGAFAMをはじめとしたIT大手各社が採用している
1011:デフォルトの名無しさん
25/08/12 19:32:22.66 wTdmXaoa.net
>>985
その書き分けは正しくない
どちらもランタイムが必要な点では同じ
1012:デフォルトの名無しさん
25/08/12 19:43:37.81 KkjDCbTs.net
バカおじは、特に非同期やマルチスレッドでの実行を意図していない通常のコードもスレッドで実行されていることを理解していないのだろう
RustやC#のタスクと比較したJavaやGoの仮想スレッドの最大の特徴は同期的なコードと非同期的なコードの間に違いが無いことであり、
既存の同期的なコードを非同期化しようとする場合にも大規模な書き換えを必要としない
1013:デフォルトの名無しさん
25/08/12 20:17:50.06 /yJ0tylT.net
どちらが良いかは明らかで
言語自体も普及が遅れていて不利なRustのタスク方式を各社が採用した
その結果Rust自体も普及することになった
1014:デフォルトの名無しさん
25/08/12 20:28:25.50 a3TkiHxV.net
タスクと仮想スレッドは違うと言いたいんだか同じと言いたいんだかブレブレで何言ってるかさっぱり分からん
1015:デフォルトの名無しさん
25/08/12 20:35:35.59 a3TkiHxV.net
>>976「その仮想スレッドはRustではタスクと呼んでいて」
→同じ！
>>984「Javaの仮想スレッドもRustのタスクもGoのGoルーチンもOSスレッドに対してM:Nスケジューリングする点で違いはないよ」「違いはプリエンプティブかどうかスタックレスかどうかなど」
→目的が同じだけど違う！
>>986「目的は共通して」
→目的が同じなだけだからね！ 同じとは言ってないよ！
いつものくだらない言い繕いか
1016:デフォルトの名無しさん
25/08/12 20:41:50.62 wTdmXaoa.net
大きな違いとしてはRustのタスク方式はスタックレスで他はスタックフル
Rustでは何万ものスタック領域確保が不要でその切り替えも不要という利点がある
1017:デフォルトの名無しさん
25/08/12 20:43:33.09 BYPdwzD6.net
平日にくだらん言い争いやめろ
仕事しろや
1018:デフォルトの名無しさん
25/08/12 21:25:01.40 /yJ0tylT.net
それまでマニア向けだったRustが
これによりIT界の実用部門で採用され
普及に拍車をかけた重要な分岐点とみることもできる
1019:デフォルトの名無しさん
25/08/12 22:23:03.93 C7FhDLJq.net
このスレの半分は複おじでできています
複おじレスの半分は嘘・誇張・勘違いでできています
(残りの半分は自演レス)
1020:デフォルトの名無しさん
25/08/13 13:05:59.56 8ztXa6qO.net
う
1021:デフォルトの名無しさん
25/08/13 14:21:30.18 BMTFnZZ6.net
複
1022:デフォルトの名無しさん
25/08/13 18:02:27.96 8ztXa6qO.net
お
1023:デフォルトの名無しさん
25/08/13 18:47:51.10 p1WDfix1.net
じ
1024:デフォルトの名無しさん
25/08/13 20:28:33.97 G1NFqKcW.net
Rust最高！！
1025:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 40日 22時間 58分 28秒
1026:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています