22/01/27 22:19:47.56 avZQ9Wm7.net
闘え
※前スレ
C++ vs Rust
ｽﾚﾘﾝｸ(tech板)
C vs C++ vs Rust Part.2
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
22/01/27 22:28:23.63 4DQKoSsj.net
前スレまでのあらすじ
---
987 デフォルトの名無しさん sage 2022/01/27(木) 17:14:15.89 ID:hWkHkx2k
>>986
> だから専有機なら上限で用いる
「現在の主流」というのは、「専有機」での話？
それとも一般的な話？
994 デフォルトの名無しさん sage 2022/01/27(木) 17:52:30.63 ID:LojT3k5n
自分が理解できないと相手が敵かつ全て同一人物に見える病気のパターンかねｗ
皆普通に同じことを指している
何が理解できないのか素直に言ってごらん
995 デフォルトの名無しさん sage 2022/01/27(木) 17:55:13.00 ID:hWkHkx2k
>>994
>>987の質問に答えてから続けてね
3:デフォルトの名無しさん
22/01/27 22:58:22.92 37eem+FW.net
あらすじが全くわからんw
4:デフォルトの名無しさん
22/01/27 23:13:49.64 cK3g3Gve.net
彼はこの部分がわからなくて連投していたみたいだから横から補足説明しましょう
> 大雑把にI/O観点で二つに分けると
> 昔は同期I/Oでブロックされるからマルチスレッド
> 今は非同期プログラミングでスレッド数はシングルからCPUコア数が上限
> RustのFutureタスク、GoのGoルーチン、JavaScriptの非同期Promiseやコールバック
> いずれもプロセス内スケジューラがI/O多重化(select/epoll)やタイマーなど管理して非同期プログラミングを支えている
昔は自分でOSスレッドを立ち上げて使っていたのに対して
今は自分で立ち上げるのがOSスレッドではなくそれよりも粒度が細かく軽い非同期なタスクで
OSスレッドを立ち上げる役割はそれらタスクの非同期なスケジューリングをするランタイムで
そのスレッド立ち上げ個数は効率最大のためCPUコアスレッド総数と一致するのが望ましいため
GoやRustなどではデフォルト値がそうなっていますよってことですよね
もちろん個数を1個つまりシングルスレッドに設定しても動くところが決定的な違いですね
OSがスケジューリングしてくれるけど重くて大きくリソースを喰うOSスレッドを今は直接使わずに
> RustのFutureタスク、GoのGoルーチン、JavaScriptの非同期Promiseやコールバック
これらのもっと軽くて小さなタスクを使うことで何万も同時に処理できるようになったという話ですね
ちなみにRustでは昔と同じ状況にスレッドとタスクを1:1(=n:n)でも使えますし
シングルスレッドにして1:nでも使えますし上述の状況は汎用的なm:nになりますね
5:デフォルトの名無しさん
22/01/27 23:14:48.99 fMPJxSq8.net
明らかに間違ってることを自信ありげに語るのはいつものこと
その人達用の隔離スレだから
>>1乙
6:デフォルトの名無しさん
22/01/27 23:25:15.10 iujD8pk9.net
横から？w
本人だろ、お前w
7:デフォルトの名無しさん
22/01/27 23:31:40.86 m/Awlcjw.net
複製おじさんのいつもの自演です
8:デフォルトの名無しさん
22/01/27 23:34:30.76 iujD8pk9.net
次はgoogleで2件しかヒットしない、「プロセス内スケジューラ」については説明してくれw
9:デフォルトの名無しさん
22/01/27 23:49:40.45 cK3g3Gve.net
非同期タスク群のスケジューリングをするランタイム部分のことではないでしょうか
一般的にプロセスの中に1つだと各スレッドへタスクを割り振るコストが高くて
各スレッドの中に独立して1つずつだと暇なスレッドと多忙なスレッドが偏るデメリットがあり
GoでもRustでもそれらのスケジューリング問題を改善するために
各スレッド内に独立キューを持って効率的に処理しつつもグローバルキューも備えることで解決しているようですね
10:デフォルトの名無しさん
22/01/28 00:05:15.17 EpTP27or.net
複製おじはGoでもRustでもまともに非同期プログラミングやったことないんだな
11:デフォルトの名無しさん
22/01/28 00:14:38.44 9bCXgVDe.net
>>8
OSスレッドがOSによりスケジューリングされることに対する対比じゃね？
タスクは各プロセスの中にスケジューラーがある
Goは言語ランタイムの中だがRustは各自が好きなのを選んだり自作も可能
12:デフォルトの名無しさん
22/01/28 01:31:02.15 DUuAybqk.net
どうせRustは普及しないんじゃないかな、知らんけど。
13:デフォルトの名無しさん
22/01/28 08:21:58.40 OuJICsLX.net
rustはc++を食うことがあってもピュアcを食うことはなさそう
14:デフォルトの名無しさん
22/01/28 08:42:08.00 3x0JFp6u.net
Cは誤解を恐れずに言えばアセンブリ言語みたいなもんだからな
15:デフォルトの名無しさん
22/01/28 13:14:51.22 7T77Q24K.net
>>13
C++ 98以前は Cと似てるし、ライブラリも言語とは無関係に自由に作れたから大丈夫。C++11以後はダメ言語になった。
16:デフォルトの名無しさん
22/01/28 13:17:06.82 7T77Q24K.net
そもそも、CやC++が普及したのはTurboCのおかげ。
TurboCはライブラリが分かり易かった。
C++11以後、言語もSTLも両方腐っていてTurboCとは全く違うようになり、
人気もがた落ちになった。
17:デフォルトの名無しさん
22/01/28 15:22:28.01 ePoQjqFg.net
何頓珍漢な事言ってんだこのバカ
18:デフォルトの名無しさん
22/01/28 18:58:54.57 9bCXgVDe.net
>>8
OSによるプロセスやOSスレッドのスケジューラではなく
プロセスの中で動くタスクのためのスケジューラ
各言語によって言語機能として備えている場合と外部ライブラリによる場合がある
Rustではその中間の形態で言語機能としてはasync/awaitの枠組みのみ提供
さらに標準ライブラリとしてFutureやWakerなどの必要とする定義のみ提供
実際に動作するスケジューラは外部ライブラリで様々な提供がなされ自作もできる
その他はこのスライドの前半の解説など参照
Rustのasync/awaitとスケジューラの話
URLﾘﾝｸ(speakerdeck.com)
19:デフォルトの名無しさん
22/01/28 21:04:45.07 zI6nuxFY.net
前スレ946の三つのサイトから数値を入手して和を求める例を練習のためにやってみたんだが
httpのheader取得までとbody取得の2回awaitが入るのがなるほどと思った
あと文字列を数値に変換parseも当然必要だったのでawait部分がちょっと長い
#[async_std::main]
async fn main() -> surf::Result<()> {
let n1 = surf::get("URLﾘﾝｸ(httpbin.org)); // 111
let n2 = surf::get("URLﾘﾝｸ(httpbin.org)); // 222
let n3 = surf::get("URLﾘﾝｸ(httpbin.org)); // 333
let sum = n1.await?.body_string().await?.parse::<i32>()?
+ n2.await?.body_string().await?.parse::<i32>()?
+ n3.await?.body_string().await?.parse::<i32>()?;
assert_eq!(666, sum);
Ok(())
}
利用させてもらったテストサイトはURLで返す値など指定できるhttpbin.org
これで動いて値取得もできて合計値assertも通ったのだが実は落とし穴があることに気付いた
20:デフォルトの名無しさん
22/01/28 21:49:38.11 YDzvJ7+G.net
元のJSのコードもだけど
await連発すんなよw
21:デフォルトの名無しさん
22/01/28 22:11:12.59 zI6nuxFY.net
そのテストサイトにhttp返答を遅延させるdelay機能があるので試した時に露見した
同時に指定値を返せないようなので数値化と足し算の意味はないが遅延時間を知りたかった
let d1 = surf::get("URLﾘﾝｸ(httpbin.org)); // 4秒
let d2 = surf::get("URLﾘﾝｸ(httpbin.org)); // 5秒
let d3 = surf::get("URLﾘﾝｸ(httpbin.org)); // 3秒
let sum = d1.await?.body_string().await?.parse::<i32>().unwrap_or(0)
+ d2.await?.body_string().await?.parse::<i32>().unwrap_or(0)
+ d3.await?.body_string().await?.parse::<i32>().unwrap_or(0);
結果は12秒かかってしまい期待と異なり直列に実行されていた
肝心なことを忘れていた
22:デフォルトの名無しさん
22/01/28 23:09:26.07 zI6nuxFY.net
JavaScriptではPromiseを返す関数を3つ呼べばそれで3つ並行に実行される
しかしRustでは並行に動くタスクを自分で明示的に起動しなければいけなかったのだ
よく考えればGoでも自分で明示的にgoと前置指定することで別goルーチンを起動している
Rustではそれがspawnでありgoと同じくそれによりスケジューラに登録されるようだ
use async_std::task::spawn;
let d1 = spawn(surf::get("URLﾘﾝｸ(httpbin.org))); // 4秒
let d2 = spawn(surf::get("URLﾘﾝｸ(httpbin.org))); // 5秒
let d3 = spawn(surf::get("URLﾘﾝｸ(httpbin.org))); // 3秒
このようにspawnを付けて以降は同じ実行をすると全体で結果5秒となり並行に実行された
言語自体に魔法の仕組みはなく自分で明示的にスケジューラに登録指定するのはわかりやすくて安心した
そのスケジューラも手作りできるらしく興味深い
23:デフォルトの名無しさん
22/01/28 23:23:01.28 JUEBwV02.net
自分でblock_on書かないとRustのasyncは身に付かない
24:デフォルトの名無しさん
22/01/28 23:49:49.26 zI6nuxFY.net
>>23
use async_std::task::{block_on, spawn};の時
このblock_onを使った
fn main() -> surf::Result<()> {
block_on(async {
let d1 = spawn(surf::get("URLﾘﾝｸ(httpbin.org)));
// 略
})
}
の簡略版が>>19で書いた
#[async_std::main]
async fn main() -> surf::Result<()> {
let d1 = spawn(surf::get("URLﾘﾝｸ(httpbin.org)));
// 略
}
ってことか
つまりasync { ... } という非同期ブロックをblock_onによりスケジューラに実行させているわけだ
当たり前だがspawnする以前に最初からスケジューラの掌の上で踊っていたのであった
じゃないと全体を並行に実行できないもんな
25:デフォルトの名無しさん
22/01/29 13:58:43.26 AW7V4mOd.net
Rustのasync/awaitはコンパイルされると単純なステートマシンになる
例えばasyncブロック内にfuture1.awaitとfuture2.awaitが順に呼び出されるとする
最初はfuture1をpollする状態でpending中はpendingを返す
そこでreadyになればfuture2をpollする状態へ遷移
そこでもreadyになれば全体としてreadyを返す状態へ遷移
結局スタックレスなコルーチンを実現しているだけなので非常に軽い
26:デフォルトの名無しさん
22/01/29 22:23:27.99 12259hRt.net
起動も切替もスレッドより軽くてリソースも喰わないなら
非同期タスクの欠点は何だ？
27:デフォルトの名無しさん
22/01/29 23:26:45.54 7irU+4ae.net
Rustの場合軽量タスクはプリエンプティブじゃないので、変なコーディングすると特定のタスクが実行され続けて、他のタスクがいつまでも実行されないことがある
あとは、OSのスレッドじゃないからスレッドの属性や権限をタスク単位で異なる物にすることはできないとか
28:デフォルトの名無しさん
22/01/29 23:44:38.93 AW7V4mOd.net
>>27
前者は間違えて同期ブロッキングする関数を呼んでブロックしてしまった場合
および長時間ずっと全く非同期関数を呼ばずに計算し続けるか暴走する場合
これらはバグならfixで解決
バグでないなら非同期タスク実行スレッドとは別に専用スレッドを用意して実行できるスケジューラもあるのでそれを利用
29:デフォルトの名無しさん
22/01/30 00:54:30.09 zeCbxF6p.net
>>28
同じ処理でも入力内容次第で変わるからそんな簡単にいかないよ
30:デフォルトの名無しさん
22/01/30 01:16:02.14 iWlFH2We.net
async-stdならgoみたいにタスクが一定時間経っても制御返してくれないときに勝手にスレッド起こしてくれるんじゃなかったっけ
31:デフォルトの名無しさん
22/01/30 18:58:15.77 9ei8l7Ku.net
>>29
入出力が行なわれたらタスクのスイッチングが発生するので
意図的にブロッキングするものを呼んでブロックしているケースを除くと
いつまでもタスクが切り替わらないのは演算のみを延々と続けるケースのみになる
対応策としては自分で定期的に手放すか以下の方法で回避
>>30
それは様々な問題点で中止
結局tokioもasync_stdもそのような特殊ケースはspawn()の代わりにspawn_blocking()することで
タスクのスイッチングに影響が出ないように別スレッドで実行させる方針
その場合は結局スレッドを自分で起動して同期ブロッキングで使う昔からの方法と実質同じだが
そのような特殊なケースも含めて統一的にタスクを扱える
32:デフォルトの名無しさん
22/01/30 20:50:10.05 dly2JmLT.net
>>31
延々と演算を続ける意図はなかったのに結果としてそうなる場合があるということ
それを最初から想定できてyieldを挟めるなら問題ないのだが現実はそうはなっていない
URLﾘﾝｸ(tokio.rs)
33:デフォルトの名無しさん
22/01/30 21:57:34.87 C4ZQL08k.net
そのbudget方式は戻ってこないとペナルティ与えられないから本質的な解決になっていない
yield相当をコンパイラが上手く挟むのも無理だからプログラマーが自らすればいい
34:デフォルトの名無しさん
22/01/30 22:13:02.89 46YJeJfB.net
歴史から学ばない人
35:デフォルトの名無しさん
22/01/31 00:52:40.26 wgfsi16C.net
歴史ってのがマルチタスクOSにおける cooperative vs preemptive の話だとするなら前提が違いすぎない？
任意のアプリケーションが動く可能性のあるOSと自身のプログラムのルーチンが実行されるアプリとではスケジューラに求められる制約条件は違って然るべきかと
36:デフォルトの名無しさん
22/01/31 07:30:22.38 qlFEomu1.net
シングルスレッドかつcooperativeなJavaScriptがNode.jsを含めて成功しているように問題なく動作する
同期ブロッキングを完全排除してしまえばタスク切り替えが起きない場合すなわちスケジューラに戻らない場合は
入出力もなくループでメモリ上演算を繰り返している場合となる
そのような場合でもループ内で自分で定期的にスケジューラへ制御を戻してやればよい
そのためにRustではtask::yield_now()がある
37:デフォルトの名無しさん
22/01/31 10:15:42.24 O/M0tTc6.net
イベントループがハングアップした時の対処とか考えたことないでしょ？
バグだからfixすればいいじゃ能がない
歴史に学ぶといいよ
38:デフォルトの名無しさん
22/01/31 10:24:59.23 qlFEomu1.net
>>37
GoやJavaScriptなどは言語内蔵だが問題が起きたことはない
Rustは言語から切り離されているが同様
いずれもそれらのランタイムの製作者以外がその部分のコードを触ることはなくバグが発生しようがない
39:デフォルトの名無しさん
22/01/31 10:27:00.53 /Hwves02.net
>>37
> イベントループがハングアップした時の対処とか考えたことないでしょ？
そういうのは上位で対処（タイムアウトでプロセス再起動とか）することもあるからケースバイケースでしかない
40:デフォルトの名無しさん
22/01/31 10:46:15.49 5QuAHu0k.net
イベントループがハングアップするってなに？
epoll_waitをブロッキングで使う場合でもタイムアウト設定すればハングアップなんてしないでしょ？
41:デフォルトの名無しさん
22/01/31 11:35:28.84 BNlzdeLS.net
タイムアウト設定忘れみたいなバグの話でしょ
そんなに引っ張る話でもないと思う
42:デフォルトの名無しさん
22/01/31 12:52:34.54 qlFEomu1.net
>>41
それは万が一あるとしても非同期スケジューラランタイム実装者の管轄
その利用者である一般プログラマーが引き起こすバグではないため関係ない
43:デフォルトの名無しさん
22/01/31 13:02:21.71 dnOSCP4X.net
> epoll_waitをブロッキングで使う場合でもタイムアウト設定すればハングアップなんてしないでしょ？
の話だぞ？
44:デフォルトの名無しさん
22/01/31 13:17:00.70 wgfsi16C.net
歴史って言葉持ち出してるんだしそんなしょうもない話じゃなくてもっと有名なエピソードなんじゃないの
45:デフォルトの名無しさん
22/01/31 13:24:49.76 HGCqFbKg.net
「Rustのタスクの欠点は？」
「プリエンプティブじゃないところ」
「プログラマーが注意すればいいだけだから問題ない」
46:デフォルトの名無しさん
22/01/31 13:35:30.64 qlFEomu1.net
そりゃepollやselect相当を自分で使っていてミスをすればイベントループがハングアップするのは当たり前
しかし非同期タスクのイベントループは非同期スケジューラの中にあって自分でepollやselectを扱わなくてよくなった
だから自分のミスでイベントループがハングアップすることはなくなった
それ以前の歴史では色々あったが状況が変わった
47:デフォルトの名無しさん
22/01/31 13:51:12.77 dnOSCP4X.net
はいはい、理想的な環境で羨ましいですね
これでいいかな？w
48:デフォルトの名無しさん
22/01/31 14:52:14.32 QZLkrRiL.net
メモリ開放忘れみたいなバグの話でしょ
そんなに引っ張る話でもないと思う
49:デフォルトの名無しさん
22/01/31 14:57:56.44 wgfsi16C.net
バグ耐性高めるためにタスクをプリエンプティブにしたいならすれば良いのでは
プログラマーのスタンスに合わせて適切な物を選べるよう選択肢は用意されてると思うが
何について言い争ってるのかよくわからない
50:デフォルトの名無しさん
22/01/31 15:37:58.82 UHXhumHV.net
GoやNode.jsが上手くいってる主因は非同期並行プログラミングのしやすさ
両者は方向性が真逆だけどそこが共通点で時代の要請
逆にC++が振るわないのは非同期並行プログラミングのしにくさ
その状況でRustが登場して非同期並行プログラミングのしやすい環境も装備されたという流れ
51:デフォルトの名無しさん
22/01/31 18:03:53.30 dLpRlGxR.net
>>49
タスクはプリエンプティブにはできないよ
スレッド使えって言ってるの？
52:デフォルトの名無しさん
22/01/31 18:33:21.76 fs07R1AL.net
>>51
そうじゃね？
53:デフォルトの名無しさん
22/01/31 18:56:25.41 UHXhumHV.net
Node.jsもプリエンプティブではないけど困っていない
タスクがプリエンプティブではないことを欠点だと主張する人は
欠点だという具体的な例を挙げてから主張すべき
54:デフォルトの名無しさん
22/01/31 19:02:29.41 wgfsi16C.net
>>51
そうだよ
ここで言うタスクはtokioやasync-stdの用語のタスクのことね
spawn_blockingでタスク生成すれば専用スレッドが割り当てられるので特定のタスク選んでプリエンプティブにできる (OSにタスクスイッチの制御を委譲できる)
55:デフォルトの名無しさん
22/01/31 19:03:44.27 wgfsi16C.net
>>53
spawn_blockingみたいなAPIが用意されてるのはプリエンプティブなタスクの需要はあるんじゃないの
そこを否定する意味が分からない
56:デフォルトの名無しさん
22/01/31 19:28:57.02 UHXhumHV.net
>>54
それはレイヤーが違う
まずOSスレッドは何をしようが常にプリエンプティブ
だからOSスレッド上で動いているタスクも途中で一時中断されたり再開されたりしうる
だからといってタスクをプリエンプティブだと言わないのはタスクの階層で話をしているため
タスクスケジューラに制御を戻さない限り他のタスクに切り替わらないため「プリエンプティブではない」と言われる
次にspawn_blockingで起動されるのもタスクの一つ
だからタスクスケジューラが管理するスレッドの中で動く
それがspawnだと一つのスレッドに対するキューに複数のタスクが割り当てられる
一方でspawn_blockingは一つのスレッドに対するキューにそのタスクのみが割り当てられる
それだけの違いであり両者ともにタスクスケジューラの管理下にあるタスクである
もちろん動作中も終了後もタスクとして同じ扱い
つまりspawn_blockingはプリエンプティブにするものではない
同じタスクでありスタックレスなコルーチンであることも同じ
>>55
その意見は成立していない
57:デフォルトの名無しさん
22/01/31 19:56:01.95 wgfsi16C.net
>>56
確かにプリエンプティブという用語を使ったのは適切ではなかったかもね
タスクがスレッドを占有するか他タスクと共有するか選択できると言い換えればよいかな
58:デフォルトの名無しさん
22/01/31 21:28:17.75 L8OnQfxN.net
>>54
最初からspawn_blockingで呼ぶべきだと誰もがわかるような処理だけじゃないよ
Goと同じでRustもそのうちプリエンプティブなスケジューラが作れるような機構を用意すると思うけどね
59:デフォルトの名無しさん
22/01/31 22:11:33.46 qlFEomu1.net
>>58
preemptiveは必要ない
シングルスレッドかつcooperativeなJavaScriptがNode.jsを含めて問題なく動作し成功している
60:デフォルトの名無しさん
22/01/31 22:59:08.63 UPbAych9.net
Rustってデータ競合を許さない、ってあたりが並列処理とめちゃくちゃ相性良いように見えるけど、
まだそういうスケジューラとか非同期ランタイムらへんの仕組みがちっとも枯れてないんだね
将来のデファクトがどうなりそうか、ってのはある程度見えてきてるのかな？
61:デフォルトの名無しさん
22/01/31 23:10:00.73 9ggC0jgK.net
>>59
tokioの開発者もasync-stdの開発者もそうは考えてない
a major source of bugs and performance issues in concurrent programs: accidental blocking.
URLﾘﾝｸ(async.rs)
62:デフォルトの名無しさん
22/01/31 23:16:15.33 UHXhumHV.net
>>61
それはすぐに廃止された
そして現在tokioもasync-stdもプリエンプティブを許すコードは存在しない
63:デフォルトの名無しさん
22/01/31 23:18:46.34 9ggC0jgK.net
>>62
知ってるよ
問題認識の話をしてるんじゃん
64:デフォルトの名無しさん
22/01/31 23:21:44.46 9ggC0jgK.net
Node.jsはタスク単位で高い信頼性が求められるシステムでは使われない
イベントループがブロックしたら他のタスクを道連れにしてプロセス丸ごと再起動する以外に対処法がないから
それもexecution managerできちんとモニタリングしてればの話
JSやNodeとRustとはポジショニングが違う
65:デフォルトの名無しさん
22/01/31 23:28:55.88 qlFEomu1.net
>>64
イベントループがブロックすることはない
何を言いたいのか意味不明
66:デフォルトの名無しさん
22/01/31 23:47:16.39 UHXhumHV.net
>>64
Node.jsまで否定し始めるとは発狂もほどほどに
67:デフォルトの名無しさん
22/02/01 01:18:54.05 NlOJHFhB.net
>>58
rustでプリエンプティブなタスクって実装できるのかね
goみたいなシグナルでスイッチする仕組みは使えない気がするが
68:デフォルトの名無しさん
22/02/01 09:02:19.73 YxH4csZd.net
昔は標準で出来たのに「そういうのはライブラリでやればいい」って嘯きながら削除して、そのあと一生それが出来る標準ライブラリが登場しないいつものRust
69:デフォルトの名無しさん
22/02/01 14:23:13.43 fJKShZ3h.net
>>67
Cで実装できることはRustでも実装できる
もちろんRustにもプリエンプティブなスケジューラは存在する
Rustで書かれたプリエンプティブなリアルタイムOSもある
>>68
Rust標準にプリエンプティブなタスクであるグリーンスレッドがあったのは
Rust 1.0が正式リリース(2015年)となる以前Rust ～0.9 の試行している時代
しかし重厚となりベアメタルもターゲットとするRustでは不適なため放棄
例えばGoの方法だと巨大なランタイムや個別スタックが必要など
そのためRust標準ではスタックレスで軽いタスクを提供
さらに加えてasync/awaitもサポートし現在の軽く便利な環境となった
70:デフォルトの名無しさん
22/02/01 15:14:51.45 7ZSm+F9e.net
あと5年寝かせれば使えるようになるかな
71:デフォルトの名無しさん
22/02/01 15:26:14.30 0bEAn4zq.net
別に今でもasync-stdを使えばええんちゃうか？
72:デフォルトの名無しさん
22/02/01 15:54:32.70 aP+3H5wQ.net
>>69
ユーザーランドでプリエンプティブなタスク実現するという話なんだけど
具体的にどのライブラリがサポートしてるの？
73:デフォルトの名無しさん
22/02/01 16:14:56.52 fJKShZ3h.net
>>71
async_stdでのプリエンプティブな試みは軽さの方針等に合わず、組み込まれないままで終わった
>>72
上記の後継がasync_stdから独立していてsmolscaleとなっている
74:デフォルトの名無しさん
22/02/01 17:44:48.05 IGt6++7z.net
>>72
lunaticってのがWASM限定だけどプリエンプティブ実現してるらしいよ
WASM以外はコンパイラのサポートがないと無理
>>73
async-stdがやろうとしてたのはプリエンプティブではないよ
75:デフォルトの名無しさん
22/02/01 23:44:18.44 rLXhSAw+.net
話題になってる分野だとC++が惨敗すぎて
Rustの話題一色になってしまってる感じ
76:デフォルトの名無しさん
22/02/02 00:32:45.41 Bknypv+c.net
C++が落ち目なのはまっとうなエンジニアの間では共通認識だろ
77:デフォルトの名無しさん
22/02/02 02:30:31.45 YscELMZC.net
78:変な拡張し杉てワケワカになってきてるよな
79:デフォルトの名無しさん
22/02/02 11:27:34.63 jvlsF+ng.net
変な拡張を使わなければ良いだけでは？ 使いこなせないのを使えなとは言わない。
80:デフォルトの名無しさん
22/02/02 14:23:10.98 X76n4047.net
RustがGo位の位置にたどり着くのは、あと何年かかるかね
81:デフォルトの名無しさん
22/02/02 15:00:57.22 O+j3A95O.net
GoはWebとかのアプリケーションでカジュアルに使われるようになってきたから、使う人数もかなり多くなってきたけど、
Rustはそういうポジションにつくことないだろうから、現在のGoほどの人気になることはないんじゃない？
RustはC/C++のシェアを塗り替えていく程度だろうけど、そういう低レイヤーでは最強言語になりそう
82:デフォルトの名無しさん
22/02/02 15:03:25.91 6tF6MeYL.net
RustがTIOBE Indexに出てくるのはいつなんだろう？w
URLﾘﾝｸ(i.imgur.com)
83:デフォルトの名無しさん
22/02/02 22:30:37.00 yDHN0aKU.net
言語機能としてはC++が完敗だから
過去遺産しか誇るものがない
84:デフォルトの名無しさん
22/02/02 22:35:52.80 /PkFuWcg.net
何言ってんだこのバカ
85:デフォルトの名無しさん
22/02/02 22:46:31.08 J71gX0gE.net
シェアもユーザー数も過去遺産と言われてしまえばそうだが
そんなことは興味がないのでC++での非同期並行プログラミングについても語って欲しい
86:デフォルトの名無しさん
22/02/03 16:11:01.01 VWdjVpzZ.net
C++の非同期っていうとstd::asyncとか？
87:デフォルトの名無しさん
22/02/03 17:48:17.26 rBa0lj+C.net
>>81
今26位で、Kotlin, Lua, Scalaとかより上なんだが
88:デフォルトの名無しさん
22/02/03 17:52:10.90 6/rx3Wgr.net
>>86
COBOLより下なんかwwwww
89:デフォルトの名無しさん
22/02/03 18:30:47.00 VWdjVpzZ.net
KotlinやScalaは結局流行らずJavaで十分だし
Luaも一時期熱狂したけど記法や環境が多くの人の好みに合わずPerlのように嫌われてる
RustもC/C++で十分という認識が強くて普及せずに一部の通好みに終わる可能性がある
Rustは有力企業もプッシュしてるけど三つの言語の流行らない特徴を全て備えてる
そうこうしてるうちにRustより優れた言語がぽっとでて席巻する未来だってある
90:デフォルトの名無しさん
22/02/03 18:38:00.04 I6DodtQJ.net
流行るの閾値高くない？
何位以上になったら満足なんだ
91:デフォルトの名無しさん
22/02/03 18:48:22.27 Y+zgwr9T.net
普通にTop10じゃね？
92:デフォルトの名無しさん
22/02/03 18:51:38.73 OQgvAcI9.net
しかしTop10のVisualBasicやアセンブリが流行ってるとか言われてもあまり納得感はないな…
93:デフォルトの名無しさん
22/02/03 19:08:22.03 Ajxf7YAY.net
TIOBEってトレンドを計測してるわけじゃなくて、あくまで検索エンジンで検索結果のヒット数が多かったランキングだからな
CとかVBみたいに昔から一定の人気を保ち続けてるような言語がランキング高くなりやすいんじゃないかな
94:デフォルトの名無しさん
22/02/03 19:24:04.62 I6DodtQJ.net
GitHub上の活動に基づいたランキングの方がプログラマ間の流行を知るには良いのかな
URLﾘﾝｸ(madnight.github.io)
95:デフォルトの名無しさん
22/02/03 19:40:42.80 NxnOaIbO.net
せやな
TIOBEはJavaScriptとアセンブラが隣の順位に並んでるとかおかしすぎるやろ
96:デフォルトの名無しさん
22/02/03 21:31:55.43 8HqROgrm.net
>>88
Scalaも当時は熱狂的なファンがいたよなｗ
97:デフォルトの名無しさん
22/02/03 21:44:00.20 OJ3iv254.net
ScalaはJVMベースだという点以外は特に悪いところは無いと思うんだが
98:デフォルトの名無しさん
22/02/03 23:27:45.66 VxNIdQ9k.net
コラッツ関数を上手く実装できないかな
99:デフォルトの名無しさん
22/02/04 00:31:37.55 tMDf8XuC.net
>>93
githubはアマチュアプログラマも沢山混じってる。
日経の調査ではプロのプログラマで最も使われている言語はC/C++だとされている。
なお、githubでも、CとC++を合算すると、9.82%、Rustは 0.694%で、
14.1倍の差がある。
100:デフォルトの名無しさん
22/02/04 00:34:29.27 uF1Qc9S6.net
>>98
C vs C++でもあるんだから足したらだめでしょ
101:デフォルトの名無しさん
22/02/04 00:35:47.48 tMDf8XuC.net
>>91
VisualBasicは結構使われているのではなかろうか。Excelなどで。
アセンブリは、基礎的なライブラリを作る人や組み込み、OS、BIOS
を作ったり、グラフィックや数値計算の高速化を行う場合に必要な場合がある。
102:デフォルトの名無しさん
22/02/04 00:36:35.60 tMDf8XuC.net
>>99
Cにクラスを入れたものとしてC++を使っている人は多いはず。
MFCなどもそう。
103:デフォルトの名無しさん
22/02/04 00:44:19.25 uF1Qc9S6.net
>>101
いやいや、スレタイ通りこのスレではCとC++は対立する物として区別すべき
104:デフォルトの名無しさん
22/02/04 00:45:03.38 zhkygWhI.net
今どき言語マウントするやつは
メンタルも技術力もアマチュア
105:デフォルトの名無しさん
22/02/04 00:47:42.81 tMDf8XuC.net
C++はCを基礎にしてるくせに、Cに歯向かって宿主を殺してしまう寄生虫みたいな
ことになってるからな。
106:デフォルトの名無しさん
22/02/04 05:41:15.73 3M0ClPfa.net
いまのc++の拡張がな
autoとラムダとdecltypeくらいでやめときゃいいのにあとでボツになりそうな仕様までモリモリに盛りやがって下手したらobjective-cみたいになりそう
なのにいまだにpropertyも実装されてないとか
107:デフォルトの名無しさん
22/02/04 06:48:54.05 GRC0hKFU.net
conceptsは許せる
108:デフォルトの名無しさん
22/02/04 08:29:55.22 rPvrWkyY.net
>>105
それほどへんなもの追加されてるか？
右辺値参照、constexpr、可変引数テンプレートは必要だしな
109:デフォルトの名無しさん
22/02/04 08:53:37.86 O81zVfQh.net
色々理解できない機能が増えて辛いんだろw
110:デフォルトの名無しさん
22/02/04 09:58:17.78 nTZc+xED.net
conceptはむしろ必須だろうよ
111:デフォルトの名無しさん
22/02/04 10:06:51.33 xcjLhLWs.net
C++11移行では、変数定義で、
TYPE a = b;
の形式が非推奨で、
TYPE a{b};
が推奨になった。
これは、C/C++の今までの伝統を全否定している。
C++11以後は、宿主を殺すウイルス的な存在に成り下がった一例。
112:デフォルトの名無しさん
22/02/04 11:28:12.62 i2fLUlAL.net
URLﾘﾝｸ(hp.vector.co.jp)
すこ
113:デフォルトの名無しさん
22/02/04 11:33:17.83 O81zVfQh.net
>>110 みたいな爺さんは書き方変わるだけでアタフタw
114:デフォルトの名無しさん
22/02/04 12:53:41.07 6YwPoRaj.net
>>110
TYPE a{b};
↑これって何がうれしいの？
c++よく知らんので教えてほしい
115:デフォルトの名無しさん
22/02/04 12:55:43.71 m8EcUnam.net
コンパイラ都合じゃね？知らんけど
116:デフォルトの名無しさん
22/02/04 14:18:18.78 vKz9Nbsj.net
>>113
オブジェクトの定義に対して初期化子を与えると、オブジェクトの初期値を
決定することになるが、初期化子には次の4種類ある :
T a{b};
T a={b};
T a = v;
T a(v);
・このうち、あらゆる局面で利用できるのは、最初の T a{b}の形式のみ
(なおこの形式はC++11で新しく導入された。)。
・一番大きな理由はこの形式は「縮小変換を許さないから」とされる。
ただし、ややこしいのが、Tの部分を autoにした場合は、T a{b}の形式は
落とし穴がされるので使うべきではないとされている。
なぜなら:
auto z1{99]; // z1は initializer_list<int>型になってしまう。
auto z2 = 99; // z2は、int型。
ところが、Tが具体的な型の場合には、T a{b} が推奨される:
int x1{99}; // 推奨される書き方。
int x1 = 99; // 縮小変換があるので推奨されない書き方。
全く一貫性が無く、C++11が駄目な部分の一つ。
117:デフォルトの名無しさん
22/02/04 14:21:57.65 vKz9Nbsj.net
>>115
[誤字訂正版]
オブジェクトの定義に対して初期化子を与えると、オブジェクトの初期値を
決定することになるが、初期化子には次の4種類ある :
T a{b};
T a={b};
T a = b;
T a(b);
・このうち、あらゆる局面で利用できるのは、最初の T a{b}の形式のみ
(なおこの形式はC++11で新しく導入された。)。
・一番大きな理由はこの形式は「縮小変換を許さないから」とされる。
ただし、ややこしいのが、Tの部分を autoにした場合は、T a{b}の形式は
落とし穴が有るので使うべきではないとされている。
なぜなら:
auto z1{99]; // z1は initializer_list<int>型になってしまう。
auto z2 = 99; // z2は、int型。
ところが、Tが具体的な型の場合には、T a{b} が推奨される:
int x1{99}; // 推奨される書き方。
int x1 = 99; // 縮小変換があるので推奨されない書き方。
全く一貫性が無く、C++11が駄目な部分の一つ。
118:デフォルトの名無しさん
22/02/04 14:40:30.04 MGyBlJhW.net
ふーん、レガシー言語は大変だね
119:デフォルトの名無しさん
22/02/04 14:44:09.08 vKz9Nbsj.net
Rustはもっと最悪に汚い。
C++の最大の欠点は、仕様が難しいことに有るが、
Rustはさらに仕様が難しい。
よって、RustはC++をさらに悪くしたと言えて、改良には全くなってない。
120:デフォルトの名無しさん
22/02/04 14:54:48.13 WO7o5PWJ.net
ふーん、レガシー脳は大変だね
121:デフォルトの名無しさん
22/02/04 14:59:52.64 vKz9Nbsj.net
>>119
馬鹿は黙ってろ。
122:デフォルトの名無しさん
22/02/04 15:11:33.72 dFWqGnrm.net
つまり仕様が簡単な方が良いということ？
123:デフォルトの名無しさん
22/02/04 15:17:49.19 wTfQ05na.net
>>119
ばーかｗ
124:デフォルトの名無しさん
22/02/04 16:13:01.17 sAwXze1R.net
効きすぎだろwww
125:デフォルトの名無しさん
22/02/04 16:23:37.19 J8iEhnuL.net
c++は（ランタイム速度落とさなくても）できらぁ！ってなったらとりあえず入れるからな。
ある意味とてもガキくさいがそれはそれでありなポジションに到達してる気はする。
126:デフォルトの名無しさん
22/02/04 20:04:05.51 JLdS+NWr.net
そんな凄いんだったらもっと普及してるよねRust
でも現実はブビにもコボルにも負けてる泡沫言語
127:デフォルトの名無しさん
22/02/04 20:40:31.16 b3SZZj/4.net
単純に新しい言語だから累積となるユーザ数でまだ不利なだけ
2019年11月のasync導入で非同期プログラミングがまともに使えるようになってまだ2年余り
Linux OSのようにC++を頑なに拒否していたプロジェクトでもRustは受け入れられたように
C++に未来はないがRustには未来がある
128:デフォルトの名無しさん
22/02/04 20:44:24.76 JLdS+NWr.net
最後間違い
C++に未来はないがRustも未来はない
129:デフォルトの名無しさん
22/02/04 20:49:40.24 jGBmcDmC.net
日本は先進国の技術トレンドから5年以上遅れてるからね
130:デフォルトの名無しさん
22/02/04 20:53:24.16 rIsLZ1dN.net
C++erはレガシー脳が多いから
いい意味でのレガシーね
オリンピックレガシーみたいなw
131:デフォルトの名無しさん
22/02/04 20:54:41.42 aq7ZCAbr.net
C++はあんなみすぼらしいラムダ式用意して哀れやわ
貧乏の家の子が自家製ボタモチもって突っ立ってるようやわ
132:デフォルトの名無しさん
22/02/04 21:01:52.67 JLdS+NWr.net
Rustやってる奴は現状アーリーアダプターで普及するにしてもまだ年月掛かると思う
んでその間にまた新しい言語が開発されみんなそっちに移って行くと
133:デフォルトの名無しさん
22/02/04 21:06:34.54 3IKuZnie.net
新しい言語はどんな問題解決してくれるんだろうな
動的型付けが復権するんだろうか
134:デフォルトの名無しさん
22/02/04 21:15:25.28 V2NB9pIC.net
>>131
アーリーアダプターは数年前の時期
今は大手IT各社GAFAMがRustに本腰
プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
URLﾘﾝｸ(j)
135:apan.zdnet.com/article/35166267/ Facebook(現Meta)が「Rust Foundation」に参加 https://japan.zdnet.com/article/35170192/
136:デフォルトの名無しさん
22/02/04 22:59:18.87 ckxp+S+3.net
>>131
それならそれで無駄にはならない気がするが
考え方は継承されるだろうし
137:デフォルトの名無しさん
22/02/05 01:30:11.76 6GVIsHGT.net
SNS見てる限り、若い人でも人気は Rust より C/C++ の圧勝。
138:デフォルトの名無しさん
22/02/05 02:39:36.18 ye9/tceq.net
大学の課題とかはまあC/C++よね
139:デフォルトの名無しさん
22/02/05 06:15:36.04 LYyRCemg.net
>>133
RustはVisual studioでデフォルトで選択できるようになったら普及するだろうな
140:デフォルトの名無しさん
22/02/05 09:06:42.96 E0droKIF.net
北京五輪と東京五輪の開会式をプログラミングで例えるとどうなるやろ？
141:デフォルトの名無しさん
22/02/05 16:44:42.87 bofW+oE9.net
そのまま普通に
東京五輪 Rust
北京五輪 C++
142:デフォルトの名無しさん
22/02/05 17:35:54.33 O/WKZnIq.net
東京五輪 FAMILY-BASIC
143:138
22/02/06 17:01:26.43 LMR3oS4I.net
ちょっとセンシティブな話だったか
与太話と思ってスルーしてくれ
すまんかった
144:デフォルトの名無しさん
22/02/10 11:18:14.49 sUV8whwi.net
>>139
Rustってそんな酷い言語だったんだ
手出さなくて良かったわ～
145:デフォルトの名無しさん
22/02/10 11:25:47.65 ylUFM8HS.net
Rust 拝金主義
C++ ハイキング
146:デフォルトの名無しさん
22/02/10 20:10:06.55 9RAaYAUg.net
RustはC,C++を駆逐すると思う。アレに拘泥する理由はない。
147:デフォルトの名無しさん
22/02/10 21:00:13.02 ylUFM8HS.net
HighKingの至高の頂に座居するC++に勝てると本気で思っているのかね
148:デフォルトの名無しさん
22/02/10 21:47:05.33 o2ECnsWv.net
>>144
過去資産があるから駆逐まではいかないかな。
でももっと利用されるだろう。
けど非同期のやつとかの分断をどうにかして欲しい。
149:デフォルトの名無しさん
22/02/10 21:50:08.15 dDg7TD3H.net
ジワジワと侵食して気が付いたらいつの間にか利用していたって広がり方するんだろうな
150:デフォルトの名無しさん
22/02/10 21:51:34.38 9RAaYAUg.net
>>116
これ見てクソ言語だなって思わないヤツいるのかね。
151:デフォルトの名無しさん
22/02/10 21:53:35.73 LnXBonLg.net
>>116
なんでこんな言語が使われるようになったんや？
152:デフォルトの名無しさん
22/02/10 23:38:10.62 o2ECnsWv.net
>>149
使われるようになったんじゃなく、既に使われてた言語を過去との互換性を崩さずに 変更しようとして/変更して そうなったんだよ。
その変化は今なお止まってないんよ。
153:デフォルトの名無しさん
22/02/10 23:40:02.53 TPkaON1O.net
>>149
はい
URLﾘﾝｸ(hp.vector.co.jp)
154:デフォルトの名無しさん
22/02/11 01:30:20.07 ieudecgp.net
>>149
C++が最初に使われ始めたころは、T a{b}のような記法はなく、
C++11で登場した。
使われ始めたころのC++はCの後継として丁度良いと思われるようなもので
あって、>>116のような変な仕様は入ってなかった。
最初は良かったが、後を突いていくと時々「え？」と思うような仕様が入り込み、
C++11で如実になった。
・templateの仕様も「え？」と思うことが多いものだった。
Stroustrap氏によれば、高速化に重点を置いて導入されたものらしいから、
分かり易さは犠牲になっているようだが、それにしても分かりにくいことが多い。
・C++にはライブラリが無かったので、C++11で導入されたが、それが
賛否の分かれるもので、恐らく6割くらいの人には質が悪く感じるものであった。
155:デフォルトの名無しさん
22/02/11 07:42:26.56 KbgZfaat.net
www.mercari.com/jp/search/?keyword=hr400p
こういう安い中古チューナ買って、Coinyをスカパープレミアム放送のICカード化して、
スカパープレミアムのチャンネル全部見れるし、USB HDDに録画フリー。
【avoCADO】 Coiny card Part4【仮想通貨】
ｽﾚﾘﾝｸ(avi板)
156:デフォルトの名無しさん
22/02/11 11:09:11.39 X1ujBpuJ.net
C++は必要な機能だけ使ってれば問題ないことが多いが、
コンパイルエラーメッセージがやばすぎる
まともな言語とは言えない
157:デフォルトの名無しさん
22/02/11 11:36:27.12 08JP5jFO.net
アレは読むんじゃない
詠むんだ
158:デフォルトの名無しさん
22/02/11 11:39:59.37 MSfgatap.net
>>154
逆にRustのコンパイラのエラーメッセージは手厚く至れり尽くせりで感度もの
159:デフォルトの名無しさん
22/02/12 01:52:06.05 ct0ZlJaB.net
>>154
C++は、学者がtemplateメタプログラミング関連などの理論的な正しさを
見せびらかしているだけの様な気がするよ。
「ほら、これでメタプログラミングができるだろ、俺の理論の正しさがわかったか」
みたいに。
160:デフォルトの名無しさん
22/02/12 01:53:21.86 ct0ZlJaB.net
ただ、だからといってRustがその代わりになるということではない。
RustはRustでC++以上に問題を入れ込んでしまった。
これもまた机上の空論の様な言語。
161:デフォルトの名無しさん
22/02/12 09:46:16.21 nCAwro3+.net
>>158
机上の空論でない言語は何よ？
162:デフォルトの名無しさん
22/02/12 10:21:13.78 ZjQpgox3.net
アセンブラとC言語
使わないけどFORTRANとCOBOLもそうかな
163:デフォルトの名無しさん
22/02/12 10:44:19.07 lHDa3hl7.net
>>160
ADAは？
164:デフォルトの名無しさん
22/02/12 11:06:25.45 4ZF6L5uh.net
>>159
横やけど
俺もC言語だと思ってる。
165:デフォルトの名無しさん
22/02/12 11:24:57.04 ZjQpgox3.net
>>161
Ada は（少なくとも出た当時は）けっこう机上の空論ぽい機能てんこ盛りだった
166:デフォルトの名無しさん
22/02/12 11:27:00.51 nCAwro3+.net
Cは貧弱すぎだろう。いまさらmallocとか書く気もおきん。
167:デフォルトの名無しさん
22/02/12 12:03:28.21 yRIrPLWC.net
>>158
C++の問題よりはマシだろ
168:デフォルトの名無しさん
22/02/12 12:07:09.85 XghCcbPA.net
前にこれをC++スレかどっかで発言したら結構叩かれたけど
C++って結局はテンプレートが言語の真ん中にあるよな
他の言語色々やった上であらためてC++見ると俺にはそう見える
一応マルチパラダイム言語だからC++しかやったことない人は
テンプレートだけをフォーカスされるのは不服っぽいけど
169:デフォルトの名無しさん
22/02/12 12:08:32.56 v8ccrYYP.net
テンプレートは強力だよな
170:デフォルトの名無しさん
22/02/12 12:12:41.52 XghCcbPA.net
Cではちょっとしんどいです
いろんなコンテナ使いたいです
そんとき型をパラメータ化したいです
ハゲ「テンプレートでみんな幸せ」
C++er「やったぜ」
C++規格の関係者「いろいろ仕様につっこんだぜ！」
C++er「あっはい」
171:デフォルトの名無しさん
22/02/12 12:42:37.24 Wnw3K02J.net
>>166
概ね同意
テンプレートは便利だけど使いすぎてワケワカメってなりがち
172:デフォルトの名無しさん
22/02/12 13:44:38.22 v8+/CWv5.net
Rustでバブルソート書いてみたがすげー書きやすいな
食わず嫌いだったかもしれん
コンパイルエラーがめっちゃわかりやすい
173:デフォルトの名無しさん
22/02/12 13:57:38.37 w2XePdCb.net
ほんとかよｗ
174:デフォルトの名無しさん
22/02/12 14:50:46.51 wXyEGH3A.net
バブルソートw
175:デフォルトの名無しさん
22/02/12 15:04:29.49 kx8mtXuQ.net
バブルソートw
176:笑うとこかよ
177:デフォルトの名無しさん
22/02/12 15:45:26.65 yRIrPLWC.net
確かにエラーは笑っちゃうくらい親切だわな
178:デフォルトの名無しさん
22/02/12 16:16:36.29 zOhO24og.net
rustのエラー報告は全てのプログラミング言語で最高の親切さだと思う
他の言語がサボりすぎなんだよな
rust書くと他の言語かけなくなる
179:デフォルトの名無しさん
22/02/12 16:54:42.98 zd9UI5Og.net
そんなバブルソートバカにせんでもよかろうに
大学一年で最初の方に習うし、初めての言語触るにはまあまあ良い題材では
180:デフォルトの名無しさん
22/02/12 17:44:36.13 91xKDv7O.net
少しいじってcombソートにしたらクイックソートにもひけをとらないしな。
181:デフォルトの名無しさん
22/02/12 17:55:38.68 nCAwro3+.net
Rustで双方向リストをマージソートでソートするとかだとめんどくさいことになる気がする
182:デフォルトの名無しさん
22/02/12 18:09:42.02 REfvKUVO.net
バブルソートがすげー書きやすいってどのへんが？
逆にそんなもん書きにくい言語なんてあるの？
fn main() {
let mut v = vec![8, 4, 3, 7, 6, 5, 2, 1];
let bsort = |v: &mut Vec<i32>| for i in 0..v.len() {
for j in 1..v.len() - i {
if v[j] < v[j - 1] {
v.swap(j, j - 1)
}
}
};
bsort(&mut v);
println!("{:?}", &v);
}
↑書いてみた
細かいところは日本語版wikipediaに準拠
183:デフォルトの名無しさん
22/02/12 18:12:12.77 /iL1/Dd6.net
ソートの話はどうでもよくて要点はRustに対してのこの部分だと受け取ったが
>>170
> 食わず嫌いだったかもしれん
> コンパイルエラーがめっちゃわかりやすい
184:デフォルトの名無しさん
22/02/12 18:34:19.97 v8ccrYYP.net
>>180
同意
185:デフォルトの名無しさん
22/02/12 19:15:40.31 1IxSArcj.net
バブルソートは理解が難しいわりに現実に使われんのがな。
それだったらクイックソートをだな。
186:デフォルトの名無しさん
22/02/12 19:50:02.51 ZjQpgox3.net
>>182
> バブルソートは理解が難しい
えっ？
187:デフォルトの名無しさん
22/02/12 19:53:57.23 772ADf0k.net
>>183
頭の良さは人それぞれなんだから馬鹿にしない
188:デフォルトの名無しさん
22/02/12 21:02:43.90 kBzBXJs5.net
ダブルアレイは原理が簡単にもかかわらず、十分バグが取れるまでずいぶん時間がかかった。
189:デフォルトの名無しさん
22/02/12 23:07:39.79 wXyEGH3A.net
CPU時間をたらふく使うバブリーなソートだよな
190:デフォルトの名無しさん
22/02/12 23:55:25.98 x20bdFcp.net
>>180
Rustはコンパイラが出すエラーメッセージが詳しすぎて解決案まで示唆してくれたり親切すぎる
他のコンパイラ言語だけでなくインタプリタ言語まで広げても一番親切なプログラミング言語システムだと断言できる
191:デフォルトの名無しさん
22/02/12 23:56:38.45 zNyDeBid.net
まあC++にテンプレートないならそこまで使わんわな
192:デフォルトの名無しさん
22/02/13 01:14:02.16 z8C8/2EV.net
Stroustrup氏の脳内では、テンプレートの目標が高速化であるということなのが
問題の始まりの気がする。
193:デフォルトの名無しさん
22/02/13 01:20:30.65 z8C8/2EV.net
マクロ=高速化用途で使われているもの
という見方が如何にも実用プログラムを書いたことの少ない学者だと思う。
194:デフォルトの名無しさん
22/02/13 09:42:52.30 LKJBNTq1.net
C++からテンプレート取ったらなにも残らない
195:デフォルトの名無しさん
22/02/13 09:51:25.60 0Lo3ZZ1+.net
いや残るだろ
196:デフォルトの名無しさん
22/02/13 10:12:41.48 jQxqAel+.net
STLなくなっちゃう
197:デフォルトの名無しさん
22/02/13 10:25:11.79 yoBtg/nD.net
>>186
その代わりメモリーは使わないから貧乏な俺でも使える
198:デフォルトの名無しさん
22/02/14 23:17:34.32 T9mSH3bb.net
>>179
そういうことではなく
おそらく>>170が言いたいのはコンパイラが出すエラーがめっちゃ親切なことだろう
こっちで書き換わってるからここにmutを付けなさいとか
ここで所有権が移動したのに後で使用してるからここに&を付けなさいとか
これをuse宣言するのを忘れてますよとか
この変数は宣言されず使われていますがこの変数名のスペルミスではありませんかとか
といった簡単なものから
複雑な借用関係をちゃんと登場人物たちをはっきりさせてあっちとそっちがこれこれでマズいのでこうしてみたらどうかなど
こんなにきめ細かく親切なエラーを出すコンパイラ＆インタプリタは他の言語と比べてもトップではないか
199:デフォルトの名無しさん
22/02/15 00:19:44.75 kCmeQXW/.net
>>151
デマは辞めようね
200:デフォルトの名無しさん
22/02/15 00:24:28.01 tssMbTRA.net
>>195
同意
201:デフォルトの名無しさん
22/02/15 07:23:31.22 A9ZkwK3T.net
>>195
そこは目から鱗だよな
ここまでできるなら、他の言語も頑張れよと言いたくなる
202:デフォルトの名無しさん
22/02/15 07:51:21.06 aaenmMxg.net
言語として所有権の概念がないからその辺りの指摘はしないけどVS2022のC#も結構色々提案してくれるぞ
203:デフォルトの名無しさん
22/02/15 09:28:59.50 CNcLOkDE.net
このながれでこれを言う意味なんてないけど
わかるやつだけわかってくれたらいいんだけど
Rustのコンパイラ昔は酷かったよな
無慈悲なボローチェッカと戦ってたよな(´；ω；｀)
204:デフォルトの名無しさん
22/02/15 09:42:41.51 qxt1mofg.net
まだメジャーバージョン1だしそりゃまあ
205:デフォルトの名無しさん
22/02/15 11:48:06.88 je481k6i.net
>>200
コンパイラというよりもnon lexical lifetimeが入る前の言語仕様の制約が厳しくて辛かったんじゃないかな
>>201
コンパイラのバージョンがsemverにしたがってるうちはメジャーバージョンアップしないんじゃないかな
基本的に過去との互換性は崩さないし、必要ならエディションで非互換な変更もできるようにしているので、
メジャーバージョンアップしてまで互換性崩したい理由がなさそう
206:デフォルトの名無しさん
22/02/16 19:19:14.27 lHwbgihf.net
どこかでPython 2 -> 3みたいなことが起こるかもよ
207:デフォルトの名無しさん
22/02/16 20:18:02.36 oWbPDf/g.net
>>203
Rustは後発言語なだけあって
今どきのプログラミング言語の成功部分を洗練して採り入れてる
だから互換性のないバージョンアップをする時はRustより新しい言語が新たに成功してそれをRustも採り入れたくなったが互換性を維持したままでは出来ない時が来てから
208:デフォルトの名無しさん
22/02/17 03:10:03.97 reqFguXW.net
RustとかNimは第何世代の言語なん？
209:デフォルトの名無しさん
22/02/17 11:44:19.88 RuZDOzbq.net
>>205
第4世代の高水準言語の仲間じゃね？
210:デフォルトの名無しさん
22/02/17 23:40:19.82 W9idHeI8.net
>>202
そのnon lexical lifetimeが入る前の言語仕様の制約が厳しい件なのかどうか教えて
このリンクリストの実装でpush_back()のコードがlifetimeでコンパイルエラーとなる話
URLﾘﾝｸ(qnighy.hat)
enablog.com/entry/2017/05/06/070000
今このコードをコンパイルすると問題なく通って実行もできてしまう
Rustのコンパイラはどんどん賢くなって制約が無くなっていってるんだな
211:デフォルトの名無しさん
22/02/18 00:44:32.85 yXo12zTr.net
Rustって普及するんすか
212:デフォルトの名無しさん
22/02/18 00:54:27.33 WX40LAaF.net
>>195
エラーメッセージの親切さで言うとVC#がトップだと思ってるけどそれ以上？
C++でハマったときの沼の深さは異常だからそんな親切なら乗り換えたくなってきたな
213:デフォルトの名無しさん
22/02/18 00:57:20.21 Dn+7AFaS.net
rustのコンパイる中ってみんな何してんの？
214:デフォルトの名無しさん
22/02/18 01:32:33.29 7ZNuwX6P.net
>>207
push_backの例はまさにNLLでコンパイル通るようになるコードだね
215:デフォルトの名無しさん
22/02/18 02:16:48.89 0USC0+1K.net
C++のTMPのエラーメッセージとRustのジェネリックのエラーメッセージ
C++のはもはや意味不明だがRustのはまだ人間が読める
216:デフォルトの名無しさん
22/02/18 15:09:52.72 6v8ahY7t.net
あまりに親切すぎるメッセージなので、それならそういう風に変更したものをコンパイルしてみて、「こう変更したらコンパイルできました」となればいいなぁ
とRebuildの宮川さんが言ってました
217:デフォルトの名無しさん
22/02/18 15:36:44.00 7ZNuwX6P.net
cargo check --fix である程度は勝手に修正してくれるんだっけ
218:デフォルトの名無しさん
22/02/19 08:57:52.80 AlOKsuc0.net
>>209
C#も親切だけど、Rustはそれ以上だよ
これらに比べると、C++のは情報が無いも同然
219:デフォルトの名無しさん
22/02/19 09:04:29.27 59REwZPX.net
何言ってんだこのバカ
220:デフォルトの名無しさん
22/02/19 09:05:12.66 Wd6uYUeM.net
C++でハマるのはむしろコンパイル通ったあとだからｗ
みんなそれはご存知だとは思うけどｗ
221:デフォルトの名無しさん
22/02/19 09:12:00.22 l5YLFJyt.net
Rustはコンパイルが通ればメモリ問題や競合問題が起きず、プログラム自体に専念できるのがいいよな
そしてコンパイラが出すエラーが親切に手取り足取りしてくれて、すぐ修整できてコンパイルも通しやすい
222:デフォルトの名無しさん
22/02/19 09:37:18.64 AG6SdX6W.net
>>218
つくづく考えた奴は天才だとおもうわ
逆になんでいままででてこなかったんだろうとも思う
Linuxつくるのもいはいけどそれをつくる道具を作るのが先でもよかったような
linuxを全部rustで書き直したrust-linuxみたいなのを作る奴もそのうち出てきそう
223:デフォルトの名無しさん
22/02/19 10:49:58.66 lpo/y5Sw.net
>>219
書き直したとして、1日でビルドできたらいいね
224:デフォルトの名無しさん
22/02/19 11:06:51.15 UkMRjGML.net
Rustの考え方の基になったCycloneが目指してたのがまさにそれだね
225:デフォルトの名無しさん
22/02/19 11:25:52.64 x/upE6G9.net
>>219
> Linuxつくるのもいはいけどそれをつくる道具を作るのが先でもよかったような
GNUって言うかストールマンはその考えでしょ
> linuxを全部rustで書き直したrust-linuxみたいなのを作る奴もそのうち出てきそう
言い出しっぺの法則ヨロ
226:デフォルトの名無しさん
22/02/19 11:45:04.32 AG6SdX6W.net
>>222
いや、マジで俺がやってもいいぞ
誰もやってなかったら俺が次のLinusになれるってことか
むしろお前らは絶対に真似しないでほしい
227:デフォルトの名無しさん
22/02/19 12:04:13.57 ukdLXHKY.net
rustのコンパイルが遅いのは依存ライブラリやジェネリスクの実体化によりコード量が多くなっているからで
コンパイラ自体は並列化とか頑張ってて高速という話を聞くけど実際のところCやC++と比較してどうなんだろうね
ヘッダファイル周りの枷がある分CやC++が優位とも簡単には言えない気がする
228:デフォルトの名無しさん
22/02/19 12:21:08.88 ZWczq9Ua.net
>>223
真似はしないから一つだけ聞いてみたい
どこから書き直し始める？
229:デフォルトの名無しさん
22/02/19 12:59:28.88 NbUDuEDT.net
コンパイラの並列化で
数十コアも効率良く使えるなら
実質的にコンパイル時間は無視できる
230:デフォルトの名無しさん
22/02/19 13:06:40.37 AG6SdX6W.net
>>225
main()かな
231:デフォルトの名無しさん
22/02/19 13:33:27.92 6TS2kFRN.net
>>227
無理無理ｗ
232:デフォルトの名無しさん
22/02/19 14:08:34.48 AG6SdX6W.net
>>228
まあそれは冗談でも「rust os 自作」でググるといろいろでてくるからそれを参考にやってみるわ
rustでOS作ってる先達者が結構いるみたいだからそれを参考にLinuxカーネルの移植をがんばってみるわ
233:デフォルトの名無しさん
22/02/19 14:33:33.28 ZWczq9Ua.net
>>229
まあそんなんだろうと思ってたけど、せめてリーナスがなぜLinuxを作ろうと思ったか、どんな哲学で設計したかぐらいは読んでみると良いと思う
タダで読める情報はいくらでもある
234:デフォルトの名無しさん
22/02/19 14:47:00.85 AG6SdX6W.net
>>230
「それがぼくには楽しかったから 全世界を巻き込んだリナックス革命の真実」は読んだけどそれじゃだめかな？
235:デフォルトの名無しさん
22/02/19 14:48:10.94 xNWdpb+t.net
現時点で2200万行もあるから、完全に移植しようとしたら毎日1万行のコードを移植し続けたとしても、6年はかかるね
そんな爆速で順調に行くわけないし、よっぽどの天才でもなければ1人では生涯に終えるのは無理かな
省ける部分を省くとしたら、何万行になるのかな？
236:デフォルトの名無しさん
22/02/19 15:29:14.09 AlOKsuc0.net
>>224
C/C++に比べたら速いよ
でも、C#に比べたらC/C++と同列に遅い、という程度
237:デフォルトの名無しさん
22/02/19 15:51:49.27 6TS2kFRN.net
rust触ったことないからわからないけどC/C++よりコンパイル速いわけないじゃん
238:デフォルトの名無しさん
22/02/19 16:17:48.81 x/upE6G9.net
Rustのコンパイルが遅いようです。なぜですか？
URLﾘﾝｸ(prev.rust-lang.org)
239:デフォルトの名無しさん
22/02/19 16:25:04.60 oF6CN3LV.net
>>233
CとC++を一緒にすんな
240:デフォルトの名無しさん
22/02/19 16:28:39.65 lVeS0ElI.net
>>235
それ4〜5年前の古い情報
URLにprevとありそのトップページに2018年12月6日とあるように昔のページを残してある
241:デフォルトの名無しさん
22/02/19 16:53:58.55 V3h8uUoV.net
>>237
で、これより新しい情報あるの？
242:デフォルトの名無しさん
22/02/19 18:57:21.37 ukdLXHKY.net
フルビルドと差分ビルドで区別して議論しないと比較難しいね
あと差分ビルドについてもバイナリ生成までするのかソースのチェックで十分なのかでまた変わってきそう
243:デフォルトの名無しさん
22/02/19 21:09:06.50 tV1lc2OB.net
Rustって普及するんすか
244:デフォルトの名無しさん
22/02/19 21:24:23.44 kSnJ/KwP.net
いいえ、あなたには必要ありません
245:デフォルトの名無しさん
22/02/19 22:54:34.42 zY+XWPI2.net
流行る言語は登場から10年くらいでウワーっと大流行するんだが、Rustにはそんな気配はないから
精々Goとかと同じような感じにしかならんやろなー。
246:デフォルトの名無しさん
22/02/19 23:26:45.94 lVeS0ElI.net
>>240
新規案件がC++ではなくRustになっていきつつあるように
じわじわと着実に置き換わっていくのだろう
一方的にC/C++が喰われていくのが止まる理由も見つからん
247:デフォルトの名無しさん
22/02/20 02:10:18.88 5KrZlkth.net
Rustの案件なんてないよ
248:デフォルトの名無しさん
22/02/20 02:51:48.98 Q+YkyZIv.net
>>242
goレベルでも十分流行ってると言えると思うんだけど
249:デフォルトの名無しさん
22/02/20 06:11:08.95 rMSJWNa2.net
>>240
VisualStudioの新規プロジェクトの作成でデフォルトで選べるようになれば普及するだろうね
250:デフォルトの名無しさん
22/02/20 09:55:15.25 c+ifp9sQ.net
>>246
C++もVC++が出てから一気にCを喰い始めたしな
なんだかんだWindowsの影響力はめちゃくちゃ大きい
251:デフォルトの名無しさん
22/02/20 11:25:19.25 Q+YkyZIv.net
当時と今とじゃデスクトップアプリの置かれてる状況が全然違うと思うけど
252:デフォルトの名無しさん
22/02/20 12:09:19.72 28EWOJnb.net
何をもって普及とするかといえば、まだにVB書いてるやつもおるし、組み込みではRustなんて考えられないし、フロントエンドは
JS/TS/Nodeでほぼ不動。そうなるとJava/C#、Railsなどのビジネス系エンタープライズだが、メニーコア用のGoとかのほうが
敷居が低い分だけ人を確保しやすい。言語的な優劣では普及は進まない
当然、高スループットが求められる大企業のエリートでは使われるだろうけど、日本の中小企業で使われるとか想像ができない。
奇々怪々C++は食われていくだろうけど、マイクロコントローラなどでCが食われるなんて無い。データ分析はPythonとかJuliaとか
ビックデータはHadoop・Spark(JavaやPython)だろう
だが当然ながら*nix系は一歩先を進んでるRustだが、ちんまいコマンドラインのプログラムとか、デバイスドライバだとかそういう
分野でしか使えない（使われない）と思う。あとは自動運転なんかのプログラムならRustが使われてたりするが、そういう
技術者はPythonも使えるし、Juliaなんかもすぐ覚えられる。スマホアプリ系もRustなんてありえない
あと残るのはデスクトップアプリケーションとか、これも今はElectron系とかがあるのでネイティブで書く意味があまりない
253:デフォルトの名無しさん
22/02/20 12:14:16.60 RjCQdBpa.net
普及なんてしなくていいんだよそもそも
それを必要とするやつの手に届いたら十分なんだよ
C++でやってた分野の一部でもRustで書き換わって
それでメンテする連中がラクできることになって
一方でユーザ側にも恩恵はあるだろうしそういうのでいいんだよ
ド素人のアマチュアプログラマに届く必要はないんだよ
254:デフォルトの名無しさん
22/02/20 12:26:24.06 TEB+ikpz.net
普及しなくていいし、してもらいたくない
なぜならうちの会社が業界でトップを維持してる秘密だから
他社のウエブサービスより圧倒的に早くセキュアなのはずばりRustをつかってるから。
その前はLispを使ってた。
だから真似してもらいたくない。
まあ、真似できないたまろうけどw
255:デフォルトの名無しさん
22/02/20 12:34:20.56 Q+YkyZIv.net
>>249
これrustに限らず、現状がそのまま続いて新たな言語で置き換わることはないだろうとしか言ってないよね
256:デフォルトの名無しさん
22/02/20 12:48:19.88 RjCQdBpa.net
>>251
そういうことやね
それを必要としてるやつはコッソリ一人で握り込んで
それを優位に役立てていくだけのことだから
257:デフォルトの名無しさん
22/02/20 12:53:50.15 pLBa4/kQ.net
>>249
組み込みはrust向きなとこなんじゃないのかね。組み込み業界のことは一切知らんからアレだけど。
258:デフォルトの名無しさん
22/02/20 13:19:37.41 5KrZlkth.net
Rustが組込向きかどうかはともかく、LinusはC++に対してはCの問題を何一つ解決せず、事態を悪化させるだけと言っていて、Rustについてはドライバを書けるようにするところまでは実際にやってきているらしいよ
259:デフォルトの名無しさん
22/02/20 13:40:02.09 QnKhevyf.net
>>249
組み込み以外にミドルウェアらへんでも使われるようになると思う
OS、RDBMS、Webサーバとか
ミドルウェアよりも上位レイヤーのアプリケーションだけで見ると、GCがある言語でもだいたい十分そうだし、Rustは目立たなそう
260:デフォルトの名無しさん
22/02/20 13:49:36.22 NF24OHT2.net
rustはc++よりbetter cしてるから徐々に市民権得るだろうな
261:デフォルトの名無しさん
22/02/20 14:01:22.11 uUEkIMOM.net
>>251
> 他社のウエブサービスより圧倒的に早くセキュアなのはずばりRustをつかってるから。
おお、なるほど
> その前はLispを使ってた。
ズコーッw
作り話はもっとうまく作れ
262:デフォルトの名無しさん
22/02/20 14:21:18.20 xQDNRCh/.net
Rustってクロージャの再代入できない？
null許容することになるから出来ないようにしてる？
263:デフォルトの名無しさん
22/02/20 14:31:26.55 Q+YkyZIv.net
型が同じなら再代入可能だけどクロージャはそれぞれ別の型を持つので単純には代入どきない
Box<dyn Fn()>などに変換すればできる
264:デフォルトの名無しさん
22/02/20 16:38:17.59 xcGmkjoA.net
>>249
ゲーム系のWASMとか
265:デフォルトの名無しさん
22/02/20 18:49:49.78 xQDNRCh/.net
>>260
ふーんそうなの
Box調べてみるわ
266:デフォルトの名無しさん
22/02/20 19:16:43.92 eM0QoFz6.net
Lispってセキュアなコード書くのPythonより難しくないか
267:デフォルトの名無しさん
22/02/20 22:26:50.09 uSEnVnLU.net
こちらのまわりではスクリプト言語で書かれていた物の高速化でRustへ移行が多いな
レスポンスの意味での高速化もあればリソースとしてのCPUタイム激減もある
使用メモリも激減するためクラウドでもオンプレでも費用支出が激減し桁が変わる場合もある
268:デフォルトの名無しさん
22/02/21 08:03:12.70 J/Dh0skf.net
>>255
さすがにc++03とかと比較されても……
269:デフォルトの名無しさん
22/02/21 08:27:27.48 JVbzDyQT.net
よく知らんのだけど、カーネル書くのに抽象化って必要なの？
もしいらないんだとしたらC++がカーネル書くのになんのメリットもないと考える気持ちもわかる気がする
Rustの場合は安全性がついてくるので抽象化がなくても使う価値がある
270:デフォルトの名無しさん
22/02/21 08:42:47.98 OCv9XetQ.net
Rustのオブジェクトシステムって実際C++のそれと比べたら遥かにわかりやすいよな
traitって概念ほんまありがてえわ
271:デフォルトの名無しさん
22/02/21 08:51:29.17 NpsKB2au.net
>>265
元ネタはコレ
URLﾘﾝｸ(developers.slashdot.org)
272:デフォルトの名無しさん
22/02/21 08:57:14.48 qHKOEqJY.net
>>266
パッと思い浮かぶのはファイルシステムと仮想ボリュームぐらいだけど、C++がメリットになるとは思えんな
273:デフォルトの名無しさん
22/02/21 12:01:24.19 L89iNs1x.net
>>264
DiscordがGoで作られてたバックエンドの一部をRustで書き直したらめちゃくちゃコスト下がったってニュースあったな
C++がRustに置き換わるってよりスクリプト言語やGC言語で作られたものが置き換わっていくのがまず先だろう
274:デフォルトの名無しさん
22/02/21 12:15:00.96 NpsKB2au.net
どうでもいいけど、このスレ個人の思い込みと間違いだらけに見えるな
275:デフォルトの名無しさん
22/02/21 12:25:54.59 R0Wvqlvm.net
>>270
それは今でも粛々と置き換わってるだろう
Rustが使われるのは、スクリプトやGC言語ではパフォーマンスなどが得られない分野なんだろうと思う
276:デフォルトの名無しさん
22/02/21 12:29:39.29 /1Q8PAGZ.net
DiscordがRustに移行した当時のGoは大分ウンコだったけど、今ではわりとマシになっちゃったよ
277:デフォルトの名無しさん
22/02/21 12:50:01.46 hkBHJMBS.net
Goってもうジェネリック入った？
278:デフォルトの名無しさん
22/02/21 12:51:46.86 Vy+crfrM.net
>>271
隔離スレに多くを求めすぎ
279:デフォルトの名無しさん
22/02/21 13:09:04.30 NpsKB2au.net
なんでこうなっちゃったんだろうね。一部の馬鹿が日本をどんどんダメにしてる気がする。もっとちゃんと比較できるよう上手く使えばいいのに。
280:デフォルトの名無しさん
22/02/21 13:20:49.36 /1Q8PAGZ.net
>>274
ああ、おれが言いたかったのはGCの停止時間がマシになったよ、ってことだけだよ
言語機能は大して変わってない
でもGenericsは今月中のリリースが予定されてる1.18に載るはず
281:デフォルトの名無しさん
22/02/21 13:41:53.53 Jx3FjySw.net
昔マイコンBASICって雑誌があってだな
282:デフォルトの名無しさん
22/02/21 14:41:23.11 RtL8dE4+.net
GCがある言語のパフォーマンスが悪いというのは思い込み
283:デフォルトの名無しさん
22/02/21 15:52:49.19 8WYOAA82.net
>>279
トータルのパフォーマンスが問題じゃないんだ、予期せず処理が詰まったり急に負荷があがったりするのが問題なんだ。
まぁ今時のGCはストップザワールドは起きないだろうけど。
284:デフォルトの名無しさん
22/02/21 17:02:58.71 RtL8dE4+.net
>>280
GCが動いて困る場合は、現状でもC++かCなどで実装されているはず
なので、パフォーマンスを向上させる目的でGCあり言語をRustで置き換えるというのは、あまりないと思われる
285:デフォルトの名無しさん
22/02/21 17:03:00.28 dkDp5UUZ.net
>>278
俺はIO派。その前は月間マイコン。
286:デフォルトの名無しさん
22/02/21 17:06:01.87 dkDp5UUZ.net
>>281
あるよ。いま、うちがやってる移植プロジェクトはその案件。
他社がそんな考えだから今の所引く手あまた。一社独占。大阪にもう１社あるってうわさだけど。。。
客が数十件待ってる状態。年収軽く３本いくわｗ
287:デフォルトの名無しさん
22/02/21 17:10:20.58 RtL8dE4+.net
まぁ、GCの弊害がわからず採用して実稼働に入って困ったような技術要素選定バグの場合は、言語置き換え対象としてRustが選ばれるケースはあると思う
288:デフォルトの名無しさん
22/02/21 17:12:56.49 RtL8dE4+.net
>>283
GCの問題じゃなくてパフォーマンスの問題でリプレースなの？
元言語何？
289:デフォルトの名無しさん
22/02/21 17:16:52.14 RtL8dE4+.net
年収3本って3000万ってことか？
内容から、フリーランスでRustへのリプレースを専門でやってる感じだが、個人特定されかねないぞw
290:デフォルトの名無しさん
22/02/21 17:17:29.45 k9jZTatR.net
>>283
レアだから現在のcobolみたいなもんか
291:デフォルトの名無しさん
22/02/21 17:18:15.19 Gf4lGfIx.net
聞いてもない年収語るような奴の相手すんなよ…
292:デフォルトの名無しさん
22/02/21 17:46:13.57 hWQuQvUr.net
Rustに置き換える理由はパフォーマンスより保守性とか堅牢性だと思う
開発者が少ない現状だと単純に保守性向上のためだけに外注するようなケースは少なそうだけど
今のシステムが不安定で改修もままならないからRustで作り直すってケースなら結構ありそう
293:デフォルトの名無しさん
22/02/21 17:56:15.16 9wSZ8YP/.net
トヨタなんかの車載システムはCとRustで開発してるとか聞いたことあるが
294:デフォルトの名無しさん
22/02/21 17:58:36.91 H7trbIGN.net
車でストップザワールドはまずいわな
295:デフォルトの名無しさん
22/02/21 18:02:07.18 LC1rF3os.net
>>281
今までGCありスクリプト言語をRustへ置き換えたり置き換えつつある
GCの有無は条件ではないのだけど速さ省メモリに安全性と書きやすさ等でRustとなった
296:デフォルトの名無しさん
22/02/21 18:07:56.53 NpsKB2au.net
9割嘘
297:デフォルトの名無しさん
22/02/21 18:30:22.78 Vy+crfrM.net
>>284
サービスの立ち上げ期にGC影響も見越してカリカリにチューニングするってのは早すぎる最適化なんじゃないのかね
rustで他の言語と同じくらいの早さでサービス作れる人材がそろってるなら良いが
298:デフォルトの名無しさん
22/02/21 18:32:07.53 kwaQcaho.net
スクリプトからの置き換えとして、VMを配布したくない（JVM/.NETが除外）、それなりに言語機能が欲しい（Goが除外）となるとRustくらいしか残らんのだよな
逆にそれらを許容できるなら別にRustじゃなくていいんだが
299:デフォルトの名無しさん
22/02/21 18:34:26.10 shT+MRih.net
Firefoxがいまだに勝てないのに速さとか言われてもな、省メモリならEdgeだし、自分たちがしたいだけでしょ
300:デフォルトの名無しさん
22/02/21 18:43:26.39 NpsKB2au.net
VMとかgoとかスレ違い
なんでC/C++/RustでGCとか出てきてんだよ
ム板ならGCの話をするならスレ立てて簡易実装くらい出して、有無の差異、モデルの差異、各言語の比較をしてほしい
前提の違う話を複数絡めて盛りすぎ
※明らかな嘘は論外
301:デフォルトの名無しさん
22/02/21 18:50:49.00 lBTJyZA6.net
うちはNode.jsからの移
302:行先がRustになった JavaScriptよりプログラミングしやすくなった
303:デフォルトの名無しさん
22/02/21 22:12:40.35 TSmsigpa.net
C vs C++ vs RustなんてRust圧勝で勝負ついてるんだから話すことなくない？
304:デフォルトの名無しさん
22/02/21 22:17:05.24 Gf4lGfIx.net
だったら黙ってれば？
305:デフォルトの名無しさん
22/02/22 00:25:06.07 5VMYN97O.net
>>300
なんだよ偉そうに
306:デフォルトの名無しさん
22/02/22 07:36:54.62 3cXa2TFM.net
>>299
言語機能としては圧勝なんだが、人やソフトなどの開発環境が惨敗だから困るんだよな
307:デフォルトの名無しさん
22/02/22 09:09:32.46 5VMYN97O.net
>>302
今一人勝ちのJavaだってそうなるまでに20年かかったんだから今判断しても意味なくね？
308:デフォルトの名無しさん
22/02/22 10:17:05.86 5VMYN97O.net
>>258
Lispとかいたらズコーってされたけど適材適所だと思うぞ
ルンバがLispで書かれているのは知ってるよね？
強力なメタプログラミング機能とインタラクティブな開発が必要なら採用してみてもいいのでは？
309:デフォルトの名無しさん
22/02/22 10:34:56.38 AiPUeoxY.net
>>304
セキュアなWebサービスはどうしたんだよw
310:デフォルトの名無しさん
22/02/22 11:24:36.79 FcgRLtLU.net
rustに置き換えようとして担当が逃げ出したプロジェクトがかなりあるわ。。これからその地獄がはじまる。
311:デフォルトの名無しさん
22/02/22 11:47:19.90 5VMYN97O.net
>>306
うちにもってきてよ。やってあげる。
312:デフォルトの名無しさん
22/02/22 12:20:08.49 kvixU8HR.net
どうしたらLispでセキュアなwebサービス作れるん
313:デフォルトの名無しさん
22/02/22 12:37:25.61 5VMYN97O.net
>>308
作れないからRustにしたんだよ
314:デフォルトの名無しさん
22/02/22 12:41:08.18 fFHtSmjB.net
Lispだろうと多言語だろうと新しめの通信とかSSLとかのライブラリを探すとこからスタートじゃない？
315:デフォルトの名無しさん
22/02/22 13:10:26.52 gqoJFVcX.net
Javaは言語登場から10年くらいで多くの人が利用してたし開発環境も続々でとような。
316:デフォルトの名無しさん
22/02/22 13:12:29.23 G6nBeheJ.net
明らかな嘘だけになったなｗ
317:デフォルトの名無しさん
22/02/22 13:38:49.42 FcgRLtLU.net
>>307
好きなの、残らず持ってってええぞ
URLﾘﾝｸ(jp.indeed.com)
318:デフォルトの名無しさん
22/02/22 21:22:01.94 y2qiytj8.net
>>306
置き換え元のコードが酷かったんじゃね。C++のコードとかだいたい酷いし。
319:デフォルトの名無しさん
22/02/22 21:38:20.03 Uj7UhjXB.net
現役プロダクトのコードを別言語に置き換えるのってrustに限らず大変なのでは
全面的な置き換えはプロダクト全体の再開発に等しい
特定の担当に押しつけるのではなくチーム全体で徐々に新規部分から置き換えた方が成功率高そう
320:デフォルトの名無しさん
22/02/22 21:54:32.13 B2H8wIkZ.net
>>314
> C++のコードとかだいたい酷いし。
×だいたい酷い
○すべてが酷い
◎すべてがゲロ以下に酷い
321:デフォルトの名無しさん
22/02/22 21:55:58.40 WirMN8li.net
一般的にコードを『置き換える』という気構えだと失敗
少なくとも移植先の言語に合わせて何らかの内部設計のし直しからが最低限のスタート
目的が効率アップにあるなら並行や並列が設計として入ってくるだろうし
目的がGC無くしてメモリ省力化だけであってもデータ構造の見直しは必須など
322:デフォルトの名無しさん
22/02/22 22:33:06.33 dVa/srT8.net
ねえねえ
ベクタの特定のターゲットの添え字を返すfind(v, target)を作ったとして、
ターゲットが見つからなかった場合のエラー処理はどうするのが良いと思う？
C/C++だと返り値を整数にして-1だったら見つからなかった、と言う感じが多いと思うんだけど
Result<usize, &str>とかにしてエラー内容を表す文字列を返しちゃう？
323:デフォルトの名無しさん
22/02/22 22:36:39.92 Uj7UhjXB.net
>>318
標準ライブラリの関数を使う
324:デフォルトの名無しさん
22/02/22 23:06:43.66 WirMN8li.net
>>318
まずRustではそういうのはベクタに対して実装せずにスライスに対して実装する
次にRustではそういったものにはResultではなくOptionを返す
最後にそのような機能は標準ライブラリを使えば色んな意味で間違いがない
325:デフォルトの名無しさん
22/02/23 00:15:24.41 3kJCLKpV.net
>>319
>>318
あ～Optionなんてのがあるのね・・・
326:デフォルトの名無しさん
22/02/23 09:54:11.97 vCUIsgzX.net
usize, &strってすでにRustだろ
URLﾘﾝｸ(doc.rust-lang.org)
URLﾘﾝｸ(cpprefjp.github.io)
どうでもいい
327:デフォルトの名無しさん
22/02/23 10:10:32.07 kNrPH1ZT.net
>>98
しかしC言語技術者は求人市場では圧倒的に不足していると言われてる
どこにいるんだか
328:デフォルトの名無しさん
22/02/23 12:37:36.24 a0AIymqn.net
「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」とMiller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
URLﾘﾝｸ(news.yahoo.co.jp)
329:デフォルトの名無しさん
22/02/23 12:44:28.80 vCUIsgzX.net
>>324
同記事の引用
『プログラムをRustで書き換えることで、サービスは10倍速くなり、レイテンシーも大幅に短縮された。サーバーの数を減らすことができたので、結果的にエネルギー消費量も減少した。
「エネルギー効率の高い言語はRustだけではなく、昔からあるC言語もエネルギー効率は高い。しかしRustは安全性を犠牲にすることなく、省エネ化を実現した初めてのメインストリームのプログラミング言語だ。CやC++で書かれたプログラムが抱える深刻なセキュリティ脆弱性の70％は、メモリー安全性の問題に起因している。それに対して、Rustは安全性の問題を抱えていると感じることなく、エネルギー効率を高められる」とMiller氏は言う。
しかし、Rustにも習得の難しさをはじめとする課題はある。
経験豊富なエンジニアでも、Rustを使いこなすまでには、この分野に詳しい専門家のサポートを受けながら、3～6カ月の学習期間が必要だとMiller氏とLerche氏は言う。「Rustの習得を、野菜嫌いの克服に例えるエンジニアもいる。使いこなせるようになれば好きになる人が多いが、多くのエンジニアはそうなる前に見切りをつけたり、あきらめたりする。Rustは持続可能性とセキュリティに影響する可能性があるが、その力を発揮するためにはまず、ブロッコリーをブラウニーに変えなければならない』
330:デフォルトの名無しさん
22/02/23 14:27:22.03 1qABUjpC.net
コンピューターのエネルギー効率が高い代わりに人間の効率が下がるんですがそれは
331:デフォルトの名無しさん
22/02/23 14:41:11.80 lP5I9oG+.net
コンパイル時にめっちゃエネルギー使ってる
Tier 1のプラットフォームの最新数バージョンくらいはバイナリ配布する仕組みがcargoに必要
332:デフォルトの名無しさん
22/02/23 14:42:22.66 0x8HcgAm.net
>>326
まぁ作ったあとの稼働と運用考えたら総じてプラスになるでしょ。ならない？
333:デフォルトの名無しさん
22/02/23 15:38:19.82 5Q12euAa.net
>>326
一定規模超えたら一気に効率上がるぞ
334:デフォルトの名無しさん
22/02/23 16:55:23.95 +3d31FNr.net
>>326
これよく言われるけど言語による生産性の差って定量的にデータ集められてるのかな
335:デフォルトの名無しさん
22/02/23 17:27:51.83 1qABUjpC.net
メンテナンスフェーズに入ったとしても、人件費より電気代の方が高くなるようなことってなかなかなくね？
そんな大成功を納めたサービスってどれくらいあるんだろうな
336:デフォルトの名無しさん
22/02/23 17:29:51.77 Q7pYnx45.net
>>329
そうそう。
昔はJavaでやろうとしても人材不足でリプレースできなかったけど今は余裕で集められるもんな