Rust part12

**デフォルトの名無しさん** · 2021/08/24(火) 22:55:27.78

公式
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のasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

前スレ
Rust part11
https://mevius.5ch.net/test/read.cgi/tech/1623857052/

**デフォルトの名無しさん** · 2021/09/22(水) 12:31:35.55

競プロの人ってレギュレーション守れば何してもいいって考え方の人が多いよね。
規約次第ってのが正にそれ。

unsafe みたいに取り扱いが繊細な機能は基本使わない、使う時には議論した上で限定的に使うみたいな感じに取り扱うのがほとんどだろ。
規約で機械的には決められないと思うよ。

**デフォルトの名無しさん** · 2021/09/22(水) 13:23:06.09

競プロでunsafeなんて使わないよ
グローバル変数おじさんなら知らんけど

**デフォルトの名無しさん** · 2021/09/22(水) 13:53:44.01

久々にusize祭りｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

unsafe fn calc(bit: i32) -> i32 {
　if bit == 0 { return 0; };
　if DP[bit as usize] != -1 { return DP[bit as usize]; };

　let mut start_id: i32 = 0;
　for i in 1..=K_NUM { if bit & 1 << i == 0 { start_id += C_NUM[i]; }; }

　let mut res: i32 = i32::MAX;
　for i in 1..=K_NUM as i32 {
　　if bit & 1 << i > 0 {
　　　let mut end_id: i32 = start_id + C_NUM[i as usize];
　　　let mut num: i32 = end_id - start_id - (SUM[end_id as usize][i as usize] - SUM[start_id as usize][i as usize]);
　　　res = res.min(calc(bit ^ 1 << i) + num);
　　}
　}
　DP[bit as usize] = res;
　res
}

**デフォルトの名無しさん** · 2021/09/22(水) 13:54:58.06

なんで来るんだよおじさんー

**デフォルトの名無しさん** · 2021/09/22(水) 13:57:46.22

Rust競プロでグローバル変数（static mut）はマジでおすすめしないぞ、ほんまに
意味わからんWAの原因になりうる

https://qiita.com/qnighy/items/46dbf8d2aff7c2531f4e

**デフォルトの名無しさん** · 2021/09/22(水) 15:00:43.19

そんなに生配列使いたいならCで書けよ

**デフォルトの名無しさん** · 2021/09/22(水) 19:10:57.50

結局規約頼りならrust使う意味は薄いわな。

**デフォルトの名無しさん** · 2021/09/22(水) 20:53:41.87

>>509
それはRustだけでなくcやc++でも起こることなので、注意すれば大丈夫ヽ(´ー｀)ノ
Rustだから駄目、c++ならokという根拠にはならないから

**デフォルトの名無しさん** · 2021/09/22(水) 23:41:24.94

>>511
1%でもダメな箇所があったら全部ダメって考える人？

**デフォルトの名無しさん** · 2021/09/22(水) 23:53:53.16

理想的な言語には無駄など一切無いのだ

**デフォルトの名無しさん** · 2021/09/23(木) 00:15:25.31

規約になんもないからってunsafeまみれだとぶっ叩かれるぞ
そう、actix-webの作者のように

**デフォルトの名無しさん** · 2021/09/23(木) 00:24:58.81

>>507 添削しました。お収めくださいまし。

1. 安易にグローバル変数を使うな。状態を引数で持つくらいやれ
2. 引数bitが負になるのかくらい考えろ。脳死でi32とusizeをコピペしてるだろテメー
　暗黙のキャストが無い==明示的にキャストすればいい、じゃねえぞ
　パッと見て汚いなら設計が汚えんだ。動的プログラミングだから汚えんじゃねえ、テメーが汚えんだ
　…負数になる可能性がある場所はたったの1行じゃねえか！どうした？頭使ってる？
4. unsafe外す努力もしねえのか、どうした？5回deleteキー押せば外れるぞ？
5. 値とインデックスが混ざるような書き方、どうして怖がらない？ロボトミー手術でも受けたのか？
6. C/C++には無い機能も使わず、warningもlinterも無視して、一体どうしてrustで書いてるんだ？
　勉強中とすら言えねえじゃねえか。
　まさか、VBAスクリプトを.javaファイルにコピペして「動きません！javaはクソ！」とか言っちゃう伝説のコーダーなのか？

**デフォルトの名無しさん** · 2021/09/23(木) 01:13:45.47

質問です
デフォルト値を与えるトレイトDefaultについて例えば
#[derive(Default)]
struct S { a: i32, b: i32, c: i32 } の時に
let s = S::default(); と書いても同じ結果で短いのに
let s: S = Default::default(); と書くのはDefaultトレイトのdefault()だと明示するためでしょうか？
結局deriveすると
impl Default for S {
　fn default() -> Self {
　　S { a: 0, b: 0, c: 0 }
　}
} を自動的に定義してくれるという理解であっていますか？
驚いたのは
let s = S { b: 123, ..Default:default() };
とすると残りフィールドをデフォルト値展開してくれて S { a: 0, b: 123, c: 0 } が得られることでした
そこでderiveを使わずに自分で
impl Default for S {
　fn default() -> Self {
　　S { ..Default::default() }
　}
}
と手動かつ内部をDefault::default()に任せてみたところ
再帰しているとコンパイルで警告が出て実行するとコアダンプでしたw
なぜ？

**デフォルトの名無しさん** · 2021/09/23(木) 01:38:10.01

>>517
Default::defaultはどこでも使えるから癖で使ってる人が多いんだと思う

S { b:123, ..Default::default() }は残りのフィールドを展開するというより、
S::default()の所有権を奪ってbだけ書き換えたものを返すという理解が正しい
, ..に続くのは構築しようとしているものと同じ型の値
例えばS { a: 123, ..s }のようにも書ける
, ..Default::default()と書けばSが期待される箇所なので, ..S::default()と同様になる

以上を踏まえれば最後のコアダンプの原因はS::defaultの無限再帰によるstack overflowだと容易に理解いただけよう

**デフォルトの名無しさん** · 2021/09/23(木) 02:02:07.87

>>518
なるほど！よく考えれば
let base = S { a: 0, b: 0, c: 0 };
let s = S { b: 123, ..base }; の時と同じstruct base式の構文だったのですね
結局、以下のように自分で展開したところ(当たり前ですが)上手く行きました
impl Default for S {
　fn default() -> Self {
　　Self {
　　　a: Default::default(),
　　　b: Default::default(),
　　　c: Default::default(),
　　}
　}
}

**デフォルトの名無しさん** · 2021/09/23(木) 07:42:33.86

Defaultトレイトのdefaultと明示するため、で合ってるよ
Arc::cloneにもそのような文化がある

**デフォルトの名無しさん** · 2021/09/23(木) 11:37:02.58

>>513
1%のダメな箇所で他の言語の文句言ってるのはrust信者の方ですけどね。

**デフォルトの名無しさん** · 2021/09/23(木) 13:01:19.66

まあ、100%良いものなんてないんだし、子供達がせっかく作ったものを評価し、使ってやるというのも、年長者の優しさってものだろう。

今までどれだけ色々な言語が作られ、流行る、主流になると言われては下火になっていったことかと思えば、Rustもまたいずれ他のものにとってかわられるのが世の流れではあるだろうが、それならそれで良いじゃないか。

諸行無常

**デフォルトの名無しさん** · 2021/09/23(木) 13:12:55.93

>>522
Rustを置き換えるにはコンパイル時点でのメモリ安全性保証を実現しないといけない
Rustは諸問題を解決してしまったので代わりの言語は数十年出てきそうにない
もし出てきたときには手続き型ではなくなってるだろう

**デフォルトの名無しさん** · 2021/09/23(木) 15:20:08.54

みずほのシステムを全部Rustで

**デフォルトの名無しさん** · 2021/09/23(木) 15:55:02.56

>>524
ボンクラPGは排除できるから意外と良い選択かもw

**デフォルトの名無しさん** · 2021/09/23(木) 16:44:35.84

みずほはもっとマクロなレベルでの設計の問題じゃないの知らんけど

**デフォルトの名無しさん** · 2021/09/23(木) 17:01:36.77

つかCOBOLならもともとメモリ安全性は高いだろ

**デフォルトの名無しさん** · 2021/09/23(木) 17:14:42.14

昔の 1% は (注意を払うという対処法で) なんとかなったが現代のコード規模の 1% は深刻だという話なんだよ。

**デフォルトの名無しさん** · 2021/09/23(木) 17:44:30.23

静的チェックでその１％が埋まると思ってるのがお気楽だなと思うわ。

**デフォルトの名無しさん** · 2021/09/23(木) 18:01:26.98

usize祭りｺﾈ━━━━(ﾟдﾟ；)━━━━!!

let mut dp = vec![i32::MAX; n_list.len() + 1];
for &i in &n_list {
　for j in 0..dp.len() {
　　if dp[j] > i {
　　　dp[j] = i;
　　　break;
　　}
　}
}
let mut cnt = n - dp.iter().filter(|&x| x != &i32::MAX).count();

**デフォルトの名無しさん** · 2021/09/23(木) 18:27:08.03

vscodeでセーブした時に、ifに付けちゃった括弧を外して欲しいんだけど、何をどう設定すればいいの？

**デフォルトの名無しさん** · 2021/09/23(木) 18:28:49.30

処理系の勉強をかねてRustで
ttps://www.sigbus.info/compilerbook
これをやってみようと思う
序盤で二分木＆再帰・・・うへー

**ハノン** ◆QZaw55cn4c · 2021/09/23(木) 18:32:58.93

>>532
二分木はむしろ非再帰で組めといわれたら罰ゲームなんですよ‥‥

**デフォルトの名無しさん** · 2021/09/23(木) 19:12:11.01

なんかこのスレ競プロの厄介な人に乗っ取られた？
クソコードを延々と貼り付けてるあたり開き直ったか

**デフォルトの名無しさん** · 2021/09/23(木) 19:15:36.83

競プロは別スレ建てて分離しましょう
競プロの件はいずれもRustを利用＆学習する人々にとって役に立たない有害なものばかりでこのスレと別件ですから

**デフォルトの名無しさん** · 2021/09/23(木) 19:22:24.57

競技プログラミング総合スレ 63
https://mevius.5ch.net/test/read.cgi/tech/1627477128/

**デフォルトの名無しさん** · 2021/09/23(木) 19:48:26.70

>>535
いやRustで競プロをする人もいるじゃんね
Rustを使用している人は、仕事だけの人、競プロだけの人、仕事でも競プロで使う人、のそれぞれの合計

ということは、そこから競プロを排除するってことは、より少ない人数だけを対象にするスレを立てるってことだから、
競プロの話題を禁止したい人が、「Rust原理主義者スレ」とでもして、自分たちが別スレをたてて
原理主義者たちだけで移動するのが論理的かつ合理的ヽ(´ー｀)ノ

**デフォルトの名無しさん** · 2021/09/23(木) 20:01:59.63

とキチガイが申しております

**デフォルトの名無しさん** · 2021/09/23(木) 20:06:06.82

>>537
あなたはまず何の説明も無しにコード貼り散らかして祭りだとか言うことの目的を教えなさいよ

**デフォルトの名無しさん** · 2021/09/23(木) 20:19:26.28

ブログトップにキモい自撮り写真貼ってるやつを見てから
競プロ臭のくっさいコードはスルーすることに決めてる

**デフォルトの名無しさん** · 2021/09/23(木) 20:34:50.85

>>538-540
スレッドは知識の集合知である場所だと思うから、
B木を考えても、情報が細分化される場合には、
携わる人数（情報）が少ないほうを葉にするのが妥当だと思うけど

>>539
Rustにはメリットもあるし、デメリットもある
様々な側面から、こういうことがあり得るとか、こういうこともできるとか
そういう情報がプラスになるんじゃないかと思っている

仕事のみの人にとっては競プロの書き方は我流だと思うだろうし、
競プロでも書いている人は、別に仕事で競プロの書き方はしてないが
直感的にやりたいことができないこともあるという思いもある

そのあたりの折り合いを付けるのが正しいRustスレなんだと思うんだよね。個人的に。
だから競プロ以外の話をしたいなら、原理主義スレを立てればいいし、
競プロだけの話をしたいなら、競プロスレを立てればいい。

ただし、ここはRustのrootだと解釈している

**デフォルトの名無しさん** · 2021/09/23(木) 21:50:54.44

ってことで以降は競プロ禁止
やりたい人は競プロのスレで

**デフォルトの名無しさん** · 2021/09/23(木) 22:02:49.74

>>542
そういう強権的なやり方は嫌われると思う

**デフォルトの名無しさん** · 2021/09/23(木) 22:22:06.57

俺はお前が嫌い

**デフォルトの名無しさん** · 2021/09/23(木) 22:56:16.76

>>541
要はフィードバックが欲しくてソース貼ってるのか？
ならせめて入力仕様と出力仕様くらいは書こうな
競プロなら問題へのリンクでもいい

**デフォルトの名無しさん** · 2021/09/23(木) 23:17:56.15

codeLLDBを消去しやがるからavastアンインストールしてやったわ

**デフォルトの名無しさん** · 2021/09/24(金) 00:59:53.09

>>541 添削しました。お納めください。

1. Cをそのままコピペしただけじゃねえか
　 Rustの機能を試すだぁ？enumもtraitもパターンマッチも使えないのに何が検証だ馬鹿野郎
　「Cコピペしたけどメリット無いね！」って後何回繰り返すんだ？
2. なんだこの察してちゃんなコードは。保育園にいるつもりか？
　意図の明確なコードが1行も無いんだが？
3. お前がここにゴミを貼る妥当性が一つも無い
　 Rustの世界に持ってきた概念のどれも使わないで、何が検証できると思ってるんだ？
　例えるなら「ひらがなしか知らない外国人が日本語の良し悪しを検証します！」っていうもんだぞ
　誰がマトモに付き合うんだ？

**デフォルトの名無しさん** · 2021/09/24(金) 01:50:08.20

>>529
CやC++だと非安全コードはどこにでも現れる可能性があるので100%のコードを人力で確認する必要があったが
rustでは安全性に関してはunsafeな部分のみ(例えば全体の1%)を確認すれば良いという話では
静的チェックで100%なんとかしようという話はしていないと思うが

**デフォルトの名無しさん** · 2021/09/24(金) 02:35:54.11

そうだなーと思う反面unsafeだらけのコードを目の前にしてげんなりする未来も見えるという…

**デフォルトの名無しさん** · 2021/09/24(金) 04:43:03.82

ほとんどの用途でunsafeを直接使うことは無いんじゃない？
グローバル変数はOnceCellで解決してしまったし
もし生ポ操作するとしたら新たな型を作ってその中に閉じ込める

**デフォルトの名無しさん** · 2021/09/24(金) 08:02:15.31

そういうコードが書ける事が問題だとあれほど批判してたのに

**デフォルトの名無しさん** · 2021/09/24(金) 08:30:26.85

>>551
それは何も問題ではないよ
例えばVec型もpushやpopですら内部はunsafe利用だけど我々はそれを知らず気にせず安全に使うことができる

**デフォルトの名無しさん** · 2021/09/24(金) 10:22:26.34

>>551
どのレスに対するコメント？

**デフォルトの名無しさん** · 2021/09/24(金) 13:18:46.57

そもそも競プロにメモリ安全性とかいらないしC++で書いといてくださいよ

**デフォルトの名無しさん** · 2021/09/24(金) 14:03:53.31

Rustの良いところはメモリ安全だけではなかろう？

**デフォルトの名無しさん** · 2021/09/24(金) 19:03:51.27

機能性で言えば競プロに必要なものは大抵の言語が備えてるだろうし
使いやすさで言えばRustはきっちり書くことを求められてるから素早く書くのには向いてないし
それでも敢えてRustを選ぶ理由は趣味や慣れくらいなのでは

**デフォルトの名無しさん** · 2021/09/24(金) 21:51:28.01

releaseビルドするとTrojan:Script/Wacatac.B!mlを検出して
Windows Defenderに怒られる
--release付けないと大丈夫
誤検知かな？

**デフォルトの名無しさん** · 2021/09/24(金) 22:12:48.28

>>553
ごめん
例えばUnsafeCellの存在はRustの借用ルールに制約されることなく自由に新たな型を設計して作る道を開いているけど
あくまでも安全な型を作るための素材であって具体的にはRefCellやOnceCellなどの様々な安全な型を提供する素材となっているように
unsafeの存在も上位レベルで安全な関数やモジュールを提供するための素材としてのみ用いるべきではないか
ということを伝えたかったのです

**デフォルトの名無しさん** · 2021/09/24(金) 23:54:29.51

つまり競プロ君のunsafeの使い方はただ危ない逸脱のみであり、
安全かつ便利な何かを提供する目的のための使い方ではなく、
Rustの精神に反している、と。
したがって競プロの話は、
このRust本スレでやるべきことではなく、
ここでは禁じて別スレでやるべき、と。

**デフォルトの名無しさん** · 2021/09/25(土) 00:09:12.18

>>559
競プロくんを競プロの代表扱いするのはさすがに競プロの人に失礼では

**デフォルトの名無しさん** · 2021/09/25(土) 01:22:46.71

Rustの精神とかそんな大層な話でもないでしょ
建設的に話せない奴に付き合う必要はないというだけ

**デフォルトの名無しさん** · 2021/09/25(土) 03:09:21.77

>>558
違う人が書いた事を、さも自分が書いたように返答するのはどうかと思う

**デフォルトの名無しさん** · 2021/09/25(土) 08:30:11.81

>>562
え？？
>>558は自分の意見を書いただけでこのスレにしか書いていないし参考にしたサイトや書き込みもないよ
もし偶然にそっくりな内容なものがどこか他にあるなら見てみたいので教えて

**デフォルトの名無しさん** · 2021/09/25(土) 22:50:40.30

>>559
こういう自分の意見にあわないと何でも排除したいヤツはどこにでもいるんだよなあ

**デフォルトの名無しさん** · 2021/09/26(日) 00:09:45.69

Range関連での質問です

(Included(&x), Included(&y)) はx..=yと書けますが、
(Excluded(&x), Included(&y)) を似たように書く方法ってありますか？

**デフォルトの名無しさん** · 2021/09/26(日) 01:40:54.44

>>565
ないんじゃない？

(3..=5).skip(1)で、妥協するかなぁ

**デフォルトの名無しさん** · 2021/09/26(日) 01:56:26.69

Range はよく使うから構文糖を入れてちょっと簡単にするという判断がうまれたんだと思うんで、
それほど頻出しないパターンは明示的に書くしかしょうがないと思う。
自分のプログラムでよく使うのであればそういう関数を用意しておけというくらいの妥協になる。

**デフォルトの名無しさん** · 2021/09/26(日) 03:07:15.60

>>565
range式も魔法があるわけではなく
それぞれ対応する構造体があって各traitなどを実装してるだけなのですが
stdにあるのは以下の6種類のみですね
assert_eq!(.., std::ops::RangeFull);
assert_eq!(3.., std::ops::RangeFrom { start: 3 });
assert_eq!(..7, std::ops::RangeTo { end: 7 });
assert_eq!(..=7, std::ops::RangeToInclusive { end: 7 });
assert_eq!(3..7, std::ops::Range { start: 3, end: 7 });
assert_eq!(3..=7, std::ops::RangeInclusive::new(3, 7));
例えば開始点のあるRangeFrom・Range・RangeInclusiveはIteratorも実装

一方でその(Excluded(&x), Included(&y))形式すなわち
(Bound<T>, Bound<T>)および(Bound<&'a T>, Bound<&'a T>)型だと
実装されているのはRangeBoundsトレイトのみでIteratorトレイトなどは無いという違いがあるようです
開始がUnboundedだと意味がないからでしょう
つまりイテレータで回したい時にはこの形式では使えないので
(Excluded(x), Included(y)) は (x+1)..=y と書くしかないと思います
もちろんSkip構造体のコストを払って(x..=y).skip(1)もアリです

**デフォルトの名無しさん** · 2021/09/26(日) 03:55:02.75

>>566 >>568
すみません、言葉足らずでした
BTreeMap/Setのrangeメソッドに渡す引数を意図していました
こちらに渡すのはイテレータではないのでskip(1)はできないようです

>>567 >>568
あまり頻出ではないですし仕方ないですかね
実際困るわけではないのですが、
アンバランスなので気になってしまいました

**デフォルトの名無しさん** · 2021/09/29(水) 09:06:12.26

無職の人工衛星おじさん来て

**デフォルトの名無しさん** · 2021/09/30(木) 11:51:35.89

ttps://lkml.org/lkml/2021/7/7/349
完全にストップしたな。最低だよ。

**デフォルトの名無しさん** · 2021/09/30(木) 12:33:08.03

>>571
どういう意味や？

**デフォルトの名無しさん** · 2021/10/01(金) 12:54:11.60

>>573
どういう意味や？

**デフォルトの名無しさん** · 2021/10/01(金) 13:00:05.87

自問自答かいな

**デフォルトの名無しさん** · 2021/10/01(金) 14:16:55.18

Rust for Linuxに関しては結局それ以降進展無しということ？

**デフォルトの名無しさん** · 2021/10/01(金) 14:33:36.85

そりゃ普段の作業はGitHub上でやって、まとまったところでパッチ投げるんだから
LKMLで日々の進捗報告なんかしたら迷惑でしかない

**デフォルトの名無しさん** · 2021/10/01(金) 14:40:28.89

https://github.com/Rust-for-Linux/linux
ここかな？全然活発だったわ

**デフォルトの名無しさん** · 2021/10/01(金) 15:23:00.24

いや実際のドライバーが動かないのにごねてるだけやん。。話になってないんだが。

**デフォルトの名無しさん** · 2021/10/01(金) 23:00:07.65

as usize祭りの回避ができてきてる━━━━(ﾟ∀ﾟ)━━━━!!

let mut heap: BinaryHeap<Reverse<(usize, usize)>> = BinaryHeap::new();
heap.push(Reverse((0, 0)));

while let Some(Reverse((_, now))) = heap.pop() {
　let mut que: VecDeque<(usize, usize)> = VecDeque::new();
　que.push_back((now, 0));
　while let Some((next, cnt)) = que.pop_front() {
　　if cnt == price[now].1 { break; };
　　for &i in &list[next] {
　　　if total[i] > total[now] + price[now].0 {
　　　　total[i] = total[now] + price[now].0;
　　　　heap.push(Reverse((total[i], i)));
　　　}
　　　que.push_back((i, cnt + 1));
　　}
　}
}

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

>>578
そうなんだ。誰がどこでごねてるの？

**デフォルトの名無しさん** · 2021/10/02(土) 07:25:57.30

VSCodeか何かで、編集中のファイルを（保存する度ではなく）リアルタイムで構文チェックしてもらうことってできないの？
目が悪いもので、C#みたいに間違えたら即指摘みたいなのがすごく助かるんだけど・・・・

**デフォルトの名無しさん** · 2021/10/02(土) 08:17:40.16

rust-analyzer入れれば若干のラグはあるけどそんな感じでやってくれると思うが

**デフォルトの名無しさん** · 2021/10/02(土) 08:21:40.61

すまんオートセーブもつこうてたわｗ

**デフォルトの名無しさん** · 2021/10/02(土) 09:01:16.43

>>581
IntelliJRustにon the fly analysisあるぞ

**デフォルトの名無しさん** · 2021/10/02(土) 15:27:53.04

普通にVscodeでRustの拡張入れたらやってくれん？
俺が思てる構文チェックとかの支援とは違うんかな

**デフォルトの名無しさん** · 2021/10/02(土) 15:48:21.44

vscode+rust-analyzerでオートセーブ無効でもリアルタイム構文チェックしてくれるよ

**デフォルトの名無しさん** · 2021/10/02(土) 17:14:40.18

いつrust-analyzerに移行するか悩み中。

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

>>586
Auto Saveオフだと、指摘してくれないやつ結構ない？
セーブして初めて指摘されるやつが結構あるような

**デフォルトの名無しさん** · 2021/10/02(土) 17:45:45.06

rust-analyzerってvimでも使える？
流石にvim捨てるべきかなあ

**デフォルトの名無しさん** · 2021/10/02(土) 18:12:12.35

vimでもneovimでも使えるよ

**デフォルトの名無しさん** · 2021/10/02(土) 21:14:54.36

rls から rust-analyzer の移行なんて躊躇するもんじゃないぞ。
試して合わなければすぐに戻せばいいだけだし、戻りたいと思う可能性は俺はゼロだと思う。

**デフォルトの名無しさん** · 2021/10/02(土) 21:57:31.81

>>588
構文チェックとrust-analyzerの検知できる型エラーは保存しなくても指摘されるはず(前者は即時、後者は少しラグがある)
rustcじゃないと検出できないものは確かに保存時しか出ないかもね
特に害あるものじゃないしauto save有効にしても良いのでは？

**デフォルトの名無しさん** · 2021/10/02(土) 23:35:42.15

>>589
実際にビルドしてみてそのエラーメッセージをエディタに反映するという仕組み (いわゆる flycheck) は昔からあったんだが、
頻繁に実際にビルドするんじゃなくて処理系の構文解析プロセスとエディタを連携させればもっと効率的なんと違うか？という
のがマイクロソフトによって LSP (Language Server Protocol) として標準化されたという経緯がある。

エディタにとっては場当たり的なエラーメッセージの解析をせずによくなったので昔より楽になってるんだよ。
昔から flycheck をやってるようなエディタはだいたい LSP にも対応してる。

**デフォルトの名無しさん** · 2021/10/04(月) 23:18:59.60

https://thenewstack.io/linus-torvalds-on-community-rust-and-linuxs-longevity/
> “Probably next year, we’ll start seeing some first intrepid modules being written in Rust, and maybe being integrated in the mainline kernel.”

**デフォルトの名無しさん** · 2021/10/05(火) 01:50:58.24

統合早いな。多言語プロジェクトでcargo面倒くさい問題はなんかやってんだろうか？
統合されたらソース読んでみよ。

**デフォルトの名無しさん** · 2021/10/05(火) 03:19:27.62

言語を組み合わせる場合を含めてビルドプロセスの記述はなんだかんだで make が万能なんだよな。
クソみたいに場当たり的だけど必要だから機能を追加してきたという現実の前には
どんな美しいパラダイムも砂上の楼閣という印象だわ。

**デフォルトの名無しさん** · 2021/10/05(火) 11:23:44.05

cargoが勝手にクレートダウンロードしてくれるのは便利だけどね
セキュリティ的には……どうなんかなー

**デフォルトの名無しさん** · 2021/10/05(火) 11:55:21.23

ビルドはmakeからrustc呼ぶ形になってたはず
カーネルに関してはクレートのダウンロードなんかもしないならそれで問題ない

**デフォルトの名無しさん** · 2021/10/05(火) 12:47:41.98

余計なことするツールに限ってモジュラリティ低い

**デフォルトの名無しさん** · 2021/10/05(火) 12:55:43.82

>>596
既存のものがクソだから俺が全く新しいクールな奴を作ってやるぜ！っていって新しいクソが1つ増えるのはもはや伝統芸やね

**デフォルトの名無しさん** · 2021/10/05(火) 15:46:57.33

>>597
そのための --offline オプション

**デフォルトの名無しさん** · 2021/10/05(火) 18:59:42.65

>>600
makeの機能を持つprologは欲しいなぁ。

論理プログラミング言語を拡張したmakeとか堅牢そうな気がするけど、誰もやらないのかしらん。

**デフォルトの名無しさん** · 2021/10/05(火) 20:24:54.05

>>602
prolog難しいから流行らない

**デフォルトの名無しさん** · 2021/10/05(火) 21:06:12.38

宣言的なものの依存がゴタゴタしたもののデバッグのしずらさを知らんのだろう。呑気なもんだ。