24/04/04 15:21:14.87 AF0jRQyM.net
>>547
>値が複製されて、複製された値の所有権が関数fに渡るだな。
複製された値の所有権は最初から関数fのスコープの中で発生するものなので
「関数f」に渡るという表現には少し違和感を感じる
551:デフォルトの名無しさん
24/04/04 15:34:13.46 1vyOHDUL.net
「違和感を感じる」という表現に違和感を感じる
552:デフォルトの名無しさん
24/04/04 18:59:50.97 mbQWc9lN.net
>>551
滑ってるぞ
553:デフォルトの名無しさん
24/04/04 19:04:00.82 mNkWQBjH.net
感じてるから違和「感」だからね
要は頭痛が痛いと同じ
554:デフォルトの名無しさん
24/04/04 19:08:09.03 v0TcrcAn.net
違和感がある。これでどうだ
555:デフォルトの名無しさん
24/04/04 19:17:51.63 v7LceGlx.net
>>553
感じるを感じるメタ表現だろ。
ポインタのポインタみたいなもんだ。
556:デフォルトの名無しさん
24/04/04 20:07:49.07 xDxHg+AD.net
>>542
embedded 対応アーキ少なくね？
557:デフォルトの名無しさん
24/04/04 23:05:07.77 94OMF7T7.net
>>553
「違和感を感じる」は「頭痛が痛い」とは違って重言ではないよ
URLﾘﾝｸ(togetter.com)
URLﾘﾝｸ(www.nhk.or.jp)
558:デフォルトの名無しさん
24/04/04 23:18:56.70 94OMF7T7.net
>>557
重言ではあるけど間違った日本語ではない
といったほうがよかったね
559:デフォルトの名無しさん
24/04/05 00:09:35.95 Lw8p7kTG.net
>>556
少ないね。
でも、そもそも今までCとアセンブラ以外はほぼ無い状態だったから、出てきただけマシ。
それに、少ないといってもシェアが広いアーキなので滑り出しは順調と言えるのかと。
560:デフォルトの名無しさん
24/04/05 00:21:09.11 dub3Z8tI.net
後発言語？
561:デフォルトの名無しさん
24/04/05 00:50:16.55 Lw8p7kTG.net
少し前まで次世代言語と言われてた程度には後発。
鯖向け言語で終わると思ってたら、マジでC/アセンブラの牙城を崩し始めるとは思わんかった。
むしろ崩し始めることすら無理だと思ってた。
562:デフォルトの名無しさん
24/04/05 05:07:52.53 CPVE6BHF.net
>>559
状況も追い風なのかもね。
二の足踏んでたけど、armと生きていく決心をしてrust覚えるか。
先にrust身に付けてから、非対応アーキでC++導入したらメリットあるかな？
563:デフォルトの名無しさん
24/04/05 08:11:28.72 Lw8p7kTG.net
Rust知ってれば安全性の高いシステム組めますと言うアピールになるし、C++にもその安全性のための知見は役立つ。
複数言語使えますってだけでもアピールになるしね。
Rustは多分仕事自体はまだ多くない。
これからアピールして増やしていく感じなので、両方使えてた方がいい。
564:デフォルトの名無しさん
24/04/06 22:48:03.64 4i1Gvjc8.net
rustというものがありながらなぜ大部分のコードはC言語なのかを知るために現場に行くのもアリ
565:デフォルトの名無しさん
24/04/06 23:06:32.76 7kpWL/Du.net
Rustが実用的になったのは2020年
それ以降の新規案件はRustになっている
566:デフォルトの名無しさん
24/04/07 01:26:10.29 Hmt7T+4v.net
Rustへの移行は始まったばかりだからまだまだCが残っているのは当たり前
567:デフォルトの名無しさん
24/04/07 10:55:29.15 QD1FKAnH.net
絶壁の学習曲線。
貧弱なライブラリと人材。
早すぎる最適化。
しばらくは既存コード置き換えが中心だし、今後もプロジェクト初期のプロトタイピングで使われることは無いだろう。
568:デフォルトの名無しさん
24/04/07 14:17:46.28 vzw88H1n.net
P系言語の糞思考に染まっていない初心者こそ
最初にRustを学ぶべき
569:デフォルトの名無しさん
24/04/07 18:04:59.36 Sj2oLPpI.net
>>567
移植なんて無駄な作業はどの言語間でも行われることが少なく
570:デフォルトの名無しさん
24/04/07 18:05:33.79 nD4MmBKu.net
初手Rustは冗談抜きで2024以降だと選択肢に入るんじゃないか
571:デフォルトの名無しさん
24/04/07 18:09:00.76 Sj2oLPpI.net
>>567
移植なんて無駄な作業はどの言語間でも行われることが少なく
通常はシステム更新で全体もしくは一部が作り直される時に別の言語が使われる
Rustでも同様でほとんどがそれら含む新たな案件
572:デフォルトの名無しさん
24/04/07 18:16:09.73 TV6Dkj8m.net
>>567
早すぎる最適化という意味不明なデタラメ書いているのは君一人だけ
そしてRustを叩きたいためにウソを散りばめる
573:デフォルトの名無しさん
24/04/08 02:24:45.08 BHlkyWwA.net
>>567
貧弱なライブラリとかエアプかよ
そしてRustを叩きたいためにウソを散りばめる
574:デフォルトの名無しさん
24/04/08 03:09:59.48 BqmMXmQi.net
単なる感想を必死にウソ扱いして何がしたいんだコイツw
575:デフォルトの名無しさん
24/04/08 11:48:22.86 hzcejt90.net
ライブラリはPythonと比べると流石に貧弱
特に数値計算とか物理・機械学習系
簡単な数値計算の時点でnumpy•scipyのようなデファクトがなく、雑魚が乱立している
もっと高度な計算系ではもっと雑魚が乱立しているか、そもそもない
576:デフォルトの名無しさん
24/04/08 12:32:47.46 64QjhTLf.net
>>575
キチガイアンチ
すべての分野でライブラリが充実している言語は存在しない
ある分野で一番充実している言語を棍棒にしたら他のすべての言語が負けるのは当たり前
そういう無意味なことをして叩いて楽しいか？
577:デフォルトの名無しさん
24/04/08 13:16:14.61 JoalanBl.net
>>576
貧弱なことを指摘するのは叩きではない
俺はただ、「貧弱なライブラリとかエアプかよ」とか言っているエアプに現実を指摘しただけだ
578:デフォルトの名無しさん
24/04/08 14:02:16.22 7wfBslr8.net
>>576
そこは「Rustなら〇〇分野のライブラリがどの他言語より充実している」と反論するところだろ。
579:デフォルトの名無しさん
24/04/08 14:10:54.87 7wfBslr8.net
>>570
絶壁の学習曲線だから無理だろ。
moveを意識しないshared xor mutableの無い、Rc中心のEasyRustとかが無いと、fnひとつ呼び出せないんじゃない？
580:デフォルトの名無しさん
24/04/08 14:43:36.67 IC0NBj1d.net
Crypto分野はRustが他言語よりも充実してるかもね
581:デフォルトの名無しさん
24/04/08 15:06:06.34 rjHvzTUw.net
ライブラリの多さってイコールでユーザの多さなんだよ
更にいうとその言語開発者の意欲の表れでもある
ライブラリが少ないという事はユーザが少ない
更に少ないユーザの中でも意欲の有る人間は少数って証明なんだよね
582:デフォルトの名無しさん
24/04/08 15:43:54.88 JoalanBl.net
いやまあ数はあるんよ数は
意欲のある人はいるっぽいんだけど、デファクトとるようなライブラリってやっぱりそれなりの人数でちゃんと資金とって作られてるんだよな
資金取るのは個人の意欲だけじゃなくて、お金のある人を納得させる理屈が必要で、少し前までのRustは少なくとも数値計算の分野でそれが出来る言語ではなかったと思う
583:デフォルトの名無しさん
24/04/08 16:39:42.51 9qnuy4NE.net
てかrustユーザーってnvidiaのcudaサポートの酷さにガチギレするような奴ばっかでしょ。
そんなんで数値計算ライブラリが入るわけがない。
584:デフォルトの名無しさん
24/04/08 17:11:27.78 7wfBslr8.net
初心者向けのSimplified Rustと、
c/c++ライブラリバインドを強化したAdaptor Rustあたりは欲しいなぁ。
Safe Rustじゃ難しそうだし。
585:デフォルトの名無しさん
24/04/08 17:54:43.90 JoalanBl.net
ゼロからプログラム書くならSafe rustが一番簡単だよ
こいつに従っているだけで割と見通しが良くてバグりにくいコードが書ける
まあGoto 多用しているようなFortran おじいちゃんとは相性が悪いかもしれんが
586:デフォルトの名無しさん
24/04/08 19:05:28.67 ifgKIXku.net
C++を完全に理解した者のための言語それがRust
故に誰も
587:デフォルトの名無しさん
24/04/08 20:39:36.28 cqL1RV99.net
C++を使ったことないけど
Rustで困ったことないな
Rust理解で必要なことはポインタとスタックとヒープとRAIIくらいかな
所有権は単なるヒープ解放責任だから大したことではない
所有権を他へ譲渡しないとRAIIによって自動解放されるというだけの話
非常にシンプル
588:デフォルトの名無しさん
24/04/08 21:02:11.65 YkdU7kgc.net
所有権を複製するとか間違った事を言い続けてる人が良く言うわw
589:デフォルトの名無しさん
24/04/09 00:09:53.71 pItuq1gX.net
>>588
それは俺じゃないぞ
590:デフォルトの名無しさん
24/04/09 02:45:12.09 hsAXyuRl.net
>>589
誰だよお前。
591:デフォルトの名無しさん
24/04/09 09:16:17.69 OXfvzIgi.net
今のところ>>458が一番面白い
592:デフォルトの名無しさん
24/04/09 10:16:36.65 Po0ZJOeT.net
昭和ギャグ？
ちょっと意味がわかりません
593:デフォルトの名無しさん
24/04/09 11:01:29.74 cj+QXWpg.net
今どきイジりを面白いとか、イジメ肯定派かよ。
594:デフォルトの名無しさん
24/04/09 13:18:19.32 9AcR/8+u.net
進化論肯定派じゃないの
人を淘汰することを志している
595:デフォルトの名無しさん
24/04/09 17:18:23.86 +rnauHt3.net
ｶﾁｮｰ「???」じゃなくて
ｶﾁｮｰ「で?」なら共感できたかも
596:デフォルトの名無しさん
24/04/10 01:14:02.81 /k7xUJZy.net
rustだいぶ分かってきたつもりだけど
ライフタイムとジェネリクスとクロージャが一斉に襲いかかってくると無理
好きな言語だけど世の中にはプログラミング言語に強い興味を示す奴が稀なので厳しいなぁと感じる
597:デフォルトの名無しさん
24/04/10 08:03:56.89 ltqciZ07.net
>>592
進捗報告相手が課長というのが昭和かもな
そんな会社で働きたくない
598:デフォルトの名無しさん
24/04/10 11:01:40.54 5Js//1cu.net
>>596
moonbit くらいならどうかな？
599:デフォルトの名無しさん
24/04/10 11:35:35.51 AS+TZoYk.net
>>596
それぞれ理解していれば組み合わさって困ることはないんじゃないかな
Rust特有のライフタイム注釈は構造体なら「参照を持ってるよ」の印で関数なら「この引数の参照は返り値の参照に対応するよ」の印であとは有効期間を満たすだけなど
600:デフォルトの名無しさん
24/04/10 16:55:22.63 yZA7mDLP.net
Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか？めんどいんですけど
601:デフォルトの名無しさん
24/04/10 17:30:31.18 Fk7YBwaR.net
メソッドをそうでない普通の関数と区別するためにはなんらかのマークは要るじゃろ。
602:デフォルトの名無しさん
24/04/10 17:38:51.91 t7JkSWKp.net
self/ mut self/&self/&mut selfの区別もいるしな
self自体これ以上短くしてもよくわからん単語になるしまぁ妥当では
603:デフォルトの名無しさん
24/04/10 17:52:25.08 5Js//1cu.net
C++ の ref-qualifier とか無理のある文法だもんな。
そこに書くんか!? という変な驚きがある。
引数の一種ということにしたほうがかなり単純でよい。
実際、 C++ でも C++23 から this を明示的な引数に取れる文法が追加された｡ (deducing this)
604:デフォルトの名無しさん
24/04/10 17:58:48.34 Q64PiueS.net
RustでPython実装すりゃ良いんじゃね
605:デフォルトの名無しさん
24/04/10 18:34:01.75 3h5gXXiJ.net
>>602
普通に全部ダサいんだよなあ
何とかならなかったのかとならなかったのかとならなかったのかと…
606:デフォルトの名無しさん
24/04/10 19:34:40.80 8DE+tVvz.net
selfより短ければ良いのか、それともC++みたいに省略できてしまってどこで定義されてるのかようわからんくなるのが好きなのか
607:デフォルトの名無しさん
24/04/10 19:44:04.66 y0DX5npz.net
ぜひとも >>605 の考える最高にイケてる構文を教えてほしい
Rustを今から変えるのは無理でも、後継言語に採用されるかもしれんし
608:デフォルトの名無しさん
24/04/10 19:47:55.68 IjfZ+vUr.net
>>605
nimの関数呼び出しルール
関数名(第一引数,第二引数...)
第一引数.関数名(第二引数...)
で第一引数がself相当
が一番スマートかと。
609:デフォルトの名無しさん
24/04/10 20:06:03.20 AS+TZoYk.net
>>605
むしろ>>602はそれらの区別のためにもselfは必須と言ってるようにみえる
さらに構造体などフィールド名と関数内の変数名との区別のためにもselfは欲しい
現状のRustの仕様がベストかな
610:デフォルトの名無しさん
24/04/10 21:28:15.02 8DE+tVvz.net
selfじゃくてthisならC++マニアも納得
611:デフォルトの名無しさん
24/04/10 21:34:35.54 6SjCdg5T.net
>>608
nimを知らないけど、Rustのassociated functionもその二種類の呼び出し方法がとれる点は同じだね
Vec::push(&mut vec, 123);
(&mut vec).push(123);
vec.push(123);
この&mutを省略できてRust便利
612:デフォルトの名無しさん
24/04/10 21:37:52.75 Mpv09JwO.net
thisはたまにselfの代理で使われてるな
Rc::into_innerとか
613:デフォルトの名無しさん
24/04/10 23:19:28.12 AS+TZoYk.net
deref後のinto_inner適用と区別のため
敢えてself使わないことでメソッド呼び出し形式をできなくして
明示的にRc::into_inner呼び出しさせるパターンだね
614:デフォルトの名無しさん
24/04/10 23:45:41.84 Fk7YBwaR.net
メソッドを呼び出すことと関数の第一引数に渡すことを同一視する構文は
LISP 用に作られたオブジェクトシステム new flavors でやってた。
615:デフォルトの名無しさん
24/04/11 02:11:03.37 4f6XcC0j.net
それは同一視というか構文が1つしかないだけでは
616:デフォルトの名無しさん
24/04/11 02:14:15.06 7FNbL3Xb.net
呼び出し時には与えない引数って紛らわしくね？
617:614
24/04/11 02:45:03.24 C4qhk0zm.net
>>615
メッセージを送る構文と関数呼出しの構文の両方があって構文糖として扱える仕組みになってたという話。
new flavors の前に flavors というのがあって、それはメッセージを送る構文しかなかったのだけど
new flavors で改良 (かどうかわからんけど) された。
618:デフォルトの名無しさん
24/04/11 04:57:52.23 r6y9Ju0a.net
>>616
むしろ逆かな
target.method(arg1, arg2, ...)という
targetへのメソッドコールを実現するのを関数で表すと
method(target, arg1, arg2, ...)とする言語が多い
Rustでも同じでこのtargetをselfと書く
targetは送る側から見た視点
selfは受け取った側から見た視点
各実装は受け取った側でなされるためself
619:デフォルトの名無しさん
24/04/11 08:24:38.80 McLA6Ner.net
UFCSは第一引数を1つ目だからというだけの理由で特別扱いするのが気持ち悪いんだよな
レシーバとして扱われるなら構文上も特別であってほしい
620:デフォルトの名無しさん
24/04/11 08:39:59.21 UjbgXeUt.net
>>619
何が気持ち悪いのかさっぱりわからない
まず、全ては関数呼び出しになりそれ以外の方法はない、というのはいいよね？
次に、その関数呼び出しでのレシーバの渡し方は最初の引数になる、というのも自然だよね？
ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
621:デフォルトの名無しさん
24/04/11 08:49:57.16 azFLg2co.net
言うほどほとんどの言語がこれか？
pythonは後付けでOOPぶっこんだからただの関数の引数にSelfなんだ
これがPythonいまいちだなって思うところ
c++も似た様な理由でstaticでthis
後発で考慮する余裕あるのにそれを引っ張ってる
622:デフォルトの名無しさん
24/04/11 09:02:17.34 NXydgA7G.net
>>621
君の感性がおかしいんじゃね？
NimもZigもRustもPythonと同じ標準方式
foo(receiver, arg1, arg2, ..)
または
receiver.foo(arg1, arg2, ..)
623:デフォルトの名無しさん
24/04/11 09:02:43.98 7FNbL3Xb.net
>>618
なるほどちょっと納得した
624:デフォルトの名無しさん
24/04/11 09:11:33.28 azFLg2co.net
>>622
実質Pythonフォロワーを含めて言われても…
625:デフォルトの名無しさん
24/04/11 09:14:09.83 azFLg2co.net
C言語のときはOOPじゃなくてただの関数の第一引数に構造体を指定してた
それがOOP言語になって指定不要になった
それがまたC言語時代に逆戻り
626:デフォルトの名無しさん
24/04/11 09:15:22.73 NXydgA7G.net
>>624
何を言ってるのかわからん
文句を言うなら望ましい代案を出してみて
627:デフォルトの名無しさん
24/04/11 09:17:05.47 azFLg2co.net
あらかじめ書いておくけどreceiver.Foo()じゃないメソッドがあるのは
receiverがNullの可能性がある場合でそう設計されてただけ
628:デフォルトの名無しさん
24/04/11 09:20:43.92 NXydgA7G.net
代案を出せないってことはRustに言いがかりをつけてるだけだな
629:デフォルトの名無しさん
24/04/11 09:24:05.56 azFLg2co.net
別に他のOOP言語のように関数にマークつけてこれはこのインスタンスのメソッドですよと言えばいいだけ
その表記は時間をかけて考えたらいい
630:デフォルトの名無しさん
24/04/11 09:30:34.30 cvuvfjXO.net
>>625
レシーバは必ず必要
Goでも
func (receiver ReceiverType) Foo(引数…) {
return receiver.xxx + receiver.yyy
}
と書く
レシーバ指定不要という主張は理解できない
631:デフォルトの名無しさん
24/04/11 09:45:56.75 gYo8nOa5.net
レシーバの名前を自由につけられると人によってバラバラで読みづらいんだよな
selfなら必ず揃うし予約語としてシンタックスハイライトされるのもいい
632:デフォルトの名無しさん
24/04/11 09:51:28.66 azFLg2co.net
いやいやｗ
無知って怖いねとしか…
633:デフォルトの名無しさん
24/04/11 09:52:17.20 azFLg2co.net
>>630
634:デフォルトの名無しさん
24/04/11 10:19:57.47 UmgPKlgb.net
UFCSはフリー関数でもメソッド風に呼び出せる機能のことでRustやその他多くの言語のメソッド呼び出しとは似て非なるもの
>>619はそれを分かった上でNimについて書いてるのかもしれないけど>>620や>>622は明らかに誤解してる
635:デフォルトの名無しさん
24/04/11 10:33:59.60 Nlu6ipA3.net
>>631
そう言われるとRustの仕様がベストなのかな
レシーバに名前を付けないと名前空間の分離ができなくて
レシーバに名前を自由に付けられると読みづらくて
636:デフォルトの名無しさん
24/04/11 11:00:57.82 azFLg2co.net
IDころころお爺さんは明らかに話を理解できないな
637:デフォルトの名無しさん
24/04/11 11:23:46.71 CaCoKmZ3.net
Rustは小文字selfが値、大文字Selfが型を示していて使いやすいよな
型指定にSelfやSelf::Itemなど使えるだけでなく
Self::CONSTANT_NAMEやSelf::function_without_self()などの呼び出しもできる
Selfによって自分自身であるとわかりコードが読みやすい
型名変更の影響も受けず読みやすいメンテしやすい
ダメな言語だと以下のダメなパターンがある
・Selfの代わりに型名を書かなくてはいけない言語 (自分自身だとわかりにくくメンテ性も悪い)
・Selfの代わりにself(やthis)を用いてしまう言語 (値と型の区別がつかない)
・Selfを使わずに名前空間の区別がない言語 (間違いが起きやすく自分自身だとわかりくくメンテ性が悪い)
638:デフォルトの名無しさん
24/04/11 11:57:27.19 17a5lmDN.net
関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな……
639:デフォルトの名無しさん
24/04/11 11:57:34.08 6x2Zth+c.net
複オジは見えてる範囲が狭過ぎる
だから長文になればなるほど勘違い度や害悪度が高まる
640:デフォルトの名無しさん
24/04/11 12:47:47.10 ZruVErXu.net
自分が使ってきた特殊な仕様の言語に慣れ親しんでいると
一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない
Rustを叩く前に視野を広く持つべきだな
Rustの仕様はよく考えられ機能的に洗練されている
641:デフォルトの名無しさん
24/04/11 12:59:00.66 AZdBjU6j.net
>>640
Rustに無いからといってUFCS叩くのはさすがにアホかと。
642:デフォルトの名無しさん
24/04/11 13:15:55.80 4f6XcC0j.net
そんなことよりError::sourceの戻り値に'static要求されるのってなんでなん
643:デフォルトの名無しさん
24/04/11 15:57:20.01 R8LZpbjl.net
>>642
エラー返す時に参照してるリソースをつかんだままにしたくないからじゃない
644:デフォルトの名無しさん
24/04/11 15:59:23.14 v1XXdeLJ.net
くだらないレスは頻繁にするのにまともな質問が来ると急に黙るの面白い
645:デフォルトの名無しさん
24/04/11 16:41:03.54 KhnNkcJ8.net
まともな質問にいつものノリで適当に答えて嘘だったら良くないしね
646:デフォルトの名無しさん
24/04/11 17:01:08.25 TWMZ6q+3.net
そっか
俺の答えも間違ってたしな
正しくはdowncastのために必要らしい
詳しくはfix_errorのRFC見て
647:デフォルトの名無しさん
24/04/11 17:41:58.72 McIjmFt1.net
Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環？
648:デフォルトの名無しさん
24/04/11 17:48:38.15 McIjmFt1.net
動き出した
サーバー側の問題っぽいな
URLﾘﾝｸ(github.com)
649:デフォルトの名無しさん
24/04/11 18:55:11.06 4f6XcC0j.net
downcastなんて別にしないからいらねーよって思ったけど
そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか
ヒントありがとう
650:デフォルトの名無しさん
24/04/11 19:06:32.42 VFM//2+p.net
複おじはc++も使ってなかったんだな
651:デフォルトの名無しさん
24/04/11 20:25:23.50 81s1BzdD.net
>>641
UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。
Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。
652:デフォルトの名無しさん
24/04/11 20:52:12.80 AZdBjU6j.net
>>651
UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。
それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。
653:デフォルトの名無しさん
24/04/11 21:02:41.98 81s1BzdD.net
>>652
Rustでメソッド呼び出しは拡張困難ではなく、拡張用トレイトを自由に新たに用意することで、他への汚染を招かずに安全に拡張できる。
そのためUFCSのような愚かな方式を採る必要がない。
654:デフォルトの名無しさん
24/04/11 21:15:01.99 mF0oHAZm.net
答えを教えてもらっているのにヒントありがとうというオジさんw
655:デフォルトの名無しさん
24/04/11 21:16:29.71 2g+gCFiF.net
メソッド名空間www
656:デフォルトの名無しさん
24/04/11 21:54:13.50 AZdBjU6j.net
>>653
それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。
もっとUFCSならではの問題点を指摘してくれ。
せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。
657:デフォルトの名無しさん
24/04/11 23:54:23.85 A4VQpdsZ.net
アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ
アラビア語おすすめ
658:デフォルトの名無しさん
24/04/12 00:40:05.77 fvGN/jjJ.net
>>656
それはメソッド呼び出しのメリット
モジュール化や結合の観点からも最初からメソッド定義していくのが正しい
UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる
具体的には歴史的な負の遺産でボロボロなC++が該当する
そのためC++ではUFCSを導入しようと今も悪あがきをしている
ほとんどの言語にUFCSがないのはそんなものを必要としないためだ
659:デフォルトの名無しさん
24/04/12 00:44:02.94 tVNhffJ+.net
モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ
RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい
660:デフォルトの名無しさん
24/04/12 02:47:17.34 DYhqcHWh.net
それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない
AddAssignやSubやShlなど多くの演算は非対称
661:デフォルトの名無しさん
24/04/12 04:21:38.21 tVNhffJ+.net
いや別にSubでもDivでも左のみに紐づいているのはキモい
662:デフォルトの名無しさん
24/04/12 04:49:28.47 rUQyilnM.net
>>658
やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。
例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ？
グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。
663:デフォルトの名無しさん
24/04/12 05:26:42.25 CIaMPOtu.net
>>662
トレイルではなくトレイト
トレイトは名前空間を用意するものというより、トレイトをuseすることでそのトレイトにより実装されるメソッドが使えるようになるだけ
664:デフォルトの名無しさん
24/04/12 07:31:40.11 rUQyilnM.net
>>663
だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。
665:デフォルトの名無しさん
24/04/12 12:27:40.08 OadUyd3M.net
>>659
＞モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ
同意
666:デフォルトの名無しさん
24/04/12 12:33:34.40 rAepnpk2.net
>>664
Rustはそうやってきちんと管理できつつ便利でいいよなー
他の言語も導入すればいいのに
667:デフォルトの名無しさん
24/04/12 12:43:39.99 6xQx5uEa.net
>>665
オブジェクト指向を全否定するキチガイか
クラスのある言語もクラスのないGoやRustなどの言語も
一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
668:デフォルトの名無しさん
24/04/12 13:04:32.76 qd6Rxygz.net
とりあえず感覚で一行目から罵倒する人
669:デフォルトの名無しさん
24/04/12 15:24:23.71 XC+pkKeZ.net
>>667
>一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
オブジェクト指向前提思考？
670:デフォルトの名無しさん
24/04/12 16:22:22.83 RDQRwL9V.net
>ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
からの
>UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
schizoかな？
671:デフォルトの名無しさん
24/04/12 17:02:05.38 oSrgtnnN.net
それらの件でもRustの仕様が優秀すぎ
672:デフォルトの名無しさん
24/04/12 20:51:13.79 NYkXEvAJ.net
>>670
虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ
673:デフォルトの名無しさん
24/04/12 22:18:23.28 HgYc1X5O.net
おじいちゃんは昼だけ起きてて
夕方を過ぎると寝てしまう
674:デフォルトの名無しさん
24/04/12 22:50:23.70 3nYhUDoK.net
RUSTがトレンドに！！
675:デフォルトの名無しさん
24/04/12 23:58:18.71 lpyrPPhz.net
>>667
つジェネリック
676:デフォルトの名無しさん
24/04/13 04:39:15.20 0YGiYUZr.net
ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか
677:デフォルトの名無しさん
24/04/13 07:36:48.57 beXAxXwF.net
トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ？
柔軟性のために外延性は欲しいところ。
678:デフォルトの名無しさん
24/04/13 08:07:59.96 S51MIqUj.net
異なる型間の共通項をトレイトとして切り出すだけでよく
コードを美しく整理して保守性を高めやすい
679:デフォルトの名無しさん
24/04/13 13:32:34.24 OrtqC7Lq.net
敬称ないせいで苦労してるんだってな
680:デフォルトの名無しさん
24/04/13 13:36:34.54 F3jinTSj.net
143 デフォルトの名無しさん 2024/04/07(日) 19:27
純関数型言語でなくても
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない
それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている
681:デフォルトの名無しさん
24/04/13 16:56:52.49 L60jXWVE.net
継承がなくても構造体にメソッドついてたら実質クラスだろ
関数に構造体渡してたらそれはクラスじゃないけど
682:デフォルトの名無しさん
24/04/14 23:56:10.96 RjsA2T1t.net
>>681
構造体にメソッドが付くことはカプセル化と言う
クラス＝カプセル化＋実装継承 なのでクラスとカプセル化は異なる
このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった
実装継承とは具体型が別の具体型を継承することを指す
クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる
正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する
つまりクラスを完全に排除できるためモダンな言語群にクラスはない
683:デフォルトの名無しさん
24/04/15 00:05:55.58 R9iMDmBn.net
用語も色々。
Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、
JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。
極論すればクラスと名付けたものがクラス。
Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。
C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、
クラスとは何かを定義せずにクラスかどうかを論じても無意味。
684:デフォルトの名無しさん
24/04/15 00:26:07.32 rd9697wK.net
型クラスとクラスは全く異なるので混乱しない
クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す
JavaScriptはプロトタイプを親として実装継承するためクラス
一方でRustにクラスはない
685:デフォルトの名無しさん
24/04/15 01:47:00.44 YLFAz6O4.net
クラスとは何か？継承とは何か？
こういう基本的な概念を特定言語の実装から離れて理解しようとしない限り何を言っても虚しい
>>681が一番まとも
686:デフォルトの名無しさん
24/04/15 01:58:25.85 CPtYka/u.net
話は非常に単純
具体的な型から具体的な型への継承が実装継承でこれがよくない
classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承
interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない
最近の言語がclassのみ採用しなかった理由はその違い
687:デフォルトの名無しさん
24/04/15 02:39:20.65 zOelqs9y.net
RustにはJavaのクラスはありません
RustはJavaではないからです
あたまいいね
688:デフォルトの名無しさん
24/04/15 03:16:04.95 0QcDOjSQ.net
Javaの生みの親であるJames Goslingも、
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」に対して、
「クラスを除外するでしょうね」と答えている。
その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。
689:デフォルトの名無しさん
24/04/15 08:31:26.40 Mqs/ngjj.net
クラスのようなものでいいよ
690:デフォルトの名無しさん
24/04/15 10:16:50.96 dcBtWsLv.net
バカの一つ覚えの相手をしても時間の無駄
691:デフォルトの名無しさん
24/04/15 12:54:52.68 f4iHJAq/.net
クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな
692:デフォルトの名無しさん
24/04/15 21:09:43.00 97bFGSba.net
それは単に使い分けが出来ない馬鹿な子向けの説明だぞ
693:デフォルトの名無しさん
24/04/16 07:27:41.72 10PaZXAR.net
>>691
言語仕様としてあった方が良いということ。
694:デフォルトの名無しさん
24/04/16 07:42:24.51 KU96szRc.net
馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ
695:デフォルトの名無しさん
24/04/16 08:43:42.78 OvO8gS8m.net
Javaの生みの親も言ってるようにクラス継承の機能はない方がいい
なくても困らない
あると問題を引き起こす
696:デフォルトの名無しさん
24/04/16 09:30:25.53 YlYBNC7y.net
そういうのは話半分に聞いておけばいいよ
nullを使ったのは失敗だったとか
後からそれらしいことを言ってるだけ
javaはクラスと継承が無くなったらまともに機能しない
interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず
697:デフォルトの名無しさん
24/04/16 09:50:49.42 pgei3+18.net
>>696
interfaceにデフォルト実装を後から入れたので問題なくなった
そうなるとclass継承は不要
698:デフォルトの名無しさん
24/04/16 09:55:41.24 YlYBNC7y.net
最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから
今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって
後から○○無くせばよかったと言うのは誤りで浅はか
NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ
699:デフォルトの名無しさん
24/04/16 10:21:05.77 pgei3+18.net
今となってはclass継承は廃止でいい
700:デフォルトの名無しさん
24/04/16 11:59:36.87 NkOUpCFP.net
インターフェイスにも集合で言うところの外延性は欲しいところ。
701:デフォルトの名無しさん
24/04/16 13:49:22.28 DzgCvS5T.net
そういうの使いたいならTSがいいよ
702:デフォルトの名無しさん
24/04/16 14:56:34.55 vP0l1V0c.net
具体的なデメリットって何なの？
703:デフォルトの名無しさん
24/04/16 15:29:25.10 ePcpSD5e.net
ダサい
704:デフォルトの名無しさん
24/04/16 20:45:11.55 scEyspJl.net
そういう感覚的なもの？
705:デフォルトの名無しさん
24/04/16 22:20:54.32 pbIQ4i0L.net
基底クラスで保証してる内部条件を継承クラスで壊されやすい
Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど
C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う
古い知識だから最近の動向は知らない
706:デフォルトの名無しさん
24/04/17 08:15:23.25 eua5YI/M.net
Unreal EngineがRist対応するんだってね
707:デフォルトの名無しさん
24/04/17 16:42:11.69 eua5YI/M.net
Ristってなんだ、Rustだた
708:デフォルトの名無しさん
24/04/17 21:06:33.89 ZcFRYo3q.net
Rast
Rist
Rest
Rost
709:デフォルトの名無しさん
24/04/17 21:31:42.40 O0zLY4aF.net
Risp
710:デフォルトの名無しさん
24/04/18 23:48:18.11 mul2o/Jt.net
>>706
時代の流れだな
711:デフォルトの名無しさん
24/04/19 17:19:41.25 QdSz4ItG.net
隙間作って床下チェスト収納ってできなくなった？動画みてるけどうまくできん
712:デフォルトの名無しさん
24/04/20 17:39:26.03 pCmD4UWo.net
shift-jiｓのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない
全部読んでデコードして\nで切り分けるしかないの？
713:デフォルトの名無しさん
24/04/20 17:53:01.46 AAPU1iqE.net
read_lineはutf-8じゃないと無理だけどread_untilならバイト列で１行ずつ取れそう
714:デフォルトの名無しさん
24/04/20 22:11:31.95 pZNdwQSZ.net
>>712
encoding_rs_io::DecodeReaderBytesBuilderでsjisをdecodeするreaderを作る
あとはreader.lines()で同じ
715:デフォルトの名無しさん
24/04/20 22:28:20.55 pZNdwQSZ.net
std::io::BufReader::new(encoding_rs_io::DecodeReaderBytesBuilder::new().encoding(Some(encoding_rs::SHIFT_JIS)).build(std::fs::File::open(SJIS_FILE)?)).lines()
716:デフォルトの名無しさん
24/04/21 07:15:48.69 QKVewSeW.net
BufReaderもFile::openもそのまま使える点がいいね
717:デフォルトの名無しさん
24/04/21 10:23:00.52 Be3/0qjS.net
>>715
ありがとうございます
動作確認しました
ちょっと仕組みがむずかしいですね
718:デフォルトの名無しさん
24/04/21 18:25:05.39 GAd5jyBU.net
decoderが挟まるだけだよ
// UTF8の場合
let file = File::open(path)?;
let reader = BufReader::new(file);
for line in reader.lines() {
// SJISの場合
let file = File::open(path)?;
let decoder = DecodeReaderBytesBuilder::new()
.encoding(Some(SHIFT_JIS))
.build(file);
let reader = BufReader::new(decoder);
for line in reader.lines() {
719:デフォルトの名無しさん
24/04/22 06:09:19.12 kZ9sSSe5.net
バッファリングせず丸ごと贅沢にメモリ使っていいなら単純
let bytes = fs::read(path)?;
let (s, _, _) = SHIFT_JIS.decode(&bytes);
let reader = BufReader::new(s.as_bytes());
for line in reader.lines() {
720:デフォルトの名無しさん
24/04/22 20:07:02.52 g+YSHIF5.net
コマンドラインからファイル名取るようにしたらパニック
windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい
721:デフォルトの名無しさん
24/04/22 20:46:10.62 ZfX6SpnE.net
何を言ってんのw
722:デフォルトの名無しさん
24/04/22 21:19:42.71 g+YSHIF5.net
知らないとそういう反応するんだろうけど
std::env::args_osを使ってOsStringを取って対処する必要があるんだよ
勉強になっただろ？
723:デフォルトの名無しさん
24/04/22 21:24:48.26 g+YSHIF5.net
日本人だから日本語名が付いたファイルを扱う機会に恵まれてるからこういうことに出会える
アメリカ人だったらこういうのに出会わないでコーディングしてリリースしてるだろう
世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されている
724:デフォルトの名無しさん
24/04/22 23:12:07.98 ljq3CdpU.net
>>722
チュートリアルレベルの基礎を
バッドノウハウwとか
積み重ねでいかないといけないwとか
言ってるから何言ってんのwになる
725:デフォルトの名無しさん
24/04/22 23:32:38.83 cr/ZTax6.net
>>720
Rustのパニックはどの関数で何をした時に発生するかすべてドキュメントに明記されてるのでパニックはプログラミングした側に問題がある
さらにパニックがソースコードの何行目のどの場所で起きたのかもわかるのですぐにそのバクを調査できる
まずは基礎知識を身につけよう
>>722
std::env::argsのドキュメントにどういう時にパニックが起きるか書いてある
さらに対処方法はargs_osを使えと明記されている
ドキュメントを見よう
726:デフォルトの名無しさん
24/04/22 23:35:51.77 g+YSHIF5.net
>>724-725
こういう低能がありがたがるんだろうな
信者としか言いようがないｗ
727:デフォルトの名無しさん
24/04/22 23:42:55.88 g+YSHIF5.net
リリースした後の実行時のpanicを有り難がる信者
Rustのライブラリの思想がいまいち馴染みにくいと言うか素人が作るとこうなりますと言う見本
728:デフォルトの名無しさん
24/04/22 23:57:01.81 kZ9sSSe5.net
>>722
Rustではそんな個別の知識を知らなくてもpanicさせた関数が分かるから
その関数のドキュメントのpanicの項目を見れば明記されてる
他の言語と比べても良い環境
729:デフォルトの名無しさん
24/04/23 00:03:29.34 aheV4X/O.net
馬鹿と話しててもらちが開かない
世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されているのは事実
お前らそれを一個一個プルリク送ったりしてるのか？
730:デフォルトの名無しさん
24/04/23 00:13:45.98 aheV4X/O.net
所有権とか導入してバグを静的に弾こうとしてる割にはこういうところではガバガバ
世界中で英語じゃないwindows環境でpanicが起こるコードが蔓延してる
非合理的
731:デフォルトの名無しさん
24/04/23 00:34:48.42 tNw43TTr.net
そんなことより The Embedded Rust 読み始めたんです。
冒頭からリンカで割り込みベクタマップの取り方やら panic 無効にしての main 関数導入やら、HAL は自分でこさえるんだよね？と言わんばかりの内容。
おおむかしのMCU開発環境みたいで嫌いじゃないけど、arch 対応してないと敷居高いねこれ。
732:デフォルトの名無しさん
24/04/23 09:44:34.04 SlAsUTut.net
公式チュートリアルすらまともに読めないお馬鹿さんは自分が使う道具を間違えててもそれを言語のせいにしたがる
プラスドライバーを使うべき状況でマイナスドライバーを使って使いにくいじゃねーかこんな道具は非合理的などと言い出す
ヤバすぎね？
733:デフォルトの名無しさん
24/04/23 11:06:58.83 PMnHeW+x.net
>>725
なんでコンパイル時にエラーにできないんだろう？
Rustのポリシーからすれば安全優先でargs_osだけにしてargsは削除すべきでは？
c++じゃあるまいに、コマンドラインのデータが常に正しいunicodeだと信用するプログラムを書けるとか、セキュリティーホールになりかねんと思うけど。
734:デフォルトの名無しさん
24/04/23 12:06:18.33 cfnwg7MD.net
panicは安全ですヨ
735:デフォルトの名無しさん
24/04/23 12:11:09.83 r76fNggU.net
>>734
緊急停止して「安全ですよ」はちょっと……
736:デフォルトの名無しさん
24/04/23 12:14:00.43 jXQ0V2HY.net
>>733
セキュリティホールにならない
異常データに対して止まり動作を続けない
737:デフォルトの名無しさん
24/04/23 15:43:54.29 3Xc7JqWG.net
>>733
>なんでコンパイル時にエラーにできないんだろう？
出来るわけないだろw
実行時に与えられる外部入力をコンパイル時にどうやって判定するんだよw
バカすぎる
738:デフォルトの名無しさん
24/04/23 16:19:44.91 1rwyWp7B.net
しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス
もう治る見込みはないからargs_os()を使おうねってだけだけど
739:デフォルトの名無しさん
24/04/23 16:52:58.90 Kbb8det7.net
一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど
特に提案もなさそうだし誰も困ってないんじゃないかな
そもそもほとんどのケースでclapとか使うだろうし
740:デフォルトの名無しさん
24/04/23 17:20:16.94 jbFpiEtG.net
>>733
＞>>725
＞なんでコンパイル時にエラーにできないんだろう？
むしろ何でできると思ってるんだろう。謎
741:デフォルトの名無しさん
24/04/23 17:22:13.22 SM3r9/qB.net
環境変数もvarとvar_osがあるから慣れろとしか言えない
OS標準が全部utf-8になる未来もありえるし
742:デフォルトの名無しさん
24/04/23 17:48:20.12 x1LuxzDZ.net
>>741
紛らわしいけどvar/var_osとvars/vars_osは別物だよ
varはinvalid UTF-8でもエラーハンドリング可
varsはpanic
argsは引数にUTF-8以外はダメだよって前提で使える余地がまだあるけど
varsはそんな前提をおける状況はほぼなくてよりたちが悪い
743:デフォルトの名無しさん
24/04/23 18:06:35.01 DF4k8ks3.net
>>741
>OS標準が全部utf-8になる未来もありえるし
10年前のその未来予想が大外れしてるから今となっては設計ミスとしか言いようがない
もう10年経ったとしても状況は変わらないと思う
744:デフォルトの名無しさん
24/04/23 19:06:07.68 rRGY+2Qg.net
>>732
公式チュートリアルまともに読めるならC++で良いからな
745:デフォルトの名無しさん
24/04/23 20:01:34.96 +uJAOtCC.net
よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？
どう考えてもstd::env::argsを非推奨にしろとは思うけどね
欧米人がつくるとこんなことになるんだ
普通は2種類の扱いがある
・実行環境に合わせて自動的に内部での標準形式に変換
か
・何もしない
何もしないならOSから受け取ったままOSに渡して置けば大体問題はない
第三の愚策がRust
受け取ったままそのままOSに渡してもコケる
Rustは何もしないように見えるけど何かしてるからコケるのでは？
746:デフォルトの名無しさん
24/04/23 20:52:29.82 xiHKhQOf.net
>>745
間違いだらけだな
世界の標準はUTF8
ウェブももちろんUTF8
RustもUTF8
Rustがこの件でコケることはない
きちんと各関数の仕様が明記されていて常に正確に動作している
747:デフォルトの名無しさん
24/04/23 21:05:41.35 ykVY4Q8s.net
Rustのパニックは綺麗なパニック
いいね？
748:デフォルトの名無しさん
24/04/23 21:12:51.81 xiHKhQOf.net
>>747
一般的なパニックは色んな意味合いがあるけど
Rustでのパニックは関数ドキュメントに明記されている想定のことが起きた
ライブラリ関数の作成者はパニックを発生させる時の条件をドキュメントに明記しなければならない
だからそれを利用する各プログラマーにとっても想定内のことのみパニックが起きる
749:デフォルトの名無しさん
24/04/23 23:35:29.98 v0qt2UCV.net
>>745
勘違いしてることが多すぎてもう笑うしかないwww
750:デフォルトの名無しさん
24/04/23 23:41:39.78 x1LuxzDZ.net
>>745
>よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？
30年以上前にUCS-2がWindowsやJavaに採用された時代のことを言ってるのかな？
(UTF-16と違ってUCS-2は固定幅なので今でもまだ使い所はあるけど)
↓これが15年くらい前のUTF-16に対する一般的な認識
URLﾘﾝｸ(softwareengineering.stackexchange.com)
751:デフォルトの名無しさん
24/04/24 00:43:41.33 5EZEwmZn.net
utf-16はUnicode 2.0（1996年7月）のサロゲートペア導入でutf-8に逆転されたな
しばらくはBMPしか使われなかったから耐えてたけど
1990代前半に始動したJavaは運が悪かった
752:デフォルトの名無しさん
24/04/24 01:21:01.63 YBOQY0J9.net
>>749
そう書きながら何もまともなレスすらできないレス乞食
753:デフォルトの名無しさん
24/04/24 01:23:24.26 YBOQY0J9.net
Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど
Rustが正しいRustが正しいと繰り返すばかり
754:デフォルトの名無しさん
24/04/24 12:36:38.15 A+y4lqIx.net
>>737 >>740
windows環境とかunicode以外が混ざる環境でargをコンパイルエラーにできないのかね。
そもそもargは廃止していい。
755:デフォルトの名無しさん
24/04/24 12:47:56.41 HIQuAly7.net
すげーどうでもいい話だな
756:デフォルトの名無しさん
24/04/24 12:47:57.96 A+y4lqIx.net
>>746
なるほど。
「RustはWindowsをケアする気が無い」
ということですか。
757:デフォルトの名無しさん
24/04/24 12:58:45.05 GRRi3Rgr.net
>>754
Windowsでも設定すればUTF-8になるしLinuxだってUTF-8以外に自由に変えられるわけだから、そんな判定は不可能
まぁ廃止していいには同意するけども
758:デフォルトの名無しさん
24/04/24 13:18:14.84 meF6WBmz.net
Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。
今の Linux はおおよそ UTF-8 で統一されているけど規約で縛っているだけで、 OS としてはバイナリ単位で素通し。
保証としてはあてにならん。
759:デフォルトの名無しさん
24/04/24 13:18:30.26 HIQuAly7.net
コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。
760:デフォルトの名無しさん
24/04/24 14:25:14.78 up+AoO7k.net
>>754
無知にもほどがある！
unicodeとUTF-8が区別できない
Windowsに限らずLinuxでもmacOSでも非UTF-8の引数や環境変数が使われる可能性があるのは同じなんだがそんな常識を知らない
761:デフォルトの名無しさん
24/04/24 15:25:54.44 65hs2nTl.net
>>760
そんなんだったらなおさらのこと、Rustの安全指向に従ってargs_osだけにすべきで、argsは廃止にすべきだろ。
Rustはメモリ安全しか興味無いんかね。
762:デフォルトの名無しさん
24/04/24 15:53:48.65 gLaneKFw.net
保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。
763:デフォルトの名無しさん
24/04/24 16:02:42.64 zvblwt+/.net
どうでもいい話でもめてるな
Rustはすべて提供してドキュメントにそるぞれ明記しているのだから使う側の各自の問題
こちらはUTF8環境でしか使われないのでargs()のみ利用している
764:デフォルトの名無しさん
24/04/24 16:05:40.76 AQu1Dr63.net
URLﾘﾝｸ(github.com)
関係する議論はこのあたりかな
もともとはargs/varsをパニックさせずに無視するか置換してほしいって要望だったが
無視や置換はセキュリティ上問題になる可能性があるので却下
varsは将来的にdeprecatedにするかもと言っている
なんでargsもdeprecatedにすべきだろって提案すれば通る可能性はあるかもね
765:デフォルトの名無しさん
24/04/24 16:26:19.27 MMJHgfnp.net
正しく使え論は暴論だな
それが許されるならスマートポインタやGCは出ずみんな今でも生ポインタを使ってる
766:デフォルトの名無しさん
24/04/24 16:40:56.16 zvblwt+/.net
>>765
生ポインタは安全ではないから全く違う
argsは常に安全
767:デフォルトの名無しさん
24/04/24 16:44:59.20 MMJHgfnp.net
常に自動変換したほうが安全だけどな
開発者が特別コードを書く必要もない
768:デフォルトの名無しさん
24/04/24 17:05:56.77 MMdiZvh6.net
Rustはファイル名も自動変換なんかしていないように
変換するかどうかは各自の自由裁量であるところが非常に良い点だよ
自分の好みと合わないからといって批判している人たちは頭がおかしいので相手にしても無駄なのだろうけど
769:デフォルトの名無しさん
24/04/24 17:17:38.15 MMJHgfnp.net
>>768
ここまで読んで何の話をしているのか理解できないならRust使うのは辞めたほうがいい
770:デフォルトの名無しさん
24/04/24 17:21:01.52 MMJHgfnp.net
ファイルの引数だけ標準では何もしない
普通のキーボード入力などでは変換している
771:デフォルトの名無しさん
24/04/24 17:23:28.05 D1bqYp6J.net
>>770
え？？
772:デフォルトの名無しさん
24/04/24 18:26:14.33 AQu1Dr63.net
>>768
自動変換は正直意味不明だが（変換元の文字コードが判定不能なのに何を変換するのか？）
argsは今RFC出したらResultにしろって突っ込まれると思うし
1.0であまり深く考えずに入れちゃった気はするよ
773:デフォルトの名無しさん
24/04/24 18:50:02.66 5HDpMmrb.net
Resultとかのハンドリングが面倒な人向けの簡便方法として用意されてるのでそれはないと思う
argsじゃなくてargs_utf8onlyとか名前をダサくして
逆にargs_osを元のargsに戻しとけば
リファレンスをよく読まない人たちがつまづく可能性を下げられる
774:デフォルトの名無しさん
24/04/24 19:00:18.55 65hs2nTl.net
こういうのを見ると、RustのデザイナーはRustに求められているのがなんなのか理解できていないと思うわな。
Rustは雇われコーダー用Safe Rustのニーズがほとんどで、Unsafe Rustとかのニーズは無いと思うがね。
775:デフォルトの名無しさん
24/04/24 19:01:34.27 MMJHgfnp.net
>>772
自動変換が本当に意味不明ならここまでの話が見えてないとしか言いようがない
776:デフォルトの名無しさん
24/04/24 19:14:39.18 9A8KMAyG.net
自動変換とかそんなアホなこと言ってるのはあんただけやで
そんなものは無いし必要ない
777:デフォルトの名無しさん
24/04/24 19:18:07.57 MMJHgfnp.net
こいつOsStringの概念が分かってないのか
本当に知能レベルが低すぎる
778:デフォルトの名無しさん
24/04/24 19:45:20.62 AQu1Dr63.net
OsStringはOSから渡されたバイト列をそのまま格納するだけで
EUC-JP環境ならEUC-JPバイト列がそのまま入るし何も変換されたりしないが…
779:デフォルトの名無しさん
24/04/24 19:49:39.48 MMJHgfnp.net
想像力が欠如しているか頭がおかしいか指示待ち人間だからそういう幼稚なレスになる
結局内部で使う場合は簡単にutf8に変換してる
なにからutf8に変化するか指示も必要がない
ただのボイラープレート
780:デフォルトの名無しさん
24/04/24 19:58:53.67 ArOBrbBE.net
>>777
自動変換なんてものはない
むしろ自動変換を避けるために用意されているのがOsString
もちろん自動変換は行われない
781:デフォルトの名無しさん
24/04/24 20:02:00.63 MMJHgfnp.net
人間じゃなくて壊れたロボットに話しているようだな
いくつになろうとこんなダメな人間になってはいけないな
782:デフォルトの名無しさん
24/04/24 20:16:20.94 il94IOIF.net
ぼきのかんがえたさいきょうのげんごにはstring<encoding>とchar<encoding>があって
どんなエンコーディングの文字列でも統一的に扱うことができましゅ
Rustもまだまだでしゅね
783:デフォルトの名無しさん
24/04/24 20:44:42.25 xJ62MSkB.net
ほとんどの環境がWebも含めてUTF8に統一となったからRustのstr/String内部表現がUTF8であるのは合理的といえる
もちろんWebでもローカルファイルでも古いものは様々な文字コードが使われているため必要なら各々で対処する必要がある
784:デフォルトの名無しさん
24/04/24 21:30:38.14 nN1vQ+Ae.net
文字コードをUTF-8とか特定のものに決め打ちにしないという点ではRubyが一番先進的だったが、あれはやりすぎで以降の言語には採用されなかったな。
785:デフォルトの名無しさん
24/04/24 21:49:41.83 tlaf0qkO.net
めちゃくちゃ間違ってるのになぜ上から目線で自信満々にレスするんだろう？
複オジは昔の自分を諭してる気分じゃないか？
786:デフォルトの名無しさん
24/04/24 22:41:53.26 MMJHgfnp.net
Rustが正しいの一点張りの狂人
787:デフォルトの名無しさん
24/04/25 01:24:12.71 fpMjozoS.net
>>0774
お前の着眼点は凄えよ！感動した。
その通り、Rustは初心者/素人 御用達言語だよ。
788:デフォルトの名無しさん
24/04/25 07:30:11.27 xsazBswH.net
おじいちゃん誰にも相手にされず寂しくなったんだねw
789:デフォルトの名無しさん
24/04/27 03:20:12.65 nhA0znD3.net
聞き分けることができない。
URLﾘﾝｸ(kanji.reader.bz)
790:デフォルトの名無しさん
24/04/27 21:28:13.67 +PotGQRe.net
crates.io が死んだときはどうすれば良い？
791:デフォルトの名無しさん
24/04/27 21:31:55.69 Ik8q0/YE.net
cargo run --offline
792:デフォルトの名無しさん
24/04/28 09:02:55.08 nHdP2D/h.net
ミラーサイトとか無いんだっけ？
793:デフォルトの名無しさん
24/04/29 14:17:37.62 wZNa4EA4.net
5chが荒らされてる時はどうすれば良い？
794:デフォルトの名無しさん
24/04/29 16:10:30.59 E9KMHG2x.net
取り敢えずアゲとけばいいんじゃね？
795:デフォルトの名無しさん
24/04/30 02:47:45.81 Mf3BeDX5.net
したらば掲示板あたりに避難所作っておけばいかが
796:デフォルトの名無しさん
24/04/30 03:09:09.37 LM/x1iE2.net
落ち着いてpanicしよう
797:デフォルトの名無しさん
24/04/30 07:30:51.55 QURaxzoQ.net
core吐きそう
798:デフォルトの名無しさん
24/05/01 23:17:38.38 7162bhB/.net
python みたいに何でも格納できる辞書型ってC++には無いよね？
799:デフォルトの名無しさん
24/05/02 02:40:57.58 VpjL2uZS.net
enumも弱いなあ
800:デフォルトの名無しさん
24/05/02 18:14:15.88 MEkFc6Ha.net
anyとmap組み合わせればいいんじゃね？
ここRustスレだけど
801:デフォルトの名無しさん
24/05/02 20:59:19.04 AhHSwsoc.net
Rustで辞書型はHashMap
複数の型を格納したかったらenumかdyn Trait
TraitをAnyにするならdowncastして使う
実際には共通に処理したい目的があるはずなのでそのTraitを用意すればdowncastしなくて済む
802:デフォルトの名無しさん
24/05/03 11:35:32.62 nLK8l4in.net
pythonみたいにだからclassがわりなのかも
p["name"]="yamada taro";
p["age"]=25;
みたいなのかな
いずれにしてもC++じゃないので
803:デフォルトの名無しさん
24/05/03 23:02:14.16 NBKkZegt.net
静的型付けの有用性が大きく上回るから
そのケースならstructにするだろうし
色んな型を横断的に扱いたいケースならtraitかな
804:デフォルトの名無しさん
24/05/04 04:23:28.64 hKZu/p+3.net
URLﾘﾝｸ(pbs.twimg.com)
805:デフォルトの名無しさん
24/05/04 09:38:11.89 dspjTuTH.net
GUI付きのポータブルなデスクトップアプリを作るとなるとどのライブラリがいいんだろ？
806:デフォルトの名無しさん
24/05/04 12:00:07.75 GFUvMaSe.net
tauri?
807:デフォルトの名無しさん
24/05/04 12:04:17.00 WHGnbjEl.net
UIはもうネイティブにこだわらなくてもいいんじゃないかな
昔からwebでしかUI提供してないソフトはゴロゴロある
808:デフォルトの名無しさん
24/05/04 15:02:31.51 UtcYFhat.net
用途次第
WebベースのUIでは反応速度が遅すぎる場合もあるしサイズが許容できない場合もある
809:デフォルトの名無しさん
24/05/04 15:44:19.83 oqQ8V/k0.net
Tauri は各環境の WebView を使うからアプリケーションの側では管理しなくてよくなり楽……
みたいな言説もあるが、 WebView の種類・バージョンを固定できないから変化に追従する必要が生じる。
そもそもウェブの世界は変遷が激しい。
Living Standard ってなんやねん。 普通の産業の感覚では信じられんようなことをしやがる。
元からウェブ系のスキルセットを持っている人が開発してメンテナンスもするってのなら
Tauri は良い選択肢だと思うが、それなりにデメリットもあるよ。
ただ、多言語 (というか Unicode) に隅々まで対応しているようなフレームワークってことになると
ウェブ系の基盤がめちゃくちゃ整備されているのでそこらへんは唯一無二だわ。
810:デフォルトの名無しさん
24/05/04 16:01:23.73 WHGnbjEl.net
即応性が必要な人は特殊な学習を手間暇というか単純に時間をかけてやって
そうでない場合は普通にhtmlで
811:デフォルトの名無しさん
24/05/04 16:07:02.02 lP1zz7vp.net
実行時のメモリ使用量の違いもかなり大きいから最初に考慮しといた方がいい
常駐の軽いアプリを作りたい場合なんかは特に
812:デフォルトの名無しさん
24/05/04 16:07:49.70 oqQ8V/k0.net
UI を記述するためのものとしては html は「普通」じゃないってことをウェブ系の人は思い出して欲しい。
元はドキュメント記述用だったのに html5 から大幅に路線変更してアプリケーション基盤として再編したけどどう見たって無茶苦茶だ。
ウェブの人が使う分にはこれでいいことは否定しないけど、 UI 記述の「普通」ではない。
813:デフォルトの名無しさん
24/05/04 16:17:08.35 5ROxz5B4.net
UI記述は宣言的なものが主流になりつつあってhtml的なものが「普通」になってきてるんだよ
MFCやCocoaやGTK的なものが今では逆に「普通」ではない
814:デフォルトの名無しさん
24/05/04 16:22:01.06 WHGnbjEl.net
html5は死んだ
もうどこにも存在しない
815:デフォルトの名無しさん
24/05/04 16:22:16.16 oqQ8V/k0.net
>>813
宣言的がどうこうとかいう問題ではなく html が「普通」ではないと述べてる。
これが良いとか悪いとか言ってるわけではないよ。
まず第一に選ぶべき「普通」だとする論を否定してる。
816:デフォルトの名無しさん
24/05/04 16:58:29.96 uscJJ1KS.net
じゃあslint?
817:デフォルトの名無しさん
24/05/04 18:05:18.74 uscJJ1KS.net
何気にslintと書いてみたが紹介動画見る限りvs codeにアドオン入れてライブプレビューしながらuiの構築がサクサク行えるのは割といいな…
tauriは環境構築する段階でnodeのバージョンやら依存ライブラリの不備でエラーがでてしまい結構時間が掛かってしまった
818:デフォルトの名無しさん
24/05/04 18:12:14.00 WHGnbjEl.net
デスクトップアプリのここにグラフ出してくださいって言われて
対応できる環境は少ない
819:デフォルトの名無しさん
24/05/04 19:49:33.93 kEH6RwVz.net
他にいい表現方法があるなら自分で作って使ってりゃいいじゃん
820:デフォルトの名無しさん
24/05/04 21:10:45.57 D/qKI/dJ.net
dioxusはあんま使われてない感じ？
821:デフォルトの名無しさん
24/05/04 23:00:15.61 ycOsd5I6.net
iced.rs
822:デフォルトの名無しさん
24/05/05 10:17:39.98 k5d9I+SK.net
>>821
Elm Architectureの設計パターンを覚える必要があるけどなかなかいいですね
823:デフォルトの名無しさん
24/05/05 18:52:14.60 k5d9I+SK.net
試してみたけど導入のカウンタの例がいきなりビルド出来ない…
バージョンの変更にドキュメントが追いついていないのは残念ですね…
824:デフォルトの名無しさん
24/05/05 23:14:06.38 XwodnLf4.net
freyaはどう？
825:デフォルトの名無しさん
24/05/09 16:51:54.63 7kteiv59.net
URLﾘﾝｸ(blog.logrocket.com)
826:デフォルトの名無しさん
24/05/09 22:53:04.47 mHp10mC4.net
一覧
URLﾘﾝｸ(lib.rs)
827:デフォルトの名無しさん
24/05/10 22:11:46.56 R/1AnZ57.net
Edera
828:デフォルトの名無しさん
24/05/11 15:19:35.98 7ZNhzC0A.net
URLﾘﾝｸ(loglog.games)
Rustはゲーム開発に向いてないという記事
C/C++を置き換えるという目標がまた一つ遠のいてしまったな
829:デフォルトの名無しさん
24/05/11 16:10:55.98 cPH9qnwk.net
Rust製ゲームエンジンが未成熟なんだから当たり前だろ😅
830:デフォルトの名無しさん
24/05/11 17:53:51.16 PRiIqFBU.net
Web開発は素早い実装と更新が必要だから
Rustは向いてない動的型言語が向いてる
みたいな記事は昔あった気がする
831:デフォルトの名無しさん
24/05/11 18:07:19.67 YXABt1rM.net
>>828
＞Rustが上手くなれば、これらの問題はすべて解消されます。
＞Rustは大規模なリファクタリングに優れているため、
＞borrowチェッカーのほとんどが自業自得の問題を解決します。
＞十分な経験を積めば、ユーザーは考えずにそれらを完全に予測し、生産的になります。
＞私はRustでさまざまなユーティリティやCLIツールを書くのをとても楽しんでいますが、
＞数行のコード以外はPythonよりも生産性が高いことがわかりました。
＞「コンパイラ駆動開発」をどこまで進めて、実際に成功できるのかと驚いたことが何度もあります。
＞Rustの最大の強みは、Rustにふさわしいコードを書いていると、物事が非常にうまくいき、
＞言語がユーザーを正しい道に導いてくれることです。
832:デフォルトの名無しさん
24/05/11 19:27:53.90 3IwrsNfE.net
>>828
この記事、ゲーム開発においていかにUnityがすばらしいかを伝えたいだけじゃん
833:デフォルトの名無しさん
24/05/12 06:43:20.67 k1k0SaOB.net
>>831
エキスパート専用、初心者お断り
というRustのいつもの欠点。
834:デフォルトの名無しさん
24/05/12 11:56:37.24 WctoPZ5N.net
ずいぶん過疎ってるけどどんぐりのせいなんかね？
835:デフォルトの名無しさん
24/05/12 12:01:04.30 ReOJFzuL.net
c++を完璧に使いこなせばrustは不要とか
いうのは欠点ではないの？
836:デフォルトの名無しさん
24/05/12 12:04:43.22 qXz8Kn6F.net
それは本人の練度の問題やんけ
837:デフォルトの名無しさん
24/05/12 12:33:17.76 ybg7kEk2.net
>>835
政府レベルで脱C/C++推奨してるのよ
ソース記事>>500
838:デフォルトの名無しさん
24/05/12 13:10:14.91 ytouLwn1.net
政府のお墨付きは強いカードだ
839: 警備員[Lv.1][新初]
24/05/12 15:34:04.32 bb5m7yXX.net
書き込めない
840:デフォルトの名無しさん
24/05/12 17:53:27.59 YZSMKp1R.net
tauriがだいぶ普及してrustに手を出す人が増えたね
いい傾向だ
841:デフォルトの名無しさん
24/05/12 23:38:46.27 dSHQVPuW.net
Tauriで流入した人の多くはフロント側 (JavaScript, TypeScript) の技術者な気がする
「ほぼRust書かずにTypeScriptでできますれ」みたいな言説も見かけるくらいだし
実際そのアプローチはありだろうしRustの認知度にも寄与するだろうけど、純Rustのフレームワークも成熟して欲しいところ
842:デフォルトの名無しさん
24/05/12 23:46:56.69 y8qBeNSM.net
ガワをRustで書いただけで何が嬉しいことでもあるんか？
私はRust使ってますって言えるから？
843:デフォルトの名無しさん
24/05/13 00:38:30.52 DdLtk1MY.net
繰り返しになるが GUI 記述として html ベース、ウェブベースの制御はそんなに筋が良くない。
根本的に GUI に対する要求が複雑だから万能を目指したフレームワークはだいたいそうなるものではあるんだが
逆に言えば万能でなくてよいときに使うにはウェブウィジットはリッチすぎる。
それとウェブ世界の living standard という体制に不信感がある。
ウェブ世界ではそれで良いにしてもどこでもその考え方が通用するわけではない。
844:デフォルトの名無しさん
24/05/13 02:02:04.61 TEcr6tUj.net
>>843
抽象的な欠点あげつらうのは役に立たないんで
今普及してるguiツールキットでおすすめと
その理由は？
845:デフォルトの名無しさん
24/05/13 02:21:51.83 DdLtk1MY.net
>>844
Tauri がウェブフレームワークに依存しているのが悪いというのは具体的ではないんか？
それが良い場合もあるので何が良いかは結局のところ場合によるとしか言えない。
そりゃそうだろ。
ウェブフレームワークを活用できることとウェブフレームワークに縛られることは表裏一体で
活用しつつ欠点から逃れるなんていう都合の良い話はないというごく普通のことを言いたいだけ。
846:デフォルトの名無しさん
24/05/13 02:31:51.65 TEcr6tUj.net
>>845
ウェブguiの欠点が全く具体的じゃないし
場合によるというなら役に立つ場合に使えばいいよね
で話はおしまいなんで何も役に立たない
話だね
847:デフォルトの名無しさん
24/05/13 03:08:04.24 DdLtk1MY.net
>>846
ウェブフレームワークの欠点なんかいまさら説明せなあかんようなこと？
役に立つ場合には使えばいいってのは当然の大前提で、
話題の流れとしては >>842 に対して「全ての」場合に Tauri がマッチするわけない
(ので色々な選択肢が出てくるに越したことは無い) って話じゃん。
これから生まれる (生まれていない) 色々なプロジェクトのどれがどういう状況で役立つかなんか事前にわかったら苦労はないわ。
色々出て来て色々消えるのも当然のことで、
Rust スレなんだから純 Rust で出来るものも有って欲しいという期待は自然なものだろ。
848:デフォルトの名無しさん
24/05/13 03:11:17.53 7xLbVW9j.net
QtレベルのフレームワークがRustで書けるならそれは嬉しいけどね
開発者のモチベが続かないような気がする
あまりにもゼロから実装しなきゃならんし
849:デフォルトの名無しさん
24/05/13 03:11:29.07 To2vSRYZ.net
デザイン系の人の大多数がウェブアプリ開発をできるからTauriは高需要でいいと思う
そもTauriはRustが主役のフレームワークじゃないんだからあーだこーだ言う必要なし
世間の知名度が上がる道具になってくれれば十分ってもんよ
850:デフォルトの名無しさん
24/05/13 03:17:53.91 +k5+3Net.net
デスクトップアプリ自体需要低下が著しいわけで、いまさら新しいGUIフレームワーク作りましたって誰も使わんわ
WPFすら将来性が怪しまれてるのに
851:デフォルトの名無しさん
24/05/13 03:26:50.43 7xLbVW9j.net
ちなみに全てゼロから実装してるGoのGUIフレームワークのgokiは6年以上開発しててまだ完成しない
描画から全部作ってる
そしてついに開発者が飽きた
同じくgoのfyneも5年ぐらい開発してこちらもOpenGLでゴリゴリやってるようだが
すでにOpenGLは時代遅れだし
すでに開発者が飽き気味
852:デフォルトの名無しさん
24/05/13 03:46:12.80 FJrB7Dif.net
ウェブまわり自体がクソってのには賛同するけど、これまでの莫大な資産や個々の経験の後押しが需要を押し上げるんだから仕方ない
どれだけRust由来のGUIフレームワークを望んだとしても負ける未来しかないんだ
WPFもWinUI3もFlutterもComposeも頑張ってるけど勝てないんだ
853:デフォルトの名無しさん
24/05/13 06:53:31.41 NqUrzczE.net
>>825
Rust GUI framework performance comparison
URLﾘﾝｸ(lukaskalbertodt.github.io)
854:デフォルトの名無しさん
24/05/13 08:41:01.54 1UkfuR6U.net
可能性があるとすると組み込み系かなぁ
車載GUIにUnityとか検討してるとこはあるみたいだけど、多少描画がバグってもいいゲームとは違うし
Rustの安定性が求められる領域ではあると思う
slintなんかはそちらを目指しているように見える
855:デフォルトの名無しさん
24/05/13 10:36:48.17 gtcOXaAe.net
フロントについてこういうカッチかちの言語でうまくと思ってるやつは実際にコード書いてないのがバレバレだよ
856:デフォルトの名無しさん
24/05/13 11:03:56.17 TEcr6tUj.net
>>847
こういうアプリ作りたいならウェブ技術・
tauriは論外くらい言ってくれよ
857:デフォルトの名無しさん
24/05/13 11:12:58.92 2BkgcWoG.net
>>848
QtのRustバインディングがもっと進歩すればなあ。
JS系はreact圧倒的に強いからQMLなんて絶対流行らんだろうに
858:デフォルトの名無しさん
24/05/13 11:14:38.81 BwU1QaNs.net
RustのGUIフレームワークを気になって色々見てたけどどれもよくあるレンダリングエンジンのWebGPU、Vulkan、OpenGL、SkiaをRustラップしてるだけじゃんね
純粋なRust製レンダリングエンジンはどこだよ
859:デフォルトの名無しさん
24/05/13 12:01:14.07 7xLbVW9j.net
>>858
今時自前で描画なんてやる訳ないだろ
なんのためにGPUがあるんだ
860:デフォルトの名無しさん
24/05/13 12:47:01.47 nhWWGTo5.net
WebGPUの参照実装であるwgpuは純Rust製だと思ってるけど違うんかね？
861:デフォルトの名無しさん
24/05/13 13:02:11.22 LO420and.net
>>858
少なくともOpenGLとVulkanはグラフィックAPIなんだからラップするのは普通でしょ
862:デフォルトの名無しさん
24/05/13 15:33:49.11 Y2zR27Yz.net
tauriはロジック部分をrustで書きやすいんでしょ？理想的じゃないか
フロントとバックで得意分野の棲み分けができてて賢いフレームワーク
863:デフォルトの名無しさん
24/05/13 16:08:29.50 DdLtk1MY.net
だから Tauri が悪いという論じゃないんだ。
他の選択肢がいっぱいあると嬉しいねって話なんだってば。
864:デフォルトの名無しさん
24/05/13 21:28:07.97 59wZgx8n.net
神学論争じゃなくてエンジニアリングとして
tauriではこんなアプリ作るべきじゃない
理由はこんな欠点があるからという
話してくれれば良いだけなんだが
865:デフォルトの名無しさん
24/05/13 22:14:06.95 ZPj3lkv2.net
GUIといっても多種多様に分かれて共存しておりRustでも色々なライブラリがある
slintのように軽量重視もあれば
eguiのように(一般的な保持モードとは異なり)即時モード採用もあったり
tauriのようにWebと同じ枠組みを使うことで同じ知識の活用とWebアプリとの共通化をはかるものもあり
他にも様々なものがある
前提環境抜きで特定のものを批判してる人はおかしい
866:デフォルトの名無しさん
24/05/14 07:45:48.78 6cY0CvIK.net
みんな違ってみんな良い
867:デフォルトの名無しさん
24/05/14 08:57:53.35 xCwyd0xz.net
slintは素直でとっつきやすかったな
icedは変化が激しいのか入門もさせてもらえない…
868:デフォルトの名無しさん
24/05/14 23:21:46.80 hA3mS4wv.net
LambdaはRustで書くのが定番になってきたな
869:デフォルトの名無しさん
24/05/15 00:25:29.32 pg7m6itF.net
何より悲しい一人ランバダ
870:デフォルトの名無しさん
24/05/15 04:42:11.15 NcaIPB0V.net
わしウェブ系技術ってのが嫌いやねん
871:デフォルトの名無しさん
24/05/15 06:07:55.49 HCR4HRqT.net
具体的に指摘できない人は単なる無知か落ちこぼれ
872:デフォルトの名無しさん
24/05/15 09:47:09.65 qxOWZ5PZ.net
tauriは叩く要素が特にない
electronのデメリットを克服しつつも既存の普及済み技術を集合させた感じなんだもの
tauri導入における敷居の低さはあっぱれとしか言いようがない
ウェブ技術やってない人はこれを機会にreactを勉強したらいいよ
873:デフォルトの名無しさん
24/05/15 11:23:11.20 z848GXEz.net
なんかもう面倒臭いしバックエンドもnode.jsでいい気がしてきた
874:デフォルトの名無しさん
24/05/15 14:38:34.92 h8Rmia3E.net
結局最初はrailsでokみたいなのが最近の流れでしょ。
そこから開発規模に沿ってどう分割していくかってのが最近のテーマではあると思うけど。
最初からかっちり開発しましょうなんて20年前のお花畑理論でしかないわな。
875:デフォルトの名無しさん
24/05/15 15:28:41.91 aizlqnqQ.net
ネイティブGUIアプリの話にRails関係ないだろ
Web開発でもとりあえずRailsのピークは過ぎ去ってるぞ
876:デフォルトの名無しさん
24/05/15 15:31:56.50 5ypavdrK.net
tauriはデータの受け渡しが遅すぎる
877:デフォルトの名無しさん
24/05/15 16:29:56.86 0QhUyids.net
モダンなGUIアーキテクチャでRust書きたいよ
今のは全部古すぎる
878:デフォルトの名無しさん
24/05/15 16:33:24.96 V9iVMFnF.net
>>875
ネイティブGUIアプリじゃなくてデスクトップGUIアプリやろ
まさかTauriはネイティブ扱いとか言わんよな？
879:デフォルトの名無しさん
24/05/15 16:39:14.07 aizlqnqQ.net
>>878
何言ってるのか意味わからんので
あなたのネイティブGUIアプリと
デスクトップGUIアプリの定義と
その違いを説明してくれ
880:デフォルトの名無しさん
24/05/15 16:42:32.92 0QhUyids.net
デスクトップGUIはWebViewを使ったガワアプリも含まれるって意味だろ
881:デフォルトの名無しさん
24/05/15 17:30:27.13 hv8buZEp.net
めんどくさいからデスクトップアプリでいいよ
882:デフォルトの名無しさん
24/05/15 18:24:29.03 xsUSdCEo.net
>>879
一般的にネイティブアプリとは各プラットフォームでネイティブとされてるUIコンポーネントや開発ツールを使って作られたもの
デスクトップアプリはWindows・macOS・Linuxなどのデスクトッププラットフォーム上で実行されるアプリ
(どちらも基本的にGUIアプリについてのみ使われる言葉)
例えばJavaで作ったデスクトップアプリは一般的にネイティブアプリとは呼ばれないが
Java(とJetpack Compose)で作ったAndroidアプリはネイティブアプリと呼ばれる
883:デフォルトの名無しさん
24/05/15 18:30:24.12 4Z0tBK25.net
Visual Studio Codeはネイティブアプリですか？
884:デフォルトの名無しさん
24/05/15 18:35:01.39 NOtrSmJC.net
>>883
ガワアプリです
885:デフォルトの名無しさん
24/05/15 19:01:08.64 xxmBp0ld.net
tauriはフロント側をrustで書けないのがきつい
yewとかで頑張ればrustでやれなくはないけど素直にjs使った方がいいし
886:デフォルトの名無しさん
24/05/15 19:44:27.90 bSYaxLzm.net
フロントは成熟したフレームワークを使いたいからhtmljs仕様なのはむしろ助かることない？
887:デフォルトの名無しさん
24/05/15 19:49:50.25 rWGs03Ps.net
TauriはOS付属のWebViewを下地にして動くことを売りにしてるんだからRustでフロント書きたい人は最初からお客様じゃないぞ
本気でYewでひーひー言いながら書くつもりか？
888:デフォルトの名無しさん
24/05/15 23:50:43.95 s3H9dEcY.net
フロントエンドをHTML/CSS/JavaScript以外で書く人がもうほとんどいない
ただしJavaScriptを直接書かなくてもWebAssemblyで好きな言語で書くのは構わないし同じWeb枠組みの範囲内の話
889:デフォルトの名無しさん
24/05/16 00:16:06.21 1J3uYj1b.net
>>888
結局これだよな。JS以外のクロスプラットフォームなフロントエンドってほとんど無いんだからそこはもう諦めたほうが
890:デフォルトの名無しさん
24/05/16 00:39:52.36 OUQcYMxX.net
そもそもrust推すやつはフロントエンドなんて全く好きじゃないだろ。
891:デフォルトの名無しさん
24/05/16 00:53:56.65 hXehBl/a.net
フロントエンドだけでは何もできなくて
バックエンドや裏はRust採用がリソースコストを最小にできる
そのためのクラウドでのコードもクラウドインフラ自体もRustで記述
さらにCDNインフラ自体もCDNエッジでのコードもRustで記述
892:デフォルトの名無しさん
24/05/16 01:44:19.55 i/RRcUKc.net
>>872
何にしたって否応なくトレードオフはある。
Electoron のデメリットを克服したといっても
その替わりに Electoron に無かったデメリットも生じてる。
たとえば WebView を抱え込まない (実行環境にあるのを使う) のは
実行環境のエコシステムとの連携が必須ってことだ。
基本的にはちゃんとサポートが続いているバージョンの実行環境を使えって話ではあるけどさ、
そうもいかんこともあるのも現実なんよ。
Tauri を叩いてるやつなんていないよ。
まさか「あらゆる」 UI を Tauri でなんとかできると思ってるわけじゃないだろ？ という話。
比較的には有力とは言えるだろうけども。
893:デフォルトの名無しさん
24/05/16 01:56:21.83 g8xzkHEo.net
仮想のtauri狂信者を叩いてるのが一人いるのはわかった
894:デフォルトの名無しさん
24/05/16 02:15:18.77 8s3HDjEn.net
そんなに熱くならんでも良い
Tauriガワ＋Rustビジネスロジックな本格的定番デスクトップアプリが
未だに存在しないから察しろ
895:デフォルトの名無しさん
24/05/16 15:17:12.19 DDVd9f//.net
察しろって歴史が浅いだけでは
896:デフォルトの名無しさん
24/05/16 18:07:35.69 2492rnzS.net
>>891
そこまで行くのに何十年掛かるんだろうなぁ
897:デフォルトの名無しさん
24/05/16 18:37:15.15 hXehBl/a.net
>>896
既にRustで記述されているという現在の話だぞ
Rustで記述されているソース記事は>>51
898:デフォルトの名無しさん
24/05/16 23:54:35.57 4W8w/h2s.net
何十年かかろうがRustが普及するのは事実
乗り遅れるなよ？
899:デフォルトの名無しさん
24/05/16 23:57:43.65 sN6tl8jZ.net
既にそれらクラウドやCDNのインフラはRust製へ切り替わっていってるし
その上で動くユーザーコードも従量制コストのためRustが採用されてるね
900:デフォルトの名無しさん
24/05/17 00:37:51.70 lOJfePdD.net
Rust2024次第や
901:デフォルトの名無しさん
24/05/17 14:37:51.89 R46RaGVX.net
>>898
そうやって何十年騙されてきたんだろう
902:デフォルトの名無しさん
24/05/17 17:27:00.95 fyAXY6lw.net
Rustって、学習コストていうか、習得難易度が高いらしいね
903:デフォルトの名無しさん
24/05/17 18:13:44.03 63RUfPPA.net
本来ちゃんと考えなきゃいけないものをランタイムがやってくれるからって
思考放棄してた部分が表に出てきただけなんだよね
例えば優秀な人はCでもポインタ一つとってもその意味するところが何か、所有するのか、弱参照なのかを意識するし
オブジェクトの管理に参照カウントを実装しているだろう
実際至高のCプログラムであるlinuxカーネルはそのような作りになっている
優秀な人は凡人に見えていないものが見えてるんだよね
904:デフォルトの名無しさん
24/05/17 18:50:38.58 x3ZQoGKy.net
>>903
>実際至高のCプログラムであるlinuxカーネルはそのような作りになっている
>優秀な人は凡人に見えていないものが見えてるんだよね
そして年間数百個の脆弱性を生む結果となっている
真に優秀なら当然そんな結果はもたらさない
自分が優秀だと勘違いしてる人は凡人にすら見える当たり前ことが見えてないんだよね
905:デフォルトの名無しさん
24/05/17 19:03:33.62 63RUfPPA.net
>>904
脆弱性ゼロというのはありえないというのはわかる？
906:デフォルトの名無しさん
24/05/17 19:06:03.74 FyQgq0p4.net
>>903
そのランタイムに任せて非効率になる道と
人が頑張って効率的になるが脆弱性も生じる道の2つしか従来なかったところに
第3の道として効率的かつ安全が保証されるRustが登場して解決した
907:デフォルトの名無しさん
24/05/17 19:45:03.26 S7DVNM0H.net
>>899
Rustが向いてそうなOSやハイパーバイザが
まだまだじゃない？
908:デフォルトの名無しさん
24/05/17 20:17:03.89 Bzly/lr+.net
それなら有志団体のProssimoあたりがRust移植を資金調達しながらやってるじゃない
焦らんでも数十年後にはRustがそれなりに普及してるよ
909:デフォルトの名無しさん
24/05/17 20:33:12.91 Bflq38Ga.net
初心者向けRustが無ければ無理じゃない？
910:デフォルトの名無しさん
24/05/17 20:36:48.91 ljCa+132.net
マンガで読むrust入門とか小学生向けの本が出れば本格的普及かな
911:デフォルトの名無しさん
24/05/17 20:39:02.47 Bflq38Ga.net
最初にスタックフレームの説明から入るのか。
胸熱だな。
912:デフォルトの名無しさん
24/05/17 21:01:30.45 xPWhJeFc.net
バカと初心者は遅いバカ向け言語でいいんだよ
バカでなければその後にRustに行き着くから
913:デフォルトの名無しさん
24/05/17 21:10:07.25 FOdKNTRJ.net
単に sudo を rust で書き直すのにもわりかし時間かかってるよな。
914:デフォルトの名無しさん
24/05/17 21:18:42.19 63RUfPPA.net
昔のCでよくある
hoge = update_hoge(hoge);
みたいなプログラムはRustに移植するのがクソ大変なんだよ
古いプログラムだとこの手のコードが大量に出てくる
実質データ構造から全て書き直しになって移植に時間がかかる
915:デフォルトの名無しさん
24/05/17 21:23:31.52 MaibK+2h.net
>>914
>クソ大変
なんで?
916:デフォルトの名無しさん
24/05/17 21:25:38.04 ljCa+132.net
rustを選民意識で使ってる奴とかいる？
917:デフォルトの名無しさん
24/05/17 21:26:53.82 5wpOXFHi.net
インターネットドメインの無償TLS証明書であるLet's Encryptなどを運用している非営利団体ISRG (Internet Security Research Group)のProssimoプロジェクトは二つの目標を掲げている。
「私たちの目標は二つある。1つは、インターネットを支えるソフトウェアインフラをメモリ安全のコードに書き換えること。もう1つは、メモリ安全性に関する人々の考え方を変えることだ。『C』や『C++』のようなメモリ安全ではない言語で書かれたソフトウェアを展開するのは危険だという証拠があるにもかかわらず使われ続けており、人々がそのリスクを十分に認識し、メモリ安全性をソフトウェアの要件と見なすようにしたい。」
このソフトウェアインフラのメモリ安全性向上に向けて取り組むProssimoプロジェクトの一環として、suやsudoなどのセキュリティユーティリティーを「Rust」で再実装して広める活動も行われている。
918:デフォルトの名無しさん
24/05/17 21:29:19.78 qNukMIkl.net
コンピュータリテラシーの低い人を増やしまくった結果セキュリティ事故祭りになっているのでは？
919:デフォルトの名無しさん
24/05/17 21:44:22.72 GF5EVhbY.net
>>914
>> hoge = update_hoge(hoge);
その例だけなら以下で終わるから説明不十分
update_hoge(&mut hoge);
もちろんこれはメソッド化して
impl Hoge {
fn update(&mut self) {
呼び出しはhoge.update()
これで終わる話だから
おそらく元のC言語コードがグローバル変数を使うなど酷い状態なのだろう
920:デフォルトの名無しさん
24/05/17 21:49:13.20 6kFr2fm8.net
>>917
C/C++を捨てる方向でどこも同じか
>>500で米政府も表明してるしな
921:デフォルトの名無しさん
24/05/17 22:24:35.35 63RUfPPA.net
>>915
当たり前だがhogeはヒープで確保されており
あらゆるところで参照、保持、変更されうる場合がある
よってRcにて管理する必要がある
当然Rcの中のオブジェクトを変更できないと意味がない
つまりCellなりRefCellが必要となる
そして循環参照の問題もあるので弱参照を考えなきゃならん
このようにちょっとしたコードでも単純に移植することが難しい
rust wayな方法で書き直すしかない
922:デフォルトの名無しさん
24/05/17 22:35:22.67 mTdFoxaI.net
sudoが時間かかってるのは単にそれなりの規模だからってだけだと思うけどな
あとsudo風の代替品ではなくてそのまま入れ替え可能なものを目指してるから
仕様の把握と一致検証にも時間がかかるだろうし
923:デフォルトの名無しさん
24/05/17 22:36:32.50 JB0Glcw4.net
ゲーム開発に向かないからC/C++が残ることが確定してしまった
924:デフォルトの名無しさん
24/05/17 22:37:07.66 GF5EVhbY.net
>>921
Rcは必要ない
Rcは所有者が複数になった時のみ登場
925:デフォルトの名無しさん
24/05/17 22:38:27.40 5wpOXFHi.net
>>923
そんな話は聞いたことがない
926:デフォルトの名無しさん
24/05/17 22:42:58.17 cCnlY4YV.net
Rustゲームエンジン開発なんざ勝手にやっとけって感じ
セキュリティ脆弱性が致命的になる分野でのRustへの移植が大事なんだから
927:デフォルトの名無しさん
24/05/17 22:44:28.89 JB0Glcw4.net
>>925
ゲーム会社でRustを採用しようとするところが全然出てこない
それが答えだよ
928:デフォルトの名無しさん
24/05/17 22:58:43.56 BR1qVngc.net
巨大なC/C++遺産ですぐに動けないだけでおそらく少しずつ進めているのだろう
もし何ら対策しないところがあるとすればそのゲーム会社だけ取り残されるのだろう
929:デフォルトの名無しさん
24/05/17 23:17:51.68 +PGm3s9t.net
ゲームなんていう表層的な分野でRustは採用なんてされてないだぁ！って駄々をこねられてもねえ
930:デフォルトの名無しさん
24/05/17 23:57:11.09 BR1qVngc.net
分野によって対応の時間差が出るだろうけど
C/C++排除の流れは止まらない
931:デフォルトの名無しさん
24/05/18 00:25:26.98 Hzmk0zu+.net
少なくともアメリカの軍事分野の制御システムは>>500の声明のとおり最優先でC/C++からRustへの置き換えられるのが確定してるし民間に広まるのは時間の問題
932:デフォルトの名無しさん
24/05/18 00:35:56.17 woQdAE7H.net
DirectX、OpenGL、Vulkanといった主要なグラフィックスAPIがC/C++で作られてるし
ゲーム分野が仮にRustに置き換わるにしろ数十年はかかりそう
933:デフォルトの名無しさん
24/05/18 06:54:07.34 CGudIpEF.net
ポインタの概念を経由しないでrustから入るってほぼ無理だと思うけどね。
rustから入ればc/c++はいらないって人はその辺を誤魔化しすぎてんだよ。
934:デフォルトの名無しさん
24/05/18 09:05:31.34 knMB7JYq.net
ポインタの概念の理解は必要だけど C の構文は理解困難なのよね。
935:デフォルトの名無しさん
24/05/18 10:36:57.70 Fx9Rd4Sf.net
rustがメインで使われるようになろうとも、組み込み系の最初の学習教材としてはC言語が一番扱いやすいから大学で組み込み系での実践言語として今後も使われていくよ
一定数ははじめからRustを教えたりJavaを教えるところもあるかもだけど
936:デフォルトの名無しさん
24/05/18 10:48:07.73 XduL+8Iy.net
なんか勝手に組み込みの話にされてるけどゲームはC/C++が残り続けるよ
Rustでゲームを作るのは流行らない
937:デフォルトの名無しさん
24/05/18 18:43:24.68 Olj0jDDg.net
政府レベルで勧告しているから少なくともビジネスレベルやその製品まではC/C++が排除されてRustへ置き換わる
ゲームのような枝葉末節は知らん