Rust part21

**デフォルトの名無しさん** · 2023/08/15(火) 22:24:39.45

公式
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 part20
https://mevius.2ch.net/test/read.cgi/tech/1677771928/

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

**デフォルトの名無しさん** · 2023/09/09(土) 11:00:13.25

html の設計がいびつなんだよね……。
xhtml まではドキュメント記述言語としてタグのセマンティクスを重視した設計だったのが
html5 から living standard の流れで html はウェブアプリケーション基盤だとする派閥が圧勝した。

そこからの流れで外観を記述する言語としての活用が広まっている状況があるのは事実だし、
もうこの流れに逆らえないのも事実だと思うが
html はやっぱり GUI 記述言語としては不格好な存在だよ。

**デフォルトの名無しさん** · 2023/09/09(土) 11:33:35.06

ハッピープライスパラダイス
ハイパーテキストマークアップランゲージ

あくまでもテキスト用言語だからなぁ

**デフォルトの名無しさん** · 2023/09/09(土) 13:03:51.75

HTML+JSが嫌なら全部canvas+wasmでやればええねん
アクセシビリティとかは考慮しないものとする

**デフォルトの名無しさん** · 2023/09/09(土) 14:51:58.44

屋上屋を重ねるという慣用句はこういうときにつかうのかな。

**デフォルトの名無しさん** · 2023/09/09(土) 15:09:29.22

>>165
C/C++ は実行環境の管理と開発環境の管理を分けないスタイル(ライブラリもディストリビューションのパッケージマネージャーで管理する)でやってたし、分離するにしても chroot (今ならdockerでもよいかも)とかで出来てたからそれ以上には発展しなかった。
でも本来は別物ということにするほうが自然だと思う。
言語をまたいだ開発をするプロジェクトがややこしくなるがそれは本来的にややこしいものだからしょうがない。

**デフォルトの名無しさん** · 2023/09/09(土) 16:01:57.25

>>172
いつの話？無理やり停滞感を擦り付けている???

発展して_____+_____がデファクトスタンダード
それで不足なら_____サーバー

毎回ビルドに6時間とか待たなくて良いように発展した手法がほぼ統一された
Rustもビルド時間の件で大揉めしたじゃん、何も解決しなかったけど
(空気読んで情報は伏せた)

**デフォルトの名無しさん** · 2023/09/09(土) 16:45:26.09

>>173
過去形で書いてるよ。
今は違うと強調したつもりの表現なんだけど……

**デフォルトの名無しさん** · 2023/09/09(土) 18:12:41.11

>>174
>今は違うと強調した

本気で言っているのなら
ちょっと心配になるレベルのコミュ□だぞ

か、またはネット□□師か？

あと後出し皮肉オジは煽りオジと同化しているからやめろ

Rustで煽りオジはサイコパス確定した
https://mevius.5ch.net/test/read.cgi/tech/1693451813/93
>軽く煽った後は、本業に戻る、だよ急がないし

**デフォルトの名無しさん** · 2023/09/09(土) 19:36:26.65

オジ連呼厨は他人に絡み過ぎ
このプログラム板では人でなくプログラムや技術に目を向けろ

>>165
cargoはrustcとハードリンク一体化してるようにRust用かつ公式
yarnとnpmで分裂しているのとは異なり一体化してくれていてありがたい

**デフォルトの名無しさん** · 2023/09/09(土) 19:51:44.43

>>165
大統一パッケージマネージャ作ってくれ

**デフォルトの名無しさん** · 2023/09/09(土) 20:39:12.68

debとかrpmとか

**デフォルトの名無しさん** · 2023/09/09(土) 21:06:18.16

>>178
aptで良いと思う

**デフォルトの名無しさん** · 2023/09/09(土) 21:31:02.60

>>175
後出し皮肉オジは、コテハン出してた頃の複オジそのものに見えます
質問して答える自作自演も

**デフォルトの名無しさん** · 2023/09/09(土) 21:33:52.69

>>179
aptはdebパッケージの管理ツール

**デフォルトの名無しさん** · 2023/09/09(土) 22:07:42.11

>>178
依存crateをいちいちapt-getしてくるのさすがに大変すぎないか？

**デフォルトの名無しさん** · 2023/09/10(日) 10:57:43.69

>>165
antも廃れたな

**デフォルトの名無しさん** · 2023/09/10(日) 13:28:10.69

>>183
パッケージマネージャの側面はmavenからでantにはivyで逆輸入された。

antは廃れるべくして廃れたな。

**デフォルトの名無しさん** · 2023/09/10(日) 14:52:06.76

mavenとかまだ使ってるとこあるの？
普通はgladleだよね？
未だにmavenだとしたらちょっとそこはヤバいと思う。

**デフォルトの名無しさん** · 2023/09/10(日) 15:10:16.28

今でも使ってるなんて誰も言ってないのでは

**デフォルトの名無しさん** · 2023/09/10(日) 15:36:29.89

いや、未だにmavenって認識が間違ってるよ。
定型的な開発サイクルであればmavenで十分だしそこで明確なツラミもないのにgradleに移行しようって判断するようなチームはヤバい。

とはいえ今だと初手でgradle選択するチームが多いだろうね。

**デフォルトの名無しさん** · 2023/09/10(日) 16:18:37.72

自分で質問して自分で答えるタイプの人でしたか

**デフォルトの名無しさん** · 2023/09/10(日) 17:15:47.84

みんなjavaに詳しいのね

**デフォルトの名無しさん** · 2023/09/11(月) 00:02:48.34

ビルドのためにグルービーとかいう言語を使わなければいけないことに異常性を感じないのかjavaの人たち

**デフォルトの名無しさん** · 2023/09/11(月) 00:13:23.96

MakefileやCMakeも大概だしビルドは魔境

**デフォルトの名無しさん** · 2023/09/11(月) 00:18:19.95

Groovy は、Rubyist なら分かる。ほぼ同じ

**デフォルトの名無しさん** · 2023/09/11(月) 00:23:10.62

>>190
今のgradleはgroovyじやなくてkotlinで書けるよ

**デフォルトの名無しさん** · 2023/09/11(月) 09:54:06.45

もう maven も gradle も java も使ってないから安心汁

**デフォルトの名無しさん** · 2023/09/11(月) 17:56:49.57

>>190
世の中にはビルドとかCI/CDの定義ファイルがYAMLだからって、それ拡張してif else の制御構造組み込んでるところもあるんやで。

**デフォルトの名無しさん** · 2023/09/11(月) 21:37:45.75

>>195
antやん

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

CNCF系はyaml好きだからね
それはさておき、言語固有のリポジトリマネージャはOSとは独立じゃないとディストリビュータもライブラリ管理者も辛いという必要性があって生み出されたもの
今後もなくなる事は無いでしょう。CPANあたりが元祖ですかね

**デフォルトの名無しさん** · 2023/09/13(水) 23:41:57.05

tomlがEBCDICで描かれてたら絶望しかない

**デフォルトの名無しさん** · 2023/09/14(木) 10:03:14.07

さすがにcpanなんかもう使われてないよ

**デフォルトの名無しさん** · 2023/09/14(木) 10:31:50.25

tomlとRustって直接関係あるの？
単に採用が多いってだけ？

**デフォルトの名無しさん** · 2023/09/14(木) 10:45:04.55

明確に関係を規定しているわけではないが
開発ツールチェインで採用している以上は馴染みやすいし、
習慣的に toml が普通という感じ

**デフォルトの名無しさん** · 2023/09/14(木) 18:18:10.36

JetBrains から RustRover 出たね。まだプレビュー版だけど。その代わり無料だ。

**デフォルトの名無しさん** · 2023/09/14(木) 18:20:11.06

ぜひとも IntelliJ IDEA のように無料のcommunity版も出して欲しい。

**デフォルトの名無しさん** · 2023/09/15(金) 11:42:38.55

的を射ている
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

**デフォルトの名無しさん** · 2023/09/15(金) 12:00:21.56

めちゃペラいな
初めて3日くらいの感想ぽい

**デフォルトの名無しさん** · 2023/09/15(金) 12:00:26.41

しょーもな...

**デフォルトの名無しさん** · 2023/09/15(金) 12:03:53.15

しっかりやってる人の意見
https://kerkour.com/should-i-rust-or-should-i-go

Goと比較した場合のRust一番大きいメリットはエラー処理やバグ検知だけどasyncのデメリットが大きいのも確か

**デフォルトの名無しさん** · 2023/09/15(金) 12:13:34.28

むしろNimのネガキャンにしかなってないって話題になってた記憶が

**デフォルトの名無しさん** · 2023/09/15(金) 12:13:50.38

>>205
Rustの一番の課題が絶壁の学習曲線なんだから、３日目の感想は重要だろ。
それを無視するならHaskell化待ったなしだな。

**デフォルトの名無しさん** · 2023/09/15(金) 12:52:21.36

情報密度が違っててワロス
https://www.ossnews.jp/compare/Rust/Nim

**デフォルトの名無しさん** · 2023/09/15(金) 12:58:36.85

>>207
むしろasyncが容易かつ効率的なことがRustの利点だよ
そして軽い非同期タスクを大量にマルチスレッド上でいわゆるM:Nスケジューリングできるのは、
RustとGoしかないためその両者の比較になるのはその通りだが出来る範囲はRustが広くきめ細かい
もちろん非同期以外の言語仕様も同様でGoは貧弱すぎる

**デフォルトの名無しさん** · 2023/09/15(金) 13:33:46.47

Go は貧弱だが Go くらいで十分な範囲をカバーできるだろ……という割り切りで設計されているように見える。

**デフォルトの名無しさん** · 2023/09/15(金) 14:58:25.08

Goは構文が簡素なのは割り切りとしていいと思うんだけど
参照周りの扱いとかCの頃から進歩してなくて
「こんなこと今どき人間が気をつけて書くの？」という気持ちにはなる

**デフォルトの名無しさん** · 2023/09/15(金) 16:57:51.41

>>210
こういう役に立たない一般論に比べれば>>204のような薄っぺらい個人の感想のほうが実践知なのでまだ価値がある

**デフォルトの名無しさん** · 2023/09/15(金) 19:05:24.10

>>210
スマホからは何も見えない……
なんかあるの？

**デフォルトの名無しさん** · 2023/09/15(金) 19:11:49.50

>>215
RustとNimを比較してるサイト

**デフォルトの名無しさん** · 2023/09/15(金) 20:05:41.52

Goは構文簡素にしてても内部のGCとかは複雑にしてるイメージ。

**デフォルトの名無しさん** · 2023/09/15(金) 20:39:40.02

>>214
どちらのページも意味のある情報がなにもない
くだらない揚げ足取り

>>215
PCからしか内容が見えないダメサイト
内容に意味はないため見る必要ない

**デフォルトの名無しさん** · 2023/09/15(金) 22:34:16.16

そのRust批判を書いてる人もそうだが
意味のあるプログラミング経験の少ない人はmutを毛嫌いしてるよな

言語に関係なくミュータブルか否かの区別がある方が好ましく
ミュータブルの使用は必要最小限が好ましい
という当たり前のことに沿う仕様なのに理解できなくて批判

**デフォルトの名無しさん** · 2023/09/15(金) 23:11:51.65

>>219
ミュータブルか否かの区別があるのは煩雑になるだけで好ましくない。WindowsやLinuxのソースコードに
Rustが採用されたと言ってもごく一部でメモリ安全性が特に重視される部分だけ。全部をRustで書くなんて
煩雑な作業には人間はとても耐えられない。

**デフォルトの名無しさん** · 2023/09/15(金) 23:17:03.67

>>219
>ミュータブルか否かの区別がある方が好ましく
当たり前では

mojo調べでlet/var区別が好ましいと決着ついた
https://docs.modular.com/mojo/manual/basics/index.html#variables

rust mutが好まれてないだけ

>>220
let/varだと区別がありつつ煩雑じゃない、という事ですね

**デフォルトの名無しさん** · 2023/09/15(金) 23:24:01.30

それと
>>220
Linuxカーネル本体は当分Cのままで
デバイスドライバをrustで書く準備が出来た、だけですよ

**デフォルトの名無しさん** · 2023/09/15(金) 23:26:04.83

>>220
mutableとimmutableの区別は必須
それを煩雑という者は初心者のみ

>>221
色んなプログラミング言語をやってきてる者にとってそんな些細な記述方法を問題にするやつはいない
参照のある言語でmutableを区別するならばmut付加方式が合理的
例)　let mut x: &mut Type = ...

**デフォルトの名無しさん** · 2023/09/15(金) 23:28:27.24

あと前スレで出ていたcurlですが
rust TLS backendを使う選択肢があるのに配布用には採用されてませんね

$ curl -V
... libcurl/8.3.0 OpenSSL/3.1.2 (Schannel) zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.11.0 nghttp2/1.56.0
Release-Date: 2023-09-13

**デフォルトの名無しさん** · 2023/09/15(金) 23:30:46.42

letの後に識別子しか書けないならlet/varでいいんじゃね
パターンが書けるならlet/varよりlet/let mutの方が合理的な気がする

**デフォルトの名無しさん** · 2023/09/15(金) 23:31:04.61

ここはRustのスレ
的外れなRust叩きをしているバカはアンチスレへ移動しろ

**デフォルトの名無しさん** · 2023/09/15(金) 23:35:09.11

sudo-rsも v0.2.0でstableと言い切って知らないdistributionに
ねじ込んだようですがその後どうなるのか要チェックです

**デフォルトの名無しさん** · 2023/09/15(金) 23:43:02.23

mojoの所有権周りの構文ってRustより重い感じなんだな
これPython書きたいような人に受け入れられるんだろうか…

**デフォルトの名無しさん** · 2023/09/15(金) 23:44:55.11

>>225
>パターンが書けるならlet/varよりlet/let mutの方が合理的な気がする
気がする、ではなく
合理的だという説明が聞きたい

**デフォルトの名無しさん** · 2023/09/15(金) 23:47:42.54

>>221
たとえばRustでよくあるこういうパターンはmojoでどうするんだろう
let (tx, mut rx) = channel(100);
そもそも可変参照はどう区別するんだろうね
あと関数の引数変数のmutable性はどうやって表すんだろう
Rustのmutを添える方式が自由度が高くてわかりやすいよね

**デフォルトの名無しさん** · 2023/09/15(金) 23:48:06.93

>>228
どの辺りが重い感じ？

**デフォルトの名無しさん** · 2023/09/15(金) 23:52:51.61

>>231
borrowed, inout, owenedって全部キーワード指定だし結構長くない？
自分はRustみたいに明示的なのが好きだから多少長くてもいいけど
Python好きな人だとどうなんだろうって

**デフォルトの名無しさん** · 2023/09/15(金) 23:54:33.01

パターンマッチの場合束縛する変数が複数になり得るので、それぞれの変数に対して異なるmutabilityを宣言できる

あと、Rustは変数への束縛にmove/refの区別もあることも関係してるかもね
letやvarのように別構文を用意するなら、それぞれに対してmove版、ref版が必要になってしまう

**デフォルトの名無しさん** · 2023/09/15(金) 23:59:25.63

let (foo, ref mut bar) = とかよく使うもんね
mutやrefが分離キーワードになっているRustが便利

**デフォルトの名無しさん** · 2023/09/15(金) 23:59:43.71

>>230
なるほどね
mojoでunpackがどうなるのか知らないけど
unpack用のlet/varシンタックスはあった方が良いね

let/var方式の他の言語を参考にするんだろうな

**デフォルトの名無しさん** · 2023/09/16(土) 00:02:44.62

>>234
>mutやrefが分離キーワードになっているRustが便利

これを突き詰めるとponyになるって5chで聞いたよw

**デフォルトの名無しさん** · 2023/09/16(土) 00:03:10.36

>>234
いや、今となってはrefはほとんど使わん

**デフォルトの名無しさん** · 2023/09/16(土) 00:26:11.63

TauriとTauri Mobileが別々の実装として統合されないの悪手だと思うんだがな
せっかくRustでロジック書けてネイティブ呼び出しまで簡単で手頃なフロントエンド実装で期待してたのにわざわざコミュニティ分断する必要あるんか？
なんかXamarinみたいな結末迎えそうで残念だわ

**デフォルトの名無しさん** · 2023/09/16(土) 09:10:27.83

T,o,k（迷惑という方は←をあぼーんしてください。）

更に家族に教えて加えて￥4000×人数をGET。
https://i.imgur.com/p75gBok.jpg

**デフォルトの名無しさん** · 2023/09/16(土) 09:55:59.18

>>238
無理に一つにしようとすると条件分岐増えてごちゃごちゃしてわかりにくくなる、というのはありそう。知らんけど。

**デフォルトの名無しさん** · 2023/09/16(土) 10:40:22.96

>>239
もう現金化してアンインスコしてる

**デフォルトの名無しさん** · 2023/09/16(土) 11:27:20.46

RustRoverを試してみる
https://zenn.dev/helloyuki/scraps/a0241df49b2556

**デフォルトの名無しさん** · 2023/09/16(土) 11:55:36.71

ウェブ系の奴らがやけにJetBrains推してくるけどAndroid Studio使ったら如何にゴミIDEなのかよくわかった
しかも個人使用でも買い切り数百ドルもしたのに今はサブスク月額1300円とかぼったくりもいいところ
VSCodeがあって本当によかったVSもCEならデバッガに制限あるけど無料だしこれほどMSに感謝したことはないね

**デフォルトの名無しさん** · 2023/09/16(土) 12:20:19.81

mut よりもShared XOR Mutableの方が難しいだろ。

**デフォルトの名無しさん** · 2023/09/16(土) 12:41:23.41

>>243
Android Studio は IntelliJ IDEA がベースになっていて無料の community 版があるが?
ていうか Android Studio の方は最初から無料じゃなかったか? 金取るやつあるの?

**デフォルトの名無しさん** · 2023/09/16(土) 12:57:41.63

>>223
let x: &mut Type = ...
でよくね？

**デフォルトの名無しさん** · 2023/09/16(土) 13:00:07.59

>>244
lifetimeが難しいというのも大体がshared xor mutableの話だしな

**デフォルトの名無しさん** · 2023/09/16(土) 13:07:54.84

>>246
それだとimmutableとなり変数値を書き換えできないから根本から違う

**デフォルトの名無しさん** · 2023/09/16(土) 13:23:53.43

描き替え出来るから問題無い

**デフォルトの名無しさん** · 2023/09/16(土) 13:57:40.01

>>249
ポインタ値の書き換えと
ポインタが指す先の書き換えの
区別がついていないのはCでも初心者レベル

**デフォルトの名無しさん** · 2023/09/16(土) 14:05:34.65

うん
だから付ける必要無い所まで描く必要無いよね

**デフォルトの名無しさん** · 2023/09/16(土) 14:06:34.42

refとmoveの区別がある言語とそうでない言語の構文比較しても仕方なかろう

**デフォルトの名無しさん** · 2023/09/16(土) 14:10:34.38

>>246
ダメです
全く異なります
let mut x: &mut Type = ...　←xの値を書き換えられる
let x: &mut Type = ...　←xの値を書き換えられない

**デフォルトの名無しさん** · 2023/09/16(土) 14:24:43.82

>>253
だから付ける必要無い所まで描く必要無いよね

**デフォルトの名無しさん** · 2023/09/16(土) 14:32:47.40

>>239
絶対に試すべきだね。

**デフォルトの名無しさん** · 2023/09/16(土) 14:37:19.47

>>254
mutabilityを必要とする分に応じてmutを付ける必覧vがあります
そのため以下4種類がコードに応じて使い分けされています
let mut x: &mut Type = ...
let x: &mut Type = ...
let mut x: &Type = ...
let x: &Type = ...
前者のmutは変数xの値を更新するならば不可欠です
後者のmutはType型の可変参照で参照先の値を更新するならば不可欠です
それぞれの値を更新するためにはそれぞれのmutを欠くことはできません

**デフォルトの名無しさん** · 2023/09/16(土) 14:43:13.66

ほんまジャップはアホやな
しょーもない重箱の隅をつつきあって知識自慢のマウント合戦
そして出来上がった成果物は誰も使わないクソゴミ
ジャップがオナニーしてる間にソフトウェアは中国に30年遅れているという現実
お前ら見てるとマジで日本人がソフトウェアで土人の未開レベルな理由がよーくわかる

**デフォルトの名無しさん** · 2023/09/16(土) 17:08:24.37

まともなプログラミング言語ならばそれら四つの区別がある
例えばC/C++ではこのように対応する

// 変数値は不変で参照先も不変
Rust: let p1: &i32 = ...
C/C++: const int* const p1 = ...

// 変数値は可変で参照先は不変
Rust: let mut p2: &i32 = ...
C/C++: const int* p2 = ...

// 変数値は不変で参照先は可変
Rust: let p3: &mut i32 = ...
C/C++: int* const p3 = ...

// 変数値は可変で参照先も可変
Rust: let mut p4: &mut i32 =...
C/C++: int* p4 = ...

つまり可変な時にmutを付けるか
不変な時にconstを付けるかの些細な違いにすぎない

**デフォルトの名無しさん** · 2023/09/16(土) 17:14:29.95

参照の可変性という概念を持つ言語がそもそも少ない

**デフォルトの名無しさん** · 2023/09/16(土) 17:15:13.87

概念が異なるのに構文の話だけをしても仕方ない

**デフォルトの名無しさん** · 2023/09/16(土) 17:34:04.75

参照先の値がread onlyかwritableかはプログラミングで極めて重要だよね
間違えて意図せず書き換えてしまっていたバグなどの減少にも繋がるから必要な機能じゃないかな

**デフォルトの名無しさん** · 2023/09/16(土) 17:37:07.29

>>258
2番目と4番目はRustだとsmellyなのでリファクタリング検討候補

**デフォルトの名無しさん** · 2023/09/16(土) 19:41:48.63

>>204が言ってるのはmutの区別が不要じゃなくて
良く使うmutable側でタイプさせんなってことでしょ

**デフォルトの名無しさん** · 2023/09/16(土) 20:04:56.12

ほとんどのプログラムではmutと記述すべきところが少ない
もしmutが多いならレアケースを除いてコードを改善すべき可能性が高い

**デフォルトの名無しさん** · 2023/09/16(土) 20:10:22.45

>>263
＞良く使うmutable側でタイプさせんなってことでしょ

お前、それプログラミングのセンス無いわ。
あ、もしかして使い捨てのコードしか書いたこと無い？

**デフォルトの名無しさん** · 2023/09/16(土) 20:12:22.58

>>263
慣れてきたらmutあんま使わなくて書けるようになるよｗ
関数型言語やってるとmut相当のもんなんて基本使わんのだし

**デフォルトの名無しさん** · 2023/09/16(土) 20:31:44.89

>>266
その代償としてイミュータブルをコピーしまくってメモリ浪費して関数型言語遅いじゃん

mut祭りで読みづらい代わりに高速でメモリ効率が良いのがRustの売りでしょ