次世代言語27 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/08/05(金) 08:26:38.87

スレタイ以外の言語もok

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1655771266/

**デフォルトの名無しさん** · 2022/08/13(土) 05:34:22.29

>>335
終わりの始まり。

**デフォルトの名無しさん** · 2022/08/13(土) 06:07:19.25

Rustで出来てる有名なソフトって何かあるの？

**デフォルトの名無しさん** · 2022/08/13(土) 06:28:22.11

AWSだけでなくLinux OSもAndroid OSもRustを採用したから終わりの始まり

**デフォルトの名無しさん** · 2022/08/13(土) 07:38:54.55

あくまでも適してるのは低レイヤー

**デフォルトの名無しさん** · 2022/08/13(土) 08:13:13.08

Linux OSもAndroid OSもCで書かれてる。

**デフォルトの名無しさん** · 2022/08/13(土) 08:17:14.35

Rustで書かれてるメジャーなOSって何かあるの？

**デフォルトの名無しさん** · 2022/08/13(土) 09:28:15.05

あったら何なの？無かったら何なの？
関係ないんだよお前には

**デフォルトの名無しさん** · 2022/08/13(土) 09:42:57.35

なんかGoもRustも違うんだよな～
求めてる言語じゃないっていうか
Cをベースにして欲しいんだよ俺は
C++は論外

**デフォルトの名無しさん** · 2022/08/13(土) 09:49:20.23

Rubyはどうだい？

**デフォルトの名無しさん** · 2022/08/13(土) 09:55:35.86

>>325
メモリ安全を売りにしているRustだから、メモリアロケータもRust製に拘った方が良いとかは無い？

**デフォルトの名無しさん** · 2022/08/13(土) 09:58:00.87

>>343
C#をネイティブコンパイルで

**デフォルトの名無しさん** · 2022/08/13(土) 10:00:10.89

■Rust使用実績
<OS>
- Linux
- Android

<基盤、ミドルウェア>
- AWS

<アプリケーション>
- Firefox

<Webアプリ>
- Cookpad
- Dwango

**デフォルトの名無しさん** · 2022/08/13(土) 10:16:01.13

WebアプリでRust使ってるやつはバカそのもの

**デフォルトの名無しさん** · 2022/08/13(土) 10:45:37.81

■Goの使用実績

https://github.com/golang/go/wiki/GoUsers

**デフォルトの名無しさん** · 2022/08/13(土) 11:10:16.71

GCがメモリ解放を「遅延」する特性を
プログラミング全般に応用した遅延評価は
GCの失墜を象徴する芸術作品なんだよ

**デフォルトの名無しさん** · 2022/08/13(土) 11:30:18.26

>>350
メモリ解放の遅延と評価の遅延は対象も効果も目的も違うだろ。

同一視するのはさすがに無知過ぎない？

**デフォルトの名無しさん** · 2022/08/13(土) 11:41:11.76

GCが適さない環境でメモリ管理するいいやり方が所有権システムってだけなのでは？

GCが特に問題ならない環境でその所有権システムをわざわざ利用するメリットは？

**デフォルトの名無しさん** · 2022/08/13(土) 11:45:26.29

Haskellの場合は構文木のグラフ簡約がなければGCのグラフ探索もほとんど不要だよね

**デフォルトの名無しさん** · 2022/08/13(土) 11:56:00.20

>>352
静的型付けとか所有権とかは
難しいものでもなく慣れだけで簡単で
実際に使っていると大した手間も無く
メリットばかりが得られるんだよ

コンパイル時点で静的に全て決まるから
実行時にその分の無駄なデバッグなども不要
どの分野とか全ての分野で同じ

更にオマケとして
高速と省メモリが付いてくる
もちろん安全性も付いてくる

**デフォルトの名無しさん** · 2022/08/13(土) 12:17:05.15

>>352
エコ

**デフォルトの名無しさん** · 2022/08/13(土) 12:27:39.76

信者曰くデメリットなくてコストもかからずメリットしかないらしいけど
競プロでもISUCONでも全然人気ないし、エンタープライズでもほとんど見ないね

**デフォルトの名無しさん** · 2022/08/13(土) 12:38:30.52

UnityがC#からRustに乗り換えでもしたら、
私でもRustを扱える難易度かもしれない。

**デフォルトの名無しさん** · 2022/08/13(土) 12:44:13.20

そもそもGCがボトルネックになるケースって相当なレアだと思うんだけど
GCをなくしたいモチベーションがよくわからない

**デフォルトの名無しさん** · 2022/08/13(土) 12:53:11.09

GCかどうかはどうでもいい話

高速＆省メモリ
　だと
エコ＆利用者も快適＆リソース料金コストも安い

つまり良いこと尽くしなので高速＆省メモリを選ぶ
結果として非効率なGCは論外

**デフォルトの名無しさん** · 2022/08/13(土) 12:57:18.86

エンタープライズでは開発コスト重視するからRustはコストの観点では論外だね
開発メンバが抜けた時に継続してメンテできるか？新たな人材の確保は容易化？を最優先に考えるから

コストで有利に働くのはあくまでも個人開発の場合だね

**デフォルトの名無しさん** · 2022/08/13(土) 12:58:30.25

NoSQL最強でRDBは不要おじさんw
無知そのものw

**デフォルトの名無しさん** · 2022/08/13(土) 13:02:33.78

なにがし言語が使える人材、なんて人材の探し方してるの？
それでエンタープライズは笑う

**デフォルトの名無しさん** · 2022/08/13(土) 13:04:50.07

>>352
メモリ以外のリソース、コネクションやファイルハンドラやらも所有権の枠組みで管理できるので並列処理でリソース管理周りのバグを出したくなければRustが理に適ってるシーンもある。

GC付きの言語でメモリ以外のリソースをGC的に管理しようとする取り組みとか無いのかね。
tryで囲んだりdefer書くとかで責務をいつまでも書き手に委ね続けるのは言語設計者の怠慢だわ。

**デフォルトの名無しさん** · 2022/08/13(土) 13:07:30.57

イキってRustなんて使ったところで技術的負債になるだけ

あくまでもC++を置き換えるだけだからイキって採用しないようにしろよ

**デフォルトの名無しさん** · 2022/08/13(土) 13:07:51.86

エスケープ解析に触れないでGCと所有権を比較するのはさすがに無能すぎる。

あと、所有権に言及して設計の制約を無視する奴は詐欺師。
Rustはまず効率化のために制約の下でできる範囲で設計して、無理なら設計を破棄してやり直す(か、そもそもコーダーにやらせない)思想だろ。

**デフォルトの名無しさん** · 2022/08/13(土) 13:19:05.90

>>360
現実世界だと大手IT各社がRustを採用しているのはどうしてなの？

**デフォルトの名無しさん** · 2022/08/13(土) 13:23:30.97

>>363
デストラクタ内でポインタをいじる処理を許せばGCの性能が死ぬ

**デフォルトの名無しさん** · 2022/08/13(土) 13:35:35.80

>>363
C#のusingじゃだめですか

**デフォルトの名無しさん** · 2022/08/13(土) 13:36:08.73

>>367
メモリ以外のリソースを持つオブジェクトを型付けしてやって効率的にするとかできないもんかね。

何にせよRustの適用領域が狭いのは確かだけどハマる領域だとこれ一択レベルだろうな。

**デフォルトの名無しさん** · 2022/08/13(土) 13:40:47.26

>>369
Rustはほとんどの領域に向いている汎用的な言語
そもそも特定向け専用言語なんて非常に珍しい存在

**デフォルトの名無しさん** · 2022/08/13(土) 13:40:59.10

>>366
ヒント　低レイヤー　C++

**デフォルトの名無しさん** · 2022/08/13(土) 13:45:03.23

>>368
C#のusingやkotlinのuseが正解っぽい感じはするんだけど、GCみたいにそもそも普段は意識しなくて済む感じになってほしい。

**デフォルトの名無しさん** · 2022/08/13(土) 13:54:48.24

>>370
向いていると専用の違いがわからない馬鹿

**デフォルトの名無しさん** · 2022/08/13(土) 14:02:11.57

ここにあるファイルを末尾に日付を入れてネットワーク上のNASにコピーした後、削除し空ファイルを作ってください。
これをRustでやる奴はウンコ、普通にbashで書く

**デフォルトの名無しさん** · 2022/08/13(土) 14:06:21.25

Pythonの__del__の仕様を確認したらむちゃくちゃ大雑把だった
こんなのスクリプト以外で許されるわけねえだろ

**デフォルトの名無しさん** · 2022/08/13(土) 14:10:23.92

>>374
エラー処理の要件次第ではbashだと辛くなりそうな予感がするんですが

**デフォルトの名無しさん** · 2022/08/13(土) 14:19:49.12

>>372
普通にストリームとかを使いっぱにしとけばいいんじゃね？
まともな実装ならその変数がGCで回収される時にクローズされるだろ

**デフォルトの名無しさん** · 2022/08/13(土) 14:49:04.30

>>326
日本が伊達にIT後進国じゃないってことだよな

**デフォルトの名無しさん** · 2022/08/13(土) 14:51:34.28

>>343
zig

**デフォルトの名無しさん** · 2022/08/13(土) 15:27:52.15

>>374
それだとファイルの末尾だと誤読しうる
おそらくファイル名の末尾の意味だろう

そういう処理は用途によってはbashスクリプトも当然使っている
ただし色んなエラー処理をしだすとシェルスクリプトでは面倒なこともある

そのためプログラミング言語を使う場合もある
Rustを使っているものもある

**デフォルトの名無しさん** · 2022/08/13(土) 15:36:28.85

>>377
GCはいつ起こるかわからない
そしてその使い方ではGCが起きるまでクローズが遅延される

すると色んな問題が起こる
OSリソースがその間占有され続ける
占有オープンなら他者が利用できないなど

GC言語を使うなら面倒でもdeferやusingなどで明示的に後処理するしかないだろう
もちろんC++やRustならばRAIIにより即座に解放されクローズ処理もされるため面倒な記述は不要である

**デフォルトの名無しさん** · 2022/08/13(土) 15:40:18.08

>>381
> GCはいつ起こるかわからない
> そしてその使い方ではGCが起きるまでクローズが遅延される
そんなことは分かってるよw
話の流れくらい読めよ

**デフォルトの名無しさん** · 2022/08/13(土) 15:56:23.29

>>382
RAII言語の方が優秀だと認識できているならばよろしい

**デフォルトの名無しさん** · 2022/08/13(土) 16:14:32.90

>>383
アホなの？
C# の using も知らん無能はいちいち絡んでくるなよ

**デフォルトの名無しさん** · 2022/08/13(土) 17:08:08.82

>>384
君は>>381を最後まで読まずに
途中で反射的に書き込んでいると分かったのでもういい
反省しなさい

**デフォルトの名無しさん** · 2022/08/13(土) 17:28:21.83

NoSQL最強おじさん笑
RAII最強おじさん笑

**デフォルトの名無しさん** · 2022/08/13(土) 17:30:58.15

>>385
お前は>>372に既に書いてあることをアホみたいに再度書いてるから揶揄されてることも分からん知能しかないことがよくわかったよw

**デフォルトの名無しさん** · 2022/08/13(土) 17:33:59.86

>>375
そんな雑なものがたくさんあるのに、Rustにすべきなんて言う人とはいつ迄も平行線な気がするよね。

**デフォルトの名無しさん** · 2022/08/13(土) 17:41:30.08

>>363
それが怠慢とかｗ
どこでメモリ（リソース）を確保してどこで解放するかをプログラマが選択出来なきゃ
それこそ自由度が無く使いにくい言語になる
GCがあるから解放しなくてもいつかやってくれるから明示的に書かないという思想が
正しいと思っているならおかしい

**デフォルトの名無しさん** · 2022/08/13(土) 17:50:27.94

>>388
Rustやれぇとか命令されても
命令を無視する自由度のある人間はいちいち気にしない
命令無視しようが平行線だろうが何も問題ない

**デフォルトの名無しさん** · 2022/08/13(土) 18:03:09.67

useとかusingとかdeferとか
書き忘れていたら実行前にエラーとなってくれればいいんだけどね
忘れずに書いていることに依存させる言語仕様はよくないね

**デフォルトの名無しさん** · 2022/08/13(土) 18:12:50.43

GCは結局メモリとGCの二つを管理しなきゃいけなくなって非効率なんじゃないか？

**デフォルトの名無しさん** · 2022/08/13(土) 18:14:07.67

量子プロセッサ時代のプログラミング言語とか、意義のある会議は出来ないものか。

**デフォルトの名無しさん** · 2022/08/13(土) 18:42:16.49

ここ隔離スレなので特定のトピックに興味あるなら専用スレ立てた方が良いよ

**デフォルトの名無しさん** · 2022/08/13(土) 21:59:10.85

ファイルの自動クローズがRAIIで無条件かGCなので何らか明示指定かの話を見ていて思ったんだけど、
メモリの自動解放はこれまでGC言語だけの特権でGCにはデメリットもあれどメモリの自動解放という何もかもを上回るメリットが前面にあったのよね。
ところがGCがないのにメモリを自動解放するプログラミング言語が登場しちゃって危機感を覚える人も登場しちゃって、

**デフォルトの名無しさん** · 2022/08/13(土) 22:51:24.09

GCがない(?)のにメモリを自動解放するプログラミング言語は昔からありますが……C++と言いましてね。

C++で（Rustみたいに）スタックフレームに何でも押し込むスタイルにするとどうなるのかねぇ。

**デフォルトの名無しさん** · 2022/08/13(土) 23:40:22.03

重要なものがキャッシュに乗りにくくなるのでは？

**デフォルトの名無しさん** · 2022/08/13(土) 23:54:24.87

そもそもRustもC++も含め、RAIIは何でもスタックに積んでいるわけではない
スタック上の値のように振る舞うように作られているだけで、内部的にヒープにメモリを確保しポインタを保持しているケースが多い

**デフォルトの名無しさん** · 2022/08/14(日) 00:25:46.03

Rustは自動メモリー管理が売りなんだから、C++のように自由に何でも出来たらダメでは？

**デフォルトの名無しさん** · 2022/08/14(日) 00:49:36.36

JavaとHaskellの良いとこ取りのように宣伝されてたけど、悪いところを併せ持ってしまったのでは？

**デフォルトの名無しさん** · 2022/08/14(日) 07:17:26.98

>>396
C++はメモリを自動解放しない。
unique_ptrやshared_ptrを忘れずに利用し間違えずに使用した場合のみ自動解放されるが、
それはその正しく作られたプログラムがメモリを自動解放しているのであり、
C++という言語自体がメモリを自動解放することはない。
一方でGC言語やRust言語などはプログラムの記述と関係なくメモリが自動解放される。

**デフォルトの名無しさん** · 2022/08/14(日) 07:54:47.25

事実上今時のプログラムで生ポインタなんて使わないしアスペの>>401は知らんけど普通のプログラマにとってメモリー解放はC++程度で充分

**デフォルトの名無しさん** · 2022/08/14(日) 08:05:26.58

>>402
それはプログラマーの問題。
プログラマーの作ったプログラムにより自動解放している。
C++という言語はメモリを自動解放しない。

**デフォルトの名無しさん** · 2022/08/14(日) 08:19:24.23

>>401
一般ユーザーがめったに使わないnewで言いがかりつけるなよ。Rustのunsafeみたいなものだろ。

**デフォルトの名無しさん** · 2022/08/14(日) 08:30:27.75

はいはい、アスペは何を指摘されているかも理解できないからどうでもいいわ

**デフォルトの名無しさん** · 2022/08/14(日) 08:44:12.34

ムッシュムラムラ

**デフォルトの名無しさん** · 2022/08/14(日) 09:20:45.22

RAIIみたいなありふれたものじゃなくてxor mutabilityをアピールした方が良いのでは

**デフォルトの名無しさん** · 2022/08/14(日) 09:37:16.54

>>407
これ

**デフォルトの名無しさん** · 2022/08/14(日) 09:38:28.08

>>407
実運用としては難しすぎて逆効果だとわかっているから言わないんだよ。
あるいはそもそも理解していないか。

**デフォルトの名無しさん** · 2022/08/14(日) 10:03:55.97

>>409
難しすぎて逆効果ってどういうこと？
ワイRust大好きマンだけど、趣味ってだけで業務ではRust使ってないからよくわからない....

**デフォルトの名無しさん** · 2022/08/14(日) 10:19:19.22

>>410
もちろん難しいことはなくとてもシンプルな原理
そして実運用で非常に大きなメリットをもたらしている
Rustが大手IT各社に支持されている理由の一つ

**デフォルトの名無しさん** · 2022/08/14(日) 10:29:55.69

あくまでもOS開発の用途で採用されてるだけ

**デフォルトの名無しさん** · 2022/08/14(日) 10:38:15.56

>>412
Rustの世界的大規模な調査結果により
Rustの利用対象はサーバーサイド/バックエンドが最多で
以下クラウド、分散システム、WebAssembly/Webフロント、組み込みといった状況になっている

**デフォルトの名無しさん** · 2022/08/14(日) 10:43:52.82

>>413
ソースは？
大手企業は？

**デフォルトの名無しさん** · 2022/08/14(日) 10:48:15.10

>>414
>>413のソースは毎年調査が行われているRust Annual Survey Report

**デフォルトの名無しさん** · 2022/08/14(日) 10:58:46.14

>>407
XORじゃないけどな

**デフォルトの名無しさん** · 2022/08/14(日) 11:16:29.29

before == afterのことをimmutableというなら
==の定義とかあるんですか？
まさか、大手企業を観測すれば==の定義が分かると思ってるマッドサイエンティストはいないよね

**デフォルトの名無しさん** · 2022/08/14(日) 11:19:12.35

>>416
一般的にデータ競合を起こさないための条件は
multiple readers XOR single writer
そしてRustも同じくこのシンプルな原則に従っている

**デフォルトの名無しさん** · 2022/08/14(日) 11:47:03.37

現実には複数の状態のストアに跨がる論理的な競合の方がずっと問題で、単一データの読み書きの競合なんてアトミック変数くらいで十分

**デフォルトの名無しさん** · 2022/08/14(日) 11:59:58.73

実行時に同時に読み書きしうるかどうかをコンパイラが厳密に検知することは不可能
Rustがやってるのは大幅に安全側に倒すアプローチで、それでいいんだったら関数型みたいにそもそもミュータブルなデータを共有しない、でも立派に対策になってるよね
実際それで十分なケースが殆どでしょ

**デフォルトの名無しさん** · 2022/08/14(日) 12:04:57.82

Rustはdata raceはふせげてもrace conditionは防げない
銀の弾丸でも何でもない

**デフォルトの名無しさん** · 2022/08/14(日) 12:09:32.20

>>419
アトミック変数を忘れたら競合する
さらにアトミック変数を使ってもそのコストがかかる

Rustでは静的にコンパイル時にデータ競合を必ず排除する
アトミック操作を必要とするならば指摘してくれる
multiple readers XOR single writerを守っていれば当然(コストの高い)アトミック操作を必要とせずにコンパイルが通る

したがってRustは他の言語よりもコストを低くデータ競合の安全性を常に満たせる

**デフォルトの名無しさん** · 2022/08/14(日) 12:11:52.89

並行処理をしてないのにいちいちいらない制約かけられる方がコスト高いわ

**デフォルトの名無しさん** · 2022/08/14(日) 12:12:26.58

>>422
いつものキッズかな
単一変数のデータ競合が生じなくても多くのロジックは競合するんだよ

**デフォルトの名無しさん** · 2022/08/14(日) 12:17:06.31

並行処理を安全に実装するのが難しいから、需要があってGoとかRustみたいな言語が登場してるのであって、直列なコードしか書かないなら昔の言語でもよくね

**デフォルトの名無しさん** · 2022/08/14(日) 12:18:16.18

>>425
そうじゃなくて、並行処理をしている場合、現実には競合するタイミングが生じないと分かっていても制約がかかることになるんだよ
コンパイラは静的なスコープを検査することしかできないからな

**デフォルトの名無しさん** · 2022/08/14(日) 12:35:39.15

>>424
そんな当たり前のことで問題のすり替えをするのは行儀がよろしくない
>422では明確にデータ競合の話をしている

どの話であってもまずはデータ競合を起こさないことが必須
しかしこれまでの言語はプログラマー任せであり言語として実行前に静的にデータ競合を防ぐ機能を持たなかった
Rustはそれを実現するとともにコストの高いアトミック操作無しでもデータ競合を避ける形もサポートした

**デフォルトの名無しさん** · 2022/08/14(日) 12:48:55.73

>>427
多くの場合はより高水準の制御や抽象化を必要とするため、君が思っているほどデータ競合可能性の回避は重要じゃないってことだよ
制約に対して得るものが小さい

**デフォルトの名無しさん** · 2022/08/14(日) 13:14:59.37

>>428
実際にそれらのプログラミングをしていればわかる
データ競合の回避は重要どころか必須

**デフォルトの名無しさん** · 2022/08/14(日) 13:29:25.97

やっぱRAIIを意識しないと会話が成立しないぞ

読みたい情報が消されたり書き換えられているバグよりも危険なのは
情報を記憶する領域自体が消滅しているバグだから
書き換えを制限する効果よりもmoveやdropを制限する効果を見なければ本質が見えない

**デフォルトの名無しさん** · 2022/08/14(日) 13:35:19.72

>>428
データ競合可能性の回避は重要か重要じゃないかではない
データ競合可能性の回避は必ずすべきこと
Rustを叩きたいからといってこれを重要じゃないと主張するのは頭が狂っている

**デフォルトの名無しさん** · 2022/08/14(日) 13:53:29.77

データ競合可能性の回避をしてないシステムやアプリって存在するの？

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

並列処理しなくてもmutable aliasingにまつわるバグは起こりうるよね
典型的にはコレクションのイテレート中の要素追加とか

これを防ぐ仕組みを整えたらうまいこと並列処理にも応用できたという話であってデータ競合を防ぐことが本質ではない

**デフォルトの名無しさん** · 2022/08/14(日) 14:09:17.85

>>432
回避し切れてないシステムやアプリはそこそこ存在するけどw

**デフォルトの名無しさん** · 2022/08/14(日) 14:32:21.17

mutable aliasingはGC言語でも防げないからなぁ
これが一度Rustに慣れてしまうと他に戻れなくなる原因の一つかも
他言語も積極的に取り入れてほしいところ