結局C++とRustってどっちが良いの？ 4traits
レス数が1000を超えています。これ以上書き込みはできません。
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」
っていう雑談スレ。
前スレ: 結局C++とRustってどっちが良いの？ 3traits
https://mevius.5ch.net/test/read.cgi/tech/1683154196/
関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/ おちんぽみるく おちんぽみるく
おちんぽみるくが でちゃいましゅ！ medaka.5ch.net
/test/read.cgi/prog/1619943288/521
名言だなこれはω めも
medaka.5ch.net
/test/read.cgi/prog/1619943288/575 言語は新しいほうが古いほうを参考にできるわけで、
新しいほうが良いのは当たり前
C++の後釜はRustでいいの？ってスレならまだわかるが、どっちが良いの？はアホ >>10
Carbonが何なのかも知らない？
Carbonの公式FAQを読もう
Rustが使えるならばRustを使った方がよいと明記されている TypeScriptプログラマーの視点だけど
C++は変数宣言や型指定の方法が特殊で乖離が大きくてコスト
Rustはそれら含めて多くの点で近くて親しみやすい (ブラウザ本体じゃない)webのほうで成功事例がちょくちょく出るのはそのせいか >>11
じゃあ何で今になってCarbon開発してると思う？ C/C++とRustが互いに乖離があるのは当たり前で相対的なものだからそこはイーブンでどうでもいい話
そして色んな言語をやっていればそんな乖離なんて大したことない単なる慣れの問題だとわかっている話 >>18
置き換えを狙っているならイーブンではない
Carbonの方がこの点は有利 おまえらCarbonのコードを見たことないのか？
Hello, worldサンプルコード
package sample api;
fn Main() -> i32 {
Print("Hello, world!");
return 0;
}
記述の乖離が有る無しを議論してるようだが
Carbonはfnとか-> i32とかRustそっくりなんだぞ なんでコロンじゃなくて アローでやっているのか意味がわからなかったんだよね そこ >>20
そっくりじゃん?
#include <cstdio>
auto main() -> int {
printf("Hello, world!");
return 0;
} 売れない漫画家で最も厄介なものは、自分の描きたいものと一般受けするものとの
違いだといわれている。Rustが最良に思えるのに一般受けしないと思っているのなら、
同じ病。いわゆるセンスの問題で、勉強しても直るものではなく、生まれついたもので
あるかも知れないから、一番、向いて無い/才能がない、ということになる。 だからRustは
「作業者に好き勝手やらせないための言語」で、
「管理者が作業者に使わせる言語」。
だからMSとかのマネジメント層が積極的に推進して普及させようとしている。普及すればプログラマ単価下がるからな。
Rustの絶壁の学習曲線といった作業者視点の問題点も、マネジメント側からすれば(普及して単価が下がるようなら)どうでもいい話。 >>26
おまえ生まれてから今までずっと何言うてんねん プログラミングの仕事ってそんなに好き勝手やってるか？
俺が見た現場はルールで縛られながらコーディングしてたよ Rustできるようなやつの単価はそんなに下がらないだろ >>32
Cのコーディングルールで動的確保禁止とかあるから、もしかしたらRustの方が自由度あるかもしれん まだ継続スレ立ててやってんのか
板違いの議論すること自体無能の証なんだが自覚ないのか >>36
5chあまりやってなくてよく分からんけど、適切な板って何処なん？ >>32
途中まで全く同意だが
デスマが始まるとおざなりになおざりにされるのであった >>36
このスレが無いとRust本スレが無限に荒れるんだ
どうか生暖かい目で見てやってくれ、申し訳ない GoogleやMozillaには、本物のプログラマが必要とするソフトは作り得ない。
なぜなら自分達はルール違反のドーピングして生きていることに気付いて無いから。 >>39
あっちがいつまでも伸びないのはこれいかに >>33
MSとかマネジメント層はそうだろうね。
>>34
Javaとかは普及している分安いかと。
普及して安くなると質の低下が問題になるけど、Rustは「とりあえず走りそうな低品質コードをエラーにする」ことで改善できるのがc++に無い利点。 RustがCの代替になることが決まったなら、その程度のチェックにかけるコストは許されたことになる
同じだけC++もチェックしてくれるようになるといいし、少なくとも、
未定義になりそうなところはぽんぽん落ちてくれると、今すぐ幸せになれそう c++は、標準でコーティング規約を作って欲しいところだけど、政治的に難しいだろうなぁ。 なくはないけど、みんな守らないよね
だから、新しい言語ができた
なので、そのルールがC++に来れば、さすがにみんな少しは準拠するのでは C,C++は混沌の世界
面倒なとこは未定義で決めずに逃げる
もはやまともな秩序は望めない 上司からとりあえず
MISRA C++ 2008準拠してねって言われてるけど、
2008って古すぎだよね >>42
あっちの人らは Rust の本質を理解出来ないだろうし
コンパイルも通せない連中ばっかじゃね C/C++ はレガシーな部分を削ぎ落さないと駄目だろうね
でもそうなったらもう C/C++ のメリットが無くなって
Rust でええやんってなる コーダー向けのsmart c++とかを用意すればいいのにな。
コーダーにテンプレート定義とか不要だろ。newとdeleteも触らせないほうがいい。 572 デフォルトの名無しさん sage 2023/06/07(水) 16:20:31.76 ID:QsxM8200
書きやすいか否かという話より、rustは意外にタイピング量は多い思想は考え直してほしい。
std::fmtなどの「::」だとか引数名・変数の後の型の「:」だとか、むろんmutも、戻り値の「->」もなぜ引数の「:」と戻り値の「->」を同じにしなかったのか？思想面が分かる人に教えてほしい。
ほかにもなぜマクロ呼び出しに「!」をいちいち付けるのかとか、関数はfnやpubで省略しているのに？アトリビュートも#[xxx]と異様に見える。なぜ@xxxでは駄目だったのか？
まあセミコロンはC/C++からの移行を重視したのだろうけど。言語をディスってる訳じゃなく完全論破されることを願う >>54
これ長々書いてる割に大したこと言ってないな 雑スレだし、愚痴はいいんだけど、簡潔なほうがいいな(自戒 誤 バグの70%はC/C++
正 バグの70%は馬鹿プログラマ >>58
Dunning-Kruger Effectですねw そして馬鹿プログラマが簡単に未定義踏めるのがC/C++ だからRustみたいな指導員付き教習車が欲しいんだろ。マネジメント層は。 安全装置付きの工作機械みたいなもんだろ
教習車って。PASCALかなんかか(← 教育用言語として)ｗ
未定義ってのは処理系依存でもあるので、コンパイラが落としてくれてもいいんだぞ
今後はそうなっていく…ことを願う つーか、ベテランでも未定義動作は踏む事ある
気がつく仕組みすらないのが終わってる
安全装置外したスピード狂向け言語だな そのバイナリがちゃんと止まるかどうかの判定プログラムを書けば全てまるっと解決だろjk 補助輪付き三輪車がRust
D++はブレーキ無しの競輪用自転車 >>59
チョットデキル←Dunning-Kruger Effect
完全に理解した！←Dunning-Kruger Effect
どっちにも使う RustはC/C++書ける人でないと書けないと思う
C/C++のゴミな部分を散々食らった人でないとその概念がなぜ存在してるか理解できない
急がば回れよ C/C++のゴミな部分を散々食らった人は
回避方法も身に付いてるから
結局Rustいらねってなる RustはC/C++に手を出して挫折した人を拾う救いの言語 >>74
ある程度身についてるけどコンパイラがおしえてくれるわけじゃないからね Rustの新しい点は コンパイル言語でありながらperlのようなライブラリーの配布方法をとっている点だ
これは C ++ではありえなかった事態だ YouTube で有名な雑食系エンジニア・KENTA は、
初心者のキャリアパスは、Ruby on Rails → Go だけと言ってる
米国年収でも、Rails, AWS Solution Architect が13万ドル
Ruby, Elixir : 9.3 万ドル
Go : 8.9
Rust : 8.7
多くの言語 : 6.5〜7
PHP : 5
Dart : 4.4
Rubyは、Go/Rust/Elixir の3大言語を超えた。
一方、Rust/Elixirは普及のキャズムを超えなかった >>81
rails使いがGoつかえる訳ない
C使いが
ましてやRustなど >>74
人間はミスをする生き物というのを理解していれば、そういうアホな発言は出てこない ミスはたいていリリース前に発覚するが
デバッガと格闘してミスの場所を突き止めていくC++より
コンパイラがミスの場所を教えてくれるRustの開発効率が優れてる
C++はミス発覚がリリース後になる場合もある cargo も crates.io もデカすぎなんだよ
ローカルにボコボコゴミ溜めやがって >>85
C/C++もRustもアルゴリズムのバグを教えてくれる訳ではない
C/C++で危険回避方法が身に付いている人はコンパイル前に既に気付くから問題無い 生ポの取扱って極めるなら難しいけど、C++erはそのへんが難しいって弁えるから、ちゃんと避ける
でも、プロジェクトって一人じゃないからね
言語のほうで、ちゃんとチェックしてくれるのは結構なこと
避けてたから気づいてなかったのが正直なとこだが、コンパイラのほうのチェック機構もだいぶ進化してる >>85
>ミスはたいていリリース前に発覚するが
だがリリースできないよりできたほうがいいんだわw
バグはあとから改修すればなんとかなる場合が99%
リリース遅延よりよっぽどまし 出すことが肝心
その意味でrustは生産性は高くない
てかさ. 商用のRustコンパイラどんだけあるのさw
特に組込で商用のrustコンパイラ挙げてくれ
IARあたりがコード品質の高いrustコンパイラ出してからでもまったく遅くない >>88
>でも、プロジェクトって一人じゃないからね
それをいうならRust熟練のプログラマどんだけ居るのさww >>85
開発効率の高さとリリース時の穴の少なさでRustが圧倒的に有利だな 大手が採用するっていったんだから、>>89-90 のあたりは、目途がついたんだろ
効率の高さってのはなんなんだ >>93
コード生産効率
単位時間に何行書けるかって話だ
あとになってバッファオーバーランエラーなんか判明しても構わないから >>93
大手?
MSがrust使うっていうのも一部だけだろ
だったら最低VSでRustサポートしてから言ってくれ
大体チップメーカがまともなrustコンパイラをリリースした話は聞いてない
チップメーカーはC/C++コンパイラはチップと同様要視してるがrustはまだまだ眼中にない
Intelがrustコンパイラ出したら考えるわww 所有権あたり, rustの機能をC++がパクってるんだろ?
だったらrust風にC++で書くように機能制限して書かせてほぼ事足りるんじゃねーの?
Lintかコンパイル時ウオーニングで
PC上で実験的にコード書いてるならいざしらず
商用のコンパイラでrustコンパイラが存在しないのに何言っても絵に書いた餅 このスレ見るとC++erの知能の低さにビックリするな
5ch特有の事象ならいいんだが 知能というか知識と経験が無いだけでしょう
慣れるとC++もRustもコードを書く速さはほとんど変わらない
ただし以下の差が致命的に大きい
メモリ管理やデータ競合でミスがあった時にコンパイル時にわかるRust
実行するまでわからないか実行してもレアケースは気付けないC++ >>100
>>101
お前らがまともな商売したことないだけだろw
レアケースなら気づかなくていいんだよww
ホスピタルグレードやらNASAやらならいざしらずだ
現実をしらないww >>99
すくなくともチップメーカ謹製のrustが出なきゃ話にならんしな
cudaあたりにしてもさww それそれ
抜け穴用意しといて
というか用意せざるを得ないわけで
ありがたがってる時点でおめでたすぎるやろ
一般製品において, めったに出ないエラー or fault は
ユーザーをテスタにすればいいってこともわかってないんだよなおこちゃまは ♥ >>104
これが本当なら、PMの責任
C++から来たなら、unsafeの限局化は頼まれなくたってやるもんだと思うが cでも商用コンパイラとgccあたりじゃコード品質最悪なんよな
せいぜい規格遵守しただけの教育用途
元ルネサスの香取裕二の解説見てよーわかったわ
そこらへんgccだとソースコード見てくれって話なんだろうが,
どれだけコンパイラのソースコート見て理解してるユーザが居るのか?っていうね
商用に使える品質にはるかに及ばないコード品質なのに
レアケースのバグに有利とかもうわけわかってねぇんだろなコイツ >>106
その前にrust使った商用コード書いてないだろが
お前とこrust使った製品リリースしてるのかよww >>108
たぶん誤解されてるな 俺は「C++で十分」派
Rustの成果をC++が貪欲に取り込めばいいと思ってる
MSはブートローダとなんだったかのテキスト処理あたりからRust化してみるらしいぞ
がっつりテストを持ってれば、そういうことにも挑戦できるんだろう c++はコンパイルエラーで間違ってる場所を正確に指してこないからなあ
pythonもそうだったけど今かなり正確になって来た >>111
それはコンパイラによるのでは?
g++ + emacsでエラー箇所に正確にカーソル飛ぶよ >>113
clagの方が良いのかは使ってないか分からんが
g++ + emacsでエラー箇所に正確にカーソル飛ぶよ
俺の場合はemacsが読んでいるので快適なんだが
人間のおまいさんは冗長で読めてない? >>107
>cでも商用コンパイラとgccあたりじゃコード品質最悪なんよな
どういう意味？
「商用コンパイラは別としてgccあたりじゃコード品質最悪なんよな」
のこと？ gccはLinuxカーネルのビルドに使われているのだが...
ということは史上恐らく最も普及しているOSであろう
Androidカーネルも >>115
自分は
商用コンパイラとGCCともに仕様満たしてるだけでろくでもないもんだと取った
そもそも文章がおかしいので何度も読み返した gccは最初のCバージョンが継ぎ足し継ぎ足しで30年ぐらい使われて
C++バージョンになってから10年経ってるはず
その間の仕様変遷を見るとウンコになってても不思議じゃない >>118
Initial release: March 22, 1987; 36 years ago gccとくらべうる商用コンパイラってインテルのことを指すのだろうけど
数値計算の分野以外では使われてないし
数値計算もpythonで良くなったので既存のゴミコード使ってるような会社以外は必要ない しかし、各種 物理シミュレータや、気象シミュレータで、Python なんて使い
たくなぞ。 アカデミアでのパイソンの普及は
まずグラフのライブラリの充実が貢献したのかな?
最近ではAI関連のライブラリやサンプルコードの充実が
効いてそうだけど
Rustも頑張ってくれ 既存資産を使いまわせないから使わないだけで
速度的にはもはやpythonで良い
GPU使いたい場合もライブラリでカバーできるし
ちな富岳も富士通が頑張ってカリカリにチューニングされたpython使えるようにした パイソンってコンパイラあったと思うけど流行ってないの?
流行ってないなら何で? ちな俺の会社ではモジュールはrust使って書いてるのだがそれを使うユーザーの人たちはみんなpython
だからpyo3というrustをpython拡張モジュールにするライブラリを使っておる
これで開発者はrust、ユーザーはpythonという夢のような仕組みが簡単に実現できるようになった
C++の利点のinteropすらrustの前ではオワコンとなった pythonはスクリプトに毛が生えたレベルの用途に便利
ライブラリはC++で作ってもいいからパーツをくみ上げる最後のコーディングはpythonレベルでいいんだろう
学習時間も短いんで優秀
万人のためのプログラム言語
だからここで書かれるような批判とはかみ合わない pyo3とやらはC/C++に比べてどう優れてるの? 本屋の言語の棚の半分ぐらいがpythonとかおかしいんだけどなあ >>129
本を必要とする層は他のプログラム経験がない層だと思う
パイソンに総取りされているってことだね >>128
pythonモジュールからrustのモジュールを簡単にインポートできる
感覚としてはpybindに似てるかな
pybindがあるからC++使ってたのだけどもう必要ない C++は、20年後でも割とそのままコンパイルできて動作する可能性が高いが、
Rustは難しいだろうな。特に crate (library) とかが。 pythonもバージョン違いによる動作が不安定。
ツールを使いたいだけなのに、背後でPythonやJava、Lua、node.js などが
勝手に動き出し、途中でエラーになって終わるこっとが多い。
そして、新しすぎる Python でも駄目。適切なバージョンが有る。
また、それをインストールすることで、また別のアプリや開発環境が
動作しなくなる。
rustcも似たような感じがする。cargoもLLVMも。 そして、Docker使えなどと、こちらに負担を強要してくる。
その Dockerも仕組みを理解するのが人悶着有るだろう。
また、node.js 自体が変なバージョン管理システムを持っており、それが
また大変。ディレクトリ構造が変になって、後から元に戻すのに一苦労する。
それに比べると、商用コンパイラはとてもシンプルで、環境を元に戻すのは
比較的楽。 cargoとかの仕組みを理解するのも大変だ。
manifest的なファイルとか、makefileの代わりになるファイルとか。
そして学んだと思ったら、半年後には、cargo はもう古い、今度は busgo だとか
言われて老害、などといわれる。
automakeだ、Ninjaだ、cmakeだ、ごちゃごちゃしすぎてる。
学び損だ。 ネットだと、pythonは2系と 3系の違いだけで済むかのように見えてしまうが、
実際には、3.2 と 3.6 の違いでもエラーが起きる。
そして、「新しいものをインストールすれば済む」というような生易しいもの
ではない。
Javaも、1.7 系と 1.8 系の違いで、Android で大問題が起きる。
ところが、これも新しくすれば解決と言う問題では無い。
新しくすると、別の問題が起きてしまう。
そして、そのことに膨大な時間をとられ、自分のプログラミングのロジックを
考えている時間はほとんどなくなる。 rustも公式サイトのドキュメントが不十分だし、また、日本語翻訳版は、
全く理解できない言葉で書かれている。
そして、書かれている情報が古く、現状と合わなくなっていることが多い。
そして、非常に広範囲に渡って知りたい情報が載ってない。
たとえば、マクロ、unsafe、ライフタイム修飾、実際のマシン語
バイナリレベルでの内部データ構造などの情報が大幅に欠如している。
そして、すぐに仕様が変更され、物凄く勉強したのに、無効化され、
老害扱いされる。だから、深く使おうとすると必然的に老害扱い
されるので、表面的にだけ使用するサンプルの様な短いプログラム
している人だけが賞賛されるような事態となる。 >>137
オープンソース関連は、プライドが高い人が多く、自分の比を決して認めない。
「すみませんでした、直します」
見たいな態度を決してとらない。
また、「それは古い、新しいバージョンでは直っているかも」などと指摘されるが、
実際には全く直って無い事が 100%。 >>140
ほら。
crateに関数が揃っているような分野のサンプルプログラムみたいな短い
プログラムを書いて、「ほら凄いでしょ」みたいなことをやってる人が
SNSでよく見かける。でも、ソースを見てみると、本人が書いている
部分は簡単に出来ることを長々と書いているだけ。
本質的には、crateに、たまたま、丁度良い関数が用意されていたからできているだけ。
また、日本は広いので、たまたま上手く行く人がいる。
大部分の人はやりたいことに対する解決策がcrateでは見出せず、結果が出なくても、
SNSなどではそれを知る事が出来ない。
crateにあるものは簡単だが、自分でやろうとする突然めんどくさくなるだろう、
Rustは。 C++に固執してる人は時代遅れのおじいさんしかいなくなってるみたいだな あの、与えられたものを黙って使いなさいと言われる感は、確かに苦手だね
与えられたものを理解して使いなさいと躾けられてきたし 反対意見が出た場合に、新しいということを根拠に、古い言語を指示する人を
老人扱いするのは狡猾でずる賢い。英語に訳すと clever としか訳せないかも
知れないが。単に clever という意味ではなく、ずるい、悪い、意地悪い、
不公平、などの意味を持っているのでここを見ている外国人は注意。 >>133
流石に言ってることおかしいよ
まあC絡みのバイナリパッケージ入れるときに依存関係で躓くことがあるのは初心者ならあり得るが >>147
現実にそうなってるんだからしょうがないじゃない。
今までの個人的経験に基いたら、そうなる。
どんなに反対されても、経験してしまったんだから。
だから、100円ショップで100円のイヤホン買って音質が最悪だったから、
多分、他の電気製品やボールペンもそうかもしれないと思って買わないのと同じ。
顧客は、体験から学んでしまうので、普段からの出来事がとても重要。
粗悪品を使わされた店は信用ががた落ちになる。挨拶がしっかりしてる店は
なぜかリピーターが多く、潰れない、と言われている。
それと同じ。今までの態度や商品の出来具合、品質、嘘があったこと、トラブルが多かったこと
などで、顧客はオープンソースにそういうイメージを抱くのは当然の権利。 オープンソースもピンキリだしねえ
でもアレルギーはもったいないぞ
法人が資源を注ぎ込んでるプロジェクトもある
利用しない手はない
ピンキリだけどねｗ >>149
clangも、重要な部分に不具合がある。
簡単にはリンクが出来ないとか。
不可能ではないが、やり方が書いておらず、自分で試しまくって見つけた。
オープンソースはいつもそう。
そして、次のバージョンでまた変化し、せっかく見つけた対処法も無効化されて
しまう。 >>132
Rustのcrateのversion管理とコンパイラのedition管理は秀逸なので
現在コンパイルできて動いているならば何年後でもコンパイルできて動く よくあるのは、配布する人が、配布し忘れている何かがあるのではないか。
これはとても難しい問題で、その人の環境では、他の人には存在し無い
ディレクトリにパスが通っていて、その中に重要な何かが置いてあったり、
何らかの configuration file が、デフォルト状態ではなかったりするため、
その人の環境では上手く行き、何の問題も無い。
しかし、配布する際、そのすべてを配布できて無いので、クリーンインストール
した人は、不具合が起きる。
オープンソースは、AppleやGoogleがやっていても、このようなことがよく起きる。
恐らく、ツールや設定ファイルが大量にありすぎるからでは無いか。
しかも、赤の他人が作ったものなので、全貌を把握できない。
改造されてしまったものが流布されているので、原作者でさえ、何が
どうなってるか分かって無い。 >>151
信用出来ない。それは、今までの経験に反する。
Rustだけがその例外だとは信じられない。
しかも、10年経ってみないと答えが出ない。
そんな重要なことは、今までの人生経験から推定するしかない。
オープンソース関係者の言うことほど信用できないものは無い。
中国と同じような感じ。
実際、github のいいねや、寄付は、多くは中国からもたらされている聞いている。
中国企業は、中国共産党から補助金を得ており、それを github に寄付しているの
だろう。中国共産党は今でも社会主義を目指すと言っているので、github や
オープンソースの寄付運動は、中国共産党(左翼の総本山)が行なっている。 unsafeってキーワードは失敗じゃないの
rustではほんとは使っちゃダメってことでしょ
unsafe連発の成果物見て萎えちゃった
せめてunsafe無しでGUIプログラミングできてから出直してきてよね オープンソース系のソフトは、sysroot だったり、勝手にパスを検索してしまっ
たりする。また、影響を与える環境変数が非常に多いため、動作が不安定になる。
gcc のリンカの ld にしても、余計な検索を非常に多くしてしまう。
たとえば、-lxxx としていすると、libxxx.a だけでなく、xxx.lib, xxx.a, など
非常に多品種な物を検索する。しかも、検索する場所も非常に多い。
これは非常に危険で、脆弱性と不安定をもたらす。
絶対にリンクしてはいけないバージョンを勝手に探し出してきてリンクしてしまったり、
配布もとの人が想定して無いものが実際にはリンクされていて、それが
顧客のクリーン環境では存在して無いから不具合が出たりする。
バージョン違いや環境違い、CPU違いのライブラリが勝手にリンクされてしまい、
不具合になったりもする。
厳密性が無いから、不安定。
世界中の設計指針の異なる無数の人が書いたソースなので、コード規約が守られて
無いため、grep 検索しても不具合のもたらしそうな箇所を見つけ出すことが出来ない。
そのため、いつまで経っても、潜在的な不具合原因が入ったままとなる。
ツールの中に「パスっぽい文字列」が固定で入っていると不安定要因になるなので、
grep検索して特定して削除しようかと思っても、上手く検索に引っかからないので
誰も修正できない。 >>154
こんなことが罷り通ってるんなら、真にunsafe{ } を使いこなしているのは、C++ってことにじきになるなあｗｗｗ
(この目で見てないので)しらんけど
たぶん、C++から行った奴じゃないな >>154
二つ誤解している
unsafeは人間が安全性を保証しなければいけないブロック
それ以外の部分はsafeとなりコンパイラが安全性を保証してくれる
unsafeはほとんどの場合でメインのプログラムには出て来ずにモジュールやクレートの中に閉じ込めて用いる
仮にunsafeを使っても局所的に閉じ込めることによって人間が安全性を保証しなければいけない部分を極小化する
とはいえ自分でunsafeコード書かなければいけなくなることは特殊な機構やFFI作成など滅多にない
たいていは標準ライブラリや既存クレートを用いて自分はsafeなコードを書くだけで済む
次にGUIについても同じでunsafeは必要なく実際にunsafeを使わずにGUIを使うことができている
ただし上述したようにGUIに限らず一般的に自分でFFI作成となると話は別
FFIの相手先はRustによる安全性の保証が及ばないため当然unsafeとなる
したがって一般的にFFI部分はそのコードのみunsafeを使うがそのモジュール利用者はunsafeを使わずに済むように作る
その利用者である一般のプログラマはunsafeを使う必要はない
ただし論理的にsafeなインターフェースのみを提供できないものに対するFFIのみunsafeなインターフェースが剥き出しとなる
そのようなunsafe剥き出しなFFI利用者のみunsafeの使用が必須となる pythonは比較的簡単にいろいろなバージョンのすみわけができる仕組みが充実してる方だと思うけどな… 自分もあと20年ぐらいしたらこんなダメなおじいさんになってしまうんかな >>155
前段リンカーの検索パスは設定可能
コンピュータなので勝手にリンクする訳などなく
設定されたルールに基づいてリンクされる
なぜ自分が使い方を知らないだけだと考えないのだろうか?
随分と傲慢な人だね
後段設計指針はプロジェクトごとにある
ちゃんとレビューしてるプロジェクトもあれば
質の悪いプロジェクトがあるのも事実
淘汰圧が掛かるから重要度が高いものから淘汰されていく >>160
gcc系はこっちの意図に反して、勝手にやってしまう傾向があるように感じるんだよ。
自分勝手と言うか。パソコン文化、Windows文化、個人向けコンピュータ文化
を知らないことも原因かも知れない。おかしいことがあっても誰も訂正しない。
自己主張が強すぎる。 >>155
>配布もとの人が想定して無いものが実際にはリンクされていて、それが
>顧客のクリーン環境では存在して無いから不具合が出たりする。
Docker嫌ならstatic linkすりゃ良いだけでは? 老害といわれようが、俺が今まで経験した限り、商用コンパイラは安定性が高く、
こちらの意図した通りの動作をしてくれる傾向があるが、gcc も clang も
おかしな動作が多い。極端にコンパイル速度が遅いこともあるし。
それに、途中までは動くが、実際の >>163
#手が滑った。
それに、clang なども途中までは動くが、実際の exe ファイルまでは作れないことが
多かった。不可能ではないが、結果的に必要なものをたまたま見つけたのが数年後。
それまでは exe ファイルが作成できなかった。
それに比べ、商用コンパイラでこんな自体は経験したことが無い。 >>161
>gcc系はこっちの意図に反して、勝手にやってしまう傾向があるように感じるんだよ。
それはgccのルールをユーザが学ぶべきだろうw
>パソコン文化、Windows文化、個人向けコンピュータ文化を知らないことも原因かも知れない。
UNIXの文化というか作法はWinwosより古くからあるもの
UNIXを使うのなら使う人が学ぶべきことがら
あなたは使わない方が良いと思うけどもね >>164
他の人が出来ていて自分が出来ていないのなら原因はどこにあるのでしょうか? >>162
完成品ではなく、開発環境なので、こっちはこっちでリンクされるわけだから、
そういう問題ではない。コンパイラ作者が開発環境をテストする際、テストアプリ
にリンクするライブラリや設定ファイルが、クリーンインストール環境とは
異なっている場合があり、それが不具合の原因かも知れないと言うこと。
コンパイラ作者は、問題ないと思っているが、分かりにくい問題が潜んで
しまっている。
色々な商用コンパイラを使ってきたガ、こんなことは無かった。 >>166
実は他の人も出来て無い。
オープンソース系は、なぜか出来て無いのに出来ていると嘘付く人が多い。
本当に出来て無いのだ。 gccもclangもc++専用コンパイラじゃなくて多言語に対応した仕組みになってるからコンパイルが遅くても当然だよ
前段で各言語の処理して汎用の中間コードにして（必要なら他の中間言語にまた変える）そこから最適化を数段挟んで最適化して出力してる >>167
何書いてるのか分かりにくいが
おまいさんがある開発環境を整えようと思ってできなかった
その原因は作者にあると言いたい?
>>168
>オープンソース系は、なぜか出来て無いのに出来ていると嘘付く人が多い。
何のためにwww >>163
モジュール化して分散コンパイルすると良いよ
PCの台数あるならdistccとか導入するとかも良い >>135
何年も経ってるのにいまだにcargoを超えるものが出てきてないのが現実だよ >>167
あ！わかった
Winowsと同じ要領だと思って
ディストリ配布の公式バイナリ以外を
よく考えずにインストールして
必要なライブラリのバージョンが合わずに
動かんかったパターンだな >>136
まずOSのパッケージマネージャでほとんどのバージョンはインストールできる
それでほぼ困らないし組織で使うならバージョンを固定するのが当然
どうしてもバージョン縛りがあるならdockerで動かせばよろしい
それも嫌ならvenvもある
それすら嫌ならcondaに引きこもる手もある pythonはパッケージマネージャを使えばバイナリ自体が違う名前でインストールされる
だから既存の環境がぶっ壊れることはない
もちろん手動で入れるとその限りではないから
ちゃんと理解してる人でないとできないし既存の環境を"上書き保存"してしまう可能性はある
まずパッケージマネージャを使うことを徹底すべき
alternativeコマンドを使えばデフォルトのpythonコマンドで使うバージョンを固定できる
これでほぼ環境問題は無くなった これ加えてvenvを使えばインストールするモジュールも固定できる
これで何がダメだというのか？
この辺の知識を調べるのは面倒ではあるが一回調べてしまえば何も困らない 少し前にあった非常にダメな時期にかじったんじゃないかなと pythonに限らずLinuxに野良パッケージ入れるときは
$HOME以下のサブディレクトリにstow使って入れると良いよ
決してroot権限を使うべからず WindowsであってもWSL2を使えばほぼ同じではないのかな？ お爺さんが言ってるのはcygwinやMinGWでclangがうまく動かないとかそんな話じゃないかと
それで動くexeを吐かないと言って憤慨してるとしてもう～んという感想しかない pythonが仮想環境の構築に取り組んだおかげで他の言語もいろいろと恩恵にあずかれているはず
パッケージの仕組みもいろんなところへ波及したと思う pythonのpipがゴミと言ってる人をよく見かけるが
cargoと比べると論外なだけでvenvなどと組み合わせれば十分手厚くて要件は満たしてると思うけどね >>135
Rustを使えばcargoだけを覚えればよいから簡単で楽でおすすめだよ
色んな言語の中でも最も良い環境の一つ C++erは、オーバスペックなものも好きくないんだよ
職務では、指定されたものを指定されたように使うんだけどさ、自分用はね >>135を見ても適応能力が低いんだな
若くなさそうなので適応能力が低下するのも無理はなかろうが
周りが悪いと当たり散らすのは良くない 老人だから新しいものを覚えられないんだろうな
もう引退しろよ ある程度普及したり評価された後にパッケージやモジュールの仕組みを変えるのは容易ではない
でも結構最近はあるよな… requirements.txtとか知らんのだろうね ここまで全方位に「経験から言ってうまく行かない」ってそりゃお前がおかしいんだろとしか
全方位だぞ？何ならうまくやれるんだよ 前スレからオープンソースを批判している人はあらゆるものを上手く扱えないことがその批判理由だと判明した
おそらく知能か精神がギリ健なのだろうから可哀想だがここで暴れるのは迷惑だ >>163
そのおかしな動作というのを教えてくれないか？ >>189
それこそが一番の弱点やん
まともなパッケージマネージャ使ったことないのん？ なんかスマホのchromeのホームページにしてるgoogleのニュースで全部Rustで書かれたKata OSなるものをGoogleが開発したってnewsが出てきた
記事は去年の10月あたりに書かれた記事みたいでなんでそんな前の記事がtopics欄に突如出てきたんだかよくわからんのだけど、コレよくわからん
googleってRust陣営ってわけじゃないんだよね？
そのgoogleがなんでわざわざ敵(?と言わないまでも別陣営の)Rust使ってOS書いたんだろ？
AndroidもRustにするつもりなんかな？ >>191
テラテールのスレに居座っているやつに似てるな cygwinやMinGWでまともなexeが出来ないとか動かないと言われても困るでしょう >>195
意味が分からんけどgoogleは普通にRust側だよ >>195
nest hubはカーネルをlinuxからZirconに置き換えた
Rustで書いたカーネルでAndroidのカーネルを置き換えるってことが
将来無いわけではない 初心者の基本のRuby on Rails をやっていないからだろう。
各プロジェクトにはbundler を使うから、
すべてのモジュールは、すべての条件に合ったバージョンを探して固定される
日本人が作った、多言語バージョンマネージャーのanyenv では以下の言語に対応している。
Renv, crenv, denv, erlenv, exenv
goenv, hsenv, jenv, jlenv, luaenv
nodenv, phpenv, plenv, pyenv, rbenv
sbtenv, scalaenv, swiftenv, tfenv
同様のツールに、asdf もある。
他には、Docker もある。
WSL2, Docker Desktop
VSCodeの拡張機能・Remote Development に、
3つの拡張機能・Remote Container/WSL/SSH が含まれている >>195
GoogleはMicrosoftやAmazon等と共同でRust Foundationを設立してRustを強力に支持している そうなんや、googleもrust支援してる側なんや
なんか勝手に自分の中で“GoogleはGo陣営、反Rust側”みたいに思ってた Microsoft支持してるならVisual Rust++はよ出せよ こんな国に、日本にとやかく言う資格は無い :
【不都合な真実】
なんと、アメリカは、日本より平均寿命が 8.15歳も短い！！
* アメリカ
76.4歳 : 2020年より 0.6 年短くなった。
男: 73.2歳
女: 79.12歳
* 日本
84.55歳
男: 81.47歳 : 2020年より 0.09 年短くなった。
女: 87.57歳 : 2020年より 0.14 年短くなった。 オープンソース信者の脳内では、Linuxが標準OSということになっており、
Linuxだけで安定動作すれば閑静だと思っている。だから、gccやclangが不安定
だということが理解できない。
但し、Linuxで試してもそんなに安定ではない。
彼らは、殻に閉じ困り、本当に安定なものを使ったことが無いから理解できない。 まともに動作しないのに高く評価すると言う弱者同士で褒めあう協同機構が
オープンソースに他ならない。
大したものをべた褒めして、中国が多額の寄付を渡す。
そうやって、プロプライエタリ文化を破壊しようとしている。 >>206
俺Linuxで開発してクロスコンパイルして
バイナリはWindowsで動かしてるよ
極めて安定している >>206
Android安定してないか？落ちないだろ？
もちろん他の有体物並みには壊れるが
カーネルに不具合があって落ちるということはほとんど聞かない
ビルドしているのはgcc >>209
信頼できる筋の調査でも、安定性が低いことが分かってるし、技術力が
最高レベルに高い人も、オープンソース系は不具合が覆いと言っていたし、
自分の経験からも、オープンソース系は不安定だし、バージョン依存性がきついし、
すぐに動作不良を起こして、次々に新しいバージョンを強制させられるし、
あなたよりよっぽど信頼性が高い情報。
実際に実用的なものを作ろうとしてみれば分かる。
依存関係がめちゃくちゃスパゲッティーであり、不具合が絡まりまくっている
ということが。 ラズパイとかでお気楽お手軽開発できるのは良い時代になったものよ
デバイスそのものの値上がり酷いが >>210
そのバージョンだけでは割と安定だが、バージョンを越えるとすぐに問題を来たし、
以前のバージョン用のアプリは、新しいバージョンのOSでは動作不良を起こす。
だから、GooglePlayにおいてあるソフトの何割かは、動作不良状態にある。 >>205
まずは、人間で一番重要であるところの、「生存する」というところから出来て無い。
そんな国が、真実を語れるわけ無い。 シンギュラリティによりC++不要の時代へ
すでにソートアルゴリズムやハッシュ関数の高速化に成功
https://gigazine.net/news/20230608-alphadev-sort-algorithm/
世界中の研究者たちによって何十年と改善され続けており、すでにこれ以上ないほど効率的な実装となっていました。
しかし、人間による改善活動は主にC++のコードレベルで行われています。C++で書かれたコードは、実際にコードが実行される前にアセンブリ言語にコンパイルされ、その後アセンブラによって機械語に変換するという手順を踏みます。DeepMindの研究チームはこの「アセンブリ言語」レベルであれば、C++のコードからは見つからないような改善点が見つかると考えたとのこと。 >>214
カーネルの話をしている
落ちないだろ？ >>214
補足すれば、それを左翼大家である Googleは、アプリ作者のせいにし、
新しいOSでテストしたものしか認めないような方針にしてしまった。
つまり、自分の技術力の無さを、個々のアプリ作者のせいにしてしまっているのだ。
オープンソースは、そういう文化。責任を他者に押し付けたり、技術の無さを
他人のせいにしてしまう。 >>219
UNIX系のツールにすら適応できてないので説得力がない
ここはRustスレなのでRustでカーネル書いてみ？
みんな喜ぶよ >>220
喜ばれたくなんて無い。おまえらは左翼どうしでマネーを寄付しあってろ。 >>218
いやw不勉強で適応出来ない開発ツールのユーザに責任がある 誰でも作れるなら再発明しないでオープンソースを享受すればいいのに >>221
お前には落ちないカーネルの開発は出来ないと思うよ
mingwなのかcygwinか知らんが開発ツールも使えないんだろ？
Linusはgccで開発しているよ！ >>223
そんなことすれば、LinusやGoogleやアメリカのMITやハーバードなどの権威を
高めてしまうだけだ。 >>224
お前が出来ないから、他人も出来ないと思うな。
低レベル！ 金持ちが嫌いだからみんな苦労しましょうってアホかいな >>226
開発ツールも使えない人がどうやって開発するのかな？ >>218
googleって年間760億ドル利益を上げているんだよ
あなたも新しいビジネスモデルに適応しなよ
マイクロソフトにはもう誰もなれないよ >>228
非常に狭いオプションと環境だけ使ってれば使えるようなコンパイラだといっているんだ。
Linuxを何度も試してみたが5種類くらいテキスとエディタがインストールされていたが、
どれも不安定でそれぞれにバグが有り、試してバグが出たら、別のを起動し直して編集
しなおす、ということが必要だった。しかも安定したエディタがひとつも無く、
どれも少しずつバグがあった。 >>229
Googleは、ほぼ広告ビジネスだけしか収入源が無く、それしか成功して無いと
聞いている。しかし、独占禁止法違反を繰り返し、磐石の地位を気付いている。
ずる賢いアメリカ政府は独占禁止法違反を適応しないので、いつまでも、
悪さをする企業が存続し続けているだけ。 Androidも音関連が全然駄目で、遅延が異常に大きかった。
DirectSoundよりずっと後発なのに、DirectSoundレベルのAPIも持っておらず、
独自の馬鹿が考えたとしか思えないAPIしか持って無かった。
だから、良い音ゲーや音楽ソフトが作れない。
また、同じCPUでは、Android OSは、iOSより遅いことが分かっている。
それは、Googleの技術力の無さである。 >>230
> 非常に狭いオプションと環境だけ使ってれば使えるようなコンパイラだといっているんだ。
この結論に至った経験を詳しく書いてみ？
ちなみにgccはターゲットとしている石が最も多い
エディタは何を試したのかな？ >>231
新しいビジネスモデルに適応しな
もう誰も新たなマイクロソフトにはなれない世界だよ
貴方の憧れていた世界は過去のものだよ
戻ることはない >>194
他のやつと大して変わらんぞ
freezeして吐き出せるのだから
君こそpython使ったことないだろ >>233
ターゲットが多いゆえに、大部分のオプションが動作不良を起こすため、
ほとんどのオプションが混乱を招くだけで意味の無いものと成っている。
しかも、-L dir や、*.o や、-lxxx などの書く位置によって、大幅に
動作が変わってしまう。WeakExternal がまともにサポートされておらず、
それを、Windowsのせいにしている。実際は、自分達の調査能力が
低いだけである。 gccの説明を読んでも、x86 や、x86_64 では全く関係の無い話が多く、
混乱を招くだけである。ドキュメントの大部分は全く関係無く、読むだけ
無駄である。 >>237
それも、左翼思想が背景に有る。それは、デファクトスタンダードを認めず、
弱小で全く人気の無い CPU や OS に関しても「悪平等に」扱うためである。
今、パソコンやモバイルで、有名な環境は 5 種類くらいしかないにもかかわらず、
ソースに現れるマクロスイッチが、100種類を越えるくらいの聞いたことの無い
知名度の無い環境のものとなっている。環境の名前なのか CPU の名前なの
かもさっぱり分からないので、単独の人がソースを解読することが不可能となり、
それも不安定要因になっている。
どの #if 文の中がコンパイルされるのかすら分からないので、論理を負うことが
できない。それは、論理力の不足や頭の悪さから起因するのではなく、
誰も知らないような弱小環境のためのマクロスイッチを大量に埋め込んで
しまっているからである。
それが、オープンソースの実態である。
つまり、デファクトスタンダードを無視し、次々に現れる弱小環境/弱小CPU
を「平等に」扱うことによって、本当に実力の有る人まで真の実力を発揮
できないような世界を作ってしまっているのである。 具体的な話が一切出てこないフワフワした話ばっかしてるな
コード書けるやつはおらんのか？ ずるい仕組みで作られたものは、当然、その報いを受けるべきである。 >>153
>>155
ほんそれ
判ります
staticおじさんだとしてもプロの眼とオプソのアマチュアとの違いを感じる >>152
何が必要かもすべてドキュメントに描いて有れば信用出来るかな >>180
coff とか omf とか elf とかの区別付いてないんだろうな
いい年して今までどうやって生きて来たんだろ
下請けに丸投げして責任取らないタイプの人かな >>182
pip uninstall ってもう出来たっけ？ >>236
-lxxx は *.o を挟んで二回描くのが常識
-lxxx hoge.o -lxxx
だ >>238
>環境の名前なのか CPU の名前なのかもさっぱり分からないので、
>単独の人がソースを解読することが不可能となり、
>それも不安定要因になっている。
その「環境の名前とCPU の名前が分からない」原因が
自分にあると考えないのが不思議でならない
>誰も知らないような弱小環境のためのマクロスイッチを大量に埋め込んで
>しまっているからである。
自分の限られた知識で巨大なソースコードを読むことに
あなたが慣れていないんだと思うよ
それと「不安定」ってのは具体的に書かないとな
gccはAndroidのカーネルのビルドに使われているんだよ?
極めて安定していると思う 文章から推測できるでしょう
5chに居ながら、。を多用してる時点で対応力は期待できないんだ
推定over70下手したら後期高齢者のお爺さんにとやかく言っても無駄だと思うけど… >>244
それはさすがにできるやろ
できない時代を知らない つかえるもんはつこうたれという図太さが欲しいよな(自戒 UNIXがLinuxだけだと思ってたり
UNIX知らないのにCygwinやMinGW使おうとしたり
色々残念なのは伝わってくる 左翼が全て悪い，アメリカは日本に劣ってる
こんな短絡的な発想するやつ，どんな環境で育ったんだか
まぁ結論ありきで喚いてるのはわかった ここは、Rustの欠点も、gccの欠点も、完全否定されるだけの悪いインターネット。
C++を悪く言っても完全否定はされないのに。
俺は知っている。オープンソースのソフトの欠点を指摘すると全否定されることを。 このスレでも、
「他の人は普通に使えてる、不安定だと思うのは、お前が使いこなせないだけ」
などという人がいるが、じゃあ言うが、現れて5年以上、本も多数出ているのに、
ランキング20位、使用者数 1% 以下の言語は、実力がその程度だから、と言えよう。
結果がすべてなのであれば、そういう結論にならざるを得ない。
決して、「顧客が馬鹿だから」「老害が多いから」などというべきではない。
もし、「結果が出て無いのは他の要因があるため」などというのであれば、
「不安定なのだって、実際に、その環境では不安定」であることを認めなければならない。
なぜなら、世の中は複雑で、そんなに単純ではないからだ。 重要なのは実行の速さと省メモリ
これはコストに直結し電気代さらにCo2排出にも影響する
C++とRustのみがこれを満たす実用的なプログラミング言語 このスレでRustサイコーって言ってるヤツは何らかの意図があるんじゃね？
だってめっちゃ不自然だからｗ そんなすぐみんなが移行できるわけないやん
そんなこともわからんて仕事したことある？ >>257
プログラマなら具体的に書きなよ?
ソースコード書いてるんでしょ?
貴方の書き込みはあやふや過ぎるので議論ならんのだよ
ソースコードもあやふやなのかい? スクリプト言語はスクリプトを書くには向いていてジャンルが別
プログラミングするならC++かRust >>257
ちゃんと人が読めるように段落とか区切って >>81
に書いたが、
YouTube で有名な雑食系エンジニア・KENTA は、
初心者のキャリアパスは、Ruby on Rails → Go だけと言ってる
Rubyの米国年収は9.3万ドルで、Go/Rust/Elixir の3大言語を超えた。
一方、Rust/Elixirは普及のキャズムを超えなかった。
超えたのは、Goだけ
最も好きな言語が、Elixir/Rustとか言うけど、こういうランキングは意味ない >>262
具体的も何も、結果が全てというなら、普及率がさんざんな結果になっているRust
は、それが全て、といことになるということだよ。
結果がすべてであるなら「良い言語なのに使われない」なんて余地は存在しないはずなのだから。
金持ちは頭がいいから、貧乏人は頭が悪いから、経済が悪いのは国民が
頭が悪いかサボっているから、氷河期世代が駄目なのは彼らがサボっていたから、
などという短絡的な見方しかしてはいけないことになる。 「現状が全て。自信があるのに現状が輝いていないのは自己認識が間違っているから」
のような説を当てはめれば、Rustは自己認識が高すぎる自信過剰なだけの実力が
無い言語、ということになる。 >>267
雑食系なんたらってコピペBOTと信じて疑わなかったけどもしかして人が打ってんのか？
信者？ 知らん人の断言聞かされても反感買うかおかしいやつと思われるだけだぜ >>246
アホぬかせ。
いくつかのプラットフォームでのコンパイラのバグを回避するために
「x + 1」の変わりに「x + SIZE_T_ONE」
#define SIZE_T_ONE ((size_t)1)
などというアホ丸出しのマクロが使われているんだぞ。 単なる荒らしだからケンタとか適当に出してるだけだよ
釣られまくってるやつは反省しなさい
ワタクシがインターネットリテラリーを教え込んでやる
荒らしの手法を20年研究してる俺は全てわかる 「Rustが全く普及して無い事が、Rustが糞言語である証拠だ」
という結論になるわけですな。
「結果が全て説」を採用する限りにおいては。 世の中には「この商品は良いのに、客が馬鹿だから売れない」などという
態度に出る赤字経営者がいるが、それは間違いで、
経営論的には、お客さんにほとんど買ってもらえて無いのに、商品が良いなんてことは
言えない。
Rustは、無料なのに使ってもらえてないんだから、それを優れていると
思い込むのは、万年赤字駄目社長ということになる。 15年前のプログラミング言語製品が中古市場で、未だに一万円を超える価格で
取引されている。一方、Rustは、無料なのに0.5%位しか使われて無い。
それは一体どういうことか考えよう。Rustが優れていると言う認識が
果たして正しいのかどうか。 >>271
イマイチよくわからんがそれ不安定なの？
そのコードの意図を説明してくれ
なぜ不安定なのか
その理由を聞いて判断したい
君の思い込みかもしれないからな もっと言えば、ある言語では、15年前の開発環境が、未使用品なら5万円でも売れて
いる。
それに対して、Rustはなんという惨状か。
だから、信者と呼ばれるのだ。
特にオープンソース系でこの病は良く見かける。 >>276
コメントにそう書いてある。
/* Some constants coerced to size_t */
/* Annoying but necessary to avoid errors on some platforms */
#define SIZE_T_ZERO ((size_t)0)
#define SIZE_T_ONE ((size_t)1)
#define SIZE_T_TWO ((size_t)2)
#define SIZE_T_FOUR ((size_t)4)
/* The bit mask value corresponding to MALLOC_ALIGNMENT */
#define CHUNK_ALIGN_MASK (MALLOC_ALIGNMENT - SIZE_T_ONE) まぁそもそも現実問題としてRustへの移行の圧力は言うほど大きくないかもしれんな
Rustの売りはメモリ管理
そもそもノイマン型のコンピュータだと不定長のデータを扱うのはかなり難しい、どうやってもメモリ確保していらなくなったら解放してを繰り返すと使えない領域がどんどん増えていく、いわゆるフラグメンテーションの問題
まぁこれが問題なのは間違いないし、GCというのがあまり褒められた対策でないのも確か
しかも従来型のGCだと基本GCの間はメモリは使えなくなる、いわゆるギャページコレクターとメインプロセスの間で競合の問題が発生してしまうから
これらの問題を解決するにはプログラミング言語の側のメモリアクセスの方法を見直す以外に解決策がないのは確か、すなわちそれは「今までのようには自由にメモリにアクセスできなくなります」という新しい縛りを導入しない限り不可能
Rustはこの問題に対するひとつの答えを与えようと頑張っているわけだけど、しかしそもそも解決するって言ったって今まで自由にしてきた事をできなくするわけだからそりゃ嫌がられるわな、新しいルールや概念持ち込まれるわけだから
当然「その問題そこまで深刻か？今でもちゃんと動いてるやん？なんでそんなルールに縛られんといかんの」となるわな
結局「GC上等、何がいかんのじゃかかってこいや」という声が消える事はないし、当然みんながみんな新しいメモリ管理方式を受け入れるなんて事はないやろ
おそらくごく一部のOSの開発者とか相当シビアなメモリ管理を要求される環境下で動作するシステムとかかなり限定的な場面でしか浸透しないんかもしれんような気はする >>275
ここに皿があるとしよう
ある人は「なんだこの汚い皿は！いらない！捨てなさい」と言って捨ててしまった
しかしある人がゴミ捨て場でこの皿を見たところ
「景徳鎮の皿だ！国宝級の皿だ！なぜこんなところに落ちているのだ！すぐに私の事務所に持って帰れ！」と言った
プログラミング言語もこれと同じということよ
>>278
いやそれだけじゃわからんだろ
annoyingの理由が書いてない
単なるsize_tマクロの定義の問題な気がするがそういうのはCでは普通にあるぞ
あるシステムのマクロが被ってたり定義が違ったり
コンパイラのバグというよりわかっちゃいるが歴史的経緯のために変えられないというのが正解
だからautoconfのようなものが存在している >>280
後半、ちゃんと書いてあるじゃないか。
もしかして英語が読めないのか？ >>278
そんなゴミをのような
定数のない古い時代のものをさっさと捨てて定数を使えよ >>282
俺に言うなよ。
これは、dl_mallocのソースコードで、
オープンソース界隈ではこれが最高に良い allocator だと賞賛されているんだから。 そこのプログラミングの現実を知らない人、ゴミが賞賛されるのがオープンソース世界
なのがやっと分かったか。 >>284
お前は頭の悪さを自覚しろよ。
正しいコンパイラなら、この場合の1と((size_t)1)で差は出ないはずなんだよ。
それが出てしまうと言うのはそもそもコンパイラがANSIに準拠して無いことを
意味する。 まあ多分今ならそのマクロ消しても動くと思うよ
昔の環境でsize_tの範囲がおかしいとかそういう内容だろうから
それを持って不安定というのは的外れ過ぎる
もっと根本的にやばい話なのかと思ってたがこの程度なのかよ
くだらない >>287
アホか。こんな程度の問題じゃないわ。
もっとあらゆる場面で不安定だわ。
gccの不安定さはきわまる。 せめてそのマクロが定義された理由くらいは見つけてこいよ
古いメーリングリストとかにあるんだろ それ以前に#defineのような衛生的でないマクロをさっさと捨てればいいのにね
せめてRustのように副作用のない衛生的なマクロを導入すべき >>287
先日も指摘しておいたが、オープンソースは左翼思想なので、
質の悪いコンパイラも平等に扱おうとするから、そういうマクロが必要になる。
そして、そのように弱者救済の様なことやっている俺って素晴らしい、と
彼らは悦に浸っている。 バカがC++やRustを使いこなせるわけないんだから普及率なんてどうでもいいだろ >>294
しかし、CとC++を合わせた使用率は、プロに限定すれば全言語の中で TOP だ
という調査結果も出ている。 何で普及率の話になってるんだ？
こいつはスレタイ読めないのか？ >>296
「結果が出せてないのはお前のレベルが低いからだ」
みたいなことを言う人が出てきたから、それをRustに応用してみただけだ。
ブーメランというか、法則のユニバーサル適用。
そうでなければダブルスタンダードだ。 プロなら当然C/C++もしくはRustといった限界を引き出せるプログラミング言語を使える必要があるから100%だろうな 「良い」という意味を深く考える必要がある。
一部の人に受けが良いことをもって「良い」と言っていいのかと言う問題。
普及して無いと言うことは、広く一般には良いとおもわれてないか、
経営理論的には何らかの弱点があるからと考えられている。 それに、オープンソースのAndroidは、OSもハードも安いはずなのにiPhoneに
負けている。これも、何らかの欠点を見出して消費者が選択した結果だ。
つまり、オープンソースは勝ててない。
それにプログラマ目線だと、オープンソースに良い経験を受けてない。
今までの総体として、オープンソースソフトに不快感、不安定感、手間がかかる感、
時間を奪われる感、すぐ変化して自作の過去の遺産が壊れる感、などをもって
いるから、忌避されている。 >>297
Rustのように次々と結果を出していってる言語は珍しいよな
新興言語にすぎないのに各OSにクラウドなどインフラまでもが次々とRustを採用
C++は邪道だと頑なに採用を拒んできたLinuxもRustに対しては採用OKを出したことも象徴的 >>301
Rustは、githubで2.1%、tiobeで0.9%
一方、CとC++を合わせると23.7%位で、PytonやJavaの約2倍に達する。 もういいよ
お前の戯言は聞くに値しないことが上のやりとりで全て明らかになった 言語そのものでもRustには、多数、問題が有る。
Rust信者は、指摘されても納得しないだけだ。 普及率なんてどうでもよくね？
良いものを使ったほうが得
それがすべて
大手IT各社も各OSもその判断をしてRustを採用している >>302
やることが決まってるカーネルにC++とか要らん、とかいうことだったらしい
あの頃のLinusは口が悪かったが、まあ、そういわれたらそうかなと >>302
Rustでビルドしたオブジェクトって
Linuxカーネルにどうやってリンクするの?
Linuxってclangでビルド出来た? 世界だと
Android72%
iOS26%
日本国内は
Android32%
iOS67%
そもそもシェア率と良し悪しが連動してないと許されないのであれば世界は一つの製品が独占してしまうわけだし、恥をかいたところでこの話の持って行き方は辞めようか も一つ付言するとオープンだとこうやって突っ込めるが
プロプライエタリな製品だと誰も見ることができない
>>278は意図が分からんので置いておくとしても
プロプライエタリな製品にクソコードがないとは言えない >>297
Androidの方が普及しているよ
お前さんは開発ツールもろくに扱えないのにも関わらず（他の人は出来る）
落ちないカーネルを書けると言う
>>226は本当かね? まぁ普及率という話ならRustがCやC++みたいにはやっていく感じはせんわな
確かにRustのメモリ管理はなるほどだけど、現行のメモリ管理方式(と言っても事実上なにもしない方式だけど)でもまぁちゃんと動くしな、ちゃんと今でも動いてるのになんでそんな小難しい概念もっかい勉強せんといかんの？マンドくさい、それ美味しいの？ってなるわな
流行るわけない
それ勉強して新しいメモリ管理の方法勉強して今までの方法では出来なかった事が突然できるようになったりはしない、安全性、信頼性、保守性とかいうジミーな違いしか出ない
まぁ流行らんわな 新しい言語に対して普及率でしか叩けなくなってる時点で
まるで自ら敗北を認めているようなもの 月曜午前2時～3時が一番ヒートアップしてるな
ニートしかおらんのか >>310
調査の観点が異なるものを端末シェアかのように扱うのは間違い
特定サイトにおけるユーザーエージェントベースの調査と実際の端末シェアにはかなりの乖離がある >>317
どの調査を見ても日本国内ではiOSが多く
世界全体で見るとAndroidが多い
文意に違いはないと思うよ >>317
お前が大人しく意見を取り下げられるように言い回しに配慮を乗せたのを読み取ってくれ 自分はRustはコードを書いていてCやC++に比べてメモリ管理が圧倒的に楽だし、文法も分かりやすいから普通に好きだけどなぁ。まあ、自分はまともにコードを書けるのはC,C++,Python, Rust, Javascriptくらいしかないけどね。 >>315
このスレデは、古い言語に対して老害としか叩けなくなっているんだが。 【新語辞典】
若害:
「若くて何も知らないゆえに、人に迷惑をかけること」 >>318
世界市場に比べて日本市場はiOSの割合が顕著に高いのは事実だが
端末シェアは日本でもAndroidの方がやや高いよ
ざっくり言えば半々
7:3みたいなとんでもない数字出したらガベージインガベージアウトにしかならない SNSを見ていると、Rust信者はプライドが高い人が多い。
確かに一定水準のものは出来て入るが、だから何？
Rustで作ったから偉いとでも思ってるのだろうか。 他の人たちなんか気にせずに
便利で高機能な好みの言語を使えばいいよ
便利で高機能な言語としてもRustはベストな言語の一つであることは間違いない
さらにRustはおまけとして高速省メモリが付いてきてお得でもあるし
様々な安全性や堅牢性もおまけてして付いてくる >>326
自分で作ったものを自慢するなら多少ウザくても実力は認めざるを得ない
しかし現実は… >>327
良い部分だけを書けばそう書けるかもしれないが、それは俺の感覚には合わない。 >>326
高いよ
高くなると言った方が正しい
「正しいエンジニアリング」をしているという感覚が強くなりすぎて
ゴミな他言語を使ってるやつを全否定してしまう
もちろん表には出さないが(異常者と思われたくはないので)
内心はそう思ってるので漏れ出てるのだろう 「ゴミ」「老害」「クソ」「オワコン」と言う言葉も人を傷つける
言葉なんだよなぁ。
仮に優秀だとしても、このような言葉を使う人は人間性に問題が有る。 >>327
ADHDってとにかく周りと比べたがるらしいよ
自分の使ってる言語が劣っているから悔しくて荒らしているのだろう Rustには、改良点が有ることはあるが、改悪点も有るのに、それには触れないんだよな。 >>320
まともにコード書ける人がこんなこと書くわけがない
メモリセーフの意味すら理解してないじゃんか
632 デフォルトの名無しさん[] 2023/06/12(月) 12:58:17.77 ID:oql3AWnL
ただの思いつきだが、CやC++はメモリセーフではないだろ。ってことはプログラム中で結構無駄なメモリを消費してたりしないの？Rustはそこの所最適化されてるから究極的にはRustの方がCやC++よりも高速に動作するのでは？ C++はわりとなんでもかんでもヒープに置くから、当たらずとも遠からずｗ Rustのenumも大きさが不揃いだと無駄なメモリ消費するから最適化されてるとは言い難い
中身をBoxに入れればいいんだけどこの流れでヒープ使うと文句言われそう let a = vec![0u8; 8];
let mut b = vec![0u8; 8];
let hoge = &a[0] as *const u8;
let fuga = &b[0] as *mut u8;
let moge = hoge as *mut u8;
Rust の unsafe って C++ の const より緩いんじゃね >>268
これからの日本は
「DQNの子沢山」
という言葉がぴったり >>274
特定の層にだけ普及すれば良い
裾野が広いことが常に良い事ではない unsafe は決して天下の印籠ではないな
見ざる🙈言わざる🙊聞かざる🙉
臭い👃ものにフタしてるだけニダ safe部分をRustコンパイラが保証してくれるから人間頼みの必要がないところが肝となっている
そして通常のプログラムにunsafeは出てこないのでコード全てをコンパイラ任せにできる
事情によりunsafe部分があってもそこだけを厳重に監視して人間が保証すればよい >>345
Nimはpythonのライブラリにアクセスすると途端にスピードPython並みになってしまうのでは？と、思ったので自分は途中でやめた。 >>271
コンパイル以前にプリプロセッサで処理されちゃう程度のもんだと
思うけど、コンパイラのバグでこれがどうにかなっちゃうの？ なんでもかんでもintだった名残の一種だろ、そういう牧歌的な時代もあった >>336
C++だってその機能を全部使う訳じゃなくて敢えてbetterCとして使うことも多い
Rustだってメリットの部分だけ使う手もある >>348
C++もRustもPythonのライブラリにアクセスすると途端にスピードPython並みだが >>347
>通常のプログラムにunsafeは出てこないので
都合の悪い部分を観えなく(観なく)して済ませてるだけでは？
>unsafe部分があってもそこだけを厳重に監視して
観えないところでunsafeが暗躍しまくってる状態でも？ >>352
Nimの長所って文法が楽でpythonやC,C++のライブラリへのアクセスが容易で、素のスピードも速いって点だろ。ただ、pythonのライブラリにアクセスすると速度がpython並みになるのでは結局C,C++のライブラリへのアクセスしやすさ以外は大した利点として残らないように感じるってこと。純粋なNimのみで構築されたライブラリってそんな多くないし。 nim使う奴の大半は記法目当てだろ。
pythonとかc++のイビツな記法を捨てられるメリットはデカイ。
いっそのことpythonの中にnim記法モードを用意して欲しいわ。 なんでコンパイルしないの
もしかして本質的に作れないの 零細だからな
そしてNimはトレーシングGCを避けると
リファレンスカウンタが本質的には不要な場面でも使われうるため
いずれにしてもC++/Rustの速さを出せない 各種言語のInterOPを書きやすいのはトランスパイラの利点ではあるけど
そういう用途で使われてないのが現状 あほ: 石橋を叩かずに渡る
大あほ:: 石橋を叩いて壊す
慎重派: 石橋を叩いて渡らない
頭脳派: 石橋を叩いて他人に渡らせる 石橋を「ポインタ」に置き換えると…
…あほが正解になる不思議! (哲学 fn safe_func() {/*Cのライブラリを使い倒す*/unsafe{...}} 部品をオープンにすれば部品毎に競争や自己責任が生じる
逆に部品を情報隠蔽すれば連帯責任しかない
C++とRustはスマポを部品化したから、不要なら使わない自由がある unsafe 便利過ぎて Rust だぁぃ好き💛♡(⋈◍＞◡＜◍)。✧♡
になりました C++でもコメントにunsafeって書いとけば同じことだぞ なぜ Windows Server は絶滅したのか？ [
https://gigazine.net/news/20230615-jim-keller-tenstorrents-interview/
オープンソースが勝つと信じています。
人々はLinuxに切り替えたら、誰もNTやOS 360に戻りませんでした。
これは一方通行です。 カプセル化と継承がなかった時代に戻ればいいのに
戻ってないって言いたいだけのために関数型に転進した説が出てくる 関数型言語のメリットが理解出来ない池沼とか実在するの？
釣りだろ 例えばCopyとCloneの対立がない状況を理解するには対立を知る必要がある
が、知る必要がないこと自体がメリットだとしたら 別に関数型だからカプセル化が出来ない訳でもないし
継承はデメリットが多いから委譲に主流が移っただけ >>367
オープンソースの勝者は、巨大テック企業のGoogleやAppleなどに
限られる気がする。
「水源の枯渇」現象(富が入ってくる場所が消える)が起きるから。
ハードウェアはまだ、「工場」や「生産設備」「製造機械」
「機械の操作能力」で差が付けられるから、オープン化しても
なんとかなりそうなものの、それですら、Androidで儲かって
いるのは、韓国 Samsung だけ。その Samsung も中国勢
に押されて業績悪化していると聞いたし。 g++もrustcもタダで使ってるのにまだ自分が勝者ではないと思ってるのかね
自虐にもほどがある >>374
PC/AT規格をオープン化したところ、台湾の自作機用マザーボードメーカー
だった Asus や Gigabyte, MSI などだけが儲かり、
日本のパソコン業界は壊滅状態になった。
そして、さらに、IBMがパソコン部門をLenovoに全て売却しNECも、
同様にLenovoに委譲し(?)た。そしてなぜか、その Lenovo ですら
業績悪化し、困っていると聞いた。
オープンソースOSのAndroidを見ても、Sony, Sharp, FUJITSU, NEC
など、ほとんど壊滅状態に近く、ほとんど儲かって無い。Sharpは
倒産して中国に買収されてしまった。
過去の例で見ても、「MSX規格」も、多数の企業が参入しすぎて
儲からなかった、と聞いている。
一見、オープン規格と相性の良さそうに見えるハードウェア業界においてすら
このような状態。ソフトウェア産業とオープンソースは相性がとても悪く、
富の水源が完全に枯渇してしまう。
なお、Googleは、ソフトウェア企業ではなく、巨大データセンター + 広告
の企業だ。 >>375
何を言ってるの。
100円ショップのものを有りがたがっている日本人なんて存在
してない。
それと同じ。
産業が潰されて、困ってる人の方が多い。 あの、これさ…脱構築されて困ってる人が多い…と言った？
もしかしたら・・・ Lenovoは、売上高が2兆円もあるのに、利益が600億円しかない。
しかも、パソコン部門は34%減の減収。
経営論的には、売上高が大きいのに利益が少ないのは、危険状態だと聞いた。
なぜなら、それは手間ばかりかかっているのに、儲からない、非常に
メンドクサイ状態だからだそうだ。
オープンソースの先方でありそうな Lenovo は、このような状態。
結局、オープン化によってパソコンが儲からないものになってしまった。 あまり大したことはしてなくて計算結果もそれらしい正しそうな値が表示されるのですが
正常に終了(しているように観える)するときと
結果を表示した後にpanicして終了するときがあります
実行するたびに上のどちらかになります
gmpを呼ぶのがunsafeだからだと思うのですが
panicの犯人がどこにいるか調べるにはどうすれば良き？
https://wandbox.org/permlink/3KFAdQezjDCRJCJ0
// https://crates.io/crates/rust-gmp を使用
use gmp::mpf::Mpf;
use std::ops::Div;
fn from_si(si: i64) -> Mpf {
let mut f = Mpf::new(512);
f.set_from_si(si);
f
}
fn main() {
let mut t = from_si(0);
for k in 1..=40000 {
t = t.add(from_si(1).div(from_si(k).sqrt()));
}
let mut exp: i32 = 0;
let s: String = t.get_str(0, 10, &mut exp);
println!("0.{} e{}", s, exp);
} PCがオープン化される前にIBMやNECが殿様商売やってたの知らんのか？
彼らは得た利益を国民に分配なんてしてなかったぞ
これじゃあ規制できないねえ、さてどうする？ >>380
動かなかったから手直ししたらこれになった
malloc(): corrupted top size
中止
panicですらないSIGABRTなのでC++でやってたようにlldb/gdbでがんばってね オープンソースって所詮は弱者の戦略だからな。絶対的な強みを持ってるAppleとかはほとんどやってないよね。逆にMicrosoftやGoogleですらオープンソースを推進してるならこいつらの強さは相対的な強さでしかなくて思われてるよりも立ち位置が不安定ってことでは？ >>381
パソコンハードウェアがコモディティー化しているのはしょうがない。
しかし、最先端のソフトウェアが世界のTOPレベルの大学の学者や学生
が補助金や研究費で作られているのに無料化しているのは、
それとは全く異なる。 >>382
でも、NECやIBM以外のメーカーからちゃんとパソコンも売られていたので
殿様商売とは言えなかった。
競争の結果だ。
しかも、多数の企業がちゃんと競争に参入できていた。
今は、ソフトウェアを売る事業には、アメリカのテック企業以外が
全く参入できない。 >>384
Appleは、clangで大々的にC++コンパイラをオープンソースで
イリノイ大学に開発させている。 「コモディティー化」を安易に使う人がいるが、おかしい。
それだと、無料化されてしまっているものが、なんでも「コモディー化」
の結果だと言えてしまう事になる。
問題は、時代の最先端を言っており、今後の最先端であり続ける可能性
が高いものが、無料化されていると言うことだ。
自動車などは、100年前の技術、テレビなども50年前の技術で、
基本的に技術的変化が少なすぎるからコモディティー化するのは仕方が無い。
ところが、物凄い速度で大幅に改良が続けられているものが、無料化するのは
おかしい。 >>385
ハードウェアがコモディティ化して利益が上がらないのを
オープンソースと絡めて書き出したのは（>>374,376）
お前（TBj+uqoQ）だろうが?
お前さんの主張は
かつては市場があったが最早市場がないところで
商売できないと駄々こねているだけだよ
新しい戦略に適応しな >>388
俺がコモディティ化と言っているのはハードウェアだ
よく読め >>389
ハードウェアがコモディティー化するのは時代の流れだから
しょうがないんだよ。
問題は、コンパイラなど、まだどんどん改良が進められている
ソフトウェアが無料化されてしまっていることだ。 >>388
ソフトウェアのハードウェアとの最大の違いはコストゼロで複製できること
この性質があるからハードウェアでは成立しないオープンソースが
ソフトウェアでは成功した
この辺もかつてRMSは言及している >>392
だから、それがアメリカ以外のソフトウェア業界を苦しめている。 >>391
ハードウェアの話をしだした（>>374,376）のはお前（TBj+uqoQ）だ
間違えていましたとまず訂正したまえ >>393
RMSがターゲットにしているのはプロプライエタリ製品全てだよ
米国もそれ以外も全てが対象
そして私もあなたも>>375の言うように恩恵を受けている
RMSが変えてしまった世界にあなたは駄々をこねずに適応しなさい >>394
リンク先のサイトも、RISC-V CPU というハードウェアを念頭に
おいているように思えたから。
(時代錯誤の)そんなものですら問題を生じる、と言いたかった。 >>395
俺は、g++やrustcも全く使ってない。
ゴミ。 >>397
今やコンピュータ制御された製品に
オープンソースのソフトウェアが
使われていないものを見つけるのは難しい
g++やrustcを使っていなくても
あなたは必ずRMSの恩恵を受けている >>398
メリット1に対して、デメリット100000000 >>399
まずあなたは携帯電話を用いないこと
インターネットも使用しては駄目だ
レスを禁じる オープンソース信者はカルト。
人に大迷惑をかけても
「神に喜ばれることをしている」
などとと思い込んでいる。 >>401
なぜそんな風に考えるのか根拠を書いてくれるかな?
単に思い込みで書いているのなら直ぐに撤回した方が良い >>401
オープンソースのソフトを使って
5chに書き込んでんじゃねーよ >>402
そもそも、「全ての人に良いソフト生産行為」なんて存在し得ない。
誰かにはメリットでも、誰かにはデメリットになる。
それを大々的に無料で推し進めるのは、ファシズムみたいなものだ。 >>403
それしか存在しないからだ。
勝手にアジアを植民地化して、戦争になったら原爆落としておいて、
「原爆落とした結果の世界の恩恵を受けているくせに
何を言っているの」
みたいなことをいうアメリカ人と同じ。 >>405
お前はプログラマだろ?
RMSから恩恵を受けないと宣言して自分で作成せーよ 見ててやるからOSS規制を掲げて国政に打って出ろよ
グズグズせずに今すぐ行動しろ >>404
誰も強制してはいない
自由競争の結果だよ >>388
>物凄い速度で大幅に改良が続けられているものが、無料化するのはおかしい。
大半は本当に「改良」なのかどうかすら怪しい改変ばかりだぞ ブラウザが無料である事は、有料ブラウザを売って暮らすと言う選択肢を
なくしているわけだから、収入の「水源の枯渇」に他ならない。
ブラウザだけでなく、ワープロ、表計算などのあらゆるOffice製品も、
Googleは無料化を推し進めている。
その財源は、彼らだけしか持ち得ない「打ち出の小槌」である
広告料である。
競争が全く生じ得ず、新規参入も不可能。 >>409
強制されている。
また、真の意味の自由競争ではなく、ドーピングの結果に過ぎない。 >>413
そっちは独占によるドーピングが施されている。 >>412
強制されていない
プログラマなら1から自分で作れば良いのでは? >>414
他人に説明するときはドーピングなどとアヤフヤな言葉を使わない
使うならばまず定義してくれ
サッパリ分からん >>415
作っても売れないから不可能。
オープンソース運動によって「水源が枯渇」されてしまっているから。 >>417
自分の使う分の話だよ
オープンソースの利益を享受していたら何も説得力はない
他人が書いてくれたものは無料で使っておいて
自分の利益を主張してもガメつい人なんだなとしか思わない >>418
何を言っているの。社会がそれを使わないと生きていけないような
構造になっているから、使わざるを得なくなって使っているだけで
ブラウザに感謝してる人なんて一人もいないぞ。
所詮そんなもん。
それより、自分が作ったものが「民主的投票行動」によって
買って貰えた方が喜びがずっと大きい。
そしてそれができなくなくしてしまったオープンソース活動家の
罪は無限大に大きい。 OSSを使わずに生きてる高齢者とかけっこういるでしょ KOできないから仕方なく多数決で判定される
多数決を喜ぶ人がいるのがおかしい はやく出馬しろよ〜
ワンイシューでも圧倒的に支持されて余裕で当選だろ
OSS活動家を断罪しようぜ オープンソースを悪用してるずる賢いヤツがいるってことだね >>380
Mpf::new(512); ときどき落ちる
Mpf::new(128); 落ちる確率は512より減るみたい
Mpf::new(64); 落ちない
Mpf::new(32); 落ちない (多分デフォ)
いずれにしても使い物にならんなω >>419
うんうん、ここなら話聞いてもらえるから嬉しいよねw でもオープンソースにこんな問題があるだなんて考えたことなかったなあ 空気中の酸素とか無料だけど文句言わないのかな
酸素企業が潰されてるだろ >>387
そうなのか。まあ、でもGoogleやMicrosoftの規模ではないよね。だってこの二社はかなり多分野でオープンソース化目指してるじゃん。AppleのはMacとios用のC++コンパイラのためかな。でも、Appleはそんなに多くのことをオープンソース化目指してないと思うんだけど。結構、秘密主義の企業じゃないの？ 秘密主義だが、投資もするってことでは それなら整合する 秘密主義者を2人雇ったらどっちが有能でどっちが無能か全然分からない
分からないなら終身雇用するしかない とりあえずオープンソース反対で書き込みまくってる人がいるけど、オープンソースの使えなかったら殆どプログラミングとかできなくね？ >>436
プログラムを作る道具が有っても、肝心の「水源」が壊されて
しまったので、作っても売ることができないので意味が無い。 オープンソースにより、道具が無料になると同時に、道具で作った
ものを売る先が無くなった。これを
「オープンソース化による水源の枯渇」
という。 >>439
それは批判を誤魔化すための常套句。
実際には不可能。 立場を隠して一方的に吠えてるだけなのに批判できてると思ってるのが笑える 水源なくなるとか言ってるけどさ、その道具や標準ライブラリそのもを売るわけじゃ無いのにね 形而上学的リソースが枯渇したと主張しても信用されなくなってきてる
だから炭素の収支をニュートラルにするほうが現実的になった 俺も「光源」が枯渇してるからプロプライエタリは悪だと思うぜ Rustは機械学習関連のRust純正クレートがpython並みに充実してくれば、十分に覇権をとれるポテンシャルがあるきはする。 Linux MintでFirefoxを使っている
FirefoxはRustで書かれているというけどGoogleMapのストリートビューを使っていると
メモリの空きが目に見えて減っていき最後にはハングする
Rustだから良いというわけではない >>450
DOMとかJS周りの話でRust関係なさそう >>450
Firefoxの一部のライブラリがRust製なだけだったような
あれだけ巨大でモノリシックなもの全体をRustにするには長い時間がかかる
一方でモノリシックでないマイクロサービスなど個別に独立しているものは移行が速い
あとは移行ではなく新規案件のプロジェクトはもちろん強い Google Map っていかにもメモリー開放をしなさそう
循環参照もしやるそう
他のブラウザに比べメモリを食いつくすのが早いのだとすると
他の言語と条件は一緒だから Rust での書き方が下手という
結論になるけど
ハッシュの初期値の設定が大きすぎるとかいう可能性もあるけど >>453
Rustは関係ない
Google MapはC++やRustを実行しない
Google Mapが実行するのはJavaScript
FirefoxのJavaScriptエンジンは大昔からSpiderMonkeyでC/C++製
だからRustは関係ない Rustでwebブラウザぐらい作ってみせたらいいのにね どの分野でも巨大なものをすぐに別の言語に置き換えるのは時間もコストも掛かり全く無駄だ
一方で様々なシステムを新たなものにしたり新たに作るならば開発効率の良いRustが採用されていってる
そうやって社会全体でみれば時間をかけてRustへ置き換わっていくのだろう そんな調子では書ける人が一向に増えないので普及とは程遠い状態だろう
知る人ぞ知るマニアの言語の一つになるような気がする >>456
Rustユーザーの裾野を広げるにはゲーム開発用のクレートを充実させる方が有効な気がする。そうすればゲーム開発を始めるプログラマーがC,C++,C#ではなく、Rustを最初の言語に選ぶ確率が上がるし。 >>457
どのくらい迅速に置き換わるかは、C++に留まるかどうかに関係するぞ
どう考えたって、C++にも来るほかないトレンドだし > unsafe
C++にunsafe来る -> そんじゃ勉強するしかない -> できるようになったしC++でいいやもう になる C++にラストの機能がきたところでライブラリが全て追従するわけじゃないでしょう 人気の高いものは漸次追従するっしょ
やってた人はそれなりにうんざりきてるだろうし
>>462
うっせえはげええ まぁ勢いはあるやろな
以降の圧力がある程度以上で業界でRust移行がトレンドになって新規案件でRust採用事例が増えてくればそれが呼水になってさらに移行圧が高まって‥も考えられるけど一方で
安全性何それ美味しいので知らんふり、様子見が大半でどこも移行しようとせず、一向にRust採用事例が増えないなら、仕事もないのに勉強なんぞするかボケになる
そしてこの手の空気というかトレンドというかは全く読めんからどうなるかさっぱりやな 安全性何それ美味しいの、はないとおもうけど
Rust(Dart,Swiftも同様)何それ美味しいの、は言う人いるかもね
モバイルやってなければなおのこと この動画のタイトルと出だし見てMS teamsがtauriになったと勘違いするオッチョコチョイがいるかもしれない
https://www.youtube.com/watch?v=BjQv8-18MW4
実際にMS teamsはパフォーマンス不足を理由にelectron辞めた訳だけど
結果はtauriを選ばずC++WinUI
採用事例をひけらかすのなら、非採用事例、不適格理由も枚挙しないとね
この辺り考察ある？ まぁアナウンスされてる通りコンパイル時点で検出できる脆弱性が増えるとかじゃないの
知らんけど 非採用事例
C++はLinuxカーネルに採用されないからLinuxデスクトップ系
C++はCPythonに採用されないからJavaScript系 >>471=Qiitaから来た偽物か本物の手抜きだな
本物の複オジはRustに見切り付けてJavaScriptフロントエンドを煽り初めてるぞ 「『C++を経験した人』がRustを好きになる」説があるが、
C++を長年経験して大規模プログラムを作ってもも頭が良すぎると
メモリ関連バグに全く遭遇しないのでRustの良さが感じられない。 >>473
何これ？これが複オジの現在形なのか？<ズコー メモリ関連バグの遭遇率や困りさ加減は当然ながら個人差があるもの。
うっかりミスが多い人や、バグが出たときの原因特定や対処が
下手な人にとっては困るが、それが当てはまらない人も存在する。
そして、今まで優秀とされた人は、それらが上手く行っていた人。
上手く行かなかった人は高速なアプリが作れなかったから、良いソフトは
作れなかった。
だからRust信者は、良いソフトを作ったことが無い人が多いはずだ。 頭が良ければミスしないから無視して良いという考え方は
プログラミングに限らずエンジニアリング一般として
排除されるべきものなんだけどね ミスするバカだからRustありき、と言われて、ウンって言えないわな
俺はそんなミスしねーよとしか返しようがないｗ
C++だって、とうの昔から、型チェックだの、assertだのとチェックの恩恵は受けてるんだけどね
Rustが正しいと業界が認めたんなら、C++にもとっとと所有権関係きてほしい >>467
その件はRustとC++の話とは関係ない
ElectronもTauriもWeb技術つまりHTML/CSS/JavaScriptでGUI部分が記述されWebブラウザと同じ
つまりWebブラウザと同じフレームワーク含めたコードとデータを使ってデスクトップアプリを作れることが利点
Visual Studio CodeがElectronで作られているようにほとんどの利用ではパフォーマンスに問題はなくマルチプラットフォームの恩恵もある
しかしそれらWeb技術ベースではなく直接GUIライブラリを呼び出したほうが少し速いし更にOS固有のライブラリを呼び出した方が少し速いのも当然だ
そこは何を重視するかで変わる
その例だとWinUIを直接呼び出す選択をしたという話だろう >>479だね、このタイミングで同時出現した理由は不明だけど
http://hissi.org/read.php/tech/20230620/RkRnWmV5ZW0.html
別スレみたら 複おじ=はちみつ はhissiで確定してるっぽい
仮に>>472が本当ならトリップ付きで表明しないと偽物が濡れ衣きせ放題だよね
でも今後も自演なりすまし、Rustでマウント嘘大げさばら撒く気満々だと思われ ほら、これこれ>>481
なんの情報もない前置き、プロンプトエンジニアリングで消したいわ
最後の一文もRustからWinUI直呼び出来るのに、なんでRust却下だったのかは話逸らし
マイクロソフトが評価してGUIに向ていないと結論出したのが大きいよ >>483
ちゃんと理解できているか？
元々C++で本体を書いていてGUI部分がElectronだったのをWinUIへ切り替えた話だぞ
当然C++による本体部分はそのままなのだからWinUI呼び出しにRustを使うわけがない
もし仮に元々Rustで本体を書いていてGUI部分がTauriだったのをWinUIへ切り替えるならばそこだけC++を使うわけないのと同じだ え?>>484はelectornアプリ書いたこと無いんかwww
旧Teamsのnative部分なんてほんのわずかだったと思うぞ
その僅かな部分さえRustに置き換えるメリットがないと
マイクロソフトが評価した
という事から目を逸らすなよ 本体のソースが僅かでもビルドツールを変えるのが超面倒くさそう マイクロソフトが評価した:
ビルドツールを変えるメリットもなし >>485
GUIがメインのおもちゃなプログラムだとネイティブ部分がごく僅かもあるかもしれないけど
普通のプログラムならネイティブ部分が主要部だよ
もしGUI部分にはGUI以外も記述しているなら酷いよ >>489
一言だけ言うけどvscode最適化のblog見た方が良いよ >>473
遭遇しなかったらrustは生まれてないだろw
必要ないのだから デストラクタが呼ばれないバグまたは仕様が大量にありそう
2回呼ぶより0回の方がマシだから呼ばない
0回を1回に改善する度胸はC++には無さそうだ >>491
頭は別に良くないけど俺は必要性を感じないな
newを直接書かないだけ >>493
その程度なら何も問題を理解できてないからrust使った方がいいよ
まあmainのみのコードなら別にC++でいいと思うけど >>495
その程度なら何も問題を理解できてないからrust使わなくていいよ
まあmain.rsのみのコードなら別にRustでいいと思うけど >>495
具体的に書きなよ
それでは議論できんだろ? >>492
ひょっとしてC++のデストラクタは手動で呼んでると思ってる? >>498
古いコードの互換性を切り捨てていないならそうなると思ってる >>499
もしやC++のデストラクタって手動で呼んでた時代があった?www
うそやろw >>497
どうせお前反応しないから書くわけないだろ わかったから
何も理解してないのだから大人しくしとけ 理解と信頼を得るために、Rustを使う。いい判断だ
俺はC++でたくさんだ 別にC++がダメとは思わない
最近の機能を駆使すれば相当安全なプログラムは書けると思う
ただあまりにもバッドパーツが多いのよ >>505
ヒント:オブジェクトのコピー時に起きることは？ >>493 は釣り。C++使いなら当然理解してる。
そこを踏み込んで殴ってみた>>495 は先手。不利は覚悟の上だよな?
>>506
取り繕っても無駄 >>507
ヒント:オブジェクトのコピー時に実装者の脳内に起きることは？ >>510
お前こそちゃんとかけ
ほらヒントは出したぞ
何が起こるか
その時考えられる不具合は？
C++使いならこの不具合はすぐピンとくるんよ >>511,512
以下がお前の最初の書き込みだ
>>495>その程度なら何も問題を理解できてないからrust使った方がいいよ
「問題」を書け 初めて書き込む者ですが
結局メモリ管理をプログラム言語に任せるか自分でやるかって差だと思うのですよ
メモリ管理でバグは出ると言う人はじゃあ言語にメモリ管理を任せてもバグは出るって事になるじゃないですか
最終的にメモリ管理をきっちできるかどうかできっちりできる人は自分で管理できるんですよ >>517
GoogleやMicrosoftやAmazonなどライバル同士のIT大手が手を取り合ってRust Foundationを設立しRustへ移行しつつある理由はメモリ管理だけでなくあらゆる点でRustが優れているためです
まずはRustも使いこなせるようになってみましょう
他のプログラミング言語と比べて優れていることを誰でも理解できるでしょう
食わず嫌いの人はこのスレに参加する権利がありません メモリ管理の事を言っただけで好き嫌いがあるという事にされて書く権利とか何故か自分に権利があるか如く言う人がいるのがrustなんですね まぁしかしこれが流行るかどうかのキモでもある
要は正解はひとつじゃないのに何でお前の見つけた正解だけでオレの流儀の正解は正解にしてもらえないの？オレの流儀でもうまく行ってるんだからほっといてくれや、小難しい言葉ばっかり使いやがって、ほっとけや‥となる
「コンパイラが間違いを見つけるチャンスを増やす」＝「今までどうでも好きにできたものを“こっちにしろ”と強要される」わけでしかもそれで何か「今まで出来なかった事が何か新しくできるようになる」感じはほとんどないからな
使わない人は永遠に使わない気もする > 食わず嫌いの人はこのスレに参加する権利がありません
ダウトｗ 食わず嫌いで愚痴ってる俺も混じってるぜｗ
>>1 のとおり、マなら、やれといわれたらやるんだが
自分用はねえ
あ、Rustのメモリ管理がC++にも来るのが前提な あれはいいものだ メモリ管理もいいけどそれはオマケだな
Rustは各言語で育った最新のプログラミングパラダイムが有機的に洗練されて採り入れられていて書きやすい
C++にもそのうち一部はあるが継ぎ接ぎ増築のせいで使いにくく普及していない機能が多い
快適さが天と地ほど異なりC++には戻りたくない そうね
今からキメラCやるよりRustの方が合理的 Rustの独習本でたら買おうと待ってるんだが出ないな
需要がないのかな？ そう言えばRustメインでWebアプリを製作してるって日本の企業があった気がする。 このネット時代にどのプログラミング言語を学習するにしても書籍は不要だろう
どうしても書籍がいいなら本屋に何種類もRust本が並んでいるから好みのを買えばよい
おすすめはオライリーの『プログラミングRust 第2版』だがもっと入門に徹したものが欲しいなら立ち読みで探せ >>520
Effective C++ってのを購入しないとC++の正解には到達できないんだろ？ そのへんは教科書だし、そもそも仕様書が頭に入ってないとダメ
認めてもらおうと思ったらね
まあ図書館に置いてあればいっぺん目を通しとけ Rustは以外とWeb系のバックエンドのライブラリ(例えばactix-webとか)はしっかりしてる印象がある。GUI,部分を担うTauriがもうちょい進化すれば、RustオンリーでWeb系は完結するようになるかも。 >>521
✕ あらゆる点でRustが優れている
○ 「リスクコントロールするマネジメントサイド」にとって、コーダーに(比較的)安全なプログラムを強要するRustが便利 強要しているのはRustでも数学でもないんだよなあ
生物学が色々なことを強要して炎上している まぁメモリ管理に対しては一応納得いく強要かなとは思う
プログラマにメモリの確保、解放をさせない、データをコンストラクトした時点でメモリ確保、参照が終わった時点で解放
しかし一つのデータを複数の変数が参照しているとどの参照が無効になった時点で解放していいのか決定できないから“所有権”なる概念を導入する、いつ参照が終了したのか確定するために“ライフタイム”という概念の設定
もちろんどちらの概念もないとコンパイラはいつメモリを確保していつ解放していいかわからない、なのでプログラマはこの概念を理解して所有権とは何か、ライフタイムとは何か、どのように決まるのか理解しないといけない
まぁ鬱陶しいのはその概念を“全変数全クラス一律統一”のルールにしてるので“整数型”とか“プール型”みたいな“メモリの確保”もへったくれもない変数についてもそのルールが適用されるとこかな
すると極めて簡単なHellow Worldレベルのプログラムでさえ怒られる時があって“うぜー！ぎー！”とはなるな、確かに
なので学習コスト高めの批評につながる >>533
所有権も参照もC++にある概念でRust特有の話ではないだろ
ライフタイムはC++にないがプログラマーは意識していないとダングリング等を引き起こしかねないので意識してるだろ
>> “整数型”とか“プール型”みたいな“メモリの確保”もへったくれもない変数
この部分は意味がわからない
整数型でもブール型でもメモリの確保は必要だろ
型が違うとサイズが同じでも突然にメモリ確保が必要になったり不要になったりするのか？
それとも例えばサイズが4バイトだとメモリ確保が不要だが16バイトだとメモリ確保が必要とかそんな世界があるのか？？(サイズ0は除く)
>> 極めて簡単なHellow Worldレベルのプログラムでさえ怒られる時があって“うぜー！ぎー！”
これは何を指しているか曖昧でよくわからんが
コンパイルエラーか何かでそこまで短気なやつはいないし
どんな機能でも使い方を数回間違えれば覚えるだろ
そんなことで詰まる人はどんな言語でもどんなシステムでもどんな機能でも対応無理だ >>534
まぁ、そこらへんは多分ほんとにコンパイラ自分で作ってみるくらいの事しないと分かりにくいかもな
ここがわからないとそもそもopy treitとは何かの意味がわからんからな
意味がわからなくても「これはcopy trait、これは違う、何故か、わからなくても全部暗記」でも乗り越えられなくはないけど >>535
根本的な理解ができていないようだな
Copyトレイトを実装しているか否かに関わらず当然どちらもメモリの確保が必要
例えば
// Copy非実装型
struct Foo(i32);
// Copy実装型
#[derive(Copy,Clone)]
struct Bar(i32);
型Fooも型Barも当然どちらもメモリの確保が必要 まぁ、基本は
スタック is GOD.
再帰構造 is GOD.
という話なんですけどね。
型厳密なFORCEとかできんかね。 普通にRustの仕組みを誤解してるんだと思うわ
一番問題なのは借用と値渡しを混同してると思うところ というか言語に関係なく
サイズ0でなければメモリの確保が必要
これはメモリを使うコンピュータの基本常識
もちろんコンパイル最適化によって生成コードレベルではレジスタ利用のみに成りうる場合もあるが
それは環境依存であるとともに言語レベルでは関係ない話 TがCopyならば&Tを渡されても全く問題ない、とは言い切れない
呼び出し直前にコピーし参照が消滅してから値渡しすれば&mut Tを得られる可能性がある >>541
何をいいたいかさっぱりわからん
具体的なコード例を出してみ なんで借用が使われてるか分かってない人が書いてるから
そこに乗っかって言いたいことを言い続けても話が長引くだけで不毛だから 借用とは参照の受け渡しに過ぎず
参照とはライフタイム付きのポインタ(アドレス)に過ぎないから
C言語のポインタさえ理解している人ならば理解に困らない
その上でデータ競合防止のための単純な借用制限ルールを把握すれば基本は完了
ここはすぐに学習が終わるところ
混乱ないように補足しておくと
単体の参照はアドレスのみだか
連続体の参照はアドレス＋長さの対
dynの参照はアドレス＋vtableアドレスの対
参照は以上3種類
ちなみに例えばVecがアドレス＋長さ＋キャパシティを持つのは参照とは無関係でVecの構造体データ自体
それを&Vec<T>として参照すらならその構造体データを指すアドレスとなるし
&[T]として参照するならばVecの構造体データを指さずに中身のアドレス＋長さの対の参照となる
その違いまでを理解できたら終わり なぜコードを出さないかというと強要されてないから
まさか強要が好きな人はいないよね この件にとやかく言うつもりないけど
ずっとレジスタに乗ったままの変数ならメモリは確保しなくてもいいんじゃないかと思うけど
xorの後カウントとか何かの値をレジスタに入れてそれを使って判定してそのまま消えるとか
関数抜けるときレジスタに入れっぱなしとか
検証する気もないが C/C++理解してたらそんなゴミみたいな質問は出てこないのだけどな
いきなりrustやってもわからんというのが俺の持論 xorの後の意味が分かってなさそう
gcc -Sでアセンブリに変えてみてるとそういう挙動に見えるんだから >>546
最終的にレジスタ演算のみで完結したとしてもそれは各CPU等のアーキテクチャ毎に最適化したコード生成レベルの話
プログラミング言語レベルの話ではない
例えばレジスタを持たない仮想機械でも動かせる 無知なのは仕方ないが積み重ねてる感じが一切ないんだよな
まっっっっっったく学習してないというかなんというか 【プログラミング言語】企業が求めるエンジニア言語ランキング 2位「R」、3位「Go」 1位は？ 企業DB運営会社が発表 [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1687350694/
Rustがランキング入りしてない コンパイル先で使えるレジスタが0本か100本かわからないので全てメモリ上に確保して進められる
参照を渡すならばレジスタが余っていようとレジスタへの最適化はできない
しかし参照渡しを値渡しに最適化してしまいレジスタを使う可能性もありうる
いずれにせよレジスタの存在は忘れてプログラミングすることになる 要するに物理的事情で強要されるのは許せるが数学的に強要されるのは許せないと >>525,530
大丈夫か?
>>554
大丈夫か?
ポエムか?
>>553
残酷な現実 >>557
>>>554
>大丈夫か?
皮肉じゃね? >>555
LLVM IRは逆にメモリの存在は忘れて（仮想の）レジスタのことだけ考えるモデルなんだがなあ
どこにも文書化されていない「俺様の考え方」に話を合わせろってスタイルやめてほしいわね 企業はRust使いを望んでないのか
俺は硬い書き味への期待で個人で使うつもりで学んでる
身に付けるまでに多少の苦労があっても恩恵がデカすぎると思ってるから
つーのもts書いてるとjsとかP系言語で新規に何か書く気になれねえんだよな。tsの型なんて言ってしまえば柔軟性優先のユルユルでしかないのに、もうそれがないところには戻りたくない
またwasmをホイホイ使えるようになれば、有象無象のWEB系人材の中では多少マシな立ち回りができるんじゃないかと期待してるから
つまり個人の戦略としては、企業の求める人材像に伸るか反るかとは別であっても良いんじゃないの もっと有害な物がいくらでもある
企業が求めてないけど無害な物をいちいち問題視するのは安全第一ではない視点 >>560
求人しても応募者がいないんじゃしょうがないだろ。
土方Rusteseが増えてからだよ。 上の方で出てたけど、webから来た人とRustは相性はいいみたいね
ニーズも合う 確実にマルチスレッドだし、セキュリティに関しては最前線だし >>553
Rustじゃ何も作れないんだからしゃーない >>559
LLVM IRのレジスタはCPUのレジスタとは全く別物
LLVM IRのレジスタは書き換えができない一方で無限の個数を持ててCPUのレジスタとは真逆の性質を持つ
あくまでも中間言語であって各プログラミング言語とも各CPUアーキテクチャとも独立している
一方C++やRustなどのプログラミング言語の変数においてレジスタは直接無関係で仮定されない
(staticでない)ローカル変数はスタック上にそのメモリ領域を確保したものとして動作するとみなしてよい
そのためレジスタを持たないWebAssemblyでも動作することができる
レジスタを持つ環境ではそのコード生成時の最適化でレジスタ利用ももちろん可能
各プログラミング言語とレジスタは直接関係ない futures::select を macro で使いたいんだが
use futures::{pin_mut, selct, future::FutureExt};
だと select! が無いと言われ
use futures::{pin_mut, future::{FutureExt, selct}};
だと select() は function だと言われる
select! どこいったし >>431
富豪がタイタニック冒険で沈没して酸素不足
酸素に金払わないとこうなる例 >>473
実際C++/Cのメモリ管理をわきまえてりゃメモリバグに遭遇する確率は低い
逆にRustにしたからと言ってメモリバグ0になる訳じゃない
メリット<コストなら移行しないだけ >>475
>だからRust信者は、良いソフトを作ったことが無い人が多いはずだ。
前半が正しいだけに結論が残念だな
だからRust信者は、C/C++に挫折した人が多いはずだ。
なら同意 >>566 自己解決しましたほんとうにありがとうございました まぁ覚えても仕事で使う人はほとんどいないだろうから覚えてもおそらく1円の特にもならない人がほとんどやろ
そう言う人が覚えるメリットはないし覚えなくてもいいやろな
オレは大学でソフトウェア工学やってたから興味あるので勉強するけどそうでもなけりゃやる意味ないかもな >>572
言うほどないけど
BASIC : 最初の一歩には最適かな？
C : 感動したな
Perl : さらっとなんかやりたい時は便利だった
Objective-C : NeXTでやった、大学時代、最先端やってる感だったけど、GUI周りがサクサクできるのは楽しかったかな
Eiffel : これも大学時代、Object指向大流行の時代、まぁ学術的な意味しかない感じ
Lisp : 計算論の勉強のときに必須だった、ともかく大学時代の勉強で後で実務に役に立ったものはない、しかし勉強して無意味だったとはもちろん思わないんだけどね
C++ : 就職してから、仕事で覚えた、イヤもなんもなし、できなきゃ飯が食えん、まぁ文句なしの業界標準
JAVA : コレも仕事、職場であったけど自分であんま組んだ事ない、できたコード見て綺麗やなとは思った
Javascript : コレは組んだ事もほとんどないくせに教えさせられた、必然的に憶えたけど
Haskell : 趣味、関数型流行の先駆け、久々のLisp系、ちょっと感動、流行ってほしかったけどいつの間にか消えてしまって残念
Rust : 現在趣味で勉強中、コレも消えちゃうのかな >>573
なんと高見の見物、消えても構わない趣味限定のHaskell&Rust
現実逃避ポエマーによる反実仮想風説の流布を咎めてください アセンブラとか含まないんだ…。(自分ならお約束的にZ80とか混ぜてる 組み込みの人でないなら、少なくとも32bitCPU以降じゃないとお約束は通じない(最悪、老害扱いされる) こんなしょーもないことでマウントする>>575は複オジなのだろう
しかも、このスレで頻繁に出る低レイアバトルが8bitマイコン前提だったとはねw 透視能力と予知能力ってどっちが良く当たると思う？
時と場所の範囲を広くできる方が当たるよね JavaをJAVAって書く人にはコードを触らせるなってばっちゃが言ってた 組み込みおじさんだからな
話がすげー古いんよ
Z80とか誰がやってんのよw >>583
実際組み込みは息が長いよ
ちょっとQiita見るだけでも70才位までいる
>>584
32bit経験者ってだけで老害扱いはないだろうけど、CPU自体はオワコン 32ビットRISC-Vチップ1個120円(海外のセット販売だともっと安い)が、
Rustでプログラミングできるそうだけど。 それの書き込みツールがRustらしい 波はそこまできてる
https://github.com/ch32-rs/wlink
Rust to C みたいなトランスパイラでいいのかもね
LLVMなら基本的にはできるんだろうから、なんとかなるだろ
手で書くから問題なんであって、中間表現としてのCに罪はない
clangエアプなのでしらんけど あ、ちょっとちがった
書き込みツール、Rust版ができてる、がより正確 5chにもRedditやSOのupvote/downvote欲しいよなあ
このスレの存在やRustスレの衰退ぶりを見てて思った 真面目に人の話を聞いてから否定したり、その人の所為にするよりは
人の話を聞かないという手もある >>591
まあ、5chの運営は政治思想的な理由で大規模な書き込み規制を行うゴミ組織ですから、あまり期待しない方が良いのでは？ 打倒Numpyを目指してRustでNdarrayベースでクレートの開発目指してんだけど、NdarrayやNumpyに追加して欲しい機能とかある？ >>594 良いね、まず過去現在の類似の試み、その状況を調べた限り挙げて見ては？ >>594
requires_grad=trueで勾配計算機能を追加
GPU転送機能 >>594
自分の試みが何が優位なのか、そのPOC、goalとnon-goal
機能拡充の前にPOCだけでも
ただ闇雲にやってみた、だと就職活動で逆効果 認証受けずモグリで運営していたのは問題だが
爆発じゃなくて爆縮400気圧
潜水艦の操縦がゲームコントローラとかワクワク感たまらねぇ
Rustで造ってれば安全だったはず >>594
BLAS
Complex Linear Algebra Rubyは、パッケージシステムやインストーラーを強要しなかったから
普及したが、node.jsは強要したので普及が遅いかも。
Rustもcargoを強要するのでダメ。 >>601
水深4000フィートまで耐えられるよう建造して
水深4000メートル潜ろうとして途中で水圧に耐えられなかった
長さの単位が統一されていないUSAだから起きた
メートル法に統一しているべきだった
この件はプログラミング言語は関係なさそうだ
しかし似たような事例で文字エンコーディングの不統一のためのバグが昔あった
Rustなら言語レベルでstrとStringがUTF8に統一され正当性チェックもあるため
入力の間違いやプログラムの間違いで取り違えたまま実行されることはなさそうだが >>603
cargoを使いたくないなら使わなくても使える
$ rustc foo.rs
これで実行可能バイナリfooが作られる
$ ./foo
あとはrustc --helpなどを見てくれ >>606
恐らくそれだとcrateが使えないので、cargoを強要される。
C/C++ではありえない設計思想。 そして、crateを使うことで、オープンソース思想に染まった一員
のようになってしまい。オープンソースが指示されているかのような
嘘の証拠を作ってしまう。 オープンソース思想っていうか、オープンソース世代だね
プロプラもオープンソースも貪欲に利用できる大胆さがほしいね また、cargoを使うことで、exeサイズの増大が起きるだろう。 >>607
できるよ
まずクレートbarをコンパイル
$ rustc --crate-type=rlib bar.rs
ライブラリファイルができた
$ ls -l libbar.rlib
ライブラリのある場所を指定してコンパイル
$ rustc -L . foo.rs
できあがったので実行
$ ./foo しかし、現実的に出来ないんだろうて。
そんなに簡単なら、cargoなんて不要なんだから。 SOのサーベイの所得プロットなんだけどZigの所を見る限り、普通に受け止める「言語別所得」と違う
https://survey.stackoverflow.co/2023/#section-salary-salary-and-experience-by-language
https://www.itmedia.co.jp/news/articles/2306/23/news109.html
https://image.itmedia.co.jp/news/articles/2306/23/l_dy_fig_04.png
まずZigの平均経験が10年以上が有り得ない(Zigは2016～)
あと、ホバーすると出てくる数字だと
$103,000 * 259 = $ 26.7m = 38億円 となって、
現段階では純Zig案件でこんな額は注がれてるイメージが出来ない
(せいぜいZig Software Foundationトータルで$1m寄付が有るか無いか程度)
言語別というより、言語扱う人別(複数延べ)データとして見ないと可笑しなことになる
Zigの場合は、250人位が仕事は他言語、完全趣味+OSSでZig、の方が近いのでは cmakeやcargoが必要なのは、gccとllvmの仕様が統一される保証がないから？ それと愛され言語の呼び名が変わったけど
https://survey.stackoverflow.co/2023/#technology-admired-and-desired
Go
desired-admired
20.59%-62.45%
所得プロットでの"人数" 6650
これも下と比較すると全く整合性がない
https://go.dev/blog/survey2023-q1-results
satisfied = 92%
n=5280
調査による差が激し過ぎでは >>602
何かBlasはndarrayクレートのオプションをfeatures = ["blas"]で、Cargo.tomlに設定すると使えるらしいですよ。 >>587
いや、俺が見かけた話は CH32V003 でなく CH32V203。 かつて日本人が1000人いたら、300人くらいはNECのマシンを
買ったことがあった。
RedHatはかつてのNEC以上に大儲けしていることになっているが、
fact checkが必要で、1000人いても、一人も世話になってない
気がするぞ。
つまり、オープンソースはfakeだらけなんじゃないの。
だれが、Linuxのサポートなんて必要としているものか。 そもそも、そんなに大人数の会社のサポートが本当に儲かっている
なら、誰でも真似できるはず。RedHatに優秀な人材なんて
入社するわけ無いんだから、その辺のマクドナルドのアルバイト
みたいなのにコールセンターで「サポート」させればいいだけ。
でもRedHatに続く企業が現れないと言うことは、RedHat
は、左翼によって捏造された企業である疑いが濃厚。
いつも左翼はそうやって嘘を付いて人々を操る。 RedHatなんて、多分に嘘だろうけど1万9,000人も社員がいて
年間4000億円もの収益があるとされている。
サポートで収益がそんなにあるわけない。
誰がそんな有象無象の社員の電話サポートなんて必要とするものか。
じゃあ聞くが、Windowsのサポートなんて何回電話したこと有る？
無料でさえ電話しない。
金取るのにそんな電話するわけ無い。
つまり、捏造。
オープンソースは、カルト宗教で信者達が捏造しているに決まってる。 1万9,000人もコンサルタント(?)がいて、そんな人のアドバイスで
ことが改善するわけ無いことは、誰の目にも明らか。
カルト宗教の力が無ければ、とっくに衰退しているはず。
そもそも技術力が無いから、サポートが必要なOSにしか育て
られないわけで、サポートを必要とするのは技術力が無い
ことの証明になっている。
そんなことは、誰でもわかることで、パッパラパーでなければ、
そんなテレホンサポートになんて金払って電話するわけ無い。
カルト信者の集団捏造に決まってる。
githubは、中国の国営企業がスポンサーの大多数を占めていて、
共産主義のプロパバンダ組織になっている。
そして、5chのLinux板とプログラマ板は、中国の五毛党による
工作活動が盛んで、オープンソースと社会主義を礼賛ばかりしている。 あのーCppとRustのどっちが良いのかと関係ない話すんのやめてもらえますか？ SDGsで考えれば、そんなカルト宗教集団の作ったものを使うことは、
カルト宗教に利することになってしまうからダメだ。 >>619-622
まーた始まった
書き込みを見ていると長いこと生きている筈なのに
なーんでそんなに世間知らずなの? 若いと、世界が制御下におかれていることが分かって無い。
学校では世界がまるで実力社会であるかのように教えるからな。
現実は嘘つきや捏造であふれかえっている。 そもそも、平均寿命が日本より8.15歳も短い国がまともなわけが無い。
人権だ自由だなんて言っても、実際には助ける振りしてるだけで
人を助けないし。
最近じゃ彼らの思う「自由」の限界が来て超監視社会になっている。
アメリカではネットすら監視装置として使うことが当たり前になっているし。
当然日本の個人も監視されている。
これは妄想ではない。スノーデン氏などのハッカーにも指摘されているし。
アメリカのGDPが高いのも、はっきり言って寿命が短いからだろう。 アメリかは911事件によって、初めて恐怖を味わった。
それにより初めて自由を制限することこそ重要である事を悟った。
彼らは極端なので、超監視社会に移行した。
彼らはやっと、自由を制限しないと、自分の自由も守られない
ことを知った。
世界の国の何週も後を行っている国家。
嘘つき大国で、あらゆることが嘘。
Rust人気も嘘。github人気も嘘。オープンソース人気も嘘。
RedHatが大儲けしていると言うのも嘘。カルト信者の
集団協力により、数値が捏造されているだけ。 >>621
決算捏造したら犯罪だよ
そんなことも知らんのか? >>630
・カルト信者による集団行動。
・ネットサポートなんて実際にやったかどうかの証拠が残らず
事実かどうか確認できない。 >>631
>>621
>RedHatなんて、多分に嘘だろうけど1万9,000人も社員がいて
>年間4000億円もの収益があるとされている。
この数字はどこから出した? 決算として公表されたものじゃないのか? Linuxって寄付がおおきいんじゃなかっけ?
大企業でもその上でアプリを作って儲けようようという算段があるから
インターフェースだけしっかり作ってくれれば自社製品で使うのはそんなに
大変じゃない
日本との文化の違いだな Rustのndarrayはonesとzerosを高次元のの形状に関して実行速度を計測するとなぜかonesの時がzerosよりも6桁くらい実効時間が遅かった。これ、絶対バグあるな。 >>613
HTML/CSS がプログラミング言語部門の二位ってなんの冗談ランキングだ？ 数学100点マンが100点をとったのは何十年も前でマイクロソフトの一部の環境しか知らずオープンソースが大嫌いなのか 非標準ライブラリを弄らないと何も作れないC
unsafeを使わないとライブラリを作れないRust
STLやboostだけでも成立する競プロ
出題範囲内だけで成立する何十年前の数学 >>639
そろそろunsafeの意味を覚えろよ
unsafe ＝ 人間がコードの安全性を保証しなければいけない部分
C/C++はプログラム全体がunsafeであることが様々な問題を引き起こしてきた
そこでunsafeな部分をできる限り小さく限定することで問題を根本的解決することになった C/C++は、普通、やっちゃだめなところは避けて使う
当たり前のことを守れないコーダーが現場に大量導入されて今に至る
Rustは、普通、unsafeを最小化して使う
…おなじことになるだろ? >>641
Rustはほとんどのケースで一般プログラマーがunsafeを使う必要がない
もしunsafeを使っていたら厳重にチェックされ必要ないのにunsafeを使うプログラマーは排除される
どうしてもunsafeを避けられない構造が発見されると一般化されるとともにモジュール内に閉じ込められ多数の監視の元に管理される
Rustの標準ライブラリもそうしてできあがった デフォルト全危険 人間が責任を持たねばならないのが全域
デフォルト全安全 明示したところだけは人間が責任を持てば良い
同じと見るか違うと見るかは自分次第
ただしチームメンバーのことを信用できるか？ チームメンバーが自分を信用していると確信できるか？
ここを考えるとハゲ具合は一目瞭然やろ
他言語バインディング関連は…知らんので全部Rustで置き換えろ struct Hoge {
Foo* foo;
};
この構造体が所有するfooはこの構造体が所有しているのか？
所有している場合、他に外部で参照しているオブジェクトはないのか？
それは弱参照としての扱いかそれとも所有者として振る舞っているのか？
fooは共有されるのか？
fooの生存期間は？
fooの初期化方法は？
デストラクタなどで勝手に破棄して良いのか？
(他に参照がある場合、ダングリングポインタ発生)
このオブジェクトは変更されるのか？されないのか？
このオブジェクトがコピーされる時の動作は？
クローンすべきなのかムーブすべきなのか
ポインタのコピーで良いのか？
C/C++の問題点はこれに尽きる
何もわからないのだ
C++だともう少し明確になるが問題は変わらない
上記を全てクリアにするために文法や仕組みを考えたらrustになったと言う話 >>639
>unsafeを使わないとライブラリを作れないRust
ほんそれ
はいはい御安全に >>640
>そこでunsafeな部分をできる限り小さく限定することで問題を根本的解決することになった
違うね
unsafeが散在して同じ事 >>643
>デフォルト全危険 人間が責任を持たねばならないのが全域
>デフォルト全安全 明示したところだけは人間が責任を持てば良い
ネガティブリストの方が扱いやすいが漏れが発生しやすい
大規模になるとポジティブリストより面倒臭いぞ？ >>644
おまいはドキュメントも参照せずにAPI利用する糞プログラマ > 必要ないのにunsafeを使うプログラマーは排除される
これができるかどうかだな
ま、unsafe使ったコード全部排除したらいいだけなんだが >>648
その観点でドキュメントAPIに全面依存の遅れた考えの人がまだいることに驚いた
ドキュメントは書き忘れたり書き間違えたり更新でコードと乖離したりするうえに
ドキュメントを読まない人や読み間違える人や更新された時に追随を忘れるなどミスは多岐に渡る
人間に大きく依存していることが敗因なので可能な限り自動チェック化が進められてきた >>650
> 必要ないのにunsafeを使うプログラマーは排除される
生ポインタやnewを直接使うプログラマーを排除すれば良い >>649
その「まともなドキュメント」の用途にもよるが
C++には規格書がある（Rustにはまだない） 各企業がコンパイラを乱立し始めると統一のために規格書が必要となる
Rustは大手ITが手を組んでRust Foundationが支える単一コンパイラだから規格書は不要だろう 既にrustcとrust-analyzerが異なるコードベースを独自に抱えてしまっていることすら知らずに、彼はそうつぶやくのだった 言語を広めるために規格が必要だった時代があったんだよ
特に異なるプラットフォーム用に異なるコンパイラを各プラットフォームベンダが先んじて作らないといけなかった時代にはね >>644
c++なら「smart pointer使え」「const使え」「ポインタと自動変数を使い分けろ」だろ。
生ポインタは主に過去互換性のためのもので、新しいコードで使うものじゃ無いわな。 >>653
規格書はあくまで規格書
言語を使うための必要な情報となるドキュメントにはならない 生ポを使わないとスマポを定義できない点はブーメラン刺さってる
あとは、安全と自称するより何も自称しない方が謙虚だと思うかもしれないが
unsafeな箇所をunsafeと自称するのはもっと謙虚である >>657
それならそのルールをコンパイラで強制したらいいじゃん
できるもんならね ナマポが危険ってのは
どこで必要になるか
どこがスコープでがスコープに入るか、もしくはstaticで参照して解放まで用意するか
どこで使わなくなるか
等の設計ができてないから危険と思うんだよね
こういうのが出来てないとポインタだけ危険とか言っても他の場所でバグらせそうな気しかしない
セマホみたいな排他制御で解放せぬまま進めたり終わらせて起動できなくなったり
さらに設計が出来て無い人からぐちゃぐちゃのソースになりそう
初めからどこで使ってプールするから解放は最後とか決めて書けば解放はほぼできると思うけどな >>660
自前のホルダーとファクトリーを定義すればだいたい強制できる。
生ポインタを晒す必要があるときが厳しいけど、global deleter以外はなんとか禁止できる。
c++標準にget()を無くしたsmart ptr欲しい。 Rustのndarrayの改善点を自分なりに調査してまとめてみた。
1) 配列の型変換のサポートが微妙。
2) ブロードキャスト機能のサポートが微妙。
3) numpyと比べてユーザーが配列の中の型を一々意識する必要がある。
4) pytorchのtensor型が持っているような機能がない。(requires_gradとか) >>663
あとin-place modeを作ってくれ
特定の領域を一度アロケートしたらそれを使い回すような演算ができると良い
とにかく途中でメモリを消費しないように さらにいうと演算を一度グラフ構造に落とし込んで依存関係を解析し
依存ごとに並列実行してもらえるとありがたい
ここまでやるとガチで速いと思う どちらにしろrequires_grad入れるならこれをやらないと勾配計算できないから必須 >>665
そこら辺はrayonでサポートされてる？ >>666
requires_gradは実装できそう。ただ、AVX命令は今のところRustの安定版ではサポートしてない感じかな。流石に情報学科の人間ではないからAVX命令とかのハードに近い部分の実装はムズいかな。ただ、型指定に関してはだいぶpythonの様に融通が効く感じにできてるとは思う。 rustではAVXの取り扱いがむずいの？
相性が悪いとか？
AVX自体は皆が思ってるより難しくない
やってることは大したことないんだけど
配列をポインタでグルグル回すだけ
利用も下請けの関数作ってそこに投げるだけなんだけどね 基本的にこんな流れ
配列AとBがあって
それぞれをポインタなどで指して
AVX命令でロードして計算して結果をどこかに吐き出す
ポインタを進める
これを終わりまで繰り返すだけで汎用性が高い
すでに誰かが書いたコードを丸パクリすることも簡単
誰にでも使える
でもみんな毛嫌いする rustでそこまで型を気にしなくてよくてnumpyと殆どAPIが一緒で実行速度も十分なライブラリができれば、rustはもっと流行ると思う。ということでまずはrustのndarraryクレートベースで作っておいおいndarrayクレートの中身もAVXやrayonで最適化を目指す感じかな。 >>670
この本がめちゃくちゃわかりやすかったよ
https://www.cutt.co.jp/book/978-4-87783-387-9.html
この本は数値計算で必要な概念が全部説明されてるしおすすめ
というかこんなニッチな分野独学以外無理 unsafe はガン細胞のようなもの
unsafe を散らすのが Rust
unsafe のままそっとじするのが C++ 同じ著者のこれもおすすめ
https://www.cutt.co.jp/book/978-4-87783-369-5.html
よく使うAVX命令がほぼ全て説明されてるが機械的なので上の本を読んでからの方が良い
内容はかなり被ってる >>676
物事はそう単純じゃない
pythonみたいに何も考えなくても使えることに意味がある
rust勉強しなければ使えないライブラリはあまり普及には意味がない AVX512(zmm)は、使えないCPUもあると思う。
Intelでも少し古い場合や、AMDだと最近のものでも
使えない場合があるはず。
GPUだと、コア数が少なくなってもそれなりに動くが、AVXだと
ハングアップするだろう。 SIMDに対応するかどうか判定することもできるので分岐でもなんでもしたらいい
さらにベクタ長を出すこともできる
ループのところでベクタ長で割ってループさせる
ベストプラクティスは知らんけど動く それにIntelのSIMDは、並列化の度合いが少な過ぎる。
AVX512ですら、float32で、やっと16倍個同時では、そんなに高速化
はできない。なぜなら、計算の前と後の処理に時間が掛かるので。
それに科学技術計算では、float64 が基本だから、AVX512ですら、
中核部分ですら8倍にしかならない。
それに8倍といっても、基本的に掛け算や足し算の計算部分だけが
8倍になるだけだし。
実際には、ソースや結果(デスト)のコピーやループしたりするのに時間が掛かる。
GPUだと、計算以外のコピーの部分まで高速化できる可能性がある。 Intelも設計の悪さにやっと気付いたらしく「、AVX512は廃止される
らしい。
数%しか速度向上しないのに、電力が23%位上がってしまうのだとか。
だったら、GPUみたいにした方がいい。
GPUだと、コア数に比例して速くなるはずだから、集積度を上げるだけで
速度はいくらでも上がる。問題は電力使用量。
だから、電力を如何に抑えるかが重要になる。
それだのに、電力が異常に上がってしまうAVXは設計が悪すぎる。
そもそも、Intelは命令セットの全体的な設計力には昔から問題が有る。 その結論はCPUによる高速化は効率が悪いからしないほうがいいと言うことか？
だったら愚かな人間の考えはやはり愚かと言うことだよ AVXの場合、乗算と除算、加算、減算のような中核部分だけが
速くなるだけ。転送はデータバスのビット数のまま。
だから、限界がある。
データバスが64BIT程度では、どうにもならない。
一方、GPUは、完全に並列化できるので、コア数に比例するような
速度向上が見込めるはずだ。知らんけど。
それに、レイトレーシングの様なものを並列化するのは、SIMDでは
無理が有る。 CPUとGPUは別売りできるからもしGPUは要らないと思ったらクビにできる
抱き合わせ販売は解雇規制みたいなもの >>686
CPUによる高速化もやるべきだけど、SIMDはとても扱いにくい。
効果が小さいのに、知るべき命令数が多すぎるし、分かりにくいし。
しかも、たかだか中核部分ですら16倍にしかならない。
しかし、それをするための準備にオーバーヘッドが大きすぎて、
典型的には1.3倍とかにしかならないらしい。 そもそもnumpyはBLASのラッパだということを理解してるか？ SIMDでもなんでもかんでも早くなるわけでもない
ただ自分のところではメソッドレベルで処理速度が80倍近くまで上がったものもあった
全体に占める処理量は多くないが驚異的
AVX利用できるのにしないのは何故なのかと言えば
単純に知識がないので使えないからと言うだけだろう >>692
>ただ自分のところではメソッドレベルで処理速度が80倍近くまで上がったものもあった
x87 FPUはスタックマシンで、SSE の xmm/ymm/zmm 系は
レジスタマシンだからではないのかな。
AVX512ですら、速くなるのは最大でも16倍程度のはずだ GPUはもう科学計算の分野では遠い存在になりつつある
あまりにもコストが高すぎる
今後どんどん上がっていくだろう
もう普通の大学や企業で研究開発の一部で使えるものではなくなった
今こそCPU復権の時だと思っている
シングルノードでカリカリにチューニングした数値計算ライブラリが欲しいよ >>695
いくらかかるかご存知？
まあ知らないのだろうけどw >>696
ぴんきり。CPUの価格と比べて、そんなに高いわけではない。 >>697
で、いくらなのよ？
定量的な話できないの？
ド文系？ >>698
倍精度浮動小数点(double)が高速化されているGPUで、2万5000円
のものが有った。
今は分からない。 >>692
使える人間自体が少ないのもそうだし、特定CPU向けのコード混ぜるとメンテナンスコストが高い
よほど有用だと判断されないかぎり普通はやらない IntelのSIMDは、レジスタの幅が小さすぎる。
1024個のdoubleを同時に掛け算できるような程度で無いと
余り高速化は望めない。 >>699
もういいよ
定量って意味すらわからないとは ところが、10個の独立したCPUがあったならば、10倍近い速度
は出る。SIMDだと、1024個同時に計算しても、トータルの
数値計算は、やっと数十倍位にしかならないだろう。 >>703
昔に調べたことだから数値は忘れている。
しかし、一般論として、SIMDよりマルチコア方式の方が
将来性が有ると言われているはず。 SIMDは時代遅れ。
AMDとnVidiaは賢いから、どんどんマルチコア化を進め、
AIや数値計算で高い評価を得ている。
ところが、Intelはセンスの無いアホだからSIMD化を進めようと
したが、全然速度が上がらない上に命令が複雑で、しかも、
機種依存、世代依存が激しくて使い物にならない。
GPUだと数年後に買い換えれば、プログラムを修正しなくても、
何倍にも高速化される。コンパイラの修正も不要。
SIMDだと新命令が出るたびにコンパイラの修正が必要だから、
コンパイラ作者は、なんでこんなことに付き合わされる
か分からずないで泣いているだろう。
実際、富岳や地球シミュレータはコア数が多い。 まぁでもやっぱりベクトル演算系は後回しにはなるんかな
そこまてニーズがあるとは思えない
しかし潜在需要は出てくるかもしれんけど
科学シミュレーション系、動画処理系、とか
YouTuberが動画合成するのに動画処理系は流行ってるけど
機械学習のためのベクトル演算も流行る兆しはあるけどな ベクトル演算は自由度が低すぎて使い勝手が悪い。
だから衰退して、いまのスパコンでベクトル型を採用しているものは
ほとんどない。
そして、それと似た設計思想なのがSIMD命令。
だから、SIMDが廃れるのは当然で、実際、Intelもやっと気付いて、
AVX512(zmmレジスタ)は廃止方向で、最近はコア数の増大へと
舵を切っている。その方向性は正しい。
AMDやnVidiaは頭が良くて、もっとずっと前からコア数増大へと
舵を切っている。
だから、科学技術計算でもGPGPUを使う流れは変わらない。
高いのは、半導体不足で高くなっているだけだろう。 いやGPU使わないならSIMDしか高速の余地がないんだよ
せっかくrustで実装するならサイズによって実装を切り替えるべき
要素数が少ない→キャッシュメモリを活かすようにメモリレイアウトを工夫する
要素数が中→SIMD+キャッシュメモリ最適化
要総数が大→スレッド+AVX+キャッシュメモリ最適化
これこそ現代アーキテクチャを生かしまくった実装
そしてBlasはこういう実装になってる
ただの生VecでループするならCと変わらん メモリドリブンとか非ノイマン型になるとまたアーキテクチャが違ってくる モダンで高速なCPUベースの数値計算ライブラリのまとめ
1.CPUの活用
SIMDを使う
2.キャッシュメモリの活用
キャッシュメモリを常に意識する
常にキャッシュに乗る範囲で演算を行う
3.パイプライン処理
計算を直ちに実行するのではなくまず計算グラフを構築し
トポロジカルソートなどで依存関係を解析する
依存ごとにパイプラインを作成し非同期で計算を実行する
記法としてはメソッドチェーンを利用するとやりやすい
非同期実行にはpromise/futureに代表される
非同期ライブラリを使うと書きやすくなる
この点rustはtokioなど非同期実行には使いやすいライブラリが大量にある
この点pythonのライブラリは現状だと全くお話にならないレベルの実装だ
中身がCなのでそこまで細かいチューニングができない
rustを使えば相当速くできるはず >>594,635,663,670,676
ndarray本体にコントリビュートするつもりは無いの？ SIMDの使い道がないなんて普通は思わないな
実際はSIMDは動画のデコードエンコードで使用されてる 追加
>>683,712
ndarray本体にコントリビュートするつもりは無いの？ 本気でやるつもりがあるならこんな場所じゃなくてGitHubのissues/discussionsで議題出すでしょ まあまあ
>>594,635,663,670,676
>>683,712
の意見を訊いてみましょう >>715
ないかな
俺が上で言ってるアーキテクチャだとtokioを組み込む必要があって
ndarrayにそんなことができる余地はない
tokioを組み込んでおけば複数ノードへの展開まで視野に入る
GPUを凌駕するところまでいけるんだよ 例えばUTF8 validationなどもbyte毎に処理するよりSIMDで速くなったりする この数値計算に「非同期ライブラリを組み込む」というのをやってるものは見たことがない
このアイデア使っていいよ 了解
>>683,712,718は>>666の人なのね
>720
>tokioを組み込んでおけば複数ノードへの展開まで視野に入る
>この数値計算に「非同期ライブラリを組み込む」というのをやってるものは見たことがない
https://crates.io/crates/mpi ←生きてる
https://crates.io/crates/node_crunch ←過疎
これらはtokio要らない見たいだけど、他に良いのがあるの？
>>594,635,663,670,676
言いだしっぺ待ち >>721
MPIはHPC分野で伝統的に使われてるライブラリだけど
書き方に非常にクセがあるのよ
いわゆるデータ並列でCUDAっぽい書き方を強要される
これが使いにくい
今時のライブラリで使うものではないと思う >>722
気になっているのは
>>718 >tokioを組み込んでおけば複数ノードへの展開まで視野に入る
の部分なんだけど説明してもらえる？ そういや、Intelからはdpcppとかいうのが出てるけど、あれってどうなん
ガチエアプで、そういうのもあるってのを把握してるにとどまってるんだが >>723
そこはまだ検討中ではあるがtokioのイベントループの中で
各ノードと通信を行うという意味
具体的な方法はまだ決めてはいないが既存のプロトコルでやれれようにしたい
gRPCをtokioの元で動くようにして
gRPCで各ノードと通信を行うようにするとかね
実際そういうライブラリはあるらしい >>725
了解
形になったら大宣伝しよう
という事で言いだしっぺ待ち
>>594,635,663,670,676
ndarray本体にコントリビュートするつもりは無いの？ >>724
俺の知る限り実用的なマルチノードでの計算ライブラリはMPIぐらい
スパコンの世界ではMPIを使うこと前提に組まれた数値計算ソフトがめちゃくちゃ多い
しかしやはり古いと思う
新しいモダンな数値計算のライブラリをデザインする時に来ている >>680
結構、とりあえず異なる数値型同士の行列積は既に実装できてるけど。勿論、ユーザーは最初に型を指定しなくてすむように演算。組んでるけど。rustは型をある程度動的にしてもそとまでスピードも落ちないんだよね。少なく自分の計測の範囲内では。 MPI自体は単なるマルチノードでの通信ライブラリに過ぎない
これを使っている前提のソフトが多いって意味ね >>727
>デザイン
coarray fortranってのがあるけど手書きMPIの方が性能は上らしい >>730
通信の方式とかかなりチューニングされてるからね
伊達に何十年も存在してない >>726
まあ、単純に自分が主体のクレートを開発したいというのと、ndarrayだと、型指定が多くてpythonライクな感じにならないから。ということで設計思想がndarrayの中の人たちとは少し違う。 >>731
だね
>>732
なるほどね
>単純に自分が主体のクレートを開発したい
ver0.2.0で止まったりするとけっこう黄色信号で、せっかく技術力を誇示してもコミュ力評価が落ちるから
逆にコントリビューターが来るくらい頑張ってね >>683
ただ、ndarrayベースだとnumpyの様にas_typeとかreshapeを実装しにくい。self.reshape(shape)って感じにしにくい。APIは出来るだけnumpyに寄せたいのでそこら辺は少し困ってる。後、pythonでnumpyのfor文を回したときとの時間はまだ倍程度にしかなってない。自分で一から実装するべきかもしれない。 >>734
倍速いってことねrustで開発中のクレートの方が。 >>734
numbaでnjitした時との比較かどうかを明記した方が良い >>734,735
あとnumbaはparallel=Trueで簡単に並列処理が出来るから、速度優位を主張する時は
numba @njitは大前提で、parallel有り無し、自分のクレート(parallel有り無し)のデータを出さないと
見向きもされない タスクによるけどrayon使うと爆速になるものもあるな。1000倍以上早くなったタスクがあったのは驚いた。 AVX512(zmm レジスタやEVEX)を使った高速化は、時代錯誤と言われる様になるぞ。
最新のCPUでは事実上 使えなくなるらしいから。
命令表の表だけの行数(rowの個数)だけでも3500にも及ぶ複雑な体系を
沢山勉強しても、結局無駄になった。 2020/04 にAMDがAVX512対応を表明して、実際に対応したと
思ったら、2022/03くらいで、IntelがAVX512を廃止する以降を
発表したとか。
そうやって競合企業を混乱させて弱体化させようとしている。
経営学における「陽動作戦」に近い。 要素数を即値などで指定できずに、命令自体を買えてしまうので、
Intel準正のC/C++コンパイラ以外では、CPUが出てから対応に
時間が掛かる。ベクトル型スパコンでは、要素数を即値などで
指定できていたらしいのと対照的。
つまり、Intelが自分だけが優位に立てる作戦になっている。
命令のニモニックを分かりにくくすると同時に命令の個数や
オペランドの組み合わせをやたらと増やし、アセンブラ表記も
アセンブラの修正を必要とするようなものにしてしまうことで、
Intel純正開発環境以外では、対応に時間が掛かるようにしてある。
複雑すぎて人間の頭にはInputすることすら大変になり、全貌を把握する
のに膨大な時間が掛かる。複雑すぎて、サードパーティーのアセンブラや
コンパイラがバグ無く動作するのは難しい。コンパイラ作者の勘違い
があれば、バグになるから。 Intel CPUの特徴は、アセンブラのニモニックが異常に分かりにくく、
Intel C/C++ コンパイラの intrinsic(組み込み関数)の表記は
少し分かり易い。
それで、純正コンパイラに誘導する作戦なんだろう。
アセンブラのニモニックも分かり易くしようと思えば出来たはず
なのに、高価なC/C++コンパイラを買わせるために、わざと
アセンブラを難しくした。
経営的には、参入障壁を上げ、模倣をしにくくし、自社だけに
有利なようにする戦略と考えられる。 iclっていつのまにか無料だぞ(サポートが有償)
まあIntelほどの巨人でも、生き残りは大事だからな
我田引水は程度問題 Linux のプロセス管理メモリ管理はピンピンコロリ作戦 >要素数を即値などで指定できずに、命令自体を買えてしまうので、
>命令のニモニックを分かりにくくすると同時に命令の個数や
>オペランドの組み合わせをやたらと増やし
インテルはいってるは命令の一部に即値が入ってるアーキテクチャーが好きなだけ
つまりオペコード＝「オペコード＋オペランド」であって
「オペコード＋オペランド」であることには変わりない インテルどこ言ったんだよと思ったのはここだけの秘密です ここでは教えたがりの無能からしか回答が来ないので自分で調べることをおすすめします rayonは並列スケジューラ
tokioは並行並列スケジューラ
どちらもワークスティーリング方式でジョブ/タスクを効率よくスレッドに割り当てて並列処理してくれる点では同じ
しかしファイルやネットの読み書きなどで待ち時間が発生する場合に
スレッドからそのタスクを一旦外して他のタスクを割り当てる並行処理も行なうほうが効率がよい >>720
Rustのndarrayにはrayonベースで非同期ライブラリが組み込まれてるっぽいけど。 常に同期して進めるわけでなければ非同期なので、非同期の並列は普通に起こり得て、非同期はそれ単体ではその観点で大した意味はないね
意味を持つのは非同期での並行、例えば一番わかりやすいのはシングルスレッドで非同期で並行して動作するJavaScriptかな
内部実装的には効率のためI/Oでマルチスレッドを使う実装もあるけど、シングルスレッドでも非同期に並行処理の実装が可能
各プログラミング言語のうちシングルスレッドでも並行に動作するpromiss/futureを持つ場合がこれに該当し、シングルスレッドでもasync/awaitで動作できるなら非同期な並行で動作してる
一方でJavaScriptはシングルスレッド内でしかasync/awaitの並行処理ができないけど、tokioなどはマルチスレッドで並行並列処理ができる
rayonはこの非同期な並行はできない >>751
マジ？
俺のアイデアパクられたかと思ったがあくまでプラグイン的な感じみたいね
俺のアイデアは非同期パイプラインベースの上で数値計算を行うこと
これができるのはtokioのみ 何度も言うがなぜ非同期パイプラインを使うのかというと複数ノードで計算できることを想定に入れているから
その時点で俺のアイデアがずば抜けてることがわかると思う rayonっての知らなかったから調べてみたけど
やはり複数ノードは絶望的だな
しかしメソッドチェーンで数値計算を行うという俺のアイデアとかなり似たことはできるっぽくセンスの良さは感じる Vector SIB(VSIB)が良く分からない。
* vm32{x,y,z}
index レジスタが、xmm, ymm, zmm の中に 32BIT の個々の要素として入る。
* vm64{x,y,z}
index レジスタが、xmm, ymm, zmm の中に 64BIT の個々の要素として入る。
というところまでは分かったと思う。
[base + index * scale + disp]
で base は、GPR(RAX,RBXなど)、index が、xmm/ymm/zmm になっている。
float32 に対する vm32x の場合は、EA(Effective Address)が、
EA = base + xmm[i*4] * scale + disp
(i = 0,1,2,...,3/7)
の様になる感じ。
但し、xmm[i] で xmm の iバイト目から始まる DWORD みたいな意味になる。
でも、
Table 2-13. 32-Bit VSIB Addressing Forms of the SIB Byte
の
Note
1. If ModR/M.mod = 00b, the base address is zero, then effective address is computed as [scaled vector index] + disp32. Otherwise the
base address is computed as [EBP/R13]+ disp, the displacement is either 8 bit or 32 bit depending on the value of ModR/M.mod:
MOD Effective Address
00b [Scaled Vector Register] + Disp32
01b [Scaled Vector Register] + Disp8 + [EBP/R13]
10b [Scaled Vector Register] + Disp32 + [EBP/R13]
の部分の意味が分からない。 >>756
分かって来た。
これは、base が 2進数で 101 の場合の話で、注意が
必要な場合に言及していたんだ。
特に難しいことは無いようだ。
もともと 32BIT の x86 で、SIB が無い ModRB で [d32]
だった箇所が、AMD64で、[RIP+d32]に変更になったので、
混乱を招き易いので注意書きを書いているだけらしい。
但し、SIB が有る場合の、mod=00、base=101 の場合の該当箇所は、
x86でもx64でも、[d32 + sclae * index] の意味になっていて、
特に混乱が無い。
SIBが有る場合は、mod != 00 の場合でも、x86、x64 で特に違いが
見られない。
だから、この注意書きは、もともとそんなに注意を必要とする部分
ではないと思う。逆に注意書きを書くことで混乱を招きそうな
気もする。 スレに合った話をするか。
CやC++よりもRustの方が優れてる。
1)RustはCやC++と比べてセキュリティ的に圧倒的に勝ってる。
2)rust anslyzerはかなり優秀。
3)非同期処理や並列処理周りのライブラリが優れている。
4)CやC++みたいにコンパイラが乱立してない。 4は「乱立」って言葉使って誤魔化してるが欠点だろーが?w 予めネガティブな言葉を使うことによりさもそれが悪いことかのように見せかける詭弁のテクニックだな
「C/C++はコンパイラが複数ある。Rustは一つしかない」だとネガキャンには弱い
だからここぞとばかりに貶めるネガティブな言葉を使ったワケだ。
これが宗教戦争の端緒だよ
これに「○○言語を使ってる人間は劣っている」とかの人格批判まで加われば立派な宗教だ ところでC++にはtokioやrayonにそれぞれ相当するものがないのですか？ あるのかないのかは知らない
ないのかもしれないけど大規模なプロジェクトでC++は使われているだろう >>763
C++ならtbbかな
あと非同期イベントループ使いたいならlibuv
しかしそれらを組み合わせることは不可能
tokioの素晴らしさは自分たちで非同期の仕組み自体を作れるところ >>765
それらはレベルが低すぎて対応するものではない
libuvはLinuxでいうところのepollシステムコールのイベントループにタイマとウォッチャの毛が生えた程度のライブラリ
使い勝手はコールバックを駆使する昔の不便な時代なもの
そしてスレッドセーフでないためシングルスレッド用
Rust tokioやGoのような高機能で使い勝手の良いものはC++に存在しない Rustって型を抽象的にしてもあまり実行時間に変化がない？ゼロコスト抽象化と言ってるけど。 >>762
こういうものには、カルト構造が有り、
本当に「信者」という言葉がふさわしいと言われている。 AVX512 は、非推奨(deprecated)で、第12世代 Core i
シリーズの Alder Lake からは、デフォルトで disableになる
とのこと。重い処理用に用意されている P コアではまだ使えるが、
低消費電力の E コアでは、AVX512 が使えない。
どちらが使われるかは OS が切り替えて、どちらになるかは
アプリが決められない(?)ので、AVX512 が使えない、みたいな
話らしい。知らんけど。
こうなった根本原因は、AVX512にはそもそも熱狂的人気が無かったから
なんだそうだ。SIMD命令だけが速くなるだけで、数値計算プログラム
においてすら、全体的には数%しか速くならないのに、電力消費は
25%位も多くなる、という困った事になっていたそうだ。
SIMD命令はプログラムの自由度が低過ぎるし、お膳だてのための
オーバーヘッドがかなり掛かってしまう。
そもそも、今や、乗算、除算ですらかなり速く計算で来てしまうので
SIMDにするメリットより、デメリットの方が多くなってきつつある。
なでなら、SIMDにするためには、離れた要素をmergeしたり、
maskパターンを用意したりする必要があるが、それに時間が
掛かってしまう。いまや乗算なんて、10クロックくらいしか掛からない
のに、maskパターンを用意するのにそれよりも多く掛かってしまう可能性
があるので、SIMD命令を使ってもトータルではほとんど速くならない
ことが多くなってきている。
さらに、加算(add)や減算(sub)なんて、もともと1クロックで
実行できてしまうし、本質的に並列化できる場合には、
1クロックで4命令程度は同時実行されることがある。
だから、SIMD命令を使わなくてもループ命令を
展開するだけで、勝手に同時実行される場合がある。
だから、SIMD命令の高価がほとんど無い事が多くなってきている。
それに対して、マルチコアによる同時並列実行は、とても上手くいく。 わかったから
使うほうが早いのだから使うんだよ
わからんやつだな >>771
特殊ケース以外は、微妙に速いだけだろう。 どうせ、研究目的とかで、非常に非現実的な
例で実験して速くなった、とか言っているに一票。 そんなに速くなるんなら、廃止する理由が無い。
便利でも無いし、単純なマルチコア実行に比べれば、
遅いし。 マルチコア実装が理想的な動作をしないから仕方がない
手元のコードを通してしか動作を見れないのだから仕方がない もちろんマルチコア「も」使うんだよ
さらにプラスアルファで搾り取る
そのためのSIMD そもそもデータって、色んな場所に散らばっている。
しかし、SIMD命令で演算するためには、それらを
1つの場所に集めてくるか、VSIBを使わなければならない。
しかし、それが効率よく出来ない。
マルチコアでやれば、そのような手間が無いため、単純に
速度がコア数分だけ倍増するが、SIMDだとそうはいかない。
SIMDで高速化できるのは、数値計算に限定しても、
気象シミュレータの様に場合分けが少なめで単純な
メッシュで計算自体は場合分けが無くて同じ事の単純な
繰り返しになっている場合に限られる。
レイトレーシング、剛体力学計算、パーティクル計算、
量子シミュレータなどは、同じ事の繰り返しにはしにくい
ので SIMD で高速化するのは難しい。
一方、マルチコアで高速化するのはSIMDに比べれば
簡単である場合が多い。 あとAVXは廃止されてないぞ
Xeonでは普通に使えるし
コンシューマー用の製品でもAVXを復活させるらしい
なぜならAMDが対応したから
AVX大戦国時代に突入が確定
普通のコア側の性能が完全に頭打ちなのだから
これまであまり活用されてなかったAVXなどのSIMDが今まで以上に大事だ >>776
SIMDでは微妙に高速化されるだけだろう。
マルチコアするための「スペース」が減ってしまう。 やはりこれから数値計算にはAVXは当たり前のようになりそうだな
mojoというプログラミング言語もSIMD構造体を使えるし
juliaでもSIMDモジュールがある
ライブラリ作者が勝手に最適化するのはもはや義務となりそう そういう意味ではrustのstd::simdなどが標準モジュールに入ってきたのもこの流れを受けてのことだろう
rustのコア開発者は流行りに敏感だ これを読め
Intelが将来登場するCPUで再びAVX-512に対応する模様。AMDに対抗するため。
https://gazlog.com/entry/intel-avx512-rebirth/ とはいえ並列数が少なすぎるというのは同意
GPUの数万スレッドと比べるとあまりにも差がある なんかの避難スレみたいになってるようだけど、自由にしゃべっててくれ
C++派だが、Rustの奴がガチな話してるの見るのは刺激になっていい
適当に流し読みしとくから IntelとAMDで使えるAVX命令がオワコンと思ってた人がいるみたいですね
さらにサーバー用CPUの存在も知らなかったのか？
無知って怖い 多分win12か13でAVXの対応有り無しで足切りがあると思うわ
AVX使わない理由がない 今までセレロンでAVXは無効化されてた
急にセレロンが無くなってそれ相当の後継CPUでAVX有効になってる
MSから通達があったんじゃないかな
次のOSでAVX必須にしますって
MSだってコードはAVXありで統一したほうがテストが楽になる 中途半端に新しいCPUも名前はセレロンのままにして
AVXで足切りすると一般ユーザーは自分のPCが足切り対象かどうかわかりづらい
それで名前を変えた
セレロンではwin12は使えませんと言えれば楽だから tokioとasync-stdはどちらが使いやすいの？ >>789
個人的にはasync-stdが好きだったが
tokioの充実度とtokio前提クレートの増大によりasync-stdを捨てた ただ、12世代 Core i では、一時的であるにせよ、
AVX512が使えないような状態になるって事
だよね。 GPUはCPUでは速度低下するような大量の計算に向いてる
少ないとCPUに完全に負けるパターンが多い Rustで数値型みたいのってないの？一々132,i64, f32, f64とか宣言しないとダメなの？ >>767
ラッピングして新たな型を作ってももちろん実行速度は同じにできる
>>796
むしろ型を宣言することが珍しい
普通は型推論に任せる
型推論できない整数はi32になるのでそれか無指定時の整数型 i32,i64, f32, f64, ...等を一纏めにした型が欲しいんですよ。 数字に型があるなんてのはプログラマの発想だわな
麻痺してるけども haskell の (Num a) => a みたいなやつ？
どっかのblogでRustにはないって言ってたのみた記憶が Rustではtraitを用いたgenericで解決させることが多いが
具体的に何をしたいのかによっては別の方法になるかもしれない
何をしたいのか具体的な話を書くべき JSみたいになんでもnumberで扱いたいとかそんな程度の思いつきでしょ Rustでrayonクレートを使ってみた。自分のやったコード大体素のRustのfor文の5倍くらいだった。 話の流れと全然関係無いけど、オープンソースは
成功して無いと思っても、成功しているんだ、
と言い返される。rustも今後、成功して無いような
状態になっても、いんや、これは大成功なんだ、
と言い返される気がする。 数値型実装の件は何か解決できたわ。
何か微妙な質問をしてしまった気がするわ。すまんな。 Rust作者にとってRust使用者は顧客ですらない。 顧客ベネフィットは関係なく、全て自分の名誉のため、
あるいは、歴史に名を残すことが目的になっている。
「ほら便利でしょ」「ほら画期的でしょ」
「ほら安全で楽でしょ」と。 まわりまわって、自分の為になるんだぜ
あくまで私利私欲 情けは人の為ならず ユーザーに合わせてソフトをカスタマイズするか
既製品にユーザーが適応するか
の対立がオープンソースにはほとんどない
どっちか一方だけが勝利とか成功するみたいな分断をなくすには良い方法だと思うよ オープン・ソース・ソフトを作れば作るほど
「水源枯渇問題」が生じる。
水源とは、顧客の財布を山の上流の水源に見立てたものである。
顧客は、コンパイラを使ってソフトを作って生計を立てた
がっている。なのに生計を立てるための水源を枯らしてしまうから、
オープンソースコンパイラの顧客ベネフィットは低い。 Rustを流行らせれば流行らせるほど、水源が枯渇
するから、顧客は積極的に使うわけには行かなくなる。
出来る限り(無料だが)「不買運動」を行なおうとする。
いくら安くても、rustcは、顧客にとってマイナスの価値を持っている。
なぜなら流行れば流行るほど、水源が枯れ、顧客の夢や
目的から遠ざかるためである。 マーケティングにおいて、「顧客ベネフィット」とは
「顧客が商品から得られる良い効果」を指す。 有名な例では、
ドリルとドリルによって空けられる穴の関係が上げられる。
顧客が欲しいのはドリルと言う製品ではなく、穴である。
同様に、顧客が欲しいのはRustコンパイラでも、それで自分が
作るプログラムそのものでもない。水源から流れてくるお金と
プログラムを使ってくれるユーザーの存在である。しかし、
オープンソースが流行るとその目的からは益々遠ざかる。
だから、オープンソースは顧客ベネフィットが低いどころか
マイナスである。 コピーが違法か合法かでいえば合法だが
合法な状態になっても、いんや、これは悪いことなんだ、と言い返される
どうやら合法と善を区別する傾向があるのは慈善事業だけではないらしい Ruby で、Vagrant を作った大学生のMitchell Hashimoto の会社・
HashiCorp の時価総額は、7千億円！
Rubyの神と言われて、今では、Terraform などGo の神！
OSS じゃないと、学生プログラマーが時価総額1兆円とか行かない
ハーバードでもそう。
年収3千万のサラリーマンになるな。
時価総額1千億円を狙うなら、Ruby on Rails をやれ RustとC, C++のスレでRubyを推す奴マジで謎だな。せめてRustやC, C++との比較の文脈で話せ。 できちゃうんだぜどころか、相性いいらしいってのは上のほうでみたよ C/C++の標準ライブラリって
ファイルを読み書きできるけどディレクトリやソケットはできない感じ？ ないけどある boostには来てる
API直叩きが好きな俺はそっちエアプだけど 理想と現実の合間を取った実用が実装で来ていれば標準に取り込まれるのだろうけど
標準ライブラリが出来てからどれだけ時間が経っているんだろ
亀の歩み寄り遅い
C++の呪い >>815
いや穴で例えるなら
安価な靴下と穴と寿命で語れ
もちろん安価が顧客ベネフィットだったら穴開き易くても売れる >>817
VagrantもTerraformも意味不明だな。
オープンソースはカルト宗教になっていて、信者が
寄付してるのではないか。 それに MIT ライセンスなのに、どうやって金儲けしてる
のかも不明だ。 仮想マシンの設定ツールななかしらんが、
そんなもん、1つあれば十分だし、そもそも仮想マシンなんて
普通の一使わない。
そんなもんの時価総額が7000億円にもなるなんておかしい。
トヨタ自動車は、一台200万円くらいの車を大衆に大量に
売っていても、ある程度の時価総額だ。
MITなソフトなんて無料にダウンロードできるんだから、
儲かること自体ありえない。
何らかのカルト集団と断定する。 そもそも需要が無いはず。
需要が無いはずのもので金儲けできるわけない。
やはりカルト集団によるなんらかの仕掛けがあると
疑われる。 それに仮想マシンなんて割りとそのままインストールできるし、
設定ツールなんて不要。
それにMITなら無料で入手できるのに儲かる分けない。
アメリかは嘘ばっかり。
オープンソースを広めようとする左翼による偽装工作
としか考えられない。 昔MS-DOSは沢山の人が使っていたが、それでも、
マイクロソフトは年間数十億円くらいしか売上げが
なかったことがある。Windows95を販売してやっと
100億円を超え始めた程度だったはず。
わけの分からん需要がない無料ツールで時価総額が
7000億円になるなんてありえない。 まーた始まった
根拠のない仮説を開陳する前に
成功している人がマネタイズをどうしてるか考えなよ この語りっぷりからするとVagrant使ったことないんだな
何も全部が全部「世間で評価されてるのが大きい、自分で触ったこともないのに貶すな」とは言わんが、最高レベルの貶し方をするつもりならそれ相応の行動は求められるでしょうよ
俺は仕事でだいぶ世話になってる
たしかに俺自身は金を落としたことはないけど、まあなんかやって儲けてるんだろ
コンパイラ売るしか考えられない爺さんは退場しなさい >>831
有体物を売って利益を得るのは最も古典的なマネタイズ手法
ソフトウェアは無体物なので古典は通用しないことを理解しな だからMSはSurfaceをGoogleはAndroidをAppleはiPodを売り始めたんですね >>834
本当はカルトの可能性が高い。
使ったことある人ですら一銭も金を落としてないわけだから。 スレ違いの無能に付き合うなよ。
レスするやつはアラシのコメ増やす同類。
NG設定しとけ。 RegHatも売上げが数千億円あるとされるが、
俺もRedHatの1万5000円くらいの箱を買ってみたことはあるが、
使いものにならないことが判明し、
それっきり。 アメリかは悪魔の神を信じている悪辣国家。
日本の敵。
昔から仲が良いことは一度も無かった。 自分の家から半径100m以内にトヨタ車は100台くらい
あるだろ。
Vagrant製品(?)の単価はトヨタ車の100分の一位で、
時価総額は30分の1くらい。
だったら、トヨタ車の3倍位は、Vagrantに金払ったことが
ある位でないとおかしいだろ。
なら、自宅から半径100m以内にVagrantに金払った人が
300人くらいいないとおかしい、という大体の見積もり
が出来る。
そんなにVagrantに金払ってるわけないだろ。
だから、カルトだと言ってるんだ。 >>840
>Vagrant製品(?)の単価はトヨタ車の100分の一位で、
>時価総額は30分の1くらい。
>だったら、トヨタ車の3倍位は、Vagrantに金払ったことが
>ある位でないとおかしいだろ。
アホか?w 何年生きてきたんだ? 家賃払ってない外食なら、客だけでなく店もお金をあまり払ってない
客がケチった分だけ店が損をする経験則が通用しない >>842
カルトによる fake 情報や信者による寄付などがあるんだろう。
または中国などの左翼による支援金など。 >>846
儲かる見込みも無いのに株価だけが高い状態だと
いうことだな。
しかしRedHatの売上げの高さは事実かどうかも含めて、
それだけでは説明できない。 カーネルにC++使ってないならディストリでC++使うしかない >>849
向上での生産や、原材料の仕入れや、製品の出荷、
配達などのモノの移動を伴わないから、証拠が
残りにくく、実際には嘘でもすぐには分からない。 Redhatの顧客が誰で何を売っているのかビジネススキームも把握していない>847。破綻しているから聞くだけ無駄。
>815で
「顧客が欲しいのはドリルと言う製品ではなく、穴である。」と書いているだろ。Redhatの顧客はオープンソースソフトウェアが欲しいんじゃなくて
ソフトが動作している状態
→成果物を生み出し続けている状態
→儲かる状態
が欲しいんだろ。Redhatはそのキーパーツのひとつを企業に高く売っている。 >>850
虚偽の決算って犯罪だよ
RedHatが虚偽の決算を公表していると言ってるのかな? >>851
>Redhatはそのキーパーツのひとつを企業に高く売っている。
具体的に何を。
もし本当なら、世界中が真似しているはず。
数千人の社員が出来る「サポート」なんて誰でも出来る。 RedHatの顧客例として上がってる企業は以下の通り:
英国陸軍: 戦争屋さん。ある意味では人殺し団体。暴力団。
Edenor:アルゼンチンの最大の電力供給会社
伝統的な既得権益団体。
HCA Healthcare:
米国最大級の医療サービスプロバイダー
金持ち誤用達の権力団体のイメージ。 軍隊や電力会社など、公共機関で、税金的な収入がある
ところが、わけの分からん団体に出費している
感じか。 >>853
「誰でもできる」と考えているのが浅はか。
24時間年中無休のサポートができるのならやってみろよ。 ほかに、社会主義国(左翼)インドのタタという企業や、
日本の郵便局にあたるアメリカの UPS (ある意味では公共事業体)
が顧客例に上がっている。
UPS(郵便)もインフラで税金のように収入がある。
元々国の機関で、配達のインフラは国の税金で作られた。
信頼感も国の組織だからある。日本の郵便局と同じ。
電力会社も民間企業の様に見せて、実際には国の機関。
電信柱の配電線や高圧鉄塔による送電線、火力発電所、変電所
原子力発電所も、もともと国家が作ったもの。
原子力発電所なんて、民間が勝手に出来るものではない。
そうやって、国民の税金で基礎が作られた団体が、RedHatに
勝手に金を流していることになる。 >>856
RedHatには1万9000人も社員がいる。
当然優秀な人ばかりではない。
夜勤でアルバイトにでもやらせてるんだろ。 これはまた別種の狂信者ですなあ
某氏はこれを見て自身の振る舞いを見直すための糧とするように 大国家の軍隊、国家最大の電力会社、国家の郵便局
みたいな、税金やそれに似た収入源で莫大な収益が
ある企業が勝手にオープンソースに賛同して、RedHat
に金を流している。
やはりカルトだ。
経済においてもカルトと言うものが存在すると言われている。 >>858
なら人手掻き集めて24/7サポートやれよ。
「誰でもできる」だったよな？ >>861
誰でも出来るが、カルト宗教のグルにならなければ、
信者からは金が入ってこないから成り立たない
と言っているんだよ。
だから、グルであるRedHatには可能でも、普通の
経営者には不可能。
だから、RedHatだけが儲かる。つまり、宗教団体の
親玉的存在になっている。 「Shriners redhat」で検索すると、フリーメーソン
とも関係ありそうな宗教のグルが赤い帽子を被る傾向が
あると出てきた。 RedHatはコネチカット創業でShrinersはニューヨーク発祥
だとか。距離も近いし、イギリスに関係が深い場所だとか。
だから、英国陸軍が何かやっているのか。
最近、英国が酷い国である、という噂がたっている。 >>862
日本語わかってますか？
あなたは「誰でもできる」と言ったのですよ？
とっととカルトでも何でも集めて24/7サポートやれよ。 Shriners は、全て「メーソン」なんだそうだ。
つまり、フリーメーソンと関係が深いようだ。
そうか、フリーメーソンが世界にオープンソースを
広げようとしているから、莫大な金が動いているのか。
なぜ儲かってるのか不明だったが、だとすれば納得が行く。
ウクライナ戦争もネオコンやディープステートと言われる
人達が仕向けていると聞いている。
ジョージ・ソロスや、バイデン大統領、
ロスチャイルド、ロックフェラーが関係していると言う
噂が立っている。 >>865
技術や技能的には誰でも出来る。
カルトなので、心情的に出来ないだけ。
宗教者には誰でも出来るが、良心の呵責から
多くの人には真似できない。
罪悪感にさいなまれるから。 >>867
アホかな？
>815「顧客が欲しいのはドリルと言う製品ではなく、穴である。」
じゃないのかな？
Redhatの顧客は技術や技能が欲しいんじゃなくてサポートにより維持される状態が欲しいんだろ。
「誰でもできる」じゃなかったんかよ。
とっととRedhat並のサポートやれよ。 >>868
優れたOSならサポート要らず。
サポートが要るのはOSがタコだから。 >>869
それは「サポートなんて簡単」と言っているのかな？
ならとっとと24/7サポートやれよ。 RedHatは普通に民間企業のサーバーで使われまくってるだろ
お前が苦しいのは中国のせいじゃなくて病気のせいだから病院行けって ま資本主義はみんなが信仰してるから成立している
ってところは当たってなくもない 税金の支払いはいくつかの例外を除いて通貨で行わなければならない、という現実があるから、まるまる幻想というわけじゃないけどな。 侵略はするけど借金だけはクソ真面目に返済する人生って言うほど現実的かなあ RustとRedHatって何か関係あったっけ？
現状だとRustはWeb向けのライブラリが豊富で、こっち関係の人がちょっとずつ増えてきてる感じかな。 Rustには数値計算と、機械学習系のRust純正の優秀なライブラリが欲しいところですね。 なんかRustの変数の扱いって結局C++のスマートポインタと一緒なんじゃないの？
要するに今までは
「使いたい人だけスマートポインタなるもの用意しますので使って下さい、めんどくさい人は使わなくていいです」
だったのを
「安全性、性能の面でスマートポインタ使って下さい、全変数扱い統一」
にしただけじゃないの？
つまり“全変数原則スマポのように所有権、ライフタイムを持たせたC++”がRustではないの？ >>877
全然違う
Rustの基本くらいは理解しようぜ >>881
うん、どう見てもアレの人が出てきたからお前は違うな
すまん rustを使ってみた感想としては安全性が高いのはいいんだけど、ちょっとしたコードでもタイプ量が多くなるところがマイナス
結局c言語ぐらい気軽にかける文法が望ましいがc言語ではメモリリークを出さない開発が至難の業である
よってrustは文法をc言語に寄せるべきだ
俺はメモリ安全なc言語を使いたいんだ pythonだと高速のライブラリは有用だけれど
rustだと遅いとか文句言われそう rayonと組み合わせて使うならtokioよりもasync-stdの方が良さそうだな。このように組み合わせると非同期かつ行動に並列化の最適化の恩恵を受けれる。 >>880
違うん？
RustでもC++のスマートポインタでも“所有権”とか“ライフタイム”とか言う概念出てくるし、「ポインタの中ではデータの所有権を持つものが設定される」「所有権を持つポインタがスコープを離れ全て無効になったときデータは自動的に(プログラマがメモリ解放の手続きを行わなくとも)自動適に消去される」とあって少なくとも細かい違いはあっても「プログラマがメモリの解放をしなくても自動的にコンパイラが解放のコードを挿入する」と言う根幹の部分は同じじゃないの？
どっか違うの？ 仮に、質問は有料で独断は無料だとしても、お金を払いそうな人はいっぱいいる
有償サポートは儲かる できるっちゃできるだろ
布教うっせえC++でたくさんだ、って言ってる人がいるだけで >>887
とりあえず公式チュートリアルThe Bookの4章まで読みましょう
そうすれば自ずと答えは出てくる
https://doc.rust-lang.org/book/ >>857
これは良い視点
もっと拡散追及して良い話 >>864
>最近、英国が酷い国である、という噂がたっている。
これは最近じゃなくて昔からだな
もちろん酷い國は英國だけじゃないし英國が一番酷い國だとは思わない >>875
web向けならRustじゃなくても良いのになω >>877 と >>887 は
Rustの前にC/C++を勉強するべき >>888
だから感染警告サポート詐欺が流行るんだよな >>883
>c言語ではメモリリークを出さない開発が至難の業である
doubt
シレっと嘘を描くな >>895
そうすると変数が何かも分かってない残念な子ってことになるからもう一度読んだ方がいいんじゃね
あとスマートポインタも復習した方がいいかもね スマポはライブラリ
代わりがいくらでもあるライブラリは
唯一無二の言語に隷属するというのがオーソドックスな見方
逆に、同一の概念が複数の言語に現れるという見方は共感されにくい >>887で正しいやろ
細部は違うとしてもRustに導入された変数の振る舞いは
C++のスマートポインタから拝借されたかどうかは知らんが
共有している >>904
まあ、このサイトはRustの文法云々の説明が丁寧に書いてあるというよりはRustの色々な付加的な機能の使い方が丁寧に書いてあるサイトなので、今話題のスマポとは関係ないけどな。 実はRust vs C++ ではなくてｽﾏﾎﾟ以上使える人 vs ｽﾏﾎﾟまでは使えない人の構図なんだよな 元の変数が使えなくなるという部分は影響を受けたとは思うけど
概念としては別 >>908
Rust初めて見たときはstd::auto_ptrがよぎったな その手合いの批判を目にして考えたんだ
俺いままで、スマポを適切に使えるか自信なくて、スマポなんかなくても間違わないように設計してたなって
ちなプロじゃない(業務で書いてない)ので、こんなもんで済んでたってのはある
Rustがスマポを当たり前にしちまった 俺も使えるようになるんだろうな >>910
>スマポを適切に使えるか自信なくて
どんな奴やwww
標準ライブラリの中で最も簡単な部類やろ >>877
そこはC++とRustで大きく異なる
とりあえず所有権とスマートポインタ(スマポ)の根本的な違い
C++: 所有権はヒープ領域に対してのみ存在する
Rust: 所有権はヒープ/スタック領域かの区別なく存在する
C++: スマポが指す領域はヒープ領域のみ
Rust: スマポが指す領域は一般的にヒープ/スタック領域の区別がない、ただしヒープ領域のみを指すスマポ(ex. Box)もある
C++: スマポはヒープ領域とその所有権を管理するために使われる
Rust: スマポは汎用的で任意の領域を指しRAIIに基づき動作する様々なものがスマポ
これらの差異によるRustの様々な効果は多く書ききれないが
C++は機能が非常に弱いとともに複雑となっている
Rustはコストの軽いスタック領域のシンプルで安全な活用が進んでいる等 >>912
それは枝葉末節な話
プログラミング言語にこれまでになかった所有権なるものが発明され導入された
その発想はどこから来たのか? という大きな話では>>877は正しい
>>877の最後の行は言い過ぎだけども >>913
C++とRustでは>>912に書いたように本質的に異なる
この本質的な差異を理解できないとRustを会得できない
なぜC++は不十分なのかも理解できない >>913
めちゃくちゃ話変わっとるやんw
本人以外でここまでのエクストリーム擁護するやつおらんわな
しかも所有権はスマポ以前からある概念だからそのエクストリーム擁護も当然の如く間違いなんだが もちろんRustはスタックにデータを保持するような変数に対しても、すなわち全変数について所有権、ライフタイムを定義してその求めるところのルールに従わなければならないと言うのはC++との違いではある
しかしそれはこの話の本質ではないやろ
そんな話してないやん？ >>914
スタックに置くかヒープに置くかは明らかに末論やろ?
そんなものを意識する極々などこで書いてるの? 所有権か、それを越える何かが、はやくC++に来ないとダメだ
何と言われようがかまわん、話はそれからだ >>913
どこからきたか？という点に関してはその通りだな
元々はメモリの解放漏れとダングリングポインタを防ぐための概念だが >>916
そこはC++で上手くいかなかった一因でもあるから本質的な差
さらに>>912に書いたようにスマポの概念も大きく異なる
>>917
ここはスレタイからC++とRustの比較スレ
両者の本質的な違いに言及できずに同じ扱いをしている書き込みは存在意義すらない 違う、そんな話してないでしょと言ってんの？
わからん？
そんな話ではなく、Rustの変数の扱いがむずかしい難しい、学習コストが異様に高いと言ってるけど、そんな事言い出したら実質同じなC++のスマポだって使えないでしょと言ってる
Rustはその学習コストの高い概念を“全変数”に課しているためものすごく簡単なプログラムでもその難しい概念の理解を強要されるから難しさが際立つけど、C++でもC++11以降はポインタについてはスマポ推奨で、事実上ポインタ使わないプログラムなんて書けないんだから学習コストの高さはC++もRustも同じようなもんじゃないのと言ってる
ともかくオレが上げてる“テーゼ”すら読み取れてない 本質的な違いなどないのではないか! という議論はあってもいいぞ 雑スレだし
まあ俺にはわからん 俺は馬鹿だから難しい話はわかんねけけどよ、流れ自体は良いんじゃねえのか？ それが仲間ってもんだろ！！ >>923
ちょっと違いますね
元々の議論は「C++にも所有権があるしスマートポインタを使えばよいのでRustは不要」
と間違った主張する人たちがいるところから始まっていると思います
したがって正解は>>912でしょう twitterで、Rustというキーワードだけ書くと、ゲームと区別が付かなくて流れて
誰も話題にしてくれないから、Wasmというキーワードを混ぜてる
のかな、と最近思ってしまう。
本音は、いい迷惑。Rustのことなんて話題にしたく無いのに
Wasmで検索すると高い頻度でRustの話が出てきてしまうから。
嫌な感じ。 ヒープに取るかスタックに取るかで速度以外に違いなんてあったっけ? ヒープが断片化するとキャッシュミスになりやすいのでは、とかいうね
実機で測ってみないとなんともだけど メモリアロケータのコードを読んだり自分で書くとわかるが
ヒープ領域の確保と解放はやることが多く非常に遅い
さらにヒープ領域の利用はキャッシュミスの観点から遅くなりがち
可能な限りスタック領域を活用するRustは理に適っている 所有権を明示的にコンパイラがチェックするかしないかは天と地の差がある 何でもかんでもヒープにおいちゃうスマポは時代遅れ
Cでとりあえず全部のオブジェクトをmallocするようなもの >>934
そこは正確に「C++のスマポ」と書いた方がいい
Rustのスマポは意味が異なりヒープを必ずしも扱うとは限らないため >>877に始まる議論でメモリアロケーション云々は枝葉末節な議論でしょう
なぜなら文法の話をしているので
文脈を読めないのかな? rustのスマポというドキュメントに書いてない造語はやめよう 「バールのようなもの」みたいな不完全な言い回しはド文系が使いがちな言葉遊びだよ Rustとか以前にVerseきてくんないとどうにも
Pythonすら(実行中に)つかえん …あーいや、Pythonは組み込む試みがなくはないらしいな 部分的に前言撤回 >>937
Rustのスマポはthe Bookで丸ごと一章を割いてしっかり説明がある
具体的な要件としてはDerefとDropのトレイト実装
Derefはdereference『*』オペレータで使える記述面としてのスマポ要件
DropはRAIIにより後始末できる機能面としてのスマポ要件
ヒープ領域を管理するためのC++のスマポとは異なり
Rustのスマポはもっと広義で多様なものが含まれている >>928
Closure言語よりはマシなネーミングだと思う >>945
Rust Bookを読みなさい
スマポの要件からスマポの具体例にスマポの自作の仕方まで説明されているから >>947
そんなのは言語によって変わるでしょうよ
あとRAIIはスマポでもなんでもない RAIIを最初から知ってる奴は冷静なんだけど
知らなかった連中はなんでもスマートポインタに見えたり
さらにはそれらがGCであるとまで強弁するやつまでおる
あくまで単なるRAIIなんだけどなあ >>944
T: DropはT自身に対するスマポですか？ >>950
きみはまず言語仕様とライブラリの仕様とランタイムの仕様をきちんと理解した方が良いよ
ある言語での概念を他の言語に持ち込んで理解するのは
ナンセンスと言わざる終えない >>948
明記しているように>>945は「Rustのスマポ」についての話
そしてRAIIをスマポとは書いていない
(RAIIにより生じる機能の)Drop実装はRustのスマポの要件の一つ
>>950
いいえ
Rustのスマポの要件がDerefとDropを実装していることとRust Bookに明記されていること以上の話はない レス番号をミスったので以下へ訂正
明記しているように>>944は「Rustのスマポ」についての話 >>931
>>912の所有権＆スマポのC++とRustでの違いがこのスレの根幹のひとつだよ
その違いをわかってない人がたびたび間違えたり勘違いして荒れてる >>955
>>912は>>877のレスとして書かれている
所有権はスタックに取ろうがヒープに取ろうが無関係なので>>912は枝葉末節な話
別の話としてやるならどうぞ RustのスマートポインタとC++のスマートポインタは用語の定義がそもそも違う >>957
このスレで最も重要なことを枝葉末節と言い切るのは勉強不足じゃないかな もめてる文脈に興味はないが
>>912の内容自体は正しい なぜrustとC++を比較しているのか理解できない
根本から違うものを無理やり比較してる なぜか類似性見出してるが「全くの別物」という理解をした方が良いよ C++は失敗したのではなくループしてるんじゃないか
自由過ぎて数え切れない選択肢をしらみつぶしに
枝葉末節を除けばRustと同じパターンも1個ぐらいあるのでは >>964
だから比較する部分ではないんだよ
同じ機能ではないから スマートポインタで二転三転してるからね
あれで見限った
結局unique_ptrも使いやすくはないし
微妙なバグを生む書き方ができてしまう chromiumで生ポインタをraw_ptr<T>に全部書き換えたのは笑ったな
Googleでもこんなクソみたいなことするんだな >>969
生ポインタを捨ててペナルティを払ってでも対策に乗り出したのが面白いね
ref_countを持っていてカウントがゼロになっても解放せずにダングリングポインタのバグを検出してるらしい
GoogleはC++を早く捨てたいようだけど巨大なコードの既存プロジェクトだけは仕方なく理不尽な手段を取るしかないようだね 所有を強参照で、借用を弱参照で表現するのは正論だよ Googleに限らずどこでも人員が整った新規プロジェクトからRustへ変わっていく構図だ >>972
そこまで言うと誇大広告の類だな
各社の新しもの好きが試して成果物がようやく出てきた感じ 俺はc言語がいいんだ
cとpythonが融合したような言語がいいんだ
rustは惜しいがいまいちしっくり来ない 根本的に勘違いしているやつがいるけど、c++のスマポはヒープ専用じゃないからね？リソース管理全般に利用できる。
c++のスマポで管理できないのはスタックメモリ。スタックメモリはコンパイラが自動変数として強制的に管理するから、ライブラリからは管理に介入できない。 >>951
>ナンセンスと言わざる終えない
君には國語の学習を強く薦める >>980
nimでダメならRustはもっとダメじゃない？ Nim入れようとしたらWindowsだとMinGWいるのかよ
今のところLinuxで使う感じか 基本的価値観というのがあって
条約がなくても即興で同盟関係を作れるマイノリティがおるんよ >>981
明らかにRustの方が開発者のコミュニティは活発だよね。そもそもNimよりは圧倒的に各種ライブラリが揃ってるし。 AWSなど社会のインフラが次々とRust製になっていってる現実を見るべき ロシア兵は畑でとれるらしいけど
Rust兵は無理なんだな
ゆっくりと樽辺りで熟成しないとjavaプログラマ以下の生産性しか出ない javaプログラマはボジョレーヌーボとして出荷される
Rustはそれは無理な話 この板的にはC#はJavaを圧勝するとのことだが、JavaはC#よりユーザー数が多い。
ところが、この板的には結果が全てだそうだから、もしそうなら、
Javaの方がC#より優れている、ということになるね。
トータルではJavaが買っているからJavaの方がC#より
使われているのだ。
その中には、アンチ・マイクロソフト、マイクロソフト不買運動
の影響も有るんだろう。 C++とRustを比べた時、使用者数は、今現在は圧倒的にC++が
勝っている。このことは、何らかの意味でC++がRustに勝っている
ことを示す。
そして使用者数の増加数を見る限り、RustがC++をやがて
抜かす可能性もない。 このスレで数の理論を話したいなら出て行ってくれ
頭が悪すぎるのでもはやレスする気すら起きない RustがC++に買っていると思ってる人は、評価の観点が間違ってると言うことなんだよ。 ボジョレーヌーボーはPythonで作ってほしいんよ
PythonとC++が両方間違っている場合しか正解にならない選択肢はなんか狭いよな もう新しい言語に移行できないレガシープログラマーの数では確かに圧倒してる このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 24日 2時間 43分 55秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
