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

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

スレタイ以外の言語もok

前スレ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

**デフォルトの名無しさん** · 2022/04/15(金) 13:05:03.59

>>910
そうだよ
でも生ポインタというかアドレスが何か分かっていないとこのキャストが意味するところは理解できないでしょうし
それゆえ「生ポインタの知識は不要だし有害」は過言という主張です

**デフォルトの名無しさん** · 2022/04/15(金) 13:17:15.21

>>911
そりゃそうだね

**デフォルトの名無しさん** · 2022/04/15(金) 16:25:15.14

メロスは激怒した
必ず、かの邪智暴虐（じゃちぼうぎゃく）のRUSTを除かなければならぬと決意した。
メロスには生ポイントがわからぬ

**デフォルトの名無しさん** · 2022/04/15(金) 16:35:16.39

生ポインタの知識は無くてもプログラムは書けるし、動くし、困るまでは、知らなくても良いんじゃないの？

**デフォルトの名無しさん** · 2022/04/15(金) 17:23:21.88

一皮むけば生ポインタ出てくるのはどの言語でもそうだしことさらrustだけ取り上げる理由もないとは思うけど
ポインタの知識が有害というのは言い過ぎ

**デフォルトの名無しさん** · 2022/04/15(金) 18:39:04.53

でもおまえdouble freeじゃん

**デフォルトの名無しさん** · 2022/04/15(金) 23:07:48.60

Rustの話は専用スレ立ててそっちでやれよ

**デフォルトの名無しさん** · 2022/04/15(金) 23:46:20.49

>>917
Rustの話ではないぞ
double freeはRustでは起きない
Rustは全自動解放だからプログラマーが気にすることはない

**デフォルトの名無しさん** · 2022/04/16(土) 02:03:12.36

いまさらdouble freeが問題になる言語ある？

**デフォルトの名無しさん** · 2022/04/16(土) 02:10:47.90

c++はstd::unique_ptrで使い回すようにしたららだいぶスッキリしたよ。
継ぎはぎ故の古い環境やオレオレツールが動くのも良い。
でもどっかでカバっと大規模に整理して欲しいと思ったりもする。

**デフォルトの名無しさん** · 2022/04/16(土) 06:37:22.84

pythonってそんなに世の中で使われているかな？
単にエンジニアが好きと思ってるだけのような気がしなくもないのだが・・・
俺は嫌いだけどｗ

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

寧ろエンジニア以外に受けているのでは？

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

そのうち小学生の必須科目になりそう

**デフォルトの名無しさん** · 2022/04/16(土) 09:04:49.24

「全自動解放だからプログラマーが気にすることはない」そんな訳ない、Rustでも自分でカスタムアロケータ書けば気にする

**デフォルトの名無しさん** · 2022/04/16(土) 12:15:02.24

Pythonの何でもかんでもベクトル演算縛り他の言語始めるとき悪影響だよな

**デフォルトの名無しさん** · 2022/04/16(土) 16:00:51.37

pascal じゃなく python ？
pascal は言語理論上の基礎の上に載ったしっかりした文法だが python のような出鱈目文法が今はウけるのか？

世も末としかいいようがない…

**デフォルトの名無しさん** · 2022/04/16(土) 16:23:00.38

LL(1)がそんなすごい話だっけ？

**デフォルトの名無しさん** · 2022/04/16(土) 17:15:40.83

>>923
ベーシックよりはマシかと。

**デフォルトの名無しさん** · 2022/04/16(土) 18:18:48.48

>>927
そのような基盤にすら載らない言語が跋扈するなんて世も末かと

**デフォルトの名無しさん** · 2022/04/16(土) 18:23:19.78

>>929
意味解析しないと構文解析できないCとかいう言語が跋扈してる時点ですでに世界は終わっているよ

**デフォルトの名無しさん** · 2022/04/16(土) 18:58:19.37

クククLispが世界を支配する日は近いぞ

**デフォルトの名無しさん** · 2022/04/16(土) 19:01:07.55

>>931
残念ながら・・・
そろそろC++++とか出ないのか？ｗ
あ、C#かｗ

**デフォルトの名無しさん** · 2022/04/16(土) 19:42:31.25

>>924
嘘つき
アロケータを自作しようが標準のを使おうが
そのことには全く影響されずに自動で解放されるぞ

**デフォルトの名無しさん** · 2022/04/16(土) 20:32:01.07

じゃあなんでRustは学習コストと難易度が高いのですか？

**デフォルトの名無しさん** · 2022/04/16(土) 20:51:06.94

Rustに手を出してみたが特に難しいことは無かったな
むしろ洗練されたわかりやすい言語だと感じた
その上で必要ならば細かいことにも手が行き届く感じ

**デフォルトの名無しさん** · 2022/04/16(土) 22:40:46.66

洗練と言うのは一人だけだからわかりやすい

**デフォルトの名無しさん** · 2022/04/16(土) 23:21:57.42

>>933
嘘つき、deallocで実際に解放しなければ解放されるわけないだろ、死ね詭弁論者

**デフォルトの名無しさん** · 2022/04/16(土) 23:59:23.94

>>937
それ、「freeを呼べばメモリが解放される」って主張にたいして
「メモリ解放しない独自実装のfreeならメモリリークする」って反論するようなもので
論理的には正しいけど意味のない主張だよね

**デフォルトの名無しさん** · 2022/04/16(土) 23:59:50.03

でも君たちRust書いたとてIT土方のままだよね

**デフォルトの名無しさん** · 2022/04/17(日) 00:34:36.53

>>937
それは君が理解できていないからそんな主張になる

メモリの解放は3階層ある(GCでない場合)
(1) デストラクタによる解放　←プログラミング言語の仕様で関係するのはここまで
(2) メモリアロケーターでの解放　←例えばmallocに対するfreeの内部はここ
(3) OSへのメモリ解放　←システムコールsbrkはここ

C言語は(1)がないため(2)のfreeをプログラマーが忘れず呼び出す必要がある
C++は(1)のデストラクタの記述と呼び出しにプログラマーの手動が一部残りうる
Rustはプログラマーが何もしなくてよい

**デフォルトの名無しさん** · 2022/04/17(日) 00:45:36.82

で？年収は？

**デフォルトの名無しさん** · 2022/04/17(日) 00:46:21.20

>>940
それ実質GCじゃん

**デフォルトの名無しさん** · 2022/04/17(日) 00:54:39.19

>>942
Rustでプログラマーがメモリ解放しなくてよい点はGC言語に似ているけど
GC言語はガベージ(＝ごみ)が溜まっていって後でガベージコレクションを行なう必要があるのに対して
Rustでは即座に自動的にメモリ解放されるためC言語と同様に省メモリかつ高速というメリットがある

**デフォルトの名無しさん** · 2022/04/17(日) 01:09:59.47

>>943
細かく解放のオバヘッド乗るとか最悪じゃん

**デフォルトの名無しさん** · 2022/04/17(日) 01:16:07.56

>>944
CとC++とRust がその同じ方法だけど
いずれも超高速だよ
つまりGCするよりも即座に解放するのが正解と結論が昔から出ているよ

**デフォルトの名無しさん** · 2022/04/17(日) 07:19:14.82

>>944
普通はシステムコールする専用のスレッドを作ってそこで全部やるからオーバーヘッド無いよ

**デフォルトの名無しさん** · 2022/04/17(日) 08:46:12.09

嘘乙
システムコールだろうがGCallだろうが、CPUとメモリ使うから一緒だぞ
これだから物理を知らないソフト屋は

**デフォルトの名無しさん** · 2022/04/17(日) 09:02:05.09

バックグラウンドのシステムコールが問題になるような環境だと、それこそガベコレ動かしてる余裕など無いのでは？

**デフォルトの名無しさん** · 2022/04/17(日) 09:50:03.49

>>943
>>549

**デフォルトの名無しさん** · 2022/04/17(日) 10:25:23.27

freeでsbrk走るとか本気で言ってるのか

**デフォルトの名無しさん** · 2022/04/17(日) 10:28:31.82

>>944
どういう状況を想定するかにもよるけど、解放可能なオブジェクトを解放せずどこかに貯めておいて、
後からまとめて解放するような実装もできるよ
明示的に書かないといけないからちょっとめんどくさいが

**デフォルトの名無しさん** · 2022/04/17(日) 10:33:33.77

解放可能なオブジェクトを解放せず後からまとめて解放するような実装を明示的に書く

それはもうGCなのでは？

**デフォルトの名無しさん** · 2022/04/17(日) 10:44:39.16

自分でやるかシステムに任せるかで違うと思うよ

自分でやるとバグが発生する可能性がある

**デフォルトの名無しさん** · 2022/04/17(日) 11:09:06.02

現実にGC言語方式よりもC/C++/Rust 方式の方が圧倒的に速くて省メモリであると判明している
ただしCでは手動でメモリ解放しなければならないデメリットがありミスも多かった
そこでC++ではメモリ解放を一部自動化した
さらにRustではメモリ解放を完全自動化してミスもゼロとなった

**デフォルトの名無しさん** · 2022/04/17(日) 11:10:30.80

まるでメモリ解放以外のプログラムのミスは無いみたいな感じだよな

**デフォルトの名無しさん** · 2022/04/17(日) 11:11:47.17

Rustコンパイラはメモリリークが発生しないことは保証しません

**デフォルトの名無しさん** · 2022/04/17(日) 11:16:42.17

セキュリティで問題となる多くはメモリ関連が起因している

**デフォルトの名無しさん** · 2022/04/17(日) 11:17:28.40

>>956
そんなの当たり前じゃん
一般的にコンパイル時点でメモリリークを検出することは論理的に不可能
だからRustコンパイラはメモリリークが発生しないことを保証できない
これはRustの問題ではない

**デフォルトの名無しさん** · 2022/04/17(日) 11:19:15.00

わざとメモリリークさせているのか事故ってるだけなのかコンパイラは区別できないからな

**デフォルトの名無しさん** · 2022/04/17(日) 11:29:57.34

Rustでは循環参照以外ではメモリリークを起こさないことをコンパイラが保証できる
さらにRustでは循環参照をプログラマーが意図的に起こさない限り勝手に作られることはない
そのためプログラマーの意図せぬ循環参照は起きずメモリリークも起きない

現実問題としては長らくRustプログラミングしてきて実験テスト目的以外で循環参照を扱ったことは一度もない

**デフォルトの名無しさん** · 2022/04/17(日) 12:30:05.08

顔真っ赤になってこういう事を書いてくる知能の無さそうな奴と仕事するのが嫌だ

**デフォルトの名無しさん** · 2022/04/17(日) 12:32:19.63

>>952
tracing GCみたいな大げさなものでなくても、解法対象オブジェクトをVecに入れておいて適当なタイミングでVecごとdropするみたいなことはできる
シンプルだからバグの入り込む余地は少ないと思うけど、あらゆるケースに対応しようとするともう少し複雑な仕組みが必要かもね

>>960
いつもrust擁護してるけど、知識不足のせいか言葉遣いが雑なせいなのか、突っ込みどころ多すぎて逆効果になってる
循環参照以外でも Box::leak などでメモリリークは起こせるよ

**デフォルトの名無しさん** · 2022/04/17(日) 13:18:48.86

>>962
おまえバカだろ
プログラマーが意図的にしないとメモリリークは起きないという話の場へ
Box::leakでメモリリークを起こせるという主張はキチガイ

**デフォルトの名無しさん** · 2022/04/17(日) 13:31:15.61

>>963
よく読んで
>>960の主張は以下
1. Rust では循環参照以外ではメモリリークを起こさないことを保証できる
2. 循環参照はプログラマーが意図的に起こさない限り起きない
Box::leakは1の反例
プログラマが意図的にメモリリークを起こさない限りメモリリークしないなんて主張については何も言っていない

**デフォルトの名無しさん** · 2022/04/17(日) 13:37:41.71

結局プログラマーが意図的に起こさないとRustではメモリリーク起きないんでしょ？
この件でRust叩きは無理があるんじゃないかしら

**デフォルトの名無しさん** · 2022/04/17(日) 13:39:19.65

速くて省メモリなんて目指してない人が大多数なんだよ

システム書く人ならそれ目指すけど

**デフォルトの名無しさん** · 2022/04/17(日) 13:47:11.48

プログラミング言語は3つに分類できる感じ？
CとC++　←省メモリ高速だがメモリ解放でミスると危険
GC言語　←省メモリ高速ではないがメモリ解放は自動で気にしなくていい
Rust　←省メモリ高速だがメモリ解放は自動で気にしなくていい

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

なんかすげぇ素人がまぎれこんできたなw
長文タレ流し君の方がよかったかもw

**デフォルトの名無しさん** · 2022/04/17(日) 14:21:16.64

Rust　←省メモリ高速だがメモリ解放は自動で気にしなくていいが独自の戒律があり常にそれを気にしなくてはならない

**デフォルトの名無しさん** · 2022/04/17(日) 14:22:13.65

>>967
その通り
IT大手各社が珍しく連合してRust推ししているのはRustがプログラミング言語の革命児だから

**デフォルトの名無しさん** · 2022/04/17(日) 14:51:06.13

自演くっさ

**デフォルトの名無しさん** · 2022/04/17(日) 14:54:33.00

Rustはバランスの良い言語だと思うけど万人向けではないからなぁ
真の意味で万人向けの言語なんてそもそも存在するのかは分からんが

**デフォルトの名無しさん** · 2022/04/17(日) 14:57:22.12

>>972
俺は嫌いだけどjava辺りだろ

**デフォルトの名無しさん** · 2022/04/17(日) 15:14:44.89

JavaよりはRustの方が使いやすくて便利でいいわ

**デフォルトの名無しさん** · 2022/04/17(日) 15:22:20.54

自演と単発ｗ

**デフォルトの名無しさん** · 2022/04/17(日) 15:45:36.98

>>970
Rust推しは電通がからんでるような気がするんだが

**デフォルトの名無しさん** · 2022/04/17(日) 15:53:33.91

つまりMicrosoft・Amazon・Google・Facebook(Meta)など大手IT各社が一緒になってRust Foundationを立ち上げたのも裏で電通が暗躍？

**デフォルトの名無しさん** · 2022/04/17(日) 15:57:37.21

wikipediaのMozilla Foundationのページ見てたら理事会に日本人居るの見つけたんだけど
この人経歴が訳アリすぎるなｗ

**デフォルトの名無しさん** · 2022/04/17(日) 16:06:11.24

>>977
だろうな

**デフォルトの名無しさん** · 2022/04/17(日) 16:29:36.29

>>977
広告代理店にそこまで影響力あるわけ無いだろう

**デフォルトの名無しさん** · 2022/04/17(日) 16:36:29.33

>>980
電通の背後には政府とアメリカがいる

**デフォルトの名無しさん** · 2022/04/17(日) 17:06:13.05

つまり宇宙人との密約で動くアメリカ政府と
ネオコンの陰謀ということか

**デフォルトの名無しさん** · 2022/04/17(日) 17:21:02.73

ネトウヨ「電通の陰謀」

**デフォルトの名無しさん** · 2022/04/17(日) 17:37:31.56

電通陰謀論は左右問わないね
ネトウヨはマスコミ批判に絡めて電通を黒幕にするし、パヨクは自民党が選挙で勝つことの裏に電通がいることにしたがる

**デフォルトの名無しさん** · 2022/04/17(日) 17:52:20.84

次スレ立てます

**デフォルトの名無しさん** · 2022/04/17(日) 17:52:57.09

https://mevius.5ch.net/test/read.cgi/tech/1650185555/

**デフォルトの名無しさん** · 2022/04/17(日) 18:36:45.87

>>986
↑
TypeScript Swift Go Kotlin 辺りは次世代感があまりないので、タイトルから外したかったが、とりあえずそのままにしておいた。

**デフォルトの名無しさん** · 2022/04/17(日) 18:37:21.30

Nimはほとんど話題に出てないけど残しておくの？

**デフォルトの名無しさん** · 2022/04/17(日) 18:52:19.55

>>988
個人的にはマイナー言語は残して、少しでも注目を得られればと思っている。

**デフォルトの名無しさん** · 2022/04/17(日) 19:39:25.03

なんでお前が勝手に決めてるンだ

**デフォルトの名無しさん** · 2022/04/17(日) 19:59:35.43

っていうか実質話題はGo vs Rustになってるんだからそれでいいのでは？

**デフォルトの名無しさん** · 2022/04/17(日) 20:37:58.47

>>990
マイノリティにも配慮した、中々の英断だろ？

**デフォルトの名無しさん** · 2022/04/17(日) 20:38:30.40

>>991
そうかも

**デフォルトの名無しさん** · 2022/04/17(日) 20:40:24.07

まあこのスレはRust、Go、C++、C#、Javaのスレって感じだな

**デフォルトの名無しさん** · 2022/04/17(日) 20:53:06.77

>>986
なにげに876の順にしたのは素晴らしいと思うよ

**デフォルトの名無しさん** · 2022/04/17(日) 21:16:36.68

>>994
いやいや、C++,C#,Javaは次世代でもないし、GoやRustに比べればすでに完敗してるから入れなくていいだろ

**デフォルトの名無しさん** · 2022/04/17(日) 21:36:04.21

次世代かどうかはしらんけど、そのへんの言語の話題がなぜか多いんよ

**デフォルトの名無しさん** · 2022/04/17(日) 21:40:35.44

その三つを基準にして比較検討していくんだから話題に出ない方がおかしい

**デフォルトの名無しさん** · 2022/04/17(日) 22:20:42.76

いっそのこと1.0がリリースされてる言語は対象外にしよう

**デフォルトの名無しさん** · 2022/04/17(日) 22:31:30.13

１０００ならPHP大復活時代でルースターズを蹂躙レイプする

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 26日 19時間 7分 49秒