Rust part33 (229ﾚｽ)
上下前次1-新
80: 08/25(月)21:09 ID:KzDmCwhz(1) AAS
ファンじゃなくて自演スレだから
81(2): 08/27(水)18:45 ID:s/5KNF71(1) AAS
タプルといえばzipとmultizipの方針の違いでVec指定の与え方が微妙差
let (counts, chars) = str.chars().sorted().dedup_with_count().unzip::<_, _, Vec<_ Vec<_>>();
let (counts, chars) = str.chars().sorted().dedup_with_count().multiunzip::<(Vec<_ Vec<_>)>();
82: 08/28(木)10:55 ID:OS0cfYx9(1/2) AAS
抽象なんて「見たいものだけを見る」という程度の意味だからね
もしメモリ管理が最大の関心事なら
抽象度が最も高いIUnknownにリファレンスカウント機能をつけていい
83(1): 08/28(木)11:58 ID:1IatnfJ+(1) AAS
>>81
左辺に型を書けばいいんだよ
そのほうが読みやすいしタイプ数も少ない
あとunzip/multiunzipはcollectでも代用可
84: 08/28(木)15:40 ID:OS0cfYx9(2/2) AAS
なんで掛け算の引数には名前がないんだろう
順序を逆にできない理由が一目でわかるような名前があるなら名前をつけるべき
85: 08/28(木)20:43 ID:fdP0HyCm(1) AAS
>>81
unzipはトレイトを使っていないため余分なパラメタが露出してしまってる
multiunzipはトレイトMultiUnzipを
collectはトレイトFromIteratorを使っている
>>83
今年のRust 1.85からタプルもcollectできるようになったね
86: 08/30(土)05:57 ID:JBC8dN2M(1) AAS
a * b * c
は b や c のすぐ隣に目印があるからキーワード引数は不要だ
mul(a, b, c)
(* a b c)
このような記法だけが、b c 付近で文法的サポートが不足している問題を抱えている
87: 08/30(土)23:22 ID:6bFj+97W(1) AAS
>>55
namedtupleは廃れて今はdataclassを使う
Rustでの#[derive(Debug, Hash, Ord)]付き構造体相当
結局Pythonでもそのへんはちゃんとしてほしいことになった
88: 08/31(日)09:51 ID:cF2U6lLu(1/2) AAS
ハッシュ関数を使えば保守的GCが廃れる
確率を見たらカオスと思え
89: 08/31(日)10:00 ID:mJd+1ya1(1) AAS
>結局Pythonでもそのへんはちゃんとしてほしいことになった
誰か日本語に翻訳して
90: 08/31(日)10:52 ID:QUPYnWaR(1) AAS
足りない頭で必死に調べた複おじの努力を認めて差し上げろ
それはともかく、一般にスクリプト言語ではタプルはあまり好まれず、辞書が好まれる傾向がある
- ユーザーが辞書データ構造を使ってレコードを扱うことに慣れている
- 辞書を扱うための簡便な構文が存在する場合が多い
- 辞書と配列の速度やメモリ使用量の差が問題にならない
- 値が増えた場合にランタイムエラーを引き起こす
なお、dataclassは辞書に対する型付きのラッパーに過ぎない
あくまでこれはスクリプト言語の事情であり、Rustのような静的言語においてはレコードはタプル(構造体は名前付きのタプルの一種)として実装することが基本であることに注意しなければならない
91(1): 08/31(日)17:32 ID:qrCON/OK(1) AAS
辞書かどうかは本質ではない
辞書として用いないことが圧倒的に多いため例えばV8では静的解析で判明するプロパティを構造体フィールドのように扱い実行するため辞書実装とは異なり速い
92: 08/31(日)18:15 ID:IkR/a1qs(1) AAS
また的外れなレスだなぁ
結局複おじにもそのへんはちゃんとしてほしいことになった
93: 08/31(日)18:20 ID:yY4/9rZW(1) AAS
>>91
V8のプロパティアクセスの最適化は基本的には静的解析に依存しないよ
同じプロパティが同じ順序で追加されたオブジェクトは同じ型と見做してキャッシュされたプロパティの位置を利用する
あくまで辞書データ構造を前提としたままでキャッシュ戦略を工夫しているに過ぎない
94: 08/31(日)23:19 ID:cF2U6lLu(2/2) AAS
魔法の数字ではなく
ちゃんとenumを使うことになった
95: 08/31(日)23:24 ID:Dds/cnqW(1) AAS
Minimal Embedded FAT32 Driver - in Rust!
動画ﾘﾝｸ[YouTube]
96(2): 09/02(火)22:34 ID:sEJ6dDWm(1) AAS
「Rust」の平均単価が3カ月連続上昇 エン・ジャパンがフリーランス案件の分析レポートを発表
外部ﾘﾝｸ[html]:atmarkit.itmedia.co.jp
開発言語別では、比較的新しい言語「Rust」が3カ月連続で平均単価を伸ばし、87万4000円（2025年6月比で4.4％増）で1位となった。
97: 09/03(水)01:10 ID:rmZ6WmxL(1) AAS
もういいよ
98: 09/03(水)06:18 ID:Myuv+TwW(1) AAS
Rustがトップになる予想が当たったね
99: 09/03(水)08:43 ID:Ypa4ifGO(1) AAS
これからどんどん増えるで
100(2): 09/03(水)10:27 ID:pUgFa8ls(1) AAS
外部ﾘﾝｸ[html]:corp.en-japan.com
Goもそうだけどレベル低い人(特定言語の習熟度ではなく基礎的な技術力の観点で)お断り案件がほとんどだから単価が高く出る
つまり裾野が狭いことを意味するわけで、決して手放しに歓迎すべきことではない
特にRustがこれから食っていかなければならないのは最下位付近にいるC++とCの領域だから、普及していけば単価は大幅に低下する
101(1): 09/03(水)10:39 ID:slTkF8Pj(1) AAS
> 全体として、比較的新しい言語である「Rust」や「Go言語」、「Kotlin」などが高い単価を維持しており、市場での需要の高さがうかがえます。
これかなり違和感あるなあ
このへんのメンツの単価が高いのはつまるところ案件の難易度が高いからで、
下の方のコモディティ言語と同じように需給バランスで単価が決まると考えてるのは実態を知らないんだろうなと思う
102: 09/03(水)11:43 ID:FcGJkFCi(1) AAS
>>100
C系はバカでも書けるから安いんだよ
レベルが低い人はRustが難しいと感じて挫折や一部アンチ化
一方で今後求められつつあるのが安全で速いRust
103: 09/03(水)12:11 ID:UDH6IOq3(1) AAS
もしかしてRustを誰も使ってないのはレベル低い人だらけだから？
104: 09/03(水)12:41 ID:JLXMHQtL(1) AAS
>>101
案件の難易度というよりも
開発者個人に期待されてる技術水準だったり
言語に付随して求められる知識やスキルの水準と希少性による
それらが低い水準の技術者でも構わないという求人の多寡が
言語別平均単価を最も大きく左右する要因
105: 09/03(水)14:32 ID:mk24rcqJ(1) AAS
低い水準の技術者ほど言語別の単価を気にするのは他に差別化できるものがないからなんだよな
転職エージェントについても同じ事が言える
106: 09/03(水)14:55 ID:wGzU1Ifu(1) AAS
納期を守るのと守らないのはどっちが供給不足か
デフレ脱却したいとして、供給を減らすのと増やすのはどっちが合理的か
ぜんぜんわからない
雰囲気
107: 09/03(水)20:52 ID:16NS2IAc(1) AAS
関係ないよ
Pythonの単価が一番高かったころもあった
その時はみな稼いでいたんだろな
需要と供給のバランスが崩れてるところと言う視点だけだと思うけど
108: 09/03(水)23:36 ID:0gdcYoMa(1) AAS
何が関係ないのか全然わからん
109: 09/04(木)00:25 ID:6pIdFnm5(1) AAS
プログラミングは一種のパズルのようなもの
各言語の機能制約＋バグなく目的の実現という全体のパズルを解いていく
Rustの場合はメモリ関係や諸々の安全性などのための制約で他より難しいパズルになるため誰でも参入できるわけではない
代わりに速さ省メモリ安全性の両立という唯一の果実を得ることができる
構造的に単価の崩壊は起きそうにない
上下前次1-新書関写板覧索設栞歴
あと 120 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.010s