次世代言語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にできるのだからそこに制限も不便もない

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

Erlang VM を使う、関数型言語のElixir は、Immutable

Docker も、Immutable Infrastructure
disposable(破棄可能)だから、流行った

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

>>37
Rust推しはキチガイってことですねｗ
JavaScriptはデフォルトconstじゃないですｗ
出来るところをconstにしよう！なら問題ないｗ
デフォルトをconstにする＝制限と言ってるだけｗだってmutとか書かないといけない＝制限だからｗ
そして書いた瞬間に確実に「制約」になるからねｗ
明示的に書けば外せるから制約じゃない！とかアホとしかｗ

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

>>38
Erlangなんて日本じゃほぼ使われてませんｗ

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

>>36
君がプログラムを書いたことがないからじゃないか？
>>34が書いているようにRustは選択肢が色々と用意されていてプログラマーがそれらを選択することができる言語
もちろんcloneやcopyは最小限にしたほうが望ましいからそれらはデフォルト適用になっていない
合理的である

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

>>41
そうして書かれたコードが制約過多だって言ってんだよｗ

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

頭いいなら機械語直接書いてくれ
俺は頭悪いからモダンな構文使える言語を選ぶよ

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

じゃあgoっていう簡単な言語があるよｗ Rustとかいうゴミ言語を勧めるバカの言うことは聞かない方がいいよｗ

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

Goの良さもRustの良さもわかるからそこまで論争になるのがよくわからないw

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

俺は遊んでるだけだけどｗ

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

なんかやたら噛み付いてくるんだよねｗ事実なのにちょっとでもRustをディスるとｗ

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

なぜ論争になるかより、なぜ相手にするのかが疑問だ
NG放り込めば始末できるのに

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

>>39
色んなプログラミング言語を知らないあなたが無知にみえます
Rustの場合は関数型言語に近くてif式、match式、loop式といったように文ではなく値を返すことが可能なものが多いです
そのため必然的にほとんどの変数利用はimmutableとなります
もちろんRustはmutableも使えますからそこに制限は全くないです
上述したようにif式、match式、loop式といった値を返すことも可能な点でも他の言語よりも自由度と表現力が増しています

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

我慢できないようだよｗなんでかは知らないｗ
あ、別スレに貼ったやつを燃料として投下しておこうｗ

https://mevius.5ch.net/test/read.cgi/tech/1643289587/730
学習曲線やゔぁ！ｗ

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

>>49
近くねーよｗ関数型に近い表現が出来るとしか言われてねーよｗ
そして最近の言語は程度の差こそあれ近い表現も遅延評価も出来るよｗ

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

rustは学習曲線高いと言っても、一番最初にrustを勉強すると大変だとは思うけど、c++とhaskellあたりを学んでおけば大したことないし、コンパイラがうるさいおかげでよくわからないままメモリ周りのバグを含んだクソコードを書かないという点ではハードルはむしろ低いんじゃないか？
goはそれとは逆のアプローチを取ってるだけでどちらが優れているとかではない気がする。
片方を過剰に擁護するのはプログラミング言語についてあまり知らないから自分の理解できるところだけ切り抜いて騒いでるだけにしか見えない。
goが馬鹿向けの言語とか言ってる人もいるけど、goを使って素晴らしいソフトウェアを作り上げた優秀なエンジニアもたくさんいることを知らずに言ってるなら本当に恥ずかしいことだと思うw

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

>>52
キミは賢くてかつ弁えてるね

**デフォルトの名無しさん** · 2022/03/23(水) 08:02:19.50

>>44
横入りですまんがGoは言語の機能が低すぎるせいで無駄に記述が長くなり苦痛
書いていると同じパターンが何度も出てくる
Go言語のサポートが少ないため冗長なことを人間がさせられてしまう

**デフォルトの名無しさん** · 2022/03/23(水) 08:19:52.35

>>52
>c++とhaskellあたりを学んでおけば大したことないし

つまり初級者・中級者お断りということかね。
PythonとかJavaあたりのユーザーは絶望的かと。

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

C++の前にCは習得しておきたいし、C++自身もHaskellも学習曲線やばいけどねｗ
ヤバい言語を2つも習得してようやく他の言語と比較しうる学習曲線になるRustって一体・・・ｗ

Goの冗長さはRustの言語的制約と似たようなものｗ
明快さの代わりに受け入れざるを得ないｗこの手の問題は開発環境によりほんのり改善できるｗ

**デフォルトの名無しさん** · 2022/03/23(水) 08:34:40.79

>>55
C++もHaskellも全く知らないけど
Rustを普通レベルには使えるようになったから
C++もHaskellを知らなくても大丈夫なことは保証するよ

**デフォルトの名無しさん** · 2022/03/23(水) 08:37:32.32

今こそJava復活の時

［速報］JavaOneが復活、今年10月にラスベガスで開催。2017年以来5年ぶり
https://www.publickey1.jp/blog/22/javaone1020175.html

**デフォルトの名無しさん** · 2022/03/23(水) 08:42:55.48

>>55
この表現は確かに不適切だったと思う。
伝えたかったのは、cライクな構文、メモリ周りの知識、型システムの知識があればrustが極端に難しい言語ってわけではないってことなんだ。
そしてこれらの知識はプログラミングを書いていれば自然と知ることになるものだと思ってる。(c++とhaskellが書けないと理解できないと言いたかったわけではない)
プログラミング初学の人や、プログラマではないが仕事の道具としてスクリプト言語を使ってるような人が学ぶ言語じゃないのとは思うけど、アプリケーションの開発を行うような人にとっては難しすぎる言語仕様じゃない。

**デフォルトの名無しさん** · 2022/03/23(水) 08:47:46.12

違う違うぞ
使えるようになったつもりなだけだｗ
RustにはC++とHaskellが必須！C++の難解なエラーを気が狂いそうなほど読み解き、公衆の面前でモナドとは・・・っていうポエムを書いてからでないと本当の意味でRustの扉は開かないｗ

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

>>59
同感
Rustを難しいと言うのは大げさもしくは批判派によるレッテルだと学んで分かった
むしろRustを使うことでの絶大な効果に驚いた
一番大きかったのは実行時デバッグの激減
コンパイル時点で実行時に起き得る様々な問題を食い止めてくれるため開発効率が一気に上がった
使いやすさに加えて実行の速さや省メモリなど一石多鳥

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

>>61
伝わってよかった....
後半の部分も完全に同意する。ブレークポイント貼って変数の値をチェックしながらデバッガをいじくり回すみたいなことをする頻度が激減したのが大きい。
ヤバそうな部分もunsafeとかunwrapみたいにコード上に明示されるのが地味に快適。自分にとってコードって書くことより読むほうが大変だから、そういうところがありがたい。

38 · 2022/03/23(水) 09:35:58.30

確か、Elixir はスクエニで使っている。
ニコ生でも、会議をやっていた

他には、組み込みのNerves

YouTube で有名な、雑食系エンジニア・KENTA のサロンは、Ruby on Rails だけど
ポートフォリオは、Elixir のPhoenix

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

>>62
書きより読み重視ってのは最近の言語全般の傾向であるように思う
GoとRustは全然方向性違うけど、ソースコードの情報量増やして読むコストを下げるという点では同じかな、と
OSSなんかだと書く人より読む人が遥かに多いし、個人開発だったとしても半年前のコードなんて覚えてないから結局読みやすさは重要だよね

**デフォルトの名無しさん** · 2022/03/23(水) 10:52:27.45

書きやすい言語ほど読みにくいよね
書き手の自制心にもよるんだけど
rubyとか書いてるときすっげーストレスないんだけど
あとから見るとその時のノリで書いてるのがよくわかる
Javaは現代視点だとやや冗長かもしれんが
後から読んでも意外と読みやすい

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

可読性は重要。
漏れなんか、一月前の自分のコードでも、自分で書いたと分からないからw

この処理は、いつの間に誰が書いたの？
とか、よく他人に聞くw

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

>>62
たしかにRustでは実行しながらの無駄なデバッグ時間が無くなった
コンパイラによるチェックが厳しい言語ほどプログラミング効率が良くなると実感した

>>64
その通りで1年経つと自分で書いたコードでも忘れてる
機能追加などで再び触るときに読みやすさだけでなく
Rustではデータの扱いや構造をいじった時にミスるとコンパイラが敏感に叱ってくれるのが良い
おかげで時間生産性が大きく改善した

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

>>59
>cライクな構文、メモリ周りの知識、型システムの知識があればrustが極端に難しい言語ってわけではないってこと

Pythonユーザーはカスリもしないし、Javaユーザーもcライクな構文以外は知識無いだろ。

>そしてこれらの知識はプログラミングを書いていれば自然と知ることになるものだと思ってる。

そりゃ傲慢だね。
PythonとかJavaを使うのにコールスタックとかヒープとか意識したっけ？