Rust part23
■ このスレッドは過去ログ倉庫に格納されています
>>500 メモリ安全というならSafe Rustのみだな。Unsafe Rustは禁止すべき。 c++標準も、Safe Rust に倣って c++ subset for safe programming とか 作ればいいのに。 メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。 java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。 >>501 C/C++はプログラム全体がunsafe空間なので難しい safeにしようとすると全く別言語になってしまう 結局C/C++を捨てるのが正しい >>503 nullポイントがある時点で… 一応JavaはStream APIと同じくらいのタイミングでOptional<T>が追加されてたはずだけど,だからといって従来の「失敗したらnullを返すメソッド」がOptionalを返すように修正されたわけじゃないしなぁ ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される nullから何かを読み出して動き続けると危険 >>508 Someである保証がある時のみunwrap()を使う 保証がないのにunwrap()する人はクビ メモリ安全の文脈だからそういう次元の話ではないのだが >>505 コーダー向けだから別言語でいいよ。 new deleteは禁止していいし、ポインタ演算その他のポインタ処理は全部禁止でいい。生ポインタのヒープ領域コピーも禁止していいし、そもそも生ポインタ禁止で参照のみ可にしてもいい。 operator関数定義も禁止でいいんじゃない? ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね どの言語にも共通するけど,書けるようになってくると楽しいよ でもってライブラリが足りて無いなって思って「使えね」ってなるんだよね >>512 あ、未定義と定義されているのも全部禁止ね。 >>500 これでRustの知名度も上がるし普及も加速しそう >>517 結構前にもNASAが同じ様な事言って今やんw rustを無理に使ってまですることがぬるぽ対策とかアホだよね >>519 まあ戦争によるサイバー攻撃に備えろってのは分かるんよ 日本も来年ぐらいに戦争になるって予測がアメリカとか含めて言われてるからね >>518 NASAに続いて米政府も「C/C++からRustへ切り替えろ」と明確なメッセージを出したことは大きいね 間違いなく日本も追随することになる Rust愛用者だけど今のホワイトハウスに推されると逆に不安になるんだがw ONCDは健全なのかな >>518 NASA?NSAじゃなく? NSAはNASAじゃないぞ。 ワロタ NSAとNASAの区別もできんとはww メッセージを出してるところが広がってトーンも厳しくなってきてるのは確か 2022/11 NSA 2023/09 CISA 2023/12 CISA+NSA,+FBI+Five Eyesの各機関 2024/02 White House(ONCD) >>524 あとは日本がどれだけ遅れるかだな 数ヶ月か、1年か、数年か、 外部のお墨付きを欲しがる時点でオワっとるんよ 言語として ここでそういう話題使って必死で盛り上げようとして 消えそうな火に風送ってるつもりかしらんけど IT大手ライバル同士が GAFAMからHUAWEIまで一致団結して Rust Foundationを設立した時点で未来は確定していた そしてRustに対抗できるライバル言語の芽が今も存在しない Rustの代替になる思想の言語が全くそれ以降全く見ないからな。 今のところGCレスでメモリ安全に向き合った唯一の言語でねえの? 後発の言語は Rust みたいに複雑なコンパイル時の検証を最初から書こうなんてそうそう思えないんじゃないかな。 >>527 欲しがってるかね? むしろ外部が乗っかろうとしてる感じ。 >>530 メモリ安全に向き合う、程度ならそれこそc++11が先駆けだろ。 過去互換性のせいで徹底できないけど。 それよりもRustはスタックフレーム指向であることに価値がある。 スタック is god, 再帰 is god. >>515 まあ標準ライブラリがかなりミニマムだなぁって感じるときはある 乱数くらい用意しておいてよ… >>530 ある言語Aがあってその弱点が強烈で直したいけどすでに普及しきっている で別の言語Bが作られる その言語Bが普及しきっていなければ容易に弱点を変更できるので別のC言語は必要とされない >>534 >その言語Bが普及しきっていなければ容易に弱点を変更できる これが真とは限らない 容易に変更できる場合もあればそうでない場合もある Rustで過去に結構破壊的変更がされてたらしいけどそれは普及してなかったからじゃないのか wikipedia > 2015年に1.0版がリリースされるまでにいくつもの破壊的な仕様変更があったが、1.0版以降は基本的には後方互換を保って6週間間隔で定期的にリリースされている。 GCやJITは銀の弾丸と思われていろんな後発言語に取り込まれたけど、所有権は最初から組み込むには高度すぎるがエコシステム成熟前に組み込まないといけないという制約が大きいんだろうな。 >>537 所有権は最終的にはプログラム間の境界の問題になるから、c++のスマートポインタのようにアダプタで管理範囲を調整することで改善可能。 適切なアダプタを用意しても境界のプロトコルをどうやって徹底するかという問題は残るから、Rustみたいに言語レベルで強制できると頑強になる。 ただ、Rustみたいにガチガチにすると設計の柔軟性を失うから、実装も早すぎる最適化になりがち。Rustの絶壁の学習曲線と相まって、開発初期のRust導入はプロジェクトを破綻させる要因となりうる。Rustが適しているのは、ある程度枯れた設計の実装を置き換えるようなプロジェクトかと。 Rustはむしろリファクタリングにも向いていてなかなか良い言語だぜ とりあえず動くように雑に書いて動かしてみて 次に機能追加充実させる上で整理しながらモジュール化や共通事項のtrait化など このようなリファクタリング過程で 他の言語だとメモリ安全性だけでなく書き換え競合やヌル値エラー値取り扱いミスなどエンバグすることも多いが Rustではコンパイル通せばそれらの心配がなくリファクタリングできる そもそもGC無しの言語ってニッチじゃない? 当面は、Rustで充足されて安泰な気がする。 うむり、実用言語では現時点で安全性とスピードを高い次元で両立できてるのはRustだけかもね。 関数型言語にも良いのあるけど、普及しなさそうだしね…。 (OCamlとか次世代HaskellらしいIdrisとか) それにCとアセンブラしかない分野(C++不可なくらい低スペックな組み込み)でC++以降のモダンな言語が使えるのは大きい。 学問的には合理的な型システムとか検証器とかの研究は大きく進んでるけど メモリの動作モデルをそこそこちゃんと仕様にしてるのは C/C++ しかないんだよね。 LLVM が C/C++ を前提にしてるところもあるし、 Rust もそれに合わせる形になってるところもある。 C/C++ 的な分野をよりよくやる言語と考えると Rust はとても良い。 すまんが↓これが動く理由を教えて欲しいんだけどさあ https://paiza.io/projects/uhC43ajorg-qaLG7mXbw7w 一見すると5行目で所有権が失われて、6行目で使ってるように見えるんだけど・・・・ これって5行目が借用に推定されてるの? それともリテラルを引数にした場合だと5行目で「1」が他のスタックにコピーされて、所有権が失われる問題なんか起きないのかな? へるぷみい >>544 値とその所有権が複製されて関数fに渡される分とそのまま残る分の2つになる 値が複製されて、複製された値の所有権が関数fに渡るだな。 所有権の複製とかいうクソワードは避けてくれ。 >>544 i32 は Copy トレイトが実装されてる。 普通なら所有権の移動になる文脈で暗黙に clone されると思ったら良い。 そう言うことなのか、ありがとう! 理由が分からなかったから不気味だったぜ >>547 >値が複製されて、複製された値の所有権が関数fに渡るだな。 複製された値の所有権は最初から関数fのスコープの中で発生するものなので 「関数f」に渡るという表現には少し違和感を感じる 感じてるから違和「感」だからね 要は頭痛が痛いと同じ >>553 感じるを感じるメタ表現だろ。 ポインタのポインタみたいなもんだ。 >>542 embedded 対応アーキ少なくね? >>557 重言ではあるけど間違った日本語ではない といったほうがよかったね >>556 少ないね。 でも、そもそも今までCとアセンブラ以外はほぼ無い状態だったから、出てきただけマシ。 それに、少ないといってもシェアが広いアーキなので滑り出しは順調と言えるのかと。 少し前まで次世代言語と言われてた程度には後発。 鯖向け言語で終わると思ってたら、マジでC/アセンブラの牙城を崩し始めるとは思わんかった。 むしろ崩し始めることすら無理だと思ってた。 >>559 状況も追い風なのかもね。 二の足踏んでたけど、armと生きていく決心をしてrust覚えるか。 先にrust身に付けてから、非対応アーキでC++導入したらメリットあるかな? Rust知ってれば安全性の高いシステム組めますと言うアピールになるし、C++にもその安全性のための知見は役立つ。 複数言語使えますってだけでもアピールになるしね。 Rustは多分仕事自体はまだ多くない。 これからアピールして増やしていく感じなので、両方使えてた方がいい。 rustというものがありながらなぜ大部分のコードはC言語なのかを知るために現場に行くのもアリ Rustが実用的になったのは2020年 それ以降の新規案件はRustになっている Rustへの移行は始まったばかりだからまだまだCが残っているのは当たり前 絶壁の学習曲線。 貧弱なライブラリと人材。 早すぎる最適化。 しばらくは既存コード置き換えが中心だし、今後もプロジェクト初期のプロトタイピングで使われることは無いだろう。 P系言語の糞思考に染まっていない初心者こそ 最初にRustを学ぶべき >>567 移植なんて無駄な作業はどの言語間でも行われることが少なく 初手Rustは冗談抜きで2024以降だと選択肢に入るんじゃないか >>567 移植なんて無駄な作業はどの言語間でも行われることが少なく 通常はシステム更新で全体もしくは一部が作り直される時に別の言語が使われる Rustでも同様でほとんどがそれら含む新たな案件 >>567 早すぎる最適化という意味不明なデタラメ書いているのは君一人だけ そしてRustを叩きたいためにウソを散りばめる >>567 貧弱なライブラリとかエアプかよ そしてRustを叩きたいためにウソを散りばめる 単なる感想を必死にウソ扱いして何がしたいんだコイツw ライブラリはPythonと比べると流石に貧弱 特に数値計算とか物理・機械学習系 簡単な数値計算の時点でnumpy•scipyのようなデファクトがなく、雑魚が乱立している もっと高度な計算系ではもっと雑魚が乱立しているか、そもそもない >>575 キチガイアンチ すべての分野でライブラリが充実している言語は存在しない ある分野で一番充実している言語を棍棒にしたら他のすべての言語が負けるのは当たり前 そういう無意味なことをして叩いて楽しいか? >>576 貧弱なことを指摘するのは叩きではない 俺はただ、「貧弱なライブラリとかエアプかよ」とか言っているエアプに現実を指摘しただけだ >>576 そこは「Rustなら〇〇分野のライブラリがどの他言語より充実している」と反論するところだろ。 >>570 絶壁の学習曲線だから無理だろ。 moveを意識しないshared xor mutableの無い、Rc中心のEasyRustとかが無いと、fnひとつ呼び出せないんじゃない? Crypto分野はRustが他言語よりも充実してるかもね ライブラリの多さってイコールでユーザの多さなんだよ 更にいうとその言語開発者の意欲の表れでもある ライブラリが少ないという事はユーザが少ない 更に少ないユーザの中でも意欲の有る人間は少数って証明なんだよね いやまあ数はあるんよ数は 意欲のある人はいるっぽいんだけど、デファクトとるようなライブラリってやっぱりそれなりの人数でちゃんと資金とって作られてるんだよな 資金取るのは個人の意欲だけじゃなくて、お金のある人を納得させる理屈が必要で、少し前までのRustは少なくとも数値計算の分野でそれが出来る言語ではなかったと思う てかrustユーザーってnvidiaのcudaサポートの酷さにガチギレするような奴ばっかでしょ。 そんなんで数値計算ライブラリが入るわけがない。 初心者向けのSimplified Rustと、 c/c++ライブラリバインドを強化したAdaptor Rustあたりは欲しいなぁ。 Safe Rustじゃ難しそうだし。 ゼロからプログラム書くならSafe rustが一番簡単だよ こいつに従っているだけで割と見通しが良くてバグりにくいコードが書ける まあGoto 多用しているようなFortran おじいちゃんとは相性が悪いかもしれんが C++を完全に理解した者のための言語それがRust 故に誰も C++を使ったことないけど Rustで困ったことないな Rust理解で必要なことはポインタとスタックとヒープとRAIIくらいかな 所有権は単なるヒープ解放責任だから大したことではない 所有権を他へ譲渡しないとRAIIによって自動解放されるというだけの話 非常にシンプル 所有権を複製するとか間違った事を言い続けてる人が良く言うわw 進化論肯定派じゃないの 人を淘汰することを志している カチョー「???」じゃなくて カチョー「で?」なら共感できたかも rustだいぶ分かってきたつもりだけど ライフタイムとジェネリクスとクロージャが一斉に襲いかかってくると無理 好きな言語だけど世の中にはプログラミング言語に強い興味を示す奴が稀なので厳しいなぁと感じる >>592 進捗報告相手が課長というのが昭和かもな そんな会社で働きたくない >>596 それぞれ理解していれば組み合わさって困ることはないんじゃないかな Rust特有のライフタイム注釈は構造体なら「参照を持ってるよ」の印で関数なら「この引数の参照は返り値の参照に対応するよ」の印であとは有効期間を満たすだけなど Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか?めんどいんですけど ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる