Rust part9
レス数が1000を超えています。これ以上書き込みはできません。
デフォルトでは利便性やリンクの高速化のために大きくなってるけど
組み込み用途ならちゃんと最小化する方法はあるし
Cと同程度まで縮むよ >>896
下記の記事の Executable sizes の節で実行ファイルのサイズについてCとの比較を考察してた
サイズ削減する方法も書いてあったよ
https://kornel.ski/rust-c-speed ちょびっとだけどついにlinux-nextにrustで書かれたコードが入ったか >>896
組み込みデバイスでrustを使いやすくしようとしてるワーキンググループあるから
どういうところで不便に思っているのかコメント寄せてあげたら良いのでは
https://github.com/rust-embedded/wg
issueでコメント募集してるよ 依存しているクレートが多いとビルドが長い、いい加減にしろ。なんじゃこりゃ >>901
だから考えてるスケールが全然違うっつーの Rust の実行ファイルが大きくなりがちなのは何でもかんでもスタティックリンクする文化であって、
そうしてでもうんざりするような (実行時の) 依存関係に悩まされたくないという話なので、
不要なもので肥大化しているわけじゃないよ。 本来必要なものがあるだけ。
もちろん制約の大きい組み込み環境でごく基本的なライブラリすら制約してまで
大きさを削ったら使い勝手は悪いだろうけど、
それは Rust に限った話でもない当たり前のことだし。
メモリが数キロバイトとかいうレベルだったら (少なくとも現時点では) Rust が不向きというのはそうかもしれない。
そんで特に Rust を使いたいというケースでもない。 >>906
具体的に言語化できる能力あったらこんなとこで愚痴垂れてないでしょう Linuxのディストロだとなるべくダイナミックリンクにするようにしてると思うんだけど
Rust製ツールとその方針の相性悪い気がする Q. Rustの倒し方を教えて下さい
A. まずデータセンターを燃やします
フランスのデータセンターで火災…『Rust』に復元不可能なデータロストが発生するなど大規模被害に発展 | エンタメウィーク
https://ent.smt.docomo.ne.jp/article/8989583 Rustってなんか日本人的にわびさびっぽい名前でいいよな そこんところは golang とか rustlang とか書く風習が出来てるから
たいした問題ではないんだが、 C のことを clang とか書き始めるやつが出てきてクソッタレという感じ。
よそでどんな習慣が出来てもいいけど変な汚染するなよな〜〜という。 LLVM ClangはふつうClangて書かない？ Clang は Clang のことなので
C のことを Clang っていわれると困るって話 >>909
というよりその方針だとsoのバージョン非互換で問題が起きて大変なので
GoやRustなど最近の言語はダイナミックリンクを避けている。 >>917
ディストロがビルドして配るバイナリの話だからバージョン非互換は関係ないのでは
非互換が問題になるならソースにパッチ当てられる訳だし
goも同じ問題があるというのはそうだけど >>919
そもそも最近はディストロのパッケージ管理システムに乗りたくなくなっているのでは？いろいろなディストロのいろいろなバージョンに対してバイナリを提供すること自体が大変で。
Gentooやってると依存関係ミスっててコンパイルこけるとかよくある。
（そういう意味でもGoやRustはかなりコンパイルに失敗しづらくて安心感はある）
退化している感もあるけど、GitHubで全ディストロ対応のシングルバイナリ配るのが結局楽だった、という感じなのかも。 場合によっては違うバージョンのライブラリが共存することもあるし
ファイル名のルールでどうにかしたりはすごく面倒
近頃はコンテナにまるごと突っ込むとか言った解決法も取れるが、
それなら全部スタティックリンクしたらええやんというのは
順当な方針だよな パッケージのバージョン管理とかRustは最近のnpmばりによくできてるんじゃないの
知らんけど >>921
gcc コマンドの実態が clang の環境が
存在するのでそれを茶化したジョークだと思う Ruby, Python, Rとか言語独自のパッケージ管理システムもありつつ
同時にディストロのパッケージ管理システムにも有名ライブラリだけは乗ってたりして
なんか二重管理みたいな変な事になってる 開発環境が用意するパッケージ管理は開発環境の管理だし
ディストリビューションの管理は実行環境の管理なんだけど、
ライブラリが実行環境なのか開発環境なのかは不可分な部分もあって単純に二分できんのよ。
C/C++ のライブラリのパッケージ管理が発展してないのは伝統的に
ディストリビューションのパッケージ管理に全力で乗っかる文化があったからで、
モダンな開発環境は分けようとしてかえってややこしくしているような気もする。
元々あった問題があぶりだされただけかもしれんけど。 まあlibcのバージョン違いで困った経験あると、スタティックリンクはやむ無しって思うけど。 >>913
コンパイラをclangという名前にしてしまったAppleが馬鹿なだけ。
ライバルにMSのcl.exeというものが30年ほど前からあるだけでも
ややこしいのに。 >>926
C/C++全盛の頃はコードを書く人と使う人が一致してることが多かったから問題なかった気がする。
自分の環境さえ正しくセットアップすればそれで問題ないという。
今みたいにGitHubでコード共有するのが当然って世界だと違う環境でビルドするのが困難ってのはきつい。
OSSのC++ライブラリを使おうとしたときに、作者と違うディストリビューション使ってる場合、ほぼ確実になんらかのトラブルにはまる印象だなぁ。 てか低レイヤー依存のパッケージは言語パッケージ管理じゃ扱いづらいだろ。 >>928
自分の開発環境に cl.exe があるのを見つけて
「あれ？ Common Lisp なんか入れたっけ？」って思ったことがある。 Rustと関係ない雑談はそろそろよそでやって下さいね 次世代言語21 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1587276362/
あっちのスレの流れの中に投下するものがこっちに誤爆して話題が続いてるだけだぞ 親善試合のプレー中でもないのにパンチを繰り出し、歯を折る韓国人の本質 >>939
証明論関係はプロトコル検証なんかには使えるかもね。 PDA以上の機械はどうやって機械的に証明したらいいんじゃ…… ZDNet Japan: トーバルズ氏が考える、LinuxにおけるRustの居場所とは.
https://japan.zdnet.com/article/35168533/ >要するに、Linuxの記述言語がCからRustへと変わる日は当面の間やってこないだろう。その一方で、Rustベースのプログラムやドライバーをユーザー空間で実行するということに対する関心は高く、それに向けた動きは数多くあるため、いつの日にかLinuxというOSでRustベースのカーネルが採用されるだろう。
まあ当たり前の結論だわな。 Javaやpythonのようなバブルは無いだろうが一定の需要はあるだろう 競技プログラミング分野で謎の注目を集めてるよRust
短時間とか早解きが重要なコンテストでは雑に書けないので使いづらいが、長期間のコンテストでは重宝されてる
強い人たちが使ってるのもあって まあ９割は単なるファッションだろ。
実際使ってみるとc++で気をつけるのとほぼ変わらんしそれができる輩しかまともに使いこなせん。 そもそもデバドラならC++でもいいんちゃうん？
Linusが問答無用で許さない感じ？ >>954
昔LinusはC++をボロクソに言ってた。特に例外周りがカーネルとは合わないとかだったかな。
今の改心したLinusなら違うかもしれないが。 C++は罵詈雑言で二度とそんなこと言うな
ぐらいで叩いてた 思いっきり皮肉だけど｢C++独自の機能を使わないならC++でも構わない｣みたいなこと言ってなかったっけ オブジェクト指向はクソみたいなのも言ってた気がするし、
当時Linusが文句言ってたポイントをRustはうまく回避してるかも。 linusはオブジェクト指向はファイルシステム周りでは有効って昔から言ってる。
流石にこの辺りの感覚は鋭いわ。 あぁ確かにオブジェクト指向というよりC++のそれにまつわる機能がクソって話だったね。 そうは言ってもリナス自身が言語処理系に手を出す事は無いんだろうな >https://japan.zdnet.com/article/35168533/
これも年取ったからだいぶ穏やかに答えてるけど内心は
「とりあえずデバイスドライバーで実装してみろやwやれるもんならなw」って感じだと思うぞ。 >>955
https://tabesugi.net/memo/2009/1a.html
Date: Thu, 6 Sep 2007 18:50:28 +0100 (BST)
Message-ID: <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org>
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。 >>956
＞C++は罵詈雑言で二度とそんなこと言うな
＞ぐらいで叩いてた
>>964
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。 >>957
＞思いっきり皮肉だけど｢C++独自の機能を使わないならC++でも構わない｣みたいなこと言ってなかったっけ
>>964
＞唯一まともで、効率がよくて、システムレベルで使えて、移植性があるC++ ってのは、基本的に C で使える機能だけに限ったときなんだ。 >>958
＞オブジェクト指向はクソみたいなのも言ってた気がするし、
>>964
＞C だけに限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
＞ついでに沢山のプログラマが実際に低水準の問題を理解することができて、
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。 しかしこの話ももう15年近く前だし、C++20についてどう思ってるのかは気になるな。
相変わらずボロクソなのか、もう少し丸くなってるのか。 >>963
残念ながらlinusは俺の１０倍はひねくれてるよ 色々な言語を扱ってみればどんな言語でも"トンでもなく悪い設計の元になりうる"のは
Linusも気がついてるんだろうが、こういう手合いは
単に自分の好みで気にいらない事を否定するのに「一般的に良くないものだ」という
主張を持ちだすから始末がわるい
またこの手の攻撃的な人物は自分の周囲の人間が一般的であると思い込む傾向もあり
たしかにLinuxとオープンソース界隈の人間がC++を使いまくると"トンでもなく悪い設計"に
なりやすいだろうなというのもわかる(そういう界隈の人間は基本的に自由であり
自由にできる幅があるときは自分の思いついた"カッコイイやりかた"をすぐ人におしつけたがる) C++ネタになると書き込みするやつが急に増えるんだからwww
いい加減C++スレでやってね C++に勝てるっていう宣伝文句に惹かれて興味を持った人が多いのだから、本当にC++より良いのかっていうところに焦点が当たるのは宿命 >>953
C++ の仕様に違反せずに書くために「気を付ける」程度で本当に足りるのか？
足りないからそこそこの規模のプロジェクトになったら valgrind とかのツールを導入するはめになるんだろ。
十分に知識を持っていても隅から隅まで 100% に配慮するのは無理ってのがわかってるから、
C++ で気を付けるのとほぼ変わらんなら Rust を導入する意義はある。 規模が大きくなって関わる人数も増えれば気を付けるのもかなりのストレスだしなあ C++より安全という声は多いが誰がC++に勝てるなんて言っているんだ？ c++でもuniqueptrなりconstなりmoveなりはあるわけで、かける人は同じように書けるだろ。
結局かける奴は書けるしかけない奴は書けないってのはどっち使っても一緒だわ 昔は隅々まで配慮できる集中力があった気がするけど
歳とともに無理になってくるからコンパイラに指摘してもらったほうが楽。
いつまでも完璧なC++が書けるならそれはそれで羨ましい。 高度な技術と集中力でミスなく実行すれば
バグは発生しないという妄想に付き合うほど
みんな暇じゃないんだなあ だから問題あれば自然にコンパイラで引っ掛かるような書き方してるって話なのに全く通じてねーなこのバカ。 気をつければ大丈夫の域出てなくて笑う
コンピュータの仕事してるとは思えない、 >>980
C++ってmoveされた後のオブジェクトに触って警告とか出ましたっけ？？ そんなところでミスしてなぜかテストも書かない輩みたいな馬鹿を想定する意味がわからん。。
とことん自分の都合のいい馬鹿ユーザーしか想定してないってのが丸わかりだわ。 そうだぞC++が使いこなせないのはお前らがバカだからだ
根性で頑張れや そうだぞC++で出るバグや脆弱性はテストで全て回避出来るからな
死ぬ気でテスト書かないと駄目だぞ
コンパイラの警告なんかに頼るのは負けだと思え C++はメモリへのアクセスの回数やパターンが見た目からはわかりにくいコード
（コードからメモリが透けて見えないコード）にすぐなるから
カーネル製作者としては許容し難い、というのが主要な反対理由のはず 言語がRustであってもC++的な書き方をしているのを見たら怒り狂うことは必定 指差し確認しながらコード書くべしとか言ってる馬鹿と変わらんな c++でまともに書けない奴がなぜかrustを使うと書けるようになるとかいうファンタジーを信じるバカの多さよ。。 「気をつければ大丈夫」みたいな根拠無き精神論って日本の生産性が低い一因だよな 関数粒度を揃えるとかも根性論だとか思っちゃうバカなんだろうな。。 せやせやまずc++でテスト100万行書いてから文句言え C++のテストフレームワークって基本的にクソマクロ触らされるからやだ はいはい、まともにrustでc++並の開発速度で製品作ってから言えや。 レス数が1000を超えています。これ以上書き込みはできません。
