C vs C++ vs Rust Part.3

**デフォルトの名無しさん** · 2022/01/27(木) 22:19:47.56

闘え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/
C vs C++ vs Rust Part.2
https://mevius.5ch.net/test/read.cgi/tech/1639539350/

**デフォルトの名無しさん** · 2022/02/20(日) 12:53:50.15

>>249
組み込みはrust向きなとこなんじゃないのかね。組み込み業界のことは一切知らんからアレだけど。

**デフォルトの名無しさん** · 2022/02/20(日) 13:19:37.41

Rustが組込向きかどうかはともかく、LinusはC++に対してはCの問題を何一つ解決せず、事態を悪化させるだけと言っていて、Rustについてはドライバを書けるようにするところまでは実際にやってきているらしいよ

**デフォルトの名無しさん** · 2022/02/20(日) 13:40:02.09

>>249
組み込み以外にミドルウェアらへんでも使われるようになると思う
OS、RDBMS、Webサーバとか

ミドルウェアよりも上位レイヤーのアプリケーションだけで見ると、GCがある言語でもだいたい十分そうだし、Rustは目立たなそう

**デフォルトの名無しさん** · 2022/02/20(日) 13:49:36.22

rustはc++よりbetter cしてるから徐々に市民権得るだろうな

**デフォルトの名無しさん** · 2022/02/20(日) 14:01:22.11

>>251
> 他社のウエブサービスより圧倒的に早くセキュアなのはずばりRustをつかってるから。
おお、なるほど

> その前はLispを使ってた。
ズコーッw

作り話はもっとうまく作れ

**デフォルトの名無しさん** · 2022/02/20(日) 14:21:18.20

Rustってクロージャの再代入できない？
null許容することになるから出来ないようにしてる？

**デフォルトの名無しさん** · 2022/02/20(日) 14:31:26.55

型が同じなら再代入可能だけどクロージャはそれぞれ別の型を持つので単純には代入どきない
Box<dyn Fn()>などに変換すればできる

**デフォルトの名無しさん** · 2022/02/20(日) 16:38:17.59

>>249
ゲーム系のWASMとか

**デフォルトの名無しさん** · 2022/02/20(日) 18:49:49.78

>>260
ふーんそうなの
Box調べてみるわ

**デフォルトの名無しさん** · 2022/02/20(日) 19:16:43.92

Lispってセキュアなコード書くのPythonより難しくないか

**デフォルトの名無しさん** · 2022/02/20(日) 22:26:50.09

こちらのまわりではスクリプト言語で書かれていた物の高速化でRustへ移行が多いな
レスポンスの意味での高速化もあればリソースとしてのCPUタイム激減もある
使用メモリも激減するためクラウドでもオンプレでも費用支出が激減し桁が変わる場合もある

**デフォルトの名無しさん** · 2022/02/21(月) 08:03:12.70

>>255
さすがにc++03とかと比較されても……

**デフォルトの名無しさん** · 2022/02/21(月) 08:27:27.48

よく知らんのだけど、カーネル書くのに抽象化って必要なの？
もしいらないんだとしたらC++がカーネル書くのになんのメリットもないと考える気持ちもわかる気がする
Rustの場合は安全性がついてくるので抽象化がなくても使う価値がある

**デフォルトの名無しさん** · 2022/02/21(月) 08:42:47.98

Rustのオブジェクトシステムって実際C++のそれと比べたら遥かにわかりやすいよな
traitって概念ほんまありがてえわ

**デフォルトの名無しさん** · 2022/02/21(月) 08:51:29.17

>>265
元ネタはコレ
https://developers.slashdot.org/story/21/04/17/009241/linus-torvalds-says-rust-closer-for-linux-kernel-development-calls-c-a-crap-language

**デフォルトの名無しさん** · 2022/02/21(月) 08:57:14.48

>>266
パッと思い浮かぶのはファイルシステムと仮想ボリュームぐらいだけど、C++がメリットになるとは思えんな

**デフォルトの名無しさん** · 2022/02/21(月) 12:01:24.19

>>264
DiscordがGoで作られてたバックエンドの一部をRustで書き直したらめちゃくちゃコスト下がったってニュースあったな
C++がRustに置き換わるってよりスクリプト言語やGC言語で作られたものが置き換わっていくのがまず先だろう

**デフォルトの名無しさん** · 2022/02/21(月) 12:15:00.96

どうでもいいけど、このスレ個人の思い込みと間違いだらけに見えるな

**デフォルトの名無しさん** · 2022/02/21(月) 12:25:54.59

>>270
それは今でも粛々と置き換わってるだろう
Rustが使われるのは、スクリプトやGC言語ではパフォーマンスなどが得られない分野なんだろうと思う

**デフォルトの名無しさん** · 2022/02/21(月) 12:29:39.29

DiscordがRustに移行した当時のGoは大分ウンコだったけど、今ではわりとマシになっちゃったよ

**デフォルトの名無しさん** · 2022/02/21(月) 12:50:01.46

Goってもうジェネリック入った？

**デフォルトの名無しさん** · 2022/02/21(月) 12:51:46.86

>>271
隔離スレに多くを求めすぎ

**デフォルトの名無しさん** · 2022/02/21(月) 13:09:04.30

なんでこうなっちゃったんだろうね。一部の馬鹿が日本をどんどんダメにしてる気がする。もっとちゃんと比較できるよう上手く使えばいいのに。

**デフォルトの名無しさん** · 2022/02/21(月) 13:20:49.36

>>274
ああ、おれが言いたかったのはGCの停止時間がマシになったよ、ってことだけだよ
言語機能は大して変わってない
でもGenericsは今月中のリリースが予定されてる1.18に載るはず

**デフォルトの名無しさん** · 2022/02/21(月) 13:41:53.53

昔マイコンBASICって雑誌があってだな

**デフォルトの名無しさん** · 2022/02/21(月) 14:41:23.11

GCがある言語のパフォーマンスが悪いというのは思い込み

**デフォルトの名無しさん** · 2022/02/21(月) 15:52:49.19

>>279
トータルのパフォーマンスが問題じゃないんだ、予期せず処理が詰まったり急に負荷があがったりするのが問題なんだ。
まぁ今時のGCはストップザワールドは起きないだろうけど。

**デフォルトの名無しさん** · 2022/02/21(月) 17:02:58.71

>>280
GCが動いて困る場合は、現状でもC++かCなどで実装されているはず
なので、パフォーマンスを向上させる目的でGCあり言語をRustで置き換えるというのは、あまりないと思われる

**デフォルトの名無しさん** · 2022/02/21(月) 17:03:00.28

>>278
俺はIO派。その前は月間マイコン。

**デフォルトの名無しさん** · 2022/02/21(月) 17:06:01.87

>>281
あるよ。いま、うちがやってる移植プロジェクトはその案件。
他社がそんな考えだから今の所引く手あまた。一社独占。大阪にもう１社あるってうわさだけど。。。
客が数十件待ってる状態。年収軽く３本いくわｗ

**デフォルトの名無しさん** · 2022/02/21(月) 17:10:20.58

まぁ、GCの弊害がわからず採用して実稼働に入って困ったような技術要素選定バグの場合は、言語置き換え対象としてRustが選ばれるケースはあると思う

**デフォルトの名無しさん** · 2022/02/21(月) 17:12:56.49

>>283
GCの問題じゃなくてパフォーマンスの問題でリプレースなの？
元言語何？

**デフォルトの名無しさん** · 2022/02/21(月) 17:16:52.14

年収3本って3000万ってことか？
内容から、フリーランスでRustへのリプレースを専門でやってる感じだが、個人特定されかねないぞw

**デフォルトの名無しさん** · 2022/02/21(月) 17:17:29.45

>>283
レアだから現在のcobolみたいなもんか

**デフォルトの名無しさん** · 2022/02/21(月) 17:18:15.19

聞いてもない年収語るような奴の相手すんなよ…

**デフォルトの名無しさん** · 2022/02/21(月) 17:46:13.57

Rustに置き換える理由はパフォーマンスより保守性とか堅牢性だと思う
開発者が少ない現状だと単純に保守性向上のためだけに外注するようなケースは少なそうだけど
今のシステムが不安定で改修もままならないからRustで作り直すってケースなら結構ありそう

**デフォルトの名無しさん** · 2022/02/21(月) 17:56:15.16

トヨタなんかの車載システムはCとRustで開発してるとか聞いたことあるが

**デフォルトの名無しさん** · 2022/02/21(月) 17:58:36.91

車でストップザワールドはまずいわな

**デフォルトの名無しさん** · 2022/02/21(月) 18:02:07.18

>>281
今までGCありスクリプト言語をRustへ置き換えたり置き換えつつある
GCの有無は条件ではないのだけど速さ省メモリに安全性と書きやすさ等でRustとなった

**デフォルトの名無しさん** · 2022/02/21(月) 18:07:56.53

9割嘘

**デフォルトの名無しさん** · 2022/02/21(月) 18:30:22.78

>>284
サービスの立ち上げ期にGC影響も見越してカリカリにチューニングするってのは早すぎる最適化なんじゃないのかね
rustで他の言語と同じくらいの早さでサービス作れる人材がそろってるなら良いが

**デフォルトの名無しさん** · 2022/02/21(月) 18:32:07.53

スクリプトからの置き換えとして、VMを配布したくない（JVM/.NETが除外）、それなりに言語機能が欲しい（Goが除外）となるとRustくらいしか残らんのだよな
逆にそれらを許容できるなら別にRustじゃなくていいんだが

**デフォルトの名無しさん** · 2022/02/21(月) 18:34:26.10

Firefoxがいまだに勝てないのに速さとか言われてもな、省メモリならEdgeだし、自分たちがしたいだけでしょ

**デフォルトの名無しさん** · 2022/02/21(月) 18:43:26.39

VMとかgoとかスレ違い
なんでC/C++/RustでGCとか出てきてんだよ
ム板ならGCの話をするならスレ立てて簡易実装くらい出して、有無の差異、モデルの差異、各言語の比較をしてほしい
前提の違う話を複数絡めて盛りすぎ
※明らかな嘘は論外

**デフォルトの名無しさん** · 2022/02/21(月) 18:50:49.00

うちはNode.jsからの移行先がRustになった
JavaScriptよりプログラミングしやすくなった

**デフォルトの名無しさん** · 2022/02/21(月) 22:12:40.35

C vs C++ vs RustなんてRust圧勝で勝負ついてるんだから話すことなくない？

**デフォルトの名無しさん** · 2022/02/21(月) 22:17:05.24

だったら黙ってれば？

**デフォルトの名無しさん** · 2022/02/22(火) 00:25:06.07

>>300
なんだよ偉そうに

**デフォルトの名無しさん** · 2022/02/22(火) 07:36:54.62

>>299
言語機能としては圧勝なんだが、人やソフトなどの開発環境が惨敗だから困るんだよな

**デフォルトの名無しさん** · 2022/02/22(火) 09:09:32.46

>>302
今一人勝ちのJavaだってそうなるまでに20年かかったんだから今判断しても意味なくね？

**デフォルトの名無しさん** · 2022/02/22(火) 10:17:05.86

>>258
Lispとかいたらズコーってされたけど適材適所だと思うぞ
ルンバがLispで書かれているのは知ってるよね？
強力なメタプログラミング機能とインタラクティブな開発が必要なら採用してみてもいいのでは？

**デフォルトの名無しさん** · 2022/02/22(火) 10:34:56.38

>>304
セキュアなWebサービスはどうしたんだよw

**デフォルトの名無しさん** · 2022/02/22(火) 11:24:36.79

rustに置き換えようとして担当が逃げ出したプロジェクトがかなりあるわ。。これからその地獄がはじまる。

**デフォルトの名無しさん** · 2022/02/22(火) 11:47:19.90

>>306
うちにもってきてよ。やってあげる。

**デフォルトの名無しさん** · 2022/02/22(火) 12:20:08.49

どうしたらLispでセキュアなwebサービス作れるん

**デフォルトの名無しさん** · 2022/02/22(火) 12:37:25.61

>>308
作れないからRustにしたんだよ

**デフォルトの名無しさん** · 2022/02/22(火) 12:41:08.18

Lispだろうと多言語だろうと新しめの通信とかSSLとかのライブラリを探すとこからスタートじゃない？

**デフォルトの名無しさん** · 2022/02/22(火) 13:10:26.52

Javaは言語登場から10年くらいで多くの人が利用してたし開発環境も続々でとような。

**デフォルトの名無しさん** · 2022/02/22(火) 13:12:29.23

明らかな嘘だけになったなｗ

**デフォルトの名無しさん** · 2022/02/22(火) 13:38:49.42

>>307
好きなの、残らず持ってってええぞ
ttps://jp.indeed.com/Rust%E9%96%A2%E9%80%A3%E3%81%AE%E6%B1%82%E4%BA%BA

**デフォルトの名無しさん** · 2022/02/22(火) 21:22:01.94

>>306
置き換え元のコードが酷かったんじゃね。C++のコードとかだいたい酷いし。

**デフォルトの名無しさん** · 2022/02/22(火) 21:38:20.03

現役プロダクトのコードを別言語に置き換えるのってrustに限らず大変なのでは
全面的な置き換えはプロダクト全体の再開発に等しい
特定の担当に押しつけるのではなくチーム全体で徐々に新規部分から置き換えた方が成功率高そう

**デフォルトの名無しさん** · 2022/02/22(火) 21:54:32.13

>>314
> C++のコードとかだいたい酷いし。

×だいたい酷い
○すべてが酷い
◎すべてがゲロ以下に酷い

**デフォルトの名無しさん** · 2022/02/22(火) 21:55:58.40

一般的にコードを『置き換える』という気構えだと失敗
少なくとも移植先の言語に合わせて何らかの内部設計のし直しからが最低限のスタート
目的が効率アップにあるなら並行や並列が設計として入ってくるだろうし
目的がGC無くしてメモリ省力化だけであってもデータ構造の見直しは必須など

**デフォルトの名無しさん** · 2022/02/22(火) 22:33:06.33

ねえねえ
ベクタの特定のターゲットの添え字を返すfind(v, target)を作ったとして、
ターゲットが見つからなかった場合のエラー処理はどうするのが良いと思う？
C/C++だと返り値を整数にして-1だったら見つからなかった、と言う感じが多いと思うんだけど
Result<usize, &str>とかにしてエラー内容を表す文字列を返しちゃう？

**デフォルトの名無しさん** · 2022/02/22(火) 22:36:39.92

>>318
標準ライブラリの関数を使う

**デフォルトの名無しさん** · 2022/02/22(火) 23:06:43.66

>>318
まずRustではそういうのはベクタに対して実装せずにスライスに対して実装する
次にRustではそういったものにはResultではなくOptionを返す
最後にそのような機能は標準ライブラリを使えば色んな意味で間違いがない

**デフォルトの名無しさん** · 2022/02/23(水) 00:15:24.41

>>319
>>318
あ～Optionなんてのがあるのね・・・

**デフォルトの名無しさん** · 2022/02/23(水) 09:54:11.97

usize, &strってすでにRustだろ
https://doc.rust-lang.org/std/string/struct.String.html#method.find
https://cpprefjp.github.io/reference/string/basic_string/find.html
どうでもいい

**デフォルトの名無しさん** · 2022/02/23(水) 10:10:32.07

>>98
しかしC言語技術者は求人市場では圧倒的に不足していると言われてる
どこにいるんだか

**デフォルトの名無しさん** · 2022/02/23(水) 12:37:36.24

「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」とMiller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
https://news.yahoo.co.jp/articles/399e10841c9a9b776ac5ac3e8402f75da93d17ef

**デフォルトの名無しさん** · 2022/02/23(水) 12:44:28.80

>>324
同記事の引用
『プログラムをRustで書き換えることで、サービスは10倍速くなり、レイテンシーも大幅に短縮された。サーバーの数を減らすことができたので、結果的にエネルギー消費量も減少した。

　「エネルギー効率の高い言語はRustだけではなく、昔からあるC言語もエネルギー効率は高い。しかしRustは安全性を犠牲にすることなく、省エネ化を実現した初めてのメインストリームのプログラミング言語だ。CやC++で書かれたプログラムが抱える深刻なセキュリティ脆弱性の70％は、メモリー安全性の問題に起因している。それに対して、Rustは安全性の問題を抱えていると感じることなく、エネルギー効率を高められる」とMiller氏は言う。

　しかし、Rustにも習得の難しさをはじめとする課題はある。

　経験豊富なエンジニアでも、Rustを使いこなすまでには、この分野に詳しい専門家のサポートを受けながら、3～6カ月の学習期間が必要だとMiller氏とLerche氏は言う。「Rustの習得を、野菜嫌いの克服に例えるエンジニアもいる。使いこなせるようになれば好きになる人が多いが、多くのエンジニアはそうなる前に見切りをつけたり、あきらめたりする。Rustは持続可能性とセキュリティに影響する可能性があるが、その力を発揮するためにはまず、ブロッコリーをブラウニーに変えなければならない』

**デフォルトの名無しさん** · 2022/02/23(水) 14:27:22.03

コンピューターのエネルギー効率が高い代わりに人間の効率が下がるんですがそれは

**デフォルトの名無しさん** · 2022/02/23(水) 14:41:11.80

コンパイル時にめっちゃエネルギー使ってる
Tier 1のプラットフォームの最新数バージョンくらいはバイナリ配布する仕組みがcargoに必要

**デフォルトの名無しさん** · 2022/02/23(水) 14:42:22.66

>>326
まぁ作ったあとの稼働と運用考えたら総じてプラスになるでしょ。ならない？

**デフォルトの名無しさん** · 2022/02/23(水) 15:38:19.82

>>326
一定規模超えたら一気に効率上がるぞ

**デフォルトの名無しさん** · 2022/02/23(水) 16:55:23.95

>>326
これよく言われるけど言語による生産性の差って定量的にデータ集められてるのかな

**デフォルトの名無しさん** · 2022/02/23(水) 17:27:51.83

メンテナンスフェーズに入ったとしても、人件費より電気代の方が高くなるようなことってなかなかなくね？
そんな大成功を納めたサービスってどれくらいあるんだろうな

**デフォルトの名無しさん** · 2022/02/23(水) 17:29:51.77

>>329
そうそう。
昔はJavaでやろうとしても人材不足でリプレースできなかったけど今は余裕で集められるもんな

**デフォルトの名無しさん** · 2022/02/23(水) 17:41:24.45

>>331
それはユーザー数によるとしか
めちゃくちゃ大量のメッセージを捌きまくらないといけないサービスの場合はほんのちょっとしたパフォーマンス改善でも物凄くコスト下がったりするし

**デフォルトの名無しさん** · 2022/02/23(水) 17:45:28.95

>>333
ユーザー数によることはわかってて、そんな事態がどれくらいあるのかと言ってるレスに対してユーザー数によることを指摘するのか……

**デフォルトの名無しさん** · 2022/02/23(水) 18:24:51.09

世の中ウェブサービスだけじゃない

例えば携帯電話のベースバンドチップの消費電力が
半減とかできて表のニュースにはならないし

**デフォルトの名無しさん** · 2022/02/23(水) 18:29:47.83

>>328
ただ作った後の効率に対してプログラマーは報酬を貰えないからな
作った後の効率がいいから、作る費用が上がっても構わないという判断をしてくれるかどうか

**デフォルトの名無しさん** · 2022/02/23(水) 18:46:55.85

Ruby などは可読性が高いから、保守できる。
C/C++ は10年やっても、Ruby on Rails を1年勉強した人にも勝てない

経験は、10年とか時間じゃなく、内容。
例えば10年の内、ポインターに9年使ったとか、人生の無駄

Railsでは、初心者の1年の内容が、
Docker, Linux, データベースなど、ほぼシステムとサービス内容

例えば、Homebrew もRuby製。Cに置き換えるのに、10年掛かった。
SASS もRuby製。C++に置き換えるのに、数年掛かった。
最近では保守できずに、Dart製に変わった

Rubyの女神・池澤あやかが、Ruby以外で開発者を募集しても集まらないから、
結局、Railsで作る事になったと言ってた

最近は、宇宙開発などの組み込み用でも、mruby を使う。
人工衛星イザナギ・イザナミで使っている。
Cで可読性が悪い、文字列処理の部分などを、mrubyで書く

本も出た

Webで使えるmrubyシステムプログラミング入門、近藤宇智朗、2020/11

宇宙開発などの組み込み用、MicroPython, Lua, Squirrel の代替になる。
Ubuntu 18.04, C99 対応

**デフォルトの名無しさん** · 2022/02/23(水) 18:51:10.94

>>325で明らかにサービスの話してるのに突然携帯のチップとか言い始める奴ｗ

**デフォルトの名無しさん** · 2022/02/23(水) 19:57:40.25

Rubyしかやってないやつのコード読みにくすぎて震える

**デフォルトの名無しさん** · 2022/02/23(水) 20:04:08.39

言語を1つしかわからんやつなんてそもそも初心者しかいなくね

**デフォルトの名無しさん** · 2022/02/23(水) 21:26:07.56

HomebrewがCに置き換わったってどこ情報？

**デフォルトの名無しさん** · 2022/02/23(水) 21:30:43.83

ポインタに9年使うってどういうこと

**デフォルトの名無しさん** · 2022/02/23(水) 21:40:29.46

>>326
C C++ Rust全て経験しているとわかる
Rustはプログラミングの生産性も優れている
人間にとっても効率が良い言語

**デフォルトの名無しさん** · 2022/02/23(水) 21:41:50.11

rustの改善のしどころは無いのか？

**デフォルトの名無しさん** · 2022/02/23(水) 21:57:31.33

Rustは保守性も良いね
例えば機能追加や改善などで変更時もコンパイルが通ると安全性が崩れていないと保証される点
これは開発時もそうだがそれらの実行時の無駄なデバッグが不要となった点

**337** · 2022/02/23(水) 22:01:48.42

>>341
Homebrew
https://brew.sh/index_ja

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

install.sh だから、もうRuby スクリプトじゃない。
中を見ていないけど、C か何かのバイナリをインストールするのじゃないの？

よく知らないけど

**デフォルトの名無しさん** · 2022/02/23(水) 22:19:18.74

>>343
C C++と比べたら生産性高いのは同意するし、型まわりのお陰で言語仕様が生産性高くなりそうなのも同意するけど、やたらライブラリが充実しているスクリプト言語とかGoと比べるとまだ人間にとっての生産性では勝てなそう
この辺りのライブラリ生産する人間をGoに吸われている感じがあるのでサービスにRust使うのが本格化する日は来るんだろうかって感じ

**デフォルトの名無しさん** · 2022/02/23(水) 22:20:48.72

shellで書かれたインストールスクリプトも分からない男の人って・・・

**デフォルトの名無しさん** · 2022/02/23(水) 22:27:11.67

>install.sh だから、もうRuby スクリプトじゃない。
>中を見ていないけど、C か何かのバイナリをインストールするのじゃないの？

一文も理解出来んかったんだが……

**デフォルトの名無しさん** · 2022/02/23(水) 22:34:57.03

>>346
そうなんだ、すごいね！

**337** · 2022/02/23(水) 22:47:13.28

よく覚えてないけど、
ちょっと前は、Ruby スクリプトを実行するような感じだった

/bin/ruby -e "$(curl -fsSL URL～/install.rb)"

**デフォルトの名無しさん** · 2022/02/23(水) 22:56:55.36

>>351
昔のmacにはRubyが標準で入ってたけど、Rubyが同梱されなくなったから、RubyがなくてもインストールできるようにHomebrewのインストーラがBashで書き直されただけだよ
いまでもHomebrewの本体はRubyで実装されてる

**デフォルトの名無しさん** · 2022/02/23(水) 23:36:06.18

linuxも考慮されてるのかもね

**デフォルトの名無しさん** · 2022/02/23(水) 23:54:17.80

>>352
今はまだ同梱されてるよ
次の12.3からpythonだけ削除
rubyとperlは残ってる