-
プログラム
-
Rust part28
-
UPLIFTで広告なしで体験しましょう！快適な閲覧ライフをお約束します！
公式
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/...ow-not-to-learn-rust
※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/
※次スレは原則>>980が立てること
前スレ
Rust part27
https://mevius.5ch.n...cgi/tech/1733146370/
ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.n...cgi/tech/1514107621/ - コメントを投稿する
-
O2
-
Boundsを制約と訳すスレ
-
そろそろ自転車置き場決めた？
-
ピンポーン「トレイト境界のほうから来ました」
-
>>3
boundsの意味もtrait boundsでの用法もある範囲や領域の限界や限度や際や境界を意味しています
trait boundsはそのままトレイト境界が正しいです
英語においても制約を意味するconstraintを用いずに境界などを意味するboundsを採用しています -
Goを布教する人が「ジュニアクラスとシニアクラスとで書き方が変わらない」と主張していた
格上と比較され、どっちも同じと評価される
この戦術をもし使い回すとしたら意訳ではなく直訳を推すだろうと思う -
日本語訳プロジェクトを引き継いで「トレイト制約」で統一すりゃいいんじゃないんかな。
日本語訳プロジェクトは最新版に追随できていないから、誰も文句言わないだろ。 -
>>8
Trait Bounds自体は制約の意味ではなくてトレイトを満たす型の集合の境界を表している
制約が起きるのはジェネリックな型パラメータに対してであって一般的に型制約(Type Constraint)と呼ばれる
つまり『トレイト境界』によって対象となる型パラメータに『型制約』が生じるという関係 -
すげーなトレイト制約
これだけで無限に荒らせるじゃん -
いつも批判する人「いつでも自由だった」
いつもなら批判を批判する人「今だけ自由じゃん すげーな自由って」 -
蒸し返しピンポンダッシュやり続ける境界が荒らし
-
そもそも前後の文脈から境界の意味で使ってるのは明白なのに議論する意味あるの？
-
オライリーが「トレイト制限」で訳してたらもう少し穏便だったな
「制約」にしたせいで「境界」との互換性が破壊された -
『トレイト境界』には解散命令が出されたな
-
空の境界
-
間を取ってトレイトバウンズで平和
-
>>15
「境界」との互換性ってなんだ？ -
「制限はしているが制約はしていない」by トレイト境界
-
Out of bounds.
略してOB -
だからトレイトが実装されていないときにOut of Boundsと言われて納得するかと書いたよね？
違和感しかない -
だからとっとと「トレイト制約」に修正した最新版のRust Book日本語訳を作って公開しなよ。
日本語で参照できるドキュメントが「トレイト境界」なんだから、今のままじゃ「トレイト制約」が普及することなんてありえん。 -
それはそう。
間違っていると思うなら正しいと思う形のものを出していくしかないし、それを認めさせないと個人的に何を思おうがコミュニティの意見の代表にはなれない。
少なくとも真っ先に翻訳を出すような熱心な人々は境界と言ってるし、技術用語の習慣としては妥当性がある。 -
>>23
性的マイノリティっぽい人に「口先だけでなくとっとと本格的な手術をしなよ」と言っているような意見だ -
「find」コマンドよりシンプル＆爆速の検索コマンド「fd」の使い勝手を確かめてみた、Rust製でGitHubスター数は3万個以上
https://gigazine.net...fd-find-alternative/ -
>>27
もし R 言語っての作ったらRustより75%向上って言ってもらえるのか -
あるぞR言語
-
>>9
RustのTraitのもとになったのはHaskellのType Class
RustのTrait Boundsに相当するものはHaskellではType Class Constraints
Traits Boundsは単語の意味的にも用途的にも型を制約するために存在していて型制約の一種 -
もうやめて！ 旧トレイト境界のライフはもうゼロよ！！！
-
'a: 'bをlifetime boundって呼ぶのだけは理解できるが
Ty: 'aとかTy: Trがboundかって聞かれるとなあ -
lifetimeってスコープじゃないんかい
NLLと言うなら尚更
lexicalではないがスコープではあるんだと誰でも思うでしょ -
>>26
> fdは同じ処理を約0.25秒で完了しました。
> 実に6倍以上の速度で処理を行えていることが分かります。
Windowsでも6倍も速くなったということはOsStrのWTF8の影響は微々たるものなのか回避しているのかどちらなのだろう
いずれにせよRustで爆速に作れるんだな -
>>33
lifetime boundsはライフタイムそのものではなくてライフタイムを使ったジェネリックの型制約のこと -
>>34
time fd --threads=1 > /dev/null と time find . -print > /dev/null
で比べると、findの方が倍程度速かったからfdのはマルチスレッドの威力かな -
>>36はWindows MSYS2での結果だからOsStrrのWTF8の影響でfd(シングルスレッド)が遅いのかも
-
Rustってlinuxコマンドの焼き直しばかりしてるイメージ
-
>>38
確かにRustは清書用とは良く例えたもんだ、Rustは仕様追加変更に弱そうだし
出始めは高速で注目されたalacrittyなんて文字関連不具合は非対応の一点張りだしなあ
TypeScriptコンパイラ(type checker)で言うと、何年もかけてRustで作ったら、その間の停滞はもちろん、その後も進化止まるからなあ -
「Google Chrome」のフォント処理がC/C++言語からRust言語に
「FreeType」からの移行でメモリ安全性を改善
https://forest.watch...cs/news/1672186.html -
性能などでC実装の既存コマンドを越えられるポテンシャルがあるからね
あとは利用者のバックグラウンドがUNIX系の人多いのかな
Goはランタイム付いてきてバイナリが肥大化するから魅力ない -
>>30
本物アカデミア発のHaskellは流石 -
拗らせ詭弁爺>>44は境界(boundsじゃないよ、boundaryだよ)の数学的定義も知らずに妄信してるんだろ
-
恥ずかしいの沸いとるしw
msys2知らんのやろな -
そんなものの上で比較して何が嬉しいギガジンと言っている
LinuxDesktop使わんかい -
せめてmacOSだな
ﾄﾞｻﾞｰしかギガジンにはおらんのかもな -
Rustはリファクタリングや変更に強いため
それらでエンバグしやすい言語よりもRustを使うのが好ましい -
恥の上塗りすこいな ID:1e+q4ua7
>>34が気にかけてるOsStr/WTF8の影響の話だからな
windowsでやらなきゃ意味ないよ
とは言えRust自体がWindowsなんて相手にしてない節が多々あるので、RustがWindowsで遅いと言われても納得ではある
> LinuxDesktop使わんかい
まずLinuxでこれやって見ては
> time fd --threads=1 > /dev/null と time find . -print > /dev/null -
ガハハ、Linuxで遅いと残念だから調査してみますか
-
一般的にマルチスレッド対応をする時
並列に動作できるようにアルゴリズムを組み替える
シングルスレッドで動かすと最善アルゴリズムではなく最善より不利になったとしても、並列化できることを最優先にアルゴリズムを変える
そういう常識を知らない無知な人が「--threads=1」で実行して速度比較してしまう -
>>56
そんな保険張らなくても良いと思うよ
数値計算などを含めると分割コストが馬鹿にならないけど、ディレクトリトラバーサルはロスなくマルチスレッドが効きやすい処理だから
自分は昔から自作のMPMCキューとスレッドプールでその手の処理やらせてる -
>>57
第一生命の人にそれ言えるの？ -
FreeTyoe終了するんか胸熱
-
あの記事の比較を真に受けるやつはどうかしてるぞ
簡単なベンチマークすらできないのか？ -
>>53
リファクタリングって車輪の再発明のことだよ -
>>60
fd vs (gnu)findの記事で、(ms cmd)dir -s をしかも powershell(.net) 上でやるのが良い味だしてるよなw
--threads=1 比較はこのスレでの話 -
>>53
そこまで言うなら論より証拠が欲しいな
お題スレで697が型変更(BigInt要件追加703,706)で困ってるかもしれないので助けてあげて
C++の方は難なく型変更出来た、それも(おそらくアルゴリズム内容に感知しない)別人が
https://mevius.5ch.n.../tech/1691038333/697 -
rustは身内よりも
外からの攻撃に耐えてる感じか
素性がいいからな
ポテンシャルが危険視されてんだろ -
再発明禁止したらLispしか書けなくなるぞ
それはそれでいいか -
>>41,53,64
そのポテンシャル、いつ発揮するの？ -
>>41,53,64
そのリファクタリング、いつやるの？ -
Ubuntuのcoreutilの一部をRust実装にしてみる予定あるよ
ゆっくりかもだが着実に浸透していく -
>>71
乗っ取ってる最中だな -
やりがいあるのかね
> linuxコマンドの焼き直しばかり
やらされるようになったら愛され言語陥落 -
>>72
ははw、Linuxはデバドラで軒下貸しただけのつもりだったのかな -
Linuxはカーネルだけだから関係ないぞ
置き換えてるのはGNUのコマンドだね -
>>63
Rustは強い静的型付け言語なのでその手で問題があれば必ずエラーとなり教えてくれる
問題児となる暗黙の型変換や(!Copyの時の)暗黙のコピーがないため優秀
エラーに従いそれらを手入れしてやるだけだ
もちろんコピーせずに済むところは参照を使い必要なところのみclone()する
アルゴリズムの変更は必要ない
ここまで一般的な話だが
BigIntに限ればさらに効率高めるためにxxx_assign系を使うように変えられるとヒープ割り当て抑制でさらに効率が上がるだろう
頑張れ -
BSDがカーネルからgcc消した時もまずはコマンド(linuxからしたらユーザーランド)からコツコツやってたな
-
でかくて体力あるとこが立ち泳ぎしてる段階
-
車輪の再発明でもいいからOpenCVのRust版みたいなの欲しい、とは思う
巨大だから作り直しが面倒というのは目に見えてるが -
Rustは車輪の再発明に向かないよな。というのもコスパ悪いから。すでにバグ取りして動いてるC++とかライブラリーをわざわざ書き直すなんて俺たちはしないな
どちらかと言うと真新しいライブラリーの設計するときに導入しやすいし、チームにも勧めやすい。俺たちのチームでは一からスキーマ決めて新しい機能追加していこうってなったときテストコード含めて一括で書けるからライブラリークレイトがデグレイドしなくて開発効率上がってる
0->1型開発ならRustでやりますと言っても承認降りるよ。品質保証部とかの人もリリース済み製品の変更は嫌うが、新規開発は好きにやってと言ってくるし -
OpenCVのRust版はもうあるんじゃないの
pureRustしか勝たんのなら知らん -
>>83
なるほどね -
>>85 の 799 に答えるなら「OpenCVは既に入っている」なんだけどね
-
>>80
どの言語からどの言語に移植するのもコスパ悪いので必要ないならする意義はない
しかしそれでもRustへの移植が行われているのは実利があるからでその2大理由は
CPUメモリのリソース効率が良くなる場合
セキュリティ脆弱性を含めた安全性が良くなる場合
もちろん単純な移植ではなく再設計を伴うならばそれ自体がRustを選ぶ理由になる -
そこでGoです
-
つまり簡単に言えばTrait制約は誤訳ってこと？
-
つまり、英語の単語と日本語の単語は一対一対応ではないということ
-
>>90
一貫することが技術用語としては正しい態度なんだよ。
自然言語的な意味で誤訳かどうかは最初から問題じゃなくて「Rust 用語では境界ということにする」という先駆者たちの合意に反して新しい語をあてるのはよくなきだよなって話。 -
バイナリサイズが大きくならない
も入れておこう。Docker imageなどでは重視される -
>>93
Cと比べて小さかったら、機能がそろってないだけだな -
Goはインストールすれば必ず動くから
Dockerの必要なし
繰り返す
Dockerの必要なし -
>>95
docker を何だと思ってんの？ -
>>94
Rustなら同等サイズで同機能狙えるでしょ。アピールポイントやで -
C の主要な関数は実質的に OS の一部みたいになってる (libc.so) からその分だけ実行ファイルは小さくなる。
工夫すれば Rust でも同等を狙うことは出来るが Rust らしさは失われるよ。 -
コードの見た目と安全性がRustのままならいいよ
libc使うと変わっちゃうか。unsafeが多そう
↑今すぐ読める無料コミック大量配信中！↑
