Rust part33

**デフォルトの名無しさん** · 2025/08/15(金) 17:49:30.70

公式
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 part32
https://mevius.5ch.net/test/read.cgi/tech/1755057787/
Rust part31 https://mevius.5ch.net/test/read.cgi/tech/1751545806/
Rust part30 https://mevius.5ch.net/test/read.cgi/tech/1748392296/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/10/18(土) 16:27:26.83

>>332
それならPolarsがあるな
RustというかPythonのライブラリだけど

**デフォルトの名無しさん** · 2025/10/18(土) 16:29:59.91

>>317
もうめちゃくちゃだなw
抽象度の異なるものをごちゃまぜにしてるだけでなく
ロックフリーや排他制御が何なのかという基本すら理解してない

さすが複おじ

**デフォルトの名無しさん** · 2025/10/18(土) 17:20:51.07

おじ使いの人はいつもデタラメに言いがかりをつけまくってるけど具体的な情報をもたらさない特徴があるね

**デフォルトの名無しさん** · 2025/10/18(土) 18:35:02.78

スレ荒らしだから無視しとけ

**デフォルトの名無しさん** · 2025/10/18(土) 21:38:19.83

anyhowとかtokioも言語標準としてあってほしい部類だよな
serdeも今時シリアライズぐらい入っててよくねえ？とは思わなくもない

**デフォルトの名無しさん** · 2025/10/18(土) 21:53:44.59

anyhowは今でこそデファクトだけど
quick-error -> error-chain -> failure -> anyhow
という変遷あっての結果だから標準ライブラリでなくて正解ではあったと思う
serde は安定してるけど結局tomlやserde_jsonは分離してるからそれだけ入っても、という感じか

**デフォルトの名無しさん** · 2025/10/18(土) 22:10:01.44

いずれもどこまでを標準に入れるか難しいから標準は現状の最小限がいいよね

**デフォルトの名無しさん** · 2025/10/18(土) 22:16:21.80

Rust crates recent downloads TOP30
1位 syn
2位 bitflags
3位 hashbrown
4位 base64
5位 regex-syntax
6位 proc-macro2
7位 indexmap
8位 regex-automata
9位 quote
10位 itertools
11位 libc
12位 heck
13位 serde
14位 memchr
15位 unicode-ident
16位 serde_derive
17位 cfg-if
18位 autocfg
19位 aho-corasick
20位 serde_json
21位 rand_core
22位 once_cell
23位 regex
24位 getrandom
25位 itoa
26位 windows_x86_64_msvc
27位 rand
28位 ryu
29位 cc
30位 strsim

**デフォルトの名無しさん** · 2025/10/18(土) 22:20:56.31

排他制御で撃沈した複オジが話題転換しようと頑張ってる感じ？

**デフォルトの名無しさん** · 2025/10/18(土) 22:29:27.69

多くのクレートが用いている基礎クレートが大量にあるから
もし標準ライブラリに入れるならそれらを優先だろうな

**デフォルトの名無しさん** · 2025/10/18(土) 22:29:58.32

itoaって独立したクレートとして存在したのか

**デフォルトの名無しさん** · 2025/10/19(日) 00:23:47.35

標準でまかなえるものが多ければ多いほど、金取って保守する業務では使いやすくなるので
標準ライブラリはちゃんと保守できる範囲なら、でかければでかいほうがいい

**デフォルトの名無しさん** · 2025/10/19(日) 00:35:19.83

金を取ってるのに標準ライブラリじゃないと保守できないってダメなとこじゃん
しかも標準ライブラリやクレートのメンテしてる人たちにお金を出す気もないんだろ

**デフォルトの名無しさん** · 2025/10/19(日) 07:59:03.97

そういうのは単純に「Rustが向かない領域の一つ」というじゃない？
できるだけリスクを減らしたい (依存を減らしたい) エンプラ分野で、OracleやMicrosoftにお金を払ってでも Java や C# を使う理由というか
自社開発なら、ライブラリが使えなくなる等のリスクも自分達の責任で済むから、話は違ってくるだろうけど

**デフォルトの名無しさん** · 2025/10/19(日) 08:11:35.49

というかC/C++の代替としてはサードパーティのライブラリは十分に吟味してちゃんと手の内で把握して使うのが当然で、
Web系のアホの「なんかよく分かんないのが色々入ってるけど動いてるからヨシ!」は想定してないんだろ

**デフォルトの名無しさん** · 2025/10/19(日) 08:12:34.65

tokioなど大手IT各社が金出すか人出すか協力するかしていて信頼性が高い
もちろん各社が実際に使ってる
標準かどうかの名目よりそういうことが重要

**デフォルトの名無しさん** · 2025/10/19(日) 08:18:08.18

>>347
RustのWeb系基盤は一番下のtokioを含めて多階層に構成されていずれも標準ライブラリではないけど皆が用いていて安心感があるよ

**デフォルトの名無しさん** · 2025/10/19(日) 09:01:48.04

コアチームの人もしばしば言っているけど
標準に入ったからといって自動的にメンテされるようになる訳ではなく
人手が足りないと単純に放置されて「このライブラリは標準だけど使わないほうがいい」とかなるだけなんだよな

**デフォルトの名無しさん** · 2025/10/19(日) 09:18:07.38

RustはWeb関連が実際に業界大手のクラウドやCDNなどで使われているのが大きいよね

**デフォルトの名無しさん** · 2025/10/19(日) 09:56:19.63

C++ での例だと文字コード変換の枠組みである codecvt は C++26 でまるごと削除になる。(C++17 の時点で非推奨)
結局のところ常に変化するし常に追従するしか仕方ない。
完成したらそれをずっと使い続けられるという訳ではない。
ウェブ界隈では常に改定し続けるという意識があるから問題か起きたらそのときに対応すればよいという将来に対して楽観的 (無頓着) な価値観が生まれたのたと思う。

**デフォルトの名無しさん** · 2025/10/19(日) 10:00:00.50

産業的な価値観で見ると living standard という制度は気狂いにしか見えんが、ウェブの価値観ではこれが受け入れられるんだからな……

**デフォルトの名無しさん** · 2025/10/19(日) 10:01:28.52

>>352
そのウェブ界隈って何？
Rustとは関係ない話？

**デフォルトの名無しさん** · 2025/10/19(日) 10:22:53.22

産業的には進化は止まってくれた方が使いやすい
開発者的には進化し続けてくれた方が新機能使えて楽しい
これ、両立できると思うけど。deprecatedされたら新しい機能使えばいい
俺たちベンダーの食い扶持にもなるとは考えられんか

**デフォルトの名無しさん** · 2025/10/19(日) 10:27:52.04

クラウド利用まで含めてWebベースのこの時代にWeb方面を批判してる人はWebと全く無縁な世界にいるの？

**デフォルトの名無しさん** · 2025/10/19(日) 11:19:39.80

批判しているわけじゃない。
そういう価値観で動いていてその価値観が相容れない場合はあるってだけの話だ。

**デフォルトの名無しさん** · 2025/10/19(日) 11:20:31.74

この文脈でのWebっていうのはフロントのことなのはわかると思うけど
開発経験ない人？

**デフォルトの名無しさん** · 2025/10/19(日) 11:31:51.71

>>355
産業的には進化が止まるのが良いとは思ってないがバージョンナンバーがないと仕様をまとめるのに支障がある。
ひとつのプロジェクトは多くのサブプロジェクトの集合体で、ひとつのゴールに向かって進めいている途中に規格がかわっていくなんてのは管理しきれない。
完成したときに根拠の規格が古くなっていてもかまわないから一貫した規格を使いたいんだよ。

**デフォルトの名無しさん** · 2025/10/19(日) 12:08:21.35

ここはRustのスレなんだから
元々のクレートの話のWeb関係もサーバサイドだよね
Rust以外の話をしてる人が場違い

**デフォルトの名無しさん** · 2025/10/19(日) 12:16:46.65

>>359
>>規格が古くなっていてもかまわないから一貫した規格を使いたいんだよ。

RustはCargo.tomlでバージョン指定すれば古くなっても一貫して使えるでしょ

**デフォルトの名無しさん** · 2025/10/19(日) 13:20:36.22

>>361
ツールチエンといふやつか！
nightlyに依存したコードとか書いてたら戸惑うとは思うけど通常は困らん
それに依存関係のあるグレートで致命的セキュリティホールとかあれば結局放置できなくて全部上げるしなあ

**デフォルトの名無しさん** · 2025/10/19(日) 15:01:40.23

>>361
living standard にバージョンナンバーは存在しない。
現在のプロジェクトでどの規格に基づけと書くことができないし
Rust のウェブ関連のライブラリのどれがいつの規格に対応しているかわからない。

**デフォルトの名無しさん** · 2025/10/19(日) 15:13:23.14

>>350
今、rustfmtが放置されてるらしいね

**デフォルトの名無しさん** · 2025/10/19(日) 15:30:20.66

>>364
さすがに無責任すぎるね
偉そうに>>350みたいな偉そうな物言いをする以前の問題だわ

**デフォルトの名無しさん** · 2025/10/19(日) 15:54:16.06

脆弱な言語だな

**デフォルトの名無しさん** · 2025/10/19(日) 16:32:09.86

実際問題としては責任はないから無責任ってのは当たり前の話ではあるな。

**デフォルトの名無しさん** · 2025/10/19(日) 16:52:25.14

中水準言語、高水準言語、ライブラリ、フレームワークとなんでもあるプログラミング言語を語るのは難しい。

**デフォルトの名無しさん** · 2025/10/19(日) 17:00:18.30

rustfmtって最近Linusがウンカスってキレてたけどそれで放棄されたん？

**デフォルトの名無しさん** · 2025/10/19(日) 17:09:39.48

>>369
それとは直接関係ない

**デフォルトの名無しさん** · 2025/10/19(日) 17:38:21.32

>>367
個人になくともRust財団にはガバナンスや品質管理の責任があるし、
個人もテック企業の社員が会社から金貰って業務としてRustの開発をしているから自社に対して対価に見合った仕事をする責任はあるよ

**デフォルトの名無しさん** · 2025/10/19(日) 21:02:09.84

rustfmt最後のリリースが2023年7月か
コード自体は普通に今もコミットされてるみたいだけど、なんでリリースしないんだろうね？

**デフォルトの名無しさん** · 2025/10/19(日) 22:44:25.22

複おじが現れたときだけ不毛に無意味に盛り上がるスレ

**デフォルトの名無しさん** · 2025/10/19(日) 23:28:35.37

>>358
RustでWebの話はサーバーサイド
例外的にフロントの話をする場合でもWebAssembly利用
もし別の言語の話をしているなら明示的にその言語名を書きなさい

**デフォルトの名無しさん** · 2025/10/20(月) 10:34:27.56

rustメンテイナーて結構給料いいの？

**デフォルトの名無しさん** · 2025/10/20(月) 11:45:59.23

そりゃ大部分はAWSとかMSとかの米ビッグテックの社員だからな
余裕で年収20万ドルオーバーよ

**デフォルトの名無しさん** · 2025/10/20(月) 12:06:58.50

>>375
Mozillaの給与水準は他と比べるとかなり低いがアベノミクスのおかげでシンガポールや香港はおろか韓国や台湾にも抜かれた貧しい日本の給与水準から考えればかなり高い

**デフォルトの名無しさん** · 2025/10/20(月) 12:15:16.08

Mozillaの社員なんて大規模レイオフでもうほとんど残ってないでしょ
今のRustは>>376のようなビッグテックが主導してるよ

**デフォルトの名無しさん** · 2025/10/20(月) 16:59:56.26

アベノミクスのおかげでGDP過去最高609兆円、平均年収過去最高460万円、税収過去最高75兆円です

**デフォルトの名無しさん** · 2025/10/20(月) 18:51:31.70

>>379
バカ発見

**デフォルトの名無しさん** · 2025/10/21(火) 03:24:38.73

はえーやっぱ給料いいんか
ibmでlinuxかーねる書くみたいな仕事とかも国内じゃまあ無理やな

**デフォルトの名無しさん** · 2025/10/21(火) 03:46:47.30

Rustの有力開発者はみんなAstralで働いてる印象

**デフォルトの名無しさん** · 2025/10/21(火) 08:21:33.19

んなわけないでしょ
たかが従業員50人くらいのスタートアップが自分のプロダクトじゃなくてRustの開発ばっかりやってたらVCがキレるわ
それに仮にAstralがRustの最有力なんだとしたらRustはPythonの奴隷ということになるが、お前はそれでいいのか

**デフォルトの名無しさん** · 2025/10/21(火) 11:09:21.75

嫌な絡み方だなあ
そんなに癇癪持ちならプログラムでバグ出たときどんだけキレるの

**デフォルトの名無しさん** · 2025/10/21(火) 12:19:27.25

そりゃあもう開発室は修羅場よ

**デフォルトの名無しさん** · 2025/10/21(火) 12:51:53.63

独裁者あるある
立法の奴隷をやめようという発想で行政を暴走させる

自分で立法しないやつは奴隷か独裁者にしかなれないんだよ

**デフォルトの名無しさん** · 2025/10/21(火) 14:45:27.32

Servo 0.0.1 Release
https://servo.org/blog/2025/10/20/servo-0.0.1-release/

えっ？

**デフォルトの名無しさん** · 2025/10/21(火) 15:11:56.06

>>387
先月ナイトリービルドを試して、すぐにフリーズして使い物にならんなと思ったけど

**デフォルトの名無しさん** · 2025/10/21(火) 16:12:17.01

Astral は Python のパッケージ管理を商品にして儲ける計画らしいけれど、今のところ真っ当に動いていない。
金が消えていくだけで入ってくる仕組みがいまだに何も出来ていないので心配されてる。
本当にどうなってんだろ？

**デフォルトの名無しさん** · 2025/10/21(火) 16:36:04.66

ユーザーベースを広げて競合を潰しておくと有償機能を発表した時にユーザーの逃げ道が少なくていいんだよ

uvよりruffの拡張のほうがマネタイズしやすいだろうな

**デフォルトの名無しさん** · 2025/10/21(火) 16:42:06.09

>>389
今の規模ならエンタープライズ向けの有償サポートだけで十分食えるでしょ

**デフォルトの名無しさん** · 2025/10/21(火) 18:26:55.85

今のuvやruffでは有償サポートビジネスは無理
マンパワーの面でも相性が悪すぎる

**デフォルトの名無しさん** · 2025/10/22(水) 10:19:41.33

AstralのイグジットはVCの成功シナリオとしてはG/A/Mに買収くらいしかないでしょ
もしくはdockerみたいに売り時を逃した挙句にエンプラ向けの企業と組んで細々とやるかだな

**デフォルトの名無しさん** · 2025/10/22(水) 13:55:31.39

Astralは要はAnacondaの商売を乗っ取ってやろうってことでしょ?
Anacondaは従業員300人いるらしいから儲かってそう

**デフォルトの名無しさん** · 2025/10/22(水) 14:34:51.47

Anacondaは突然の有償化で崩壊、自滅したでしょ
非難されることは目に見えてたはずだけど、金払う客が少しでも残れば十分に資金回収できると踏んだんだろう
収益化が見えずVCから資金回収を迫られて強引に手仕舞いすることになった形

**デフォルトの名無しさん** · 2025/10/22(水) 18:48:15.08

複式簿記おじさん「国や企業の借金は投資家の資産です（回収しないとは言ってない）」

**デフォルトの名無しさん** · 2025/10/23(木) 00:17:51.64

アナコンダの件は企業は無料のを使っちゃいけないってお灸を据えた形にはなってて、うちの会社でも金払って使ってるわ
やっぱプログラマーとしては無料ほど高くつくものはないしサポート体制継続するなら有償でもいいって思うベンダーが我が多いってこと

**デフォルトの名無しさん** · 2025/10/23(木) 00:49:38.88

Anacondaみたいに全力で嫌われちゃうと今後はもう先細りしかないからなあ
企業での利用だったらとりあえずは金払ってもいいけど、将来性の面で問題があるから乗り換えを考えるわ

**デフォルトの名無しさん** · 2025/10/23(木) 02:13:47.52

引数がふたつ以上あるときのライフタイム注釈ているかこれ
アプデで省略できるようにしてくれんかな

**デフォルトの名無しさん** · 2025/10/23(木) 08:02:52.36

確かに面倒だけど、実装から推論するのはRustの根本設計思想的にNGだからどうしようもない
どうせ書くのAIなんだから今となってはもうどうでもいいことだし

**デフォルトの名無しさん** · 2025/10/23(木) 08:26:01.60

大した手間ではなく
むしろライフタイム注釈は有った方が読みやすく
参照の流れも理解しやすい

struct Foo<'a, 'b, 'c>も
3系統の参照が入っていると明示され
他の言語よりも理解しやすくなってる

**デフォルトの名無しさん** · 2025/10/23(木) 09:55:41.49

なるほど。。。
変数に生存期間があるのはわかるけど「変数の型」にまで生存期間があるってのがようわからんぜよ

**デフォルトの名無しさん** · 2025/10/23(木) 10:42:16.86

ライフタイム注釈も型のジェネリックパラメータの一つと考えればよいかと
参照のライフタイムは現行関数を抜けたら即死ぬ参照からもっと祖先の関数まで持ちこたえる参照そして永久不滅の参照まで色々あるけどジェネリックにいずれも入り得る

**デフォルトの名無しさん** · 2025/10/23(木) 11:33:06.85

>>402
なるほどじゃねーよ
簡単に騙されんな

**デフォルトの名無しさん** · 2025/10/23(木) 12:08:09.39

>>401
設計者も手間だと思ってるから引数一つの場合の省略ルールがあるのに何言ってるの
引数が複数のときにライフタイムの明示が必須なのは、シグネチャだけの推論では多くの場合において過剰に強い制約を生じるから
仮にシグネチャだけで安全に推論するなら、戻り値のライフタイムは最もライフタイムの短い引数に合わせるしかないだろ？
そうするとスコープがネストされているような場合に戻り値が短いスコープの方に制約されてしまう
実用上はそれでも問題なく使えるケースは多いはずだが、本来の必要最低限の制約とは食い違うというのが設計者には許せなかったのだろう

**デフォルトの名無しさん** · 2025/10/23(木) 12:30:49.98

だからこそライフタイム注釈の明示的な指定が重要
それがあることでコンパイラもコードレビューも正しい判断ができる

**デフォルトの名無しさん** · 2025/10/23(木) 14:21:00.93

注釈はプログラマの意図の表明だ。
意図と違う形で辻褄が合っても問題だろ。
よほど自明の場合だけ省略できるようになってるけども、どのレベルから自明と言えるかは感覚的だからな……

**デフォルトの名無しさん** · 2025/10/23(木) 15:22:08.96

ライフタイムの指定を省略できる場合であっても、省略すると戻り値のライフタイムの制約が必要以上に強くなってしまうケースは普通にあって、
>>405の理屈を厳格に適用するなら引数が一つでもライフタイムの明示は必須だ
食い違いが生じるケースがどれくらいの頻度で発生するかという統計の問題なのよ

**デフォルトの名無しさん** · 2025/10/23(木) 15:27:37.26

二つを'a 'aにすると寿命の短い方に揃えられてしまうけど
二つを'a 'bにすると各々の寿命が尊重されて後に出来ることの範囲が広がるって話？

**デフォルトの名無しさん** · 2025/10/24(金) 10:04:48.68

であるか

**デフォルトの名無しさん** · 2025/10/25(土) 12:18:04.03

ライフタイムめんどくせえし全部stringで返すべと思ってたら&strとstringの速度差はだいたい10倍あるみたいなのでやっぱできるだけ&strで返そうとおもた🐼

**デフォルトの名無しさん** · 2025/10/25(土) 12:27:15.75

そりゃ先頭ポインタと長さを返すだけで済む&str返しやスライス&[T]返しが圧倒的に速いよ

**デフォルトの名無しさん** · 2025/10/25(土) 12:30:11.50

>>411
実際のアプリではそこまで差は出ないでしょ
マイクロベンチマークが見せる幻想

**デフォルトの名無しさん** · 2025/10/25(土) 12:36:43.77

&str返しができる状況でString返しをしてしまうセンスだと至る所で似たような非効率をしてしまいかねない

**デフォルトの名無しさん** · 2025/10/25(土) 14:30:41.07

そもそもそのへん無頓着ならPythonとかのスクリプトでよくねっていう気も

**デフォルトの名無しさん** · 2025/10/25(土) 15:28:17.84

たまにはCowのことも思い出してあげて🐮

**デフォルトの名無しさん** · 2025/10/25(土) 16:30:57.36

>>411
繰り返し呼ばれない関数で文字列がそれほど長く
速度的なメリットよりもライフタイムを引きずり回すデメリットが大きくなる場合は
&str返しできる状況でもstring返しをする

それ以外は&strで返せるなら&strを選ぶのが基本

**デフォルトの名無しさん** · 2025/10/26(日) 12:11:46.95

文字列は用途によってはstring_cacheなど使ってintern化すると一気に扱いやすくなるよ

**デフォルトの名無しさん** · 2025/10/26(日) 15:33:24.64

「用途によっては」「条件によっては」を付けたらだいたい何でも正しいよ。
つまり無意味だってことだ。

**デフォルトの名無しさん** · 2025/10/26(日) 15:48:22.18

何にでも向き不向きがあり万能はないため特徴と用途を比較して適切に選ぶ必要がある
文字列の比較があるならinterningは有利
同じ文字列が出てこないなら機能を発揮しない
それでも64bit ID化される点で参照や所有権を気にすることなく気軽に扱える視点での利点はあるかな

**デフォルトの名無しさん** · 2025/10/26(日) 22:42:01.01

https://itest.5ch.net/mevius/test/read.cgi/tech/1757733847/52
> Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
> 安全性などはついでのオマケ

5chのRust信者は程度が低いなｗ安全性への認識がこんなものかｗｗ

**デフォルトの名無しさん** · 2025/10/26(日) 22:50:15.71

高い抽象度で使いやすい言語は他にもあるけど速さ省メモリを両立させた言語はRustが初だな
それだけでも十分に価値はあるけどセキュリティ面から今重視されている安全性まで両立させたことが決定打

**デフォルトの名無しさん** · 2025/10/26(日) 23:04:51.09

> 安全性などはついでのオマケ
　
安全性に勝るものなどないのに馬鹿丸出しｗ

**デフォルトの名無しさん** · 2025/10/26(日) 23:17:12.99

安全性が使用動機でなくても
他のメリットも他言語に例がなく十分満足できる言語とは言える

**デフォルトの名無しさん** · 2025/10/26(日) 23:20:44.90

Rustは実際はc++の代用として使われる事例がほとんど
ユーザーは欧米に偏っていて一番IT人材が多いインドではほぼ使われていない

**デフォルトの名無しさん** · 2025/10/27(月) 00:24:06.81

>>425
インドでもRust利用企業が多い

Companies that use Rust in India
https://theirstack.com/en/technology/rust/in

**デフォルトの名無しさん** · 2025/10/27(月) 02:06:07.73

下馬評垂れてればプログラマーとしての格が上がるとでも思ってるんだろうか

**デフォルトの名無しさん** · 2025/10/27(月) 06:13:04.93

>>425
各スクリプト言語からRustが多いよ
例えば遅くて困っていたツールなどで新たに良いものに作り直す時にRustが選ばれてる
先週このスレで話題になってたPythonのツールの話もそれだね

**デフォルトの名無しさん** · 2025/10/27(月) 06:31:46.50

rustにも機械学習ライブラリあるしaiもrustでよくね

**デフォルトの名無しさん** · 2025/10/27(月) 09:29:34.52

>>429
そういう実際の経験に基づく説得力のあるコメントは参考になる
やっぱ人工知能を実装するならRust一択という結論に至った
2位の候補はC++だけど僅差でRustが使い勝手上かなあ

**デフォルトの名無しさん** · 2025/10/27(月) 09:32:19.04

>>428
遅くて困っていたツールってほど遅いのは普通に設計ミスじゃ無いの
たとえばspawnせずにシングルスレッドで回してる箇所見落としてるとか
言語による性能差意識できるほどRustがいいとは思えん
わざわざ他の言語で書くより、元のプログラミング言語でリファクタリングの方が楽だと思うけど

**デフォルトの名無しさん** · 2025/10/27(月) 09:34:42.42

>>426
英語はよくわからんけど、408社ってインドの有名企業のほぼ全て採用ってことか
メジャー企業はインフォシステムとかタタとかしか知らんがそこまで普及したのはここ数年よね
なんか日本より導入進んでね？