Rust part9

**デフォルトの名無しさん** · 2020/08/23(日) 01:07:35.52

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust part8
https://mevius.5ch.net/test/read.cgi/tech/1579834072/

**デフォルトの名無しさん** · 2021/02/10(水) 08:39:46.46

それAppleに言えよ…

**デフォルトの名無しさん** · 2021/02/10(水) 09:32:21.19

craneliftがあるじゃん
デバッグビルド向けだけど

**デフォルトの名無しさん** · 2021/02/10(水) 09:36:57.75

コンパイラはrust自身で作られてるからそのうちそうなるんじゃね？

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

>>658
Appleは重要なパトロンではあるけど関心はApple以外誰も興味無い
キメラ言語のObjective-Cを守る一点だけだろ

**デフォルトの名無しさん** · 2021/02/11(木) 01:31:10.60

>>657
というかC++をちゃんと使いこなしている人は、Rustが便利だとは思えない人が多い
のでRust化する動機が無い。

**デフォルトの名無しさん** · 2021/02/11(木) 02:06:38.13

>>662
>>627てこと？

> 小さいプロジェクトならRustは
> ・生ポインタ使わない
> ・できる限りSTLを使う
> ・const、moveをデフォルトで使う
> ことにしたC++に敵わないような
> C++の方が柔軟だしず～っと短く書けるし

**デフォルトの名無しさん** · 2021/02/11(木) 02:10:08.49

>>663
むしろ、STLがクソすぎるのがC++が嫌われる原因。
C++は、STLを使わずに独自templateライブラリを使うのが便利。

**デフォルトの名無しさん** · 2021/02/11(木) 02:23:45.58

>>664
「使いこなす」がレベチ過ぎてワロシ
コンテナとアルゴに関しては俺もSTL使う方が良いと思ってたわ
vector<bool>とか、難のある仕様があるのは理解してたがそういうのに個別に対処すれば十分だろうと

リーナスとかもSTLが大ッ嫌いだという記事をよく見るが、具体的にどこを毛嫌いしてるのか俺は理解していない

**デフォルトの名無しさん** · 2021/02/11(木) 03:22:28.69

いつもの爺だよ

**デフォルトの名無しさん** · 2021/02/11(木) 10:32:11.70

そりゃOSレベルで見たらメモリの使い方がラップされるようなライブラリは使わんだろ。
馬鹿でもわかる話だと思ってたがそうでもないのか。

**デフォルトの名無しさん** · 2021/02/11(木) 10:55:34.35

むしろ C++ のつらさを知ってないと Rust の良さは (悪さもだが) わからんだろ。

**デフォルトの名無しさん** · 2021/02/11(木) 12:17:58.13

>>667
それ言ったらC++のCじゃない部分は全部ダメじゃね

**デフォルトの名無しさん** · 2021/02/11(木) 12:18:18.96

STLに限らず

**デフォルトの名無しさん** · 2021/02/11(木) 12:38:34.69

>>669
そうだよ
「OSを実装するためには」という条件ではね

**デフォルトの名無しさん** · 2021/02/11(木) 15:13:11.82

>>669
STLはCの良さを台無しにするような傾向がある。
C++の言語仕様自体は適切に使えばそのようなことはない。

**デフォルトの名無しさん** · 2021/02/11(木) 15:46:32.06

>>672
> STLはCの良さを台無しにするような傾向がある。
これは観念的な話？
パフォーマンス的には、もちろん不要なコピー等は避けるという前提のもとで、同じなのかなって思ってたんだけど

> C++の言語仕様自体は適切に使えばそのようなことはない。
適切というのは、C with class として使えば、ということ？

**デフォルトの名無しさん** · 2021/02/11(木) 16:26:39.58

>>672
STL というものは C++ の中にはない。

**デフォルトの名無しさん** · 2021/02/11(木) 16:31:10.44

C++ の標準ライブラリは C 的な良さを殺さないように配慮しまくってるから
抽象化層で抽象化しきれずにイビツになってるんで、
出来が良いとは思わんが C の良さを台無しにしてるとは思わんな。

**デフォルトの名無しさん** · 2021/02/11(木) 16:32:15.96

>>675
そう思ってるならあなたも設計者の頭の出来も馬鹿。

**デフォルトの名無しさん** · 2021/02/11(木) 17:01:42.79

他所でやれ

**デフォルトの名無しさん** · 2021/02/11(木) 17:04:12.74

>>662
MozillaもGoogleもMSもC++を使いこなせないからRustを支援してるって主張か？

**デフォルトの名無しさん** · 2021/02/11(木) 17:27:06.59

>>678
Mozillaなんか独占禁止法違反を誤魔化すためのGoogleの下請けに過ぎないので
レベルの高いプログラマはもはやいないし、MSやGoogleは巨大すぎるので
できそこないのプログラマも多い。

**デフォルトの名無しさん** · 2021/02/11(木) 17:42:02.28

おじいちゃんの想像力が凄すぎる

**デフォルトの名無しさん** · 2021/02/11(木) 19:00:14.15

トランプ好きそう

**デフォルトの名無しさん** · 2021/02/11(木) 19:04:26.47

>>679
なるほど、Mozillaのプログラマは全員レベル低いしGoogleやMSでrustに関わってる人も全員出来損ないという主張なのね

**デフォルトの名無しさん** · 2021/02/11(木) 19:17:51.67

ダニング＝クルーガー効果

ダニング＝クルーガー効果とは、能力の低い人物が自らの容姿や発言・行動などについて、
実際よりも高い評価を行ってしまう優越の錯覚（英語版）を生み出す認知バイアス。
この現象は、人間が自分自身の不適格性を認識すること（メタ認知）ができないことによって生じる。
1999年にこの効果を定義したコーネル大学のデイヴィッド・ダニング（英語版）とジャスティン・クルーガー（英語版）は、
「優越の錯覚を生み出す認知バイアスは、能力の高い人物の場合は外部（＝他人）に対する過小評価に起因している。
一方で、能力の低い人物の場合は内部（＝自身）に対する過大評価に起因している。」と述べている。

**デフォルトの名無しさん** · 2021/02/11(木) 19:50:13.66

いつもの爺だって言ってんのに

**デフォルトの名無しさん** · 2021/02/11(木) 20:05:54.55

>>675
抽象化しきれてないというのは、実装の話？
それともインターフェースの話？

**デフォルトの名無しさん** · 2021/02/11(木) 20:11:37.99

ここはC++のスレじゃないので他所に行ってね

**デフォルトの名無しさん** · 2021/02/11(木) 20:55:43.37

>>685
インターフェイス (仕様) の話だけど実装の話でもある。

たとえば C++ では vector の大きさが変わったら (それの要素を指す) イテレータは一斉に無効になって
コンパイル時にも実行時にも捕捉されない (捕捉することを保証しない) のは
明らかに vector の実装の都合を想定していて、
仕様を満たす範囲で効率的に実装すれば (vector の) イテレータの実体はポインタ一個になる。

C++ の標準ライブラリは C で出来ること、 C の習慣の見栄えを変えているに過ぎないし、
そうなるようにデザインされている。

実装がどうなっているかが透けて見えるような仕様になっているという意味で抽象化がしきれていないと書いた。

**デフォルトの名無しさん** · 2021/02/11(木) 21:35:06.01

>>676はクソか馬鹿。理由は説明しない。

**デフォルトの名無しさん** · 2021/02/11(木) 23:40:49.80

>>687
ありがとうございます
為になります

でもそれは裏を返すと、パフォーマンス的にはCと同等の効率で実装されていると思って良いんですかね？
（ただしラップしていることのオーバーヘッドはある？）

**デフォルトの名無しさん** · 2021/02/12(金) 00:55:03.10

>>668
学術的な言語理解ならその通りだが、言語習得という意味では寧ろ逆ではないかと
C++の瘴気に毒された民は清浄の地には住めない体になってる

**デフォルトの名無しさん** · 2021/02/12(金) 01:08:51.70

>>689
完全に成功していると言い切れない部分はあるかもしれないけど、
実行時に処理すべきことが同じならクラスやらテンプレートやらでラップしても
C と C++ でほとんど差は付かないよ。
少なくとも現代的な処理系で最適化を有効にして比較した場合には。

**デフォルトの名無しさん** · 2021/02/12(金) 01:20:11.09

>>690
それはどうだろう。
俺はアマチュアだがそれでも C++ を二十年以上触ってきた感覚で言えば
Rust はかなり良いという印象なので、 C++ のグダグダさに
うんざりしてる人は結構いるんじゃないか？

C++ の自由さを楽に感じている部分もあるんだが、結局はツギハギだからなぁ。
理念的な良し悪しを置くとしても長期にわたって機能を増やしていれば
一貫性のないところだっていっぱい出てくるのは仕方がないことで、
どこかで時代をリセットしてやり直す必要はあるんじゃないかと思う。

俺にとってはそれが Rust って感じ。

**デフォルトの名無しさん** · 2021/02/12(金) 07:21:37.77

test

**デフォルトの名無しさん** · 2021/02/12(金) 15:00:39.40

rustももう十分一貫性ないだろ。c++リセットしたい割に同じ道行ってるのがどうしようもねーなという印象。

**デフォルトの名無しさん** · 2021/02/12(金) 15:46:07.19

だからお気持ちはいいから具体例を挙げろよ

**デフォルトの名無しさん** · 2021/02/12(金) 16:25:53.42

>>694
一貫性が壊れてきてるというのはわかるよ。
でも、それを繰り返すもんだという諦めがあるから、
Rust がグダグダになりきったらまた新しい何かが登場するだろうと期待して今は Rust ってこと。
C++ の状況をなぞるならこれから 15 年か 20 年くらいはなんとかなるだろ。それで十分だ。

>>695
以前のスレでも書いたような気がするが、
is_alphabetic の引数は self なのに is_ascii_alphabetic は &self だったりするとかみたいな
微妙な歴史的経緯がちょろちょろと見え隠れする。

個別に見れば重要ではないんだけど、
そういうどうでもいいことの積み重ねが全体としてのいびつさになる。
かといってそこらへんを綺麗に整理しつづけるために互換性を失うようでも
受け入れられなかっただろうというのもあるので、
そこらへんは本当にしゃーないんだわ。

**デフォルトの名無しさん** · 2021/02/12(金) 18:51:43.73

エディションで定期的にリセットする仕組みが機能するかどうかは興味あるな
Rustで初めて挑戦する感じだから、良い感じに機能するのはさらに次世代の言語になるだろうけど

◆QZaw55cn4c · 2021/02/12(金) 23:17:05.75

>>687
＞実装がどうなっているかが透けて見えるような仕様

私はむしろ、実装が透けて見えるのが王道だとおもっていたのですが、あなたのいう「抽象性」というのが私の感覚とは違うのかもしれませんね
抽象性を徹底して理解するためには、どんな勉強をすればいいのでしょうか？

◆QZaw55cn4c · 2021/02/12(金) 23:18:50.55

>>692
＞C++ のグダグダさにうんざりしてる人は結構いるんじゃないか？

私はまだ経験が浅いのかもしれませんが、そんなに C++ がグダグダだとは思っていません
どういうところがグダグダなのか例示していただけるとありがたいです‥‥

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/13(土) 11:09:55.70

>>698
抽象というのは、要は余計な要素をそぎ落とすという話なので考え方によっては
どこが余計なのかというのは変わりうるけども、仮に vector の本質を
「縮小・伸長可能な配列」であると考えるならば
　・要素が隣り合う
　・要素アクセスのコストのオーダーは O(1) である
といった性質は本質に付随する性質として受け入れられる。でも、
　・配列を伸ばしたらイテレータが無効になる
という仕様は
　・配列の大きさを変えるのをメモリの確保しなおしで実現する
　・イテレータの実体はポインタ一個である
という実装上の理由 (を想定している) なので、抽象化の漏れだと思う。
イテレータをコンテナ (の参照) とインデックスの組で実装すれば回避可能なわけだし。
でも C++ の標準ライブラリでは C の価値観を以て抽象化よりも実行効率を優先するという選択をした。

繰り返すけど、これは何を本質とみなすかという見方によって変わりうるので、
考え方によって詳細は変わるかもしれないということには注意。
　・対象は何である (ように見せている) か？
　・対象がそう見せようとしている通りに使えるか？
　・その上で対象がそう見せかけようとする以外の部分 (実装の都合) を「忘れられる」か？
というのがライブラリが持つ抽象性。
カプセル化で大事なのは情報隠蔽だというのをどっかで読んだことくらいあるでしょ。
余計なことは見せないほうがいい。

んで、私 (>>687) にとっては vector のメモリ管理の都合は (少なくとも必要になるまでは)
忘れていたい余計なことだと思えるということ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/13(土) 11:21:51.89

>>699
特にいびつさを生み出している例はヘッダファイルかな。
ソースファイル (.c) がひとつのモジュールとして機能して
ヘッダファイルがモジュールの外に向けたインターフェイスとして機能する
というのは C の世界ではまあまあ上手くいっているのだけど、
ヘッダファイルに定義を書くようになってから役割の境界が破綻してきた。

従来の C の世界では「定義はどこかのコンパイル単位に属す」という前提があったが、
ヘッダ内での実装 (テンプレートやインライン関数) ははっきりした所属がない。
テンプレートαがテンプレートβを使っていてソースファイルγでαを使いたければ
γ内からβも見えてしまうので隠蔽しきれない。 (カプセル化の破綻)

C++er にとってモジュール機能の導入が悲願のひとつと言われ続けていたのは、
ヘッダファイルという仕組みが理由になっている色々なグダグダの解消につながることが
期待されていたからだよ。
C++20 でとりあえずモジュールが導入されたけど色々な機能をモジュールを前提
にしたものに置き換えて古い仕組みがフェードアウトするまではまだまだグダグダする
だろうけどな。

ところでこれ以上は Rust スレで C++ の話を続けるとうっとうしがられるので、
質問があればこれ以降は C++ スレで。

**デフォルトの名無しさん** · 2021/02/13(土) 12:33:21.13

板違いでしたらすみません。
カスタムSMGでリロードしても
弾が装填されません。
弾はピストル弾であってますよね？
バグですかね
よろしくお願いします

**デフォルトの名無しさん** · 2021/02/13(土) 12:36:25.47

板違いでしたらすみません。
カスタムSMGでリロードしても弾が装填されません。
ちなみにピストル弾です。
バグですかね
よろしくお願いします。

**デフォルトの名無しさん** · 2021/02/13(土) 12:37:34.81

わかりにくいボケ

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/13(土) 12:45:41.52

たぶんこれとひっかけたネタ
https://store.steampowered.com/app/252490/Rust/

**デフォルトの名無しさん** · 2021/02/13(土) 13:05:51.12

鉄道やデジカメ、プログラム、ゲームの板のスレって
いつも無関係な話題で罵りあってるよね
これらの板って何か変な物を吸引するのだろうか

**デフォルトの名無しさん** · 2021/02/13(土) 13:33:02.22

→704
ボケ言うなカス

**デフォルトの名無しさん** · 2021/02/13(土) 14:06:11.02

▷707
なんじゃワレやるんかコラ

**デフォルトの名無しさん** · 2021/02/13(土) 14:49:42.47

pythonのモジュール作成者にもっとrustの利用が促進されればいい感じになりそうな気がする

**デフォルトの名無しさん** · 2021/02/13(土) 19:30:22.42

はっきり言って邪魔でしかない

**デフォルトの名無しさん** · 2021/02/13(土) 19:58:39.56

>>709
Rust 使えるなら Python 要らないだろ。

**デフォルトの名無しさん** · 2021/02/13(土) 20:30:02.97

プラグインとしてのwasmは流行りますか？

**デフォルトの名無しさん** · 2021/02/13(土) 21:46:14.79

>>712
可能性は十分にあると思う。

**デフォルトの名無しさん** · 2021/02/13(土) 23:21:08.34

wasmはWebブラウザだけでなく、令和のJavaアプレットのように Write once, run anywhere を標語に
あらゆる目的で使われるようになるよ

**デフォルトの名無しさん** · 2021/02/13(土) 23:57:58.78

ちょっとしたやつでもファイル容量大きくなるからまだ無理
さらにいえばjsでもgpu使えるから並列計算ならそれ使えばいいし、wasmの用途は限られる
将来的に5gとかで通信速度上がったら使われるようになると思う

**デフォルトの名無しさん** · 2021/02/14(日) 00:05:54.10

今、5GのEdge Computingがwasmの適用範囲として最も注目されている領域

**デフォルトの名無しさん** · 2021/02/14(日) 10:45:44.60

wasmバブルってのはちょっと考えにくい

**デフォルトの名無しさん** · 2021/02/14(日) 11:17:05.02

泡沫の夢という意味かもｗ

◆QZaw55cn4c · 2021/02/15(月) 00:18:35.54

>>700
＞・配列を伸ばしたらイテレータが無効になる
＞という仕様は
＞　・配列の大きさを変えるのをメモリの確保しなおしで実現する
＞　・イテレータの実体はポインタ一個である
＞という実装上の理由 (を想定している) なので、抽象化の漏れだと思う。

ふむふむ‥‥抽象化といってもいろいろあるんですね‥‥

＞イテレータをコンテナ (の参照) とインデックスの組で実装すれば回避可能なわけだし。

私はイテレータはポインタの読み替えだと決め付けていたので、こういうイテレータの実装はちょっと抵抗がありますね
コンテナへの参照とインデックスを組みするとなると、これはスレッドセーフのことを考えないといけないな、と、どうしても思ってしまいます
そういうこと、すなわち必要に応じて重たいけれどもスレッドセーフにするか、それとも単一スレッド内の話だから軽く書きとばすか、というのはアプリケーション側の裁量だと思っています
言語標準で最初から「スレッドセーフにしました！」というのは、C/C++ 的にはイマイチではないかな、と

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/15(月) 01:57:36.14

>>719
> C/C++ 的にはイマイチではないかな、と

そうだよ。
C++ が C 的な考え方から離れなかった (他の方針も取れたのに) という話をしてる。
C/C++ 的にイマイチになる例を出したんだからイマイチだよ。

**デフォルトの名無しさん** · 2021/02/15(月) 02:16:06.50

WebAssemblyで書かれたアプリはあるんですか？

**デフォルトの名無しさん** · 2021/02/15(月) 03:28:26.27

喧嘩売りたいわけじゃないんですけど、Rustって明示性を重視してますよね、mutとか、所有権とか
でもそのくせ式としてreturnを省略できたり、でも例外はないからOptionやResultが普通でunwrap
しなくちゃならなかったり、でも>>505-508のようにメモリモデルの（まだ）定義がなく?、>>333
みたいな暗黙の再借用が出来たり色々ちぐはぐな気がするんですが、1.5、2.0辺りになったら大幅に
変わったりしますか？足を撃ち抜かないCPPとしては「良い」出来だと思うんですが、、正直、ほんの
ちょっと触ってみてCargoコンパイルが重くて、特徴の明示的など非常にめんどくさいんですがそういうもの？
C++20やC++23なんてありますが正直、もう時代の役目を終えたと感じます。いくら色々な機能を追加しても
能力次第で足を撃ち抜く事には変わりなく、そのような用途であるカーネルさえ古典的な安定したC、C++を
使いますよね。RustがWebkitを倒せたらほとんど使いどころがないような？

それと恐らく借用があるのでGCは搭載・あるいはON/OFFされないとほぼ確実に思いますが、async
awaitな非同期ではくGoのようなライトウェイトなGoroutineみたいなのが搭載される計画はありますか?
余談ですがLinux-kernelやドライバに使われると聞いているので、（標準的・言語的にはランタイムに入る事は）
無いんだと思ってますが、Goも例外は無いけど、なんであの界隈はブロック例外がアンナにも、お嫌い
なんでしょうかね？ちなみに最近、Nimというのを触ってとても感銘を受けました。

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/15(月) 04:42:37.54

>>722
これはきちんと議論を追っているわけではなく私なりの理解だということを事前に断っておくけど、
(unsafe を除いて) メモリ管理のチェックが自動化できることが最重要の指針だと思う。

チェックするにあたって必要な情報が多いから結果的にたくさんのことを明示する必要があるけど、
曖昧さがないなら明示する必要はないし、
実際の利用でほとんど常に同じような指定をしているならそれをデフォルトにして違うときだけ指定するのでも問題にならない。

**デフォルトの名無しさん** · 2021/02/15(月) 09:10:14.02

>>722
単に明示性を重視してるというよりは、分かりにくいとか非推奨とか高コストなとこは明示して
そうでないとこは省略させたいように見えるな。
例えば関数の型なんかは技術的には省略して推論できるけど
分かりにくくなるからあえて書かせるとか。
なのでreturnは自明だけどResultはちゃんと処理させたい、
という考え方かと。

goroutineみたいなのはまず入らないだろうね。
そもそもなるべく標準ライブラリは小さくする方針だし、
現状でもrayonみたいな並列処理ライブラリ使えばいいし。

**デフォルトの名無しさん** · 2021/02/15(月) 14:18:13.02

>>723 >>724
なるほど、スペシャルサンクスです！メモリ管理のチェックを”最”重要視してるわけで、あまり煩雑な明示
及び、高コストな明示はしない方針だろうという事ですね。ドライバーやカーネル、OSコマンドに使われて
セキュリティホールが一掃される日が早く来てほしい。
並列処理でrayonというのがあるんですか！教えてくれてありがとうございます。確かにライブラリというか
C++のようなRTLは小さくしてほしいですね。Goのようにデカすぎるのは組み込み用途に向かないので。

**デフォルトの名無しさん** · 2021/02/15(月) 18:15:16.43

goroutineの代替ならtokioとかasync-stdみたいな非同期IO系のランタイムも外せないのでは
goroutineの並列と並行のどっちの側面について言ってるのか次第ではあるけど

**デフォルトの名無しさん** · 2021/02/15(月) 18:57:38.65

asyncではなく、って言ってるのでrayonとかの方が近いかな、と。
まぁどっちにしてもgoroutineそのものなモデルを提供するライブラリは多分ないので
各自必要な並列並行性に応じたライブラリを選ぶ必要はある。

**デフォルトの名無しさん** · 2021/02/15(月) 22:30:19.90

RustにあってC++にない機能はありますか？

**デフォルトの名無しさん** · 2021/02/15(月) 23:16:52.31

>>728
memory safety

**デフォルトの名無しさん** · 2021/02/15(月) 23:34:00.74

リージョン推論とアフィン型

**デフォルトの名無しさん** · 2021/02/15(月) 23:35:54.84

勢い

**デフォルトの名無しさん** · 2021/02/16(火) 00:39:31.16

若者

**デフォルトの名無しさん** · 2021/02/16(火) 01:35:01.04

hygenicなマクロやproc macro

**デフォルトの名無しさん** · 2021/02/16(火) 14:47:28.42

初心者

**デフォルトの名無しさん** · 2021/02/16(火) 19:09:01.10

LinuxカーネルをRustで書こうとかいう話が去年出てたけど、
社会のインフラにもなってるようなカーネルの開発者が考えてることと
プログラミング言語で遊びたい人の考えてることが違いすぎて萎えた

しょせん、プログラミング言語なんてアセンブラとC以外は全部遊びだよね
安かろう悪かろうの遊びレベルの仕事に金払う会社があるから勘違いされやすいけど

**デフォルトの名無しさん** · 2021/02/16(火) 19:18:56.90

JAVAも遊びってマジ！？

**デフォルトの名無しさん** · 2021/02/16(火) 19:36:38.83

COBOLも遊びだそうです

**デフォルトの名無しさん** · 2021/02/16(火) 19:47:40.11

遊びで生まれた子供がなんか言ってらｗ

**デフォルトの名無しさん** · 2021/02/16(火) 20:07:29.86

今はカーネルモジュールを対象にRustをサポートする予定みたい
ABIとかメモリ管理まわりの差異の吸収をどうするか一番熱いところをやってるね
https://lwn.net/Articles/829858/

**デフォルトの名無しさん** · 2021/02/16(火) 20:25:37.08

C/Ruby 併用のmruby の本が出た。
文字列処理などは、GC のあるRuby側で書く

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

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

人工衛星イザナギ・イザナミでも、使っている

**デフォルトの名無しさん** · 2021/02/16(火) 21:11:02.07

なぜここで宣伝？

**デフォルトの名無しさん** · 2021/02/16(火) 22:20:14.90

そいつただのキチガイだから聞いても無駄だぞ

**デフォルトの名無しさん** · 2021/02/16(火) 22:40:03.47

>>735
LinuxもC言語ももとはと言えばスペーストラベルってゲームで遊びたくてLinuxの前身のUNIXが作られたし、そのゲームを移植するためにB言語がつくられて、
さらにそれを改良したのがC言語だ。

**デフォルトの名無しさん** · 2021/02/17(水) 00:07:57.00

ここにも出没するのか…

**デフォルトの名無しさん** · 2021/02/17(水) 00:30:02.75

なるほど。いろんなスレで同じこと書きまくってんのな

**デフォルトの名無しさん** · 2021/02/17(水) 02:18:16.85

>>743
Cが遊びにも使えることを主張しても反論になってないぞ

**デフォルトの名無しさん** · 2021/02/17(水) 03:00:38.28

推奨NGワード： ruby

**デフォルトの名無しさん** · 2021/02/17(水) 11:52:49.70

RUSTはウェブとかAI分野でのバブルは考えにくい

あるとすればIOTやら組み込み向けだろう

**デフォルトの名無しさん** · 2021/02/17(水) 13:28:23.14

金融でHaskell流行ったみたいな感じでrust流行ったりしないかね

**デフォルトの名無しさん** · 2021/02/17(水) 13:40:51.06

そもそもそんなに流行ってほしいか？
インフラとかライブラリとか地味なところで
ひっそりと使われるのが適してると思うけど。

**デフォルトの名無しさん** · 2021/02/17(水) 18:07:12.21

利用者増えた方が投資も増えて進歩が速くなるから

**デフォルトの名無しさん** · 2021/02/17(水) 20:57:43.14

今の様子じゃ10年経ってもなんも変わらんだろ。先のある言語じゃない。

**デフォルトの名無しさん** · 2021/02/17(水) 21:22:18.90

システムプログラミング分野ではC++からRustに変わっていくんじゃないの？

**デフォルトの名無しさん** · 2021/02/17(水) 21:34:22.05

GAHUMが採用し出して団体まで作ったのに先がないなんてどんな世界観なんじゃ

**デフォルトの名無しさん** · 2021/02/17(水) 22:03:18.40

Rustが流行らなくてもRustの考え方を取り入れた言語が広まってくれればいいな

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/17(水) 23:46:21.75

やりたいことが出来るライブラリ (クレート) があるなら
言語の詳細がどうでもよくなりがちってのはあると思う。

**デフォルトの名無しさん** · 2021/02/18(木) 00:18:21.59

コンストラクタ、構造体のめんどくささ考えても絶対流行らんわ。
根本的におかしい言語機能なんだよ。

**デフォルトの名無しさん** · 2021/02/18(木) 01:33:00.72

プログラマーって人と違った事が好きな尖った奴のイメージがあるけど、実際は
寄らば大樹の陰で巨人が採用したプログラミング言語に従うのが吉なのだ。