Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

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

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/05/24(土) 12:00:21.23

ていうか、mutを制限しない限り、末尾\0は別の値に変更できるから末尾\0は保証されない

**デフォルトの名無しさん** · 2025/05/24(土) 12:06:04.95

>>805
コンパイルが通れば安全というのはRust-bookの翻訳の間違いな。原文読まないと
手を動かさないと理解できないだろうが、Rustにはテストフレームワークが組み込まれてるし、さらに外部のクレートを使うことが推奨される

cargo-nextest
cargo-insta
あたりね

ライブラリークレートをコーディングするときに並行してテストコードも書いて、バウンダリーズとかに問題がないことを確認した上でcrates.ioやgithubに公開しないと恥かくよ。上のヌル文字終端とかもCから来た人なら絶対テストに入れるべきよ

恥を気にしない人なら好きにしてくれ！

**デフォルトの名無しさん** · 2025/05/24(土) 12:24:06.94

>>805
Rustではコンパイラが通れば必ず安全が保証されるよ

**デフォルトの名無しさん** · 2025/05/24(土) 12:24:29.19

>>805
MSエディタはインデックス範囲外をpanicするAPIを使っていて安全に落ちていて他の言語と同じ

**デフォルトの名無しさん** · 2025/05/24(土) 12:26:01.00

>>805
Safe Rustに限定すればRust自身にバグがない限りは安全
今回のはpanicするだけなので安全の範疇だよ
「安全 == ロジックバグがないこと」だと思ってるならそれは間違い

**デフォルトの名無しさん** · 2025/05/24(土) 12:30:11.61

panicがイヤならpanicしないAPIを使えば解決するね
panicするAPIを使っておいてpanic違反するのはマゾみたいなもの

**デフォルトの名無しさん** · 2025/05/24(土) 12:45:05.58

>>803
Cの場合は空文字列でも\0があるから最初に
if (str[0] == '\t)
をぶつけても問題にならないよ
このフローをそのままRustに持ち込んだ感じ
もとのコード見れないから断言はできんが

**デフォルトの名無しさん** · 2025/05/24(土) 12:45:10.09

とっくに化けの皮は剥がれてるのに、こんな新規参入のない掲示板で耳障りのいいことばっかり書いて何になると思ってるんだろうか

**デフォルトの名無しさん** · 2025/05/24(土) 13:50:39.66

コード見たけどRustならスライスとそのメソッド使うところ
なぜかインデックスアクセス多いな
該当部の直後も
while remove < self.tab_size as usize
　&& offset + remove < replacement.len()
　&& replacement[offset + remove] == b' '
{
　remove += 1;
}

**デフォルトの名無しさん** · 2025/05/24(土) 14:01:45.35

最初に機能の弱い他の言語で書くからそうなる
最初から抽象的に書けるRustを使うべき

**デフォルトの名無しさん** · 2025/05/24(土) 14:17:39.59

えー、このクソ言語で？

**デフォルトの名無しさん** · 2025/05/24(土) 14:34:27.01

crates.ioの恥は描き捨て

**デフォルトの名無しさん** · 2025/05/24(土) 14:47:03.56

続けるだけでは意味がない。研究が示した「成長できない人の条件」
公開日2025.05.24 13:00:14 SATURDAY
http://nazology.kusuguru.co.jp/archives/177845

**デフォルトの名無しさん** · 2025/05/24(土) 15:05:18.87

古く機能が弱いプログラミング言語にこだわってる人は成長できない

**デフォルトの名無しさん** · 2025/05/24(土) 15:11:27.10

キラキラは個人の成長じゃなくて人類の進化なのに

**デフォルトの名無しさん** · 2025/05/24(土) 15:17:37.34

>>812
仮にCバージョンでTextBufferをnull終端した状態で管理していたとしてもreplacementはその一部分を指し示すものなのでnull終端したりはしないぞ

**デフォルトの名無しさん** · 2025/05/24(土) 15:21:29.32

null終端は部分文字列が作れないからそういう時には使わないよな

**デフォルトの名無しさん** · 2025/05/24(土) 16:45:23.89

>>821
コード見てないだろ

https://github.com/microsoft/edit/blob/main/src/buffer/mod.rs
のunindent()が何やってるか追えば対象の一部分を作業用の一時bufferに読み込んでるの分かるはず
エディタは履歴管理も必要だからね

**デフォルトの名無しさん** · 2025/05/24(土) 17:16:21.68

>>792
まだ本番運用前だからね
TypeScriptとかJavaScriptのホットリロード(pm2)がプログラム修正時にすごくありがたいんよ
でもRustで性能上がるのはわかりきってるから悩ましい

本番環境で実行中のプロセスは実行終了まで旧バージョンで動作させて
新たな処理は新バージョン用の新プロセスで実行してくれるようなRust用のしくみ(pm2のRust版みたいなの)ないのかな

**デフォルトの名無しさん** · 2025/05/24(土) 17:46:57.96

Common Lisp は実行性能が良くて抽象度も高いしホットリロードの本家みたいなもんだ。
だけどまぁ Lisp 系ってだけで敬遠するのが世間の普通だし、慣れが不十分だと何でも使い難いよ。

慣れてるのがやりやすいというだけの本当に単純な話なんで、
Rust 初心者が今まで使ってた言語より使い難い！ってのは言語の比較になってない。

**デフォルトの名無しさん** · 2025/05/24(土) 17:57:30.53

>>823
だからその読み込み先の一時bufferをnull終端させたりしないんだって
それに一時buffer使ってるのは履歴管理のためじゃないぞ

**デフォルトの名無しさん** · 2025/05/24(土) 18:01:36.37

そういや、一昔前は新しい言語が話題になれば必ずLispと比べて腐すのが作法だったのに
近頃は見なくなったな

**デフォルトの名無しさん** · 2025/05/24(土) 18:12:36.04

Rust はカテゴリとしてはシステムプログラミング言語だ。
C++ などに慣れている人が Rust 入門する分にはそんなにハードルは高くないと思う。
むしろ C++ 使いこそ Rust を賞賛しているケースが目につく。
C++ は必要なものは揃っている現実的な言語だが後付けだらけでグダグダだし、メモリアクセス関連で未定義を踏むのはベテランでもやることだからな……。
それが解決するなら大歓迎だ。

ウェブ系 (JavaScript, TypeScript) からだと Rust は色々と分かり難い要素が多そうだが、
ウェブ界隈で Rust の存在感が出てきてしまったから使わざるを得ないこともあるだろうし、
仕方なく使ってれば文句も出るんだろうと思ってる。

**デフォルトの名無しさん** · 2025/05/24(土) 18:24:31.95

OOP時代に耳障りのいいことが色々言われたおかげで
演算子や関数名を左端に書く時代は終わった
けど演算子は継承やvirtualでうまく表現できなかったからOOP時代も終わった

**デフォルトの名無しさん** · 2025/05/24(土) 20:46:05.09

>演算子や関数名を左端に書く時代

なにこれ

**デフォルトの名無しさん** · 2025/05/24(土) 21:37:14.29

>>830
たぶん LISP のことを言ってる。

**デフォルトの名無しさん** · 2025/05/24(土) 21:53:46.20

>>824
そんなBFFみたいなのをRustで書くのはあまり一般的ではないでしょ
普通にNextとかにしてパフォーマンスクリティカルな部分だけRustで書いてRPCかFFIで呼べばいいのでは？
どうせ君はやってみたいだけ俺スゲーしたいだけなんだから、その方が合理的な判断でRustを採用してるっぽくなって自尊心高まるぞ

**デフォルトの名無しさん** · 2025/05/24(土) 22:24:13.67

>>727
unindent関数で各行をreplacement.drain(offset..offset + remove)しているけど
indexを使わずにイテレーターでやる場合、更に追加のバッファが必要になる感じで良いのかな？

**デフォルトの名無しさん** · 2025/05/24(土) 22:57:52.90

>>814
安全に速くするにはこう？
remote += replacement[(offset + remote)..]
　.iter()
　.take_while(|b| **b == b' ')
　.take(tab_size as usize - remote)
　.count();

**デフォルトの名無しさん** · 2025/05/24(土) 23:12:04.53

spaceとtabが混ざっているとインデントレベルが破綻するね
例えば tab_width==4 で
space tab の並びはインデント1つ分

**デフォルトの名無しさん** · 2025/05/24(土) 23:12:54.11

unindent後も
tab の並びでインデント1つ分

**デフォルトの名無しさん** · 2025/05/24(土) 23:23:16.50

それは混ぜた人の問題だから仕様でいいだろ

**デフォルトの名無しさん** · 2025/05/24(土) 23:35:00.85

>>832
両方の言語で書いてみたあとそれも考えたけど
性能差の根本がhttpサーバ部分の性能差だからそうはいかないんよね

**デフォルトの名無しさん** · 2025/05/24(土) 23:39:02.86

>>837
そだね
スター沢山ついたけど細かい面倒を買って出る人は少ないよね

>>834
ちなみにspace/tab混在も対応する場合、オリジナルのループなら簡単な変更で、意図が明確だと思うけど
イテレーターだとごちゃつくのでは

>>727,833
これもごちゃつくのでは

**デフォルトの名無しさん** · 2025/05/25(日) 01:10:56.69

>>838
さすがにそのレベルだと完全に無意味なオーバーエンジニアリングだから、もう好きにしたらいいのでは

**デフォルトの名無しさん** · 2025/05/25(日) 01:44:17.05

どうせ君はやってみたいだけ俺スゲーしたいだけなんだから

見ず知らずの相手にここまでひどい人格否定ワード言われる筋合いはないぞ。追放かなこいつ

**デフォルトの名無しさん** · 2025/05/25(日) 04:45:11.33

メモリ保護以外にもなんかねーのか
もう一歩欲しいよな
型アノテーションもつけてくれ

**デフォルトの名無しさん** · 2025/05/25(日) 10:06:04.62

Web APIでhttpサーバ部分がボトルネックになるってどんな状況なんだろ
大量のIO待ちリクエストが発生するような状況ならあるかもしれないが、そんなの>>824みたいなゆるいスタイルで作るかなあ

**デフォルトの名無しさん** · 2025/05/25(日) 10:20:43.43

>>843
その>>824の人の状況は知らないけど
httpサーバ部分がRustとJavaScriptでは裁けるクライアント数が全然違うよ

**デフォルトの名無しさん** · 2025/05/25(日) 10:57:10.37

>>844
ffi等による部分的なRust化で効果がないってことは、838のいうhttpサーバーというのはhttpサーバーのミドルウェア部分(アプリケーションコードを含まない)のみを指してるはずで、
それがネックだとすると、レスポンスタイムの殆どをIOが占めていて、かつ同時処理されるリクエスト数がサーバー台数に対して無茶苦茶多いという極端な状況が考えられる
そんな状況なら一般的なWebアプリだったらDBのコストの方が遥かに高くつくんじゃないかなあ

**デフォルトの名無しさん** · 2025/05/25(日) 11:02:49.46

なんでJSTS使いってGoやC#じゃなくてRustまで飛躍するんだ？使いこなせるのか？
システムプログラミング言語とWeb言語は完全に別物だから

**デフォルトの名無しさん** · 2025/05/25(日) 11:22:41.64

100倍努力すれば勉強時間は100分の1ですむという神話がある

**デフォルトの名無しさん** · 2025/05/25(日) 11:31:38.72

>>845
リアルタイムで取りに行く必要のあるDBは少なく多くは一定時間内のキャッシュで済む

**デフォルトの名無しさん** · 2025/05/25(日) 11:37:00.52

と言う説がある

**デフォルトの名無しさん** · 2025/05/25(日) 11:38:05.07

>>846
中途半端な立ち位置のGoやC#を使う意味は全くない
Rustでいい

**デフォルトの名無しさん** · 2025/05/25(日) 12:02:39.00

中途半端なものは成果にならなかったとしても教養にはなる
教養を軽視すれば論理が飛躍する

**デフォルトの名無しさん** · 2025/05/25(日) 12:06:42.87

rustでメジャーDB作ればよいんじゃね？

**デフォルトの名無しさん** · 2025/05/25(日) 12:20:37.56

>>686
Javaはあったっけ？

**デフォルトの名無しさん** · 2025/05/25(日) 12:22:11.20

Denoの影響で流行ってそう

**デフォルトの名無しさん** · 2025/05/25(日) 12:52:15.88

Denoの設計思想変更はあまり受け入れられておらずマイナーなままなんだよな

**デフォルトの名無しさん** · 2025/05/25(日) 13:44:42.15

すまんが、Rustに向いたデザインパターンのトレーニング方法を教えてくれんか？
Rustの言語仕様だけ勉強していてもメンテナンス性の悪い酷いコードしか書けないぜ

**デフォルトの名無しさん** · 2025/05/25(日) 14:11:23.96

コストカットさえすればあとは自然といい感じになるという説がある
書けないのか読めないのか
もし読めないなら、書くトレーニングを減らせばいい

**デフォルトの名無しさん** · 2025/05/25(日) 14:13:31.63

特定のイディオム的なやり方があるけどそれを知りたいんだろ

**デフォルトの名無しさん** · 2025/05/25(日) 14:19:30.22

トップダウンな段階的詳細化かな
CやHaskellにおける極めてスタンダードな構造化手法
WebやOO言語から入った奴が既存の枠組み無しで一からコード書こうとして書けないのは、大抵この基本的なトップダウン設計を理解してないのが原因

**デフォルトの名無しさん** · 2025/05/25(日) 14:23:16.15

>>856
デザインパターンはクラス前提での難点の工夫も多いけどRustは素直にトレイトでベストが多い

**デフォルトの名無しさん** · 2025/05/25(日) 14:26:54.40

クリーンアーキテクチャも各境界のトレイトを定めて各層から独立させることが肝やで

**デフォルトの名無しさん** · 2025/05/25(日) 14:37:17.44

初心者は動きを確認しながら作ろうとしちゃうからそれだけでは動かすことのできないトップを先に作るというのに慣れてない。
コードを書き始める前に設計を終わらせるというのも言語に慣れない内にするのは難しいしな……

**デフォルトの名無しさん** · 2025/05/25(日) 14:42:23.80

各レイヤのトレイト設計を先にする
下位はトレイトを実装する
上位はトレイトを利用する

**デフォルトの名無しさん** · 2025/05/25(日) 14:44:22.31

最適化の努力を全然やってないコードは「動かすことのできる設計図」に近い

**デフォルトの名無しさん** · 2025/05/25(日) 14:50:57.47

OOPに引っ張られると酷いコードになりやすいね
構造体をレコードとみなしてデータベースを操作するイメージだと整理しやすい気がする
ボローチェックはテーブルとか行のロックに近いし
変な粒度のテーブル（構造体）作るとロック競合で詰むのも似てる

**デフォルトの名無しさん** · 2025/05/25(日) 15:28:44.21

Rust は Haskell に副作用が許されてるくらいの感じ

**デフォルトの名無しさん** · 2025/05/25(日) 15:41:43.47

>コードを書き始める前に設計を終わらせるというのも言語に慣れない内にするのは難しいしな……
そんなんできるの？って感じなんだが
自分はどうしても書きながら改善していく形になってしまう

**デフォルトの名無しさん** · 2025/05/25(日) 15:48:51.02

>>867
リファクタリングしながらでもいい
トレイトに切り分けよう

**デフォルトの名無しさん** · 2025/05/25(日) 16:22:56.39

ポンコツばかりだな

前に出てきたような普通の言語なら何でもなく書けるけどRustでは書けないパターンで
一般的な回避法を探してるんじゃないか？

バッドノウハウ的なもの

**デフォルトの名無しさん** · 2025/05/25(日) 18:13:31.58

「副作用を許さないHaskell」や「staticを許さないJava」は綺麗なルールだが綺麗すぎる
実戦にそんなルールはない

**デフォルトの名無しさん** · 2025/05/25(日) 18:46:48.62

アンチパターンの知識は役に立つ
というか、そのパターンはデメリットがメリットを上回るという知識が役に立たない

**デフォルトの名無しさん** · 2025/05/25(日) 19:08:43.23

トップからのプログラミングしたいけど機会減ったな

**デフォルトの名無しさん** · 2025/05/25(日) 19:18:51.73

>>828
システムプログラミング言語でテキストエディタを作っちゃ駄目だよなｗ

**デフォルトの名無しさん** · 2025/05/25(日) 19:25:37.29

>>873
その用途もRustが最適

**デフォルトの名無しさん** · 2025/05/25(日) 19:42:58.71

>>873
そっか！サーバーサイトもフロントエンドも全部Rsutが最適なんだね！すごいね！Rust！

**デフォルトの名無しさん** · 2025/05/25(日) 19:56:26.05

それはそう

**デフォルトの名無しさん** · 2025/05/25(日) 20:21:45.96

Rustは最強だね

**デフォルトの名無しさん** · 2025/05/25(日) 20:26:32.18

もはや常識だぞ

**デフォルトの名無しさん** · 2025/05/25(日) 20:47:34.22

この板では、スレの勢いだけは最強だな

**デフォルトの名無しさん** · 2025/05/25(日) 22:28:28.84

Rustの生産性ってどーなの？C++より上？C#より上？

**デフォルトの名無しさん** · 2025/05/25(日) 22:49:17.80

普通はC#でいいんじゃね
特別な理由があればRustやCを使ってよい

**デフォルトの名無しさん** · 2025/05/25(日) 22:57:41.38

C++よりはさすがに上だけどC#には負ける印象
C#はよくできとる

**デフォルトの名無しさん** · 2025/05/25(日) 22:59:35.23

開発生産性を犠牲にしてパフォーマンスと安全性に振ってるのがRust

**デフォルトの名無しさん** · 2025/05/25(日) 23:11:26.43

>>883
開発効率の良さからRust使ってる
実行前に多くの問題が片付く点が大きい

**デフォルトの名無しさん** · 2025/05/25(日) 23:54:48.00

Rust製 coreutils 0.1 がリリースされた
https://github.com/uutils/coreutils/releases

Ubuntu 25.10 から採用される予定なのか
https://www.phoronix.com/news/Rust-Coreutils-0.1-Released

**デフォルトの名無しさん** · 2025/05/26(月) 00:19:33.38

うん。結構既出

**デフォルトの名無しさん** · 2025/05/26(月) 00:24:26.87

>>886
そっか、時々しか来ないんで
スマソ

**デフォルトの名無しさん** · 2025/05/26(月) 00:37:02.06

ええんやで

**デフォルトの名無しさん** · 2025/05/26(月) 01:35:11.42

>>886
嘘つき
昨日出たばかりの新情報

**デフォルトの名無しさん** · 2025/05/26(月) 08:22:21.45

声が聞こえない人が聞こえるのは下記の論文から見てもわかります
先天性【生まれた時には決まっている】のものです

心の中の声が聴こえない？「無内言症」とその影響
公開日2024.05.19 00:00:00 SUNDAY
私たちは日々、頭の中で自分と会話をしています。これは「内なる声」と呼ばれ、私たちの思考や行動に大きな影響を与えています。
しかし、驚くべきことに、人口の5〜10パーセントはこの内なる声を持たない「無内言症（anendophasia）」という状態であることが近年の研究で明らかになりつつあります。
デンマークのコペンハーゲン大学（UCPH）で行われた研究では、内なる声を持たない人々は単語の記憶力が低く、タスクの切り替えなども普通の人とは異なることが示されています。
研究内容の詳細は2024年5月10日に『Psychological Science』にて発表されました。
https://nazology.kusuguru.co.jp/archives/150322

統合失調症患者が「思考」と「外部の音」を区別できなくなる原因が明らかに
公開日2024.10.10 07:00:44 THURSDAY
そのような幻聴には、「お前には生きている価値がない」「死ね」などと自分を否定する声が含まれます。
また、「今、○○の建物に入った」「交差点を歩いている」などと、誰かが自分を監視しているかのような声が聞こえてくることもあります。
この機能の不具合により、患者たちは「脳内の思考」を自分のものだと認識しづらく、それがまるで外部から聞こえてきたかのように感じてしまうのです。
研究の詳細は、2024年10月3日付の学術誌『PLOS Biology』に掲載されました。
https://nazology.kusuguru.co.jp/archives/163195

統合失調症では脳の「意味ネットワーク」が崩壊していると判明！
公開日2022.12.27 18:00:51 TUESDAY
日本の東京医科歯科大学で行われた研究によって、統合失調症患者の脳内ではものの意味を関連付ける「意味ネットワーク」が無秩序になっており、異常な概念の結び付けや思考の一貫性の阻害が起きる原因になっている可能性が示されました。
研究内容の詳細は2022年12月21日に『Schizophrenia Bulletin』にて公開されています。
https:
//nazology.kusuguru.co.jp/archives/119693

**デフォルトの名無しさん** · 2025/05/26(月) 09:27:34.04

糖質ていうか多重人格なら自演は上手だろうな

**デフォルトの名無しさん** · 2025/05/26(月) 13:11:38.86

>>889
公式に出たのが昨日で、フォーラム情報なんかから、ここでも1ヶ月くらい前から噂になってたのかな

**デフォルトの名無しさん** · 2025/05/26(月) 13:27:39.25

>>892
別件ISRGによるsecurity分野Rust化でのsudoをUbuntu採用の話>>254のみ

**デフォルトの名無しさん** · 2025/05/26(月) 13:29:46.87

>>893
あれ、ここじゃないどこかのスレで見たのかな
X上のネタまである

**デフォルトの名無しさん** · 2025/05/26(月) 13:32:15.03

>>885は従来のGNU Coreutilsつまりls cat cpなど一般コマンドのRust化

**デフォルトの名無しさん** · 2025/05/26(月) 14:06:23.93

>>895
そんなん笑うわ

**デフォルトの名無しさん** · 2025/05/26(月) 14:57:19.37

C/C++製は可能な限り排除が世界の流れ
時間はかかるが着実に進む

**デフォルトの名無しさん** · 2025/05/26(月) 15:03:51.02

GNUプロジェクトでRustってなくない？
C排除が結果的にGNU/GPL排除になりそう

**デフォルトの名無しさん** · 2025/05/26(月) 15:13:23.78

GPL汚染やぞ
汚汚汚汚汚汚染やぞ

**デフォルトの名無しさん** · 2025/05/26(月) 15:25:41.75

なんでRust界隈はGPL採用少ないの？

**デフォルトの名無しさん** · 2025/05/26(月) 15:43:36.17

ubuntu黒人奴隷商人はgplもdebianの理念も関係ないしな

**デフォルトの名無しさん** · 2025/05/26(月) 15:58:41.68

>>900
Rust 界隈というより時代の流れ。
オープンソースの隆盛には GPL くらい苛烈にライセンスを感染 (汚染) させていく必要があったのは確かなのだが、
異なるオープンソースライセンスを組み合わせようとすると GPL は都合が悪いので今となっては積極的に選択しづらい原因にもなっている。

**デフォルトの名無しさん** · 2025/05/26(月) 16:30:01.17

時代変わったね。それだけソフトウェアも普及した

**デフォルトの名無しさん** · 2025/05/26(月) 16:31:17.97

それは違うな
今時のOSSの多くが採用しているMITライセンスはGPLと互換性があり、問題なく混ぜることができる
近年GPLに人気がないのは、ソフトウェアをマネタイズする際に、バイナリを配布するのではなくインターネットを介してサービスのみを提供する形が主流になったことが原因
本来GPLというのは「俺のコードで商売するならソースは公開しろ」という精神が根底にあるのだが、
マネタイズのためにバイナリを配布する必要がなくなったことでソース公開を要求できなくなり、無意味になってしまった

**デフォルトの名無しさん** · 2025/05/26(月) 16:33:59.10

GPL3があるでよ