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/02(金) 12:27:55.82

>>70
費用対効果考えると厳しいな。

c++のプロジェクトをRustに切り替えるよりか、コーティング規約組んでlint用意して強制したほうが効果高そう。
既存コードの扱いが難しいけど。

**デフォルトの名無しさん** · 2024/02/02(金) 13:20:50.14

Webアプリ用途でもAxumやActixがフレームワークとして十分使いやすいから、もっとRustは普及していい

**デフォルトの名無しさん** · 2024/02/02(金) 13:32:21.68

c++ から rust に移すなら、その前に c++ コードのリファクタリングとしてmove使用コードに直すだろうし、
それやったらもうそれで良くね？ってなると思うわな。

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

言語移植はそのうちAIがなんとかしてくれるんじゃなかろうか

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

所有権があるから GC 言語からの移行でも安全になる恩恵はあるんだよなぁ。

ほんとエポックメイキングな言語だよ。

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

rustの最大のメリットは、絶対では無いけどコンパイルさえ通ってれば他人のクソコードに悩まされずに済む点じゃないかね。

**デフォルトの名無しさん** · 2024/02/02(金) 21:11:58.02

>>76
なんで悩まされないの？

**デフォルトの名無しさん** · 2024/02/02(金) 21:33:43.48

Rustでも糞コード見かける
たとえば非常に単純な例でいうと元の部分strを返せば済むのにString作っちゃうなど無駄にヒープ使ってしまうケース
でも見抜きやすく手直しもしやすい

**デフォルトの名無しさん** · 2024/02/02(金) 21:34:56.76

Rust以外でよく見かけるのはど
こで書き換わっているかわかりにくく副作用や競合が心配なケース
Rustではデータ競合が起きないしグローバル変数も制限があるためこの手の類には悩まされない

**デフォルトの名無しさん** · 2024/02/02(金) 22:24:30.77

メリットが欲しいと思ったことはないな
新しいジャンルで唯一の選択肢なのでメリットの大きさを比較する必要がない
異なるジャンルでは比較する意味がわからない

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

>>78
1周回ってString返したほうが良くなる状況もあるからそんなに単純じゃないよ

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

>メリットが欲しいと思ったことはないな
誰もメリットが欲しいかどうかについては話してないよｗ

**デフォルトの名無しさん** · 2024/02/02(金) 22:34:00.04

>>81
それは絶対にない
部分str返しで済むなら必ずそうすべき
それを返された側がString化が必要な時のみ行なう

**デフォルトの名無しさん** · 2024/02/02(金) 22:36:34.16

欲しくないものを供給している可能性を誰も想定していないのか

**デフォルトの名無しさん** · 2024/02/02(金) 22:47:15.09

わかりやすいのがstr.trim()かな
前後のスペースを取り除く関数だけど当然Stringではなくstrの一部分を返す
Stringがほしい人はstr.trim().to_string()

**デフォルトの名無しさん** · 2024/02/02(金) 22:52:35.98

>>85
欲しい人にもそうでない人にも対応できるように&strがベストとは思わんか？

**デフォルトの名無しさん** · 2024/02/02(金) 22:55:20.18

>>86
同じ主張だよ
str返しが可能ならStringを返してはいけない
slice返しが可能ならVecを返してはいけない

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

上書きされる前に別の場所にコピーした方が比較的安全というメリットが消えた
Rustが消した

**デフォルトの名無しさん** · 2024/02/02(金) 23:26:54.37

>>88
Rust以外ではいつ書き換えられたりor解放されたりするかわからないから
安全なプログラミングということで(無駄になる恐れもあるけど)コピーしておく安全策をとることがあった

Rustでは知らぬ間に書き換えられたりor解放されたりすることはないので
安全策を保ったままで無駄なコピーが不要となった

**デフォルトの名無しさん** · 2024/02/02(金) 23:26:59.82

Stringを使うことで無駄に専有されるヒープメモリはそこまで悪に感じないわ
カーネル作ってるわけでも競技やってるわけでもないんだったらね
可読性のために型を統一させるほうを優先する

**デフォルトの名無しさん** · 2024/02/02(金) 23:34:55.21

>>90
主張がよくわかりません
&strを渡せば済むところをString渡しで統一したりしてるのですか？
それで可読性が上がるとは思えません

**デフォルトの名無しさん** · 2024/02/03(土) 00:06:15.17

>>90
そのためにムダにto_string()やそのclone()をするのは間違い
他の言語やスクリプト言語ですらそんな酷いことは行われずにコピーオンライトやインターン化でムダを防いでいる
Rustではまずは&strで行ける範囲は&strで行き次にCow併用そして同じ中身のStringが複数できるならstring_cacheなどでインターン化など

**デフォルトの名無しさん** · 2024/02/03(土) 00:06:54.99

C++でもstring_viewとstringは使い分けるぞ

**デフォルトの名無しさん** · 2024/02/03(土) 00:39:47.95

&strでいいなら&strで返すのが基本だけどプログラム全体を見たときにStringで返したほうがものすごくコードを単純にできる場合がある
アロケーションコストが全く問題にならない状況であれば&strに固執する必要はない
無駄なヒープアロケーションは増えるけど違う観点の無駄を削減してる
トレードオフだよ

型を統一するって話はよくわからんけど

**デフォルトの名無しさん** · 2024/02/03(土) 00:41:39.18

そこ気にしないなら普通にスクリプト言語でも使っとけば良いと思うよ

**デフォルトの名無しさん** · 2024/02/03(土) 00:44:03.79

>>94
そんな例は起きない
strを返された側でString化が必要な時のみするのがベスト

**デフォルトの名無しさん** · 2024/02/03(土) 05:44:40.82

>>96
そりゃベストはそうだろうけどさ…
c++で言うchar型で良いところをわざわざstdのStringを使うなって話でしょ？
動的メモリ確保になってようがその程度の誤差くらい動けばどっちでもいいわ…

**デフォルトの名無しさん** · 2024/02/03(土) 06:03:57.16

>>95
Rustから一気にスクリプト言語は飛躍しすぎだからスクリプト言語より先にガべコレ付き言語を薦めてくれ
ガべコレ付き言語はヒープメモリを気にしない人にはおすすめだよ

**デフォルトの名無しさん** · 2024/02/03(土) 06:28:46.54

>>97
文字列だけでなく一般的な話
部分スライスを返せば済むところをわざわざVecにして返すことが許されるのか？という話だぞ
これを誤差だと言い張るならRustを使う資格はない

**デフォルトの名無しさん** · 2024/02/03(土) 06:58:55.64

こだわりの強い人がおるなあ

**デフォルトの名無しさん** · 2024/02/03(土) 07:31:56.62

sliceやstrですむのにVecやStringを使ってしまう人はlifetime parameterを習得できていなくて使えこなせないからだと思うよ
structやfnでlifetime parameterを付けたことのない初心者に多いね

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

こういうふうに面倒くさい人がRust使いには多いから普及しないんだろうなあ
アルゴリズムとデータ構造の分野からみてもクッソどうでもいい議論だよ

**デフォルトの名無しさん** · 2024/02/03(土) 07:41:20.05

>>102
アルゴリズムとデータ構造の一番の基本が無駄なコピーをしないこと

**デフォルトの名無しさん** · 2024/02/03(土) 09:16:17.07

strで返せるがあえてStringで返すと良い具体例を出せばいいのではと思った。

**デフォルトの名無しさん** · 2024/02/03(土) 11:13:51.22

富豪的プログラミングしたいならrustは向いてないよ
普通にpythonで十分

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

でもPythonのDjangoは遅くてゴミじゃん
省メモリ最速のWebアプリ作るならRust一択だわ

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

例えばsplitみたいなのはstrで返せるけど、それを大量に呼んで受け側でto_stringをつける場合、
コードがto_stringだらけで見づらくなるとかはあるかな
そういう時にsplit_to_stringみたいな名前でString返すようにしたりはするけど
自分の場合、どっちかっていうとパフォーマンス云々より関数名から内部でアロケーションが連想されるかどうかを重視してる気はする

**デフォルトの名無しさん** · 2024/02/03(土) 11:24:32.59

rustでwebアプリなんてコストかかりすぎでは？ふつーにgoかjava/kotlinかc#で作ればいいじゃん

**デフォルトの名無しさん** · 2024/02/03(土) 11:28:03.29

>>104
ないでしょ
少なくともその関数側で判断できるものではない
帰ってきた文字列をどうするかは使う側が決める
これはrustに限った話ではなくプログラミングのお作法の話
文字列を変更したいという意図で所有権を持った文字列を作りたいならto_ownedすべきだし
そうでないならライフタイムを意識してそのまま使えばよろしい
C/C++でも全く同じ話よ
C++ならstring_viewを返す
そこであえてstringを返す意味はライブラリ提供者側にはない
例えば10000回のループの中でそのような関数が呼ばれたらどうなるか？
恐ろしいことになる
C/C++だと常にそういうことを考えてる
pythonとかだと全部stringだから意識してないのだろうけどさ
本来は意味のないアロケーションであることが多い

**デフォルトの名無しさん** · 2024/02/03(土) 11:32:33.77

>>107
大量であっても&strのままでよいものはString化しない
String化が避けられない場合でも大量ならばイテレータで処理してるはずなので.into()の数は少ないはず
いずれの場合でも関数は&strを返せばすむ

**デフォルトの名無しさん** · 2024/02/03(土) 11:33:55.72

正しいことが必ずしも正義とはならない、とだけ言っとくわ

**デフォルトの名無しさん** · 2024/02/03(土) 11:36:04.38

>>108
RustでWebは容易かつ向いている
Rustの公式アンケート世界調査でも最多利用はWeb分野

**デフォルトの名無しさん** · 2024/02/03(土) 11:47:22.41

rustあんま使ってない人だけど、strはImmutableでstringはMutableなんでしょ？
文字列配列を柔軟に扱いたいときだけstringで色々して、データを受け渡しするときは当然strを使うのがモラルってもんでしょ
immutable_stringはよく知らん

**デフォルトの名無しさん** · 2024/02/03(土) 11:50:08.77

今現在Rustが実際に多く使われてる分野って、スクリプト言語の下まわり、ライブラリ高速化だよね
だからそれはWeb用だと言われたらまぁそう

**デフォルトの名無しさん** · 2024/02/03(土) 11:51:38.36

>>112
108だけどそれはasm.jsの代替のwebアセンブリってやつをrustでやってるんでしょ
webアプリとは違うねん

**デフォルトの名無しさん** · 2024/02/03(土) 11:53:33.66

単なるWebサイトの演算処理の補助用途とWebアプリ用途を一緒にしてほしくない
全然違うねん

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

>>114>>115
Rustの利用で最も多いのは
Webサーバーサイド・バックエンド・クラウド
https://gihyo.jp/assets/images/article/2022/09/rust-monthly-topics/in_what_technology_domain_is_Rust_used_at_your_company.png

>>116
Webアプリのサーバーサイドとして使われています

**デフォルトの名無しさん** · 2024/02/03(土) 12:09:03.48

>>117
スクリプト言語のライブラリとしてRust使ってる人はそんなアンケートに答えないし
自分がRust使ってる自覚もないよ

**デフォルトの名無しさん** · 2024/02/03(土) 12:13:31.67

rust開発チーム直々の調査結果なんね
ちゃんとぎひょう記事urlも貼ってくれ
https://gihyo.jp/article/2022/09/rust-monthly-topics-01

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

>>118
Rustで何を開発しているか？だからそれら別言語の人は関係ない
PythonやJavaScriptなどのライブラリが最近はRustで書かれることが増えたが
その開発者たちもRust利用者全体から見れば少数
一番多いのはWebのサーバーサイド・バックエンド・クラウド

**デフォルトの名無しさん** · 2024/02/03(土) 12:35:09.79

WASMはRustに限らずそんなに大っぴらに普及しないと思う
ゲームエンジンかエンコーダーデコーダーくらいにしか需要がない
GUIとしてのWASMはDOM操作を直接できない時点でゲーム操作用途にしか使えないゴミ、終わっとる

**デフォルトの名無しさん** · 2024/02/03(土) 12:55:06.68

wasmは触ってみりゃ分かるけどjavascriptの演算処理を単にrustで書いてコンパイルしてみると、rustのstdがバイナリに同梱されるせいで移植前のスクリプト状態よりファイルサイズが増加するんだよね
wasmテキスト形式で書くかstdレスなrustで書かなくちゃ本末転倒になる
まあファイルサイズが増加してでも演算処理を高速化したいならいいんだろうけど俺は吐いた

**デフォルトの名無しさん** · 2024/02/03(土) 13:12:09.54

>>117
組み込みシステム開発者なんていう有能が溢れるほどいるわけないし妥当な結果ね

にしてもRustがサーバー開発でこんなに占めてるんだねえ

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

>>121
WASMはWebブラウザ内用途だけではないよ
CDNエッジでの利用も増えているね
WASIなどによる拡張でできることは無数に増えてく

>>122
stdは無くてもRustは機能するようにできているよ
例えばスライスやstrはcoreにあるし
VecやStringはallocにあるよ

**デフォルトの名無しさん** · 2024/02/03(土) 13:45:54.96

WASIはモバイルOSあるいはデスクトップOS業界がどう動くかだね
wasmerみたいなWASIランタイムをOSが標準装備してくれるなら、WASIの注目度が上がるし、OSに依らないアプリを手軽に作れる
特にモバイルOSではランタイム同梱によるアプリの肥大化を阻止できる

WASIは今のままではJVMのようにマルチプラットフォームなランタイムの上で動くアプリでしかないから、どっかの有名なプラットフォームが積極的に土台として採用しないと忘れ去られる
UnityでもAndroidでもどこでもいい

**デフォルトの名無しさん** · 2024/02/03(土) 14:00:52.18

まあ数日前にWASI 0.2.0の仕様が確定したばっかだから時期尚早と言われればそのとおりなんだが

WebAssemblyを進化させる「WASI Preview 2」が安定版に到達。OSや言語に依存しないコンポーネントモデルを実現
https://www.publickey1.jp/blog/24/webassemblywasi_preview_2os.html

**デフォルトの名無しさん** · 2024/02/03(土) 14:54:43.97

wasm,wasiはコンテナ界隈とかも期待はしてるようだけど確かにまだ早い。

**デフォルトの名無しさん** · 2024/02/03(土) 15:14:19.35

あ、俺みたいに用意されたものを使う的な人間の場合ね。

**デフォルトの名無しさん** · 2024/02/03(土) 15:32:51.57

重さが気になるほどの人気サイト作ってから言えよな。。クソしょーもねーわ。

**デフォルトの名無しさん** · 2024/02/03(土) 18:14:49.92

wasmはブラウザでffmpeg動かすときに使ったことある

**デフォルトの名無しさん** · 2024/02/03(土) 20:39:34.60

rustはもっとC#みたいなクラスの書き方が出来れば最高なのになー

**デフォルトの名無しさん** · 2024/02/03(土) 20:58:14.42

>>131
クラスはプログラミング言語の歴史では大失敗作と言われていて
モダンな新言語(Rust, Go, Zig, Nim, etc.)ではいずれもクラスを排除している
既存のクラスのある言語でもカプセル化以外のクラスの機能は使わずにインターフェース等を使うことが推奨されている
Rustのtraitはその中でも最も優れたものなのでRustで困ることはないよ

**デフォルトの名無しさん** · 2024/02/03(土) 21:06:51.84

Rustはtraitのドキュメント見た時に
とっ散らかって見えるんだよなぁ

**デフォルトの名無しさん** · 2024/02/03(土) 21:20:55.82

何事もタダでは手に入らない
良い面だけしか見ない人はいつまで経っても素人

**デフォルトの名無しさん** · 2024/02/03(土) 21:29:31.74

本当にいいの？僕は…黒人だよ？

**デフォルトの名無しさん** · 2024/02/03(土) 22:04:08.76

クラス排除はJavaの生みの親ですら主張しているほどプログラミング言語界での共通認識

＞以前Javaのユーザグループミーティングに出席した際、James Gosling（Javaの生みの親）がメインの講演者として招かれていました。
＞すばらしいQ&Aセッションの途中に、こんな質問が出ました。
＞「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」
＞答えは「クラスを除外するでしょうね」というものでした。
＞笑いが静まった後、彼が説明したのは、本当の問題はクラス自体ではなく実装継承(extendsの関係)なのだということでした。
＞インターフェースによる継承（implementsの関係）のほうが望ましいのです。
＞できる限り実装継承は避けたほうがよいでしょう。

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

クラスを排除した代わりにRustでは実装継承の実現に4種類もの異なる方法が導入されている
もちろんGoでもNimでもクラスとは違う形で実装継承が実現されている
にもかかわらず物事の表面しか見ない人はそれに気づけないし今でも実装継承が絶対悪だと信じて疑わない

これが所謂バカの壁

**デフォルトの名無しさん** · 2024/02/03(土) 23:26:38.80

>>137
Rustに実装継承はないよ
どのやり方でも必ず委譲が発生する健全な方法を採っていて実装継承の問題を排除している

**デフォルトの名無しさん** · 2024/02/03(土) 23:35:45.23

クラスが悪いのか継承とかの機能が悪いのか

**デフォルトの名無しさん** · 2024/02/03(土) 23:45:39.46

大雑把に　クラス＝カプセル化＋実装継承
よくないのは実装継承
カプセル化だけなら構造体の範囲内
つまり実装継承を伴うクラス自体が要らないというのがモダン言語

**デフォルトの名無しさん** · 2024/02/04(日) 00:25:24.84

Kotlinのsealed interfaceはマジで超使いやすい

**デフォルトの名無しさん** · 2024/02/04(日) 00:27:54.98

Rocketってフレームワーク試してみたんだけどこれホストを127.0.0.1以外にできないんかな
なんかハードコーディングでlocalhost指定になってる気がしないでもない

**デフォルトの名無しさん** · 2024/02/04(日) 00:33:31.21

そのRocketというフレームワークは使ったことないが、GitHubレポジトリで「127.0.0.1」で検索したら、
https://github.com/search?q=repo%3Arwf2%2FRocket%20127.0.0.1&type=code
exampleでなんか設定ファイルでadressを指定してるけどこれは違うの？
https://github.com/rwf2/Rocket/blob/master/examples/config/Rocket.toml

繰り返すがRocketというフレームワークは使ったことないので悪しからず

**デフォルトの名無しさん** · 2024/02/04(日) 00:59:56.12

その辺grep置換で全部置き換えたけどダメだった

core\lib\src\listener\endpoint.rs にある
Endpoint::Tcp(TcpAddr::new(Ipv4Addr::LOCALHOST.into(), 8000))
がそれっぽくはあるけどどう書き換えたもんか

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

https://rocket.rs/v0.5/guide/configuration/
読んだ感じだとRocket.tomlって設定ファイルで指定するのが簡単みたい
下の方にプログラムで設定する方法も書いてあるけど

こういうフレームワーク系はプロキシサーバーの裏側で動かすのが理想かもしれない

**デフォルトの名無しさん** · 2024/02/04(日) 03:52:57.49

Rustを書けるようになると、C/C++でも行儀よく実装できるようになるから
するとドキュメントの充実しているC/ C++でいいかとなりそう

**デフォルトの名無しさん** · 2024/02/04(日) 05:28:12.54

>>105
Python信者か？　富豪プログラミングでもRustの方が書きやすいが

**デフォルトの名無しさん** · 2024/02/04(日) 07:20:12.68

動的型付けのPythonは論外でプログラミングには向いておらずスクリプトを書く程度に使う言語
静的型付けの言語の中では過去の様々な問題点を踏まえて洗練された設計となっているRustがプログラミングに最適

>>146
それはない
例えば今では必須な非同期プログラミングでもC++は出遅れていて使いにくいだけでなくRustのtokioに相当する基盤もない

**デフォルトの名無しさん** · 2024/02/04(日) 08:23:06.79

>>146
ドキュメントの数は多いけど、自動生成もない時代のが多くてソースコードと乖離してたり
古いLinuxディストリ前提だったりして役に立たない率がめちゃ高いんだよな
ドキュメンテーションテストとかdocs.rsとかそういう仕組がちゃんとしてるのに慣れると
わざわざ古代の遺物的なのを発掘しに行く気にはなれない

**デフォルトの名無しさん** · 2024/02/04(日) 08:29:53.11

Cは構わないけど、C++はあり得ない
絶対に二度と触りたくないし、積極的に見たくもない

**デフォルトの名無しさん** · 2024/02/04(日) 08:46:56.47

Cにdeferが来たら、もうC++を触らなくてよくなるんだ🥰
…C23でのdeferの実装、見送られたけどね

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

ああ、zigを本番環境で使いたいなあ

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

>>145
それもやったけど変わらなかった
まぁver0.xだし正式リリースになったらもうちょいマシになるんだろうから
今はまだ使い時じゃないって事で

**デフォルトの名無しさん** · 2024/02/04(日) 10:56:28.64

>>153

これでなんの問題もなく動いたけど…

#[launch]
fn rocket() -> _ {
let config = rocket::Config {
port: 7777,
address: std::net::Ipv4Addr::new(0, 0, 0, 0).into(),
..rocket::Config::default()
};
rocket::custom(&config).mount("/", routes![index])
}

**デフォルトの名無しさん** · 2024/02/04(日) 11:21:21.48

>>146
自分で書く分ではどっちでも。
でもお前の職場のプログラミングセンス無いやつにもc/c++で書いてて欲しいと思う？

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

>>153
rocketを使う理由が特にあるわけではないならば
一番ダウンロード数も多くRustで本流のaxumを使うといいよ
https://github.com/tokio-rs/axum
このURLを見てもわかるようにtokio開発チームが直接手掛けているWebアプリフレームワーク

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

>>148
それはあなたの主観だよ
世界中で流行っているpythonをそのように評価をすること自体がナンセンスだとは思わないか？

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

>>157
前にも書いたけど例えばPythonのDjangoは遅い
PythonがRustに勝ってる点はローコストでコーディングできる、それのみ
学習コスト、開発時間などを投資できるならRustのようなlow-levelな言語を用いた製品のほうがコンピュータに優しいのは既知の事実

**デフォルトの名無しさん** · 2024/02/04(日) 13:07:03.82

>>157
Pythonでプログラミングを実際にすればわかるけど
ある程度の大きさのものを作るには開発デバッグ効率が非常に悪いね
数ある諸言語と比べてもPythonのメリットは普及していること以外には何も無いかと

**デフォルトの名無しさん** · 2024/02/04(日) 13:22:50.87

>>158
つまりpythonはプログラミングに向いていないというのは間違いということで良い？

>>159
そうは思わないな
開発ツールやエディタが進化してるから差は感じない

**デフォルトの名無しさん** · 2024/02/04(日) 13:45:38.68

インタプリタ言語はプログラミングに値しないってか？流石に言いすぎだぞ
うちの小学生の子どもにScratchをプログラミング学習として遊ばせてるけど、そのScratchもれっきとしたプログラミング言語だし

**デフォルトの名無しさん** · 2024/02/04(日) 13:54:00.15

>>147
メモリ管理をランタイムに任せることを富豪的プログラミングというのでは？書き易さなんて単に個人の言語の習得度の差でしかない

**デフォルトの名無しさん** · 2024/02/04(日) 14:07:26.71

お前のDjangoは遅い？ならサーバーのスペックを10倍にしろやゴラァ
ってのが富豪的プログラミングの理念ね

**デフォルトの名無しさん** · 2024/02/04(日) 16:31:03.43

Rustと比べるとPythonはプログラミングに向いていない
スクリプト程度ではなく普通にある程度の規模があるプログラムを対象とする

**デフォルトの名無しさん** · 2024/02/04(日) 16:54:18.26

特定領域の話と一般論をごっちゃにしてるやつ多いな。

**デフォルトの名無しさん** · 2024/02/04(日) 16:54:55.07

実際にPythonで書くと実行時デバッグがどうしても多くなるね
後から機能追加したりリファクタリングしたりする時も再び実行時デバッグに陥りやすいね
その点Rustは静的型付けであるだけでなくデータ競合もコンパイル時点で防いでくれるから優れているね

**デフォルトの名無しさん** · 2024/02/04(日) 16:55:36.99

>>162
文脈的に文字列を無駄にヒープに置いただけで富豪扱いなんだよな
あと習熟度に依存するのはそれはそうなんだけど、Pythonに習熟した人間ほどRustの方が書きやすいという傾向がある気がする
少なくとも俺の身の回りではそう

**デフォルトの名無しさん** · 2024/02/04(日) 17:00:11.71

書きやすかろうが何だろうがユーザ数が全てやろ
Rustは流行ってないそれだけは確か

**デフォルトの名無しさん** · 2024/02/04(日) 17:01:42.98

ユーザー数が全てはまあそれはそう

**デフォルトの名無しさん** · 2024/02/04(日) 17:06:47.57

そこは単純な話だろう
PythonとRustの両方をそこそこ使いこなせる人たちに
どちらの言語でも開発可能な領域の案件をどちらで開発したいか尋ねる
100%の人たちがRustで開発したいと答える
つまりPythonは劣った言語