Rust part20

**デフォルトの名無しさん** · 2023/03/03(金) 00:45:28.73

公式
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 part19
https://mevius.5ch.net/test/read.cgi/tech/1673926892/

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

**デフォルトの名無しさん** · 2023/07/31(月) 18:05:43.81

mutはガチでダサい
何かいい記号はなかったのかとｗ

**デフォルトの名無しさん** · 2023/07/31(月) 18:13:53.64

英語圏の人たちはmut見てcoolに感じるとか日本人と感性が違う可能性がある

**デフォルトの名無しさん** · 2023/07/31(月) 18:38:57.32

>>878
感性が古いよ

**デフォルトの名無しさん** · 2023/07/31(月) 18:48:05.02

今までミュートと読んでいた

**デフォルトの名無しさん** · 2023/07/31(月) 18:49:54.52

unicode解禁にして変にすればいい

**デフォルトの名無しさん** · 2023/07/31(月) 20:49:15.69

>>881
短い略語を使いたがるのはメモリ容量が少なかった昔の習性・感性だろ。
昔に作られた言語のFortranとPascalですらfunctionは略さなかったのに、
今になって変な略語を採用したRust開発者は工学的センスも美的センスもない。

比較的新しい言語のF#はmutと略さずにmutableと書く。

**デフォルトの名無しさん** · 2023/07/31(月) 21:15:27.96

BASICの頃はDEF FNと言うので関数を定義してた

**デフォルトの名無しさん** · 2023/07/31(月) 21:25:40.03

様々なプログラミング言語があって千差万別な中
大した問題ではないキーワード名やその多少の長さに文句をつける人はダメな仕事できないやつ
仕事できる人は文法とその意味論を比べる

**デフォルトの名無しさん** · 2023/07/31(月) 21:34:38.41

ダサいのはダサい

今後何があってもbegin end区切りの言語は使わないと思う
delphiやってた時もimplementationと言うのを見てクソダサいなと感じた
Objective-Cも二度と接することはないだろう

**デフォルトの名無しさん** · 2023/07/31(月) 22:59:44.59

kotlin や swift の前で同じこと言えるの？

**デフォルトの名無しさん** · 2023/07/31(月) 23:19:46.93

implementation　Point　{
public function ...
｝

**デフォルトの名無しさん** · 2023/08/01(火) 03:00:40.65

>>880
constより2文字も短い！かっけええぇぇぇ！！！
かもな
同意しないけど

**デフォルトの名無しさん** · 2023/08/01(火) 03:53:49.10

constは定数だからコンパイル時に静的に確定する
immutableかmutableかというのはconstとは無関係な概念で実行時の変数の値が書き換わるかどうか
つまりRustの非mut (immutable)は定数ではなく実行時に値が決まる変数

**デフォルトの名無しさん** · 2023/08/01(火) 11:16:59.87

let x : u32 = 1234;
と
const x : u32 = 1234;
は違うんですか？

**デフォルトの名無しさん** · 2023/08/01(火) 11:22:28.49

なるほど、const = の右辺値はconst 文脈で書かれていてコンパイル時に決定できないといけないけど let = の右辺はその制約がないのか

**デフォルトの名無しさん** · 2023/08/01(火) 17:52:49.94

constはコンパイル時に値が決まる定数となり定数名は大文字で書く
letは(mutの有無に関係なく)実行時に値が決まる変数となり変数名は小文字で書く
mutの有無はその変数の値が書き換えられるかどうかだけの違い

**デフォルトの名無しさん** · 2023/08/01(火) 18:49:11.32

自分は素人だけどそれじゃあ型に対する言及が抜けてないですか？

**デフォルトの名無しさん** · 2023/08/01(火) 20:27:35.06

型とは直交する概念なので型とは無関係
任意の型で成り立つ

**デフォルトの名無しさん** · 2023/08/01(火) 22:08:28.57

'static

**デフォルトの名無しさん** · 2023/08/01(火) 22:38:58.55

constはシャドーイングは行われない
変数と違い型を必ず明示しなくてはならない

**デフォルトの名無しさん** · 2023/08/02(水) 00:09:43.49

>>898
なんでですか？
constシャドーイングしてなんか不都合あります？

**デフォルトの名無しさん** · 2023/08/02(水) 00:12:43.58

>>892
constならROM領域に置ける

**デフォルトの名無しさん** · 2023/08/02(水) 00:12:59.71

あ、わかった
そりゃそうだ

**デフォルトの名無しさん** · 2023/08/02(水) 09:00:43.40

関数名というか関数を格納した変数？にもmut付けるときあるけど
動作中に関数を変えるのが目的？って表明以外の意味ある？

**デフォルトの名無しさん** · 2023/08/02(水) 13:19:46.95

関数ポインタかラムダ式（クロージャ）かで意味が変わりそうだな

関数ポインタの場合は途中で別の同型の関数に差し替えるときにmutが必要
クロージャの場合は途中で内部の変数が変更される（FnMutになる）ときにmutが必要
（クロージャは型の関係で別の関数に差し替えることはできないはず）

下の例だとf,gのどちらもmutがないと怒られる

fn print_foo() { println!("foo"); }
fn print_bar() { println!("bar"); }

fn main() {
let mut f: fn();
f = print_foo;
f();
f = print_bar;
f();

let mut i = 0u32;
let mut g = move || { println!("{i}"); i += 1; };

for _ in 0..5 { g(); }
}

**デフォルトの名無しさん** · 2023/08/02(水) 13:23:57.98

そこに置かれてる値（関数ポインタ or クロージャ）が変更されるという意味では同じか

**デフォルトの名無しさん** · 2023/08/02(水) 18:24:39.32

let mut hoge; じゃなくて

むしろ let hoge = 3; と mut hoge = 3; の二種類に分ければ美しくてよ

**デフォルトの名無しさん** · 2023/08/02(水) 19:02:02.79

static mut もあるし
letはパターンマッチ文だからlet (mut a, b) もあるし
if let Some((ref mut p, ref q)) もあるし

**デフォルトの名無しさん** · 2023/08/02(水) 20:18:56.34

>>905
それは無い

**デフォルトの名無しさん** · 2023/08/03(木) 07:43:41.06

速い！安全！ださい！

**デフォルトの名無しさん** · 2023/08/03(木) 08:17:38.34

>>906
mutを単独キーワードに分離したRustの設計方針の勝利だな

**デフォルトの名無しさん** · 2023/08/03(木) 10:00:57.61

かわいい
北朝鮮みたい

**デフォルトの名無しさん** · 2023/08/03(木) 21:15:21.47

こんなスレ見てるなんてダサいぞ！

**デフォルトの名無しさん** · 2023/08/04(金) 09:07:52.99

かわいい
埼玉県みたい

**デフォルトの名無しさん** · 2023/08/06(日) 17:59:34.17

任意長整数型演算の実装の演習してるんですけど

・和の時には下の桁から、大小の比較の時は上の桁から順次比較するので双方からのアクセスをO(1)で行いたい
・任意長なので加法のときにover flowしたときitemの追加ができないとダメ

この場合どのcollection型が有利ですか？
ソースが難しすぎてわかりません
情報お願いいたします

**デフォルトの名無しさん** · 2023/08/06(日) 19:27:39.64

自分ならVec使う

**デフォルトの名無しさん** · 2023/08/06(日) 19:29:40.12

>>913
何を問題にしているのかわからない
言語に関係なく連続体のデータ型(配列やベクタなど)の順次アクセスは
前から後ろから関係なくサイズNに対して総コストO(N)で1つあたりO(1)
それらのうち固定長ではなくサイズを伸ばせるデータ型(ベクタ)なら要素を追加できる
RustならVec

**デフォルトの名無しさん** · 2023/08/06(日) 20:21:24.84

>>915
各collectionの内部構造がよくわからないんですよ
ソース全部読めてなくて
vecってLinkedLustみたいな数珠繋ぎじゃないですよね？

**デフォルトの名無しさん** · 2023/08/06(日) 20:24:19.56

>>914
ありがとう
確かに片方だけ伸ばすならbecで良さそうなんですよね
しかし後でよくよく考えたら掛け算の時に一の位の方向にも伸ばせた方が便利な気もしてきて
でもそっちは絶対じゃないんですよね
なんせvecのソースがむずい

**デフォルトの名無しさん** · 2023/08/06(日) 20:32:19.03

ソースよりドキュメントを見なよ。
図つきで解説されてるから。
Vec は必要に応じて自動で再配置する配列ってかんじ。
要素は連続して配置される。

**デフォルトの名無しさん** · 2023/08/06(日) 20:50:29.31

>>918
https://doc.rust-lang.org/std/collections/index.html
とか読んだんですけどよくわからないんですよ
rust専用スレならstd::vec全部目を通せてる人いるかなと
連続して確保される領域の幅とかは指定できます？

**デフォルトの名無しさん** · 2023/08/06(日) 20:51:36.50

>>916
性質が重要なのであってよほどのことがないかぎり実装内部のソースを知る必要はない
LinkedListは極一部の用途を除きほとんどの用途で遅く不利になり今回も考える必要はない
これらは言語と関係なく一般的な話

**デフォルトの名無しさん** · 2023/08/06(日) 21:11:21.94

>>920
とりあえず今はガロアの連分数使って円周率の計算でもやってみようと思ってるんですけど、その場合計算する項のlog orderで桁数が増大していきます
でも例えばbinary splittingとかにすれば桁数の上昇具合が変わってきます
そういう用途に応じて適切なcollection型の使い分けできるようにしたいんですよ
あくまで練習なので
ソース読みはまぁ趣味みたいなもんなんですけどそもそもRustの自習が趣味なので

**デフォルトの名無しさん** · 2023/08/06(日) 21:11:35.12

>>919
だからドキュメント読めってば。
Vec はポインタとキャパシティと長さを管理する仕組みだと書いてある。
https://doc.rust-lang.org/std/vec/struct.Vec.html#guarantees
実体が配列だからスライスの形で扱うことも出来る。
もし C++ を知ってるなら設計理念的には vectorと同じ感じとおもっていいと思う。

**デフォルトの名無しさん** · 2023/08/06(日) 21:16:41.06

>>922
まぁ実はちょっと立場上普通の人より深く知ってる事を要求されることが多いんですよ
もちろんRustを並の人より知ってると言えるには後何年か修行しないといけないんでしょうけど、そもそもRustについては趣味なのでそこまで深く理解しなくてもいいとは思ってます
まぁ趣味なのでボチボチ読みます
ありがとうございます

**デフォルトの名無しさん** · 2023/08/06(日) 21:39:48.28

Haskell君と同じ臭いがしますね～w

**デフォルトの名無しさん** · 2023/08/06(日) 22:09:28.45

>>921
何度も書いて伝わっていると思うが各データ型の性質や各用途への向き不向きは使用言語と関係ない話
その適切なcollection型の使い分けというのが仮に必要だとしても各言語と関係なく抽象的なレベルで考えて可否を判断すべきこと
その上でベクタ型のデータ構造では何がいけないのかの問題点も見えてこない

**デフォルトの名無しさん** · 2023/08/06(日) 22:29:25.87

やっぱり>>913のようにサイズが不定である場合にはダメですね

The capacity of a vector is the amount of space allocated for any future elements that will be added onto the vector. This is not to be confused with the length of a vector, which specifies the number of actual elements within the vector. If a vector’s length exceeds its capacity, its capacity will automatically be increased, but its elements will have to be reallocated.

まぁ一般論ではなくて××桁まで計算するとか決めうちして使います
どのみち掛け算最終的にはFourier変換でやってみるつもりなのでその場合不定長だとメチャクチャ難しいし

**デフォルトの名無しさん** · 2023/08/06(日) 22:59:01.67

>>926
不定長なら再配置を含めてもVecが有利
再配置コストは例えば2^nから2^(n+1)へ広げる度にしか発生せず誤差となる
それよりも連続領域に配置されることによるメモリキャッシュ効果が絶対に効く

**デフォルトの名無しさん** · 2023/08/06(日) 23:14:54.40

>>927
そうなんですか？
でもドキュメントには続いて

For example, a vector with capacity 10 and length 0 would be an empty vector with space for 10 more elements. Pushing 10 or fewer elements onto the vector will not change its capacity or cause reallocation to occur. However, if the vector’s length is increased to 11, it will have to reallocate, which can be slow. For this reason, it is recommended to use Vec::with_capacity whenever possible to specify how big the vector is expected to get.

とありますよ？

**デフォルトの名無しさん** · 2023/08/06(日) 23:50:23.90

それを読んで再配置があった場合でも1回あたりO(1)で済んでいることが理解できないならば
Rustの勉強でもなくプログラミングの勉強でもなくCSなどの基礎から学ぶことをおすすめする
そういう基礎を理解しないままO(1)で行ないたいと最初の質問で書いていたのもヤバい
何度も伝えているが各言語と関係なく成り立つ話なのだから各言語に立ち入る前に理解を済ませておくべき

**デフォルトの名無しさん** · 2023/08/07(月) 00:14:34.21

>>929
>CSなどの基礎から学ぶことをおすすめする
任意長整数型演算の実装の演習をするような人ならCSで学ぶ程度の知識はあるんじゃなのか
当然、データ構造についても一通りの知識はあると思うが

**デフォルトの名無しさん** · 2023/08/07(月) 00:41:08.66

“amortized O(N)”を”1回あたりO(1)”に変換するあたりは流石オジ
でもCS基礎を学べというオジの主張に今回ばかりは同意するよ

**デフォルトの名無しさん** · 2023/08/07(月) 00:47:42.86

>>929なんでO(1)で済むんですか？
そもそもデータ全体を連続領域に確保するんでしょ？
その延長する部分のヒープがもう埋まってたらデータ全部丸写しするしかないんじゃないですか？
大体そもそもデータを連続領域に確保して前からも後ろからも関係なくアドレス1発でアクセスもできて、その上データの追加もO(1)でできるとかなら無敵じゃないですか？
そんな魔法のよなメモリ管理できるハズないのでは？

**デフォルトの名無しさん** · 2023/08/07(月) 00:48:41.30

Vecって単純過ぎてデータ構造では扱わなかったりするのかな
ならし解析では最初に出てきそうなネタだけど

**デフォルトの名無しさん** · 2023/08/07(月) 00:50:22.19

ああ、データの読み書きが一回あたりI(1)ですか
でも今データの追加は整数の桁数が一上がるごとに発生するんですよ？
あらかじめデータの桁数が不明でそれが難しいと言ってるじゃないですか
足し算のたびにコピー発生しますよ？

**デフォルトの名無しさん** · 2023/08/07(月) 00:53:46.05

こいつぅ
絶対わかってないやんw

**デフォルトの名無しさん** · 2023/08/07(月) 00:53:52.95

実際バイナリスプリッティングでマクローリン級数で足し算する場合とかどうやってあらかじめ必要桁数予言するの

**デフォルトの名無しさん** · 2023/08/07(月) 00:54:45.54

実際どんな用途かも具体的に書いてるのに

**デフォルトの名無しさん** · 2023/08/07(月) 02:21:35.00

2年くらい前の過去スレと今の状況見比べて泣いちゃった

**デフォルトの名無しさん** · 2023/08/07(月) 10:50:23.98

ここまでvecdeq無しとは

**デフォルトの名無しさん** · 2023/08/07(月) 18:18:54.25

VecDequeもその名の通りVec(正確にはどちらもRawVec)で作られていて
確保されている連続領域に対して未使用領域が末端か途中かの違いしかない

>>932は確保されている連続領域が埋まった時のコストを気にしているようだが
サイズNが埋まるまでの再配置の総コストは最悪ケースでもわずかN-1回の読み書きコストで済む

例えばサイズN/2が埋まった時にその倍のサイズNの新たな連続領域へ再配置するためにはN/2回の読み書きが発生
仮に最悪ケースでサイズ1からスタートしてもそれまでの累積の再配置コストはN/2+N/4+N/8+...+1 ＝ N-1が上限値となる
つまりサイズNが埋まるまでの再配置の総コストは最悪のケースで読み書きN-1回でありO(N)で済む

一方でサイズNが埋まるまでの再配置以外の読み書きが何回行われるかを今回のケースで考えると
次々とサイズが倍々に増えていく計算の場合は最小でも合計O(N)回の読み書きが起こり
次々とサイズがリニアに増えていく計算の場合は最小でも合計O(N^2)回の読み書きが起こり
もっと緩やかにサイズが増える場合や上述の増え方の場合でも普通に読み書きが多い計算なら合計O(N^2)を超える
現実のほとんどの計算においてVecの再配置コストO(N)は誤差となる

**デフォルトの名無しさん** · 2023/08/09(水) 00:49:09.66

>>930
＞当然、データ構造についても一通りの知識はあると思うが

今までのレス読んでそう思う？

**デフォルトの名無しさん** · 2023/08/09(水) 18:58:03.94

でも競プロでvec.insert(0, value)でタイムアウトしたけどvecdeque.pushfront(value)ではタイムアウトしなかった経験があるな

**デフォルトの名無しさん** · 2023/08/09(水) 19:31:59.29

VecDequeはring bufferだから連続性は保証されないね
VecみたいなDerefがないから&[T]に渡せない
slice未実装かと思ったら2つのsliceで返すas_slices()が実装されてて思ったより芸が細かかった

**デフォルトの名無しさん** · 2023/08/09(水) 22:17:02.23

>>942
そのinsertはずらすコピーが毎回O(N)かかるからサイズNになるまでの累計はO(N^2)になってしまう
一方で満杯になったときの自動再配置コピーコストの方は累計でO(N)だからさほど気にしなくていい

>>943
その時の状態配置に応じて最小コピーで連続領域にしてくれるmake_contiguous()で
連続1本になった&mut [T]を得られるのでVecDeque内でのsort()なんかもできちゃうね

**デフォルトの名無しさん** · 2023/08/10(木) 04:07:06.41

>slice未実装かと思ったら2つのsliceで返すas_slices()が実装されてて

He-

**デフォルトの名無しさん** · 2023/08/10(木) 04:08:51.37

vecdequeはlinkedlistじゃね

**デフォルトの名無しさん** · 2023/08/10(木) 06:08:17.32

vecdequeはもちろんvecで構成
linkedlistは他のデータ構造(vector, binary tree, hash table)と比較してほとんどの用途で遅く不利なため極限られた用途でしか用いられない
linkedlistが用いられる限られた用途でもlinkedlistの欠点を補うため同時にhash tableやbinary treeなどと組み合わせて用いられることも多い

**デフォルトの名無しさん** · 2023/08/11(金) 08:01:08.13

>>930
データ構造なんて知らなくてもできる
中学生の頃やってた

大学入った1年の前期でプログラム実習があってそこでも多倍長整数演算の計算をやった
配列で計算すんの
何も難しいことはない

**デフォルトの名無しさん** · 2023/08/11(金) 08:22:37.37

RustやるならCSでもまず計算モデル(特にスタックフレームモデル周辺)だろ。

**デフォルトの名無しさん** · 2023/08/11(金) 08:37:22.11

>>948
その配列というのが長さと場所を固定した連続領域を取るデータ構造なのよ
Vecは同じ連続領域だけど長さと場所は可変なデータ構造
VecDequeはVecを用いたリングバッファで連続領域を確保して使っているけど使用データ自体は最大二つの領域に分かれるデータ構造
LinkedListは連続領域を使わない連結リストといったようにいろいろあるデータ構造の中で質問者はどれを使うべきか悩んでるみたい

**デフォルトの名無しさん** · 2023/08/11(金) 11:19:59.50

最近おかしな議論が複数のスレにまたがって続いてるけど
多倍長整数というワードすら出てこないんだからなあ

**デフォルトの名無しさん** · 2023/08/11(金) 12:40:08.98

複オジと厨房と二人いるのか？
それとも厨2病をこじらせた複オジか？

**デフォルトの名無しさん** · 2023/08/11(金) 13:08:17.16

>>951
ユーザーは多倍長整数ライブラリを使えばいい
しかし彼は作る側でどのデータ構造を使って実装するとよいかの相談
Rustの話ではなく普遍的な基礎知識の話だけどな

>>913
>>任意長整数型演算の実装の演習してるんですけど
>>(略)
>>この場合どのcollection型が有利ですか？

**デフォルトの名無しさん** · 2023/08/11(金) 14:32:24.16

>>952
最近はこじらせてる人が3～4人いるよ
複オジは>>953

**デフォルトの名無しさん** · 2023/08/11(金) 14:38:02.18

複オジ認定される人は複数いると思われ

**デフォルトの名無しさん** · 2023/08/12(土) 06:55:54.99

誰かに雇われてるのかもな

**デフォルトの名無しさん** · 2023/08/12(土) 17:12:05.53

詳しい人がいたらアドバイスをもらえると嬉しいです
やりたいこと
　入力系イベントの変換及び送出
　例えば所定のウインドウがアクティブ時にピンチインが入力されたらCtrl+「-」を送出とか
OS
　WindowsとLinux。同じコードで両OSに対応する必要はない
UI
　とりあえずCLIでも構わない
技術要素
　入力系イベントのグローバルフック。Rustではどうやる？
というか言語を問わずグローバルフックを使った新しい記事ってめっちゃ減っている気がする
現行の環境でどのような実装が良いのかよくわからない

**デフォルトの名無しさん** · 2023/08/12(土) 18:35:08.55

XY問題の上にRust関係ないな

**デフォルトの名無しさん** · 2023/08/12(土) 20:05:24.91

今でもピンチイン/ピンチアウトで縮小拡大できないデスクトップアプリは珍しくないからね
特にエンジニアリング系アプリは有名どころでもタッチやペンに対応していなかったりするし
あと今から作るならRustを使いたいけどフックなどの実装は処理系依存になりやすく
システム言語を自称するRustでどこまでできるのかという点も興味ある

**デフォルトの名無しさん** · 2023/08/12(土) 21:12:06.35

言語と関係なくね？

**デフォルトの名無しさん** · 2023/08/12(土) 22:08:53.37

>>960
言語の話ではないが、まぁ、RustでWinやLinuxのアプリを作るときには(激システム依存だろうが)関係するからな
WinならWinのapiを使うためのクレート
https://learn.microsoft.com/ja-jp/windows/dev-environment/rust/rust-for-windows
で頑張るとかになるだろうが。

**デフォルトの名無しさん** · 2023/08/12(土) 22:11:27.89

アタオカがまた別のアタオカを呼ぶ

**デフォルトの名無しさん** · 2023/08/12(土) 22:58:19.87

>>957
今風のやり方は知らないが大昔にCでxlib使ってx11のイベント通知もらって何でもできた

>>959
CでできることはRustでできる
各分野についてRustだけで書かれたクレートもあれば
Cのライブラリを呼んでほぼ生で提供するクレートから
それをRustなインタフェースで提供するクレートもある
レアな分野で誰もクレート作ってなければ自分で作るのも難しいことではない
まずはcrates.ioでクレート探しからスタート
もし何を探すべきかがわからないのならばそれはRust以前の問題

**デフォルトの名無しさん** · 2023/08/12(土) 23:35:32.02

まぁ仕事でRust使う人は皆無だろうからな
そして仕事でなければコンソールアプリで十分やし
家でサンデープログラミングするのにわざわざwindows sdk引っ張り出さないし

**デフォルトの名無しさん** · 2023/08/12(土) 23:49:38.13

むしろ仕事でWindowsを使わない
人それぞれだろう

**デフォルトの名無しさん** · 2023/08/12(土) 23:52:35.31

システムプログラミング向けの言語だからデスクトップアプリでは活況ではないんじゃないかな

**デフォルトの名無しさん** · 2023/08/13(日) 00:01:39.02

そうか、サーバサイドの人は使わんわな

**デフォルトの名無しさん** · 2023/08/13(日) 00:04:16.66

好きにプロセス消失してもいい系のWebサーバ向けアプリには
あんまメリットないわな。

**デフォルトの名無しさん** · 2023/08/13(日) 01:00:38.38

>>967
>>968
WebサーバーサイドはRustが最も適している
そしてRustが毎年調査しているAnnual Survey ReportでもRustの業務利用目的の調査トップがWebサーバーサイド＆バックエンド
https://gihyo.jp/assets/images/article/2022/09/rust-monthly-topics/in_what_technology_domain_is_Rust_used_at_your_company.png

**デフォルトの名無しさん** · 2023/08/13(日) 11:45:17.49

また現状認識ズレた人が不況に熱心なこと

**デフォルトの名無しさん** · 2023/08/13(日) 12:47:43.44

クラウドはリソース(演算能力やストレージ)を使った分だけ金がかかるという話は何度も言及されているやで

**デフォルトの名無しさん** · 2023/08/13(日) 13:12:36.18

ずっとそれ勘違いして言い続けてるよね
急になんJ民の振りしてもバレバレ

**デフォルトの名無しさん** · 2023/08/13(日) 13:31:43.04

>>971
オンプレミスも同じ
遅い言語を用いていると無駄にサーバー数が必要となりその電気代が固定費となってしまう
C/C++にはtokioのような非同期並行並列でCPUマルチコアを使い切れるスケジューリング環境もないため
現状Rust一択

**デフォルトの名無しさん** · 2023/08/13(日) 16:16:11.90

オンプレでも最終的にはそうなんだけど、クラウドの力でリソースの割り当てが柔軟に出来る状況になったので
「(開発初期は) まだ余っているリソースのチューニングは後回しにする」ということが出来なくなった。
余りなど存在しないので。

**デフォルトの名無しさん** · 2023/08/13(日) 20:12:32.36

費用ならjavaやc#の方が安い
利用者が多くエンジニアを集めるコストが低いので

**デフォルトの名無しさん** · 2023/08/13(日) 21:37:06.42

Webサービス分野だと小規模なサービスは人件費 > サーバー費用だからRustは早すぎる最適化になりがち。
とはいえ開発体験もかなり優秀な部類になってきたから初手でRust選ぶのが開発者のオナニーとは言い切れなくなってきてるよな。

**デフォルトの名無しさん** · 2023/08/13(日) 22:11:07.62

ウェブサービスというものが根本的に手探りだった時代は
素早く変更してサービスに反映させられる言語が重要だったけど
今は部品が確立してそれを組み合わせる形に変わっているから
部品が充分に揃っていると仮定できるなら言語 (処理系) の性能差で差がつく。

**デフォルトの名無しさん** · 2023/08/13(日) 22:21:31.33

でも実際問題としてRustで組んだ人いる？