23/08/16 00:25:33.09 Wd6XOYTc.net
隔離スレができてから、多少S/N比が改善することを期待して様子見してたけど
やっぱり一度去った人が戻ってくることはないし、どうしようもないんやなあって
まだ見てる物好きなRustaceanはﾜｯﾁｮｲスレにも是非来てくれや
17:デフォルトの名無しさん
23/08/16 03:56:50.52 1NDN9ysp.net
>>15
前スレ
> 1000 名前：デフォルトの名無しさん[sage] 投稿日：2023/08/15(火) 22:12:55.30 ID:6mJ3MaUL
> rustupが動かないので手動でクロスビルド環境を構築したいんだが
> rustup target add ～
> って具体的に何やっているの？ターゲットはとりあえずthumbv7em-none-eabihfとriscv32imac-unknown-none-elfの２つ
> ネイティブビルド環境は公式にあるプレビルドファイル一式を適当な場所に手動で展開すれば構築できるけど(構築済み)
の回答をもらえるならﾜｯﾁｮｲスレに行こう
18:デフォルトの名無しさん
23/08/16 04:11:40.66 N5bIbKLx.net
rustupが動かない、というのが理解できない
rustupはクロス環境関係ない
クロス環境用には実行バイナリだけ生成すればいい
rustupはそのままネイティブ自環境でのみ動けばよく
rustup target add xxxでクロス用のtoolchainを指定
そのあとはシンプルにまずはrustc --target xxx test.rsが動くかどうか
19:デフォルトの名無しさん
23/08/16 04:35:41.91 N5bIbKLx.net
例えばrustup target add wasm32-unknown-unknownすると
rustupのhomeが ~/.rustup のとき
~/.rustup/toolchains/*/lib/rustlib/ の下にできる
20:デフォルトの名無しさん
23/08/16 10:47:04.56 tgyEZLGb.net
>>5
同意はするが
Rustの資料って体系化されずにとっ散らかってるイメージがあるから
手っ取り早くアクセスできるようにまとめてくれてるのは有難い
21:デフォルトの名無しさん
23/08/16 14:44:41.59 1NDN9ysp.net
>>17
rustupがリンクが使えるファイルシステム？じゃないと動かないっぽい
ノートPCでNTFSパーティションがカツカツなのでSDカード(FAT32)上にインストールしたいがリンクできないとか怒られる
rustcやcargoはリンクできないから動かないようには見えないしよくわからない制限
この現象は公式フォーラムにも書かれていたがパーティションを変更するみたいな回答しかなかった
現状はネイティブビルド環境は公式からプレビルドのバイナリを落としてきて解凍すれば構築できるが
そのような代替手段がない？クロスビルド環境は構築できない状態
22:デフォルトの名無しさん
23/08/16 15:31:51.82 Qm23kCGE.net
ここは素人相手のサポートセンターじゃないんだから「動かない」とか「動かないっぽい」とかじゃよっぽどの暇人以外には相手にされないぞ
23:デフォルトの名無しさん
23/08/16 15:45:31.11 1NDN9ysp.net
現象は
URLﾘﾝｸ(users.rust-lang.org) ←exFATパーティションにインストールしようとして失敗している
これと同じだと思う
24:デフォルトの名無しさん
23/08/16 18:15:04.82 Wd6XOYTc.net
ﾜｯﾁｮｲスレに書いといたんでよろしゃっす
25:デフォルトの名無しさん
23/08/16 18:52:12.16 tBfVLS+Q.net
>>20
rustupをターゲット先で動かす必要ある？
例えばターゲット先がWasmだとそこにrustupもcargoもないけど
それらがある手元でWasmバイナリを生成できるよね
リンクが使えるファイルシステムでコンパイルできない状況がわからないので教えて
26:デフォルトの名無しさん
23/08/16 22:31:03.77 o5ZiEkHD.net
>>24
exFat ではシンボリックリンクを作れないって話が明瞭に書いてあるだろ。
ファイルシステムの機能として無いものは無い。
27:デフォルトの名無しさん
23/08/16 23:07:47.05 tBfVLS+Q.net
>>25
クロスビルドは任意の環境で行なえるのに
なぜFATしか使えない環境でビルドするのか不思議に思ったのです
すみません
28:デフォルトの名無しさん
23/08/17 00:30:25.16 IFnR6C6t.net
ポータブルメディアだとFATをつかうのはそれなりにあることだからなあ。
買った時点でフォーマット済みなのも普通だし。
さすがにSDカードに開発環境を構築するのは想定外と言えるにしても外付けハードディスクくらいなら事情によっては無いこともないんじゃないか。
29:デフォルトの名無しさん
23/08/23 15:46:36.91 89z/H8g7.net
let hoge = "もとの文字列";
let hoge = hoge.replace("なんか1を", "別のなんか1に変換");
let hoge = hoge.replace("なんか2を", "別のなんか2に変換");
let hoge = hoge.replace("なんか3を", "別のなんか3に変換");
...
みたいなのが連続して実行したいとき
まとめてやってくれるような関数とかありますか？
また変換表がVecとかMapとかDBみたいなのに対応してるものもありますか？
30:デフォルトの名無しさん
23/08/23 17:55:57.94 JDxfEBUZ.net
>>28
単に連続して実行したいだけなら自分でループさせる関数作れば十分だと思う
効率的なアルゴリズム実装を探してるならとりあえずaho-corasick
regexを使ってるようなプロジェクトならregexでもいいと思う
31:デフォルトの名無しさん
23/08/23 18:02:34.00 JDxfEBUZ.net
もとの文字列が大きくなればなるほどstr::replaceを繰り返し実行する方法は効率が悪くなる
もとの文字列が小さいならあんまり気にする必要無い
少なくともベンチマークとってから考えるべき
32:デフォルトの名無しさん
23/08/23 23:32:44.32 J9iaXSyF.net
その前に変換された部分を後続の変換の対象にするのかしないのかを決めないと
「まとめてやる」だから対象にしないっぽいけど
文字列リテラルのエスケープを本来の文字に置換するイメージでいいのかな
変換前の文字列を簡単なパターンで表現できるなら正規表現のライブラリがいいと思う
余分にひっかけた場合は変換せずにそのまま通す感じで
マッチした文字列→変換する文字列の処理を自前の関数で書くとよさそう
33:デフォルトの名無しさん
23/08/23 23:46:47.50 1keD1dOe.net
aho使うのが楽
入力がimpl std::io::Readで出力がimpl std::io::Writeを指定できるからファイルでもなんでも楽
34:デフォルトの名無しさん
23/08/24 07:02:22.08 2mbJt/0N.net
thx
35:デフォルトの名無しさん
23/08/26 21:30:29.95 gjVHse6A.net
constな再帰関数で以下のエラーが出てその対処方法を知りたいのですが
error[E0080]: evaluation of constant value failed
| foo(n)
| ^^^^^^ exceeded interpreter step limit (see `#[const_eval_limit]`)
const_eval_limitで検索しても削除された(？)らしい情報しかわかりませんでした
どう指定するとリミットを増やせますか？
36:デフォルトの名無しさん
23/08/26 22:02:13.69 ONdb/hN6.net
>>34
古いバージョン使ってない？
37:デフォルトの名無しさん
23/08/26 22:23:39.67 hWWrh3fN.net
1.72での変更みたいだね
38:デフォルトの名無しさん
23/08/27 08:31:30.86 lrONLN4Y.net
一昨日リリースの1.72にこう書いてあるな
URLﾘﾝｸ(blog.rust-lang.org)
you can allow(const_eval_long_running) to permit especially long const evaluation.
ところがこう指定してもエラーになる
#[allow(const_eval_long_running)]
正解はこれ
#[allow(long_running_const_eval)]
39:デフォルトの名無しさん
23/08/27 19:53:52.23 Aks4ymi6.net
>>37
リリースを読む奴はほとんどいないだろってことでいい加減でも良いやといことだろうな
Rust野郎にしてみれば手を抜を抜けるところは手を抜くって良いこと
40:デフォルトの名無しさん
23/08/27 21:39:30.30 /o9fKn5S.net
コンパイルエラーで正しいほうが表示されるから問題ないわな
const_eval_limitのほうは↓
#![feature(const_eval_limit)]
#![const_eval_limit = “10000000”]
41:デフォルトの名無しさん
23/08/27 23:07:34.85 F9w6FdF5.net
レビューすり抜けちゃったんだな
PRでも出してあげたら
42:デフォルトの名無しさん
23/08/28 03:13:40.15 gISZWwhM.net
英単語のスペルチェックはしなくて良いから
関数や変数のスペルチェックに力を入れてくれ > Codeエディタさん
43:デフォルトの名無しさん
23/08/29 03:19:51.47 UVGH3K1M.net
VSCodeの余計なお世話機能外しのサイトないかな？とにかく邪魔
44:デフォルトの名無しさん
23/08/29 09:29:50.39 ud/hz0aH.net
let hoge = "hoge".to_string();
let v = hoge.as_bytes().to_vec(); // ← ここでデータのコピーは発生しますか？
45:デフォルトの名無しさん
23/08/29 09:40:59.22 ud/hz0aH.net
あー
let v = hoge.into_bytes(); // これか
46:デフォルトの名無しさん
23/08/29 10:07:33.54 ud/hz0aH.net
let v = hoge.as_bytes().into(); // これも等価なんか？
47:デフォルトの名無しさん
23/08/29 10:08:22.27 ud/hz0aH.net
>>43 と >>45 が等価で
>>44 だけ違うんか？
48:デフォルトの名無しさん
23/08/29 10:28:52.72 hbocgPIY.net
>>43
コピーを発生せずに別の型へ変換するには「消費してxxxへ変換」(into_xxx)するしかないため元が所有権を持たなければならない
つまり単なるスライス参照&[T]をto_vec()するのはコピーが発生する
一方で所有権を持つスライスBox<[T]>ならばinto_vec()でコピーを発生させずにVecにできる
このto_xxxとinto_xxxに注意
>>44
互いに消費してコピーを発生せずに行き来できる
let vec = string.into_bytes();
let string = String::from_utf8(vec).unwrap();
前者は特にVec<u8>になるためinto_vecではなくinto_bytesと名付けられている
後者はutf8保証チェックが入るためResultが返る
その保証を人が与えるならチェックを省略できる
let string = unsafe { String::from_utf8_unchecked(vec) };
49:デフォルトの名無しさん
23/08/29 11:53:16.22 j8lLGaij.net
>>46
リファレンス見ればすぐわかるよ
もし見方や調べ方がわからないならそれを質問するといい
50:デフォルトの名無しさん
23/08/29 14:58:40.58 0ZJbGVqi.net
>>42
VSCodeの邪魔な機能で最初に思い浮かぶのはinlay hintsだな
［File > Preferences > Settings］の［Editor › Inlay Hints: Enabled］を
offかoffUnlessPressedに変えると消える
offUnlessPressedだとCtrl + Altを押してる間だけ表示される
51:デフォルトの名無しさん
23/08/30 11:49:10.17 2xM9XyZu.net
unsafeを使ったコードで
有効な参照ではないことを確認する方法はありますか？
52:デフォルトの名無しさん
23/08/30 15:30:33.41 OpkUn9pD.net
miriやaddress sanitizerやloomのようなツールとテストの組み合わせで検知するくらいじゃないかな
もちろん100%の検知は不可能
53:デフォルトの名無しさん
23/08/30 15:37:47.00 jEaVNaFL.net
日本人は100%とか完璧とか絶対とか求めるの好きだよね。
やる側が志すのはいいんだけど、たいていはやらない側が求めてくる。
54:デフォルトの名無しさん
23/08/30 17:42:42.30 Pm5h7iVu.net
そういう理にかなわないことをしているから原発がぶっ飛ぶんやで
55:デフォルトの名無しさん
23/08/30 17:57:48.34 DO1AbTsl.net
address sanitizerじゃなくてmemory sanitizerだった
56:デフォルトの名無しさん
23/08/30 20:21:44.39 y+HDByBG.net
無効な参照は即UBじゃなかったけ
なので正しく書かれたRustプログラムの参照はすべて有効
57:デフォルトの名無しさん
23/08/30 21:05:03.06 7wIq4Piv.net
正しく書かれてるかどうかを確かめる方法を聞いてるんだろ
58:デフォルトの名無しさん
23/08/30 22:02:55.54 zbgAoZ7n.net
rustでdll造ってCから使うとき
rust側で勝手に捨てられるのは困るな
59:デフォルトの名無しさん
23/08/30 22:17:03.68 kn7H0YN4.net
そのためにforgetとかleakみたいな謎関数がある
存在は知ってるけどまだ使う機会に恵まれない
60:デフォルトの名無しさん
23/08/31 00:43:59.43 gbA1Jwq2.net
Cに所有権ごと渡すなら使うのはinto_rawかfrom_rawじゃね
61:デフォルトの名無しさん
23/08/31 11:31:08.47 qE8kvwKZ.net
Rustしばらく使ってるとC/C++描けなくなってくる
62:デフォルトの名無しさん
23/09/01 16:56:03.45 8Q6o7DlX.net
sqlite3 用の crate って sqlite3 という名前のがあるけど
rusqlite 使うのとどっちが良い？
63:デフォルトの名無しさん
23/09/02 07:37:58.97 v3EBZAej.net
失礼します
Rustは制約の厳しい言語だから（環境さえ整えば）他言語にトランスパイルしやすい言語
という認識は合ってるでしょうか？
64:デフォルトの名無しさん
23/09/02 08:12:23.91 bvTG+KAn.net
Rustは制約がほとんどなく自由な裁量の大きな言語の一つ
楽に書ける方法の一方で色んな観点を極めることにより書き手によってメモリ利用法や実行速度もピンキリになりうる
色んな環境で動かせることもできてOSの無い環境やstdライブラリを使わない方法など自由が大きい
プログラミングパラダイムやスタイル指向の見地からも書き手によって様々な方針をとることができる
65:デフォルトの名無しさん
23/09/02 08:29:19.99 bvTG+KAn.net
ランタイムが必須かどうかも制約として重要になってくる
C/C++やRustはそのような制約がないため他の言語のライブラリ作成にも用いることができる
WebAssemblyでの実行についても同様でそのような制約のないRustが有利なため最も使われている
66:デフォルトの名無しさん
23/09/02 11:00:44.98 YkB2gBn6.net
>>62
トランスパイル先言語との機能的互換性の高さやや元言語のコンパイラが単純なほうがトランスパイルしやすいと思う
例えばOwnership/Borrow/Lifetimeあたりのトランスパイルが楽かどうか
67:デフォルトの名無しさん
23/09/02 11:44:04.91 g76m2OPt.net
>>65
壮大な勘違いしてるな
実行時に所有権やライフタイムは一切出て来ないぞ
68:デフォルトの名無しさん
23/09/02 11:48:36.47 l2r0UsPx.net
>>66
壮大な勘違いしてるな
トランスパイル時は実行時ではないぞ
69:デフォルトの名無しさん
23/09/02 11:50:40.77 l2r0UsPx.net
一口にトランスパイルといっても、元言語にあった属性をどこまで先言語に引き継ぐかは目的に応じた取捨選択がなされるものです
前例がないので>>62に対する答えは「未知数」としか言えないですね
あるいは言語自体に「トランスパイルのしやすさ」という属性があるとすれば、それは「言語自体がトランスパイルされることを前提として設計されているか」と同義でしょう
その側面から言えば答えは「いいえ」です
70:デフォルトの名無しさん
23/09/02 12:05:15.52 f2x52juV.net
ライフタイムは妥当かどうかの静的なチェックに使われるもの
トランスパイル先に持ち込まれることはない
71:デフォルトの名無しさん
23/09/02 13:06:33.37 euHMK3ab.net
短絡思考 + 自己弁護 = 複オジ
72:デフォルトの名無しさん
23/09/02 13:21:18.64 gZ7bGKIm.net
トランスパイルというとTypeScript→JavaScriptみたいにシンタックスをほぼ保ったまま変換することを意図してる？
それともRustで書いたコードをトランスパイル先のランタイムなり処理系なりで動かせれば良い？
後者ならトランスパイル先言語でWASMランタイム用意すればRustで書いたコードは動かせるよね
73:デフォルトの名無しさん
23/09/02 14:30:38.26 mCX3wjBN.net
NimはCにトランスパイルされる
74:デフォルトの名無しさん
23/09/02 14:59:18.30 dPTTZbJb.net
コンパイルする話じゃなくトランスパイルする話をしてるのにその区別すらできないオジ
75:デフォルトの名無しさん
23/09/02 15:01:52.18 Ng1Dtdjk.net
一般にトランスパイルは同程度に高級な言語の間で
(なるべく)変換後の言語として自然な形で変換するものを言う。
コードジェネレータ、または実行エンジンとして他言語を
経由するものは含んだり含まなかったりするけど
表面上は同じことをやってるので境界が曖昧なんだよ。
76:デフォルトの名無しさん
23/09/02 16:08:00.76 LNeShMZN.net
境界があいまいだからRustコードからWASMバイナリを生成することをトランスパイルと呼んでもおかしくないと？
77:デフォルトの名無しさん
23/09/02 16:25:56.23 Ng1Dtdjk.net
>>75
そう呼んで欲しくはないが呼んでるかもしれないという想定で
すり合わせるプロセスは必要かもしれない。
78:デフォルトの名無しさん
23/09/02 16:37:50.73 aKZIxXWD.net
>>65 がトランスパイル先にまでOwnership/Borrow/Lifetimeあたりの機能あったほうが良さそうなこと匂わすトンチンカンなこと書いてるからだろ
79:デフォルトの名無しさん
23/09/02 17:46:31.63 3Onl8i9L.net
>>77
そんな頓珍漢な勘違いをするのはおまえだけだろw
80:デフォルトの名無しさん
23/09/02 18:52:34.01 l2r0UsPx.net
どうせ>>62も複おじなんだろうね
なぜRustからトランスパイルしようなどと思ったのか？
その動機が出ないならこの話は終わりです
81:デフォルトの名無しさん
23/09/02 19:16:20.22 v3EBZAej.net
>>62です。ぼんやりとした質問ですみませんでした
例えばRustが読めない人向けにPython等に変換してPython読める人ならなんとか読めるものに変換できないかなという想定でした。
あとはLLVM以外の環境で動かしたいとか。それなら確かにWASMで良かったみたいですね。
Rustは型が厳格とかデフォでimmutableだったりムーブだったり制約が強いイメージでしたが前提からして間違ってたみたいですね
皆さま事細かにありがとうございました
82:デフォルトの名無しさん
23/09/02 19:32:06.11 aKZIxXWD.net
だから言っただろうがよ
83:デフォルトの名無しさん
23/09/02 19:33:02.08 EvLWL1zC.net
これは違うな
疑って失礼しました
84:デフォルトの名無しさん
23/09/02 19:34:44.69 GzMi3EqG.net
>>67
お前が勘違いしてんだろガイジ
実行時に所有権やライフタイムは出てこないからこそトランスパイル先の言語にもこれらの機能が言語機能として備える必要がないわけでこのスレでお前だけが1人だけ勘違いしている
頭悪そう
85:デフォルトの名無しさん
23/09/02 19:51:23.24 Wl+8+V5g.net
おじ、キレた！！
86:デフォルトの名無しさん
23/09/02 20:07:34.22 x+ZOYO9b.net
複数ID全員おじとか糖質患者やろ
お前のたった1人だけの発言の方がすべておじに似つかわしいんやけど自覚できない？
87:デフォルトの名無しさん
23/09/02 20:45:16.67 f2x52juV.net
おじ使いはいつも病気
88:デフォルトの名無しさん
23/09/02 23:40:40.30 lMQqG2Zb.net
的外れなレス(>>63-64)からの
恥ずかしい壮大な勘違い(>>66)
そしてなぜかドヤる(>>81)
控えめに言って頭オカシイ
さすが複オジ
89:デフォルトの名無しさん
23/09/02 23:56:54.98 v0MnUUsV.net
オジオジ言ってる人は書き込みに中身がなくて全方位叩きだからスレ荒しが目的なのかな
反応せず無視するのがいいんだろうけど反応しちゃった失礼
90:デフォルトの名無しさん
23/09/03 00:03:56.01 cm8T2pY+.net
どうでもいいし面倒だしもうここ潰してﾜｯﾁｮｲありスレに一本化してほしいんだけど
91:デフォルトの名無しさん
23/09/03 00:09:50.96 HRiHoELW.net
「自演認定は頭おかしい」論法
「おじ連呼厨」の強調
いつものやつですね
自演認定糖質論法は久しぶりに聞いた気がする
92:デフォルトの名無しさん
23/09/03 00:16:07.67 HRiHoELW.net
ID:bvTG+KAn
ID:g76m2OPt
ID:f2x52juV
ID:GzMi3EqG
ID:x+ZOYO9b
ID:v0MnUUsV
93:デフォルトの名無しさん
23/09/03 00:20:28.54 cZTMAPOv.net
議論でバトルが盛り上がるのは歓迎
オジおじ連投がいる時は議論がなく荒れるだけでつまらん
94:デフォルトの名無しさん
23/09/03 00:35:38.11 HRiHoELW.net
歓迎するわけねーだろアホか
95:デフォルトの名無しさん
23/09/03 00:38:35.94 cCJ59BhE.net
まともな議論が成り立たない原因は複オジだからね
まともな議論ができそうなのはどう見ても>>65や>>68のほう
>>91にまとめられてるレスを書いてるようなやつが議論は歓迎とか笑わせるな
96:デフォルトの名無しさん
23/09/03 00:45:48.36 HRiHoELW.net
既視感の正体
ｽﾚﾘﾝｸ(tech板:745番)
ｽﾚﾘﾝｸ(tech板:468番)
97:デフォルトの名無しさん
23/09/03 00:53:25.84 roP/qgKi.net
>>61
亀レスだが特に理由がないならrusqliteで
今のところはこれがデファクト
98:デフォルトの名無しさん
23/09/03 01:20:25.77 YZAPuv0W.net
気に食わない意見があるけど反論できないで次々とおじさん認定して叩くだけのゲスがいるな
libsqlite3の上に構築したRusqliteでもいいが
Rustで構築したSQLxがSQLiteもサポートするようになり出来が良いので急上昇で逆転する見込み
99:デフォルトの名無しさん
23/09/03 01:41:47.18 mceEf04V.net
sqlxのsqliteドライバもlibsqlite3の上に構築されてるぞ
SQLiteはCのAPIしか提供してないんだから他のものを使う理由がない
100:デフォルトの名無しさん
23/09/03 07:28:12.23 x92ht6sx.net
また知ったかぶりして恥かいてるww
101:デフォルトの名無しさん
23/09/03 08:37:05.08 WZFIWsZX.net
sqlx以外はasync/await使えない？
102:デフォルトの名無しさん
23/09/03 13:35:31.95 mxOeoCcq.net
自分でspawn_blockingすればいい
103:デフォルトの名無しさん
23/09/03 13:45:08.16 yQjRA1Qa.net
安定感や性能に差があるのでsqlite限定ならFirefoxでも使ってるrusqliteがベター
104:デフォルトの名無しさん
23/09/03 13:48:17.25 jFAGdbdC.net
■購入目的（達成されました）
・Rustで動くプログラムの写経
・映像表現的な出力結果はモチベーションを維持できる気がした
・RustについてはWeb上に素晴らしいテキストがたくさんあるので簡単な実践的なプログラムを読みたい
■自分のレベル
私は数カ月前にRustを勉強し始めました。
これまで高校でc、Javaの基礎、大学でc++基礎、ObjectiveC、社会人になってPythonやc#と触れてきました。たくさん触れてきていますが結局自分が作りたい少し大きい物をプログラミングで何かを作りきるということをしてきませんでした。いつもチュートリアルで終わりです。永遠に世界に挨拶でもしてろと言われそうなタイプです。
ここ数年で映像制作から転職してインフラエンジニア関係に勤めています。
ネットワークやサーバ周りの知識に加えて一つ言語を修めたいと思いRustをはじめました。
105:デフォルトの名無しさん
23/09/03 23:37:22.86 IkMULQX5.net
>>101
spawn_blockingは別OSスレッドを立ててそこで実行するだけだから根本的な解決にならない
106:デフォルトの名無しさん
23/09/04 01:10:37.74 Ev35rGw5.net
>>104
別OSスレッドを立ててそこで実行する以外の解決方法はないよ
107:デフォルトの名無しさん
23/09/04 02:53:02.64 IXHvJiGY.net
君たちは何を問題と定義しているのか
108:デフォルトの名無しさん
23/09/04 06:58:20.37 HktKZ7k9.net
昔と違って今はFutureを返すcrateを選べるのだからそこで困ることはないな
糖衣のasync関数を含めてFutureさえ返してくれればいい
自分側はawaitもしくはspawnしてもいいしFutureUnorderedなどで早い者勝ち処理など自由な方針を取れるのだから
109:デフォルトの名無しさん
23/09/04 09:56:10.80 NSmwDj9w.net
>>107
そこで困るとは？
110:デフォルトの名無しさん
23/09/04 10:17:13.25 /ASAZOX6.net
困ってない人は一生気付かない
これが理想郷
111:デフォルトの名無しさん
23/09/04 13:01:49.77 9feyj9k/.net
いつものストローマンオジ
112:デフォルトの名無しさん
23/09/04 18:54:13.07 UIsGravq.net
困ったことが無い香具師には何で困るかわからんマジ
113:デフォルトの名無しさん
23/09/04 20:11:06.59 pWElWRNz.net
Futureもawaitして同期のみで困っていない人もいる
Futureすら使わず別スレッドにしちゃって困っていない人もいる
ただしベターな方法を知らないために困っていないだけかも知れない
理解した上で選んでいるなら問題ない
114:デフォルトの名無しさん
23/09/04 20:41:40.87 0aDTsPbB.net
>>112
同期APIを非同期で使う話だということを理解してね
何に困ってるのか知らんけど
115:デフォルトの名無しさん
23/09/04 20:57:24.92 IXHvJiGY.net
よく分からんが誰も困っていないらしいのでヨシ！
116:デフォルトの名無しさん
23/09/04 21:18:46.15 xwtgk4fq.net
>>114
俺は誰れが何に困っているのか分からん。 で、>>107は知っているみたいだが
>>100は
>sqlx以外はasync/await使えない？
だから、うん、使えない/いや、xxxも使えるのような回答で良いはずなのに
ITドカタ板に多い障碍者は妄想必死して、変なことを言い出すからな。
117:デフォルトの名無しさん
23/09/04 21:28:55.91 bE42d19a.net
>>113
最後の手段spawn_blocking()の話？
あれはスレッドを消費しちゃうから例えばクライアント接続が多数来てそれぞれが使うと詰むよ
全部を非同期APIに統一するのがよいね
118:デフォルトの名無しさん
23/09/04 21:58:02.43 dk25eEP4.net
そういう状況なら非同期とか言う前にsqliteやめよう複くん！
119:デフォルトの名無しさん
23/09/04 22:16:10.47 Ts5EvUDj.net
SQL関係ない一般的な話がされてると思ってたらSQLにこだわる人もいてよくわからんな
SQLにしてもサーバーに繋ぎにいくなら同期はありえんな
120:デフォルトの名無しさん
23/09/04 22:29:51.49 fWqFM9pZ.net
>>116
スレッド消費せずにSQLiteへの接続を同時にさばくことが出来ないからね
複オジおすすめのsqlxも当然接続ごとに別OSスレッド立ち上げてるからクライアント接続が多数来たら同じように詰むんだよ
121:デフォルトの名無しさん
23/09/04 22:47:23.47 rfWjSjrk.net
自分が何を知らないか
知ってる人もいれば
知らない人もいる
前者は詐欺師で
後者は複オジである
彼はみんなを騙しているのではなくて
彼はなんでも知っているつもりなのである
122:デフォルトの名無しさん
23/09/04 23:11:41.51 ueRfdgpS.net
RustのSQLデファクトスタンダードのsqlxに対して「複オジおすすめのsqlx」と書いてることから、
複オジ使いはRustを使っていない疑惑が再び出てきた。
123:デフォルトの名無しさん
23/09/04 23:53:13.41 IXHvJiGY.net
>>118の相似形
ｽﾚﾘﾝｸ(tech板:919番)
919: デフォルトの名無しさん sage 2022/05/09(月) 18:50:22.63 ID:rGYbsi5m
>>915<
124:/a> >>918 FizzBuzzは単なる話の出発点の例の一つに過ぎなくて既に皆はもっと一般的な話をしているようにみえる 皆もFizzBuzz限定の話なんかに興味はなくて一般的な話に興味があるからではないかな
125:デフォルトの名無しさん
23/09/04 23:54:19.18 8cZoZvfB.net
またオジが妄想に取り憑かれてるねww
126:デフォルトの名無しさん
23/09/04 23:56:14.30 IXHvJiGY.net
質問者のユースケースが非同期ライブラリを必要としているのか？
そうした前提を確認せずに、非同期対応の一点でライブラリの適・不適を評価しようとすること自体が筋違いなのです
127:デフォルトの名無しさん
23/09/05 00:09:09.34 XN2NC5/h.net
質問者>>100は
>sqlx以外はasync/await使えない？
だから、非同期が前提ではないかい
128:デフォルトの名無しさん
23/09/05 00:23:36.51 XDjugVOt.net
>>125
そっちじゃなくて>>61のこと
URLﾘﾝｸ(github.com)
なるほどワーカースレッド立てて通信してるだけで別に非同期ファイルI/Oを最大限活用するとかじゃないんだね
確かにこれなら>>119の言う通りブロッキング待ちするものをspawn_blockingしても大した差はなさそうだ
129:デフォルトの名無しさん
23/09/05 04:37:15.62 Zsmh0CoR.net
>>117
これこれ
130:デフォルトの名無しさん
23/09/05 05:16:32.99 Rvonn+YZ.net
>>101
各spawn_blocking()毎に専用のネイティブスレッドをブロックする形で用いるため
spawn_blockingが同時に大量に発生しないよう留意しなければならない
そのため同期ライブラリの利用方法には何らかの制限がついてしまう
非同期ライブラリを利用すればそのような制限はない
131:デフォルトの名無しさん
23/09/05 12:58:37.11 V9mIkqYx.net
sqlx crateでMySQLを使っているがクライアント接続が多数来ても捌けてる
すべて非同期なのでブロックされることも別スレッドで実行されることもない
132:デフォルトの名無しさん
23/09/05 14:15:52.81 SlAKktdo.net
node.js推しだった人か
133:デフォルトの名無しさん
23/09/05 14:17:29.93 6qNvCW8J.net
redis-rsよりも良いの？
134:デフォルトの名無しさん
23/09/05 14:29:07.14 bhQzjDZU.net
>>129
そりゃMySQL自体が非同期APIを提供してるからね
同期APIしか提供してないSQLiteとは全く事情が違うんだよ
135:デフォルトの名無しさん
23/09/05 19:14:25.74 dmqj3xko.net
かつてデファクトスタンダードだったdiesel crateがsqlx crateにその座を奪われた原因もdieselが非同期APIに対応できなかったせい
136:デフォルトの名無しさん
23/09/05 21:03:20.66 x/2k1tVz.net
それもあると思うがたしかディーゼルってActiveRecordの開発者が設計してるんだよね
137:デフォルトの名無しさん
23/09/06 08:23:13.48 KSPgDJdv.net
sqlxのほうがシンプルで使いやすくわかりやすい
138:デフォルトの名無しさん
23/09/06 10:25:26.54 UTcPybKQ.net
>>134
ということはライセンスで敬遠されたのか？
ここにもOSS問題が
139:デフォルトの名無しさん
23/09/06 12:30:09.29 12hS6FX4.net
>>136
いいかげんコテハン付けろよ。
140:デフォルトの名無しさん
23/09/06 18:07:43.20 bKG9yIlg.net
>>136
Apache2.0とMITのデュアル�
141:宴Cセンスに何の問題が？
142:デフォルトの名無しさん
23/09/07 13:34:15.26 bUyh+PaU.net
GUI作りたいけどよくわからん
今のデファクトはなんや
143:デフォルトの名無しさん
23/09/07 14:34:25.76 BcSMP50e.net
デファクト決定戦レスバしかしてねーなこのスレ
144:デフォルトの名無しさん
23/09/07 15:38:29.71 kMvLzM04.net
デファクトと言える目安は Recent Downloadsで同カテゴリ2位以下と3倍以上差がついてるかどうか
145:デフォルトの名無しさん
23/09/07 21:32:40.12 pU5U2pan.net
GUIはデファクト無いと思う。要件で選ぶしかないわ。
146:デフォルトの名無しさん
23/09/07 21:35:22.15 I+OYue/W.net
RustならTUIが標準でしょ
147:デフォルトの名無しさん
23/09/07 23:41:05.43 7NPDh5XT.net
マウスでポチポチしたいんじゃ
148:デフォルトの名無しさん
23/09/08 00:00:03.39 hm00xw28.net
Rust製のGUIフレームワークあれば良いんだろうが
現状はQtやらgtkのような他所製のエンジン(GUIツールキット)を利用するためのクレートを使うって感じだろ？
自分が分かる・使ったことがあるGUIツールキットをRustを介して使えになるんじゃないのか。
149:デフォルトの名無しさん
23/09/08 00:06:21.68 DPQbgsiL.net
GUI に関しては OS (ディストリビューション) が提供するもの (をラップしたもの) を
避けるわけにいかないから「Rust 製」にこだわれないんだよね。
150:デフォルトの名無しさん
23/09/08 00:13:42.42 TT5R0qcn.net
OSのコンポーネント使うことにこだわらないならeguiでよいのでは
151:デフォルトの名無しさん
23/09/08 00:23:14.31 DPQbgsiL.net
egui は名前がエグい
152:デフォルトの名無しさん
23/09/08 00:25:14.57 3wUsERty.net
GUIは各言語に関係なく様々なレイヤーや様々なカバー範囲などあってRust以外の言語でも多数の選択肢があり要件により変わる
Rustのクレートでも同様であり極端なものだと例えばx11-dlクレートも該当すればtauriクレートも該当して自分はどちらも別用途でそれぞれ使用している
153:デフォルトの名無しさん
23/09/08 00:29:58.49 E3X/Jdig.net
X11ならマルチプラットフォームでもRust製で作れるな
154:デフォルトの名無しさん
23/09/08 01:30:03.20 EHbxHCsV.net
フリーランスエンジニアになってからの年収推移を公開【現在年収1000万】
【実体験】仕事ができない新卒エンジニアでも月収７０万フリーランスになれる理由
フリーランスエンジニアは年収900万円までは余裕！現役フリーランスエンジニアが徹底解説
フリーエンジニアの平均年収！未経験が年収1000万円を超える方法とは？
月額150万円以上も可能？ITフリーランスで高単価を獲得できる理由
在宅で年収１０００万稼ぐフリーランスエンジニアの稼ぎ方【再現できる】
フリーランスのエンジニアやるなら45歳までに貯金5000万円作れないと死ぬ説
155:デフォルトの名無しさん
23/09/08 06:05:02.97 1e7fFDSb.net
>>144
今どきのTUIはマウスでポチポチできるようになってるぞ
156:デフォルトの名無しさん
23/09/08 07:42:03.69 L1913KOe.net
管理画面はウェブベースにしておけ
157:デフォルトの名無しさん
23/09/08 08:41:49.30 07e9DMWQ.net
どういうこと(´・ω・`)？
158:デフォルトの名無しさん
23/09/08 09:16:05.39 3pBwkm6o.net
田売りなのかなって気もするけど覚えること多そうだな…
159:デフォルトの名無しさん
23/09/08 12:46:27.44 Qwh1dPVP.net
Streamlit の Rust 版ってあるのかな
160:デフォルトの名無しさん
23/09/08 14:11:22.78 E3X/Jdig.net
>>152
マジかよ
２１世紀ってすげーな
161:デフォルトの名無しさん
23/09/08 17:46:35.04 DPQbgsiL.net
ターミナルがマウスイベント送信できるようになってるやつならね。(まあモダンなのはだいたい出来ると思うが)
162:デフォルトの名無しさん
23/09/08 18:56:17.34 LCrxvNjx.net
Tauriでいいじゃん
163:デフォルトの名無しさん
23/09/08 19:04:26.66 TT5R0qcn.net
sixel使ってターミナルGUIアプリケーションとかできないのかね
164:デフォルトの名無しさん
23/09/09 00:48:43.38 uwI0AfpW.net
tauri執拗にすすめるやつなんなの？病気？
165:デフォルトの名無しさん
23/09/09 01:42:23.33 UR7WoOUT.net
スレに２回しか出てないのに執拗とは
166:デフォルトの名無しさん
23/09/09 01:55:37.10 nFkP/7o8.net
荒れるから、田売りの話は禁止にしよう
167:デフォルトの名無しさん
23/09/09 02:24:44.28 i5s7UXai.net
「Electronよりなんか良いっぽい」以外の利点が知られていないTauriさん
168:デフォルトの名無しさん
23/09/09 08:43:17.99 jpDXx+st.net
yarnだのcargoだのどいつもこいつもなんでオレオレパッケージマネージャ使いたがるの😭
169:デフォルトの名無しさん
23/09/09 09:07:53.17 cXOKMQb6.net
VSCodeなど(当時はTauriはなく)Electronで書かれたソフトが多いようにElectronとTauriは共通してメリットが多い
さらにWebアプリ化もしくはその逆も比較的容易
ただしどちらもHTML/CSS/(JavaScrpt)のWeb知識が必要なのでこれを持たない者だけが批判しがち
170:デフォルトの名無しさん
23/09/09 09:14:21.06 Vd67mKNx.net
オレオレじゃないパッケージマネージャというと？OS依存するものしか思いつかないが
171:デフォルトの名無しさん
23/09/09 11:00:13.25 Ig5iuvnc.net
html の設計がいびつなんだよね……。
xhtml まではドキュメント記述言語としてタグのセマンティクスを重視した設計だったのが
html5 から living standard の流れで html はウェブアプリケーション基盤だとする派閥が圧勝した。
そこからの流れで外観を記述する言語としての活用が広まっている状況があるのは事実だし、
もうこの流れに逆らえないのも事実だと思うが
html はやっぱり GUI 記述言語としては不格好な存在だよ。
172:デフォルトの名無しさん
23/09/09 11:33:35.06 IggX53ET.net
ハッピープライスパラダイス
ハイパーテキストマークアップランゲージ
あくまでもテキスト用言語だからなぁ
173:デフォルトの名無しさん
23/09/09 13:03:51.75 qxfK5/Yz.net
HTML+JSが嫌なら全部canvas+wasmでやればええねん
アクセシビリティとかは考慮しないものとする
174:デフォルトの名無しさん
23/09/09 14:51:58.44 Ig5iuvnc.net
屋上屋を重ねるという慣用句はこういうときにつかうのかな。
175:デフォルトの名無しさん
23/09/09 15:09:29.22 Ig5iuvnc.net
>>165
C/C++ は実行環境の管理と開発環境の管理を分けないスタイル(ライブラリもディストリビューションのパッケージマネージャーで管理する)でやってたし、分離するにしても chroot (今ならdockerでもよいかも)とかで出来てたからそれ以上には発展しなかった。
でも本来は別物ということにするほうが自然だと思う。
言語をまたいだ開発をするプロジェクトがややこしくなるがそれは本来的にややこしいものだからしょうがない。
176:デフォルトの名無しさん
23/09/09 16:01:57.25 sGUJTy2x.net
>>172
いつの話？無理やり停滞感を擦り付けている???
発展して_____+_____がデファクトスタンダード
それで不足なら_____サーバー
毎回ビルドに6時間とか待たなくて良いように発展した手法がほぼ統一された
Rustもビルド時間の件で大揉めしたじゃん、何も解決しなかったけど
(空気読んで情報は伏せた)
177:デフォルトの名無しさん
23/09/09 16:45:26.09 Ig5iuvnc.net
>>173
過去形で書いてるよ。
今は違うと強調したつもりの表現なんだけど…
178:…
179:デフォルトの名無しさん
23/09/09 18:12:41.11 hWR6yEQh.net
>>174
>今は違うと強調した
本気で言っているのなら
ちょっと心配になるレベルのコミュ□だぞ
か、またはネット□□師か？
あと後出し皮肉オジは煽りオジと同化しているからやめろ
Rustで煽りオジはサイコパス確定した
ｽﾚﾘﾝｸ(tech板:93番)
>軽く煽った後は、本業に戻る、だよ 急がないし
180:デフォルトの名無しさん
23/09/09 19:36:26.65 pYp2eZcM.net
オジ連呼厨は他人に絡み過ぎ
このプログラム板では人でなくプログラムや技術に目を向けろ
>>165
cargoはrustcとハードリンク一体化してるようにRust用かつ公式
yarnとnpmで分裂しているのとは異なり一体化してくれていてありがたい
181:デフォルトの名無しさん
23/09/09 19:51:44.43 qxfK5/Yz.net
>>165
大統一パッケージマネージャ作ってくれ
182:デフォルトの名無しさん
23/09/09 20:39:12.68 Rk1XYFyW.net
debとかrpmとか
183:デフォルトの名無しさん
23/09/09 21:06:18.16 IggX53ET.net
>>178
aptで良いと思う
184:デフォルトの名無しさん
23/09/09 21:31:02.60 1qPxYBdj.net
>>175
後出し皮肉オジは、コテハン出してた頃の複オジそのものに見えます
質問して答える自作自演も
185:デフォルトの名無しさん
23/09/09 21:33:52.69 Rk1XYFyW.net
>>179
aptはdebパッケージの管理ツール
186:デフォルトの名無しさん
23/09/09 22:07:42.11 qxfK5/Yz.net
>>178
依存crateをいちいちapt-getしてくるのさすがに大変すぎないか？
187:デフォルトの名無しさん
23/09/10 10:57:43.69 yM7j2B0I.net
>>165
antも廃れたな
188:デフォルトの名無しさん
23/09/10 13:28:10.69 NvPhT1QM.net
>>183
パッケージマネージャの側面はmavenからでantにはivyで逆輸入された。
antは廃れるべくして廃れたな。
189:デフォルトの名無しさん
23/09/10 14:52:06.76 9TiyMpcM.net
mavenとかまだ使ってるとこあるの？
普通はgladleだよね？
未だにmavenだとしたらちょっとそこはヤバいと思う。
190:デフォルトの名無しさん
23/09/10 15:10:16.28 yM7j2B0I.net
今でも使ってるなんて誰も言ってないのでは
191:デフォルトの名無しさん
23/09/10 15:36:29.89 NvPhT1QM.net
いや、未だにmavenって認識が間違ってるよ。
定型的な開発サイクルであればmavenで十分だしそこで明確なツラミもないのにgradleに移行しようって判断するようなチームはヤバい。
とはいえ今だと初手でgradle選択するチームが多いだろうね。
192:デフォルトの名無しさん
23/09/10 16:18:37.72 yM7j2B0I.net
自分で質問して自分で答えるタイプの人でしたか
193:デフォルトの名無しさん
23/09/10 17:15:47.84 DnwEEEwp.net
みんなjavaに詳しいのね
194:デフォルトの名無しさん
23/09/11 00:02:48.34 RxCGMczZ.net
ビルドのためにグルービーとかいう言語を使わなければいけないことに異常性を感じないのかjavaの人たち
195:デフォルトの名無しさん
23/09/11 00:13:23.96 aoFlyd5o.net
MakefileやCMakeも大概だしビルドは魔境
196:デフォルトの名無しさん
23/09/11 00:18:19.95 /EmpjAru.net
Groovy は、Rubyist なら分かる。ほぼ同じ
197:デフォルトの名無しさん
23/09/11 00:23:10.62 ul9tFljX.net
>>190
今のgradleはgroovyじやなくてkotlinで書けるよ
198:デフォルトの名無しさん
23/09/11 09:54:06.45 lXcI/Ajd.net
もう maven も gradle も java も使ってないから安心汁
199:デフォルトの名無しさん
23/09/11 17:56:49.57 gmM4YyOK.net
>>190
世の中にはビルドとかCI/CDの定義ファイルがYAMLだからって、それ拡張してif else の制御構造組み込んでるところもあるんやで。
200:デフォルトの名無しさん
23/09/11 21:37:45.75 +I//Qqk+.net
>>195
antやん
201:デフォルトの名無しさん
23/09/13 22:09:57.35 JQEDxoJN.net
CNCF系はya
202:ml好きだからね それはさておき、言語固有のリポジトリマネージャはOSとは独立じゃないとディストリビュータもライブラリ管理者も辛いという必要性があって生み出されたもの 今後もなくなる事は無いでしょう。CPANあたりが元祖ですかね
203:デフォルトの名無しさん
23/09/13 23:41:57.05 ljzzNVbD.net
tomlがEBCDICで描かれてたら絶望しかない
204:デフォルトの名無しさん
23/09/14 10:03:14.07 CfWv79JE.net
さすがにcpanなんかもう使われてないよ
205:デフォルトの名無しさん
23/09/14 10:31:50.25 JeXpXyyi.net
tomlとRustって直接関係あるの？
単に採用が多いってだけ？
206:デフォルトの名無しさん
23/09/14 10:45:04.55 hWZaPMNq.net
明確に関係を規定しているわけではないが
開発ツールチェインで採用している以上は馴染みやすいし、
習慣的に toml が普通という感じ
207:デフォルトの名無しさん
23/09/14 18:18:10.36 uElhXa+m.net
JetBrains から RustRover 出たね。まだプレビュー版だけど。その代わり無料だ。
208:デフォルトの名無しさん
23/09/14 18:20:11.06 uElhXa+m.net
ぜひとも IntelliJ IDEA のように無料のcommunity版も出して欲しい。
209:デフォルトの名無しさん
23/09/15 11:42:38.55 FLL155po.net
的を射ている
URLﾘﾝｸ(wolfbash.hateblo.jp)
210:デフォルトの名無しさん
23/09/15 12:00:21.56 FSCF79pL.net
めちゃペラいな
初めて3日くらいの感想ぽい
211:デフォルトの名無しさん
23/09/15 12:00:26.41 LQyUZKSg.net
しょーもな...
212:デフォルトの名無しさん
23/09/15 12:03:53.15 xQfsfFQS.net
しっかりやってる人の意見
URLﾘﾝｸ(kerkour.com)
Goと比較した場合のRust一番大きいメリットはエラー処理やバグ検知だけどasyncのデメリットが大きいのも確か
213:デフォルトの名無しさん
23/09/15 12:13:34.28 LoLA89os.net
むしろNimのネガキャンにしかなってないって話題になってた記憶が
214:デフォルトの名無しさん
23/09/15 12:13:50.38 +YuTSIf8.net
>>205
Rustの一番の課題が絶壁の学習曲線なんだから、３日目の感想は重要だろ。
それを無視するならHaskell化待ったなしだな。
215:デフォルトの名無しさん
23/09/15 12:52:21.36 FLL155po.net
情報密度が違っててワロス
URLﾘﾝｸ(www.ossnews.jp)
216:デフォルトの名無しさん
23/09/15 12:58:36.85 FqVl8L26.net
>>207
むしろasyncが容易かつ効率的なことがRustの利点だよ
そして軽い非同期タスクを大量にマルチスレッド上でいわゆるM:Nスケジューリングできるのは、
RustとGoしかないためその両者の比較になるのはその通りだが出来る範囲はRustが広くきめ細かい
もちろん非同期以外の言語仕様も同様でGoは貧弱すぎる
217:デフォルトの名無しさん
23/09/15 13:33:46.47 yoJlOour.net
Go は貧弱だが Go くらいで十分な範囲をカバーできるだろ……という割り切りで設計されているように見える。
218:デフォルトの名無しさん
23/09/15 14:58:25.08 3ICKgtSW.net
Goは構文が簡素なのは割り切りとしていいと思うんだけど
参照周りの扱いとかCの頃から進歩してなくて
「こんなこと今どき人間が気をつけて書くの？」という気持ちにはなる
219:デフォルトの名無しさん
23/09/15 16:57:51.41 fC9P09S6.net
>>210
こういう役に立たない一般論に比べれば>>204のような薄っぺらい個人の感想のほうが実践知なのでまだ価値がある
220:デフォルトの名無しさん
23/09/15 19:05:24.10 BkBNFquN.net
>>210
スマホからは何も見えない……
なんかあるの？
221:デフォルトの名無しさん
23/09/15 19:11:49.50 wdMffZ4Q.net
>>215
RustとNimを比較してるサイト
222:デフォルトの名無しさん
23/09/15 20:05:41.52 pQw5TxEC.net
Goは構文簡素にしてても内部のGCとかは複雑にしてるイメージ。
223:デフォルトの名無しさん
23/09/15 20:39:40.02 zdZpv9AJ.net
>>214
どちらのページも意味のある情報がなにもない
くだらない揚げ足取り
>>215
PCからしか内容が見えないダメサイト
内容に意味はないため見る必要ない
224:デフォルトの名無しさん
23/09/15 22:34:16.16 qrlNPDKn.net
そのRust批判を書いてる人もそうだが
意味のあるプログラミング経験の少ない人はmutを毛嫌いしてるよな
言語に関係なくミュータブルか否かの区別がある方が好ましく
ミュータブルの使用は必要最小限が好ましい
という当たり前のことに沿う仕様なのに理解できなくて批判
225:デフォルトの名無しさん
23/09/15 23:11:51.65 UUFGnjcv.net
>>219
ミュータブルか否かの区別があるのは煩雑になるだけで好ましくない。WindowsやLinuxのソースコードに
Rustが採用されたと言ってもごく一部でメモリ安全性が特に重視される部分だけ。全部をRustで書くなんて
煩雑な作業には人間はとても耐えられない。
226:デフォルトの名無しさん
23/09/15 23:17:03.67 /YAD597I.net
>>219
>ミュータブルか否かの区別がある方が好ましく
当たり前では
mojo調べでlet/var区別が好ましいと決着ついた
URLﾘﾝｸ(docs.modular.com)
rust mutが好まれてないだけ
>>220
let/varだと区別がありつつ煩雑じゃない、という事ですね
227:デフォルトの名無しさん
23/09/15 23:24:01.30 /YAD597I.net
それと
>>220
Linuxカーネル本体は当分Cのままで
デバイスドライバをrustで書く準備が出来た、だけですよ
228:デフォルトの名無しさん
23/09/15 23:26:04.83 6F2DK256.net
>>220
mutableとimmutableの区別は必須
それを煩雑という者は初心者のみ
>>221
色んなプログラミング言語をやってきてる者にとってそんな些細な記述方法を問題にするやつはいない
参照のある言語でmutableを区別するならばmut付加方式が合理的
例) let mut x: &mut Type = ...
229:デフォルトの名無しさん
23/09/15 23:28:27.24 /YAD597I.net
あと前スレで出ていた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
230:デフォルトの名無しさん
23/09/15 23:30:46.42 Mq8zEA1a.net
letの後に識別子しか書けないならlet/varでいいんじゃね
パターンが書けるならlet/varよりlet/let mutの方が合理的な気がする
231:デフォルトの名無しさん
23/09/15 23:31:04.61 ksZUfg69.net
ここはRustのスレ
的外れなRust叩きをしているバカはアンチスレへ移動しろ
232:デフォルトの名無しさん
23/09/15 23:35:09.11 /YAD597I.net
sudo-rsも v0.2.0でstableと言い切って知らないdistributionに
ねじ込んだようですがその後どうなるのか要チェックです
233:デフォルトの名無しさん
23/09/15 23:43:02.23 4Db3FasG.net
mojoの所有権周りの構文ってRustより重い感じなんだな
これPython書きたいような人に受け入れられるんだろうか…
234:デフォルトの名無しさん
23/09/15 23:44:55.11 /YAD597I.net
>>225
>パターンが書けるならlet/varよりlet/let mutの方が合理的な気がする
気がする、ではなく
合理的だという説明が聞きたい
235:デフォルトの名無しさん
23/09/15 23:47:42.54 cnhK/Rr/.net
>>221
たとえばRustでよくあるこういうパターンはmojoでどうするんだろう
let (tx, mut rx) = channel(100);
そもそも可変参照はどう区別するんだろうね
あと関数の引数変数のmutable性はどうやって表すんだろう
Rustのmutを添える方式が自由度が高くてわかりやすいよね
236:デフォルトの名無しさん
23/09/15 23:48:06.93 /YAD597I.net
>>228
どの辺りが重い感じ？
237:デフォルトの名無しさん
23/09/15 23:52:51.61 4Db3FasG.net
>>231
borrowed, inout, owenedって全部キーワード指定だし結構長くない？
自分はRustみたいに明示的なのが好きだから多少長くてもいいけど
Python好きな人だとどうなんだろうって
238:デフォルトの名無しさん
23/09/15 23:54:33.01 Mq8zEA1a.net
パターンマッチの場合束縛する変数が複数になり得るので、それぞれの変数に対して異なるmutabilityを宣言できる
あと、Rustは変数への束縛にmove/refの区別もあることも関係してるかもね
letやvarのように別構文を用意するなら、それぞれに対してmove版、ref版が必要になってしまう
239:デフォルトの名無しさん
23/09/15 23:59:25.63 cnhK/Rr/.net
let (foo, ref mut bar) = とかよく使うもんね
mutやrefが分離キーワードになっているRustが便利
240:デフォルトの名無しさん
23/09/15 23:59:43.71 /YAD597I.net
>>230
なるほどね
mojoでunpackがどうなるのか知らないけど
unpack用のlet/varシンタックスはあった方が良いね
let/var方式の他の言語を参考にするんだろうな
241:デフォルトの名無しさん
23/09/16 00:02:44.62 A/Og/XEu.net
>>234
>mutやrefが分離キーワードになっているRustが便利
これを突き詰めるとponyになるって5chで聞いたよw
242:デフォルトの名無しさん
23/09/16 00:03:10.36 e71CP5Wp.net
>>234
いや、今となってはrefはほとんど使わん
243:デフォルトの名無しさん
23/09/16 00:26:11.63 h6vfr2ug.net
TauriとTauri Mobileが別々の実装として統合されないの悪手だと思うんだがな
せっかくRustでロジック書けてネイティブ呼び出しまで簡単で手頃なフロントエンド実装で期待してたのにわざわざコミュニティ分断する必要あるんか？
なんかXamarinみたいな結末迎えそうで残念だわ
244:デフォルトの名無しさん
23/09/16 09:10:27.83 FQ6fYHli.net
T,o,k（迷惑という方は←をあぼーんしてください。）
更に家族に教えて加えて￥4000×人数をGET。
URLﾘﾝｸ(i.imgur.com)
245:デフォルトの名無しさん
23/09/16 09:55:59.18 ZJLR+eYH.net
>>238
無理に一つにしようとすると条件分岐増えてごちゃごちゃしてわかりにくくなる、というのはありそう。知らんけど。
246:デフォルトの名無しさん
23/09/16 10:40:22.96 FZJflFW6.net
>>239
もう現金化してアンインスコしてる
247:デフォルトの名無しさん
23/09/16 11:27:20.46 8u+hT5wA.net
RustRoverを試してみる
URLﾘﾝｸ(zenn.dev)
248:デフォルトの名無しさん
23/09/16 11:55:36.71 jG7brSLe.net
ウェブ系の奴らがやけにJetBrains推してくるけどAndroid Studio使ったら如何にゴミIDEなのかよくわかった
しかも個人使用でも買い切り数百ドルもしたのに今はサブスク月額1300円とかぼったくりもいいところ
VSCodeがあって本当によかったVSもCEならデバッガに制限あるけど無料だしこれほどMSに感謝したことはないね
249:デフォルトの名無しさん
23/09/16 12:20:19.81 E7jGhtqP.net
mut よりもShared XOR Mutableの方が難しいだろ。
250:デフォルトの名無しさん
23/09/16 12:41:23.41 8u+hT5wA.net
>>243
Android Studio は IntelliJ IDEA がベースになっていて無料の community 版があるが?
ていうか Android Studio の方は最初から無料じゃなかったか? 金取るやつあるの?
251:デフォルトの名無しさん
23/09/16 12:57:41.63 RATZO/gi.net
>>223
let x: &mut Type = ...
でよくね？
252:デフォルトの名無しさん
23/09/16 13:00:07.59 XaZSJ/up.net
>>244
lifetimeが難しいというのも大体がshared xor mutableの話だしな
253:デフォルトの名無しさん
23/09/16 13:07:54.84 2emM+tnC.net
>>246
それだとimmutableとなり変数値を書き換えできないから根本から違う
254:デフォルトの名無しさん
23/09/16 13:23:53.43 RATZO/gi.net
描き替え出来るから問題無い
255:デフォルトの名無しさん
23/09/16 13:57:40.01 2emM+tnC.net
>>249
ポインタ値の書き換えと
ポインタが指す先の書き換えの
区別がついていないのはCでも初心者レベル
256:デフォルトの名無しさん
23/09/16 14:05:34.65 RATZO/gi.net
うん
だから付ける必要無い所まで描く必要無いよね
257:デフォルトの名無しさん
23/09/16 14:06:34.42 XaZSJ/up.net
refとmoveの区別がある言語とそうでない言語の構文比較しても仕方なかろう
258:デフォルトの名無しさん
23/09/16 14:10:34.38 nUKpqsu7.net
>>246
ダメです
全く異なります
let mut x: &mut Type = ... ←xの値を書き換えられる
let x: &mut Type = ... ←xの値を書き換えられない
259:デフォルトの名無しさん
23/09/16 14:24:43.82 RATZO/gi.net
>>253
だから付ける必要無い所まで描く必要無いよね
260:デフォルトの名無しさん
23/09/16 14:32:47.40 F5t5l7vC.net
>>239
絶対に試すべきだね。
261:デフォルトの名無しさん
23/09/16 14:37:19.47 nUKpqsu7.net
>>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を欠くことはできません
262:デフォルトの名無しさん
23/09/16 14:43:13.66 BFCePFCu.net
ほんまジャップはアホやな
しょーもない重箱の隅をつつきあって知識自慢のマウント合戦
そして出来上がった成果物は誰も使わないクソゴミ
ジャップがオナニーしてる間にソフトウェアは中国に30年遅れているという現実
お前ら見てるとマジで日本人がソフトウェアで土人の未開レベルな理由がよーくわかる
263:デフォルトの名無しさん
23/09/16 17:08:24.37 DWW8ClN4.net
まともなプログラミング言語ならばそれら四つの区別がある
例えば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を付けるかの些細な違いにすぎない
264:デフォルトの名無しさん
23/09/16 17:14:29.95 AP//fjNl.net
参照の可変性という概念を持つ言語がそもそも少ない
265:デフォルトの名無しさん
23/09/16 17:15:13.87 AP//fjNl.net
概念が異なるのに構文の話だけをしても仕方ない
266:デフォルトの名無しさん
23/09/16 17:34:04.75 nlb2ovML.net
参照先の値がread onlyかwritableかはプログラミングで極めて重要だよね
間違えて意図せず書き換えてしまっていたバグなどの減少にも繋がるから必要な機能じゃないかな
267:デフォルトの名無しさん
23/09/16 17:37:07.29 sqsrY/cP.net
>>258
2番目と4番目はRustだとsmellyなのでリファクタリング検討候�
268:�
269:デフォルトの名無しさん
23/09/16 19:41:48.63 OLEDwioO.net
>>204が言ってるのはmutの区別が不要じゃなくて
良く使うmutable側でタイプさせんなってことでしょ
270:デフォルトの名無しさん
23/09/16 20:04:56.12 DWW8ClN4.net
ほとんどのプログラムではmutと記述すべきところが少ない
もしmutが多いならレアケースを除いてコードを改善すべき可能性が高い
271:デフォルトの名無しさん
23/09/16 20:10:22.45 TlXhcaWs.net
>>263
＞良く使うmutable側でタイプさせんなってことでしょ
お前、それプログラミングのセンス無いわ。
あ、もしかして使い捨てのコードしか書いたこと無い？
272:デフォルトの名無しさん
23/09/16 20:12:22.58 b0KnMHZf.net
>>263
慣れてきたらmutあんま使わなくて書けるようになるよｗ
関数型言語やってるとmut相当のもんなんて基本使わんのだし
273:デフォルトの名無しさん
23/09/16 20:31:44.89 /CtnFWfv.net
>>266
その代償としてイミュータブルをコピーしまくってメモリ浪費して関数型言語遅いじゃん
mut祭りで読みづらい代わりに高速でメモリ効率が良いのがRustの売りでしょ
274:デフォルトの名無しさん
23/09/16 20:37:59.24 EG7NJZsJ.net
多い少ないの話したいなら定量的な根拠持ってきてくれ
根拠ないなら断言するのはやめて
275:デフォルトの名無しさん
23/09/16 20:45:23.05 DWW8ClN4.net
>>267
それは関係ない
まずRustのほとんどのプログラムでmut祭りになることはなくmutの出現は少ない
その上でRustはCとほぼ同じ程度速い
276:デフォルトの名無しさん
23/09/16 20:50:47.30 bcC3Efve.net
どちらがより目立つべきかを考えたら
mutable なほうが目立つべきだし
目立って欲しい方に指定をつける文法が自然だ。
良く使うほうが短く書けるべきという視点だって
もちろん間違いではないし、評価軸は無数にある。
定量化したところでそれぞれの重みをどう捉えるかは
感性の問題だろ。
277:デフォルトの名無しさん
23/09/17 12:16:37.26 ju6VviWZ.net
>>211
Goでできない非同期処理って何？
channelとselectとgoroutineとsyncパッケージでなんでもできるけど
278:デフォルトの名無しさん
23/09/17 13:48:53.24 4koi4/xu.net
>>271
例えばベアメタル環境での非同期とか？
まぁ大抵の環境でだいたい上手く行くってのがGoのいいところだから
別に悪くはないと思うけど
279:デフォルトの名無しさん
23/09/17 17:36:59.55 FEktRC8x.net
毎日ちょっとずつ課題でてそれを解いていくようなRust勉強サイトってないの？
ナンプレ毎日１問クリアしていく感じなやつ
280:デフォルトの名無しさん
23/09/18 01:48:58.76 u21D7vuy.net
>>273
exercism.org どうかな
281:デフォルトの名無しさん
23/09/18 10:51:29.83 +ud3D/1q.net
>>267
>その代償としてイミュータブルをコピーしまくってメモリ浪費して関数型言語遅いじゃん
Rustのことなら#[derive(Copy)]とか.clone()とか描いちゃだめだよ絶対
282:デフォルトの名無しさん
23/09/18 12:04:31.40 X+wkGtcX.net
>>267
エイリアス解析がやりやすくなって本質的に同じものなのか
複製が必須なのか自動で判断して最適化される。
プログラマが判断するよりたぶん賢い。
mut を付けるかどうかは性能じゃなくてロジック的な妥当さで決めるもんだよ。
283:デフォルトの名無しさん
23/09/18 12:15:08.64 eKGbn4o/.net
techempowerベンチ見るとrustと比較してgoがしょぼいけど
こんなものなの?
284:デフォルトの名無しさん
23/09/18 12:28:49.50 X+wkGtcX.net
つよつよプログラマがチューニングすれば際限なく性能を挙げられるという意味での性能の良さと
非プログラマがテキトーに書いても及第点程度の性能が出るというのは言語として両立しにくい。
仮にしょぼいのが本当だとしてもトレードオフになる何かがあったりするから
総合的な使用感は実際に使ってみないとよくわからん。
285:デフォルトの名無しさん
23/09/18 12:39:00.83 b4Z9xD4H.net
>>277
GoはGC内蔵言語だから本質的に遅い
GC内蔵言語はGCするから遅いわけではなくGCのためにヒープメインにならざるをえないため遅い
286:デフォルトの名無しさん
23/09/18 12:44:14.37 AWdb6cD0.net
なんでもイミュータブルじゃなくて必要な時にミュータブルにしつつ安全性をコンパイラが保証してくれるのがいいんだよなぁ。
287:デフォルトの名無しさん
23/09/18 13:13:11.65 eKGbn4o/.net
そもそも、goはc#にすら負けてね?
1番高速じゃなくても2番目あたりでいいかなと思ってるんだけど
どれがいいのかなと
ななやむぐらいならわかりやすい1番にしとけばいいのか?
288:デフォルトの名無しさん
23/09/18 13:16:25.44 eKGbn4o/.net
goのgc調べてみましたが参照カウントとかじゃないのか
289:デフォルトの名無しさん
23/09/18 13:54:07.10 1tuWbz8L.net
Rustは見た目が汚いのが困る
もういっそCの方がきれいで安全で保守性が高いまである
290:デフォルトの名無しさん
23/09/18 14:01:16.96 6k3cBrAf.net
Cは大きなプロジェクトが汚すぎる
モジュールで名前空間分けられないから
291:デフォルトの名無しさん
23/09/18 14:04:02.95 DByXMqbY.net
C言語は"安全装置のない銃"に徹しているからな
シンプルなだけに危険いっぱいだ
292:デフォルトの名無しさん
23/09/18 14:43:26.49 EhgpbTsZ.net
C#はunsafeやSpanがあるので頑張れば結構速い
ネイティブコンパイルもできるようになってきたからとにかく速度を求めるようなアプリじゃなければ十分
293:デフォルトの名無しさん
23/09/18 15:27:10.56 orcKBY2S.net
Rustもcrateのダウンロード数に応じて
crate開発者が課金される時代か
メシウマじゃなかった胸熱
294:デフォルトの名無しさん
23/09/18 15:57:52.35 qN+5vY8o.net
何の話かと思えばunityか
295:デフォルトの名無しさん
23/09/18 16:04:36.29 2MGtTYvZ.net
とりあえずミュータブルの話をするならshared xor mutable に触れなきゃ意味ないし、それなら元ネタのトランザクション分離レベルぐらいは勉強しとかんといかん。
296:デフォルトの名無しさん
23/09/18 16:05:47.88 7BUJ27i/.net
>>285
C(C++含む)の真のヤバさはそれが周知されていないことだと思う
セキュリティ、セキュリティ吠えながら妄信的にC/C++使っているところとか普通にあるし
297:デフォルトの名無しさん
23/09/18 17:52:28.36 yZdHYJJu.net
>>283
＞もういっそCの方がきれいで
前置宣言だからそれは無い。
298:デフォルトの名無しさん
23/09/18 22:02:21.17 1tuWbz8L.net
>>291
前置宣言だから綺麗に書けるまである
299:デフォルトの名無しさん
23/09/18 22:29:41.23 b4Z9xD4H.net
>>283
Rustは普通というか見た目キレイ側
300:デフォルトの名無しさん
23/09/18 23:41:51.16 X+wkGtcX.net
>>290
ロジックが正しくてもバイナリレベルでは脆弱性になることがある。
分かりやすい例では、言語の理屈では寿命を終えたはずのオブジェクトでも再利用される機会がなくて内容が残り続けるとかね。
そういうときにでもどうにかする知見が C/C++ では積み上がってる。
普通に書いて脆弱性が発生しにくいに越したことはないが、脆弱性が発生していることがわかったときに直せる確信があるというのはセキュリティが重要な場面で C/C++ を使う理由になる。
C/C++ が「自分の足を撃つ」ことになるなんてのは百も二百も承知の上で、「自分の足を撃つことも出来る」ことに価値を見いだしてるんだよ。
もともと自分の足を撃つというのは戦争に行かなくて済むようにわざと撃つことがあるというのを下敷きにした言い回しで、危険であると同時にそれが必要なこともあるというニュアンスを含んでいる。
301:デフォルトの名無しさん
23/09/18 23:47:04.73 h2SSCK+Z.net
>>294
それRustに対するアドバンテージになってないな
むしろディスアドバンテージ
302:デフォルトの名無しさん
23/09/19 07:20:03.69 H6NF4sQp.net
>>294
目的のために敢えてUB引き起こすってこと？
303:デフォルトの名無しさん
23/09/19 11:44:23.57 B2l8DHRh.net
>>294
＞そういうときにでもどうにかする知見が C/C++ では積み上がってる。
所謂、バッドノウハウね。
そりゃさんざん今までやりまくって、なんなら現在進行形だったりするんだからノウハウも積み上がるさ。
304:デフォルトの名無しさん
23/09/19 13:23:13.06 Gn3exU3j.net
データベースのデータファイルの中の構造は、
C言語の「全部生メモリ」状態で、ポインタの
変わりにファイルポジションになっていて
普通に相互リンクトリンクやファイルポジション
をデータの位置を表現するのに使われていたりする。
だから、実行中のプログラムの RAM のメモリー安全
は確保されたとしても、ファイルの中は安全には
ならない。
305:デフォルトの名無しさん
23/09/19 13:27:32.55 Gn3exU3j.net
>>298
[補足]
・ポインターの代わりにファイルポジションが使用され、
古来の plain C と同様のプロググラミングが行なわれている。
・LockFile や fnctl で「部分ロック」が当たり前
のように使用されており、非常に複雑な
配慮が必要なプログラミングになっている。
もっといえば、DBMS を使うアプリケーションも、非常に
配慮が必要な場合も多く、どのようなテーブルやカラム構造
にするかは難しい。ID番号をリンクしたり、どうやって
データを参照しあうかなどが生ポインタと同様の難しさ
を持っていて、わずかでも間違えば、全データが論理破損
してしまう可能性を持っている。
306:デフォルトの名無しさん
23/09/19 14:54:41.30 rHe1cSmV.net
だれか巻き込まれてないか？
URLﾘﾝｸ(www.youtube.com)
307:デフォルトの名無しさん
23/09/19 15:58:16.52 H6NF4sQp.net
形式検証をrustに組み込むのってどれくらい現実的なんだろ
言語本体ではなくてproc macroで実現できるのかね
308:デフォルトの名無しさん
23/09/19 16:39:15.02 p1GkLls0.net
>>299
一般的なDBMSは中央集権でページアクセスを一元管理してるから生ポインタとは全く質が異なる
309:デフォルトの名無しさん
23/09/19 17:37:47.80 /HqZkxNe.net
>>302
ただ、購入履歴などは「誰が購入したか」のIDを
購入項目テーブルとユーザーテーブルを結びつける
必要があるので、IDがポインタの役割になる。
わずかでも狂うと、別人が買った項目が結び付け
られてしまう。
値が1つ、または、行が一行でもずれるとほぼ全体が破綻する。
310:デフォルトの名無しさん
23/09/19 18:14:50.54 mxtPnJ5/.net
DBでも何でもそうだけどshared xor mutableも必要
311:デフォルトの名無しさん
23/09/19 18:23:26.80 /HqZkxNe.net
販売サイトなどのバグって怖くて、500円のものが
バグれば5000円になったりする可能性ある。
そういうものは、プログラミングを気をつける
しかなくて、Rustの安全対策でも防げない。
312:デフォルトの名無しさん
23/09/19 18:32:19.28 gvKDfDmE.net
「気を付ける」の内訳にはテストを書く習慣とかが含まれてる。
気を付けないとしょうがないけど
気を付けるのに使える道具はそれなりに揃ってる。
313:デフォルトの名無しさん
23/09/19 18:34:24.73 mxtPnJ5/.net
すべてのバグをなくせる言語がないのは当たり前
データ競合により起こるそういう値のバグも現実にあるのだからRustでその手のバグをなくせるのも事実
314:デフォルトの名無しさん
23/09/19 18:55:07.79 p1GkLls0.net
>>303
そのレイヤーの話でもDBMSはトランザクション管理されてるから生ポインタとは状況が全く異なる
トランザクショナルメモリで管理された共有メモリと生ポインタの違い(実際はそれよりもまだ差がある)
315:デフォルトの名無しさん
23/09/19 19:02:27.03 p1GkLls0.net
>>304
同時実行制御には大きく楽観的制御と悲観的制御があるがshared xor mutableは後者
高い同時実行性能が求められる場合には楽観的同時実行制御を使うことが増えている
DBの話だけでなくロックフリーアルゴリズムも基本は楽観的制御
316:デフォルトの名無しさん
23/09/19 19:54:07.45 /x1C5Bro.net
>>309
楽観的排他制御を用いることができる現実的ケースが狭い
衝突した時の処理やり直しコストも考慮する必要がある
その一般的な話とは別にポインタ(参照)の話の方は必ず衝突するためsingle writer xor multiple readersが必須
317:デフォルトの名無しさん
23/09/19 21:00:27.72 BGD+Lo74.net
排他制御も凄く奥深い話ではあるが、そういう
ものだけでなく、単なるプログラムミスで、
ID番号が1つずれたり、行がなんらかの事が
原因で1ぎょうずれたりしても、大変な問題
を巻き起こす。だからテストは必須。
318:デフォルトの名無しさん
23/09/19 21:30:53.89 cyrWzrEE.net
RDBMSで物理的な一行とか関係ない
テキストファイルに永続化してる素人だな
319:デフォルトの名無しさん
23/09/19 21:34:30.39 BGD+Lo74.net
>>312
DBMS自体をプログラムする場合には関係ある。
320:デフォルトの名無しさん
23/09/19 21:41:37.42 BGD+Lo74.net
それと、DBMSを使うに徹する場合でも、行に
付ける ID 番号の管理がまた問題になる。
それも慎重に良く考える必要がある。
321:デフォルトの名無しさん
23/09/19 21:50:10.01 LcWw/5IR.net
それサロゲートキー義務で設計したらの話でしょ
322:デフォルトの名無しさん
23/09/19 21:55:08.52 BGD+Lo74.net
>>315
色々な機能を実装する上で、色々有り得る。
323:デフォルトの名無しさん
23/09/19 22:32:18.55 e2nf9Krk.net
>それと、DBMSを使うに徹する場合でも、行に
>付ける ID 番号の管理がまた問題になる。
DB板にもそういうのいるけどRDBにID必要と考えてるやつはもっかい勉強してこい
324:デフォルトの名無しさん
23/09/19 22:44:03.77 5k6OZf8O.net
>>310
>楽観的排他制御を用いることができる現実的ケースが狭い
MVCCやCASが楽観的制御
分散非同期が前提の世界では楽観的制御がデフォルト
じゃないとスケールしないから
Rustがコンパイル時悲観的制御にしてるのは実行時の管理を無くしたいからであってポインタだとshared xor mutableが必須だからではない
トランザクショナルメモリがその一例
325:デフォルトの名無しさん
23/09/19 22:57:59.75 cyrWzrEE.net
DBMSをプログラムする場合には当然関係ある
でも1行ずれたら大変とかいう下手くそは任されないので関係ない
326:デフォルトの名無しさん
23/09/19 23:03:17.25 BGD+Lo74.net
>>319
下手クソとか上手いとかっていうより、
そうならないようなアルゴリズムやデータ構造を
ちゃんと考える能力があるかどうかなん
だろうけどな。
327:デフォルトの名無しさん
23/09/19 23:06:22.84 r+harKS8.net
可変参照と不変参照に対してMVCCなんて使えないよ
それはデータをコピーすることと同じになってしまう
ソフトウェアトランザクショナルメモリはどの環境でも使用可能なのに不利だからほぼ使われていない
さらにRustのshared xor mutableはそれらと独立した話であり共存できる話なのでshared xor mutable必須は問題ない
328:デフォルトの名無しさん
23/09/20 01:44:31.66 16Zt41/R.net
会話のドッジボール
329:デフォルトの名無しさん
23/09/20 09:31:56.94 R98wQa7Y.net
>>303
マイニャンバーですね判ります
330:デフォルトの名無しさん
23/09/20 09:33:37.66 R98wQa7Y.net
>>305
500円の商品が5000円になるバグよりも
500円の商品が5円になるバグの方がはるかに怖い
331:デフォルトの名無しさん
23/09/20 09:37:31.04 R98wQa7Y.net
>>313
いやいやωωω
332:デフォルトの名無しさん
23/09/20 09:39:49.95 erhjcmms.net
>>324
一番の問題は、レジ打ちの人間だったら絶対間違わない
ミスがコンピュータでは起こりえるということだよ。
333:デフォルトの名無しさん
23/09/20 09:41:04.74 erhjcmms.net
>>325
DBMSのアルゴリズムやSQLiteのソースなどを見ていたが、
大いに関係あるぞ。
334:デフォルトの名無しさん
23/09/20 10:30:52.85 jgkdiTgC.net
SQLiteはファイルロックに頼らざるを得ない仕組みなのでDBとしては特殊
335:デフォルトの名無しさん
23/09/20 11:17:52.24 InZb605T.net
俺が高校生だった25年前頃、志木駅で500円分ぐらいのパンを買ったら4000円ぐらい請求されたぞ
336:デフォルトの名無しさん
23/09/20 11:46:41.00 UfpBE+4Y.net
まあ他のバグが減ればその分本質的な問題に注力出来るわな
そういうのはテストケースも綿密に行う必要がある
337:デフォルトの名無しさん
23/09/20 12:17:55.14 1SabZs8d.net
>>317
むしろナチュラルキーにして詰んだりバグってる
338:デフォルトの名無しさん
23/09/20 13:53:51.14 56axJTdd.net
ナチュラルキーがプロジェクトの最後までユニーク保障されたことなんかマジで無いズラ
サロゲートキーは必須ズラ
339:デフォルトの名無しさん
23/09/20 14:13:13.56 I55f6i4N.net
今日入門した。ツアーやったらサンプルプログラムが80個ぐらいできた
fn a(i: i32){ println!("{}",i) }
fn main(){ let x = 10; a(x); a(x) }
これは10が2回出力される
構造体引数だと2回よべずにエラーが出たけど
プリミティブ型？なら所有権がどうのとかなくてスタックにコピーされるだけであってる？
340:333
23/09/20 14:30:53.92 I55f6i4N.net
別のチュートリアル始めて理解した
コピートレイトが実装されてるからなのか
341:デフォルトの名無しさん
23/09/20 15:53:12.11 R98wQa7Y.net
#[derive(Copy)] 禁止
342:デフォルトの名無しさん
23/09/20 18:16:56.45 52Xj2Gp1.net
>>328
他のDBMSでもプロセス間の排他制御は
出来る方法が限られているのでファイルロックを
使っている可能性が高い。
他の方法だと、mkdir 法や、名前付きパイプが
あることがあるが、ファイルロックの方が便利。
一つのプロセスの中のスレッド間の排他制御は
色々な方法が有るが、プロセスを越えた排他制御
は意外と他に出来る方法が無いから。
343:デフォルトの名無しさん
23/09/20 18:33:23.45 I55f6i4N.net
>>335
#[derive(Copy,Clone)]はもう試しました
Rustのいいところが失われますね
344:デフォルトの名無しさん
23/09/20 18:51:23.96 o02nl+od.net
rustの名前の由来は？
345:デフォルトの名無しさん
23/09/20 19:07:11.98 DDNbmZRy.net
URLﾘﾝｸ(en.wikipedia.org)(fungus)
robustな菌らしい
346:デフォルトの名無しさん
23/09/20 19:38:07.98 I55f6i4N.net
OpenGLをやりたくてcrates.ioで最新版を調べてCargo.tomlに
[dependencies]
bytemuck = "1.14.0"
ogl33 = "0.3.0"
[dev-dependencies]
beryllium = "0.13.0"
imagine = "0.5.1"
このプログラムをビルドするとberylliumがunresolvedと出ます
use beryllium::*;
fn main() { let sdl = Sdl::init(init::InitFlags::EVERYTHING); }
berylliumのパッケージ名が変わったりしたのでしょうか
わかる人いますか
347:デフォルトの名無しさん
23/09/20 20:29:54.63 X4X5BtpX.net
>>336
さすがにmutex_lock使ってるよ
乏しい経験からの妄想なんかじゃなく、ちゃんとソース見れ
348:デフォルトの名無しさん
23/09/20 21:48:28.31 UIQvYKk8.net
>>331
ナチュラルキーをまともに扱えない奴はそもそも設計者失格だろう
349:デフォルトの名無しさん
23/09/20 22:20:31.31 DDNbmZRy.net
>>340
単純に動かすだけならdev-dependenciesからdependenciesに移せばいいと思う
テスト用の依存としてdev-dependenciesにこだわるなら
use beryllium::*;
の前に
extern crate beryllium;
を入れれば通るかな
あまりdev-dependencies使わないから分からん
350:デフォルトの名無しさん
23/09/20 22:37:25.93 I55f6i4N.net
>>343 ありがとうございます、動かせました！楽しい
351:デフォルトの名無しさん
23/09/20 23:23:26.93 T1fPPHAq.net
dev-dependenciesについてはこの辺参照
testやbenchやexampleだけで使う依存を定義するやつ
URLﾘﾝｸ(doc.rust-lang.org)
main関数の中で必要なら普通のdependencyにしないといけない
extern crateは関係ない
352:デフォルトの名無しさん
23/09/20 23:35:58.10 8RfwRI5f.net
>>331
未来永劫ユニークとノンヌルを単独ナチュラルキーで満たせればいいけど
そうでないときもあるもんね
>>336
プロセス間mutexやセマフォもあるよ
>>337
小さいデータならCopy実装は有利
353:デフォルトの名無しさん
23/09/21 00:37:39.43 hd16Ksmk.net
>>336
単一ファイルでまかなうSqliteと一緒にすんな
354:デフォルトの名無しさん
23/09/21 02:18:25.33 AFY6neVf.net
>>341
CreateMutex()の第三引数に名前を指定しなければ
ならないが、ユニークな名前をどうやって作るか
が大問題になるよね。
その点、LockFile() なら名前衝突の問題は
最初から簡単に確実に回避できる。
355:デフォルトの名無しさん
23/09/21 03:10:10.71 2dN46EMa.net
普通のDBってインターフェースを一つのサーバーで提供してると思うんだけど
名前解決が出来ない管理なんてあるの？
356:デフォルトの名無しさん
23/09/21 03:14:44.34 AFY6neVf.net
>>349
なるほど。そういうことか。
SQLiteは、中央サーバー的なプロセスが無いから
事情が違うってことなんだな。
357:デフォルトの名無しさん
23/09/21 04:39:08.18 uFUX5dn+.net
まずプロセスを分けるメリットがない
CPUコアスレッド数のスレッドを立ち上げれば一つのプロセスでそのマシンのリソースを使い切れる
ただし通信待ちでスレッドが止まったらその分のCPUリソースを無駄にしてしまうため各スレッドで複数のタスクを動かす
ただし各スレッドが抱えるタスク数は偏りがちなことが知られているため暇なスレッドは他からタスクを盗んで実行できるようにする
以上のスケジューリングをするのがRustのtokio
358:デフォルトの名無しさん
23/09/21 08:25:19.60 CT30w3BF.net
URLﾘﾝｸ(www.sqlite.org)
359:デフォルトの名無しさん
23/09/21 10:46:48.71 BwXSXzYj.net
>>352
Rust以外の言語は完全に否定されているけど
今後Rustだけは条件を満たせば採用するとあるね
360:デフォルトの名無しさん
23/09/21 10:59:44.45 3hJtL3Ib.net
mutable xor sharedはトランザクション分離レベルで言うとSERIALIZABLEだと思うけど、書き込み性能にけっこう致命的なパフォーマンス劣化が出たりしない？
あらかじめ主要な書き込み先オブジェクトの参照を保持しておくとかのオブジェクト指向の定石が利用出来ないし。
361:デフォルトの名無しさん
23/09/21 11:03:41.54 KbwNEPLt.net
SQLiteは今、日本の人が一人でRustに移植してるみたいだけど？
完成度は知らない
362:デフォルトの名無しさん
23/09/21 13:31:34.10 cACw6b27.net
>>351
MySQLやPostgreSQLみたいな普通のDBMSでは
単一プロセスがデーモンとして常駐してファイル更新
を一元管理するのが前提となっているが、
SQLiteでは、そのような常駐プロセスが
存在しなくて、各アプリがSQLiteのライブラリ
プログラムを呼び出して、ライブラリの関数が
排他制御を行なって単一ファイルを壊さないように
ロックしながら互いに強調しつつ、部分書き換えや
部分読み込みを行っている。
つまり、SQLiteは管理を担う単一の常駐プログラム
がなくて、個々のアプリ(の中のライブラリ)が
協調動作するようになっている。
だから、プロセス間で同期を取る仕組みが必要となる。
しかし、CreateMutexでは、ユニークな名前が必要
となってしまい、その名前を決めるのがメンドクサイ。
一方、LockFile だとファイルのパス名で自動的に
ユニークの名前に出来てしまうから、非常に簡単に
安全に正しくロックできる。
363:デフォルトの名無しさん
23/09/21 16:18:11.92 B1OFnXUk.net
3文字で言うと
364:デフォルトの名無しさん
23/09/21 16:54:51.87 2fMT8T96.net
SQLite便利だよ
365:デフォルトの名無しさん
23/09/21 17:25:46.98 WBcwDy8I.net
sqliteは便利だけどテーブルロックなところがうんこなんだよな
begin conccurentとか予定あるらしいが
366:デフォルトの名無しさん
23/09/21 20:32:07.68 2tR0WsIS.net
複数のプロセスからアクセスしないのを前提条件に出来る場合もそれなりにあるもんな。
ちょっとしたツールでデータベースのプロセスをいちいち起動するのはわずらわしいし、 sqlite くらいの気軽さはありがたいのは確か。
sqlite みたいな方針のデータベースが他に台頭してないのが不思議なくらいだ。
367:デフォルトの名無しさん
23/09/21 20:41:30.87 PYjX2iWU.net
>>359
テーブルロックじゃなくデータベースロック
multiple reader xor single writerはデータベース単位
368:デフォルトの名無しさん
23/09/21 20:59:40.19 WBcwDy8I.net
もっとひどいデータベース単位か
URLﾘﾝｸ(www.sqlite.org)
これでページ単位が導入されても、select for updateみたいに明示的にロック
がほしいな
リトライとかだるい
369:デフォルトの名無しさん
23/09/21 20:59:47.82 WBcwDy8I.net
もっとひどいデータベース単位か
URLﾘﾝｸ(www.sqlite.org)
これでページ単位が導入されても、select for updateみたいに明示的にロック
がほしいな
リトライとかだるい
370:デフォルトの名無しさん
23/09/21 23:58:45.91 +/xN81gC.net
以下のような関数(実際のものとは少し違いますが)を実装してみたのですがイテレータのメソッドチェーンの箇所で型が合っていないとコンパイルエラーが発生します
アルゴリズム自体を変更することで目的としていた処理はできましたが結局このエラーの直し方がわかりません
ライフタイム周りが原因だとは考えていますがどのように修正すればよいしょうか
fn hoge(
func: &impl Fn((&i64, i64)) -> i64,
arr: &[i64],
ret: &mut Vec<impl Iterator<Item = i64>>
) {
ret.push(arr.iter().zip(std::iter::repeat(arr[0])).map(func));
for i in 1..arr.len() {
hoge(func, &arr[i..], ret);
}
}
371:デフォルトの名無しさん
23/09/22 09:19:17.11 dkRHHNCe.net
fn hoge(
func: &impl Fn((&i64, i64)) -> i64,
arr: &[i64],
ret: &mut Vec<impl Iterator<Item = i64>>
) {
ret.push(arr.iter().zip(std::iter::repeat(arr[0])).map(func).collect()[0]);
for i in 1..arr.len() {
hoge(func, &arr[i..], ret);
}
}
372:デフォルトの名無しさん
23/09/22 12:36:56.71 E1X0qleO.net
lifetimeの問題もあるかもしれないがimpl Iteratorの型をとるところに関数内で生成したイテレータを渡しているのがそもそもおかしい
373:デフォルトの名無しさん
23/09/22 13:53:26.70 dkRHHNCe.net
>>360
mdb
374:デフォルトの名無しさん
23/09/22 16:15:11.47 v8mgsVW8.net
>>366
mapにはhogeの外から引数として関数を渡しているので再帰呼出しごとにイテレータの型は変わらないですし
```
let mut v = Vec::new();
hoge(|(&a, b)| a + b, &[1, 3, 5], &mut v);
```
という形でhogeを呼び出せばイテレータの型は自動的に推論されると思うんですが...
375:デフォルトの名無しさん
23/09/22 18:07:36.44 KH67E8jw.net
impl TraitはTraitを実装した型のいずれか一つを受け入れるだけで、Traitを実装した型全てを受け入れるわけではない
376:デフォルトの名無しさん
23/09/22 18:31:55.39 v8mgsVW8.net
>>369
mapの中に直接クロージャを渡せば確かにその制限に引っかかりますが、今回は再帰の中で一つの関数を使いまわしているのでimpl Iteratorの型は一つに固定されませんか?
377:デフォルトの名無しさん
23/09/22 18:41:57.56 v8mgsVW8.net
>>365
イテレータのまま保持して遅延評価させたいんです
378:デフォルトの名無しさん
23/09/22 18:43:25.81 8SLDLfd5.net
関数定義から一意な具体型に推論されるのは戻り値型に書いた impl の話ですね
引数型に書いた impl は単にジェネリック引数を匿名化したものという扱いなので
hoge は I: Iterator<Item=i64> なる任意の I で単一化できるような定義が求められます
URLﾘﾝｸ(doc.rust-lang.org)
なので引数で&mut引き回してdynも使いたくないということであれば↓になりますかね
URLﾘﾝｸ(play.rust-lang.org)
379:デフォルトの名無しさん
23/09/22 19:29:43.87 v8mgsVW8.net
>>372
コンパイル通りました!ありがとうございます!
ただもう少しわがままを言うと、実際の実装で
380:はメソッドチェーンの箇所がこれの2倍ぐらいの長さなので具体的なイテレータの型を書かずにコンパイラ任せにしたかったんですが、話を見る限りどうも無理そうですね...
381:デフォルトの名無しさん
23/09/23 08:15:26.34 piK9W+al.net
>>373
>>372も書いてるけどimpl IteratorをBox<dyn Iterator>にする手もあるよ
382:デフォルトの名無しさん
23/09/23 09:19:17.35 lKOAbDFW.net
可能なら dyn は避けるに越したことは無い。
dyn はトレイトオブジェクトを扱うための仕組みであって
推論を補助する仕組みではないから。
383:デフォルトの名無しさん
23/09/23 09:55:40.35 piK9W+al.net
>>375
実装の隠蔽目的でdyn使うのはそんなに変な使い方ではないと思うが
384:デフォルトの名無しさん
23/09/23 09:59:36.45 i9fpyxKg.net
Box<dyn Trait>で解決しました本当にありがとうございました