Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

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

※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 part23
https://mevius.5ch.net/test/read.cgi/tech/1708677472/

**デフォルトの名無しさん** · 2024/05/27(月) 06:42:29.23

**デフォルトの名無しさん** · 2024/05/27(月) 06:43:12.56

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
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 macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/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 serde Book
https://serde.rs/

**デフォルトの名無しさん** · 2024/05/27(月) 08:12:23.89

Cloudflare、HTTPプロキシ開発用RustフレームワークPingoraをオープンソース化
ttps://www.infoq.com/jp/news/2024/03/cloudflare-open-sources-pingora/

**デフォルトの名無しさん** · 2024/05/27(月) 19:41:54.75

>>1 乙

**デフォルトの名無しさん** · 2024/05/27(月) 21:05:50.42

なんで黙ってﾜｯﾁｮｲスレのリンク消したの？

**デフォルトの名無しさん** · 2024/05/27(月) 21:10:59.53

>>1乙ust

**デフォルトの名無しさん** · 2024/05/27(月) 23:31:45.00

rust-lldって魔法？

**デフォルトの名無しさん** · 2024/05/28(火) 23:01:09.87

「Sudo for Windows」はRustで開発されている！
メモリ安全が重視される分野で採用が広がるRust言語
ttps://forest.watch.impress.co.jp/docs/serial/yajiuma/1594981.html
次期大型更新「Windows 11 バージョン 24H2」に
搭載されることが確定した「Sudo for Windows」が、
Rust言語で開発されていることがわかった。

**デフォルトの名無しさん** · 2024/05/29(水) 09:39:32.15

完全にRustは残る言語になってしまったね

**デフォルトの名無しさん** · 2024/05/29(水) 11:05:17.42

言語の生き残るか否かもWindows次第かな

**デフォルトの名無しさん** · 2024/05/29(水) 13:45:30.43

この言語を支持してるやつは総じてデバッグ能力が低い

**デフォルトの名無しさん** · 2024/05/29(水) 13:56:47.79

なるほどそれはもうやるしかないね

**デフォルトの名無しさん** · 2024/05/29(水) 14:07:58.08

今更こんなのだけで一喜一憂するの？

ちなみにAzureCLIもRustだぞ
MacでHomebrewでインスコする時にRustのコンパイル始まって凄く時間掛かる

**デフォルトの名無しさん** · 2024/05/29(水) 14:55:30.35

ʕ◔ϖ◔ʔ

**デフォルトの名無しさん** · 2024/05/29(水) 16:53:17.15

>>12
テスト走らせるんじゃあかんの？

**デフォルトの名無しさん** · 2024/05/29(水) 17:06:12.76

>>9
これ仕組み上、console APIやTUIは動作しない
(それと肝心なところのほとんどがunsafeなのは見なかったことに)

**デフォルトの名無しさん** · 2024/05/29(水) 19:19:21.66

そういや、sudoとかの引数のバッファオーバーフローとかって、std::env::args_os使っていれば安全なのかな？

**デフォルトの名無しさん** · 2024/05/29(水) 22:46:32.28

unsafeはRust外のFFI/API境界でのやむを得ない出現か
unsafeを使うことで効率的かつ安全なパターンになる時のいすれかだが
後者のパターンは特定のプログラムから切り離してsafeなインターフェースを提供する汎用ライブラリに閉じ込めるのが好ましく
標準ライブラリはそのようにして出来ている

**デフォルトの名無しさん** · 2024/05/30(木) 12:31:47.54

つまりwindowsクレートはsafe interfaceの提供をサボってるということ？

**デフォルトの名無しさん** · 2024/05/30(木) 12:33:13.48

Rustと外側との境界はunsafeにせざるを得ないのは当たり前なのに肝心なところはunsafeと言われてもなぁ。
レビューすべき箇所が局所化されるだけでも十分なメリットだろ。

**デフォルトの名無しさん** · 2024/05/30(木) 14:46:49.26

>>20
>>21
どちらも正しい
Rustとその外側の境界部分で必ずunsafeが生じるからそこを問題にすることはない
ただしその部分は安全なインタフェースを提供するモジュールかできればクレートとして分離するのが好ましい

**デフォルトの名無しさん** ころころ · 2024/05/30(木) 16:38:16.78

Rust製Webサーバーで一番使われてるフレームワークって何だろ
MySQLと親和性高いなら使ってみたい

**デフォルトの名無しさん** · 2024/05/30(木) 18:56:43.74

>>23
axumとsqlx

**デフォルトの名無しさん** · 2024/05/30(木) 21:16:17.01

>>24
ありがと、試してみよう

**デフォルトの名無しさん** · 2024/05/31(金) 21:36:08.12

コンパイル前にcargo sqlx prepareでDBサーバからデータの型を得ておくことで静的型チェックできる仕組みなんだね

**デフォルトの名無しさん** · 2024/06/01(土) 10:39:11.44

へー、便利そう。
だけどこういう仕組みってカラム追加時のDBのマイグレーション辺りが入ってくるととたんに難しくなるんだよなぁ。

**デフォルトの名無しさん** · 2024/06/01(土) 22:15:15.67

>>27
そういうDBテーブル構成変更するとどんなプログラミング言語でも何らかの対応が必要となるよ
Rustでsqlx利用ならばDB構成変更した時にcargo sqlx prepareで型をDBから入手し直せばコンパイル時に静的に型チェックされるから楽で安全だね

**デフォルトの名無しさん** · 2024/06/01(土) 22:32:36.24

DBの構成管理をどこで行うかという話
その辺の道具類は他言語に比べてRustはまだまだなので
DB側のツールで管理しておくという昔ながらのやり方が現状のベスト

**デフォルトの名無しさん** · 2024/06/01(土) 22:35:04.27

スクラッチのPHPみたいにSQL直書きからのexecuteはナシ？

**デフォルトの名無しさん** · 2024/06/01(土) 22:44:45.41

>>30
Rustのコード内にSQL直書き文字列を書ける
その上でデータベースとの静的な型チェックもされるのがsqlxのメリット

警備員[Lv.6][新芽] · 2024/06/01(土) 22:51:53.44

それで実行計画も取れるの？

**デフォルトの名無しさん** · 2024/06/01(土) 23:58:30.16

実行計画はDBのデータではないから型チェックは意味ないような

**デフォルトの名無しさん** · 2024/06/02(日) 09:14:40.51

>>21
機械語に近い部分がunsafeなのは当たり前だけど
それを手書きしていることを納得させるのが難しいんだろう
一番自動化されてるフレームワークを使ってみたいんだろ

**デフォルトの名無しさん** · 2024/06/02(日) 12:55:11.71

接続相手の仕様が形式化されたデータとして存在すれば
Rust 上の関数との対応付けを自動化できることもあると思うけど
形式化されたデータは誰かが準備しないといけないことには変わりないからなぁ。

Windows では API の仕様記述を WinMD と呼ばれる形で標準化してるけど
それだって WinRT (ちょっと高級な API) が前提になっているのでそんなに万能ではない。

あらゆる仕様を記述できるほど自由度 (複雑さ) のあるフォーマットにしたら結局は
プログラムを書くのとそんなに変わらんようになるので自動化できる部分は自動化して
ややこしい場合は手書きするという割り切りしないと仕方ない。

**デフォルトの名無しさん** · 2024/06/02(日) 23:32:50.95

Unix系システムコールとの共通部分は
ファイルシステムなど標準ライブラリとして安全なインターフェイスを提供できてるね
Windows特有部分も同じようにMicrosoftがsafeなライブラリを公式に用意することが望ましいのかな

**デフォルトの名無しさん** · 2024/06/03(月) 08:58:28.03

>>35,36
なるほど。結構時間経ったと思うが厳しい。

Microsoftがsafeなライブラリを公式に用意するまで、
プロダクションでのRust採用は様子見するのが良さそうだ。

Linux特有の機能が必要な場合も同様に様子見するのが良さそうだ。

**デフォルトの名無しさん** · 2024/06/03(月) 09:53:26.77

>>37
Windows クレートはもうかなり充実してるよ。
メタデータからの自動生成なので網羅的だし、 safe でいけるメソッドは safe になってる。
unsafe なのは本質的に unsafe なのでどうしようもないし。

Readme に書いてある例が古い Win32 API を使うスタイルの書き方だから印象が悪いのかなぁ……。

**デフォルトの名無しさん** · 2024/06/03(月) 12:15:09.36

>>37
LinuxでRustで困ってることないよ
様子見しなきゃいけないことがあるのならば具体的に挙げてみたら？

**デフォルトの名無しさん** · 2024/06/03(月) 15:47:20.28

>>38
>本質的に unsafe
良いキーワード出た、深掘りしてくれ

これとか
github.com/tokio-rs/io-uring

io_uringが本質的にunsafeだとでも思ってるのかな？

**デフォルトの名無しさん** · 2024/06/03(月) 16:27:42.41

本質的にC++な機能といえば多重継承
多重継承は他の言語に移植できない
万一できたとしたらそれは自動生成ではなく手作業で工夫されたコードだろうね

**デフォルトの名無しさん** · 2024/06/03(月) 17:17:59.54

Win32APIを素で提供しようと思ったらunsafeなのは仕方ないので、もう一枚ハイレベルなラッパーかませてsafeにしてほしいところではある。

**デフォルトの名無しさん** · 2024/06/03(月) 19:27:13.29

だからモダンな WinRT に移行しようね！

**デフォルトの名無しさん** · 2024/06/03(月) 20:11:34.31

WinRTってWin32のAPI網羅できてるの？
モダンなAPIが古いのを機能的に網羅できてないから仕方なく使ってる気持ちなんだけど。

**デフォルトの名無しさん** · 2024/06/03(月) 20:49:12.70

WinRT は「おおよそ」には Win32 API の機能を網羅しているが
根本的なパラダイムが違っていて単純には置き換えられない場合はある。
最初から WinRT を前提として作っていれば Win32 API 抜きで行けることは多いよ。
ゼロではないところがイライラするかもしれんけど。

**デフォルトの名無しさん** · 2024/06/03(月) 21:57:04.03

>>41
クラス多重継承は問題多すぎなダメな機能なので多くの言語で禁止している
クラス継承そのものが問題を多く抱えているため各機能のインターフェースなどを実装するのが望ましい
Rustならば複数のトレイト境界を指定することでそれら複数のトレイト機能を実装した任意の型を対象に抽象的なプログラミングができる