次世代言語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/03/22(火) 04:13:45.26

まだやんのかよ！

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

別に俺はスレ消えても良かったんだが、次スレの話が出てたから、書き込み多かったし立ててやっただけｗ
次はいくら書いても俺は立てないことにするわｗ

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

どもです(´・ω・｀)

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

結局Goが最強ってことでいいよね

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

Goが最強みたいな評価が一般的になると正直死にたいです。僕の負けで良い。

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

>>6
言語オタクの人生敗北者

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

(´・ω・｀) おーい、磯野、V言語の話しようぜ

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

次世代アセンブラって無いの？
それがさいつよだろ。

a4 · 2022/03/22(火) 11:53:46.88

>>9
なでしこみたいな日本語のアセンブラとかどうかな。

a4 · 2022/03/22(火) 11:56:28.94

>>9
今、こういうの作ってる。
http://01ken.com/DSC00274.JPG

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

>>9
LLVMとかかね。

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

数年前のGo「ジェネリクスが無いことで型システムがシンプルに保たれています」
今のGo「ついにジェネリクスがやってきた！今こそGoがプログラミング言語の頂点に立つ！！」

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

型パズル始める人の要望に合わせると
誰でも理解できるシンプルな言語仕様から
かけ離れてくけどどう決断するんだろ

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

Javaにもジェネリクスいらんかったと思うのよね
C++やっててJava出てきたときの新鮮さはよかったね
型パラメータ無しで、プリミティブ型と参照型のふたつでやりくりしてくだっていう
割り切りからのOOP集中って感じでとにかくスッキリしてた

まぁユーザが増えて言語の地位を得るとともに
ドカタ言語という側面も出てきたからジェネリクスからは逃れられんかったね
いつまでも先進的な言語ではいられないね

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

Goはジェネリクス導入は大変だから後回しにしたってだけで
言語仕様をシンプルにする云々は外野が勝手に言っていた印象

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

JavaはArrayListやHashMapの要素が型無しだったから流石に不便すぎた
Goの場合は動的配列や連想配列の要素はもともと強く型付けされているから、genericsが無くても実用的にはほど問題にならなかったんだよ

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

>>17
それはジェネリクスを理解していない発言

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

>>18
仮にそうだとしたら、ジェネリクスを理解してない俺のような愚かな人間にとっても、
強く型付けされた動的配列や連想配列は必要であることが証明されたわけだ

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

>>19
そんな当たり前のことしか誇れるものがないGoが悲惨
大昔の言語やスクリプト言語と比較するしかないとは

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

ジェネリクスの代わりにコード生成でなんとかしているとか聞いたことある
C++のテンプレートの展開を手動でやっているようなものでコンパイルエラーメッセージが大変なことになりそう

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

不便すぎるGoなんかを使っているのはGo信者だけだよ

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

じゃあもう全員で最も技巧的で分かりにくいが高速で何でも出来るC++に移行すればいいのだよｗ
人間がそんなに頭いいんならなｗ

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

>>23
そこは生産性の高いRustでよいでしょう
見落としもコンパイラがエラーにしてくれることでどれだけ時間の節約になったことか

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

ああだからな、俺はRust/Goの「キラーアプリ」は何？と聞いてるんだ。
「上に政策あれば下に対策あり」ではないが、「難題あれば迂回策あり」程度にはノウハウは溜まっている。
だからそこを敢えて正面突破する場合、迂回策を明確に上回る利益が必要なんだよ。
(迂回策では実現出来ない性能とか)

前スレ>>992
C#が重量級になりすぎてるのは事実。
同様にC++もだから、C++の特定の使い方(とはいえほぼ本流)だけ切り出して簡易版を用意したいのは分かる。
ただそこで余分な仕様を付け加えて、結果「借用」とかやりだしてるから頂けない。
「簡易版」への切り出しなら「簡易」に収まる範囲に留めるべきだった。
(「メモリリーク無し」ではなく「データ競合無し」なら所有権を1つに絞る必要もなく、
つまり関数の引数として使うだけならいちいち借用する必要もなかったはずであり、
これであれば無駄な混乱もなかったはずなので、
やっぱり所有権を絞ってるのは所有権の静的追跡＝「メモリリーク無し」を目指してる気がするが)

前スレ>>994
> うっかりループカウンタをgoroutine内でそのまま使ってしまって意図通り動かなくなったりすることがある
これは同様の事を俺もやった事がある。ただしこれにも、

・IDEで色が付く(ローカルではない変数は別の色で表示される)

という、果てしなく馬鹿っぽい迂回策はある。
エラー検出は編集時であり、コンパイル時よりも性能がいい。（ただし目で見てチェックだが）
そしてコードやプログラマに対する負荷もない。
(つまるところ、一方ロシアは鉛筆を使った、に近い)

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

>>25
C++のunique_ptrの意味も利点も所有権とは何かもわからないまま文句だけ垂れる無知無能C#プログラマーさんだ
そして相変わらず意味不明な書き込み

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

>>21
全く逆だよ。コード生成を間に挟んでるから原因が分かり易い。

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

>>25
C#にも参照があるのに
なぜ他の言語に対しては参照を必要ないと批判しているのですか？

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

>>28
他の言語では「借用がない」と言っている。
Rustによって新たに導入されたもので、それで何かしら恩恵があればいいが、
「データ競合がない」程度では見合わない。
既にある迂回策に対して利点がないのなら、プログラマの負担を増やしただけ無駄だ。

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

>>29
呆れた…
参照を使うことを借用と言うんだよ
だから借用というものは当然存在しなくて存在するものは参照だけ
せめて超基本的なことくらい学んでから出直してきたら？

**デフォルトの名無しさん** · 2022/03/23(水) 00:25:31.71

既に、YouTube で有名な、雑食系エンジニア・KENTA が結論を出している

Rust, Elixir は普及のキャズムを越えなかった。
越えたのは唯一、Go だけ

例えば、今世紀最大の起業家、
Ruby 製のVagrant の作者・Mitchell Hashimoto も、Rubyから、Goへ行った

Go製のTerraform で、HashiCorp の時価総額は、今や数千億円

GitHub もGoへ移行する
GitHubのコピーで、時価総額2兆円のGitlab はRuby on Rails のままで、Goへ行かない！
クレイジーw

CircleCI は、Closure 製なのか？
これも、Go, Elixir へ移行しないといけない

**デフォルトの名無しさん** · 2022/03/23(水) 05:11:33.35

>>24
頭がいいなら、そんなメモリ安全とかデフォルトimmutableでmoveで借用という制限だらけのRustを使わずとも安全かつ正確な実装ができるんじゃよｗ
ただ、(横暴な言い方をすると)それだけ安全側に振ったC++なRustでも結局習得に時間がかかるため、コストに釣り合うのはごくごく一部の領域のみというのが結論ｗ

**デフォルトの名無しさん** · 2022/03/23(水) 05:28:37.24

>>25
相変わらず、荒すぎる上に間違っているｗ

お前の場合、Rustは不勉強すぎてお話になっていないよｗそういう解釈か～という勘違いとかそういうレベルではなく、まるで整合が取れてないから他人から見ると字面だけ追って理解できてない状態にしか見えないｗ
ただC#よりRustの方が楽ということは全くないｗなぜなら制限が少ないからｗ GUIの裏でタスクが1つ2つ動く程度では並列時の問題なんてそうそう起きないし、品質の取れたエコシステムすら整っておらず複雑かつ面倒なだけのRustはメリットなんて何一つないよｗ

Goでのうっかり問題については、並列時の所有権のありがたみはRustならではｗ discordが移行したときにこぞって持ち上げられたのがココｗただこれも常時強制されると不便なだけなので、一長一短ｗ

**デフォルトの名無しさん** · 2022/03/23(水) 06:26:25.92

>>32
> デフォルトimmutableでmoveで借用という制限

プログラミング歴があるならば
デフォルトでimmutableの方がありがたいことにほとんどの人が賛同する
そのためimmutableだけの言語まであるくらいだ
Rustはmutableも使える言語だからそこに制限はない

moveについてはその方が複写よりも当然効率が良いため
何らかの事情で複写したい時はcloneすればよいので困らない
効率が悪くても毎回複写がいいならばCopyトレイトを宣言で可能
つまりRustは3種類の方法を提供していてそこに制限はない

借用とは参照を使うことであってこれも制限ではない
そして参照渡しをするなどの実質の参照を扱う言語は普通に多い
Rustにおける参照とはそれらよりも抽象化された概念だがほぼ同じ
何か制限を設けているわけではなくむしろプログラマーへの選択を与えている
複写(Copy/clone)して渡すのか参照を渡すのかそれともそのものを渡す(move)のかを選べる

**デフォルトの名無しさん** · 2022/03/23(水) 06:59:48.04

>>34
> プログラミング歴があるならば
> デフォルトでimmutableの方がありがたいことにほとんどの人が賛同する
ないないｗ

> Rustはmutableも使える言語だからそこに制限はない
デフォルトの制限が厳しいから書きにくいんだよｗ制限を外すことの大変さと恐ろしさをプログラミング歴のある人は知ってるからｗ

> moveについてはその方が複写よりも当然効率が良いため
> 何らかの事情で複写したい時はcloneすればよいので困らない
効率悪ｗ

> 効率が悪くても毎回複写がいいならばCopyトレイトを宣言で可能
> つまりRustは3種類の方法を提供していてそこに制限はない
わざわざトレイトが必要なんですってよ！奥さんｗ
こんなに使いにくいのが制限じゃないんですってよ！ｗ

> 借用とは参照を使うことであってこれも制限ではない
> そして参照渡しをするなどの実質の参照を扱う言語は普通に多い
言葉すら必要なく、所有権を意識するから必要になる概念で、おもっきし制限だよねｗ

> Rustにおける参照とはそれらよりも抽象化された概念だがほぼ同じ
> 何か制限を設けているわけではなくむしろプログラマーへの選択を与えている
> 複写(Copy/clone)して渡すのか参照を渡すのかそれともそのものを渡す(move)のかを選べる
嘘乙ｗ

**デフォルトの名無しさん** · 2022/03/23(水) 07:05:41.35

なんでRust推す連中ってこう嘘ばかりついたり誤魔化そうとしたり間違いを認めなかったりするんだろうなｗ

**デフォルトの名無しさん** · 2022/03/23(水) 07:11:45.93

>>35
キチガイだな
コードを書いたことがないのかな
今どきはJavaScriptですら書き換えない変数はconst宣言(＝immutable)が勧められる時代
JavaScriptにしてもRustにしても書き換えたい変数はmutableにできるのだからそこに制限も不便もない