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>で解決しました本当にありがとうございました
385:デフォルトの名無しさん
23/09/23 16:36:06.31 WPP4nTE5.net
>>364です
補足すると今回自分がわかっていなかったのは以下のような関数がコンパイルを通らないということですね
```
fn hoge<T>(a: i64, b: &mut T) {
*b = a;
}
```
impl Traitが単にジェネリクスの糖衣構文であるということと、
トレイト境界を満たす型をジェネリクス引数に渡した場合は合法に"ならなければならない"、トレイト境界は十分条件も満たさなくてはならないという点
386:を解っていなかったのがポイントでした...
387:デフォルトの名無しさん
23/09/23 21:17:07.32 piK9W+al.net
戻り値のimpl Traitと引数のimpl Traitで振る舞い違うのは当たり前ではあるんだけど混乱しやすいポイントではあるかもね
388:デフォルトの名無しさん
23/09/24 12:22:42.57 2YTVyUlC.net
0788デフォルトの名無しさん
2022/06/21(火) 08:59:28.38ID:vO+TReRM
俺はフロントエンドやらないからこのスレでTauriの話をしないでくれ
389:デフォルトの名無しさん
23/09/24 12:36:49.28 2YTVyUlC.net
こいつはどうかな
URLﾘﾝｸ(zenn.dev)
390:デフォルトの名無しさん
23/09/25 23:08:53.71 OcxuhTB3.net
rustでdx12ってまともに使えますか？
そろそろc++は卒業したい
391:デフォルトの名無しさん
23/09/26 10:01:41.63 q653RLNX.net
>>382
使えないということだな。
392:デフォルトの名無しさん
23/09/26 17:46:11.75 WrG1pnap.net
一応d3d12があるけど、これを直接使うよりwgpu経由のほうがいいんじゃないか？
393:デフォルトの名無しさん
23/09/26 18:52:01.41 liEPyEVD.net
rustとgoとc#でjsonのシリアライズ、デシリアライズ実験したんだけど
rust 1ms cargo run --release
go 10ms
c# 40ms dotnet build -c Release
こんなに違うもんなの?
リリースモードでビルドしたつもりだけど
WebAPIのバックエンドどれにするか悩んでたけどもうrust1択でいいやん
394:デフォルトの名無しさん
23/09/26 21:18:52.63 rDjR9GdF.net
最適化で計測対象の処理が丸ごと消えてないかな
どこかでデータのサイズとか集計とか出力してればいいけど
395:デフォルトの名無しさん
23/09/26 21:22:16.85 sfzsNV4F.net
さすがそこまで速くないよね
C#ももっと速いような気がする
396:デフォルトの名無しさん
23/09/26 21:40:15.73 aJs6t/KK.net
コードの問題かベンチマークの問題だね
397:デフォルトの名無しさん
23/09/26 21:41:15.28 K0prie5d.net
>>385
goこのライブラリ使うとどうなる？
URLﾘﾝｸ(github.com)
398:デフォルトの名無しさん
23/09/26 21:41:38.03 aJs6t/KK.net
>>378
>fn hoge<T>(a: i64, b: &mut T)
fn hoge<T>(a: T, b: &mut T)にすればいいと思うけど
同じような解決策が>>364にあるということなの？
399:デフォルトの名無しさん
23/09/26 21:56:19.26 liEPyEVD.net
>>385
それやってる
まず、デシリアライズ1000回して
シリアライズ1000回でシリアライズでバイト配列になるからそのサイズのトータル
を求めてる
さっきのは1回あたりの平均
>>389
それやったら7.5ms
experimentalなJSON v2は13ms
400:デフォルトの名無しさん
23/09/26 21:59:59.97 liEPyEVD.net
つか、goってリリースビルドないやろ?
コンパイルも一瞬でへ?ってなるわ
それぞれ30行未満のコードだけど..
401:デフォルトの名無しさん
23/09/26 22:29:35.41 liEPyEVD.net
URLﾘﾝｸ(controlc.com)
goだとこんな感じ
402:デフォルトの名無しさん
23/09/26 22:43:29.67 liEPyEVD.net
ああ、ごめんC#は嘘でしたすみません
3msになりました
403:デフォルトの名無しさん
23/09/26 22:55:30.68 liEPyEVD.net
Rustは最強で
C#はメモリ使用量多いがMSが最適化ガンバッテル
Goはメモリ使用量少なくて言語仕様がシンプルだがC#に負けたり...
404:デフォルトの名無しさん
23/09/26 23:05:14.16 EQtG/kil.net
意味のないベンチマークだね
ちなみにこういうのはNimが速いと思うよ
結局こういうのってコンパイラの最適化の勝負をしているだけだから
Rustが速いというよりはLLVMが速いだけ
Zigとかでも同じスピードが出るはず
その代わりにコンパイル速度が遅いというデメリットがあるからこれは単なるトレードオフで、用途に応じて適した言語を選択するのが重要ってだけだね
WebAPI作るならIOが結局ボトルネックになるからパフォーマンス気にするにしても別にスクリプト言語じゃないならなんでもいいのよね
好きな言語にすればいいと思う
405:デフォルトの名無しさん
23/09/26 23:08:16.82 kLEETtIu.net
それはともかく
NimはRustに対して意味のあるアドバンテージ皆無でNimだけは要らん
406:デフォルトの名無しさん
23/09/26 23:14:09.15 liEPyEVD.net
まぁ、データベースはおもいっきし叩くね
最初は最強言語じゃなくてわかりやすい2番あたりの言語でいこうと思ってるんだけたんだけど
で、1番ははっきりRustっぽいからわかりやすいからいんだけど、
2番(C#,Go?)がはっきりしないから1番の言語でいいのかなと
最大の目的はサーバー費用を押さえられるように
407:デフォルトの名無しさん
23/09/26 23:14:24.83 gNMcg380.net
Nimはオフサイドルールってだけで試す気にもならないんだよな…
408:デフォルトの名無しさん
23/09/26 23:52:14.82 lFc5NXyg.net
>>396
多数の非同期タスクを偏らずスレッド間でスチールしてスケジューリングできるのは現状GoとRustしかない
小規模ならGoでもよいがそれ以上だと言語機能が貧弱なGoは辛くなってきてRustの独壇場
409:デフォルトの名無しさん
23/09/27 00:09:38.71 8IPpP98U.net
>>400
妄想乙
URLﾘﾝｸ(ufcpp.net)
410:デフォルトの名無しさん
23/09/27 00:11:19.90 8IPpP98U.net
この妄想も延々言ってたけどやっと黙るのかな？
470: デフォルトの名無しさん sage 2023/09/26(火) 09:57:28.51 ID:ycG3j/g+
>>469
IaaSの一部にそういうケースがありうるだけだぞ
PaaS (FaaS)は基本的にメモリ使用量✕実行時間で料金が決まる
メモリ使用量は少なければ少ないほどコストに優れている
411:デフォルトの名無しさん
23/09/27 00:29:08.13 MfhnDtnO.net
複オジは相変わらず嘘ばっかり
成長しないね
412:デフォルトの名無しさん
23/09/27 00:38:28.22 +nRBKi9H.net
AIにRust生成させてGoと比較してみたけどmarshal以外は変わらないな (goccy/json使用)
x86でやってる？ARMだと違うのかも
(俺はUbuntu x86/64)
URLﾘﾝｸ(pastebin.com)
$ go run ./main.go
1187 [μs]
268419000 [bytes] 467 [μs]
$ cargo run --release
1347 [μs]
263672000 [bytes] 255 [μs]
413:デフォルトの名無しさん
23/09/27 00:56:55.88 +nRBKi9H.net
俺の環境だとgoccy/jsonにすることで4倍速くなったけど何が違うんだろうね
goccy/json
1129 [μs]
268419000 [bytes] 446 [μs]
標準json
4125 [μs]
268419000 [bytes] 533 [μs]
go-json-experiment/json
3446 [μs]
263609000 [bytes] 745 [μs]
414:デフォルトの名無しさん
23/09/27 01:02:33.77 +nRBKi9H.net
これにしたらRustより早くなったわ
結局これっていかに最適化しているかってだけだと思う
URLﾘﾝｸ(github.com)
[Go sonic json]
914 [μs]
263609000 [bytes] 209 [μs]
415:デフォルトの名無しさん
23/09/27 01:06:34.20 8IPpP98U.net
気づくのが遅い
416:デフォルトの名無しさん
23/09/27 01:44:16.58 jtGLjNq+.net
>>405
お手数かけて本当にごめんなさい
自分の実行方法が問題でした
>>385でgoの部分が空欄のように実行方法がわかってなく、
デバッグモードで動いていました
すみません
go runで動かしたら>>405のような速度になりました
417:デフォルトの名無しさん
23/09/27 01:51:26.25 jtGLjNq+.net
WebAPIでgoで行く決意ができました
本当にお騒がせしました
418:デフォルトの名無しさん
23/09/27 04:55:49.67 UdUnwuun.net
YouTube で有名な雑食系エンジニア・KENTA が、既に言ってる。
キャリアパスは、Ruby on Rails → Go のみ
Ruby/Goの神・HashiCorp のMitchell Hashimoto がそう。
Ruby製のVagran
419:t → Go製のTerraform。 今は、Goプログラマーしか求めていない Rust/Elixir は普及のキャズムを超えなかった。 超えたのは、Goだけ
420:デフォルトの名無しさん
23/09/27 17:50:20.18 wGZOY1wb.net
まあビルド時間の重要性はちょこちょこ一人で作ってるやつは理解できんわな。
421:デフォルトの名無しさん
23/09/27 18:56:48.41 CCaLLXi3.net
仕事なら相応に強力なマシンかレンダリングサーバがあるだろ
422:デフォルトの名無しさん
23/09/27 21:44:37.94 fWGZRw8C.net
レンダリングサーバーは関係なさすぎ
423:デフォルトの名無しさん
23/09/27 22:03:34.78 vmit0gpI.net
ビルドサーバーと間違えたのかもね
424:デフォルトの名無しさん
23/09/28 18:29:13.32 gS/5M63X.net
MARCHを受けるために東大の過去問を練習するような意識高い系バカ
425:デフォルトの名無しさん
23/10/06 11:57:36.28 Zl0hPCVy.net
一体誰がRustを推しているのか？
中國？
426:デフォルトの名無しさん
23/10/06 13:12:35.08 2p+njRVB.net
関数型と手続き型のいいとこ取りしたいプログラマだろ
情報科学の先進国なら中国に限らず一定数いるはず
427:デフォルトの名無しさん
23/10/06 16:38:53.65 AJI+rgso.net
ネットインフラが次々とRust製になっていってる
＞【CDN世界トップシェアCloudflare】
＞URLﾘﾝｸ(www.publickey1.jp)
＞CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
＞同社自身がRust製のHTTPプロキシである「Pingora」を開発し利用していることを明らかにしました。
＞【クラウド世界トップシェアAWS】
＞URLﾘﾝｸ(japan.zdnet.com)
＞Rustで構築されたAWSサービスの例としては、
＞コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
＞「Amazon Simple Storage Service（S3）」、
＞「Amazon Elastic Compute Cloud（EC2）」、
＞コンテンツ配信ネットワーク「Amazon CloudFront」、
＞LinuxベースのコンテナーOS「Bottlerocket」などがある。
428:デフォルトの名無しさん
23/10/06 20:34:57.35 hdhWn3/E.net
関数型の良いとことるの諦めた言語って感じだけどｗ
初期の頃はocamlでコンパイラ作られてたらしいのに
MLの匂いさえ残ってない単なる手続き化型言語だわ
429:デフォルトの名無しさん
23/10/06 20:35:16.84 hdhWn3/E.net
関数型の良いとことるの諦めた言語って感じだけどｗ
初期の頃はocamlでコンパイラ作られてたらしいのに
MLの匂いさえ残ってない単なる手続き化型言語だわ
430:デフォルトの名無しさん
23/10/06 21:14:33.58 b1wSOXuc.net
スタックフレームに着目したのはプラスだけど、下手にスタックフレームを隠そうとしているのはマイナス。
計算モデルをスタックフレームにするぐらい割り切れば良かったのに。
431:デフォルトの名無しさん
23/10/06 21:15:11.56 b1wSOXuc.net
スタックフレームに着目したのはプラスだけど、下手にスタックフレームを隠そうとしているのはマイナス。
計算モデルをスタックフレームにするぐらい割り切れば良かったのに。
432:デフォルトの名無しさん
23/10/06 23:16:24.42 tE7CLicd.net
mut 入れたのが間違いなんだろ
433:デフォルトの名無しさん
23/10/06 23:30:10.29 hdhWn3/E.net
関数型に関してはscalaのほうがよっぽど意欲的だよ
def qsort(list: List[Int]): List[Int] = list match
case Nil => Nil
case pivot :: tail =>
val (smaller, rest) = tail.partition(_ < pivot)
qsort(smaller) ::: pivot :: qsort(rest)
たとえば↑こういうのとか
434:デフォルトの名無しさん
23/10/07 00:34:46.36 Hyqci1qG.net
関数型というよりはリスト型言語だな
435:デフォルトの名無しさん
23/10/07 01:56:24.14 a3LzK6ia.net
システムプログラ�
436:~ングのための言語なので純粋に関数型な要素だけを求めるなら別の言語を当たった方が良い
437:デフォルトの名無しさん
23/10/07 02:12:44.80 QajUcOD9.net
リスト型つまりLinkedListをメインにすると利便さと引き換えに遅い問題とガベージが出まくる問題がある
Rustはリスト型メインにしなくて正解
438:デフォルトの名無しさん
23/10/07 04:42:48.81 +bTugVnw.net
GCを前提にしない仕様の上に積み上げなくてはならないという側面から見ると、わりかしよくやっている方なんじゃなかろうか……知らんけど
439:デフォルトの名無しさん
23/10/07 06:29:51.58 GJ9LXcgc.net
自称情強底辺者「Rustでhello worldかける俺カコイイ」
真の成功者「スイカゲームでボロ儲けしました」
440:デフォルトの名無しさん
23/10/07 06:46:44.80 bWLG2vp7.net
mut無しとはこういうことか
URLﾘﾝｸ(play.rust-lang.org)
fn qsort<T: Copy+Ord>(list: &[T]) -> Vec<T> {
match list {
[pivot, ..] => {
let (smaller, rest): (Vec<T>, Vec<T>) =
list[1..].iter().partition(|&i| i < pivot);
[qsort(&smaller), vec![*pivot], qsort(&rest)].concat()
},
_ => vec![]
}
}
fn main() {
let list = [9, 0, 7, 3, 6, 1, 2, 4, 8, 5];
println!("{:?}", list);
println!("{:?}", qsort(&list));
}
441:デフォルトの名無しさん
23/10/07 09:44:47.17 WqNjBTZw.net
まあ今時ランタイム速度でそこまで差がつくことはないわな。
ガベコレの実行タイミングが問題になることは結構あると思うけど。
442:デフォルトの名無しさん
23/10/07 11:17:12.27 fuWtUzBR.net
アロケートしまくリングやな
443:デフォルトの名無しさん
23/10/07 12:06:59.60 pov02R//.net
ランタイムサポートが極まってきたからこそ
極めきれない部分の差が目立ってきたんだよ。
444:デフォルトの名無しさん
23/10/07 14:19:35.27 koj+veBs.net
XYZ座標みたいな単純だけどプリミティブでない大量のデータの配列を作りたいときに
１つ１つをオブジェクトにしないといけないGC言語は放り投げたくなる
座標なら最悪プリミティブに分解して自分で並べれば済むけど型が混ざると詰む
445:デフォルトの名無しさん
23/10/07 15:18:57.75 AO4ZOvxF.net
>>424
>>430
なるほど
美しいコードはスッキリうんこみたいに気持ち良い
まるで脳が洗われるようだ
普段いかに毒に浸かってるかが判るな
446:デフォルトの名無しさん
23/10/07 15:43:47.56 Ozx346pn.net
Rustのはmutなしにした場合の問題提起のための悪い例だろ
447:デフォルトの名無しさん
23/10/07 15:51:39.94 O3XDw4H3.net
>>434
Rustでも１つ１つオブジェクトにする
何の問題もないどころかむしろ好ましいやり方
448:デフォルトの名無しさん
23/10/07 16:42:12.14 2ow1Jojj.net
ocamlだとこんな感じかな？
let rec qsort = function
| [] -> []
| pivot :: tail ->
let smaller, rest = List.partition ((>) pivot) tail in
qsort smaller @ pivot :: qsort rest
>>424 scala比較のためそのままコピペ
def qsort(list: List[Int]): List[Int] = list match
case Nil => Nil
case pivot :: tail =>
val (smaller, rest) = tail.partition(_ < pivot)
qsort(smaller) ::: pivot :: qsort(rest)
scalaすごい頑張ってると思うわ
449:デフォルトの名無しさん
23/10/07 23:59:36.96 QajUcOD9.net
>>430
RustはそのようにOCamlやScalaと同等に書くことも容易な点がいいな
同時にその方法によりRustで記述すると大量にVec(またはリストを実現する何か)を使い捨てていることが見える
つまりGC言語ではガベージが大量に出る
450:デフォルトの名無しさん
23/10/08 02:42:17.66 9NUoKPD/.net
くすくす
451:デフォルトの名無しさん
23/10/08 08:07:41.64 WAd1DVRF.net
同等に書けてないでしょｗ
452:デフォルトの名無しさん
23/10/08 09:57:45.64 ShBUnVvx.net
同等というより>>438と>>430は全く同じだな
空でなければpartitionでsmallerとrestに分けて
それぞれを再帰でqsortしてconcatenate
453:デフォルトの名無しさん
23/10/08 10:16:57.79 CrdCteTP.net
次はHaskellまたはErlangでおながいしまつ
454:デフォルトの名無しさん
23/10/08 10:38:24.03 lCt9aeoq.net
in-placeなqsort書いてよ
455:デフォルトの名無しさん
23/10/08 10:39:23.48 WAd1DVRF.net
>>443
Haskell
qsort [] = []
qsort (x:xs) = qsort [y | y <- xs, y < x] ++ [x] ++ qsort [y | y <- xs, y >= x]
Erlang
qsort([]) -> [];
qsort([X|Xs]) ->
qsort([ Y || Y <- Xs, Y < X]) ++ [X] ++ qsort([ Y || Y <- Xs, Y >= X]).
456:デフォルトの名無しさん
23/10/08 12:06:58.68 3KZ70qk+.net
複オジは常にヒープアロケートするGC言語しか知らないのかな？
特定の言語の機能不足をGC言語の制約のように語るのはやめような
457:デフォルトの名無しさん
23/10/08 14:27:21.60 1klr8jB1.net
rustより高度なライフタイム管理する言語ってないの？
458:デフォルトの名無しさん
23/10/08 14:53:30.59 33/5YUgE.net
高度なライフタイム管理のベクトルがわからん
全データに参照カウンタをもたせて参照→存在を保証してるGC言語ならたくさんあるし
処理過程を生成する（書かせない）ことでライフタイムを意識させない関数型言語もある
459:デフォルトの名無しさん
23/10/08 14:57:14.95 lcllyLaE.net
>>442
ScalaのListもOCamlの[]も単方向リストであってべクタではないのに唯一気付いていないおじさん
460:デフォルトの名無しさん
23/10/08 15:04:22.44 KeQMELAC.net
それはそれとしてScalaのcase classはRustにも欲しいと思うことあり
461:デフォルトの名無しさん
23/10/08 15:32:16.97 1klr8jB1.net
>>448
rustを置き換え可能な言語で
つまりゼロコスト抽象
大学の研究レベルのものとかでないのかな
462:デフォルトの名無しさん
23/10/08 16:37:56.79 lCt9aeoq.net
ランタイムコストなしのライフタイムチェックはシステムプログラミング言語だから必要な話で、そうでない言語ならGCで良い
shared xor mutableの静的な保証はGC言語でも嬉しい性質だと思うが、他の言語で採用例はあるのかね？
463:デフォルトの名無しさん
23/10/08 18:19:11.05 WAd1DVRF.net
enumのリストで書いてみたわ
rust不慣れだから所々おかしいかも
URLﾘﾝｸ(ideone.com)
enum List<T> {
Cons(T, Box<List<T>>),
Nil,
}
impl<T: Copy + PartialOrd> List<T> {
// 略
fn qsort(&self) -> Self {
match self {
List::Nil => List::Nil,
List::Cons(pivot, tail) => {
let (smaller, rest) = tail.partition(|x| *x < *pivot);
smaller.qsort().concat(&rest.qsort().prepend(*pivot))
}
}
}
}
fn main() {
let list = List::<i32>::nil().prepend(4).prepend(8).prepend(8).prepend(3).rev();
list.each(|n| print!("{}", n));println!("");
list.qsort().each(|n| print!("{}", n));println!("");
}
464:デフォルトの名無しさん
23/10/08 19:36:48.46 e3limdE9.net
>>449
目的はソートなので、
単方向リストを用いるかベクタを用いるかは実装方法の問題だから些細な話かな。
実用上もベクタで十分だから単方向リストの出番は滅多にないよね。
465:デフォルトの名無しさん
23/10/08 20:05:18.10 lCt9aeoq.net
で、みなさんは単方向リストを使う綺麗だけどクソ遅いコードを並べて何がしたいんですか？
466:デフォルトの名無しさん
23/10/08 20:14:55.63 BgGDjECm.net
そんなの用途次第だろ
ど素人かよ
467:デフォルトの名無しさん
23/10/08 20:19:50.77 QzGY7mJQ.net
>>454
>>439がガベージがどうこう言ってるのについてはどう思う？
468:デフォルトの名無しさん
23/10/08 20:59:00.53 e3limdE9.net
>>457
リストはガベージと裏表一体ですが何を問題にしていますか？
リスト化する時にconsセルの割り当てが発生します。
そしてリストから取り出す時に空のconsセルがガベージとして発生します。
469:デフォルトの名無しさん
23/10/08 22:12:35.86 nH9KI4I/.net
赤っ恥オジの言い訳草
470:デフォルトの名無しさん
23/10/08 22:57:55.16 1kYUOs3M.net
入れもの(メモリ)はどのデータ構造でも不可欠だからいずれもゴミが発生するのは仕方ない
ただしリスト(各セル|ノード)に比べてベクタは以下の点で有利
・まとめて確保解放ができる
・next pointer(の容量と処理)が不要
・リニアスキャンが速い
・ランダムインデックスアクセスも速い
そのためRustでもほとんどの用途でベクタが使われリストは少ない
471:デフォルトの名無しさん
23/10/08 23:00:08.12 Li9tDqQF.net
今どきはCPUキャッシュが効くかどうかが問題だから
472:デフォルトの名無しさん
23/10/08 23:38:45.90 F0i6/5MC.net
三連休使ってrustの勉強してるけど、ようやく慣れてきた
某openGLの本をMacでやっててDSL2のインストールに四苦八苦、、、
なんかこいつだけCargo.tomlの書き方が、、、
急ぎ足せずrustのとこにある蟹表示するやつ写経してクレートの追加覚えた
先は長いね、、、
頑張る
473:453
23/10/09 01:16:03.20 VBg3Yonc.net
>>444
>>455
URLﾘﾝｸ(ideone.com)
これでクイックソートになってるはず？
なってなくても笑って許してほしい
474:デフォルトの名無しさん
23/10/09 01:21:45.86 L6ciWwId.net
>>456
ソート済み配列のソートの計算量が最悪になるqsort実装の活用方法わかんないです
どういうときに有効なんですか？
標準ライブラリのソートアルゴリズム使った方が良いのでは
475:デフォルトの名無しさん
23/10/09 01:24:15.18 TA+AoWAa.net
リストと配列比較してるやつ全員馬鹿です
476:デフォルトの名無しさん
23/10/09 13:24:27.74 gMk1hFfQ.net
そんな香具師いたか？
477:デフォルトの名無しさん
23/10/09 18:01:30.12 416rm9Ab.net
appendできないListってダサい
478:デフォルトの名無しさん
23/10/09 18:16:49.87 TA+AoWAa.net
おるやん！
479:デフォルトの名無しさん
23/10/11 15:06:20.59 UxaO0GW9.net
Rust検索したらゲームの方が出てきてお前じゃないってなって情報収集が捗らない
480:デフォルトの名無しさん
23/10/11 15:25:39.99 kTxLNWR8.net
それで困ったこと今まで一度もないんだがどういう検索でそうなるの？
普段からゲーム関係の検索したりサイト閲覧してたりする？
481:デフォルトの名無しさん
23/10/11 16:05:36.62 jfZ9hs4j.net
ゲームの方もやってますね
Rust初心者が簡単なゲーム作ろうとしてまして
(Pythonのpygameでブロック崩し作れる程度)
検索方法がまずいのかもしれませんね
描画したり、画像をはったり、それを縦横動かしたいだけなのですが
icedか？eguiか？みたいなとこまで来てるけど、まだ使い方がよくわからんですね
どこの関数が初期設定の一発実行で、どこの関数が60fpsの毎回実行なのかとか
プロではなく趣味なので言葉選びが毎回曖昧です
482:デフォルトの名無しさん
23/10/11 17:42:19.71 Pu4uPjjn.net
なるほどそういう感じなのか
検索ワードに”game”とかも含んでるなら
月並みだけどprogrammingを足してみたりゲームの方にだけ特徴的なワード(surviveやsurvivalとか)を除外してみたりするといいんじゃないかな
483:デフォルトの名無しさん
23/10/11 20:52:08.31 OZznE1k0.net
>>471
URLﾘﾝｸ(arewegameyet.rs)
とりあえずこの辺のチュートリアルから選んでやってみては？
484:デフォルトの名無しさん
23/10/11 23:18:11.74 vJm7EO/F.net
>>441
>>430がVec使用だから同等でないという話ならばRustにもリンクリストがあるよ
リンクリストに特化したパターンマッチング構文や結合構文はないけれど
例えばTをCopyせずそのまま使うならば
use std::collections::LinkedList;
fn qsort<T: PartialOrd>(mut list: LinkedList<T>) -> LinkedList<T> {
if let Some(pivot) = list.pop_front() {
let (smaller, rest): (LinkedList<T>, LinkedList<T>) =
list.into_iter().partition(|x| x < &pivot);
// concat
list = qsort(smaller);
list.extend([pivot]);
list.extend(qsort(rest));
}
list
}
fn main() {
let list = LinkedList::from([9, 0, 7, 3, 6, 1, 2, 4, 8, 5]);
println!("{:?}", list);
println!("{:?}", qsort(list));
}
485:デフォルトの名無しさん
23/10/11 23:57:55.35 2xINBvCy.net
はあ
馬鹿なんですね
486:デフォルトの名無しさん
23/10/12 11:14:39.52 u59ybXeV.net
たしかに Rust ゲーム 造り方 で検索するとゲームの方ばっかり出る罠
487:デフォルトの名無しさん
23/10/12 11:17:21.26 u59ybXeV.net
>>474
mut 使ったら負け
488:デフォルトの名無しさん
23/10/12 12:51:53.05 5Y8Kw2UP.net
>>477
そんな表層的なことを問題にするのは愚か
例えばmutを表層的に使っていない>>430はそこで呼び出しているpartitionとconcatそれぞれのなかでmutを使っている
当たり前だがデータを組み立てたり書き換える処理は全てmutにたどりつく
>>474でも表層的にmutを無くしたいだけならば同様にconcat関数を作りその中でmutを使えばいい
489:デフォルトの名無しさん
23/10/12 12:52:32.93 5Y8Kw2UP.net
>>477
そんな表層的なことを問題にするのは愚か
例えばmutを表層的に使っていない>>430はそこで呼び出しているpartitionとconcatそれぞれのなかでmutを使っている
当たり前だがデータを組み立てたり書き換える処理は全てmutにたどりつく
>>474でも表層的にmutを無くしたいだけならば同様にconcat関数を作りその中でmutを使えばいい
490:デフォルトの名無しさん
23/10/12 13:19:12.59 SguY35qe.net
mut使ったら負けとは俺は思わないが断じて表層的なことではない
本質的に重要な違いだからこそRustでは明確に区別してるわけなので
それにconcatもpartitionもmut使ってない
491:デフォルトの名無しさん
23/10/12 13:31:42.25 IQy1JHL6.net
単方向リストと両方向リストの区別もついていない馬鹿だからしょうがないね
492:デフォルトの名無しさん
23/10/12 14:04:37.89 29Fh0rnH.net
標準ライブラリのソース見たら
concatもpartitionもmut使ってるな
最終的にあらゆるmutになるのか
493:デフォルトの名無しさん
23/10/12 14:35:37.70 +nxBPiMF.net
すべてがmutになる 森鴎外
494:デフォルトの名無しさん
23/10/12 14:56:18.33 oQimRC1z.net
「ボクの考えた最強の汚コードを批判するな！」
495:デフォルトの名無しさん
23/10/12 14:58:53.27 X9LcShxS.net
>>482
ネタじゃなくマジで言ってるならRustは辞めとけ
絶望的に向いてない
496:デフォルトの名無しさん
23/10/12 15:06:20.95 pri3rXDa.net
複オジが劣化したのだろうか
それとも複オジ劣化版が新たに出現したのだろうか
497:デフォルトの名無しさん
23/10/12 15:24:09.95 VkfPx0C5.net
mutを使わずにできることは読み出しとムーブとコピーだけ
498:453
23/10/12 19:51:44.10 viHBcoi7.net
今度はDartで書いてみた
3.0でパターンマッチがちょっと強化されたらしい？
3.0新登場のスイッチ式の=>の右側には式だけしか書けない？
dartにはそもそもpartitionはない？
というわけで>>445のHaskell方式で書いてみた（程遠いけど）
List qsort(List list) {
return switch (list) {
[] => [],
[var pivot, ...var rest] => qsort(rest.where((x) => x < pivot).toList()) + [pivot] + qsort(rest.where((x) => pivot <= x).toList())
};
}
499:453
23/10/12 23:01:31.11 viHBcoi7.net
こういう書き方もできた
こっちのほうが雰囲気出てるかな？
List qsort(List list) {
return switch (list) {
[] => [],
[var x, ...var xs] => qsort([for (var y in xs) if (y < x) y]) + [x] + qsort([for (var y in xs) if (x <= y) y])
};
}
500:デフォルトの名無しさん
23/10/13 08:06:18.09 q0Ayf65Z.net
>>482
RustはCと同じ高速で動作する手続き型言語だから少なくとも最下層はmutが基本になる
たとえばイテレータからVecへcollectする場合
特殊ケースはunsafe最適化
一般ケースはlet mut vec = Vec::new();してextend
その一方でプログラミングする時はその最下層を意識しなくても知らなくてもいい
mutを必要としないiter.collect()と抽象的に書ける
501:デフォルトの名無しさん
23/10/13 08:24:52.90 NdZOKZ+T.net
最強Rust始めたわい
mutの話が出てるから質問
シャドーイングっていう性質使えばmutなくても書けそうな気がしてる(まだ書けてない)んだけど
シャドーイングしたときと、mutではメモリの動き何か変わるのかな？と
シャドーイング
let z = x + y;
その後z使って処理
let z = x - y; // z宣言して前回のz上書き
その後z使って処理
502:デフォルトの名無しさん
23/10/13 12:19:34.60 tPfYbY0d.net
>>491
それを1億行書いたとする。たぶんスタック溢れるんじゃね？
503:デフォルトの名無しさん
23/10/13 12:43:08.68 zQ1dnjfM.net
1億行書く意味が分からんが
そんな問題ではないだろw
504:デフォルトの名無しさん
23/10/13 18:31:34.80 Q91zX7Uf.net
ドロップしないの？
505:デフォルトの名無しさん
23/10/13 19:31:02.96 /Zwm785x.net
ちょっと前にJSONシリアライズでの最適化の話出たけど
goは空気感が不安になるよな
rust->システムプログラミングよりの言語で、速度やらいろいろうるさそうなやつが
集まってて、そんなやつらの作るライブラリだからパフォーマンスとか心配しなくてよさそう
C#->.NET開発チームが毎年長文ブログでがんばってるアピール
go->言語機能とかほぼ完成しちゃってるんだろうが
アピールもない、この空気感
506:デフォルトの名無しさん
23/10/13 19:35:26.71 /Zwm785x.net
URLﾘﾝｸ(devblogs.microsoft.com)
今年の.netのパフォーマンス改善はこれ
goはシンプル言語で標準ライブラリも最小限だから
もうあまりやることないのか?
507:デフォルトの名無しさん
23/10/14 14:19:51.05 MfcWhKX5.net
>>491
不使用領域は再利用されるから単純な順次処理ならシャドーイングで十分
mutが欲しくなる理由の１つは繰り返し処理だな（長さ不定のリストの集計とか）
関数型言語みたいに再帰使えばmutなしでも何とかなるけど慣れないとややこしい
あとは全部作り直すのが不合理なデータの部分的な書き換えでもmut使いたい
508:デフォルトの名無しさん
23/10/14 19:31:37.47 FeWBHDoO.net
for文で値を変えるカウンタとかフラグとかもmutじゃないと書けないな。
まぁ for 文より iter で書けという一派も多いかもしれんけど。
509:デフォルトの名無しさん
23/10/14 19:57:12.00 jlnlui4T.net
モジュールの内部では (性能上の理由で) mut を使っても、
外側に見せるインターフェイスは
(不自然ではない範囲で) mut を避けるのは自然な方針だと思う。
510:デフォルトの名無しさん
23/10/15 09:39:38.68 M8zy/AR3.net
Cで書いたプログラムを Rustで書いたらこうなります
っていうのをひたすら集めた本がほしい
511:デフォルトの名無しさん
23/10/15 10:09:58.67 Xnkvwbkm.net
全銀システムでJavaの
512:信頼が失墜した今こそrustのチャンスだな
513:デフォルトの名無しさん
23/10/15 11:00:17.07 2BZrn9hr.net
全銀はまだCOBOLだろ
ほんといつもいつも嘘ばっかりだな
514:デフォルトの名無しさん
23/10/16 10:19:13.28 kgcCjrnK.net
>>500
似たような動機で描かれた本とかブログは観たことあるけど
Rustっぽくないコードばっかりでうんざりする面もある
515:デフォルトの名無しさん
23/10/16 10:21:08.50 kgcCjrnK.net
全銀協のフォーマットって今も変わってないんだろうけど
半角カタカナだらけでRustで扱うのは大変かも知れないね
516:デフォルトの名無しさん
23/10/16 10:35:49.58 enUIFRpv.net
扱う文字については適当なライブラリを整備すればそんなに問題にならなさそうに思うが
517:デフォルトの名無しさん
23/10/16 11:26:02.88 SeIR9j3q.net
>>505
＞扱う文字については適当なライブラリを整備すれば
外字ばかりとかでそれが大変なんじゃないの？知らんけど
518:デフォルトの名無しさん
23/10/16 12:22:46.59 SkmcjqYw.net
半角しかないのに外字とは
519:デフォルトの名無しさん
23/10/16 13:30:20.84 kgcCjrnK.net
今のうちに Rust でﾊﾝｶｸｶﾀｶﾅ自由自在な crate 造っておけば
将来ライセンス料でｼｯﾎﾟﾘ儲かりますか？
520:デフォルトの名無しさん
23/10/17 11:40:48.89 xDsy3kB7.net
Rustに慣れるとCのifで()付け忘れたわ
521:デフォルトの名無しさん
23/10/19 14:52:32.31 rcYEOPS6.net
Vec の iter() と into_iter() の違いは？
522:デフォルトの名無しさん
23/10/19 14:53:04.92 rcYEOPS6.net
Vec の iter() と into_iter() の違いは？
523:デフォルトの名無しさん
23/10/19 15:12:31.11 V7scna43.net
>>510
引数に着目するといい。
into_iter はムーブするが iter は借用する。
524:デフォルトの名無しさん
23/10/20 01:20:11.96 /f3Rr7gK.net
>>500
その発想がすでに間違ってる
根本が違うから同じようには書けない
525:デフォルトの名無しさん
23/10/20 06:13:09.90 3+q+Er7L.net
Cで安全に書いたときと同じ生成コードにはなるけどRustでは抽象度の高い表現をするからなあ
例えばメモリのある範囲の領域を順に読み取る(書き込む)というC言語だとポインタをインクリメントしていくだけの場合でも
Rustだとまずメモリの領域をスライスという安全な抽象表現で扱い可変性もライフタイムも付随してスライスが指す元の安全に確保されている領域(配列やベクタなど)も必須というところからスタート
そのうえでスライスのイテレータにより必ずその範囲内のみを順に安全に指し示す参照(または可変参照)が次々と得られて順に読み取る(書き込む)ことが達成される
さらにRustではこれをfor文ではなく抽象度の高いイテレータメソッドチェーンで書くことも多いからCコードとの対応はますます難しくなるね
526:デフォルトの名無しさん
23/10/20 06:56:18.50 /M3RKJCH.net
unsafe {
Rust で C ポインタやりたいなら
let p = *mut hoge;
p+=1;
std::slice::from_raw_part(p. 1)[0] = hage;
}
527:デフォルトの名無しさん
23/10/20 09:04:11.56 6mF1sPPt.net
>>513
同じように書けないからこそ対比したものが欲しいと言う話だろうに
528:デフォルトの名無しさん
23/10/20 09:27:32.12 /M3RKJCH.net
>>516
クソでたらめだが真面目に実装するとマジ面倒
>>515 方式だと
#[derive(Debug)]
struct Hoge {a: u8, b: u8, c: u8}
impl Hoge {
pub fn new(a: u8, b: u8, c: u8) -> Self {Hoge{a, b, c}}
}
fn main() {
let hoge: Vec<Hoge> = vec![Hoge::new(1, 2, 3), Hoge::new(4, 5, 6), Hoge::new(7, 8, 9)];
println!("{:?}", hoge);
let mut p = &hoge[0] as *const Hoge as usize;
p += 2 * std::mem::size_of::<Hoge>();
unsafe { std::slice::from_raw_parts_mut(p as *mut Hoge, 1)[0] = Hoge::new(8, 3, 1); }
println!("{:?}", hoge);
}
>>514 方式だと
let p = &hoge[0] as *const Hoge as *mut Hoge;
unsafe { std::slice::from_raw_parts_mut(p, 3)[2] = Hoge::new(8, 3, 1); }
でちょっとマシになるくらい
529:デフォルトの名無しさん
23/10/20 09:40:03.83 2W9ATkqE.net
マクロでウヒヒ
530:デフォルトの名無しさん
23/10/20 11:03:08.72 +Ixb2Hv2.net
近代的な言語の仕組みってのは大規模なプログラムをどうやってまとめるかという方向で進歩してるから
小さなサンプルで比較しても設計理念は身につかんのだ。
531:デフォルトの名無しさん
23/10/20 13:13:02.21 iA9G36tB.net
設計理念を身につける話なんて誰もしとらんだろw
532:デフォルトの名無しさん
23/10/20 15:12:25.73 +Ixb2Hv2.net
してないから問題だと述べてるんだが。
俺が学生のときに英語の長文の全ての単語の横に(単語ごとに！)日本語の単語を書いてたやつがいたことを思い出したわ。
本に載る程度の規模(ひとつあたり数ページくらい？)のプログラムを対比するってのはそういうことだよ。
言語の設計理念に基づいた構造こそが重要で、構造を論じるほどの規模にならないならたいした違いは見えてこない。
533:デフォルトの名無しさん
23/10/20 16:07:06.67 /M3RKJCH.net
CでもPythonでもRustでも全部の行にあほみたいなコメント描く香具師はうざいけど
Rustのcrateでdocsにcomment100%達成するためにはアホなコメント描かされてダサい設計思想だと思う
534:デフォルトの名無しさん
23/10/20 16:34:14.75 HySp0Cr6.net
>>521
日本語の設計理念wが身についてないみたいだなw
535:デフォルトの名無しさん
23/10/20 17:24:55.57 /f3Rr7gK.net
unsafe使うならCでいいんだよなw
536:デフォルトの名無しさん
23/10/20 19:40:13.76 3+q+Er7L.net
>>524
それは違う
unsafeを使ってsafeなインターフェースを提供する部分だけ人間が安全性を保証すれば
それ以外の部分はすべてRustが安全性を保証してくれる
その方針でRustの標準ライブラリやunsafeを用いる一部クレートが作られている
537:デフォルトの名無しさん
23/10/20 20:06:04.22 9sHhryb+.net
>>525
もちろん品質が保証されてるライブラリは使うよ
現時点でここまでライブラリが揃ってるから自前でunsafeを書く必要は感じない
538:デフォルトの名無しさん
23/10/21 12:29:35.28 sf7W/HH9.net
関数型最強(キリω
ですねわかります
539:デフォルトの名無しさん
23/10/21 21:43:10.75 sGOhbjn7.net
Linuxでも、結局のところ「C言語でいいじゃん」という結論になりそうよね
リーヌスもなんかやっぱRustはなぁ・・・ってトーンダウンしてきてるし
540:デフォルトの名無しさん
23/10/22 00:35:28.61 GiKl9Asx.net
>>528
カーネルなんて低レイヤーのポインタ操作とかビット演算しかしないからな
541:デフォルトの名無しさん
23/10/22 00:50:06.85 n0l+NFKj.net
Linux カーネルの中にだって Rust が適している場所も
あるといえば有るだろうけど現時点でそれなりに検証が済んで
安定して動いているものを「置き換え」するほどではないだろうな。
適しているからといって各部を別の言語で書いたりすると
接続箇所で面倒になったりもするし。
542:デフォルトの名無しさん
23/10/22 11:49:16.17 IKvVj0uW.net
カーネルで流行らないならもう流行るところないんじゃ…
543:デフォルトの名無しさん
23/10/22 19:50:36.55 NN1UsPSx.net
どの言語からどの言語への場合でも既に動いているものを別の言語に移植するだけだとコストがかかる
それでもスクリプト言語からRustへ置き換えるなら実行速度と省メモリの効果がコストを上回りやすいためよく行われている
一方でC/C++
544:からRustへ換えても実行速度と省メモリの効果はない だからシステム設計を変えるなど大きな更改タイミングでRust化することが多い 特にマイクロサービス化されているものは個別に更改できるためシステム全体の一部Rust化に向いている 最も向いておらずハードル高いのがモノリシックになっているOSカーネル その場合でも分離されているデバイスドライバは最近のデバイス複雑化と更新対応の多さからもRust化が向いているため進んでいる
545:デフォルトの名無しさん
23/10/22 19:58:13.61 fijCTFBo.net
>>531
もうちょっと上位のレイヤーなら良いと思うけどね
Cでバッファオーバーランするようなプログラムって
結局Rustでもunsafe使わざる終えないような処理なので
546:デフォルトの名無しさん
23/10/22 21:57:00.47 xV2fKCwr.net
構造体をキャストするものでも、hoge_storage_t みたいに最大サイズを規定するパターンと
char foo[0]; を積極的に利用するパターンと 真っ二つにわかれるしねぇ
後者はRustでどうすんだろ
547:デフォルトの名無しさん
23/10/22 22:15:56.13 fijCTFBo.net
結局構造体もパケットのバイト列にパックするからね
その時unsafeを使うことになる
548:デフォルトの名無しさん
23/10/22 22:45:30.49 EpprGwAf.net
構造体はunsafeいらん
タグ無し共用体はunsafe
549:デフォルトの名無しさん
23/10/22 23:15:20.26 HWj9itUZ.net
流行るから価値ある、流行らないから価値なしって評価基準はジャパニーズカルチャーのガラパゴス
550:デフォルトの名無しさん
23/10/22 23:23:05.72 /1lQw0Ls.net
>>534
後者も普通に表現できるしCとのFFIも可能
551:デフォルトの名無しさん
23/10/22 23:28:57.61 zUgjdRO9.net
Redox（URLﾘﾝｸ(www.redox-os.org)）みたいなRust製のUnix系OSプロジェクトならもうあるし
無理してLinuxに食い込む必要はないと思うんだけどLinux開発者でもRust使いたい人はいるんでしょ
Linuxは一部のモジュールがRust製になる程度で中核は最後までCで通すと思う
というかRustで置き換えるなら名前変えてほしい
552:デフォルトの名無しさん
23/10/23 00:13:38.68 tCssLiBK.net
>>539
まあカーネルで使ってる基本的なデータ構造(赤黒木、ハッシュテーブル、双方向リスト)
kref(リファレンスカウント)などは外せないからね
無理に組み合わせるとかえってキツい気がする
553:デフォルトの名無しさん
23/10/23 05:58:05.37 3382hDjx.net
>>533
実際にはCでもバッファオーバーランしないからRustでは、unsafe必要ないでしょ
554:デフォルトの名無しさん
23/10/23 06:59:33.53 8gpCEC0e.net
>>533
>使わざる終えない
昔こんな誤字よく観たな