X



Rust part16
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2022/06/27(月) 08:17:03.45ID:gDlfKP6u
公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part15
https://mevius.5ch.net/test/read.cgi/tech/1652347700/
0002デフォルトの名無しさん2022/06/27(月) 08:18:31.94ID:gDlfKP6u
Rust The Book (日本語版)
https://doc.rust-jp.rs/book-ja/
Rust edition guide (日本語版)
https://doc.rust-jp.rs/edition-guide/
Rust by example (日本語版)
https://doc.rust-jp.rs/rust-by-example-ja/
Rust cookbook (日本語版)
https://uma0317.github.io/rust-cookbook-ja/
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
Rust nomicon book (日本語版)
https://doc.rust-jp.rs/rust-nomicon-ja/
Rust async book (日本語版)
https://async-book-ja.netlify.app/
Rust WASM book (日本語版)
https://moshg.github.io/rustwasm-book-ja/
Rust embeded book (日本語版)
https://tomoyuki-nakabayashi.github.io/book/
Rust enbeded discovery (日本語版)
https://tomoyuki-nakabayashi.github.io/discovery/
Rust Design Patterns (日本語版)
https://qiita.com/Yappii_111/items/4ccc3a8461cdd4035651
https://qiita.com/Yappii_111/items/654717e6a6a980722189
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
0003デフォルトの名無しさん2022/06/27(月) 08:20:20.52ID:gDlfKP6u
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust Reference
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
0004デフォルトの名無しさん2022/06/27(月) 08:41:06.85ID:iHSX8+Sp
☆WebAssembly(WASM) https://webassembly.org/ https://ja.m.wikipedia.org/wiki/WebAssembly
・Wasmer - The Universal WebAssembly Runtime https://wasmer.io/
-> WASI(WebAssembly System Interface)とEmscriptenに準拠したWASMを実行できるランタイム
・WAPM - WebAssembly Package Manager https://wapm.io/
-> WebAssembly製ツール/ライブラリのパッケージマネージャー
☆Rust
・wasm-pack - your favorite rust -> wasm workflow tool!
https://github.com/rustwasm/wasm-pack
-> WebAssemblyのrustcコンパイルサポート
・Yew - Rust / Wasm framework for building client web apps https://yew.rs/ja/
-> WebAssembly によってマルチスレッドな Web アプリのフロントエンドを作ることができる、モダンな Rust のフレームワーク
☆最近のWebAssemblyのニュース
・Publickey - Enterprise IT × Cloud Computing × Web Technology / Blog より https://www.publickey1.jp/programming-lang/webassembly/
・WebAssembly活用プロジェクト https://madewithwebassembly.com/
・WebAssemblyが気になるので調べてみた - Qiita https://qiita.com/t_katsumura/items/ff379aaaba6931aad1c4
・WASMとRustはVue.js/React.jsを打倒するのか? - JSへの侵略の歴史 https://zenn.dev/koduki/articles/c07db4179bb7b86086a1
・Typescriptの次はRustかもしれない https://zenn.dev/akfm/articles/81713d4c1275ac64a75c
・WebAssemblyはJVMやeBPFのリバイバルではない WasmがWeb以外でもアツい理由 - ログミーTech https://logmi.jp/tech/articles/324956
・Rust GUI の決定版! Tauri を使ってクロスプラットフォームなデスクトップアプリを作ろう https://zenn.dev/kumassy/books/6e518fe09a86b2
類似スレ
【wasm】ブラウザでC++。Emscriptenを語ろう https://mevius.5ch.net/test/read.cgi/tech/1547549448/
0005デフォルトの名無しさん2022/06/27(月) 11:22:00.27ID:KIsxDRwt
前スレにあったrustupのnamingの話だけど
もともとはサブコマンドのないシェルスクリプトでrustをupdateするからrustup

元の意味からするとrustup updateは重複表現なんだけど
rustupを動詞として捉えずツール名の名詞として捉えればrustup updateは違和感ない
0006デフォルトの名無しさん2022/06/27(月) 12:15:14.52ID:BV1DTZv2
rustupにサブコマンドがない時代なんてあったっけ?
rustupの前身のmultirustの頃からupdateサブコマンドはあったような
0008デフォルトの名無しさん2022/06/27(月) 15:34:37.88ID:hKxUT5Kw
>>6
コード的には主にmultirust.sh -> multirust.rs -> rustup.rsなんだけど
名前はrustup.shから引き継がれてる

rustup.shはサブコマンドがなかった
rustup.rsは最初からサブコマンドがあったけどrustupと叩くと今のrustup update相当の処理(update_all_channels)をしてた
0009デフォルトの名無しさん2022/06/27(月) 21:57:27.41ID:TFU41qtv
>>987
Stringを自己trimするtrim_in_place()を対称的に短く書くなら

fn trim_in_place(s: &mut String, mut f: impl FnMut(char) -> bool) {
 if let Some(end) = s.rfind(|c| !f(c)) {
  let end = s.ceil_char_boundary(end + 1);
  s.truncate(end);
 }
 if let Some(start) = s.find(|c| !f(c)) {
  s.drain(..start);
 }
}

たとえわずかでも先にendを処理
fは char::is_whitespace など

ただし目的外使用なので長くなるけど置き換え
s.drain(..start);

s.replace_range(..start, "");

こちらはunstableなので長くなるけど置き換え
let end = s.ceil_char_boundary(end + 1);

let end = ((end + 1)..).filter(|&i| s.is_char_boundary(i)).next().unwrap();

ここでendはrfind()で発見済なのでend + 1でunwrap()可能
0014デフォルトの名無しさん2022/06/28(火) 16:03:15.75ID:ucMrCo9H
リーナスに認められて良かったな
0019デフォルトの名無しさん2022/06/28(火) 20:32:29.27ID:+JjrPLHw
Rust is coming to Linux, says Torvalds
https://cloud7.news/linux/rust-is-coming-to-linux-says-torvalds/

Linus Torvalds also announced some changes he plans to implement into Linux soon.
Most significantly, the open-source programming language, Rust might be included in the next release.
Torvalds stated that Rust will be introduced in a limited way.

Torvalds reminded the attempt to introduce the C++ programming language 25 years ago, which didn’t go as expected.
Compared to C, Rust is better at utilizing and protecting resources.
0021デフォルトの名無しさん2022/06/28(火) 21:09:24.12ID:20pFpWMa
既に安定して動いているカーネル本体からスタートするのは非効率たから
新たに増えていくデバドラなどからRust導入
そしてRust>C>C++と評価されたことも大きい
0022デフォルトの名無しさん2022/06/28(火) 21:14:03.79ID:nuii8/Ul
ドライバだとunsafe祭りになると思うけど、それでもRust活かせるのかな
0023デフォルトの名無しさん2022/06/28(火) 21:23:20.31ID:20pFpWMa
Rustは標準ライブラリからしてunsafeだらけ
Rustのメリットはunsafe部分を局所的に閉じ込めることができること (他言語は全てがunsafe状態)
そして局所的に閉じ込めた部分の健全性を人間が確保すればプログラム全体の健全性がコンパイラにより保証されること
0024デフォルトの名無しさん2022/06/28(火) 23:19:05.36ID:9UGNj1/z
C だとどこが「安全ではない」のかわからん。
unsafe がはっきりと切り離せる分だけ多少はマシ。
0025デフォルトの名無しさん2022/06/28(火) 23:21:02.37ID:UTlbkk5U
>>18
おい荒らすな
0027デフォルトの名無しさん2022/06/28(火) 23:54:54.04ID:GLoxI7Da
Cたけでなくほとんとのプログラミング言語がデータ競合を見過ごす、あるいは、対応しても実行時にようやく気付いてエラー
Rustのようにコンパイル時エラーとしてくれるのはレア
0028デフォルトの名無しさん2022/06/28(火) 23:59:16.02ID:ZKoUX8TI
>>18
あわしろは巣に帰れ。
0029デフォルトの名無しさん2022/06/29(水) 04:43:12.90ID:wTdKgESK
結局allocを用意して、Resultを返すような別方言のRustを作っただけじゃん。こんなんでええのかよ、糞言語
0032デフォルトの名無しさん2022/06/29(水) 09:48:50.80ID:0DT3duzl
mallocに失敗してパニックするかどうかは最終的にどうやって切り替える仕様になるわけ?
Cargo.tomlに書くとか?
0033デフォルトの名無しさん2022/06/29(水) 10:00:12.87ID:RxSbHfnw
>>32
全体が一気に切り替わるようなのは多分想定されてない
Resultを返すAPIが追加される感じ
例えばtry_reserveなんかはnightlyでは実装済み
0034デフォルトの名無しさん2022/06/29(水) 10:29:37.35ID:o1jl8+0D
話としては二段階あるんだよね

一つは昔からのcore::つまりいわゆるno std::環境
つまりヒープは標準ライブラリとして提供しない
BoxやVecやStringなどのヒープ利用以外はイテレータ含めて全て使える
ヒープは自分で管理するかそういうクレイトを使う

もう一つがstd::からのalloc::の分離
BoxやVecやStringは現在ここにある
Box::try_new()やVec::try_reserve()やString::try_reserve()を使ってアロケーション時のエラーを得ることも可能

この理解でよい?
0035デフォルトの名無しさん2022/06/29(水) 12:52:13.13ID:FmyetX4I
>>33
try_reserveは1.57でstabilizeされてる

>>34
core::もalloc::もno_std用


一部コレクションのtry系メソッド以外はどういう形にするか明確な方針は決まってないんじゃないかな
Allocatorトレイトをstabilizeしていく方向は決まってるだろうけど
それを使った上位のAPIがどういう風になるかはわからない
0038デフォルトの名無しさん2022/06/29(水) 17:53:19.15ID:2Zsw8Y9r
>>30 >>31
顔真っ赤www
0039デフォルトの名無しさん2022/06/29(水) 18:28:59.03ID:wO7vqP7J
>>31みたいなレスしちゃった時点で負けなんだが本人が歳だけ食ってメンタル10代のこどおじだから面倒臭いんだよな

>>29
何と戦ってるの?

こんなのよくある問い詰められて二の句が告げなくて『なにが?』とか『なんのこと?』ってはぐらかしてる馬鹿なおっさんそのものなんだが本人気付いてないんだろうなw
0041デフォルトの名無しさん2022/06/29(水) 19:27:35.51ID:IsSV4hIQ
いずれにせよ
ベアメタルなどの組み込みやOS開発向けがほとんどの用途
それ以外の影響なし普通の人々にとっては今まで通り
0045デフォルトの名無しさん2022/06/29(水) 21:48:58.34ID:RzXMGtd7
質問失礼します。
初心者なので当たり前の事質問してたらすみません。
風化対策でTCを置くのは理解してTCを拠点内においてそのすぐ1マス開けて横にもう一個建築物を建てたのですが
そっちだけ風化してしまって崩れてました。これは何が原因なのでしょうか。
0048デフォルトの名無しさん2022/06/29(水) 22:10:07.93ID:RzXMGtd7
なるほど…どおりで皆が何いってるかがまったく理解できなかったわけですね。
自分が初心者だからだと思ってました。凄い恥ずかしいです。リンクまでありがとうございます!
0051デフォルトの名無しさん2022/06/30(木) 08:24:56.17ID:cp0D79F2
Twitterで
ゲームのRustと紛らわしいからググラビリティがどうこう、いうツイートがかなりあるけど
それらのツイートがなければかなり検索楽になるから止めてほしい
0052デフォルトの名無しさん2022/06/30(木) 08:29:33.75ID:M3oLoiTd
redditは確かあまりにゲームの書き込み多いからスクリプトでそれっぽいキーワード弾いてるんじゃなかったっけ?
今でもときどき書かれてはいるけど
0054デフォルトの名無しさん2022/07/01(金) 00:25:37.32ID:ESXQaW+s
>>53
Web系は時期にWebAssemblyが超使われるようになるだろう。
そうなるとWeb系の人はRustできないとWeb系の仕事ができないとなるから
嫌でも覚えるしかないだろうな。
そんな状況になるとRustはWebAssemblyのためのものって感じなるだろう
0055デフォルトの名無しさん2022/07/01(金) 01:05:48.97ID:QsJqZKbw
ないないウェブはどんどん移り変わるツールチェインのトレンド追い続けるだけだからwasmやrustが大人気になってメインになることは100%ない
0056デフォルトの名無しさん2022/07/01(金) 01:20:55.79ID:TBvdgDV9
かと言って組み込みも今動いているCコードをわざわざ書き換えることはないと思うからかなり先かな
0058デフォルトの名無しさん2022/07/01(金) 03:03:39.63ID:2xG+zSps
そりゃMSですらRustに可能性を感じてWindowsのコアコンポーネントをRustで書き換えたりしてるけどだからと言ってC++がお役御免になるなんて考えちゃう奴はどうかしてるというかにわかの馬鹿かポジショントークのどちらかだよ
0059デフォルトの名無しさん2022/07/01(金) 03:09:52.32ID:iXSnlIKp
まぁこの20〜25年ずっとウェブはJS、デスクトップ・モバイルはJAVAだから何も変わってないんだよ現実はそんなものさ
0060デフォルトの名無しさん2022/07/01(金) 03:32:40.77ID:pCpAVMfP
どこでも同じシンプルな結論が出ている
・既存のものを書き換えるのは無意味
・新たに作るものはRust 一択
0061デフォルトの名無しさん2022/07/01(金) 10:02:10.38ID:fTPBYdla
USの状況見るとRustが広く使われるようになるのはもう疑う余地ないと思ってるけど
ここまで世の中の現実を知らない人がRustを推してるのを見ると悲しくなる
0062デフォルトの名無しさん2022/07/01(金) 11:50:32.58ID:7FVP6Hci
C は使われる範囲が広すぎた。
JavaScript は使われる範囲が広すぎた。
必ずしもベストではない場面でも使われ過ぎた。
そういった「過剰に使われている状況」が改善されていくってだけだろう。

現状がベストならあえて変更する必要はない。
0063デフォルトの名無しさん2022/07/01(金) 13:17:28.43ID:T/nKI+TL
5chに限らずネットだと言語だなんだドヤ顔で蘊蓄垂れてイキリ散らかしてる奴ばかりだがGoogleに腐るほど日本人、まともなアプリの開発できないとネタにされるくらいソフトウェア後進国のIT土人国家なのオチが綺麗過ぎて爆笑してしまう
このスレでも結局オチはエロゲっていうクソみたいなセンスのキチガイしかいないからなお前らがRust推すほどこりゃダメだって思うわ
0065デフォルトの名無しさん2022/07/01(金) 13:37:31.87ID:fF+Ny/hr
C/C++よりコンパクトに機能が高く書きやすいからRustを使っている
他の言語は遅くて論外
0066デフォルトの名無しさん2022/07/01(金) 13:42:34.60ID:UdT3FWB5
JSをサーバーサイドに使うのはどうなんかね?
速さは性能やらCDNでごまかせるけど、RUSTやC++とかで出来るならそっちのほうが良さそうな気がする

まあPHP使ってる雑魚だから現状関係ないけど
0067デフォルトの名無しさん2022/07/01(金) 14:03:44.85ID:8rqDa7Vf
用途や状況に合わせて言語は使い分ければいい
ひとくちにWebと言っても用途も状況も様々
0068デフォルトの名無しさん2022/07/01(金) 14:14:38.28ID:EeNr3/+w
RustRust言うけどこのスレの人間たちもRustでは一日1000行もコード書いてないだろ
0069デフォルトの名無しさん2022/07/01(金) 14:44:33.26ID:7FVP6Hci
>>66
ウェブの表層のほとんどは「ビジネスロジックの記述」をやりたい。
Rust や C++ は良くも悪くも機械に対する指示としての側面が大きい。
ビジネスと機械の間を埋めるのがエンジニアの役割ではあるんだが、
ビジネス寄りのエンジニアとガチ技術寄りのエンジニアで棲み分けが有る。

もちろん何だって速いに越したことは無いが、
ソフトウェアをガチガチにチューニングしたって限界があるからなぁ。
頑張ってソフトウェアをチューニングしてもせいぜい二倍とか三倍とか程度にしか伸びん。
ビジネスが拡大すれば再現なく高い性能が要る (可能性が有る) わけで、
必要なときに機械の数を倍にすれば倍の性能になるデザインのほうが重要なんだよ。
0070デフォルトの名無しさん2022/07/01(金) 15:16:38.49ID:5qHSWxfW
俺は楽だからwebも含めて大抵はrustで書いてるな
0071デフォルトの名無しさん2022/07/01(金) 15:59:50.99ID:6Fa4fCYf
こちらはまずはバックエンドとスクレーパー方面だけRust化した
フロントエンドはこれから
0072デフォルトの名無しさん2022/07/01(金) 16:39:02.14ID:aPWs3jPS
お前らは日本人あるあるで手段と目的を履き違えてる奴ばかりなんだよ
御宅を並べるのは中国にすら20年遅れてしまったソフトウェア分野で結果出してからやれお前らみたいなの逆に迷惑
ウェブつながりのつい最近の話でNode-Sass(LibSass)が非推奨になりDart-Sassになった理由は色々言われているが要はC++でsassの実装は極めて難しくLibSassをメンテする・できるボランティアがいなくなったからなわけで
じゃあお前らご自慢のRustでLibSass書き直せよ?お前らなら余裕だろ?結果出してくれよ?
お前らみたいにネットのコメントだけでイキってる奴らって最高にダサい
0074デフォルトの名無しさん2022/07/01(金) 18:22:07.89ID:coxy+5j4
ドキュメント読む限りでは
Rustは他のRustプログラムと同様にgdb/lldb
jsはWebViewのデバッガを利用することになるようだが
0075デフォルトの名無しさん2022/07/01(金) 20:10:55.31ID:85aMWYB4
>>73
公式ドキュメントの方法じゃないけどVSCodeのrust-analyzer使えばlaunch.jsonやtasks.json書かなくても簡単にRustのデバッグできるよ
UIは実行後のウィンドウでCtrl+Shift+iでWebView Consoleが開くからconsole.logはこっちのコンソールで確認できる
ただUIのjsのブレークがうまくいかないからこっちは俺が教えてほしい
0076デフォルトの名無しさん2022/07/01(金) 20:21:51.18ID:EeNr3/+w
出来ても結局自分でライブラリ類は書かなきゃ行けないんでしょ?
jsの大量のライブラリが使えるならいいんだけど
0078デフォルトの名無しさん2022/07/02(土) 00:08:31.01ID:AmkG6Kqz
>>68
>Rustでは一日1000行もコード書いてないだろ
日本のITの主力のドカタ向けのRustの仕事はまだほとんどないだろうからな。
だから、いまRustしている奴の多くは個人の趣味でRustしている感じだろうし。
俺的にはRustを使った社内システムの開発とかやっているレベルで激すごいなって思う
Rustがメジャーになれば受注案件でRustも使うってなるんだろうが
0079デフォルトの名無しさん2022/07/02(土) 02:58:41.46ID:e9/H958U
現実を直視できないアホばっか
Rustの案件なんてあるわけないだろ都内ですらC++のドライバ開発で人材集めるの相当苦労するのにRustでプロダクションクオリティで書けるPGがいたとして名抜きの奴隷なんてやるわけない
だからそんなプロジェクトはないし案件が発注されることもない
0080デフォルトの名無しさん2022/07/02(土) 06:04:06.91ID:snCDtfbl
なるほどRustを叩いているのは受注土方だったんだな
こちらは自社開発だから便利で安全で高速なRustを普通に採用できている
0081デフォルトの名無しさん2022/07/02(土) 07:01:32.45ID:rBgXmnU4
ローカルなツールを自分一人でシコシコ作ってるってパターンだろw
0083デフォルトの名無しさん2022/07/02(土) 08:15:05.98ID:BolvizBW
現実にRust利用がどんどん広がっていってる現状に嫉妬してるおまえらはRustアンチスレの方へ行けよ
0085デフォルトの名無しさん2022/07/02(土) 09:49:00.17ID:HrEq3hU6
自社開発製品
・FizzBuzzイテレータ
・カウントアップイテレータ
・フィボナッチイテレータ

当社製品はすべてジェネリック対応
型の最大値を超えると自動的にイテレート終了
Rust製で安心安全高速!
5ちゃんねるユーザー大絶賛!!
「所有権複製論」の複オジ先生自ら開発!!!
0087デフォルトの名無しさん2022/07/02(土) 12:45:33.26ID:yGSrF2fX
このRustアンチ
いつも不利になると作り出した仮想敵叩きへと逃げ込むな
0091デフォルトの名無しさん2022/07/02(土) 18:21:13.38ID:2aQtTORk
自演自画自賛してたから
大絶賛でも間違いではない

いや、間違いか
0093デフォルトの名無しさん2022/07/02(土) 19:02:42.47ID:9mM8C95j
>>88
Wasmで、DOM直書きできるのは、今のところRustしかないことが
いまのWasmを書く際のRust人気になってるようだ。
しかし、今後、ライブラリの中にDOM操作を隠蔽できてしまえば、
ライブラリを使う限り自分でDOM操作はしなくて良くなるからDOM直書きは
不要になる。
0096デフォルトの名無しさん2022/07/03(日) 00:47:23.25ID:dzYoxo9e
>>95
現段階でWasmを使おうとしている人の大部分は、
「WebプログラミングはHTMLとDOM操作で行うもの」
という固定観念があるので、それが直接的に出来るRustを使おうとしていると
言うことだ。
しかし、DOM操作を関数の中に閉じ込めてしまえば、DOM操作と言う概念を
一切合財忘れてしまって、Windowsプログラミングのような手法でWeb
プログラミングできるようになる。
0097デフォルトの名無しさん2022/07/03(日) 00:47:34.21ID:dzYoxo9e
>>95
現段階でWasmを使おうとしている人の大部分は、
「WebプログラミングはHTMLとDOM操作で行うもの」
という固定観念があるので、それが直接的に出来るRustを使おうとしていると
言うことだ。
しかし、DOM操作を関数の中に閉じ込めてしまえば、DOM操作と言う概念を
一切合財忘れてしまって、Windowsプログラミングのような手法でWeb
プログラミングできるようになる。
0098デフォルトの名無しさん2022/07/03(日) 00:49:19.63ID:dzYoxo9e
>>97
いったんそうなってしまうと、WebプログラミングにDOM操作が全く必要なく
なってしまうので、WasmにおけるRustのアドバンテージが消失してしまう
可能性が高い。
0099デフォルトの名無しさん2022/07/03(日) 01:58:58.46ID:HrPxrbHk
rustでもDOM操作はJS経由してるし直接的にできるわけではないでしょ
wasmでrustが有利とされているのはランタイムが薄くてバイナリサイズが小さくできる点では
0100デフォルトの名無しさん2022/07/03(日) 02:21:32.37ID:dzYoxo9e
>>99
そもそもJSの時点で速度に不満の有る人がどれだけいることか、という点がある。
C++なら既存の資産もあるし、nativeアプリと互換性を持たせることが出来る
メリットもあるが、Rustにはない。
0101デフォルトの名無しさん2022/07/03(日) 02:21:34.94ID:dzYoxo9e
>>99
そもそもJSの時点で速度に不満の有る人がどれだけいることか、という点がある。
C++なら既存の資産もあるし、nativeアプリと互換性を持たせることが出来る
メリットもあるが、Rustにはない。
0102デフォルトの名無しさん2022/07/03(日) 02:26:10.32ID:dzYoxo9e
twitterを見ていると、Rust派の人は、JSより高速になることをメリットと考えている
ようだが、JS自体がもともと結構速いので、多くの用途では実際にはほとんど
体感速度は高速にはならない。
なので、Wasmの意味が無い、用途が無い、という結論に至ってしまう。
これはそもそも、Wasmが作られた経緯を無視しているから。
WasmはC++をブラウザで使いたい、という事から始まったもの。
EmscriptenでC++をasm.js化していたものが、それをさらに効率よくするために
生み出された。
だから、もともとJSを高速化したいことが目的ではなく、C++を使うことが
目的だった。
Rustでは駄目なのだ。Rustでやろうとするから、そもそも論に陥る。
そもそも、そんなに高速にする意味があるのか、という。
0103デフォルトの名無しさん2022/07/03(日) 02:29:04.40ID:dzYoxo9e
Rustはメンドクサイのだ。
だから、「そこまでして高速にする必要があるのか」という疑問に至る。
ところが、C++はRustほどはめんどくさくない。
普通に直感的に書いたものが、JSの5倍程度の速さを安定してたたき出す。
なので、C++で書くと楽なので意味があるが、Rustはめんどくさいので意味が無い、
ということになり、Wasm不要論へと繋がっていく。
しかしそれは、Rustを使おうとしたことがそもそも間違いなのだ。
0104デフォルトの名無しさん2022/07/03(日) 03:29:33.96ID:IpMp4A6f
てか明らかにvueもreactもいじったことない奴が騒いでるだけだろ。
まともに相手するだけ無駄だわ。
0105デフォルトの名無しさん2022/07/03(日) 03:50:27.37ID:A6Umne1m
世界中のIT技術者から愛されているプログラミング言語はなにか。
プログラミング関連のQ&Aサイト「Stack Overflow」を運営する米Stack Exchangeがそのような調査結果を発表した。
各言語の「Loved」(愛している)と「Dreaded」(恐れている)の比率でLovedが最も高かったのは「Rust」(86.73%)で7年連続で1位になった。
回答数は7万1467件。
https://www.itmedia.co.jp/news/articles/2206/24/news128.html
0107デフォルトの名無しさん2022/07/03(日) 07:40:44.40ID:xnM4EaFU
そりゃそうなるわな
既存のメンテ以外ではC++で書くことはない
時間とともにRust一色となるだろう
0108デフォルトの名無しさん2022/07/03(日) 08:33:17.69ID:tt1RzXNI
Rustは圧倒的にコーティングしやすい
様々な近代的なパラダイムを洗練して採り入れたことが大きい
メモリ解放も完全自動で気にしなくていいのにC並に高速というオマケ付き
0112デフォルトの名無しさん2022/07/03(日) 11:37:22.22ID:BkE0C3wS
煩雑。
参照でツリーが作れない。
リンクリストが本来の性能を引き出せない。
0113デフォルトの名無しさん2022/07/03(日) 11:38:06.57ID:BkE0C3wS
これらのRustの問題点は、教授レベルでも理解出来てない人が多い。
0114デフォルトの名無しさん2022/07/03(日) 11:48:29.39ID:xlXEUxdt
教授レベル?!

複オジ大先生 vs 数学100点大先生のやり取りはいつもいつも有意義有意義ww
0115デフォルトの名無しさん2022/07/03(日) 12:04:57.77ID:0zvrEFac
今日日曜だけどつまらない書き込みしてんじゃないぞ

一日最低1000行書かないとレスしたらダメだぞ
0116デフォルトの名無しさん2022/07/03(日) 12:06:35.28ID:0zvrEFac
ライフタイムがらみで一日なんどかキーボードかマウスを投げたくなる
自動で判定しろよ
0117デフォルトの名無しさん2022/07/03(日) 12:53:49.06ID:E6Fi7aBt
>>116
そんな悩むようなことか?
そこまで酷いのは何か基本理解の欠如があるのではないか
簡単な具体例を出すことを勧める
0118デフォルトの名無しさん2022/07/03(日) 13:33:15.09ID:/eA4inlP
オブジェクトの寿命に関するルールは実際には C++ とそれほど差が無い。
厳密に検証するということと、検証に必要なちょっとしたアノテーションが必要ってだけ。
0119デフォルトの名無しさん2022/07/03(日) 14:26:00.76ID:HrPxrbHk
1000行書くという謎の目標にこだわってるからライフタイムの理解がおろそかになってるのでは
エラーが出るたびに原因をしっかり調べれば同じ過ちを何度も繰り返すことはなくなるでしょ
0120デフォルトの名無しさん2022/07/03(日) 14:38:47.08ID:Tm7q4JxH
登大遊は凡人レベルのコードでいいなら1日1万行は余裕で書けるって豪語してて草生えたな
一時期は天才少年プログラマーと持て囃されてた彼も所詮日本の凡才駄プログラマーだったな
彼を見てるとわかるが日本人は手段にこだわって目的を達成できずに結果残せないないアホばかりなんよ
SNSやナレッジコミュニティやオフ会でドヤ顔で偉そうに蘊蓄たれてイキリ散らかしてるやつばかりなのって要するに日本の終わってるゼネコンビジネスIT業界で楽しみを見出せる要素がそこしかないからなんだってことよ
如何に日本のプログラマーがゴミで哀れな奴らかわかる
0121デフォルトの名無しさん2022/07/03(日) 15:03:07.11ID:E6Fi7aBt
そもそもコードを書く時間よりもその
コードのリファクタリングなどの時間の方が多い
そしてリファクタリングでは行数は減る方向が多い
書く行数の多さを気にするのは質ベースより量ベースの典型的なダメパターン
0122デフォルトの名無しさん2022/07/03(日) 15:32:59.76ID:EctOodKi
普通にプログラミングするには問題ない程度にライフタイムを理解した上でも、
Rustには沢山の欠点が有り、ライフタイムをこれ以上理解しても、それは
解決しないと思ってる。
なぜなら言語そのものが持つ欠点だから。
0123デフォルトの名無しさん2022/07/03(日) 16:05:52.40ID:/eA4inlP
それはそう。
足りない諸々は unsafe でやれ (プログラマが正しさを保証しろ) というデザインであって、全部を面倒見れるとは誰も思ってないよ。
0126デフォルトの名無しさん2022/07/03(日) 17:03:35.61ID:EctOodKi
>>123
しかし、Rustの方式では、ある種のアルゴリズムは、unsafe の中だけに
閉じ込めきれないことがあり、結局、アプリでそのアルゴリズムを本来の
効率では使えないことがある。
これも言ってることを理解するには経験と深いイマジネーションが必要なので
反論してくる人が居てもその反論が間違いで、Rustの欠点として本当に存在
している。
昔、C言語が登場した頃、アセンブラほどには速度を引き出せ無い事が有ったが、
大事な部分の関数をアセンブリコードで書けばそれで解決した。だから、
C言語がこんなに普及した。
ところが、Rustでは、それと同じ事が出来ない。
unsafeの中だけに閉じ込めきれず、「はみ出してくる」部分がsafeに扱えないので破綻してしまう。
0127デフォルトの名無しさん2022/07/03(日) 18:00:07.94ID:K4HcDkkQ
具体性の欠片もないフワフワした話しかできないんなら黙ってりゃいいのにw
0128デフォルトの名無しさん2022/07/03(日) 21:50:25.68ID:HrPxrbHk
linked listの人の完全論破されたら潜伏してほとぼりが冷めてから全く同じ主張を繰り返すムーブ何回目だよ
0129デフォルトの名無しさん2022/07/03(日) 22:08:21.67ID:tiLDs1XL
>>126
具体的なことを何一つ言えない時点で話にすらならないが
一つ重要なアドバイスをしてあげよう

unsafeとは他の言語と同じ状態ということ
つまりunsafeについて批判すればするほどそれはRust以外の言語がいかにダメなのかを語っていることになる

ちなみにRustはunsafeの中でC言語と同じことができるしもちろんインラインアセンブラも書ける
つまりRustはC言語と同じ機能及び性能を有している側面がまず第一としてある

その上で外部を巻き込むことなくunsafeな部分を内部に完全に閉じ込めた各モジュール例えば標準ライブラリなどを次々と生み出すことにも成功している
そしてRustコンパイラが安全性を保証するプログラムを現実に書くことができることを実証してきた
だからこそIT大手各社が共同でRustを支持する状況にまでなったのだ
0131デフォルトの名無しさん2022/07/03(日) 23:17:08.11ID:x9P0i8er
なんか違うというレベルじゃなく一番大事なところが間違ってるよ
0132デフォルトの名無しさん2022/07/03(日) 23:41:56.43ID:ha/kcOac
このスレでよく見かけるパターン
Rustアンチな人は不利になると「なんか違う」「間違ってる」など呟くが具体的には何も言えない
0133デフォルトの名無しさん2022/07/03(日) 23:48:10.53ID:uYnkpWRD
このスレじゃなくて5chすべてがそうなんだよ馬鹿www
こんな便所の落書きにすら劣るキチガイの巣窟で正論打っても意味ねーんだよ
こいつらはこいつら自身が一番嫌いなDQNやチンピラと同じ大いなる無駄なことして暇つぶしてるガイジどもなんだよwww
0135デフォルトの名無しさん2022/07/04(月) 00:48:50.97ID:H2jYU4qp
cと同じに欠けるってのは明らかに嘘だろ。メモリモデルが違いすぎるっつーの。
0139デフォルトの名無しさん2022/07/04(月) 03:21:25.34ID:zU5p2DDn
>>135
「メモリモデル」という言い方は、PC-9801のような16BIT MS-DOS時代に
別の意味で使っていたから混乱を招くが、言いたいことは分かる。
0142デフォルトの名無しさん2022/07/04(月) 09:03:48.35ID:tfDB1jS/
>>138
そんな真面目な用語じゃなくて
プログラマがメモリに対して持つメンタルモデルとかそのくらいの意味ではないかと思われる
0144デフォルトの名無しさん2022/07/04(月) 09:24:13.06ID:WMds9h9Q
>>142
そのレベルの話だとしてもスタックやヒープの使い方はrustもcも同じだよね
何をもって違いすぎると言っているのかがわからん
0145デフォルトの名無しさん2022/07/04(月) 11:11:40.91ID:1aJxC781
>>129
>unsafeとは他の言語と同じ状態ということ
unsafeでもRust特有のメリットもあればデメリットもある
特にC/C++とは担保されてるsafetyのレベルが根本的に違うので「unsafeなら他の言語と同じ」とか言ってる人はunsafeをまるで理解してないので騙されないように
0146デフォルトの名無しさん2022/07/04(月) 11:57:37.00ID:DrP+xMl0
そこはあまり本質的じゃないな
Rustは機能的にも速度的にもC言語の代替となれる点が本質だろう
そのうえでRustは非常に大きなプラスαがあるからC/C++は不要となった
0147デフォルトの名無しさん2022/07/04(月) 12:04:57.14ID:RBYxpWsA
Rustの側で書き換えないから
let a=99;
とかした奴をCに渡してC側で書き換えるのってアウトだよね?
0150デフォルトの名無しさん2022/07/04(月) 12:48:07.99ID:RggUqH9I
Rustの登場でC/C++が要らなくなったのは当然

>>147
まずはRustの初歩を学習必須
Rustではlet mut a = 99; とmutを指定すればその変数が書き替え可能
呼び出し先で書き替えたいならば
まずRustの関数を呼び出す時は &mut a と可変参照を渡せば呼び出し先で書き替え可能
Cの関数を呼び出す時はそれを *mut とポインタにして渡せば呼び出し先で書き替え可能
0151デフォルトの名無しさん2022/07/04(月) 12:51:14.14ID:iNsmlcex
>>146
全てunsafeにでもしない限り、効率を落とさずには代替になれない例が有ると言っている。
ポインタ値をアプリ全体でLinkedListのノードを識別するための id 値として
利用している場合だ。
index 番号では効率が劇的に下がるケースが多い。
0152デフォルトの名無しさん2022/07/04(月) 13:07:11.60ID:EPYowFm9
>>151
その件に限らず全てのケースで以下が成立する
基本事項: RustではCと同じ速度&同じ安全度で常に全ての実装が可能
追加事項: RustではCと同じ速度&完全に安全なインタフェースで多くの実装が可能
したがってCが不要となったとの話はもちろん正しい
0155デフォルトの名無しさん2022/07/04(月) 13:39:33.82ID:Lyc/Sj1E
>>153
それはmut宣言していない変数を(先のC関数もしくはRust unsafeで)書き換えてしまうことになるためあまりよろしくない
書き替えるならばmut変数のmut参照を直接*mutにした方が良いのでは
let mut a: 型名 = 初期値;
c_func( & mut a as *mut _ )

>>154
それは>>152で正しい
0156デフォルトの名無しさん2022/07/04(月) 13:43:31.17ID:NdI05vlq
すべての言語にunsafeがあればいいよね
0158デフォルトの名無しさん2022/07/04(月) 14:07:26.39ID:V2xsx4Ai
>>147
FFI呼び出しに要求されるsafetyを満たしてないと言う意味ではアウトだけどそれがどうかした?
0159デフォルトの名無しさん2022/07/04(月) 14:13:33.00ID:hjCO09br
まーた複オジ vs 100点オジの低レベルな言い争いになってるから
隔離スレ復活させたほうがいいな
0164デフォルトの名無しさん2022/07/04(月) 18:07:12.10ID:3k8jHKP2
> 全てunsafeにでもしない限り

誰も問題にしてないところを勝手に取り上げるのはストローマン論法っていうんだぜ!
0165デフォルトの名無しさん2022/07/04(月) 18:46:54.41ID:tF6z07pc
>>151
なにを問題にしてるのかよくわからんが必要なら全てunsafeにすればいいやん
それでもCとかと同じでそれ以外のケースではRustの方がより安全なんだし
0166デフォルトの名無しさん2022/07/04(月) 19:49:32.85ID:FTPm+Svf
リーナスがこのスレを見ていたらLinuxに採用されることはなかっただろうね
0169デフォルトの名無しさん2022/07/04(月) 20:06:09.66ID:WMds9h9Q
メンタルモデルってプログラマー界隈ではよく知られた言葉だと思ってたんだけど通じない人もいるのね
0170デフォルトの名無しさん2022/07/04(月) 20:26:03.13ID:rP4GYYNg
プログラマー界隈で言ってる奴を見たことないしそもそも違い云々の時にそんなもん出されても困惑するだけ
0172デフォルトの名無しさん2022/07/04(月) 21:09:07.84ID:LgYZqAbq
>>169
自分の周りでも普通に通じるけど、よく考えるとどこで知った用語か謎かも…
なんか有名なプログラミング系の本とかに書いてあったっけ?
0173デフォルトの名無しさん2022/07/04(月) 21:22:26.69ID:k0bSAJLz
適当な造語をさも常識のように語るのはやめようね
そもそもそんな言葉使わなければいい話
0174デフォルトの名無しさん2022/07/04(月) 21:31:48.17ID:rrB3dRAB
>>172
プログラミングのコンテキストでよく使われるようになったのはUI/UXデザイン分野でよく使われてたからじゃないかな
ドン・ノーマンの「誰のためのデザイン?」とかかなり昔の本から使われてるよ
0175デフォルトの名無しさん2022/07/04(月) 21:34:43.82ID:tfDB1jS/
そもそも拾う必要すら無かったレスを拾ったばっかりによく分からん論争に
なんかすんませんな
0177デフォルトの名無しさん2022/07/04(月) 21:44:59.75ID:Xyf5Vl2i
複オジ大先生がそんな言葉ないとおっしゃってるんだぞ!
スーパー自宅開発者の複オジ大先生が間違ってるとでも言うのか!!
0180デフォルトの名無しさん2022/07/05(火) 04:52:44.77ID:86ZbPeAT
だから
> ポインタ値をアプリ全体でLinkedListのノードを識別するための id 値として利用している場合だ。
の場合だけだろ
お前はそんな特殊なアプリしか作らないのかよw
そもそもノードの識別を全体にばらまいてるとか設計がタコなんじゃね?
0181デフォルトの名無しさん2022/07/05(火) 05:08:33.40ID:WHTTcdQX
>>180
RubyやJava、オブジェクトの「識別番号」が取得できることがあるが、
それはポインタ値だ。通し番号ではない。
つまり、C言語では伝統的に、リンクトリストのノードを識別するために
ポインタ値が使われている。そしてそれこそがリンクリストの本来の使い方。
だれかが間違えて、通し番号で識別する習慣が生まれてしまったが、それは
集団幻覚みたいなもので、誤った使い方だ。
0182デフォルトの名無しさん2022/07/05(火) 05:22:06.16ID:b2cot2gP
で、何が言いたいんだ?
Linked Listをアプリ全体にばらまいてるアホ設計を正当化しようとしてるのか?w
0185デフォルトの名無しさん2022/07/05(火) 07:54:16.72ID:n+I8xvZo
>>181
GC言語では、ポインタと言ってもコストの高いポインタとなっていて、コストの高いガベージコレクションで回収する。
それに加えて、データ競合を防ぐには更に何らかの競合回避コストも加わってくる。

一方で、C/C++ではリンクされたノードリストからノードを外す時に、そのライブラリがノードを解放してしまうと、そこへのポインタを保持していた場合にダングリング発生。
それを回避するためにはshared_ptrなどのコストの高いポインタを使わざるを得ない。
ちなみにC++のshared_ptrはスレッドセーフだからマルチスレッド時でも大丈夫だが、逆に言えばシングルスレッド時には無駄なコストがかかっている。

Rustでは、そこはRcとArcの2種類が提供されており、シングルスレッド時にはコストの低いRc使用、マルチスレッド時にはRcだとコンパイルエラーとなってくれてArc使用と、最小限のコストで済む。
このようにノード解放の観点だけ見ても、考慮すべきことをRustコンパイラは適切に指摘してくれる。
0188デフォルトの名無しさん2022/07/05(火) 11:28:42.85ID:UQspXvq+
>>182
C言語が速い秘密はLinkedListとそのノードをアプリ全体でポインタ値で識別している
ことにある。先頭を0として1,2,3と割り振った通し番号を使っていたと
したら、全然速度が出ない。
そしてその証拠が、JavaやRubyなどで「識別番号」が8桁の16進数で表示できる
ことだ。その識別番号とは生ポインタ値のことであり、それがそのオブジェクトを
唯一に特定できる最も効率的な方法である。
他の方法では効率が落ちる。
0189デフォルトの名無しさん2022/07/05(火) 11:29:55.08ID:UQspXvq+
>>185
あなたは、理解が浅い。
RustのRcやArcには欠陥がある。
そんなもので済むならとっくにCやC++でも採用されている。
C/C++の歴史の長さを舐めてはいけない。
0190デフォルトの名無しさん2022/07/05(火) 12:22:07.18ID:KaO4bask
>>188
同じ話を何度も繰り返すなよ、ボケ爺か?
そうであってもそのアプリがCと同じでそれ以外のアプリならRustの方が安全って書いてあるだろ
0192デフォルトの名無しさん2022/07/05(火) 12:32:52.81ID:84q7aSs+
えっ、なにか説明が欲しかったのか?
スレ読んでりゃわかると思うがw
0193デフォルトの名無しさん2022/07/05(火) 13:04:52.14ID:n+I8xvZo
>>189
欠陥があると主張するならば、その理由を示さなければならない。
さらにC++でも採用されていることを知らないのは無知ではないか?
C++のshared_ptr = RustのArc = SwiftのARC が同じ機能であり、スレッドセーフなリファレンスカウンタ利用の共有ポインタ方式。
それらのスレッドセーフでないコストの安いバージョンがRustのRcである。
これらは、安全にポインタを共有しつつ即時解放を行なうために、必須の機能である。
0195デフォルトの名無しさん2022/07/05(火) 13:19:57.09ID:MoDZ63yv
ラスタシアンは何故算数おじさんに触れずにいられないのか
0196デフォルトの名無しさん2022/07/05(火) 16:10:20.98ID:UQspXvq+
>>193
いや、RustのRcなどは、C++とshared_ptrと同じじゃない。
全然違うと言っても過言ではない。
0198デフォルトの名無しさん2022/07/05(火) 23:09:51.67ID:n+I8xvZo
>>196
違いがあると主張するならば、この議論で意味のある違いがあることを示さなければならない。
さらに前述の、欠陥があると主張した件についても、その欠陥を示さなければならない。
0199デフォルトの名無しさん2022/07/05(火) 23:19:42.19ID:I5LuZ1z+
>>197
>具体的になにが違うの
平日の昼ひまでこのスレにくるおじさん・じじいは
C++のshared_ptrと同じじゃないということを知ってさえいれば激十分なんだよ。
だから、具体的になにが違うかは(知らないから)答えられない。
C++とRustの深い知識あるようなすごい奴が平日の昼暇でここで遊んでいる
なんてことはないだろう。
0202デフォルトの名無しさん2022/07/06(水) 12:20:02.69ID:b0Oxubv9
ここRustプログラミングに関することならば何でも歓迎
各々の関心がないことの和集合を取ると全体集合になる
特定の人にとって関心がないからと言って排除してはいけない
0203デフォルトの名無しさん2022/07/06(水) 14:24:50.14ID:oR52wNCu
違いが大きすぎるとどこが違うとかいうのを説明するのが難しくなる。
織田信長とオムライスの違いを説明できるか?
まあ shared_ptr と Rc の違いはさすがにそこまで大きくはないけども、
前提となる C++ と Rust の違いも小さくはないので比較する意味を感じないな。
shared_ptr は shared_ptr だし Rc は Rc としか言いようがないだろう。
0204デフォルトの名無しさん2022/07/06(水) 16:11:44.19ID:rco22hfx
リファレンスカウント方式の複製可能なスマートポインタという点では類似のものと言って良いのでは
元々はc++とrustで実行効率に差があるという話だがその観点でどういう差があるのかね
そもそも実行効率が何のことを言っているのかがよくわからんから議論しても仕方ないか
0206デフォルトの名無しさん2022/07/06(水) 23:39:03.25ID:DBl9eUwS
>>203
全く別物の比較なら、信長は人間、オムライスは食べ物、というようなザックリした説明で良くなるのでは?
0207デフォルトの名無しさん2022/07/06(水) 23:45:15.32ID:DBl9eUwS
Arcとstd::shared_ptr<>が似てるという人に対して、「いや、std::shared_ptr<>とRcは全然違う」と反論するのがおかしいのでは?
0208デフォルトの名無しさん2022/07/07(木) 00:18:57.43ID:6JbvD3+y
>>206
そうだよ。
それを適用するなら
shared_ptr は C++ のスマートポインタ、 Rc は Rust のスマートポインタということしか言えなくなる。
0209デフォルトの名無しさん2022/07/07(木) 00:49:54.35ID:Sq6Pkb7P
>>208
俺らのレベルではその程度の知識で十分だろ
で、スマートポインタでもなんか違いあるの?と質問されても具体的に答えられなくても
全く問題ないからな。
一方、すごい人からすれはstd::shared_ptr<>とRcは全然違うとなるんだろうが
(すごい人敵にはそれらは例えばstd::shared_ptrは信長で人間、一方、Rcはオムライスで食べ物ぐらい違う!
でも、俺らは人間だって餌として食べることができるから同じだろ)
0210デフォルトの名無しさん2022/07/07(木) 05:04:39.45ID:WPmCyDkS
>>196
>>193
> C++のshared_ptr = RustのArc = SwiftのARC が同じ機能であり、スレッドセーフなリファレンスカウンタ利用の共有ポインタ方式。
って書いてるんだから同じじゃないとか全然違うとかフワフワしたこと言ってないで
・機能
・スレッドセーフ
・リファレンスカウンタを利用
の各項目について違いを書きなよ
0214デフォルトの名無しさん2022/07/07(木) 12:48:02.98ID:kuHYrppG
>>212
だとするとshared pointer方式ってどんな方式??
リファレンスカウンタを利用しないshared pointer方式もあるってことだよね?
0215デフォルトの名無しさん2022/07/07(木) 14:09:00.32ID:1csywUpz
>>214
shared pointerはc++のが有名すぎるからなんとも言えないなぁ。

参照カウント以外でポインタを共有するのはリンクリスト方式とかあるよ。
0216デフォルトの名無しさん2022/07/07(木) 15:30:16.82ID:jjCeBJbE
ARCで管理してる時点でRustはガベコレじゃないからすごい!って理論は破綻してるんじゃありませんかね?
0217デフォルトの名無しさん2022/07/07(木) 15:41:53.87ID:6JbvD3+y
>>216
誰がそんなこと言ってんの?

静的に管理できるものは静的に管理するし、実行時にしかわからないものは実行時に管理するってだけのことだ。
参照カウンタの適用範囲を間違えてるプログラマがいるならそれはそいつが無能。
0218デフォルトの名無しさん2022/07/07(木) 16:01:25.39ID:HUExG/fK
Rust公式の日本語意訳にはしっかりRustはガベコレじゃないから高速って書いてあるね
0219デフォルトの名無しさん2022/07/07(木) 16:16:37.05ID:I5wN0SQd
>>216
Objective-C/SwiftのARCとRustのArcは同じ3文字略語だけど別のものだよ
それを理解した上で言ってるのなら別にいいんだけどさ
0221デフォルトの名無しさん2022/07/07(木) 18:52:31.81ID:pAImJ0Xg
>>220
それはRustの定義がおかしい
一般的にはメモリリークがあるとメモリ安全だとは言わない
0223デフォルトの名無しさん2022/07/07(木) 19:11:09.29ID:Efq0h4+x
なんだ、じゃあ、バグはセーフティと定義したら、Rustは安全高めなのか。
0225デフォルトの名無しさん2022/07/07(木) 19:39:16.69ID:6JbvD3+y
>>221
Rust が言語の仕組みによって防ごうと努力する範囲にメモリリークは含まないという定義だよ。
それを表すのに「Rust の仕様の中では」メモリ安全という用語を使っているのであって、
定義におかしいもクソもない。 定義なんだから。
0226デフォルトの名無しさん2022/07/07(木) 19:46:35.34ID:6JbvD3+y
>>224
クラスと名付けられている概念はない。
あなたにとってクラスとは何のこと? 何が出来ればクラス?
0228デフォルトの名無しさん2022/07/07(木) 19:49:32.87ID:idvDnT2E
>>216
ARCで管理しているのはSwift
RustはC++と同じくRAIIなので高速
どうしても共有メモリを使いたい時のみshared_ptrやRc/Arcを用いる
0229デフォルトの名無しさん2022/07/07(木) 20:00:40.75ID:pAImJ0Xg
>>225
そのRustの仕様の中でメモリ安全性を達成できていないんだから
Rustの仕様の中でメモリ安全性という用語を使うのは不適切
Rustの謳うメモリ安全性は世間一般のメモリ安全性とは異なる概念なんだからそれを表すには他の用語を使うのが適当かと
0230デフォルトの名無しさん2022/07/07(木) 20:06:09.82ID:idvDnT2E
>>224
クラスはその根幹の継承がデメリットだらけと結論が出ているためGoやRustなどでは採用されていない
メンバー変数やメンバーメソッド等とは構造体で使えるため困ることはない
Rustでは構造体を含む任意の型に対して横断的に共通適用可能なトレイトがあり非常に強力で利便性がよい
0231デフォルトの名無しさん2022/07/07(木) 20:09:54.71ID:6JbvD3+y
>>229
知らんがな。
大抵の専門用語は一般名詞に (その分野における) 明確な定義を与えることで成り立ってるのはごく普通のことだろ。
0232デフォルトの名無しさん2022/07/07(木) 20:25:04.56ID:idvDnT2E
>>229
世間一般なんてものはなくそれぞれがそれぞれの定義域に依る
そしてそれが明確になっていればよい
例えばRustではメモリ競合は防止可能と明確化しつつ、より一般的な競合状態は対象外と明確化している
原理的に無理なものは無理なのだからそこは明確化してあればそれでよい
0233デフォルトの名無しさん2022/07/07(木) 21:01:30.61ID:0wlfNyVX
>>228
aliasingの話してるところにRAIIが来るのもよくわからないがRAIIだと高速という理屈はさらにわけわかめ
0237デフォルトの名無しさん2022/07/07(木) 22:05:44.36ID:idvDnT2E
>>233
C++とRustはヒープ利用に対してRAIIによるデストラクタ呼び出しによりリファレンスカウンタ無しでメモリ解放するので高速
さらに加えてRustでは所有権と借用のルール明確化により解放の安全性も静的に保証している
一方でSwiftはヒープ利用に対して常にリファレンスカウンタを用いるARCによりメモリ解放の管理をするため低速
0238デフォルトの名無しさん2022/07/07(木) 22:11:56.95ID:hEh+9Mpq
>>236
その流れで継承不可のクラスベースのオブジェクト指向言語がどういうものになるか思考実験的に考えてみなよ
0239デフォルトの名無しさん2022/07/08(金) 03:25:18.13ID:CKdXv9cu
それよりSQLが超苦手な俺はPRQLにめちゃくちゃ期待しているのだがラスタシアン達はSQLも達者なのかね?
0241デフォルトの名無しさん2022/07/08(金) 07:13:21.57ID:vMUJBeEa
pijul使ってみたけど、改行コードがCRLFだと非対応で
バイナリファイル扱いになるという謎仕様でまいった
差分とか出せなくなる
ファイルタイプ判別を変えるオプションは無い

それは置いといても、表示もドキュメントも超簡素で
もうすぐ1.0.0リリースを迎えるとは思えない状態

ほとんどの入門記事で使われている重要コマンドpijul statusが
最近のバージョンで削除されたのも謎すぎる
だいじょうぶなのかこれ
0242デフォルトの名無しさん2022/07/08(金) 07:47:38.58ID:ifo4L8le
>>239
今の開発のトレンドが互換性維持で苦労して中途半端なものになるくらいなら好きな仕様にして最後全部トランスパイルすりゃいいじゃん!になってしまったな
世の天才が叡智を絞った結果がRust界隈含めて今まで散々馬鹿にしてたウェブ(JS)の後追いなの草生えるわ
ちなみに英語圏ではSQLはシークェルと発音するから覚えとけ
ラスタシアンの紳士諸君はえすきゅーえるとかクソダサい発音禁止な
0243デフォルトの名無しさん2022/07/08(金) 08:02:14.74ID:i9Nd4OSx
PRQL 書き味が CloudWatch logs Insightと似てそうだけどあれもそんなにいいもんじゃないぞ。
0245デフォルトの名無しさん2022/07/08(金) 08:11:32.47ID:i9Nd4OSx
コントロールも無視もできない処理系や既存資産の上でまともな進化や開発体験を維持しようとしたらトランスパイルになるのは必然だったんだろうな。

それが必要になるクソさと、トランスパイルコストの損益分岐点が最初に現れたのがJSってだけだと思うよ。
0246デフォルトの名無しさん2022/07/08(金) 08:44:10.67ID:efA8XUrt
>>240
メモリリークに関しては

まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
ただし、Rustにおいて循環参照は他の言語と大きく異なり、
・意図的に色々と明確に指示して作成しないと、循環参照は自然に発生しない
・強い参照と弱い参照を使い分けることが出来るため、強い参照のみによる循環参照を避けることが可能
・意図的に強い循環参照を作成した場合は、それはRustにとって自動的なメモリ解放の対象とならない

したがって、Rustにおいて強い循環参照を意図的に作成した場合のみメモリリークが起こりうるが、わざと作成したのだから意図通り、という扱い
0248デフォルトの名無しさん2022/07/08(金) 09:12:01.24ID:1lqt9Ku2
「循環参照は自然に発生しない」なんていう解説狂信者おじさんがいる限り、プロジェクトには絶対Rustは採用しない......
0249デフォルトの名無しさん2022/07/08(金) 09:29:57.41ID:L1lQIkzy
ほんとこの種の信者は迷惑だわ
普通は多人数で作業して、データー構造をRc<T>をWeak<T>にあらかじめしておくようなことはしないし、”わざと作成したのだから意図通り”とか
相手(これから学ぶ人や新人)を騙すために都合の良いことを吹き込んでいるようにしか見えない・・・
それなら自動メモリ管理ではないので、作り方/使い方により自然/意図しない使い方でリークも場合もあると明確に認めて、その分だけ
自動メモリ管理ではないないので速度が速いし、メモリー解放のタイミングもある程度コントロール出来ると誠実に話したほうが余程、印象が良いのに。
胡散臭い宗教の勧誘に見えるような態度だから叩かれる
0250デフォルトの名無しさん2022/07/08(金) 09:30:47.62ID:Gv4jmnae
>>241
PijulもPRQLなど最近の新たな試みはRustで実装されることが多いが
それらはRust言語のためのものではなく汎用的なものであり
それらの問題点もRustとは直接関係がない
今後Rustで書かれた新たなものがどんどん増えていくだろうがそこは区別すべきところかな

一方でそれらをRust言語で使うためのクレートなどがあれば
Rustプログラミングにおいて使う特有の話なので
それらの話題自体を避けるべきではないね
0251デフォルトの名無しさん2022/07/08(金) 09:41:28.80ID:v7XD1ZOP
循環参照は自然に発生しないって、コードを何も書かなければ発生しないって意味かな
0252デフォルトの名無しさん2022/07/08(金) 09:42:55.25ID:QpPOct5C
>>248
新たなプロジェクトが次々とRustを採用している現実を直視しようぜ

>>249
循環参照はRust以外だと知らぬ間に発生してしまう自然なよくあるものだが
Rustでは複雑な操作で意図的に作り出さないと出現すらしない点を理解しようぜ
0253デフォルトの名無しさん2022/07/08(金) 09:58:58.97ID:BqWLp+Ol
RAIIでメモリをケアするのは
GC方式にくらべて高速ってのはまぁそうなんだけど
それよりも
開放タイミングが決定的であることのほうが特徴
オブジェクトの生存期間によってメモリの使用期間もプログラマが管理できて嬉しい
0254デフォルトの名無しさん2022/07/08(金) 12:01:11.06ID:bBPWEvXX
>>236
参照カウント方式と区別したいなら、「GC方式」みたいな曖昧な用語はやめて「トレーシングGC」を使おうぜ。
0255デフォルトの名無しさん2022/07/08(金) 12:37:51.01ID:4Cg/jdLt
>まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
この時点で嘘だらけなんだから、それ以上読む必要無い

日本語ブログだとこういう複オジレベルの人が多数派なので
Rustを本気で学びたいやつは英語のリソースメインで学ぶことを強くすすめる
0256デフォルトの名無しさん2022/07/08(金) 12:39:17.46ID:u4+He/YT
>>249
アンチは実際にプログラミングしたことがないのかね
Rc<T>自体は書き換えできないのでRc<T>だけでは循環参照を作ることができない
Rc<T>とWeak<T>は互いに対称ではないため直接置き換える対象ではない
例えばnewもRc::new(T)とWeak::new()で引数Tの有無からして異なる
さらに多人数で作業するから強い循環参照を知らぬ間に作ってしまうとの言い訳も意味不明だ
0257デフォルトの名無しさん2022/07/08(金) 12:42:18.47ID:u4+He/YT
>>255
Rustは所有者がいなくなると自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全で合っている
0258デフォルトの名無しさん2022/07/08(金) 14:56:50.59ID:bBPWEvXX
>>257
メモリを解放しないCopying GCの方が高速なんだけどなぁ。

Rustもメモリ解放しない実装なのかね?RAIIならスタック領域しかメモリを確保しないとか。
0259デフォルトの名無しさん2022/07/08(金) 16:11:26.76ID:VZayErSn
>>258
C++もRustも仕組みは同じ
RAIIによりスコープを外れた対象のスタック部分が解放される時にそのデストラクタによってヒープ部分が解放される
汎用的にはこれが最も高速かつ利便性>>253が高い

Copying GCは特殊な環境で特殊な使い方に限定する場合は速いこともありうるがデメリットも多く一般的には使われることが少ない
使用メモリが多くなるとかコピーで値を移動させるため非常に遅いなどのデメリットの他に
そこを指す全てのポインタ値をGCのたびに全て修整しなければならないという致命的な欠陥がある
C/C++/Rustなどでスタック上に置かれたポインタ値の全てを的確に書き換えるのは不可能なので使えない
0260デフォルトの名無しさん2022/07/08(金) 16:24:07.17ID:atE4xqm8
短時間で終了するプログラムはfree呼ばずにexitした方が高速な場合がある
copy gcも条件付きだが高速な場合がある
常にRAIIによるメモリ解放が他の手段より高速というのは誤り

100%正しいという風に断言するから枝葉の議論になるし最初から論理的に厳密な文章書いた方が良いよ
0261デフォルトの名無しさん2022/07/08(金) 16:35:35.79ID:VZayErSn
>>260
これは特殊な使い方限定の話を持ち出したら意味がない話
既に書いたようにCopying GCは汎用的には使いものにならない
一般的にはRAIIによる解放が最も高速かつ利便性が高い
そのためC++でもRustでもその方法がとられている
0262デフォルトの名無しさん2022/07/08(金) 17:23:29.15ID:cRmlWf2z
copying GCはJavaで使われているのだが

解放しない、以外でスタックの解放(malloc的なものに対する)freeより速いものはあるの?
0263デフォルトの名無しさん2022/07/08(金) 18:32:33.29ID:r9xh0XFc
>>246
C++にもweak_ptr<>あるけど。
0264デフォルトの名無しさん2022/07/08(金) 18:32:40.38ID:IcalP2aj
RAIIがGCより高速なら
RAIIの一例であるshared_ptrはGCの一例であるARCより高速ということになるが
どういう原理で高速になるの?
0265デフォルトの名無しさん2022/07/08(金) 18:42:02.74ID:r9xh0XFc
でも、Firefox良く落ちるじゃん。
0266デフォルトの名無しさん2022/07/08(金) 18:45:00.33ID:r9xh0XFc
でも、JavaはC++も20倍速いってサイト無くなったじゃん。
0267デフォルトの名無しさん2022/07/08(金) 18:50:36.37ID:r9xh0XFc
>>261
だって、RustはC++0xのパクリじゃん。
0268デフォルトの名無しさん2022/07/08(金) 18:52:55.66ID:hlO59OkW
>>264
shared_ptrではRAIIによって解放しない
RAIIによってデクリメントするだけ

SwiftなどでのARCが遅い理由は参照型の全てにおいてshared_ptrを使用しているような状況であるためコストが高い
0269デフォルトの名無しさん2022/07/08(金) 18:54:07.09ID:r9xh0XFc
じゃあ、unique_ptr<>でいいじゃん。
0270デフォルトの名無しさん2022/07/08(金) 19:10:19.78ID:hlO59OkW
>>269
unique_ptrとshared_ptrの役割の違い、動作の違いを理解できていない君が
間違えて用いてもC++ではコンパイルが通ってしまったりして実行時に問題を引き起こす
Rustは間違えて用いるとコンパイルエラーとなり通らないから安全側に救われる
0272デフォルトの名無しさん2022/07/08(金) 21:48:50.65ID:i9Nd4OSx
>>257
即座に開放というのがOSに返却とか認識してたらアウトだぞ。
アロケーターなに使うかで実際の挙動は変わってくるからな。
普通しないがクソアロケーター使ったら、OSからみたらリーク同然になったりするし。
0273デフォルトの名無しさん2022/07/08(金) 21:53:34.22ID:G/CdBPp1
所有者がいないとメモリ解放って間違ってるよね?

所有者がいてもブロックから出たら解放されるからコンパイルエラーが出てコンパイルされない
0276デフォルトの名無しさん2022/07/08(金) 22:38:42.99ID:J0vSCVey
>>273
所有者がいなくなるとメモリ解放であってるよ
スコープを抜けると所有者がいなくなりデストラクタが呼ばれて管理していたヒープ領域があれば解放される
0277デフォルトの名無しさん2022/07/08(金) 22:51:41.26ID:j0PLF9Z7
所有権とは?の話に戻っちゃうな
複製おじさんネタで散々繰り返したやつ
0279デフォルトの名無しさん2022/07/08(金) 23:08:26.12ID:h7kEq7Ot
なんか合ってるのか分からんけど最近思うこと

Rustの言語仕様内に明確に含まれているのはlifetimeだけで
所有権とか所有者ってのは実はただのメタファーでしかない?
0280デフォルトの名無しさん2022/07/08(金) 23:12:47.70ID:r9xh0XFc
C++はコンテナのアロケータと積み荷のアロケータが別とかできるくらい柔軟ですよ。
0281デフォルトの名無しさん2022/07/09(土) 00:08:13.16ID:Xo3+Ls6P
コンセプトをコンパイラにハードコーディングして変えられないようにしたのがRustってこと?
0282デフォルトの名無しさん2022/07/09(土) 03:43:55.29ID:dAPednzC
>>256
こいつのような気持ち悪い反吐が出る輩がいるからRustがいまいちメジャーにならない。公式ドキュメント書き換えてこいゴミ
上の文章読んでどの辺が「アンチ」だ?ゴミのくせにイキって恥かいてんじゃねーわw

The Rust Programming Language 日本語版
循環参照は、メモリをリークすることもある
循環参照を回避する: Rc<T>をWeak<T>に変換する
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html
0284デフォルトの名無しさん2022/07/09(土) 07:31:04.73ID:O4my42l1
認める事を全くせず、大したコードも書いてないのにRustやってる事だけが自尊心だから勝手にアンチだの決めつけて
いつも人を見下して偉そう。プロジェクトチームの雰囲気はそいつがいるだけで常に最悪、チームの重荷・会社の害悪。
口癖は「意味不明」
0285デフォルトの名無しさん2022/07/09(土) 10:34:16.63ID:OnqDT6DB
>>282
実際にコードを自分で書いて理解したほうがいいよ。
その公式Bookに書かれている内容はもちろん正しいし、
その相手>>256の書き込み内容も正しくて、
両者に矛盾はないよ。
0287デフォルトの名無しさん2022/07/09(土) 11:50:07.31ID:lwwTn4Ql
どちらにしてもRust使っても気楽にコーディングできるわけでもなく
メモリ構造考えなければいけないんですね
0288デフォルトの名無しさん2022/07/09(土) 13:10:56.08ID:g+WH1rkE
結局、C++0xのパクリじゃないですか。
C++はそこからさらに10年以上進んでるのに。
0290デフォルトの名無しさん2022/07/09(土) 13:41:18.89ID:ByPaZ1uJ
>>279
説明用に作った概念ではあるけどRustの根幹に関わる重要な概念なので
「ただのメタファーでしかない」という言い方は微妙
自分の好き勝手に解釈した内容を公式見解かのように流布する輩を助長することになるから
0291デフォルトの名無しさん2022/07/09(土) 14:19:07.01ID:g+WH1rkE
パクリ元のC++で所有権と呼ばれてるからでしょ。
0292デフォルトの名無しさん2022/07/09(土) 14:21:22.91ID:g+WH1rkE
C++は高機能すぎて分けワカメなので、初心者用に出来ることを減らしますという、ジェネリクス界のPythonがRustでは?
0293デフォルトの名無しさん2022/07/09(土) 14:57:08.15ID:gD3yh/Bo
>>283
見たけど正しいやん
間違ってる!とウソをつくけど間違ってる点を指摘できないいつもの人かね?
0294デフォルトの名無しさん2022/07/09(土) 15:04:05.66ID:g+WH1rkE
誰も所有してないのに解放されないなら意味ないじゃん。
0295デフォルトの名無しさん2022/07/09(土) 15:25:00.91ID:3oDyg2LH
>>294
ヒープ領域に対して誰も所有(利用)しなくなった時に
・自動解放しない(要手動解放) ← C C++(下記除く)
・即座に自動解放する ← Rust C++(unique_ptrなど使用時)
・GCする時になってから自動解放する ← ほとんどのGC言語
0296デフォルトの名無しさん2022/07/09(土) 15:36:21.95ID:lXmK1DKz
Cで書くにしても、今時のCLIツールならヒープなんか解放せず放置しても実用上問題ないよね
0297デフォルトの名無しさん2022/07/09(土) 16:18:04.20ID:y0LX8Rgp
そもそも間違ってるとは何と照らし合わせて間違ってるという主張なのか
「そうあるべきではない」というべき論なら前提を明確にしない限り知らんがなとしか言えん
0298デフォルトの名無しさん2022/07/09(土) 16:36:33.54ID:g+WH1rkE
>>295
いや、C++はアロケート時にアロケータを選択するから。
デフォルトが準備されてるだけで。
当然、GCもあり得るから。
0299デフォルトの名無しさん2022/07/09(土) 16:39:05.20ID:g+WH1rkE
だめだ、こいつに聞いても無駄だ。
誰かわかるやつ居ないのか。
0300デフォルトの名無しさん2022/07/09(土) 16:52:06.76ID:3+oPDqor
この板で最も勢いのあるスレになりましたな
0301デフォルトの名無しさん2022/07/09(土) 17:15:21.88ID:ziCGmT1x
>>284
アンチ君は皆に論破されると毎回
思い込みの仮想敵を作り人格攻撃を始めて逃避するようだが
そんな下らないことはアンチスレでやってほしい
0302デフォルトの名無しさん2022/07/09(土) 17:29:07.29ID:g+WH1rkE
自分より詳しいやつは全部アンチか。
それじゃダメだろ。
0304デフォルトの名無しさん2022/07/09(土) 17:54:41.59ID:g+WH1rkE
つまり、C++0xをパクって機能限定して簡単にしたのがRustだろ?
0305デフォルトの名無しさん2022/07/09(土) 17:58:46.63ID:QKZ/1qEu
>>295
プログラミング言語の進化の中で、
そのメモリ自動解放における高速性と安全性の両立をRustが初めて実現したってことになるのかな
0306デフォルトの名無しさん2022/07/09(土) 18:04:41.00ID:SVLGLpJF
Region-based Memory Management の構想は Cyclone から始まってる。
この段階では実用化したとは呼びにくいが、実現は出来ていた。
0308デフォルトの名無しさん2022/07/09(土) 18:46:05.22ID:hyXSHlQu
正確にはこうだな

プログラミング言語の進化の中で
メモリ自動解放における高速性と安全性の両立を実現した初めての実用的な言語がRust
0310デフォルトの名無しさん2022/07/09(土) 18:58:45.49ID:g+WH1rkE
C++0xがなかなか標準化されないので、それなら自分で作ろうと立ち上がったと本人が言ってるじゃん。
0312デフォルトの名無しさん2022/07/09(土) 19:22:48.72ID:kZfneOfi
別にC/C++でもちゃんと作れば高速性と安全性は両立してるよ
ちゃんと作るのが難しいかどうかの話でしかないだろ
0313デフォルトの名無しさん2022/07/09(土) 19:29:47.99ID:TbjkUF4v
>>312
C/C++では不可能
うっかり危険なコードを書いてもコンパイラが通してしまう
Rustはコンパイラが指摘して通さないため安全
0314デフォルトの名無しさん2022/07/09(土) 19:30:20.48ID:6ug5/LDh
難しさを度外視してちゃんと作ればいいと言うならアセンブラでも同じわけで。
0315デフォルトの名無しさん2022/07/09(土) 19:36:03.58ID:hyXSHlQu
>>312
残念ながらCとC++は安全性を満たしていない
現状Rustだけが安全性と高速性を両立させている
0317デフォルトの名無しさん2022/07/09(土) 19:51:24.99ID:zb7jG/MW
じゃあChromeやSafari、Edgeじゃなく、お前のブラウザーふぁいあーふぉっくすにしろよ?安全じゃないんだろ?ぷゲラ
0318デフォルトの名無しさん2022/07/09(土) 19:52:51.29ID:FBd+xess
うっかり前提条件が保証できていないunsafe fnの呼び出しを書いてもRustコンパイラは通してしまうではないですか
0319デフォルトの名無しさん2022/07/09(土) 20:07:34.54ID:kZfneOfi
>>313,315
ああ、Rustが決めた安全性か
まあ>>274みたいなのには目をつぶるならそれでいいんじゃねw
はたから見たらオナニーにしか見えないけど

>>314
そうだよ、突き詰めたらレベルの違いでしかない
普通のひとは突き詰めること自体が馬鹿らしいって思うからこんなことで揉めたりしないけど
0321デフォルトの名無しさん2022/07/09(土) 20:29:03.57ID:r2wQepG1
C++が敗北した理由が安全性を疎かにしたことは事実だけど
当時は安全性なんてそこまで重視されていなくて速ければよい時代だった
さらに安全性と速さを両立させる使い物になるプログラミング言語が出てくるとは想像できなかった
ここ数年でC++がようやく退場する時代となったたけでありそれ以前はC++の天下であった
0324デフォルトの名無しさん2022/07/09(土) 21:26:07.86ID:rB16NsHU
>>318
実際にプログラミングをしたことがないからアンチはそんな間違った発言をうっかりしてしまう
0325デフォルトの名無しさん2022/07/09(土) 21:36:29.93ID:TbjkUF4v
>>319
天と地ほどの差がある
コンパイル時点でエラーとして弾いてくれてコンパイラが修整すべき点をアドバイスしてくれるRust
コンパイラは何も言わずに通してしまい実行運用中に問題が発覚するC/C++
0326デフォルトの名無しさん2022/07/09(土) 21:37:18.68ID:FBd+xess
「前提条件が保証できていない」に触れていないのはうっかり読み飛ばしたのかな?それともわざとかな?
0328デフォルトの名無しさん2022/07/09(土) 21:51:31.23ID:8h5AdXRe
>>323
レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ

>>325
> まあ>>274みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない
0329デフォルトの名無しさん2022/07/09(土) 22:07:58.78ID:dPnpzXnF
アンチ連呼おじさんの主張は「おまえらはプログラミングしたことが無い」
0330デフォルトの名無しさん2022/07/09(土) 22:17:01.66ID:5J/+jd/X
話は単純
RustはC++における問題のうちみんなが挙げてるような重要な部分を解決してしまった
それにプラスしてC++よりpRustの方がプログラミングしやすい点も非常に大きい
0331デフォルトの名無しさん2022/07/09(土) 22:18:10.11ID:GNVCknQf
コテハンとは一体
0332デフォルトの名無しさん2022/07/09(土) 22:29:14.97ID:FBd+xess
>>330
そうだな
そしてRustが解決したという「問題」の範囲を大きく見せて誇大広告している人がいたのでぶっ叩かれたと
単純な話だ
0333デフォルトの名無しさん2022/07/09(土) 22:30:12.39ID:dcG9hbvO
>>329
「おまえらはもうプログラミングしていないだろ」
じゃないのか
若い時はしていたんだろうが、おっさん・爺になって仕事ではもうプログラミングしていない
比較は必死にするが実際のRustプログラミング話が無いおじさん・爺のRustスレだからな
0335デフォルトの名無しさん2022/07/09(土) 22:44:39.49ID:3KUXTO+D
>>332
Linus含めたLinux開発陣も同じ結論
C++はダメな言語なので不採用
Rustは良い言語なので採用
0336デフォルトの名無しさん2022/07/09(土) 22:46:38.67ID:dcG9hbvO
>>334
歳をとってもうプログラミングしていないん(実質現役引退)だから
Cすら仕事で書いていないだろ
0337デフォルトの名無しさん2022/07/09(土) 22:59:01.59ID:hVKa6Imk
> 287 名前:デフォルトの名無しさん [sage] 投稿日:2022/07/09(土) 11:50:07.31 ID:lwwTn4Ql [2/3]
> どちらにしてもRust使っても気楽にコーディングできるわけでもなく
> メモリ構造考えなければいけないんですね

読んでなるほどなと思った
よくわかんないけどとりあえず動けばいいという人と、
ちゃんと理解して自分の思う通りに動かしたい人の違いだなと
0338デフォルトの名無しさん2022/07/09(土) 23:05:49.23ID:dcG9hbvO
>>335
俺,win使っているが
そのよい言語のRustをコンパイルするのに(C/C++する気ないのに)駄目な言語のmsvcを入れないと
とコンパイルできないてのがな

で、なんでmsvc必要なんだ?
ひょっとしたら、linuxでもgccとかを入れないと駄目なのか
0339デフォルトの名無しさん2022/07/09(土) 23:15:33.27ID:yHOdCoxc
>>337
その人があまりにも知識不足の可能性が高い
Rustでも他の言語と同様に(C互換FFIを除いて)メモリ構造なんて公開も保証もしていない
ほとんどのプログラミング言語はメモリ構造なんて低いレベルで使うものではなくもっと抽象度の高い部分でその定義と保証がなされるもの
だからRustでも他の言語と同様にメモリ構造は考えなくて良いし考えてはいけない
メモリ構造は言語として保証していないし保証しないからこそ大胆なコンパイル最適化を行なっている

話を戻してその人はメモリ構造ではなくデータ構造と言いたかったのではないか?
データ構造は他の言語と同様にRustでも考えなければならない
それがプログラミングの中心だから
0340デフォルトの名無しさん2022/07/09(土) 23:30:15.11ID:hVKa6Imk
>>338
そんなこと知らずに、そういうレスしているところにドン引きだな
自分で調べた?
調べたら、その結果をここで報告よろしく
0341デフォルトの名無しさん2022/07/09(土) 23:45:37.10ID:yHOdCoxc
>>338
Rust批判派があまりにも知識不足で驚いた
ちなみにこちらはLinuxだがrustc(=Rustコンパイラ)だけあればコンパイルできる
0342デフォルトの名無しさん2022/07/10(日) 00:12:02.83ID:VXHYDjJa
>>339
SwiftとかABI stabilityを実現してるやつは仕様としてメモリレイアウトを定義して公開してるやろ
0344デフォルトの名無しさん2022/07/10(日) 00:16:59.60ID:CjJVLv20
まあ>>287の書いてるメモリ構造という言葉はメモリレイアウトでもデータ構造でもないのは明らかだけどな
0346デフォルトの名無しさん2022/07/10(日) 00:30:08.21ID:tvXCky2C
>>342
そのABIはコンパイル後のバイナリのフォーマットの話だぜ
今回の『気楽にコーディングできるわけでもなくメモリ構造考えなければいけないんですね』はプログラミングの際の話だから関係ない

プログラミングする上でメモリ構造は考えなくていい
例えばRustの型VecやStringなども各々のがどんなメモリ構造になるかは規定も公開もない
もちろんソースコードを読めば内部のデータ構造までは分かるがそれに依存してコードを書いてはいけないし依存できないよう抽象化されたインタフェースのみ規定公開されている
0349デフォルトの名無しさん2022/07/10(日) 01:02:48.63ID:qjKEOyYX
>>343
なるほど、
>341
>ちなみにこちらはLinuxだがrustc(=Rustコンパイラ)だけあればコンパイルできる
は、比較的新しいrustを使えばgcc(リンカ)イラネってことか
rustでリンカ作った方がgccのリンカよりずっと良いものになるだろうからな
0351デフォルトの名無しさん2022/07/10(日) 01:48:41.75ID:LxkGLd0V
>>350
おまえ低能だな
そんな内容と設定ではそのスレは過疎って終わることくらい予測できるだろ?
0352デフォルトの名無しさん2022/07/10(日) 04:45:49.56ID:T5qatPVB
荒らしてるのはLinux板の連中か。
0353デフォルトの名無しさん2022/07/10(日) 08:32:10.98ID:VKvLuEGz
Cellを使っていて思ったんだが例えば

trait CellUpdateWith<T> {
fn update_with(&self, f: impl FnOnce(&mut T));
}

impl<T: Default> CellUpdateWith<T> for Cell<T> {
#[inline]
fn update_with(&self, f: impl FnOnce(&mut T)) {
let mut inner = self.take();
f(&mut inner);
self.set(inner);
}
}

このようにメソッドupdate_with()を用意しておけば
内部更新もわかりやすく記述できるな

let foo = Cell::new(vec![1, 2, 3]);
foo.update_with(|v| v.push(7));

身代わりにself.take()でdefault値を入れてCellから取り出し
self.set()でCellへ戻すという無駄な操作は最適化で消えるようだ
https://godbolt.org/z/19c4EbErG
0355デフォルトの名無しさん2022/07/10(日) 13:59:32.22ID:blpABUiA
>>354
この手の人は自分が排除されることを最も恐れてるんだよ
そうならないための策ならなりふり構わず何でもやる

自分が排除される側にいる自覚がなければそんなことやらない
0358デフォルトの名無しさん2022/07/11(月) 00:14:06.35ID:triNevnR
15年近くc/c++触ってなくて(ずっとjava触ってた)
rustの所有権とか何故こんな仕様になったのか経緯がわからなくて
最近のc11以降の仕様の?unique_ptrとかshared_ptrとかstd::moveとかstd::forward学んで
(元々boost にスマートポインタがあった記憶があるけど記憶が曖昧)
どうしてこう言う機能が出来たのか少しわかった

今のc++はconst 地獄だしとにかくコードが汚くなる
こりゃrust の方が良いわ

あと型名の付け方が好き。u32とかf32とか
昔cで書いてた頃typedefでわざわざ定義してたよ
0359デフォルトの名無しさん2022/07/11(月) 10:40:05.73ID:1W23UOpt
const 地獄 ← 判る
static_cast うぜー ← 判る
Rust 万歳 ← 判らん
0360デフォルトの名無しさん2022/07/13(水) 23:59:24.88ID:qlTJEO+a
>>353
もっと便利にできるぜ

use std::cell::Cell;

trait CellWithMethod<T> {
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R;
}

impl<T: Default> CellWithMethod<T> for Cell<T> {
#[inline]
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R {
let mut inner = self.take();
let result = f(&mut inner);
self.set(inner);
result
}
}

fn main() {
let foo = Cell::new(vec![1, 2, 3]);
foo.with(|v| v.push(7));
assert_eq!(4, foo.with(|v| v.len()));
assert_eq!(7, foo.with(|v| v[3]));
assert_eq!(vec![1, 2, 3, 7], foo.with(|v| v.clone()));
}
0361デフォルトの名無しさん2022/07/15(金) 21:39:01.85ID:qV4GyRtM
>>360
CellでVec使えるのか
何か間違って学習していた

https://qiita.com/wada314/items/24249418983312795c08
> 1. Cellの中身の型はCopyをimplしていなければならない

https://dev.classmethod.jp/articles/rust-smart-pointer/
> ・Cellの中の型はCopyトレイト実装が必須

https://qiita.com/usagi/items/fc329895cebd3466910e
> Cell は値の "移動" によって内部可変性を実装するため <T> は Copy 可能な "値" 向けのコンテナーで、
> i32 や Copy trait を実装した何かを扱うのに"適した"コンテナーです。

https://zenn.dev/mebiusbox/books/22d4c1ed9b0003/viewer/5df75e
> Cell<T> の大きな制約として, T は Copy トレイト境界があることです.

実際にはCellはCopyを要求していない
やってみたら>>360のコードが動いてCell<Vec<_>>が使えた
0365デフォルトの名無しさん2022/07/16(土) 00:28:56.56ID:730D9OZt
>>361
get()がCopyを要求するからってのもあるけど
古いThe BookにはCellはCopy専用・RefCellはCopy以外も使えるという説明があったので
それが日本語訳とかで残ってたんじゃないかな
0366デフォルトの名無しさん2022/07/16(土) 23:27:56.53ID:MG4+BxCd
>>360
!Syncで参照無しならデータ競合を起こさない、という点を使った用法だな
便利だから公式サポートすればいいのにな
0367デフォルトの名無しさん2022/07/20(水) 00:26:56.65ID:XqWqiApN
StackOverflowで「好きな言語No.1」だそうだが、調査方法に問題が有り、
二位以下も聞いた事が無いような言語ばかり。
0373デフォルトの名無しさん2022/07/20(水) 13:30:14.44ID:S6pSKHOi
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい
0374デフォルトの名無しさん2022/07/20(水) 13:30:16.81ID:S6pSKHOi
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい
0378デフォルトの名無しさん2022/07/20(水) 17:02:14.65ID:xLuB33a9
とりあえずcarbon自体のコードの8割がcarbonで書かれるエコシステムが確立してからだろう
0379デフォルトの名無しさん2022/07/20(水) 19:50:56.65ID:hGf+NvAH
JSのTypeScript
C++のCarbonって感じかね

どうなるんだろうね
確かにC++を無くすのは勿体ないがまだ0.1か いつ1.0になるかなぁ 10年後くらいか
Rustよりも難しくはなくメモリ管理も楽になるのかな
0380デフォルトの名無しさん2022/07/20(水) 20:00:37.08ID:xdIX6xM1
Rustはあらゆる面で安全と高速の両立する抽象化を実現した言語だから
現在のCarbonのドキュメントを見る限りRustの領分に入ってきていないでしょう
それよりもC++と書き方がかなり変わっていて互換性がなく別言語の様相でCarbonは中途半端な立ち位置に見える
0381デフォルトの名無しさん2022/07/20(水) 20:01:46.68ID:sReX4jGj
Carbonは「Rustが難しすぎるから簡単にしたい」とは言ってなくて、C++と相互運用できる言語を目指してるだけっぽいからなぁ
結果的にRustより難しくなっても驚かないけど
0382デフォルトの名無しさん2022/07/20(水) 20:33:50.16ID:sReX4jGj
そもそもCarbonの使い所ってC++のレガシーコードが大量にあるところだから
C++も当然マスターしてないといけなくて、学習量は明らかに増えてる気もする
0383デフォルトの名無しさん2022/07/20(水) 20:52:36.69ID:oyesoq1v
ドラゴンボールのゲームでドドリアの色違いでカーボスと言うのがいたのを思い出した

どちらかと言うとザーボンの色違いがカーボスなら納得なんだけど…
0384デフォルトの名無しさん2022/07/20(水) 21:27:24.19ID:mJssGRdK
Carbonって中途半端すぎね?
まともな言語設計者ならオブジェクト指向もう採用しないと思うんやけどなんか継承機能もあるみたいだし
なんでこういう中途半端のところもC++参考するんだよこういうところこそRust参考にしろよ
0385デフォルトの名無しさん2022/07/20(水) 21:44:56.66ID:qLBZujX3
>>384
C++とシームレスに相互運用することが最優先課題だから、そこはC++と同じにしておかないとそもそも存在意義がなくなる
0386デフォルトの名無しさん2022/07/20(水) 22:16:07.31ID:gROTqHCf
ま、2-3年後にどうなってるかだな
バックにGoogleいるらしいから開発終了なんてことはなさそうだが
0387デフォルトの名無しさん2022/07/20(水) 22:21:24.71ID:9oJrmZpV
>>386
逆じゃね?企業だからこそ開発者の熱意とか関係なくコストに見合わないとなれば容赦なく切られるかと
Goみたいに社内で使うことが確定してしまえば安泰だけど
0390デフォルトの名無しさん2022/07/21(木) 00:45:01.09ID:g1dckGB4
5年たったらまたオブジェクト指向が再燃してるかもしれない
と言うか業務では大規模開発にはオブジェクト指向が必須なんだな

モジュールでは全体が見通せない
0391はちみつ餃子 ◆8X2XSCHEME 2022/07/21(木) 00:52:44.62ID:/hG5LMVG
話題が逸れるが >>384 が C++ の型システムをオブジェクト指向と呼んでるっぽいのが気になる。
オブジェクト指向はオブジェクト同士がメッセージを送りあう形でプログラムを構成する思想のことで、
それを言語機能としてどのように支援するのかには様々なバリエーションが有りうる。
型システムとは独立した概念だよ。
ふんわりした概念なので定義によるが Rust もオブジェクト指向 (をサポートする) 言語に分類されることはある。

それはそれとして、 C++ の型システムもベストとは言えないが最悪というわけでもない。
実際にかなり多くの場面で活用されている実績は認めないといけない。
要するに「この程度で十分」ではあるんだよ。
C++ の本当につらいところは C から引き継いだガバガバさや歴史的事情のワケわからんところであって、
型システムの根本的な改善はそれほど切実に必要だとは思わないな。

C++ が駄目だと否定するんじゃなくて C++ みたいなことを C++ より上手くやるという方向性はアリだろう。
0393デフォルトの名無しさん2022/07/21(木) 00:58:24.47ID:MOkaWH3B
>>391
前半は正しいが
後半のクラス継承システム程度で十分という点には賛同しかねる
今までの現実の多くのケースはクラス継承システムしか使えない環境だったから無理矢理にそれを使っているだけである
0394デフォルトの名無しさん2022/07/21(木) 01:00:56.06ID:g1dckGB4
似たような機能のものを大量に書く場合どのように実装するのが楽かどのように管理するのが楽か

モジュールではないな
0395デフォルトの名無しさん2022/07/21(木) 01:15:53.78ID:MOkaWH3B
>>394
その点ではRustもC++も同じオブジェクト指向なので何を主張したいのかわからない

Rustの基本はselfに見られるようにオブジェクト指向
違いはC++がクラス継承なのに対してRustはトレイト
ジェネリックから見るトレイト境界による型制約となり
逆の視点から見るとトレイト付加によるメソッド拡張となる
0396デフォルトの名無しさん2022/07/21(木) 03:25:39.61ID:DiLbgRco
いくらRustが有望だと言われていても、ポインターがないと使いづらい場面ってあるよな
ツリー構造とか、ポインターなしで大して実行速度も落とさず記述する技があるようだけど・・・・大掛かりなことをするのなら労力を割くのもいいけど、ちょっと使うだけには労力がかかりすぎる
0399デフォルトの名無しさん2022/07/21(木) 08:09:40.58ID:HHuzACnI
>>385
Rustからわかるように、求められているのは膝を打ち抜く自由の無いc++であり、コーダーに使わせる言語。
unsafeはc++で実装すりゃいいので、継承とかは使うだけに限定するという手もある。
0400デフォルトの名無しさん2022/07/21(木) 13:48:15.98ID:xy799ZfA
>>391
話し手がなにをオブジェクト指向の言語としているのかどうか判断する程度の読解力は持ち合わせてくれないかな?
RustはC++のように継承を導入することによってもたらされる問題を回避するためにclassじゃなくてtraitを基本的なプログラムの構成要素として採用することで既存のオブジェクト指向言語と一線を画すというプログラミング言語史に残る進歩を達成していた
0401デフォルトの名無しさん2022/07/21(木) 15:49:13.07ID:Q1uK5/Rv
>>400
Haskellの型クラスの方が先だろ。

「プログラミング言語史に残る進歩」とかさすがに恥ずかしいレベル。
0402デフォルトの名無しさん2022/07/21(木) 16:58:11.12ID:xy799ZfA
>>401
RustのtraitをただのHaskellの型クラスの類似物としてしか認識できないのはお前が単に馬鹿だから
Rustのtraitは本来継承もmixinとも違ったC++のclassより洗練された新たなプログラムの構成要素だっていう側面が理解できていない馬鹿が多すぎる
ただRustではこのtraitという構成要素に実用上の面から今度は型クラスという機能も持たせているというだけで話の順序が違う
こんぐらいRust書いていたらtraitには単に型クラスだけの意義だけじゃないってわかると思うんやがお前にはそういった才能もないただのネット上で繰り返し喧伝されている宣伝にしか注目する脳がないいわばにわかの部類の奴だということがわかった
0403デフォルトの名無しさん2022/07/21(木) 17:50:57.39ID:eNA5340i
traitの画期的な部分はc++のabstract classで実現できないの?
0404デフォルトの名無しさん2022/07/21(木) 17:54:16.35ID:F7Gtvv1S
>>402
何が言いたいのかよくわからないけど型クラスになくてtraitにあるものって何?

associate typeはrustの発明だと思うけど、そういうこと言いたいわけでもなさそうだし
0405デフォルトの名無しさん2022/07/21(木) 18:07:36.13ID:ySHdWcK4
自分が崇拝する神だけが唯一正しいと妄信して
他人の考え方を徹底的に糾弾排斥するのがカルト

カルト化した人間とまともな議論ができると思うな
0406デフォルトの名無しさん2022/07/21(木) 18:19:30.67ID:xy799ZfA
>>404
公式サイトにすら出典付きで載ってあることなんだけどなんでここで聞くの?
繰り返しになるがtraitの型クラス以外の側面に気づけないのはお前が単に馬鹿なだけ
0407デフォルトの名無しさん2022/07/21(木) 19:01:28.92ID:HGs+QJMA
>>406
そういうのを誘導しないからお前はダメなんだよ。

prev.rust-lang.org/ja-JP/faq.html#how-do-rust-traits-compare-to-haskell-typeclasses

How do Rust traits compare to Haskell typeclasses?
Rust traits are similar to Haskell typeclasses, but are currently not as powerful, as Rust cannot express higher-kinded types. Rust’s associated types are equivalent to Haskell type families.
0410デフォルトの名無しさん2022/07/21(木) 20:48:28.30ID:rGFlKcYB
>>407
それURLがprevで始まっているように古い情報ページ
わざわざそれを出すのは何か意図がある?
0411デフォルトの名無しさん2022/07/21(木) 21:43:04.55ID:vaotA28G
>>408
正しい情報を啓蒙するのは面倒だということを知らしめる意図じゃない?
0412デフォルトの名無しさん2022/07/21(木) 21:59:42.36ID:vJeGD7jb
>>404
Rustのトレイトは
トレイト境界を実装で指定できるだけでなく
トレイト境界を型宣言でも指定できるなど
様々な点で型クラスと異なるよね?
0415デフォルトの名無しさん2022/07/21(木) 23:56:47.54ID:vrEITS91
>>412
トレイトに関しては当然Haskellの型クラス由来の部分が多いけど互いに片方にしかないものもあり異なる側面があるわけか
0421デフォルトの名無しさん2022/07/22(金) 00:46:45.91ID:Dec8FkF+
>>418
-XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language.
0423デフォルトの名無しさん2022/07/22(金) 01:43:49.12ID:kvE65+oR
トレイトのどの辺が「洗練された新たなプログラム構成要素」と感じるのか全然分からん
俺の中ではインターフェースと一緒の扱い

Rustが画期的だったのはOwnership/Referenceルール + Borrow Checker
この点に異論ある人はいないよね?
0424デフォルトの名無しさん2022/07/22(金) 02:15:42.10ID:g+hZIhYV
>>423
一般的なインタフェースなんて
Trait Boundsもimpl Traitもdyn Traitもないゴミ

>>419
その点でも差異があるだけでなく
Rustのトレイトは基本概念こそHaskellの型クラスと同じだがそれ以外は各々の言語に適応してかなり異なる
0425はちみつ餃子 ◆8X2XSCHEME 2022/07/22(金) 03:26:24.88ID:fX2QhDiX
>>424
そりゃ言語に合わせて変えるところがあるのは当たり前だが、
基本概念が同じだというなら類似物ではあるだろう。
カテゴリ分けしたらおおよそ同じところに分類するよ……。
0426デフォルトの名無しさん2022/07/22(金) 03:47:26.49ID:u1/oKmBi
>>425
それは違うのではないかな
例えばHaskellはRustのtraitでのdyn(動的解決)とimpl(静的解決)といった重要な基本概念を欠いているよ
0427デフォルトの名無しさん2022/07/22(金) 05:52:26.07ID:FhKnOINS
C++の欠点は、何でもできること。
その欠点をなくして、わかりやすくしたのがRust。
バイナリ界のJavaと言い換えても良い。
ほとんどのプログラマはC++よりRustを使うほうが良い。
0430デフォルトの名無しさん2022/07/22(金) 09:55:09.86ID:aK9LU/qI
>>424
>一般的なインタフェースなんて
>Trait Boundsもimpl Traitもdyn Traitもないゴミ

言語化できてないから本質を理解できていように見える

Trait Boundはジェネリック型の型制約で一般的なインターフェイスも型制約として機能する
一般的なインターフェイスは動的ディスパッチなのでdyn Trait相当

impl Traitがmonomorphizationのことを言ってるならそれはTraitの機能じゃなくGenericsの機能
C++で20年前から使えるよね?
C++以外でもSwiftみたいに一部の言語はGenericsのspecialization機能があるけど一般的にはオーバーロード使ってstatic dispatchにすることが可能
0431デフォルトの名無しさん2022/07/22(金) 10:57:57.42ID:GQh1j6M0
>>418
javaのgenericsでextends使うとできるやつかな?
0432デフォルトの名無しさん2022/07/22(金) 11:30:46.07ID:emgmw9dd
Java厨は出て来ないで下さいうざいだけです
0433デフォルトの名無しさん2022/07/22(金) 11:34:22.85ID:LVIZaCij
>>429
msとかgoogleとかの狙いはそうだろ。
土方がコーティングしてもバグが入り込まない。
その代わり難易度が上がっているからコーダーの単価上がりそうだけど、msとかgoogleはそんなの気にしないだろうし。
0434デフォルトの名無しさん2022/07/22(金) 13:14:37.08ID:GQh1j6M0
>>432
rustの画期的な部分なんだろ?言い返せないのかよダサいなお前

本当に革新的なのは>>423あたりなんじゃないの
0435デフォルトの名無しさん2022/07/22(金) 14:36:57.37ID:ZDp8+ZKO
kumagiとか見てると、google社員でもc++触らせたらあかん奴ってのが結構いるのがわかる。
0436デフォルトの名無しさん2022/07/22(金) 14:59:23.46ID:hnGDX2CP
>>431
Javaのジェネリクスは変な制限が多く
インタフェース指定していって問題があってもコンパイルエラーとならず実行時エラーとなるものがあるなどJavaは論外
他にも問題多すぎてRustに何ひとつ勝てないから新システムを機会にJava→Rustとなったものも出てきている
0437デフォルトの名無しさん2022/07/22(金) 15:43:33.15ID:yLavWCdC
>>434
Ownership/reference自体はc++にもあるからあんまり革新的とは思えないな。

コールスタック&RAIIを中心にしてメモリ管理ルールを再構築して、厄介なヒープメモリの管理をできるだけ避けて高速化しているのが特徴だと思う。
革新的なのはそのルールを徹底していることくらいかと。
0438デフォルトの名無しさん2022/07/22(金) 17:12:05.71ID:efNbKFVE
安全性とゼロコスト抽象化の制約下で開発効率を高める仕組みを導入していることがRustの特徴だよね
言語仕様や処理系実装上での苦労や工夫はいろいろあるが、それらによって実現される機能自体が目新しいものというわけではない
0439デフォルトの名無しさん2022/07/22(金) 17:40:06.82ID:whw2xWQR
Rustが発明したのかどうかはしらんけど、Borrow Checkerは他の普通の言語にはない仕組みで、目新しく感じるけどなあ
Borrow Checkerが効かないようなコードを書くんだったらRustを使う意味が感じられないぐらいにはね
0441デフォルトの名無しさん2022/07/22(金) 18:05:15.33ID:K++ItniC
Borrow checker自体は2000年頃のCycloneの時点でほぼできていたっぽい
Rust独自なのは多分shared xor mutableとmove by defaultじゃないかな
0442デフォルトの名無しさん2022/07/22(金) 19:11:51.06ID:yoEBUVfk
>>437
そう。
C++には何でもある。
それが欠点。
必要なものに厳選して誰でも使えるようにしたのがRust。
C++のアイデアとJavaの実用性、二つの遺伝子を組み合わせたのがRust。
ちなみにお母さんがJava、お父さんはHaskellという建前だけど、本当のお父さんはC++。
Haskellさんは、自分の子供だと信じてる。
0444デフォルトの名無しさん2022/07/22(金) 21:16:25.55ID:i57cd+Nw
>>442
javaの立ち位置なんて、無関係な癖に建物の影からチラチラこちらをうかがって変な妄想してる気味悪い知らない奴だよ。
0445デフォルトの名無しさん2022/07/22(金) 21:29:36.07ID:zWgtMzpY
>>435
あの人はプログラミング能力だけの人じゃなくてDBとか分散システムのアルゴリズムが主戦場の人でしょ。
プログラム読み書き堪能に越したことはないけど、そこだけで人を評価するのは視野が狭いよ。
0447デフォルトの名無しさん2022/07/23(土) 05:40:41.12ID:xoLMiefm
>>435
C++だけでなくRustも理解できてない?


純粋に疑問なんですけどRust使ってる中で「値オブジェクトマジ助かる!」って事あるんですか。
適当に参照で渡したデータが意図せず書き換えられて伝搬して困る典型ケースはコンパイラが潰してくれる認識なんですが。
0448デフォルトの名無しさん2022/07/23(土) 08:37:27.70ID:0xKT+wLu
>>447
それはRustじゃなく値オブジェクトを理解できてない
院卒の新人だったりしない?
0449デフォルトの名無しさん2022/07/23(土) 09:37:03.85ID:bR39w9BX
Googleは金の亡者
0450デフォルトの名無しさん2022/07/23(土) 11:55:37.32ID:8Uydd8B4
>>448
低レイヤーのプログラマーは値オブジェクトとか知らないほうが普通
アーキテクチャ設計といったらCPUやメモリアーキテクチャの事だと思ってたりするw
0451デフォルトの名無しさん2022/07/23(土) 13:10:56.93ID:RBxCW/xN
OwnershipルールとReferenceルールがWhat
Borrow CheckerはHowに相当

Howにももちろん価値はあるが
それと同じくらいWhatをシンプルに絞り込んだものにしたことにも価値がある

後知恵で見れば当然に見えるようなシンプルなルールを作るのはものすごく難易度が高い
0452デフォルトの名無しさん2022/07/23(土) 16:15:20.09ID:tefRxlpq
>>451
わかる
Rustのメモリ周りや、UnixとかRISC-Vみたいに、システムを動作させるに必要な機能の数をできるだけ小さくするのって難しいけど、完成品を見ると当たり前じゃんみたいな印象を受ける
0453デフォルトの名無しさん2022/07/23(土) 18:34:20.81ID:u2Y0Vizw
>>445
残念ながらスパナーとか普通に実装してるgoogleにおいてはあんまり価値のある能力ではないよ。
0454デフォルトの名無しさん2022/07/23(土) 19:04:05.94ID:ehQy/P8s
ISO、C++標準化委員のグレイドン・ホアレ氏はC++0xの標準化過程で、後方互換性を削ぎ落せば理解しやすくなることに気が付く。
そして私的プロジェクトとして実装し始めた。
2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
0455デフォルトの名無しさん2022/07/23(土) 19:21:14.26ID:NE7ljYY1
C++標準化委員の人でもあったんか
それにしてもRustっていいネーミングだよな
なんかしっくりくる
0456デフォルトの名無しさん2022/07/23(土) 19:57:02.71ID:uphZtYPd
正直なところ一般的な単語とか1文字とかの言語名はやめて欲しいと思わなくもない。
0457デフォルトの名無しさん2022/07/23(土) 20:43:26.21ID:PgM2fTTz
>>453
逆じゃね。自分たちで作ってるからこそアルゴリズム方面の知識の意味があるのでは
0460デフォルトの名無しさん2022/07/23(土) 21:28:49.17ID:zqWGCIwO
>>456
昔は大変だったけど今時はグーグルさんもだいぶ賢くなって来たから〇 言語や〇 langでいける
0461デフォルトの名無しさん2022/07/23(土) 22:37:12.56ID:SkYdpzS6
>>454
>2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
2006年の間違いじゃない?

ちなみに>>451に書いてるReferenceルールやBorrow CheckerはGraydon時代にできたものじゃないよ
0463デフォルトの名無しさん2022/07/24(日) 09:29:10.51ID:TkuAh24s
RustじゃなくてHoareの方が検索性は高かったと思う
言語に自分の名前つけたっていいじゃん、最初だけイタい人扱い受けるだけだし
0464デフォルトの名無しさん2022/07/24(日) 12:23:10.54ID:A2ivE9+A
でも本当にHoareなんて名前付けたら絶対Tony Hoareのほうだと思われるやろな
0466デフォルトの名無しさん2022/07/24(日) 13:06:01.37ID:hnBeY/7d
木村拓哉と苗字が同じ木村君みたいな。
0469デフォルトの名無しさん2022/07/24(日) 13:48:30.68ID:q7gbemmZ
新言語を作る際にはありふれた言葉を使うなってコンセンサスがあれば…

C java go Perl Ruby Rust ...
0470デフォルトの名無しさん2022/07/24(日) 13:53:14.16ID:iVL8opWs
せめて後ろに +lang した名前を正式名称にしてくれりゃなあ
Javalang、Clang、Golang、Rustlang...
clangは名前衝突するから今更ムリだけど
0471デフォルトの名無しさん2022/07/24(日) 14:08:13.51ID:6QULAMze
RustとかGoはもう今じゃメジャーだから大分マシだけど
上の方に出てるCarbon?だのみたいな新しい知名度低いようなのにとっちゃ検索されづらいのって結構大きいデメリットじゃないのかね
0473デフォルトの名無しさん2022/07/24(日) 17:26:22.59ID:AIK5SBoS
Rustでは検索にこまったことないけどなぁ
CやGoではそれなりに困ったことある
特にC
0475デフォルトの名無しさん2022/07/24(日) 18:34:31.10ID:kd/zxSl1
Pythonはまさかちょっとしたイタズラ心で命名した言語が
30年経ってこれほどまでに普及するとは思ってないだろうなぁ。
0477はちみつ餃子 ◆8X2XSCHEME 2022/07/25(月) 09:42:55.60ID:OE8E5RfU
パーソナライズ (その人のアクセス傾向を検索結果に反映する) がそこそこ機能してるっぽいという話はあるなぁ。
個人情報保護の法律との兼ね合いが難しいみたいだが。
0480デフォルトの名無しさん2022/07/25(月) 14:10:01.30ID:fotNOYOj
全然、思想や人柄が違う人を後継者に立てようとしても無理が有るな。
0481デフォルトの名無しさん2022/07/25(月) 19:30:13.93ID:qs4kuyp6
>>456
その例でいってとにかくクソダメなのが Go
言語仕様も前時代的なウンコみたいな仕様だが何がだめといって名前がクソすぎ
ついでにいうとマスコットが致命的にキモすぎる
0482デフォルトの名無しさん2022/07/25(月) 20:08:08.67ID:uz33IoOs
goはgolangって呼び方が一般化してるから問題なくね?
親会社もalphabetだし、仮に一般名詞でも検索してやんよっていう自信の現れなのかも。
あとlisp monsterのほうが可愛いよね
0484デフォルトの名無しさん2022/07/25(月) 21:42:28.43ID:GF1rw+EH
ゴラン高原はイスラエルが不法に占領してるシリアの土地であり、日本政府はシリア高原と呼称するそうだぞ。
0485デフォルトの名無しさん2022/07/26(火) 07:10:48.91ID:4TZ4RWr2
今ちいかわってキモいキャラが流行ってるように
Gopherくんもいずれ世界的なマスコットキャラクターになるよ
0487デフォルトの名無しさん2022/07/26(火) 08:15:07.77ID:RlhOzjvN
今マイコン用クレートでメジャーなのってどのあたり?
自分で作るにあたり参考にしたいのだが
0489デフォルトの名無しさん2022/07/26(火) 08:37:23.50ID:jFWmtimM
言語の名前がGopherだったらよかったのに
0491デフォルトの名無しさん2022/07/26(火) 09:38:10.98ID:hAg2HYen
プロトコルはイーサリアムとビットコインで実現出来ます
この2種類以外は今後不要になります
0494デフォルトの名無しさん2022/07/26(火) 11:19:17.05ID:wEdk200U
Web3なんて流行るわけねーだろ
スマートコントラクトの開発コスト高すぎ&不便すぎ
0498デフォルトの名無しさん2022/07/26(火) 12:14:19.05ID:/Gebh7sM
Etherはイーサーだけど
Ethereumはァセーリアム
日本語読みだと外人に通じないから注意な
05064872022/07/27(水) 07:28:03.29ID:6+JEeGDS
>>499
ありがと。見てみます
どのくらいのさじ加減が使いやすいのかが難しい・・・
0507デフォルトの名無しさん2022/07/27(水) 07:32:05.65ID:6nSf0k+r
>>503
ダイハツの軽自動車
0510デフォルトの名無しさん2022/07/28(木) 00:38:58.21ID:z/Vvst4i
アレはAptosとして生き残った
大型の資金調達を連発して次の投機の標的になってる
0511デフォルトの名無しさん2022/07/30(土) 22:19:27.63ID:wZaxY20D
std::io::Result<()>
↑の()ってなんすか?
Ok(());
↑の()も。
「空」を意味してるってことでいいんですか?
0512デフォルトの名無しさん2022/07/30(土) 22:34:27.43ID:PnFWbFUc
5つの何かを返す関数なら
return (a, b, c, d, e);
0つの何かを返す関数なら
return ();
と考えてもよく何も返さないこと
0517デフォルトの名無しさん2022/08/02(火) 23:33:57.17ID:FkNkpg49
bevyとFyrox Engineはどちらの方が良いのかな
人気度はbevyな気がするが
0520デフォルトの名無しさん2022/08/04(木) 12:38:32.91ID:pLEfRi/j
エディタとかツールの機能拡張だよ。
RubyとかJVMとかある程度の動的さを持つランタイムがあると開発楽だけど、GoやRustみたいにスタティックリンク、シングルバイナリが基本になると
たしかにwasmベースで作るのが筋が良いのかねぇ。
0522デフォルトの名無しさん2022/08/04(木) 13:50:49.10ID:ck4xiQdl
クロスプラットフォームで同一バイナリが動いてそこそこ高速で組み込み用途に向いてる
という条件だとLuaかwasm
0524デフォルトの名無しさん2022/08/04(木) 15:10:31.96ID:b+TNnTjV
プラグインというよりマクロの実行環境の話だな
Luaやwasmはホストアプリにランタイムを同梱する必要がある
0525デフォルトの名無しさん2022/08/04(木) 15:23:41.09ID:1k9fnhsy
Luaやwasmを使うようなスクリプト型(スクリプト言語のことではなくて、上位レイヤのシナリオだけをユーザーに書かせる方式)の拡張って、
よほどホスト側にプラットフォームとしての魅力がない限りは成立しないよ
ホストがスクリプトに対して提供している機能以上のことはできないわけだからな
そうじゃなくて、やりたいのはホストにない機能を追加できるプラグイン機構じゃないの?
0526デフォルトの名無しさん2022/08/04(木) 15:39:46.71ID:9TNfUmNd
>>520
Rustでやりたいってことは実行速度を重視してるんだろうし動的リンクしかないだろ
しかしwasmにしてもいいっていうならJavaScriptやらLuaの活用も検討しろ
0527はちみつ餃子 ◆8X2XSCHEME 2022/08/04(木) 15:55:10.42ID:hPtMGH66
そういえば Rust の proc macro を wasm としてコンパイルしたらどないやという話はあったんじゃなかったっけ?
最終的にどういう結論になったのか追ってないんやが……。
必要な機能は Rust コンパイラの中に全部あってシステムの外とやり取りする必要もないから良い案に思える。
0528デフォルトの名無しさん2022/08/04(木) 17:17:23.18ID:KbhCPu0a
>>525
Luaやwasmからホストの用意した機能を呼び出す形だけでなく
ホストからLuaやwasm側の処理を呼び出す形も実装可能だよ
DLLに比べると相当手間がかかるけど
0529デフォルトの名無しさん2022/08/04(木) 17:19:43.26ID:ck4xiQdl
動的リンクするにしてもABIがunstableだからインターフェースはextern "C"で公開せざるを得ないし
それなりの量のグルーコードが必要になるかと
その辺良い感じにどうにかしてくれるcrateがあるかもしれないけど
0530デフォルトの名無しさん2022/08/04(木) 17:29:05.26ID:1k9fnhsy
>>528
そうしたとしてもホスト側に存在しない(ホストからスクリプトに対して公開されていない)機能は使えないでしょ?
0533はちみつ餃子 ◆8X2XSCHEME 2022/08/04(木) 17:58:11.58ID:hPtMGH66
>>530
ホスト側を経由せずに外にアクセスするのは禁止できたほうが嬉しいことも多いだろ?
俺が使っているソフトでプラグイン機構があるものというと画像ビューアとかメッセンジャとかだが
それほど自由に外の世界にアクセスする必要はないし、不必要ならアクセスさせないに越したことは無い。
(悪意あるプラグインを作り難くなるので。)

制限があるというのと制限を付けられるのは表裏一体なのでそんなの場合によるとしか……
0534デフォルトの名無しさん2022/08/04(木) 18:01:34.69ID:9TNfUmNd
>>529
> 動的リンクするにしてもABIがunstable
あー、そうだったわ
めんどくさいんだった
0535デフォルトの名無しさん2022/08/04(木) 18:42:08.03ID:pLEfRi/j
野良プラグイン入れて環境壊して上等!って時代でもないからねえ。
ある程度、できること制限できるようにしたプラグイン機構も大事な時代よ。

そういう点でwasmがセキュリティとパフォーマンスのバランスが取れていて魅力という層もあるでしょ。
0536デフォルトの名無しさん2022/08/04(木) 18:42:45.33ID:KbhCPu0a
>>530
そりゃ広い意味で言えばどんな機能だってホスト側に存在してなければ使えない

「ホストにない機能を追加できるプラグイン機構」ってどんなものイメージして言ってるの?
0537デフォルトの名無しさん2022/08/06(土) 12:18:12.84ID:z/fLyAW1
今の環境で正しくレンダリングされる10年前に作られたWebサイトは多くない
同様にTauriで作成されたアプリが10年後でも問題なく使用できるのだろうか
0538デフォルトの名無しさん2022/08/06(土) 20:40:11.73ID:6gQA87rg
Tauriはバックとフロントが明確に分離されているからOS標準ブラウザに変更があっても修繕はしやすそう
Macとかだと突然仕様変えてきそうで怖いな
0539デフォルトの名無しさん2022/08/07(日) 00:00:20.59ID:pGypWfdH
Rustでライブラリをどうやって選定してんの?
crate.io見て人気のを選んでんの?

GETだけのためにhttpclient使おうとしたらtokio入れて使えとか全然意味わからんしコンパイルしたら
これを使うには2018使えと2022使えが出てくる…


他のに変えても変わらず
GETなんてコピペ産業で実現させてくれよ

use
初期化
GET

これで終わらせてくれ
0541デフォルトの名無しさん2022/08/07(日) 00:19:22.87ID:thO2Aez3
>>539
まあ今はそういう人向けの言語じゃないからね

とりあえずreqwestのblocking clientでやってみて合わなそうならあきらめろん
0542デフォルトの名無しさん2022/08/07(日) 00:27:13.75ID:pGypWfdH
crate.ioにwebclient一覧が並べてあるけど結局最近のダウンロード数見て判断なんだろうなと

どれもtokio使ってるしCurlコマンドみたいに一発でGETやPOSTって感じでもない
tokio必須と言うことは標準でasyncライブラリの完成度が低いんだろうけど
憶測が当たってるかどうかもよくわからない
0543はちみつ餃子 ◆8X2XSCHEME 2022/08/07(日) 00:48:31.33ID:yGip1YMx
>>542
Rust は標準ライブラリの中に非同期ランタイムを持ってない。
言語として非同期を扱えるようにしつつ具体的な部分は外部のクレートに任せられるように
分離に成功しているという意味では十分に完成度は高いとも言える。
0545デフォルトの名無しさん2022/08/07(日) 05:20:01.36ID:FgVTxKNL
簡単に使いたいなら、非同期じゃなくて同期版のhttpクライアントライブラリ使いなよ
0546デフォルトの名無しさん2022/08/07(日) 08:15:04.13ID:PrNdTuny
Goを素直に使っとけ
標準ライブラリでそのままできる上に非同期もGoroutineを使うだけ
テスト用のライブラリも用意されてるからクライアントサーバーもそのままテストできる
0548デフォルトの名無しさん2022/08/07(日) 08:29:14.86ID:PrNdTuny
標準ライブラリでHTTPクライアント・サーバー・テスト・非同期を全て統一的に扱えるってのはかなり強みではある
Rustはランタイムコストをゼロに近づけるためライブラリ化しているが、それは必ずしも利用者にとってメリットがあるわけではない
あくまでもOSやドライバなどを作る上でランタイムコストを削らないと適さないからそうなっているだけ

>>539 みたいな人にはまず用途を考えた上で高レイヤーのプログラムを作りたいのであれば素直にRust以外の言語を使うことをお勧めする
0549デフォルトの名無しさん2022/08/07(日) 08:59:18.95ID:9InYic2G
>>548
あまりにも狭い視野と酷い誤解をなさっているようだが
ウェブ関係はRustのメリットが十分にある分野で実際にRustで利用が多い分野
0550デフォルトの名無しさん2022/08/07(日) 09:24:53.04ID:OveVhBWN
複オジ相手にするのは隔離スレか実質隔離スレの次世代スレだけにしろ
0551デフォルトの名無しさん2022/08/07(日) 09:37:06.87ID:VV/7IoC0
>>548はいつものRustアンチのキチガイかな
RustはOSやドライバ用と嘘をついてそれ以外なら他の言語を使うべきと誘導する書き込みがそっくり
0554デフォルトの名無しさん2022/08/07(日) 12:50:43.08ID:45kFT7pS
次世代スレの方もワッチョイ付ければ例のバカが寄り付かないことがほぼほぼ実証されつつあるので
あとは過疎を恐れず移行すれば万事解決です
0557デフォルトの名無しさん2022/08/11(木) 07:14:02.75ID:wbWFySKV
structに不変なフィールドを持たせるにはどうしたらいいのですか?
const定数ではなく、インスタンスごとに初期化時に値を設定したら、その後は変更不可能。
他のフィールドは変更可能でも。
0558はちみつ餃子 ◆8X2XSCHEME 2022/08/11(木) 10:33:56.78ID:5k4DsUHs
>>557
直接的にメンバに指定を付けることは出来ない。
Rust のアクセス制御はモジュールが基本単位になっていて、
「メンバに pub が付いていない」「そのモジュールの中でメンバを変更することがない」ならば変更不可能なメンバになる。
0561デフォルトの名無しさん2022/08/13(土) 13:54:36.73ID:QcomGE6R
>>560
言語としてのRustにはピクリとも興味がわかなかったが
なんだか急にRustに興味がわいてきたぞー
0562デフォルトの名無しさん2022/08/16(火) 13:03:21.19ID:RcKGtcJQ
VSCode + CodeLLDB + LLDBでデバッグしているのですが、ポインタに関して見方がよくわかりません
Borrowed pointer typeの参照先の値ってデバッガ上でどうやったら見れるんですか?
0565デフォルトの名無しさん2022/08/19(金) 15:56:19.49ID:WZnrgrRN
今の時代ってcc++rustなんて、低レイヤーをやってる人以外は不要だな
Java Script全盛のこの時代にいちいちコンパイルするなんて面倒で仕方ない
0567デフォルトの名無しさん2022/08/21(日) 14:52:30.50ID:j3ukytx2
RUST大流行だな
ほんと紛らわしい
0568デフォルトの名無しさん2022/08/21(日) 17:28:20.00ID:zaSnZ+Z6
この言語開発した人、Swiftにいっちゃったみたいだけど追い出されたの?
0571デフォルトの名無しさん2022/08/22(月) 12:22:08.49ID:+Lu+Ewk5
ジャバスクリプト全盛の時代にネイティブこんぱいらなんて
不要だろ。
jsでカーネルのラードンをつくる猛者まで出てきた
0572デフォルトの名無しさん2022/08/25(木) 01:05:28.98ID:YZq8nn1p
Arc<HashMap<T1, T2>>みたいにした場合って、どの範囲でスレッドセーフになるんですか?
0573デフォルトの名無しさん2022/08/25(木) 02:02:11.07ID:sE5vq5kZ
範囲はHashMap全体たが
Arc単体で提供するスレッドセーフはimmutableな共有所有のみ
その例だとHashMapは読み取り専用になる
他を要求するなら他と組み合わせる

まずArcは置いといて単独所有の時
整数やブールならAtomicXxxでスレッドセーフ
一般的な型ならMutex<T>
読み取り同時複数ならRwLock<T>
それぞれコストが異なるので使い分ける

その上で共有所有ならArc<.....>をそれらの上に被せる
0576デフォルトの名無しさん2022/08/25(木) 23:42:19.60ID:3Alfspxr
条件を満たせなければコンパイラが指摘してくれるところがRustの良さ
間違えていても安全でなくてもコンパイルが通ってしまい実行時に酷い目に合う従来の言語
0577デフォルトの名無しさん2022/08/26(金) 03:34:10.56ID:7ybirmBf
Test
0578デフォルトの名無しさん2022/08/26(金) 10:06:51.61ID:i2SIEm4o
>>576
コンパイル通ったら安心と思い込む馬鹿
0582デフォルトの名無しさん2022/08/27(土) 03:03:50.30ID:TTfNOQhF
>>578
うちの会社にもいるわ
ビルド出来たってドヤ顔のバカ
そんなものは、ある程度の言語の知識があればいいだけ。
0589デフォルトの名無しさん2022/08/31(水) 09:32:55.55ID:Ln42v62t
急に書き込み減ったけどもう飽きられたの?
Scalaのときもそうだったけどエンジニアがこういう読みにくい言語で現場を遊び散らかして負債だけ残すの何とかして欲しいわ
0590デフォルトの名無しさん2022/08/31(水) 09:53:20.72ID:WKGTXtBk
?の意味とか;の違いとか、すぐに調べられないからバッドノウハウ化しているよね。FAQとかダメダメだし。
せめて検索性に配慮して記号を決めればな。?::くらいにしても問題ないだろうに。
0591デフォルトの名無しさん2022/08/31(水) 09:56:03.10ID:rQxi5a/d
ピークを過ぎた感はある
Scalaで遊んでたのはDDDとか高レイヤの好きな意識高い系が中心だったからまあそこまで酷い負債にはなってないけど、
その点Rustの負債はタチが悪そうだな
0592デフォルトの名無しさん2022/08/31(水) 10:04:18.55ID:RT2RvDVv
Amazonがプログラミング言語「Rust」を使っている理由
https://japan.zdnet.com/article/35183866/

Amazon Web Services(AWS)は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、GoogleやMicrosoftとともにRust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。

AWSのソフトウェアエンジニアで、Rustの普及に取り組む、
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100%を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service(S3)」「Amazon Elastic Compute Cloud(EC2)」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。

「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50%削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
0593デフォルトの名無しさん2022/08/31(水) 10:44:22.32ID:nTGfEW2M
>>590
そういう基本的なのはチュートリアルに書いてあるんだから何をあらためて検索する必要があるっていうんだ?
0596デフォルトの名無しさん2022/08/31(水) 12:34:08.26ID:J/OAC0EF
例えば
question mark site:doc.rust-lang.org
で検索すれば必要な解説がすぐ見つかる
0597デフォルトの名無しさん2022/08/31(水) 12:53:27.03ID:+Igep1U8
>>593
公式に「チュートリアル」てあったっけ?
THE Book読めということかしらん?

>>594
Error propagationとかStatement and item terminatorぐらいしか記載無いんだけど……

>>595
公式の解説出てこないんだけど、公式には説明無いんかね?
0598デフォルトの名無しさん2022/08/31(水) 13:07:27.93ID:+Igep1U8
>>596
おお、ここまで指定すれば見つかりますな。公式トップに検索窓ぐらい欲しいところだけど。
0599デフォルトの名無しさん2022/08/31(水) 13:18:26.51ID:Fgf/9Zy6
>>597
エラーとか文に関わるものということが分かれば、関連するリファレンス探すとっかかりにはなるんじゃないかと
少なくとも記号よりは検索しやすい
0600デフォルトの名無しさん2022/08/31(水) 13:39:17.87ID:lcZ+Kyy5
所有権チェックはありがたいけど、lintみたいにビルドと分けた方が使い勝手よかったと思うがな。
0601はちみつ餃子 ◆8X2XSCHEME 2022/08/31(水) 13:42:22.79ID:nTGfEW2M
>>597
> THE Book読めということかしら

せやで。
まあそれに限らなくてもいいけどどんな入門書でも ? の説明がないなんてことはないでしょ。
常識的な手順通りに学習してれば ? が大まかに何をする演算子なのかくらいは知っているはずだし、
エラー処理にかかわるものだと知ってればもっと細かいドキュメントを探すのにも苦労するってことはない。

なるべく一発で検索できたほうが便利というのはわからんでもないが、
演算子であると同時に制御構文の類でもあり、周辺の機能と連携するのできちんとした理解をしようとすれば
どうせ色々と見るはめになる。
0602デフォルトの名無しさん2022/08/31(水) 15:08:14.60ID:Fgf/9Zy6
>>600
所有権チェックをなくすってどういうこと?
referenceが有効な間に元データをmoveした場合に警告だけ出してコード自体はコンパイルできるようにするとかそういうこと?
0603デフォルトの名無しさん2022/08/31(水) 16:15:20.37ID:bi3oBo/Y
コンパイル(ビルド)時に所有権チェックの結果を使ってメモリの解放処理を挿入してるんだから分けるのは無理
0604デフォルトの名無しさん2022/08/31(水) 16:22:04.68ID:UXqUoG+N
ビルドしなくてももっと気軽にわかるようにしろってことか?
linterの領域外れてる気もするが
0605はちみつ餃子 ◆8X2XSCHEME 2022/08/31(水) 16:50:31.19ID:nTGfEW2M
細かな所有権の整合性を後回しにしてとりあえず動く (ように見える) ところまでもっていきたいという気持ちはわからんもでない。
でもなー、そういうことすると整合性がとれてないままの未定義コードが世に溢れてしまうのは確実だろう。
0606デフォルトの名無しさん2022/08/31(水) 16:56:11.73ID:LCT5ihCl
所有権周りのエラーって基本的なデータ構造に起因することが多いからなぁ
後から直そうとか思うと結局全部作り直すはめになるから
一度チェックなしモードとかで作っちゃうと永遠にそのままだろうね
0608デフォルトの名無しさん2022/08/31(水) 19:07:16.13ID:th8cAM8K
>>592
そのうち、他の分野のライフサイクルみたいに、製造時、利用時といった感じで電力効率が語られるようになるんかね。
0609デフォルトの名無しさん2022/08/31(水) 20:09:18.42ID:iogMBVhq
>>601
the book読めというのはさすがに初心者殺しだと思うけどなぁ。

公式に絶壁の学習曲線をどうにかしようという意識はあるのかしらん?
0610デフォルトの名無しさん2022/08/31(水) 20:22:19.87ID:3b0JioqE
学習曲線をどうにかしようという気合はめちゃめちゃあるが、バカを賢くしようというつもりはないだろう
0611はちみつ餃子 ◆8X2XSCHEME 2022/08/31(水) 20:35:16.89ID:nTGfEW2M
>>609
えっ、なじみのない所有権システムとかも含めてめっちゃわかりやすく解説した the book を
用意してくれるなんてスゲー親切だと思うが、何が不満なんだ?
(俺自身は英語あんまりわからんので日本語訳を読んだ。)
0612デフォルトの名無しさん2022/08/31(水) 20:38:24.92ID:SRFkQuBk
>>609
the bookは初心者のためのもの
Rustを全く知らなくてもちゃんと順を追って理解できるように書かれている

?は自分でエラー処理を書くようになり、
さらに自分の関数でResultなどを返すようになり、
そこでErr(e) => return Err(e)などを書くようになり、
そこでのショートカット表現として必要になるものだから
the bookでも同じ順で学べる

?をいきなり調べたい時や詳細を知りたい時は
the Rust referenceを開いて🔍をクリックして
question markと打てば該当ページに辿り着く
0613デフォルトの名無しさん2022/08/31(水) 20:53:00.34ID:bW00GV9W
>>605
>>606
同意。
0618デフォルトの名無しさん2022/09/01(木) 01:28:45.35ID:v92yFclD
今時、ネイティブ吐く必要なんて全くない
tsでもvscのようなソフトが作れるんだし。
ユーザーランドではネイティブはもはや不要だろ
0621デフォルトの名無しさん2022/09/01(木) 09:29:49.86ID:WQm7Gv/J
vscはコア部は全部C++だけど。
そのうえに薄くjs乗ってるだけやがな。
0622デフォルトの名無しさん2022/09/01(木) 09:46:54.90ID:NH2cx+n6
Tauri (Rust) vs. Electron (C++)の戦いの結果…

> Electronの代替を目指す軽量なRust製フレームワーク「Tauri」
https://www.publickey1.jp/blog/22/electronrusttauri.html

> Electronはフロントエンドの基盤としてChromiumを組み込んでいますが、
> Tauriでは代わりに各OSが備えているWebViewの機能を、抽象化レイヤのwry経由で呼び出すことで、
> クロスプラットフォームを実現しつつChromiumを不要にしています。
> フレームワーク内にChromiumを組み込まないことでセキュリティも向上すると、Tauri開発チームは説明しています。

 ↓ 「マジ?!」と思っていたらマジだった!!

>開発フレームワーク「Electron」に複数の脆弱性
https://news.mynavi.jp/techplus/article/20220818-2426640/

>Electronは、HTML5やCSS、JavaScriptといったWeb技術を用いてデスクトップアプリケーションを開発することができるフレームワークで、
>Microsoft TeamsやVisual Studio Code(VSCode)、Discordなどの人気アプリケーションでも利用されている。
>今回のElectronの脆弱性に関する発表は、米国で開催されたサイバーセキュリティカンファレンス「Black Hat USA 2022」の次のセッションで行われたもの。
>研究チームがElectronを使用して開発された20のアプリケーションを調査し、そこで発見された複数の脆弱性について報告した。
>発見された脆弱性の一例としては、以下が挙げられている。
>・VS Codeにおけるリモートコード実行の脆弱性
>・Discordにおけるリモートコード実行の脆弱性
>・Microsoft Teamsにおけるクロスサイトスクリプティング脆弱性
>・ChromeのCSP(Content Security Policy)バイパスの脆弱性
>・V8のリモートコード実行の脆弱性
0625デフォルトの名無しさん2022/09/02(金) 22:13:08.24ID:06QeBluE
--emit asmで吐かれるアセンブラリストのフォーマットの資料ってどっかにある?
gas系っぽく見えるけどちょいちょい判らないのが・・・
0627デフォルトの名無しさん2022/09/04(日) 14:45:48.94ID:c9grlmUi
VScodeがもっさりは感じたことないな
ネイティブのVSのほうが重すぎ
0628デフォルトの名無しさん2022/09/05(月) 15:09:06.52ID:LmWvGk9l
関数の入出力はu8だけど関数内の計算はi32で行いたい場合って普通どんな感じで書くの?
06336282022/09/05(月) 17:50:42.31ID:Y4+oTyIj
例えばこんなの
fn func(x: u8, y: u8) -> u8 {
 let x32 = x as i32;
 let y32 = y as i32;
 let z32 = (((x32 - y32) * 170) >> 16) + y32;
 return z32 as u8;
}
4行使うのは冗長かなーと思わなくもなく・・・
テンポラリ変数の名前を考えるのもちょっと面倒だし
0635デフォルトの名無しさん2022/09/05(月) 19:20:47.36ID:g3RfqaIY
>>633
行数短くしたいだけなら

fn func(x: u8, y: u8) -> u8 {
 let (x, y) = (x as u8, y as u8);
 (((x - y) * 170) >> 16) + y) as u8
}

とは書けるけどやってることは全く同じだしこれで期待に応えられてるかは分からん
0637デフォルトの名無しさん2022/09/05(月) 21:29:56.32ID:wI2HBmBd
>>633
その例は手動で最適化すると
fn func(_x: u8, y: u8) -> u8 {
 y
}

それはともかく
行数を節約したいという間違った価値観を捨てることをおすすめ
0640デフォルトの名無しさん2022/09/06(火) 00:31:42.49ID:EiVnVIDc
結局u8で返すなら
途中でi32使わずとも
工夫するとu8のままだけで算出できちゃったりするわけか
06436282022/09/06(火) 11:02:40.94ID:xGSGq1SQ
スタンダードな書き方みたいなのはないのかな
なら>>634で行こうと思います

あと>>633は右シフトを間違えていました
16ではなく8です
0644デフォルトの名無しさん2022/09/07(水) 08:11:56.26ID:8saglJYc
Rustのバイトオーダーってそのターゲットのネイティブ(x64ならリトルエンディアン)で良いの?
0645デフォルトの名無しさん2022/09/07(水) 08:24:04.31ID:41cUJGIp
もちろん
そして依存しないよう3種類用意されてる
assert_eq!(0x01020304, u32::from_be_bytes([1, 2, 3, 4])); // big endian
assert_eq!(0x04030201, u32::from_le_bytes([1, 2, 3, 4])); // little endian
assert_eq!(XXX, u32::from_ne_bytes([1, 2, 3, 4])); // native endian
0646デフォルトの名無しさん2022/09/07(水) 23:31:51.68ID:qqHULq33
native endianというのは初めて聞いたのですが、これはどういうものなのですか?
0647デフォルトの名無しさん2022/09/07(水) 23:54:21.35ID:En8I5Kb5
この場合 >>644も書いているようにコンパイルターゲット環境のエンディアンのこと
特にターゲット指定がなければ自分の使っているPC環境で通常はx64などlittle endianになりますが
そこでleと指定してはダメで環境に応じて適切に対応させるためにneを使います
一方でAPIなどでエンディアンが指定されてる時は指定通りbeかleを使います
0648デフォルトの名無しさん2022/09/08(木) 00:04:41.95ID:nmwPOGZ0
>>645
サンクス。u32とかにはfrom_leとかあるみたいですね。こっちの方が使う機会は多そう
デフォルトのバイトオーダーを変更したり、変数やフィールド単位でバイトオーダーを設定する
みたいな芸当は流石に無理なのかな・・・ググったけどそれっぽい情報は見つけられなかった
0649デフォルトの名無しさん2022/09/08(木) 00:19:17.65ID:8UoQH6yi
>>648
操作に最適なバイトオーダーは使用CPUで決まるネイティブエンディアン
だから原則としてネイティブエンディアンのみでプログラミングする
例外として外部とのやりとりなどエンディアン指定がある時はその境界で変換
0650はちみつ餃子 ◆8X2XSCHEME 2022/09/08(木) 00:23:28.76ID:MG9wnc1h
>>648
内部的に色々な表現を有りということにするならやりたい操作を個別に定義するしかないよ。
でも普通はそんな煩雑なことをしたくないから
内部的には一環した表現を使って必要な変換は入出力のみというのが一般的な構成だし、
言語やライブラリも基本的には一般的な構成に倣っている。
0651デフォルトの名無しさん2022/09/08(木) 01:11:28.44ID:U6/gufpm
>>648
変数やフィールドのメモリ上の表現が特定のエンディアンにしたいのであれば、
#[repr(C)]
struct BeU32([u8; 4]);
みたいな構造体を用意して
impl Be32 {
fn get(&self) -> u32 { u32::from_be_bytes(self.0) }
fn ser (&mut self, v: u32) { self.0 = v.to_be_bytes(); }
}
こういうアクセサを実装すれば良いかと

何の役に立つのかはよくわからないけど、特定のエンディアンでシリアライズされたデータにそのままアクセスしたい場合とかに便利なのかな
0653デフォルトの名無しさん2022/09/08(木) 15:55:57.30ID:Vswe11EN
RustをOpenMPIに対応させるようなプロジェクトってありますか?
0656デフォルトの名無しさん2022/09/08(木) 20:45:38.87ID:Vswe11EN
知りたいのはOpenMPIの方です
ググるとOpenMPIとOpenMPを勘違いしたと思われるRayonを紹介する記事が出てきたり、OpenMPがらみのサイトが出てきたり、なかなか状況が分かりません・・・・
0658デフォルトの名無しさん2022/09/08(木) 21:56:17.41ID:fa0yFdt8
MPIはHPC以外では使う必要ないです
機械学習でも有用だとは思いますが
そもそもフレームワークが対応していないから
全部自前で作ってるような人以外は必要ないです
0659デフォルトの名無しさん2022/09/09(金) 01:14:31.51ID:4b4Wyf25
Open MPIに限らずMPIはアプリから見たらただのライブラリだからRust側で特別な対応は不要で単にCの関数を呼び出せばよいだけでは
0660デフォルトの名無しさん2022/09/09(金) 08:12:49.36ID:auDHI5c1
良くありがちな奴だと思うけど
struct ARGB32 {A: u8, R: u8, G: u8, B: u8,}
みたいに書くとスネークケースじゃないと警告が出るけどどう書くのがRust流なの?
これ小文字にしちゃったら少なからず可読性が落ちるよね
0661デフォルトの名無しさん2022/09/09(金) 08:31:41.27ID:WeF8ASv0
#[allow(non_snake_case)]
しかしフィールド名だけ小文字にすれば不要
struct ARGB32 {a: u8, r: u8, g: u8, b: u8,}
そして可読性が落ちると思わない
0663デフォルトの名無しさん2022/09/09(金) 12:29:38.55ID:6YdHvwwi
識別子を極端に省略するのは良くないという現代のプログラミングの流儀と業界の略語でコンフリクトしてるよね。
略語を使わずに書くとこうかね?

Color<T>{alpha: T, red: T, green: T, blue: T}

CMYはどうなるとか言い出すやつがいると面倒そうだけど。
0664デフォルトの名無しさん2022/09/09(金) 12:42:45.67ID:VsTRsG1f
enum Color {
Red,
Blue,
Green,
RGB(u32, u32, u32),
HSV(u32, u32, u32),
HSL(u32, u32, u32),
CMY(u32, u32, u32),
CMYK(u32, u32, u32, u32),
}
0665デフォルトの名無しさん2022/09/09(金) 13:41:22.02ID:4b4Wyf25
最低限ガイドには従った方が良いと思う
https://rust-lang.github.io/api-guidelines/naming.html
acronymはひとつ単語として扱うとあるから Rgb とか Argb とすべき

あとは適当なグラフィック系ライブラリの実装を見て真似してみたら良いのでは
規約に従ってないライブラリも多いけど

そもそも既存crate使えば独自にArgb型定義する必要もなくなるかもしれない
0666はちみつ餃子 ◆8X2XSCHEME 2022/09/09(金) 14:02:11.22ID:gp9Eay33
API ガイドラインってことは、 API として公開しない (内部的な) 名前は雑でいいってことだよね。
0668デフォルトの名無しさん2022/09/09(金) 14:42:45.26ID:4b4Wyf25
>>666
非公開部分を将来公開APIにする可能性や、自分以外の誰かがソース読んでパッチ作ってくれる可能性考えると、
最初から内部も規約に従ったものにしておいた方が良いと思う
そもそもひとつのプロジェクトの中で公開部分と非公開部分で異なる規約混在するのも嫌では
0669デフォルトの名無しさん2022/09/09(金) 15:18:27.40ID:QLGZdL8Z
mozillaは公開できない関数名を使ってオープンソース化が数年遅れた過去があったなぁ。
0672デフォルトの名無しさん2022/09/09(金) 17:53:00.11ID:rfSAUeXI
CreateFileW in windows::Win32::Storage::FileSystem - Rust
ttps://microsoft.github.io/windows-docs-rs/doc/windows/Win32/Storage/FileSystem/fn.CreateFileW.html
とかAPIガイドラインもクソもないけど名前だけRustに寄せたところでリファレンスドキュメント(MSDN)との差異が
拡大するだけでメリットはほとんど無いような
0673デフォルトの名無しさん2022/09/09(金) 21:16:36.10ID:pyHRaXAz
JPEG、MPEG、PNG、HEVC・・・すでに略されている物をありがちな命名規則で書くと判りにくくなる
0674デフォルトの名無しさん2022/09/09(金) 22:46:34.35ID:B0h43lqZ
>>673
同意
0675デフォルトの名無しさん2022/09/10(土) 00:32:32.71ID:qBfKxAEz
>>663
その方向でやってみます

というかこの構造体をArrayに沢山詰めようとすると初期化が難しいのか。どうしようか悩んだ結果こうしてみた
#![no_std]
const LEN: u32 = 640*480;
let mut bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)};
bitmap[0].red = 0xFF;
アセンブラリストを見る限りは問題なさそう
0676デフォルトの名無しさん2022/09/10(土) 01:19:16.36ID:BhJh8aSd
acronymを全部大文字にするか先頭だけ大文字にするかってそんなに大きな問題かな
一貫性のあるルールに従っていれば書き手や読み手として混乱することもないと思うんだが
0677デフォルトの名無しさん2022/09/10(土) 03:00:06.93ID:Rsh0NV07
Ipv4なんて一瞬なんのことか分からんかったな
結局慣れで、一貫性以上に価値のある好みなんてのはない
0678デフォルトの名無しさん2022/09/10(土) 07:09:44.43ID:2MfL7Eat
>>676
その一貫性が崩れるのがいやなんだろ。
ドキュメント・コメントでは全部大文字なのにコードでは先頭だけ大文字とか。
慣れの問題だが、今まで/一般的 に全部大文字で慣れてるものをこの時だけ先頭大文字に慣らせというのは抵抗感あって当たり前。
0679デフォルトの名無しさん2022/09/10(土) 07:12:21.94ID:2MfL7Eat
>>676
問題の大小なんて誰も言ってない。
今までの慣れ/一般的な表記 を置き換えるのは抵抗感あるって話。
0680デフォルトの名無しさん2022/09/10(土) 12:37:11.73ID:GXRB1/O5
命名規則を利用する目的は可読性や開発効率の向上などのはず
一般的な表記から外れるのであればそれなりの理由が必要であろう
「命名規則に従ったから」では「目的より手段を優先している、合理性がない」などと
突っ込まれてもしょうがない
0681デフォルトの名無しさん2022/09/10(土) 13:03:13.98ID:jQKLnU5m
JavaScriptのアイツは
XmlHttpRequestと命名されるべきだったのか?
XMLHTTPRequestと命名されるべきだったのか?
0682デフォルトの名無しさん2022/09/10(土) 13:20:38.77ID:AMhmGX9g
eXtend Markup Language Hyper Text Transfer Protocol Request
0683デフォルトの名無しさん2022/09/10(土) 13:38:53.61ID:D1Nb21qC
完全に好みの問題と思うから何らかのルールで統一されてればどっちでも良いと思うけど、
LCD TV、nVidia、iOS IoT Hubなんかをどう表記するかとか変数名ならどうしようとか考えるのめんどいから
表記の慣例とか無視して全部キャメルケースにしちゃうな
0684デフォルトの名無しさん2022/09/10(土) 13:50:29.86ID:TnGNUz3W
ルールから逸脱させるかどうか悩むならルールに合わせておくおじさんになった
0685デフォルトの名無しさん2022/09/10(土) 14:31:16.93ID:/uHulLcW
Rustすれのレベルの低さにガッカリ
Python質問すれとかみたいに和気あいあいとしてない殺伐にドッキリ
0686デフォルトの名無しさん2022/09/10(土) 14:56:40.59ID:qBfKxAEz
>>675みたいに書いた場合
>let mut bitmap:[u32; LEN] = [0; LEN];
のmutが余計だと警告が出る。この場合実際に確保されるメモリ領域は書き込みも出来るスタックフレームだろうし
mutを取っても動作上は問題ないと思うけど、mutがない領域に書き込むことになりプログラムの意味としては誤っている
参照先を強制的に書き換えるようなコードを書くと、とコードと警告と動作のミスマッチが起きる気がするけど
なんか上手い書き方はないのだろうか

この辺の低レイヤーの用途で参照先を書き換える話ってBookのReferenceやUnsafeあたりにもそれっぽい事書いてないし
どこを見たらいいのか判らない
0687デフォルトの名無しさん2022/09/10(土) 15:47:06.47ID:BhJh8aSd
>>675
ARGB32にDefault実装して
let mut bitmap : [ARGB32; LEN] = Default::default();
とするのが良いかと
repr(C)がついてない構造体のメモリ上での表現がどうなるかは保証されてないから元のコードが意図通り動作する保証はないと思う
0689デフォルトの名無しさん2022/09/10(土) 15:54:53.07ID:BhJh8aSd
>>687
[T; N] は N <= 27 までしかDefault実装されてなかったからこのコードじゃダメだった
こっちならOK

let mut bitmap: [ARGB32; LEN] = std::array::from_fn(|_i| Default::default());
0691デフォルトの名無しさん2022/09/10(土) 16:39:14.44ID:qBfKxAEz
>>687
すみません。構造体にはrepr(packed)を付けています。u8がパディング無し4つ並ぶはず
repr(C)だとCと同様にパディングされる可能性が出てくると思うのですが

>>688
CloneとCopyを付ける方法に関してはどのような動作になるのか確信を持てていないです
原則コピーになるという情報は出てきますが、画像のバッファだし原則参照で必要なときだけ
コピーしたいです(すでに初期化とは別のところで問題になっています。参照とコピーの
切り替え方法が判らない)
0693デフォルトの名無しさん2022/09/10(土) 19:24:52.82ID:qBfKxAEz
>>692
自分の理解があっているか不安なんですが、mutを付けずにletで宣言すると書き換わらない値として
書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか?というのが心配な点です
言語仕様上mutを付けない宣言でも必ず読み書き可能な領域に配置されるというのであればそれでかまわないと思いますが
とりあえず手元のx64向けのコンパイラではmutを付けずともスタックフレームに配置されるようですが
組み込み向けなど他のコンパイラでも同様の動作を前提として問題ないのか判りません

古いバージョンのBookにはスタックやヒープの解説があったようですが
ttp://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/the-stack-and-the-heap.html#:~:text=Memory%20management&text=The%20stack%20is%20very%20fast,explicitly%20allocated%20by%20your%20program
最新版にこのページはないような・・・しかも
>Rust ‘stack allocates’ by default, which means that basic values ‘go on the stack’.
だとRAMを節約したいからROMに配置する実装もあり得ると読めなくもない
0694デフォルトの名無しさん2022/09/10(土) 20:06:33.59ID:xD3pa07u
let bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)};

これでいいってことじゃない?
一個目のbitmapは実際書き込んでないからmut不要
二個目のbitmapは変数名同じだけど一個目とは別の変数で、こっちは次の行で書いてるからmut必要
0695デフォルトの名無しさん2022/09/10(土) 20:13:43.96ID:xD3pa07u
あぁ言いたいことは分かった
確かにtransmuteしてるからバックエンドの挙動によっては変なことになりうるかもね
ただそれは別にmutをつけても保証はされない気がする
0696デフォルトの名無しさん2022/09/10(土) 20:24:18.78ID:BhJh8aSd
>>691
repr(packed)を指定した構造体のフィールドへのアクセスは未定義動作を引き起こす可能性があるからrepr(packed)は基本的には使わない方が良いよ
https://doc.rust-lang.org/nomicon/other-reprs.html#reprpacked

確かにrepr(C)やrepr(Rust)はパディングされる可能性があるけど、フィールドのアラインメントを適切にするために必要なものなので
パディングが問題になるならフィールドのメンバーの順序やサイズを見直すか、フィールドの値を読むのに std::ptr::read_unaligned を使う必要があるよ
https://doc.rust-lang.org/std/ptr/fn.read_unaligned.html

read_unalignedのドキュメントにも書いてあるけど、アライメントが不適切なフィールドへの参照を作るのすら未定義動作になるという落とし穴もあったり、
repr(packed)な構造体の取り扱いにはいろいろと注意が必要になるので、本当に必要なとき以外は使わない方が良いよ

あと、repr(packed)はrepr(packed, Rust)と同じ意味になるので、構造体のフィールドがメモリ上でどのような配置になるかの保証はないよ
フィールドの定義順とメモリ上での順序を同じにしたいのであれば repr(C) または repr(C, packed) と指定する必要があるよ

いずれにせよ今回は全てのフィールドがu8だからrepr(C)でパディングが挿入されることはなく
無駄にメモリを消費することもないよ

どうしてもパディング挿入が心配なら mem::size_ofやmem::align_ofを使って構造体のサイズとアライメントに関するアサーションを加えるのが良いと思う
0697デフォルトの名無しさん2022/09/10(土) 20:36:28.31ID:BhJh8aSd
>>693
let a = ...;
let mut a = a;
みたいに書いた場合、一個目のaと二個目のaは別の変数扱いでそれぞれ個別に領域が割り当てられるよ
二個目のaに格納されるのはaの値で、ポインタじゃないから一個目のaが書き込み不可な領域に格納されていたとしても
二個目のaのために割り当てられた読み書き可能な領域に一個目のaの値がコピーされるような動作になるはず
最適化によって一個目のaと二個目のaが同じ領域を使い回すようになるかもしれないけど、二個目のa定義後はその領域に対する書き込みは可能なことが保証されてるはず

transmuteを呼び出した場合も同じで、
transmute(a) という呼び出しをした場合transmuteに渡されるのはaの値なので、二個目のaの定義後は問題なくaに書き込めるはず

ただし、transmuteに&aを渡して&mutに変換するみたいなことをすると未定義動作になるから注意は必要
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
> Mutating immutable data. All data inside a const item is immutable. Moreover, all data reached through a shared reference or data owned by an immutable binding is immutable, unless that data is contained within an UnsafeCell<U>.
0698デフォルトの名無しさん2022/09/11(日) 12:51:18.94ID:6axTKkj4
>>693
>mutを付けずにletで宣言すると書き換わらない値として
>書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか?というのが心配な点です

しねーよ。
組み込みだろーがそれは変わらない。
letついて束縛変数といわれようが変数は変数。
0700デフォルトの名無しさん2022/09/11(日) 13:49:03.04ID:7UmicIsS
コンパイル時に値が確定してないとtextセクションに書けないでしょ
0701デフォルトの名無しさん2022/09/11(日) 13:55:35.90ID:VMVpvyTB
そっちは定数でconstだしそうなる
letはあくまでもimmutableな変数であり定数ではない
0702デフォルトの名無しさん2022/09/11(日) 13:57:25.52ID:kEOVMHNm
コンパイル時に確定するような式なら最適化でありえるんじゃないの?
0703デフォルトの名無しさん2022/09/11(日) 14:07:54.90ID:VMVpvyTB
どのように最適化されようが
constではなくlet x = ...ならば
let mut x = x; とムーブして書き換え可能
これは言語のレベルで保証される

そしてそのように使うならば最適化も無駄なことせずにtext segmentでなくdata segmentに置くだろう
0704デフォルトの名無しさん2022/09/11(日) 14:40:44.81ID:ujBIW69o
CloneとCopyについて
let mut bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<[u32; LEN], [ARGB32; LEN]>(bitmap)};

#[derive(Clone, Copy, Default)]

let mut bitmap:[ARGB32; 16] = [ARGB32::default(); LEN];
で読み書きを
bitmap[0].red = 0x80;
let x = bitmap[0].red;
bitmap[0].green = x;
としてみたけど出力された読み書き部分のコードは同じでした。もっとでかい構造体じゃないとムーブかコピーかの区別は出来ないのかな

>>696
マジか。Rustでもパディングの問題がつきまとうのか。でも
>Accessing unaligned fields directly with e.g. packed.unaligned is safe however.
って事は.redとかでアクセスする場合はコンパイラが良きに計らってくれるのでアクセス境界の問題は起きないって事かな?
画像データのバイトやビットの並びなんてすでに決まっていてプログラムはそれに合わせるしかないのが普通でしょうし
勝手にパディングされても困ります

実は並行してCでも書いているんだけど構造体のパディングの制御は処理系依存らしくて移植性を優先すると
データは整数の配列で持って論理演算とシフトで分解、構築するコードになってしまってます
0706デフォルトの名無しさん2022/09/11(日) 15:13:19.03ID:/O1tQPyF
どの言語でも同じ
Rustでも&mutでtransmuteしてもendian依存は避けられないな
let mut x = 0x01020304_u32;
let a = unsafe { std::mem::transmute::<&mut u32, &mut [u8; 4]>(&mut x) };
a[1] = 7;
assert_eq!(x, 0x01020704);
とlittle endianでは7の位置はこうなる
0707デフォルトの名無しさん2022/09/11(日) 18:54:24.82ID:gEyGQ7vE
このスレでよく出てくる μt ってなんなん?
音的に mut をそう書いてる異常者がいるだけかと思ってるんだけど、なにか別の意味を持った概念や機能だったりするの?
0709デフォルトの名無しさん2022/09/11(日) 20:27:57.44ID:QYXgEc7E
>>708
そうなんだ。
0710デフォルトの名無しさん2022/09/11(日) 20:45:42.63ID:hnVgjqVb
>>708
なるほど、ありがと。
異常者かと思って真面目に読む気が失せてたんだけど誤解だったか。
0712デフォルトの名無しさん2022/09/11(日) 21:45:56.06ID:ujBIW69o
例えば
pixel.alpha = in[0].alpha;
pixel.red = in[0].red / 2;
pixel.green = in[0].green / 2;
pixel.blue = in[0].blue / 2;
out[0] = pixel;

red = 0xFF & (in[0] >> 16);
green = 0xFF & (in[0] >> 8);
blue = 0xFF & in[0];
red /= 2;
green /= 2;
blue /= 2;
pixel = 0xFF000000 & in[0];
pixel |= red << 16;
pixel |= green << 8;
pixel |= blue;
out[0] = pixel;
ではだいぶ見やすさが違うような
0713デフォルトの名無しさん2022/09/11(日) 21:47:41.04ID:3JeGkSLy
>>704
パディングというかメモリアクセス時のアラインメントについてはCPUの仕様だから言語関係ないよ
x86がunalignedなアクセスについてゆるゆるだから忘れられがちだけど雑に書いたプログラムをarmで動かしたりするとクラッシュする

今回はu8へのアクセスだからさすがにパディング入れられることはないと思うけどね
0714デフォルトの名無しさん2022/09/11(日) 21:50:14.96ID:3JeGkSLy
>>712
シフト処理など隠蔽してくれるアクセサメソッド用意したらだいたい同じような読みやすさになるのでは
0715デフォルトの名無しさん2022/09/11(日) 23:45:21.14ID:ujBIW69o
Rust固有じゃないけど移植性を改善する方法に1バイトずつ処理するという手があるけどこの実装は、今時の32bitや64bit環境で
相応にデバフが入るんですよね。MSVCでも8bitロード×8を64bitロード×1に最適化してくれなかったし

>>713
そこを抽象化するのが処理系の仕事では。いまだに構造体でパース・・・みたいなコードを見かけるし

>>714
読みやすさは改善しても今度は速度にデバフが入るような。こういうケースでアクセサメソッドを利用したとして
全てインライン展開&最適化されますかね?一つでもコールやブランチが残ったら速度が結構落ちるだろうし
0716デフォルトの名無しさん2022/09/11(日) 23:59:30.49ID:/O1tQPyF
>>707
色んなブラウザで見てみたけど
&mut (分けて書くと & mut )が μt と表示されるのはバグってるchmateだけっぽい
0718デフォルトの名無しさん2022/09/12(月) 01:00:12.66ID:JkhjRZ+U
>>716
ほー、chmateはワザとunescapeしてるのか?
5chがUnicode文字表示できるようになったんだし、そういうのはもう余計なお世話だな
0719デフォルトの名無しさん2022/09/12(月) 01:13:39.26ID:D0TZxDhn
HTML等の文字参照を処理する場合でも
μt (= & m u ; t )が μt となるのは正しいけど
&mut (= & m u t )が μt となるの間違いだからこれはバグと思われる
0721デフォルトの名無しさん2022/09/12(月) 06:45:23.29ID:hsi1XO0i
文字列参照に & mut なんてないからテキトーに解釈してるんでしょ
良し悪しは別にして html を扱うブラウザではそれほど珍しくはない
個人的には余計な事すんなとは思う
0722デフォルトの名無しさん2022/09/12(月) 07:14:45.53ID:tyJETXG8
これはmateのバグです
& x y z ; とセミコロンで終わる場合のみその部分を文字参照として解釈するのが正しいです
0724デフォルトの名無しさん2022/09/12(月) 07:34:32.06ID:o/NFQNbK
& amp ; amp; を空白なしで書き込んだら & に変換されてしまった
実体参照複数回展開しているのかな
&amp;
0725デフォルトの名無しさん2022/09/12(月) 08:15:16.27ID:NGx/fsjU
ライブラリとかのコンポーネントの一部を作っているときに入出力だけ不定値として扱う方法ってありませんかね
ガワ作って入出力を完全に外部に出さないとコードがみんな消えてしまうのは不便です
最適化レベルによる変化とか全然確認出来ないし
0726デフォルトの名無しさん2022/09/12(月) 08:36:58.55ID:tyJETXG8
ちょっと意味がわからない
こうなるはずだから困ることはないと思うけど

・最適化によってRustが定めている意味が変わることはない
・pub宣言しているものは中で呼ばれていなくても単体コンパイルで消えることはない
・pub宣言されていないものは中で呼ばれていなければ今後も誰からも呼ばれないためwarningが出て消える
0728デフォルトの名無しさん2022/09/12(月) 12:04:36.56ID:tyJETXG8
その場合でも実際に使う型々でtestを書くだろうからcargo testで確認できるでしょ
0729デフォルトの名無しさん2022/09/12(月) 12:46:09.29ID:SjJDv8F6
>>726
ありゃうちの環境の問題か。pub付けただけじゃ関数丸ごとなかったことにされる
pub extern "C"でRust外の入出力にしてようやく消えなくなる
もうちょっと調べてみる
0731デフォルトの名無しさん2022/09/12(月) 19:11:31.91ID:2zIjStdY
>>730
変更してみた。staticlibだとpub付けても消える。rlibなら消えないようだ
とりあえずrlibにしておいてある程度形になってきたら変更すればいいか
コード自体はどっちでも大差ないだろうし
0732デフォルトの名無しさん2022/09/18(日) 01:08:32.32ID:g4sMxKuf
[u32; LEN]と[ARGB32; LEN] の件、アラインメントが違うからtransmuteの時点でUBだけど
0733デフォルトの名無しさん2022/09/19(月) 02:33:25.46ID:HMAR4dxa
Tauriで動画プレーヤー的なのを作るサンプルってどっかにある?
ただ再生するデータは既存のmp4ファイルなどではなくRustプログラムから渡したい
あと再生、停止、コマ送り、シークなどの基本的な機能は実装したい
0734デフォルトの名無しさん2022/09/19(月) 07:48:35.44ID:BbpMxDy4
TauriってWebアプリのサーバーサイドがRustで一体型プログラムになっているだけだろ?
そして既存のWeb技術を活かせるのがTauriの利点だろ?
そうならば例えばhls.jsなど既存の好みの動画配信再生フレームワークを使えばいいだけじゃないか?
Webサーバーサイドやったことあるならばフロントエンドからファイルに見えているものは本物のファイルである必要はなくサーバーサイドが算出していれば十分だろ?
0735デフォルトの名無しさん2022/09/19(月) 12:27:41.81ID:HMAR4dxa
>>734
>HLS
ちょっと調べてみたけどHLSでいわゆるRAWデータを再生出来るという情報は見つけられていない
特にビデオが未圧縮データを扱えそうにない。オーディオは未圧縮FLACでいけるかもしれないけど
再生したいのがWebブラウザが対応していないデータなのでどうしようか考え中

ビデオはBMPのぱらぱら漫画でオーディオはHLSで未圧縮FLACとか?なんか無駄に実装量が増えるけど
0736デフォルトの名無しさん2022/09/19(月) 13:11:44.57ID:PTk7Q+2G
その手のやつでオーバーヘッド減らすならOS毎にネイティブ実装するしかなくない?
0737デフォルトの名無しさん2022/09/19(月) 18:38:49.00ID:EybjBREq
なんとかtauri使うにしてもJSやらWASMやらで動画レンダリングするようなもの作らないとだめそう
0738デフォルトの名無しさん2022/09/19(月) 18:45:15.20ID:npVSxydm
実装を追加させない方法ってありますか?
別個に渡されたふたつの型が同じであるという制約を付けたいという目的で
以下のようなトレイト Same を定義した場合、実装を追加できてしまうと破綻してしまうので、
なんらかの方法で制限できるだろうかという疑問です。

pub trait Same<T> {}
impl<T> Same<T> for T {}

// 使用例
pub fn foo<T, U>(x: T, y: U)
where
T: Same<U>,
{
}

ちなみに目的を上述しましたけども実際には目的というよりは題材です。
つまり具体的な用途は考えておらず、質問はあくまでも「実装させない方法があるかどうか」です。
0741デフォルトの名無しさん2022/09/19(月) 21:29:04.18ID:Elo9mBmF
ふたつの型が同じという制約を付けたいなら
TとUじゃなくTとTにすればいいじゃんか
0742デフォルトの名無しさん2022/09/19(月) 21:34:13.52ID:jWPeXdq1
>>738
達成したいことが特にないらしいからなんとも言えないけど enum を使っても近いことはできるんじゃないかな。

enum Same{SameA(型A),SameB(型B)}

みたいにしてやれば、Same 経由で扱う限り実装は増やせないぞ。
0743デフォルトの名無しさん2022/09/19(月) 22:48:26.11ID:npVSxydm
>>739-740
実装を追加させないテクニックのひとつとして有用ですし紹介はありがたいです。
しかしそれだと Sealed を実装した型だけにしか使えず、 >>738 で示したような汎用的に型を比較するトレイトには使えないですよね。
この Same のように機能するトレイトに実装を追加させないというのは前提と考えて欲しいです。

>>741
そういうレスが付くことを避けたいから最後の文をつけたつもりなんですが……。
Rust の初心者として様々な言語機能を理解したいという立場で疑問に思った部分を抜き出し、
説明のために前提条件を設定したのであって、前提条件の部分自体は解決したい課題ではないです。

いわゆるXY問題というものの存在は承知しておりますので
解決したい大元の問題を示さないというのがモヤモヤするだろうなというのはわかります。
わかりますが、大元の問題というものはありません。
この範囲で完結するパズルだと思ってください。
0745デフォルトの名無しさん2022/09/20(火) 00:42:08.53ID:FykVNAq+
impl Foo for Tが存在する時点で他の型にFoo実装しようとするとconflictしなかったっけ
07497382022/09/20(火) 01:17:29.77ID:w2qVrruo
なるほど、 C++ と違って特殊化にならないからより狭い範囲の実装は追加できないんですね。
&T とか &mut T とかも先に実装しておけば追加の余地をなくせると。
&T とか &mut T とか以外にどういうのがありえますかね?
07517382022/09/20(火) 01:53:09.66ID:w2qVrruo
>>750
ありがとうございます。
言われてみれば当然のような感じですがまだまだ私は Rust らしい考え方が出来ていないようです。
0754デフォルトの名無しさん2022/09/20(火) 20:46:56.46ID:Di+jgu/u
今のところデバドラだけという話だけど
基幹部分の新実装をRustで作りましたという
人が絶対現れるからそのときどうなるだろ
0756デフォルトの名無しさん2022/09/22(木) 02:33:16.78ID:OUmiFnaH
MS AzureのCTOが「新しいプロジェクトでC/C++使うのはやめて
非GC言語が必要な状況ではRustを使うべき時だ」ってツイートしてるけど
Visual StudioでもRustが最初からパッケージングされてるようになるのかな
0758デフォルトの名無しさん2022/09/22(木) 13:36:58.59ID:V4zanZlp
>>756
MSがRustの開発環境に投資するならVSCodeのエクステンションじゃない?
いまさらVSに対応言語を追加する気はないでしょ
どう考えてもWindowsユーザーは少ないだろうし
0759デフォルトの名無しさん2022/09/22(木) 19:38:28.16ID:VGEMfVQX
>>756
マーク・ルシノビッチ氏、Microsoft AzureのCTOなのか。
インサイドWindowsにはお世話になったわ。
0760デフォルトの名無しさん2022/09/23(金) 05:18:56.24ID:I8UIrhRk
Iteratorに対するIntoIteratorのように
Futureに対するIntoFutureということか
しかも.awaitに対して自動適用だからもっと効果が大きいか
非同期を返すビルダーに対してFutureを返させるためのビルド完了指示メソッド呼び出しが不要となる
0761デフォルトの名無しさん2022/09/23(金) 08:24:08.00ID:G8O+P73a
Rust analyzerが優秀過ぎてMSが入る余地なさそう
PythonがMS Storeから落とせるみたいにインストールが楽になるとかならありそう
VSに導入されたらそれはそれで面白いんだけど.Net言語との連携が強化されないと旨味がないな
0763デフォルトの名無しさん2022/09/23(金) 10:08:58.99ID:QyFSmn0+
既存ライブラリがそのまま呼べるならお試しで部分的に新言語導入してみようとなる可能性もあるので意味はある
0765デフォルトの名無しさん2022/09/23(金) 12:31:56.94ID:aakQSAhx
>>758
VSCodeの方が対応は早いかもだが、VSに追加する気がないことは無いんじゃないかな
0766デフォルトの名無しさん2022/09/23(金) 17:48:32.43ID:z6wpDrU6
>>762
書き方悪かったわ
Rustで作った何かをC#とかから簡単に呼べるといいねって意味だった

GoのCGoみたいな仕様だったら色んな意味で面白いと思う
0767デフォルトの名無しさん2022/09/23(金) 18:02:01.54ID:bhLcJIv7
rust_analyzerの話題ついでに教えて欲しいのですが、保存なしで構文チェック等してくれるようにならないものなのですか?
編集を破棄して保存前の状態にしたい時があるので、できれば自動で保存したくないのです
Vim系プラグイン等を入れていれば無限に戻せるのかもしれないものの、Vimが使えない身としては困ってしまいます
0768デフォルトの名無しさん2022/09/23(金) 18:02:58.63ID:exFn1ITS
>>766
ああそれならありだな
まあ今でもC/C++とかで作ったdllなりをC#から呼び出せるから同じような感じでできるんじゃないかな
0770デフォルトの名無しさん2022/09/23(金) 18:05:33.15ID:5/jqA4bf
C#も.Netも全く興味ないので知らないが
PythonでもJavaScriptでも何でもRustで作ったライブラリなどを簡単に呼び出すことができる仕組みがそれぞれ整えられている
既存のものの置き換えは無意味だが新たに作られるものはRustで書くことが増えている
0771デフォルトの名無しさん2022/09/23(金) 21:26:00.89ID:Oi43IjEf
repr(C)でCのフリしたRustじゃなくて、俺はありのままのRustが動いている世界線が見たいよ
0772デフォルトの名無しさん2022/09/23(金) 21:26:44.38ID:bhLcJIv7
>>769
でも、破棄ならコミット後の状態にも戻せるぜ?
0774デフォルトの名無しさん2022/09/23(金) 21:53:19.36ID:wlVyCNVq
>>773
そんなことすべきでない
自由にRust コンパイラによる最適化の余地を与える現在の方針がベスト
外部に公開しなきゃいけない時に外部に公開する部分だけを#[repr(C)]や#[wasm_bindgen]など指定すればよい
0776デフォルトの名無しさん2022/09/23(金) 23:55:09.24ID:9eaiNZZz
なるほど
0777デフォルトの名無しさん2022/09/23(金) 23:58:10.15ID:SxK8BSHj
対C/C++はそこまで必要ならそこもRustで書いちゃうから何ら問題はない
他の言語ではそれぞれもっと大きなオーバヘッドを持っているので誤差に収まり問題にならない
0781デフォルトの名無しさん2022/09/24(土) 03:05:40.90ID:ugWjDAH5
Rustだけで閉じていればpubであっても自由に最適化されるからpubかどうかは関係ないでしょう
結局Rustの外に公開する部分だけの話に限られるからそこだけ相手毎に応じる現行の方式のままで構わないでしょう
0782デフォルトの名無しさん2022/09/24(土) 08:50:49.84ID:pfcr5AFZ
C++やRustはABI決まってないのにC言語は何故ほぼ決まってるの?
0784デフォルトの名無しさん2022/09/24(土) 09:15:16.80ID:WR9fIR0K
ぶっちゃけあらゆるOSがC言語で書かれているあたりCの呪縛から逃れられないよ
0785デフォルトの名無しさん2022/09/24(土) 09:26:53.29ID:rPP8Qygy
>>782
名前をプログラマが決められるからだよ
0786デフォルトの名無しさん2022/09/24(土) 09:44:37.12ID:BCuennz9
>>782
むしろCは決まってるの?
決まってるわけじゃなくて単純だし歴史も長いから結果的にほぼ変わらない&その現状に合わせて変わらない変更をしてるだけみたいなことをgccかなんかの中の人の記事で読んだ気がするんだけどデマなんかな
0787はちみつ餃子 ◆8X2XSCHEME 2022/09/24(土) 10:38:04.73ID:2HWwrIyG
近年になって作られた高速リンカ mold の作者の話でも、
文書化されていない暗黙の仕様に何度もぶつかったみたいなことだったはず。

C 以外の言語 (処理系) もツールチェインは共通のものを使っている場合は結構あるし
どれがどの挙動に依存しているかようわからんので安易に整理するわけにもいかず、
結局のところは C コンパイラとは長年に渡って協調してきたから細かい問題点が
解決されているというだけで、そんなにカッチリした仕様が確立しているわけではないと思う。
0788デフォルトの名無しさん2022/09/24(土) 11:00:33.46ID:DaB/WDgt
CはCPUベンダーが呼び出し規約を文書化してるよ
moldの話はELFやリンクに関連する話では
確かにABIのうちではあるけど言語ごとに異なる仕様になるようなものではないと思う
0789デフォルトの名無しさん2022/09/24(土) 11:33:36.58ID:FWSMvJVe
AMD64の呼び出し規約をググるだけで2種類くらい出てくるのにコイツは何を言っているんだ?

>>786
呼び出し規約どころか構造体のレイアウトすら実装依存の部分があるよ
0790デフォルトの名無しさん2022/09/24(土) 13:14:15.81ID:DaB/WDgt
>>789
そこでいう実装依存ってプラットフォームごとの差違のこと?
それとも同じプラットフォームでもツールチェイン依存でレイアウトが変わりうる場合があるの?
0791デフォルトの名無しさん2022/09/24(土) 14:25:21.27ID:PoJJisuz
cdeclとかstdcallみたいなやつ?
0792はちみつ餃子 ◆8X2XSCHEME 2022/09/24(土) 16:06:51.67ID:2HWwrIyG
>>791
その段階ではあまり曖昧さはない。
リンクする前の状態はリンクに必要な情報一式が入ってるはずなんだけど、
その扱いが言語や処理系をまたぐとややこしくなることもあるってこと。
アーキテクチャによって扱いを変える必要がある場合もあるし。
0793デフォルトの名無しさん2022/09/24(土) 16:24:43.84ID:PoJJisuz
>>792
コンパイラがリンカに渡す情報って統一規格があるの?
0795デフォルトの名無しさん2022/09/24(土) 17:10:20.79ID:GMpouZpq
じゃあ、そのオブジェクト・ファイル形式の仕様に問題があるってことでは?
0796はちみつ餃子 ◆8X2XSCHEME 2022/09/24(土) 17:36:26.33ID:2HWwrIyG
>>795
ELF に置き換わるときにオブジェクトファイルの仕様の曖昧さはほとんど解消されていると思う。
ただ現実には全てが正しく実装されているわけではなく、
場合によっては正しかったほうを間違った側にあわさざるを得ないとかいう場合もある。
仕様がどうこう言ったって、実装が間違っていたって現実にもう動いているものがあるのなら変えられんのよ。
そういう歴史的負債がどんどん積み重なってわけわからんようになる。
0798デフォルトの名無しさん2022/09/24(土) 22:13:22.85ID:DaB/WDgt
元々の他言語からrust呼び出す話ならそのレベルの話は関係ないでしょ
LLVMがよしなにやってくれるのでは
0799デフォルトの名無しさん2022/09/24(土) 22:29:32.09ID:GMpouZpq
ARM64ほどの絶対的パワーは必要ないので、ARM63で価格が120円くらいのチップになりませんかね?
0800デフォルトの名無しさん2022/09/25(日) 08:24:33.85ID:j3K9KjV7
Option<NoneZeroUsize>などを使えば
IDやカウンタなどの用途でOption<usize>などを使っていたものを
半分のメモリサイズで済むようになるの?
0802デフォルトの名無しさん2022/09/25(日) 15:32:52.52ID:F2Viqk5M
Microsoftがやりそうなことだけど、Rustに独自拡張を含めたりとかしてほしくない
0803デフォルトの名無しさん2022/09/25(日) 17:24:00.83ID:xalR35FT
Linuxはカーネル開発の為に今まさにRustに独自拡張を含ませようとしてるのに
Microsoftはダメなの?
0804デフォルトの名無しさん2022/09/25(日) 17:34:47.30ID:4B3i10Bx
try_new()とかtry_reserve()とか元々ないのが不思議だったし導入の良いきっかけとなっただけ
0805デフォルトの名無しさん2022/09/25(日) 17:57:47.12ID:6lgwXJxi
言語自体forkして独自のエコシステムを構築しようとしなければ別に良いのでは
0807デフォルトの名無しさん2022/09/25(日) 18:14:08.03ID:Td47G6We
Rustに限った話じゃないんだけどそれなりに複雑なロジック(例えばデコーダやパーサ)の実践的なテストの
作り方の解説とかどっかにある?例えばJPEGやPNG、MP3、AVIとかを扱うようなコードを想定
関数単体のテストはともかく、結合した状態で全てのコードを動かそうとすると入力パターンがどんどん増えるし
パディングビットにゴミがあっても問題ないかなどを考慮しだすと更に膨れあがる
さらに歴史が長いフォーマットだと、そもそも仕様をどう定義するのかという点が問題になることもあるし
0809デフォルトの名無しさん2022/09/25(日) 19:04:38.98ID:rVqFiGXV
>>803
別に独自拡張とか入れてないだろ
コンパイラへの機能追加は全部本体に入れていてnightlyで使える状態だし
Linuxカーネル向けのallocなんかは単にライブラリであって言語自体がforkしてるわけではない
0811デフォルトの名無しさん2022/09/25(日) 19:59:47.96ID:Rxhh3DJ9
>>810
迷走と凋落、そして黒歴史化。
0812デフォルトの名無しさん2022/09/25(日) 20:07:26.82ID:58piYD8Z
>>807
メディアのエンコーディングのことはさっぱりしらんけど、一般的には結合テストじゃなくて、単体テストでパターンは網羅すべし
できるんならやればいいけど、結合テストで入力の網羅なんて普通はやらない
0813デフォルトの名無しさん2022/09/25(日) 20:26:59.51ID:Td47G6We
>>812
条件分岐で関数Aを呼ぶべき所を間違えてA'を呼んでいて出力結果がちょっと変・・・というのをさっきやらかした
関数そのものに問題はないし処理内容がちょっと違うだけなので実行は出来てしまうのがいやらしい
で、テストを作ろうとしたけどどうしようか悩み中
0815デフォルトの名無しさん2022/09/25(日) 21:09:49.29ID:j1+dHWho
>>807
歴史があり、曖昧さが残るフォーマットの再実装はできればやりたくない仕事だな。
対応する仕様を現代で最低限必要なものを取捨選択して決め打ちで実装しつつ、考慮漏れでクリティカルなものは取り入れていく方式でやるしかないよ。

歴史あるフォーマットの曖昧な対応を追体験する作業は、不毛だからできれば既存実装におまかせすべき。
0816デフォルトの名無しさん2022/09/25(日) 21:31:04.61ID:Td47G6We
>>814
中間コンポーネントの単体テストって普通どうやるんだろ
後段のコンポーネントを切り離してテストするのか?繋げたままテストするのか?
切り離せるようにするとその部分にバグが入り込む余地が生まれるし

>>815
歴史が長いと仕様上○○であるがこれに準拠しないアプリやデータが少なからず存在するため
△△のような実装がベターだみたいなのが沢山あるからねぇ
そしてこの手の情報はググっても網羅するのが難しい
0818デフォルトの名無しさん2022/09/25(日) 21:51:47.84ID:PDKGWlWe
>>816
> 中間コンポーネントの単体テストって普通どうやるんだろ
中間の意味がよく分からんけど>>813みたいな話なら関数A、関数A'をモックにしてテストする
たいていのテストツールではモックの呼び出し回数のテストができる
0819デフォルトの名無しさん2022/09/25(日) 21:53:52.45ID:j1+dHWho
>>816
JavaみたいにDIが発展しているタイプの言語だと中間コンポーネントが呼び出すコンポーネントはモックをインジェクトしてやって、適切なメソッドが呼び出されたかのテストとかよく書くね。

けど、正直Rustを含む他の言語で中間のレイヤだけ独立してテスト書くようなこだわりはあまり見たことも書いたこともないなぁ。
モジュール設計の考え方が変わるからかな?
0820デフォルトの名無しさん2022/09/25(日) 22:41:02.05ID:Td47G6We
今作っているのだとこんな感じかな?
関数C(データの前処理、処理単位への分割)

関数B(処理全体の制御)→関数A'(処理1-2)

関数A(処理1-1)

>>818,819
その場合モックへ切り替える機構はどうするんだろ
そのためにコードを書き換えていてはミスが入り込む可能性が高くなるし、条件付きコンパイルも同様のリスクがある

てかThe Rustのテストの所を見ても関数の呼び出し状況をテストする方法とかは書いていないんだよな
なんかその辺を良い感じに可視化してくれるツールとかあるんだろうか
0821デフォルトの名無しさん2022/09/26(月) 00:07:36.94ID:h/WE7ZWH
>>820
すまん rust だと cargo test で単体テストを実施するみたいだけど mook/stub をどうやって使うかはよくわからんかったわ
C++ とかだと googlemook とか使ってテスト用のモッククラスを作って入れ替えるかたちだね
0823デフォルトの名無しさん2022/09/26(月) 06:28:19.26ID:p/pWEmYs
cargo testで関数テスト、モジュールテスト、モジュール間テストなどあらゆるテストをやっているけどダメなの?
0825デフォルトの名無しさん2022/09/26(月) 19:21:24.42ID:kI3cAlPQ
モックやスタブは別モジュール化しておいて
mod tests内では本物モジュールをuseする代わりにそれをuseするだけじゃないの?
0827デフォルトの名無しさん2022/09/26(月) 19:31:51.25ID:i/jndsoD
他の言語でもユーティリティを使わずに、DIやモックを自分でやったことがないんだろうな
説明が面倒だ
0828デフォルトの名無しさん2022/09/26(月) 19:38:20.09ID:V9yeC/LF
>>827
テスト以外の開発の話でも
フレームワークに依存してやってる人は
単純なこと含めて本質的なことを理解してない人が多く
フレームワークなしでは何も分からず何も出来なくなってしまう例を時々見かける
0829デフォルトの名無しさん2022/09/26(月) 21:10:39.16ID:qW/k82Qg
cfg使えば良いじゃないって人は#ifまみれで一見しただけじゃ
何がどう動くんだか判らないCのコードを正当化するつもりなのだろうか
Rustは人間が注意すれば問題ないみたいな考えはレガシーで時代遅れだ
という思想の言語だと思っているんだが違うのかな
0830デフォルトの名無しさん2022/09/26(月) 21:41:35.64ID:w5YNQb64
>>829
#ifは使わないし
cfg(test)はテスト分離のため必須でしょ
どんな環境でも魔法は無いよ
0832デフォルトの名無しさん2022/09/27(火) 01:17:35.37ID:OwORQ6vn
mod tests に cfg(test) は必要だとして
依存性の注入にはtrait使えって事なのでは
0834デフォルトの名無しさん2022/09/27(火) 08:15:53.87ID:SBVoZTui
AMD64のデフォルトのオペランドサイズは32bitなのにusizeが64bitなのは何でなのかな
0837デフォルトの名無しさん2022/09/27(火) 19:04:38.56ID:ZwmfNOl5
>>831
単体テストで、依存を分離するのは当然のことすぎてみんな説明が億劫になってる
C++だろうがRubyだろうが、モックやスタブを使って、関数同士やクラス同士の依存を切り分けてテストするのは当たり前
そうしないとそもそも単体テストにならないじゃん

わかってる人にしかわからないであろう簡略な説明をすると、テスト用のエントリポイントで、テストに使うモックオブジェクトを指定するだけだよ
そういうことができるようにあらかじめコード設計しておかないといけないがな
考えてなかったならリファクタが必要
0839デフォルトの名無しさん2022/09/27(火) 19:51:56.44ID:AWnlNGZp
本物と異なり決まった値を返す送信元スタブと
本物と異なりassertだけする送信先モックを
mod testsの中では本物の代わりにuseするだけだよね
入れ替えちゃうからtrait制約で本物も偽物も受け付け対応とかわざわざする必要ないよね
0840デフォルトの名無しさん2022/09/28(水) 00:44:24.76ID:JQpGo85s
>>839
useしたモックをどうやって注入すんの
関数の引数もstatic変数でも良いけど、テスト対象の実装がモックも本物も選択的に使えるようにするならば、
genericな型を受け付けるような実装にしておかないといけないのでtraitが登場するのでは

それともmod testsの外もcfgで置き換えると言っている?
0841デフォルトの名無しさん2022/09/28(水) 00:48:00.37ID:JQpGo85s
要は
use imp::Foo;
fn target(foo: Foo) {}
がテスト対象だとして
mod tests {
use mock::Foo;
#[test]
fn test() {
target(Foo::new());
}
}
してもコンパイル通らないよね
targetがimp::Fooもmock::Fooも受け付けるようにするにはtraitが必要では
0844デフォルトの名無しさん2022/09/29(木) 01:43:05.00ID:xXycU9Ev
u32 を格納する型が必要になり、また、逆に u32 に変換する必要もあるという状況で
せっかくだから u32 に変換可能な型は受け入れようと考えてこんなコードを書きました。
しかしエラーになります。

struct Code(u32);

impl<T: Into<u32>> From<T> for Code {
fn from(x: T) -> Self {
Code(x.into())
}
}

impl From<Code> for u32 {
fn from(Code(x): Code) -> Self {
x
}
}

結果的に自分自身への変換を許すことになってしまうのが既存 (標準ライブラリ)
の定義と衝突しているという理屈は理解しているのですが、
問題を解消するためにこの定義が受け入れる範囲から自分自身 (Code) は除外するように
うまく制約を付ける方法は思いつきません。

そもそもこんなところで勝手に変換するのがよくない作法だとかそういうのは脇に置いて
「自分自身だけ除外するような制約」を上手いこと表現できませんかね?
0848デフォルトの名無しさん2022/09/30(金) 02:17:04.59ID:Yj/X+hjS
初歩的なことですまんけどさ
メソッド内で↓みたいなのってよく見るけど、こう言うのってself.asdfのまま使用するのに比べてどういった利点があるの?
let asdf = self.asdf;
0851デフォルトの名無しさん2022/09/30(金) 12:43:57.87ID:NYKsqXq4
書き方は違うけどフィールドそれぞれに対して処理を行う場合に抜け漏れがないことをコンパイラにチェックさせる目的でローカル変数にすることはある

let Foo { foo, bar. baz } = self;
としておくと後続の処理で使わないフィールドがあったときにコンパイラが警告してくれる
構造体に新たにフィールド追加した場合も分割代入の箇所でコンパイルエラーになるので修正必要箇所を洗い出すことができる
0853デフォルトの名無しさん2022/09/30(金) 14:15:24.65ID:oHn8O8ll
本人は俺ってスゲー、天才やん!
って思ってるんだろうけど後でコード見たらなんでこんなイミフなことしてるんだ?バカじゃねーの
ってなるパターンかと
まあこういう工夫をすること自体は悪くない
0855デフォルトの名無しさん2022/09/30(金) 14:50:06.85ID:temvUu5a
>>851
俺もそのdestructuring assignment自体は使いまくる
しかし目的が漏れチェックとは違うのでこうだな
let Self { foo, bar, .. } = self;
0857デフォルトの名無しさん2022/09/30(金) 15:59:33.74ID:XmkFmofe
こうやって自己満足の意味不明なコードが量産されていく
0858デフォルトの名無しさん2022/09/30(金) 16:19:08.34ID:GH/ZHf2N
全フィールド舐めるのが重要な処理ってシリアライズとかだろうか
そんな小手先のテクニックとかじゃなくてproc_macro組んだ方がいいと思う

シリアライズしたいだけならserde使って#[derive(Serialize)]
これも結局proc_macroだわな
0859デフォルトの名無しさん2022/09/30(金) 17:36:27.38ID:NYKsqXq4
コマンドライン引数や設定ファイルの定義をclap::Argやserde::Deserializeで宣言的にやって、
それらを処理するところで分割代入してローカル変数にして処理してる
人間が意識的に気をつける必要がある箇所を極力減らしたい気持ちでやっている

好き嫌いあるかも知れないけど趣味プロダクトだしコーディングの意図をコメントに残してるから許せ
0860デフォルトの名無しさん2022/10/01(土) 02:29:47.97ID:hYwRxeDD
>>844
impl<T: Into<u32>> From<T> for Code {}の定義はFromの反射性と衝突するから間違ってる。
Into<u32>を受け付けたいなら関数のパラメタの型をT: Into<u32> or impl Into<u32>にすればいい。
まあ、実装上の規約として必要なんで内部ではtrait IntoFooはパターンとして使われるけど外に漏らすようなものでもない。
0863デフォルトの名無しさん2022/10/01(土) 19:20:52.10ID:LqnhFBhC
アドレスを考えれば明白に別物
一方で
let t = (123, "abc");
let (x, y) = &t;
と自動マッチングしてくれて
&t の型は &(i32, &str)
x の型は &i32
y の型は &&str
となる
つまり&(T, U)が(&T, &U)に分割代入される
0865デフォルトの名無しさん2022/10/03(月) 22:39:32.97ID:zgM1XF6F
amd64ターゲットでアセンブラリストを吐かせてみたらr13が全く使用されていないんだけど
r14、r15よりr13を空けておく理由がなにかあるのかな
0867デフォルトの名無しさん2022/10/04(火) 00:38:55.95ID:1GTeu6AF
うまく表現できないのですが、cやc++なら部分から始められる(動くものが作ることができる)のですけど、rustはそんな気がしないというか
伝わりにくいかもしれませんけど
0868デフォルトの名無しさん2022/10/04(火) 00:52:50.22ID:4fgdKnMe
そういう事象をちゃんと論理がとおった表現ができないからrustが使えないんだよきみは!
0869デフォルトの名無しさん2022/10/04(火) 07:13:44.70ID:vxOZn4OH
作りたいものの設計のイメージがc++でできているならそれをrust化するのは比較的簡単だろうしそれができないならrustの基本的な理解が足りないだけかと
0870デフォルトの名無しさん2022/10/04(火) 07:32:23.41ID:LLw3rM8F
Rustはデータ構造を最初に設計しないといけないというのはあるな
C++でもちゃんとそういうやり方が出来てるなら素直に移行できるだろうけど
雑にポインタ持ち回ったり実装の都合でアドホックに相互参照入れちゃったりする人には厳しいだろう
0871デフォルトの名無しさん2022/10/04(火) 08:55:50.45ID:fDq9dWrD
C系は良くも悪くも動いてしまうんよな
そんで知らぬ間に副作用まみれになっている
0873はちみつ餃子 ◆8X2XSCHEME 2022/10/04(火) 09:22:15.67ID:P4nmisNi
雑に始めてから整理していくスタイルなら C++ のほうがやりやすいというのは理解できる。
でも雑に始めたら整理する機会などないのが現実。
0874デフォルトの名無しさん2022/10/04(火) 09:24:31.25ID:BONyu2jp
>>867 ですが、
部分から始められるというのは、部分的な学習からということです
ここまで学習すればここまではできるとか
rustでは最初のプログラムを作るにもたくさんのことを知らなければならないというか
Haskellをかじったことがあり、とても興味深いのですが
わかりにくい独り言に、レスをくださってありがとうございました
0875はちみつ餃子 ◆8X2XSCHEME 2022/10/04(火) 09:48:05.73ID:P4nmisNi
>>874
> 部分的な学習から

できない。
部分的に学習して何かができたように見えても必ず間違ったものを書いているのが C++ というもの。
学習を進めていくにつれて間違っていたことに何度も気づくのでうんざりした経験があるだろ?
0876デフォルトの名無しさん2022/10/04(火) 10:23:23.92ID:5od2FDFX
部分的な学習ってのは
C with classes -> STL -> move
みたいな感じじゃない?
他人のコード読むなら全部必要だけど、独習してる分には最初テンプレートとかなくてもいけるでしょ
0877デフォルトの名無しさん2022/10/04(火) 12:43:12.54ID:7zYgBA5I
>>875 >>876
横からだけど、「部分的な学習」はもっと手前のところ。初心者でも
空のコード->リテラル->関数呼出->ライブラリ使用->変数定義・使用
あたりで使い方が広がるんだけど、Rustは関数呼出-変数あたりに概念のデカイ塊がある。

このあたりをまとめて覚えないと機能するプログラムを組めないので、学習者には辛い状態が続く。
Rustはc++以上に挫折しやすいと思う。
0878デフォルトの名無しさん2022/10/04(火) 12:54:59.39ID:zVqHX6VA
借用と実体(所有権)を常に意識しなきなならんからね
Cだと全部ポインタ使うから意識しないんだけどね
0879デフォルトの名無しさん2022/10/04(火) 13:01:26.34ID:NJ6V6LdV
どんなプログラミング言語でもいいから何か言語を学習済みの人にとって
他の言語を学習するのは部分的に段階的にすることが可能だよ
もちろんRustでも同じで初心者向けの学習本
The Rust Programming Language
https://doc.rust-jp.rs/book-ja/
を順番に少しずつ進めれば部分的に段階的に学習できるよ
0880デフォルトの名無しさん2022/10/04(火) 13:14:23.44ID:fXb8hG+g
>>877
段階を経ず一気に進める無謀なことをする人だけが挫折するかもしれないが無謀なその人が悪い

>>878
いきなりそこまで進める人は単なる無謀者
まずは他の言語と同じ使い方
・実体のコピー
・参照(=借用)
のみ使っている限り所有権なんて知らなくてよい
参照を戻り値としない限りライフタイムも知る必要ない
まずは部分的な学習をすればいい
その後で所有権とライフタイムを学べばよい
0881はちみつ餃子 ◆8X2XSCHEME 2022/10/04(火) 13:25:41.11ID:P4nmisNi
>>877
> 関数呼出-変数あたりに概念のデカイ塊がある

C++ にもある。
あるのに中途半端な状態で間違った使い方が出来てしまうのが問題の根源。
まともに機能していないことに気づかずに
機能するプログラムを作れていると誤解して後になって結局は行き詰る。

>> 878
意識する必要はある。
コンパイラが検証してくれないのだからむしろ C のほうが強く意識する。
0882デフォルトの名無しさん2022/10/04(火) 13:37:36.16ID:pLeAl7hn
まずは(Copy実装型の)数値演算だけやって変数と関数の使い方を覚えればいいだけじゃん
所有権なんて出て来ないぜ
その後にようやく数値の配列をやってその参照渡しと可変参照渡しを学ぶ
といったように順番にちよっとずつ学習していけば全くの初心者でも躓くことはない
0884デフォルトの名無しさん2022/10/04(火) 13:49:35.50ID:ez1nu7fa
部分的な学習ができないと主張してるやつは、いきなり無茶なことをしてるバカだけだな。
0885デフォルトの名無しさん2022/10/04(火) 14:54:07.07ID:zVqHX6VA
>>880
でも標準機能の中でその理解が必要なんだよ
into_iterとかiterとか
その辺は本当にちゃんと理解してないとまともなループする書けない
0886デフォルトの名無しさん2022/10/04(火) 15:06:46.90ID:ZhUau2yw
言語の学習ではあまりないと思うけど複数のコンポーネントを全て完動させないと到達出来ない領域があるのは確か
レイヤーが下がるとそう言うのも珍しくない
0887デフォルトの名無しさん2022/10/04(火) 15:37:58.58ID:attOzucb
>>885
それは一気に全てを理解しないといけないと思い込んでるアホ人間だから
初心者のうちはfor文なんてざっくりした理解で十分に学習をどんどん進められる
後にIntoIteratorを理解する段階になってようやくfor文を完全に正解に理解すればよい
0889デフォルトの名無しさん2022/10/04(火) 16:01:39.35ID:zVqHX6VA
>>887
いやそれは無理があるだろ
所有権と借用の理解は型変換の時にも必須
collectとか使うときにも必須
競プロみたいな数値だけ扱うようなプログラムならかけるけど
0890デフォルトの名無しさん2022/10/04(火) 16:03:22.02ID:LLFCSjL7
>>886
それは言語の学習と関係ないよね
Rust固有の話でもないね
つまり今回の話と全く関係ないでしょう

ちなみにそういう時はサンプルコードなどをまずは魔法の呪文とブラックボックスとして受け入れましょう
そして一つずつ把握する範囲を広げていけばよいのです
失敗する人は最初から全てを把握しようとする人だけです
0891はちみつ餃子 ◆8X2XSCHEME 2022/10/04(火) 16:06:42.76ID:P4nmisNi
>>885
問題点が分かってきた。
「部分的な学習」というのは項目をひとつきちんと理解してから次の項目の学習に移るみたいなスタイルを前提としているんじゃないか?
俺が思ってた学習スタイルは「概念が存在していることは知っている」という程度の全体像から解像度を上げていくような方向性だった。
機能は互いに連携するので「この部分は完璧にわかっているけど他はまだ」なんて状況は有りえんし、そういう学習方法できちんと身につくとは思わない。
(もちろん人によってやりやすいスタイルはあるのだろうけども、個人的にはオススメ出来ない。)

流し読み程度でも入門書を一度読めば (細かい借用規則を覚えていなくても) iter を使うくらいは出来るよ。
そこから何度でも読んで細かい理解を深めていくんだよ。
0892デフォルトの名無しさん2022/10/04(火) 16:09:22.52ID:Yud6QviI
>>889
キチガイは黙っていろ
どんな世界でもそんなに一気に大きく手を広げて学習しようとして上手くいくわけがない
単純に一つずつやっていくのが正しい
collectなんて後で困らん
そもそもイテレータ使わなきゃcollectは出て来ない
ぶっ飛んだことを書き込んでいることを自覚しろ
0894デフォルトの名無しさん2022/10/04(火) 16:15:28.56ID:Qrm8xufh
>>889
collectを使わなくてもプログラムを書けるから少しずつ学習していく方法でも支障はないし
collectを一旦は魔術だとみなして仕組みの詳細まで把握せずに利用して進めていく学習方法でも支障はないし
FromIteratorなんてあとから学べば十分ですよ
0895デフォルトの名無しさん2022/10/04(火) 16:17:47.88ID:zVqHX6VA
いやcollectをここまで安全かつ効率よく実装してる言語はないのにそれを使わないのは論外
0896デフォルトの名無しさん2022/10/04(火) 16:19:54.90ID:zVqHX6VA
戦国時代に例えるならここに名刀があります
ワタクシは未熟だからこの刀は使いませんと言って
戦に出て殺されるみたいな話
その名刀を最初から使えるように訓練すべき
0898デフォルトの名無しさん2022/10/04(火) 16:26:15.56ID:Qrm8xufh
>>895
使いたいならば使えばよいだけですよ
初心者がFromIteratorの仕組みまで理解しないとcollectを使っちゃいけないのですか?
この場合の『部分的に学習』とはcollectの機能の一部をまずは表層的にのみ理解して使ってみることです
そしてこの『部分的に学習』は可能です
0900デフォルトの名無しさん2022/10/04(火) 16:29:25.15ID:zVqHX6VA
いやだから「表層的な学習」だとコンパイルすら通せないんだって
0901デフォルトの名無しさん2022/10/04(火) 16:31:30.86ID:zVqHX6VA
何度も言ってるけどRustはコンパイルを通せば
意図してないエラーはまず起きないし
Nullで落ちるなんてこともない
0902デフォルトの名無しさん2022/10/04(火) 16:35:17.34ID:vFqvnIUB
頭がいいと思い込んでる馬鹿がいきなり複雑な難しいことに挑戦して失敗して
難しい!とわめく馬鹿パターンはどんな分野でもある
その馬鹿が>>896
0903デフォルトの名無しさん2022/10/04(火) 17:00:26.62ID:zVqHX6VA
「段階的学習」というのは数学や物理においては成立する言葉だがプログラミングにおいては成立しない
なぜなら「知識の差」が普遍的に影響を受けてしまうから
例えば数学では代数学の理論を知らなくても初等整数論は学べるがプログラミングではそのようなことはないとわかる
0904デフォルトの名無しさん2022/10/04(火) 17:01:28.47ID:zVqHX6VA
例えばアルゴリズムの問題もそう
「知らない」ことが致命的になり得る
0905デフォルトの名無しさん2022/10/04(火) 17:06:11.40ID:zVqHX6VA
collectを知らないものが自前でfor文で同じことを実装していたらどうなるだろうか?
レビューで指摘され赤っ恥を書かされてプライドはズタズタ
それが原因で鬱になるかもしれん
さらにパフォーマンス悪くなる
精神的にも肉体的にもダメージを負うことになる
0906デフォルトの名無しさん2022/10/04(火) 17:18:30.46ID:vFqvnIUB
>>905
真逆だ
初心者の学習過程ならばcollectを使わずに実装することは適切な練習問題だ
その段階を経てからcollectを学習した者こそ身に付く
0908デフォルトの名無しさん2022/10/04(火) 18:05:45.53ID:qunzxQTR
>>907
その通りなんだけど
Rustは段階的な学習ができない!と主張している変な人がいるのよ
0911デフォルトの名無しさん2022/10/04(火) 19:01:55.07ID:7zYgBA5I
>>907
初心者・初学者に「the bookを読め」はさすがにむちゃだろ。

やっぱり「初心者はRust使わず他の言語から勉強しろ」が正解なのかね。
0912デフォルトの名無しさん2022/10/04(火) 19:07:38.54ID:gMN5eNCr
>>891
さすが餃子さん分かってらっしゃる
最初は大まかな理解→もう少し詳細な理解→最後に完璧な理解という解像度の段階的な学習を中心に
項目や範囲を広げていく網羅度の段階的な学習を組み合わせることでRustの学習を含めて一般的な事柄にも適用できる
0913はちみつ餃子 ◆8X2XSCHEME 2022/10/04(火) 20:17:29.13ID:P4nmisNi
>>911
そこで言ってる「初心者」は「Rust の初心者」ではなく「プログラミングの初心者」の意味?
そうだとすると the book はちょっとハードルが高いということはあるかもしれんな。

でも C++ と比較すると C++ のほうがもっとハードルが高いと思う。
コンパイラが検出しないところで未定義に入り込むことがあまりに多い。
初心者が間違うのは当然のことだが、正しいのか間違っているのかわからないというのは間違っていることが明白であるよりもしんどい。
そこで間違ったまま邁進できるようなメンタルの持ち主はそれはそれで遠からず行き詰るし。
0914デフォルトの名無しさん2022/10/04(火) 20:27:55.40ID:9Mq2x6bG
>>867 ですが、
>>876 さんがおっしゃることが僕の意図を言い当てています
c++を使わなくなって 15年は経ちますが、その頃の c++にはテンプレートはありましたがスマートポインタやラムダ式、その他諸々のモダンな機能はまだありませんでした(と思います)
クラス付きのCの部分で仕事をしていました
モダンなc++へ再入門するか、rustを学ぶか迷って rustに触れて今に至りました
0915デフォルトの名無しさん2022/10/04(火) 20:36:11.60ID:pQmQIrKs
>>914
C程度の予備知識があるならば
>>907のRust Bookだけで容易に段階的に学習できるから何ら問題は起きず大丈夫
0916デフォルトの名無しさん2022/10/04(火) 21:10:32.92ID:d7kGndGU
所有権も借用も生存期間も理解してなければ
メソッド呼び出し一つ満足にできないんだから
それら無しに動くものが作れるわけない

学習自体は言語に限らずどんな学習でも部分的段階的にやるもの
それ以外の方法なんてないんだから論点ずれてる
0917デフォルトの名無しさん2022/10/04(火) 22:06:44.90ID:GBsxPWRL
>>916
それはさすがに無知すぎやろ
Rustは数値など所有権とは無縁な型で構成されているから
所有権なんて理解しなくてもプログラムを組める
段階的に後から所有権を学ぶことができる
0923デフォルトの名無しさん2022/10/05(水) 03:09:52.75ID:Ybu4BU3z
どうも段階的にやれると思ってる人はデータタイプを数値に限定してる気がする
数値はコピー可能でありRustのサンプルとしてよく使われるが
コピー可能なオブジェクトというのは普通のアプリケーションでは効率が悪すぎて使わない
つまり所有権の理解は必須なのだよ
0924デフォルトの名無しさん2022/10/05(水) 03:15:49.43ID:UScD8/dK
初学者にマウント取りするだけで、ステップアップの具体的なノウハウを示したり
理解しやすいドキュメントを整備提供したりできない積極的に導けない人間ばかりの
コミュニティが形成されてる言語は決して流行らない

行き着く先は*BSDのような”魔法使い以外は帰れ帰れ”した結果の荒涼とした世界
0925デフォルトの名無しさん2022/10/05(水) 03:19:22.28ID:Ybu4BU3z
数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう
コピーして効率よく処理できる仕組みがないからmoveが生まれた
0928デフォルトの名無しさん2022/10/05(水) 07:53:16.44ID:MzMPKgoE
初学者にマウント取りたいやつがイキってる
0929デフォルトの名無しさん2022/10/05(水) 10:48:19.99ID:gF0QOXVU
初学者にしてもスタイルは人それぞれだろうし皆がどうやってrust習得したか語ってくれた方が参考になりそう

自分はlifetimeが導入される前からrust触ってたからコンパイラに追加される機能を適宜試してみながら体で覚えた
0930デフォルトの名無しさん2022/10/05(水) 11:23:13.56ID:1F438Xk1
初級者はHello, world!からって、かつての初級者はBASICから並みに罠じゃね
ほとんどのHello, world!は現代のプログラミングで必須の要素が欠落しまくっているからな
0931デフォルトの名無しさん2022/10/05(水) 11:28:02.85ID:BbaUEliB
複オジも100点オジも
もう少しRust勉強してからレスするか
大人しくしとくかどっちかにしてくれ
0934デフォルトの名無しさん2022/10/05(水) 12:32:57.65ID:OxlYZjk9
今担当してる作業が、あるまとまった処理を上手く対応付けするとちょっと複雑な数値演算処理だけに置き換えられるので、
その数値演算ライブラリを作っているのだけど、確かに所有権は全く出て来ない。
入出力は配列(スライス)の参照渡しと可変参照渡しとなっていてライフタイム明記も無し。

所有権を学ぶ前に参照(借用)だけで十分に色んな実践ができると思う。
そして参照は他の言語でも配列などは参照渡しになるから、新たにスライスだけ覚えればRustを段階的に学ぶことができる。
0935デフォルトの名無しさん2022/10/05(水) 12:36:28.49ID:+KHGV4+/
俺はずっとJavaメインで、遊びでlispとかHaskellとか触る程度で低レイヤは触ってなかったんだけど、Rustでここまで現代的に書けるならアリだなって触り始めたクチだな。
0936デフォルトの名無しさん2022/10/05(水) 12:59:55.95ID:EKfM3pGK
>>930
まずハロワやれと言われるレベルの初級者ってプログラミング自体初めてやるようなレベルの人でしょ
それならあれこれ教えたところでどうせ理解不能になるだけなのでとりあえず動くものを作らせることには意味がある
0937デフォルトの名無しさん2022/10/05(水) 13:37:41.28ID:Pj9P59N0
ただいまんこのあとは
シコシコちんちん シコシコ イソチンチン
0938デフォルトの名無しさん2022/10/05(水) 13:47:37.30ID:X575+w0V
かい
0939デフォルトの名無しさん2022/10/05(水) 15:06:32.60ID:wne70pEz
>>930
何を勘違いしてるんだよw
ハロワはプログラミングの勉強じゃなくて>>932も書いてる通り環境の勉強だぞ
お前の言う必須の要素が何を指してるのか知らんけど例えばif文の勉強したい時に動かせるかどうかは重要だろ
0941デフォルトの名無しさん2022/10/05(水) 16:19:48.70ID:7FrBhgJk
>>940
それも真
しかし>>934のような使い方だと所有権を意識する必要すらないのも真
同様に>>934のような使い方だと参照のライフタイムを意識する必要がないのも真
これは類似なものとしてC言語を使っている時に常に所有権とライフタイムを意識する必要性があるわけではないことも同様に例示される
0942デフォルトの名無しさん2022/10/05(水) 17:04:57.53ID:NuKocPG+
噛み合ってない理由がわかった
競プロ勢が多いんだな
数値しか扱わないなら
ベターCとして書くことは容易だからね
0943デフォルトの名無しさん2022/10/05(水) 17:33:30.37ID:66O9N6nP
競プロじゃないけどトレイトとかよく判らないから安定しているCとしてしか使っていないわ
0944デフォルトの名無しさん2022/10/05(水) 17:33:54.20ID:mBRaD/Kx
>>942
競プロ勢による書き込みが見当たらないこの状況で
妄想により幻覚が見えているのか?
0946デフォルトの名無しさん2022/10/05(水) 23:31:57.40ID:lcOrUuZN
色々書いたうちCLI程度の規模のプログラムだと大半は所有権の移動がなくて所有権の意識が薄いな
オブジェクトをnewするところは厳密には移動と言えるかも知れないが単なる値返しと捉えるだろう
あとはオブジェクトの参照を渡していくだけたから単なる参照渡し
0947デフォルトの名無しさん2022/10/05(水) 23:44:31.07ID:V7HNybPt
毎日毎日息を吐くように嘘を吐く複オジ
控え目に言っても頭おかしい
0948デフォルトの名無しさん2022/10/05(水) 23:56:41.83ID:nYqhDlIA
数値型だけでは動くものが作れないことに気がついたみたいだな
Rustで所有権を理解せずに動くものを作るなんて柱を使わずに家を建てるようなもの
0949デフォルトの名無しさん2022/10/06(木) 00:08:02.42ID:aXzDwmUt
>>946
関数が値返しと引数可変参照渡しへの書き込みだけならプログラムの規模や種類に関係なくそんなもんだろ
所有権が出てくる幕はない
もちろんライフタイムも出てこない
0950デフォルトの名無しさん2022/10/06(木) 00:34:26.13ID:XbdFr8Zd
そういう点では所有権が出てこなくてもかなりの範囲のプログラムを書けるよ
0951はちみつ餃子 ◆8X2XSCHEME 2022/10/06(木) 00:34:32.05ID:rLXZsLBm
>>949
いくつかの自明な場合にはライフタイムを省略しても暗黙のルールが適用されるから書かなくてもよいだけで、ライフタイムが存在しないわけではないよ。
その暗黙のルールが比較的自然に定義されてるってことなんだろうね。
0952デフォルトの名無しさん2022/10/06(木) 00:37:42.29ID:4kCBwc0q
>>951
それは違うな
>>949のケースは参照返しをしていないのだからライフタイムは出て来ない
ライフタイムの存在を意識する必要もない
0954デフォルトの名無しさん2022/10/06(木) 01:33:20.48ID:QZHh62Nh
Rustを使ってると、参照を返すようなコードはだんだん避けるようになるかもしれないな
0955デフォルトの名無しさん2022/10/06(木) 01:59:47.45ID:iRnDWdOb
競プロみたいにmain関数のみ
データ型は数値のみ
データ構造は固定配列のみ
サイズも高々数百から数千程度なのでスタック確保でオッケー
配列への参照のみ必要
結果は固定配列を新しく作ってそこに詰めていく
これなら所有権など一切いらない
0956デフォルトの名無しさん2022/10/06(木) 02:04:59.09ID:MtARpYSM
この件は数値型や競プロは一切関係ない

ヒープを使うVecやStringやそれらを含む構造体を返しても『値返し』となる点がポイント
『参照返し』とならないため『ライフタイム』は登場せず『所有権』を意識する必要もない
そして『値返し』だけでも様々な実用的なプログラムをRustで作ることができる
0958デフォルトの名無しさん2022/10/06(木) 02:38:59.47ID:v2j3J5Hy
>>954
個人的にはdangling pointetとか内部オブジェクトを書き換えられる心配しなくて良くなるから
他の言語より積極的に参照返すようになってる気がする
0959デフォルトの名無しさん2022/10/06(木) 06:12:47.90ID:QjC44cq3
参照返しの安全性を保証できるRustいいよな
参照返しを使わず値返しだけでもかなり広い範囲のことを処理できる点も同意
0961デフォルトの名無しさん2022/10/06(木) 15:10:52.39ID:9m7OD5Nx
参照を返す時のみ
ライフタイムの概念が登場
だから参照返しと値返しの区別は実質的に重要

もちろんRustでは常に(広義の)値返しとなる
そして参照返しとは参照を(広義の)値返しすること
参照返しの対義語として(狭義の)値返しを使ってもよい
0962デフォルトの名無しさん2022/10/06(木) 15:23:56.79ID:v2j3J5Hy
構造体など参照以外の値がlifetime持つ場合もある
参照だけ区別するのはなぜ
0964デフォルトの名無しさん2022/10/06(木) 15:29:37.21ID:phH8VW1M
>>962
それはそのフィールドが参照を返しているね
構造体がライフタイムを持つのはそのような時
0966デフォルトの名無しさん2022/10/06(木) 15:37:35.04ID:mTG1aBjr
最初に言い出したのは

>>952
> >>951
> それは違うな
> >>949のケースは参照返しをしていないのだからライフタイムは出て来ない

これか
0970デフォルトの名無しさん2022/10/06(木) 15:45:23.29ID:JBcgzpIo
Rustでは参照返しが有る時だけライフタイムパラメータが付くんよ
例えば3つの参照返しが有る時に3つのライフタイムが異なれば3つのライフタイムパラメータが付くんよ
だから参照返しが有るか無いか区別されてしまうんよ
0971デフォルトの名無しさん2022/10/06(木) 16:06:44.80ID:sWKfpE/G
結局Rustにおける値と参照とは何かを知るためには所有権の理解が必須なワケよ
0973デフォルトの名無しさん2022/10/06(木) 16:23:06.37ID:bcHprxpF
>>971
参照を返さない限り所有権の理解は不要
Rustでは配列も構造体も更にはヒープを用いるVecやString等も値として返される
つまり参照を返さなくてもある程度の広範囲のプログラムを書くことができる
0976デフォルトの名無しさん2022/10/06(木) 16:42:22.59ID:bM/kk4ia
所有権要らないならRust要らないじゃんって思いながらずっと読んでる

どういう結論に持っていきたいの
0977デフォルトの名無しさん2022/10/06(木) 16:44:20.49ID:QZHh62Nh
釣りが目的で書き込んでるひとと、それに付き合ってレスしてるひとがいるからわけわからん
0978デフォルトの名無しさん2022/10/06(木) 16:49:39.04ID:+ZB5z2+t
参照渡しだけして参照返しをしなければ
所有権もライフタイムも出てこないからそれらを意識することもない
結果として所有権とライフタイムを理解していなくてもそのスタイルでプログラムを組むことが出来てしまう
0979デフォルトの名無しさん2022/10/06(木) 17:03:06.06ID:HCQdlFdq
>>976
rust 学習の話だろ?
未来永劫所有権の理解は不要なんて誰も言ってないと思うが
0980デフォルトの名無しさん2022/10/06(木) 18:43:34.42ID:rjzElph2
逆にrustだとどういう時に参照返しが必要になるの?
0982デフォルトの名無しさん2022/10/06(木) 19:17:16.58ID:mTG1aBjr
「参照で返す」「参照を返す」って表現する人 ←わかる
「参照返し」と言い続ける人 ←???
0984デフォルトの名無しさん2022/10/06(木) 19:40:30.33ID:mTG1aBjr
値渡し参照渡しで言うと依然として単なる値渡しなのに
ただポインタを渡してるだけでそれを
「ポインタ渡し」とか言い出したり
ひどいやつだと「参照渡し」だと言いはったり
そういうのを過去にC言語界隈で見てきたから気になったんよ
独自解釈による珍妙なワードはこの世に必要ないと思うでしょ

>>983
そうですかボクからはもう何も言うことはありません
0985デフォルトの名無しさん2022/10/06(木) 19:48:59.04ID:dbBfkB/k
>>984
それは君が区別すべきことを理解できていないから混乱している
会話や説明では何と何を区別するかが重要
もちろんRustでは常に指定した型そのものが渡され返される
だから区別するとしたら実体を渡したり返したりするのかその参照を渡したり返したりするのかが焦点となる
したがって参照渡しや参照返しという言葉がぴったり適して使われている
0986デフォルトの名無しさん2022/10/06(木) 19:53:30.79ID:mTG1aBjr
あとポインタへのポインタを「ダブルポインタ」って呼んじゃう人もいたな
このスレでは「所有権の複製」ってのもあったな
0987デフォルトの名無しさん2022/10/06(木) 19:58:06.41ID:tLVpM1Ll
>>986
英語でもダブルポインタと言うし何を問題にしているのかわからん
自分勝手な線引きやルールがあってそこから外れると融通が効かなくなるダメな人かね?
0988デフォルトの名無しさん2022/10/06(木) 20:04:50.45ID:aGNYxTl9
ゲームの方のRustで、ホロライブのRustのSeason3が終わるから検索汚染も減るかもな
0989デフォルトの名無しさん2022/10/06(木) 20:12:15.66ID:EteQ2MpB
参照で返すことを「参照返し」と言った途端ブチギレするのマジで意味不明なんだがその呼び方を否定するとどんなメリットがあるのだろうか
0991デフォルトの名無しさん2022/10/06(木) 20:27:57.49ID:RK7Fg483
>>984を見るとCでポインタで渡すことをポインタ渡しと言われるだけで発狂するようだからその人はキチガイ
0993デフォルトの名無しさん2022/10/06(木) 20:52:48.54ID:mb1xnKf4
他への参照を持つ実体を返すのは値返しか参照返しかはたまた別の何かか
なんて考えたくない
0994デフォルトの名無しさん2022/10/06(木) 20:58:52.86ID:EteQ2MpB
「ポインタ渡し」がNGなら「ポインタを渡すこと」も日本語でそう表現していいよと言語の開発者がわざわざお墨付き与えなければNGだと思う
0995デフォルトの名無しさん2022/10/06(木) 21:00:15.33ID:99NRyDSB
今回はRustの段階的学習の話だから、これだけのことではないかい。
参照返しが含まれていなければ、ライフタイムを把握する必要がなく、所有権を学習していない段階でも、そのプログラムを書くことができる。
参照返しが含まれていれば、ライフタイムを把握する必要があり、所有権を学習した以降となる。
0997デフォルトの名無しさん2022/10/06(木) 21:09:49.66ID:Re0G7B20
ぼくちゃんrust入門者
ライフタイム注釈だけはどうにかならなかったのとか思った
でもいろいろ満足
tauriやるぞう
0998デフォルトの名無しさん2022/10/06(木) 21:23:30.56ID:xIsaLol7
ホント毎日毎日アホなこと書いてるなぁ
釣られちゃうRust入門者は少し不憫
10011001Over 1000Thread
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 101日 13時間 18分 37秒
10021002Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。

ニューススポーツなんでも実況