結局C++とRustってどっちが良いの？ 6traits
レス数が1000を超えています。これ以上書き込みはできません。
C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」
っていう雑談スレ。
前スレ
https://itest.5ch.net/mevius/test/read.cgi/tech/1688129795
関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.n...cgi/prog/1619943288/ Rustはライフタイムの管理がムズいな。上手くいくかなと思っても結構コンパイルエラーが起こる。これは自分がライフタイムを正確に理解してないだけ？ >>1
関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/ クラウド世界トップシェアのAWSもRustで構築されているらしい
https://japan.zdnet.com/article/35183866/
AWS (Amazon Web Services)は、「Rust」を使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、Rust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。
AWSのソフトウェアエンジニアで、Rustの普及に取り組む
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく「エネルギー効率に優れている」。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。
Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」、
「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」などがある。 === 複製おじさん（通称複おじ）について ===
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が複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。 前スレで、moveいるいらないっぽい話がちょろっと出てたけど、
moveまわりを避けて、実直にポインタでやりとりする書き方してるんだろうな
APIにごく近いところに住んでて、簡潔に書くようにしてたら、おのずとそうなるかと C++のtemplateの扱いもガチ勢とコンテナ専で意見が分かれそうだな
マルチパラダイム言語だから仕方ないけど見る人によっては無駄に複雑化してるかもしれない
>>1
亀だけどスレ立て乙です >>9
C++の最大の特徴は後方互換性だよ
拡張された部分が複雑で気に入らなければ
使わなくても良いんだよ じゃあ過去のコードを手直しせずに新しいコンパイラでコンパイルできるのかと言えばそうでもない コンパイラのバージョン上げて必要になる修正なんて微々たるもの
あんまりコンパイラのバージョン跨ぐと修正が多くなるけども
追従していけばそれほど大変でもない
例の人には特に苦手な作業だろうw Rustを使ってる人は、
何か作りたいものが有って作ってるんじゃなく、
自己アピールや書籍を書いたりするためにしている人が多い。 >>964 前スレから
>>>962
>>C++20もconceptとかrequireとか言い出してるから心配しなくていいよ
>最近のC++に問題が多数混入したことは知られているが、
>人気が絶頂だったころのC++はシンプルで分かり易かったぞ。
最近っていつ？ C++って、全機能使いこなせないと殴られるんちゃうかみたいな ふいんきあった
仕様書頭に入ってないと発言権ありません的な
まあでもそのくらいの気合はあって悪くない
Rustを前にして、苦手意識のほうを捨てることにしたよ >>13
私は非同期並列処理を用いた高速な行列演算フレームワークを開発しているところ何ですけど。 >>977
気持ちは判る
改悪は事実だが元々良かった訳でもないしな >>984
これも判る
std::vectorもstd::listも馬鹿設計 あたまのおかしい連続レス
>>1
こんな板違いのクソスレ立てるくらいならワッチョイ付きのまともなRustスレ立てろ
ここは頭のおかしい荒らしを養殖、醸成させるスレになってんだよ >>2
むずいというよりメンドくさいだけ
考え方はシンプル
メンドくささを受け入れられない気持ちは判る >>21
関数引数のライフタイム注釈は、まあ、分かるんだけど、
structに対するライフタイム注釈は、色々な書籍を見ても、
厳密な定義が分からなかった。
ちゃんと、数学的な言葉や擬似コードなどで書いて欲しい。
たとえば、注釈Aと注釈Bの積集合が、戻り値のライフタイム
になる、みたいな言葉で書くのが数学的な書き方なんだが、
今のRustの仕様書では、そのような言葉で書かれていないので
精密な定義が分からない。
なので、ちゃんとしたプログラムが出来ない。 >>24
気付くかどうかがその人の能力。
具体的にプログラミングして実現する実装能力とは別。 Haskellバカも含めて論文だの厳密だの言うくせに誰もRFC2094を読んでいないのはなぜなのか
https://ubnt-intrepid.netlify.app/rfc-2094-ja/ 煽ったり荒らしたりして情報を引き出すやり方なんだろう
自己中 >>26
>気付くかどうかがその人の能力。
「俺は問題が分かっている気づかないお前は能力が低い」では議論にならない
こういう言い回しが散見される
あなたが社会に馴染めない原因 >>25
規格をまとめれば査読されるだろうからマシになる >>25
君の頭の悪さをRustのせいにするなよな >>31
なんとでも言え。
俺は現実世界では優秀だと認められてるから。 >>34
おまえはおまえでちゃんとやっているつもりなんだろうが、
おれはおれでちゃんとやっているつもりだ。
Rustを非推奨とするのは、俺の心からの日本や世界への
愛でもある。
俺の考えでは、Rustは人類を良く無い方向に導くから
それを阻止しようと考えている。いわば、聖戦のようなもの。 現実世界でも優秀でないのは文章を見れば一目瞭然
ある一定以上の知性がある人はここまで馬鹿な文章を書かないから >>36
俺は左脳的じゃないからかも。
色々調べてみると、右脳優位らしいし。 脳の言語機能が発達してない人にプログラミングは無理だろ
少なくとも今の技術では 難化の原因の一つはstatic変数の悪口を言ったこと
だから昔の技術ではプログラミングできた人達も、今の技術では無理になった >>35
歳はかなり上のはずなのに
時折書く文章は中学生みたい
引きこもりなのかな? 本当に頭がよければ世界の80億人を愛するとか簡単に言うわけないんだよな
少なくとも世界中に足を運んで交流してからだろ 歳は若くても45くらい多分50代後半かなと思う
それで>>35の書き込みだよ
社会経験が乏しいだと思う
俺はこの人は高齢引きこもりなんだと思う
何かの事情があったのだろう 両者とも何か、リスクが低過ぎる物事に対する憎悪を感じる
詐欺よりも未定義の言葉を嫌うのもリスクが低過ぎるからじゃないか 病人の相手を任せるためにも、はやくAIの開発がすすんでほしいわ まず、このスレの連中は、いったん素晴らしいと思い込んだ
ものを無批判に受け入れすぎている。そして、英語圏の
批評、批判を全く読んでない。
読んでいればRustの評価は余り高くなくて、意見が
半々くらいに分かれていることがすぐに分かるから。 OSなんて一つの言語で記述するメリットが大きすぎる
それを上回るよほどの大きなメリットがない限り他の言語を導入することはない
しかしMicrosoftはWindowsでRustを導入しGoogleはAndroidでRustを導入した
C++を邪道な言語として使用を拒否してきたLinuxもRustを導入した まあmalloc失敗でpanicにならんのならええんやない？ >>49
Rust の方でも .unwrap() 禁止するか unsafe {} 必須にして欲しいわ OSではCの支持率100%になってもアセンブラを排除するのは不可能
つまり、数値を抑制するのではなく
数値が上がりすぎるとスカウターみたいに爆発する脆弱性をなくせばいい
安全をどれだけ信奉してもunsafeを排除できないのは良いことだ >>47
>C++を邪道な言語として使用を拒否してきたLinuxもRustを導入した
$ wget 'https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.4.7.tar.xz'
$ tar xJf linux-6.4.7.tar.xz
$ find linux-6.4.7 -name *.c -o -name *.h | xargs cat | wc -l
32115936
$ find linux-6.4.7 -name *.rs | xargs cat | wc -l
17057
たった0.05%だよ
rsソースの増加速度よりcソース増加速度の方が速いのも前回示した通り
>しかしMicrosoftはWindowsでRustを導入しGoogleはAndroidでRustを導入した
Windowsは前に出回ったスクショにファイルサイズが出てたねw
Andoroidで使われているとか言ってるRustは果たしてどのくらいなのかな? >>46
ここは北朝鮮じゃないので何を使うかは選択でき自由がある
「無批判に受け入れすぎている」は全く当たらない >>49
RustはLinuxなどのおかげで改善された
メモリ確保もエラーを返せるようになった 行数もいいけど独裁者が何人いるか数えてみろよ
たったの1人しかいないから無力の無能だと言えるなら正直者
だが掌返して1人だからといって無能とは限らないとか言い出せば嘘つきだ >>56
意味がわからん
日本語も書けなくなったのか？ >>52
あの頑固者のLinusが解禁したこと自体が画期的
RustがOKなら、Rust程度のOOPはOKってことで、近い言語が続々参入したりして
そうなると、simple化付きC++ってのも見えてくる 何かの政治的な理由でRustを仕方なく使ったんじゃね？ >>60
知らんまじで 処理系に指定があるかまでは存じ上げず 普通にrustc（+llvm）でいいでしょ
知らんけど どいつもこいつもマウントを取る相手に飢えてるんやなあって パタリとレスが止まったが
>>59みたいなこと書くのなら>>60とか>>64には答えられんとなぁw カーネルは知らないがrustcでコンパイルしたものとc言語で書かれたものはリンクできて動いてるし何を問題にしているのかわからない
最近はPythonやJavaScriptのライブラリもRustで書かれることが増えている >>68
Linuxカーネルは伝統的にgccでコンパイルされてきた
rustのコードはrustc on llvmでコンパイルされる
そうするとgccが吐いたオブジェクトファイルと
rustc on llvmが吐いたオブジェクトファイルをリンクできるのか?
という疑問が普通に浮かぶ
[解法1] できるのなら何も問題ない
[解法2] できないのならカーネルをclang on llvmでビルドすればリンクできるだろう
最近はclang on llvmでカーネルをビルドすることもあるみたいで
検索するとAndroidはclangらしい
[解法3] あるいはgccrsでrustコードをコンパイルすればgccのコードとリンクできるだろう
さて始まったらしい（しかし何もリリースされていないw）カーネルでRustの利用方法は
1なのか2なのか3なのか? あるいは別の方法かな? WindowsでRustの利用が始まっているらしいが
MSはllvm使うのかね? Visual Rustかね? >>69
何を問題にしているのかさっぱりわからん
gccもclangも同じELF形式のオブジェクトファイルを吐くだけだぞ
共有ライブラリなども当然同じものが使われている
コンパイラ毎に別々の形式を吐いて共有ライブラリなども別々に用意されていると勘違いしている？？ rustのコードはrustc on llvmでコンパイルされる
そうするとgccが吐いたオブジェクトファイルと
rustc on llvmが吐いたオブジェクトファイルをリンクできるのか?
あほすぎわろす そもそもRustは全く関係なくC言語だけを使う世界でも同じ話
コンパイラを変えてもリンクする既存ライブラリは同じものを指定して同じものをリンクするだろ
それを知らないとはエアプログラマーかね？ まずrustcがllvmでコード生成してることを知ってるかどうか確認する必要があるな
rustc on llvmという表現に若干の不安を感じる
もしかしたらllvmを知ってるかどうかの確認も必要かもしれない >>75,76
じゃ1で良いのかな?
つまりカーネルはgccでビルドして
Rustで書かれたカーネルモジュールは（まだないけどもw）
rustcでコンパイルするのかな? coff とか omf とか elf とか面倒だよなω
D は沈没したしωωω 夏風邪で寝込んでた 隠れ新型コロナかもしれん ちなマスクはしてる
俺はC++派だし、どうしてるんかまで知らんって
Rust部のツールチェーンのバージョンを指定してるんじゃないか
見に行く元気はない まだだりぃ
Rustの努力にはライバルながら賛辞を贈る
Rustの成功をC++に取り込むべきだと思ってるからね >>80
>>69の解法2だね
>>72,73,75,76
何で解法1じゃないの?
何でvery experimentalなの? Rustに詳しい人しか答えられないような内容を
ここに書くべきじゃない。
Rust専門スレがあるのに、何故そこに書かないか。 昔はコンパイラとリンカは別物でコンパイラはposix標準のライブラリファイルを出すのが仕事でその後各言語が吐き出したライブラリファイルをリンカでくっつけてた
しかし今はコンパイラがリンクまでやってるのでこの“別言語間のリンク”がどうなんとなってるけど、流石にコンパイル後リンク前のライブラリファイル形式もその形式のファイルをはくオプションも残ってるやろ >>82
>Rustに詳しい人しか答えられないような内容を
>ここに書くべきじゃない。
何やそれw
自分が詳しくないこと分からないことについては
ここに限らず（5chにも限らず）書くべきじゃない かたいこというなや
「しらんけど」って付けときゃいいんだよ
しらんけど
まあ、bfd/binutilみたいのができて久しいし、
そのへんに準拠してれば、リンクはできるよ
(最近のことは)しらんけどｗ calling convention は、今後もなんとか突き合わせてもらうとして。
だいぶ前に書いたのは、RustにはRustのname manglingがあって、C/C++がそれに合わせられないかってこと
それができれば、所有権情報付きの型に対応できることになるから、
C/C++も一気に所有権まわりを獲得できるってことになる >>84
Rust専用スレがある。
そっちの住人にこっちは隔離スレとされた。
隔離されて無いはずのスレに戻れよ。
そっちの方が多いはずなんだろ、Rust信者の脳内では。 戻れも何も俺はそもそもRustユーザではないので
「Rust専用スレ」なるものを開いたことはない
ここには議論をしに来たのであってウザいと言われれば
反論できないのだなぁwとしか思わん またーりしていけよもう
たらこは言った、面白いことをかけって 質問してるヤツと答えてるヤツが同一人物って可能性もある さすがにその可能性を疑い出したら病気の一歩手前だから気を付けてくれ
何か引っ掛かる点があったなら別だけど >>93
同一人物で自作自演したとして
俺が何をどう思われたいと思ってるのかが分からんので
是非論理的に教えてくれ >>69
それはRustと全く関係ない問題
オブジェクトファイルはコンパイラと独立した存在
C言語だけの話でもclangとgccを当然併用できる
まず関数fooだけのfoo.cを用意
$ cat foo.c
#include <stdint.h>
int foo(int32_t a, int32_t b) {
return a + b;
}
これをclangでコンパイル
$ clang -c foo.c
オブジェクトファイルfoo.oが出来ている
$ ls foo.o
foo.o
つづく 次に関数mainのmain.cを用意
$ cat main.c
#include <stdio.h>
#include <stdint.h>
int32_t foo(int32_t, int32_t);
int main(void) {
int ret = foo(10, 20);
printf("ret = %d\n", ret);
return 0;
}
このmain.cをgccでコンパイルして(clangで作った)foo.oをリンクして実行ファイル生成
$ gcc -o main main.c foo.o
無事に足し算が実行できました
$ ./main
ret = 30 clangとgccで上手くいった話は
rustcとgccにしても当然上手くいく
今度はRustで関数fooだけのfoo.rsを用意 (区別できるように掛け算に変えた)
$ cat foo.rs
#[no_mangle]
pub extern "C" fn foo(a: i32, b: i32) -> i32 {
a * b
}
念のためfoo.oを削除しておく
$ rm foo.o
そしてrustcでコンパイルしてオブジェクトファイル生成
$ rustc -O --emit obj --crate-type staticlib foo.rs
さっきと同様にオブジェクトファイルfoo.oが出来ている
$ ls foo.o
foo.o
再び全く同じくgccでmain.cをコンパイルして(rustcで作った)foo.oもリンクして実行ファイル生成
$ gcc -o main main.c foo.o
無事に掛け算が実行できました
$ ./main
ret = 200
つまりRustで書かれたコードとその生成オブジェクトファイルは
何の問題もなくgccでコンパイルしたC言語コードから呼び出せる
(もちろん逆向きもOK) >>96-98
それは>>69の解法1を取り得ることを意味するが
公式文書では>>80のように解法2が説明されており
解法1はvery experimentalとある
なぜだい? 誰でも知ってることを長文で書かなくていいから>>80読んでね >>86
>それができれば、所有権情報付きの型に対応できることになるから、
これが気になってて
>>98みたいにno_mangleすると
所有権システムは制限されるのかな? >>99
その文書に根拠が書かれていないからわからない
その文書によるとclangとrustcならば上手くいくのだからRust側の問題ではなくclang側の問題でもない
仮に問題があるとすればgcc側の問題なのだろう
そしてその場合かあると仮定するとC言語のみでもgccとclangで上手くいかないケースが存在するのだろう very experimentalなのは単純に実績が浅いからでしょ
同じ規格に合わせて作ったつもりでも実際に組み合わせると想定外の問題が生じる場合がある
この辺は結合テストの経験がないとピンとこないかもしれない >>103
実績は10年以上あるでしょ
例えば/usr/lib/の下にあるライブラリファイルがgccかclangかどちらでコンパイルされたものかに関わらず
gccからもclangからもそれらライブラリを区別なく使われて問題を起こさず動いてきた
そこはELFのフォーマットが定められているからコンパイラの違いがあっても大丈夫 linuxのソースに含まれない外部配布のカーネルモジュールのコンパイルって
普通コンパイラを（バージョンも含めて）揃えない?
神経質過ぎるだけかな? 生産性最強は…「さくっと探してくる」
なんでも自作(内製)しようとしちゃうよね、自分にもそんな時期がありました
勉強にはなるけど >>93-95
hissi.org を AI に掛けたらそろそろ自演検出出来る時代 >>101
こういうことじゃないか
少し前にRust派が貼った https://github.com/microsoft/windows-rs は、
win32 APIをunsafeなRustで受けてる そういうreadmeになってるからそうなんだろう
unsafeなAPIにRustが接続してるんだから、たしかに道理
Rust派がいうように、どんどんRust世代(Swiftとかも含む)のAPIが増えてくると、
所有権情報がついたAPIになるわけだから、C++(とC)も当然それに合わせていく必要があるし、
それがわかってるなら、いまのうちから追随に向けたC++の発展を期待するぜ、っていうわけ C++なんざ何処が良いのか分からん
C#ほどセーフティーな訳でも無ければ
アセンブラみたいに痒い所に手が届く訳でもない 普通はインラインアセンブラとか使えるぞ たまに便利 >>110
>所有権情報がついたAPIになるわけだから、C++(とC)も当然それに合わせていく必要があるし
C/C++の言語仕様・ライブラリでこれをサポートする予定があるのか サポートしてもらわないと困るって話
Rustがそこまで普及するんならね C/C++の問題点はプログラム全体がunsafeエリアな点にある
Rustのように自動的に安全が保証されるsafeエリアを作るべきだ unsafe { } なコード描き捲れば良いじゃん
誰も止めないし 生のメモリはunsafeだからunsafeなエリアをゼロにするのは無理だが最小限に閉じ込めることはできる
ちなみにunsafeなエリアとは自動的に安全性が保証されず人間が安全性を保証しなければならない意味であり安全でないコードの意味ではない
C/C++は全てがunsafeなエリアとなっていることが根本的な問題であるためC/C++に導入すべきはsafeなエリアとunsafeなエリアの区別の導入 科学者は、新しいものより古いものを好むような気がする。
やっとFortranからC++に移行したみたいな感じじゃない。 unsafe { C++ }
unsafe { unsafe { Fortran }} >>118
ある年齢以下だと科学者でもかなりpythonが主流派だよ。 unsafeは名前が悪い。
noguardがguidelessの方が実態に合っている。 >>121
同意。
rustも別にunsafeだから安全じゃないってわけじゃないからな。 >>121
>noguardがguidelessの方が実態に合っている。
wwwww
guidelesswww 俺はコンパイラの支援なんか不要！
安全なコード書けるから！
などというバカ対策 いくら自信があっても
いくら百戦錬磨のプロでも
思い込みや見逃しでミスが入り込む可能性がある
そしてミスがないと主張してもその客観的な根拠はなく頭の中にしかない
C/C++にも客観的に自動的に安全性が保証されるsafeエリアを導入すべきだ
そしてプログラム本体にunsafeエリアが露出せずに済むようにsafeなライブラリ関数を充実すべきだ もっともマトモな層は、コード書きに行ってこんなとこ来ないからｗ 散髪屋に安全ガミソリを強制したり、マシン語プログラマを
蔑みそうな思想だな。 安全ガミソリは刃に毛が挟まって取れなくなって、
再利用しにくいのに対し、直刃のかみそりは、
安全面さえ気をつければ手入れが簡単で再利用しやすい
からプロは後者を好んで使う。
それと同じ。 直刃のかみそりを好んで使うプロたちに対して、
「お前らは客の安全性を疎かにする自信過剰で傲慢な
駄目な奴ら」
だとか言うつもりか。 >>134
消毒(sanitize)はどうしてるのかって問題はたしかにあるな
俺は気にしてないが、気にする人がいてもいい マシン語プログラマに対して、
「おまえらは、自身の腕を過信する安全性軽視の
駄目プログラマだ」
なんて言う権利は他人には無いと思う。 >>137
安全性とは何なのかも定義も理解できていないからそんな馬鹿げた書き込みばかりしてるのか 結局、相手を馬鹿にしてRustを推すのが、Rust信者の
やり口。 安全カミソリは安全ではないし
直刃のカミソリを使うプロでも客に切り傷つけることはよくある 直刃のカミソリっていうか、柄もないカミソリの刃だけを使うようなもんだろ。
自分も痛い目みること含めて。 他人が書いた部分や使ってるライブラリやその孫ライブラリまで含めて全ソースをチェックするのは非現実的だからな
もちろん自分で書いた部分やリファクタリングした部分も万が一のチェックを書き換えるたびにするのも手間暇コスト増
unsafeでもunguardでも呼び名はなんでもいいからsafe/guard部分がコンパイラによる自動チェックされるようになれば人間がチェックすべき部分は激減できる ダングリングの検出ってGPTの登場で
言語側が備える意味は最早なくなった
そのうち外部にチェックプログラムが登場するよ
ABIが非互換になるデメリットを考えると
なおさらRustに追随する言語はないと思う
さよならRustの未来を信じた皆さん >>144
ダングリングなんて小さな問題だけが対象ではないことを理解していなさそうにもみえるが
これまで外部ログラムがいくら頑張っても各種問題を静的に見つけることはできていないし今後も無理だろう
AIであろうとそれは同じであり神のようなAIが登場するならその時は全ての言語のプログラマー全員廃業だ >>144
外部のチェックツールって今までもあったけどね。
上手いプロンプトを考えられたらいいね。 >そのうち外部にチェックプログラムが登場するよ
今まで使ったことないのかよww 残念だけど言語サポート無しにRustと同じレベルのチェックは不可能
それがわからない時点で安全なコードを書く能力もないことが分かる >>149
SendやSyncのマーカートレイトなど
様々な安全性を型チェックで保証できるような枠組みがRustには揃ってるあたりのことか
C++にも導入すべきだよな
C++は色んな機能が足りなすぎる Rust信者の正体は、ぎゃあぎゃあ五月蝿い評論家だ。
自分が上だと思って色々言ってくる。 実際にソフトウェアでサラリーマンとしてではなく、事業
として成功している人以外の意見はさらっと流して無視
しなければ、上手く行かない。 >>155
Rustが様々な安全性をコンパイラで保証できる仕組みは
例えばスレッド間での移動や共有の可否などを抽象的なトレイトで表現して
各型をそれらのトレイト境界で制約して型チェックで実現したりしているようだから
C++にもそういう仕組みを導入すれば自動チェックの可能性が出てくるね >>156
将来的にそういうのはエディタに組み込まれたCheckGPTがやってくれるんじゃん >>157
言語仕様に組み込まれていないとそれは不可能と思われる
もしそれさえ覆すAIが出現した時にはプログラミング言語自体が全て滅びてしまう新時代となる
その新時代になるまでは言語仕様が強力なRustがAI支援で圧倒的に有利にみえる >>158
AIに最適化された言語が登場するのかも >>158
>言語仕様に組み込まれていないとそれは不可能と思われる
そなの?
人間がソースコードを読んで発見できるバグなら
直感的にはAIにも出来るのでは? >>160
そこは単純な話でプログラミングよりも遥かに難しいため
つまりそれが可能な領域にAIが達した時にはAIが最初から全て行なうのでそもそもチェックも不要になる 人間がソースコードを読んで発見できるバグなら最初からバグ入らない 人間が読んで発見できないバグをRustが発見できるかのような言い草だな たぶん、いきなり初作でバグ書いたりはしないと思うのな
あとで改造したときにエンバグする
そこでコンパイルエラーになるように言語ができてる ChatGPT-4では検出できないが
Rustで書けば検出出来るC/C++のバグを考えようぜ
ChatGPT-4はかなり賢いので俺は既に無いと予想するよ ChatGPTは、
じゃんけんの論理構造が理解できないから、じゃんけんの
プログラムのバグを発見できない。 とりあえずシンプルなバグ
ChatGPT使い方分からんから検証は任せた
C++は長いこと書いてないから古い書き方があったらすまん
#include <iostream>
#include <string>
#include <vector>
using namespace std;
int main() {
auto names = vector<string>();
names.reserve(8);
string empty = "";
string *longest = ∅
while (true) {
string name;
cin >> name;
names.push_back(name);
if (names.back().length() > longest->length()) {
longest = &names.back();
}
cout << names.size() << " names, (longest: " << *longest << ")" << endl;
}
} なんか＆empty；が空集合の記号に変換されて表示されてしまった…
たしかに文字参照形式だけど5chのバグ踏んだんかな >>169
Thanks! そのまま貼るね
I: C++プログラムのバグを教えて欲しいのですが? コードレビューをできますか?
G: もちろんです、C++のコードを見せていただければ、そのコードのバグや改善点を提案することができます。どんなコードをレビューすればよいですか？
I: >>169のコード
ただし string *longest = は string *longest = nullptr; に修正 G: コードを見た結果、最初の問題点は次の行で生じます。
if (names.back().length() > longest->length()) {
G: 最初の入力が行われる前、longest ポインタは nullptr に設定されています。
したがって、デリファレンス操作（-> を使用）は無効なメモリへのアクセスを引き起こし、
これは未定義の動作につながります。
この問題を解決するためには、longest ポインタを使用する前に、
有効な string オブジェクトを指すように設定する必要があります。
コードを次のように修正することで、
最初の入力の後に longest ポインタを設定することができます。 #include <iostream>
#include <string>
#include <vector>
using namespace std;
int main() {
vector<string> names;
names.reserve(8);
string *longest = nullptr;
while (true) {
string name;
cin >> name;
if (name == "exit") { // 終了コマンドを追加
break;
}
names.push_back(name);
// 入力後にポインタを初期化
if (longest == nullptr || names.back().length() > longest->length()) {
longest = &names.back();
}
cout << names.size() << " names, longest: " << *longest << endl;
}
return 0;
} もし空集合の記号が見えてたら＆empty；（←半角）に修正してほしい
nullptrだと最初の比較で普通に死ぬから意図したバグが出ない 文章を解釈してオーダにない修正（exitの追加）までしている
ChatGPT-4はマルチスレッドの競合状態なんかも検出するよ
デッドロックは試してないがら無理かもね
Rustはデッドロックは検出するんだっけ? 173見るとnullエラーは検出するけどvectorの再配置によるダングリングは見逃す感じでいいのかな >>174 修正してみた
-string *longest = nullptr;
+string *longest = ∅
G: あなたのコードは、ユーザーからの入力を無限に受け取り、
最長の文字列を保持しようとしていますが、問題がいくつかあります。
まず、reserve関数はメモリを確保しますが、実際の要素数を増やすわけではありません。
したがって、push_backを使用すると、reserveで予約された領域を超えてメモリが確保されます。
しかし、それはこの特定のコードには重大な問題ではないと思われます。
大きな問題は、無限ループとポインタの管理です。
1. 無限ループ：while (true)とすると、無限ループになります。
これは、ユーザーが特定のアクション（例：特定のキーワードを入力する）を行わない限り、
永遠に終了しないプログラムを作成します。
これを解決するためには、ループを抜け出すための条件（例：空の名前が入力された場合）を設定する必要があります。
2. ポインタの管理：longestへのポインタが問題です。
names.back()が返す参照は、次にpush_backが呼び出されると無効になる可能性があります。
これは、push_backが内部の動的配列をリサイズする必要がある場合、
新しいメモリ領域に要素が移動され、古い参照が無効になるからです。
以下に修正したコードを示します。 俺、C++ド素人で>>169が何をしているのかさっぱり分からんから、
どこが悪いのかさっぱり分からんが
でも、ChatGPTは何をしよう(しているのか)を理解して
(質問者にvectorの再配置でポンタ無効になるからと教えて)
>>171のような修正を提示するんだな。賢すぎだろ #include <iostream>
#include <string>
#include <vector>
using namespace std;
int main() {
vector<string> names;
string longest = "";
while (true) {
string name;
cin >> name;
if (name.empty()) {
break;
}
names.push_back(name);
if (names.back().length() > longest.length()) {
longest = names.back();
}
cout << names.size() << " names, (longest: " << longest << ")" << endl;
}
return 0;
}
このコードでは、longestがポインタではなく値として管理されているため、
namesの内容が変更されても影響を受けません。
また、名前が空の場合にループを抜ける条件を追加しました。 >>176
その通りだね
ところが>>177の修正を加えて返ってきた答えには
vectorの再配置によるダングリングを考慮してある
>>177以外の修正は俺は一切加えていない
まだ間違った答えを返すことがあるが
正解を返すポテンシャルは既にある ところで>>175なんだけど
Rustってデッドロックって検出できるんだっけ? いま、C＋＋で生ポンタを使うこと避けるようにするんじゃないのか >>174
サンクス
さすがにこのレベルだと検出できるか
（ほかに目立つバグがあるとスルーされるのかもしれないけど） デッドロックは人間でも解決できないパターンがあるからｗ あらゆるデッドロックを検出しようとするとデッドロックするから無理って
チューリング先生が証明してたと思う
停止性とは違うのかもしれないけどどうせ帰着ルート見つけるでしょ（適当） AIに関して。たまたま上手く行ったケースだけを
書いている可能性がある。
実際にやってみると変になることもあったりする
のがよくあるパターン。 >>186
>>171は1回だよ そのあと>>170を読んだので
チャットの途中から>>177の修正を加えて回答を生成させた
これも1回限り
ChatGPT-4を普段触っていて能力を知っていれば
納得の回答レベルだと思うけど? std::vector でよくある性質だけ、ChatGPTに
ハードコーディングされてる可能性がある。 >>181
デッドロックは静的に(実行せずに)検出できないことが理論的にわかっている
そのためRustを含めて任意のシステムで静的にデッドロックを検出するものは存在しない デッドロックはロック順序が定まるように自主的対応するとして
一方でデータ競合についてはRustがデータ競合のないことを保証してくれる >>190
データ競合はChatGPG-4も検出してくれる 実は俺は未来が見える。
Rustは普及しない。
いっちゃった。
ヤバイ。 >>191
ChatGPTは検出できるケースもあるだけだぞ
Rustはデータ競合を100%回避できる
そしてデータ競合は100%回避しなければならない
100%回避できる方法がある状況でそうではないChatGPTに頼るやつはバカだと断言できる >>193
GPT4使ったてないやろ？
そんなもんじゃない >>194
100%防がなければいけないこと(今回の例だとデータ競合)で
ChatGPTに依存するは愚の骨頂
ましてや100%防げるRustが存在する状況で >>195
だってRust覚えるのめんどいじゃん？ >>196
Rustは必要な高機能が充実しているにま関わらず
洗練されていて覚えることが少なくて楽だ
C++はC++20まで把握してもまだRustの高機能に追いつけていない RustやってもCを別に覚えなきゃならないじゃん?
C++覚えればCはサブセットだし楽だよ
なによりRustはやってる人が少な過ぎて人が集まらん RUSTぐらいサクッと習得出来る人じゃ無ければ集まらなくって良くない？ >>198
そういうのはdyn-upcastとかspecializationとかのRFCをstabilizeしてから言ったほうがいい Rustは速くsimd命令周りをstableにして欲しい。 信者の脳内でLinuxは大成功している事と同様の事也。 それじゃ全然足りないってことでしょ
「信者が～」とか言っちゃう奴って目標高過ぎというか欲張り過ぎなんだよね
どっちが信者だよって感じ 無料なので、100均やユニクロより地位は下だということなんだがな。 Linuxと比べれば底辺の食べ物みたいに馬鹿にされる
サイゼリヤやマクドナルドの方が遥かに高級ということになる。 そしてgccやemacsやnasmは貧者のツール。 >>211
50代だと思うけど引きこもりなのかな?
力になるよ アメリカ製のSNSが存続できているのは、アメリカ政府の
補助金のおかげ。YouTubeは個人情報をアメリカ政府に
差し出す見返りに政府から補助金を得ている。 Rust叩きをしている人たちがちょっと頭のおかしい人たちばかりなのは偶然なのか必然なのか >>214
C++も無料だから、それを言ったらどっこいどっこい スレのレベルがまた一段と下がってるね
低学年の小学生みたいw >>199-200
今Rustで募集すると間違いなくゲーマーが応募してくる >>221
ほとんどのプロは無料環境を使ってない。 GTK, wxWidgt, Qt, CodeBlocks などを試してみたが、
どれも使う気になれなかった。Qtは有料だが。 >>229
その中でましな方のCodeBlocksですら、
メニューやボタンはあれども機能しない項目が
多かったり、順序によって機能し無かったりが多く、
どのような順序で事を行なっても動作するところの
VC++とは使い勝手が全く違った。 手短に言えば「みかけだおし」で実際には機能しない
メニュー項目やオプション類が多数あって、混乱した。
gccもオプションは多すぎるほど多いが、実際にちゃんと
機能するものはほとんど無く、-I -L -O1 -v みたいなもの
だけに限られ、他のオプションは指定してもまったく機能
しないか、機能しても他のオプションと併用すると破綻したり、
または、機能しても僅かな変化しかなく、msvcが大胆に
機能変化するのとは全く異なっている。 また、ボランティアによってせっかくチュートリアルが
作られていても、「すぐに変化して」しまうため、
最新版とは同じにはならない。
しかも、チュートリアルなしでは使いこなせないような
インターフェースになっており、非常に使い勝手が
悪かった。
このことは、3DモデラのBlenderでもあてはまる。
価値観の異なる別の人がプログラミングに参加してしまう
せいか、一年たてば、使い方ががらりと変化してしまう。
そのため、YouTubeなどでボランティアが多大な時間と
努力で作り上げた解説動画と、最新版の使い方が大胆に
異なっている。それで、古い解説動画扱いされ、
老害扱いされる。せっかく努力した人の努力は水泡に帰する。
これはまさに共産主義。努力した人をあざ笑い、何もしなかった
人が安泰になる仕組み。 んーなんかよくわからないがUIビルダー試してるって事かなあ？
RUSTから離れて行ってね？ Rustも同様の事が起こる可能性が高い。
#OSSを見守ってきた人生経験より。 >>228
GTKは糞(GTK自体はC)
wxWidgetsは優秀(C++)
QtはQMLになって糞化(C++)
Code::Blocksは(C/C++)実質wxWidgets
どれも使えないのはC++の理解が足りてないんじゃないか
馬鹿自慢してるようなもの 有名なOSSツールで、年々ツールのバイナリサイズが肥大化
し、異常にサイズが大きくなってしまったものも知っている。
16BIT時代から続く有名なOSSだが、そのころから機能は
僅かしか追加されて無いのに、今や、4GB位のストレージ
を消費してしまう。機能は16BIT時代と対して変わってない。
16BIT時代だったら、数MBだっただろう。 >>235
使えるが、使いたくなかった。
なんでそんな苦労しなきゃならないのか分からん。 >>234
まあRustがTauri薦めてる時点でRustもひどいってのは同意 >>237
機能が2倍くらいになって徐々に肥大化して言ったならまだ分かる。
しかし、数年前まで32BIT版で500MB位であって、
機能は1%も追加されて無いのに、4GBになった。
これがOSSソフトの典型例。
パソコンの性能は劇的に増加したのに、インストール時間は
むしろ長くなった。
細かい時間は忘れたがインストールするだけで10分以上はかかった。 それに、ユーザー数やシェアを考えれば、優先順位は
Windows、Android、iOS、、Mac、Linux 位の順で
なければならないのに、多くのOSSでは、ターゲットもホストも
大体、Linux、Mac、Windows、iOS、Android
のような順序になっており、ほとんど逆に近い。
このことも、ストレスフルになる。 OSS作者の多くは、Linuxをメインに開発していて、
Windowsは「仕方なく」対応していることが多いらしい。
だから、WindowsとLinuxの違いのために面倒な
追加コーディングが必要になったときには、ストレスフル
となり、いやいやコーディングしてしまう。そのため、
Windowsでは中途半端な出来栄えとなり、どこかに
不具合を抱えていることが多い。
そしてそれを自分の責任とせず、Windowsや、Windows
を使っているユーザー、または、Windowsを使っている社会
などに責任転嫁してしまう。
その結果、そのような作者が多いOSSをWindowsで使うと、
ストレスフルで使う側が嫌な気分を味あうことが多くなる。 AdobeのPDF Readderもそうである。
恐らくMacとiOS(やスマホ)のインターフェースを
ベースにしているため、Windowsユーザーには物凄く
使いにくい。
Windws版のKindle Readerも同様。物凄く使いにくい。
Google Mapのインターフェースも最悪だといわれている。
しかし、それがデファクトスタンダードとなっていて、
無料なことが災いして、競争相手が育たず、世界中の
人々が使い勝手の悪い無料ソフトで、生産性が悪い
社会となってしまっている。 >>228
それら以外にRust製のGUIもたくさんあるけど言及ないの？
>>239
RustがGUIとしてTauriを勧めたことなんて一度もない
Rustにも多様なGUIライブラリが揃っている
Tauriに相応するものはElectronであってGUIといってもHTML/CSS/JavaScriptを前提とするタイプ
その比較では性能面でElectronよりTauriが優れているというだけの話 >>ID:ctz5BWzh
世界は多様でいくらお前が望んでもそれは変わらない
皆（動物さえも）適応して生活している
ずっと読んできたが
おまいさんは多様性への適用能力に問題を抱えているんだよ OSSの作者は「逆張り」傾向が強い。
別の言い方をすれば天邪鬼。
だから、多数派向けのアプリを作りたい人には、
OSSの開発環境は足かせになる事が多い。 >>244
uby界隈の人は特にそういう傾向あるな つまり要約すると「俺の利益を優先させろ！」で合ってる？ >>251
OSS・無料ものはくそってことだろ
貧乏はくそなものでもただなら大歓迎だからな >>253
でも、乞食必死してるんだろ
貧すれば鈍するだから、時期にくそを受け入れるようになるよ。
無料もの使うと乞食化するし、そして、
くそ物を使うと使っている奴もくそ化するし
そうなってもそうなっている自覚はないだろうが OSSが有料だとか無料だとかそんな次元で語ってる時点で発想が乞食でしょ
自分で何か作って公開することで知識や技術を「交換」するみたいな発想はできないのかな
使わせて「貰う」ことしか頭にないなら仕方ないけど
OSSコミュニティがみんなそうだとは思わない方がいいよ つまり「俺が作ってるものは無料じゃないので糞では断じて無い！」なの？ >>254
>くそ物を使うと使っている奴もくそ化するし
>そうなってもそうなっている自覚はないだろうが
その通りだ
有料糞品の最大派閥が君の大好きなWindowsだ 有料でクソだと生き残れないが、無料だとクソでも生き残る。 >>224
＆empty;が∅で表示される問題は>>170が言う通り5chとそのブラウザの仕様バグで合っているんじゃないかな
5chのdat仕様はHTMLタグや文字参照(＆xxx;)を含んでいてそれらをそのまま表示することになっている
一方で利用者にとってはそんなことは関係ないため＆empty;の書き込みがそのままその内部表現となり文字参照として解釈されるのは自然ではない
もちろんそのまま通さずにエスケープ処理することで対応している掲示板やSNSも多い
文字参照はあくまでもHTML(や*ML)での表現であるため利用者がそれを会話や書き込みで打ち込むのを前提とするのはありえないからである
ではなぜ5chはこんな変な仕様になっているのかというとshift-jisのまま範囲外の文字を受け付けるためだ
これを仕様通りとするならば5ch専ブラ側は利用者からユニコードで受け付けてshift-jis範囲外の文字と＆等のみを文字参照として5chへ送るべきことになる
そうすれば利用者からの入力＆empty;は5chへ＆amp;empty;と送られて表示時も正しく表示されることになる 調べたら10年以上前に決めた仕様らしいから仕方ない
普通の文章だと＆...；みたいな文字列は出てこないし >5chへ＆amp;empty;と送られて
これが為されてないのは専ブラのせい？ >>231
>gccもオプションは多すぎるほど多いが、実際にちゃんと
>機能するものはほとんど無く、-I -L -O1 -v みたいなもの
>だけに限られ、他のオプションは指定してもまったく機能
>しないか、機能しても他のオプションと併用すると破綻したり、
>または、機能しても僅かな変化しかなく、msvcが大胆に
>機能変化するのとは全く異なっている。
バイナリ変わっとるやろ?
gccのオプションが多いのは否定しないが
お前が使いこなせていないだけ >>232
チュートリアルの批判は妥当だね
追従できていないことは多々ある >>232
最後の共産主義云々は飛躍せずに論理の筋道を書かないと全く意味が分からない
まともな批判も書いているのだが
社会生活を送っているように思えない書き込みも散見される >>237
ソース見れば肥大化した理由が分かるのでは?
OSSなら知る自由があるよ 日本人は知らされて無いけど、中国がずっと前からOSSを推進しており、
githubのスポンサーも中国企業が多いと聞いた。
それにgithubの一番人気ソフトは中国製。 こいつの言ってることが本当なら、それらの問題点を改善したソフトを
有料で売れば大儲けできるのになぜかやらないんだよなぁ >>270
githubのスポンサーというか所有者はあなたが信奉して依存しまくっているMicrosoftです >>272
githubの所有者とは別に、スポンサー企業と言うのがあるんだよ。 この板を含め、ネットでは、技術よりマーケティング重視の人が多い。
それで日本の技術力低下が起きたのではないか。 テレビを見ると、やたらと技術だけでは駄目、という言葉ばかり
叫ばれるが、GAFAMは、技術先行型、プロダクトアウト型だと
言われている。実は、マーケットイン型は、模倣され易いと言われており、
だから、新興国に模倣されているのかも知れない。
GAFAMのものは、技術先行型だから他社が真似するのは難しい。
模倣しようと思っても模倣できない参入障壁が多い。
検索エンジンやChatGPTも、プログラミングだけでなく、処理能力が
桁違いに大きなスパコンの様なデータセンターが必要だと思われる。
そして二番手以下は全く売上げがたたないので大赤字となるため、
参入できない。
それが自動車産業や家電業界とは異なるところ。 コマンドラインアプリってRustってどこが向いているの？
例えばメモリリークしないっていう謳い文句があるけど別にCやC++だったらコンパイラやCLIみたいなすぐ終了するプログラムは一回もfreeしなくてもいいわけで
その場合はまるでGC言語みたいな自由な書き方が選択できるわけじゃん
メモリリークなんてどうでもいいのにそれを強制的に意識させられる言語なわけだがCLIに何が向いてるのかわからん >>278
根本的に勘違いしているようだが
GC言語が遅いのはGCでメモリ解放処理をするためではない
GCが起きる前に終わってしまうプログラムでも遅いことを知っているはずだ
もう一つ
Rustはメモリ自動解放されるからfree()とか気にする必要はない
RustはCLI含めて様々な用途に向いている
さらにもう一つ
「CLIみたいなすぐ終了するプログラム」
CLIとGUIでそんな差があると勘違いする人はかなり珍しい
CLIであろうが時間のかかる様々な処理にサーバーなどすぐに終了しないものが多い C/C++ → ライブラリの用意がめんどい(cargoとかnpmみたいな現代的な仕組みがデファクトで存在しない)
Ruby, JS, Python, Java → 処理系のバージョンや依存ライブラリのインストールに悩まされる。バイナリポンできない。
Go → GCとかでフットプリントがでかい？わりと Go でもいいじゃん派。
clap の出来もいいし向いているかはさておき秀作として CLI から始めやすいしバイナリポンでプロダクション投入しやすいのはあるね。 >>282
>C/C++ → ライブラリの用意がめんどい(cargoとかnpmみたいな現代的な仕組みがデファクトで存在しない)
はい? 何がめんどい? >>282
>Ruby, JS, Python, Java → 処理系のバージョンや依存ライブラリのインストールに悩まされる。バイナリポンできない。
aptでええがな >>281
>Rustはメモリ自動解放されるからfree()とか気にする必要はない
はあ？
Cでfreeしない場合はGC言語みたいに好きに書けるけどRustはそもそもルールを守って書かないとコンパイルが通らないだろ？
そもそもそのコンパイルを通すためにルールを守ることを強制するってのがどうなのって話
データ構造やアルゴリズムに制限を加えてるってことだよね >>286
何を言いたいのかさっぱりわからない
プログラミング経験がないのか？ >>189
GPT4を舐めてはいけない
I: C++プログラムのバグを教えて欲しいのですが? コードレビューをできますか?
G: もちろんです、お気軽にコードを共有してください。
バグを特定したり、最適化やリファクタリングの提案をしたりできます。
I:
#include <thread>
#include <chrono>
using namespace std;
int main () {
using Lock = lock_guard <mutex>;
mutex m0;
mutex m1;
thread th0 {
[&] () {
Lock l0 {m0};
this_thread::sleep_for (chrono::seconds {1});
Lock l1 {m1};
}
};
thread th1 {
[&] () {
Lock l1 {m1};
Lock l0 {m0};
}
};
th0.join ();
th1.join ();
return 0;
} G: このC++のコードにはデッドロック（両方のスレッドが無限に待機する状態）があります。
th0スレッドはm0をロックし、その後m1をロックしようとします。
一方、th1スレッドはm1をロックし、その後m0をロックしようとします。
これは次のようなシナリオでデッドロックになる可能性があります：
1. th0がm0をロックします。
2. th1がm1をロックします。
3. th0がm1をロックしようとしますが、m1は既にth1によってロックされているため、
th0はm1が解放されるのを待つことになります。
4. 同様に、th1がm0をロックしようとしますが、
m0は既にth0によってロックされているため、
th1はm0が解放されるのを待つことになります。
結果として、どちらのスレッドも他方がmutexを解放するのを無限に待つことになり、
デッドロックになります。
これを解決するためには、両方のスレッドがmutexを取得する順序を一貫させることが重要です。
以下に修正したコードを示します： G:
#include <thread>
#include <chrono>
using namespace std;
int main () {
using Lock = lock_guard<mutex>;
mutex m0;
mutex m1;
thread th0 {
[&] () {
Lock l0 {m0};
this_thread::sleep_for (chrono::seconds {1});
Lock l1 {m1};
}
};
thread th1 {
[&] () {
Lock l0 {m0};
Lock l1 {m1};
}
};
th0.join ();
th1.join ();
return 0;
}
G: この修正により、どちらのスレッドも最初にm0をロックし、その後m1をロックします。
このようにすることで、スレッド間のデッドロックを避けることができます。 まもなくVisual Studioを始めとした開発環境にGPTが統合されるだろうから
Rustのセールスポイントの価値は崩壊する >>288
競プロでもRustが向いてないのはそういうことだし、データ構造やアルゴリズムの実装パターンに制限を与えるのがRust言語だよね
freeを一切しないってのもプログラムの設計パターンとしてあるし、そうやって実装されてるコンパイラもあるわけ
低レイヤを触るプロフェッショナルからしたらそんなの足枷になるだけだろ？
コンパイルも遅くなるし
ある意味縛りプレイを強要しているわけ
マゾ言語だな >>293
壮大な勘違いをしているようで何を言いたいのかわからん
話を単純にするためにRustのことは横においとくとして
C言語でfree()をすると実装パターンに制限を与えるからfree()しない方がよいという主張なのか？ >>292
それ、プログラマも要らなくならないか？ 家でもパンツくらい履け派と履かんでもよかろうもん派 >>295
要件を定義するのに特化したのがプログラミング言語だから
自然言語での要件定義は不効率だと思うよ
数式なしの数学の本が本当に良いか?って話と同じ >>294
Cだとmallocするだけでメモリ解放はプロセス終了時に任せるという設計パターンが取れるわけで、そのすればGC言語と同じように好きなタイミングで動的確保していけるわけだけど
Rustはできるの？できないだろ？
これは設計パターンを制限していることになるよね
同じくCで書かれたコードをそのままRustに移植すると難しかったりするだろう？
一種の書き方を制限することでプログラマの自由度をなくすのがRustの本質だよね Cだとパンツは外出するときに履けば良いわけで
Rustは家の中でパンツを履くのを強制している
夏はパンツ蒸れるねん >>292
どうみてもRustと無関係な話あるいは全ての言語に関係ある話だな
その手の話はRust叩きに使えない >>300
Rust最大のセールスポイントを
GPTを用いたコードチェッカの登場により
その他の言語全てが手に入れるという話
おまけにGPTを用いたチェッカーは
Rustでも不可能なデッドロックの検出可能となる >>298
Rustで何ができないと言ってるのかわからない
何か出来なかったことでもあるのか？
Rustでもメモリの返還を最後までしないあるいは途中で返還せずクライアント毎やバッチ毎にまとめて解放は普通に行なわれている手法 >>301
100%は合っていなくても大体合っていればいい文章生成動画像生成ならともかく
量が増えたり複雑化すると簡単な計算すら間違えるため数値計算にすら使えない状況で
100%確実なRustに対してどんなアドバンテージがあるんだよ
セキュリティ面を考えるなら吐かせるコードもRustにすれば解決だからRustが有利になる主張なら理解できる >>284
そこの面倒さが分からないの旧世代すぎだろ。
>>285
ディストリ毎の対応面倒すぎるだろ。MacとかWindowsも対応したいケースもあるし。 これまでRustを始めようとしてきた者は
学習コストの高さと享受されるメモリ安全を天秤に掛けて
なんとかRustを選んできた訳だがセールスポイントを失うのだよ
GPTを使用したコードチェッカはRustにとっては逆風だよ
C/C++のように普及した状態ではなくこれから布教させようってときに トランスフォーマーって意味の理解をしているわけではないとよく言われるが
>>289で>>290の解説が返ってくるところ
意味の理解が出来てるようにしか見えないなぁ...
規模がでかいってのは凄いやね >>305
学習コストはほとんど同じ
そもそも所有権やムーブのことならC++でも学習するしその学習に半日もかからない ChatGPTの登場でRustが有利になってるよ
ChatGPTは桁が大きくなったり複雑になったりすると計算すら間違うように論理的なことは苦手で100%を求められるチェックには向かないが
多少間違うかもしれないけど大雑把な生成は得意なのでコードの叩き台には役立つ
したがって叩き台のRustコードを吐かせて必要なら人間が補正指示を出すとともに100%チェックしてくれるRustコンパイラが通るコードを吐かせれば相性も効率も完璧 ChatGPTが監査しました、でお客様が納得するか、なんだよな
コンパイルが通る通らないでチェックしてくれるほうがいいっちゃいい
これは、C++のsanitizerも同様 今年に入ってどこも社会はLLM利用の体制を整えてきたと思う
当たり前の世界に直ぐなるよ ならば、パソコンだけで処理する時代が終わり、スパコン必須の時代に
入ったと言うことか。 動的型言語とGC言語をごっちゃにしてる人も存在するねこのすれ OSS推進の結果、パソコン向けのソフトウェアを売って儲けることが
不可能となり、アメリカのテック企業はサーバーサイドでスパコン
を差別化と参入障壁にし出した。Googleの検索エンジンもスパコン
有りき。AIも学習過程はスパコン有りき。パソコンでは不可能。 >>296
めっちゃ判り易いωωω
パンツはかない方が絶対速い OSS推進の結果、プログラマーの活躍が出来る時代は終焉した。
今後は、大資本を持つ大企業がスパコン有り気で設ける時代に
なるだろう。ベンチャーの時代も終わった。 >>316
OSS推進の結果、プログラマーが活躍出来る時代は終焉した。
今後は大資本を持つ大企業がスパコン有りきで儲ける時代に
なるだろう。ベンチャーの時代も終わった。 プログラマは高校生男子のなりたい職業No.1らしいが、もう時代遅れだ。
OSS推進をやめない限り、プログラマの価値は下がり続けるだろう。 >>314
スパコンww
基本的なことを知らなさ過ぎるのに
それを自認できないから妄想爺になるんだな
勉強になるわ >>316
Visual C++で個人利用のPC用のソフトを書いて販売
って最も原始的なビジネスモデルはとっくに終わっている
>OSS推進の結果、プログラマーの活躍が出来る時代は終焉した。
大企業で働いたりその資本で下請けのプログラマーとしてやれば良いのでは?
あるいはあくまで個人利用のソフトを書いて
ビジネスと考えるなら携帯用のソフトならありえる 今の若いもんには携帯ソフトって言っても通じないだろ
携帯アプリと言え >>320
>大企業で働いたりその資本で下請けのプログラマーとしてやれば良いのでは?
日本やEUにとっては、それは、自国が税金を使って育てた人材が
アメリカ企業に利用されることになるし、若者にとっては脱サラや
一国一乗の主になるという夢が絶対に実現しない最悪の社会になる
事を意味する。 >>323
>>>320
>>大企業で働いたりその資本で下請けのプログラマーとしてやれば良いのでは?
>日本やEUにとっては、それは、自国が税金を使って育てた人材が
>アメリカ企業に利用されることになるし、
なんだそれ? 日本人は日本企業でしか働いてはいけないという主張か?
>若者にとっては脱サラや
>一国一乗の主になるという夢が絶対に実現しない最悪の社会になる
>事を意味する。
あなたはビジネスの発想が最も古典的（原始的）なところ
1990年代で止まってしまっている
ソフトを書くこと自体は特に設備も大した能力もなく誰でも出来るんだよ
誰でも出来るってことは社会ではそれほどの価値しかないということ >>324
若者がなりたいのはプログラマーであって、経営者そのものではない。 日本政府は、「全ての人にやりがいが感じられる社会にする」と
言っているが、プログラマー志望の人が、プログラマーが苦しむ
ような会社を起業すれば、同級生や友達から軽蔑されるだろう。 一国一乗の主って零細ソフトハウスの社長かなんか？
アメリカ企業で出世するほうがよっぽど夢があるな >>327
それは日本人を苦しめることになるので同級生達に顔向けできない。 およそ社会生活をやってると思えない書き込みなんだよね
国粋主義っぽいことをたまに書くけど活動家ってほどの知識もなさそうだし
高齢で引きこもりでもしてるのかな? >>328
俺の同級生はそんな頭のおかしいこと言わないよ そもそも、アメリカで複雑な仕事が出来るほどの英語力を
身に付けられるエンジニアは少ない。それと、銃で殺される
問題や、人種差別問題もある。アジア人はプールにも入れて
もらえないと聞いた。 >>332
あなたもあなたの同級生も優秀なんだから問題ないでしょ そもそも祖国を離れてアメリカで仕事をするには勇気がいる。
長男だった場合、一家が途絶える。
また、少子化で長男率が高くなっている。 >>334
小学校の時の同級生は優秀ではない。普通の公立の小学校だったから。 >>335
>そもそも祖国を離れてアメリカで仕事をするには勇気がいる。
じゃ日本法人で働いても下請けのプログラマでもやれば良いのでは?
>長男だった場合、一家が途絶える。
徳川義崇さんの発言なら分かるが アメリカで一番不安なのは医療でしょ。
Rust純正の行列演算ライブラリはベース部分が大分完成してきて、行列積の演算速度はそろそろnumpyには並びそう。 >>338
ちなみに速度の測定は1000×1000の行列積の計算でやってる。 >>338
個人的には、なんかあった時、日本だったら助けてもらえるの
ではないかと思っている。甘い考えかも知れないが、最後、
生まれも育ちも先祖も日本人のよしみで、最後の最後、
見捨てられることはないかも知れないのではないか、と
いう期待がある。 TIOBE Index for August 2023
August Headline: Julia enters the TIOBE index top 20 for the first time
https://www.tiobe.com/tiobe-index/
Juliaに抜かれたら笑う OSSは、「最初の開発者が飽きても開発が継続できる」と言われるが
実際は、まるっきり環境が変化してしまって勉強し直しや、修正が
必要になる事が多い。mingw、mingw64、cygwin、msys、msys2
WSL、WSL2 など、それぞれの違いが微妙のようで大きく複雑で
混乱の元となる。ヘッダファイルやライブラリの違いで悩まされ、
コンパイラは有るがリンカが無い、リンカのライセンスが複雑、
ライブラリがGPLでGPL感染する、など、面倒な問題をはらむ。
以前と使い勝手が大幅に事なり、困惑することが多い。 >>347
>OSSは、「最初の開発者が飽きても開発が継続できる」と言われるが
>実際は、まるっきり環境が変化してしまって勉強し直しや、修正が
>必要になる事が多い。mingw、mingw64、cygwin、msys、msys2
>WSL、WSL2 など、それぞれの違いが微妙のようで大きく複雑で
>混乱の元となる。
それらは違うプロジェクトだから違って当然
寧ろかなり似ているから同じプロジェクトだと勘違いして混乱してるのかもね
>コンパイラは有るがリンカが無い、リンカのライセンスが複雑、
なにそれ?
>ライブラリがGPLでGPL感染する、など、面倒な問題をはらむ。
ライセンスに合意しないで使用してはいけない
お店で金を払わずに商品を取ってきてはいけないのと一緒 >>344
本当にシープラ置き換えるならGOくらい抜いてもらわないとな OSSの中では一番ましなCodeBlocks+wxWidgetの組み合わせも、
wxWidgetがLGPLなのも現実的に利用不可な理由の一つ。
CodeBlocks自体にも問題が有るが。
それに、そんなものを使っても、良い方向に進化してくれない。
普通、商品を買えば進化してくれる期待があるから寄付や投票
の意味で購入するが、OSSではそれができない。 >>351
>wxWidgetがLGPLなのも現実的に利用不可な理由の一つ。
何で? 電気ドライバー、ジグソー、ボール盤など、道具は、自分で作るの
ではなく完成品が欲しい。 それより大事なのは、作ったものを適正価格で売れるという当たり前の
環境。OSSは、それを破壊してしまうから協力したくない。 ストールマンもRustの作者もサイコパスだと思う。 わかったから糞レス連投で荒らすな
お前はSteamでクソゲーを適正価格で買いまくって一生プレイしてろ >>356
「適正価格」ってのはおまいさんが売りたい価格じゃないんだよ 適正価格と言うのは、1000円や500円かもしれない。
OSSは0円だからアカンのだ。 ソフトが0円になった結果、人を集めて広告料で儲ける仕組み
しかなくなって、万人向けのサービスと、異常に高いソフトしか
なくなり、ニッチだが中間的な価格のソフトが存在しなくなって
しまった。 >>360
ソフトウェアってのは複製コストが0円なんだから
0円で書ける人がいるのなら1000円や500円は適正でない だよな
ソフトやアプリは無料で
プラグインやアプリ内課金やサポートωなんやらで儲けるのを
LGPLは妨げない >>364
彼らは絶対、プラグインもGPL感染させようとするぜ。 >>363
検索エンジンは既にインフラであり、公共財の様になっていて、
電力会社や携帯キャリアが大儲けできるのと同じ状態。
そのアメリカ企業が儲けた金で大量のプログラマを使って
開発したソフトを各国の国会の許可無く世界中にばら撒いては、
自国のソフト産業が壊滅的になってしまう。 今の状態は、Googleが税金で作らせたソフトを世界中にばら
撒いているようなもん。
「税金じゃないから自由じゃん」
では通らない。
そんなことをするには、各国の国会の許可が必要。
もっとコントロールして80%の税金を払わせないと駄目。
税金は元々そのような意味もあるんだから。 どの企業も同じでは駄目で、検索エンジンだけは税率を90%位に
あげなくては、公平さが失われ、アメリカだけが裕福になり、
他国は全くソフト開発できなくなる。 >>364
現実に上手く行っている日本企業は一つも無いはず。
アメリカ企業でもRedHatみたいに不可解な企業以外にはないはず。 >>367
意味不明
少なくとも日本は法治国家なんだから
法律に従わなければ違法となる
法律はもちろん選挙によって選ばれた
議員により構成される国会で立法されている
違法でなければそれが民意ということだよ >>369
どこが不可解なのかな?
前にあなたはもの凄いことを書いてたが
RedHatは決算が公表されている上場企業だよ? >>371
日本企業が同じ事やっても大赤字になるのに、RedHatだけが
儲かっている異常さ。同じ事やっても結果が違うと言うことは、
経済原理に合わない。ということは、カルト信者が存在する
ことが濃厚。 >>372
RedHatが粉飾決算をしていると言ってるようだが
粉飾決算は犯罪なのを知らないのかな? なんで個人利用のPC用のソフトを書いて販売って
原始的なビジネスモデルしか発想に出てこないのが謎
OSSで商売をする4つのビジネスモデル
https://japan.zdnet.com/article/35079152/ この人は昔の（90年代くらい?）成功体験に囚われているってことなのかなぁ スレの勢いは凄いから自演じゃなければ人を釣る才能はあるな
人を釣るところから金を巻き上げる技術が不足してる >>286
C言語でルール守らないで書いてコンパイラ通るってどう書くの？ >>373
粉飾決算だとは言ってない。
カルト信者に支えられている、と言っている。
イギリス陸軍、アメリカのUPS、アルゼンチンの最大電力会社
などからの大量資金注入もある。 Rustってライセンスよく確認しない人たちから異様に嫌われてるよな
そういう人と距離置くためだけに学習するのも 'アリ' なんじゃないか？ >C言語でルール守らないで書いてコンパイラ通る
コンパイラ通るけど行儀が悪いと言われるコードは溢れている
バグったまま気付かれていないコードも溢れている
行儀が悪いと言われることとルールを守らないことがどの程度一致するかは
それぞれの言葉の定義次第でもあるがその定義がそもそも揺れている >>286 > そもそもそのコンパイルを通すためにルールを守ることを強制するってのがどうなのって話
そこが難しいところ
バグが減るような絶妙なルールってのを、長らくC/C++は持たなかった
Rustが大胆にそれを提唱して、受け入れられつつある いまここ
いまのRustがベストかはわからない RustIIみたいなものがさらに生まれるのかもしれん
だが、C/C++に、「絶妙な追加ルール」が求められてるのは事実 Haskellみたいに良いところだけ他の言語に輸出する存在になってくれ
書くの怠いから流行らないで🥹 >>379
>粉飾決算だとは言ってない。
以下のように確かに言っとる
https://mevius.5ch.net/test/read.cgi/tech/1686046386/629
>RedHatが大儲けしていると言うのも嘘。カルト信者の
>集団協力により、数値が捏造されているだけ。
内心に何らかの仮説を持つことは構わないが
それを事実かどうかも検証もせずに
抑制せず外に表出してしまうことが普通の人と違う
これは被害者を生み出すことになるので差し控えよ >>385
信者が大量購入していることもOSSの評判を上げるための捏造と言えば捏造。 >>386
お前は「大儲けは嘘」と書いた上で「数値が捏造されている」と明確に書いている
つまりRedhatは本当は利益が出ていないのに
決算の数値を捏造して公表していると主張をしていることになる
RedHatは犯罪を行ってると主張していることになるが?
ちゃんと撤回したら? >381-382
C/C++は微妙にルールから(意図的に)外れて良いのがウケたんだよ
C/C++を必要以上に縛ったらそれはもうC/C++ではない
べつもの >>387
彼はRust信者のいいエサになるからここにいてくれて構わないよ 恐らく決算は、捏造はして無いだろう。
信者のお布施で利益が出ている企業が、普通の企業のように
振舞っていると言うだけで。 >>392,393
>恐らく決算は、捏造はして無いだろう。
素直に撤回すれば良い
憶測だけで根拠なく他人を犯罪者呼ばわりすると名誉毀損になる
>>375にも上げたけどまずは以下を読むと良い
OSSで商売をする4つのビジネスモデル
https://japan.zdnet.com/article/35079152/ >>394
金持ちにかかれば、どんなものでも儲かっているかのように偽装でき
るので、自分の主張を通すことが可能で、OSSを世界に広めたいなら、
その通りにすることが出来る。 >>395
>儲かっているかのように偽装
日本では「2. システムインテグレーションモデル」が多いと思うが
なぜ彼らが犯罪に手を染めると考えるのか?
動機はどのように考えているのか? 未完成で納品して改修で回収するエコシステムです本当にありがとうございました 「OSSでも儲かる教」のフロント企業RedHatがカルト信者による
偽装であったことがばれたから、火消しに躍起なのでは。 フランチャイズ店の9割が赤字なのに、本部が一部の店舗だけは
儲かるように制御し、それを代表例としてオーナー希望者に
例示する事例にそっくり。 フランチャイズ本部が儲かると思うなら本部へ行けば良いのに
自分は店舗側だと思い込むのはなぜなんだぜ
ひょっとして良い人なのかω 合法ではあるだろうが、サポートって言っても実質なんもやってない
ように見える。イギリス軍の幹部がOSS教に信仰があるのではないか。 それぞれ自分の頭でRedHatが正しいことやっているかどうかよく
考えればいい。日本は言論の自由がある国だ。反論があるなら
反論すればいい。どっちが本当の事言っているかは議論の流れで
それぞれが判断するしかない。 >>398
頭大丈夫か?
訳が有って引きこもってるのかもと思ってたが
論理的思考が弱いのかも 六本木麻布虎ノ門の森ビルみりゃ判るだろ
日本は土地貸しが儲かるんだよ
他は全部雑魚 頭おかしいやつの巣窟スレ
何しにこの板に来てるのこのキチガイども 一人で訳のわからん活動してる人以外はみんな暇つぶしでしょ 長年にわたってカーネルをいじり続けているのに、あんな程度
にしかならないなんて、技術力がとても低いんだね、RedHatって。 >>310
そういうチェック監査でChatGPTが使われることは永遠にない
ChatGPTは知能ではなく学習パターン知識に過ぎない
その学習も過学習や学習汚染で劣化する
対応できていない部分のためのモデル改善も他部分の劣化を引き起こす
> OpenAIのChatGPTなどのチャットAIは、医師免許試験の合格や驚異的な精度で数学を解くことができることが報告されています。
> しかし、2023年3月から6月の間に、ChatGPTが簡単な数学を解く精度などが急激に低下していることが報告されています。
> このようなAIの知能低下は「ドリフト」と呼ばれ、非常に複雑なAIモデルの一部を改善しようとすると、モデルの他の部分のパフォーマンスが低下する問題。
What is a 'AI drift' and why is it making ChatGPT dumber?
https://www.zdnet.com/article/what-is-a-ai-drift-and-why-is-it-making-chatgpt-dumber/
Why ChatGPT Is Getting Dumber at Basic Math
https://www.wsj.com/articles/chatgpt-openai-math-artificial-intelligence-8aba83f0 言語自体でチェック監査が可能なRustが主流となる
ChatGPTはチェック監査に不向きだがRustコンパイラが通り指定条件を満たすようChatGPTへ指示を出せばよく相性がベスト
ChatGPTができない部分だけをRustプログラマーが補佐する形になる
言語自体でチェック監査が不可能なC++にこのやり方は無理なのでC++は消える 流行りはしないでしょ多分
それ狙って作った言語でもないわけだし
ゆっくり一部でcやc++から置き換えられる程度でしょ >>413
コーティング規約を取り込んでいるのはRustの強みだけど、学習曲線が絶壁になる問題は解決できていない。
管理側はRustで土方のコード品質を高めたいんだけど、高級土方が必要になってコスト増になる両刃の剣。 >>416
GPTは現状でもコーディング規約とソースを読み込ませれば
規約違反の箇所も柔軟にチェックしてくれるし
修正を提案してくれる
数年以内にコードチェッカとして利用が一般的になると思う >>418
Rustというより、スタック構造が凄い。
もっとスタックフレーム指向の言語が出てこないかね。 >>419
俺が褒めてるのはGPTだよ
Rustはデッドロックは検出出来ないだろ？ ネットで議論が上手く行かない理由はいくつかある:
・利害関係にある当事者が出てきてしまい、第三者による議論が深まらない。
・驚いた顔や困った顔、反論できない顔、憤った顔、自信がある顔、
自信が無い顔などが見えないから、どっちが優勢か判断しにくい。
本当は困り果てた末、考えまくって反論してきているだけなのに、
まともな反論の様に見えてしまうことがある。
・年齢も分からない。結果、基礎的な勉強も終わって無い中学生が議論に参加していることがある。
・匿名な故に本当に優秀な人や専門性が有る人がどちらか分からない。
・優秀すぎると一週回って、馬鹿なように見えることがあるが、匿名
な故に経歴が分からないからそれを見極められない。 >>421
そういうのは権威主義と言って
議論において最も害悪で排除しなければならいなことだよ 議論というのは純粋に内容で勝負しなければならない
相手が中学生か大学の教授かで左右される議論など不毛の極み 討論会でも、見解に問題がある方は困った顔になることが多い。
サイコパスで無い限りは。
だから、中国の学生と討論すると中国人は負ける。なぜなら、
中国政府に嘘を叩き込まれていて、本当の情報を知らされて無い事
がその場で彼ら自身が悟るからだ。
負けたかどうかは表情で分かる。
ネットではそれが難しい。 違わない
権威主義とは権威におもねり結論が左右されること
権威主義はアカデミアにおいて害悪しかもたらさない >>426
そうでもない。中学生はまだ、十分に社会の事が分かって無いから
高度な議論には速すぎる。彼らを議論に参加させるとデタラメに
なり、社会が劣化してしまう。 >>427
不可能。
一定水準以上の頭脳を持った人だけを選別しないといけない。
だから、大企業は強い。 >>428
もしそうであるなら発言内容に反映されるだろうから
内容をもって判断すれば良いだけ
中学生の見解だからと事前にフィルターを掛けてはいけない
優秀な中学生もいるかもよ >>429
人間は権威に左右されるので難しいのは分かるが努力すべし
馴染みがないかもしれないが例えば論文の査読は匿名で行われる
なぜか? >>431
優秀かどうかは内容を持って判断することで
身分・職分で判断することではない
議論に権威を持ち込んではいけない こないだの常温超伝導の是非も、Natureや東大教授が
「間違いであると断定できる」
といいきれば、それを疑う人は少ないだろうが、中学生が
言っても無理だ。 >>436
それは議論とは言わない
例えば中学生が
根拠を示してその論理立てが正しければ賛同すれば良いし
根拠や論理立てに不備があればそれについて反論すれば良い
中学生が言っていることを根拠に
正しいだとか正しくないだとかは議論ではない
なぜか?
中学生であることを間違っている根拠にすると反証可能性がないから 技術的なことだけなら、中学生でも議論できるかも知れない。
ところが、社会的なことは無理。区別する必要がある。
だから選挙権が無いわけだから。
もっといえば、国会議員になるためには20歳でも無理。 たとえば中学生は、RedHatやOSS振興団体の書いている事を
鵜呑みにしたりするだろう。
また、実力があれば評価される、と思い込んでいるだろう。
なぜなら、中学校は至って実力主義だからだ。
ところが、日本は実力社会じゃないから実力があっても登って
いけないことを大人達は知っている。 中学生は、自分の親父が社会で実力をまともに評価されているか、問うてみろ。
もしかして、自分の世代は、社会が進化したので、実力が評価される様になった、と思っているのか？ >>438
>ところが、社会的なことは無理。区別する必要がある。
中学生が拙い発言をしたら発言内容を批判すれば良いだけ
技術的なことも社会的なことも関係ない
中学生だからという身分を根拠にするのはナンセンス
>>439,440
そんな悪習を認識していながら肯定する者が害悪だよ
社会を良くするように皆が不断の努力をすべし >>423
「勝負」と考えている時点で間違っている。
議論は言葉通り「議題に対して論ずる」こと。議題に関する知見を深めたり合意を形成したりするために行うのであり、優劣を競うためでは無い。
議論に勝ち負けは無く、共同作業による成果物があるだけ。
議論は参加者全員が勝者になるものであり、敗者が居るなら参加者全員が敗者。
ディベートごっこなら学校でやったら？
議論と討論の違いを理解できていないお子様が増えたよなぁ。 >>443
議論でも討論でもどちらでも良いよ
権威を持ち込む害悪はどちらでも共通だから
>>421
>ネットで議論が上手く行かない理由はいくつかある:
>・利害関係にある当事者が出てきてしまい、第三者による議論が深まらない。
>・驚いた顔や困った顔、反論できない顔、憤った顔、自信がある顔、
> 自信が無い顔などが見えないから、どっちが優勢か判断しにくい。
> 本当は困り果てた末、考えまくって反論してきているだけなのに、
> まともな反論の様に見えてしまうことがある。
>・年齢も分からない。結果、基礎的な勉強も終わって無い中学生が議論に参加していることがある。
>・匿名な故に本当に優秀な人や専門性が有る人がどちらか分からない。
>・優秀すぎると一週回って、馬鹿なように見えることがあるが、匿名
> な故に経歴が分からないからそれを見極められない。
上記の話の発端を読むと>>443の討論の話をしたかったのかもね?
いずれにしても内容ではなく発言者が何者かで
左右されるほど不毛な議論・討論はないだろう 全部翻訳しようと思ったけど途中で飽きた（後半は内容が薄すぎる）
ネットで議論が上手く行かない理由はいくつかある:
→ ネットで自分が優位に議論を進められない理由はいくつかある:
・利害関係にある当事者が出てきてしまい、第三者による議論が深まらない。
→ 専門的な知識をもつ人が出てきてしまい、知識のない第三者を思い通りに誘導することができない。
・驚いた顔や困った顔、反論できない顔、憤った顔、自信がある顔、
自信が無い顔などが見えないから、どっちが優勢か判断しにくい。
本当は困り果てた末、考えまくって反論してきているだけなのに、
まともな反論の様に見えてしまうことがある。
→ 自信満々にでたらめな論理を展開することで相手を困惑させて自分を優位に見せる戦略が使えない。
またネット掲示板だと考える時間があるため、でたらめな論理はまともに反論されてしまう。
・年齢も分からない。結果、基礎的な勉強も終わって無い中学生が議論に参加していることがある。
→ 年齢が分からないため、相手を経験不足や不勉強扱いして反論を無効化する戦略が使えない。 >>445
中高生くらいまでの学校教育では、公平に扱うようにして
ある。だんだん、賄賂や個人的趣向によって差別が発生
するようになる。 板の主旨もわからない、スレの主旨もわからない、言葉の使い方もわからない
そんな人がこのスレで何やってるの？恥さらし？ >>421
↑これ書いてる人とRustを推してる人ってもしかして同じ人なの？ あとで読むようにするけど、とにかく「おもろいこと書いた奴が優勝」な
こっちも生い先短いんだ >>449
この人は社会人あるいは社会人だったことがないんだと思う >>452
>>421を見ると大事なことを学ばなかったと言わざるを得ない >>453
「議題」に触れていない時点で「議論」を語る資格無いわな。
議論は議題を中心とした共同作業なのに、参加者同士の優劣とか勝ち負けみたいなどうでもいいマウンティングしか考えていない。
儒教の暗黒面に汚染された人間はこんなふうになるのかね。 Rustって整数の乗算と加算にどれくらい速度差があるの？ どのプログラミング言語でも(多倍長や10進数を除く)普通の整数は各CPUなどの整数とその演算に変換されて実行されるのよ
整数は加算も乗算もレジスタ上なら1サイクルで同じ
ただし演算とは別にレジスタ上になければメモリ読み出しがキャッシュに乗ってるかどうかで数サイクル～数百サイクルかかっちゃう
ちなみに割り算はレジスタ上で最大数十サイクルかかるから要注意ね C/C++ のプロジェクトでメンバー集まってコードレビューが必要←判る
Rust のプロジェクトでメンバー集まってのコードレビューは不要←イミフ >>422
その通り
>>423
>相手が中学生か大学の教授かで左右される議論など不毛の極み
まあ匿名で顔見えなくても文章観れば大体想像付く C++やRustのようにムーブできる言語はよいとして
ムーブできない言語はクソ 複オジは全く反省してないのな
人としてどうかと思うぞ こんなスレでTikTokのステマとか意味ないだろｗ
板の上位だけど少人数で盛り上がってるだけで多分ひねくれたやつしか見てないぞ 『統合失調症』の東海版全体検索
https://bakusai.com/sch_all/acode=5/word=%E7%B5%B1%E5%90%88%E5%A4%B1%E8%AA%BF%E7%97%87/
※タイトルにテクノロジー関係のものを見られると論文内容記載在り
ボイス・トォ・スカルひな型作成方法
【電磁波兵器の特許情報】Google検索!
【無敵の人】Google検索
神の声兵器被害者!
統合失調症などやエレトロニック・ハラスメント被害者先輩からまだ気ずいていない後輩へ
ボイス・トォ・スカル一式作成して使用できないものは
一族郎党もてあそばれる人生になる!
神の声兵器の口癖はお前が○○だから絶対殺すに変化する!
国崩しの神の声兵器!
細胞に「タトゥー」を入れる技術が発明
生きた細胞にセンサーや電子機器を取り付けるための第一歩となる」と、研究をリードした化学・生体分子教授のデビッド・グラシアス氏は語る。
※誰も神の声兵器からは逃れられないな! 言語の比較でRustに言及しただけで布教とかアンチRust脳の方が心配になるな
どんな認知バイアスだよ 今までずーっとすごくRustをプッシュしてるキチガイが居たせいじゃね？ pythonみたいなバブルは起きなかったな
やっぱコンパイラは一般には敷居が高過ぎる pythonみたいにキラーコンテンツが出てくればね Python引き合いに出すならもう少し長いスパンで見ないといけない
今調べたらPython3のリリースが15年前でびびったｗ microsoftがrust似の言語を研究してるらしい話はどうなったんだろ？ もっとスタックフレーム指向の言語が出て来てほしいわ。
スタック変数への参照を特別扱いするだけでずいぶん違うと思うけどな。 スタックから抜けるときのデストラクタで解放される
ヒープメモリの参照はどういう扱いになるの Pythonだって3.5くらいまでマイナー言語だったろ 当時はrubyとpythonが張り合ってたイメージがあるな
国内限定だったのかもしれないけど
aiが出てきて機械学習のための優秀なライブラリが出てきた辺から抜け出た感じがする いやそれ以前にlinux標準のコマンドとしてpytthon2が入ってた
AIはその後 Python2はstrがバイト列でunicodeと別だったから日本だとマイナーだったと思う
Rubyは知らないけどRuby on Railsで流行ってた
Python3で互換性切り捨てたときはPython終了とか言われてたけど結果的に成功だったな
個人的にはアノテーション足されてから気軽さが消えて逆に使いにくくなってしまった
大規模な開発で必要なのは分かるんだけど
小さいコードでもアノテーション付けないと罪悪感を感じてしまうｗ 国産スクリプト言語ということでRubyが
各種媒体で押されてたのがPython2の頃に日本で
マイナーだった理由だと思う >個人的にはアノテーション足されてから気軽さが消えて逆に使いにくくなってしまった
＋1 >>491
本屋の勢力版図がubyからpythonにみごとに置き換わった感
Rustは始まってすらいない RUSTの利点が分かる人ってアセンブラ、C、C++、Java(とかの参照カウンタ方式GC言語)を一通りやってきた人じゃないとわからないから難しいと思うわ そんなスクリプト言語たちと比較してどうするのよ
まずはインフラから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」などがある。 CDNを基幹でないと考えた理由は「webだから」ってことかな
まあ考え方は人それぞれだろうけど rustでもgcはやる
rustにgcはないというのは誰かがrustの優位性を宣伝するためのセリフで考えたものなんだろけどそれが間違って広まってる GCのある言語とはGCを前提として設計されGCランタイムを必ず伴う言語を指す
C/C++/RustはGCのない言語
高速で省メモリの優位性がある 少し前まで、crate=ライブラリだと思っていて、
crateは何万個(?)も有るらしいから、Rustのライブラリは物凄く
充実しているんだな、なんて思っていたが、大きな
勘違いだった。C++でも、主要なライブラリは100個もあるか
どうかで、それでも全言語で最大レベルだと考えられている
ので、おかしいな、とは思っていたが。
Rustのcrateは、部品の様なものでライブラリとはまた別の
概念のようだ。 どの言語でもライブラリは部品のこと
ライブラリに依存関係があるように小さな部品も大きな部品も巨大な部品もある
さらに言語によって状況は様々で標準ライブラリの意味と範囲もピンキリ C++のライブラリは、多くの場合、数百以上の関数が
集まって形成されていて、1つですべての機能が
まかなえるのに対し、Rustのcrateは、関数が一個
の場合も有り得て、複数のcrateを合わせてやっと1つの
ライブラリとしての役割を果たすようになる。 >>505
視野が狭いな
色んなライブラリがある
言語によっても様々 Rustは詐欺ってことが言いたかった。
視野が狭いといい放つのも、相手を馬鹿にして自分の欠点を
認めない詭弁。 >>507
>crate=ライブラリだと思っていて、
単にこの認識が違うだけでは?
俺はRustは使わんのだがこれのどこが欠点なのかな? Rustが輝くのはC, C++の置き換えだからカーネルとかの低レイヤーには向いてるが
Webなどのバックエンドには全く向いていない
GCも進化しているわけで、それで問題になるケースなんてなくなるだろう
GoもGCが進化しているからよくRustワナビーが貼るDiscordの記事も今では問題にならないことはGo作者が公言済み
ただLinuxカーネルとかUNIXやコンパイラといった低レイヤはC++ではなく言語仕様がシンプルで自由度の高いCを好む傾向にある
gitもC++ではなくCを採用した理由としてLinusがC++を嫌いなのはあまりにも有名
こういった層にとってはRustはC++のように言語仕様が複雑であり、Cのような自由度はなくむしろある書き方を強制するといったものだから流行ることはまずないと思われる
zigのようにBetter Cなシンプルな言語の方が好まれるはず。（zigは例に出しただけ)
低レイヤ開発者にとってメモリ安全ってのはそこまで受けがいいものではないんだよね
開発者としてバグを作らない自信があるから LinuxなどのOSSな低レイヤソフトには流行ることはないだろうけど
Googleなどといった大企業が率先してRustを採用することで流行ることはあるかもね
メモリ安全ってのはバグを未然に防ぐという観点で経営者側からしたら魅力的だから いずれにしてもC、C++の置き換えって観点でしか流行ることはないと思うよ
Webの用途では全く向いていないので、間違ってもイキって採用しないように webこそRustだよ
やってみれば分かるんだよなぁ >>499
インターネットトラフィックの大半がWebとなり
WebベースであるクラウドもWebトラフィックの大半を支えるCDNも
現代のインフラで間違いない
>>511
WebインフラのクラウドもCDNも>>496の記事で示されているようにRust製だ RustがIT土方専用言語になることはないかな
C++がその位置にはいないから Javaだって当初の目的は違ったし
言語仕様を一見web向きには
見えないけどwebに使われてるから
言語の設計から語ってもどうなるかはわからんよ JAVAおじ達が今まで考えもしてなかったメモリリークについて考えて
コーディングするなんて思えない
向いてない Javaみたいな古い言語を今さら使うのは惰性で使ってる連中しかいない
Java使うくらいならKotlinを使う
いずれにせよ仮想マシンしかメリットがなく遅い
そして仮想マシンのポータブルコードとしては普及がWasmにとって代わられてしまった
それならRustで書いて必要ならWasmへコンパイルで十分だろ javaを選ぶメリットは開発がほぼ決まりきってると言うこと
ずっと同じようなフレームワークと開発手法でずっとやって来た
Rustを学んでそのあとに何らかのフレームワークや開発手法やデバッグとか学習するなんて無駄すぎる >>519
自分でバカなことを言ってると自覚できてる？
その主張だとどんなに酷い非効率なダメな環境でも
「ずっと同じ手法でやってきた」
「新たなことを学習するのは無駄すぎる」
プログラミングに限らずあらゆる分野でのダメ人間の典型 まぁ上手く動いているものを変えるなってのはあるな
碌なことはないし完了して振り返ってみても
だいたい徒労という感想に終わる 全然関係ないんだけど最近ルビキチをあんまり見ていない気がする 記法がwebな人と親和性が高いのと、
webはwebでも、webサーバのリプレースはガチ
セキュリティは喫緊の課題だし、どんどん新しくなっていく今の流れに合う
>>520
新たなことを学習してるって公言するのは無駄すぎる
(ほんとは着手してるけど)しないって公言するほうがまだあるある >>514
最近のWebはさらなる効率化のために各CDNのEdgeサービスでWasmコードを動かすのも増えてるよな
もちろんソースコードはRustで記述 >>520
今現在でRust上でjavaの案件をリプレースできるだけのフレームワークがないし
そういう人材もいない
javaではダングリングポインタなどの問題は余程おかしなことをしてないと起こらない
javaの案件をRustに移して得られるメリットは速度が速くなることぐらいでそこまで速度を重視した案件はほぼない
javaで構築されたECサイトをRustで書き換えることに何か意味があるのか？ >>509
>Better Cなシンプルな言語
zig例に出しただけは理解した
Nimはもうオワコン？ >>526
将来Javaラーは減ってRust使える若者が増える
Javaのままでは保守出来ないし維持出来なくなってreplace需要が興る
COBOLと同じ運命 Javaは進化してるのと海外だと技術力あるやつの裾野が広いからCOBOL以上に廃れないと思う
日本の低技術力&土方体質な状況と古いJavaしか知らないと廃れると思っても仕方ない >>529
それはないかな
今現在メモリ解放について意識してないでコード書いて不自由してないのに
何でわざわざ関心の集中先じゃないメモリ解放について考えないといけないのか？
メモリ解放なんてビジネスロジックと無関係なことに時間を割くのは無駄だろう？ java開発の人間がRust導入して得られるメリットは何ですか？ >>526
Rustに置き換えて早くなるのかは微妙 Rustからjavaに変更すると
開発速度と生産性の向上:
Javaはガベージコレクションを使用するため、メモリ管理が簡単であり、一般的にRustよりも開発速度が高い場合があります。
また、Javaの豊富なライブラリやフレームワークを活用することで、アプリケーションの構築やデプロイが迅速に行えます。
エコシステムの豊富さ:
Javaは長い歴史と広範なコミュニティを持っており、豊富なツール、ライブラリ、フレームワークが利用可能です。
これにより、様々なアプリケーションの要件に対応しやすくなります。 RustへリプレースされないからJavaのほうが優れてるという理論はおかしい
Java->Rust
Rust->Java
で比較しないと rustから何かに移行するにしろJavaは無いわ
そのプロジェクトは既に地雷だわ もうrustからの移行を考えているの? 逃げ足はやっ JavaからRustへの移行のデメリット
学習コスト:
生態系の制約:
コードの複雑さ:
生産性の低下:
コミュニティとサポートの違い: >>534
FacebookやInstagramのMeta社が
Javaで書かれていたBuck1をシステム改修して
Rustで書き直したBuck2にした時の話が多数出ている
例えば次の4つの項目が挙げられている。
①Rustのasync/awaitシンタックスは、非同期のコードをとてもスムーズに記述でき、
複雑な並行処理の詳細を正しく理解するのに役立ちました。
②Rustには開発効率を高めて可読性と保守性を高める多くの高レベルな言語機能があります。
それらはenum(代数的データ型)、パターンマッチング、トレイト、手続き型マクロなどで、多くの開発者に愛されています。
③Rustは必要に応じてメモリの割り当てをより細かく制御することもできます。
ガベージコレクションのある言語では、Buckが行うようなインクリメンタルな演算に対応するのは困難です。
④Rustは高性能です。
Rustに移植することで劇的な性能向上を私たちは見てきました。
>>531
Rustは自動的にメモリ解放されるため
必要ないところで意識する必要がないメリットがある
必要なところでは細かい制御も可能なメリットもある ① ④を見るとたまたま社内にRust freakがいたってだけなんだと分かる >>540
①④の非同期の記述性と高速化に対してそんなに劣等感を感じているの？
現代は多数のCPUコア数と多数の非同期通信を両立させて高速化できることが重要
Rustはその非同期な大量の並行＆並列をシンプルかつ最も速く可能にできるプログラミング言語
他の言語だと何らかの欠陥がある 一般的企業から見れば意味のないような性能差でもMetaのレベルになれば全く事情が変わるからな
あのクラスに展開するようなソフトウェアを作ってるならJava->Rustは意味がある
Javaにasync/awaitがないのはJava特有の欠点
Rustのasync/awaitも他言語に比べると明らかに複雑で今のところはRustの欠点の一つ
超大規模に展開するようになって初めて大きくなその欠点を補うメリットが出てくる そこらの一般企業などで使われる社内システムやサービスでjavaからrustに書き換えるメリットはなんなんですか？ Javaだからrustだからとか関係無く、リプレイス自体が多大なコストとリスクを伴うから、現時点で致命的な問題も無いのにちょっと有利なのでrustに置き換えましょう、なんて全く現実的じゃない。
20年くらい経てば大きく変わってるかもね、みたいな話であって、短期間で大部分が置き換わるとか無理。
それもただの可能性なだけで普及するかなんて誰にもわからない。
半年前生成aiと連呼してた詐欺的な連中ももう虫の息なわけで。 >>543
Rustのasync/awaitが最も高速で安全
それを満たした上で記述性も優れている
重要なポイントは二つ
・大量の非同期タスクをCPUコア数に対してm:nに移動割り当て可でスケジューリングできるかどうか？
・安全かつ高速にメモリ共有および高速にチャネル通信ができるかどうか？
高速性と安全性と保守性を考えると
Rustしか選択肢がない
>>544
どの企業でもどの言語からでも同じ
Rustを採用すれば必ずメリットがある
>>545
正しい
したがって新規の案件や大規模改修からRustを採用するのがベスト >>545
>半年前生成aiと連呼してた詐欺的な連中ももう虫の息なわけで。
これなに? >>546
「どの企業でもどの言語からでも同じ Rust を採用すれば必ずメリットがある」とは限らず、
コスト、適切さ、既存エコシステム、スキルセット、リスクなどを考慮する必要があります。 >>546
>Rustしか選択肢がない
C++のコルーチンで良いのでは?
C++の方がプログラマを確保できるよ 実務経験のない複オジがメリットあるある言っても誰も耳を貸さない
著しい情弱を除いて >>548
もちろん生成ai自体詐欺的とは言わんけど、「プログラマー不要ですね」とか真面目な顔して言ってた人たちのことね。
その時点でもプログラマーを置き換えるような品質ではなかったし、その後劣化疑惑出るんじゃ話にならないですよね？
rustがそれくらい普及すると言い張ってる人も同じレベルですよね？
これからは○○の時代、と言って本当にそれだけ普及した言語ありますか？
何やかんやで結局Javaでしょ？ (C++の)コルーチンはいいぞ! (どさくさ
でも、実際にやってみると、おもいっきりダングリング ポインタのピットフォールなので、
そこに所有権関係の縛りが来れば さいつよだな! 今、行列演算ライブラリ作ってるんだけど、1000×1000の行列のdot演算が0.15秒程かかる。OSはlinuxのUbuntuディストリビューション、CPUはIntel Core i7でクロック数は2.80GHz。手元でnumpyに同様の計算をさせる平均0.04秒だった。まだsimd最適化とかはしてないけどsimdはどれくらい効果があんの？ >>552
Javaは10年掛ったけどRustは5年で追い越すんじゃね >>550
コルーチンはC++20が普及しておらず使える人もほとんどいないという問題がまずあるが
様々なasync/await対応言語の中でC++の可読性が最も低く最悪だ
それらの問題に目をつむるとしてもC++のこの機能はまだ様々問題を抱えている
まず非同期なタスクを扱う様々なユーティリティを含む環境が整っていない
そして一番重要なまともなスケジユーラがない
メモリ共有のためのMutexの非同期対応版もない
そういう状況に加えてメモリ安全性の問題も抱えてしまう
この分野は素直にRustを使うのが良いと思う >>552
>rustがそれくらい普及すると言い張ってる人も同じレベルですよね？
AIの進化を舐め過ぎ
自然言語による指示がプログラマーを丸々置き換えることはありえないが
AIはプログラマのかなりの仕事を肩代わりするだろう
rustに比べると遥かに将来性が確約されているよ >>558
別にaiの進化を否定しないが、強いaiじゃなきゃ結局人間を完全に置き換えられないことは今回証明されたし、強いai実現の目処は現時点で立ってないのでは？
根拠無しで将来性将来性言うてもしょうもないし、そういう詐欺的な言説を否定してるわけ。
もちろん現時点でも十分使える技術領域があることは否定しない。 >>561
>強いaiじゃなきゃ結局人間を完全に置き換えられないことは今回証明されたし
何それ? 「強いAI」? 「証明」?
煽りでなく端折らんで説明してくれい >>563
いや、流石に自分で検索してください。
別にオレオレ用語じゃないから。 ChatGPT活用派は、AI絵師が
「老害は困る」
「いまだに自分の手で書いている奴はアホ」
と言っているのと似ている:
https://www.youtube.com/watch?v=-WwwBlEguSU&ab_channel=ずんだもんの地獄巡り >>552
>これからは○○の時代、と言って本当にそれだけ普及した言語ありますか？
Java >>564
「今回」は書かにゃどの回か分からんよw >>565
最近衝撃受けたのはCode interpreter
1年も立たずにこんなものが出てくる
これはまだまだとんでもない発展をする AI生成は、何度も試してまともなものだけを人間が選んでいるのが
現状らしい。
「体や細部が破綻したものや落書きみたいなものまで
多種多様なため」
「AI絵師はイラストガチャを回して質が高い画像だけを
公開しているのです」
とのこと。だとすれば、ChatGPTが生成したコードも大多数は
バグだらけで一部だけまともに動くということが推定できる。 >>569
「現状らしい」とか「推定できる」とかじゃなくまず使いなよ
批判があればそれから https://qiita.com/ko1nksm/items/7b17eefdec57640c2bfd
↑
によれば、ChatGPTに関数のコードを渡して、関数の行なっている
内容を問うてみたところ、関数名が replace_all だと細部は
間違ってはいるものの、有る程度正しい解釈が返ってきたが、
同じ関数で関数名だけを repeat_all などとすると、全く
的外れな解釈が返ってきた。
replace で置換、repeat で繰り返し、だと推定して解釈
していただけで、関数の中身までちゃんとフォローして
意味を理解していたわけではないことが露呈した形と
なった。 >>567
そうですねw
chatgptの今回の盛り上がりの件です。 それから、置換文字列が重複している場合の問題を避けるため
に正しく対策したコードに対して、むしろ、逆に
置換している場合に正しく動作しない、などと解釈してきた
かと思うと、逆に ChatGPT自らにコード生成させると、
置換文字列が重複した場合に誤動作するコードを
生成してしまう、というプログラミングや数学に向いて無い
生徒みたいな振る舞いをしてしまうようだ。 >>571
>注意 今日発表されたらしい GPT-4 ではありません
おマイさんはちょっとずれたこと書いてるので
まずは使った方が良いぞ
ちょっと高いけども
社会はこの数年で一気に変わる準備をしてるんだから
勉強と思って契約しなさい JavaからAIから話題作りに事欠かないなrust 経営に詳しい人によれば、chatgptはマネタイズに失敗し、
倒産する公算が高いと言われ始めた。
だから、必至なのかな。 >>576
ああ! この人いつもの人かw
ちょっと高いかもしれんが20ドルの価値はあるよ
俺の場合は実用ではなく勉強のために
GPT4リリース日から契約したよ
半年ほどたったがその間に
pluginが出てきてCode Interpreterが登場して
発展速度に驚いている
新しいものに適応するのが苦手かもしれんが
これは社会に組み込まれていくものだから
他人に先じて取り込んだ方が良い >>576
どうかな? MSが出資していて
Officeに取り込まれるのに? ChatGPTは、利用者が17億人まで行ったが15億人に減った
そうだ。無料サービスは利用者が増えていかないと破綻する
らしく、減った時点で破綻まっしぐららしい。
しかも、AIは作る人や質問したい人向けのもので、
YouTubeのように子供がだらだら見続けることもないから
広告量で稼ぐこともできない。
DeepL翻訳の様な実用性も無いから有料での使用は絶望的。
ChatGPTは、株で生きているだけで、マネタイズには成功
してないし、これからも成功しないだろう。
twitterがずっと赤字なのと同じ。 RustよりchatGPTを使ってる人の方が遥かに多いと思う
ていうか、Rustって誰も使ってないよね https://thebridge.jp/2023/07/chatgpt-sees-10-percent-mom-decline
ChatGPTは、利用者が五ヶ月連続で減少。
一番の原因は、「思ったほど賢くない」こと。
開店時にどの店も行列を作るが、数週間後に閑古鳥となり、破綻する
店は多い。
それにシリコンバレー銀行の破綻などもあれば、アメリカの景気大後退
もある。
総合的に、来年までに倒産するという観測も出てきている。 >>576のような書き込みも
自分が適応できないことで生じている
認知的不協和を解消するために書いてるんだと
俺は見てるよ >>585
本当に興味がないのなら何も書かないんだよ
あえて「倒産する」などと書くのは興味があるんだよ
やらない自分を正当化するために書いているんだよ >>586
[裏付け]
https://www.windowscentral.com/software-apps/chatgpts-fate-hangs-in-the-balance-as-openai-reportedly-edges-closer-to-bankruptcy#:~:text=ChatGPT%20is%20reportedly%20heading%20toward%20bankruptcy.,million%20loss%20since%20debuting%20ChatGPT%2E
ChatGPT's fate hangs in the balance as OpenAI reportedly edges closer to bankruptcy.
ChatGPTの命運を左右するOpenAIの倒産報道 >>587
興味は無いが、社会を破壊してしまう心配はしている。
だから、ウォッチはしている。 >>588
[続き]
* OpenAIが破産に近づいていると報じられているため、ChatGPTの運命は瀬戸際にある
知っておくべきこと
・ChatGPTは破産に向かっていると伝えられている。
・チップ不足や利害の分割などにより、このベンチャー企業はほとんど利益を上げておらず、投資家はほとんど損益分岐点に達している。
・OpenAI は、ChatGPT のデビュー以来、すでに 5 億 4,000 万ドルの損失を計上しています。
「同社は倒産の危機に瀕していると報じられている。」
*分析
まず、AIを搭載したチャットボットを運用することは、特にコスト面において簡単なことではない。私たちはすでに、OpenAIが毎日ツールを動かすのに約70万ドルを使用していることを知っている。これはクエリ1件あたり36セントに相当する。シームレスに動作させるためにエヌビディアのような企業からGPUを調達するために使われる金額は言うまでもない。しかし、GPT-3.5とGPT-4を収益化することで、少しでも収益を上げようと努力しているにもかかわらず、OpenAIはこの状態を長く続けることができないかもしれない。マイクロソフトは、最近の投資家数人を伴って、これらの費用に対応している。投資家たちは、投資を回収できない場合、いつまで事業を維持する手助けをするのだろうか？ >>588
それ読んだ? 噂話で裏付けになっていない MSが支えるから大丈夫だよw
GPT-4搭載の「Microsoft 365 Copilot」、文章生成よりも重要なAIの能力とは
https://xtech.nikkei.com/atcl/nxt/column/18/00001/07952/
OpenAIは上場企業じゃないけども今や市場の資金はAI企業に集まっている https://www.youtube.com/watch?v=-WwwBlEguSU&list=LL&index=3&ab_channel=ずんだもんの地獄巡り
【神絵師から爆速でオワコン】AI絵師様になったずんだもんの末路【ずんだもん＆ゆっくり解説 】
AI画像生成は、破綻画像や低品質画像を出す率が高いため、何度もトライアンドエラー
を繰り返す必要がある。
また、SNSなどで話題となっているAI画像も、人間がプロ級に画力が有る人で、
手作業で修正していることが有る。
プロは、少しの修正は簡単に出来るから出来ているだけで、AIだけで生成
されていとは限らない。 >>593
自ら触ってから評価すべし
俺はAI画像生成は触らんので何も言わない 再生数稼ぎのyoutuberの話をうのみにしてるだけで馬鹿げてる
chatGPTのOpenAIは株式非上場ですでに企業価値が4兆円なんだけど… >>596
あなたのレスの中に科学的根拠何かある？
ai自体スレチだが、経済の話しかないならさらにスレチだね。 >>557
その点がC++が敗れてRustの台頭を招いた技術的な最大の原因っぽいな
C10K対策とasync/await対応を兼ねたモダンな需要にC++が実用的な解を示せなかった >>598
マジレス頼むけど
上のレスに科学的に根拠が必要な個所はどこなんだ
か・が・く・て・き・に だ！ >>600
しょうもない話は誰も興味無い。
それは科学の話じゃないよw こいつ前もやってたなコレw
「数学的に」の次は「科学的に」かww 先生、management scienceは科学に入りますか？ >>596
YouTuberと「ChatGPTで一儲けしたい投資家」の
骨肉の戦いが始まりました。
Fight!! OpenAIが存続するかに関わらず
LLMが社会に取り込まれるのは確定だよ
君らの周りも今年は対応に追われてないか？ 言語の質をデータの量で凌駕する作戦がなぜ失敗するのか？
量で凌駕するって言ったのにお金を節約しようとしてるからでしょ 逆にマウンティングを真に受けて、上下関係は社会に必要だと思い込むのも困る >>557
そのあたりはC++23でも標準化をあきらめた
低レベルな部品のみ標準化して提供という方針のままのようだ
C++20コルーチン向けライブラリcppcoroは実用的に十分埋めきれていない
C++20コルーチンにも対応したboost.asioもスケジューリング問題にぶち当たる
いずれにしても記述性と簡素さがよろしくない
IT大手各社がC++をあきらめてRustへ走ったのも仕方ないかと >>612
CPUの性能を活かせない
CPUと比べてネット通信はとても遅く待ち時間となるため空き時間をいかに活用できるかが勝負
つまり次々と切り替えて処理していくことになるが
スレッドは各リソースコストも切り替えコストもかかりプロセスはさらにそれらのコストが非常に大きい
そのためCPUの性能を活かすどころか切り替えコストで無駄にしてリソースコストで限界に達していた
そのため例えばJavaScriptはWebブラウザ内でもNode.jsなどでも同様にシングルスレッドの中で多数の通信やGUIなどを並行して非同期に捌けるようにした
Goでも多数の軽量のGoルーチンがシングルスレッドまたはマルチスレッド上で並行して動いて非同期に多数処理できるようにした
Rustの非同期タスク及びC++20のコルーチンも同じ位置付けで両者はほぼ同じ仕組みのライバル同士 >>613
>スレッドは各リソースコストも切り替えコストもかかりプロセスはさらにそれらのコストが非常に大きい
何のコスト?
「切り替えコスト」って書いてるのはユーザーモードから
カーネルモードへの切り替えコスト? プロセス全体をexitしたら各スレッドのデストラクタはどうなるんだろう
Cの標準ライブラリを捨てる
C++のデストラクタを排除する
ネイティブスレッド禁止
の三択かな >>614
スレッドは文脈からネイティブスレッド(OSスレッド)のことだとすると、
スレッド切り替えは少なくとも全レジスタの退避と復帰が必要となり、
プロセス切り替えはさらにメモリ空間の切り替えが加わる。
そして各スレッドは個別のスタック領域を持つためリソース的に大量のスレッド作成は限界個数が早い。
一方でC++20コルーチンやRustのタスクはスタックレスコルーチンなので、
個別スタック領域を必要とせず全レジスタの退避復帰切り替えも必要としないため、
大量に生成することができて極めて軽量に動作することになる。 並行並列処理に関してはGoにRustは何一つ勝ててないでしょ
Goは標準で並行並列処理をサポート
selectとチャネルとコンテキストがあり、従来のasync/awaitと比べると凝ったことをするのが非常に簡単
キャンセル処理やrate limitingや並列数制御が標準機構で自由自在
標準でサポートしているからどのサードパーティライブラリでも共通の仕組みが利用できる
こういったものが何のライブラリも必要とせず手軽にできるのが最大の強み
Goはコンパイル速度とマルチコアでスケールする並行並列処理のために作られたから
これらの観点でメモリ安全が目的で作られたRustが勝てないのは当然 >>618
goroutineやnode.jsのpromiseといったもので並行と非同期の違いって何？
別に変わらんし、区別する意味はないぞ
非同期ってのは汎用性が高い言葉で完了を待たないって意味なら何にでも使えるわけで
例えばLinuxでファイルを書き込むときはページキャッシュだけに書き込みディスクIOは非同期に行われる
これを並行処理とは言わないはず >>571
中身が replace all する関数で名前が delete all とか違う意味だったらどう解釈するのか教えて ChatGPTって観るだけで詐欺を連想するが
>>580
は説得力あるなω >>617
Goでアドバンテージ持ってる会社が他社を陥れる為にRustいいぞって噂を流したのかもな お客様を陥れるのが本質
本質を隠す為に同業者を陥れるという噂を流している https://play.rust-lang.org/ とかでも
https://paiza.io/ とかでも
使える crates が少な過ぎるんじゃね
これで普及とか無理やろ >>617
GoでできるそれらのことはRustでもできるよ
むしろチャネルの種類などRustの方が機能も豊富だよ
Goはモダンな言語の中で唯一null安全でないしデータ競合も起きまくるし安全性を無視しすぎかな
それはともかくGoは言語機能が貧弱すぎて辛すぎる
ジェネリクスがようやく入ったけどまともに使えないなど不満が多いよね
結局Goはガベージコレクション言語にすぎないから様々な限界があるよ
C/C++/Rustのように他の言語たちのライブラリ作成もできないしね ＞C++20コルーチンやRustのタスクはスタックレスコルーチンなので、
＞個別スタック領域を必要とせず
Goルーチンは個別のスタック領域を必要としてしまうね >>626
“気軽”にできるといってるわけだが本当に気軽にできるの？
標準ライブラリでサポートしているの？
データ競合に関してはチャネルを使えばある程度は回避できるしrace detectorもあるのでさほど問題にはならない
race conditionに関してはRustでもGoでも検出はできないから結局プログラマの技量になるわけだけど
Rustにしたからといってあらゆる並行並列処理のバグが回避できるものじゃないぞ
そもそも難しいものなんだから Goはこんな基本操作でも恐ろしい挙動で驚いた
14 デフォルトの名無しさん 2023/07/28(金) 03:06
その話ならばGoという最悪の言語があって直感と常識を裏切る挙動をしてくる
しかも理解できたと思ったら二転三転と次々と裏切りの挙動をしてくる
// まず [1 2 3] をaに作ってbに代入するところからスタート
a := []int{1, 2, 3}
b := a
// 実験1: 途中要素の書き換え
a[1] = 222
fmt.Println("a =", a) // → [1 222 3]
fmt.Println("b =", b) // → [1 222 3]
// aもbも書き換わってしまった！同じものを指しているのだろうか？
// 実験2: 末尾要素の削除
a = a[:len(a)-1]
fmt.Println("a =", a) // → [1 222]
fmt.Println("b =", b) // → [1 222 3]
// aだけ削除された！aとbは別なのだろうか？
// 実験3: 要素の追加 (その1)
a = append(a, 777)
fmt.Println("a =", a) // → [1 222 777]
fmt.Println("b =", b) // → [1 222 777]
// aとbは再び同じになってしまった！なぜだ？？
// 実験4: 要素の追加 (その2)
a = append(a, 999)
fmt.Println("a =", a) // → [1 222 777 999]
fmt.Println("b =", b) // → [1 222 777]
// aだけ追加された！また裏切られた！！ >>629
>race conditionに関してはRustでもGoでも検出はできないから結局プログラマの技量になるわけだけど
そこでChatGPTですよ! >>629
Rustで発生するrace conditionてどういう前提？
普通は発生しないと思うけど >>626
5chなら知ったかできて気持ちいいよねw
良かったね 常識的に考えれば気持ちいい方が合理的だよ
常識を疑えば、自分が損をしてでも何かを成し遂げるみたいな
合理性のない人間が増えてくる >>630
この話広げるのもなんなんだけどこの挙動はどう説明されるの？ >>632
race conditionの意味でググってこいよ
機械で検出できない高レベルの競合のことで、並行並列処理するときは常にこれと向き合う必要がある
Rustで検出できるのはdata raceでこれはGoでもランタイムだが検出できるわ ChatGPTは、捨て垢で使えるようになってから来いよ。。
こう煩いとRust布教されるほうがマシｗ デッドロック検出できるのって画期的なことだと思うよ >>636
data race関係ないrace conditionを言語で検知してほしいケースなんてあるの？ 過ぎたるはなんとかってやつか
しつこ過ぎるとダメって事やな >>640
Rust信者が何でもコンパイル時に検出できるとか絶対安全！だとか吹聴しているから訂正しているだけだよ
データ競合ならGoでもランタイム時に検出できるわ >>640
むしろロックフリーデータ構造は
data raceあり
race conditionなし
の良く出来た高速アルゴリズム 実際にGoで作ってるところは有名どころでも並行処理関連のバグ量産してるからRustとはリスクレベルが全く違うわな >>636
>>642
データ競合が運用時に検出できても手遅れ
しかもデータ競合を検出するために実行オーバーヘッドを伴うため悪い選択肢となる
この件でも静的にコンパイル時点でデータ競合を検出できるRustが大きく有利だろう ハイリスクハイリターンのように、リスクとリターンの差に意味がある
リスクとリスクの比較や、リターンとリターンの比較は合理的ではないと思う >>645
だけど気軽にできないよね
標準の機構で並行並列処理できないよね
async await使うだけでアホみたいに大量の依存をダウンロードしてきてコンパイル爆遅だよね
GoはCとかの手続き型言語を知っていたら、すぐマスターできるけど
Rustで並行並列処理までマスターするのに一体どれだけ時間がかかるんだろうねw >>635
C++のvectorに相当するのがその>>630のGoのスライス
その挙動は明らかに常識外れで理不尽だがGoの仕様通りの挙動
Goはあちこち設計がおかしい
>>644
このためGoで本格的なプログラミングをすべきではない風潮になってきた
もともと貧相な仕様をシンプル簡素と積極的に評価してきたが無理があった >>630
これ挙動わかってるのにわからんないみたいに書いてあるでしょ
配列とスライスのデータ構造はシンプルだからそれを調べれば自明にわかるだろ
他の言語でも
実験2でそんなこと考える奴はいないよね >>630,648
GoのスライスをC++のvector相当、ってのが早とちり過ぎる
Goのslice header, backing memoryの理解をすっ飛ばしただけじゃんw >>630
そんな妙な動きをするプログラミング言語はGoだけだな C++erに無視されてきてつまらなくなってきたので今度はGoをタゲるおじさん >>630
使いやすいかどうかは謎だけどスライスだから当然の挙動かなと
実験1 スライスは配列そのものじゃなく参照と長さなのでそういうもの
実験2 aは新しく作った別のスライスを代入してるので当然
実験3 スライスaの末尾に対してappendしてるので当然
実験4 3と同じ スライスaとbの長さが違っているので当然
結論
スライスすら使えない奴は馬鹿 てかこれを理解できないのであればRustは習得できないんじゃないかね
Rustできるならわかるだろ >>653
嫌なら配列使え、ということかね。
配列とスライスの表記に問題があるとは思うけど。[]と[1]で別物というのはやりすぎだわな。 余談
初期の開発中のC言語にはポインタは int* じゃなくてint[]だった >>630
Goの何がおかしいのかわかった
C++やRustや他の普通の言語ならば
bがaのコピーならばその実験1～4すべてでaとbは異なる
bがaを参照しているならばその実験1～4すべてでaとbは同じになる
その二つのケースどちらかになる
Goは実験を進めるごとにaとbが異なったり再び同じになったり再び異なったりおかしい なぜGoだけがそんな変な仕様にしちゃったの？
新旧の言語を見回してもそんな変な仕様の言語は存在しないよ スライス自体は他も似たり寄ったりだよ
pythonは3で多分新しい配列を作る
多分appendの時に新しい配列をコピーしてそっちに代入するはず
元の実態を明確にコピーすると言わずにコピーするかどうかと言う設計理念の違いだろう
pythonは初心者向けだからそうしたgoはしなかった 配列の箱が並んだ絵でも書いてスライスは別のところに書いてポインタの矢印と長さでも書いてみれば理解しやすい >>659
GoはC言語に近い言語だから
Cでmallocとかreallocとかを使って配列を扱ってたらよく理解できるはず
無駄なコピーを避けつつ、細かいメモリ操作も行えるようにして最適化の余地を残しているのがGoの特徴なので >>659
スライスはrangeみたいなもので、スライスそのものはそんなに変なものではない。
問題はそこではなくて、
・スライスに「可変長なだけの配列」に見えるような表記を割り当てた
・真に「可変長なだけの配列」(vectorみたいなの)が存在しない
なので、スライスと配列を混同して使わざるを得ない言語設計が問題。
素直にCOWスライスを用意すればまだ良かったんだけどね。 Goのスライスは現実社会の物を表しているとも言える
1,2,3と書かれた箱が並べてあって、あるスライス（窓）が1,2を指しているとする
そのスライスに4の箱を追加されたとしたらどのようになるのが望ましいか
Goは現実世界のように1,2,4,3と箱が並ぶ
Pyothonはどこかから急に箱が表れて
1,2,4と言う並びの箱の列と1,2,3と言う並びの箱の列ができる なるほど、スライスと言われてなんとなくわからんでもない挙動には見えてきた
でもやっぱりバグを呼び込むためだけの仕様にも思える
こんな仕様にして誰か幸せになるんかな >>665
スピードマニア、つまりgo ユーザー。 C++もRustもわかりやすい仕様だけどGoよりスピード出る Goは言語設計をミスってるな
>>630
// 実験3: 要素の追加 (その1)
a = append(a, 777)
この部分は他の言語だとメソッド名こそ異なれど
a.add(777)
a.append(777)
a.push(777)
a.push_back(777)
となる
メソッド名は自由だがこの形式が正しい
Goの失敗の原点はここだ
a = append(a, 777) 言語とライブラリを分離できないと潰しがきかない
C++の場合mallocやsjljを単なるライブラリではなく言語の一部にしたのが悪手 >>668
go はオブジェクト指向じゃないからなぁ。
純関数にしやすいように、仮引数自体は変更しない設計にしたんじゃない？Rustも似たような思想だろ。 手軽というのは実際はただの手抜きなんだよ
その尻拭いをさせられてきた良識ある若者が次の世代のためにRustのようなものを産み出す
それを無自覚な老害が腐す >>629
標準ライブラリの範囲は言語ごとに異なる
Rustの方針は言語サポートが必要な機能を標準ライブラリとする傾向が強いため他より範囲が狭い
例えばRustの標準ライブラリに正規表現や乱数などは含まれていない
だからといってRustはそれらが扱えない、というのは正しくないように
標準ライブラリに入っているか否かはさほど重要なことではない
今回の例で言えばC++20のコルーチンもRustのasyncコルーチン(タスク)も意図的にそれ自体の機能のみを言語機能および標準ライブラリに入れている
コルーチンのスケジューリング機能など含めてほとんどの機能は標準ライブラリにない
それらは言語自体が直後サポートしなくても実装可能だからであろう
Rustの場合はデファクトスタンダードの地位を確立したtokioがあるため困ることはない >>647
気軽にの意味が多様だがRustでもGoルーチンのように気軽にタスクをspawnできる
もちろんチャネルも使えてGoスタイルのプログラミングをしたければそれも簡単にできる >>654
RustでVecだと最初のb = aの時点でムーブとなるためその問題は起きない
ムーブではなくb = &aとして参照にしても競合防止のため書き換えできず問題は起きない
Goでaとbが異なったり同じになったりを二転三転してるのはaとbが競合してると考えてもいいのかもしれない >>670
Rustはオブジェクト指向であってクラス継承の概念のみを排除している
だからそこではRustでもa.push(a)の形となりVec型の値(オブジェクト)が書き換わる
他の例でもイテレータはnext()する毎に値(オブジェクト)が書き換わる getterだけを公開すればオブジェクト指向だが
いつどこからsetされるか分からないコードはstatic変数に近い性質
それはオブジェクト指向ではない >>676
「いつどこからsetされるか分からないコード」について
Rustは所有権もしくは可変参照を持たないと値を書き換えられないからコード上で明確にわかるよ
static変数については「いつどこからsetされるか分からないコード」によってデータ競合が起きうるのはその通り
しかしRustのstatic変数は(unsafeを除いて)可変(mutable)ではないため「いつどこからsetされるか分からないコード」によってデータ競合を起こすこともないよ
例えばRustのstatic変数をマルチスレッドで共有しつつ値を書き換えたいならばMutexなどによる内部可変性を与える必要がありデータ競合が必ず避けられる こういう意味のない比較を少なくとも2年はずっと書き散らし続けて
何も生み出していないっていうね 技術板のスレなのに無能が適当なこと書き散らすだけで他人が参考にならないスレ
板違いの雑談スレなんだからせめてageるな >>672
標準ライブラリのサポートは重要だろ
ちょっとしたことをやるだけでいちいちライブラリを選定する必要があり、コンパイルが遅くなる
CICDも遅くなるし、ライセンスもいちいちクリアしなくては行けない
同じく標準ライブラリが薄いNode.js使っててnode_modules肥大化問題に悩んでいる奴は多いだろう
例えばhttpリクエストするだけでもプロジェクトによってライブラリが異なる
ライブラリが異なるのでそれぞれの使い方をいちいち覚えないといけない
こういったことは企業で開発する上で不毛なんだよ 企業については、企業がライブラリを指定するんだし…感はある(非プロの感想です 選定ばかりで何も生み出さない消費者を許せないってそこに書いてある
だから選択肢を増やせば増やすほど評価が高い オープンソース環境は、OSや環境に変化があるたびに、
別人が別の修正版を出してきて、少しずつ使い勝手が違う
ので、めんどくさい。
Rustもそうなる予感がするので使わない。 >>685
今、OSSのある開発環境を使い始めたとしよう。
・ドキュメントも不十分なので、上手く行く方法を
試行錯誤して探すのが必須。
・やっと探し出した方法でmakefileやbatファイルなどを
整備して開発できるようになる。
・数年後、試して見ると動作しなくなっている。
・それでまた、ググり調査 + 自分でテストを繰り返し、
数種類の配布物を試してやっとの思いで昔と似た
ことが出来る方法にたどり着く。その間、大部分の
環境は、来たいはずれの「試し損」となる。
・そして、makefileやbatファイルが作り直しとなる。
・ライブラリパス、インクルードパス、#includeなどの
修正も必要となる。xxx.h だったものが、sys/xxx に移って
いたり、昔 typedef されていたものが、なぜか無くなったり
別ファイルで定義し奈緒知れていたりする。
・ここまで、数日間かかり、プログラミングは全く出来ない。
経験法則から導かれたOSSの開発環境の日常の風景。 >>686
>・数年後、試して見ると動作しなくなっている。
あなたのOSSとの付き合い方の問題点は上記に集約される
常に追っていかなくてはおいてきぼりにされる
あなたには向いていないので使わないこと 2022年版年次Rust調査結果、1万超の回答 職場でRustを使う理由
https://atmarkit.itmedia.co.jp/ait/articles/2308/19/news032.html
プロフェッショナルな環境でRustを使用する主な理由としては、「バグのないソフトウェアを作成できる」という認識(86％)、Rustのパフォーマンス特性(84％)、Rustのセキュリティと安全性の保証(69％)が挙げられる。また、回答者の76％が、「Rustが楽しいと感じたから」という理由だけでRustを使い続けている(ここでは回答者が複数の選択肢を選択できるので、数値の合計が100％になるわけではない)。
仕事でRustを使用した回答者のうち、72％が「チームの目標達成に役立った」と報告し(前年比4ポイント増加)、75％は今後もチームでRustを使用し続ける計画を持っている。
一方で、職場で適用されている他の言語と同様、Rustの学習曲線は重要な考慮事項だ。専門的な立場でRustを使用している回答者の39％は、そのプロセスが「挑戦的だ」と報告している。
回答者の9％は、職場でRustを採用することで「チームの速度が低下した」と回答した。 >>681
Rustはデファクトスタンダードがあるからそのように困ったことないな
httpならhttpという名のクレートに基本事項が定められていて全てのhttp実装やその上の各フレームワーク等がこれを使う
httpクレート自体はhttp実装を持たずにhttpのリクエスト型やレスポンス型にURI型やヘッダ型やステータス型などだけを持つところが重要なポイント
もし新たな速いhttp実装が現れたとしてもインターフェイスはこのhttpクレートに(少なくとも今までは全て)従うため利用者が困ることはない >>688
うん。だから、OSSは大嫌いだし、出来る限り使わない。
Linuxを含めて色々試したが、ごく一部のものを除いては
結局駄目だった。 >>691
ちなみに、俺は、自分で何から何まで作るのが好きなので、
人が作った環境に追いまくられるのが大嫌い。 >>691
適応能力に長けてないと扱うのは難しい
変化の速さがOSSの競争力の源泉の一つと感じられなければ
苦痛だろうね
オープンソースでもboostとかはほとんど変わらんやろ? 使わないの?
規格にすらあなたは新しいものにクレームつけそうだがw debとかrpmとかバイナリパッケージを否定したら挫折するね
Windowsに依存しないだけならそこまで無理ゲーではないけど
WindowsもLinuxもどっちも認めないいわゆる「中立」が過激化するとうまくいかない >>692
むしろ逆で、今までみたことがないくらい仕事が
物凄く速いと言われていたぞ。
研修時の記録も塗り替えた伝説も持っている。 >>696
アンカーミスした。
正しいアンカーは >>694。 OSSかどうかとは関係なく現状のRustはライブラリ探しと精査に超時間がかかるのは確か
アプリケーションプログラマーから見るとこれがRustの最大の欠点 >>696
仕事が速い人がOSSに適応できないわけないじゃんw
>>686に「・ここまで、数日間かかり、プログラミングは全く出来ない。」
と自分でも書いてるし
boostは使わないのかい? >>698
そもそもRustは低レイヤ向けでライブラリを特に必要としない用途に向いてるってことだよ
Webやクラウドなどの通常のバックエンドアプリはライブラリを多用することになるがそれは向いていないってことの証 ほんとに(webの上位層で)人気が出てくれば、ライブラリは勝手に揃ってくるだろうけどね >>700
ところが低レイヤもたくさんライブラリ使うんだよ RHELやHashiCorpの動きはAmazonがターゲット？ >>704-705
Mojo🔥がAmazonかGoogleに買収されてクラウドオンリーになる可能性 Firefoxはバクサイ開いたままにしてるとメモリー20GB、CPU100%になったりする
Chromeはそんなことにならない
そういう違いがある インターネットはおかしいと最初から思ってた
でもソースコードを保存する場所はネットでもディスクでも紙でもなんでもいい write_allの後はflushした方いいんじゃね？
しらんけど
まあPythonの方がアマチュア向けというか面倒見がいいのは分かる crates.ioに限った話ではないけど
ライブラリ名と実装品質のミスマッチはいつも気になってる
HTTP/2用のライブラリでもhttp2よりh2の方が利用者数多いとか
オープンなレジストリの宿命として諦めるしかないのかな >>644
5chでデマ垂れ流して気持ち良くなるだけのゴミ人生でしたw 損得の勝負をしてると、デマで得をする奴がいないか常に不安だよな
それなら単純に本当か嘘かで勝負すればデマと勝利は両立しないから安心安全なのでは >>712
HTTPを知らないなら素直にライブラリを使えよ
そのRustコード汚すぎるがそこに正しくHTTPヘッダを一行加えたら動いたぞ
サイン曲線GIFが表示されている 練習に書いてみた
fn base64_encode(input: impl AsRef<[u8]>) -> String {
const TABLE: [u8; 64] = *b"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
const MASK: usize = 64 - 1;
let mut input = input.as_ref();
let mut output = Vec::new();
while let [i0, i1, i2, rest @ ..] = input {
let x = u32::from_be_bytes([0, *i0, *i1, *i2]) as usize;
(0..=3).rev().for_each(|shift| output.push(TABLE[x >> shift * 6 & MASK]));
input = rest;
}
match input {
[i0, i1] => {
let x = u32::from_be_bytes([0, *i0, *i1, 0]) as usize;
(1..=3).rev().for_each(|shift| output.push(TABLE[x >> shift * 6 & MASK]));
output.push(b'=');
}
[i0] => {
let x = u32::from_be_bytes([0, *i0, 0, 0]) as usize;
(2..=3).rev().for_each(|shift| output.push(TABLE[x >> shift * 6 & MASK]));
output.push(b'=');
output.push(b'=');
}
_ => {}
}
String::from_utf8(output).unwrap()
} >>699
俺はOSSを使わない仕事をしているから。 >>698
>OSSかどうかとは関係なく現状のRustはライブラリ探しと精査に超時間がかかるのは確か
いや、それはOSSだとほぼ必ず起きる現象。
OSS自体が持つ欠点の一つだから。 クローズドなソフトだと、古いものも維持されるかどうかは、
それぞれの企業次第で各企業の特徴が出る。
ところがOSSの場合、人類全体の傾向となるから、
どのOSSなソフトでも似たような保守の傾向となり、
制御できない。なぜなら、人類全体の傾向はいつも
ほぼ同じだから。
電力送電における「無限大母線」という言葉を思い出した。 >724
なんか全体集合と部分集合を理解出来ていない様な日本語ですね 人類の傾向はいつも、n=1を笑い、前例が1つもない事件事故に泣く >>727
実際rustに限らずOSSなら必ず当てはまることなので部分と言っても意味はない。 >>730
「ライブラリ探し」は検索すれば良いだけ
「精査」はOSSはソース手に入るが
プロプラなソフトでは諦めるしかない 時間はお金で買える
ただ具体的にいくらで買えるのか誰も知らないだけ >>731
ライブラリの選定ってソースコードの精査はそれほど比重高くないよ。
それよりもライセンス、開発体制やアクティブさ、直近のリリース状況、人気とかが重視されがち。 >>733
アンカー間違っとった
>>724
「ライブラリ探し」は検索すれば良いだけ
「精査」はOSSはソース手に入るが
プロプラなソフトでは諦めるしかない >>712を見て思ったが
RustにもPythonのrequests/base64のようなライブラリあるんだろ >>736
Pythonのrequestsも標準じゃないだろ
Rustは標準のみを使い,Pythonでは外部ライブラリも使ってだからな RustってSimd命令は非安定だよね？実際にSimd命令使うとどれくらい高速化できんの？
Simd命令ってCPUに応じて場合分けしてコードを書かないとならんの？ >>738
CPU以外にボトルネックがないならおおよそ並列度の分だけ性能上がる
32bit + 32bitのような計算を1命令で処理してたところを256bit幅がサポートされてるハードウエア&命令を使えば約8倍 >>739
実際には、「お膳立て」のためのオーバーヘッドが有ることと、
SIMD命令が使える部分が少ないことで、8倍のSIMD命令を
使っても、20%位の向上にしかならないと言われている。
数値は大体。
だから、IntelはAVX512をメインストリームからは捨て
ようとした。 スパコンが、ベクトル型が廃れてスカラー型の並列型が
流行していることからしても、SIMDは将来性の無い
ものだと個人的には思ってる。
むしろ、SIMDを捨て、コア数を増やす方が圧倒的に
高速化できる。 スパコンのコーディングは知らんけど
雑にスレッドプールにぶん投げるだけで速くなる並列処理の方が
SIMDより使いやすいなって思う >>720
整理するとこれでいいみたい
use std::error::Error;
use std::net::TcpStream;
use std::io::{BufReader, BufRead, Read, Write};
use std::fmt::Write as _;
fn http_get(host_port: &str, path: &str) -> Result<Vec<u8>, Box<dyn Error>> {
let mut server = TcpStream::connect(host_port)?;
let mut http = String::new();
write!(http, "GET {path} HTTP/1.1\r\n")?;
write!(http, "Host: {host_port}\r\n")?;
write!(http, "Connection: close\r\n")?;
write!(http, "\r\n")?;
server.write_all(http.as_bytes())?;
let mut server = BufReader::new(server);
let mut line = String::new();
server.read_line(&mut line)?;
if line != "HTTP/1.1 200 OK\r\n" {
return Err("HTTP: not 200 OK".into());
}
while server.read_line(&mut line)? > 2 {}
let mut data = Vec::<u8>::new();
server.read_to_end(&mut data)?;
Ok(data)
} >>743
え？Rustって標準ライブラリでhttpリクエストすらできないの？ とりあえず1000×1000の行列の行列積dotが0.015秒弱でできるようなところまで行列ライブラリーが実装できたので、何とか0.00秒台で計算が終わる様にしたい。
今の所手を出してない最適化
1) Simd命令
2) インラインアセンブリ
3)ループアンローリング(これはRustだと自動的にやってくれてる様で自分の実験した範囲ではあまり効果がなかった。)
この中で一番効果的な最適化は何？
ちなみに今の所は以下の最適下は既に実装済み
1) ループ交換
2) キャッシュブロッキング
3) rayonによる並列処理 >>745
Rustの標準ライブラリは言語サポートを必要とするものを中心に極めて絞っている
既出のhttpやbase64だけでなく正規表現や乱数など多くの機能がデファクトスタンダードライブラリ
>>746
標準ライブラリにないだけで各種ライブラリは下位から上位フレームワークまで揃っている
CPUとメモリのリソースコスパ重視でWebやるならRust一択でまちがいない
Webインフラ各トップ企業たちも>>496のようにRustを採用している デファクトスタンダードという選りすぐりに聞こえるが
単にそれしかないだけのような...
ユーザ数少ないので >>747
simdに手を出すとarmのsimdまでやる羽目になる
インラインアセンブリも同じ
つまり今のところおすすめはない
外部のライブラリなどに依存するなら別だけど >>750
じゃあ基本的にはdot演算に関してはこれ以上の最適化の余地はないって感じ？ paiza.io の Rust は crates 使えないから
ホント使いもんにならんわ じゃあGitHubのCodespacesでも使ってれば >>751
おすすめはしないけどやればやったになるはず
デバッグ環境があるかは知らないが >>753
それはpaizaが悪い
例えば>>712で意味のない比較をしているが
Python版はimport requestsと標準ライブラリではないものを使っている
つまりpaizaはPythonだと標準ライブラリ以外のライブラリも使える
同じようにRustでも標準ライブラリ以外を使えるようにpaizaが対応すれば解決 シミュレータなどは行列演算だけ高速化しても、全体の
高速化にはなら無い事が多い。 >>757
手元のnumpyよりは少なくとも1000×1000の行列積は2倍から3倍速、10000×10000の行列積だと約5倍から10倍速い。手元よnumpyのバックエンドはIntelMKL。 まだ、行列の対角化とか逆行列の計算は実装できてない。 なんかnumpyが遅くない？
1000x1000でnumpy.dot(a, b)部分だけ測ったらこんな感じだったけど
0.006215572357177734
0.005822658538818359
0.005129098892211914
0.007399797439575195
0.011432886123657227
0.008414506912231445
0.009572029113769531
0.009091615676879883
0.008922100067138672
0.007265329360961914 def calc(n):
n = n // 2 * 2
a = build_matrix_np(n, 1.0)
b = build_matrix_np(n, 2.0)
start = time.time()
d = matmul(a, b)
end = time.time()
time_diff = end - start
print(time_diff)
return d[n // 2][n // 2] pipで入れたのでopenblasだと思うけど、こんな感じ
OMP_NUM_THREADS=1 python mutmul-numpy.py 1000
0.030291080474853516
0.029540538787841797
0.029771089553833008
0.02943873405456543
0.02980208396911621
0.03012990951538086
0.0300595760345459
0.030525922775268555
0.03243899345397949
0.02984023094177246
OMP_NUM_THREADS=8 python mutmul-numpy.py 1000
0.0073316097259521484
0.007174968719482422
0.007193326950073242
0.006682157516479492
0.006906747817993164
0.006983757019042969
0.007711172103881836
0.008562803268432617
0.007740497589111328
0.00671076774597168
>>759のnumpy計測がsingle threadになってたりしてる？ >>763
シングルスレッドでの計測になってたぽい。この計測って最初のメモリ確保は含めてる？ SIMDでの行列演算の最適化方法そのものとかさすがに関係なさ過ぎ。
RustとC++の違いに着目するならまだしも。 >>764
>>762の通り行列積部分
JuliaをREPLで試した
function matgen(n, seed)
tmp = seed / n / n
[tmp * (i - j) * (i + j - 2) for i = 1:n, j = 1:n]
end
n = 1000
n = round(Int, n / 2) * 2
a = matgen(n, 1.0)
b = matgen(n, 2.0)
using BenchmarkTools
c=@btime(a*b)
OPENBLAS_NUM_THREADS=1 julia --optimize=3 --check-bounds=no
29.581 ms (2 allocations: 7.63 MiB)
OPENBLAS_NUM_THREADS=8 julia --optimize=3 --check-bounds=no
6.875 ms (2 allocations: 7.63 MiB)
juliaが行列積でnumpyの10倍遅いのが意外 >>765
まあ、この板は実質雑談板なんで。アンチOSS君も大暴れしてますし大目にみてください。 OSS関係無いわな。スレチ。別のところで好きなだけやればいい。 >>769
rustのエコシステムの話とかなら関係あるけど、OSS自体のメリデメ、とかそういう論点はスレチ。 >>772
そんなことなくて、OSSであるということは、
非常に大きな影響を及ぼすので無視できない。 >>773
それが通るなら少しでも擦れば何でもありになる。
影響の大小なんて本人が大きいと言い張れば大きいことになる。
スレタイ読んで関係あるかどうか常識で考えれば自明。もちろんあなたに言っても意味無いわけですけども。 >>774
そういうことじゃなくて、OSSは本質的に非常に大問題を
抱えてしまっているから、どうしようもない。 >>775
そういうことじゃなくて、
じゃなくて、このスレそういうスレなんだよ。
マジで頭おかしいw Rustが失敗した原因の根底にOSSの問題があるって言いたいんじゃね 「（すべての）OSSは本質的に非常に大問題を抱えている」→「Rustは本質的に非常に大問題を抱えている」
ってことだな
一応前提が正しければ結論も正しいけど前提の論証が大変そうだ
「一部のOSSは本質的に非常に大問題を抱えている」→「すべてのOSSは本質的に非常に大問題を抱えている」
みたいな論証魔法を決めれば何とかなるけどプログラマはこの類には耐性あるからな
「一部の」と「すべての」を削って後ろの修飾語を盛る程度だとまだ術式が足りなくて通らない 矛盾を抱えているんだから論証とか無駄。
どんな結論でも導出できる。 背理法の仮定を利用しなくても矛盾するなら、任意の結論を背理法で証明できる
だから「矛盾しているのはお前だけ」みたいな結論はむしろ出てこないんだよ
属人的な仮定を必要としないのだから全人類が矛盾する >>782
論理を語るのなら、まず共通の前提条件を全部出して合意取れよ。
前提条件より先に結論が出るとかありえないし、前提条件の合意が取れていないなら矛盾するから議論する意味がない。 >>782
合意がなければ義務はないというのは正しい
議論には義務が必要不可欠というのは間違っている
強制力があるべきという合意がもしあれば論理ではなく物理的な戦争が始まる ちょっと間違えたけど、どこを間違えたのかいちいち合意を取るのが面倒臭い まあ、この板はプログラム関連なら基本的に何話しても良いってことで。この6traits目を、立てた本人が言ってることなんで。次のtraitからはそれについても書いとく？ このスレタイに釣られるって段階で、参加者がある程度絞られてる
別に何話そうが確かに構わんのだが、面白いことを書け
ライブラリ書いてるヤツが定着してるのは、Rustのライブラリ作りってこんな感じなのか、と思って眺めてる
そういや、hsutter氏がなんか動画出してたけど、まだ観てない
勉強しないといけないこと(non C++, non Rust)大杉 >>766 訂正
測定自体はOKですが、最後の一文、桁を読み間違えてたorz
× >juliaが行列積でnumpyの10倍遅いのが意外
juliaとnumpyは同じスピードです(両方ともopenblasバックエンド、同一スレッド数の場合)
https://i.imgur.com/AKwAFec.png
>>747,759,764
そちらの環境でのマルチスレッドnumpyの測定数値が出ていたら自作ライブラリとの比較結果お願いします >>791
なんかnumpyでマルチスレッド指定しても速度上がんないんですけど何か要因は考えられますか？ >>792
こちらでは素のvenvでやり直しても、defaultでマルチスレッドが効いています
$ python311 -m venv venv
$ . venv/Scripts/activate
$ pip install numpy
$ pip list
Package Version
---------- -------
numpy 1.25.2
pip 23.2.1
setuptools 65.5.0
$ du -h venv
96M venv
$ python matmul-numpy.py 1000
0.006245136260986328
0.006272077560424805
0.006720542907714844
0.007251739501953125
0.006670713424682617
0.0067596435546875
0.006724119186401367
0.005736351013183594
0.005699872970581055
0.007322788238525391
condaの場合は分かりませんので、とりあえずpipのopenblas版numpyで計測してみては?
https://numpy.org/install/#numpy-packages--accelerated-linear-algebra-libraries miniforgeのcondaでchannel指定してmkl版numpyを入れましたが、こちらもマルチスレッドが効いています(MKL_NUM_THREADS指定無しでも)
$ conda install -c intel numpy
$ du -h ****/tmpenv2
1.3G ****/tmpenv2 <-- orz
$ python -c 'import numpy; numpy.show_config()'
....
blas_mkl_info:
libraries = ['mkl_rt']
library_dirs = [****]
define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
include_dirs = [****]
....
MKL_NUM_THREADS=8 python matmul-numpy.py 1000
0.007200717926025391
0.007269620895385742
0.0062868595123291016
0.00983738899230957
0.007195472717285156
0.006726503372192383
0.006485939025878906
0.0068206787109375
0.006815910339355469
0.006788492202758789 MKL版はthread数指定しないと=8よりも若干遅くなる
$ python matmul-numpy.py 1000
0.007860660552978516
0.009339094161987305
0.00830698013305664
0.006848335266113281
0.008496522903442383
0.007841348648071289
0.007840871810913086
0.00741887092590332
0.007982254028320312
0.006742000579833984
$ python -V
Python 3.8.11 :: Intel Corporation
芋づるインストールされた中でバージョンが気になるもの
mkl intel/win-64::mkl-2023.2.0-intel_49496
mkl-service intel/win-64::mkl-service-2.4.0-py38h9a4cf0c_35
mkl_fft intel/win-64::mkl_fft-1.3.6-py38h5020ddc_56
mkl_random intel/win-64::mkl_random-1.2.2-py38hf267b2b_76
mkl_umath intel/win-64::mkl_umath-0.1.1-py38h51af1d9_86
numpy intel/win-64::numpy-1.24.3-py38hcdfd0aa_0
numpy-base intel/win-64::numpy-base-1.24.3-py38h9b12b81_0 シングルスレッドがopenblasよりも若干遅いじゃないか!
この辺でやめておきますorz
MKL_NUM_THREADS=1 python matmul-numpy.py 1000
0.032694339752197266
0.03222513198852539
0.03307652473449707
0.03224611282348633
0.031710147857666016
0.03175640106201172
0.032773494720458984
0.032234907150268555
0.03272652626037598
0.0316920280456543 crate の docs の comment 率上げるために
struct に comment 付け捲る仕様はホントうざい python や bumpy の話題はスレ違い。
OSSの話題は許容範囲。
同一視してはいけない。 RustとC++の比較において、前者が「パソコンにおいて」
OSSからスタートしてしまったことは、全ての問題の始まり。
かつてC言語はUnixではOSSであったろうが、パソコンでは
原則的にクローズドであったからこそ発展を遂げた。 >>799
>かつてC言語はUnixではOSSであったろうが、パソコンでは
>原則的にクローズドであったからこそ発展を遂げた。
自分で書いていて論理がおかしいと思わないのかな? >>799
C言語がクローズドって何がクローズなのかな?
ANSIは誰もが使えるオープンな規格だろうが?
他人に伝えたい文章は正確に書き給え >>801
TurboC, msc, Watcom C/C++, LSI C, Lattice C,
Small C などがクローズであり、パソコンでOSSなものは
当時存在していなかったはずだ。 C言語は、規格はオープンと言えばオープンであったが、
PC-9801用のコンパイラのソースコードは非公開であった。
X68000 は gcc だったらしいが。 >>802
>>799
>パソコンでは原則的にクローズドであったからこそ発展を遂げた。
これは因果化関係を主張しているので
相関ではなくて因果の根拠を示すことが必要です
述べて下さい >>804
クローズドだから競争が生じ、開発環境が高度に発展した。 Win95が開発環境にとって終わりの始まりだった。
OSが32BIT化したことで、Unix系の無料OSSツールが
「主流のビジネスパソコン(PC-9801など)」の世界に
大量流入。
競争条件が破綻し、競争が不可能となり、衰退。 >>759
(室温超伝導)サンプルの提出をお願いします
>>793-796
スルーか一言で済ませて、余計な知恵を付けさすな C/C++
/*
printf("hoge*/hoge\n");
*/
コンパイル通る
Rust
/*
println!("hoge*/hoge");
*/
コンパイル通らないωωω >>799
>RustとC++の比較において、前者が「パソコンにおいて」
>OSSからスタートしてしまったことは、全ての問題の始まり。
一理ある
>かつてC言語はUnixではOSSであったろうが、パソコンでは
>原則的にクローズドであったからこそ発展を遂げた。
君の世界戦は異世界のものなのか？ >>811
俺が言っているパソコンとは、PC-9801のことだ。
他のパソコンは知らんが、PC/AT機でもDOSでは、
OSSなコンパイラはほとんど動かなかったのでは。 >>814
お前の方が知らんだろ。
OSSのせいで何もかも衰退してる。 みんなの予想通り
プリゴジン氏が暗殺された
ぜんぶOSSのせいだ >>802
当時っていつだよ。
gnu cは1980年台からあるだろ。 >>813
ハナクソみたいな日本市場で世界を騙るとか、どこの異世界ですかね？ >>819
5chでイキって気持ち良くなるとか、どこの暇人ですかね？ >>802
確かにコンパイラは淘汰され減ったが
トータルのコンパイラの利用者つまり開発者は
OSSがない場合に比べて増加したんだと思うよ
誰でも直ぐに無料で開発を進められるようになり
開発者の裾野が広がったのは
ソフトウェアの進化速度を考える上で重要だったと思う >>821
淘汰されたのはOSSのせいじゃなくてVisual C++のせい。 >>818
DOSのPC-9801ではまともに使えなかった。 競技プログラミングみたいな何の能力を測定しているのか、
また、参加者も限られるようなものの成績が良かった
ことと、言語に対する評価眼を持っていることは別である。
評価とは、審査する側が誰であるかによって異なってしまう。
国際組織でも、アメリカの金で成り立っている組織は、
アメリカの意見になってしまうことは良く知られている
のと同様、プログラムでも学問の世界でも同様だと考えられる。 「若いから年上の人より正しい判断が出来る」とは限らない。
しかも、その若者の能力が高いかどうかを判定しているのが
京大総長というような高齢の権威者の場合はなおさら。
何を持って人の能力を判断しているのか問題、という問題
が起きる。 京大総長が、「この人はプログラミング能力がすばらしい」などと
判断したとしよう。
しかし、それは「京大総長基準」に過ぎない。
「プログラミング能力が素晴らしい」とは、一体何を
もって決めるのか。
仮に素晴らしかったとしても、プログラミング言語の
良し悪しをその人一人が判断してよいということでもない。 パソコンが高価だった時代はゲーム機が貧者の味方
その時代のゲームは今でも売買されているが開発者の利益にはならない
むしろ過去の商用ソフトは衰退させた方が最新のゲームを売りやすい #[derive'Copy, Clone)]
たとえば古い passwd ファイルの形式とかで使われていた
root:x:0:0:root:/root:/bin/bash
user01:x:500:500::/home/user01:/bin/bash
のような「:」区切りのテキストファイルのデータベースを扱いたいとき
C標準のライブラリは何ですか？
Rust用のcrateで言うと何ですか？ >>831
区切るだけならstr.split(':')かstr.splitn(7, ':')
構造体に入れるなら一般的にserde crate
そのケースならcsv crateでコロンにデリミタ指定でもいけるはず Cなら自分はstrtokが好きかなあ もちろんいろいろとunsafe THINK Cとか、CodeWarriorとかあったけどねえ 内製にはgccで十分だわって マクロはズル
非売品はチート
ネイティブコンパイラは商品という雰囲気 スレタイだけ見て検証結果だけ見に来ました
どこですか？ 検証結果ならC++とRustの平行線が交差してるところに書いてあるよ MS「BASICとCってどっちが儲かるの」
科学「推測するな。速度を計測しろ」
アンチOSS「ソースを見れない方が勝つ」 >>844
アホ科学者「推測するな。速度を計測しろ」
知的科学者「思考実験しろ」 科学的wの含意がわからないバカは単なるバカより悪性度が高い 参照で充分なのに所有権の移転を要求する関数があると
いちいちcloneしてから渡さないといけないから非効率
もちろん一回呼ぶだけならclone不要だが
ループ中とかで何度も呼ぶ用途には使えない
なんでそんな関数の設計になってるんだろう？
別にメリットでもあるんか？ まだ検証結果とかないんですね
結果だけは知りたいので、そのうちまた来ます >>852
誰かばれるからネットでは言えないだろうて。 逆じゃね
日本人は実装軽視
設計でガチガチに固めすぎる >>853
具体例出せないんだと
本人の認識に問題あるのか
関数の作りに問題があるのかわからない わかってないのに何かわかったつもりになって書き込まれているクソスレ 上には上がある わかったつもりでも、さらに賢い奴から見ればクソ
自分なりに勉強して持論もまとめてるが、わかったなんて思わないもんだ 賭け事とか軽率な行動をしなければいいよ
頭の中が謙虚だろうが傲慢だろうが行動に直結しなければいい
いくら謙虚になっても忠誠心か何かで極端な行動をするパターンはある 構造体に演算子オーバーロードしたいときって，所有権持ってかれないように構造体の参照に対して演算子オーバーロードでいいの？
期待通りに動くんだけど
&a + &b
みたいな書き方になってまどろっこしい (*a).演算()やa->演算()を間違えてa.演算()と書いたらエラーになるのがC++で
エラーにならないのがRustじゃないの >>867
ネットで身元がばれるような情報が書けない事をいいことに
勝利宣言してしまう人。 どうせ普及し無い事が分かってるし、なんとでも言え。 スマホや自動車の部品のように
買わされたけど存在意義は知らない物が普及することはよくある おじさん思考トレース
おじさんはね
Rustに部分的にでも欠陥があるかのような物言いは許せないんだよ
コードが出れば今すぐにでもそいつのせいにしてマウントして打ち消しようと思うんだけどね
証拠がないならそいつのせいってことで断定してマウントとっちゃうのが手っ取り早いから、もうそういうことにしちゃうよ めちゃくちゃくやしかったんだなwwwww
クッソおもろい FirefoxってRustでも書かれているってだけで
C/C++の方がまだ多いうだよ 確率的にはコンパイラのバグよりもアプリかライブラリのバグが多いから
コンパイラに欠陥があった的な物言いは分が悪い
これをやりたいためにライブラリを外部に丸投げする方式が普及している >>865
普通はCopyにする
Copyにできないなら明示的にcloneする
どちらにも採用できない状況なら
参照に対してのみオーバーロードを書く
+や-の演算子はdot演算子と違ってauto-referencingが効かないから
&a + &bみたいな書き方になるのは現状では避けようがない
将来的にauto-refが効くように改修されることがもしあれば
a + bのような書き方もできるようになるかもしれない ＞&a + &b
＞みたいな書き方になってまどろっこしい
Copy実装したくない大型なら参照を使うから&a + &bの書き方がありがたい
小型ならCopy実装してa + bと書ける 大きいサイズの値を2回以上コピーするのを1回にするような最適化は
コピーコンストラクタに副作用がない保証があればできる気がする
そしてRustのCopyの振る舞いはユーザが勝手に定義できない >>867
具体例出せないと後者の可能性高いだろ。
標準ライブラリやOSSならそういう問題は他の誰かからも指摘入って修正されるだろうし。 >>880
ありがとう
auto-refないから&a+&bって書き方になるのね
理解したわ >>883
具体例はfn add(self, rhs: Rhs) -> Outputだったということでしょ >>885
なるほどね
やはり勘違いしていたわけだ
&selfと書いていないから参照はダメだと思い込んでしまったのだろう
実際にはもちろんself自体が参照型でもOK 一般的にもトレイトのメソッドfoo(self, ...)についてself自体が&T型の場合もある
&T型はCopy実装されているため消費されても構わない
ようはポインタだから 比較演算子とかはauto-ref/derefできたほうがいいと思うが算術演算子はexplicitな今のスタイルの方がいいと思う
今でも&a + &bの中身がa.clone() + b.clone()になってるやつとかやめて欲しい >>885でSelfもRhsもOutputも自由なのでT次第でT + T、T + &T、&T + &Tなどそれぞれ最適な実装ができる
例えばT + &T -> Tは敢えて消費してそのメモリを居抜して返す効率パターン
例えば計算途中の中間生成Tは消費されてもよいわけで再び結果の中間生成Tに転用できる >>889
俺もそう思う
コピーして演算なら a+bで良いと思うけど
デカいオブジェクトで参照で演算なら&a+&bのほうがわかりやすいから良いと思う 数値計算以外にも応用できて
Rhsは &T でなくてもよいため
例えば { string.push_str(other_str); string } と書くところを
string + other_str と簡潔に書ける
以下の居抜き実装があるため
impl Add<&str> for String {
type Output = String;
#[inline]
fn add(mut self, other: &str) -> String {
self.push_str(other);
self
}
} >>888
俺もなんで&a+&bの＆を書くのがまどろっこしいが
>>847の
>参照で充分なのに所有権の移転を要求する関数があると
>いちいちcloneしてから渡さないといけないから非効率
に結び付くのか理解できないが,でも、rust野郎は激頭いいから同じ質問を形を変えた質問と
見抜いたんだろう くやしすぎて負け惜しみを書かずにはいられない老害爺ww Rustの名誉を守るため、日々欠かさずパトロール。
そうしてRustの名誉は保たれているのだ。 impl<'a> Add for &'a Foo
impl<'a> Add<&'a Foo> for Foo
これで、変数名に&はつかないけど括弧に&がつく感じにできるね
a + b + c == &(a + b) + c == a + &(b + c) Rustで学ぶなんとかとかいう本いっぱい出ているし、結構個人でやる気のあるやつは覚えるんじゃね？
Rust人口増えている印象。 地学を笑えば名誉を保てそうなのに
逆に名誉を捨てて地学を取る芸風みたいな 数年後にはHaskellみたいなってると言う人が数年前からいるけど数年後もいるだろうなぁ 数年前はHaskellはまだブームだったからその時は誉め言葉だったんじゃないの？ まあそもそもC++人口がそんなに多くないのにそこからRUSTに移行する人間なんて更に少ないわな ちょっと勉強するならいいけどビジネスでRust書くとか発狂しそう 単純なoperator overlodingでもTと&Tの組み合わせで最低4パターンは考慮しないといけないからな
一般的なビジネスアプリケーションでこういう手間をかけるだけのメリットを享受できるケースは少ない operator overlodを使うビジネスアプリケーションｗ
あるとしてもoperator overlodを定義するのはライブラリの仕事
利用者は型エラー起こさないように使うだけであり一般的な静的型付け言語どれも同じ >>914
知らない分野に無理にコメントしなくていいぞ ないな
算術以外でオーバーロードは必要ない
関数(メソッド)名で目的をはっきりさせる バカでも書けるフレームワークでも無ければビジネス利用は無いだろね >>916
operator<<
operator>> PerlやC++の演算子を想定してるんだろうけど
若者はそんなものは知らん
PythonとRustは失敗を繰り返さなかった >>919
シフトは整数以外で使ったことないな
そんなものをオーバーロードしてどうするんだよ
意味不明になるぞ >>915
具体的にoperatorをoverload実装して使うビジネスアプリケーションを言ってみろよ
例えば多倍長を利用するとしても汎用ライブラリが実装するから該当しないよな 一般的には算術演算子よりも比較演算子をオーバーロードすることのほうが多いだろうな >>921
そいう批判は昔からあったけど混乱することは全くないよ >>923
Rustなら例えばこう書くだけだな
#[derive(PartialEq)]
struct Foo { ... }
これで型表記Foo == Fooも&Foo == &Fooも通る
Foo == &Fooは撥ねてくれる
ちなみに値の比較ではなく
同一性すなわちポインタの比較をしたいならば
std::ptr::eq(&Foo, &Foo) >>925
>Foo == &Fooは撥ねてくれる
値として扱うならこれは跳ねるべきではないのでPatrialEqのimplが追加で2ついる おまえらいつも例を出さずにもめてるな
演算子をオーバーロード実装するビジネスアプリとやらの例を出せば済む話 >>927
例えば型不一致でも通せ！という理不尽な要求はここへ行き着くので認めるべきでない
if Foo != &Foo {
Foo = &Foo;
} >>929
eqメソッドを使った時も撥ねる仕様ならその言い訳も成り立ったかもね >>931
演算子オーバーロードの話をしているところにメソッドを持ち出したらオウンゴールｗ
メソッド使用でいいなら演算子オーバーロードの必要なし 演算子のオーバロードは、ライブラリマンに任せるよ これはC++も同様
あんなものバグ・抜けなしで書けるとか数学マンかよ
ああいうこともできる、というのがC++のいいところだが、自分には過ぎた代物 英単語ではない記号を使うだけなら仮想関数でもできる
仮想関数のように型を統一しないのがオーバーロードの特徴
統一するとvoid*とかObjecとか残念な型になってしまう >>900
その二つは別人
ソース俺
>>888
繋がってない
めっちゃ迷惑
自演じゃなくて他演されたの初めてだわ >>936を信じるなら
ID:EQIr/PqP
≠
ID:m1noAQBG = ID:RvCE3Lp0 = 行列ライブラリの人
で、ID:Aks4ymi6は行列ライブラリの人になりすまそうとしたっぽい謎の人物ってことかいな？ このスレまじで負け惜しみレスが多いな
なんでここまで幼児メンタルを引きつけるのか謎 ここはプログラマ板ではなくプログラム板
話はプログラムで示せ
それができない話ならばプログラマ板へ行け
具体的なコードで話せずに文句と批判するだけの無能は不要 急に発狂するやついて草
何か刺さっちまったんだろうなw こんな仮想空間でまじになっちゃって
負けたら大変なことになると思い込むのが問題なんだけど
論破というのはまさにそういう仮想空間で相手にそう思い込ませる術だよね rustって名前が良くないよねって思ったけどcも大概やったわ おれ865だけどなんで847と同一人物認定されてんの？ Rustは普及してないという願望・妄想と
Rustに言及するレスが続いてる現状を両立させるためだろ >>947
C++おっさん・爺は年齢的にRust覚えられないから
普及されると嫌だろうからな
一方、若い連中はもう化石言語になるC＋＋よりRustに将来性を見出すだろうからな。 でも、いまC++もRustも経験がない人が勉強するならC++からじゃない？ C++がある程度分かってないと、Rustのありがたみも分からないし。 Cと各スクリプト言語から来てRustで困ることなかった
C++は必要なさそう 将来性ならpython
言語設計ならNimかMojo
実力ならc/c++
かね。
pythonは無くなることないから身につけて損はないし、その延長線としてNimは使える。
Mojoはスタックフレーム指向として将来性感じる。RustはMojoの踏み台。 バイナリサイズを小さくしたい→C
バグを少なくしたい→Rust
？？→C++ >>954
Cの後継はZig
C++の後継はRust
C++はいらないこ mojoはわかるけどnimってスーパーマイナーすぎんか >>953
>>956
mojoは早くソース公開しろよ >>955
zig使ってるbunが1.0になったのに、肝心のzigはいつ1.0になるんだよ？ 喪女はまだめっちゃアーリーステージです～って言ってなかったか
それであんなにドヤ顔登場させた意味はわからんが >>962
あなたの遅れてる認定とか知りませんやんw 「次世代言語wに憧れる一日中暇なお爺さん達wのスレ」
さすが！中身がない！ 前にnimは使ったことあるけど、結論的にはそんなに将来性を感じなかった。nimのライブラリが少ないし、pythonのライブラリを使うと結局そこが律速段階になるので速度の恩恵も個人的には微妙だった。これなら普通にpythonを使った方が便利だなとは思った。いまはどんだけ進展してるのかは良く知らんけど。 >>953
Pythonは必要な時にスクリプトの読み書きができれば十分で
あの言語仕様と遅さはプログラミング言語としては適してないためこのスレの対象外
Nimは何もかも中途半端であることに加え
先が見えてしまったのとあの開発体制では今後も期待できないため無視してよい存在 mojoを持ちつつPythonを嗜み
Rustを横目にc＋に打ち込む 現実はこれ>>496
新たなネットインフラC++ではなくRustで記述されている >>971
現実はRustで書かれているものも稀にあるってだけでは? >>298
mallocしたままfreeしないのはRustでももちろんできる
BoxやVecなどにはleak()があり意図的にリークする(＝今後解放しない)ことができる
代わりに得られるのはライフタイムがstaticな可変参照
つまり静的にメモリ確保したことと同じ扱いになりライフタイムの束縛がなくなり自由となる >>972
超大手が色々検討してその結果Rustで作ったなんだが、
知りたいのは、なんで(C++じゃなく)Rustを採用したのかなんだよな。
俺思うに、ネットインフラは公開で超攻撃対象になるから、脆弱性がなるべく少なくなるように
するためにはC++よりRustが良いと判断したからじゃないかと妄想。 >>974
だからその超大手の数多ある新規プロジェクト群の中に
Rustのプロジェクが稀にあるってだけなのでは? >>973
そんなの(leak()って)あるのか、leak()でdropしない(禁止する)ように指示しているのかな >>974
C++と比べるとRustはまず記述のしやすさと可読性の良さ
そしてC++よりもコンパイル時点で判明できるミスやバグが多くてデバッガ実行も激減し開発効率が高い
同時にそれらは保守性の良さにも繋がっている
C++とRustのどちらも選べる環境ではC++が今後使われることがほぼなくなるのだろう >>975
まれだとしても,超重要なものにわざわざRustだからな
話題のRustでどれぐらいのものが出来るか確認するための
重要なものを作ってみた可能性もあるが >>496はCloudflareとAWSそれぞれの最も重要な中核部分だ
試しに作ってみるような部分ではない
今後は人員さえ揃えばRustを使うというIT各社の確固たる方針 何かを選ぶ理由とそれを選んだという事実の因果関係は無いほうが動きやすい
強者の命令に対し
命令に従うことが必然的ではない人間はもっと強い そもそも本家本丸のfirefoxのコードは実はC++の方が多いんだぜ? >>976
leak()へ所有権を渡すので所有者はいなくなりdropは起きない
代わりに&'static mutを得ることができてライフタイムに束縛されなくなる
例えば"abcde"の&'static strが所有者を持たずdropも起きないのと同じ >>977
「記述のしやすさと可読性の良さ」って冗談か？ Rustは冗長な癖に変な略語が多くて読みにくいし醜い。
あんなもんで開発するのは錆びついた歯車の自転車でギコギコ走らされるような罰ゲームだろ。 >>981
そりゃ既存のプロジェクトを数えりゃ歴史あるほうが使われてる割合多いだろうよ。 C++とRust両方使いこなせる人たちが100%
Rustに軍配を上げるように
C++の言語機能が弱すぎることがC++の敗因かと rustでdll造ってCから使うとき
rust側で勝手に捨てられるのは困るな メモリリークを簡単に立証できる参照カウントなら
勝手に捨てられないことを簡単に立証できる
これが勝因だ 1000なら今年中にC++にも unsafe{ } が来る ← 一応参加
結局C++とRustってどっちが良いの？ 7traits
http://mevius.5ch.net/test/read.cgi/tech/1693451813/ >>989
は？
C++もRustも同じだぞ
Cから所有権がムーブしてくることはないので
C++もRustもCで確保したメモリを勝手に解放することはない >>992
品質を犠牲にして儲ければ困らないがそういうのに不寛容な人達は困ってるだろうなあ
ってことでしょ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 32日 23時間 53分 25秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
