Rust part22

**デフォルトの名無しさん** · 2024/01/20(土) 23:21:40.08

公式
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/

**デフォルトの名無しさん** · 2024/02/14(水) 23:19:42.33

>>803
コンセプト。

**デフォルトの名無しさん** · 2024/02/14(水) 23:20:56.22

>>792
毎度毎度のことで余裕を削られた最後だったんだよ。

**デフォルトの名無しさん** · 2024/02/15(木) 00:20:11.01

毎度毎度のことという認識を持っていながらなぜここに書き込むのか

**デフォルトの名無しさん** · 2024/02/15(木) 00:23:07.31

>>806
せやな。
けど日本で比較的活発な Rust コミュニティというとここなんよ。

**デフォルトの名無しさん** · 2024/02/15(木) 07:06:08.60

>>804
concept記述が多すぎて書いててイヤになるな
普及しそうにない仕様がまたC++に増えた感じ
Rustが必要な機能を洗練して提供しているのと対照的

**デフォルトの名無しさん** · 2024/02/15(木) 07:43:10.62

>>808
洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。
枯れた既存プログラムの置き換え用途が無難なところかと。
コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。

**デフォルトの名無しさん** · 2024/02/15(木) 07:55:56.64

>>809
Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に
RustやめてGoにする宣言してる
理由を真面目に話してるから一見の価値のあり

**デフォルトの名無しさん** · 2024/02/15(木) 08:11:38.37

>>810
検索したけど見つからなかった……
リンクある？

**デフォルトの名無しさん** · 2024/02/15(木) 08:17:50.82

[Why I Use Golang In 2024](https://www.youtube.com/watch?v=6gwF8mG3UUY)

**デフォルトの名無しさん** · 2024/02/15(木) 08:19:40.94

>>812
サンクス。
家帰ったら見るわ。

**デフォルトの名無しさん** · 2024/02/15(木) 08:48:36.69

>>812
見た
ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い
そして批判されてるのはなぜかTypeScrpt
Goについてはシンプルなのが好きでジェネリックが導入されてワクワク
Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ
Rustの型システムはとても素晴らしいけど、

**デフォルトの名無しさん** · 2024/02/15(木) 09:52:51.93

>>808
過去のコードと矛盾しない形での後付けだからな。
C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。
簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。
Rust だって歴史が積み重なればいずれそうなる。
「綺麗なのは使われないもの」という格言を聞いたことないか？
Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。
規格策定・処理系保守のリソースは無限なわけではないしな。

**デフォルトの名無しさん** · 2024/02/15(木) 09:55:25.99

エディションはすでに複数あるけど
あっても無理とか問題起きるとか
実例あるの？

**デフォルトの名無しさん** · 2024/02/15(木) 10:07:56.04

>>816
問題が抑えられているのは問題がないように保守されているからで、
その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。
今問題があるとかそういう話じゃないから未知数と述べてる。

**デフォルトの名無しさん** · 2024/02/15(木) 10:11:47.35

C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ
C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる

**デフォルトの名無しさん** · 2024/02/15(木) 10:21:13.40

まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは

Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある

**デフォルトの名無しさん** · 2024/02/15(木) 10:32:36.57

>>817
今は良くても未来は何が起こるかわからない論法は
何にでも使えるから意味ある話とは思えないけど…

**デフォルトの名無しさん** · 2024/02/15(木) 10:37:24.02

「出来る」ということを大前提として確信できて、
その上で「上手く出来る」ならより良いってのが産業的な考え方だ。
おおよその場合に上手く出来ても
ちょっとした想定外に直面したときに破綻するようでは使い物にならない。

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

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

Rust は今の時点では実に使いやすいように見えるが、
本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。

**デフォルトの名無しさん** · 2024/02/15(木) 10:38:37.60

今の時点で使いやすければなんでもいいんだYO

**デフォルトの名無しさん** · 2024/02/15(木) 10:45:22.07

C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない
これだけ増築工事を重ねてもまだ見込みが立たないまま

**デフォルトの名無しさん** · 2024/02/15(木) 11:47:28.36

C++の知識は大いに再利用されているので現実世界の変化は小さい
想定外かもしれないのは変化の大きさではなく
現実世界を定義できないことだ
定義できるのは理論だけ

**デフォルトの名無しさん** · 2024/02/15(木) 12:02:34.79

>>821
今の想定が甘いとか具体的指摘なかったら
想定外の対処ができてないから駄目は無敵論法

**デフォルトの名無しさん** · 2024/02/15(木) 14:40:35.94

そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ
パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分

**デフォルトの名無しさん** · 2024/02/15(木) 14:47:01.34

サーバーサイドは群雄割拠時代よね
Rust、Go、Java/Kotlin、C#いっぱいある

**デフォルトの名無しさん** · 2024/02/15(木) 16:20:13.71

>>825
駄目とは言ってない。
駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。

**デフォルトの名無しさん** · 2024/02/15(木) 16:46:19.25

>>828
あなたの話相手してもrustでも他言語でもいいけど
問題回避のためにこういう仕様や実装にすべきじゃないか
みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね

**デフォルトの名無しさん** · 2024/02/15(木) 16:50:52.01

すべてを疑っても産業だけは疑いようがないって話なら
想定内と想定外の境界がどの辺にあるのかはなんとなくわかる

**デフォルトの名無しさん** · 2024/02/15(木) 17:21:54.77

>>814
Rustは型〇ナニーで長時間バトルだったと言ってるぞw
>>812動画の人がいくら天才でも2年間かき回したのは頂けない

**デフォルトの名無しさん** · 2024/02/15(木) 17:26:25.25

Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い
さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい

**デフォルトの名無しさん** · 2024/02/15(木) 17:31:26.55

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

**デフォルトの名無しさん** · 2024/02/15(木) 17:35:21.87

>>832 夢見てないで現実見ては？
https://active.nikkeibp.co.jp/atcl/act/19/00546/011500001/

**デフォルトの名無しさん** · 2024/02/15(木) 17:41:41.98

>>812
流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草

**デフォルトの名無しさん** · 2024/02/15(木) 17:53:07.04

>>835
Rustインフルエンサーの成れの果てですなw

**デフォルトの名無しさん** · 2024/02/15(木) 18:08:05.70

>>834
せめて用途別のプログラミング順位を挙げてくれ

…単発に言っても無駄か😭

**デフォルトの名無しさん** · 2024/02/15(木) 18:08:23.00

Goは２年も続けられるだろうか

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

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

file, err = os.Open(path) // ← fileと一緒にエラーの受け取りを強要される
os.Chdir(path) // ←エラーしか返さないから戻り値を無視して処理を継続できる

**デフォルトの名無しさん** · 2024/02/15(木) 18:11:15.85

>>829
情報が充分じゃない (から議論を始めることさえできない) ことが
リスクだという話をしているつもりなんだが、伝わってないのか？
どんな問題が起こるのか事前にわかれば苦労しないよ。

起きたことに対処し続けるしか仕方がないが
可能なら自分が対処する当事者にはなりたくない。

**デフォルトの名無しさん** · 2024/02/15(木) 18:19:47.46

「Go」、2月のTIOBE指標で過去最高8位に
https://japan.zdnet.com/article/35215159/
https://japan.zdnet.com/storage/2024/02/13/0ee0eaf7a75e201ad2ee580740569609/240213_tiobe.png

**デフォルトの名無しさん** · 2024/02/15(木) 18:24:55.60

>>838
悪いほうがよい (Worse is Better) 原則というものも知られている。
正しさと単純さを天秤にかけてどちらが良いかという点で Rust とは異なる重みづけをしたのが Go だと思う。
問題をコンパイラが検出できる設計はもちろんありがたいが、そのために持ち込む構造は人間が把握しやすいものだろうか。
正直言って Go が良いとは全然思わないが一貫した理念に基づく判断であって、不備でそうなってるわけではない。

**デフォルトの名無しさん** · 2024/02/15(木) 18:31:33.80

>>829 >>839
このあたりは設計の根深い問題で、「変化を抱擁する」を標語としたアジャイル開発とかインクリメンタル開発とかで色々議論されたな。
あんまり目立った成果は無かったような気もするけど、機能間の疎結合と可換性は重要な指摘だと思うわ。

**デフォルトの名無しさん** · 2024/02/15(木) 18:34:16.56

>>817
これはごもっともな意見
50年後にRust 2072エディションがある状況で最新コンパイラが2015エディションをサポートし続けてるとは思えないからどこかでは切ることになる
それでもRustのモデルとC++のモデルとどちらのほうが相対的によさそうかという選択の問題

**デフォルトの名無しさん** · 2024/02/15(木) 19:40:03.38

50年後にC++23はサポートされているのだろうか
というかC++は50年後もアップデートしているのだろうか

**デフォルトの名無しさん** · 2024/02/15(木) 19:52:43.98

>>843
cargo fix --edition
のあるRustは至れり尽くせりだよ

**デフォルトの名無しさん** · 2024/02/15(木) 20:00:49.77

>>844
既にC++17とC++20で以前導入の機能の削除が大量に行われている

**デフォルトの名無しさん** · 2024/02/15(木) 20:11:12.94

じゃあもうRustで良いじゃん

**デフォルトの名無しさん** · 2024/02/15(木) 20:27:48.49

CになかったC++の機能は削除してもチューリング完全が保証される
逆に、削除したらチューリング完全ではない保証をするならミニマリズムがベター

**デフォルトの名無しさん** · 2024/02/15(木) 22:27:00.96

>>840
Kotlinが上がってきてるのうれしい
Fortranも上がってるのはなぜだ

**デフォルトの名無しさん** · 2024/02/15(木) 22:56:46.83

C++ は欠陥報告という制度で過去の規格に遡って修正が加えられることがある。
たとえば C++11 発行当時の C++11 と今の C++11 は内容が異なるわけ。
基本的には過去の仕様に新機能を追加したりはしないが微妙な挙動の変なところを直すような保守は続いている。
実質的には Rust のエディションみたいなことにはなってるんだよなあ。

**デフォルトの名無しさん** · 2024/02/15(木) 23:13:05.86

llvmも実装はc++だし。

**デフォルトの名無しさん** · 2024/02/15(木) 23:33:02.83

>>850
Rustは必ずeditionを明示しないといけないから
あるソースコードがどのeditionなら確実に動くのか明確にわかる
そしてそのeditionを指定してコンパイルも通り実行もできる

しかしC++は当初のC++11に従いコンパイルできて動いていたものが
今はC++11の機能のいくつかは削除されてしまっているために

**デフォルトの名無しさん** · 2024/02/15(木) 23:44:16.83

>>852
C++11 は C++11 として存在し続けているので問題になってないという話をしてるんだが

**デフォルトの名無しさん** · 2024/02/15(木) 23:57:58.06

一般人と同等の読解力を複オジに期待しないこと

**デフォルトの名無しさん** · 2024/02/16(金) 01:17:00.51

cppreference.comの下のほうにちょろっと書いてあるdefect reportってそういうことだったんだ
勉強になるわ〜

**デフォルトの名無しさん** · 2024/02/16(金) 02:58:58.82

>>853
名前が同じならなんでも良い…… ってこと！？

**デフォルトの名無しさん** · 2024/02/16(金) 05:29:44.45

>>856
「規格が同じなら」ということだよ。

c++11とかはあくまで規格なので各実装の準拠率とか注意するポイントはあるけど、メジャーな機能を保守的に使えばそれなりに互換性を維持できる。

**デフォルトの名無しさん** · 2024/02/16(金) 06:06:29.14

RustのEdition方式が優秀すぎる
新たな機能の規格で分けるのではなく
各Editionは後方互換性の変化で分けているため
過去に書かれたコードも必ず動く

**デフォルトの名無しさん** · 2024/02/16(金) 08:50:06.12

>>857
規格が同じといいつつ機能消してんだから同じなのは規格の名前だけじゃん

**デフォルトの名無しさん** · 2024/02/16(金) 08:50:57.44

規格から機能ごと消えるんならよう

**デフォルトの名無しさん** · 2024/02/16(金) 08:57:09.07

>>859
消してないけど何いってんの？

**デフォルトの名無しさん** · 2024/02/17(土) 07:36:35.11

ID:T31Boec7
流石にこいつ日本語能力なさすぎだろ
ガイジかな？

**デフォルトの名無しさん** · 2024/02/17(土) 07:58:38.87

mojo vs rustでmojo公式とnetflix天才とRust本著者で盛り上がっている
https://www.youtube.com/watch?v=MDblUyz0PtQ

>>814,835
早口なので大変だろうけどちょとした言葉の節々に情報があるからリスニングがんばれ

**デフォルトの名無しさん** · 2024/02/17(土) 08:38:43.36

>>863
copilotで要約して貰うのが時間も短縮できるのに無能だなw

**デフォルトの名無しさん** · 2024/02/17(土) 11:31:52.42

>>864
この天才同士のディスカッションを楽しめないなんて損してんね🥲

**デフォルトの名無しさん** · 2024/02/17(土) 11:55:10.10

Netflixの天才とかいうのが胡散臭くて信頼性がないんだけどどういう人なのよ。

**デフォルトの名無しさん** · 2024/02/17(土) 12:54:06.77

>>863
この人の英語聞き取りにくい
もうちょっとゆっくり喋って欲しい
中身うっすいのにさ

**デフォルトの名無しさん** · 2024/02/17(土) 12:58:21.47

>>862
普通に境界性知能ってやつでは？
この手のは全部そうだと思うようにしてる

**デフォルトの名無しさん** · 2024/02/17(土) 17:40:44.30

>>863
ベンチマーク試してみたところ以外はブログ記事のまんまなのでわざわざ動画で見なくてもいいなこれ

公式ブログに書くならもうちょっとちゃんとしたベンチマークやれよって感じ
見識を疑うレベル

**デフォルトの名無しさん** · 2024/02/17(土) 18:56:01.48

Netflixの天才がいかがでしたかブログレベルの動画を出すとは

**デフォルトの名無しさん** · 2024/02/17(土) 19:01:49.62

>>863
動画内の指摘が記事に反映されてMojoがRustの3倍速いじゃん!!
Mojoコンパイラ賢いな

**デフォルトの名無しさん** · 2024/02/17(土) 19:07:25.89

以前からMojoがCより何倍も速い！とかやってるけど
ベンチ方法や条件などが何かおかしい

**デフォルトの名無しさん** · 2024/02/17(土) 20:11:15.92

SIMDが効くような恣意的なベンチだしな

**デフォルトの名無しさん** · 2024/02/17(土) 21:00:37.77

でもデータを見てから断罪するのは俗っぽいから
データを見ないでロジハラするのがベター

**デフォルトの名無しさん** · 2024/02/17(土) 21:16:16.12

DynamicVectorは最適化でSIMD使うように最適化されるってだけだろ
あと末尾最適化する
くだらなすぎる

**デフォルトの名無しさん** · 2024/02/17(土) 21:40:36.38

え？　Rustって末尾最適化できんの？

**デフォルトの名無しさん** · 2024/02/17(土) 23:56:23.75

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

**デフォルトの名無しさん** · 2024/02/18(日) 09:43:13.97

>>873,875
同じLLVM系なのにRustが3倍遅いのかよ!!
Mojoがコンパイラ賢いのかRustコンパイラが...

**デフォルトの名無しさん** · 2024/02/18(日) 10:23:17.76

あれを見て本当にRustが遅いと思っちゃう層の人にRustは向いてない

**デフォルトの名無しさん** · 2024/02/18(日) 10:24:13.10

ちなみにSIMD云々は本質じゃないよ

**デフォルトの名無しさん** · 2024/02/18(日) 10:33:07.03

>>879が3倍速いRustコードを出すってよ

**デフォルトの名無しさん** · 2024/02/18(日) 10:46:23.01

これはGoの方が速いんじゃないか？

**デフォルトの名無しさん** · 2024/02/18(日) 11:13:09.56

GoはGCを伴う言語だから論外
MojoはC/C++/Rustより3倍速い

**デフォルトの名無しさん** · 2024/02/18(日) 11:27:28.89

>>878
同じLLVMといってもMLIRという数値計算に最適化されたIRを使ってるから速い
恣意的な例である

**デフォルトの名無しさん** · 2024/02/18(日) 11:36:55.83

そういえば昔Delphiがコンパイルの速さを売りにしてたの思い出した
なんか懐かしい

**デフォルトの名無しさん** · 2024/02/18(日) 12:18:39.29

20年後にRustを懐かしむスレはここですか？

**デフォルトの名無しさん** · 2024/02/18(日) 14:55:22.54

20年後には流石にもっと良い言語が登場して流行っていることを期待している

**デフォルトの名無しさん** · 2024/02/18(日) 15:22:23.80

>>885
アンダースヘルスバーグ天才だよな
ボーランドでDelphi作って
マイクロソフトでC#とTypeScript作って

**デフォルトの名無しさん** · 2024/02/18(日) 15:34:23.48

>>888
MAUIくん！病室に戻るんだ！

**デフォルトの名無しさん** · 2024/02/19(月) 09:27:30.10

>>888
俺は天才とは思わない
この人ってお手本となる言語があって
それをよりよくすることは得意な気がする

**デフォルトの名無しさん** · 2024/02/19(月) 10:19:49.07

普通の人が実務で使うような汎用プログラミング言語は
とびぬけた画期的なパラダイムで構成しても使い難いし、
ひとつひとつはどうということはない要素を上手く組み合わせる
バランス感覚が重要って感じはあるね。
天才的な閃きでどうにかするようなものではない。

**デフォルトの名無しさん** · 2024/02/19(月) 11:58:45.15

既存のものをうまく組み合わせたりリーダーシップをとったりするのに天賦の才があったという意味なら天才かな

**デフォルトの名無しさん** · 2024/02/19(月) 12:07:19.13

自分は何も出来ない無才なのによく言うわw

**デフォルトの名無しさん** · 2024/02/19(月) 14:11:02.99

C#→Javaのビミョーなところを直す
Delphi→Pascalのビミョーなところを直す
TypeScript→JSに型付け

**デフォルトの名無しさん** · 2024/02/19(月) 14:41:59.29

Rustのビミョーなところを直して欲しい

**デフォルトの名無しさん** · 2024/02/19(月) 15:33:58.75

R#だすかー

**デフォルトの名無しさん** · 2024/02/19(月) 16:37:49.01

Turbo PascalやDelphiやVisual J++は彼か作ったと言えるがTypeScriptはHejlsbergが作ったわけじゃないからな

広報+コントリビューター+社外との政治的調整役

**デフォルトの名無しさん** · 2024/02/19(月) 18:10:38.68

R#とか絶対統計処理用の言語じゃん

**デフォルトの名無しさん** · 2024/02/19(月) 18:20:06.89

そうだな
じゃあRustyNailって名前にするか

**デフォルトの名無しさん** · 2024/02/19(月) 18:38:07.38

ビミョーなところをどうにかしたってどうせ別のビミョーなところが出てくるに決まってるんだよ。
だましだまし発展させて行き詰まったあたりでまた新しい何かが登場するのが世の中のサイクルというもんだ。

**デフォルトの名無しさん** · 2024/02/19(月) 18:50:17.05

割とマジでヘルスバーグ動きますの可能性はある
Carbon、Go→Google
Rust→Mozilla
？→Microsoft

この流れは確かにある

**デフォルトの名無しさん** · 2024/02/19(月) 20:05:38.11

GoogleもMicrosoftもRust支持で
Carbonの公式FAQにはRustが使えるならRustが良いと明記されている

**デフォルトの名無しさん** · 2024/02/19(月) 20:34:12.24

Rust支持というより、現状最良の選択肢がRustであると認めているだけでは
なのでもっと良い選択肢を作ることが出来たら嬉々として打ち出してくる可能性はあると思う