Rust part22
レス数が1000を超えています。これ以上書き込みはできません。
Rustを理解していく順序 (文法以外)
ownership
↓
lifetime (これ以前でも参照を持ち越さない範囲で可)
↓
trait (これ以前でもライブラリ既存traitメソッド使用は可)
generic (これ以前でもライブラリ既存genericメソッド使用は可)
↓
macro (これ以前でも既存macro使用は可)
async (これ以前でも同期で使用可)
↓
unsafe (ほとんどのことはunsafeを使わずに可能)
もしunsafeを使わないと効率よく実装できない安全なパターンを見つけて、
かつ、それが既存ライブラリに存在しない新たなパターンならば、
それは大発見だから皆のためにそのcrateを公開すべし オーナーシップとかAIにやらせればOK
意識して時間割く必要なし >>5
パターンマッチングはCopy実装型はcopyされてそれ以外はmoveされる
copyやmoveを避けるには
マッチング対象を参照にすれば
全て参照として受け取れる
しかしある部分はcopyである部分は参照で受け取りたいことがよくある
(例えば数値とStringで構成されてる場合)
その時は参照で受け取りたい部分のみrefを付けるとそこは参照で受け取れる >>5
refはbind by reference
左辺(相当)でのみ使う(binding生成時のみ)
右辺で&を使うのと同じだけど右辺で&を指定できない場面で使う
&を左辺で使うとパターンマッチでデリファレンス
右辺で*を使うのと基本同じ >>https://mevius.5ch.net/test/read.cgi/tech/1692105879/990
一応知らない人のために書いておくけど
「Rustがunsafeコード一切なしでメモリアンセーフ」な事が判明してから半年近く経ってる
特定の機能導入のタイミングでコードが発見されたけど、
「Rustの仕様バグ」だと認識されていて直せない
>>4
そんな事並べて理解したつもりでも、分からないと言っている人の側の主張が正当なんだよ
最近はここでも保証って言われなくなっただろ、当たり前だよRustの仕様に健全性が無いのだから
たぶん知っていて話を逸らしているのか、過去スレでスルーしたかで、この指摘も無理やり矮小化してくるからな
(githubの議論でも矮小化して放置)
気を付けろよ
https://github.com/rust-lang/rust/issues/114936 仕様バグだから直せないじゃなくて
厳密なチェックをする実装は0から作ったほうが早いから
今使ってる確率的(笑)な実装は変更しないんだよね？ これマジ？ どれくらいの確率で踏むんけ？ コンパイルのバクはケアしたくないなあ >>12
意図的にvarianceの穴を突く無意味なコードを書かないと発生しないため>>9は無害 >>9
こんなコンパイラの脆弱性を突くようなコードを普通なら書かない定期 >>9は9年前の2015年から既知の有名なパターン
意味のあるプログラミングで絶対に踏むことはないため害はない
その特殊ケースに対応するデメリットの方が大きいため対策されていない
それらを踏まえたうえでIT大手が揃ってRustを採用しRust Foundationも設立された 9のコードの意味が理解できないんだが何が問題なのか説明してくれ c++のテンプレートはチューリングマシンだから
無限ループを起こせるのは仕様の欠陥がどうか聞きたい f: impl for<'s> FnOnce(&'s str) -> (&'static str, [&'static &'s (); 0]) の説明だけ。
ライフタイム 's の str を引数にして、&'static str 型と、[&'static &'s (); 0] 型のタプルを返すクロージャが f ということ。
[&'static &'s (); 0] は &'static &'s () 型の長さ 0 の配列。
&'static &'s () は、ユニット型() のライフタイム 's の参照のライフタイム 'static の参照。
この &'static &'s () の部分で変なことが起きてそうと言っとるな。 >>17
C++ の仕様ではテンプレートの展開深度に上限を設定することを認めているのでチューリングマシンではない。
非現実的な回数のループが起こるのならそれは処理系の欠陥。 >>15
1.65.0で新しく導入された回帰バグですって書いてあるし
2015年の#25860とも別だねってコメントも付いてますやん >>18
文脈無視してその引用だけで言えそうなことは
&'static &'s T 型が存在するならば 's も 'static でなければならない
このルールに反しない限り &'s str を &'static str に変換してよい 安全にこれで&'staticへ変換できる
fn to_static_str(s: &str) -> &'static str {
s.to_owned().leak()
} 最後までずっと使うものやあるいは
あるメモリ限度内に収まる使い方ならば
リークさせて扱いが楽になるメリット享受を選ぶのもありかもな >>22
それ&'static strではなく&'static mut strを返してもええねんで leakは安全
そのプログラム終了まではその部分のメモリを解放しないだけ >>25
Rust の定義ではメモリリークは安全性を損なわないことになってる。
言語の機能として積極的に阻止しなければならないような動作ではないが、
だからといってむやみにリークさせていいわけでもないのは当然なので
そこらへんはロジック上の必要性を鑑みて「正しく」運用するのはプログラマの責任だよ。 leakは参照を削除するとメモリリークになると書いてあった（機械翻訳）けど参照って削除できるの 期待した通りの結果になるのは危険ではないという知見は合理的だ
期待や願望よりも地獄のような厳しい現実にこだわるバイアスがかかってない >>28
leak()は所有者がいなくなるだけ
つまりそのメモリ領域が解放されなくなるだけで安全な行為
そこを指す参照だけになる
一般的に参照は指しているだけ
その参照を表す変数もしくは一時的な値が消えればその参照は消えたことになる
参照が消えても実体には何ら影響なく解放なども生じない メモリリークにならない＝参照がデストラクタを呼び出せる
ではなく
参照はデストラクタを呼べないが、参照が永久に残ればメモリリークにならない メモリリークは多義なので
GC言語でも、今後は使わないオブジェクト等をどこが参照しているため解放されない、これもメモリリークと言う
つまり参照が残っているからメモリリークじゃないとは言えない
逆にRustの場合は、leak()を適用した時点でそこは永久に解放されないのだから、既にメモリリークとも言える
もちろんそれで困らない時に意図的にリークを可能とするものなので、その機能や行為自体に問題はなく、そのプログラムの性質や環境や方針次第 多義である事実に人間が従うのではなく、定義を変えたいので変えまくった人間に事実が従う
利己主義の結果を予想するのではなく結果を予想できる範囲内で利己的になる きちんとメモリ確保・解放する
ただそれだけのことだけどうまく行かないものだね >>35
Rustならそれができるし保証される
ただしその基本に加えて融通を利かせることもできる
意図的にリークさせる(解放しない)こともできるしそれを使わないこともできる
意図的に循環参照を作ってリークさせることもできるしそれを避けるための手段も用意している それくらいできてくれないと習得に対して割に合わない >>35
二回以上解放しない保証は大成功した
一回以上解放する保証をやる気がない
与えられた問題を勝手に分割してやりたい部分だけやってる Rustでは意図的にリークもしくは意図的に循環参照作成の場合を除いて必ず解放される スポーツでも五輪だけが目的のプロがいたら割に合わないが
なんか目的をあやふやにすれば五輪に出ても破産しないよね Microsoft seeks Rust developers to rewrite core C# code
https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/
でかいところのバックエンドRust化が増えてきたな Pythonやkotlinみたいな手軽さで堅牢で高いパフォーマンスが出れば最高なんだけどなかなかね from C to Rust へのマイグレーションは時間がかかるからしゃあない >>43
Pythonはスクリプトを書く程度ならいいけどプログラミングには不向き きちんとガベコレしてるのに見下されてるなあPythonは
きちんとしても割に合わない 動的型は堅牢とかきちんとやるみたいなのと相反するんだよな
書き捨てならいいけど長期的にメンテするやつには向いてない Rust、言うほどPythonと比べて手軽でないか？ プログラマの意図を書かないと、意図を表せる言語じゃないと「正しい」かどうかは検証しようがない。
だから意図の表現方法として型やライフタイム注釈やらの形を確立したのであって、お手軽に柔軟に動かす言語では実行時に不都合があれば止まるという形にならざるを得ない。
静的型があれば全部が解決ってわけではないけどごく基本的な整合性検査すらせずに実行するまでわからんというのはメンタル的にきつい。動的型はきつい。
自分で把握できる程度の小さな規模なら動的型のほうが楽ってこともあるといえばあるけど、人類は駄目なのでちゃんと把握できる規模は自分で思っているよりだいぶん小さい。 Pythonはやっぱり行列を扱うのに長けてる気がするな
ただ静的には何の変数を見ても(Variable)xxx: Anyみたいな型推定しかされていなくて、自分の書いたコードですら訳がわからなくなる
他人の書いたライブラリを使うときはまるで魔法を使ってるかのようだ Pythonというかインタプリタは部分的にCを使うことを認めざるをえない
それを大多数に納得させるコストが激安 >Pythonはやっぱり行列を扱うのに長けてる気がするな
pythonのどこが？numpyがあるだけじゃね。 PythonはC/C++/Rustで書いたライブラリを呼び出すスクリプト言語として使っている限りは問題ない
プログラミング言語としては不向きで使うべきではない OSのカーネルにはPythonは不向きだからクソどうでもいい生存競争をしなくてすむ 使い分けが出来ない人はスキルが低いだけ
言語に限らずどの技術でも同じこと 各種カーネルのRust移植に時間かかってるけどC/C++からRustへの書き直しってそんなに大変なの？ Pythonもプログラミング言語だしシェルスクリプトも立派なプログラミング言語だよ プログラミング言語はそれに付随するフレームワークの質で需要が変わってくるけど、
C/C++/Rust/アセンブラなど低水準言語はガべコレのランタイムが不要というアドバンテージがある
だからカーネル用途での需要が高い Ruby もだいぶん長いことバイトコード化すらせずに木を辿るクソ遅い設計だったんだぞ。
でもなあ、使い分けといってもやっぱり慣れたらもうちょっと他の場所でも使いたくなるし、速度の要求も静的検証の要求も出てくる。
今の Ruby は Jit で速くなったし型チェックのサポートも本格的になった。
使い分けは要るがせずにすむならそれに越したこともないんよ。 >>56
そのまま移植はほぼ不可能でしょ
データ構造から設計しなおさらないと
クソコードになりがち C の世界の文字列はゼロ終端やんか。
カーネルのインターフェイスにもその規約がそのまま現れてる。
内部的な設計は Rust 的にしつつも外向きのインターフェイスは変えないように置き換えるなら微妙な変換があらゆるところに出てくるよ。
まあそのへんは適当な専用フレームワークを確立させればたいしたことでもないが、そういう地味なことの積み重ねがいっぱい要るよ。 C/C++からJavaってのはすげー移植しやすかったのよ
その利点はほとんどないと多くの人が気がつくのに20年もかかってしまったけど >>56
書き直しさえすれば何でもいいというのは大変だろうね
何でもいいというのは嘘で
本当は好き嫌いがあるから コード移植なんてつまらなくて言語差で面倒なだけ
守るべき仕様さえはっきりしてるならゼロから書いたほうが結果的に早くて質も良くて楽しい 仕様とか契約とか目的とかは未来を予測する根拠としてはイマイチ科学的でない Linux だとバイナリ互換性もかなり大事にしてる。
(Windows ほどじゃないが。)
仕様として明文化してない挙動に依存するアプリケーションであっても今まで動いていたものが動かなくなるのは良くないという方針。
「守るべき仕様がはっきりしていれば」という前提がなりたたないから困るんだよ。
そしてそれはよくあること。 ときどき仕様も要件定義もはっきりせず発注者が把握できていないものの言語移植ケースがあるがその仕事を引き受けないほうがいい
バグらしきもの含めて現存コードと同じ動作をするよう求めてくるためムダな面倒に精神力が奪われる 仕様さえ守っていればいいみたいな考えに従うと最近はお役所系でもちらほら見るクローム以外を
排除する極右Webサイトが出来上がったりするんだろうな。発注側でも受注側でもね ちゃんと充分な調査費用も出るならやらんでもないけどな。
大きなシステムの一部をリライトする場合には一から作る場合より数倍のコストがかかっても
全体をやり直すよりはマシだから「同じもの」を求めるのはそれなりに合理性がある。
全部をリプレイスするのに前と同じという要求するやつがいたら、
前と同じがいいならそのまま使っとけやという気持ちになる。 C/C++→Rust 安全化とそのデバッグ開発効率化
C/C++以外→Rust 高速化と省メモリ化
これらの恩恵があるため
安全でないことによるバグ発生で困っているならC/C++→Rustを
CPUメモリリソース削減が求められてあるならC/C++以外→Rustを
たとえ同じ仕様のままでもやる意味が生じる >>70
費用対効果考えると厳しいな。
c++のプロジェクトをRustに切り替えるよりか、コーティング規約組んでlint用意して強制したほうが効果高そう。
既存コードの扱いが難しいけど。 Webアプリ用途でもAxumやActixがフレームワークとして十分使いやすいから、もっとRustは普及していい c++ から rust に移すなら、その前に c++ コードのリファクタリングとしてmove使用コードに直すだろうし、
それやったらもうそれで良くね？ってなると思うわな。 言語移植はそのうちAIがなんとかしてくれるんじゃなかろうか 所有権があるから GC 言語からの移行でも安全になる恩恵はあるんだよなぁ。
ほんとエポックメイキングな言語だよ。 rustの最大のメリットは、絶対では無いけどコンパイルさえ通ってれば他人のクソコードに悩まされずに済む点じゃないかね。 Rustでも糞コード見かける
たとえば非常に単純な例でいうと元の部分strを返せば済むのにString作っちゃうなど無駄にヒープ使ってしまうケース
でも見抜きやすく手直しもしやすい Rust以外でよく見かけるのはど
こで書き換わっているかわかりにくく副作用や競合が心配なケース
Rustではデータ競合が起きないしグローバル変数も制限があるためこの手の類には悩まされない メリットが欲しいと思ったことはないな
新しいジャンルで唯一の選択肢なのでメリットの大きさを比較する必要がない
異なるジャンルでは比較する意味がわからない >>78
1周回ってString返したほうが良くなる状況もあるからそんなに単純じゃないよ >メリットが欲しいと思ったことはないな
誰もメリットが欲しいかどうかについては話してないよｗ >>81
それは絶対にない
部分str返しで済むなら必ずそうすべき
それを返された側がString化が必要な時のみ行なう 欲しくないものを供給している可能性を誰も想定していないのか わかりやすいのがstr.trim()かな
前後のスペースを取り除く関数だけど当然Stringではなくstrの一部分を返す
Stringがほしい人はstr.trim().to_string() >>85
欲しい人にもそうでない人にも対応できるように&strがベストとは思わんか？ >>86
同じ主張だよ
str返しが可能ならStringを返してはいけない
slice返しが可能ならVecを返してはいけない 上書きされる前に別の場所にコピーした方が比較的安全というメリットが消えた
Rustが消した >>88
Rust以外ではいつ書き換えられたりor解放されたりするかわからないから
安全なプログラミングということで(無駄になる恐れもあるけど)コピーしておく安全策をとることがあった
Rustでは知らぬ間に書き換えられたりor解放されたりすることはないので
安全策を保ったままで無駄なコピーが不要となった Stringを使うことで無駄に専有されるヒープメモリはそこまで悪に感じないわ
カーネル作ってるわけでも競技やってるわけでもないんだったらね
可読性のために型を統一させるほうを優先する >>90
主張がよくわかりません
&strを渡せば済むところをString渡しで統一したりしてるのですか？
それで可読性が上がるとは思えません >>90
そのためにムダにto_string()やそのclone()をするのは間違い
他の言語やスクリプト言語ですらそんな酷いことは行われずにコピーオンライトやインターン化でムダを防いでいる
Rustではまずは&strで行ける範囲は&strで行き次にCow併用そして同じ中身のStringが複数できるならstring_cacheなどでインターン化など C++でもstring_viewとstringは使い分けるぞ &strでいいなら&strで返すのが基本だけどプログラム全体を見たときにStringで返したほうがものすごくコードを単純にできる場合がある
アロケーションコストが全く問題にならない状況であれば&strに固執する必要はない
無駄なヒープアロケーションは増えるけど違う観点の無駄を削減してる
トレードオフだよ
型を統一するって話はよくわからんけど そこ気にしないなら普通にスクリプト言語でも使っとけば良いと思うよ >>94
そんな例は起きない
strを返された側でString化が必要な時のみするのがベスト >>96
そりゃベストはそうだろうけどさ…
c++で言うchar型で良いところをわざわざstdのStringを使うなって話でしょ？
動的メモリ確保になってようがその程度の誤差くらい動けばどっちでもいいわ… >>95
Rustから一気にスクリプト言語は飛躍しすぎだからスクリプト言語より先にガべコレ付き言語を薦めてくれ
ガべコレ付き言語はヒープメモリを気にしない人にはおすすめだよ >>97
文字列だけでなく一般的な話
部分スライスを返せば済むところをわざわざVecにして返すことが許されるのか？という話だぞ
これを誤差だと言い張るならRustを使う資格はない sliceやstrですむのにVecやStringを使ってしまう人はlifetime parameterを習得できていなくて使えこなせないからだと思うよ
structやfnでlifetime parameterを付けたことのない初心者に多いね こういうふうに面倒くさい人がRust使いには多いから普及しないんだろうなあ
アルゴリズムとデータ構造の分野からみてもクッソどうでもいい議論だよ >>102
アルゴリズムとデータ構造の一番の基本が無駄なコピーをしないこと strで返せるがあえてStringで返すと良い具体例を出せばいいのではと思った。 富豪的プログラミングしたいならrustは向いてないよ
普通にpythonで十分 でもPythonのDjangoは遅くてゴミじゃん
省メモリ最速のWebアプリ作るならRust一択だわ 例えばsplitみたいなのはstrで返せるけど、それを大量に呼んで受け側でto_stringをつける場合、
コードがto_stringだらけで見づらくなるとかはあるかな
そういう時にsplit_to_stringみたいな名前でString返すようにしたりはするけど
自分の場合、どっちかっていうとパフォーマンス云々より関数名から内部でアロケーションが連想されるかどうかを重視してる気はする rustでwebアプリなんてコストかかりすぎでは？ふつーにgoかjava/kotlinかc#で作ればいいじゃん >>104
ないでしょ
少なくともその関数側で判断できるものではない
帰ってきた文字列をどうするかは使う側が決める
これはrustに限った話ではなくプログラミングのお作法の話
文字列を変更したいという意図で所有権を持った文字列を作りたいならto_ownedすべきだし
そうでないならライフタイムを意識してそのまま使えばよろしい
C/C++でも全く同じ話よ
C++ならstring_viewを返す
そこであえてstringを返す意味はライブラリ提供者側にはない
例えば10000回のループの中でそのような関数が呼ばれたらどうなるか？
恐ろしいことになる
C/C++だと常にそういうことを考えてる
pythonとかだと全部stringだから意識してないのだろうけどさ
本来は意味のないアロケーションであることが多い >>107
大量であっても&strのままでよいものはString化しない
String化が避けられない場合でも大量ならばイテレータで処理してるはずなので.into()の数は少ないはず
いずれの場合でも関数は&strを返せばすむ 正しいことが必ずしも正義とはならない、とだけ言っとくわ >>108
RustでWebは容易かつ向いている
Rustの公式アンケート世界調査でも最多利用はWeb分野 rustあんま使ってない人だけど、strはImmutableでstringはMutableなんでしょ？
文字列配列を柔軟に扱いたいときだけstringで色々して、データを受け渡しするときは当然strを使うのがモラルってもんでしょ
immutable_stringはよく知らん 今現在Rustが実際に多く使われてる分野って、スクリプト言語の下まわり、ライブラリ高速化だよね
だからそれはWeb用だと言われたらまぁそう >>112
108だけどそれはasm.jsの代替のwebアセンブリってやつをrustでやってるんでしょ
webアプリとは違うねん 単なるWebサイトの演算処理の補助用途とWebアプリ用途を一緒にしてほしくない
全然違うねん >>117
スクリプト言語のライブラリとしてRust使ってる人はそんなアンケートに答えないし
自分がRust使ってる自覚もないよ >>118
Rustで何を開発しているか？だからそれら別言語の人は関係ない
PythonやJavaScriptなどのライブラリが最近はRustで書かれることが増えたが
その開発者たちもRust利用者全体から見れば少数
一番多いのはWebのサーバーサイド・バックエンド・クラウド WASMはRustに限らずそんなに大っぴらに普及しないと思う
ゲームエンジンかエンコーダーデコーダーくらいにしか需要がない
GUIとしてのWASMはDOM操作を直接できない時点でゲーム操作用途にしか使えないゴミ、終わっとる wasmは触ってみりゃ分かるけどjavascriptの演算処理を単にrustで書いてコンパイルしてみると、rustのstdがバイナリに同梱されるせいで移植前のスクリプト状態よりファイルサイズが増加するんだよね
wasmテキスト形式で書くかstdレスなrustで書かなくちゃ本末転倒になる
まあファイルサイズが増加してでも演算処理を高速化したいならいいんだろうけど俺は吐いた >>117
組み込みシステム開発者なんていう有能が溢れるほどいるわけないし妥当な結果ね
にしてもRustがサーバー開発でこんなに占めてるんだねえ >>121
WASMはWebブラウザ内用途だけではないよ
CDNエッジでの利用も増えているね
WASIなどによる拡張でできることは無数に増えてく
>>122
stdは無くてもRustは機能するようにできているよ
例えばスライスやstrはcoreにあるし
VecやStringはallocにあるよ WASIはモバイルOSあるいはデスクトップOS業界がどう動くかだね
wasmerみたいなWASIランタイムをOSが標準装備してくれるなら、WASIの注目度が上がるし、OSに依らないアプリを手軽に作れる
特にモバイルOSではランタイム同梱によるアプリの肥大化を阻止できる
WASIは今のままではJVMのようにマルチプラットフォームなランタイムの上で動くアプリでしかないから、どっかの有名なプラットフォームが積極的に土台として採用しないと忘れ去られる
UnityでもAndroidでもどこでもいい まあ数日前にWASI 0.2.0の仕様が確定したばっかだから時期尚早と言われればそのとおりなんだが
WebAssemblyを進化させる「WASI Preview 2」が安定版に到達。OSや言語に依存しないコンポーネントモデルを実現
https://www.publickey1.jp/blog/24/webassemblywasi_preview_2os.html wasm,wasiはコンテナ界隈とかも期待はしてるようだけど確かにまだ早い。 あ、俺みたいに用意されたものを使う的な人間の場合ね。 重さが気になるほどの人気サイト作ってから言えよな。。クソしょーもねーわ。 wasmはブラウザでffmpeg動かすときに使ったことある rustはもっとC#みたいなクラスの書き方が出来れば最高なのになー >>131
クラスはプログラミング言語の歴史では大失敗作と言われていて
モダンな新言語(Rust, Go, Zig, Nim, etc.)ではいずれもクラスを排除している
既存のクラスのある言語でもカプセル化以外のクラスの機能は使わずにインターフェース等を使うことが推奨されている
Rustのtraitはその中でも最も優れたものなのでRustで困ることはないよ Rustはtraitのドキュメント見た時に
とっ散らかって見えるんだよなぁ 何事もタダでは手に入らない
良い面だけしか見ない人はいつまで経っても素人 クラス排除はJavaの生みの親ですら主張しているほどプログラミング言語界での共通認識
＞以前Javaのユーザグループミーティングに出席した際、James Gosling（Javaの生みの親）がメインの講演者として招かれていました。
＞すばらしいQ&Aセッションの途中に、こんな質問が出ました。
＞「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」
＞答えは「クラスを除外するでしょうね」というものでした。
＞笑いが静まった後、彼が説明したのは、本当の問題はクラス自体ではなく実装継承(extendsの関係)なのだということでした。
＞インターフェースによる継承（implementsの関係）のほうが望ましいのです。
＞できる限り実装継承は避けたほうがよいでしょう。 クラスを排除した代わりにRustでは実装継承の実現に4種類もの異なる方法が導入されている
もちろんGoでもNimでもクラスとは違う形で実装継承が実現されている
にもかかわらず物事の表面しか見ない人はそれに気づけないし今でも実装継承が絶対悪だと信じて疑わない
これが所謂バカの壁 >>137
Rustに実装継承はないよ
どのやり方でも必ず委譲が発生する健全な方法を採っていて実装継承の問題を排除している 大雑把に クラス＝カプセル化＋実装継承
よくないのは実装継承
カプセル化だけなら構造体の範囲内
つまり実装継承を伴うクラス自体が要らないというのがモダン言語 Kotlinのsealed interfaceはマジで超使いやすい Rocketってフレームワーク試してみたんだけどこれホストを127.0.0.1以外にできないんかな
なんかハードコーディングでlocalhost指定になってる気がしないでもない その辺grep置換で全部置き換えたけどダメだった
core\lib\src\listener\endpoint.rs にある
Endpoint::Tcp(TcpAddr::new(Ipv4Addr::LOCALHOST.into(), 8000))
がそれっぽくはあるけどどう書き換えたもんか https://rocket.rs/v0.5/guide/configuration/
読んだ感じだとRocket.tomlって設定ファイルで指定するのが簡単みたい
下の方にプログラムで設定する方法も書いてあるけど
こういうフレームワーク系はプロキシサーバーの裏側で動かすのが理想かもしれない Rustを書けるようになると、C/C++でも行儀よく実装できるようになるから
するとドキュメントの充実しているC/ C++でいいかとなりそう >>105
Python信者か？ 富豪プログラミングでもRustの方が書きやすいが 動的型付けのPythonは論外でプログラミングには向いておらずスクリプトを書く程度に使う言語
静的型付けの言語の中では過去の様々な問題点を踏まえて洗練された設計となっているRustがプログラミングに最適
>>146
それはない
例えば今では必須な非同期プログラミングでもC++は出遅れていて使いにくいだけでなくRustのtokioに相当する基盤もない >>146
ドキュメントの数は多いけど、自動生成もない時代のが多くてソースコードと乖離してたり
古いLinuxディストリ前提だったりして役に立たない率がめちゃ高いんだよな
ドキュメンテーションテストとかdocs.rsとかそういう仕組がちゃんとしてるのに慣れると
わざわざ古代の遺物的なのを発掘しに行く気にはなれない Cは構わないけど、C++はあり得ない
絶対に二度と触りたくないし、積極的に見たくもない Cにdeferが来たら、もうC++を触らなくてよくなるんだ🥰
…C23でのdeferの実装、見送られたけどね >>145
それもやったけど変わらなかった
まぁver0.xだし正式リリースになったらもうちょいマシになるんだろうから
今はまだ使い時じゃないって事で >>153
これでなんの問題もなく動いたけど…
#[launch]
fn rocket() -> _ {
let config = rocket::Config {
port: 7777,
address: std::net::Ipv4Addr::new(0, 0, 0, 0).into(),
..rocket::Config::default()
};
rocket::custom(&config).mount("/", routes![index])
} >>146
自分で書く分ではどっちでも。
でもお前の職場のプログラミングセンス無いやつにもc/c++で書いてて欲しいと思う？ >>153
rocketを使う理由が特にあるわけではないならば
一番ダウンロード数も多くRustで本流のaxumを使うといいよ
https://github.com/tokio-rs/axum
このURLを見てもわかるようにtokio開発チームが直接手掛けているWebアプリフレームワーク >>148
それはあなたの主観だよ
世界中で流行っているpythonをそのように評価をすること自体がナンセンスだとは思わないか？ >>157
前にも書いたけど例えばPythonのDjangoは遅い
PythonがRustに勝ってる点はローコストでコーディングできる、それのみ
学習コスト、開発時間などを投資できるならRustのようなlow-levelな言語を用いた製品のほうがコンピュータに優しいのは既知の事実 >>157
Pythonでプログラミングを実際にすればわかるけど
ある程度の大きさのものを作るには開発デバッグ効率が非常に悪いね
数ある諸言語と比べてもPythonのメリットは普及していること以外には何も無いかと >>158
つまりpythonはプログラミングに向いていないというのは間違いということで良い？
>>159
そうは思わないな
開発ツールやエディタが進化してるから差は感じない インタプリタ言語はプログラミングに値しないってか？流石に言いすぎだぞ
うちの小学生の子どもにScratchをプログラミング学習として遊ばせてるけど、そのScratchもれっきとしたプログラミング言語だし >>147
メモリ管理をランタイムに任せることを富豪的プログラミングというのでは？書き易さなんて単に個人の言語の習得度の差でしかない お前のDjangoは遅い？ならサーバーのスペックを10倍にしろやゴラァ
ってのが富豪的プログラミングの理念ね Rustと比べるとPythonはプログラミングに向いていない
スクリプト程度ではなく普通にある程度の規模があるプログラムを対象とする 特定領域の話と一般論をごっちゃにしてるやつ多いな。 実際にPythonで書くと実行時デバッグがどうしても多くなるね
後から機能追加したりリファクタリングしたりする時も再び実行時デバッグに陥りやすいね
その点Rustは静的型付けであるだけでなくデータ競合もコンパイル時点で防いでくれるから優れているね >>162
文脈的に文字列を無駄にヒープに置いただけで富豪扱いなんだよな
あと習熟度に依存するのはそれはそうなんだけど、Pythonに習熟した人間ほどRustの方が書きやすいという傾向がある気がする
少なくとも俺の身の回りではそう 書きやすかろうが何だろうがユーザ数が全てやろ
Rustは流行ってない それだけは確か そこは単純な話だろう
PythonとRustの両方をそこそこ使いこなせる人たちに
どちらの言語でも開発可能な領域の案件をどちらで開発したいか尋ねる
100%の人たちがRustで開発したいと答える
つまりPythonは劣った言語 Pythonにも確かに良い所があって、Qiitaの記事が多いから入門が簡単 そもそもお前らの勘違いはpythonを取り上げてること
寧ろ比較するというかライバルはJavaScriptだぞ
バックグラウンドや速度求められる所でも使われてる
実際にJavaScriptは以外とは失礼かもだけど高速だしな >>170
何でワザと複雑化させるの？
ユーザ数って言う最もシンプルなので良い
いざ開発で人集めたらRust出来る人が居ませんでした
居ても単価がバカ高い人でした
pythonならこちらが選び放題で報酬も安く済みます
どう考えてもpython優位だよね
言語が劣ってるとか優秀とか関係無い
目的のシステムが短期間で安く作れるかどうか
でもってそれが出来るのが優秀な言語 >>172
バックエンドではJavaScriptは遅い
フロントエンドのDOMアクセスはJavaScriptでしかできないため使わざるをえない
DOMアクセスを頻繁に伴わない処理ならばWasmが圧倒的に速くJavaScriptは遅い >>174
それはPythonしか知らないプログラマーが多いだけでどうでもいい話だな
両方を使えるプログラマーはRustを選ぶからプログラミング言語の優劣ははっきりしている 単価の話し始めたらまだPythonよりJavaの方が優位そう >>176
両方というかRustのユーザ数が少ないから人が集まらないって話してるのにバカなのかなw 目的の設定からコーティングまで自分でやらないといけない局面があって、そういう時に良いんだよな。Rust。
仕事が定型化されていたり、専門知識が要らなかったりして外注出来るならJavaで良さそう 開発保守効率の良さ Rust＞Python
実行速度や省メモリ Rust＞Python
この状況でPythonの方が優れてると主張してるやつはスレ荒らししたいだけだろうからここから出ていきなさい
専用スレへどうぞ
Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/ ユーザー数が全てと言うならJavaが最強って話をしたくなってくる そういう話じゃ無いんだよなぁ
Rust使いたいなら流行らせてユーザ数増やすしか無い
他の言語と比較して云々を語る暇があるならライブラリ作って充実させて流行らせる努力すれば良い >>180
分野によって変わるし一概にそうとは言えんよ
例えば機械学習の分野でRustを使うメリットはゼロ
開発保守性に関しても速度的にも利便性的にもツールチェインの連携にしても
今や汎用言語は以前に比べると遥かに有用性は低くなってる
だからrustが流行り切らないのだと分析してる
一昔前なら一斉に移ってたと思うよ >>183
本気で言ってるなら常識を疑う
機械学習分野は各社の競争が激しくて記述言語はC/C++/Rust
Pythonはライブラリ呼び出しスクリプトに使われることがあるだけの存在 >>183
あの、機械学習はプログラミングじゃないとは言わないけど分類としてはデータサイエンスだからな？😅数学系だからな？あんだすたん？
機械学習は理論がメイン、プログラミングはただの手段 libtorchとかてんさーふろーの実装の話ならオープンソースを見ればわかるがC/C++やで
演算処理がメイン機能なんだから当たり前だよね Rustはサーバー系、組み込み系が用途なのに、
Pythonのが優秀だのなんだの言うのいい加減に鬱陶しいぞ Pythonとか他の言語が分かれば数時間の勉強であとか感覚で読み書きできる言語だけど
Rustはそうはいかんと思うし
優れた言語と手軽に習得できる言語って比べても仕方ないと思う 言い方が悪かったかな
Pythonはさ、演算結果を得るために使うものであって、サーバーや組み込みのような常時駆動するようなものには向かないんですよ
考えてみなよ、お手軽さを求めるときは大抵は結果を求めたいときだろ？
numpyの行列計算がお手軽で便利～ってのと一緒だろ？ >>184
それを言えばpytorchのラッパーがrustにあるから同じ存在だよ >>189
じゃあrustじゃなくCで良いって話になるけど >>192
俺、1度目もRustじゃないとダメだとか言ったか？
俺の意見はちゃんとサーバー、組み込みに適した言語、Java、Kotlin（大好き）、C#、Go、C、C++（きらい）、Rust、Zig（流行ってほしい）を使えってこと
PythonやRubyをサーバーや組み込みに使ってほしくない あと機械学習の話が出てきたから追加で言うけど、演算処理するなら、極力オーバーヘッドを減らしたいわけで、ガべコレなんていう敵はいないほうがいいわけだから、C/C++/Rustを実装言語に使う
俺ら末端ユーザーが演算処理装置の実装なんてする機会がないからどうでもいい話だけど 機械学習でガベコレが気になるってかなりアプリケーションよりっぽい感じがするな
実装コストとかより推論速度が重要という人間が出てきたのを見ると、機械学習もここまで来たんだなあって感慨深くなる pythonの使われ方は1番にデータサイエンスとして、2番にプログラミング学習のお手本言語として、3番にシェルスクリプトの代替として。
実装言語としては使われてないよ。 >>195
逆に聞きたいんだけど、ただ単に線形代数の計算がしたいだけなのに、ガべコレいるの？ 言語として普及させるならやっぱ母数的にはまずWebのバックエンドだろうけど
それならそれでフルスタックフレームワーク欲しいところなんだよなあ
MoonZoonってのがヒットするけどあんまドキュメントが充実してないな >>197
いるかいらないかで言えばいらないけど、実行時間のほとんどは線形代数演算だからガベコレの時間は誤差だし、高速化したいならモデルをチューニングする方がはるかに効果が大きいので誰もガベコレなんか気にしていないという時代が長かった印象 いつのまにか実装言語の話に流れてるけど
そういう議論はしてないからな ここはRustのスレです
開発プログラミング言語として劣っているPythonの話題は他所でしてください 機械学習で得たモデルを組み込みデバイスで使いたいってことなんじゃない？
それもう機械学習を終えて、ただのアプリの設計と実装な気がするけど笑 どれもダメ
pythonに勝てる理由にはなってない
実装言語の話をしたいならC/C++で良いし現状そうなってる事実は覆らない
速度だけ欲しいならrustはいらない >>200
それはそう
行列演算ライブラリがC/C++ばっかなのはたまたまだとも言える >>201
このスレはRustスレなんだから実装の話になるのは当たり前だろ
データサイエンスの話がしたいなら他所に行ってくれ >>206
じゃあこういう視点から聞くが下回りがrustの機械学習ライブラリはありますか？ >>204
Rustを組み込み業界が推してる理由はセキュリティ、メモリ安全の観点でRustがC/C++より優秀っていう理由
実際にカーネルはRustにマイグレーションされはじめてるでしょ
Rustがサーバー用途で使われだしてるのはtokio等のRustライブラリ、Webフレームワークが優秀なおかげでJavaのSpringBootのような有名どころに機能面でそこまで劣らず使えて、省メモリ高速に使えるから >>209
そういやJVM使うから同じゲーム動かすにしてもAndroidはｉPhoneよりメモリとかのハード要件上がるとか言われてたな >>209
少なくとも下回り使う分にはそのような要求は必要ないと思うが
rustであってもunsafeだらけになるよ
非同期ライブラリに関してはpythonもasyncioというtokioに勝るとも劣らないつよつよライブラリがある
よってその点でも不足はない
Webフレームワークに関しては言わずもがな >>208
だからなんでそんなにデータサイエンスの話をしたがるの？
ライブラリ？libtorchのrustラッパーでコード書いてコンパイルすりゃいいだけやんか頭悪すぎでは？
機械学習は演算処理して類似度を求める作業なんだからコンパイルなんて手間かけずにスクリプト言語でやったほうが手軽だろうが
長時間動作させたいサーバーや組み込みとはわけが違う
インタプリタ言語とコンパイル言語の使い分けもできないの？ 負けず嫌いが多いのか知らんが相手にするから居付くんやで >>211
システムコール書くんだからそらunsafeだらけになるわな
逆に言えばそのシステムコールまわりの部分さえ厳重に書けばいいじゃんか
Webフレームワークでインタプリタ言語を使うのは、上で言われてた典型的な富豪的プログラミングだよね>>163
サーバーに重課金できるならPythonでどうぞ実装やってください
ふつうの神経を持ってたら少なくともJavaとかC#とかGoとかをサーバーに使うと思う >>212
いやそもそもの議論の出発点が「機械学習においてはpythonがrustより優れている」というところだからでしょ >>215
機械学習はプログラミングじゃないとは言わないがデータサイエンスの分野だよ（2回目）
だから「機械学習においてPythonがRustより優れてる」がそもそもおかしい
Rustはデータサイエンスをやる言語ではない >>208
【機械学習 by Rust】
・autumnai/leaf — Open Machine Intelligence framework.. Abandoned project. The most updated fork is spearow/juice.
・burn - A Flexible and Comprehensive Deep Learning Framework in Rust.
・coreylowman/dfdx — CUDA accelearted machine learning framework that leverages many of Rust's unique features. Crates.io
・huggingface/candle - a minimalist ML framework with a focus on easiness of use and on performance (including GPU support)
・huggingface/tokenizers - Hugging Face's tokenizers for modern NLP pipelines written in Rust (original implementation) with bindings for Python. Build Status
・LaurentMazare/tch-rs — Rust language bindings for PyTorch.
・maciejkula/rustlearn — Machine learning crate for Rust. Circle CI
・rust-ml/linfa — Machine learning framework.
・smartcorelib/smartcore — Machine Learning Library In Rust Build Status
・tensorflow/rust — Rust language bindings for TensorFlow. >>217
いや一覧を出せって意味じゃないぞw
python以上に使われてる例を出せって意味だよ >>216
そういう逃げはいいから
データサイエンスも普通にプログラミングです データサイエンスやるならPythonよりJuliaの方がいいな 結局論破できないんか
じゃあ絡んでくるなよ
機械学習においてはpythonに負けていますでいいだろ
そしてそれはrustがダメということにはならん
何と戦ってるのか >>222
機械学習の論文読んだことある？プログラミングなんてどうでもいいことは「～のPCスペックでPytorchを用いて実装しました」くらいしか書かれないぞ >>222
Rustは機械学習のライブラリもRustで書かれているものも多いです
PythonはC/C++依存だから同じ土俵にすら立てないと思います >>225
機械学習は理論が大事ということを語る上で関係大アリなんだが… 元々学生の勉強用としてPythonが利用されてて、
その学生が勉強の一環で機械学習したことで機械学習用のライブラリが増えた
その過去の資産(遺産？)の上に乗っかって今のAIブームがあるだけ
言語的な優位なんてものはPythonになくて
ただライブラリが充実してるだけの話 Rustで機械学習はRustだけで完結できるアドバンテージもありあります
新たに出て来て必要となる実装ライブラリもRustだけ習得すれば作れます うーん、機械学習する上で必須となる行列演算ライブラリの実装の話こそRustでやるかやらないかで盛り上がるところなのに、なぜ頑なに機械学習自体を取り上げて話をしてきたのか
理解不能だ そういやJuliaだと行列演算言語単位でサポートしてたな そもそもの話になるけども
なんでPythonが教育目的で使われたのかって話になる
Pythonはキレイに書くことを強制されるってのもあるけど
電池内蔵とか言われるぐらい標準ライブラリが充実していた
だから学習に利用されやすかった
行列計算も然り
結局ライブラリが充実してたって話に帰結するよ
尤もライブラリの大半はCで書かれてるがね ちなみにnumpyの開発者も大学生だったんじゃないかな
とにかく欧米の学生はPythonで勉強してたから
Pythonのライブラリは大学生が作ったものが多いよ その昔は perl もライブラリが豊富といわれていたんだがな
perl, ruby, python の中ではオフサイドルールがある分だけ
python の方がプログラムがごちゃごちゃになりにくい
もっとも今となっては自動フォーマッターがあるので
どれで書いてもあまり変わらないが >>233
>>234
ここはRustスレ
Rustがらみの話以外は別スレでしろ Rustはプログラム言語の王なのでRustスレではどの言語の話をしても良い 他の言語を知ることでRustの良し悪しが分かる、他の言語を学ぶことは巡り回ってRustの勉強になるって寸法よ
もちろんRustの文法やフレームワークの話題や議論があればそちらを優先すべきね Rustが『いま』流行ってなくても、Rustの協賛企業らが『無理やり』流行らすから5-10年後には日本でもサーバーサイドにRustを使う企業が増えている
20年後にはLinuxカーネルのRust化がほぼ完了してるだろうよ >>238
Rustは「安全かつエコ」という流れが生じつつあるから日本でもそうなる
エコとは他の言語より消費電力を減らしCo2排出量も減ること rustとpythonではなく、tomlとpythonを比較すればいい
スクリプトを追放するたんびにマークアップ言語が増える歴史が繰り返される >>239
相手にしなかったら自演して自分に安価つけ始めるけどな >>241
tomlはマークアップ言語じゃなくてデータ記述言語
スクリプトうんぬんは知らんが、シリアライズ効率のより良いデータ記述言語を求めるのはいい事だよ
自分のところはjson+gzipで落ち着いてるけど、goでよく使われるprotobufにいずれ移行できればなって考えてる >>230
数値演算ライブラリはC言語で十分な気がする。理由を言語化するのは難しいけど 一番向いてるのはミドルウェアとか少数のガチ勢が作ったらいいような部分なんだよな。
だから普及はしない。 >>244
並列処理まわりの仕様をよく検討した上でRustかCかC++のどれを選択するべきとは思うな アルゴリズム周りなんて共有のオンパレードなのにrustが向いてると思ってるのはちょっと素人感がすごいね。 日本語おかしくなった
並列処理まわりの仕様をよく検討した上でRust、C、C++のうちどれを使うか選ぶべき
個人的には並列処理の安全性の面でRustを使うべきだと思う まあ実情は演算処理にCUDAを使うだろうからC++で全部設計したほうが都合がいいのかな
難しい 機械学習はPython？Rust？いやいや争わずに両方使えばいいじゃん。
Rustを使って機械学習アルゴリズムを実装しPythonから呼び出す: k-meansクラスタリング
https://zenn.dev/skwbc/articles/rust_python_kmeans 機械学習だの演算処理だの、いつまでそんなつまらない話をしてるの？
rustはゴミってことで結論が出てるんだけど 荒らしに構うキチガイを追い出したいね
ID:gRgK5+vi → ID:Uc3vGql0 （違ったらごめんね） >>253
わざわざ生でunsafeなコードを書かなくてもPyO3とか使えば楽にできるよ >>243
Protocol Buffers古いし、MessagePack(古い)やCBORのほうがいいんじゃない？ 使ったことないけど。 Protocol buffersは仕様変更に強いしフォーマットを別ファイルに定義出来るという特徴があるから、msgpackやcbor とは使うべきケースが違いそう >>247
もちろん少人数ガチ勢による開発もRustが向いてるのはおっしゃる通りだけど
大人数による開発もRust向いてるでしょう
特にC++で次から次に穴の発生が尽きない各大規模プロジェクトたちは作り直しや新規ならRust一択だね >>247
Rustはサーバーサイドで最もよく使われているっていう調査結果がすでに出ているが>>117,119 >>253
どうでもいいがこの記事では非同期処理ライブラリにtokioじゃなくてrayonを使ってるんだな
気になってぐぐったら「rayonのスレッド プールは、CPU を集中的に使用する作業、つまり大規模なデータ セットの大規模な並列処理向けに設計されています。」らしい
https://www.reddit.com/r/rust/comments/xec77k/rayon_or_tokio_for_heavy_filesystem_io_workloads/ >>261
rayonは非同期を使わない並列に特化した時に速い
tokioは非同期で並行＆並列で万能 >>227
なら言語的に優れていてPythonライブラリを使えるNim最強だな。 Rust⇔PythonはPyO3で相互に呼び出せるのでRustだけあれば十分 他の言語スレに乗り込んできて居座るとかやってる事ルビガイジとなんら変わらんっていう >>263
Nimは速いしCへのトランスパイルも賛否あれど個人的には好き >>211
お前や俺らがそのunsafe部分を書く。
で職場の他の今動きゃいいってコード書いてる奴らにはunsafe部分は利用させても書かせない。
そういう分け方できるのはメリットじゃないかね。 >>259
もう5年くらいこんなこと言ってる人いるけど一向に普及してないよね。 >>269
カーネルのRustへのマイグレーションの成果が各所で出てるの知らない？ >>269
AWS SDKにRustが正式登場して、色んなところがRustを触りだしてるぞ AWSやCloudflareが大規模に使ってるからインターネットのトラフィックの結構な分量をRustが捌いてるはず
この5年でこういう人目には触れないけど基礎的な部分にずいぶん普及したよ Rust のユーザ規模はもはや小さくはないが仮に小さかったとしても、それが無用のものということを意味するわけではない。
Cobol や Fortran だって一般には化石のような印象を持たれつつも近年にも規格改定などの発展はあるし、それが求められる程度の利用シーンはある。
Lisp がインフラの中に潜んでいたりするし、Caml で書かれたプログラムがあなたがたのパソコンにインストールされていたりするのもそれなりに高い確率でありうる。
普及するっていうのはそれを不必要なところにまで押し付けたいわけじゃないだろう。 物を作ってから普及するまでの時間で評価されれば
まだ作ってない物を売るようになったり、評価を信じなくなったりする >>271
あれすげー使いにくいよ
そもそもがAWSのAPI自体が非同期の作りですぐに返ってくるものばかりだから
ライブラリ側は同期的で良いのにtokio使っちゃってるし >>272
現在のネットのインフラであるクラウドとCDNがRust製になっていってるから
Rustがネットインフラを支えるようになって来たと言っても過言ではないんだね >>275
割と何言ってるかよくわからないので
どのあたりが使いにくいのか詳しく >>275
javascriptでただの同期functionだったものが非同期のasync awaitに変わった経緯がある
同期functionだとブラウザから呼び出した時に待ち状態がフリーズみたいになって不便だった >>275
それはキミの非同期処理に関する知識が欠如してるだけ まあわざわざライブラリ側で非同期にしなくても、必要ならユーザーが勝手に非同期にすればいいってのはあるかもな tokioの非同期って
async fn、spawn、async、await
を最低限使えればなんも不自由なくね？
同期じゃないといけない理由あんの？ 同期的に使うだけの場合でも tokio をリンクするってのが気分よくないというのはわかる。 >>282
同期じゃないといけない理由？非同期の使い方がわからないからじゃないか？
ちなみにRustがダメだとアンチが言うのはアンチがRustコードのコンパイルを成功できないから AWS SDKを同期的に使いたいってそれAWS CLIじゃだめなん？w >>280
そこの今まで独自にそれぞれが用意してた部分を async await 等のAPIとして整理されたことに意義があるんと思う。 AWS CLIはcargo installで入ってこないから…… そもそもRustを使う意味がないよね
AWS SDK for Pythonがあるんだから >>286
async awaitへの統合に意義があるのはわかるけど、tokioにまで限定されるのはダルイという気持ちがある >>290
説教的に支援って資金的な支援じゃなくてAWSがtokioの営業することだったのか…… あ、AWSがtokioを運営してんのか
単なるスポンサーだと思ってた Rustで非同期やるライブラリって昔からたくさんあるけど最近はtokioしか使ってないや
すごく重い処理があるプロジェクトはtokioとrayonで使い分けてるけどそれでも両方のライブラリをプロジェクトで共存させてる 非同期のそのデメリットを消す方法は
まだ作ってないことにしよう >>277
まずAWSのAPIってのは基本的にすぐ返ってるの
この辺はわかる？
例えばインスタンスを作るAPIってのはインスタンスを作り終わるまでブロックするんじゃなくてインスタンス生成命令を出してすぐに返ってくるわけ
実際にインスタンスが生成完了したかはインスタンスの状態取得APIを使って確認するわけ
だから常に同期的に呼び出しで問題ないの
pythonのboto3ってライブラリが1番使いやすい >>299
あなたが何言ってるかわかるけどnodejsでも
似たような使い方だしrust sdkの欠点と言われても
広く同意は得られないんじゃないかなあ >>302
欠点というか使い方を難しくしてるだけな気がするんだよな
普通にCLIでええやんって思う >>303
awsに限らずweb apiのライブラリは
非同期にするのが主流だから
頑張って勉強してねとしか… AWS SDK for Rustはsend()がめちゃくちゃダサい
そのうち大幅に改修されるだろうけど
>>299
ネットワークI/Oを同期で書くのはさすがにどうかと >>300
今から見ると微妙だがCLIと対応がつけやすいし
余計なことはしなくて良いから楽だよ >>306
どう書くか？はユーザーのユースケースによるからそうとも言えないよ
例えばAzureのCLIは--no-waitというオプションがあり
処理が成功するまで待つか待たないかを決められる
これこそユーザー視点の設計だよ Google規模の会社が$1 million渡したくらいでわざわざアナウンスするなよな
タイトル詐欺じゃん
Improving Interoperability Between Rust and C++
https://security.googleblog.com/2024/02/improving-interoperability-between-rust-and-c.html 非同期を押し付けることはユーザーのメリットにはならない
Rust SDKは作り直して欲しい prostもblocking版の関数ないのかよってびっくりした記憶があるわ
C#版もPython版もasyncとblockingの両方あるのにな >>299
>>まずAWSのAPIってのは基本的にすぐ返ってるの
>>この辺はわかる？
初心者でもそんなウソはつかないぞ
AWSに限らず任意のサービスに言えるが通信時間がかかる
さらに各サービス内で状態取得だけであっても実行時間がかかる
>>だから常に同期的に呼び出しで問題ないの
本気で言ってる？
通信時間と向こうでの実行時間の間こちらはずっと何もせずに待つわけ？
非同期プログラミングの意味すら理解できていてないのか？ >>312
コンピューターにとって1秒待つって事がどれだけ長いかを理解してないんだろ 非同期の方が良いことが多いのは同意するが、非同期を押し付けられると「こんなプログラムのためにTokio入れるのかよ」って思ってしまうケースは存在する API が非同期で設計されてるのに、それを呼び出す側もさらに非同期でハンドリングするのは正直無駄じゃない？
ってのはわりと自然な感想だと思うけどな。
AWS の API なんてクライアント側で並列に呼び出したいユースケースも無いだろ。
バカスカ叩いてもスロットリングされるだけだし。 >>315
APIの向こう側で非同期なのとこちらの処理を
同期か非同期化は関係ないよね >>308
非同期APIが提供されてれば同期化は簡単にできるから必要ないんだよ 同期化ってasyncでない関数から呼べるようにするって解釈で合ってるだろうか
もしそうだとしたらasyncでない関数の中でtokioランタイム作ってawsよんでruntime終わらせるみたいな処理になっちゃわないか AWSのAPIの呼び出しが非同期になるのはAPIの内部で効率化のために非同期処理をやってるからでしょ？ うちはAWS SDK RustはAxumベースのWebアプリでDynamoDB接続に使ってるけど、みんなはなににAWS SDK使ってるん？ >>312
だからーなーんにもわかってない発言丸出しはやめよ？
通信の時間なんてかからんのやって
すぐ返ってくるから
そこちゃんと読もう？ AWS APIを生のRESTで実装してみろよ
すぐわかるぞ 言っておくが俺は一般論として非同期がダメと言ってるわけじゃないぞ
もちろんその用途としての方が便利なことは多い
あくまでAWS SDKのRust版については不満があるということよ >>325
web apiの実装として相手側が非同期処理で
手元も非同期なんてのはawsだけじゃないというか
それが主流だけど他はいいの？ このスレにはRust関連の悪い所の指摘を見ると自分が全否定されたように怒り出す人間がいるっぽいので tokioが素晴らしいのは間違いない
しかし今回のREST APIの呼び出しで程度で必要かな？と思う
非同期が必要ならtokio::process::commandでCLIを非同期で呼ぶ方が良くないか？とか色々考えてしまう >>323
>>通信の時間なんてかからんのやって
>>すぐ返ってくるから
呆れた
敢えてウソをついているのか？
それとも本当に無知な初心者なのか？ Web通信ですぐ返ってくることなんかあるのか？ と思ったけど、AWSのAIPの中身知らんから何とも言えんくなってしまった
そういえばファイルIOはすぐ返ってくるって言って良いんだろうか >>330
サイズが小さいファイルに対して非同期呼び出しをするか？という話 >>331
まあ「ファイルIOにTokioが必要です」って言われたらちょっと嫌な気分になるな >>330
Web通信は通信時間だけで大きく時間を要する
さらにWebサーバ側で処理時間がかかる >>323
cpuのナノ秒単位の処理速度に比べたら通信はとてつもなく遅いけど
レスポンスを受け取るまでの時間は処理を中断させたほうがコンピュータに優しい
tokioのグリーンスレッドを活かせ >>334
tokioのランタイムが裏で動くとか気持ち悪すぎだろ
同期でやらせろ 他のSDKのようにv3くらいになれば使いやすくなってるかもね aws sdk for rust ってwebフレームワークでサーバーサイドやってる人向けだから当然のようにみんなtokioを既に組み込んでるもんじゃないの？なにがそんなに気に入らないのか理解ができない
まあtokio以外の非同期ランタイムを使わせろって人はドンマイだけど >>337
実装の話に逸らさないで
AWSのAPIくらい同期で十分なのにわざわざ非同期にする理由を言えよ いくらすぐ返ってくるっていってもネットワーク通信なんだから
不通だったりレイテンシが長くなることはありうるし、
タイムアウトやリトライをtokioのエコシステムに乗っかってやれるメリットはあると思うけどな
そりゃ軽量な同期版があるに越したことはないけど、優先順位は落ちるだろう JavaScript SDKも内部は非同期だけど使いやすいよ
単なるコールバックで同期的に書けるし どうも最近tokioがでしゃばってきて気持ちが悪い
ここまできたらもうコアをtokioに入れてWeb用の専用言語としてフォークしたほうがよいのでは？ >>340
はぁ？そんなに同期でやりたいなら同期のある言語のSDKを使うかAWS CLIでコマンド実行しててくれよ
同期同期言ってるやつはRustでAWS触るアプリ作ってねえだろ
こちとらつい先日ようやく待ちに詫びたAWS SDK for Rustが正式版になって、ようやく、ようやくこれを本番投入できるって喜んだのによ まあ俺はCLI使ってるw
ぶっちゃけコードで書くメリットがわからない というか同期版もランタイム切り替えも別にissueとしては却下されてるわけじゃないんだし
欲しい人は実装してPR出せばいいんだよ
それがされてないってことは結局需要がないんでは？ >>344
はい、じゃあお前の負けね
もう二度と口答えすんなよ >>341
不通だろうが普通はソケットのタイムアウト値設定するから許容できる範囲内の値を設定すればよろしい
どちらにしろリトライすることになるのだ 「そんなに××したいなら○○使えば良いんじゃないの？ 」→をはい○○使っています」っていう流れ、最強言語たるRustのスレの流れとしてはあまりにも敗北感がある まとめると
tokio使わない同期API作れ
非同期版はランタイム切り替えできるようにしろ
ってことでオッケー？ >>340
コンマ1秒～1秒の頻度でデータベースクエリするWebアプリとかだったら非同期のが次々に処理できると思うけど >>351
なんだそれ？
お前そんなにバカみたいな頻度でAWS APIを使うの？笑うわ >>352
それくらいの頻度で呼び出す可能性があるのってGAFAMクラスの会社ぐらいじゃね？w >>354
それな笑笑
>>351は負けず嫌いの単発の敗者笑笑 使ってる用途が違うから噛み合わないんだな
CLIで十分な用途とAPIが必要な用途くらいは区別しようぜ あ、もしかしてガーファ勤めなんかな笑笑？
なわけねえだろ笑笑 >>355
ゲームサーバーってなに？マインクラフトでもやってるの？ガキんちょか？ >>357
うるさいな
非同期じゃないといけない理由を具体的に言ってみろよ？あ？ 自分用のツールなら一々tokioとかめんどくさいとか
わからんでもないけどそういう人をターゲットに
してないからなあ GAFAMの規模を舐めすぎだろ
10リクエスト/秒程度なら中堅企業の社内向けシステムでも普通にあるレベル 実際ゲームサーバーって大変そうよね
最近話題になったパルワールドってやつもサーバー要素があるけど、ゲームデータをどこかしらのクラウドサービスをレンタルしてやってるわけで、>>351よりもすごいレベルで行われてそう
パルワールドのサーバーはどの言語のWebフレームワークでやってるのか知らんがJavaとかC#、GoあたりならRustのが高速、省メモリでサーバー代を節約できただろうな ゲームサーバーってプログラミング関係あるの？サーバーを借りてるだけなんじゃないの？ まさかゲームサーバーがなんなのかわからない人がこのスレにいるとは 通信時間＋向こうでの処理時間はCPUにとって莫大な待ち時間
async/awaitによる非同期プログラミングをすれば同期と同じようにプログラムを組めつつその莫大な待ち時間を有効活用できる
これは特定のプログラミング言語に関係なく対応しているすべての言語で成り立つ話
もちろんRustでも同じ AWS Lambdaだと同時実行数の制限があるから、同期処理をするのは犯罪的。 現状のasync/awaitの使いやすさは
Swift > C# > JavaScript >>> Rust >>375
Python忘れてたわ
Swift > C# > JavaScript/Python >>> Rust もちろん性能面でもRustが最も有利
だからインフラに至るまで採用されている >>377
swiftってそんなに書きやすいんか？ >>375
asyncもRxもC#が発祥だけどこの言語だけ異常だよな Pythonはスレッドが擬似的なので並行処理の性能が低い。 >>375
Kotlinが抜けてる
Kotlin>（越えられない壁）>Swift > C# > JavaScript/Python >>> Rust Rustを叩きたいだけのアンチさんだから無茶苦茶や >>380
C++は論外
アンチではなく本当に書きにくい
さらにtokioのような高性能な基盤も整備されていない 非同期はC#GoKotlinRustのどれも同等に使いやすいと感じる
JavaはSpringありき、Swiftはつかったことない、C/C++は考えたくない swiftやdartはモバイルアプリ開発以外で全く使われてない SwiftはApple製ってだけで使う価値なし
開発環境の依存があまりに高すぎる >>375,377,384
なんか言語のラインナップ見るにバリバリのフロントエンド開発屋さんかな？
そらRustを使うことなんてないわな
なんでこのスレにいるのか Rustはフロントエンドも取り込むのでRustスレはフロントエンド屋も書き込んで良い まぁRustの非同期の良いところはランタイムを言語から切り離したので
Webでも組み込みベアメタルでも非同期が使えるところなんだけど
使い勝手としてWebのユースケースに特化した他言語に負けるのはしょうがない
これは時間がたっても根本的には改善されないから
不満があるなら早く他言語に移ったほうがいいよ >>390
ならGoかC#のASP.NETでいんじゃね？
さまざまな導入コストを払えるなら事実上クラウドネイティブ言語のRust一択
それとJVMがダメという理由が、Oracle JVMのLTSサポート期間が短縮されJVMのイメージが悪化したってことに依るものなら、
Kotlin/JVMだとJDK8をベースに、どのJDKバージョンでも動くようにサポートされ続けられるから、JDK8から最新のJDK21までのLTSバージョンで難なく動く
https://kotlinlang.org/docs/faq.html#which-versions-of-jvm-does-kotlin-target
OracleのJavaは終わってるがJetBrainsのKotlinは無限に始まってる 静的言語ではkotlinが個人的には1番かな
コルーチンスコープを作れるから既存の処理の中に非同期を唐突に入れられる
これが理想
ただしクラスありきなのが微妙なところ
クラスなしでkotlinのような使い心地がある言語が欲しい >>373
その時間有効に使えるのかって話なんだよ。
例えばRDSを休止したい場合に、休止するAPIを呼んで、状態を確認するAPIで休止を確認してすると思うけど、
そういう処理を自動化する時に非同期でハンドリングする意味あるかっていう。
DynamoDB のデータ操作とか業務トランザクション扱う系は非同期あっていいとは思うけどね。 既存の処理の中に非同期を唐突に入れられるのってランタイムがグローバルで一意じゃないと出来なそう
ランタイムいくらでも作れるし複数種類存在しうるRustでは無理そうね >>395
それはRustも同じ
Rustのasyncもコルーチンでありtrait Futureによって抽象化されている
Future::pollの引数であるContextがKotlinでのコルーチンコンテキストに相当する
>>397
Rustでも既存の処理に唐突に非同期を取り扱える
Rustでtokioのようなランタイムが必要になるのはspawnして完全に制御外へ切り離すときのみ
制御内ならば複数のFutureを取り扱う場合でもjoinなど様々な方法で取り扱うことができる
もちろんtokioランタイムは必要ない >>380
C++ はその性質上、システムとの連携が必要な標準ライブラリは薄い。
幅広いシステムで実現可能なように配慮するから。
必要ならサードパーティライブラリでやれというスタンス。
ただそこで強力な誰もが認めるサードパーティライブラリが結局は現れなかったというのが C++ のあかんかったところなんやわ。
個人的には C++/WinRT の非同期処理は好きなんだがね。 >>395
KotlinはデフォルトでclassがJavaでいうfinal classで定義されてて
・クラス継承禁止
・やってることはCの構造体と同じ
だから、自分はclassであるデメリットを感じてないかな
Kotlinでクラス継承するにはご存知の通りclassをopen classやabstract classと書くから見て分かるのがヨシ >>396
>その時間有効に使えるのかって話なんだよ。
非同期にすることでawsに関係なく別の処理を同じリソースで走らせられる
もしその時間を有効に使えないような用途なら省リソース高性能とは無縁だからわざわざRustを選ぶ必要ない なんかプログラミング言語総合スレみたいになってんな
いやちゃんと説明してくれて勉強になるから別にいいんだけど >>402
Rustはプログラム言語の王だから理由がなくてもRustを使って良い >>398
え、tokioランタイム無しで非同期関数呼べるんだ？ 知らんかった
でもクレートの依存は付いてきてビルド遅くなるよね >>405
tokioに依存してない非同期関数ならクレートの依存もなく自分でFuture::pollを呼べばいい
例えばpollsterってクレートはそれ専用で、block_onだけ呼べる最小限の実装になってるよ 自分でFuture::poll呼ぶとか罰ゲームすぎるやろ >>361
ゲームサーバーはユーザーの操作ログを逐一集めてるよ。 >>370
いや、無知は恥だよ。ただ罪では無い。
無知のままでいようとすることは罪だけど。
あ、実際の法律云々じゃなくて技術者としてね。 >>407
自分で呼んでもいいし自分で呼ばなくてもいい
それは何をやりたいかどこまでやりたいかなどに依存
>>405
軽いものなら例えばこれだけ
fn main() {
let val = futures_lite::future::block_on(async {
...
});
} pollを自分で呼ぶコードは悪手とかなんとか主張する人間と
そのコードに警告もしないコンパイラを
比較できるのがRustの楽しいところで
リソースを節約する話などは人間と人間の論争でありRustに責任はない C++に安全の責任はない
Pythonに動作速度の責任はない
Brainfuckにリソース節約の責任はない
Rustにリソース節約の責任はない >>366
ゲームのミドルウェアがUE4だから、サーバー側もC++で書いてるんじゃないかな。 >>412
リソース節約の責任って何？
リソース節約の責任があるプログラミング言語が存在するの？ >>415
リソース節約の責任の定義は>>411に聞くべきでは？ そもそもRustとそのエコシステムを同一視してるんじゃないか。もちろん不可分なところはあるにせよ、分けて考えないとね。 言語の形式的なルールと実利を同一視するのは
ルールを守れば必ず報われるべきってことじゃないか
でもルールを守ることと勝つことは難易度が全然違う Rustの駄目なところ
コンパイルが遅い
コンパイル時間を含めたらPythonのが圧倒的に速い >>420
みっともないからルビガイジみたいなレス乞食やめろよ >>414
フロントとサーバーは間にネットワーク通信が挟まるんだから言語をフロントとサーバーで統一するメリットなし >>426
直接に通信するあたりは言語を統一しておくと共通のライブラリを使えたりするので便利。
少人数で運用しているシステムだとクライアントとサーバーがある程度に
共通のスキルセットで構築できたほうがいいってこともある。
それがデメリットを上回るほどのメリットかどうかは状況によるけど。 gRPCやRESTなら主要言語のほぼ全てで対応されてるんだから別に同じ言語に囚われる必要無いと思うけどなあ シリアライズフォーマットの話とプロトコルの話も区別できないのかぁ スキルセットが一番発揮されるのはコード実装前の設計段階だよ
アルゴリズムとデータ構造、各種言語の各種フレームワークの知見を活かして設計してるだろ？
実装段階に入ったらあとは作業
フロント担当サーバー担当それぞれが実装する
フロントとサーバーはお互いに入出力のAPIだけ知ってればいい
言語の書き方そのものに対するスキルセットは納入期間の短縮にでも活かしてくれ >>429
そんなんprotobufかjsonのどっちかだろ
当たり前すぎてデータをどう送受信するかの話をしてたわすまん あっごめんzstdかgzipのどっちでデータ圧縮するかの話もしたほうがいいの？ それら全て些細な問題でどうでもいい
通信でもファイルでも何でも
APIやフォーマットさえ決められていればよい
どの言語かどのフレームワークやライブラリかなんて一切関係なく自由 >>426
一応、lddで確認したけれど、Epicのオンラインライブラリリンクしてたから、>>427 も言うように、クライアント側のゲームエンジンに引っ張られてると思う。 自社規格のデータをシリアライズ、デシリアライズするのに自社ライブラリを使うのと、サーバーやフロントをどの言語で実装するかは全くの別問題でしょ
>>414が言ってる、サーバーをC++で実装するだなんて効率の悪いことはするもんじゃない もちろんサーバとクライアントで同じ言語を利用すると有利な場合もある
もっと複雑なデータを別な形のデータに変換する同じ動作(コード)がサーバでもクライアントでも求められる場合がそれにそれに相当する
具体例としてはサーバサイドレンダリングをしつつフロントエンドでもシングルページのためレンダリングをする場合
従来はサーバサイドをNode.jsにすることで両側JavaScriptにしてコード共有が行われてきたが両側Rustでの動きもある 人によっては使用言語を統一したほうが数多なるデメリットを単一のメリットが上回ることもある
このご時世、簡略化されたプログラミング言語で溢れたなかで、単一言語しかできないというのは珍しいとは思うが、誰しもがバイリンガルプログラマというわけではない unreal engineってフレームワークでサーバーアプリも作れるけど、自前でAPI組んでサーバーやったほうが圧倒的に軽量なんだよね バイリンガルでないプログラマ、Javaしか書けなそう Java界隈では未だにXMLが現役なのかな
一時期は全てがXMLだったけど最近触れる機会がない >>430
「少人数で」と但し書きを入れたのは一人が色々と担当する状況であるという意味だよ。 ウェブまわりはいろんな規格が入れ子状態だから名前空間で分離する仕組みも要るところでは要る。
XML の万能さは他には代えられない便利さはある。
ただ、それが要らないところでは負担がデカいのも本当だし、多くの場合には要らんかったわという気づきがあったんだよ。
XML もスキーマがあれば大幅に情報を短縮できるバイナリXMLの規格も出てるんで、
そういうのを活用すればそれほど過剰に冗長なわけではない。 >>436
例えがフロントエンドって急にレベル下がってワロタ >>431
ゲームサーバーでも性能を極限まで高めることが要求されるような場合はprotobufやJSONはあまり使われない
↓ここでいうRaw Struct的なものが今でも使われてる
https://flatbuffers.dev/md__benchmarks.html
言語ニュートラルじゃないしサーバーとクライアントと同時アップデートしないといけないとかいろいろ制約あるけど性能が必要ならそれらの手間を惜しまない >>444
ならばプロコトル以外で
サーバとクライアントで同じコードを実行するために同じ言語であることが求められる例を挙げろよ シリアライズやパースのコストは小さくはないけど、
メモリコピーのコストが多くを占めているという発見から
なるべくコピーを減らしたシリアライズの規格として message pack が
実行性能と可搬性を (ある程度に) 両立したものとして人気がある。
まあ要するにそれぞれに利点があるんでこれが決定版とはなかなか言えないんだよな。
ある程度の収斂はしたにしても両立不可能なトレードオフってものはある。 >>445
まあゲームだとデータの規格のバージョン互換性を考えなくていいし独自規格で暗号化も兼ねたシリアライズをしたほうが悪意あるデータの改ざん防止のための対策にもなりそう
てかデータ記述言語の話なんざクソほどどうでもいいんだが xmlだろうがjsonだろうがrest通すときはgzipするからどっちでもいいわ >>446
一昔前の分散オブジェクトシステムは大抵それだぞ
COBRAとか
そういう設計古くさいから基本的にやらない >>438
ああ、なるほど、UEはゲームレンダリングエンジンとしてではなくそれ単体でサーバーサイドもできるってことね知らんかった
小規模サーバー用途ならそれで十分そう クライアントとサーバーで同じ "プログラミング言語" 使うことの話が、いつのにかプロトコルとデータシリアライズの話にすり変わってるし。
発端は >>426 あたりかな。 >>451
分散オブジェクトの話とは状況が全く異なる
ウェブのサーバーサイドとクライアントサイドでのコード共通化は現在使われている最新技術
これを片側でしか行なわないと速度面すなわちブラウザを使う人間の体感面で不利となってしまう
両側ともにJavaScriptにするのが主流だがサーバーリソースコスト面で不利なため両側Rust化 >>455
気持ち？
理解していないようなので現在のウェブ界での動向を伝えただけだが >>454
それwasmってやつ？ファイルサイズがjavascriptより大きくならない？ フロントエンドってAPI受け取ってReactで画面描いてAPI送りつけるだけじゃん、これのどこがサーバーサイドとコード共通にすなるん？？ javascriptでサーバーサイドって言ってる時点で頭がおかしいからスルーでおけ nodejsで済むサーバーって自宅サーバーか何かか? >>457
一般的には何をするかに拠る
レンダリングコード共通化の話ならばその部分については誤差範囲
>>458
あまりにも基礎知識が無さすぎるようなので
SSRとCSRの違いと両者のメリットとデメリット及びコード共通化によるメリットを勉強しなさい >>456
いやそれが余計なんだって
next.js app router+rust使ってる俺に対してする説明ではない >>459
>>460
そこはPHPでもRubyでもPythonでもJavaScriptでも変わらない
しかしそれらは遅いからサーバーサイドはRust化すべきだろう
つまりレンダリング共通コードもRustで統一すべき WASMはあまりにアセンブリ言語すぎる
watで直接WASMを書いてコンパイルするのが一番バイナリのファイルサイズを抑えられるけど大変
watじゃなくて他の言語で書くにしてもstd使うとファイルサイズが爆増する
既存のライブラリをWASM化するならともかく、既存のJavaScriptコードをstd有りで書き直すのは、ファイルサイズがJavaScriptのときと比較して増えて本末転倒だからJavaScriptのままでいい
watやRust with no-stdでWASMを頑張る人は頑張って >>459 >>460
今は企業サイトでもサーバーサイドでJavaScriptが動く時代よ
Next.jsやNuxt.jsなどの名前を聞いたことないですか？ だめだ、WASM specを見直してるけど相変わらず何書いてあるのかわからん >>464
規模がデカいアプリケーションは std の大きさなんてどうでもよくなるくらいにデカい。
大規模化するウェブアプリケーションが想定されているから
JavaScript のほうが軽量であるときは JavaScript を使えばいいよ。
そうじゃないときがあるって話なんだよ。 1コアで毎秒数万リクエスト処理するようなゲームサーバー的なものの話をしてると思ってたらSSRとかReactとか全く違うユースケースの話をしてる人達がいたのか
そりゃ話が噛み合わないわなぁ 話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち 話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち >>467
その規模のデカいアプリケーションとやらがffmpegとかゲームとかをやるwasmならファイルサイズが大きくなる以上のメリットがあるからいいが、きれいなUIを表現するためにjavascriptよりファイルサイズの大きくなったwasmを使うのはアホとだけ言っておくわ >>464
Wasmではfsなど必要ないのだから
no_stdで全く問題なくプログラミングできます
Rustの基本はほとんどcoreに入っています
allocを使えばVecやStringも使えます
あと欲しくなるのはHashMapあたりでしょうがこれもhashbrownで使えます
一度no_stdでプログラミングしてみることをオススメします >>471
いえいえ
Wasmのファイルサイズはそんな巨大になりません Rust で簡易アセンブラっぽいものを作ったことがあった (特に std を避けるとかしてない) ので
wasm で出力してみたけどだいたい 140kb くらいな感じ。
たぶん JavaScript で書いて最適化もすればもっと小さくは出来そうな感触はあるが
だからといって Rust でやって深刻に巨大すぎるということはない。
小さいプログラムのときでも Wasm は使い物になる。
いや、もちろん比較したら JavaScript で書いたほうがよいことも多いのだろうけど、
全くのアンチパターンってことはない。 今のところrustよりはecmascriptenの方が既存コードを活かせる >>462
Next.js使ってるならサーバーサイドでSSGやSSRのためにJavaScriptを動かしてるってことだね
そこをRust化したいと思わないの？ >>478
next.jsはUI部分だけでバックエンドはRustだから特に必要性は感じないね >>479
Next.jsでSSRなら毎回JavaScriptのコードが動くわけだけど
「バックエンドはRustだから」って？
外から受ける部分のサーバはRustでもそこからNext.jsを動かすためのNode.jsなどを呼び出すことになるよね 単にNext.jsがデータをフェッチする先のAPIエンドポイントがRust製ってだけだろ。
LBやらWebサーバーのような低レイヤがRust製かどうかみたいなのはそんなにユーザーに近いWeb屋が気にかけて手をいれる場所でもない。 途中にビルド嚙ませれば同じにできるけど一般的にはCommonJSとECMAScriptで違う方言のJSでやり取りする事になるけどね
TypeScriptは使ってないから知らん >>480
Next.jsがまるで悪かのように言ってるけど、そんな遅いと思わんな
自分が求めてるレベルが低いだけなのかな next.jsは普通に速いよ
ビルドがクソ遅いだけで
他のエコシステムはもっと高速なんだけどねえ サーバーサイドは可能な限りリソースコスト(クラウド代/ハード代電気代)を下げたい
Next.jsに限らずJavaScriptを含めた遅い言語の実行は避けたい
すべてをRust化するのが最善案 Next.js(Nuxt.js)はどんなにクソだとしても使わざるをえないものなんだよね
Next.js以上のものはもはや作れんよ それな
App Routerが神過ぎるんよ
これのおかげでサーバーサイドエンジニアが全てコントロールできるようになった Next.jsがRailsの息の根を止めたわけだが、
React+Next.js+〇〇
このバックエンド部分の〇〇がRustが活かせるところ >>486
>>487
ReactとNextの大改革されてきた歴史を知っていれば
数年後にはまた改善されて新たな導入が必ずある もう大きくは変わらないんじゃないか？
正直俺はPages Routerまでのnext.jsはゴミだと思ってたから使ってなかった
しかしApp Routerを見たときまさに俺の求めているものだと感じた
多分これが最高地点だよ 今はRuby on Rails でも、React/Next.js, TypeScript が転職で必須。
少し前は、Vue.js だったけど、Vue 3 は流行らなかった
Rails 7 からは、Hotwire に変わった。
HotwireはHTML Over The Wireの略で、
SPAの開発において、JavaScriptのコーディングを極力必要としない。
脱node.js, webpack
JSONではなく、HTMLベース。
サーバーサイドでHTMLを生成し、WebSocketでWebブラウザへ送信する
これで、Reactに取られたシェアを回復する >>492
javascript使ったほうがラクなのになんでわざわざhtml縛りするの？ SSRのsvelteはWebオーサリングツールから実画面に持っていきやすい
WebページのスクリプトにRust使えるブラウザとRust実装のsvelteを作ってもらいたい SvelteもNext.jsもサーバーサイドでJavaScriptを動かすためエコじゃないのでいずれ新たなものに置き換えられるでしょう std::any::type_name_of_val()は学習時にも良さそ 昔から使えるよ
fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str {
std::any::type_name::<T>()
} >>493
JS使った方が楽という感覚は理解できんわ >>496
next.jsのapp routerがサーバーサイドフレームワークになったの知らないの？ リソースコストがかかるスクリプト言語をサーバーサイドで動かしてる連中はいずれ消えるさ >>495
app routerの登場によりSSRだとかCSRとかややこしい概念は必要ない
あるのサーバーコンポーネントとクライアントコンポーネントとサーバーアクションのみ
極めてシンプルになった SSRやCSRがややこしいと感じる意味がわからん
Next.jsのPage Router時代の区別がややこしかったと感じてるだけとちゃう？
特定の実装とは関係のない概念としてのSSRやCSRは別にややこしくも何ともないでしょ
ReactのサーバーコンポーネントはNext..jsではサーバーサイドでレンダリング(HTML生成される)、つまりSSR
クライアントコンポーネントはクライアントサイドでレンダリングされる、つまりCSR
ついでに言うとHotwireみたいなのも仕組みとしての基本的な考え方は同じ Rustで引数の数を可変にしたいと思っただけでマクロが必要になるの、どういう思想なんだ >>505
オプショナル引数 → 数が少ないならOption多いならbuilder
可変長の引数 → スライス
マクロを使うのは個々の引数の扱いがそれぞれ異なりそれぞれをコンパイル時に型をチェックしたい場合などに使う next.jsはRustフレンドリーなフレームワークだから実質Rustなんだよね >>504
その発想だとサーバーアクションは説明できないよ >>508
俺は将来的にnext.jsは全部rustで書きなおされると思ってる >>504
概念自体はそっかという感じだけどそれを実装する方法があまりにもいけてなさすぎたんでしょ
App Routerはどこで実行されるか？だけを意識すればよろしい C++であれば関数のオーバーロードで実現していたようなことをRustでは全部封じてしまった結果、ライブラリは至る所マクロだらけ
これはRustの目指したいところなのか？ 実行時の分岐ではなくコンパイル時のコード生成に置き換わるんだから
ゼロコスト抽象化という観点ではC++のほうがそちらを目指さなければいけなかったんじゃないでしょうか。 あ、可変長引数の話とオーバーロードの話を混同してしまっていた。 https://qiita.com/buntafujikawa/items/1bd808f5f55eb63df7c4
こういうの知ってたら
オーバーロードもデフォルト引数もいらね〜
どうしてもほしけりゃ別名の関数作るわ
ってならん？ 別名の関数を作りたくなるのはわからんでもないけど、実際crates.ioはそうならずにマクロだらけなので 田舎者は十年間使わない道具でも納屋にしまいっぱなしってことがまあまああるけど都会だとどんどん捨てるじゃん。
都会では物より空間のほうが高くつくから。
何が大事か、何を大事ということにするかで判断が変わる。
名前を考えるってのは人にとって思ったより負荷が高いということに対する解がオーバーロードなんだよ。
でもまあオーバーロードにもデメリットは当然ながらあるので結局は何を重視するかの問題。 オーバーロードは無くてもいいけどキーワード引数は欲しいかな >>519
あるよ
X { name: "foo", num: 123, ... } >>520
いちいちstructを定義しなくてもいいようにするためにキーワード引数って存在してるんだよ >>521
同じことだろ
関数の引数で列挙するか構造体で列挙するかで差はない
構造体で列挙しておけば関数の引数はその構造体名だけ出せばよい
他の関数でも使い回せるメリットもある 構造体を使うかビルダーパターンで困ることはないからね
もし技術的に矛盾のない他の良い方法があれば提案してみるべきだけど既出だと思うよ >>525
でも可視性があがるよ、あと保守が楽ちん
メリットいっぱいなんだよ✌ Adaってなんだと思って調べたら米国国防総省が主導のもとで開発されたプログラミング言語なんだね
後に開発されたC++やJavaに影響を与えたんだって >>490
OSSはなんだって始め数年は大改革されるもんよ
良くない作りは早めに治さんと後になったら大変になるから
逆にズルズル引きずって大変な事になったのがPython2&3だったりyum辺りだな >>501
スクリプト言語は人員が集めやすいから消えはしない
世の中は理想論じゃなく現実で回ってるんだから >>522
えっ、マジで違いがわからないの？
キーワード引数の価値を理解できない人がいるとは >>530
悪いがデザインパターンの考えは大事だと主張させてもらうよ
可読性、保守性至上主義なので キーワード引数のような劣った方法より構造体あるいはビルダーパターンが絶対にいいぞ
デフォルト値はまとめてDefault実装でがっちりコードも書けるしな キーワード引数は>>523に書いてあるように、いまだ有用な実装が挙がってないから無い
数年後には有用な実装が提言されてるかもしれないから待て パターンにアンチ的な考えを持つのはお門違い
Webアプリにしてもコア部分のライブラリにしても、一般的なデザインパターンに基づいて設計されていればあとから雇った技術者に引き継がせるのが楽ちん
デザインパターンのうちのひとつ、ビルダーパターンだって可読性、保守性に優れてるから使われているんだ >>533
構文が優れていないからパターンみたいなキショいものが必要になる
誰が書いても同じようなコードになることを目指して開発されたPythonにはデザインパターンは必要ない 可読性・保守性のために追加のパターンの勉強が必要だなんて信じられない
まるでJavaみたいだ >>537
だってPythonはデザインパターンを意識しないと保守が面倒になるような複雑に設計すること自体がアンチパターンじゃんか >>539 アンチパターンは言い過ぎか、Pythonにだってデザインパターンの基本的な原則はあるんだから >>537
Pythonは欠陥プログラミング言語として知られているように酷い状況だよ
特に酷いと言われてるのはPythonにはinterface機能がないこと
抽象クラスで無理に実現しても劣りコードも汚い
Pythonはプログラミングはせずにあくまでもスクリプトとして用いる範囲内で使うのがよい まあでも言われて考えてみればbuilder patternなんてせいぜい「Pythonらしいコード」とかの範疇か >>541
pythonにインターフェースがないのは、インターフェースが必要になるような製品にpythonで設計するなってことだぞ Pythonで抽象クラス使うくらいならProtocolでも使うかな
まあtrait使う方が良いのはそうかも デザインパターンとかいうオブシコ要素をRustに持ち込むの迷惑だからやめろ パターンアンチが多いのか知らんけど、デザインパターンのうちクリーンアーキテクチャの考えは最低限習得しとくべきよ
フレームワークやライブラリと疎結合に実装しておけば保守性はばっちり
フレームワーク入れ替えのリファクタリングだって容易にできる いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
そのためRustに持ち込んでも意味がないものやRustに持ち込む必要がそもそもないことが多い
Rustを理解していない人がRustを批判しようとして逆に失敗する一因にもなっている >>546
オブジェクト指向ありきのあの本はもうオワコン
読み返すとオブジェクト指向だらけで胸焼けするよ Rustスレにオブシコアンチの居場所はないぞ
Rustはオブシコの主要機能の2/3を取り入れてるんだから >>537
Pythonもデザインパターン盛り盛りで作られてる
必要ないとか思っちゃってるのは経験が浅いだけ >>547
>いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
この考えが間違ってるんだよなぁ
デザインパターンの特定の実装しか理解してない人とデザインパターンの実装例から導き出される原則まで理解してる人では見えてる景色が正反対になってしまう例だね >>541
Pythonではインターフェースを抽象クラスで代替できるってのと
Rustではキーワード引数を構造体で代替できるってのと全く同じことなんだよな
一言で言えばどちらも低DX >>552
それは全く違う
C++とRustにキーワード引数がないのは
リソース管理の問題があるためだ
つまり引数部分で色々やると
リソース獲得問題と解放問題などが生じてしまう
だからキーワード引数ではなぬ分離したほうが好ましい >>548
クリーンアーキテクチャはアーキテクチャパターンの中でもすごくシンプルだと思うぞ
とにかく関心の分離にこだわる、この考えに尽きる
まあ、これこそオブシコの中のオブシコの考えだからアンチは大嫌いなんだろうけど >>551
言いたいことはわかるがデザインパターンといえば
GoFと言われてるようではダメで
今のパラダイムに合った本が出ないとつらいかな デザインパターンといえばGoFは流石に古くないか？？ デザインパターンという言葉はGoFに汚染されているからな
デザインパターンという言葉を使うこと自体がアンチパターン デザインパターンが広義的すぎるのは分かる
デザインパターンではなくアーキテクチャパターンと表すべきだというのなら、まさにごもっともでございます 話がそれてるけどデフォルト引数（キーワード引数）がRustに無いのは現時点での仕様
デフォルト引数を使える点はPythonの勝ちだねおめでとう、じゃあPythonくんはブラウザバックしようか 出来ることが多いほどいいってわけじゃないからなぁ。
「構造化は好きな場所にジャンプできないから欠陥のあるパラダイム！」とは言わんでしょ。
そんでそういうのは他の言語機能との連携とか諸事情を考えて決めるべきことだから
Rust でキーワード引数がないのは「今のところは」よいバランスの仕様が思いつかないでいるってだけ。
これから良いアイデアが出るかもしれないし出ないかもしれない。 >>559
いつからブラウザで見ていると勘違いしていた >>551
その導き出される原則がデザインパターンなんだが何か勘違いしてない？ オブジェクト指向におけるリスコフの置換原則もクラス継承を前提にしているように
一時期のオブジェクト指向はクラス継承を使うことが前提の狭い話が多かった
元々のオブジェクト指向はオブジェクトに値がカプセル化されてメソッドが公開されてればいい
クラスやクラス継承はオブジェクト指向に必須ではなく害悪のほうが大きい
そのためRustやGoなど多くのモダン言語がクラスを排除している >>563
Java？古いぞKotlinでだいぶキレイになった
>>401にも書いたけどclassに継承まわりの制限が設けられたのは可読性保守性においてgood いや、デザインパターンとかいうワードを声高に主張してたのって昔から大体Javarだったって話 ついJavaという言葉に反応しちゃったけどよく見たらJavarだった… >>566
ごめん勘違いした>>565はスルーしてほしい ・コンストラクタと関数を区別するのが面倒臭い
・関数とオブジェクトを区別するのが面倒臭い
・引数リストと普通のリストを区別するのが面倒臭い
デザパタの原則を導き出せばまあこうなる 今こそ新しいソフトウェア設計の本が必要かもな
オブジェクト指向でも関数型でもない「ふつうのソフトウェア設計入門」みたいな >>572
他言語の話ではなく
デザインパターンの多くがクラスとその継承を前提あるいは例示していて
Rustなどのクラスを排除した最近のプログラミング言語に対して手法もしくは例示が適さない話かと 継承なんざインターフェースでいくらでも代用できるやん
応用力ないん？ 従来は継承を使ってカプセル化とポリモーフィズムを実現してたけど、最近は継承を使わずにカプセル化とポリモーフィズムやるのが主流よね
継承をサポートしないならクラスいらないし rustのデザインパターン本こそ現代のソフトウェア開発に必要なものだ
誰か出してくれ >>546
クリーンアーキテクチャとかアーキテクチャ設計レベルの話はデザインパターンの範疇ではないよ
デザイン(設計)のパターンではあるけど「デザインパターン」という言葉はもう一段階詳細レベルの話 >>578
デザイン(設計)のパターンの中のひとつにGoFデザインパターンがあるのでは？ >>578
クリーンアーキテクチャとかもろにオブジェクト指向だろ >>578
うん>>558でも言ったけどアーキテクチャパターンと言うべきだったすまん 只の道具なんで、向いていれば適応するし、向いてなければ使わない。
宗教的な正しさなんてどうでも良いんですよ。
おまいらは政治将校か？ 実装パターン < デザインパターン < アーキテクチャパターン
すべてデザイン(設計)のパターンではあるけど対象とする粒度の違いで呼び名が違う Rustでよく使われてるパターンは
レイヤードアーキテクチャ
DDD
クリーンアーキテクチャ
なのかな？他にある？ >>580
そう感じるのはクリーンアーキテクチャをオブジェクト指向で実装した例だけを見て
クリーンアーキテクチャをオブジェクト指向の文脈でしか理解できてないからだと思う >>570
暴力でも寛容でもないふつうの非暴力闘争がいいのに
非暴力的な二項対立まで否定するのは行き過ぎだよ >>586
そういう逃げは良くないぞ
例えばDDDはオブジェクト指向じゃなくても実現できる！と言ってるのと同じ
実質そのような原典は存在しない
独自解釈によるものにすぎない オブジェクト指向、スタック指向、手続き型しか知らないんだけど他になにがあるの？勉強したいから教えてくれ 関数型はオブジェクト指向において部分的に使うもの
高階関数とかラムダ式とかはそんなに難しくない 高階関数は「人間にとって」わかりにくくなるので使うなと
言われているね
あと論理型というのがあったなあ >>589
フロントエンド用途でコンポーネント指向
あと関数型というのは名前の通り関数に型を持たせたってだけ
高階関数と呼ばれてるね
オブジェクト指向に成り代わるものはいまだ出てきていない オブジェクト指向信者の人達、その時々の優れたものをオブジェクト指向認定してるイメージがある
あるいはオブジェクト指向とはオブジェクト指向を名乗った言語の良いところどりおよびそれと重なる全てと定義していそう
オブジェクト指向信者もJavaは嫌いそう それはそうと継承の省かれたオブジェクト指向はオブジェクト指向と名乗るべきではないと思うんだが、新しい名前は無いの？ むしろ継承を省かれたぐらいでオブジェクト指向を名乗れなくなる方が意味不明なんだが。 オブジェクト指向は単なる理論であって言語がどう実装するかは言語の勝手 狭義のオブジェクト指向言語は
データと操作を一つにまとめて型として使えるよ
ということだけ
カプセル化、継承、多態性をオブジェクト指向に入れるかどうかは
昔から諸説ある >>596
オブジェクト指向はオブジェクトの中に値(異種複数可)を閉じ込めてオブジェクトへの公開メソッドのみ公開すること
継承なんて概念はない なんかオブジェクト指向といいデザインパターンといい一般的な意味とは違うふうに捉えてる人が多いね オブジェクト指向かどうかはどうでもよくてどういうアーキテクチャで設計して実装するかが重要なんだけど 関数型プログラミングがどこで使われてるのか調べてみたけどコンピューターサイエンス分野しか見つからない >>603
関数型プログラミングはただの手続き型プログラミングなんだから当たり前だろ フロントエンド屋か単にスクリプト組むくらいしかやらない人はオブジェクト指向に触れない
実装屋は逆にオブジェクト指向をベースにしたものばっかりやる
オブジェクト指向アンチの正体が分かっちゃうね 手続き型を文芸的にしたのがオブジェクト指向で、数学的にしたのが関数型 オブジェクト指向も関数型も確固たる定義がないバズワードだからな
話題にするだけ無駄 グラデーション的だわな。
常識的な分類として「かなりこっち寄り」くらいに言えるものはあるけど。
文句なく関数型といえる汎用プログラミング言語は Haskell くらいか。 オブシコアンチってなんでアンチやってるの？オブシコへのただならぬ恨みを感じるけど オブジェクトを指向指向したら汚いコードがいっぱい出た オブジェクト指向自体には問題はなにもない
問題とされているのはオブジェクト指向ではなくクラス継承
これは実装継承となるアンチパターンなので使ってはいけない >>612
ここはRustスレで継承問題はクラス機能ごと排除することでとうに解決されているんだがなんで継承問題を擦ってるんです？ 一部のRust信者の布教活動がひどかったせいで他スレ住人からさんざんヘイトを買い
普通のRust使いもクソどうでもいいこだわりを押し付けられるばっかりで
有益な情報が集まらないと判断しここを見限った
結果、ここが雑談部屋になることを止めようという勢力はRust信者だけになってしまった 今どきRustだけしか使えない実装屋なんているわけなくて他の言語の雑談がちゃんと通じるからなにも問題ない
バイリンガルプログラマな姿こそ実装屋が目指すべきところ べつに実装継承でもそれ自体が問題ってわけではない。
実装継承が依存を強める (密結合) といったって実際に依存があるものが依存するのは当たり前だし仕方がない。
ただ問題なのは事前に適切な設計をすることもまた出来ないという現実があるってことだ。
プログラムを書き進めたら思ってのと違うかったというときに強固な依存があると軌道修正がしんどい。 継承は廃れた技術だから議論する意味がない
関心の分離を意識したプログラミングをしていこう >>613
前にこのスレで話題になってただろ
Servoではポインタを使って無理矢理DOMの継承を実装してるとかなんとか >>619
なにそのアンチパターンww
俺らはこれを反面教師として頑張ろうな >>604
手続き型には関数とデータ構造がある
関数しか(抽象化され)ないというのはオブジェクト指向の視点からそう見えるだけだ 関数型言語が言う関数ってのは数学用語の関数のことで、
引数と評価結果の関係で表現される。
C とか Rust とかがいう関数のことではないよ。
関数とは呼ばれていても値を返すサブルーチンであって関数ではない。 Deref使った継承もどきは委譲と変わらんよ
継承が敬遠されるのは変数、関数単位でfinalとかsealedで修飾したりprivate/protectedを使い分けないと
基底クラスで満たすべき不変条件を継承クラスでぶっ壊されてしんどいって話だから
基底クラスをブラックボックスで抱えて公開機能だけをそのまま公開する形なら全部委譲してるのと同じ 正しい責任転嫁と悪い責任転嫁を区別するのが面倒臭いと思えば全部委譲でいい
正当化が必要と感じる人には継承が必要なのだろう 委譲やるよりインターフェースで共通項をもたせてポリモーフィズムできるほうがスッキリ実装できる インターフェースでやるときこそ委譲の使いどころでは？
データレイヤーでのインターフェースRepositoryのImplからDataSourceの各メゾットを呼び出すのはまさしく委譲の考え オブシコ＝オブジェクト指向
で使ってるとやっとわかった。「あたしこ」の「しこ」かと勘違いして訳がわからなかったよ。 >>627
レポジトリはドメインレイヤーがやるところでしょ >>627
delegationとforwardingの区別が付いてないね ここで数学用語ではなく、学校では評価されない用語を使うのがオブジェクト指向 オブジェクト指向の良い所は真に賢い人は真面目に勉強しないしょうもなさと多彩な用語の数にある
だからオブジェクト指向言語を勉強した人間は真に賢い人間と競合することなくマウントを取ることが出来るようになる >>627
それは委譲ではない
継承と委譲とインターフェースは違うもの 自分の使っている用語の定義に無頓着な人が賢いwとか有り得ない >>634
“賢い”の定義が違うんだろ
察してやれ 定義を後出しすることに罪悪感がない人はたぶんもっとリアルな悪を見慣れている Rustにはインターフェースは無くて型クラスはある
型クラスを推してけ >>634
その用語、定義ありませんよｗ
君が勝手に思い込んでるだけｗ オブシコ用語って掛け算順序界隈の主張する「等分除と包含除」とかの仲間だよね 時代はオブシコではなく関数型プログラミング
オブシコは時代遅れ
例えば機械学習は関数型プログラミングやってる RustがJSを滅ぼしてくれるのはいつになるかいのう…… まず先にDOMを滅ぼしてくれないとRustがウェブを乗っ取れない
DOMがJS依存すぎる DOMはJSに依存しないしいろんな言語のインターフェースがあるが。 >>646
肝心のWasmにDOM操作を許可しないんじゃ意味ない >>647
DOM操作自体はwasmでもできるぞ
オーバーヘッドが大きすぎて遅いだけ >>648
Wasmから直接DOM操作は不可能
JavaScriptにやってもらうしかない
つまりJavaScriptしかできない
そのため単純なDOM操作だとJavaScriptが有利だが
Wasmで何らかの処理をしつつのDOM操作だとWasmが勝つことが増えていく >>649
645だけど、だからDOM自体が欠陥品なんだって
JS依存の現状から脱却するにはDOMに変わるものが必要 tree構造以外である程度の汎用性あるデータ構造なんてないわ。 DOMに文句言ったところで何かが変わるわけじゃないからな
どうでもいい話 >>651
現状JSからしか使えないってのとDOMに欠陥があるかどうかってのは全然別の話だと思うが。 >>654
DOMには安全性のためにJavaScriptでしか触れないのは、DOMの出た当初は良かったが、JavaScript以外の言語も幅広く使われるようになった今ではその設計が古くなって欠陥品になってるのは事実 >>653
他人に文句を言うより自分で労働するという正義感は過労死の原因だよ
クレーマーはこの正義感を変えるじゃなくて既に変化した人 domなしでのナビゲーションの方法があってもいいとは思う いい加減にDOMはXMLをやめようぜ
無駄な構文が莫大な通信ロスを生んでる >>657
正義感w
自分でコントロールできないこととコントロールできることの判別こそ過労死しないためには最重要なんだけどね
DOMが欠陥品？
で？君はどうしたいんだい？ >>655
昔DOMは他の言語からでも直接触れたがほぼ全て淘汰されてJSだけが生き残った DOMをゴミと言うのはWindowsをゴミと言ってるのと同等で無駄なこと やりたいことを先に固定してからそれに合わせて物事をコントロール可能にするという順序は逆にしたい >>662
Windowsはゴミだから個人も仕事からも排除した
しかしネットがWebベースのこの時代にWebブラウザは排除できない
DOMは取り扱わざるを得ない
とはいえRustによるWasmからの取り扱いは以前よりかなり状況が良くなってきている
まずReference Types の導入によりJavaScriptのオブジェクトをそのまま透過的にだがRust(Wasm)側でも持ったり返したりできるようになった
これはJavaScriptグルーコードの削減をもたらしている
さらにGC対応もメモリ管理のうちJavaScript側依存のものの扱いを任せられるようになりRustでも取り扱いが楽になる
Rust側の内部に閉じたデータのみメモリ管理すればよくなるからだ デザインパターンはあくまで定石集なんだから、Rust用のデザインパターン作ればいいだけの話。
「Rustならこんなに簡単にできる」と自慢できるから、信者にとってもいいことかと。
あと、Rustでダックタイピングできたっけ？ 事前にTraitで定義しなきゃいけないんだったら面倒だなぁ。 デザインパターンって簡単に実装できるとか
自慢するたぐいのものだっけ？ ドメインまわりをフレームワークと分離させる設計ならなんでもいいや
今後リファクタリングすることを考えた設計が大事 >>666
ダックタイピングは動的型付け言語のためのオモチャであり
デメリットも多いためまともな言語はダックタイピングを排除して別の形を取っている
ダックタイピングは規律のない無政府状態であり可読性も下げデバッグもしにくくなり最悪となる
もちろん実行時の動的型付けの問題もはらんでおり自然の静的なチェックができない ダックタイピングというゴミのような方法に対して
Rustはダックタイピングを採用せずに代わりに完璧な方法を用意した
それがtraitのrequired methodsとtrait boundsである
この二つにより全てを解決している ダックタイピングなんて荒業ではなく、ポリモーフィズムをやりましょ >>664
ない。結局まともに使えるものを用意しようと思えばああなる。
それも理解せずに馬鹿みたいに文句言ってるだけだわな。 >>667
繰り返されれば飽きる
繰り返されないのはパターンではない >>671
GoやTypeScriptみたいな静的片付け言語でもダックタイピング採用してるよ
nominal/structuralと動的/静的は直交 Goは実行時にランタイムが動的にvtableを生成してメソッドlookupするわけだから
静的ではないでしょ？
そんなことはC++やRustでは許されない行為だよ >>676
TSはanyで型が消えてるときの話じゃないの？ 誰も定義の擦り合わせをしないのでどんどん意思疎通が困難になっていく ダックタイピングは一見するとお手軽に見えるけどプログラミング開発の足を引っ張る悪
Rustは排除しているので大丈夫
そしてRustではトレイト境界により確実に使えるものだけを呼び出せることを静的に保証しつつ用いる 現代はデザインパターンで設計するんじゃなくフレームワークで作る時代だけどな >>682
そのフレームワークがデザインパターンで出来てるんだけど アルゴリズムはライブラリを一個作れば終わり
もう一個作ったら車輪の再発明
だがデザインのレベルではワンパターンが続いてもなぜか攻撃されない >>673 >>677
c++ templateは静的ポリモーフィズムのダックタイピングの代表例だろ……
Rustのgenericsはどれくらいダックタイピングできているかね。 >>685
C++の静的ポリモーフィズムはダックタイピングではない
ダックタイピングは実行時に動的に処理されるものだけを指す
例えばGoはinterfaceでダックタイピングするが実行時にランタイムが動的にitable (interface table)を生成して用いる
これは実行時に動的に処理されるためダックタイピングとなる
もちろん実行時に動的に処理するためダックタイピングはどの言語でも問題を孕んでいる
手軽さとの引き換えだ C++のtemplate（concepts無し）のダックタイピングが好きなら
genericsよりmacro_rules!の方がいいよ C++のtemplateで正しく関数を呼ぶの難しいよ…… >>677
静的型付けの意味から解説せなあかんのんか？
勘弁してくれよ C++はちゃんとコンセプト使わないとだめだよ
黒魔術は禁止です >>686
C++ のテンプレートが受け入れる型は型同士の関係ではなくその性質に依存する。
一般的にもダッタイピングの典型例として挙げられることは多いし、静的か動的かで区別するという理屈を私が見たのはここがはじめてだ。 >>685
Rustのgenericsはtrait boundsにより完璧に静的に安全安心にチェックされ保証できる >>692
ダックタイピングの言い回しに前例はなくても原因はあるんだろう
そして原因はおれじゃない、あいつがやったという理屈は何度も見たことがある 委譲やダックタイピングを理解してないのもどうかと思ったけど
↓これらの区別ができてないのは致命的だと思うので勉強しようね
静的型付け/動的型付け
静的ポリモーフィズム/動的ポリモーフィズム
静的処理/動的処理 確固たる誰しもが認める定義のない言葉を勝手に定義してマウントとるのはやめよう？ ファクトチェック界隈では事実かデマかが確固たる論点だよね
公式ルールか、ローカルルールか、という発想はそれ自体がマイノリティ オレオレ定義で擬似問題作るの止めろ。
ダックタイピングについてはWikipediaの解説でいいか。
ja.m.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0
英語版が一番詳しいかね。 >>683
フレームワークがデザインパターンのセオリー通りにできてるかって言ったら意外とセオリーを破って新しいムーブを作ったりするのはよくある
結局パターン通りに作る云々が論じられるのはフレームワークを使う側 >>699
アンチパターンや亜種になるだけで全部パターンだぞ ダックタイピングはお手軽さを上回るデメリットだらけの悪手法
問題もなく安全で高速なRustのトレイト方式が最善策
トレイト境界により安全に呼び出せる範囲を明確にしてる点が要所 うちの講師が全てにおいてPythonに劣った言語って言ってるけどマ？ >>703
Pythonは遅いし本質でない実行時デバッグも大変だし
速くて実行前に静的に解決できるRustがベストな言語だよ >>703
その講師はメインでなにを教えてるん？データサイエンス？少なくともコンピュータ工学やメカトロニクスではなさそう >>705
その講師も大概だがお前もデバッグをまともにやったことないだろ。 >>708
Pythonは実行時に発覚するエラーが多すぎてプログラミング言語として辛いんよ >>709
よっぽどレベル低いことしてない限りそこまでキツくはないわ。
むしろrustのビルド時間分使えばよっぽど楽にテスト構築もできるまである。 >>703
どーせデータ分析やデータサイエンスの講師だろ
くだらない釣りやめろ まあどうせ荒らしのたぐいだろうから安価つけても無視されて無駄なんだろうな
くだらねえほんと >>702
trait boundはgenerics と型パラメータの相互依存が重たい気が。
c++ template & conceptみたいに、templateから型パラメータへの一方向依存になるように(型パラメータに指定される型はtemplateから独立するように)できたっけ？ わかる→ Pythonで簡単なスクリプトを書く
キチガイ→ Pythonでプログラミング開発する Pythonでプログラム書くのもちゃんと型書いてlintしたら出来なくもないよ よく分からんが画像生成系のフロントエンドでrubyベースのってあったっけ？ C++20のコンセプトはゴミみたいなenable_if_tを使わなくてよくなって見やすくなったよね
まだまともに使う機会が来なくて慣れてないけど >>716
やりたいことがよく分からないけどtraitのassociation typeで解決しない？
I: Iteratorだと要素の型はI::Item（正確には<I as Iterator>::Item）になるみたいな
C++のconceptだとtypenameに相当するのかな
traitにgenericsの型パラメータ持たせるかassociation type使うかの判断は慣れるまで難しいけど
選択肢が複数あって外部から決められる ⇒ generics型パラメータ（例：AsRef<T>）
traitを実装するときに内部で自動的に決まる ⇒ association type（例：Deref::Target）
みたいに使い分けるといい
全部をgenericsの型パラメータでやろうとするとカオスになる >>716
できる
例えばこのように
https://docs.rs/hyper/latest/hyper/service/trait.Service.html
pub trait Service<Request> {
type Response;
type Error;
type Future: Future<Output = Result<Self::Response, Self::Error>>;
// Required method
fn call(&self, req: Request) -> Self::Future;
}
ここで型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタResponseは依存しない
>>726
その二種類の混合も可能 ごめん
>>727はこうね
型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタRequestは依存しない ちょっと違うなぁ。
c++ template & conceptだと
wandbox.org/permlink/74j79ZQ3mbPb2cLO
みたいな感じでCircleはf()の影響を受けずに独立させることができる。
draw()メソッドというダックテストを満たせば他はどうでも良い。
Rustのgenericsだと
wandbox.org/permlink/CvepQKXOXaNTJoJm
みたいにCircleとf()の間にtrait Dという相互依存ができて、Circleを好き勝手に定義できなくなる。
f()が欲しいのはあくまでdraw()メソッドだけだから、双方にtrait Dが必要になるのは過剰な相互依存になる。
クラスの継承もそうだけど、余計な依存性は面倒だからできるだけ排除したいところ。 それはgeneric constraintがnominalかstructuralかという違い
Rustはnominalのみでstructural generic constraintはサポートしてないよ Pythonは全てにおいてJuliaに劣った言語だな >>729
Circleを
fn f<T: Drawable>(t: &T) -> f64 { t.draw() }
に渡したいなら普通に
impl Drawable for Circle {
fn draw(&self) -> f64 { <Circle as D>::draw(self) }
}
を追加するな
コントラクトの明示を余計な依存関係だとは思わない
ちなみに
impl Circle {
fn draw() -> f64 {...}
}
みたいに本体のimplに定義するとCircleのself.draw()は全部こっちで解決されるから
impl Drawable for Circle {
fn draw(&self) -> f64 { self.draw() }
}
って書ける
１つの型に複数のtraitで同じ名前の関数を持たせるのはRustだとたまに見かける
impl Debugとimpl Displayはどっちもfn fmt()で別の実装するし >>726
>traitを実装するときに内部で自動的に決まる ⇒ association type（例：Deref::Target）
ある型に対するtrait実装をただ一つだけにしたいものや
自然と一つだけになるような性質のものはassciated typesを使う
使う側はassociated typesのほうが使いやすいので
悩んだらとりあえずassociated typesからはじめてみる >>729
そこはtrait介在させなきゃいけないところでしょ
Rustの方針が正しいと思うよ traitとかいうつまらない機能にこだわってないでPython極めろよ
時代はAIだぞ >>735
Rustをただ貶したいだけのやつは黙っとけよ雑魚 Pythonはスクリプト言語のクセにメソッドチェーンもロクに使えないうんこだからなぁ。
比較で持ち出すならせめてNimにしろよ。 >732 >734
Rustのtrait boundはあらかじめ型の方でtraitを準備しておかなきゃいけない。
これはRustが嫌っているクラスの継承みたいなもので、genericsやるごとに元の型/traitを弄くり回す必要が出てこない？
呼び出し元が真に必要なのは機能だけなんだから、同じ名前で互換性のある引数型・戻り値型ならそのまま利用できる方が良い。
まあ、ダックタイプみたいに手を抜かずにAdapter作れ、と言う方針でも良いけど、それならAdapter helperをもっと充実して欲しいところ。
AdapterパターンとかDecorator パターンて重要なのに言語側のサポート薄いよなぁ。 >>738
>>これはRustが嫌っているクラスの継承みたいなもの
クラス継承は基底クラスの実装をそのまま継承する実装継承になっていることが問題点
一方でRustはトレイト境界となるトレイトに対して自分で実装を用意する
したがってRustでは実装継承とはならず問題が生じない >>737
Ninはコンパイル時間の無駄があるからゴミ
Pythonは実行までの速度が一番早い >>739
全然理解できていないね。
継承の問題点は、コンパイラ都合で早い段階で設計を固定しなきゃいけない「早すぎる最適化」。
機能とか実装の問題じゃなくて設計の問題。 >>743
それは継承の問題点
Rustのトレイトは各型が自分で実装するため継承ではない >>745
早すぎる最適化が問題なんだから、トレイトもその問題を引き継いでるぞ >>746
早すぎる最適化が問題になるのは継承
Rustのトレイトは継承ではなく合成で用いる >>745
全然理解できていないね。
>>743根は設計の問題で実装関係無いし、継承特有の問題というわけでもない。
>729というとfはDrawable以外のトレイトのdrawが使えない制限あるし、Circleも、問題領域に関する知識の少ない設計初期にtrait Drawableを実装するという仕様固定を行う必要がある。
c++のtemplate concept はあくまでdrawのみに依存するという違いがある。 真面目に理解したいなら>>730が正解だからstructural typingとnominal typingの意味を調べてくればいいよ >>729
C++は酷いな
struct定義の時点でdraw()宣言を要求してしまうのか
Rustなら
struct定義の時点でdraw()宣言を要求せずに済む
後からdraw()という機能(＝Drawableトレイト)が必要になった時点で
structに対してDrawableを実装すればいい
Rustの方が優れてるな >>738
複オジに毒されすぎ
オジが一つ覚えで繰り返し書いてる内容がRust開発陣の見解だと勘違いしないようにね >>738
根本的な理解がおかしいので説明すると
Rustのtraitは機能を抽象化している
各型はその機能が必要になった時にそのtraitを実装(impl)すればよい
必要な分の各機能(trait)を実装することで結果的に各機能の合成となる 細かな実装上の違いはあるけど概念レベルでは Rustのトレイトも他言語のインターフェースも同じ
実装上の違いを見て異なる概念だと勘違いしてると本質を見失う >>750
そりゃダックタイピングでdrawを使いたいんだから、drawの無い型は対象外。
>>752
もともとの話はダックタイピングでtraitじゃないよ。
Rustで静的ダックタイピング・ダックテストする方法はあるかしらん？ ダックタイピングという問題ありまくりのものを有り難がるのはバカだけ >>738
言語側のサポートならマクロで十分でしょ
macro_rules! impl_drawable {
($type:ty) => {
impl $crate::path::to::Drawable for $type {
fn draw(&self) -> f64 { self.draw() }
}
}}
を定義すれば
impl_drawable!(Circle);
だけでimpl Drawable for Cirle {...}を生成できる
渡された型が同じ引数＆戻り値のself.draw()をもってないとコンパイルできないから実質ダックタイピング
Drawableに関数を追加したらマクロにも追加すればいい
draw関数の有無だけで照合するのは別の意味のdrawも対象になるから危なっかしい
impl traitだとどのモジュールのDrawableを実装するかまで指定できるから混同の心配がなくなる ダックタイピングは使う側が気をつければなにも問題ないんだよなあ
そこらへん理解してないあたり実装をやったことのないエアプなんだろうな
かわいそう >>757
その「使う側が気をつければ問題ない」が最悪
ミスが入り込んだ時に気付かず問題を引き起こす
ダックタイピングを持ち上げるのはバカだけ >>756
これがいわゆる実装継承の再発明
このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター ダメ人間の思想「使う側が気をつければ問題ない」によって
今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史
今後はそのような言語を用いてはいけない C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？
リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。
具体的に言えば
fn increment(dest: &mut u32) -> u32 {
let t = *dest;
*dest += 1;
t
}
みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。 >>760
どこをどう曲解しても実装継承にはならんだろ
すべてのケースでマクロ使うとでも思ってるの？
〇〇の思考回路はよく分からん
>>764
Atomic系統ならfetch_addがあるけど普通のincrementは単純＆限定的すぎて逆にないな
std::mem::replace使えば
replace(&mut t, t+1)
とかできるけど+1するだけなら大袈裟すぎる気がする >>761
だから の文が全然繋がってなくてワラタw
こういう低能はプログラミングしちゃダメだよ。 >>755
そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。
DbCとか勉強したほうがいいよ。 >>767
ダックタイピングが負の遺産であることは自明だが
ダックタイピングを使わないことが負の遺産だと主張する君は破綻している >>768
自明だと検証できる証明を示して頂戴。
検証可能性の無い主張は単なる疑似科学だし。 そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明 おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる
適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ >>774
当たり前だろ。
インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。 >>776
ダックタイピングはその契約書が定義されてないのが良くない
Traitは契約書の定義みたいなもんだ
ダックタイピングは白紙の契約書にサインするようなものだ >>765
replace だと借用規則に引っかかってエラーになるようです。
まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが…… >>780
Copy型だから通りそうな気がしたけど無理だったか
何か技がありそうだけどそこまでするほどの問題じゃないよな >>764
Rustで++は排除されている
理由はたくさんあるようだが
例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか
前置と後置の間違いミスも多いことに加えて
生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや
move/copy問題もあったかな >>782
そんな話はしてないです。
役に立つことを言えないなら余計な茶々入れるな。 >>783
おまえ質問してる分際でキチガイなのか？
そういう態度を改めないなら二度と教えてやらんぞ
fn increment(dest: &mut u32) -> u32 {
std::mem::replace(dest, *dest + 1)
} 質問している人間相手なら関係ないことを書いて良いわけではない >>784
結果的に役に立たないことがあってもしょうがないですが、関係ないことをアンカーで書くのは正当化できない迷惑行為です。
質問者 (特に初心者？) には迷惑をかけてよいと考えているのだとしたらそれは改めるべき悪です。 ついに存在しないCコードの幻覚が見えるようになってしまった複製おじさん…… 一方、質問文を誤読して解答してしまった人間に対して強く当たって良いわけでもない >>788
あれは誤読 (?) なんでしょうか。
茶化しているように受け取ったので腹立たしかったのですが、
そうだとしたら >>783 は言い過ぎですね。
ID:S2bQYQek さん、すいません 人間の注意力読解力は実際この程度なので、人間にC++を扱うことは難しい 腹立てるのもわからなくはないがそんなにキレてレスするようなことではないだろ
気に入らなかったらスルーする程度には心に余裕を持っておこう 個人的には後置インクリメントだけを関数化するのは微妙に感じる
fetch_addとかは必要性を理解できるけど単純なpost_addやpost_incrementは一段階上の処理を関数化するので十分でそのほうが見通しがいいように思う >>762
こういう偉そうなこと散々言ってたhaskellがなぜ流行らなかったのかすら理解できてないというのが愚かだよね。 >>777
c++ template conceptも碌に知らないでダックタイピングをけなしているのか。なかなか……
ダックタイピングは契約の主体・時期・範囲が違うという話だかね。 >>796
C++では機能の異なる同名メソッドを区別できないから欠陥品 >>799
名前も引数も戻り値も区別できないんだったら、ダックタイピングで呼び出す側はそもそも区別する必要あるんですかねぇ。 >>796
それだとRustでいうところのトレイト境界を課すことができないな
つまりC++では安全に呼び出すことができない
呼び出したメソッド内で出来ること出来ないことが定まらないため >>801
「呼び出したメソッド内で出来ること出来ないこと」
て何？
Rustのtraitて、副作用のコントロールできたっけ？ traitのprovided methodのdefault実装で呼び出せるのはrequired methodと
trait境界がある場合はそのtraitのmethod
そしてそれらで構成された他のprovided methodのみ
って制限をC++でどうするんだろ >>792
毎度毎度のことで余裕を削られた最後だったんだよ。 毎度毎度のことという認識を持っていながらなぜここに書き込むのか >>806
せやな。
けど日本で比較的活発な Rust コミュニティというとここなんよ。 >>804
concept記述が多すぎて書いててイヤになるな
普及しそうにない仕様がまたC++に増えた感じ
Rustが必要な機能を洗練して提供しているのと対照的 >>808
洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。
枯れた既存プログラムの置き換え用途が無難なところかと。
コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。 >>809
Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に
RustやめてGoにする宣言してる
理由を真面目に話してるから一見の価値のあり >>810
検索したけど見つからなかった……
リンクある？ >>812
見た
ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い
そして批判されてるのはなぜかTypeScrpt
Goについてはシンプルなのが好きでジェネリックが導入されてワクワク
Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ
Rustの型システムはとても素晴らしいけど、 >>808
過去のコードと矛盾しない形での後付けだからな。
C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。
簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。
Rust だって歴史が積み重なればいずれそうなる。
「綺麗なのは使われないもの」という格言を聞いたことないか？
Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。
規格策定・処理系保守のリソースは無限なわけではないしな。 エディションはすでに複数あるけど
あっても無理とか問題起きるとか
実例あるの？ >>816
問題が抑えられているのは問題がないように保守されているからで、
その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。
今問題があるとかそういう話じゃないから未知数と述べてる。 C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ
C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは
Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある >>817
今は良くても未来は何が起こるかわからない論法は
何にでも使えるから意味ある話とは思えないけど… 「出来る」ということを大前提として確信できて、
その上で「上手く出来る」ならより良いってのが産業的な考え方だ。
おおよその場合に上手く出来ても
ちょっとした想定外に直面したときに破綻するようでは使い物にならない。
現実の問題ってのは想定してないところから出てくるものだから
そういうことも乗り越えられることを証明するには
実績 (歴史) を重ねるしかしょうがないんだ。
C++ は上手くやったとは言えなくても、汚くても打てる手が有る道具として信頼を得た。
Rust は今の時点では実に使いやすいように見えるが、
本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。 C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない
これだけ増築工事を重ねてもまだ見込みが立たないまま C++の知識は大いに再利用されているので現実世界の変化は小さい
想定外かもしれないのは変化の大きさではなく
現実世界を定義できないことだ
定義できるのは理論だけ >>821
今の想定が甘いとか具体的指摘なかったら
想定外の対処ができてないから駄目は無敵論法 そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ
パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分 サーバーサイドは群雄割拠時代よね
Rust、Go、Java/Kotlin、C#いっぱいある >>825
駄目とは言ってない。
駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。 >>828
あなたの話相手してもrustでも他言語でもいいけど
問題回避のためにこういう仕様や実装にすべきじゃないか
みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね すべてを疑っても産業だけは疑いようがないって話なら
想定内と想定外の境界がどの辺にあるのかはなんとなくわかる >>814
Rustは型〇ナニーで長時間バトルだったと言ってるぞw
>>812動画の人がいくら天才でも2年間かき回したのは頂けない Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い
さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい Ruby は、Go/Rust/Elixir の3大言語を超えた！
Rust の上昇は止まったか？
Stack Overflow 米国年収。2022 -> 2023
Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7
多くの言語 : 6.5〜7 -> 7.3〜7.8
PHP : 5 -> 5.9
Dart : 4.4 -> 5.6 >>812
流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草 >>835
Rustインフルエンサーの成れの果てですなw >>834
せめて用途別のプログラミング順位を挙げてくれ
…単発に言っても無駄か😭 Goは２年も続けられるだろうか
大分前に少し使ってみたけど例外投げずにResult（タプル）で返す言語設計を採用しながら
返されたResultを無視してもコンパイラが警告出さないからやめた
Cで戻り値のエラーをスルーする事案が多発したから後発言語で例外が作られたのに
↓を見て気持ち悪さを感じる人には向かない
file, err = os.Open(path) // ← fileと一緒にエラーの受け取りを強要される
os.Chdir(path) // ←エラーしか返さないから戻り値を無視して処理を継続できる >>829
情報が充分じゃない (から議論を始めることさえできない) ことが
リスクだという話をしているつもりなんだが、伝わってないのか？
どんな問題が起こるのか事前にわかれば苦労しないよ。
起きたことに対処し続けるしか仕方がないが
可能なら自分が対処する当事者にはなりたくない。 >>838
悪いほうがよい (Worse is Better) 原則というものも知られている。
正しさと単純さを天秤にかけてどちらが良いかという点で Rust とは異なる重みづけをしたのが Go だと思う。
問題をコンパイラが検出できる設計はもちろんありがたいが、そのために持ち込む構造は人間が把握しやすいものだろうか。
正直言って Go が良いとは全然思わないが一貫した理念に基づく判断であって、不備でそうなってるわけではない。 >>829 >>839
このあたりは設計の根深い問題で、「変化を抱擁する」を標語としたアジャイル開発とかインクリメンタル開発とかで色々議論されたな。
あんまり目立った成果は無かったような気もするけど、機能間の疎結合と可換性は重要な指摘だと思うわ。 >>817
これはごもっともな意見
50年後にRust 2072エディションがある状況で最新コンパイラが2015エディションをサポートし続けてるとは思えないからどこかでは切ることになる
それでもRustのモデルとC++のモデルとどちらのほうが相対的によさそうかという選択の問題 50年後にC++23はサポートされているのだろうか
というかC++は50年後もアップデートしているのだろうか >>843
cargo fix --edition
のあるRustは至れり尽くせりだよ >>844
既にC++17とC++20で以前導入の機能の削除が大量に行われている CになかったC++の機能は削除してもチューリング完全が保証される
逆に、削除したらチューリング完全ではない保証をするならミニマリズムがベター >>840
Kotlinが上がってきてるのうれしい
Fortranも上がってるのはなぜだ C++ は欠陥報告という制度で過去の規格に遡って修正が加えられることがある。
たとえば C++11 発行当時の C++11 と今の C++11 は内容が異なるわけ。
基本的には過去の仕様に新機能を追加したりはしないが微妙な挙動の変なところを直すような保守は続いている。
実質的には Rust のエディションみたいなことにはなってるんだよなあ。 >>850
Rustは必ずeditionを明示しないといけないから
あるソースコードがどのeditionなら確実に動くのか明確にわかる
そしてそのeditionを指定してコンパイルも通り実行もできる
しかしC++は当初のC++11に従いコンパイルできて動いていたものが
今はC++11の機能のいくつかは削除されてしまっているために >>852
C++11 は C++11 として存在し続けているので問題になってないという話をしてるんだが cppreference.comの下のほうにちょろっと書いてあるdefect reportってそういうことだったんだ
勉強になるわ〜 >>853
名前が同じならなんでも良い…… ってこと！？ >>856
「規格が同じなら」ということだよ。
c++11とかはあくまで規格なので各実装の準拠率とか注意するポイントはあるけど、メジャーな機能を保守的に使えばそれなりに互換性を維持できる。 RustのEdition方式が優秀すぎる
新たな機能の規格で分けるのではなく
各Editionは後方互換性の変化で分けているため
過去に書かれたコードも必ず動く >>857
規格が同じといいつつ機能消してんだから同じなのは規格の名前だけじゃん ID:T31Boec7
流石にこいつ日本語能力なさすぎだろ
ガイジかな？ mojo vs rustでmojo公式とnetflix天才とRust本著者で盛り上がっている
https://www.youtube.com/watch?v=MDblUyz0PtQ
>>814,835
早口なので大変だろうけどちょとした言葉の節々に情報があるからリスニングがんばれ >>863
copilotで要約して貰うのが時間も短縮できるのに無能だなw >>864
この天才同士のディスカッションを楽しめないなんて損してんね🥲 Netflixの天才とかいうのが胡散臭くて信頼性がないんだけどどういう人なのよ。 >>863
この人の英語聞き取りにくい
もうちょっとゆっくり喋って欲しい
中身うっすいのにさ >>862
普通に境界性知能ってやつでは？
この手のは全部そうだと思うようにしてる >>863
ベンチマーク試してみたところ以外はブログ記事のまんまなのでわざわざ動画で見なくてもいいなこれ
公式ブログに書くならもうちょっとちゃんとしたベンチマークやれよって感じ
見識を疑うレベル Netflixの天才がいかがでしたかブログレベルの動画を出すとは >>863
動画内の指摘が記事に反映されてMojoがRustの3倍速いじゃん!!
Mojoコンパイラ賢いな 以前からMojoがCより何倍も速い！とかやってるけど
ベンチ方法や条件などが何かおかしい でもデータを見てから断罪するのは俗っぽいから
データを見ないでロジハラするのがベター DynamicVectorは最適化でSIMD使うように最適化されるってだけだろ
あと末尾最適化する
くだらなすぎる Rust Reserved keywords
KW_ABSTRACT : abstract
KW_BECOME : become
KW_BOX : box
KW_DO : do
KW_FINAL : final
KW_MACRO : macro
KW_OVERRIDE : override
KW_PRIV : priv
KW_TRY : try
KW_TYPEOF : typeof
KW_UNSIZED : unsized
KW_VIRTUAL : virtual
KW_YIELD : yield >>873,875
同じLLVM系なのにRustが3倍遅いのかよ!!
Mojoがコンパイラ賢いのかRustコンパイラが... あれを見て本当にRustが遅いと思っちゃう層の人にRustは向いてない GoはGCを伴う言語だから論外
MojoはC/C++/Rustより3倍速い >>878
同じLLVMといってもMLIRという数値計算に最適化されたIRを使ってるから速い
恣意的な例である そういえば昔Delphiがコンパイルの速さを売りにしてたの思い出した
なんか懐かしい 20年後には流石にもっと良い言語が登場して流行っていることを期待している >>885
アンダースヘルスバーグ天才だよな
ボーランドでDelphi作って
マイクロソフトでC#とTypeScript作って >>888
俺は天才とは思わない
この人ってお手本となる言語があって
それをよりよくすることは得意な気がする 普通の人が実務で使うような汎用プログラミング言語は
とびぬけた画期的なパラダイムで構成しても使い難いし、
ひとつひとつはどうということはない要素を上手く組み合わせる
バランス感覚が重要って感じはあるね。
天才的な閃きでどうにかするようなものではない。 既存のものをうまく組み合わせたりリーダーシップをとったりするのに天賦の才があったという意味なら天才かな C#→Javaのビミョーなところを直す
Delphi→Pascalのビミョーなところを直す
TypeScript→JSに型付け Turbo PascalやDelphiやVisual J++は彼か作ったと言えるがTypeScriptはHejlsbergが作ったわけじゃないからな
広報+コントリビューター+社外との政治的調整役 そうだな
じゃあRustyNailって名前にするか ビミョーなところをどうにかしたってどうせ別のビミョーなところが出てくるに決まってるんだよ。
だましだまし発展させて行き詰まったあたりでまた新しい何かが登場するのが世の中のサイクルというもんだ。 割とマジでヘルスバーグ動きますの可能性はある
Carbon、Go→Google
Rust→Mozilla
？→Microsoft
この流れは確かにある GoogleもMicrosoftもRust支持で
Carbonの公式FAQにはRustが使えるならRustが良いと明記されている Rust支持というより、現状最良の選択肢がRustであると認めているだけでは
なのでもっと良い選択肢を作ることが出来たら嬉々として打ち出してくる可能性はあると思う 代替の芽が今ないから早くて十数年以上先
MojoはPythonベースで関心が数値計算に向いていて違う Netflixの天才は2年かけて右端の住人になったのか
https://pbs.twimg.com/media/GDa2G6iWIAAsyh3.jpg:orig
これからは目立った実績が無いのにRust歴が長いと
型〇ナニーで時間溶かしてると認定される >>905
Go？
Goはランタイムが大きくGCベースの言語だからRustの代わりにならんよ Web用途だとRustはtokioと関連ライブラリが必須だからGoよりランタイム大きくなるけどね >>909
Rustバイナリが小さい
tokio+hyper他で特別な指定もなく普通に作ったweb server実行バイナリがstrip後に1.3MB サーバーエンドでバイナリサイズなんてどうでもいいけど専有メモリ量がJavaやGoより小さいのはよい Rustってcargo buildとかやると通信量結構えげつない 依存関係があるライブラリをダウンロードすれば Rust に限らず
それなりにたいくさんひっついてくるのはよくあること。 C++でビルドする前にapt-getしてね、ってのも同じことだしな Rustだと依存ライブラリの数が桁違いに多くなるのが原因 お前それ、 JavaScript の前でも同じこと言えるの？ >>907
ブロックが波カッコだったらなぁと思ったことある。 一回DLしたパッケージOSにキャッシュしてくれればいいんだけど
そうじゃないから学習でやってると無尽蔵に取りにいくのはなんとかならんのか >>919
1回しかダウンロードしない
その後はそのキャッシュを用いる それよりディスク使いすぎだろ
ビルドの中間生成物が簡単にギガ単位になる >>922
それな
複雑なコンパイラでインクリメンタルビルドを高速化するには空間性能を犠牲にするしかないんだろ 大きなライブラリは動的リンクすることにしてもいいけど、
そしたら実行環境の管理と開発環境の管理を分離しづらくて面倒くさくなる。
どうやったってどこかに負担はかかるならストレージさえあれば
だいたい解決ってほうがいいという戦略なんだろ。 Rustほどディスク使う言語他にあるの？
桁違いに多いと思うんだが ビルドキャッシュの一部を何もしなくてもプロジェクト跨いで共有してくれればまだいいんだけどね
用途的に外部ストレージやNASに置くようなものじゃないというのが困るところ Rust (cargo)のソースダウンロードしてすべて同一マシンでビルドする前提の設計はいいと思う。
soとかdllとかjarみたいなの、あまり信頼したくないというか。 Crates.ioを信頼してどうせ落ちてきたもの毎回ソース全行確認したりはしないんだから、落ちてくるものがバイナリになっても別に良いかな so使ってsymbol not foundとかよくあるしな
基本的にC++ソフトのビルドは作者が使ってるディストリでしか再現しないと思ったほうがいいくらい
しょうがないからDockerでビルド環境作ったりするけど面倒だしディスクも食うし
結局ディスクキャッシュが多少多いくらいで済んでるRustが一番マシな気がする soが悪いのではなくまともなパッケージマネージャーもまともな依存解決ツールもないのが悪い 確かにOS非依存のC++標準パッケージマネージャと中央レジストリがあれば良かったかもね
ただその場合でもABIが不安定なのはどうしょうもないから
Rustと同じく手元で全部コンパイルする方式になったと思うけど Cargo 風の管理をする C++ 用パッケージマネージャはある。
最初からそのパッケージマネージャ用に構成してくれてないと
なかなか素直にはビルドできないことに変わりないんだけど。
パッケージマネージャが優秀でも C++ 世界では
「統一されていない」ことが面倒くささになってる。 そう考えると中間言語形式で配布できてAOTコンパイルもできる.NETがさいつよって話？ NuGetが使いやすいと感じた事がないし、充実していると感じたこともない >>934
dotNET は事前コンパイルしてもランタイムサポートの分厚さ (にかかる実行コスト) は避けられないので
コンピュータの性能を絞りきるようなつよつよ最適化は無理じゃないかなぁ。
いろんな方式の良いところを上手く取り入れて総合的には良いものに仕上がってるとは思うけど
それが最強かというと状況によるんじゃないの。 >>921
チャプターサンプル毎にプロジェクト作ったら毎回DLしてるように見えるけど パッケージの使い勝手という意味ではdocs.rsの存在も大きい気がするな
どんな野良ライブラリでも決まった場所に決まったフォーマットのAPI一覧が確実に存在するというのはかなり便利 ドキュメントを全く書かなくても少なくとも公開されている一覧はわかるってのは強い。
最悪の場合でもコードへのリンクもあるし。
Haskell のリポジトリがこういう感じだったので他の言語でもこれくらいやればいいのにと思ってたから
Rust で取り入れてくれたのはかなり嬉しい。 >>926
いや、スマホでセルフ開発する時に困るだろ？ procマクロとかコンパイル環境で展開したいものを除くとtarget指定した環境に依存するだけだから手元でコンパイルする必要性は全くない
いずれにしろどこでビルドするかと中間生成物のサイズが異常にデカくなる話とは別の話だよね もしスマホで開発する人がいたとしても
レンタルサーバに接続して表面上の操作にスマホを使うだけで、
実質的なストレージ・計算リソースはサーバのものを使う形にするのが普通。
スマホ内で完結させようとしたらツールチェインをセットアップするだけでもクソ面倒くさい話になるぞ。 働いてないとスマホで開発するとかいう前代未聞の人間がいるんだな iPhoneが出たばかりの頃から、脱獄して開発環境を入れてObjective-Cでプログラミングしてる人は一定数居ただろ。
最近では、どのプログラミング言語でも使えてLinux（Android）と遜色ないよ。
今のスマホは、外部モニターも外部SSDも繋げるし、外部グラボのGPUでLLM開発だってできる。ほぼほぼRaspberryPi5と変わらないよ。
だからこそ組み込みにも強いRustが注目されてるんｼﾞｬﾏｲｶ スマホでRustformersからLLM開発する場合、ローカルにOllama入れとくか、サーバにGPT-4やLlama2を入れとくかぐらいの違いしかない。
Google Coralもスマホでも使える前提の製品で、このチップは発熱量が減ればスマホに内蔵されるだろう。
実際、Vision Transformerのような技術を応用しているApple Vision Proが製品化されたから、スマホからこういった機器に移行するのかもしれない。
今後数年間、これらの技術動向から目が離せない状況が続くんだろう。 グローバルなビルドキャッシュ共有の話も予定には挙がってるね >>934
何を基準でさいつよかの定義による
デスクトップ
Web
バックエンド
iOS/Android
ゲーム
とC#だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC#使えれば何でも作れるという意味ではさいつよ >>951
.netの毎年の長文blog最適化レポートを見ると2年後くらいでNativeAOT最適化がC/C++に肉薄すると思う デスクトップ
Web
バックエンド
iOS/Android
ゲーム
とC言語だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC言語使えれば何でも作れるという意味ではさいつよ
チューリング完全なので 無能なやつほどゴールデンハンマー症候群に罹患しやすい >>949
さすがに問題として認識はしてたんだな
スマホセルフ開発の日は近い ウェアラブル系の機器には失望した。
どこへでも持っていけるよりどこへも往く必要のないインフラこそ目指すべき未来だろ。 >>957
働いてないと「スマホで開発==スマホしか持ってない」という発想になるんだなww >>960
ベッドといえばフランスベッドが取り扱ってるAI 視覚支援機器『オーカム マイアイ2』(OrCam MyEye 2)は、
イスラエルのオーカムテクノロジーズ（OrCam Technologies Ltd）の製品だったな。
これは活字の読み上げみたいだけど、寝具メーカーは、どこへも往く必要のない未来インフラをAI使って目指してるんだろう。
ウェアラブル系が狩猟型・動物型とすれば、寝具系は農耕型・植物型なんだろうな。人間は生活の約３割は寝てるんだから当然だけど。 表向きはどうであれたぶん寝たきり用だから話を膨らませるのはそのくらいにしとけ 寝たきりで親指しか動かないとかならスマホでコーディングするかもしれん 性能がどうこうよりもシンプルに画面が狭いのはすごくつらい。
無理。 >>962
いやお前に当てはめてるだけだぞ
何言ってんだ？ はちみつ餃子氏最近見ないからRust関連は触れないことにしたのかと思ったらコテ外して書き込みに来ててわろた >>969
新スレ立ったときに名前欄に入力するのを忘れてたままやな 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうが。 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうけど。 クソスレまで立てちゃってw
素直に中古のノートPCでも買えよ traitの種類多すぎて把握しきれん
使い分けもようわからんし Pythonのpep20みたいなってRustにもあるの？ スマホやタブレットなどのモバイルOS上に開発環境用意するのは主に2つユースケースがある
1つはモバイルOS上で実行させる小さなユーティリティを作るため
だいたいlinux emulatorみたいなアプリ内環境で稼働させる
もう一つは出先の空いた時間や障害対応等の緊急時にノートPCを持ち歩かなくても簡易的な作業なら対応できるようにしておくため
前者はスマホだけで作るやつもいるにはいるが少数派
なので今のところはメイン開発環境は別に用意してるのが大半 PEP20って何だよと思ったらあのウンコポエムだった 次スレタイトル間違えてしまったのですまんが誰か立て直してくれ
規制食らってもう立てられなくなった >>977
traitとは機能を抽象化した抽象型だから使いたい機能のtraitを選ぶか作ればよい
structなどの具象型は各々必要な各機能(trait)を実装しているもしくは実装すればよい
そして抽象型(trait)を用いてプログラミングすることでその機能を実装する全ての具象型を対象とした共通コードにできる >>982
FromとかAsRefとかDerefとかの時点でもうようわからんぜ Fromは汎用的な変換だよ
変換に失敗する可能性を含む時はTryFromを使う
AsRefは参照から(別型の)参照への読み替え変換
コストがかからない場合が対象
コストがかかるものはFromを使う
Derefは変換ではなく演算子
変換は複数の型への変換を実装できるけど
演算子なので各型で決められた一つの型へderefできる
&T→T
Box<T>→T
Rc<T>→T
Vec<T>→[T]
String→str
PathBuf→Path
など あー。それぞれの比較はまあそうなのかもしれないんだけど、そもそもどういうtraitがあってどういう時に使うべきなのかを全て把握できてないせいで実際にコード書く時にどれを使うとRustらしいコードになるのかわからなくなるってのがしんどいんだよね >>988
どの分野のどんな話でも基本パターンの学習による慣れ
問題
match std::env::args().XXXXX {
Some("yes") => ...,
Some("no") => ...,
_ => ..., // エラー
} 「当然こういうのが標準ライブラリにあって然るべきだろう」みたいな感覚ができるから結局は慣れ。
常識的に考えてあるだろうと思ったら nightly だったみたいなこともよく経験するから俺が欲しいようなものはみんな欲しいんだなと思う。
実質的に言語の一部みたいなくらいのやつは嫌でも避けられないから何度もドキュメントを読み返すはめになるし、そのうち自然に使えるようになる。 >>987
Derefは演算子でも利用されるがDerefそのものが演算子(や演算子の実装)というわけではない
Type Coercionというのは型変換(Type Conversion)の一種なのでDerefは変換ではないというのもやや言い過ぎ
各型で決められた一つの型にderefされるのは演算子だからという理由ではなくて
Derefはスマートポインタが包んでる値へのアクセスを便利にするために用意されたものだからderef先の型は自然と一つに決まるため(>>733)
&T→TはDerefの役割ではない AsRefとBorrowは未だにわからんなあ
調べてもHashMapがBorrow要求するならそこだけBorrow使っておけばいいか……で思考停止してる このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 34日 14時間 37分 28秒 5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《UPLIFT会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
4 USD/mon. から匿名でご購入いただけます。
▼ UPLIFT会員登録はこちら ▼
https://uplift.5ch.net/
▼ UPLIFTログインはこちら ▼
https://uplift.5ch.net/login レス数が1000を超えています。これ以上書き込みはできません。
