次世代言語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で色が付く(ローカルではない変数は別の色で表示される)

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