Rust part23
■ このスレッドは過去ログ倉庫に格納されています
termuxよりscreen派なんだよなぁ。ライセンスはgplよりbsdのが好きなんだけど。 >>21
リアルの会話でこうやってRustのマイナス面を他と同じと言う奴は
内心信用してない
>>23
言い方があれだけどこっちの方が信用できる >>25
リファクタリングってのは外部から見た時の挙動を変えないのが原則なので
少なくとも型やライフタイムについては辻褄が合っていることを保証できる仕組みは
リファクタリングでも便利なんだぞ。
内部的な処理でもあまり柔軟には変えづらいということはあるけど
変えづらいところは (外部に対する保証に関わってくるので) 変えてはならない箇所だってことがわかる。 >>9
✕プログラミングに向いていない
○rustに向いていない
皆さん、これがrust信者です >>6
せめてtraitに外延性があって集合的操作ができればいいんだけど、さすがにビルドに時間掛かりそうだしな。
ただでさえビルド時間が重たいから、設計の「早すぎる最適化」は仕方ないのかね。 >>28
例えばpythonとかだと型とかプログラム構造気にせずにパパッと書いて
ある程度動くスクラッチでレビューして内容詰めて
スクラッチから流用できそうなら作り込んでリファクタリングみたいにできるけど
Rustだとそういう風にできなさそう >>23
こういうのに限ってgoでもろくなもの書けない >>32
Pythonだとそのリファクタリング前後で挙動が変わってしまわないように気を遣うのがしんどいな
そういうとりあえず試しに作るケースだとユニットテストなんかも当然ない状況なんで
Rustに限らず静的型ならその辺をだいたいコンパイルエラーで拾えるのが楽 >>27
「僕は基本Traitがよくわからない => それはRustのマイナス面」
この発想が幼稚さがわからないのかな？
他の言語と比べたときのRustのマイナス面はたくさんあるがそういう話のレベルじゃないだろ >>32
動的型付け言語しか使ったことがない初心者が
静的型付け言語の圧倒的なメリットを理解できないのはよくあるあるある
脱初心者の壁を乗り越えよう どんな言語にもマイナス面がありRustにもある
しかしマイナス面を上回る莫大なメリットがRustにはいくつもあるからIT業界をあげてRustを支援＆採用している
揚げ足取りでRustを叩きたいだけの人はアンチスレへ行け >>36
知らないのかもしれないけど今のPythonはどちらもできる >>35
どんな理由であれ複雑なのはマイナスだろ
複雑なのがプラスだってんならC++かbrainfuckやれよ 漸進的型付けは静的片付けと動的型付けのどちらも出来るわけではなくて漸進的型付けという別物だと解釈すべきだと思うよ。 >>39
能力が同じなら複雑さはマイナスだが複雑にしてでもそれを上回るメリットが得られることがあるという話だということも理解できないの？
トレードオフ >>41
>>35はそんなこと書いてないぞ
> 「僕は基本Traitがよくわからない => それはRustのマイナス面」
> この発想が幼稚さがわからないのかな？
だぞ。勝手に自分の文脈を他の人のレスに上乗せして書いてない解釈を押し付けるなよガイジ ここはRustユーザが集うRustスレ
叩きたいだけのキチガイはアンチスレへ行け C++の後継目指すプログラミング言語「Carbon Language」、Googleの技術者が実験的公開。C++は技術的負債で改良が困難と
https://www.publickey1.jp/blog/22/ccarbon_languagegooglec.html >>37
嘘はいかんよ
Rustにはメリットなし、がIT業界の総意
Adaの方が上
最新版IEEE調査Jobs
https://i.imgur.com/Z8hI9C6.png Jobで判断するのはちょっとなあ
Jobの要件にするのってその言語さえ出来れば良い人を探す時じゃん
Rustってまだそのフェーズではないんだよな >>48
言うてメインはOSS用だよね
大手はちょっとばかり資金援助してレバレッジ効かせようと宣伝して
2021-2022がRustハイプのピークだったんだけど真水のJobは稀 >>46
Carbonはその公式FAQに明記してるように
Rustを使える状況ならRustを使ったほうがいいという立ち位置
Carbonは既存のC++遺産メンテ用 >>49
次々とRust製へ変わっていってる
リソース面すなわち経済的にもエコ的にもRustが有利なので今後次々とRust製へ置き換わっていく
ソース
＞【クラウド世界トップシェアAWS】
＞https://japan.zdnet.com/article/35183866/
＞Rustで構築されたAWSサービスの例としては、
＞コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
＞「Amazоn Simple Storage Service（S3）」、
＞「Аmazоn Elastic Compute Cloud（EC2）」、
＞コンテンツ配信ネットワーク「Аmazоn CloudFront」、
＞LinuxベースのコンテナーOS「Bottlerocket」などがある。
＞【CDN世界トップシェアClоudflare】
＞https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
＞CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
＞同社自身がRust製のHTTPプロキシである「Pingora」を開発し利 用していることを明らかにしました。 Rustは知らず知らずのうちに技術的負債を量産しそうな気配だな
Rustは既に違法建築だから
前スレで言われる矮小化オンパレードで笑ったw
前スレ
https://mevius.5ch.net/test/read.cgi/tech/1705760500/9
>>https://mevius.5ch.net/test/read.cgi/tech/1692105879/990
一応知らない人のために書いておくけど
「Rustがunsafeコード一切なしでメモリアンセーフ」な事が判明してから半年近く経ってる
特定の機能導入のタイミングでコードが発見されたけど、
「Rustの仕様バグ」だと認識されていて直せない
>>4
そんな事並べて理解したつもりでも、分からないと言っている人の側の主張が正当なんだよ
最近はここでも保証って言われなくなっただろ、当たり前だよRustの仕様に健全性が無いのだから
たぶん知っていて話を逸らしているのか、過去スレでスルーしたかで、この指摘も無理やり矮小化してくるからな
(githubの議論でも矮小化して放置)
気を付けろよ
https://github.com/rust-lang/rust/issues/114936 >>52
情報古いな
AmazonはLLRTでしょ
cloudflareのRustは放置だ 誰も問題視していないどうでもいいことでしかRustを叩けない状況
アンチが追い込まれている >>53は>>51向けな
>>52のは違うIssue/PRのcommitで場当たり的fixしただけで知れっと本質を隠蔽した
>>54
問題視したから取り繕いfixしたんだよ >>37,47
上位は納得だから結局のところ「IT業界をあげて」なんて言いたかったら
Jobで判断するのが客観的で中立フェアな基準なんだな >>53
LLRTはAWS LambdaでJavaScriptを使いたい人向けのJSランタイムの一つ
Rustが使えるならRustを使ったほうが有利
さらにAWS自体も>>51にソースがあるようにRustで書かれている >>57後半
部分的にな
あとそのソースとやらのLiam Tungはいなくなったね
飛ばし過ぎた？ >>57
>Rustが使えるなら
時々見るこの枕詞は実際の現場では使えない事の証拠なんだよなぁ >>57
>JavaScriptを使いたい人
これが圧倒的だからAmazonが独自魔改造したから凄い >>59
そのAWS Lambdaでも当然Rustを使えます
Rustを使えないのは環境ではなく低層プログラマー >>55
この恣意的な例以外で同様の脆弱性が生まれる例があれば教えて欲しい
煽りとかではなく >>62
俺も煽りじゃなく警鐘で言うけど
>>55の根本原因究明がならなかったから、今後も散発的に発見しては穴ふさぎをするのでは
(CVE報告しないで悪用されたら最悪だけど)
Rustのメモリ安全性目標チェックは他の言語と比べて
相対的にメリットがあったりデメリットがあったりするだけのことだから 例出せないならお前が偉そうに言うことではないぞ
どの立場からもの言ってるんだ？ 俺の質問に答えずに訳のわからないことを言うしかできないんですね
くだらないクズが >>52
実際の開発では出てこない極端に作り上げた例のみだから
Rustを採用しているIT大手を含めて問題視していない >>66
ちなみに急に煽り始める>>65,67はあのコテハン
>>68
>実際の開発では出てこない極端に作り上げた例
自分で踏んだ事ないから想像だけど、失敗を犯すのはその考え方の人間 いや煽ってきたのはお前だろw
何を勘違いしてるんだ 自分が攻撃するのは良くて攻撃されるのは嫌か？
そういうやつには徹底的にやるから覚悟しろよ
俺に攻撃するってことはそういうことだ 自分以外が全部同一人物だと思い込んでるアタオカの着火点は意味不明だよな >>69
実際にコードを見てごらん
ありえない無意味なコード
識者たちも問題視していない >>71 誰も攻撃してないのにこの人怖い、やめてくれませんか
心理的安全性を通り越して身の危険を感じる((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ 例の#25860、ジェネリクスとかマクロ生成の裏で意図しないでこのパターン踏んだりしない？
絶対ない？ rustでリファクタリングしながらの開発ってなると多分unsafeを途中経過で入れたりとか
そういうテクニックが必要になると思う。
その辺の整備が進めば割と広まるかもね。 >>76
絶対にないから安心していい
その「&'static &'a ()」が出てくることはない >>32
サクッとプロトタイピングする目的ならそりゃRustよりPythonのほうが向いてる
Rustは多少手間がかかったとしても速度・安全性・堅牢性を高い水準で求める場合に使う言語
>>39
AsRefやTryFromが複雑とか言われても困ります >>77
unsafeは基本的に不要
必要だと思ってもまず標準ライブラリにその機能がないか調べる
次にクレートにその機能がないか調べる
どこにも存在しない場合
unsafeを安全に閉じ込めて安全に使うことができる有用な機能を発見したのならばラッキー
それをクレートとして公開するとよい Rustコンパイラチームは意図せず発生する可能性を否定していない様子
ここのヤツはやっぱりテキトー言ってるだけか
https://hackmd.io/@rust-compiler-team/SkkrA1DCK#Variance
> https://github.com/rust-lang/rust/issues/25860
> root issue of most variance issues
> ⚠🚨⚠ can potentially just happen by accident >>77
同じ構造体の一部を参照しながら別の一部を書き換える大きめのメソッドを
複数のメソッドに分割しようとするとborrow checkerに引っかかる的な話かな
他の言語のクラスと同じ感覚で構造体作るとたまに嵌る
Rustの構造体はRDBのテーブルを正規化する雰囲気で分割した方がいい >>82
Rustのvariance仕様だから発生させることはできるけど
現実に使うコードでは発生しない
意図的にその仕様の狭間をつく現実的でないコードでのみ発生する
そのためその2015年からそのまま放置で誰も困っていない >>84
by accidentを辞書で引いてこい >>85
その2015年から9年間
その問題でトラブルが起きたことがない >>81
>unsafeは基本的に不要
>...ラッキー
嘘で始まって運頼みで締めるとはw
信者の心の支えの大手のあそこは
見境なくunsafeを使わざるを得なくなって
Rustでやった意味が無くなってるってよ 可能性を論じるならお前の頭に隕石が落ちてくる可能性だってあるが、そんなことを心配したことある？ RustはVec等のCVE前科があるからなぁ
頭に隕石が落ちたんじゃね？ 開発プログラムでunsafeを直接使うことはほとんどない
unsafeが閉じ込められ安全なインターフェースが公開されている形で間接的にのみ用いる
どうしてもunsafeが必要になった場合でもそのように安全な形で分離して用いる 隕石であれ何であれそれがエンジニアリング可能な対象なら問題を特定して語る意味はあるだろう >>89
Dropで型がpanicする時にその要素をた用いたVec::from_iter()で二重解放のバグが発見された件か
もちろん他の言語と同様に全ての言語においてライブラリにバグが見つかることは当然ある
Rustはその点でも少ない方なので信頼して使える >>90,92
思い描く理想と現実の落差が激しいな
Rust不信の原因だぞ
とくに>>92の最後の行があるから信用されない Rustの2023年のCVEはCargoで名前をエスケープし忘れた1件のみ
Rustの2022年のCVEは0件
つまりRustコンパイラについて過去2年間でCVEなし
信頼度が高いと言える Rust以外のコンパイラってそんな言うほどバグないか？ 普通にあるけどみんなで使うから大部分はリリース前に潰される
コンパイラというよりライブラリのバグみたいだけど他の言語より未定義動作にシビアだから
バグ扱いされる事例が増えるのは仕方ない >>91
お前のとこは無限のリソースがあるのかな？
いいなぁ優先順位考えなくていい環境。うらやましいよ。 今となっては未定義動作の多い言語を使うのは悪行だ
Rustを使うべし >>82
ここの信者はテキトー過ぎるよな
コンパイラ開発チームはもとより、サーベイ回答者もコンパイラバグ潰しを最優先、が一番多い >>97
余裕があるからRustもやる、と言うのが普通だな
サーベイでも(余裕がなくなって)Rust採用予定なし、なぜなら他言語採用予定だから、が一番多い
(ただし採用にはインターンも含まれる) >>99
対処の必要があるものはその通り
しかし実害がないと皆が判断して対処優先度低いまま9年間が経過したが実害がな起きていない
そんな状況のものを杞憂したり揚げ足取りでRustを叩いてる連中がゴミ 事実を書かれただけで批判だと思っちゃうようじゃ生きづらかろうな >>101
これが矮小化と言うやつか
7割がバグ潰しを「最優先」と回答している事実
直したくても直せないまま何年も経過、unsafe無しでメモリ安全ではない(事実)、Rustの不健全仕様(事実)
(unsound=不健全は数学用語、要は矛盾があるという事)
幸運にもRustが使われなさ過ぎで実害がないように見える(または報告がないだけ)
(良心的に考えてRustが広く使われてない内に)バグ潰しをしとけ、がユーザーの9割の意見(中優先含めて)
週明けのテック記事はどう書くのかな
良い所だけ抜き出してビューが取れるハイプ期間は弱まったと思う
それと飛ばし過ぎるといなくなるorz アンチもMozillaが変なことやってるだけで
firefoxに導入できるわけがない一般人が
使えるようになるのは妄想とか
言ってた頃に比べると細かい実装の穴を
ネチネチやるまでになって大変だなあ >>103
根本的なことを理解できてないようなので一点だけ
unsafeがプログラム全体に散らばっている他の言語に対して
Rustはunsafeを局所的に閉じ込めて安全なインタフェイスを公開しそれを使ってプログラミングする言語
よく使われる基本機能は標準ライブラリとしてunsafeを閉じ込めてあるが
必要なら自作を含めてunsafeを閉じ込めたライブラリを使ってよい
他の言語と比べてunsafeを局所的に閉じ込めた部分のみ注視すればよいことがRustのメリット >>105
unsafeに閉じ込められなかった事実を提示されてるんだが何言ってるんだ？ Rustコンパイラにバグがあるのはかなりキモくて嫌だけど、Rustの利用をやめるほど致命的かというとな C++ の未定義を踏んでもおかまいなしってよりは原則として問題は検出する (けどちょっとはバグもある) Rust のほうがだいぶんマシな言語設計ではある。 unsafeなライブラリがRust用の安全なインターフェースを公開することにより保証される安全性とは
もちろん呼び出される側の安全性ではない
呼び出す側だけが検査される
しかも検査が完璧かどうかは実装依存
じゃあ言語仕様により保証されるのは何か
言語仕様は、あとは検査が通るか通らないかを確かめればよいというところまで仕様を確定しなければならない プログラム全体がunsafeなC/C++は使いたくない
未定義な動作も多すぎる >>109
Rust関係無しに基本的なことを理解できてないようだけど
掛ける情けも無し 反論できないときは関連するワードを含むRustの宣伝文句をぶつける
いつもの流れです 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」
https://news.mynavi.jp/techplus/article/20240222-2889545/ >>105,109
詐欺師みたいな偽者だな、Rust不信の種まきするのやめろ
>>112
分かっていれば支離滅裂文章なんだけど騙されるのは学生位だろうか >>前スレ992
Derefは演算子
・そのためstd::ops::Derefにある (変換std::convert::AsRefと対照的)
・演算子*によりderefされる
・&**へとcoerceされる Derefの名前の由来は*演算子（dereference：参照解決）だろうけど
機能は&**へのcoerceを前提にしてて結果的にrefのままだからややこしいな
現状だとInnerRefの方がしっくりくる 意味的にはFollowRefの方が自然かな
まあ*演算子で使われるtraitだからDerefでいいんだけど 【AI】Stable Diffusion 3発表、Soraで話題の拡散トランスフォーマーを採用 [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1708865670/l50
ボイス・トォ・スカるしている者も攻撃を受けるようになりました >>115
>・&**へとcoerceされる
これDeref Coercionのこと言ってる？ だとしたら&**に限定する意味がわからない
あと前スレ992で重要なのは&T→TはDerefの役割ではないというところね
>>116,117
スマートポインタのdereferenceのために存在するTraitだから
InnerRefやFollowRefよりDerefのほうがずっと自然だと思う
*演算子の振る舞いとは別にcoercionの振る舞いは理解しなければいけない
そういう点でも「Derefは演算子」という捉え方は良くないよ Rustて、演算子と関数を(意味論的に)区別していたっけ？
中間記法によるややこしい結合順の違いがあるぐらいで、構文解析後は等価だから、あんまりこだわっても仕方が無い気が。
中間記法の演算子は人間の算数の記法に配慮しているだけの悪習でしか無いから、積極的に差異をつけないほうが良い気がするけど。 Deref に関しては * 演算子として機能する以外に型強制の規則があるという話の文脈。 +に対するAdd, &=に対するBitAndAssignと同じ位置づけで
(*T)に対するDerefがstd::opsに入ってるイメージだけど
(*T）自体は
let x: Box<String> = Box::new(String::from("foo"));
let y: String = *x;
みたいに参照先の値を取り出す使い方ができてむしろそっちが本来の意味なのに
それができないtrait DerefがDerefを名乗ってるのが微妙だと思った >>121
サンクス。
「演算子」じゃなくて「 * (参照外し演算)」ということね。 >>116
*を明示的に付けるとdereferenceされるからDeref
&**によるcoerceは何も付けずに適用される
そのため参照から参照へ型が変わるだけで参照のままとなる
>>119
Derefはoperatorなのでstd::opsにある
Derefでも&T→Tと実装されている
Derefによるcoerceは&**となる 関数と同じでは困るものといえば && || が有名だけど = が一番やばい
初期化とか代入とかコピーとか移動とか ■ このスレッドは過去ログ倉庫に格納されています
