結局C++とRustってどっちが良いの？ 7traits
レス数が1000を超えています。これ以上書き込みはできません。
C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」
っていう雑談スレ。
前スレ: 結局C++とRustってどっちが良いの？ 6traits
http://mevius.5ch.net/test/read.cgi/tech/1690610746/
関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/ あるあるトピックス
・後発のRustが優れているといっても、C/C++から「推し変」するほどじゃないな
・現状のRustはまだまだ書きにくい、移行するにしてももっと進化してからでいいのでは
・現状のcrateシステムでけえ、大げさ
・いくら安全っつっても、ヘタクソがunsafeだらけに書いちゃったらおんなし
・てかC++にも unsafe{ } はよ
・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ
・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝
・マな話は、マのスレもご活用ください >>1 GPTベースのソースチェッカーの登場でRustの必要性はほぼなくなる ネットインフラが次々とRust製になっていってる
＞【CDN世界トップシェアCloudflare】
＞https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
＞CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
＞同社自身がRust製のHTTPプロキシである「Pingora」を開発し利 用していることを明らかにしました。
＞
＞【クラウド世界トップシェアAWS】
＞https://japan.zdnet.com/article/35183866/
＞Rustで構築されたAWSサービスの例としては、
＞コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
＞「Amazon Simple Storage Service（S3）」、
＞「Amazon Elastic Compute Cloud（EC2）」、
＞コンテンツ配信ネットワーク「Amazon CloudFront」、
＞LinuxベースのコンテナーOS「Bottlerocket」などがある。 >>3
それ逆
GPTは論理的に必ず正しいことを示せるわけではない
しかしGPTは(多少間違えても)生成するのは得意
だからGPTにRustのコードの叩き台を生成させてGPTに再指示したり人間が仕上げる
そしてRustコンパイラが論理的に必ず正しく安全性を保証する
以上が互いの得意分野を組み合わせたベストな今後の向かう方向 >>2
ここまでのスレと真逆のまとめはよくないね
Rustの方が言語機能が充実しているため圧倒的に書きやすいのは客観的な事実 === 複製おじさん（通称複おじ）について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。
Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。
しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
https://mevius.5ch.net/test/read.cgi/tech/1677286186/786-799（ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている）
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張（C++にはパターンマッチが無い）に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。
ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7（これはID使用歴的に複製おじさんとは考えにくい）に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。 >>5
GPTの性能向上のスピードを舐めてはいけない
更にはRustでは不可能なデッドロックすら検出できる GPTが開発ツールに統合されることで
Rustのセールスポイントの価値はなくなる 動的ディスパッチはvtableを使った型による条件分岐で合ってるような >>10
用語の使い方以外で双方の認識に齟齬はない
どうも用語の使い方に方言があるようだ >>8
簡単で自明なデッドロックのよくある例が検出できただけであれは学習マッチングだよ
実用的じゃない
理論的にデッドロックの静的な検出は不可能なのは知っているよね？ >>12
>簡単で自明なデッドロックのよくある例が検出できただけであれは学習マッチングだよ
>実用的じゃない
そうなのかどうかは私も分からんので反例を1つ示して反駁してくれ
>理論的にデッドロックの静的な検出は不可能なのは知っているよね？
人間はできるよね? <- 反例 >>13
人間にもデッドロックの静的な検出はできません
そのため実行時のデッドロック検出ツールが使われています
この分野はGPTにも無理です >>14
>人間にもデッドロックの静的な検出はできません
お前はソース見てもデッドロックをデバッグできないんだなw
「静的な検出」に限定する必要はないのだよ >>9
むしろGPT支援でRustが有利になった
GPT自体は安全性の保証をできなくて間違いも犯すけど
GPTへRustコンパイラを通すように指示すればRustコンパイラにより必ず安全性が保証される まだ読んでない人もついてこれるように
>>12が学習マッチングと言ってるのは前スレの>>289だよ
http://mevius.5ch.net/test/read.cgi/tech/1690610746/
確かに検証したソースはシンプルで
1. ソースの規模が大きくなるとこれは検出できなくなるのか?
2. もしできなくなるとしたらどのくらいの大きさが限界なのか?
3. あるとしてその限界は実用的なのか?
など謎が多く興味深い >>15
デッドロックは簡単なものを除いて見つけるのが極めて難しくて
コードを解析してもデッドロックを見つけることは無理だと証明されてる分野
そのため検出デバッグコード入りでデッドロックが起きるまで実行させて検出しているのが現状
だからGPTも同じように長期間実行させないとデッドロックを見つけられない
デッドロックはロックの順序さえ決めて守れば発生しないので
ほとんどのプログラムはそうすることでデッドロックを回避してる デッドロック検出の現実的な需要がないので無意味だな
各ロックの依存関係が階層構造となるよう制限して設計すればデッドロックは絶対に発生しない
実用的なプログラムにおいてその制限はなんら支障をもたらさない
つまりその制限を課すだけでデッドロック問題は発生することなく終わる 反例をあきらめたか
デッドロックの検出に限らず
GPTによるデバッガ（にも限らないが）の開発環境への統合は
今日のプログラミング言語に求められる要件を大きく変えるだろうね
Rustはこの先生きのこれるのだろうか? GPTのおかげでRustだけが有利になってしまった
ミスもするが命令すれば何度でもやり直すGPT
必ず安全なコードのみを通すRustコンパイラ
この二つを組み合わせると必ず安全なコードを生成できる そういう異世界が有っても良いとは思うが
こっちの世界はそうじゃないしならなくても良いわ ＞989
C++でもRustでも所有権を持つものがいなくなった時に自動的に解放される仕組み
所有権は移動(ムーブ)できるがC言語から所有権は当然やって来ない
だからCで確保したメモリがC++やRustで自動的に解放される危険はない ひさしぶりにこのスレ見にきて
>>1 に完璧な結論が書いてあって吹いた >>1
「Aに固執するのは老害、柔軟な若者はBを好む」などという
説はよくあるが、後者は、別の新製品が出てくれば、そっちに
移るので定着しないと言われている。なので、ターゲット層
としては気をつける必要があるとされる。 >>7
>しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
Rustについても十分な知識なんて持っておらず
自信満々に間違ったこと書くから注意してね >>23
結局カットオフがあるんでアップデート後の内容に対応できてないように見えるけど。 >>5
仕上げられる人間はそんなまどろこしいことしないよ
それにaiが劣化した途端詰みですね GPTにはコード生成だの検証だのくだらんことやらせてないで証明を生成させていけッ
ttps://leandojo.org/ QiitaとNimスレで話題に上がっていたダブル再帰フィボナッチなんだけど
ちょといじったらNimでRustの700倍速出た、もちろんチートなしで 知らんけどgccとの相性が良いと言う話になっている、俺はwandbox回しただけだから wandboxさらそうかと思って保存したけど
知恵付けさせたくないから自分でやれる人だけやれば良いよ チップベンダが提供するライブラリを使うのがだいたい さいつよ
…といいつつ、一度は・多少は、自分でやってみるのは基礎力が付く
ライブラリをおかしな風に呼ぶ・まわすことが減ると思う
そういや、OneAPIの近々の更新で、iccの同梱提供やめるっていってるから、
プロプラのコンパイラもひとつ押さえとくか…って思ってる人は、オフラインインストーラ取りに行っておくといいぞ
icc系やめて、dpcpp系に収束するとかだったと思う
ガセだったらごめそ 「登録を飛ばしてDL」ってのちゃんとあるからゆるしてちょ >>40
ソース貼らない貼らない連呼する香具師がうるさいスレ
>>35 の理由は >>38 に描いてある フィボナッチはヤツの縄張りだからな
ここで喧嘩を売ると何かと面倒だ wandboxでやったら>>32のcodonのZenn記事は3年以上古いgcc使っているっぽい
g++ 14.0.0 (HEAD)
ackermann(3, 11) = 16381
elapsed time: 57 [ms]
g++ 9.3.0 (March 12, 2020)
ackermann(3, 11) = 16381
elapsed time: 134 [ms]
clang++ 18.0.0 (HEAD)
ackermann(3, 11) = 16381
elapsed time: 156 [ms] >>45
3, 11はコマンドライン引数にしてある
>>43
>>35-37だけど42は別人だ
44
不便すまない、詳細は元のQiita記事かレスをたどってくれ >>35
タイムを一応書いておく
Rustのwandboxが見当たらないからclang比較で1.6秒として
改良Nimは0.0022~0.0023秒が出たので700倍 数倍の差ならともかく700倍ともなるとネイティブ同士の言語で発生する差じゃないからな
コードがまともじゃないか比較方法がまともじゃないのは明らか
いちいち中身を見る必要もない >>48
来ると思った
だから改良Nimのwandbox貼るのやめた おじさんが出没してた過去スレって
C++ vs Rust
ワッチョイなしのほうの次世代言語スレ
ワッチョイなし時代のC++相談室
あと何があったっけ ＞C(gcc)よりNimが3倍も速い
Nimがおかしい そうやな
るstより早いはともかくcより3倍早いはなんかインチキはいってるくさい Nimすげーな。
最新の情報科学を総力して作られたNimだから
Rustより700倍、Cより3倍も速く出来たんだろ。
で、10年後にはさらにすごい言語が出ているんだろうが Nim「なんじゃこのトロくさいコード？こうした方が何倍も早いと分からん？手間かけさせやがって」 コードを見ないとなんとも言えんが、Nimの方はループにでも展開したんじゃない？
cは最適化無しとか。 >>58
人間が理解できないすごいコードを吐き出しているんじゃないのか トランスパイラが、想定以上に事前計算を進めちゃうんじゃないかｗ まともなベンチマークでは静的な事前計算ができないようにする
だからそんなことは起きない =T=i=k=T=o=k（←迷惑でしたらこちらをNGしてください。）
更にご家族にも紹介して、追加で￥3500を入手できる
https://i.imgur.com/EIoUA4P.jpg >>35
C/gccのダブル再帰の最適化本気スイッチの入れ方わかった
全てローカル、(Cは)C++chrono計測、Nimはcputicks
ダブル再帰最適化本気スイッチ版C
C/gcc
Time= 1.176ms fib_c_trigger(44)= 701408733
Time= 1.782ms fib_c_trigger(45)= 1134903170
Time= 2.424ms fib_c_trigger(46)= 1836311903
Time= 3.090ms fib_c_trigger(47)= 2971215073
Time= 3.873ms fib_c_trigger(48)= 4807526976
Time= 5.365ms fib_c_trigger(49)= 7778742049
Time= 7.337ms fib_c_trigger(50)= 12586269025
Time= 10.149ms fib_c_trigger(51)= 20365011074
Time= 13.961ms fib_c_trigger(52)= 32951280099
Time= 18.983ms fib_c_trigger(53)= 53316291173
Time= 26.660ms fib_c_trigger(54)= 86267571272
Time= 36.483ms fib_c_trigger(55)=139583862445
Time= 50.876ms fib_c_trigger(56)=225851433717
Time= 70.201ms fib_c_trigger(57)=365435296162 本気スイッチ版Cは不自然な書き方になるが再帰コール二つはループ化したりしていなくて
gccの何かの最適化が本気モードになる
改良Nim
Nimはキレイなシンプル再帰のままでここまで出る
Nim/gcc
Time= 1.368ms fib_nim(44)= 701408733
Time= 1.634ms fib_nim(45)= 1134903170
Time= 2.255ms fib_nim(46)= 1836311903
Time= 3.121ms fib_nim(47)= 2971215073
Time= 4.261ms fib_nim(48)= 4807526976
Time= 5.989ms fib_nim(49)= 7778742049
Time= 8.224ms fib_nim(50)= 12586269025
Time= 11.304ms fib_nim(51)= 20365011074
Time= 15.644ms fib_nim(52)= 32951280099
Time= 22.103ms fib_nim(53)= 53316291173
Time= 31.147ms fib_nim(54)= 86267571272
Time= 41.306ms fib_nim(55)=139583862445
Time= 58.134ms fib_nim(56)=225851433717
Time= 78.528ms fib_nim(57)=365435296162 本気スイッチ版Cでもclangでは遅いまま
C/clang
Time=1438.212ms fib_c_trigger(44)= 701408733
Time=2310.675ms fib_c_trigger(45)= 1134903170
Time=3746.923ms fib_c_trigger(46)= 1836311903
Time=6040.876ms fib_c_trigger(47)= 2971215073
Time=9779.249ms fib_c_trigger(48)= 4807526976
Time=15877.302ms fib_c_trigger(49)= 7778742049
Time=26151.375ms fib_c_trigger(50)= 12586269025
Time=42241.553ms fib_c_trigger(51)= 20365011074
Time=67936.930ms fib_c_trigger(52)= 32951280099
Time=110828.012ms fib_c_trigger(53)= 53316291173
Time=176305.471ms fib_c_trigger(54)= 86267571272
SIGINT: Interrupted by Ctrl-C.
推定
55 --> 287秒
56 --> 463秒
57 --> 750秒 シンプル再帰版 C/gcc
Time= 625.499ms fib_c_simple(44)= 701408733
Time= 995.294ms fib_c_simple(45)= 1134903170
Time=1568.026ms fib_c_simple(46)= 1836311903
Time=2497.401ms fib_c_simple(47)= 2971215073
Time=4059.698ms fib_c_simple(48)= 4807526976
Time=6563.932ms fib_c_simple(49)= 7778742049
Time=10696.766ms fib_c_simple(50)= 12586269025
Time=18117.324ms fib_c_simple(51)= 20365011074
Time=30850.988ms fib_c_simple(52)= 32951280099
SIGINT: Interrupted by Ctrl-C.
シンプル再帰版 C/Clang
Time=1556.296ms fib_c_simple(44)= 701408733
Time=2491.174ms fib_c_simple(45)= 1134903170
Time=4019.549ms fib_c_simple(46)= 1836311903
Time=6543.637ms fib_c_simple(47)= 2971215073
Time=10584.639ms fib_c_simple(48)= 4807526976
Time=17254.294ms fib_c_simple(49)= 7778742049
Time=27799.040ms fib_c_simple(50)= 12586269025
Time=45090.030ms fib_c_simple(51)= 20365011074
Time=73155.917ms fib_c_simple(52)= 32951280099
SIGINT: Interrupted by Ctrl-C.
nim 2.0.0
gcc 13.2.0
clang 16.0.5 コードも出ず一般的な副作用のある問題への適用可能性もわからないが
速度が必要なところでは始めからループを使い再帰は通常使われない
今回のような問題ならメモ化の方が高速化に対して効果的
さらにフィボナッチ漸化式の場合はそのまま二つ分のみのメモ化としレジスタ(ローカル変数)で演算していくようにプログラミングするのが常識 >>69
それ今回の目的と手段が逆じゃね？
今回のは、より高速なフィボナッチが目的じゃなく、速度計測の一つの手段として再帰のフィボナッチを使ってるんじゃね？ 言語の速度計測でフィボナッチを使うのは無意味となるためやるべきでない
ダブル再帰の計算量O(1.6^n)をどこまでアルゴリズム変換して計算量をどこまで減らせるかは言語の優劣と関係ない
フィボナッチの場合は究極的にO(n)にすることもできるが汎用的ではなくこれを言語が頑張っても意味がない
>>66もまだO(n)になっておらずさらなる改善の余地が大いにあるが仮にその対応をしてもその言語が速いことにならない
計算量を激減可能なアルゴリズムで言語間の速度を計測しても意味がない NimがCの3倍速いという話はそういうことだったのか
まともなベンチだとNimは遅くてNimを使う意義ないもんな 再帰とかじゃなくてコンパイラとかリンカとかの実用的なプログラムで同じロジックでコード書いたときに、CよりNimの方が最適化すごかったりするの？
仮にそうなら競プロでなんでnimがもっと流行らないんだろう >>75
逆にそれ以外で700倍の差をつける方法あるのか？ 結局この種の速度なんてメモリに触る部分をどれくらいカスタマイズできるか、しなきゃならんかって
話なわけで、
その辺いじってないバカほどベンチガーになる。 フィボナッチなんてキャッシュすると(メモリ触れば触るほど)速くなるだろ >>82
それは遅くなる
f(n)の計算のためにf(0)からf(n-1)までn個のメモリをメモ化で使うのと
nを順に大きくして行きメモ化は常にf(n-1)とf(n-2)の2個のみのメモリ(レジスタも可)を使うのと
どちらが速いと思う？ nはランダムに指定するんじゃなくて必ず順に取り出すルール？
そんなの使い物にならんで まーた複オジが壮大な勘違いをして頓珍漢な自説唱えてるよw 問題を勝手に決めて自分に都合の良い解釈だけで突っ走る人だから議論が成立しないよね >>84
元記事でもこのスレでもnはランダムでもなんでも関数に渡ってくる引数だよ
そのフィボナッチ計算のアルゴリズムは最適化できれば自由で途中の計算のメモ化もアルゴリズムの範疇で自由だよ
ただし関数だから以前に呼ばれた時の計算結果のメモ利用だけはダメ
それを許したらconstexprでメモつくっておいて即答になり計算測定の意味なくなるからね >>35だけど
メモ化とかしていない
asmレベルは知らないけど増加度を見れは推測はつく 煽れば情報が出てくると思っている輩が多いな
>>90
実際に試したのかどうかまでは読み取れないけど、記事は見たようで何より >>89
Rustと関係ない話をしていても心は常にRustが憎いからさ C言語の高速化のしやすさは半端じゃないな。ただ、Rustと違って時々メモリの解放忘れとかでやらかすのはあれだけだど。
gcc -O3 -march=nativeってすると爆速だもんな。Rustでこれに対応するのはあんのかな？cargo run --releaseでもgccの最適化に比べるとかなり物足りなく感じる。 LLVMベースなんだから、そのうち同等か近いところまでくるでしょ Rustのsafeモードでは効率よく使えないアルゴリズム
がある。
また、その場合、関数の中にunsafeを閉じ込めることも
不可能であることが分かっている。
ここの人は馬鹿なので理解できないので説明しない。 「safeモード」
この言葉だけで理解してないのが分かるよね 他人の無能を強調するタイプのコミュニケーションやめたほうがいいよ >>98
ソースプリーズ
根拠がなきゃ他人は説得できない 俺は趣味だからC++で良いよ。仕事で使うわけではないし。
AppleとかGoogleとかMicrosoftが使っているとか関係ねえ。 >>98
あなたがC++でソースを例示してここの人達にRustで書けるか
挑戦者を求めれば良いだけでは？
「説明しない」では誰にもさっぱり伝わらん Rustスレでコテンパンにされたのがそんなに堪えたかw お前らにはわかるまい、ってよくマンガで悪役が言うけどさ、
そう言ってる間に基礎鍛錬するから、高尚なことはいまはいいや 調べてみたらRustのコンパイルオプションにも-C target-cpu=nativeというオプションがあるっぽい。これがgccの-march=nativeに対応する模様。ただ、どちらの方が最適化性能が高いかは計測してないのでわからん。 C の vector とか map とか ordered_map から
Rust の Vec とか HashMap とか BTreeMap に変換してくれる crate ってありますか？
(また逆方向も)
map の vector だったり vector の map だったりしても再帰的に処理してくれるものを希望
っていうか copy とか clone とかせずにそのままアクセス出来れば尚良し >>110
cxx crateを見るといい
mapは対応してないけどvectorは対応してる
基本的に所有権があるから値をコピーせずに言語またいでowned valueを作ることはできない 所有権の行き来の情報を付けて、C/C++が収受できるようなればいいんだよな
RustがC/C++を追い抜くなら、かならずそれもできるようになるはず >>110
Cのmapってどこかにライブラリがあるの？
超ほしいんだけど・・・ >>110
アクセスしたいだけなら異なる型へ変換する必要がない
そのままアクセスした方が当然速い
さらに言えばもっと上位のXY問題の可能性もある >>1
OSSは混沌が続くだろう。
なぜなら、OSSという暴力を使えば、
どんなに弱い人間でも、どんなに強い人間をも
殺すことが出来るから。
ホッブズ という イギリス の 政治思想家が言うには
「人間は 放置 すれ ば、 何 を しでかす か わから ない。
永遠 に 混沌 が 続く だけ」
さらに、 混沌 が 続く 理由 を「 どんなに 弱い 人間 でも、
どんなに 強い 人間 をも 殺す こと が できる から だ」 暴力を使えば、どんな弱者でもどんな強者をも殺してしまえる。
その結果社会が乱れ、万人の万人に対する闘争状態
になる。
だから近代社会は暴力を禁止した。
ところがオープンソースは、暴力に他ならないから
社会が崩壊してきている。 >>117
また妄想かよ。コテハン付けろよ。
近代社会が暴力を禁止しているわけ無いだろ。
禁止されているのは個人の暴力で、国家が暴力機関の形で独占しているだけだわ。 あ。暴力は暴力でも、対人の暴力ね
>>113
どこのプロジェクトも、自分とこに合ったmapなりlistなりを既に持ってるから、それを使うのが結局正解
なんなら、C++(STL)で、必要十分なmapを導出(特殊化)して、extern "C" つけてあげるのもいい どうせコピーになるなら msgpack とかも OK? Googleは民間企業に見せかけた国家機関であり、
NASAのIT企業版みたいな物。RustのMozillaも
Googleから年間数千億円の資金を得ている。
どちらも共産主義的な機関だから民間企業は
勝てるわけなく、競争も不可能。 Googleの検索エンジンはCEOらの個人開発ではなく
スタンフォード大学製であり、開業資金も
スタンフォード大学から貰っていた。
また、YouTubeは米国が視聴者の情報と引き換えに
資金援助しており、それでやっとこさ経営できている
半官半民の中国と同様の社会主義の様な組織であり、
純粋な民間企業とは言えない。
当然、日本製のSNSでは競争が成り立たない。 YouTubeもGoogle検索エンジンもインターネット
自体も米国政府が国民の個人情報や他国の
企業秘密のを抜き取るための仕組みである。
そうやって技術を盗むから米国には技術で
絶対に勝てない。
TikTokはそれの中国版であるから、米国政府は
激しく抵抗した。自分がYouTubeでやっている
悪さを中国に真似されたので、自分を棚に上げて
TikTokだけを攻撃している。
中国政府はマフィアと癒着していることが
イタリア警察によって明らかになってきているが、
アメリかは元々がマフィアである。
マフィア vs マフィアの戦い中。 さらにシリコンバレー自体が軍事と結びついている
と聞いた。 Googleの検索エンジンがスタンフォード製で
あることや起業時の大学からの資金援助については
「慶応大生が学んでいるスタートアップの講義」
という本がソース。
また、YouTubeが米国政府から視聴者のデータを
政府に渡すことと引き換えに資金援助されている
というのは事実のはず。
また、GoogleがAppleにデフォルト検索エンジン
をGoogleにすることと見返りに年間一兆円の金を
渡していたことや、Chromeが出来る前にMozillaに
デフォルト検索エンジンをGoogleにする代わりに
数千億円の金を渡していたことは事実のはずだ。
Mozillaの主な資金源はそれ。
のちに、Googleは自らChromeを作ってしまったので
Moziilaに金が流れなくなって、Mozillaは倒産の危機に
ある。 >>129
dod から資金援助受けて研究するのは駆け出しの研究者なんかもそうだと言ってたぬ kill related ってゆーてたぬ Sra のお偉いさんが書いた文章にもアメリカのＩＴ企業はdodからの支援があるので日本はアメリカにＩＴで絶対に勝てないって書いてあったぬ >117 >125 >126 >127 >129 >130
だからコテハン付けろよ。 資金で勝てないというのは陰謀論でもなんでもないけどな
そもそも日本は敗戦以来アメリカの庇護下にあるんだし、
対等に競争できないことを前提に考えないといけない Chromeでは、https化してないサイトに警告が出る様にな
ったが、https化するためにはまたアメリカに結構な
金額を毎年貢がないといけなくなった。
もともとドメイン料の毎年の維持費もある。
結局、アメリカには何もしなくても金が入る
不平等な仕組みになっている。 ＡＩだってチップ作ってた企業を東京地検特捜部が因縁付けてあらかじめ潰してあるからぬ そも対等に競争なんて連中わ端から考えてもネエぬ スタート位置にすら立てねえように準備してあるんだよぬ >>133
今のテック業界は、技術や頭の良さより、
金と暴力で決まる分野になっている。
戦争になるぞと脅して自分の都合の良いルール
を世界に従わせ、金が自動的にアメリカに
入る様になっている。 dod から出てくる研究テーマわ 比較的カンタンな内容で 無名な研究者なんかでも申請通りやすくなってるぬ こうやって研究開発する人員の裾野を広げ 若手を育成すべき対象として理解してるぬ 翻ってジャップ猿のやってるコトわ ノーベル賞級の成果をあげた若手女性研究者を カスゴミステマで潰して 魂の叫びを無視して 笑い者にしたダケだぬ 当然ながら追試して正しい成果と認められても 名誉回復は一切ナシで 本人は場末の雀荘で絶賛放置プレイ中だぬ 巨大資本が裏から手を回すことを共産主義的って言うのは誤解されるからやめたほうがいいと思うんだけどな
結局それらは国際的な政治経済システムの話なんだから、ここじゃなくてもっとしかるべき場所でやりなよ ところが、大学初のものは共産主義的に
なりがちで、それがGoogleにも言えている。
あらゆるソフトウェアを無料にする姿勢とか。 Sunの商用UNIXとしての圧倒的なシェアを資金力で真正面から潰しにかかるのは現実的ではないので共産主義的手法を利用するためibmがLinuxを利用したというのが歴史的経緯と思いますケドぬ スレチさん何故ここなん？
別にどこでもいいわけじゃん
いろんなスレでやってるとか？ >>139
大学には特にＩＴ系学部は下火で基本的にカネがねえので 畢竟テーマに困れば既存の製品の車輪の再発明ぐらいしかする事がネエんだよぬ 大学でもLinuxわ人気だったぬ パッケージダウンロードのための特定のサイトへのアクセス抜きに コンパイルの労なく必要なミドルやツール類のインストールが可能だからぬ スレチを指摘されてなお居座るのは心の病気を疑われても仕方ないんよね >>142
>大学には特にＩＴ系学部は下火で基本的にカネがねえので
詳しくお願いします。
アメリかでは、ITはもう下火になってるんでしょうか。
夢のない分野になってきたんではないかとは薄々
感じてたけど。 >>147
娑婆ウケする分野かどーかじゃねえの ほぼ決着ついてるカンジだけどぬ Rust は C/C++ との相性は良くない(悪いとは言っていない)
置き換えることは可能だが面倒
無理やり置き換えたところでさらに使い難いかせいぜい同じようなものにしかならない
本気で Rust で描きたいなら C/C++ のことは忘れて新たに Rust で設計すべし
C/C++ で描けない人・描きたくない人・描き治したい人(描ける人含む) → Rust
C/C++ で描ける人・もっと楽したい人 → Nim
C/C++ で描ける人・満足な人 → C/C++ CとRustどっちがいいの？ならわかるけど、なぜC++を比較してるの？
C++は大規模開発時に楽する目的で発明された言語なのに
優秀な人材しかいないマイクロソフトがWindowsNT開発に使ったら生産性落ちたっていう欠陥言語だよ >>153
RustはC++とは相性最悪だと思うけど、Cは言語仕様がシンプルだからC言語の方がRustの仕様に合わせやすそうな気はする。C++よりも関数型のCの方がライフタイムの実装楽そうだし。 なんじゃそれ、と思うようなことが、ただの言葉足らずだったりすることもあるしな よくわからない話は静観 平日昼に役に立たないマウント合戦するクソスレ
>>1
板違いだけじゃなくキチガイ醸成するスレ立てんな
こんな奴らに居場所与えたらどこかに放火するような犯罪者になるわ CとRust比べたら普通にRustが勝ってしまうからつまらん
Cのメリットはいちいちunsafe書かずに済むことくらい CとRustを比べるとCの方が開発コストが明らかに低い。なぜならCの方がライブラリが揃ってるうえ、ライフタイムの縛りがないから。個人的にはCは数値計算のライブラリ開発ではRustよりも優れていると思う。C数値計算のライブラリはメモリリークをそこまで気にしなくて良いし未定義動作も使用者が避ける工夫をすれば大きな問題にならなそうだしね。C言語の問題はサーバーやOSサイド、Webアプリケーションの開発だと思う。ここら辺の開発ははっきりいってメモリリークとかは致命的な問題に繋がりかねない。だからISやWebアプリケーションの開発はRustでやった方が良いと思う。 >>167
C数値計算➡数値計算
IS➡OS
色々入力ミスった。 >>166
ごめん >>165 は皮肉なんだ
特に2行目 >>166
得られる恩恵<置き換えコスト
だからです。 AIチャットの台頭でC++勢いづいてるのまじうける
論文形式で全部ウェブに言語仕様ドキュメントとして残すやり方がAIと親和性高かったのかね >論文形式で全部ウェブに言語仕様ドキュメントとして残すやり方
なにそれ? Webアプリケーションのサーバーサイドの開発とかはかなりRustによる恩恵が大きい気がするんだけどな。 新規のものは可能な限りRust製になっていってるが
既存のものをそのまま書き換えるのはどの言語間であろうがコストが高い
ただしスクリプト言語からC/C++/Rustへはリソースコスト激減効果が上回りやすい ＞新規のものは可能な限りRust製になっていってるが
マジで？ >>175
>新規のものは可能な限りRust製になっていってるが
どこで？ >>175
マジで？
PHPで適当に書いた使い捨てツールもRustで書き直せるかな GCガーメモリ効率ガーだとかいうんだろうけど
ぜひISUCONでRustで優勝してみてほしいわ
優勝者は基本的に全員Goを使ってるけど、これは生産性とパフォーマンスが優れてる証拠なんだよね Goはスクリプト書く程度の規模ならよいよ
しかし普通にプログラミングしていく規模だと機能の貧弱さもあり開発がつらくなる
ようやく導入されたジェネリクスも使い勝手よくない >>181
「新規のものが可能な限りRust製になっていってる」のはどこで？ ISUCONはGoの次に使われているのが各スクリプト言語群
C++が壊滅的な状況を見てもその場しのぎのジャンル
ISUCONをもってC++・RustよりGoが優れていると主張するのは滑稽 ここはジェネリックを使いまくるC++とRustのスレ >>183
うん、だからRust自体は否定してないよ
WebにRustが向いているのを否定しているだけで
WebはGoかTypescriptなどのスクリプト言語でいいよね RustがWebに向いているならISUCONでRustの初期スコアでGoに負けてるのは何故？
なんで予選通過が1組だけなの？ Goはジェネリクスがないおかげで、標準ライブラリやOSSのコードが異常に読みやすい
Rustのマクロ、トレイト、ジェネリクスのてんこ盛りの標準ライブラリと比べると対照的
もちろんジェネリクス向いている場面はあるが機能があると必要もないところで使いたがるアホが出てくるのが問題なのよね
力に溺れてしまうのよ
その結果生産されたゴミがScalaとかのクソ言語 >>188
Goは多くがジェネリクスを入れて欲しいとの要望でついにジェネリクスを導入した
しかし他の言語と比べるとGoのジェネリクスは使いにくく多くががっかりした
それ以降はGo本スレも過疎ってる Rustは目的と手段が逆転している人間が使う言語
特にWebでRustをイキって使うやつ
何を作るのではなく何で作るのかを重視するマウントイキリ野郎 >>184
あなたのお気持ちはどうでもいいじゃないすかw >>192
Rustは上がっていき
Go行き詰まりだな >>197
それは今そうなだけでこの先わからないじゃないすか
それにgoogleトレンドの結果だけでそんなこと言ったらガキっぽいじゃないすか、ねえ goもrustもググラビリティ悪いからこれ以上発展しない >>192
Goとrust同じような言語年齢なのにGoのほうがトレンド高いのか
難しい言語のRustは学習時間が掛かる・開発者をあんまり集められないとかで避けられるのかもな その二つは10年違う
goroutine使えるようになったのが2009年
Rustがgoroutineに該当するタスクを使えるようになった(＝今のFutureとasyncが使えるようになった)のが2019年
この10年の差が大きい
>>192で興味深いのは2019年からどんどん上がるRustと下がるGo Goは何がクソといってまずネーミングが致命的にクソ
あとマスコットがキモすぎ
あれじゃだめだ >>201
それはgoroutineに比べて何が優れてるの？
2019から入ったってことはNode.jsと同じで非同期な仕組みがコロコロ変わって不安定でぶっ壊れやすいってことだよね
goroutineはGoが出た当初から何も仕組みが変わってないからどのライブラリでも共通した仕組みで使えるけど コンピュータサイエンスや低レイヤを学びたいならRustやC++ではなくCがよくて
現代で実用的な低レイヤ以外のソフトを作るにはGoが優れてる
なぜかというとどちらとも言語仕様がシンプルでどうでもいい文法の学習をすぐに終わらせることができるから
わかっているやつは言語の機能じゃなくて何を作るのかを重視するのや
Rustってのは低レイヤだけに適しているんだろうけど、それならCでいいしZigなどのシンプルな言語の方がCの後継になりうるよね
RustってのはあくまでもC++の後継であって、現在C++で作られてる特殊なアプリの後継にしかならないよね
C++がWebに向いていないのと同様Rustも当然向いていない
なぜWeb屋はCやC++の経験がないのに、Rustを使ってイキリ出すのかが本当に謎
misskeyとかな Rustが今後使われるにしてもDenoとかの言語のランタイムの裏で使っている用途ぐらいか
NginxやRedisなどの高度かつ高パフォーマンスのミドルウェア的なソフトウェアぐらいでしょ (これらはCから変える必要はないと思うが1から作る場合)
で、これらの高度なアプリを1から作ることってそんなにあるの？って話。ふつうはこれらを利用してサービスを作る側だよね。
一般層に流行らせるためには、Node.jsやGoのように誰でも簡単に扱えるようになっていないとダメ
Rob Pikeが言っていたようにGoogleの新入社員でさえ研究者でないのだから企業で使われる言語は簡単でなければならないってのが本当に真理
Googleの新入社員ですらRustなんて扱えないんだから、お前らが扱えるわけないだろ
The key point here is our programmers are Googlers, they’re not researchers.
They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python.
They’re not capable of understanding a brilliant language but we want to use them to build good software.
So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike >>205
Rustのタスクはスタックレス対称コルーチンだからGoより速くて軽い
>>4のようなネットインフラにも使われていて安定して堅固
Goは劣るためRustが採用されている >>209
webだと結局問い合わせ時間がボトルネックになるからその差が問題になるケースは限られるやろがい。
ボトムネックとボトルネックくらいの差でしかない >>207
>RustってのはあくまでもC++の後継であって、現在C++で作られてる特殊なアプリの後継にしかならないよね
なるわけないじゃん
後継じゃねーよ
C++とRustは完全に別物 >>207
>なぜWeb屋はCやC++の経験がないのに、Rustを使ってイキリ出すのかが本当に謎
ここは同意かな
C++使えないweb屋はRustでこれはいける！ひゃっはー状態なんだろ >>211
Cの後継ではないのは確かだけど、C++でもないならなんの後継なの？
Mozillaが作ってるからC++だと思ったけど いやむしろRustはCの後継と言っていい
C++の後継にはならない >>203
ネーミングが悪いのはRustだろ。しかもシンボルマークが歯車だから、錆び付いて非効率という
印象しかない。開発者は何でこんな変な名前を選んだのか。
メモリ安全、コンパイル時にエラー検出でプログラムの信頼性は保証されるから、言語名は
Trustだ! とドヤ顔で言い張れる鉄面皮ではさすがになかったんだろうな。 >>212
Web屋の世界最大手のAWSとCloudflareもWebインフラをRustで記述して実運用してるよ
ソースは>>4 >>214
そっくりそのまま返すわ
CとRustは完全に別物だから後継にはならねーよ
言語仕様を削ぎ落としたCと増やしまくってるRust
増やしまくってるのはC++と同じだからRustはC++に近い言語 >>216
それを一般的なWeb屋とは言わないんだが
インフラ屋だよね >>219
お前の中ではそうなんだろうけどこれはCを触るエンジニアでは共通認識だよ
逆にお前がRustとC++が別物である根拠を示せよ C++もRustもCの別方向の進化形でしょ
C⇔C++の書き換えとC⇔Rustの書き換えは頑張ればできそうな気がするけど
C++⇔Rustの書き換えは禿げる 結論から言えば、RustはCの後継でも、C++の後継
でもない。どちらからも言語間距離がとても遠い。 >>222
┏━C++
C
┗━━━━━━━━━Rust
こうだよ web屋がrustに流れ着くのは自然な流れ
それが理解できないのは経験不足です >>224
そんな流れまだ無いよw
今後来るのかは知らんけど Rust自体が難しいのに、更に非同期プログラミングとなるとどんでもない難易度になることになるのは想像できるわな
Web屋がそんなの使いこなせるわけないだろ
Goなら1ヶ月あれば快適にコードをかけて非同期プログラミングもできるようになるだろうけど、Rustは何ヶ月かかるんだろうね
AWSやCloudflareはWeb屋じゃないし UnityのC#のポジションに来れば習得するわ
今はまだその時期じゃない >>224
そう言われても、たしかにwebのほうは経験不足…やってねえし
てかぶっちゃけ、webの進化にはついていけん
ライブラリ・フレームワークの名前聞くたびにぐぐるしかない
ある意味、C++でもRustでもなく、JavaScript最強を実感する世界 Web屋は、Web屋であり、デスクトップアプリの
事情は分かって無いし、また、Web領域を超える
こともない。そしてRustを別の何かと勘違いして
いるのでそのうち落胆する。 Web屋は、Web屋であり、デスクトップアプリの
事情は分かって無いし、また、Web領域を超える
こともない。そしてRustを別の何かと勘違いして
いるのでそのうち落胆する。 web屋は頭悪いんだからRails使っとけってことかね
>>228 twitterでC++でCMakeやmakeのビルドエラーを直す
難しさを指摘してる人がいるけど、それは、
C++自体の問題じゃなくて、多くはGNUのプログラマ
とAutoconfやcmakeの難しさと書き方の問題によっている。
オープンソース系のCMakeやmakefileは必要以上に難しい構造をしているから。
configureなども、大部分が意味の無い構造になっているが、
それは。CやC++の問題ではない。
また、VS+MFCを使っていればその問題は生じない。
が、オープンソース系のプログラマは根本的に余り優秀でない
のでどうしてもおかしな構造をとりがち。
別の宇宙でRustがオープンソース系で流行り出せば
同様に複雑化するだろう。 twitterでRustの良さを指摘してる人のページを
見てみるとプライドが高いことが分かって来た。
独自基準で自分が優秀だと思い込んでいるような
経歴を持っている。 頭悪そうな文章だと思ってたらアンチOSSお爺さんだったwww そういう人達は学業から何から何まで
人生をかけてプログラミングの事ばかり
していてね。どうでもいいような競技みたいな
ことばかりこっていたりする。
他の人が参加すらしていない競技なのに。 ずる賢い手法で自分が一番みたいな、いなかっぺ
大将みたいな状態になっているということだ。 Rust支持者は、現状認識が間違っていて、妄想が激しい。
例えばプログラミング業界の認識からして間違っている。
集団幻覚みたいな状態にあるのかもしれない。
間違った、あるいは、自分に都合の良い認識の人が
集団を形成し、代々延々と続いた状態にあるのだ。 >>236
>また、VS+MFCを使っていればその問題は生じない。
autotoolsやcmakeを使っている場合に比べて移植性が低い >>242
そもそも誰も使ってないOSに移植する必要もない。 まぁ実態がホントにそーかまでわ分からんが 仮にそーならソレわソレでシヤワセな状態と言えるのカモだぬ >>243
誰も使ってないOSに移植する人など誰もいない 一般人向けデスクトップアプリはWindowsだけで十分。 OSS狂信者は自分の理想社会になるまで頑張り続けてるだけ。
共産主義者。 いまとなってわみんなWebアプリになってしまったので プラットフォームごとの独自GUIほすいという状況わ かなり限定的と思いますケドぬ たとえばＰＣゲのようにパフォーマンス命のバヤイトカだぬ >>247
>OSS狂信者は自分の理想社会になるまで頑張り続けてるだけ。
>共産主義者。
それは>>246のような考え方を言うのでは?
自分で自分のこと言及しているよにしか見えん webが特別なのはリリースサイクルが異常に早いこと
だからRustに魅力を感じるのは当然
Rustは難しいとか、Cより安全とかいうことを言っている連中は、残念ながら経験不足
Rustの経験不足か、webの経験不足であるのは間違いないが、なによりプログラマーとしての経験が足りてない 2年間5chやってもバレバレの自演しかできないのも経験不足？ 朝から晩まで5chで経験不足連呼するだけのゴミ人生でした >>249
意味不明。
実際にビジネスでは99.9%がWindowsなんだから
他のOSは無視してよいし。 >>253
お前がこうして書き込んで俺が読んでいるシステムは
Windowsだけで成立しているのかな?
ライブラリがポータブルなのは極めて重要
autotoolsやcmakeはそれらを支えている
視野が狭すぎる >>253
OSSをことあるごとに批判しているようだが
boostは使わないのかな? >>250
リリースサイクルが早いからバグってもすぐ直せばいいから問題ない
だからWebでRubyなどの動的言語が流行ってきたんだよ
それでも規模が大きくなると開発自体が大変になるからTypeScriptやGoなどが流行ってきた
つまりRustとWebは最悪な組み合わせだね
コンパイル速度が遅くメモリ安全のために強要される
Webでは早く開発するのが重要であるから、無駄な努力をしていることになる
Rustが向いているのは低レイヤでバグが許されない用途 あなたのような土方志向言語の使い手には呆れて反論する気も起きません
経験不足どころかプログラマーですらない >>257
前半の段落読むとRustも選択肢に入るという話かと
思ったら後半で支離滅裂になった あなたが何を言おうがWebでRustが流行ることはないからいいんじゃないかな
君の脳内だけでは流行っているようだけど そもそもGC言語であればメモリ安全
メモリが潤沢に存在するWeb環境でなぜわざわざ非GC言語を選択する必要があるの？
マゾとしか言いようがないな
目的と手段が入れ替わった馬鹿
Rustが低レイヤ専用言語という事実をいうと発狂するのは、自分がそれらに携わることが決してないWeb屋だからだろうw
効いちゃった？w >>257
複オジ以上に無知ですね
TypeScriptやGoが使われるようになった理由くらいの一般常識は最低限勉強してからWeb開発について語ってください 自分がWeb屋で低レイヤを一切触ったことがないがこれからはRustだと勝手に妄想を膨らませて無駄に勉強しちゃったけど、Webでは絶対流行らない低レイヤ専用言語だという事実を指摘されて発狂してID変えまくって書き込むアホw
お前は無駄な努力してたんだよw
意味のない努力だよ 自分で技術選定したことないから表面的なことしか分からないんだな だからお前のいうWeb開発でRustを採用している企業ってあるの？聞いたことがないんだけど
AWSやCloudflareがお前が勤められるような一般的なWeb企業ではないからな >Rust支持者は、現状認識が間違っていて、妄想が激しい。
これは一理ある >Rustは難しいとか、Cより安全とかいうことを言っている連中は、残念ながら経験不足
Rustの経験不足か、webの経験不足であるのは間違いないが、なによりプログラマーとしての経験が足りてない
これも一理ある >>254
5chって今もSJIS使ってるんだっけ
もうUTF8のDATとかHTML返してくれるようになった？ とりあえず現状行列ライブラリをRustで実装するのは止めてる。理由はsimd命令周りの対応が微妙すぎるから。
今はC言語で行列ライブラリを実装している。Rustへの移植性を考えたデータ構造にはしてある。とりあえず1000×1000の行列積をシングルスレッドで0.034秒で実行できるようになった。手元のIntelMKLと大体同じくらいの速度。まだ、試してない最適化がいくらかあるのでそこら辺を実装したら0.025秒台くらいは目指せそう。行列積の実装で大分スキルがついてきたので固有値問題とか逆行列の計算も実装していきたい。ここら辺のことが一通り終わったらGitHubにソースコードを挙げようと思う。 >>272
そのCライブラリをRustアプリから呼べるようにはしないの？
頑張ってね >>273
今、どうするか検討中。内部の行列積を計算するとことろなどのsimdやアセンブラを直接叩くところ以外は最終的にRust純正を目指していきたい。 >>275
https://paiza.io/projects/qaPwuRKbL8hEk-wHDWIqXg?language=python3
import requests
urls = [
('https://mevius.5ch.net/tech/dat/', 8),
('https://mevius.5ch.net/tech/dat/1693451813.dat', 54),
('https://mevius.5ch.net/test/read.cgi/tech/1693451813/', 45)]
for (url, l) in urls:
resp = requests.get(url)
ct = resp.headers['Content-Type']
print(f"{url} : {ct}")
tx = resp.text[-l:]
print(f"{tx.encode('latin1') if ct == 'text/plain' else tx}")
↓
https://mevius.5ch.net/tech/dat/ : text/html
</html>
https://mevius.5ch.net/tech/dat/1693451813.dat : text/plain
b'\x8e\xa9\x95\xaa\x82\xc5\x92\xb2\x82\xd7\x82\xeb <br> https://mevius.5ch.net/tech/dat/ <>\n'
https://mevius.5ch.net/test/read.cgi/tech/1693451813/ : text/html; charset=Shift_JIS
５ちゃんねる<br><br><br><br></footer></body></html>
ほんとうにありがとうございました メモリ関係に自信があるわりにはFirefoxでamebaTVを見ると
メモリリークが発生して落ちる件、修正されませんよね
かれこれ一ヶ月くらい経過するのに それはamebaTVの問題やろ
プロファイリングしろ JavaScript処理系の問題と区別できないレベルの
人がいるんだ Rustを庇うつもりはないが総本山のfirefoxでも
RustよりC/C++の方がステップ数は多いんだよ
更に言うとJavaScriptのステップ数はもっと多い
Rustが原因とは限らない スレタイはC++とRustなのに、何故かGoとかJavaScript等とRustの話にすり変わってC++が影に隠れてしまう不思議。 このスレのスレタイは「Rustレスバ会場 ワ無し」だよ C++派だが、別にいいんだ
氏んでもRust使わないってまで言ってないんだ、動向は気になるにきまってるので AVX512で行列ライブラリ開発するのは止めたわ。発熱がでかくて使えば使うほど性能が低下して全然安定しない。1000×1000の行列積なんてシングルスレッドで100回平均で0.034秒だったのが10000回平均だと0.039秒まで落ちる。 スレチだが、AVX512がすべての命令に対応しているわけじゃないし発熱は命令のせいじゃないしSIMDの話で急にスレッドの話が出てくるのも意味不明だし
一行にバグ詰め込みすぎだろｗ >>287
reqwestのbodyがStringか&'static strを要求するのは
非同期処理が終わるまで送信データが存在することを保証するためだろうから
blockingで処理が終わるまでStringが存在することを外から保証できるなら
&str（&String.as_str()）を&'static strにtransmuteすればbodyに使えるはず
本当に安全かは分からん >>287
現実の使われ方はどちらかしかない
(1)毎回値が変わる
値が変わるのだからStringを使えばよくて値が変わるのだからcloneは出て来ない
(2)毎回値が同じ
値がずっと同じならば&'static strを使えばよくてcloneは出て来ない
後者にする場合の具体的なコード変更点はこうなる
let j: String = 略;
let j: &'static str = j.leak();
for _i in 0..2 {
test_client(j)?;
ずっと同じ値を使い続けるならリークさせてもよいわけでStringを&'static strへ安全に変換できる
あとは呼び出し関数側も&'static strに変える
fn test_client(j: &'static str) -> Result<(), Box<dyn Error>> { >>288
プログラムとしては正常に動作してるんだよ。これは出力結果をテストして確認もしている。ただ、AVX256に比べてCPUの温度変化を監視すると明らかに温度上昇が確認されるんだよね。自分のPCがそろそろ3年目に突入するってのもあるかもしれないけど、明らかにCPUに良くない影響を及ぼしてる兆候は確認できたし。実際AVX256ベースのプログラムにすると10000回1000×1000の行列積を回してもほとんど100回平均の時と平均実行時間に差がなかった。 IntelのAVX256ベースに絞ればRustの安定版でも行列ライブラリが開発できそうではあるので、AVX512に対応するかいなかは結構重要な分岐なんですよ。まあ、Armのsimd命令拡張セットにはRustは安定版では対応してないし。AMDに関してはx86アーキテクチャだった気がするのでもしかしたらRustの安定版でも行けるかもしれんけど。 >>294
前スレ969ですか？
>mojoを持ちつつPythonを嗜み 次のようなトレードオフが異なります。
(1) プリプロセッサ(Cプリプロセッサ、Lex / YACなど)は、おそらく最も重い扱いです。それらは完全に一般的ですが、開発者の経験とツールの統合の点で最悪です。
(2) 一部の言語(LispやRustなど)は、マクロ拡張機能をサポートしており(時には「衛生的」)、構文の拡張と定型的な削減を可能にし、ツールの統合をいくらか改善します。
(3) C ++のようないくつかの古い言語には、ランタイム言語のデュアルである非常に大きく複雑なメタプログラミング言語(テンプレート)があります。これらは習得が著しく難しく、コンパイル時間とエラーメッセージが不十分です。 >>296
ChatGPTやん
やっぱ複オジと似てるよな 複オジ節
・当たり障りのない事
・周知の客観的事実
・一解釈、不確かな一説
・自説、自分の思い込み
・流布したい嘘
が全て断言調なところ
徐々に自説、嘘を織り込んで行く、
絶対儲かりますと畳み込む詐欺師と区別がつかない
最悪そのものかも知れない
なお上記は複オジ節で書かれている、テンプレ推奨 >>301
faqかなんか？原文かURL おねがいしてイイかぬ これも貼っておきます
We’ve raised $100M to fix AI infrastructure for the world's developers
August 24, 2023
Modular Team
https://www.modular.com/blog/weve-raised-100m-to-fix-ai-infrastructure-for-the-worlds-developers
>led by General Catalyst and filled by existing investors GV (Google Ventures), SV Angel, Greylock, and Factory.
modularは$130m集めた責任ある企業だから嘘大げさはやらないよネ! 最新ですね
https://docs.modular.com/mojo/why-mojo.html#a-member-of-the-python-family
>We also benefit from tremendous lessons learned from other languages
>(such as Rust, Swift, Julia, Zig, Nim, etc.) トランスパイラは夢がある Cに変換されるやつは人間も読みやすく現実的 >>298
>>300
mojo公式に対して複オジ呼ばわりワロタ 翻訳のクソ度がよく似てたんだろ
機械翻訳でももう少しまともなのあるだろうに https://docs.modular.com/mojo/notebooks/Matmul.html
> 180.14895626059092 GFLOP/s, a 77052.192096131941 x speedup over Python
行列積のGFLOPS数値があるけど
>>272,286の感想は？ >>314
このベンチマークはシングルコアではないよね？多分4コア8スレッドとかそんな感じ？
手元のOpenBLASはシングルスレッド計測だと大体60GFLOPSだったよ。自分がAVX512でやってるやつもは65GFLOPS。AVX512なんで、もう少しチューニングすればマックスで80とか90GFLOPSまでは期待できるかもしれない。 >>315
あと、あくまでもシングルスレッドでのGFLOPSであることには留意してね。 >>314は単精度
>>315は倍精度で出している？ >>318
やはり
単精度マルチスレッドでやると分かるけど
mojoであってもちょっと書いたくらいでは
凄く遅いという事ね
こちらはnumpy openblasで1020GFLOPS位
mojoは150GFLOPS位だった 単精度シングルスレッドは
numpyで140GFLOPS位、mojoは40GFLOPS位だったかな
(どっちも1000x1000 float32)
もともと遅いしマルチスレッドの伸びも良くない印象だった
>>315のシングルスレッドは単精度に引き直すと
結構頑張っていると思う Zigもありなんだけどバージョン1.0予定の2025年も遅れるだろうし
便利なC言語という需要がどこまであるのかわからん
正反対な方向のZigとRustだが企業がZigを選ぶのはレアケースだろう >>320
AVX512というチートに手を染めててこのGFLOPSは個人的には不満。ただ、自分のノートパソコンのzmmレジスタが16本しかなくて制約がキツすぎて困ってる。512bit長のsimdであればレジスタは最低でも32本は欲しい。16本だとパイプラインハザードの回避がかなりキツイ上ロード命令と置換命令に対して十分に演算命令を積めないのでかなり苦労している。というかAVX512をレジスタ16本はキツイのでAVX256の方で普通にOpenBLASを目指そうかどうかを検討している。 >>323
zmm レジスタは 32本有るはずだが。 激震のためRust製のゲームエンジンAmethystが注目されてるらしい
https://amethyst.rs/
激震
基本無料のソシャゲ終了のお知らせ。Unity「インストールするならお金払ってね。リセマラも都度料金徴収するから」
https://greta.5ch.net/test/read.cgi/poverty/1694588878/
全ゲーム業界に暗雲 「UNITY税」が始まる事を受け販売中のゲームを削除するとアナウンスするメーカーが出始める
https://greta.5ch.net/test/read.cgi/poverty/1694620134/ ふと試したBLISが良い感じ
単精度
OpenBLAS: 1.940ms 1030.853 GFLOP/s
BLIS: 1.983ms 1008.616 GFLOP/s
MKL: 2.654ms 753.593 GFLOP/s
倍精度
OpenBLAS: 4.139ms 483.190 GFLOP/s
BLIS: 3.584ms 557.981 GFLOP/s
MKL: 4.818ms 415.121 GFLOP/s
MKL倍精度は100回毎のサブ平均が350~550で安定していなかった
MKL単精度は安定して遅かった
OpenBLASとBLISが安定して速かった
(1000x1000 10000回平均 マルチスレッド AVX2)
>>323
AVX512はチートと言う程じゃないけど普及度はかなり下がるね >>325
Amethystはだいぶ前に開発止まったはず
アンチOSSの人はこういう激震が好きなんだろうか いい機会なので復活したりするのかもね
https://github.com/amethyst/amethyst
まあ、びっくりしたUnity側が条件変えてくるでしょ
金を生まないインスタンスが想像以上に多いらしい 希望的観測を語るのは勝手にすればいいが
実際に注目を集めているのはGodotとUnrealなのであった >>324
何か調べると自分のPCは16本っぽい。何か最初期のPCはZMMレジスタが32本あったんだけど、途中から発熱のせいで16本になって今ではサーバー用のやつ以外は基本16本って何かに書いてあった気がする。これは勘違い？ >>330
一応、EVEX prefix では 32 種類の zmm レジスタ
を区別できるようにはなっているが。 この記事ではシリコンダイ上の実体(レジスタファイル)は(1コアあたり)152(144+8)個みたいだよ
https://chipsandcheese.com/2022/06/07/sunny-cove-intels-lost-generation/
AVX512FのISA上で名前で呼び分けるのが32個(zmm0~zmm31)で実行のスケジュール段階で
144個のレジスタファイルに上手く割り振りながらアウトオブオーダー実行しているイメージです
>>323,330
>何か調べると
これの方が興味あるので差し支えなければリンクを... zmmレジスタが16本しかないやつは極一部のやつらしい。確認したら自分のPCは32本あった。
ところで、zmm0レジスタにdouble型がロードされてるときこれの2番目の要素をzmm1レジスタにブロードキャストすんのって最低でどれくらいのレイテンシーがいるか教えて欲しい。IntelのSimd命令マニュアルとにらめっこしながらやってるけど、命令の内容があまり書いてないので結構困ってる。レイテンシーとかは書いてあるけど。 >>326の計測に使ったblasバインディングがgemmとgemvしか参照していなかったので
行列積素朴実装をgemmの形にしてdllにしたらそのまま計測出来た(gemvは呼び出されていなかった)
f32 NAIVE
ST
3484.623ms 0.616 GFLOP/s
3540.897ms 0.606 GFLOP/s
3567.409ms 0.602 GFLOP/s
MT
178.104ms 12.057 GFLOP/s
178.895ms 12.004 GFLOP/s
177.376ms 12.107 GFLOP/s
f32 tile
ST
31.727ms 67.686 GFLOP/s
32.086ms 66.930 GFLOP/s
32.020ms 67.067 GFLOP/s
MT
4.042ms 531.307 GFLOP/s
3.924ms 547.233 GFLOP/s
4.065ms 528.281 GFLOP/s
f32 BLIS 目標 アーキテクチャ毎にほぼアセンブリで実装されている
ST
14.917ms 143.966 GFLOP/s
14.987ms 143.289 GFLOP/s
15.051ms 142.680 GFLOP/s
MT
2.120ms 1012.808 GFLOP/s
2.145ms 1001.183 GFLOP/s
2.108ms 1018.784 GFLOP/s f64 NAIVE
ST
4072.215ms 0.527 GFLOP/s
3965.081ms 0.542 GFLOP/s
4069.991ms 0.528 GFLOP/s
MT
284.921ms 7.537 GFLOP/s
297.872ms 7.209 GFLOP/s
271.956ms 7.896 GFLOP/s
f64 tile
ST
72.745ms 29.521 GFLOP/s
72.666ms 29.553 GFLOP/s
72.857ms 29.475 GFLOP/s
MT
9.442ms 227.445 GFLOP/s
9.547ms 224.928 GFLOP/s
9.739ms 220.504 GFLOP/s
f64 BLIS
ST
30.461ms 70.500 GFLOP/s
30.418ms 70.600 GFLOP/s
30.343ms 70.773 GFLOP/s
MT
3.896ms 551.148 GFLOP/s
3.812ms 563.403 GFLOP/s
3.924ms 547.277 GFLOP/s
1024x1024 10回平均
c=a*bのa,bは使いまわし 変数cはループ外で初期化してあるけど 都度既存メモリ破棄、新規アロケート、ゼロ初期化されていた gemm自体はアロケート済みのcを受け取るだけなので
簡潔に書いてもcメモリの使いまわしが出来る仕組みが欲しい
端数処理をしてない手抜きTileなので1024x1024でやった
>>333
楽しめるかどうかですね
こちらはどうなることやら 64x64 Tile導入時点でコンパイラがAVX2を多用したコードを自動出力した
なんかマルチスレッドの力で押し切るのが手軽
f32はGPUで
f64は個人向けGPUは遅いからCPU多コアかな 野望の段階だけど、Strassenのアルゴリズムとかの行列積高速化のアルゴリズムを効率良く組みたい。再帰的なアルゴリズムは現状のCPUの構造だとかなり難しいんだよね。
今はCだけど、できれば最終的にRustで組みたい。RustのメモリリークやSegmantation fault, メモリの2重解放がないのはスゴい利点だとと思う。今後OSなどの最深部でも行列積の計算が頻繁に呼び出されるようになるだろうからなおのことRustで目標を達成したい。 行列とカーネルを同じ文に書かれると違うほうのカーネルにしか読めん 結論とて現在のRustは糞
来世に期待ってことだよな どんな紙切れでも金塊以上の価値になれる
その結果Youは乱れ万人に対する加害者になっちゃうわな >>341
脈絡なく「結論」とか言っちゃう症状って生まれ変わるまで治らないの？
若いうちならトレーニングで治せそうだけど年取ると無理なのかな >>341
うむ。
zmmレジスタやSIMDの話題もRustに不利な事を
書き込まれたから誤魔化そうとしているのだろうね。 >>339
AIがOSに組み込まれるようになるので死ぬほど行列積の関数は呼び出されるようになると思う。 スタートレックの世界のコンピュータを目指すならOSに組み込まれるかもね
でもそれはまだ先の話だろう SIMDなんて非常に簡単で素朴なコードがかけるのに
有利不利なんてないだろ そのわりにベンチで差が出る(らしい
スレ的には、いかに上手に・素直にスタブを記述できるかだね >>347
OSにAIが標準装備されるとしても
何でそれをカーネル空間で動かさなきゃならんという話になるのかが分からん >>347
win11にWindows Copilotを搭載することが決定してるので そう先の話でわネエと思いますケドぬ まぁ ドコまでローカルホストでガリガリやらすかまでわ 分からんケドぬ >>348
それはアセンブラを直接たたくってこたかな？それって生のポインタをさわることになるからRustの目指す安全性とは結構離れてるよな。第一、データがレジスタのサイズにあわせてアライメントされてないとバグるけど、Rustではアライメントを揃えるのすらunsafe扱いだから。simdを組み込みにするのは果てしなく大変なのでは？全てunsafeにして生のポインタを引数にとるなら話は別だけど。それではもはやRustを使う意味がないし。 >>352
理解できてなさすぎ
Rustは標準ライブラリがunsafeまみれなように
いくらでもunsafeを使ってもいいんだよ
そのうえでsafeな部分を作り出せればそこはRustコンパイラによる保証がつく
だからRustだけがアドバンテージを持つ >>353
理解してると思うよ
煽られてるんだよw 行列ライブラリはぶっちゃけRUSTの運営が直接本来実装するべきなんだよね。ものすごい数の安全テストが必要だから。Rustの標準ライブラリのRCはそうやって安全性を担保してるからな。ただRustの質を担保するならRCよりも遥かに安全テストが必要になるとは思う。 blasやlapackのラッパー書けば良いのでは? もうRustの失敗を踏まえた新しい言語の登場を待とうぜ >>357
blasやlapackの中は干からびるくらいに枯れてるやろ Rustの目指す安全性ってのと真逆の意味をもつunsafe宣言は
「ここは確率的にunsafeだけど確率を覆すのが人間の仕事」と言ってる
だから確率とか好きそうな人には難しい >>360
unsafeのところは人間が死ぬ気でテストして安全性を担保してねって意味合いが強いけどな。だからRCとかARCはとてつもなく厳重なテストを行ったらしい。 >>359
誰もOSの最深部で使いまわしたけーすなんてないからどんなエラーがでるかは未知の領域だろ。 >>361
テストの戦力を集中できるから合理的なわけだが
当たりくじだけを買う集中ではなく逆にはずれそうな箇所に手間をかける Rustではそういう小さなパーツのみ人間が安全性を保証するunsafeを用い
プログラム全体はコンパイラが静的に安全性を保証する形となって開発効率が良い C/C++はプログラム全体がunsafeだから
プログラム全体に対して人間が安全性を保証しなければならず開発効率がよくない コードチェッカとしてAIが搭載されるので
現実的な必要性がなくなると思うよ >>374
ご指摘の通り今のレベルではコードチェッカとしては信用できない AIチェッカはヒントにはなっても証明にはならんやろ unsafe{ } を型の内で定義できるのがC++っぽいかなって最近思ってる >>365
Rustの仕組みで生ポやアドレスに触るような関数やライブラリの安全性の担保は死ぬ程だるいということですよ。実際sind系のクレートが全然安定版にならないのはそれが原因だからね。RCやARCとは桁が違うレベルの安全テストを行わないといけないようだからね。 >>363
使い回されるだろう。stable diffusionとかlammaとかがヌルヌル動くようなPCスペックが標準になってきたらEXCELやパワポとか、DirectXに組み込まれるだろうな。 >>380
カーネルモードという言葉を知ってる？
他の人はそういう話してるけど コードは公開するが教師データは墓まで持っていく手口はOSSに対抗する側の発想なので
GNU/Linuxと合体する確率は低い >>380
OSの最深部って話をしてるのになんでアプリケーションの話をしてるの？
低レイヤとか高レイヤとかわからない人? >>376
具体的にいつですか？
具体的とかそんなの無い感じですか？ >>382
OSS最大手のRedhatはそんな感じ Rust製のFirefoxがCPU100％張り付きとかメモリ60GBとか普通にやってくれるやつなので
Rustも宣伝通りの安全性だとは思っていない >>387
FirefoxにはC++のコードの方が多いし
ピュアRustでもcpu100%やメモリ浪費アプリの
解消なんて謳ってないので意味不明 >>387
Rustでも安全にセキュリティーホールやウィルスを書けるよ 宣伝通りではない問題は普遍的な問題
沈黙は金
雄弁は宣伝通りではない RustもFirefoxもMozillaの製品だし
どっちも眉唾程度に使ってる Mozillaのサイトには豊かな生活とか健全なインターネッツとか
アベノミクスの宣伝とだいたい同じことが書いてある >>392
内容を反省しても無駄
完璧な内容に改善しても雄弁は最善手になれない >>391
それは昔の話
3年前にMicrosoft・Google・Amazonなど共同によるRust Foundationが設立されてRustはその資金で開発されている >>397
と書くとその資金でサラリーを得る開発者を雇用しているようにも聞こえるが
Rust自体の開発をしている人って専業はほとんどいないのでは? 念の為だがOSSを批判してるんじゃないよ
>>397の認識が違うんじゃないかなってことを言いたくて
資金入れようが入れまいが開発には大して影響ない体制ではないのかな? >>398
専業と兼業がいる
Rust Foundationの昨年の年間レポートによるとfull-timeは7名 >>398
専業と兼業がいる
Rust Foundationの昨年の年間レポートによるとfull-timeは7名 Microsoft・Google・Amazonが資金を入れなかったら
その7名は雇用できないんだろうけど
7名なら兼業で賄えるだろうから大して影響ない体制とも言える transpose関数でデータを並べかえるのって割りと時間が掛かるんだよな。simd化しても並べ替えの部分でかなり時間が取られるからあまり高速にならないし。マルチスレッド化すれば確実に一定の高速化はできるが。 どっちも元々始まらなかっただろ。かつては一世を風靡したが今は終わコンになったPerlやPHPとは違い、
不発のまま忘れ去られる。 >>408
>かつては一世を風靡したが今は終わコンになったPerlやPHPとは違い、
あれ?!終わったの?
今は何に取って代わられた? これ
Rustの非同期ライブラリをPHPから利用可能にする「php-tokio」が登場 遺憾なことにphpはwordpressやらLaravelやらで今も使われてる
phpは脆弱性の宝庫 Cで開発してるとわかるけど、Cの大規模なプロジェクトは確実にメモリリークだらけになってるな。関数が内部で勝手にメモリを、確保してreturnしてるやつとか他人の作った関数だったらメモリの解放忘れること多いんじゃね？この手の部分はRUSTは神って思うことすらある。
ただ、RustはCに比べて一部の最適化オプションの性能がかなり落ちるな。多分、配列とかの境界チェックをアセンブリレベルで行ってるんだろうな。 配列はインデックスでアクセスすると他の多くの言語と同様にインデックス範囲内チェックをアクセス毎にする
しかしC言語でのポインタアクセスと同様にRustでもポインタ(参照)でシーケンシャルアクセスすればポインタ終了条件の比較のみとなりC言語と同じ速さになる >>411
PHP5系の配列の扱いはトラウマものだったわ。 Rustを踏み台にして、もっとスタックフレーム指向の言語が出てきて欲しいわな。
スタックis god, 再帰構造is god. rust自体に非はない。
「全部rustになる」みたいなことを真面目な顔して言ってた人がいた、ただそれだけの話。 >>416
再帰的なプログラムってCPUの構造的に効率化は厳しいのでは？ >>417
組込み系はZigあたりがバランス良さそうだが、issueのオープンがクローズの2倍で増えてるみたいだからまだまだまだだわ。 >>418
たとえば弱者の人権自体を否定するメリットは少ない
弱者のふりをする者の権利を嫌いということにして
もし自分が追い詰められれば本当の弱者なので人権は嫌いではない
これはメリットが大きい 元web屋で、最近マイコン開発始めて、作ったハードウェア売ろうかなと思ってたんだが、c++とRUSTどっち勉強するのおすすめ？
やっぱ資産がある分まだc++？
Rustはまだ浸透してない感がある >>422
トヨタとかはRustで開発してるって聞くが。
専門家ではないがC++よりもCの方が良いのでは？Linuxは確かC++拒否ってるって聞くし。 実用と道楽の対立が何の役に立つのかといえば
財政が破綻している者はunsafeだと言う人もいる、ただそれだけ >>405
スレチだが、転置行列を作る程度であれば、
x86 の SIMD だと、vector index の VSIB
を使えば効率よく出来るはず。 >>422
組み込みは、メモリー管理を自分で簡単に
理解して簡単に間違いなく出来るくらいの
実力があることが前提なのでCかC++で十分。
Rustは基本的にミスが多くて簡単にはそれが
出来ない人向け。 組み込み屋ならアセンブラくらいできるやろ
Rust使いたくならんかもな Cの方が早いかもしれないが、実用上その差なんて気にならないし問題になったことはない
ベンチマークの数値みてニヤニヤしてる人たちだけが遅いと言ってる
無視してOK I/Oポートの制御などや指定されたアドレスのメモリ
への書き込みは、JavaよりCの方が分かり易いから
Javaを使うほうがメンドクサイ。 I/Oポートの制御などや指定されたアドレスのメモリ
への書き込みは、JavaよりCの方が分かり易いから
Javaを使うほうがメンドクサイ。 >>427
手元にはx86_64系のCPUしかない。 >>427
手元にはx86_64系のCPUしかない。 >>427
手元にはx86_64系のCPUしかない。 まともなOSがない環境ってコンパイラよりインタプリタが実用的なのでは？
OSがなければコンパイラもないでしょ
ブラウザにたとえるととjsのインタプリタは確実にある
wasmのコンパイラは一体どこにあるのか微妙な感じ How many files(0-15)?
NEC N-88 BASIC Version 2.1
Copyright (C) 1981 by Microsoft
56543 Bytes free
Ok >>438
GCCは別にフリースタンディング環境だってサポートしてるぞ。
それともお前の言うインタプリタはGCCより広範囲に組込み環境サポートしてんの？ ある言語がオワコンかどうかいつも言い争ってるのは
gccがサポートしなくなりサポートの範囲が狭くなる場合があるのが大前提じゃないの >>419
CPUでの効率化が難しいというのはCPU処理との類似性が高いということでもあって、表記がそのまま処理になるということでもある。なので、効率化できないのなら効率化できるように表記を拡張すればいい。
再帰プログラムの効率で良く問題になるのは末尾再帰だけど、これも関数内でしか関数を呼び出すことのできない関数表記の限界であって、表記を拡張すれば解決できる。例えば関数を抜けてから関数を呼び出すように拡張したreturnを用意するとか。 >>442
キャッシュの仕組み的に再帰的なアルゴリズムだと次に使うメモリのプリフェッチがムズくね？それが簡単だらすべての行列積のアルゴリズムがStrassenとかもっと効率の良いアルゴリズムで書かれてるはずだと思うんだけど。
再帰的なアルゴリズムでキャッシュ効率を上げるのはかなり難しいというのが自分の認識だけど。 その人はまともなことを組み合わせて間違ったことを言う人だから無視していいよ
多分認知症なんだと思うよ
再帰の最適化の話分かってない まあ組み込みや数値計算ガリガリやってるところからしたら、
そのライブラリを使う上の方のレイヤーでは役に立つんかもね？くらいのものだろ。 >>445
行列ライブラリなんてアセンブリだらけだし、そういうことなら分からなくもないが。でも、だとしたら行列ライブラリを開発してる側からすると安易に「効率化」って言葉を使ってほしくはないな。 Rustは、SNS見てると、一部の有名インフルエンサー的な
人が普及させようと頑張っていて、彼を信じる沢山の
フォロワーが信じてるのでイイネを押しているみたいだ。
しかし、自分の意見を持っているかどうかは不明。 自分の意見なんて
うどんを食べるかラーメンを食べるか選ぶ程度の単純作業でしかない
けど、どっちが選ばれるか全然予測できなくて
人間はもっと機械のように予測可能であるべきだとか思ってるマッドサイエンティストもいる そもそも論としてコンピュータサイエンス系の発言ばかりを
しているアカウントのフォロワーは独特の価値観を持つ人だ。
それはコンピュータ雑誌を買う層ともまた違う。
なぜなら雑誌ほど勉強に成るような発言をしているわけではないからだ。
独特のおっかけみたいなことなんだろうか。 プログラミングがもともと得意な人はそんな人をフォローするとは
考えにくくて、プログラミングにあこがれているが力及ばず
のような人がフォローしてるのではなかろうか。 どんなひとのこと書いてるのかしらんが
art（技術）とscienceは区別されるからね コンピュータサイエンスの科学者にあこがれる人の気が知れない。
そこまで凄いことして無いと思うし。 javaは長文の文法が多い
コーディング量が増えて苦痛 >>452
連中わまるでＩＴ業者の太鼓持ちみてえだよぬ PHPで開発していたWEBサービスをRustに乗り換えてみた
https://zenn.dev/uiuifree/articles/4a52d8d21f0a1a
PHPと比べメモリ消費量が低く、OOM Killerが発生しがちでメモリ設定を上げていた部分の処理だと、3分の1程度に抑えられてバッチの実行時間は1時間程度かかっていたものが数分で終わるまで改善できています。
自社開発で長期的なプロダクトに関しては、もうRust一択で採用予定 >>447
日本でRustを必死に普及させようとしてる勢力って何者なんだろうな 知らんのか？
宇宙人とアメリカ政府との密約によって
進められてる コンパイル時間短縮にツヨツヨＰＣが必要らすいので プロセッサベンダからの案件でガンバってるヒト居てるのかぬとわ思いましたケドぬ むしろ普及しないと信じたい奴らは何者なんだと思う
エンジニア風おじいちゃん炒めかな rustってC++のstd_ptrだっけ、所有権つきのスマートポインタ
あれを言語に組み込んだって感じか ああ機械音痴だからこそ代替手段として人間を機械扱いしてしまうのかもね >>456
WebでRust使いたがるバカってなんでこういうレベル低いのにいきってる奴が多いんだろうね
そもそもメモリなんて潤沢にあるんだから全て使えばいいだけだし、バッチでOOMになるとかは明らかに作り方が問題なんだろ
適切にストリーム処理してるの？ > バッチの実行時間は1時間程度かかっていたものが数分で終わるまで改善できています
？？？
それは能力不足でクソコード書いてたのが問題でRustのおかげで改善されたわけではないだろ Rust叩いてるやつは>>464のように常識を知らないやつが多いな
メモリ使用量が1/3になったと書かれてるのだから仮にクラウドを使うならば料金が1/3になるってことだ
実行時間も1/10くらいになっているようだからメモリと合わせて料金が1/30になる
スクリプト言語からRust化はその例のようにリソースコストを大きく下げる絶大な効果を伴うことが多い
メモリ使用1/3と実行時間1/10なら普通にありうるケースだ まあ、様子見てる感じだとweb屋が一番Rustを積極的に取り込んでる気がする。組み込み系はまだそんなでもないな。RustはAWSのLambdaとか有名だけどweb系と相性が良いのかもな。 >>465
Webサーバーのバッチ処理だとしたら基本DBアクセスの処理が良くなさそうだよな >>466
メモリ以前にCPUの方が普通ボトルネックになるからメモリ使用量が1/3になったら費用も1/3になるってのは嘘だな
クラウド触ったことないでしょ君 >>469
IaaSの一部にそういうケースがありうるだけだぞ
PaaS (FaaS)は基本的にメモリ使用量✕実行時間で料金が決まる
メモリ使用量は少なければ少ないほどコストに優れている >>467
大半は、ほとんどC/C++経験が無い人が多いように見える。
それで言語を変えることで気楽に速度だけ速くしたいと思っているようだ。
しかし、ちゃんと学んでないから実際は気楽ではないことに気付いてない。 Web屋は、Ruby/JS/PHPなどのスクリプト言語とJavaを中心
にやってきて、ほとんどC/C++経験が無いが、C++を学ぼうと
して余りの仕様の膨大さと複雑さに辟易。噂でRustはそれが
改善されたと聞いてそれを真に受けている段階。 今の時代Webも組込みもアプリもゲームもやってる人なんてザラだろ
Webを下に見てるってのはそもそも技術が停滞してる >>470
そのPaaS (FaaS)側に属する料金体系のやつってAWSで言うところのLambdaしか知らんのだけど他になんかある？ >>473
下に見ているのではなく、色んな事知らないのに勝手に
集団幻覚を見ている感じだから。 >>475
だからそれはWeb屋だからってわけじゃなく単にそいつが意識高い系だったってだけ 逆に幻覚を見てないとされる状態の人々の行動も、科学で解明できない >>467
組込み系は本番運用はしてないけど、研究というかいつ本番行ってもいいように個人勉強や社内勉強会はしてるよ。
むしろ全く触れてない奴はヤバいと思う。 キャンセルカルチャーを許さない系は実務経験のない消費者に厳しく
実務経験のある業者を甘やかしてる >>456
Rustの速度を誇るための比較対象っていつも遅いRubyやPHPなどのインタプリタが選ばれてるね
それに対して速くなったとか鼻息荒く言われても…
JavaやC#に対して速度を誇るならともかくさ >>473
ウェブが下なんじゃなくて
ウェブ屋が下
発注したらすぐわかること >>460
Haskellと同じ道を歩んでるように見える 個人的にはHaskellやScalaのような抽象性と完成度でネイティブコンパイル前提の言語が生まれてくれればそれで万々歳なんだがなあ
変に流行って幻滅期入ってそのままの勢いで開発終わっちゃうみたいな展開にだけはならないでほしい >>481
ボトルネックってそういうこと
最も弱いところを変更するのが最も効率的で
元々強そうなところを変更してもほぼ無意味 Cの代替言語としてこんなんもあるでよ。
オーディンとか名前がかっこええで。
https://odin-lang.org/ >>334 単精度アップデート(倍精度は手つかず)
今度はMKLをちゃんと動かせた
ST f32 1024x1024
my-version BLIS OpenBLAS MKL
17.344ms 123.816 GFLOPS 15.241ms 140.902 GFLOPS 15.166ms 141.598 GFLOPS 14.629ms 146.792 GFLOPS
17.338ms 123.860 GFLOPS 15.217ms 141.119 GFLOPS 15.167ms 141.592 GFLOPS 14.681ms 146.281 GFLOPS
17.805ms 120.610 GFLOPS 15.237ms 140.939 GFLOPS 15.258ms 140.741 GFLOPS 14.843ms 144.678 GFLOPS
17.808ms 120.590 GFLOPS 15.272ms 140.611 GFLOPS 15.186ms 141.410 GFLOPS 14.667ms 146.417 GFLOPS
17.478ms 122.871 GFLOPS 15.310ms 140.264 GFLOPS 15.195ms 141.328 GFLOPS 14.674ms 146.346 GFLOPS
MT 8 f32 1024x1024
2.401ms 894.478 GFLOPS 2.580ms 832.272 GFLOPS 2.514ms 854.201 GFLOPS 2.104ms 1020.428 GFLOPS
2.379ms 902.518 GFLOPS 2.483ms 864.862 GFLOPS 2.702ms 794.853 GFLOPS 2.159ms 994.802 GFLOPS
2.430ms 883.801 GFLOPS 2.539ms 845.796 GFLOPS 2.716ms 790.540 GFLOPS 2.187ms 982.003 GFLOPS
2.407ms 892.147 GFLOPS 2.438ms 880.740 GFLOPS 2.714ms 791.168 GFLOPS 2.160ms 994.223 GFLOPS
2.457ms 874.045 GFLOPS 2.558ms 839.510 GFLOPS 2.524ms 850.976 GFLOPS 2.178ms 985.895 GFLOPS
MT all f32 1024x1024
1.840ms 1167.088 GFLOPS 2.107ms 1019.108 GFLOPS 2.207ms 973.061 GFLOPS 1.647ms 1304.053 GFLOPS
1.926ms 1114.813 GFLOPS 2.133ms 1006.937 GFLOPS 2.145ms 1001.273 GFLOPS 1.603ms 1339.395 GFLOPS
1.793ms 1197.473 GFLOPS 2.092ms 1026.416 GFLOPS 2.250ms 954.622 GFLOPS 1.631ms 1316.506 GFLOPS
1.800ms 1192.852 GFLOPS 2.130ms 1008.175 GFLOPS 2.160ms 994.287 GFLOPS 1.557ms 1379.502 GFLOPS
1.920ms 1118.594 GFLOPS 2.111ms 1017.376 GFLOPS 2.239ms 959.290 GFLOPS 1.566ms 1371.030 GFLOPS ST f32 2048x2048
my-version BLIS OpenBLAS MKL
143.172ms 119.995 GFLOPS 124.520ms 137.969 GFLOPS 122.140ms 140.658 GFLOPS 119.337ms 143.961 GFLOPS
144.436ms 118.945 GFLOPS 120.322ms 142.783 GFLOPS 120.386ms 142.706 GFLOPS 119.637ms 143.600 GFLOPS
142.295ms 120.735 GFLOPS 122.022ms 140.793 GFLOPS 120.581ms 142.475 GFLOPS 121.497ms 141.402 GFLOPS
142.093ms 120.906 GFLOPS 120.663ms 142.379 GFLOPS 121.417ms 141.495 GFLOPS 119.854ms 143.340 GFLOPS
143.167ms 119.999 GFLOPS 121.259ms 141.679 GFLOPS 120.834ms 142.177 GFLOPS 120.555ms 142.506 GFLOPS
MT 8 f32 2048x2048
19.379ms 886.539 GFLOPS 17.746ms 968.111 GFLOPS 17.882ms 960.746 GFLOPS 16.607ms 1034.490 GFLOPS
19.807ms 867.366 GFLOPS 17.821ms 964.021 GFLOPS 18.352ms 936.151 GFLOPS 16.314ms 1053.091 GFLOPS
19.229ms 893.456 GFLOPS 17.420ms 986.209 GFLOPS 17.945ms 957.382 GFLOPS 16.612ms 1034.212 GFLOPS
19.296ms 890.326 GFLOPS 17.633ms 974.310 GFLOPS 18.528ms 927.239 GFLOPS 16.911ms 1015.907 GFLOPS
19.207ms 894.455 GFLOPS 17.719ms 969.594 GFLOPS 18.413ms 933.043 GFLOPS 16.579ms 1036.243 GFLOPS
MT all f32 2048x2048
13.975ms 1229.316 GFLOPS 13.372ms 1284.765 GFLOPS 14.273ms 1203.695 GFLOPS 11.874ms 1446.832 GFLOPS
13.771ms 1247.523 GFLOPS 13.483ms 1274.182 GFLOPS 14.315ms 1200.149 GFLOPS 12.079ms 1422.249 GFLOPS
13.655ms 1258.142 GFLOPS 13.475ms 1274.910 GFLOPS 14.323ms 1199.435 GFLOPS 11.779ms 1458.571 GFLOPS
13.782ms 1246.555 GFLOPS 13.492ms 1273.329 GFLOPS 14.402ms 1192.845 GFLOPS 11.970ms 1435.262 GFLOPS
13.609ms 1262.422 GFLOPS 13.556ms 1267.336 GFLOPS 14.281ms 1202.959 GFLOPS 11.815ms 1454.082 GFLOPS
各行100回平均
ちゃんと動いたMKLがめちゃくちゃ速い! >>446
(1000x1000ではなく) 1024x1024や2048x2048みたいな行列サイズの場合が
キャッシュの急所を突いてくるので、前後サイズ比で遅くなっていないか確認して見て下さい
(検索して出て来たのが不自然に960で計測していて、1024にしたら2～3割落ちになるケースがあったので)
実装方法、行列のメモリレイアウトやCPU次第で1024じゃないかもしれないのでそれも要注意です 速度とかおまけなの
webは生産性が全て
だからRustなの SNSで、同じ人が同じくRustに関して書いた場合でも、
それがWindows向けの話題になると急に いいね が
減る傾向があるらしい。
つまりは、そういうことである。RustはWindowsアプリ
を作ろうとする人に人気が有るわけではないということだ。 論破するためって目的達成が簡単すぎるところが
達成不可能な過酷なノルマで追い込むような価値観をキャンセルするのに使えそう ５ちゃんで論破デキるようになるよぬって コーディング学習において モチベになりうるんだろーかぬ 違和感がモチベーションの人いるでしょ
OOPや非同期APIの違和感 漠然とRustの話題に イイネ を付けているだけで、
「Windows向け」という具体性を持たせると急に減る
ということなのかもしれないな。
しかし、スマホ向けアプリなんてゲーム以外で食っていく
ことは非常に難しいからアプリと言えば、Windowsで
あるはずなのだが。Webアプリは、本格プログラムが必要である
典型であるECサイトなんて日本で数えるほどしかないわけだし。 EC サイトを発注する奴は、情弱
Ruby on Rails 製のShopify なんか、ほぼ無料みたいなもの >>491
自分は行列ライブラリを作ってるけど、確かに2の累乗にすると性能がガクンと落ちる。正直理由はわからん。 >>501
cache bank conflict AVX512で行列ライブラリを実装してると転置コピー関数の速度の存在感が大きくなってくるな。この現象はAVX256だとあまり感じられないと思う。行列積の実行速度事態がまだまだ遅いからね。 簡単に調査してみたら、SNSで、
JavaScript Html などのキーワードが入っている投稿は
いいね が付き易い傾向が有るらしいが、Rustも似ている。
(実はHaskellも結構、いいね が付き易い。)
これは、Rustというキーワードを検索にかけている人が
多い事を意味している。 ＞＞0504
ウェブ系の人が使ってるだけじゃないの JavaScriptやRubyなどは初心者や凡人にも使いやすい言語
だと言われているので、それらからRustに全員が乗り換え
られるとはとても思えない。
逆にC++を使いこなしている人がRustに移行する理由も
余り無いどころか、むしろ利用範囲が狭まってしまう。 AIやりたいからpythonやろう! とか
そういうインセンティブがRustにはほとんど全く働かない >>508
モチベーションはインセンティブが働いた結果生じる デスクトップアプリ作りたいからrust、はある
トレンドがelectronからtauriに変わってきてるので >トレンドがelectronからtauriに変わってきてるので
トレンドはelectronからwebviewであって
tauriはwebviewを使ってる有象無象の一つでしかない
現実を見ろ >>510
いつのまにtauriはelectron競合までサポート範囲広げたの？
Rust専用から脱したのかね。 それとて過渡期でしょ
Rustに言わせればunsafeそのもののWebViewに依拠すんのが筋が悪い
しらんけど
結局ライブラリの揃ってるところに人は たかる >>501
行列ライブラリ作ってるくせにcache slicingも知らねえなら性能語る資格なし vscodeにrust analyzerとかいうの入れたらアホみたいにメモリ食ってクソだと思った
何がRustは省メモリだよ vscodeはTauriではなくElectronだからRustは関係なし
rust-anlyzerはrustcと同一バイナリ >>518
タスクスケジューラでrust-analyzer.exeだけが何もしてないのにただRustプロジェクトを開いただけで4GB食ってるんだが？
他のVSCodeは10Bぐらいが5個ぐらいあるだけだわ
Tauriとかカスだな
Electronと違って実用的なソフトが皆無 rust analyzerがメモリ食うという話なのにRustは関係ないとか頭イカれてますねー 許してやってくれ
彼はこういうことを言われると言い訳探しに必死になっちまうんだ >rust-anlyzerはrustcと同一バイナリ
違うけどｗ Java速いけどな
ダブル配列でトライ木書いたら
Javaのくせに生意気な速度叩き出してきて
ビックらこいたけど >>522
${CARGO_HOME}/binにあるこの14個はハードリンクされた同一実行ファイル
cargo cargo-clippy cargo-fmt cargo-miri clippy-driver rls rust-analyzer rust-gdb rust-gdbgui rust-lldb rustc rustdoc rustfmt rustup
同一のinode番号とハードリンクカウント(=14)が確認できる あーrustup使ってインストールしたときはその辺のコマンドの実体がrustupラッパーになるってだけの話か
間違っちゃいないけど……なあ 言語でどっちがいいだの悪いだの言っても仕方がない
ｃ＋＋の中級者程度が作ったアプリなら、どの言語でも上級者が作ったもののほうが
圧倒的パフォーマンスいいよな リアルタイムなアプリは時間のずれを許さない
銀行にたとえるとお金持ち全員が今すぐ現金を出せと要求してくる
時間をずらしてくれたら必要な現金は少ない可能性はある ガチのリアルタイムは、C++でもRustでもなく、FPGAだって聞いた
あるいはせいぜいGPUか(これは推測 ハードウェアロジックでさえリアルタイムって言うにははばかれるタイムラグがあるからなぁ >>527
全然リアルタイムじゃないじゃんw
そもそも銀行には事前通告無しの引き出し限度額が定められてるから要求自体が通らない
アホくさ >>529
リアルタイムとは実行完了時刻が保証されていることを言う
早い遅いは関係ない 複オジも全く同じこと指摘されてたよね
やっぱり両オジは似たもの同士 >>531
>>528 が言葉足らずで、金融でリアルタイムといえば…って書きたかった
言語でいうなら、VHDLか 書いたことないけど
そういやaliで買った学習用FPGA積んでるの思い出した
やることいっぱい杉 起動が遅いソフトは終了と再起動をしたくないのはわかるが
ファイル編集が終わる前にコンパイルすれば問題解決っていうのが
最高にイカれてる RustがWebで流行ることはない
なぜならもともとWebめCやC++といったコンパイラ型言語ではなくスクリプト言語が流行った最大の理由はコンパイルが遅すぎるから
だからRustは流行らない
爆速コンパイラをまず開発しろ 実アプリ開発だと
静的型付け言語だとコンパイル時に検出できるエラーが
動的型付けスクリプト言語だと大量のテストケースで
検出する必要があって
実行時間が長くて微妙なんだな >>537
んなわけないw
まともにテストケース書いたことないでしょ >>538
それなりの規模のRailsなんかの実サービスの仕事
やるとわかるよ >>538
テストケースは開発者が書くもの。
お前がダメだと思ってる後輩や先輩が全く抜けなく書いてると言いきれる？ 静的型でもdict相当と文字列使いまくる動的脳がいると無力 >>539
いやいやw
Railsアプリで型エラーを検知するためだけのテストを大量に書いてるようならテスト設計がおかしいとしか言えんよ
汎用ライブラリのテストじゃないんだから >>542
あなたはしょうもないヒューマンエラーでランタイムで
落ちても笑ってごめーんで済むような仕事しか
してないか天才なんでミスしませんのどちらかだね ある関数に文字列ではなくオブジェクトを渡したらどうなるか
が問題になるのはオブジェクトがある言語だけ
ちなみに文字列には循環参照がない
循環参照とメモリリークがあるのはオブジェクトだけ >>544
チューリング完全じゃないから、できないことが出てくるだろ。 >>547
まあチューリング完全だとしても、次は
キャズムを超えないから以下同文になるだけだな >>543
いやいやいやwあんたがエアプなだけでしょ
深刻なバグが出れば億単位の損失が出るようなシステムも長くやってたけど型のテストなんて1%もないから 試しにrubyとrailsのテストを調べてみたが型チェックしてるassertの割合はそれぞれ約1.7%と1.5%だった
言語やライブラリでもこの程度の数字 >>550
スレタイ読む前にキミはテストケースのレビューしようね 「ここのオブジェクトはこの型に限る」て感じの設計思想なんじゃね
でもせっかく動的型付けなのに型を限定するのはもったいない気がするけどな 勝手に型チェックの話に限定してるあたり
何も理解してなさそう おまいら契約による設計はちゃんと理解してる？
型チェックの話をするなら必須だからな。 下のコードで実行すると finish が出る順が
最後に completed したものが出て来るまで先に finish してても出て来ません
実際に finish した順通りに表示させるにはどう治せば良い？
use std::thread;
use std::time::Duration;
fn test_thread() -> () {
let mut handles = Vec::new();
for i in 0..5 {
handles.push((i, thread::spawn(move || {
println!("create {}", i);
thread::sleep(Duration::from_millis(400 * (5 - (i - 2) * (i - 2))));
println!("{} completed", i);
})));
}
let mut completed = 0;
for (i, handle) in handles {
handle.join().unwrap();
println!("{} finish", i);
completed += 1;
}
if completed != 5 { panic!("not finish"); }
} >>557
mpsc使うといい
あとデバッグモードだとi - 2がアンダーフローでpanicになる >>413
そんなことないよ
>>428
ほんそれ
>>472
なるほど
>>473
webはどうみても底辺だ >>488
おじん
>>493
win開発者は｢意識他界系｣が少ないのでは >>428
>>561
C/C++ *だけ* じゃ力不足なのはセキュリティ問題考えると明らか。 >>564
組み込みと言っても幅広いが、Lチカの個数を増やしたりモーターに
変えたりしたものを上手く制御するような事が中心に
なる場合は、メモリ管理はRustを使うまでも無い事が多い。
如何に電圧やサーボモーターの信号をコントロールするか、
の話になるのであって、メモリー解放エラーはほとんど関係無い。 まず、インターネットを使うまでもない組み込みに
インターネットをゴリ押しするのが先
セキュリティの話はその後かな >>565
そんな規模の組込みならアセンブラのがいいだろ。 さすがに書き間違いがこわいからCでいいだろ
そんな内容ならC++もRustもオーバスペック
こんなの出てたので ja-jpもできてたけど、品質やら未チェック自己責任
https://learn.microsoft.com/en-us/cpp/code-quality/build-reliable-secure-programs
unsafe{ } がまだなのみならず、歴史が長い分チェックポイントが大量にあるのも、
新風さわやか? なRustが好まれるところではあるんだろうな >>567
組み込みの場合、対象のCPUがころころ変わるからアセンブラは
まあ、無理。
ARM, Atmel, PIC, AKI-H4, NEC製CPU, などなど。 いや、すべての場合において変数に型がないという最大の特徴を見逃すなよ C++のnewやthrowがライブラリではないから
これは要るだろとか要らないだろとかの意思疎通が困難
Rustのnewはただの関数でResultはただの型だがそれが良い >>570
ちゅうか、Cだと変数を1つ増やすだけで済むところが、
アセンブラだと、空きレジスタを見つけるか、なければ、
pushで退避してレジスタに入れてから演算して、などと
結構なことなり、既存のコードの修正も必要にな。
また、Cだと変数の宣言位置を、ローカル変数から
グローバル変数に移すだけで済むところが、
アセンブラだと、結構なコードの修正量になる。 >>574
アセンブラの知識はコーディングに使わないにしても必須だよ
知らんで組込みとかは有りえん 安易にって言った 別人だけど
インラインアセンブラがさいつよ 異論は認める 安易にって言った 別人だけど
インラインアセンブラがさいつよ
ないしはintrinsic 異論は認める つーか、プログラム書くなら低レベルの方がやっぱ楽しいよな
IO直接ブチ叩くのは何十年経っても面白い
目に見えるすべてのコードがだいたい支配下にあるのも気分いい セキュリティの重要性 > コードの楽さ
となるような場面でのみRustは有利かもね。OSとかはできるだけRustにするべきだろうね。最もサイバー攻撃される部分でもあるわけだし。それ以外はRustを使う動機はあまりないか。 所有するとかいう用語はC/C++でも必要なのに最近までなかった
参照するしかないJavaとは違うアレを表現する単語がなかった >>583
ownershipはauto_ptrの太古からすでにあったけど？
こうやって歴史を捏造する詐欺師がいるから、歴史問題は常に嘘つきを殴らないとヤバイ。 >>581
プログラムの楽しさって本来そういうもんだよな。 >>584
Copyを実装した型は値を所有できるかできないか
所有できない値は参照するしかないのか
という疑問が太古から存在していたとは言えないんじゃないか 値にはownerがある原則を!Copyに限定する必要がないので
複製可能な値を所有できる 組み込みmruby の本も出た。
C のポインターでバグらないから安全
福岡の人工衛星、イザナミ・イザナギでも使っている unsafe {
てことは40歳くらい？
会社での立場がはっきりとしてくる年齢だね
うちはそのくらいの歳の無能が新人にすら白い目で見られてるわ
今年の新人には「あの人何してる人なんですか？何も仕事してないみたいなんですけど」って聞かれた
} 命が大事な人達にとって攻撃とは本物の銃を撃つこと
比喩的に殴るのはあくまで話し合いであり表現の自由であり平和的である インフラが次々とRust製になっていってる
＞【CDN世界トップシェアCloudflare】
＞https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
＞CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
＞同社自身がRust製のHTTPプロキシである「Pingora」を開発し利 用していることを明らかにしました。
＞
＞【クラウド世界トップシェアAWS】
＞https://japan.zdnet.com/article/35183866/
＞Rustで構築されたAWSサービスの例としては、
＞コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
＞「Amazon Simple Storage Service（S3）」、
＞「Amazon Elastic Compute Cloud（EC2）」、
＞コンテンツ配信ネットワーク「Amazon CloudFront」、
＞LinuxベースのコンテナーOS「Bottlerocket」などがある。 >>599
もう耳にタコ。
鸚鵡とかインコはかわいいからまだ良いけどさあ タコ耳
https://www.youtube.com/watch?v=us9QbgewnOI
なんで見当違いの宗教闘争延々とやっているんだ
Ａ「九九は便利だ」
Ｂ「九九では足し算引き算に役に立たない」
こんなアホな言い争い続けるのは暇すぎるどころか病院行った方がいい COBOLがなくならないように、C++も、俺が生きてるうちはなくならないだろう
Rustが実績を積んで、その成果がC++に流入するのが待ち遠しい
だから、どうでもいい AVX512を使った行列積の実装はCPU効率50パーセントが大きな壁だな。中々この壁を越えられないな。ただ流石に10月中には完成させたいな。 ていうかfirefoxでさえ全然Rustが使われてないじゃん SNSでRustを検索してみたら、大部分がゲームの方のRust
だった。そして、言語の方のRustでも、いいね は 0 の事
が多かった。その中でなぜか有名インフルエンサの発言
だけはいいねが 100 以上付いていた。
もしかしたら、何らかの組織から金を貰っての
ステルスマーケティングだろうか。
インフルエンサーに金を与えて宣伝といわずに、
宣伝してもらうらしい。 RustはOSやCloudの基盤構築に使うよう言語だろ。基本的にほとんどのプログラマは無縁なままになると思う。
ただ、GoogleやApple, MicrosoftとかAmazonの様にOSやCloudを持ってる会社のエリートにはRustは必要なスキルになるんじゃない？ 近い将来 Rust は改名されると思う
Perl のように >>607
そうはならないと思うな。
ちゃんとした理由があるけど、敢えて書かないが。 >>603
お花畑指向のお爺さんのヒトリゴトw
だから、どうでもいいww RustをやることでRustが必要なエリートエンジニアを気取れる
一般エンジニアがRustに手を出す理由はこれだろうね >>610
すぐ置き換わるという発想の方がよっぽど非現実的。 結局金貰ってRust推しの書き込みしてたんだなあ
なんかいろいろ納得 >>614
すぐ置き換わるなんてこと誰も言ってないのにな
お爺ちゃんの妄想癖こわっ! Cが登場したのが1972年で翌1973年にはUNIXはCで書き直された
Rustには勢いがない
この先生きのこれるか分からない >>618
未だにLinuxはC++を採用しないからC++はダメな言語という話になってしまう
一方でRustは一部採用が始まった C++はコマンドラインアプリにゃ無用の長物だからなぁ Rustは全く関係ないけど、Intel CPU skylakeXのvbroadcastf64x2命令のレイテンシーわかる人いる？自分は探しても書いてある資料が見つからん。 >>619
最新の安定版カーネルはV. 6.5.5
$ curl 'https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.5.5.tar.xz' -o - | tar xJf -
$ find linux-6.5.5 -name *.rs | xargs cat | wc -l
17934
$ find linux-6.5.5 -name *.c -o -name *.h | xargs cat | wc -l
32402610
Rustのソースって5.5%なんだけど何に使われてるのか知ってるのかな? >>622
>Rustのソースって5.5%なんだけど何に使われてるのか知ってるのかな?
ごめん! ごめん! あまりに少な過ぎて間違えたよ
0.055% >>606
>>616
工作もあるかもしれんが
中國人がよく使ってるイメージ Rustがlinuxに取り込まれたのが昨年12月でV. 6.1
$ curl 'https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.1.tar.xz' -o - | tar xJf -
$ find linux-6.1 -name *.rs | xargs cat | wc -l
10359
$ find linux-6.1 -name *.c -o -name *.h | xargs cat | wc -l
31476383
この9ヶ月にCで書かれたのは32402610 - 31476383 = 926227ステップ
その間にRustで書かれたソースは17934 - 10359 = 7575ステップ
この7.5千行は何が書かれたんだろうね?
いずれにしても比較してみるとRustに勢いがないと言わざるを得ない
この先生きのこれるか分からない 増分を比較すると
10359 / 31476383 = 0.008178340730727996
Rustで書こうって人はCの0.8%ってことだ
C開発者が100人いたらRust開発者は1人いないくらい 採用さえされなかったC++は全くダメという話になってしまう >>628
> 10359 / 31476383 = 0.008178340730727996
わりぃ! 式のコピペで失敗
答えは変わらず
7575.0 / 926227 = 0.008178340730727996 Linuxカーネルのプロジェクトで
Rustに存在感は全くないということ
少なくとも最初の9ヶ月間の事実 rustみたいな欠陥言語がLinuxカーネルに
取り込まれるわけないとか言ってた頃に
比べると大部後退したな RustによりLinuxのカーネルが書かれているかのような
事実と全く異なる印象を持たないようにね
そういう詐欺的プロモーションには釘を刺しておく
ちなみに本家本丸のfirefoxでもRustのコードは半分にも満たない >>617
すぐ置き換わらないなら別にお花畑でもないだろ。
支離滅裂。
多分自分が何言ってるのかよくわかってないんだろうかわいそうに >>617
すぐ置き換わらないなら別にお花畑でもないだろ。
支離滅裂。
多分自分が何言ってるのかよくわかってないんだろうかわいそうに こんなに有名になっているのに普及率0.8%であることは、致命的。
過去、天下を取った言語はこんなに知名度が出た時には
既に利用者数がランキング3位以内に入っていた。
他のどんなことにも言えることだが最初から普及しなかった
ものは今後も普及しない。 こんなに有名になっているのに普及率0.8%であることは、致命的。
過去、天下を取った言語はこんなに知名度が出た時には
既に利用者数がランキング3位以内に入っていた。
他のどんなことにも言えることだが最初から普及しなかった
ものは今後も普及しない。 こんなに有名になっているのに普及率0.8%であることは、致命的。
過去、天下を取った言語はこんなに知名度が出た時には
既に利用者数がランキング3位以内に入っていた。
他のどんなことにも言えることだが最初から普及しなかった
ものは今後も普及しない。 ここのmevusサーバー、昨日から(?)おかしいです。
物凄く反応が遅くて勝手に多重投降になりました。 本屋のPythonの本棚も今やすっかりRubyと入れ替わってPython独占状態
過去にRuby>Pythonだった時期ももちろん知っているが
今はPython>>>>>>超えられない壁>>>>>>Rubyである
いつからこうなったか？
Rust>>>>>Pythonの未来は絶対来ないと断言出来る >>619
やること(実装すべき機能)が決まってるLinuxにおいて、C++は自由すぎた
つまりダメ
Rustはそこまでじゃないということ
まあ、俺はカーネルのコードは書くことなさそうだし、C++推しでいることに C++はGUIアプリに対しては絶大だけど
ひたすら単独でシーケンシャルな処理を行う様な
単純アプリにゃ無駄が大過ぎる言語仕様何だよなぁ あ、CUIが抜けてたw
単純CUIアプリにゃ無駄が多すぎるよ gccのコンパイラにsafeオプションみたいのを付けれた方がRustよりも遥かに需要はあるかもな。 お金のためにrustを持ち上げる書き込みをするってどんな気持ちなんだろうなあ この世界の人類の知能はRustを使いこなすほど成熟してないのよね。 C++しか知らなければC++で十分だが
はるかにプログラミングしやすいRustが同性能を実現できるから
どちらも使える人に聞けば100%Rustと答える >>654
人間の互換に対する保守性を凌駕しなければ
普及はしないよ
そしてなくなる IT大手が軒並み採用しているから
今後もっとも安定するプログラミング言語 C言語なんて登場して僅か1年でUNIXのアセンブラを置き換えた
Rustはこの先生きのこれるかな? >>658
>こっちのオジサンも複オジ並みに嘘つくよね
どこが嘘なのかちゃんと指摘してね Rustはすばらしいが、推しはC++なんだよ
C++強化はよこい Cはかなり好きだけど、C++嫌いなんだよね。ところでdouble*型の代替えとしてsafe_vec型みたいのをCが作れば問題解決とはならないの？safe_プレフィックスを付けた変数に関してはgccがライフタイムチェックを行うとかそういうのは無理なの？ >>661
Rustをなぞるとボローチェックするには
- T, &T, &mut Tの区別
- ownership rule/reference rule
- init/uninitの管理(move/copy)
- リソースの管理(Drop)
- ライフタイムアノテーション
が必要
これに加えてraw pointerの取り扱いやunsafeブロック/unsafe関数、null safetyがないとsafeにはできない CにしろC++にしろ過去の資産と互換性をもったままRustと同等の安全性を提供するのは不可能なんだよ
それに仮にsafe-Cやsafe-C++みたいなものを作ったとしても既存のコードをそれらで書き換える労力がRustで書き換える労力より低くはならない
じゃあ現時点で利用可能でモダンな機能の使えるRustを使ったほうがいいじゃんという結論になる この鯖負荷状態でまだやるつもりか
5chが終わるまでやり続けるんだろうか
俺は降りる
じゃあな暇人ども 黙って去ればいいのにわざわざ書き込むのはなんでだろうｗ ちょっとトイレいってくるわって言ってるのと同じｗ
C++にセキュリティまわりの決定打が来れば、それ使って書き直したいってモチベは必ず出る
書いてる人がそれなりにウンザリきてるからね 愛すればこそ Rustは廃れてCとRustの中間的な言語が出来ると平和に解決
C++は救われない消える >>666
サーバーがDOWNと復帰を繰り返しているらしい。 サーバー本体というよりgatewayがやられてる感じか
DOS攻撃で飽和させられてんのかな
再起動で一時的に治るのも直ぐアクセス不可になるのも頷ける >>671
tempalteメタプログラミングなんかRustはできないでしょ? >>674
C++のtempalteメタプログラミングよりも強力なRustの手続きマクロがあるからC++は勝てない >>676
Linuxカーネルプロジェクトでの惨憺たる状況から分かるのは
Rustの持つ特徴はRustユーザが考えるほどには
需要がないということだよ
少なとも当時のCほどにはね 単純に巨大すぎて変える意味がないのと、ベテランエンジニアがメンテナンスしてるからCの方がいいんだよ 惨憺とか表現が大袈裟
別に誰かが困るわけでないし
カーネル全部書き直すなんて話でもない むしろビルド環境に色々な言語詰め込んでもウザいだけだし >>680
複数の言語を併用はコストがかかりハードルが高く普通はデメリットが大きい
しかしLinuxもAndroidもWindowsもそれを上回るメリットがRust導入にあると判断して併用を始めた >>681
だからLinuxは誰もコミットしてないんだってば
kernel.org見てこい 9ヶ月でRustで書かれたソースは7575ステップ
7千行なんてお前ら1人で1日で書くやろ?w >>661
それをやってるのがchromium
RawPtr<T>をナマポと置き換えた
RawPtrの機能により様々な統計(循環参照、ブラブラポインタ、参照カウントなどなど)をとることで問題をあぶり出してるらしい >>666
俺普段は他の掲示板にいるけど流石にこの状態で来る気にはなれんな
収益ないと無理でしょ
オワコン >>681
LinuxでのRust利用は
まず安定版カーネルのコンパイラをclang対応にするか
gccrsが実用段階になるかしないと誰もコミットしない
とてもとても「併用を始めた」なんて状態とは言えない
こういうRustの詐欺的プロモーションには釘を刺しておく >>663
kotlinがjavaをそのまま使えるように、c++ファイルをそのままincludeできるkotlin c++があればいい。 KotlinはGC依存言語だから
この話のスタート地点にも立てない >>688
お前は去年はrust対応パッチのマージは不可能とか
言ってた人？ 俺はV 6.1 releaseより前にここには来てないよ
別人 採用されたってだけで十分画期的なんだけど、
そんなことよりC++にunsafe{ } 流入はよ >>662 >>663
IT大手各社がC++拡張は無理と判断してRust採用へ進んだ理由はそういうことだな F12でスマホモードにすると書き込めた。
みな 2ch に移行せよ。 マイクロソフトも金貰ってRustのステマやってるのか～ MSはこういうときに、C++(VC)にも投資しながら、Rust(VS)にも投資する そのうちViusal Rust++とかRust/CLIとか出るかもね ってかC++が広まったのだってMSがWindowsの開発言語に採用したからだぞ。 >>695
unsafeスコープじゃなくてsafe相当のスコープが欲しいところ。
とりあえずはdelete new禁止、nullptr禁止(スマートポインタ含む)、生ポインタ変数禁止(仮引数含む)、ぐらいはやってほしい。
できれば(関数を拡張して)スタック上のインスタンスのみ受け付ける仮引数を用意して、スタックを特別扱いするようにできないかね。そうすりゃc++でもライフタイムを扱いやすくなるかと。 そもそもCはアセンブラまんどくせぇから始まった言語だから
アセンブラの基本的なその値はアドレスかデータかを人間が把握してるのが前提なんだよなぁ
どんどん馬鹿が入り込んで親切な言語になって行っちまったが 専業の攻撃者が煩いからね最近 ミスが許されない
たとえ酔っぱらって書いても、コンパイラがツッコミ入れてくれるってのがいいわけで >>704
それはない
>>706
ほんそれ
美しい設計を馬鹿が台無しにする >>707
コンパイラのツッコミ頼りの人がミスが許されない仕事しても大丈夫な言語なんて無い。
大丈夫だと思い込んでる人がいるだけ コンパイラくんがしっかりしてくれれば、ポンコツの俺にも、重要モジュールが書けるようになるんだなあ
(正確には品質向上、まあそこはいいように取ってね)
だからC++強化はよこい >>706
いまはセキュリティまんどくせぇな時代だよ
うん、そんなことより、俺は生ポと石の把握に専念したい
俺はそれなりに、簡潔にちゃんと書いてる自負があるが、後任のことは知らんから
陰キャだしｗ 5chのスレがまたアクセスしにくくなっているけど、
そういう場合は、2ch で書き込もうや >ALL 5chのスレがまたアクセスしにくくなっているけど、
そういう場合は、2ch で書き込もうや >ALL >>710
>そこはいいように取って
こんな考えの香具師にはまともなプログラムは描けない >>711
型安全性：まんどくせ
参照安全性：まんどくせ
メモリ安全性：まんどくせ
Rust描いてる人の意識はこんなもんだってことか >>714
そんなことを言うあなたからは、(俺は)まともなプログラムを受注できない
うん、問題ない 平和的
>>715
いやまて、俺C++推しなんだがｗ
Rustが成功パターンを示しつつあるので、C++にそれが流入すべきだと言ってる >>771
DDoS攻撃は、個々のアプリではなくサーバーの
入り口レベルで対処する必要があるらしい。
また、デスクトップアプリでは昔のままで攻撃の
対象にはなってないはず。
だから、もともとC++が強い領域では余り関係無い。 C++にRustのやり方が自然に流入するわけはなくて誰がが莫大な投資をして優秀なエンジニアを年単位で張り付かせながらコミュニティと調整したり移行のためのマーケティングもやらないといけない
そのための人も金も人もあってC++が発展すればダイレクトに恩恵を得られるMSやGoogleのような会社がそういう投資をする価値がないと判断した以上C++がRustばりに強化される未来は100%来ない
unsafeだけど速度が出せて過去の資産が使えるレガシー言語として生き残る
3D/2DやGUIの低レイヤー部分が一番長く残りそう ここ数年はGPTチェッカーの登場で
Rustがこの先生きのこれるかの瀬戸際だと俺は思うよ C++はなんでも取り込んでくるんだけど、遅いんだよとにかく
Rustで喫緊の課題を解決でき、さらにノウハウを得られるとMSほか各社が考えるのは順当
ただ、MSもMSVC/VS持ってるから、ニーズが高まれば該当チームは取り込みには来る
dogfeedルール持ってるから、取り込まれたら、新規C++コードはそれで書かれるだろう Rustの安全性をC++に導入するのはC++にasync/awaitを導入する50倍は困難
そんなことはもう誰もやらない
歴史に学ぼう >>718
お前は誰にレスしてるんだ？
C++使ってるからって掲示板でまで存在しないレスの番号参照するのかよ。
お前の作ったプログラムが世に出てないことを祈る。 >>723
2ch sc から書いたから番号がずれたらしい。知らんけど。 >>721
MSがRust#とかMSVRとか出しても使う気になれないな >>718
誰にレスしてるのか知らんけど
5chがRustで描かれていればDDoSも100%防げていたって言いたいのは判る >>726
それは全くのデタラメ。
DDoS攻撃は言語を変えても防げない。 >>720
だろうね
CopilotやGPTチェッカーが浸透すると
Rustのような言語は淘汰されていくのかなって思う >>728
反応速度が無限に早くなればあんなの攻撃にもならないよ？
今は通信頻度に比べて処理速度がべらぼうに遅いから負荷が掛かってあれが攻撃になってしまうだけだからね 夢見るお爺ちゃん相変わらずだねww
CopilotやGPTにはコンパイルエラーになるかどうかすら判別できないのに
静的解析ツールの方がまだ現実的 DDoSはネタかと思ってたがマジだったのか
さすがに無知がすぎるやろ もうさ、FPGAでサイト構築したらいいんだよ
むしろDDoS攻撃してる方が負荷掛かるくらいに >>731
>CopilotやGPTにはコンパイルエラーになるかどうかすら判別できないのに
試した? 既に実用水準だよ
Rustをやろうって動機が削がれればユーザは一向に増えない
ユーザが増えない限り忘れ去られるのが
プログラミング言語が辿る運命 >>733
DDoSは乗っ取った鯖から総攻撃するだけだから攻撃主には負荷掛からない それ以前に
Rust混入したせいで
Firefoxが不安定化してる それ以前に
Rust混入したせいで
Firefoxが不安定化してる >>730
「反応速度が無限に速くなれば」
そりゃそうだろうけど、現実に速度を速くして
防ぐことなんて可能なんかね。
そういば、CDNを使えばサーバーが分散されて速くなるから
防げるということかいな。
DDoS 攻撃って1000台とかで攻撃してくるんじゃないの？
だとしたら、それに対抗するのは難しいはずだが。 1000台とか生やさしいもんじゃない
桁が3つは違う glibcでバッファオーバーフロー系の脆弱性でたね。
一応criticalではないらしい。 WebサイトをFPGAで構築したところで無駄
勉強してから出直せ >>734
あれで実用水準だと思ってるならそりゃ話噛み合わないわ 日々使ってればLLMの本質的な強みも弱みも限界もある程度判りそうなもんだけどな
とりあえずこういうのでも読んでみたら？
https://arxiv.org/abs/2310.02059 >>743
これからプログラミングを学ぼうとする者のうち
わざわざRustをやろうって動機が削がれる者が現れるだろ?
ただでさえRustはユーザー数が少ないのに
増加を抑制する要因が日進月歩の話題の技術により
また一つもたらされたことが
命取りだと>>734は指摘している CDNは HTML+CSS+JS だけのような静的ページを
キャッシュすることは出来るが、CGI や Ruby on Rails
などを使った動的ページをキャッシュすることは基本
出来ないはず。だから、CDNサーバーの数が多いとしても、
動的ページはオリジナルサーバーの CGI や Rails などに
問い合わせしなおすから付加は減らない。
だから、秒間数千万アクセスの DDoS 攻撃をCDNサーバーの
数だけで対抗することは不可能。
なので、賢い CDN サーバーは、DDoS 攻撃されたら AI で
して、攻撃しかけてくる IPアドレス と善良な IP アドレス
を判別して前者は CUT し、後者だけをオリジナル
サーバーの CGI や Rails などに問い合わせする様になっている
らしい。 動的コンテンツもキャッシュできるよ
ショッピングカートみたいなものはもちろんキャッシュしたりはしないけど5chのスレみたいたのはキャッシュする方が普通 >>747
メカニズムにもよるが、時計みたいなものはキャッシュ出来ない
と書いてあった。
だから、掲示板の様にいつ更新されるか分からないものもキャッシュ出来ないはず。 >>747
メカニズムにもよるが、時計みたいなものはキャッシュ出来ない
と書いてあった。
だから、掲示板の様にいつ更新されるか分からないものもキャッシュ出来ないはず。 >>747
メカニズムにもよるが、時計みたいなものはキャッシュ出来ない
と書いてあった。
だから、掲示板の様にいつ更新されるか分からないものもキャッシュ出来ないはず。 >>748
掲示板もキャッシュ可能
実際に5chはCloudflareを使っている cf-cache-status: DYNAMICで返されるから
CDNでキャッシュせずにオリジンサーバーから返してるみたいよ キャッシュの効果よりこっちの方が効果あるよね
>>746
なので、賢い CDN サーバーは、DDoS 攻撃されたら AI で
して、攻撃しかけてくる IPアドレス と善良な IP アドレス
を判別して前者は CUT し、後者だけをオリジナル
サーバーの CGI や Rails などに問い合わせする様になっている
らしい。 >>756
CDNのキャッシュの話はキミが動的コンテンツはキャッシュできないと勘違いしてたから指摘しただけでDDoSの話とは関係ないぞ >>757
キャッシュすると、一時間くらい更新されなかった
りするので、他人が書き込んだことによって変化
した記事が長時間反映されないはず。
また、データベースのデータファイルが
オリジンサーバーにあるので、CDNサーバー
上で Rails や php や cgi を動かしても
本当のデータファイルに書き込むことができない。 >>754
使っているが、cgi の実行(フォルダなど)は
キャッシュはOFFにされているはずだ。 なんでもチャンスは一度きり。Rustは既にチャンスを逃した。 5chが使っているCDNはCloudflareでRust製
ソースは>>4 >>764
人は噂が出た時に調査する。その時に流行らなければ無理。
パン屋の開店時に沢山人が来る。値段と味と雰囲気を
チェックし、リピートするかどうか判定される。
それに合格しないと潰れる。Rustはその試験に失敗した。 >>765
[補足]
後から改良しても一度付いてしまったイメージは変えられない。
多くの人は最初だけしかチェックしないし、脳は一度付いたイメージを
変えたがらない。 >>765
なるほど
セールス詐欺もあると逆効果だしな 話題になると調査や学習だけはされていることが多く、
それでもなお使ってないのにはちゃんとした理由がある。 できるc++erはそもそもrustっぽい書き方を心がけていたわけで対立構造では見ないだろ
どっちもできないやつが外野から騒いでるだけ >>758
>キャッシュすると、一時間くらい更新されなかったりするので
それは1時間もキャッシュしておいて更新されてもinvalidateしないのが悪い
redditはTTL1秒でCDNにキャッシュしてる Rustを使い始めて周りの女性の熱い視線を感じるようになりました！ >>771
掲示板のオリジンサーバーをCDNで分散化させる場合、
記事を投降した際に、HTTP REQUEST はオリジンサーバー
に送らないといけないと思うのだが。
そうしないとデータベースの更新が出来ないはず。 >>780
[補足]
read はCDNサーバーのキャッシュから読み込めばいいが、
write の HTTP REQUEST はオリジンサーバーに送らなければ
ならない、みたいなことな気がしてきた。
言ってみれば、read.cgi と write.cgi が有ったとして、
前者は結果のHTMLだけをCDNサーバーにキャッシュされている
内容だけで足りることがあるが、後者は、オリジンサーバーで
実際にcgiを何らかの言語で動かす必要がある、ということ。
そうしないと、掲示板への投稿をデータベースに反映することが
できないはず。なぜなら、データベースのデータファイルは
CDNサーバーではなく、オリジンサーバーだけに置いて
あるはずだから。 >>781
そこまで問題を言語化できるのにどう対策しているのか調べられないのはなぜなのか……
思ひて學ばざれば則ち殆し >>783
CDNについて知ってから一日くらいしか経ってないから。 >>781
読み込みはキャッシュを返して書き込みはオリジンサーバーへ送るというのは至極当たり前のことだと思うんだが何を問題視してるの？ 「ベアメタル」環境でもRustを採用 Googleが「Android 14」での取り組みを解説
安全性と生産性の両面でC/C++よりも大幅に改善
https://forest.watch.impress.co.jp/docs/news/1538800.html 「ベアメタル」って初めて聞いたぞ
また新たな造語（というか用語の借用）かな? ベアメタルは10年どころじゃなく結構昔からある用語たよ 馬鹿って自分が知ってることを知らない人がいるとめっちゃイキっちゃいんだよな >>792
「メタルベアーがあらわれた」
その発想はなかった >>787
そのRustで生産性が向上な点がいいよな
まわりでも採用理由がそれ その、生産性が向上するってのは直感に反するんよなあ
・言語が安全を担保してくれるから、そこんとこをコーダーは考えなくていい
・マクロまみれのCからの解脱
・C++はともかく、Cにはasyncとかない
あたり? 後半はRustの問題点もしっかり指摘してあるよ
unsafeで囲めば良いんだろうけどそれでは意味がない 何にしても言えるのはc++を書き換えるならRustだけではなくC++の知識もいる
新規だけなら分かるがそうもいかない
今後数十年ずっとそのターンが続く 対応してるチップが少ないのは、極端な話、Rust2Cみたいなトランスパイラができれば解決する
汗とおなじで、Cは直接かくからいけないんであって、機械が吐く分には問題がない
フットプリントも、おそらく、現状で220KBかそこらが倍になったくらいで…人間が比較研究できるレベル
出力を比較すれば、Rust側の最適化がもっと進むんじゃないか
unsafe{ } が存在することで、unsafe{ }をうまく極小化する気運が生まれる
これは裏山 C++にも欲しい 今後Rustプログラマーに求められるのはc++のコードを読んでRustに書き換える能力
これが一番要求されると思う C++は使ったことがなくてC専門だったけどRust便利で使ってる ベアメタル知らないってマジ？
仕事したことないんだな >>804
知らんな
ICTとか使われ始めたときの違和感を感じた
検索すると>>787とも微妙に違う意味で使われているのが多少ヒットするね まあソース(ぐぐるの英文ページ)みたら、何をもってベアメタルって言ったかはわかる 自作OS作ろうとしたことがあるならベアメタルって言葉は当然知ってる
というかその過程で覚える
まぁベアメタルって言葉知りませんってのは低レイヤーわかりませんって白状してるようなもんだわな
ただベアメタル環境の仕事なんてほぼない
いくら小規模な組み込みでもOSは使う
仕事したことないとかほざいてるやつこそ仕事なんかしてない 「仕事したことある」ってのは、CもC++もRustも、汗でも、なんなら好きな石ならダンプでちったあ読めるレベル
そんなヤツばっかりじゃねえって
俺はRustできないからアウツｗｗ
いやまあ、なんで急にベアメタル(って単語)? とは思ったけど >>792
ベアメタルのベアはbear (熊)ではなくbare (裸の)だよ
記事の原文はこのGoogleセキュリティブログね
Bare-metal Rust in Android
https://security.googleblog.com/2023/10/bare-metal-rust-in-android.html >>807
kernel2.1くらいから追ってるけど使わないなぁ
最近は確かにご無沙汰だけども >>807
小規模な組み込みでOSを使わない仕事はまだあるよ
PICとかまだ使ってるとこもあるだろうし
自分はSTM32で最近OSなしの仕事をやった Javaもpythonと比べたら十分早い
ただcはjavaよりさらに10倍速いからなぁ… C++と比べるのが間違ってる
template使いまくりのC++からRustに描き替えるのは至難の業
CとRust比べたりCからRustに移行しようって話ならまあ判る
C++からRustに乗り換え煽ってる香具師はただの無知馬鹿 >>801 みたいに
前半はCで話してるのに
最後の結論はC++の話になってる
こういうのが一番誤解の元 横スレだけども段落分けてるから良いのでは?
C++はRustと違ってCを丸呑みしたから別言語って感じとはちょっと違う >>808
＞いやまあ、なんで急にベアメタル(って単語)? とは思ったけど
>787 の記事に書いてるからだろ。
レスの流れ読まないで脊髄反射するタイプか？ >>813
ないない
仕事ならpicだろうが普通にベンダーの指定する開発環境使ってるだろ
Toolchainがそろっててランタイムは用意されてる
OSと呼んでないだけ
仕事でそこを自作する意味がない >>819
ランタイムをOSというのですか？
組み込みでOSといったらRTOSだと思いますが
ArduinoとかもOSとか言い張ります？ 今時の開発環境は初期化や各ペリフェラル用のライブラリも用意されてはいますが割り込み処理とかは自分で全部実装する必要があります
RTOSにあるタスク制御用の機能も用意されてません
OSとよぶのは無理があります ITRONが出てこない組み込みスレ
まるでアベノミクス ITRONが出てこない組み込みスレ
まるでアベノミクス >>820
OSかどうかの話はしてない
ベアメタルか否か まぁマイコンでベアメタルとどやるやつはいないだろな
単純すぎる
プロテクションやページングとかまでやらないと面白くならない >>825
裏でOSが走ってなきゃベアメタルでいいんじゃね？ 「Widipediaに描かれてないからそれ以前は使われてない(キリっ)」とか無知過ぎる >>827
そんなに新しくない
1991年出版のThe Hacker’s Jargon Fileには既に掲載されてる
もっと古い版でも載ってるかもしれないが少なくとも2000年代前半には聞けば意味がわかる程度には浸透してた 速度が重要なVMやメモリ管理系はC++で書いて他はRustで書くことにした >>829
ベアメタルってのはようするにブラックボックスを排除して全部自分でハードを叩いてみるというスタイル
OSを自分で書くならそれはベアメタル >>834
ハード叩いてないライブラリならOKってルールなの？ >>831
Wikipediaで取り上げられるほどには
使われていなかったとは言えるね しょーもない話だな
ウルトラマンがシリーズ化して最初のウルトラマンを初代ウルトラマンと呼んでるのと変わらない >>835
厳密な定義あると思うか？
CPUのマニュアルとか見ながら１から作っていハードを全部理解したわぁって気になるのが面白さなわけ
どこまで拘るかは好きにしろや >>838
じゃあ裏でOS走ってなきゃOKじゃんｗ CDN知らないとかベアメタル知らないとか世の中いろんな人がいるわな。
知らなきゃこれを機に勉強すれば良いだけ。 >>840
珍妙な名前で呼び出したなって思うだけで
中身は昔から馴染みあるよ 「ICT」も突然使い出して
まぁ意味は分かるけど自身では未だに使わないし
最近だと「生成AI」も気持ち悪い >>839
文盲だなお前は
OSが裏で走ってるかどうかじゃない
loaderやstartupがありもの使ってたらベアメタルとは言えないだろ
そういう的外れなことを堂々と言ってくるのはどうせユーザーランドでわちゃわちゃするプログラミングしか経験ないんだろ
しったかすんな >>842
ITだと英語のitと紛らわしいから使い分けてるだけなの
生成AIは英語を訳しただけなの >>843
文盲とは文字などを知らず読めない人のことで意味が取れない人じゃない
使うと恥ずかしいレベルなので得意になって使うと馬鹿がバレる
と言うかお前もう馬鹿をさらした >>844
ICTは通信会社が頑張って流行らせた略語
itと紛らわしいから使われるようになったなんてのは真っ赤な嘘
ITではなくICTを使うのは官公庁・教育・通信セグメント及びそれらに媚びへつらう必要のある業界のみ >>843
お前が思ってるベアメタルの定義が知りたいだけなんだけど
なんでそんなに興奮するの？ >>843
もう構うな。
ベアメタル初めて聞いた( >>788 )とか言うようなやつだぞ。
>>827 で無知を晒して
>>831 、832 で返されて、
ミドル・アプリレイヤーしか触ったことない奴だよ。
その後も >>845 で必死に話題変えて誤魔化してる可哀想な奴だよ。
おそらく今度はそれらのレスは俺じゃないとか言って、誰も証明できないどうでもいいことで誤魔化そうとするんじゃねーのかな。
これ以上構うのは時間の無駄だよ。 >>843
もう構うな。
ベアメタル初めて聞いた( >>788 )とか言うようなやつだぞ。
>>827 で無知を晒して
831 、832 で返されて、
ミドル・アプリレイヤーしか触ったことない奴だよ。
その後も >>845 で必死に話題変えて誤魔化してる可哀想な奴だよ。
おそらく今度はそれらのレスは俺じゃないとか言って、誰も証明できないどうでもいいことで誤魔化そうとするんじゃねーのかな。
これ以上構うのは時間の無駄だよ。 GCをRustで実装しようかと思ったらいきなりハマった
やはりポインタ書き換えまくる処理には向いてないんかな TiobeランキングでRustは9月の17位から10月には20位に戻った。 >>853
まずは既存のgcクレートなどを見てみたら？ >>852
急にどうしたの？
なんでみんな同一人物だと妄想しちゃうの？ >>852
一緒にするな
以前も俺を他人といっしょくたにしてくれてたがw
思い込み強い方だと思うよ 同レベルのレスを一緒くたに扱っただけで大差なさそうではある 統合失調症の傾向があるんだと思うよ
日常でも思い当たることがあるんじゃないかな? >>845
文盲って本来は非識字の意味だけじゃないんだよ
英語のilliterateとほぼ同じで「無学でものを知らない/教養がない/本質をわきまえない」というような意味もあって昭和の古い辞書とかにはその意味も掲載されてる
それが差別用語だのなんだので広く使われない言葉になって本来の意味が多くの辞書には載らなくなっただけ
ただ5chではその本来の意味を把握してるというよりも辞書的意味とは違うと認識しつつ「おまえ文字の読み書きもできないのかよ」くらいの煽り文句として使ってる人が大半
まあガイシュツみたいな扱いだね
ということで>>845みたいなツッコミは逆に恥をかくのでやめたほうがいいよ それと文盲を非識字の意味で使う場合でも読みだけじゃなく書く能力も含まれてるから注意しようね >>860
それは違うんじゃない？
ガイシュツはネタとして認識されてる
誤用してることを知らないで誤用してるんだからさ？つまり馬鹿と言う線は超えてない どこか狭いコミュニティで誤用されて使われてる言葉を一般人が間違えていると指摘すると
お前の方が馬鹿だと言うのは常識的におかしい
どういう人生を送って来たのか？
狭いコミュニティでしか通用しない間違った言葉使いを一般人が知らないのは当然
指摘された側が間違った使い方をしていると知らず、指摘されて初めてそれが誤用だと知ったんだろうけどまあ頭悪いね ＞ 「おまえ文字の読み書きもできないのかよ」くらいの煽り文句
自分で書いてるこの定義すら逸脱した使い方
というかこの説明がまちがってるだろ
自信たっぷりに書いてコレ 「文盲」論争で思い出しだが最近「リテラシー」を
「倫理規範」くらいの意味で用いてる輩もやたら多くなった >>866
例えばインターネットリテラシーという言葉に
インターネットを使うために必要な倫理規範やセキュリティ意識などもリテラシーの一部として含んでいたとしても特段おかしくはない
文脈次第 課金ってほんとはおかしい、みたいな
架金、みたいな感じで言うよね
そんな言葉ないけど おまえらいくら5chだからと言って一線を超えているんじゃないか？
ネットだから匿名とか勘違いも甚だしい、
マジ取り返しのつかないことになるよ？ >>855
とりあえずいくつか見たんだけどひげぽんのこれが1番わかりやすかった
https://github.com/higepon/mosh/blob/master/rmosh/src/gc.rs
しかし世代別GCやコピーGCみたいにアドレスが変わるようなものだとこの実装は無理なんだよね
やはりオブジェクト参照にもう1つ間接参照を挟んでインデックスでデータを持つようにしなきゃダメかなあ >>113
mapぐらい自作しろよ……ってのがC
俺もわざわざ書いた ややもすると、mapぐらい…に時間溶かしちまうんだなあ
で、オブジェクトのやりとりでメモリバグ出してまた時間が溶ける
これだからCは
はよC/C++にもunsafe{ } こい >>833
>速度が重要なVMやメモリ管理系はC++で書いて他はRustで書くことにした
逆だろ
速度が重要なVMやメモリ管理系はRustで書いて他はC++以外で書くことにした
C++の出番は無いよ >>113
tcl/tk から流用出来る
なんなら cpython でも良い さっきみたら、Linux板の本日の投稿数は 6 だって。
板のサーバーの何かのファイルが紛失していてが
投稿出来ない様になっているようだが。 さっきみたら、Linux板の本日の投稿数は 6 だって。
板のサーバーの何かのファイルが紛失していてが
投稿出来ない様になっているようだが。 >>113
khashを使ってる
多分現時点で一番速いMapライブラリ
何とヘッダファイルだけで使える
gitやmrubyでも使われてるからお墨付き C++できる人にRust教えた
C++教えてもらおうとしたら「は？なんで？」って拒否された
「は？なんで？」 ほんまかしらんけど、ダチじゃないヤツに教えるのは嫌かな
底が浅いのが知れちゃうからね 数学教えるのと同じ
>>886-887
IDがcpp >>885
そこで「お前にRustを教えたんだから、俺にc++を教えるのは当然」ぐらい返せよ。 統失患いながらも必死にRust推しするのってなんか尊敬してきた ググればわかるけど、統失とか人格障害者に指摘したり病院に行けというと
決まって「お前が統失だろ」とか「お前が人格障害だろ」って返しになるんだよ 決まってはいない
不確定かもしれない状態を許すか、絶対許さないか
という意味ではリテラシーには倫理的な側面もある AIは芸能界と同じぐらい胡散臭いけど推定無罪なので
推定無罪が暴走している >>852
そこでいうミドルアプリ屋だが
PCやデバイスを買うときに
OSが入っていない意味でベアメタルが使われてるから知ってる
PCを買ったことがないか意識もせずにWindows入りを買ってしまう人ではないか？ 普通ついてる…と思いたいが、中古はわからんよね最近
デジタルライセンスが移動してる可能性とかもあるんでしょ
# Linuxとかも十分便利だが、NTの権利も付いてると一応安心派 どうせならこっち https://abema.tv/video/title/26-208
クレジット、1ページつかって権利関係びっしり
レトロコンテンツ愛いいね ちなみにキャラデザも日本向き、好感が持てる
ジャンク屋で98とかみると、その限られたリソースで何か書いてみたくなるね
今なら、ツールセットもあの頃より潤沢だし なんならバスもCだし
そういうのも、ベアメタル感って言っていいかなと思ってる ゲームとセーブデータを分離できない暗黒時代は20世紀に終わったのに
脆弱性とかを訂正するためOSは通常のファイルと同じところに入っている
ベアメタルとは、訂正よりもリセットがしたいということ ベアメタルもわからないこんなアホがRust叩きしていたのか アホが長生きする天国を貶すな
ロケットを作れる天才に爆撃される地獄を引き寄せるな >>906
＞ベアメタルとは、訂正よりもリセットがしたいということ
勝手にオレオレ定義してんなよ 最近のC++ってモダン化してるんやね(´・ω・｀ )
コルーチンやコンセプト、モジュール、、 export,importなんてまるでJSみたいや >>911
C++20のコルーチンとRustのコルーチン(＝async)
利用者人口を比べたらRustが多いと思う C++使いは老害だとする考え方について。
確かにいまのC++はおかしいと思うが、
C++03までは、まあ、良かったが、C++11以後に
めちゃくちゃになったことを若い人は知らない。
それまでは分かり易くて便利な言語だった。 MFCの CString には、古くから C の書式付文字列の
sprintf に対応する Format() 関数があり便利だったのに、
C++11には、それが無く、C++20 でやっと入った。
C++は、かたくなに C の printf 文を全否定する。
まるで宿主を殺しにかかった寄生虫のようになっている。 >>910
誰が定義したか特定できるものはオレオレ定義だね
C++はもはやStroustrup氏のオレオレ定義ではなく
委員会で定義されるらしい flutter vs Kotlin vs Kotlin >>915
printfやsprintfは脆弱性の宝庫だったからね
C++はそれを潰すのに10年以上の長い年月を必要としたということだよ >>915
MFCは完全無料じゃない…だったよな(オプソとかには使える
ソース付きのプロプラのライブラリ、言語の話とまぜるなキケン >>915,918
#include <cstdio>
std::printf ("は?"); >>914
>それまでは分かり易くて便利な言語だった。
それは新しいことに適応できないお前の問題
右辺値参照もムーブもラムダ式もC++11以降だよ 適者生存の空気に振り回されないためには優生学自体を疑えばいい
空気の方にこだわるのは回りくどい >>923
move登場後、C++は危険な言語になってしまった。 pitfallが増えたとかだろ、それはそう
勉強すべきことは増えた 別に move が原因で危険になった訳じゃなく
元々危険な言語である 危険と思わない部分だけを使えばいい
C++のサブセットを各々が発掘すればいい
元々のCが最良のサブセットという説がある
メリットは発掘のコストが0
デメリットはないが強いて言うなら
極論である、建設的でない、頑固など アセンブリの頃も危険だったけど注視されてなかった
サイズ付き文字列はpascalの文化でC勢がやっきになって否定してた
MSは部分的にAPIに取り入れてたけど内部でも意見が衝突してたみたいだ 個数で管理する方式より、
「番兵方式」の方が効率がよいことが多いからな。 >>928
Cは何が起きるか分かり易かったので、間違いも少なかった。
C++11は何が起きるか分かりにくくなった。 >サイズ付き文字列はpascalの文化で
Cのmallocも内部はサイズ付きだよね
文字列にしろmallocにしろサイズ付きにすると
サイズの最大値(サイズのデータ長)問題が残る
Cのデリミタ方式は無限ループと検索時間の無駄が残る C++の問題のひとつは
例えば型指定可能な(テンプレートを使った)汎用ライブラリを作るのは中級レベル程度ではほぼ不可能ってことだな
できると思ったやつ、多分お前はC++の規格の30%も理解できてないだろう
型推論を理解して、例外安全を保障して、他のライブラリとの整合性を理解して、と穴のないライブラリを作るのはもう人間業でない
まずユニットテストが作りきれない >>933
malloc関係無い。
あなたは、番兵方式の優秀さをちゃんと理解できてない。
マシン語レベルにまで落としたときの命令が分からないと
分からない可能性が有る。 呼び出す側のコンテキストで実際に呼ばれるコンストラクタがガッツリ変わるのはやっぱ難易度高いと思うわ。
c++はなにが呼ばれるのかコード読んでも判断に時間がかかる。 自分用のライブラリか、よそさまに出せるライブラリかでだいぶ変わるけどな
自分用なら、実装しないと割り切った要素は潰しておく(エラーにする) >>934
実際仕事のアプリケーションではそこまで凝ったものは見たことないな
せいぜいテンプレートをちょっと使う程度
あと使い方もコピーを禁止するようなlinterかましたり
言語側でちゃんと実装するより別のツールでチェックしてることが多い気がする むしろ、みんなが可読性や相互理解を必要としているというのが主観で
そういうのをわざと無視したコードは客観的な存在だったりして template< >の、何の数学? 論理学?? みたいな世界はまだしも、
こう使うんだぞ、と書いたものを、あとから来た人(未来の自分含む)が間違って使う、みたいのがいかんのよね
その場では、ちゃんと書くに決まってるので >>940
＞その場では、ちゃんと書くに決まってるので
育ちがいいな・・・ うらやましい
世の中にはそうならない現場もあるのだ >>940
>こう使うんだぞ、と書いたものを、あとから来た人(未来の自分含む)が間違って使う、みたいのがいかんのよね
>その場では、ちゃんと書くに決まってるので
それはtemplateに限らない悪いコード そういうのをちゃんとするのは、言語の範囲外、としたのがC/C++
言い割り切りっぷりだったが、モダンじゃない
現代的な要求に合ったライブラリと、言語側にもロックダウンモードが欲しいよね 下のtechtargetのページの読みやすい訳。
後半に書かれていること
・Rustが使われる理由: 安全性。ここで大体出ている通り。
・C++が使われる理由: ソースtoマシン語効率。あと、巨大すぎる過去資産。 >>940
ヒープの使い方を間違ったらデストラクタ実行が保証されないとかね ITメディア達の予定によると、C/C++は既にHaskellに置き換わってるはずだった GCが普及するのはいいが、GCと関係ない付加価値も持たされる
予定が遅れるほど付加価値も追加される >>944
書式文字列を生成するやつとかいんの？ おっかねーな
それ言い出したらどんな言語もアウトジャネーノ？ 脆弱なのは可変長引数
悪いのは文字列の特殊な値
どんな型システムも値のチェックができないという意味でアウト こういう基本的なことがわかってない奴らがウヨウヨいるからCやC++を触らせたらダメなんだよ >>950
流行りはCのフォーマット文字列よりも
テンプレート文字列の変数置き換えタイプだな
mustache template とか tempita とか
どっちにしても iostream の出る幕じゃない わかってない奴らと対話するコツは、対話はしても接触はしないこと キミもわかってない側だからね
自覚してないのが余計にやばいから 同じ穴の狢
とはいえ、C++をディスる輩とは相容れない
あくまで使いこなせない俺が悪い C++は悪くないんだ cppは糞とかいう奴が糞
確かに初心者が使うとプロジェクトが崩壊したり、完全に理解した系の人らが使っても画一的なコードにならない欠陥言語ではあるが、糞は言いすぎだ 関係ないけどuupdump復帰した (ここ見てるような香具師なら見てるのでは? uupdumpとは聞いたことがないのでググったらWindowsのためのソフトの名前か
Windowsを使わない人も多い上に
使用言語はPHPとシェルスクリプトっぽいが
このスレにどう関係するんだ？ もう10年くらいMacとLinuxしか使ってないな
久々に使うとwindowsの操作がわからなくて困る windows使ってるけど昔からVMの上でLinux動かしてた
WSLは今更感(否定はしない) Macも正直最近はブラウザしか使ってないので
実質linuxしか使ってない
steamもlinuxで動くようになったらしいから
いよいよlinuxに全面移行するか？ steam deckってプレステより高いんだ…いくら円安とは言え… LinuxでMSOfficeが動けばなあ。Officeが使えるunix環境用意するためにMac買ってる感ある。 そう考えるとブラウザって理想の仮想環境かもなあ
webassemblyで速度的な問題も解消されつつあるしサーバーのパワーも借りれるし MacでExcel使ってるとダサいよね
(もちろんMacのExcelが本家なのは知ってる) 暗号通貨botterの人でrust使いいるけどシープラ見ないのなぁぜ >>962
画一的にならなくても二極化でもすれば十分シンプルなのに
二極化するとなぜか1bitやめることが人類の目的みたいになるよね >>976
スキャンで落とされたりするのでは しらんけど
Rustがさらにもっと一般的になったら、マークされるよきっと 強すぎだな
>>980
WebAssemblyのアプリケーションのコードを記述するプログラミング言語として何を使っているかを尋ねた質問への回答では、
3年連続でRustがトップ。しかも利用率は上昇中です。
今後、WebAssemblyアプリケーションの開発でどのプログラミング言語を使ってみたいですか？ という問いに関しても、
1位はRust、2位がJavaScriptでした。 >>979
crypt界隈ではbot取引は至って普通のこと
スキャンされるとか落とされるとかマークされるとかは的外れ
RustとPythonが多いのは道具が揃ってるから >>982
採掘すんのかと思ったら、トレーダーBOTか なるほどね adblockplusがつべにblockされるので
独自の拡張機能をRustで描けますか？ 拡張機能じゃなくてもいいけど
広告だけを通さない(あるいはyoutube側には広告を観たフリをする)proxyを
Rustで描いてローカルで動かしとくって手はやってみたいかな uBlacklistでフィルタ最新にすればいけるよ
って言えばやめる口ばっかりの馬鹿
そういや行列君はどこ行ったんすかね >>991
Improve YouTube! よさげ
uBlacklist はなんか不必要なアクセス権まで要求されてるようで気持ち悪いのでやめた >>985
Rustって何かの役に立つモノを作る言語じゃないんだぞ Rust で chrono を使わないで
cal コマンドを造ってください
そのコードを C/C++ と比べてください let hoge: HashMap<u64, String> = vec![
(5, "hage".to_string()),
(1, "hoge".to_string()),
];
これが無理なのは判るのですが
let hoge: HashMap<u64, String> = vec![
(5, "hage".to_string()),
(1, "hoge".to_string()),
].try_into().unwrap();
でいけると思ったけどエラー出て
let hoge: HashMap<u64, String> = vec![
(5, "hage".to_string()),
(1, "hoge".to_string()),
].into_iter().collect();
なら通りました
一度 iter にしてまた collect したら一番上のと一緒じゃんと思うのですが
何が違うんです？ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 60日 0時間 34分 16秒 5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《UPLIFT会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
4 USD/mon. から匿名でご購入いただけます。
▼ UPLIFT会員登録はこちら ▼
https://uplift.5ch.net/
▼ UPLIFTログインはこちら ▼
https://uplift.5ch.net/login レス数が1000を超えています。これ以上書き込みはできません。
