Rust part21
レス数が1000を超えています。これ以上書き込みはできません。
昔は全体の性能に余裕があって I/O (ストレージと通信) が極端に足を引っ張る状況だったから言語処理系の動作速度は問題にならなかったけど今は全ての性能をギリギリまで絞り出す勝負に変わってる感じだね。 Rust言語は
・タイプセーフ、メモリセーフによる高い安全性
・並列プログラミング処理設計
・ガベージコレクタのようなランタイム無しに動作
だから、これらを活かせる製品に採用したらいいんじゃないかな
いまどきそんなのは組み込みロボットとかカーネルやエンコーダデコーダくらいしかないような気がするけど >>953
その条件ならウェブに向いてるね
そして実際に使われてるね ウェブっていうかwasmじゃね？
rustじゃないけどffmpegのwasm実装は使ったことある >>954
Webって言っても大規模なユーザーがいるようなものじゃない？
大した事無いサービスで、スペック高い人が必要なRustはまだまだ辛い気がする。Javascript並みに誰でも使えますって世の中になったらRust一択でも良いのかもしれないけれど。 AWSもGCPもサーバーレス環境とかのランタイムや下周りがだいたいRustで書いてある CO2排出量は難しいな
Rust書けない人間がCO2排出するだけのうんこ生産機になってしまうのもあんまエコじゃない気がする actix-webはどうなん？自分はよく知らんのだが使ってる人いるんけ？ >>958
そんなこと言ってると、Rustへのリスキリング時のco2排出量もRustのコストって言われちゃうぞ。 CO2排出量を考えて、コンパイル中は息を止めている JavaがOracle事件で終わって脱SpringでRustのActixがついに普及するかなと思ったらC#のASP.NETにみんな行っちゃった Javaが脱Springなんて馬鹿げた事言い出してるのかと見間違えたが
脱Javaの話か
Rustは学習コスト高いからJavaでやってた様な大人数プロジェクトには向かんだろう >>952
特に機械学習ではその方向が顕著
MLIRみたいにSIMDやGPUを使う前提でIRが設計されてる
Node.jsが切り開いた非同期IOの登場もでかい
これによってIOの比重が高いプログラムでもIO待ちがなくなり
さらにマルチコア、GPUを活かせる環境が整った
一方Rustはtokioなどの非同期IOを実現できるフレームワークが山のようにある
さらにSIMD命令を直接使える仕様も整備されてきている
(LLVMの最適化によって勝手に使われることも多いが)
マルチスレッドは言わずもがな
他の言語でこれらを全てサポートしている言語はない
現在の最先端の環境を活かせる言語は他に選択肢がない RustのWebアプリケーションは未履修だけどぜひやりたいなあ >>954
Webで使うにはTokioなどの重量級ランタイムが必要
ただ利用するだけなら難しくはないけどエコシステム含めそこまで安定しているものじゃないのでランタイム含め自力で修正できる力が必須 >>964
90年代後半にコボラーがJavaでWebアプリを作れるようになるための学習コストに比べればRustの学習コストは断然低い >>969
その時期にいた純粋コボラーって定年間際のジジイじゃん。そりゃ学習コスト高いわ。 httpclientもそれぞれのイベントループに対応したものをつかわないとダメだから割と面倒なんだよね
使い方もフレームワークによってかなりクセが違っていて面倒だし
ぶっちゃけWebはGoやpythonでいいんじゃねーかって思う Go のランタイムサポートは分厚めだがどうせ要るもの(やること)と考えればそんなに速度的に不利なわけではないよな。 速度的にはGoで十分なんだけど型とか貧弱すぎるんだよな…
sumタイプとパターンマッチくらいは欲しい >>968
tokioは他言語と比べて大きくない
そして安定している
>>971
各言語に複数のイベントループライブラリがあってその通りだが
Rustはデファクトスタンダードがあるためそこで困ることはない >>975
いやデファクトがあるのは良いけど
例えばコマンド実行1つとっても
tokio::process::commandとか使わなきゃいけなくてなんだかなあと
非同期版じゃないのと区別しなきゃいけなくて嫌気が刺す
まあpythonもasync使えば同じことなのだけど まあ俺はRust信者だから使うのだけど普通の人はなかなか辛いんじゃないかなーと
その点Goは何も考えなくて良いしpythonもasync使わなけりゃ同期的に書けるし >>976
PythonもasyncはそうだしJavaScript(Node)も同期execと非同期exec分かれているし
動作が異なるのだから別になるのは当たり前
もちろんRustでも同様で
そもそも関数の返り値が異なる
だから関数が分かれているのは正しい
したがって一番下位のライブラリが別であることに何ら問題はない
一方で中位ライブラリ作成側の視点に立つと
同期か非同期かだけの違いでasync/awitを除いて全く同じ構造の関数を作ることになる
そのため『?async』キーワードによるジェネリック化がRustでは進められている
期待しているのはこの話でよいのか？ >>978
いや見た目は似ててもpythonとはだいぶ違うよ
まずpythonでのasync defは単なるコルーチンオブジェクトなので非同期とか関係ない
これにより恐ろしい柔軟性を持ってる
さらにWebにおいてはASGIという非同期Webフレームワークが満たすべき仕様をまず決めた
その仕様を満たしさえすればどのような実装でも非同期の機能を満たせるような仕様となっている
そこにはもうイベントループなどの概念は消え去っている
さらに同期版と同居できる仕様となっている
なのでdjangoなどは同期版と非同期版の切り替えが可能となっている
このように明らかにユーザーフレンドリーな姿勢を貫いている >>979
Rustのasyncもコルーチンだぞ
まずは理解してから出直して来い Rustのasyncはstackless croutineでstate machineとなっている
個別stackのresouceもswitchingも不要なため軽くて有利 Rustのasyncは（スタックレス）コルーチンである
Rustのasyncは（スタックフル）コルーチンではない
どっちも正しいとは思うけど >>977
Rustが活きるのってやっぱり軍事系じゃないかな
兵器の制御とかGCなんてもってのほかだし速度も必要
メモリリークも起こせない 物理攻撃にソフトウェアを活用するってある意味「お花畑」だよな やっぱりAdaしかないか
プリプロセッサ使うのもNGだからマクロがダメなんかな とはいえF-35はC++だったんだし、そのうちRust採用されてもおかしくはないけどな The Book読んでコード打ち込んだりしたが理解できた気がしない
次はどうすればいいの 仕様の次は実装とか
いま極端なところにいる奴は次はもう一方の極端に行けばいいし
ちょうどいい位置にいる奴は一生そこに居続ければいいのでは？ >>990
理解できてないと感じるのがunsafeやasyncやマクロ辺りならそこは一旦放置して小さいCLIツールをいくつか書いて実践経験を一度積むほうがいいかもしれない
逆にownership/reference/lifetime/generic/traitといったコアなところが理解できてないと感じるならオライリー本など別の入門書をすすめる >>989
Rustは使われない
ISOプロセスは産業界の評価が高い F-15は50年以上空を飛んでいることを思い出してほしい
Rustは50年後存在しない >>993
Rustのスポンサー欄を見ればわかるけど将来Rustが使われるのは確定されたことだぞ
アンチさんどんまい 統計学的に会社や国家、生物種の存続見込みを解析した例を見たことが有るな。
これまでの歴史が長いものはこれからも長く続く可能性が高い。 >>996
Javaみたいにホストがアホなことするとすぐ廃れるけどな >>994
C++みたいに、色々な実装がでてくれは、50年後にも生きてるんじゃない？ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 158日 21時間 57分 50秒 5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《UPLIFT会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
4 USD/mon. から匿名でご購入いただけます。
▼ UPLIFT会員登録はこちら ▼
https://uplift.5ch.net/
▼ UPLIFTログインはこちら ▼
https://uplift.5ch.net/login レス数が1000を超えています。これ以上書き込みはできません。
