Rust part22

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/26 16:41 / Filesize : 258 KB / Number-of Response : 1021
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part22

1 名前：デフォルトの名無しさん [2024/01/20(土) 23:21:40.08 ID:wyzQTwgG.net]: 公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part21
https://mevius.5ch.net/test/read.cgi/tech/1692105879/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/
730 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:09:09.09 ID:IxuyFkNI.net]: わかる→　Pythonで簡単なスクリプトを書く
キチガイ→　Pythonでプログラミング開発する
731 名前：デフォルトの名無しさん [2024/02/13(火) 12:12:34.52 ID:KvZIg8uL.net]: Pythonでプログラム書くのもちゃんと型書いてlintしたら出来なくもないよ
732 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:15:32.69 ID:1UgkqCq+.net]: よく分からんが画像生成系のフロントエンドでrubyベースのってあったっけ？
733 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 13:03:33.72 ID:X5Whr4lm.net]: 単発NG推奨
734 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 13:04:48.12 ID:X5Whr4lm.net]: 単発NG推奨
連鎖あぼーん推奨
735 名前：デフォルトの名無しさん [2024/02/13(火) 13:49:44.45 ID:BKo58x30.net]: スレNG推奨では？
736 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 14:10:44.85 ID:q0xfm82v.net]: また境界知能が暴れてんのか
いい加減諦めろよ
737 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 15:09:27.64 ID:j+0n3+gu.net]: C++20のコンセプトはゴミみたいなenable_if_tを使わなくてよくなって見やすくなったよね
まだまともに使う機会が来なくて慣れてないけど
738 名前：デフォルトの名無しさん [2024/02/13(火) 19:22:36.57 ID:ui4ZrT7T.net]: XML大嫌い
739 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 20:34:52.16 ID:u8WS3GIa.net]: >>716
やりたいことがよく分からないけどtraitのassociation typeで解決しない？
I: Iteratorだと要素の型はI::Item（正確には<I as Iterator>::Item）になるみたいな
C++のconceptだとtypenameに相当するのかな

traitにgenericsの型パラメータ持たせるかassociation type使うかの判断は慣れるまで難しいけど
選択肢が複数あって外部から決められる　⇒　generics型パラメータ（例：AsRef<T>）
traitを実装するときに内部で自動的に決まる　⇒　association type（例：Deref::Target）
みたいに使い分けるといい
全部をgenericsの型パラメータでやろうとするとカオスになる
740 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 21:06:36.86 ID:4D6oEUgV.net]: >>716
できる
例えばこのように

https://docs.rs/hyper/latest/hyper/service/trait.Service.html

pub trait Service<Request> {
　type Response;
　type Error;
　type Future: Future<Output = Result<Self::Response, Self::Error>>;
　
　// Required method
　fn call(&self, req: Request) -> Self::Future;
}

ここで型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタResponseは依存しない

>>726
その二種類の混合も可能
741 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 21:08:42.27 ID:4D6oEUgV.net]: ごめん
>>727はこうね

型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタRequestは依存しない
742 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 22:37:37.84 ID:s0kRtfrq.net]: ちょっと違うなぁ。

c++ template & conceptだと
wandbox.org/permlink/74j79ZQ3mbPb2cLO
みたいな感じでCircleはf()の影響を受けずに独立させることができる。
draw()メソッドというダックテストを満たせば他はどうでも良い。

Rustのgenericsだと
wandbox.org/permlink/CvepQKXOXaNTJoJm
みたいにCircleとf()の間にtrait Dという相互依存ができて、Circleを好き勝手に定義できなくなる。

f()が欲しいのはあくまでdraw()メソッドだけだから、双方にtrait Dが必要になるのは過剰な相互依存になる。
クラスの継承もそうだけど、余計な依存性は面倒だからできるだけ排除したいところ。
743 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:17:32.55 ID:RVgq5WHA.net]: それはgeneric constraintがnominalかstructuralかという違い
Rustはnominalのみでstructural generic constraintはサポートしてないよ
744 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:20:56.53 ID:KlTxxkJG.net]: Pythonは全てにおいてJuliaに劣った言語だな
745 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:28:47.57 ID:u8WS3GIa.net]: >>729
Circleを
fn f<T: Drawable>(t: &T) -> f64 { t.draw() }
に渡したいなら普通に
impl Drawable for Circle {
fn draw(&self) -> f64 { <Circle as D>::draw(self) }
}
を追加するな
コントラクトの明示を余計な依存関係だとは思わない

ちなみに
impl Circle {
fn draw() -> f64 {...}
}
みたいに本体のimplに定義するとCircleのself.draw()は全部こっちで解決されるから
impl Drawable for Circle {
fn draw(&self) -> f64 { self.draw() }
}
って書ける

１つの型に複数のtraitで同じ名前の関数を持たせるのはRustだとたまに見かける
impl Debugとimpl Displayはどっちもfn fmt()で別の実装するし
746 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:28:48.94 ID:RVgq5WHA.net]: >>726
>traitを実装するときに内部で自動的に決まる　⇒　association type（例：Deref::Target）
ある型に対するtrait実装をただ一つだけにしたいものや
自然と一つだけになるような性質のものはassciated typesを使う

使う側はassociated typesのほうが使いやすいので
悩んだらとりあえずassociated typesからはじめてみる
747 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:30:39.22 ID:9eHJiOzP.net]: >>729
そこはtrait介在させなきゃいけないところでしょ
Rustの方針が正しいと思うよ
748 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:32:24.97 ID:RaqlAe+S.net]: traitとかいうつまらない機能にこだわってないでPython極めろよ
時代はAIだぞ
749 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:35:00.89 ID:8wj/C7pB.net]: >>735
Rustをただ貶したいだけのやつは黙っとけよ雑魚
750 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 05:05:25.04 ID:uLd8jazY.net]: Pythonはスクリプト言語のクセにメソッドチェーンもロクに使えないうんこだからなぁ。
比較で持ち出すならせめてNimにしろよ。
751 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 05:28:01.52 ID:uLd8jazY.net]: >732 >734
Rustのtrait boundはあらかじめ型の方でtraitを準備しておかなきゃいけない。
これはRustが嫌っているクラスの継承みたいなもので、genericsやるごとに元の型/traitを弄くり回す必要が出てこない？
呼び出し元が真に必要なのは機能だけなんだから、同じ名前で互換性のある引数型・戻り値型ならそのまま利用できる方が良い。

まあ、ダックタイプみたいに手を抜かずにAdapter作れ、と言う方針でも良いけど、それならAdapter helperをもっと充実して欲しいところ。
AdapterパターンとかDecorator パターンて重要なのに言語側のサポート薄いよなぁ。
752 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 06:58:38.09 ID:t2TEYrx/.net]: >>738
>>これはRustが嫌っているクラスの継承みたいなもの

クラス継承は基底クラスの実装をそのまま継承する実装継承になっていることが問題点
一方でRustはトレイト境界となるトレイトに対して自分で実装を用意する
したがってRustでは実装継承とはならず問題が生じない
753 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:00:00.30 ID:HWQ4xiFb.net]: 自演きもいなあ
754 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:00:27.71 ID:523CbVaw.net]: 実装継承はゴミ
755 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:05:57.04 ID:Uwd6Wtce.net]: >>737
Ninはコンパイル時間の無駄があるからゴミ
Pythonは実行までの速度が一番早い
756 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:33:52.24 ID:uLd8jazY.net]: >>739
全然理解できていないね。
継承の問題点は、コンパイラ都合で早い段階で設計を固定しなきゃいけない「早すぎる最適化」。
機能とか実装の問題じゃなくて設計の問題。
757 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:08:30.71 ID:b46uhNiQ.net]: >>742
実運用はビルド済だから関係ないな。
758 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:09:58.02 ID:t2TEYrx/.net]: >>743
それは継承の問題点
Rustのトレイトは各型が自分で実装するため継承ではない
759 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:41:45.06 ID:W3PM5KGQ.net]: >>745
早すぎる最適化が問題なんだから、トレイトもその問題を引き継いでるぞ
760 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:51:32.74 ID:t2TEYrx/.net]: >>746
早すぎる最適化が問題になるのは継承
Rustのトレイトは継承ではなく合成で用いる
761 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:55:57.66 ID:b46uhNiQ.net]: >>745
全然理解できていないね。
>>743根は設計の問題で実装関係無いし、継承特有の問題というわけでもない。
>729というとfはDrawable以外のトレイトのdrawが使えない制限あるし、Circleも、問題領域に関する知識の少ない設計初期にtrait Drawableを実装するという仕様固定を行う必要がある。
c++のtemplate concept はあくまでdrawのみに依存するという違いがある。
762 名前：デフォルトの名無しさん [2024/02/14(水) 09:07:35.89 ID:L7EuZktb.net]: 真面目に理解したいなら>>730が正解だからstructural typingとnominal typingの意味を調べてくればいいよ
763 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 09:20:06.07 ID:BSRmwKLd.net]: >>729
C++は酷いな
struct定義の時点でdraw()宣言を要求してしまうのか

Rustなら
struct定義の時点でdraw()宣言を要求せずに済む
後からdraw()という機能(＝Drawableトレイト)が必要になった時点で
structに対してDrawableを実装すればいい
Rustの方が優れてるな
764 名前：デフォルトの名無しさん [2024/02/14(水) 09:36:07.02 ID:48k6rT3Y.net]: >>738
複オジに毒されすぎ
オジが一つ覚えで繰り返し書いてる内容がRust開発陣の見解だと勘違いしないようにね
765 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 09:47:17.10 ID:c6aYZ04m.net]: >>738
根本的な理解がおかしいので説明すると
Rustのtraitは機能を抽象化している
各型はその機能が必要になった時にそのtraitを実装(impl)すればよい
必要な分の各機能(trait)を実装する�
766 名前：ｱとで結果的に各機能の合成となる []: [ここ壊れてます]
767 名前：デフォルトの名無しさん [2024/02/14(水) 09:59:07.19 ID:YhuSf3ik.net]: 細かな実装上の違いはあるけど概念レベルでは Rustのトレイトも他言語のインターフェースも同じ
実装上の違いを見て異なる概念だと勘違いしてると本質を見失う
768 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:10:46.95 ID:Z6/Yikm0.net]: >>750
そりゃダックタイピングでdrawを使いたいんだから、drawの無い型は対象外。

>>752
もともとの話はダックタイピングでtraitじゃないよ。
Rustで静的ダックタイピング・ダックテストする方法はあるかしらん？
769 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:17:10.59 ID:naKe/3pl.net]: ダックタイピングという問題ありまくりのものを有り難がるのはバカだけ
770 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:27:45.39 ID:s2Ev9A6j.net]: >>738
言語側のサポートならマクロで十分でしょ

macro_rules! impl_drawable {
($type:ty) => {
impl $crate::path::to::Drawable for $type {
fn draw(&self) -> f64 { self.draw() }
}
}}

を定義すれば

impl_drawable!(Circle);

だけでimpl Drawable for Cirle {...}を生成できる
渡された型が同じ引数＆戻り値のself.draw()をもってないとコンパイルできないから実質ダックタイピング
Drawableに関数を追加したらマクロにも追加すればいい

draw関数の有無だけで照合するのは別の意味のdrawも対象になるから危なっかしい
impl traitだとどのモジュールのDrawableを実装するかまで指定できるから混同の心配がなくなる
771 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:44:54.87 ID:AzS2pw5X.net]: ダックタイピングは使う側が気をつければなにも問題ないんだよなあ
そこらへん理解してないあたり実装をやったことのないエアプなんだろうな
かわいそう
772 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:53:25.15 ID:naKe/3pl.net]: >>757
その「使う側が気をつければ問題ない」が最悪
ミスが入り込んだ時に気付かず問題を引き起こす
ダックタイピングを持ち上げるのはバカだけ
773 名前：デフォルトの名無しさん [2024/02/14(水) 11:07:38.32 ID:RfRsJx+N.net]: 使う側が気をつけるならC++も問題ないからな
774 名前：デフォルトの名無しさん [2024/02/14(水) 11:17:22.43 ID:NjTyhCIW.net]: >>756
これがいわゆる実装継承の再発明
このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター
775 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 11:23:15.20 ID:FEB+PUkj.net]: >>759
そゆこと
だからRustは不要
776 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 11:28:02.15 ID:naKe/3pl.net]: ダメ人間の思想「使う側が気をつければ問題ない」によって
今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史
今後はそのような言語を用いてはいけない
777 名前：デフォルトの名無しさん [2024/02/14(水) 11:51:49.92 ID:L7EuZktb.net]: ここで>>9-20の流れを振り返ってみましょう
778 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 11:52:42.46 ID:3OoaoCBc.net]: C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？
リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。
具体的に言えば

fn increment(dest: &mut u32) -> u32 {
let t = *dest;
*dest += 1;
t
}

みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。
779 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:13:59.14 ID:s2Ev9A6j.net]: >>760
どこをどう曲解しても実装継承にはならんだろ
すべてのケースでマクロ使うとでも思ってるの？
〇〇の思考回路はよく分からん

>>764
Atomic系統ならfetch_addがあるけど普通のincrementは単純＆限定的すぎて逆にないな
std::mem::replace使えば
replace(&mut t, t+1)
とかできるけど+1するだけなら大袈裟すぎる気がする
780 名前：デフォルトの名無しさん [2024/02/14(水) 12:19:27.37 ID:Cdw7DngV.net]: >>761
だからの文が全然繋がってなくてワラタw
こういう低能はプログラミングしちゃダメだよ。
781 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:25:13.12 ID:b46uhNiQ.net]: >>755
そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。
DbCとか勉強したほうがいいよ。
782 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:29:23.30 ID:naKe/3pl.net]: >>767
ダックタイピングが負の遺産であることは自明だが
ダックタイピングを使わないことが負の遺産だと主張する君は破綻している
783 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:49:07.16 ID:b46uhNiQ.net]: >>768
自明だと�
784 名前：沛ﾘできる証明を示して頂戴。 検証可能性の無い主張は単なる疑似科学だし。 []: [ここ壊れてます]
785 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:52:16.39 ID:KpCwABm3.net]: 欠点がない言語なんて無いから言い争ってもね。
786 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:57:57.69 ID:p6Tfi6cJ.net]: そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明
787 名前：デフォルトの名無しさん [2024/02/14(水) 13:07:28.33 ID:L7EuZktb.net]: たし🦀
788 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:09:31.24 ID:aR1xhX8a.net]: おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき
789 名前：デフォルトの名無しさん [2024/02/14(水) 13:16:05.40 ID:eD+V22zq.net]: drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる
適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ
790 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:33:10.33 ID:Q08aEmFz.net]: 境界知能が可視化されてる
791 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:53:52.28 ID:Z6/Yikm0.net]: >>774
当たり前だろ。
インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。
792 名前：デフォルトの名無しさん [2024/02/14(水) 13:55:32.21 ID:eD+V22zq.net]: >>776
ダックタイピングはその契約書が定義されてないのが良くない
Traitは契約書の定義みたいなもんだ

ダックタイピングは白紙の契約書にサインするようなものだ
793 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:57:04.55 ID:s22bd+Hs.net]: >>775
お前のこと？
794 名前：デフォルトの名無しさん [2024/02/14(水) 14:31:04.48 ID:h4S8S2sP.net]: >>777
これな
795 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 14:41:15.13 ID:3OoaoCBc.net]: >>765
replace だと借用規則に引っかかってエラーになるようです。
まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが……
796 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 15:12:12.70 ID:s2Ev9A6j.net]: >>780
Copy型だから通りそうな気がしたけど無理だったか
何か技がありそうだけどそこまでするほどの問題じゃないよな
797 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 15:36:36.14 ID:S2bQYQek.net]: >>764
Rustで++は排除されている

理由はたくさんあるようだが
例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか
前置と後置の間違いミスも多いことに加えて
生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや
move/copy問題もあったかな
798 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:02:27.29 ID:3OoaoCBc.net]: >>782
そんな話はしてないです。
役に立つことを言えないなら余計な茶々入れるな。
799 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:29:39.74 ID:ona7PgM1.net]: >>783
おまえ質問してる分際でキチガイなのか？
そういう態度を改めないなら二度と教えてやらんぞ

fn increment(dest: &mut u32) -> u32 {
　std::mem::replace(dest, *dest + 1)
}
800 名前：デフォルトの名無しさん [2024/02/14(水) 16:36:51.93 ID:b+wxXawK.net]: 質問している人間相手なら関係ないことを書いて良いわけではない
801 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:42:22.39 ID:3OoaoCBc.net]: >>784
結果的に役に立たないことがあってもしょうがないですが、関係ないことをアンカーで書くのは正当化できない迷惑行為です。
質問者 (特に初心者？) には迷惑をかけてよいと考えているのだとしたらそれは改めるべき悪です。
802 名前：デフォルトの名無しさん [2024/02/14(水) 16:46:13.61 ID:L7EuZktb.net]: ついに存在しないCコードの幻覚が見えるようになってしまった複製おじさん……
803 名前：デフォルトの名無しさん [2024/02/14(水) 16:46:26.67 ID:b+wxXawK.net]: 一方、質問文を誤読して解答してしまった人間に対して強く当たって良いわけでもない
804 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:51:03.66 ID:3OoaoCBc.net]: >>788
あれは誤読 (?) なんでしょうか。
茶化しているように受け取ったので腹立たしかったのですが、
そうだとしたら >>783 は言い過ぎですね。

ID:S2bQYQek さん、すいません
805 名前：デフォルトの名無しさん [2024/02/14(水) 17:05:32.23 ID:ZK4bCcm/.net]: 人間の注意力読解力は実際この程度なので、人間にC++を扱うことは難しい
806 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 17:06:20.11 ID:Q08aEmFz.net]: だから境界知能なんでしょ
807 名前：デフォルトの名無しさん [2024/02/14(水) 17:19:45.82 ID:qgmjNVo3.net]: 腹立てるのもわからなくはないがそんなにキレてレスするようなことではないだろ
気に入らなかったらスルーする程度には心に余裕を持っておこう
808 名前：デフォルトの名無しさん [2024/02/14(水) 17:26:03.70 ID:h4S8S2sP.net]: tmuxよりscreen派だよ。
809 名前：デフォルトの名無しさん [2024/02/14(水) 17:50:47.59 ID:6CXfQ6Kw.net]: 個人的には後置インクリメントだけを関数化するのは微妙に感じる

fetch_addとかは必要性を理解できるけど単純なpost_addやpost_incrementは一段階上の処理を関数化するので十分でそのほうが見通しがいいように思う
810 名前：デフォルトの名無しさん [2024/02/14(水) 19:51:05.67 ID:7rKeAYke.net]: >>762
こういう偉そうなこと散々言ってたhaskellがなぜ流行らなかったのかすら理解できてないというのが愚かだよね。
811 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 19:57:21.78 ID:b46uhNiQ.net]: >>777
c++ template conceptも碌に知らないでダックタイピングをけなしているのか。なかなか……
ダックタイピングは契約の主体・時期・範囲が違うという話だかね。
812 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 20:14:14.28 ID:yh2p7tDo.net]: >>796
C++では機能の異なる同名メソッドを区別できないから欠陥品
813 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 20:52:10.35 ID:b46uhNiQ.net]: >>797
引数・戻り値で区別できるだろ。
814 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 21:01:37.45 ID:yh2p7tDo.net]: >>798
それに依存してしまうのがC++の限界
815 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 21:18:41.79 ID:b46uhNiQ.net]: >>799
名前も引数も戻り値も区別できないんだったら、ダックタイピングで呼び出す側はそもそも区別する必要あるんですかねぇ。
816 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 21:58:58.38 ID:H5X+9PTs.net]: >>796
それだとRustでいうところのトレイト境界を課すことができないな
つまりC++では安全に呼び出すことができない
呼び出したメソッド内で出来ること出来ないことが定まらないため
817 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 22:13:29.10 ID:uLd8jazY.net]: >>801
「呼び出したメソッド内で出来ること出来ないこと」
て何？

Rustのtraitて、副作用のコントロールできたっけ？
818 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 22:26:20.82 ID:8gvFvpJ5.net]: traitのprovided methodのdefault実装で呼び出せるのはrequired methodと
trait境界がある場合はそのtraitのmethod
そしてそれらで構成された他のprovided methodのみ
って制限をC++でどうするんだろ
819 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 23:19:42.33 ID:3OoaoCBc.net]: >>803
コンセプト。
820 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 23:20:56.22 ID:3OoaoCBc.net]: >>792
毎度毎度のことで余裕を削られた最後だったんだよ。
821 名前：デフォルトの名無しさん [2024/02/15(木) 00:20:11.01 ID:AyUC+mx+.net]: 毎度毎度のことという認識を持っていながらなぜここに書き込むのか
822 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 00:23:07.31 ID:x2y7hFPc.net]: >>806
せやな。
けど日本で比較的活発な Rust コミュニティというとここなんよ。
823 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 07:06:08.60 ID:13EQhuxe.net]: >>804
concept記述が多すぎて書いててイヤになるな
普及しそうにない仕様がまたC++に増えた感じ
Rustが必要な機能を洗練して提供しているのと対照的
824 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 07:43:10.62 ID:j4EJcuA3.net]: >>808
洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。
枯れた既存プログラムの置き換え用途が無難なところかと。
コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。
825 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 07:55:56.64 ID:hKdVOM0D.net]: >>809
Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に
RustやめてGoにする宣言してる
理由を真面目に話してるから一見の価値のあり
826 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:11:38.37 ID:j4EJcuA3.net]: >>810
検索したけど見つからなかった……
リンクある？
827 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:17:50.82 ID:Me0Wd39H.net]: [Why I Use Golang In 2024](https://www.youtube.com/watch?v=6gwF8mG3UUY)
828 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:19:40.94 ID:j4EJcuA3.net]: >>812
サンクス。
家帰ったら見るわ。
829 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:48:36.69 ID:UeUfm3Ct.net]: >>812
見た
ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い
そして批判されてるのはなぜかTypeScrpt
Goについてはシンプルなのが好きでジェネリックが導入されてワクワク
Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ
Rustの型システムはとても素晴らしいけど、
830 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 09:52:51.93 ID:x2y7hFPc.net]: >>808
過去のコードと矛盾しない形での後付けだからな。
C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。
簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。
Rust だって歴史が積み重なればいずれそうなる。
「綺麗なのは使われないもの」という格言を聞いたことないか？
Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。
規格策定・処理系保守のリソースは無限なわけではないしな。
831 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 09:55:25.99 ID:LYiZEs3M.net]: エディションはすでに複数あるけど
あっても無理とか問題起きるとか
実例あるの？
832 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:07:56.04 ID:x2y7hFPc.net]: >>816
問題が抑えられているのは問題がないように保守されているからで、
その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。
今問題があるとかそういう話じゃないから未知数と述べてる。
833 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:11:47.35 ID:9MXGquuv.net]: C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ
C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる
834 名前：デフォルトの名無しさん [2024/02/15(木) 10:21:13.40 ID:qaCOVcST.net]: まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは

Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある
835 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:32:36.57 ID:LYiZEs3M.net]: >>817
今は良くても未来は何が起こるかわからない論法は
何にでも使えるから意味ある話とは思えないけど…
836 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:37:24.02 ID:x2y7hFPc.net]: 「出来る」ということを大前提として確信できて、
その上で「上手く出来る」ならより良いってのが産業的な考え方だ。
おおよその場合に上手く出来ても
ちょっとした想定外に直面したときに破綻するようでは使い物にならない。

現実の問題ってのは想定してないところから出てくるものだから
そういうことも乗り越えられることを証明するには
実績 (歴史) を重ねるしかしょうがないんだ。

C++ は上手くやったとは言えなくても、汚くても打てる手が有る道具として信頼を得た。

Rust は今の時点では実に使いやすいように見えるが、
本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。
837 名前：デフォルトの名無しさん [2024/02/15(木) 10:38:37.60 ID:TrooctNX.net]: 今の時点で使いやすければなんでもいいんだYO
838 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:45:22.07 ID:9MXGquuv.net]: C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない
これだけ増築工事を重ねてもまだ見込みが立たないまま
839 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 11:47:28.36 ID:olqTmpaN.net]: C++の知識は大いに再利用されているので現実世界の変化は小さい
想定外かもしれないのは変化の大きさではなく
現実世界を定義できないことだ
定義できるのは理論だけ
840 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 12:02:34.79 ID:oxTsPXaA.net]: >>821
今の想定が甘いとか具体的指摘なかったら
想定外の対処ができてないから駄目は無敵論法
841 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 14:40:35.94 ID:wvzNp0zm.net]: そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ
パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分
842 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 14:47:01.34 ID:z+RD4XEG.net]: サーバーサイドは群雄割拠時代よね
Rust、Go、Java/Kotlin、C#いっぱいある
843 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 16:20:13.71 ID:x2y7hFPc.net]: >>825
駄目とは言ってない。
駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。
844 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 16:46:19.25 ID:606b12LT.net]: >>828
あなたの話相手してもrustでも他言語でもいいけど
問題回避のためにこういう仕様や実装にすべきじゃないか
みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね
845 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 16:50:52.01 ID:olqTmpaN.net]: すべてを疑っても産業だけは疑いようがないって話なら
想定内と想定外の境界がどの辺にあるのかはなんとなくわかる
846 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:21:54.77 ID:SzbBTI0k.net]: >>814
Rustは型〇ナニーで長時間バトルだったと言ってるぞw
>>812動画の人がいくら天才でも2年間かき回したのは頂けない
847 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:26:25.25 ID:BHoNDVf7.net]: Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い
さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい
848 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:31:26.55 ID:dtRRoOMy.net]: Ruby は、Go/Rust/Elixir の3大言語を超えた！
Rust の上昇は止まったか？

Stack Overflow 米国年収。2022 -> 2023

Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7

多くの言語 : 6.5～7 -> 7.3～7.8

PHP : 5 -> 5.9
Dart : 4.4 -> 5.6
849 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:35:21.87 ID:eOw5Ad1t.net]: >>832 夢見てないで現実見ては？
https://active.nikkeibp.co.jp/atcl/act/19/00546/011500001/
850 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:41:41.98 ID:wvzNp0zm.net]: >>812
流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草
851 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:53:07.04 ID:8jpdfcc8.net]: >>835
Rustインフルエンサーの成れの果てですなw
852 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:08:05.70 ID:uSGIT3N+.net]: >>834
せめて用途別のプログラミング順位を挙げてくれ

…単発に言っても無駄か😭
853 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:08:23.00 ID:giVh/goG.net]: Goは２年も続けられるだろうか

大分前に少し使ってみたけど例外投げずにResult（タプル）で返す言語設計を採用しながら
返されたResultを無視してもコンパイラが警告出さないからやめた
Cで戻り値のエラーをスルーする事案が多発したから後発言語で例外が作られたのに

↓を見て気持ち悪さを感じる人には向かない

file, err = os.Open(path) // ← fileと一緒にエラーの受け取りを強要される
os.Chdir(path) // ←エラーしか返さないから戻り値を無視して処理を継続できる
854 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:11:15.85 ID:x2y7hFPc.net]: >>829
情報が充分じゃない (から議論を始めることさえできない) ことが
リスクだという話をしているつもりなんだが、伝わってないのか？
どんな問題が起こるのか事前にわかれば苦労しないよ。

起きたことに対処し続けるしか仕方がないが
可能なら自分が対処する当事者にはなりたくない。
855 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:19:47.46 ID:SZiIKMeC.net]: 「Go」、2月のTIOBE指標で過去最高8位に
https://japan.zdnet.com/article/35215159/
https://japan.zdnet.com/storage/2024/02/13/0ee0eaf7a75e201ad2ee580740569609/240213_tiobe.png
856 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:24:55.60 ID:x2y7hFPc.net]: >>838
悪いほうがよい (Worse is Better) 原則というものも知られている。
正しさと単純さを天秤にかけてどちらが良いかという点で Rust とは異なる重みづけをしたのが Go だと思う。
問題をコンパイラが検出できる設計はもちろんありがたいが、そのために持ち込む構造は人間が把握しやすいものだろうか。
正直言って Go が良いとは全然思わないが一貫した理念に基づく判断であって、不備でそうなってるわけではない。
857 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:31:33.80 ID:j4EJcuA3.net]: >>829 >>839
このあたりは設計の根深い問題で、「変化を抱擁する」を標語としたアジャイル開発とかインクリメンタル開発とかで色々議論されたな。
あんまり目立った成果は無かったような気もするけど、機能間の疎結合と可換性は重要な指摘だと思うわ。
858 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:34:16.56 ID:3rKktGL8.net]: >>817
これはごもっともな意見
50年後にRust 2072エディションがある状況で最新コンパイラが2015エディションをサポートし続けてるとは思えないからどこかでは切ることになる
それでもRustのモデルとC++のモデルとどちらのほうが相対的によさそうかという選択の問題
859 名前：デフォルトの名無しさん [2024/02/15(木) 19:40:03.38 ID:TrooctNX.net]: 50年後にC++23はサポートされているのだろうか
というかC++は50年後もアップデートしているのだろうか
860 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 19:52:43.98 ID:flxKbqvK.net]: >>843
cargo fix --edition
のあるRustは至れり尽くせりだよ
861 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 20:00:49.77 ID:nijJOd3e.net]: >>844
既にC++17とC++20で以前導入の機能の削除が大量に行われている
862 名前：デフォルトの名無しさん [2024/02/15(木) 20:11:12.94 ID:Zy70aZMD.net]: じゃあもうRustで良いじゃん
863 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 20:27:48.49 ID:Y7OgkdHD.net]: CになかったC++の機能は削除してもチューリング完全が保証される
逆に、削除したらチューリング完全ではない保証をするならミニマリズムがベター
864 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 22:27:00.96 ID:MX4y8Eg+.net]: >>840
Kotlinが上がってきてるのうれしい
Fortranも上がってるのはなぜだ
865 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 22:56:46.83 ID:x2y7hFPc.net]: C++ は欠陥報告という制度で過去の規格に遡って修正が加えられることがある。
たとえば C++11 発行当時の C++11 と今の C++11 は内容が異なるわけ。
基本的には過去の仕様に新機能を追加したりはしないが微妙な挙動の変なところを直すような保守は続いている。
実質的には Rust のエディションみたいなことにはなってるんだよなあ。
866 名前：デフォルトの名無しさん [2024/02/15(木) 23:13:05.86 ID:17JkefKn.net]: llvmも実装はc++だし。
867 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 23:33:02.83 ID:CqGYBNeH.net]: >>850
Rustは必ずeditionを明示しないといけないから
あるソースコードがどのeditionなら確実に動くのか明確にわかる
そしてそのeditionを指定してコンパイルも通り実行もできる

しかしC++は当初のC++11に従いコンパイルできて動いていたものが
今はC++11の機能のいくつかは削除されてしまっているために
868 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 23:44:16.83 ID:x2y7hFPc.net]: >>852
C++11 は C++11 として存在し続けているので問題になってないという話をしてるんだが
869 名前：デフォルトの名無しさん [2024/02/15(木) 23:57:58.06 ID:m2l7AKkd.net]: 一般人と同等の読解力を複オジに期待しないこと
870 名前：デフォルトの名無しさん [2024/02/16(金) 01:17:00.51 ID:2uzjzXJf.net]: cppreference.comの下のほうにちょろっと書いてあるdefect reportってそういうことだったんだ
勉強になるわ〜
871 名前：デフォルトの名無しさん [2024/02/16(金) 02:58:58.82 ID:T31Boec7.net]: >>853
名前が同じならなんでも良い…… ってこと！？
872 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 05:29:44.45 ID:VnZfCvN7.net]: >>856
「規格が同じなら」ということだよ。

c++11とかはあくまで規格なので各実装の準拠率とか注意するポイントはあるけど、メジャーな機能を保守的に使えばそれなりに互換性を維持できる。
873 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 06:06:29.14 ID:VMcEA5aE.net]: RustのEdition方式が優秀すぎる
新たな機能の規格で分けるのではなく
各Editionは後方互換性の変化で分けているため
過去に書かれたコードも必ず動く
874 名前：デフォルトの名無しさん [2024/02/16(金) 08:50:06.12 ID:T31Boec7.net]: >>857
規格が同じといいつつ機能消してんだから同じなのは規格の名前だけじゃん
875 名前：デフォルトの名無しさん [2024/02/16(金) 08:50:57.44 ID:T31Boec7.net]: 規格から機能ごと消えるんならよう
876 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 08:57:09.07 ID:MpEo3rxP.net]: >>859
消してないけど何いってんの？
877 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 07:36:35.11 ID:pKHDV/cx.net]: ID:T31Boec7
流石にこいつ日本語能力なさすぎだろ
ガイジかな？
878 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 07:58:38.87 ID:y2U3e6uM.net]: mojo vs rustでmojo公式とnetflix天才とRust本著者で盛り上がっている
https://www.youtube.com/watch?v=MDblUyz0PtQ

>>814,835
早口なので大変だろうけどちょとした言葉の節々に情報があるからリスニングがんばれ
879 名前：デフォルトの名無しさん [2024/02/17(土) 08:38:43.36 ID:P+bU7/QC.net]: >>863
copilotで要約して貰うのが時間も短縮できるのに無能だなw
880 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 11:31:52.42 ID:/wuPDCL7.net]: >>864
この天才同士のディスカッションを楽しめないなんて損してんね🥲
881 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 11:55:10.10 ID:wfN7KjH7.net]: Netflixの天才とかいうのが胡散臭くて信頼性がないんだけどどういう人なのよ。
882 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 12:54:06.77 ID:p6Fewl3N.net]: >>863
この人の英語聞き取りにくい
もうちょっとゆっくり喋って欲しい
中身うっすいのにさ
883 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 12:58:21.47 ID:p6Fewl3N.net]: >>862
普通に境界性知能ってやつでは？
この手のは全部そうだと思うようにしてる
884 名前：デフォルトの名無しさん [2024/02/17(土) 17:40:44.30 ID:SxaDWram.net]: >>863
ベンチマーク試してみたところ以外はブログ記事のまんまなのでわざわざ動画で見なくてもいいなこれ

公式ブログに書くならもうちょっとちゃんとしたベンチマークやれよって感じ
見識を疑うレベル
885 名前：デフォルトの名無しさん [2024/02/17(土) 18:56:01.48 ID:bc7xcSj4.net]: Netflixの天才がいかがでしたかブログレベルの動画を出すとは
886 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 19:01:49.62 ID:hd6B0gbf.net]: >>863
動画内の指摘が記事に反映されてMojoがRustの3倍速いじゃん!!
Mojoコンパイラ賢いな
887 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 19:07:25.89 ID:1+LtKHMi.net]: 以前からMojoがCより何倍も速い！とかやってるけど
ベンチ方法や条件などが何かおかしい
888 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 20:11:15.92 ID:lHr0QJnq.net]: SIMDが効くような恣意的なベンチだしな
889 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 21:00:37.77 ID:QWthdRCX.net]: でもデータを見てから断罪するのは俗っぽいから
データを見ないでロジハラするのがベター
890 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 21:16:16.12 ID:lHr0QJnq.net]: DynamicVectorは最適化でSIMD使うように最適化されるってだけだろ
あと末尾最適化する
くだらなすぎる
891 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 21:40:36.38 ID:WeOJL5ES.net]: え？　Rustって末尾最適化できんの？
892 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 23:56:23.75 ID:uU5eCENW.net]: Rust Reserved keywords

KW_ABSTRACT : abstract
KW_BECOME : become
KW_BOX : box
KW_DO : do
KW_FINAL : final
KW_MACRO : macro
KW_OVERRIDE : override
KW_PRIV : priv
KW_TRY : try
KW_TYPEOF : typeof
KW_UNSIZED : unsized
KW_VIRTUAL : virtual
KW_YIELD : yield
893 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 09:43:13.97 ID:2fU6EVDD.net]: >>873,875
同じLLVM系なのにRustが3倍遅いのかよ!!
Mojoがコンパイラ賢いのかRustコンパイラが...
894 名前：デフォルトの名無しさん [2024/02/18(日) 10:23:17.76 ID:8VIVYK48.net]: あれを見て本当にRustが遅いと思っちゃう層の人にRustは向いてない
895 名前：デフォルトの名無しさん [2024/02/18(日) 10:24:13.10 ID:8VIVYK48.net]: ちなみにSIMD云々は本質じゃないよ
896 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 10:33:07.03 ID:diN1NxZN.net]: >>879が3倍速いRustコードを出すってよ
897 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 10:46:23.01 ID:fnRzA2e2.net]: これはGoの方が速いんじゃないか？
898 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 11:13:09.56 ID:NoFg1fuK.net]: GoはGCを伴う言語だから論外
MojoはC/C++/Rustより3倍速い
899 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 11:27:28.89 ID:YdXgtYKq.net]: >>878
同じLLVMといってもMLIRという数値計算に最適化されたIRを使ってるから速い
恣意的な例である
900 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 11:36:55.83 ID:a/PaZk8n.net]: そういえば昔Delphiがコンパイルの速さを売りにしてたの思い出した
なんか懐かしい
901 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 12:18:39.29 ID:Wi99yBdV.net]: 20年後にRustを懐かしむスレはここですか？
902 名前：デフォルトの名無しさん [2024/02/18(日) 14:55:22.54 ID:LhS8zjp4.net]: 20年後には流石にもっと良い言語が登場して流行っていることを期待している
903 名前：デフォルトの名無しさん [2024/02/18(日) 15:22:23.80 ID:L2mk1x1a.net]: >>885
アンダースヘルスバーグ天才だよな
ボーランドでDelphi作って
マイクロソフトでC#とTypeScript作って
904 名前：デフォルトの名無しさん [2024/02/18(日) 15:34:23.48 ID:CKqOMEmo.net]: >>888
MAUIくん！病室に戻るんだ！
905 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 09:27:30.10 ID:JlpPRp2V.net]: >>888
俺は天才とは思わない
この人ってお手本となる言語があって
それをよりよくすることは得意な気がする
906 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 10:19:49.07 ID:j7eyydGe.net]: 普通の人が実務で使うような汎用プログラミング言語は
とびぬけた画期的なパラダイムで構成しても使い難いし、
ひとつひとつはどうということはない要素を上手く組み合わせる
バランス感覚が重要って感じはあるね。
天才的な閃きでどうにかするようなものではない。
907 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 11:58:45.15 ID:r1DaNm3S.net]: 既存のものをうまく組み合わせたりリーダーシップをとったりするのに天賦の才があったという意味なら天才かな
908 名前：デフォルトの名無しさん [2024/02/19(月) 12:07:19.13 ID:BnjhEPJH.net]: 自分は何も出来ない無才なのによく言うわw
909 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 14:11:02.99 ID:JlpPRp2V.net]: C#→Javaのビミョーなところを直す
Delphi�
910 名前：ｨPascalのビミョーなところを直す TypeScript→JSに型付け []: [ここ壊れてます]
911 名前：デフォルトの名無しさん [2024/02/19(月) 14:41:59.29 ID:FfoO1n86.net]: Rustのビミョーなところを直して欲しい
912 名前：デフォルトの名無しさん [2024/02/19(月) 15:33:58.75 ID:BnjhEPJH.net]: R#だすかー
913 名前：デフォルトの名無しさん [2024/02/19(月) 16:37:49.01 ID:pyxz0P7h.net]: Turbo PascalやDelphiやVisual J++は彼か作ったと言えるがTypeScriptはHejlsbergが作ったわけじゃないからな

広報+コントリビューター+社外との政治的調整役
914 名前：デフォルトの名無しさん [2024/02/19(月) 18:10:38.68 ID:VthC7yJG.net]: R#とか絶対統計処理用の言語じゃん
915 名前：デフォルトの名無しさん [2024/02/19(月) 18:20:06.89 ID:BnjhEPJH.net]: そうだな
じゃあRustyNailって名前にするか
916 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 18:38:07.38 ID:j7eyydGe.net]: ビミョーなところをどうにかしたってどうせ別のビミョーなところが出てくるに決まってるんだよ。
だましだまし発展させて行き詰まったあたりでまた新しい何かが登場するのが世の中のサイクルというもんだ。
917 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 18:50:17.05 ID:JlpPRp2V.net]: 割とマジでヘルスバーグ動きますの可能性はある
Carbon、Go→Google
Rust→Mozilla
？→Microsoft

この流れは確かにある
918 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 20:05:38.11 ID:gidehIA9.net]: GoogleもMicrosoftもRust支持で
Carbonの公式FAQにはRustが使えるならRustが良いと明記されている
919 名前：デフォルトの名無しさん [2024/02/19(月) 20:34:12.24 ID:VthC7yJG.net]: Rust支持というより、現状最良の選択肢がRustであると認めているだけでは
なのでもっと良い選択肢を作ることが出来たら嬉々として打ち出してくる可能性はあると思う
920 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 20:55:09.09 ID:WSW9DaUh.net]: 代替の芽が今ないから早くて十数年以上先
MojoはPythonベースで関心が数値計算に向いていて違う
921 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 20:57:44.38 ID:34j+4tJw.net]: Netflixの天才は2年かけて右端の住人になったのか
https://pbs.twimg.com/media/GDa2G6iWIAAsyh3.jpg:orig

これからは目立った実績が無いのにRust歴が長いと
型〇ナニーで時間溶かしてると認定される
922 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 21:23:20.71 ID:MW9zngaI.net]: >>905
Go？
Goはランタイムが大きくGCベースの言語だからRustの代わりにならんよ
923 名前：デフォルトの名無しさん [2024/02/19(月) 21:38:55.37 ID:BnjhEPJH.net]: >>906
結局さ一周回ってAdaで良いんじゃ？
924 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 21:46:39.06 ID:VDl5KQ6V.net]: オーガスタちゃんが平伏せと命令する言語？
925 名前：デフォルトの名無しさん [2024/02/19(月) 22:19:23.32 ID:hvnIqBoW.net]: Web用途だとRustはtokioと関連ライブラリが必須だからGoよりランタイム大きくなるけどね
926 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 22:41:42.37 ID:+OQMy10I.net]: >>909
Rustバイナリが小さい
tokio+hyper他で特別な指定もなく普通に作ったweb server実行バイナリがstrip後に1.3MB
927 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 23:17:36.45 ID:aeOZND98.net]: サーバーエンドでバイナリサイズなんてどうでもいいけど専有メモリ量がJavaやGoより小さいのはよい
928 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 03:09:16.36 ID:sgoVzbhC.net]: Rustってcargo buildとかやると通信量結構えげつない
929 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 08:39:03.07 ID:VuVDzPkr.net]: 依存関係があるライブラリをダウンロードすれば Rust に限らず
それなりにたいくさんひっついてくるのはよくあること。
930 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 08:51:21.95 ID:HobPlk1l.net]: C++でビルドする前にapt-getしてね、ってのも同じことだしな
931 名前：デフォルトの名無しさん [2024/02/20(火) 09:54:42.94 ID:avQkuhyK.net]: Rustだと依存ライブラリの数が桁違いに多くなるのが原因
932 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 10:20:25.82 ID:VuVDzPkr.net]: お前それ、 JavaScript の前でも同じこと言えるの？
933 名前：デフォルトの名無しさん [2024/02/20(火) 10:20:33.45 ID:kmanQ674.net]: >>903
その通り
Rustの次に期待
934 名前：デフォルトの名無しさん [2024/02/20(火) 13:00:59.06 ID:MPPpoDC+.net]: >>907
ブロックが波カッコだったらなぁと思ったことある。
935 名前：デフォルトの名無しさん [2024/02/20(火) 13:46:52.53 ID:sgoVzbhC.net]: 一回DLしたパッケージOSにキャッシュしてくれればいいんだけど
そうじゃないから学習でやってると無尽蔵に取りにいくのはなんとかならんのか
936 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 14:05:25.22 ID:VuVDzPkr.net]: >>919
えっ、普通にキャッシュしますが……。
937 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 14:18:44.11 ID:YaBXE8T+.net]: >>919
1回しかダウンロードしない
その後はそのキャッシュを用いる
938 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 14:47:39.06 ID:NZma60kC.net]: それよりディスク使いすぎだろ
ビルドの中間生成物が簡単にギガ単位になる
939 名前：デフォルトの名無しさん [2024/02/20(火) 15:44:30.40 ID:s70xdtq8.net]: >>922
それな
複雑なコンパイラでインクリメンタルビルドを高速化するには空間性能を犠牲にするしかないんだろ
940 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 15:54:29.36 ID:VuVDzPkr.net]: 大きなライブラリは動的リンクすることにしてもいいけど、
そしたら実行環境の管理と開発環境の管理を分離しづらくて面倒くさくなる。
どうやったってどこかに負担はかかるならストレージさえあれば
だいたい解決ってほうがいいという戦略なんだろ。
941 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 18:32:02.94 ID:NZma60kC.net]: Rustほどディスク使う言語他にあるの？
桁違いに多いと思うんだが
942 名前：デフォルトの名無しさん [2024/02/20(火) 18:32:44.23 ID:pzacWR0B.net]: ディスクはまあTB行かなければ何をやっても良いわ
943 名前：デフォルトの名無しさん [2024/02/20(火) 18:46:34.01 ID:2x98KEBQ.net]: ビルドキャッシュの一部を何もしなくてもプロジェクト跨いで共有してくれればまだいいんだけどね
用途的に外部ストレージやNASに置くようなものじゃないというのが困るところ
944 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 18:56:04.80 ID:qhUDP5tY.net]: Rust (cargo)のソースダウンロードしてすべて同一マシンでビルドする前提の設計はいいと思う。
soとかdllとかjarみたいなの、あまり信頼したくないというか。
945 名前：デフォルトの名無しさん [2024/02/20(火) 1 ]: [ここ壊れてます]
946 名前：9:01:23.73 ID:aUCxPGU2.net mailto: Crates.ioを信頼してどうせ落ちてきたもの毎回ソース全行確認したりはしないんだから、落ちてくるものがバイナリになっても別に良いかな []: [ここ壊れてます]
947 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 19:12:55.50 ID:HobPlk1l.net]: so使ってsymbol not foundとかよくあるしな
基本的にC++ソフトのビルドは作者が使ってるディストリでしか再現しないと思ったほうがいいくらい
しょうがないからDockerでビルド環境作ったりするけど面倒だしディスクも食うし
結局ディスクキャッシュが多少多いくらいで済んでるRustが一番マシな気がする
948 名前：デフォルトの名無しさん [2024/02/20(火) 19:56:43.04 ID:hRyg00SZ.net]: soが悪いのではなくまともなパッケージマネージャーもまともな依存解決ツールもないのが悪い
949 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 20:07:01.59 ID:+of8n4/M.net]: 確かにOS非依存のC++標準パッケージマネージャと中央レジストリがあれば良かったかもね
ただその場合でもABIが不安定なのはどうしょうもないから
Rustと同じく手元で全部コンパイルする方式になったと思うけど
950 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 20:11:30.03 ID:VuVDzPkr.net]: Cargo 風の管理をする C++ 用パッケージマネージャはある。
最初からそのパッケージマネージャ用に構成してくれてないと
なかなか素直にはビルドできないことに変わりないんだけど。
パッケージマネージャが優秀でも C++ 世界では
「統一されていない」ことが面倒くささになってる。
951 名前：デフォルトの名無しさん [2024/02/20(火) 21:39:15.46 ID:1smOJz8O.net]: そう考えると中間言語形式で配布できてAOTコンパイルもできる.NETがさいつよって話？
952 名前：デフォルトの名無しさん [2024/02/20(火) 21:43:07.30 ID:BYbBGAeA.net]: NuGetが使いやすいと感じた事がないし、充実していると感じたこともない
953 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 21:59:58.18 ID:VuVDzPkr.net]: >>934
dotNET は事前コンパイルしてもランタイムサポートの分厚さ (にかかる実行コスト) は避けられないので
コンピュータの性能を絞りきるようなつよつよ最適化は無理じゃないかなぁ。
いろんな方式の良いところを上手く取り入れて総合的には良いものに仕上がってるとは思うけど
それが最強かというと状況によるんじゃないの。
954 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:14:04.42 ID:sgoVzbhC.net]: >>921
チャプターサンプル毎にプロジェクト作ったら毎回DLしてるように見えるけど
955 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:16:27.29 ID:FbkkUU+G.net]: パッケージの使い勝手という意味ではdocs.rsの存在も大きい気がするな
どんな野良ライブラリでも決まった場所に決まったフォーマットのAPI一覧が確実に存在するというのはかなり便利
956 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:30:04.17 ID:VuVDzPkr.net]: ドキュメントを全く書かなくても少なくとも公開されている一覧はわかるってのは強い。
最悪の場合でもコードへのリンクもあるし。
Haskell のリポジトリがこういう感じだったので他の言語でもこれくらいやればいいのにと思ってたから
Rust で取り入れてくれたのはかなり嬉しい。
957 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:37:39.60 ID:NZma60kC.net]: >>926
いや、スマホでセルフ開発する時に困るだろ？
958 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:45:53.34 ID:VuVDzPkr.net]: >>940
そんなやつはおらんで～～
959 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:47:07.61 ID:1CgxDriU.net]: ス、スマホ？
960 名前：デフォルトの名無しさん [2024/02/20(火) 23:05:21.55 ID:YDnp1LJs.net]: procマクロとかコンパイル環境で展開したいものを除くとtarget指定した環境に依存するだけだから手元でコンパイルする必要性は全くない

いずれにしろどこでビルドするかと中間生成物のサイズが異常にデカくなる話とは別の話だよね
961 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 23:07:55.15 ID:VuVDzPkr.net]: もしスマホで開発する人がいたとしても
レンタルサーバに接続して表面上の操作にスマホを使うだけで、
実質的なストレージ・計算リソースはサーバのものを使う形にするのが普通。
スマホ内で完結させようとしたらツールチェインをセットアップするだけでもクソ面倒くさい話になるぞ。
962 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 00:35:56.53 ID:ax8uXPdD.net]: 働いてないとスマホで開発するとかいう前代未聞の人間がいるんだな
963 名前：デフォルトの名無しさん [2024/02/21(水) 01:44:30.82 ID:q3i686zw.net]: スマホで開発はむしろ最先端
964 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 05:17:16.65 ID:cGlapTzK.net]: iPhoneが出たばかりの頃から、脱獄して開発環境を入れてObjective-Cでプログラミングしてる人は一定数居ただろ。
最近では、どのプログラミング言語でも使えてLinux（Android）と遜色ないよ。
今のスマホは、外部モニターも外部SSDも繋げるし、外部グラボのGPUでLLM開発だってできる。ほぼほぼRaspberryPi5と変わらないよ。
だからこそ組み込みにも強いRustが注目されてるんｼﾞｬﾏｲｶ
965 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 05:44:41.84 ID:cGlapTzK.net]: スマホでRustformersからLLM開発する場合、ローカルにOllama入れとくか、サーバにGPT-4やLlama2を入れとくかぐらいの違いしかない。
Google Coralもスマホでも使える前提の製品で、このチップは発熱量が減ればスマホに内蔵されるだろう。
実際、Vision Transformerのような技術を応用しているApple Vision Proが製品化されたから、スマホからこういった機器に移行するのかもしれない。
今後数年間、これらの技術動向から目が離せない状況が続くんだろう。
966 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 08:28:43.22 ID:/iiJfWDN.net]: ダウンロードしたクレートキャッシュの自動削除はもうすぐ来そう
ビルドキャッシュの自動削除はその後実装予定っぽい
https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning.html
967 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 08:31:36.21 ID:/iiJfWDN.net]: グローバルなビルドキャッシュ共有の話も予定には挙がってるね
968 名前：デフォルトの名無しさん [2024/02/21(水) 09:05:07.84 ID:33Eh81yS.net]: >>934
何を基準でさいつよかの定義による

デスクトップ
Web
バックエンド
iOS/Android
ゲーム

とC#だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC#使えれば何でも作れるという意味ではさいつよ
969 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 09:19:16.71 ID:VUY6mIOu.net]: >>951
.netの毎年の長文blog最適化レポートを見ると2年後くらいでNativeAOT最適化がC/C++に肉薄すると思う
970 名前：デフォルトの名無しさん [2024/02/21(水) 10:25:34.81 ID:ygn/feiE.net]: デスクトップ
Web
バックエンド
iOS/Android
ゲーム

とC言語だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC言語使えれば何でも作れるという意味ではさいつよ
チューリング完全なので
971 名前：デフォルトの名無しさん [2024/02/21(水) 10:33:55.14 ID:3B94ePzU.net]: 無能なやつほどゴールデンハンマー症候群に罹患しやすい
972 名前：デフォルトの名無しさん [2024/02/21(水) 10:37:42.60 ID:33Eh81yS.net]: >>953
嘘ばっかりだなw
973 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 12:23:52.50 ID:FRHKNAr+.net]: >>949
さすがに問題として認識はしてたんだな
スマホセルフ開発の日は近い
974 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 12:50:43.67 ID:ax8uXPdD.net]: マジでスマホしか持ってないの？
クソワロタ
975 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 13:41:48.13 ID:s/93fWsg.net]: ウェアラブル系の機器には失望した。
どこへでも持っていけるよりどこへも往く必要のないインフラこそ目指すべき未来だろ。
976 名前：デフォルトの名無しさん [2024/02/21(水) 14:32:00.13 ID:T2E+AzfY.net]: >>954
同意
977 名前：デフォルトの名無しさん [2024/02/21(水) 15:10:22.61 ID:KvtS9dqN.net]: >>958
背もたれ付きベッド
978 名前：デフォルトの名無しさん [2024/02/21(水) 15:11:12.28 ID:KvtS9dqN.net]: >>953
Rustはチューリング安全だぞ
979 名前：デフォルトの名無しさん [2024/02/21(水) 16:06:34.40 ID:RjxZ1GsP.net]: >>957
働いてないと「スマホで開発==スマホしか持ってない」という発想になるんだなww
980 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:15:10.41 ID:cGlapTzK.net]: >>960
ベッドといえばフランスベッドが取り扱ってるAI 視覚支援機器『オーカムマイアイ2』(OrCam MyEye 2)は、
イスラエルのオーカムテクノロジーズ（OrCam Technologies Ltd）の製品だったな。
これは活字の読み上げみたいだけど、寝具メーカーは、どこへも往く必要のない未来インフラをAI使って目指してるんだろう。
ウェアラブル系が狩猟型・動物型とすれば、寝具系は農耕型・植物型なんだろうな。人間は生活の約３割は寝てるんだから当然だけど。
981 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:30:25.40 ID:vYwp44u6.net]: 表向きはどうであれたぶん寝たきり用だから話を膨らませるのはそのくらいにしとけ
982 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:47:28.48 ID:OHlXXLmE.net]: いくらなんでもスマホでコーデングはせんやろ
983 名前：デフォルトの名無しさん [2024/02/21(水) 16:49:23.05 ID:1mshJDzd.net]: 寝たきりで親指しか動かないとかならスマホでコーディングするかもしれん
984 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:54:05.86 ID:s/93fWsg.net]: 性能がどうこうよりもシンプルに画面が狭いのはすごくつらい。
無理。
985 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 18:17:59.27 ID:ax8uXPdD.net]: >>962
いやお前に当てはめてるだけだぞ
何言ってんだ？
986 名前：デフォルトの名無しさん [2024/02/21(水) 21:37:40.46 ID:4F0o6gVI.net]: はちみつ餃子氏最近見ないからRust関連は触れないことにしたのかと思ったらコテ外して書き込みに来ててわろた
987 名前：デフォルトの名無しさん mailto:sage [2024/02/22(木) 16:00:18.09 ID:o0M/RgFs.net]: >>969
新スレ立ったときに名前欄に入力するのを忘れてたままやな
988 名前：デフォルトの名無しさん mailto:sage [2024/02/22(木) 23:42:55.14 ID:1e40BABA.net]: >>949
毎晩ならその機能もう使えるのか
989 名前：デフォルトの名無しさん [2024/02/23(金) 12:05:46.18 ID:vPqrWVzU.net]: 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうが。
990 名前：デフォルトの名無しさん [2024/02/23(金) 12:05:51.79 ID:vPqrWVzU.net]: 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうけど。
991 名前：デフォルトの名無しさん [2024/02/23(金) 15:12:44.34 ID:z6SHyxko.net]: iPadでXcode使えるからそれで遊んでみれば
992 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 15:20:09.67 ID:CheDQupm.net]: Rustが使えないとな
993 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 15:21:05.22 ID:jTrUecQ5.net]: クソスレまで立てちゃってw
素直に中古のノートPCでも買えよ
994 名前：デフォルトの名無しさん [2024/02/23(金) 16:04:17.89 ID:02Kw336h.net]: traitの種類多すぎて把握しきれん
使い分けもようわからんし
995 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 16:18:25.67 ID:NJWNbZ5N.net]: Pythonのpep20みたいなってRustにもあるの？
996 名前：デフォルトの名無しさん [2024/02/23(金) 16:32:06.33 ID:eHVJk53E.net]: スマホやタブレットなどのモバイルOS上に開発環境用意するのは主に2つユースケースがある
1つはモバイルOS上で実行させる小さなユーティリティを作るため
だいたいlinux emulatorみたいなアプリ内環境で稼働させる
もう一つは出先の空いた時間や障害対応等の緊急時にノートPCを持ち歩かなくても簡易的な作業なら対応できるようにしておくため

前者はスマホだけで作るやつもいるにはいるが少数派
なので今のところはメイン開発環境は別に用意してるのが大半
997 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:15:31.94 ID:kgcjkDLJ.net]: PEP20って何だよと思ったらあのウンコポエムだった
998 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:26:44.63 ID:kgcjkDLJ.net]: 次スレタイトル間違えてしまったのですまんが
999 名前：誰か立て直してくれ 規制食らってもう立てられなくなった []: [ここ壊れてます]
1000 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:35:21.56 ID:CheDQupm.net]: >>977
traitとは機能を抽象化した抽象型だから使いたい機能のtraitを選ぶか作ればよい
structなどの具象型は各々必要な各機能(trait)を実装しているもしくは実装すればよい
そして抽象型(trait)を用いてプログラミングすることでその機能を実装する全ての具象型を対象とした共通コードにできる
1001 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:38:39.47 ID:CheDQupm.net]: 次スレ
Rust part23
https://mevius.5ch.net/test/read.cgi/tech/1708677472/
1002 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:45:54.27 ID:kgcjkDLJ.net]: >>983
ありがとう
1003 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:51:32.20 ID:jYYzpIEX.net]: >>978
こういうのをまとめようとはしているよ
https://smallcultfollowing.com/babysteps/blog/2023/12/07/rust-design-axioms/
1004 名前：デフォルトの名無しさん [2024/02/23(金) 20:10:18.94 ID:1IK2X2kO.net]: >>982
FromとかAsRefとかDerefとかの時点でもうようわからんぜ
1005 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 22:42:10.08 ID:oukljDwS.net]: Fromは汎用的な変換だよ
変換に失敗する可能性を含む時はTryFromを使う

AsRefは参照から(別型の)参照への読み替え変換
コストがかからない場合が対象
コストがかかるものはFromを使う

Derefは変換ではなく演算子
変換は複数の型への変換を実装できるけど
演算子なので各型で決められた一つの型へderefできる
&T→T
Box<T>→T
Rc<T>→T
Vec<T>→[T]
String→str
PathBuf→Path
など
1006 名前：デフォルトの名無しさん [2024/02/23(金) 23:50:59.87 ID:1IK2X2kO.net]: あー。それぞれの比較はまあそうなのかもしれないんだけど、そもそもどういうtraitがあってどういう時に使うべきなのかを全て把握できてないせいで実際にコード書く時にどれを使うとRustらしいコードになるのかわからなくなるってのがしんどいんだよね
1007 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 23:59:41.76 ID:hX/YHnPg.net]: >>988
どの分野のどんな話でも基本パターンの学習による慣れ
問題

match std::env::args().XXXXX {
　Some("yes") => ...,
　Some("no") => ...,
　_ => ..., // エラー
}
1008 名前：デフォルトの名無しさん [2024/02/24(土) 02:12:39.95 ID:YQ3M0cmx.net]: 梅
1009 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 04:00:00.27 ID:felFEjYK.net]: 「当然こういうのが標準ライブラリにあって然るべきだろう」みたいな感覚ができるから結局は慣れ。
常識的に考えてあるだろうと思ったら nightly だったみたいなこともよく経験するから俺が欲しいようなものはみんな欲しいんだなと思う。
実質的に言語の一部みたいなくらいのやつは嫌でも避けられないから何度もドキュメントを読み返すはめになるし、そのうち自然に使えるようになる。
1010 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 12:21:57.67 ID:lhpjpr9r.net]: >>987
Derefは演算子でも利用されるがDerefそのものが演算子(や演算子の実装)というわけではない
Type Coercionというのは型変換(Type Conversion)の一種なのでDerefは変換ではないというのもやや言い過ぎ

各型で決められた一つの型にderefされるのは演算子だからという理由ではなくて
Derefはスマートポインタが包んでる値へのアクセスを便利にするために用意されたものだからderef先の型は自然と一つに決まるため(>>733)

&T→TはDerefの役割ではない
1011 名前：デフォルトの名無しさん [2024/02/24(土) 12:57:43.72 ID:Sbx59RJL.net]: AsRefとBorrowは未だにわからんなあ
調べてもHashMapがBorrow要求するならそこだけBorrow使っておけばいいか……で思考停止してる
1012 名前：デフォルトの名無しさん [2024/02/24(土) 13:58:08.04 ID:Q2pRspv0.net]: 埋
1013 名前：デフォルトの名無しさん [2024/02/24(土) 13:58:23.94 ID:Q2pRspv0.net]: 生め
1014 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:58:40.99 ID:Q2pRspv0.net]: 、埋め
1015 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:58:46.56 ID:Q2pRspv0.net]: ！埋め
1016 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:58:52.17 ID:Q2pRspv0.net]: ？埋め
1017 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:59:00.55 ID:Q2pRspv0.net]: ○埋め
1018 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:59:07.65 ID:Q2pRspv0.net]: ～埋め
1019 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 34日 14時間 37分 28秒
1020 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef