結局C++とRustってどっちが良いの？ 9traits

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ
・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝
・マな話は、マのスレもご活用ください↓

前スレ: 結局C++とRustってどっちが良いの？ 8traits
https://mevius.5ch.net/test/read.cgi/tech/1698468300/

関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

---

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

あるあるトピックス
・後発のRustは優れている(この点で特に争いはない
・といっても、C/C++から「推し変」するほどじゃない(使わないとは言ってない
・ていうか、Cとの比較と、C++との比較は違うくね?
・いくら安全っつっても、ヘタクソがunsafeだらけに書いちゃったらおんなし
・てかC++にも unsafe{ } はよ

・web方面、特に基盤部分での人気すごいね
・ChatGPTとかが賢くなる(のに賭けてる)からどうでもいい

=== 複製おじさん（通称複おじ）について ===
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が複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。

複おじは全レスおじさんの事かと思ってたから解説助かる

C++は全体がunsafeなのに…

複数垢を使って自演連投してるから複おじだと思ってた
考えを改めないといかんな

>>3
複おじと言えば一文一文すべてがデタラメなこの名レスを忘れたら駄目だぞ

>ムーブでビットパターンのコピーは発生しない
>ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
>さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
>Copyのコピーはディープであって高コスト
https://mevius.5ch.net/test/read.cgi/tech/1652347700/52

>>7
日本語として成立してない
怖い
なんかやってんじゃないか

>>7
過去レス見ると嘘つき呼ばわりされてる理由がよくわかった

>>2
＞・てかC++にも unsafe{ } はよ

まだこんなこと言ってる奴がいることに草

改めて複おじの足跡を辿るか？
>>3のまとめも半年以上更新してないし

ChatGPTにCopy Traitを実装するべき場合について聞いたら、「所有権の複製」って項目が現れてワロタ

「Copyのコピーはディープであって高コスト」以外は初心者によくある勘違いだし
勘違いから間違った内容を書いてしまうことは誰にでもあることだからまだいいのだが
繰り返し間違いを指摘されても謎の上から目線で無理筋の強弁を重ねることから荒らし認定されている

Copyはクローンされるけどクローンの実装次第ではディープコピーにならんの？

自己愛性パーソナリティ障害持ちに多い特徴だよ
自分のミスは絶対に認めずに詭弁を言う

Copyのクローンは単純なmemcpyだと思っていいよ
構造体の中に別の構造体（Copy可）が埋め込まれたような型だとディープコピーに見えるけど
再帰的なコピーは必要なくて単にバイト列全体を丸写ししてる
（逆に言えばそれができない型はCopyをつけられない）

前スレ
>0994デフォルトの名無しさん
>2023/12/08(金) 10:27:55.85ID:gyEpWkla
>Cで書かれたプログラムがある
>Rustに移植せよ
>https://uguisu.skr.jp/othello/7gyou.html
>https://ideone.com/0xz2SJ
Rustでできた?

>>16
それだとヒープのデータはコピーしてないことになるけど
メモリをアロケートしてデータをコピーはしてないってこと？
シャローコピーなの？

参照を含まない型のコピーにdeepもshallowもないでしょうが

ヒープ使う型は基本的にCopyにできない（Cloneは実装可能）
構造体に１つでもCopyにできない型が含まれてたらその構造体もCopyにできない
Copyはmemcpyしても問題ない型のマーカーだと思ってもらえばいいかな
メモリをアロケートしてデータをコピーする処理はCloneの方で実装する

そういえばmutがない方の参照はCopy可能だから
「ヒープ使う型は基本的にCopyにできない」はちょっと誤解を招くかな
ヒープを所有する型の方がいいかも

あー参照とかBoxは含められないのねCopyは
勉強になりますた

>>14
ディープコピーにはならん

>>18
Copyはシャローコピー

>>22
参照は含められる
#[derive(Clone, Copy)]
struct Foo<'a>{
x: &'a Bar,
y: i32,
}

C++は、全部 unsafe と言っても、
デバッグの済んだライブラリを正しく用いて
いれば、その部分は安全。なので、関数引数の
部分だけをよくチェックすると良い。
C++の関数呼び出しは、ポインタに
関しては、型チェックが強いので
間違った呼び出し型をしていれば
コンパイルエラーになることが多い。

>>17
https://mevius.5ch.net/test/read.cgi/tech/1681777958/

>>24
間違えないように書けば正しい動作するという
意味にしか取れない

>>26
Rustも同じだろ
「間違えないように書けば正しい動作する」も間違い
「間違えないように書けばコンパイルが通る」に過ぎない
正しい動作をするかどうかは間違えないように書くかどうかとは別の問題

>>27
その程度の理解力だと普段の仕事も間違いだらけぽいな

普段の業務も間違えだらけな奴がC++使うとか地獄か？

ロジックエラーはrustも共通だけど
rustはコンパイラのチェックが厳しいので
そこで防げるエラーはあるな
俺はそんなとこで間違えないから不要だけども

複おじってrustを普及させようとステマ要員なんだろうな

むしろRust支持者と見せかけてRustを貶めたい工作員だろう

C++もさることながら、C++とセットで付いてくるCMakeが嫌すぎる
Cargoは良いよマジで

autotools使えば良いじゃない?

autotoolsはcmakeよりさらに嫌かな……

ビルドツールとしてのzigいいぞ

>>33
makeに戻ったな
細かいことやろうとすると全部書き下せるmakeが1番自由度がある
典型的なことだけしたいならcmakeで良いけど

>>37
わかる

>>37
ruby必要だけど、rakeコマンドいいんじゃないかなと最近気になってる。

結局新しくて便利なものに徐々に流れる運命かなと思う

>>37,38
automake良いよ
makeの自由度があって依存関係の追跡もautoでやってくれる

どれもこれもCargoのはるか下でどんぐりの背比べみたいな利便性の主張合戦をしてるイメージ

meson割といい
cmakeが覇権とってるのは残念すぎる
あの文法の出来損ない感はひどい

>>42
議論をしたいのであればどう優れているのか具体的に書かないと

嘲笑してるだけで議論をしたいわけではないだろ
どう優れてるか具体的に教えてほしいのであれば教えてくださいと書かないと

>>45
ティッピングポイントに達することはないと踏んでいるので
どうでも良いというのが正直なところ

そもそもCargoとmakeを比べること自体ナンセンスなんだが

完全に機能が一致するとは思わんけどautotools相当じゃねーの?

パッケージを再利用可能な方法で定義するという面では共通しているかもしれんが
それも重要なのはautotools自体より
configureなりMakefileなりがGNUの規約に従っているってことのほうなんじゃねえかな……

Windowsネイティブビルド考えたらautotoolsはありえんでしょ
そのあたり機能がそろってるからcmakeがメタビルドシステムとして使われる
ほんとクソだけど

windowsなんてnmakeでいいやん

とっちらかりすぎで草

>>51
標準はmsbuild、nmakeはレガシー

一般的なことしかしない素人にわかりやすく教えてくれ教えてくれないか
CMakeどういうところがクソ？

>>53
あれXMLでしょ？
自動生成されるようなプロジェクトならいいだろうけど
手書きの場合nmakeがベスト

>>54
まずは使ってみたら？
偉そうにする前にさ

>>50
俺はWindowsバイナリはクロスコンパイルでしか作成しないけども
autotoolsはMSYS2で動くんじゃねーの?

cmakeだったらbazel使った方がまだマシだろ

あんなの使うメリットがない
モノレポのGoogleだから使ってるだけ

>>54
単体のプロジェクトならあまり困らない
しかし他のcmakeプロジェクトの取り込みとかやりだすとなかなか思い通りにいかない
言語コアが貧弱で変数すら関数が提供するというとんでもない設計
滅んで欲しい

rake使ってる人いないの？

Ruby関連のプロジェクトなら使って良いと思うけど
全く関係ないプロジェクトで別言語の環境を用意しなきゃいけない時点で厳しいかな

>>45
教えてくださいと書いたところで議論したいわけではないなら答えは来ないだろw

>>60
ありがとう、なんとなく理解ができた。

どう理解できたのw

ビルドツール選ぶだけで議論が発生する言語嫌すぎる

それJavaScriptの人に対しても同じこと言えんの？

JavaScriptはそもそも使っている人も含めて番人が認めるクソなので

いやC/C++のビルドも大概終わってるぞ
RustやGoみたいなやり方ができれば1番なのだが

>>65
CMakeのインタプリタの作りが貧弱でなんでもCmake独自関数を通さないと書けないような仕様？
多種のプロジェクトを一括管理しようとすると、Cmakeでの書き方の定石みたいなのがとても面倒臭い
てな感じに理解した、どう？

>>70
何でインタプリタが出てくるのか
本質は各プラットフォームのビルド環境を作って呼び出すだけのツール
LinuxだとMakefileを生成してmakeを実行するだけ
全然分かってないやん

あ、教えてしまった
こりゃ一本取られたな

>>71
いやいや、もういいです。私の質問の流れからあなたのその回答だと的外してるし。
いわゆる揚げ足取りの人でしょ？
私はすでに転んでるから、揚げ足は取れませんよ。
ではあとは自分で調べますので。悪しからず。

>>73
的外れではないだろう
的外れなことを言い出したから正解を教えてあげただけ
揚げ足取りと取られるのは心外だし
他の連中も同じこと思ってるよ

>私はすでに転んでるから、揚げ足は取れませんよ。
ナイスな言い回しだね
センスを感じる

開き直るのはやめてくれないか
正解か間違いかの2択しかない世界なんだよ
多少厳しいこと言うのは当然なんだ
そんな甘い世界ではない

じゃあなおのことつねに正しいことを言ってくれよ
さっきから君は間違いしか言っていないじゃないか
それとも自分は例外なのか？

的外れか逆ギレかの2択しかない思考なんだな

間違いを指摘してくれないか？
君はいつもそうだ
間違ってると言いつつ何も指摘しない
もうバレてるんだよ
この偽善者が

この流れから行ってどちらが頭がおかしいか？は一目瞭然だと思うのだが
cmakeを一切触ったことがないにも関わらず
大体理解したとか嘘を自演しそれを指摘したらもういいと逃げ
さらに追い討ちをしたら揚げ足取りと言われる
異常行動してるのは俺かお前か

「一般的なことしかしない」とは書いたけど
一切触ったことないなんて書いてないし。

「なんとなく理解ができた」とは書いたけど
大体理解したなんて書いてない。

自己目線だけで考える癖を直したほうがいいのでは？
思わぬ間違いのもとだぞ。

完全にブーメランだな

いいから違いを指摘しろよ
お前が言ったんだぞ
あくしろよ
ほら

ややこしい奴やな、まず頭冷やしてﾜｯﾁｮｲを理解してこいや

結局答えられずか
何もできないなら何も発言するな
ほんとお前はしょーもないな

>>84
もしかしてワッチョイが違うから違う人って思ってる？
いや思わそうとしてる？
クソワロタ

Ruby でRubyで使う、C 拡張ライブラリを作る場合、
gemspec ファイルで、extconf.rb を指定して、rake install する

mkmfがMakefile を作成する

# extconf.rb
require 'mkmf'

create_makefile(〜)

C++のビルドがRubyに依存するの、ダルすぎる

あーでもRuby拡張をビルドするとき限定ならいいか

>>62
いうて、今時はmakeコマンドも別途入れないといけないOSばかりだけどな

ninja「…」

ninjaはレイヤーが下
人が直接書かない

だがニンジャは一人も残らずコロす

ninjaに妻子でも殺されたのかよ

>>68
時代の流れについていけてないだけ

まーた変なスレ立ってますな
https://mevius.5ch.net/test/read.cgi/tech/1702531392/

おっまた俺の出番か？
潰しに行こうかな

潰すレベルの話題ですらなかった

あぼーん

>>99
ばら撒き凄いな

ﾜｯﾁｮｲ付いてないスレなら見境なしか
ええ加減にせえよ複おじ
https://mevius.5ch.net/test/read.cgi/tech/1519896738/

UPLIFT プレミアム・サービスのお知らせ

https://uplift.5ch.net/

ＵＰＬＩＦＴ　主な特典
・連続投稿の規制を緩和します。
・スレッド作成時の規制を緩和します。
・5ch.netのスレッド表示画面に表示される広告を除去します。
・5ch.net専用ブラウザで5ch.netの過去ログを閲覧できるようになります。
・海外からのアクセス・ホスト経由からでも書き込みができるようになります。
・書き込みが規制されているプロバイダーからでも書き込みができるようになります。
・5ch.netを安定して利用できるように運営を支援できます。

5ちゃんねるを存続させるためには、皆様のご協力が必要です。

最後まで御精読いただきありがとうございました。

ﾜｯﾁｮｲ付いたらこの静けさ・・・ちょい笑う。
あの雄弁・熱弁どこへやら

あちこち渡り歩いた挙げ句結局予想通りになったか

889: デフォルトの名無しさん sage 2023/12/05(火) 14:23:46.88 ID:4UYj/sQ8
ﾜｯﾁｮｲ立てたってところで結局また次世代言語スレと同じ流れになってRustスレに帰ってくるんだろ

このスレ実質一人が9スレ目になるまで回してたのってすごくない？
その情熱に比べたらﾜｯﾁｮｲなんてどうでもよくない？

スレが変わると前後して、BBxに焼かれまくったんだよね

RustかC++に動きがあれば、また活気でるっしょ
なんか動きあった?

Rustが再評価される：エコシステムの現状と落とし穴
https://www.infoq.com/jp/articles/rust-ecosystem-review-2023/

Rustチームの調査によると、サーバーサイド(バックエンド)のプロジェクトがRustの主要な技術領域であることが明らかになった。クラウドコンピューターのインフラとアプリケーションもRustを適用する大きな分野であり、分散アプリケーションもRustコミュニティの間で人気のある選択肢である。

Linuxはもっともターゲットとされているプラットフォームである(77％、Windowsは約41％、macOSは36％)。WebAssemblyは22％で、組み込みシステムは11％しかターゲットにしていない。モバイルアプリケーションでのRustの利用は、ほとんど無視できるほど少ない。

Rustチームの調査参加者の38%は、Rustは他のプログラミング言語よりもプログラミングがかなり複雑であることに同意している。62％が、習得にかなりの労力を要すると回答している。彼らはまた、Rustがさらに複雑になっていくことを心配している。これは、調査参加者の間でRustの将来に対する懸念として2番目に多かった。

80％以上のRust開発者はプロファイリングツールをまったく使っていない。その理由の1つは、現在利用可能なツールが非常に使いにくく、その結果を解釈するのが難しいからかもしれない。プロファイリングに焦点を当てた教材もほとんどない。開発者は、Rustのパフォーマンスを実際にチェックすることなく、盲目的に信じて満足しているようだ。このような姿勢は、業界でRustの採用が進むにつれて、重大な問題になる可能性がある。プロファイリングツール自体も学習教材も、改善のための真剣な取り組みが必要だ。

RustはC/C++キラーであるという当初の認識は、現在では適切ではないことが示唆された。既存のコードベースにおいて、C/C++のコードが大規模に置き換わっているという証拠はないし、将来そうなるとも予想されていない。なぜか？それは、CとC++の両方が機能し続けているからだ。C++は進化しており、長年の問題が解決されつつある。すべてをRustで書き直す必要はない。さらに、それを行うだけの労働力もない。

C2Rustがあるんだから、書き直しコストはなくなっていくとかいう話だったのでは
C++はともかく

若干旧聞だが
https://pvs-studio.com/en/blog/quest/kushnirenko_quiz/

途中でくたびれて、解いたところまで解説が見たい
https://pvs-studio.com/en/blog/posts/cpp/1091/

MLIRだの、dialectだのいうのが流行りだしてるんやな
どうやって勉強せえとｗ

Googleがプログラミング言語「Rust」に100万米ドルを助成、「C++」との併存・置き換えを図る
メモリ安全性にかかわるセキュリティ問題を減らしつつ、生産性を向上
https://forest.watch.impress.co.jp/docs/news/1566662.html

「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

報告書ではメモリ安全性について「メモリ安全性が保たれていないと、意図しない方法でメモリへのアクセス、書き込み、割り当て、または割り当て解除が行われる可能性がある」とし、メモリの安全性を保つ特性を欠くプログラミング言語として「C」「C++」を挙げた。

また同時に「メモリの安全性の脆弱性を軽減する最も効果的な方法は、サイバースペースの構成要素の一つであるプログラミング言語を保護することだ。メモリ安全なプログラミング言語を使用すると、ほとんどのメモリ安全性エラーを排除できる」とし、「Rust」などのメモリ安全性の高いプログラミング言語の使用を推奨した。

Rust界隈って政治臭が凄いな
そのうちC/C++の使用が法で規制されそう

増改築繰り返した古城に住むより、新築のSECOMの家ってこった。

でもなー実家が古城なんだよな

古城のリワークって夢あるぜ
仕事はともかく、ライフワークはこれでいいや

とっととdelete new malloc freeを禁止したコーダー向けc++を作ってほしい。
フルc++はライブラリアン専用でいいよ。

>>116
いまどきdelete new?
malloc無しでヒープの管理はどうするの?
と釣られてみる

さらに
「それは俺の仕事じゃない」
と釣られてみる

// 結局、だれの責任か、なので

【まとめ記事】 The Memory Safety Challenge in C++
https://johnfarrier.com/looking-for-pointers-the-c-memory-safety-debate/

Rust は C++ に比べて namespace 忘れる心配が減るが
use hoge::*; をやりがち
pub use fuga::*; もやって楽しくなる

VisualRust++まだかよ

>>121
ほれ
https://report.adam-tokunaga.jp

ボイス・トォ・スカル/マイクロ波聴覚効果
これらに関するモノが表に出ないのは下記が原因

スラップ訴訟
>>ある程度の発言力や社会的影響力のある、社会的に優位といえる立場の者が、特に発言力や影響力を持たない相対的弱者を相手取り訴訟を起こすこと。
巨大IT企業から「法的措置をちらつかせる停止通告書」を受け取った場合の対処方法とは？
https://gigazine.net/news/20240201-deal-cease-and-desist-big-tech/
>>「Cease and desist(停止通告書)」とは、著作権侵害やその他の違法行為を犯していると思われる相手に対し、その行為を停止せずに続ける場合は法的措置を取ると警告する通知のことです。
>>巨大テクノロジー企業は個人の開発者や研究者に対して停止通告書を送り、自分たちにとって不都合なサービスの開発や研究を止めさせようとすることがあります。

伝二派や音波や磁場などに関する論文を一般人がつなぎ合わせて世界中に周知っ徹底すれば主の手の研究所が研究可能になる
一般の人が使用できるように企業が製品化してくれる
現在裏で使用しているので本物か偽物かが不明なので確実に本物という品を使用できる
一般の者はすり替えられても機器が本物かが不明でしょう
消費者省に訴えれる

一定以上の一般人がそういったものがあると認識すれば器機使用者もだれを見ればよいか不明になる
本物の器機使用者のランニングコストが重荷になってくる

霊感商法
電磁波過敏症や低周波騒音被害はプラセボ効果とレセプト効果に置き換えれる

Rustなんてゴミだろ
7DtD \595だから買っとけよ

Cargo の fetch がマジうざい
一日一回必ず遅くなるωωω

>>118
河野タローみたいな言い分だな

https://forest.watch.impress.co.jp/docs/serial/yajiuma/1594981.html
「Sudo for Windows」はRustで開発されている！ 「バージョン 24H2」にも導入決定
メモリ安全が重視される分野で採用が広がる

RunAsでええやん

C/C++こそ至高(であるべき)、と今でも内心思ってるが、
近ごろのC++の使われ方は異様なフットプリント肥大化になってる
いったんC++を排して、Rustで書き直してもらったほうが、Windowsもシェル以上がスリムになりそう

>>127
すげー！！！やっぱRustだな！

String では as_str() でいけるのに
PathBuf では to_str() になるのなんで？

PathBufはvalid UTF-8とは限らない
それがわかってればニュアンスの違いや戻りの型の違いが分かるはず

好きなもの使えよ。なんでも一つに決めようとするから、子供なんだよ。

でもね、基本的には「なんでも一つ」に決めるべきなんよ
複数許容するというのは例外処置なんだと肝に銘じておくべき

ひとつに絞るなら、COBOLのようにしぶとく生き残るだろうCを選ぶけど、(進化の面において)だらしないんだよな

Cはまだマシだけど
C++はボタンかけ間違えたまま無理に猪突猛進

CはnullptrがC23になってようやくとか委員会サボりすぎ

C言語スレ見て判るようにC界隈の集まりは老人会だよ

【AI】IQ100超えを達成したAIモデルのClaude 3は「いい性格」を持つようにトレーニングされている [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1718025035/l50

C言語は永遠に不滅だッ！！

どちらもGUIに弱い
でもC++はUnrealEngineがある分強い

GUIに強い言語ってのがわからん

HTML/JSですら、強いっていうのとは違うと思う
あれは複雑になりすぎてる

rustはまずgodotに採用してもらおう

>>142
VB Delphi C#
やぞ

Form系を持ってるかどうかか ライブラリ+IDEの力だな 一理ある

guiビルダーって固定レイアウトでしか威力発揮出来ないからなあ

GUIつーても、WinでGUI作る意味は薄い。
スマホアプリか、Webアプリがメインやろ。

その場合、開発環境はLinuxかMacになる。
イミュータブルがデフォルトなのも並行・並列処理に有利（鯖向け）だし。

さすがにJavaから乗り換えは難しいだろうけど、新規案件から徐々にRustに移行すると予想。
その際、JavaのNetBeansやSpring的な地位を獲得しようと動き出すオープンソースも出るのでは。
（もう出てる？）

量子テレポーテーション
光より早いは光の振動数より早くなるという意味
振動するはジグザグなのでより線に近くなっている状態なので坊でついている状態
ワーム・ホール
全ての者が振動しているのでその振動幅を多くして１回折り曲げた状態でAB感が接触している状態を話している
でも移動後に一気に反発して反対側に振り切れるのでそのエネルギーを物質が受けると・・・

ボイス・トォ・スカルのマイクロ波聴覚効果【1970年ごろ】の論文はマイクロ波を使用しているのでマイクロ波当確効果という題名
下記の電磁波を使用すれば題名がその波の名前に変化する
スマフォで使用されている波は【マイクロ波 ミリ波 テラヘルツ波】がある
なのでミリ波聴覚効果 テラヘルツ波聴覚効果 という特許名称になる

電磁波の種類は周波数によって分類される
電離放射線【波長が短い】とは、周波数が3000THz以上の高周波電磁波
非電離放射線【波長が長い】とは、周波数が3000THz以下の電磁波

大きく分類すると下記の5種類の電磁波が存在
1.放射線【X線 γ線】
2.光線【紫外線 可視光線 赤外線】
3. 高周波（電波）【サブミリ波 マイクロ波 超短波】
4. 中間周波【短波 中波 長波 超長波 極超長波】
5. 超低周波【超低周波には他の電磁波のように種類があるわけではなく、1種類しかありません。】
※量子テレポーテーションまで加速すると可視光線も見えなくなる
可視光線なども威力が出るとS線のようになるが各線の特徴が残る

>>146
いやいや
いつの時代の話だよw

【マイクロ波センサー】長距離でも壁があっても動きを検出！
↓2010年ごろには完成
高齢化社会を支える“見守りシステム”の開発に成功-カギを握った半導体ソリューションとは
↓2026年ごろにさらに性能工場
旭化成、ミリ波・マイクロ波帯の空洞共振器による微小金属検査システムを開発

男女関係なく陰部を撮影
一度でも盗撮されていれば正確な色合いの・・・
初期型は赤外線センサー【自動ドアのセンサなど】

子どもが言語を獲得していくのと同じようにAIモデルに学習させることに成功
AIを使って「赤外線カメラ画像のフルカラー化」に成功！

世界中で横行

ほら出てきた
https://www.itmedia.co.jp/enterprise/spv/2406/28/news084.html

NAPTIMEとはなかなか皮肉の効いたプロジェクトだな

プログラマーやセキュリティ屋が橋の下か地下道で
昼寝せざるを得ない時代もそう遠くは無いようだ

並以下の技術者(俺含む)は仕事なくなるなｗ

上級者はAIを庇護して鍛えるお仕事 今より難しそう

流行りに乗っかって儲ける山師みたいなプログラマーが輩出するだけで
別に今までと変わらないと思うけどなあ

現状はネットに転がってるソースを引っ張ってくるだけ。
引っ張ってきたソースにバグがあったとして、それは掲載した人の責任か？引っ張ってきたAIの責任か？利用した人間（または会社）の責任か？

自動車の自動運転と同じで、どこが責任とるか決まらんと実運用は難しい。

>>154
KENYAのことか

>>155
利用した人間の責任に決まっとるやろw

AIでコード作成→AIで脆弱性検出→（以下ループ）

>>157
順当に考えれば、そう。
でもそうなるとAIの普及の妨げになる。
AIを売る側にも責任は取りたくないけど、じゃあ利用したあんたの責任ねって言ってたら利用してもらえないというジレンマ。

責任はうちで持ちます！という言える（だけのクオリティを出せる）AI企業が一抜けするだろうけど、まだ言えない。
というチキンレースなう。

>>159
そもそもソフトウェアにそんな製品はないだろう
何でも良いので使用許諾を良く読んでみ？

ちょっと旧聞だが

【解説】 Rust言語を、人命に関わるような決定的に安全性が重要なシステムに使用することをサポートする「Safety-Critical Rust Consortium」設立
https://www.publickey1.jp/blog/24/rustsafety-critical_rust_consortium.html

C/C++派だが、こうしてライバルが がんばれば、C/C++もやっと改善すると思うので

>>160
今まではね。
でも、AI時代は分からない。

自動車業界がまさに「自動運転で事故を起こした時、運転手の責任か？メーカーの責任か？」論争の真っただ中。

「包丁で事故を起こした時、利用者の責任か？メーカーの責任か？」

>>162
自動車にはリコール制度があるから
ソフトウェアに導入されることはない

>162
それは利用者が手を出せない(出さない)自動運転だからこその議論

>>163
事故の原因が包丁の欠陥によるものならメーカーの責任

>>162
レベル3/4だと運転手は自動運転システム
事故の原因が自動運転システムによるものなら今の法律や今までの原則に従えば当然メーカーの責任
でもそれだと日本での実用化が送れて日本メーカーが開発競争から取り残されちゃうなどと言ってとメーカーの責任を少しでも減らそうとしてるのがトヨタをはじめとしたスポンサー企業から献金/裏金/広告料を受け取ってる人達
検索エンジンの汚染もすでに広がってるので要注意

ソフトウェアは自動車産業と比べると
メーカ側が負う責任は極めて限定されている超あまあまの業界
みんな読んでないと思うが使用許諾契約書をちゃんと読むと
ソフトウェア使用によって生じた如何なる損害についても
賠償請求することはできないと規定されていることが多い
AIもそれで起きる被害をメーカ側が負わせられることはならないと思うよ

EULAに書いたからといって損害賠償を一切しなくていいわけじゃないから
賠償関係は今年から不当条項にあたるかどうかの判定も厳しくなってるから
古いEULAをそのまま使ってると無効とされるリスクが高い

>>162
ハルシネーションで人死にが出たらとんでもないので永久に実用化しないでくれ

とりあえず乗ったやつの自己責任でいいんじゃない
一度死人が出ないと答えは出ないよ

ちょっとぼんやり考えた
AIがふわっとコードを量産するフェーズと、Rustが超安全コードってものに挑戦するフェーズがいっぺんに来てるのか

安全性と正しさは無関係
Rustはコードの安全は保証しても
システムの正常性は保証しない

これなんかかっこいい教訓言ったつもりなんかな

さあな
相当に頭が悪いやつだということだけは間違いない

どのへんから頭の悪さを感じたんかね？

>>167
それじゃ一生自動運転なんかできんと思うけどね。
普及するには保険のような支払い義務とセットにしなきゃ無理だと思う。

本物の文盲が居るな

日本がまさにそうなってる、ほっとくと一生自動運転なんかできん
いろいろ蹂躙できるらしい中共系がすんごい進んでるじゃん

瑕疵を生まないAIってのは、日本向きの題材かもね 避けて通れないし

経済合理的な技術って受け入れない社会が衰退して、受け入れる社会が得するだけだからな
もたついてるあいだに手遅れになる

W3Cとマイクロソフトの仕様ならバッファオーバーフローしないアルゴリズムでパーサーを書けたのに
グーグルwithアップルがなぜか危険にしたのが
HTML5仕様

Switch/PS3エミュきたな
これでソニーと任天堂のゲーム割りまくってやるぞ
誰が日本企業に金なんて落とすかバーカ

https://www.aroged.com/2024/07/09/xbox-series-xs-dev-mode-update-enables-switch-and-ps3-emulation/

>>163
包丁はほとんどの場合、使用者本人が自覚を持って行動を起こさないと人命に関わる事故は起きない
でも自動運転は、使用者の意思に関係なく人命に関わる事故を起こす

包丁を例に出して議論は不適切

自覚を持って包丁を使って人命に関わる結果を引き起こしたのならそれは事故ではなく事件

>>182
すべてが自動運転なら格段に事故が減ると思うよ
たぶん1/100とか1/1000くらいにはなる

自動運転を公道で許可するなら免許条件の厳格化もセットだ
DQNが排除されるだけで事故も渋滞も大幅に減少する

事故の殆どはヒューマンエラーが原因
コンピュータの誤作動はそれに比べて遥かに少ないと思われ

人間が運転して年間数千人が死ぬところを
自動化したら数十人なったら画期的な
進歩だけど残念ながら厳しく言われるだろなあ

自分の運転が原因じゃないのに事故ったら自分に賠償請求が来るから、絶対メーカー訴える人出てくる。
んで、「自動運転は事故を起こさないことを保証するものではありません」って書いてましたよね？って言われて敗訴するまでが１セット。

事故が減るってのが統計で明確になったら、ヘルメット義務化みたいに自動運転義務化すれば保険会社から変わっていって普及するだろうけど。
それこそ当分先の話。

>>188
完全自動運転の場合の事故の責任は運転者ではなくメーカー側にあるってのはとっくに決まってたと思うが。
整備不良や違法改造なんかは罰だろうけど。

電動キックボードは一瞬で普及したから結局利権とかみ合うかどうか次第だよ
そういう意味では自動運転が公道で走るなんて都心じゃ一生無理だろう

まずタクシー業界に補助金を掛けてねじ込む
そして運ちゃんを乗せた状態で自動運転を導入する
運ちゃんは業務中自動運転させるか自分で運転するか選べて事故った時の対応や保証も一部兼ねるとする
損害が出た場合は運ちゃん：タクシー会社：自動運転業者で適当に比率を割り振る
自動運転中の場合乗客と一緒にただ乗ってただけの運ちゃんに責任は発生しないからWin-Winだろう
これで自動運転を公道で走らせる目的を一旦達成させる

いや自動運転させるかどうかは客に選ばせた方がいいか
選ばせることで客にも心理的責任を負わせて、やっぱ自動運転or運ちゃんがいいねと利用後に評価して貰うか

>>188
>「自動運転は事故を起こさないことを保証するものではありません」って書いてましたよね？
これで賠償責任を逃れられると思ってる無知なやつもいるんだなｗ

超高齢化社会に加えあらゆる運転手が極端に不足している。
進むべき答えは一つだよなぁ

タクシー露助は事故を起こさないことを保証するものではありません

タクシー雲助だったわ恥ずい

運転手不足を補うのに自動運転をというのなら間に合わんだろ
それに移民でどうになしましょうという事が閣議決定してるしな

ライドシェアとか白タク以外の何物でもない
っていうか武漢コロナ前から中國人の白タクが横行していた

>>193
裁判で勝訴するにせよ、敗訴するにせよ、その文言が入ってるかどうかで賠償額が違ってくる。
要は、運転する側が自動運転は100%安全を保障するものではないという認識を持っているかどうか。
（例えば、事故が起こりそうなときにブレーキ踏んだかどうか）

メーカーが自動運転の覇権をとれば賠償額なんてすずめの涙、とんでもない利益が出るでしょ
何人か犠牲になったとしても、巨額の利益が見込めるからテスラ、BYDがし烈な争いをしてる。
正直賠償なんて自動運転が市民権を得てしまえばどうということはない程度になるだろうよ

>>199
それ運転補助の話じゃん
レベル2までの話をしてるのは君だけだぞ

運転の主体が人間から自動運転システムに移る最低でもレベル3以上を前提とした話をしてる

>>201
自分もそのレベルの話をしてるつもりだったが…。

レベル３だろうが４だろうが、事故が起きるときは起きる。
いざという時にブレーキを踏めば止まる、自動運転を切る機能は必須。

それとも何、危ない！って思っても自動運転だから大丈夫ってブレーキ踏まなかった馬鹿を擁護するつもりか？

レベル４をうたっておいてブレーキ踏まざるを得ない自動運転だった → （事故っても事故らなくても）メーカー責任

レベル４だからと自動運転まかせでブレーキも踏まず事故った → 運転手の（自動運転に対する）監督不行き届き

レヴェル4に任せておけばよかったのに人間様がブレーキ踏んだから事故ったになりそう

そういう場合もどっちも起こり得る。
でもだからって自動運転を切る機能自体が無いってのは有り得ない。

事故りそうな時もレベル４に任せるかどうかは企業や個人の判断に委ねるが、機能としては切れるようにしておかないと。

その時代なら車載カメラから状況を分析してシミュレーションで何回も検証して、どっちが事故らなかった可能性が高いか割り出せるだろう。
そして、それを人間が判断できたかどうか、その辺が裁判の際の焦点になるんじゃないかな。

>>202
>レベル４だからと自動運転まかせでブレーキも踏まず事故った → 運転手の（自動運転に対する）監督不行き届き

運転者の介在が不要なのがレベル4。その辺の認識から間違ってたら議論にならない。

>>205
それは失礼した。

けどまあ、非常停止ボタンと遠隔でのブレーキは付くはず。
（運転手が居なくなり、管理責任者が一人で複数台をモニターする感じ）

Rustスレで自動運転の話題
なぜ？
テスラが自動運転の開発言語にRust使ってるとか？

使われてるかは知らんけど、Rustに向いてる用途ではあるね。
速度求められる上に、命に関わるからバグは許されないという、Rustにドンピシャな用途。

天下のトヨタはC++だぞ
はい論破完了
https://anon.isc5.com/2015/06/sirouto.html

使われてるか知らんって言ってるのに論破も何もないやろ…。

こっちでも調べてみたら、今年2月にやっと検討グループが出来た段階だね。
https://www.tech-street.jp/entry/2024/02/14/112728#%E4%B8%BB%E3%81%AA%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E7%B1%B3%E5%9B%BD%E4%BC%81%E6%A5%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E7%B7%A8

こちらは「現時点、Rustで自動運転はありえない」という意見。
あくまで「現時点」。
コンパイラ対応してないのにコード効率悪いってのは謎だが、座談会に対する印象は悪くないみたい？
https://x.com/rui_long_lab/status/1691436985934835713

コンパイラが無ければ普及のしようも無いわな。
期待はされてるし、時間の問題だろうけど。
自動車業界に採用されればマーケットでかいから他より高給取りのプログラマーになれるぞ。

>>203-204
エアフランスかなんかの中華航空機の名古屋の空港で落ちた事故だね

Rustが採用されることはないんじゃないかな
C/C++を使う組み込み向け開発が広く普及してる現状，Rustに切り替えるメリットが感じられないんじゃないかと思う

具体的に何やってるかは勿論不明だが
トヨタがRustで求人出す程度には考慮対象
だと思われる

Rustのコード書くのって苦痛だから自動生成に向いてるとおもうよ！

Rustコンパイル遅いし
うっかりcargo updateしたら糞時間かかるし

>>216
コンパイル時間だけでなく、Updateという概念自体ガ開発環境では不安定要因になる。
また、ネット環境が遅い人を「技術が無いからお金が無くてネットも遅い」という論理で
馬鹿にしたりするのもおかしい。技術とお金の有る無しは日本においては相関が低いのに。

Rustの作者はアメリカ人で、なおかつ、FireFoxという無料ソフトを作り、
Googleからデフォルト検索エンジンをGoogleにすることで、年間一兆円の見返りを
貰っていた企業の人。だから、ネットが遅いとか、パソコンが非力とかの人の
気持が分からないし、ソフトを売って頭角を現したい、というような人の気持も分からない。

まーた始まった
1. 遅いってどこと契約して?
2. 以下でどのくらいの速度なん?
https://fast.com/ja/

ほらね。その人の実績を知りもせずに、ネットやパソコンの性能だけで能力を推定してしまう。

>>220
お前の実績にも能力にも興味はない
（もし実績や能力で評価して欲しければ公表しな?）
俺はどんなネット環境かに興味がある

>>221
なら、「まーた始まった」などと人を馬鹿にする必要はないはずだ。

>>222
俺は毎度きちんと理由を述べて馬鹿にしてきたよ

>>219について答えてね
どんな環境なのか興味ある

光ファイバーなどを使わずに、スマホ用の格安キャリアのSIMカードをSIMルーターに
入れて使っている。これで、月に2,000円ほどで使いたい放題に出来ている。
が、光ファイバーに比べれば遅い。

なるほど
だから遅いんだね

pearlのcpanやpythonのpypiはインストールするとき
(または最初にモジュール使ったとき)しか観に行かないけど
Rustはいつまでも回線に粘着してるイメージ

Rustの面白いところは使ってる人が誰もいないってことなんだよな

Rustは売りもあって関数型の中ではいい線行くとは思うけど、エゴが強すぎてまだ時期尚早って感じだからな
あと2段階ぐらい変身が必要かもな

>>228
うむり。
早くて５－１０年。
下手すれば２０－３０年は掛かるかもしれん。

ただ、確実に嫌われ者のC++のシェアを半数以上は持っていく。
C、アセンブラは規模によっては行けそうな気もするけど、ちょい分らん。

https://www.tiobe.com/tiobe-index/
最近の傾向としては時間経過のグラフをみると
2017年を底にC++は増加傾向のようだけどね

>>230
去年(2023)を境にまた下降に転じてるようにも見えるけど…。
（雑誌interfaceで特集組まれたり連載始まったりで経営者の目にも止まった（？）時期と重なる？）

でも、増加傾向だとしても驚くに値しない。
そもそもRustにまだまだライブラリが不足してるからね。
（そして、C++もシェアポインタとかでポインタ関連のバグ対策に力を入れてもいる）

で、一番C++のシェアを取りに行けそうなのが組み込み分野。
そもそもライブラリ（によるバイナリ増加が無理）が使えない場面が多い分野だからね。

コンパイラがやっと出始めたところだから、これからだよ。
出るだけじゃダメで、最適化も進まないとだし。
（こればっかりは先に出た言語に一日の長がある）

本当、長い目で見るしかない。
プログラマーだけでなく、経営者（総合的な開発コスト）やCPU兼コンパイラメーカー（どっちのコンパイラが開発しやすい？Rustもサポートしないと他に乗り換えられるかも？）の判断も重要になるし。

Rustについては上で良いとして、Haskellの順位がScalaやTypeScriptより上なのが地味にうれしい。

いっぱしの人気言語って言っていいよね。
（Ada以下なのは見ないことにする）

その辺てユーザーの声が小さすぎてリサーチ失敗してるだけだろ

そうかもね。
まあ、そもそもHaskellはそんな順位行かないのは分かってたから、50位以内に入ってくれてるだけでうれしい。

そして今気づいたけど…。
smalltalkが入ってない。
Effelも…。
という事は…。
純粋○○言語において、純粋関数型言語が純粋オブジェクト指向言語に完全勝利!!＼(^o^)／

目くそ鼻くそでは…

>>218
グレイドン・ホアレはFirefoxを作ってないだろ。

>>231
embedded ruby とはなんだったのか

走行中にぬるぽで崖から転落しそう

トヨタが実現した世界初の「自動運転によるタンデムドリフト」は、自律走行車の進化にとって重要な一歩になる | WIRED.jp
https://wired.jp/article/toyota-stanford-ai-tandem-drifting-cars/

ハローワークで聞いたら
10年前はJavaの募集がほとんどだったけど
昨年あたりからJavaが無くなって
Rustがほとんどになったって

>>239
ハローワークは素人だけどな

マジかよ退職届出してくる

トップブリーダー推奨

println!("hello, work.");

>>238
ヌルポは、メモリーエラーの中では初歩的なものなので、初心者以外は余り起こらない。
また、Rustの場合は、メモリーエラーが起きにくい変わりに、配列の index 番号の
間違い、及び、配列の範囲外アクセスによる panic が起きてダウンする可能性が出る。
どちらのエラーになるかの違い。

認知症なのかな？

数学100点大天才でお馴染みﾐﾈｵ大先生です

ここの人は、IQが低いのか、いつまで経ってもRustの本質を理解できず、銀の弾丸だと思い込んでいる。

それに、懇切丁寧に説明する義務も無いので説明したくない。

多くの人には数学的な才能がないので、数学的な対応関係とかを一瞬で想起する能力がない。
だから、正しいことを自分では思いつけなかったり、人が言っても即座には理解できない。
正しい理解に達するのにめちゃくちゃ時間がかかり、過去の例だと、15年かかる。

現実的には誰もRustなんか使ってないんだからそんなに心配しなくて大丈夫

素人すぎてGUIのパーツを色々なところで呼び出すときに所有権周りが大変そう

米国防総省DARPA、C言語のコードからRustへの自動変換実現を目指す「TRACTOR」プログラム開始
https://www.publickey1.jp/blog/24/darpacrusttractor.html

JSONパーサーがC++からRustになった「Google Chrome 128」
https://forest.watch.impress.co.jp/docs/news/1617607.html

unsafe {}

>>252
ね？防衛省は？こういうのやらないの？

中國に外注してるんだろ

世界の警察を米から日本に委譲されたらそういう予算も出てくるやろなあ
そもそも今更トランスレーターなんか誰が使うのやら

いみふ

Cでシンプルなアルゴリズムで作ってAIにグチャグチャのRustに変換して安全安心ってことだろ

となりの芝生は碧いってことだな

トーバルズ氏、「Linux」カーネル開発状況、「Rust」導入、AIを語る
https://japan.zdnet.com/article/35223295/

LinuxへのRust言語の導入の話になると、Torvalds氏は採用のペースが上がらないことに失望感を示した。「更新が思ったほど速く進んでいないが、問題の一端は、昔からのカーネル開発者が『C』に慣れていて、Rustを知らないことにある。彼らは、ある面で大きく異なる新しい言語を学ばなければならないことを、あまり歓迎していない。そのため、Rustに関しては多少の反発がある」

それに加えて、「Rustインフラストラクチャー自体がそれほど安定していないことが、もう1つの理由だ」とTorvalds氏はコメントした。

誰かが「まんがでわかるやさしいRUST」でも書かないと駄目だな

C経験しかない老人で戦うしかないとか地獄かな

まぁここでの反応そのまんまだな
業務命令で強制でもされない限り
Cで書ける人は学習コストを払う価値が
見いだせないだろう

「新しい」と「古い」という構図に持ち込んだら、反論しにくくなるから楽だよね。
ずるい手法だ。
同様に議論の余地を与えないものとして、優秀な人、頭の良い人にしか理解できない、
という構造もある。「難しい」から馬鹿には理解できないだけだ、とね。

アメリカ人が良く使う経営手法として「セキュリティー商法」というものがあるが、
人間は安全面を指摘されると従わざるを得なくなる、というものだ。
それも、Rustは使っている。典型的な経営手法を全て使っていると言える。

新しいものを拒否するようになったら、老害PGとなった証拠
引退の時間だ

さっさと失敗だったRustを諦めて次へ行くべきだよなあ

もっと失敗を出し尽くさないとまた失敗するだろ

勉強中の素人の意見を書いていく
C++はバージョンがわからん
Rustはクレートがわからん

Poetry

そんなの自己肯定感に決まってるでしょ
Scalaが一部で流行ったのは、Javaというクソドカタ言語を使うコンプレックスを避けつつ同プラットフォームの恩恵にあずかれるために他ならず、
本質的には関数型云々はどうでもいいんだよ
素直な気持ちで自分のハートにも聞いてみたらいい
そして今Scalaは社会から全力で否定されているわけで、そのようなユーザーが離れていくのは当然なの

人に話しかける口調のヒトリゴトって怖いね

https://japan.zdnet.com/article/35224062/

LinuxカーネルへのRustの統合は、物議を醸しているとしても、注目の話題であり続けている。先頃、Microsoftのソフトウェアエンジニアで、「Rust for Linux」のメンテナーの1人でもあるWedson Filho氏が、同プロジェクトを離れる意向を「Linux Kernel Mailing List」(LKML)への投稿で表明した。同氏はその理由について次のように書いている。「以前は、技術に関係ない無意味なことに対応するエネルギーと熱意があったが、約4年が過ぎて、それを失ったことに気づいた。今もそれを持っている人に任せるのが一番だ」

同氏は何を言っているのだろうか。Linuxカーネル界隈には、Rustと一切関わりを持ちたくない開発者やメンテナーもおり、同プログラミング言語はすでに失敗しているとの意見を遠慮なく表明している。

議論をいとわないTorvalds氏でさえ、「中には険悪な議論もある。なぜRustがこれほど論争の的になっているのか、よく分からない。自分が若かった頃を思い出す。『vi』派と『Emacs』派が言い争っていた。どういうわけか、Rust対『C』の論争は、特定の領域において、ほとんど宗教のような意味合いを帯びている」と語った。

>>274
Linusだってさんざん中指立ててきたのに、何言っているんだ？

もしも Rust MIR の仕様が安定化される未来が来たら、他の言語にもライフタイム注釈拡張を定義して borrowck の仕組みが輸出されたりすることもあるのかな

>>274
Rustがクソってわかるのに4年も掛ったのかよ

>>275
Nvidiaにしか立ててないだろ

Rustの宗教臭さは特定の強い思想を持つ団体が提供した実装1個しかないからやね
ANSIやISOやらで標準化して各企業内で実装して揉まれてない言語は使わん方が賢いで

あのスレでなんか布教活動やってるのは約一名なので……

>>280
Hideyuki Tanaka ？

>>281
もしかして↓もお前？
こういうの普通に迷惑だし場合によっては失礼だしやめたほうがいいよ

https://mevius.5ch.net/test/read.cgi/tech/1542002113/928
928: デフォルトの名無しさん sage 2024/08/23(金) 00:25:52.73 ID:Vi8prHau
はちみつ先生の中の人ってエピステーメー氏じゃないですか。

消すと増える法則

何も増えてないぞ

最近は消えてばっかの印象しかない
特に動画関係

>>274
嘆かわしいことだ
C言語教は排他的だ

Rust民の一部が、Cの侮辱に走ったからねえ

そういえばlinuxカーネルにD言語という話は出なかったのかな

C++は侮辱して良いけどCは侮れない

侮れないのはC言語の熟練プログラマであってC自体は思うさま罵倒してもよい

>>290
ABIが絡む問題だとC以上に成功してる言語は無いと思う
C++開発者やRust開発者でも、自作ライブラリを他の言語から呼べるようにしたければ、基本的にCのAPIに頼ることになる
Cで実装する必要はないけどCの知識はあった方が良いし、これは暫く変わらないと思う

ワードサラダに何マジレスしてんの

Linuxカーネルのような分野ではなく、より高レベルのアプリ開発などだとC++とRustの受容ってどうなの？
現時点でC++の資産が大きいからC++を使い続けるところ、C++からRustに移行したところはあると思うけど、逆にRustを諦めてC++に戻ったというケースもあるのか

rustで仕事してからc++に戻るとあまりに汚いコードに愕然とする。
ライブラリの問題さえなければ全部Rustにしたいんだけどねぇ。

C -> C++ のときも、似たようなことを思ったよ
C++派だが、きっと、post Rust 世代のC++コードも、似たことになると思う

年数経ってるC++コードってifdef地獄になりがち

ScalやHaskellでも同じようなこと言ってた人が沢山いたけど
今はどこに行っちゃったんだろ

世のマイノリティはすべからく世代交代により引退し文字通り自然淘汰で消えていくと思われる
子供に数学がベースにあるだとか関数型を教えてもはぁ？って感じだろう
Rustもメモリ安全という売りが無ければ誰も見向きもしないだろう

Rustは関数型言語ではないし、HaskellやScalaの仲間ではないよ
関数型っぽいところもあるけど、参照やスマートポインタなど基本的なところは C++ の方が近い

C++との違いとして大きい (そして学習コストが高いと言われやすい) のは借用やライフタイムまわりだけど、これはメモリ安全のためのものであって関数型に由来するものではない

Rustの実績が安定したら、学ぶべきプログラミングパラダイムもはっきりする
C++が何を獲得すべきか、はっきりする日も近い

なんでもかんでもじゃだめだ 実績ベースでないと

>>299
リージョンベース推論はMLKit→Cyclone→Rustという系譜ではあるから一応これも関数型由来と言えなくもないよ
まあRustに取り込まれてから相当手が入ってるからもはや別物だろと言われても否定はできない

>>297
今でこそC#に近い速度出るようになったけど、
当時のHaskellはPythonとどっこいどっこいだったからね…。

今でも並行・並列処理は関数型言語が有利とは言われてるけど、正格評価の関数型言語だね。

Haskellは遅延評価が並行・並列処理の邪魔するから。
（なので、正格評価の方が良い場合のみ正格評価にしようという意見も出てた）

それでもHaskellは美しいから好き。

Scalaは…何か自爆した記憶がある。

>>302
当時っていつ頃?

マルチメディアライブラリ「FFmpeg」がアセンブリ言語の手書きで爆速になったという報告
94倍も処理速度が向上、新しいCPUほど効果あり
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1638345.html

あの行列演算命令みたいの? を手書きで使いこなせること自体シビレる
頭いいんだろうな

あとテストがしっかりしてるから、大胆にチャレンジできるんだろうか

>>303
Haskellが話題になった2006年頃。
学ぶべきプログラミング言語５選とかに選ばれたのと、
Perlの本家より速くHaskellでPerl6のインタプリタを作ったとかで話題になった。

それがきっかけでHaskell入門書が出始めた。

つーても、速度自体は２０年近くあんまり変わってなかったりする。
（コンパイル時間は短くなったり、再帰の時のスタック消費も減ったりそれなりの進化はあったが）
stackがまだサポートしてない最新版を入れてみたらC#並みの速度出てビビった。
(次のstack辺りで正式サポートされる？)

でもHaskellの最適化はもっとポテンシャルあるはず。
C++では参照透明性が確保出来ないから x = 2 * 3 = 6
みたいな単純な式しか定数に出来ないけど、
Haskellなら下みたいな関数も

mylist 3 4 = [[1,2,3,4],[5,6,7,8],[9,10,11,12]]

みたいに、引数を渡せばガンガン定数に出来るポテンシャルがある。
(コンパイルが終わった段階で計算時間０)

main = print.last.last $ mylist 3 4 -- ここが、main = print 12 になるポテンシャル。

mylist n m = take n.iterate f $ [1..m]
where f = map (+m)

ずっと待ってるけど、やっぱりそんな最適化を組み込むのは難しいらしい。
参照透明性を最大限利用する日は遠い。

>>304
作り上げてるときは楽しいだろうな
でも、半年後や、一年後にメンテしなければならなくなったとき地獄ｗ

試行的なブランチだろうから書き捨てだろうね

>>307
Rustサイコー！！！

アメリカは自分が負けそうになると、
規制を作り、人為的な均衡状態を作る。
それが今回は「安全な言語の強制」。
これで排除されるのはC/C++のみであり、
他の言語は全く影響を受けない。

>アメリカは自分が負けそうになると
現時点でC++を一番多く使ってるのって大手ITの多いアメリカじゃないの？
アジア企業でC++が多くアメリカ企業ではRustが多いとでも言うなら別だけど
単にセキュリティリスクになり得るメモリバグを減らす努力をしろってだけの話だと思うが

>>310
アメリカに限らず、どこでもC/C++が最高の言語なんて思ってないから。他に代わりになる物が無かったから仕方なく使ってるだけで。rustが出てきた今、新規案件でC++使う必要もない。サーバー関連ならなおさら。

つうか、rustの難しいと言われてる部分の70%位はメモリ管理周りで、それはC++やってる人なら既にマスター済みの概念。残りはトレイトとか関数型の機能ぐらいで、両方使える様になるなんて簡単なのに、何をケチっているのやら。

Rustは机上の空論的。

C/C++で安全に描ける人はRustなんて不要
そのままC/C++使ってれば桶

>>313
>残りはトレイトとか関数型の機能ぐらいで
具体的にどの機能を指して”関数型の機能”と言ってるの？

Rustの関数型っぽさってごく一部だよ
enumやパターンマッチがあったり、OptionやResultに対してmap, flatmap操作ができたりするくらい
関数合成やカリー化は気軽にできない (Box<dyn Fn(A) -> B> のようなものが必要になる) し、関数型のやり方で書ける言語ではない

Rustはパフォーマンス重視だからってのもあると思う
関数を柔軟に組み合わせるにはヒープが必要で、メモリの管理をカッチリやるRustでそれを表現すると面倒というか

C++から来れば関数型らしさの強い言語だけど、関数型言語からすれば違うよね、という位置付けだと思う

欧米はトヨタを負かそうとしてよく自滅するよね
CO2ガーSDGsガーEVガーだとか
まあC/C++とは違ってトヨタは最高の自動車ではあるんだけどね

本当に技術力が有る人たちに任していてはC/C++は消えていかないから、
技術力が無いアメリカ政府が無理やり潰しにかかっており、市場をゆがめている。

>>319
昔はフルアセンブラでゲーム作ってたよ。C言語なんて割り込み処理も書けないし、最初は色んな縛りが多すぎて面倒だとも思ってたよ。
今アセンブラで組むか？と言われたらもうやらないよ。
C++も仕事で25年以上使ったよ。死ぬほどデバッグしてきたよ。で、今はもうrustでいいじゃんって思ってる。既に仕事で使っててメリットの方が多いからね。
そういう事よ。

巡り合わせの差はでかいな
職務でRust使ったヤツは抵抗感がもうないし、まだのヤツはじっくり研究する時間がある
俺は後者 C++から逃げたくない

組織人ならどんな言語でも使えるようになるしか無い
嫌ならフリーランスやるしか無い

>>322
使いこなせる言語の幅だと実際はこの真逆
“やるしか無い”というメンタリティではどちらでも見込みはないが

>>310
まあこれが真実だろうな

>>324
アメリカは規制大好き国家で、サウスウェスト航空も
初期のころ、州をまたぐ航路を禁止されてしまった。
恐らく他の航空会社を守るためだろう。

>>323
やれといわれたら、「しゃあない、いっちょやってやるかｗｗｗ」だぞ
やってみたいことが無数にあってだな 命じられるのはいいきっかけ

>>321
C++なんて俺が小学生の頃からあるし今更こんな古臭い言語使いたくない

別にいいぞ、異論は認める
C++ってのはなあ…

…俺の母ちゃんなんだ

The C++ is my mother's tongue.

騙されちゃダメ。Rustが流行りだと言ってるけど、実際使っている(使えてる)奴はそんなにいないって。
まだ様子見だね。どんな言語も最初は綺麗な言語だよ(30年以上前、C++もそう言われていた)。しかし、
よってたかって「ああしてほしい。こういう問題がある」と言った意見が寄せられて今の仕様に。それ
でもまだいい方にまとまっている。さて、Rustはどうなるんでしょう？

MSがVisual Rust++を出してからが本番

>>331
ありそうｗ

>>331
その前にMSが傾いてそう。

EchoAPIは大きな変革をもたらし、APIのデバッグを迅速に行って、スムーズなユーザー体験の構築に集中できるようになる！

MSが一番仕様汚す真犯人では

まあでもヘジルスバーグがどう手を入れるか見てみたい
delphiやc#やtypescriptに影響与えたからな

Visual R＃が出て
Rustが終わるのでは

.NETと接続するための Rust/CLI かもしれない

C++/CLI並に何でもできるが面倒すぎるものだったら使いたいな。

>>337
統計解析が得意そう

小倉智昭さんRIP、ここの住人ならパソコンサンデーみてたよな？

懐かしす
朝生と同じテーマ曲だったよね？

EchoAPIはAPIの問題を迅速にデバッグするのに役立ち、安心して次に進むことができるよ

サイコパスの脳の違いを発見。一般の人に比べ線条体が大きいことが判明
karapaia.com/archives/52313287.html

>>344
でも、本人が性格悪い人に限って、他の人の事をサイコパスと言っていたりするんだよなぁ。

>>344
ずるいことばかり考えてるから後天的に線条体が発達したかも知れないな

南無南無
https://www.youtube.com/watch?v=f6R4T7bYG9k

Rust、zulipに参加してみたけど
あんま活発じゃないのかな、、、

なぜ日本語? Ruatで話すべきでは?

LinuxカーネルのメンテナがRustコードを混ぜることを「癌」と呼び、開発者間の対立が激化中
https://techfeed.io/entries/67a52d4677bdbc0f2990eed9

RustをLinuxカーネルに導入したい勢力と、C言語主体の開発体制を維持するメンテナとの対立が顕在化し、現在激しさを増している。

Rust勢の怠慢なんだよね
C to Rust を実用化して、一気にpure Rust Linux をフォークすればいいんだよ
みんなそっちに来るはずだろ
C to Rust の成熟・信頼獲得の機会にすべきまである

>>350
このスレと同じ予想できる展開w
Rustは補助輪みたいなもんだ
Rustユーザ「補助輪あると誰が乗っても原理的にコケないよ」
Cユーザ「俺は補助輪なくてもコケない! 補助輪うざい!」

「いつの話だ。Cにも補助輪ついてる」って、はやくなってほしい

Asahi Linuxのリードデベロッパがアップストリームメンテナーを辞任⁠⁠、背景に“C vs. Rust”対立に端を発したブリゲーディング
https://gihyo.jp/article/2025/02/daily-linux-250213

おまえホントLinuxゴシップ好きやな

Rustは開発や拡張には向いていないんよ
固まったコードを描き換えて聖書するには向いてるのは判る

>>353
AIが補助輪になったよ

AIに監査させました、で投資家が納得するかだな

Rustのsafeとの相互運用が完全にできればいい

>>358
Rustは何が監査してるの？

コンパイラ

ついにC/C++が復活の狼煙を上げる

新たなC言語拡張コンパイラ「TrapC」が発表 — ガベージコレクトなしでメモリ安全なC/C++を目指す
https://techfeed.io/entries/67c4d3a9bb060d7fb550d283
Safe C++ Extensions の提案：複雑化する開発エコシステムの強化が目的
https://iototsecnews.jp/2024/09/18/the-safe-c-extensions-proposal-strengthening-security-in-a-complex-ecosystem/

C++陣営を本気にさせただけでもRustの存在意義があったな

しゃあないなあ、と重い腰を上げ…かけたところｗｗ

はよ進化しろ
仕事で使えと言われたらRustでもなんでも使うけど、墓までもっていく言語はC/C++に決めてるんだ

定期的に後継言語来るし普及するの?
Rust以外雑魚

C++に未来は無い
C->C++がそもそも間違った進化なのでC++を治してももう手遅れ
C->C++じゃない何かに進化する必要がある
それはC->Rustかも知れないしC->Nimかも知れないしC->Zigかも知れないし
C->別の何かかも知れない
C++の進化はもう要らない

>>365
願望塗れで意味の無い主張ですなぁ。

X(旧 twitter)で、C++ というキーワードが検索できないんだけど、
俺の環境だけなのか、一般的に他の人の環境でもそうなって
いるのかどっち？

検索出来るけど、Cで始まる言語と軍用機まで色々かかるな

そもそもRustはC++から互換性を取り除いたものでは

Rustはいずれ無くなるのでは？
PascalやBasicのように

C使うなって米国の役所が言ってるからな

C++が上手いこと安全で高速な限定言語作ればいいけど、今の標準委員会はそんなこと考えてなさそうだからなぁ。

開いたパンドラの箱の底には希望が残されているという

C++は規格を刷新してC+++にでもしないと未来はない

C#はC++++なんだよなー一応

C+-0で

>>375
それはコンパイルできない

++C++

operator overheat🔥

「Google Chrome」のフォント処理がC/C++言語からRust言語に
「FreeType」からの移行でメモリ安全性を改善、脆弱性が出にくいライブラリに
https://forest.watch.impress.co.jp/docs/news/1672186.html

先にfirefoxをどうにかしろよｗ