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/01/22(月) 23:14:04.77

>>17
C++ の仕様ではテンプレートの展開深度に上限を設定することを認めているのでチューリングマシンではない。
非現実的な回数のループが起こるのならそれは処理系の欠陥。

**デフォルトの名無しさん** · 2024/01/22(月) 23:41:39.76

>>15
1.65.0で新しく導入された回帰バグですって書いてあるし
2015年の#25860とも別だねってコメントも付いてますやん

**デフォルトの名無しさん** · 2024/01/23(火) 00:35:34.27

>>18
文脈無視してその引用だけで言えそうなことは
&'static &'s T 型が存在するならば 's も 'static でなければならない
このルールに反しない限り &'s str を &'static str に変換してよい

**デフォルトの名無しさん** · 2024/01/25(木) 23:09:32.35

安全にこれで&'staticへ変換できる

fn to_static_str(s: &str) -> &'static str {
　　s.to_owned().leak()
}

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

最後までずっと使うものやあるいは
あるメモリ限度内に収まる使い方ならば
リークさせて扱いが楽になるメリット享受を選ぶのもありかもな

**デフォルトの名無しさん** · 2024/01/27(土) 23:34:17.17

>>22
それ&'static strではなく&'static mut strを返してもええねんで

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

>>22
leakって安全なの？

**デフォルトの名無しさん** · 2024/01/28(日) 04:27:59.88

leakは安全
そのプログラム終了まではその部分のメモリを解放しないだけ

**デフォルトの名無しさん** · 2024/01/28(日) 08:32:52.16

>>25
Rust の定義ではメモリリークは安全性を損なわないことになってる。
言語の機能として積極的に阻止しなければならないような動作ではないが、
だからといってむやみにリークさせていいわけでもないのは当然なので
そこらへんはロジック上の必要性を鑑みて「正しく」運用するのはプログラマの責任だよ。

**デフォルトの名無しさん** · 2024/01/28(日) 12:34:08.20

leakは参照を削除するとメモリリークになると書いてあった（機械翻訳）けど参照って削除できるの

**デフォルトの名無しさん** · 2024/01/28(日) 13:17:17.43

>>28
原文は何て書いてるのさ

**デフォルトの名無しさん** · 2024/01/28(日) 14:30:03.90

期待した通りの結果になるのは危険ではないという知見は合理的だ
期待や願望よりも地獄のような厳しい現実にこだわるバイアスがかかってない

**デフォルトの名無しさん** · 2024/01/28(日) 15:17:37.40

>>28
leak()は所有者がいなくなるだけ
つまりそのメモリ領域が解放されなくなるだけで安全な行為
そこを指す参照だけになる

一般的に参照は指しているだけ
その参照を表す変数もしくは一時的な値が消えればその参照は消えたことになる
参照が消えても実体には何ら影響なく解放なども生じない

**デフォルトの名無しさん** · 2024/01/28(日) 18:26:28.82

メモリリークにならない＝参照がデストラクタを呼び出せる
ではなく
参照はデストラクタを呼べないが、参照が永久に残ればメモリリークにならない

**デフォルトの名無しさん** · 2024/01/29(月) 23:08:47.69

メモリリークは多義なので
GC言語でも、今後は使わないオブジェクト等をどこが参照しているため解放されない、これもメモリリークと言う
つまり参照が残っているからメモリリークじゃないとは言えない
逆にRustの場合は、leak()を適用した時点でそこは永久に解放されないのだから、既にメモリリークとも言える
もちろんそれで困らない時に意図的にリークを可能とするものなので、その機能や行為自体に問題はなく、そのプログラムの性質や環境や方針次第

**デフォルトの名無しさん** · 2024/01/30(火) 02:10:08.22

多義である事実に人間が従うのではなく、定義を変えたいので変えまくった人間に事実が従う
利己主義の結果を予想するのではなく結果を予想できる範囲内で利己的になる

**デフォルトの名無しさん** · 2024/01/30(火) 06:01:38.95

きちんとメモリ確保・解放する
ただそれだけのことだけどうまく行かないものだね

**デフォルトの名無しさん** · 2024/01/30(火) 07:11:49.27

>>35
Rustならそれができるし保証される
ただしその基本に加えて融通を利かせることもできる
意図的にリークさせる(解放しない)こともできるしそれを使わないこともできる
意図的に循環参照を作ってリークさせることもできるしそれを避けるための手段も用意している

**デフォルトの名無しさん** · 2024/01/30(火) 11:19:29.95

それくらいできてくれないと習得に対して割に合わない

**デフォルトの名無しさん** · 2024/01/30(火) 23:08:46.90

>>35
二回以上解放しない保証は大成功した
一回以上解放する保証をやる気がない
与えられた問題を勝手に分割してやりたい部分だけやってる

**デフォルトの名無しさん** · 2024/01/31(水) 05:41:08.45

Rustでは意図的にリークもしくは意図的に循環参照作成の場合を除いて必ず解放される

**デフォルトの名無しさん** · 2024/01/31(水) 22:24:17.87

スポーツでも五輪だけが目的のプロがいたら割に合わないが
なんか目的をあやふやにすれば五輪に出ても破産しないよね

**デフォルトの名無しさん** · 2024/02/01(木) 16:48:45.42

Microsoft seeks Rust developers to rewrite core C# code
https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/

でかいところのバックエンドRust化が増えてきたな

**デフォルトの名無しさん** · 2024/02/01(木) 17:28:29.31

しかしRust流行らんな

**デフォルトの名無しさん** · 2024/02/01(木) 19:27:48.94

Pythonやkotlinみたいな手軽さで堅牢で高いパフォーマンスが出れば最高なんだけどなかなかね

**デフォルトの名無しさん** · 2024/02/01(木) 20:38:04.52

from C to Rust へのマイグレーションは時間がかかるからしゃあない

**デフォルトの名無しさん** · 2024/02/01(木) 21:16:53.56

>>43
Pythonはスクリプトを書く程度ならいいけどプログラミングには不向き

**デフォルトの名無しさん** · 2024/02/01(木) 21:44:37.29

きちんとガベコレしてるのに見下されてるなあPythonは
きちんとしても割に合わない

**デフォルトの名無しさん** · 2024/02/01(木) 21:53:27.11

動的型は堅牢とかきちんとやるみたいなのと相反するんだよな
書き捨てならいいけど長期的にメンテするやつには向いてない

**デフォルトの名無しさん** · 2024/02/01(木) 21:55:25.71

Rust、言うほどPythonと比べて手軽でないか？

**デフォルトの名無しさん** · 2024/02/01(木) 22:17:59.13

プログラマの意図を書かないと、意図を表せる言語じゃないと「正しい」かどうかは検証しようがない。
だから意図の表現方法として型やライフタイム注釈やらの形を確立したのであって、お手軽に柔軟に動かす言語では実行時に不都合があれば止まるという形にならざるを得ない。
静的型があれば全部が解決ってわけではないけどごく基本的な整合性検査すらせずに実行するまでわからんというのはメンタル的にきつい。動的型はきつい。
自分で把握できる程度の小さな規模なら動的型のほうが楽ってこともあるといえばあるけど、人類は駄目なのでちゃんと把握できる規模は自分で思っているよりだいぶん小さい。

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

Pythonはやっぱり行列を扱うのに長けてる気がするな
ただ静的には何の変数を見ても(Variable)xxx: Anyみたいな型推定しかされていなくて、自分の書いたコードですら訳がわからなくなる
他人の書いたライブラリを使うときはまるで魔法を使ってるかのようだ

**デフォルトの名無しさん** · 2024/02/01(木) 22:40:37.81

Pythonというかインタプリタは部分的にCを使うことを認めざるをえない
それを大多数に納得させるコストが激安

**デフォルトの名無しさん** · 2024/02/01(木) 22:42:10.75

>Pythonはやっぱり行列を扱うのに長けてる気がするな

pythonのどこが？numpyがあるだけじゃね。

**デフォルトの名無しさん** · 2024/02/01(木) 22:45:58.52

PythonはC/C++/Rustで書いたライブラリを呼び出すスクリプト言語として使っている限りは問題ない
プログラミング言語としては不向きで使うべきではない

**デフォルトの名無しさん** · 2024/02/01(木) 22:54:05.96

OSのカーネルにはPythonは不向きだからクソどうでもいい生存競争をしなくてすむ

**デフォルトの名無しさん** · 2024/02/01(木) 23:06:17.91

使い分けが出来ない人はスキルが低いだけ
言語に限らずどの技術でも同じこと

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

各種カーネルのRust移植に時間かかってるけどC/C++からRustへの書き直しってそんなに大変なの？

**デフォルトの名無しさん** · 2024/02/01(木) 23:14:24.05

Pythonもプログラミング言語だしシェルスクリプトも立派なプログラミング言語だよ

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

プログラミング言語はそれに付随するフレームワークの質で需要が変わってくるけど、
C/C++/Rust/アセンブラなど低水準言語はガべコレのランタイムが不要というアドバンテージがある
だからカーネル用途での需要が高い

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

Ruby もだいぶん長いことバイトコード化すらせずに木を辿るクソ遅い設計だったんだぞ。
でもなあ、使い分けといってもやっぱり慣れたらもうちょっと他の場所でも使いたくなるし、速度の要求も静的検証の要求も出てくる。
今の Ruby は Jit で速くなったし型チェックのサポートも本格的になった。
使い分けは要るがせずにすむならそれに越したこともないんよ。

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

>>56
そのまま移植はほぼ不可能でしょ
データ構造から設計しなおさらないと
クソコードになりがち

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

C の世界の文字列はゼロ終端やんか。
カーネルのインターフェイスにもその規約がそのまま現れてる。
内部的な設計は Rust 的にしつつも外向きのインターフェイスは変えないように置き換えるなら微妙な変換があらゆるところに出てくるよ。
まあそのへんは適当な専用フレームワークを確立させればたいしたことでもないが、そういう地味なことの積み重ねがいっぱい要るよ。

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

C/C++からJavaってのはすげー移植しやすかったのよ
その利点はほとんどないと多くの人が気がつくのに20年もかかってしまったけど

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

>>56
書き直しさえすれば何でもいいというのは大変だろうね
何でもいいというのは嘘で
本当は好き嫌いがあるから

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

コード移植なんてつまらなくて言語差で面倒なだけ
守るべき仕様さえはっきりしてるならゼロから書いたほうが結果的に早くて質も良くて楽しい

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

仕様とか契約とか目的とかは未来を予測する根拠としてはイマイチ科学的でない

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

Linux だとバイナリ互換性もかなり大事にしてる。
(Windows ほどじゃないが。)
仕様として明文化してない挙動に依存するアプリケーションであっても今まで動いていたものが動かなくなるのは良くないという方針。
「守るべき仕様がはっきりしていれば」という前提がなりたたないから困るんだよ。
そしてそれはよくあること。

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

ときどき仕様も要件定義もはっきりせず発注者が把握できていないものの言語移植ケースがあるがその仕事を引き受けないほうがいい
バグらしきもの含めて現存コードと同じ動作をするよう求めてくるためムダな面倒に精神力が奪われる

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

仕様さえ守っていればいいみたいな考えに従うと最近はお役所系でもちらほら見るクローム以外を
排除する極右Webサイトが出来上がったりするんだろうな。発注側でも受注側でもね

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

ちゃんと充分な調査費用も出るならやらんでもないけどな。
大きなシステムの一部をリライトする場合には一から作る場合より数倍のコストがかかっても
全体をやり直すよりはマシだから「同じもの」を求めるのはそれなりに合理性がある。
全部をリプレイスするのに前と同じという要求するやつがいたら、
前と同じがいいならそのまま使っとけやという気持ちになる。

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

C/C++→Rust　安全化とそのデバッグ開発効率化
C/C++以外→Rust　高速化と省メモリ化

これらの恩恵があるため
安全でないことによるバグ発生で困っているならC/C++→Rustを
CPUメモリリソース削減が求められてあるならC/C++以外→Rustを
たとえ同じ仕様のままでもやる意味が生じる

**デフォルトの名無しさん** · 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使ってる自覚もないよ