Rust part10

**デフォルトの名無しさん** · 2021/04/02(金) 21:38:04.11

Mozilla発のRust言語のスレ

公式
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 part9
https://mevius.5ch.net/test/read.cgi/tech/1598112455/

**デフォルトの名無しさん** · 2021/04/06(火) 02:13:12.02

そういう人は低レイヤーを触るのがそもそも間違ってる。

**デフォルトの名無しさん** · 2021/04/06(火) 02:33:17.68

まともなマニュアルすらないからな。魔境

**デフォルトの名無しさん** · 2021/04/06(火) 04:24:25.20

>>15
独学するしかないと思ってた

**デフォルトの名無しさん** · 2021/04/06(火) 09:55:26.42

cmakeやmesonやIDEの支援があると言ってもやはり敷居は高いわな

だがrust使うにせよC/C++のライブラリ使ったりドキュメント読む羽目になるのでやはりある程度相互運用の知識は必要

**デフォルトの名無しさん** · 2021/04/06(火) 11:13:42.73

オープンソースの makefile は無意味なごみが集まってるから読みにくいだけ。
特に gnu makeがおかしい。
gnu 系はヘッダファイルもソース本体も汚い事が多い。

**デフォルトの名無しさん** · 2021/04/06(火) 12:13:30.74

ここにはC++使いしかいないのか

**デフォルトの名無しさん** · 2021/04/06(火) 12:16:43.42

その類のmakefileはautoconfとautomakeで自動生成されるもので、人間が読むものじゃないでしょ

**デフォルトの名無しさん** · 2021/04/06(火) 12:28:15.32

C++03の地獄を見てきた者達だ
面構えが違う

**デフォルトの名無しさん** · 2021/04/06(火) 16:42:56.60

Rust の世界だけを考えるならビルドプロセスは Cargo に書いておけばそれで OK だけどね。
全て Rust だけでは書けない場合には従来のツールチェインに更に Cargo が加わって余計にややこしくなってるとも言える。
https://xkcd.com/927/

ツールが汚いのは現実が汚いからだよ。
汚い現実から目をそらして綺麗なルールの中に閉じこもっても、
汚い現実が消えてなくなるわけじゃない。

Makefile が不愉快なら Makefile を使わないプロジェクトを増やすのを頑張るこったな。

**デフォルトの名無しさん** · 2021/04/06(火) 17:35:44.74

rustだけのプロジェクトでもcargo-xtaskを使ってたりするからcargoだけですべてOKかというと微妙だけどね
タスクランナーやビルドのポストプロセスなんかのサポートって予定されてるの？

**デフォルトの名無しさん** · 2021/04/06(火) 18:23:14.98

Rust版makeみたいなツール見かけた気がする

**デフォルトの名無しさん** · 2021/04/06(火) 19:12:35.86

>>26
つ https://github.com/sagiegurari/cargo-make

**デフォルトの名無しさん** · 2021/04/06(火) 23:23:49.86

そういうのあるの知ってるけどcargo本体に取り込む予定があるかが気になってる
グローバルにその手のツールインストールするとバージョン固定が難しいので
npmみたいにlocal installできるならそれでも良いけど

**デフォルトの名無しさん** · 2021/04/07(水) 09:04:42.45

対応は結構してるわな。ただここの連中はこれくらいもできなさげ。
ttps://qiita.com/mutuya/items/f00a5b99a3f047dc3cb3

**デフォルトの名無しさん** · 2021/04/07(水) 13:04:30.43

>>27
使ってる人いる？

**デフォルトの名無しさん** · 2021/04/07(水) 13:14:18.37

>>30
マルチプラットフォームで単純なmakeより複雑なことをしたいときには使っている。ただ大抵の場合makeでいいんじゃないかとも思う。

**デフォルトの名無しさん** · 2021/04/07(水) 13:18:48.25

Rust in the Android platform
https://security.googleblog.com/2021/04/rust-in-android-platform.html

**デフォルトの名無しさん** · 2021/04/07(水) 14:06:22.69

>>22
ところがそのautoconf系そのものがそもそも汚い。
そして、autoというのは真っ赤な嘘であることが知られている。

**デフォルトの名無しさん** · 2021/04/07(水) 14:24:24.61

たまにCMakeが無いとcargo installがこけるツールがあってげんなりするわ

**デフォルトの名無しさん** · 2021/04/07(水) 15:05:49.86

m4マクロで書くというのはそろそろやめにしてもらいたい

**デフォルトの名無しさん** · 2021/04/07(水) 18:53:05.80

>>30
既定のタスクをそのまま使う分には便利だけど、ちょっとアレンジしようとするとめんどくさかったという感想。
単に慣れの問題かもだが、gnu makeのMakefile中でcargo叩く方がやりやすかった。

**デフォルトの名無しさん** · 2021/04/08(木) 16:35:24.79

>>32
訳
Rust言語でAndroidはより強固・安全に～GoogleがOS開発への導入を進める
https://forest.watch.impress.co.jp/docs/news/1317183.html

**デフォルトの名無しさん** · 2021/04/08(木) 16:40:19.95

Rustバイナリにユーザー名が埋め込まれる脆弱性が発見された

**デフォルトの名無しさん** · 2021/04/08(木) 19:01:45.52

スーパーでよく見かける生産者表示だ、気にするな

**デフォルトの名無しさん** · 2021/04/08(木) 19:25:11.32

ユーザー名といかコンパイル時のソースのフルパスね
ホームディレクトリ配下にソースがあるならログインユーザー名が含まれる
あと発見されたのは最近ではなかったはず

**デフォルトの名無しさん** · 2021/04/08(木) 20:20:07.26

それを消すためのオプションは数年前から付いてて
そのオプションがうまく効かないケースがあるってバグが修正中なはず
最近あったのは単にその話を記事に書いた人がいるってだけ

**デフォルトの名無しさん** · 2021/04/08(木) 20:20:24.34

ディレクトリ名にマイナンバーを入れてる人がいたらどうすんだまったく

**デフォルトの名無しさん** · 2021/04/08(木) 20:46:41.37

どんな間抜けだよ

**デフォルトの名無しさん** · 2021/04/08(木) 21:41:22.53

ディレクトリ名につい「クソプロジェクト」とか入れてるやつはいるだろ

**デフォルトの名無しさん** · 2021/04/09(金) 01:29:12.23

ていうかログインユーザー名に実名いれるとかバカなんじゃないか

**デフォルトの名無しさん** · 2021/04/09(金) 01:29:59.12

>>44
たしかに・・それに近いことは・・ある。

**デフォルトの名無しさん** · 2021/04/09(金) 11:49:57.87

fuck_you_cplusplus とか普通にありそう

**デフォルトの名無しさん** · 2021/04/09(金) 15:11:34.90

どこのモジラだよ。

**デフォルトの名無しさん** · 2021/04/09(金) 20:07:51.03

Linusじゃないの

**デフォルトの名無しさん** · 2021/04/10(土) 00:22:28.46

Linusが吠えた! ─中指立てて「NVIDIAは世界最悪の企業」
https://gihyo.jp/admin/clip/01/linux_dt/201206/18

それはそうとして、Rustの（Goもだが）「..」が
begin～lastの意味ではなくて
begin～last+1なのは
コメントに「arr[0..3]」とか書きたい場合に地味に困る

**デフォルトの名無しさん** · 2021/04/10(土) 02:24:29.60

>>42
ネタにマジレスするけどマイナンバーはただの概念で
国民識別番号は国のサーバーに有る。

>>50
last+1って何？　..は[begin, last)だぞ。
左閉右開半開区間はPLじゃ一般的だけど。

**デフォルトの名無しさん** · 2021/04/10(土) 03:35:58.01

>>51
begin～last すわなち [begin, last]　をRustで書いたら
begin..last+1
になる、という意味やったｻｰｾﾝ、

しかしコメント内に現れた「a..b」は、Rust式に[a, b)と解釈すべきなのか、
それとも伝統的な[a, b]解釈とすべきなのか
というのがそこはかとなく疑問が……

**デフォルトの名無しさん** · 2021/04/10(土) 03:38:59.03

同じことは「=」と「==」（代入と等値）の使い分けを
コメント内にまで持ち込むべきかどうかという意味で
昔から迷う感じだったものがRust（やGo）の「..」のせいで悩みの種が増えたは！

**デフォルトの名無しさん** · 2021/04/10(土) 10:43:41.15

>>52
Rustコード中ではbegin..=lastって書いたほうがいい（>=rust-1.26.0）
知ってたらすまん

>>53
Rubyもそうだぞ

**デフォルトの名無しさん** · 2021/04/10(土) 10:51:20.63

pythonもじゃないか？
C系のfor(int i=0;i<5;i++)の終了条件に合わせてあるのかと思う

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/10(土) 11:33:17.54

最後の要素を意味するときは last で、
最後の要素のひとつ後を指すときは end を使う習慣があると
どこかで見た覚えがあるんだけど、
別の言語だったかもしれないしどこかの数学分野だったかもしれない。
うろおぼえでスマソ

**デフォルトの名無しさん** · 2021/04/10(土) 11:52:10.96

既存の言語でも a..b が [a,b] になるもの、[a,b) になるものが混在してたこと、
また、見た目で意味が明確にわかることから a..b と a..=b を採用したという経緯だった気がする

**デフォルトの名無しさん** · 2021/04/10(土) 16:42:23.36

https://doc.rust-lang.org/book/ch02-00-guessing-game-tutorial.html
の一番最後のコードをコピペしてもエラーで動かないのですが
どこをなおしたらいいのでしょうか？

**デフォルトの名無しさん** · 2021/04/10(土) 17:11:01.23

cargo. tomlそのままってオチかな？

**デフォルトの名無しさん** · 2021/04/10(土) 17:13:25.76

randの追加はしております

**デフォルトの名無しさん** · 2021/04/10(土) 17:23:47.25

エラーメッセージを

**デフォルトの名無しさん** · 2021/04/10(土) 17:24:38.49

エラーそのまま貼らないとわからないわ
と言うか頭からやりなよ

**デフォルトの名無しさん** · 2021/04/10(土) 17:50:35.32

せっかく日本語訳だってあるわけだし
https://doc.rust-jp.rs/book-ja/ch02-00-guessing-game-tutorial.html

**デフォルトの名無しさん** · 2021/04/10(土) 21:25:06.44

あ、すいません
randのバージョンを最新版のものにしてました
チュートリアルで指定されているバージョンにしたら動きました
失礼しました

**デフォルトの名無しさん** · 2021/04/10(土) 21:28:15.45

乱数なんて超基本的なライブラリが
コンパイル通らないぐらいのAPI変更を簡単にやってしまうなんて大丈夫なのかこの言語

**デフォルトの名無しさん** · 2021/04/10(土) 21:58:15.68

この場合は言語の責任でもないしそのためのcargoだし

**デフォルトの名無しさん** · 2021/04/10(土) 22:07:11.12

でもせっかくこういう体験したのであればソースの方を直すのも正しき甲殻類な気がするな

**デフォルトの名無しさん** · 2021/04/10(土) 22:55:00.58

最近使ってないけど
randってなんか使いにくいAPIだった気がする

**デフォルトの名無しさん** · 2021/04/11(日) 01:46:09.52

最近マシになってきた

**デフォルトの名無しさん** · 2021/04/11(日) 03:28:20.09

マシにする為だろうが一度決めたAPIは変えない
それがC/C++界の掟じゃないのか？

**デフォルトの名無しさん** · 2021/04/11(日) 08:22:28.91

絶対に変えないようにした結果かえってひどいことになってるイメージ

**デフォルトの名無しさん** · 2021/04/11(日) 08:57:50.42

普通は破壊的仕様変更のときはメジャーバージョン変えそうなもんだがバージョン0だからな

**デフォルトの名無しさん** · 2021/04/11(日) 09:07:58.37

バージョン0のうちは破壊的な変更もし放題ということか

**デフォルトの名無しさん** · 2021/04/11(日) 09:12:29.26

そいや非推奨や廃止の警告出せたっけ？

**デフォルトの名無しさん** · 2021/04/11(日) 10:02:11.52

>>74
deprecatedアトリビュートで出せるよ

**デフォルトの名無しさん** · 2021/04/11(日) 10:25:10.63

Microsoftがプログラミング言語「Rust」への支援を強化
https://news.yahoo.co.jp/articles/d9e8b5acb96920789bb4364951481f074bfd93d8

visual rustとか出さないでよね…

>>75
だよねえ
どのバージョンで変えるか警告はするよねえ

**デフォルトの名無しさん** · 2021/04/11(日) 10:47:22.32

んでバージョン指定変えてみたら

get_rangeの引数が最小、最大+1の２つから最小..最大+1の範囲リテラルに変わったのね

カンマを..に一ヵ所変えるだけだったから修正自体は対したことなかったけどオーバロードがあればもっと緩やかな改変が出来るのだろうか？
ゼロコスト抽象化の方針上仕方ないのだろうか？

**デフォルトの名無しさん** · 2021/04/11(日) 11:24:02.64

>>77
そんなしょうもない変更の為に互換性破壊したのか

**デフォルトの名無しさん** · 2021/04/11(日) 11:29:55.74

>>78
..= が使えるようになったとあるのでインターフェースの改善ではあるのでは
あと破壊的変更はこれだけではない
https://rust-random.github.io/book/update-0.8.html

**デフォルトの名無しさん** · 2021/04/11(日) 12:27:09.74

マイナーバージョンが上がるのでも結構変わると言うことか

**デフォルトの名無しさん** · 2021/04/11(日) 13:05:02.83

バージョン0のうちはね

**デフォルトの名無しさん** · 2021/04/11(日) 13:15:29.70

誰かも言ってたけどこう言うのは標準ライブラリで整備してほしい所だあな

**デフォルトの名無しさん** · 2021/04/11(日) 13:43:12.49

乱数は用途によってアルゴリズム使い分けにゃならんからなぁ
Cのrandはまぁ使えないとしてC++のrandomまで行くと重い

**デフォルトの名無しさん** · 2021/04/11(日) 14:40:26.89

randの設計が安定しない現状でstdに入れるにしても
かなり限定されたサブセットしか入れられないのでは

**デフォルトの名無しさん** · 2021/04/11(日) 17:41:37.63

それで十分だろ。
メルセンヌツイスターとか必要な場合は各々入れたら良い。
手軽な乱数を必要とする場面は割とある。

**デフォルトの名無しさん** · 2021/04/11(日) 21:41:09.50

メルセンヌ・ツイスタ、MT19937 を使っているのは、Ruby ぐらい

他の言語は、低品質

**デフォルトの名無しさん** · 2021/04/11(日) 22:30:00.44

一瞬信じかけたけど、pythonもboostもmtだったわ

**デフォルトの名無しさん** · 2021/04/11(日) 22:41:39.90

何でそんなとこで嘘つくん？

**デフォルトの名無しさん** · 2021/04/11(日) 23:24:19.82

>>85
直近でThreadRngやRngも破壊的変更されてて
乱数生成器の種類を充実させるとかそういうレベルにすら達してないのよ

**デフォルトの名無しさん** · 2021/04/12(月) 16:58:50.31

一部のプログラミング言語では、デフォルトの疑似乱数生成器としてメルセンヌ・ツイスタが
標準ライブラリに取り入れられている。そのような言語の例として、 Python,[2][3] Ruby,[4]
R,[5] PHP,[6] MATLAB, C++[7]（C++11から）がある。

**デフォルトの名無しさん** · 2021/04/12(月) 19:41:31.46

よそはよそ！うちはうち！

**デフォルトの名無しさん** · 2021/04/12(月) 21:18:15.82

線形合同が、あまりに低品質

**デフォルトの名無しさん** · 2021/04/12(月) 21:49:55.90

オライリー調査で明らかに--Go、Rust、Ruby、Dartに関心高まる - ZDNet Japan

https://japan.zdnet.com/article/35169143/

**デフォルトの名無しさん** · 2021/04/12(月) 22:02:51.56

fn main() {
let n = 100;

println!("{}", type_of(n));
}

これを実行すると
E0425: cannot find function `type_of` in this scope not found in this scope
になるのですがtype_ofは使えないのでしょうか？

rustc -V
1.51.0です

**デフォルトの名無しさん** · 2021/04/12(月) 22:08:31.70

すいません
とほほのRust入門見て解決しました
type_ofを関数として定義しないとダメなんですね

https://docs.rs/typed/1.0.0/typed/fn.type_of.html
にページがあったので組み込み関数があるものだと思いこんでたら
そういうものは存在しなくて,type_ofの関数を定義しないとダメだったようです

kindleで入門書を購入したのですがそこが省略されておりはまりました
失礼しました

**デフォルトの名無しさん** · 2021/04/12(月) 22:40:04.94

乱数ってxorshiftとかxoroshiroもあるわけで
まぁアルゴリズム固定は難しいでしょう

**デフォルトの名無しさん** · 2021/04/12(月) 23:08:15.49

no_std環境も考えるともし一つ選ぶならMTよりxorshiftかなぁ。Rustの方針に合わないから入ることはないだろうけど。

**デフォルトの名無しさん** · 2021/04/13(火) 00:51:04.66

APIをどうするかどこまでリッチにするかとかも難しいんだろ

**デフォルトの名無しさん** · 2021/04/13(火) 01:57:46.80

xoroshiro1024がないんだよね。

>>95
```shell
rustup doc --std
```

**デフォルトの名無しさん** · 2021/04/15(木) 21:01:10.98

パニックお断り―Linus，"Rust for Linux"の盛り上がりに釘を刺す
https://gihyo.jp/admin/clip/01/linux_dt/202104/15

**デフォルトの名無しさん** · 2021/04/15(木) 21:13:33.74

JavaScript／TypeScriptランタイム環境「Deno 1.9」がリリース、パフォーマンス向上に寄与する機能追加など
https://codezine.jp/article/detail/13970

**デフォルトの名無しさん** · 2021/04/16(金) 04:30:01.56

>>100
メモリの確保に失敗したくらいでpanicはしないが
alloc::alloc::Allocatorの一部メソッドはpanicするから
no_core上にpanicしないアロケータ実装すればよさそう。

コンパイル遅いのはキャッシュするしかない。

**デフォルトの名無しさん** · 2021/04/16(金) 09:28:25.44

結局kernelやるならunsafeつけまくりにしかならんだろ。
そうするとなぜrustで？という事になる。

**デフォルトの名無しさん** · 2021/04/16(金) 09:50:50.04

>>102
その「panicしないアロケータ」を使った Vec やらなんやら全部実装しなおさないといけなくならない？

**デフォルトの名無しさん** · 2021/04/16(金) 18:31:00.46

>>104
といっても変えるのはnewとかくらいで大半の実装はそのままもってくればいいんじゃない？
まあパッチ投げてる人もそこは作業量多いとは言ってるけど。

**デフォルトの名無しさん** · 2021/04/16(金) 18:54:38.72

>>104
Vec等のコンテナにはtry_reserveとかのメモリ割り当て失敗でエラーにする関数用意されているから
メモリ割り当ての失敗だけが問題ならliballocの使い方を変えるだけでよいのでは
他にpanic要因あるならだめだけど
ちなみにnewはメモリ割り当てしないから変更不要

**デフォルトの名無しさん** · 2021/04/16(金) 21:12:31.63

ある種の「コンテキストに対するunsafe」をつけて回らなきゃ無理。
でもってそれはmoonshotだって言ってるわな。
https://lkml.org/lkml/2021/4/14/1140

**デフォルトの名無しさん** · 2021/04/16(金) 21:47:54.90

特定の関数が割り込みのコンテキストから呼び出されたときにコンパイルエラーにすることは
今の言語機能では不可能という話か

**デフォルトの名無しさん** · 2021/04/16(金) 23:21:39.03

>>107
role orientedな言語でコンパイラが特別扱いする
コンテキストを指定できれば実現できる、
ここまで考えてだからmoonshotなのかと。

**デフォルトの名無しさん** · 2021/04/16(金) 23:46:26.48

Cでも出来てないことを要求してどうすんの

**デフォルトの名無しさん** · 2021/04/17(土) 00:54:40.80

知らんがな。どうしてもrustでkernel作りたいってやつに言えや。

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/17(土) 02:30:05.79

Linux のカーネルはカーネルとは言ってもかなり巨大なので
現状の Rust でも採用可能な箇所もあるんでないの。
知らんけど。

**デフォルトの名無しさん** · 2021/04/17(土) 08:49:33.19

>>112
だからその考えでドライバーならということで始めたら上記の問題が出てきたってところだよ。
何周遅れてんだよ。

**デフォルトの名無しさん** · 2021/04/17(土) 09:05:35.37

グーグル、Linuxカーネル開発における「Rust」採用の動きをサポートする考え
https://japan.zdnet.com/article/35169455/

利用が進めば問題点も見えてくるし何らかの対策は追加されるだろうな

**デフォルトの名無しさん** · 2021/04/17(土) 09:33:32.53

linusすごいな
Rust関わってる人全員子供扱いかよ