次世代言語15 Go Rust Bosque Kotlin TypeScript

**デフォルトの名無しさん** · 2019/04/19(金) 22:19:00.41

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2019/06/04(火) 01:05:20.63

とりあえずjavascriptが滅びてくれれば良いよ

下手に有能な人が有用なライブラリ作っちまってなかなか滅びてくれない

**デフォルトの名無しさん** · 2019/06/04(火) 01:49:36.49

面白味や工夫の余地は無いが誰が書いても同じ物を
ひたすらだらだら並べるしかないという意味では書きやすいと言えるかも

**デフォルトの名無しさん** · 2019/06/04(火) 01:54:27.71

>>225
なんで？

**デフォルトの名無しさん** · 2019/06/04(火) 02:10:09.55

滅びるわけないだろ世の中の仕組みが分かってない奴だな。
だいたいメタに考えても無い。
なぜならこの世の中で>>225の希望が叶ったことなんてひとつも無いからだ。
これからもそう。
俺は正しい世の中が間違っていると僻んで妬んで死んでいく。

**デフォルトの名無しさん** · 2019/06/04(火) 07:25:00.53

goはビルドが楽だわ。
他の言語はビルド工程についてろくなものを用意しない。
まあにわか商売するならそれは正解なんだが。

**デフォルトの名無しさん** · 2019/06/04(火) 07:46:12.42

include地獄とかないのはいいよね
バイナリはデカいけど

なにあれ

小さくできないの？

**デフォルトの名無しさん** · 2019/06/04(火) 08:02:43.00

goはバカナリ

**デフォルトの名無しさん** · 2019/06/04(火) 08:50:39.65

Go別に速くねえと思うんだけど、速いって何と比べてんだ？

**デフォルトの名無しさん** · 2019/06/04(火) 08:53:46.08

>>232
Pythonと比べてだよ

**デフォルトの名無しさん** · 2019/06/04(火) 08:54:25.85

マルチスレッドを扱いたいときにはgoは便利なんだけど、
マルチスレッドって可能な限り避けるべきと思ってて、
そんなgo使いたいことってある？って気持ちになる

**デフォルトの名無しさん** · 2019/06/04(火) 09:15:55.70

Goがアーリーアダプターの能力に恵まれたってのはある
血統や反C++思想に惹かれてベテランのCエンジニアが賛同し、
デプロイ性の高さや非同期処理のエレガントさに惹かれてハイスキルなバックエンドエンジニアが賛同した
最初に目をつけたのがRuby信者やHaskell信者だったら、ElixirやScalaのようにエモい人達の一時の祭で終わってた

**デフォルトの名無しさん** · 2019/06/04(火) 09:26:55.20

>>233 Python といってもいろんな実装があるからな。
スピードが欲しい時はそれなりの実装を使うだろ。
PyPy とGOは同程度のスピードだろ。
NumbaだとGO の3倍くらいは早くなるよ。
Cython だともっと早くなる。

大抵はライブラリが最適化されてるから何もしないでもかなり早いよ。実際に統計処理とか比較してみるとわかる。

**デフォルトの名無しさん** · 2019/06/04(火) 09:36:02.60

きっついなあ

**デフォルトの名無しさん** · 2019/06/04(火) 10:17:42.21

反C++思想といいながらなぜPythonと比較するんだい？
それは「C++もPythonもどっちもどっち」とでもいうべき思想だろ

**デフォルトの名無しさん** · 2019/06/04(火) 12:07:17.04

それなりのライブラリを使ったら速いのは知ってるんよ。。。

**デフォルトの名無しさん** · 2019/06/04(火) 12:12:16.04

>>236
C言語だからな

**デフォルトの名無しさん** · 2019/06/04(火) 12:45:13.80

>>232
スピンアップじゃね？
これもGoogleが作ってる恩恵なんだろうが

**デフォルトの名無しさん** · 2019/06/04(火) 13:40:03.02

>>235
エモい（）無能の祭りで終わった言語にRust足しといて

**デフォルトの名無しさん** · 2019/06/04(火) 14:24:39.32

firefoxで使われてんじゃん

**デフォルトの名無しさん** · 2019/06/04(火) 15:51:24.12

WebAssemblyを次世代言語って言い張れる？
いちおうそれまでなかったのは確かｗ

**デフォルトの名無しさん** · 2019/06/04(火) 15:58:59.38

誰も素で書かないコンパイルターゲットだからバイナリとかVMバイトコードとかの競合では

**デフォルトの名無しさん** · 2019/06/04(火) 17:41:42.55

いずれwebassemblyって無くなりそうじゃない？

**デフォルトの名無しさん** · 2019/06/04(火) 18:27:03.01

あれもビルドがめちゃくちゃ遅いw
ほんとダメな機能ってのはわかりやすいわw

**デフォルトの名無しさん** · 2019/06/04(火) 18:51:05.59

>>244
中間言語の位置じゃね？

**デフォルトの名無しさん** · 2019/06/04(火) 19:30:35.98

そうだね

**デフォルトの名無しさん** · 2019/06/04(火) 20:41:46.70

scalaはいろいろ実績もあるしelixirやjuliaなんかと一緒にされたら可哀想

**デフォルトの名無しさん** · 2019/06/04(火) 21:03:43.85

やっぱrustは終わりかけてるの？

**デフォルトの名無しさん** · 2019/06/04(火) 22:04:21.17

パカソンが型ガバだからGoがウケたってのもあるな
mypyゴミすぎ

**デフォルトの名無しさん** · 2019/06/04(火) 22:17:03.60

pythonとgoなんてほとんど関係ねーわ。
パースを楽にしようとかそのくらいの視点しか関係してるところがない。

**デフォルトの名無しさん** · 2019/06/05(水) 00:23:45.19

>>251 rust は最初から錆び付いてるからね。

**デフォルトの名無しさん** · 2019/06/05(水) 05:24:48.22

えーみんなrust嫌いなの？

**デフォルトの名無しさん** · 2019/06/05(水) 10:21:36.89

おれ的には始まってる
なんとか説得して少しだけ使ってるけど心地よすぎぃ

**デフォルトの名無しさん** · 2019/06/05(水) 10:32:46.07

もっと客観的な欠陥があればその話をしたいところだが
嫌われているかもしれない以外の問題点が見つからなかったんだ

**デフォルトの名無しさん** · 2019/06/05(水) 11:25:25.15

>>250
負の実績がいっぱいあるね

**デフォルトの名無しさん** · 2019/06/05(水) 15:32:02.23

>>256
どんな仕事で使ってるの？
やっぱりc++置き換えとして？

**デフォルトの名無しさん** · 2019/06/05(水) 18:56:26.25

性能もデプロイも人と一緒に作業することも考えなけりゃそりゃ心地いいだろうね。

**デフォルトの名無しさん** · 2019/06/05(水) 19:01:46.58

ちんちんしこしこ？

**デフォルトの名無しさん** · 2019/06/05(水) 19:48:44.82

goとrubyのnilが受け付けない。
いや、nullにしろよ。

**デフォルトの名無しさん** · 2019/06/05(水) 20:07:29.78

lispをかじったことがあるならnilに抵抗無い。nullもnilもラテン語由来で無を意味するもので、別にtypoというわけじゃない。
けどnullもnilもあって別物だよ！とかいう言語は設計をやり直した方が良い。片方だけにしろと言いたい。

**デフォルトの名無しさん** · 2019/06/05(水) 20:27:33.95

nilだとエロくないからなあ

**デフォルトの名無しさん** · 2019/06/05(水) 21:08:16.91

nilはSwiftで慣れた

**デフォルトの名無しさん** · 2019/06/05(水) 21:15:45.44

nilはパスカルじゃ？

**デフォルトの名無しさん** · 2019/06/05(水) 22:22:57.66

>>259
cとかjavaとか

>>260
そんな楽な仕事があるならいいな！

**デフォルトの名無しさん** · 2019/06/05(水) 22:50:26.06

nil が正しい

null はポインター

**デフォルトの名無しさん** · 2019/06/05(水) 22:55:22.69

niplとかなら本気出せたな

**デフォルトの名無しさん** · 2019/06/05(水) 23:33:28.01

>>263
これ同意。

**デフォルトの名無しさん** · 2019/06/05(水) 23:35:44.89

やっぱ悪貨は出回りやすいのう

**デフォルトの名無しさん** · 2019/06/06(木) 00:07:13.34

>>266
LISPは1960年に発表された時点でNILだし流石にLISPが先では

**デフォルトの名無しさん** · 2019/06/06(木) 00:17:37.37

>>263
ハイ先生質問です
nullとundefinedがあるJavaScriptは許されますか？

**デフォルトの名無しさん** · 2019/06/06(木) 00:27:12.35

つまりtypescriptにもある

**デフォルトの名無しさん** · 2019/06/06(木) 00:37:48.55

PythonのNoneは？

**デフォルトの名無しさん** · 2019/06/06(木) 04:58:36.69

typoscript

pythonは許す

**デフォルトの名無しさん** · 2019/06/06(木) 11:52:20.99

NoneはOption<T>
nilはList<T>
nullはポインタ<T>

型は不要と思うならこういうのが3つ以上存在することに抵抗がある
1つくらいならあってもいいが

**デフォルトの名無しさん** · 2019/06/06(木) 12:14:30.45

概念の違いと運用を混同している

**デフォルトの名無しさん** · 2019/06/06(木) 14:06:06.41

Optionの不動点は自然数と等価なんだよな
これは人間の錯覚や感情論などではない

**デフォルトの名無しさん** · 2019/06/06(木) 22:34:22.75

SwiftUIが盛り上がってたから久々にSwiftの言語仕様の変更点とか見てたら
Opaque Result Typeってのがあって、これ自体はまぁいいんだけど

protocol周りの仕様がホント悪臭放ってんなって改めて思ったわ

**デフォルトの名無しさん** · 2019/06/07(金) 02:28:39.22

これのバックエンドは全部Rustらしい
Goでも書いたけどRustで書き直したってさ

https://gigazine.net/news/20190606-bloom-open-source-google/
https://users.rust-lang.org/t/bloom-a-free-and-open-source-google-in-rust/28981

**デフォルトの名無しさん** · 2019/06/07(金) 06:29:06.55

BUT the language itself is too poor. Lack of immutability, lack of generics, mediocre module system, very poor package management at the time … made it doesn’t really scale.

It’s really easy to write HTTP servers in Go, but nothing more, the business layer is completely rotten by the imperative paradigm. The worst thing being pointers.

なるほどね

**デフォルトの名無しさん** · 2019/06/07(金) 12:18:53.00

prologブームの遺児みたいなimmutabilityに
googleの仕事が奪われる

**デフォルトの名無しさん** · 2019/06/07(金) 18:43:06.16

>>281
いつかメンテナンスできなくならなければいいんだが

**デフォルトの名無しさん** · 2019/06/07(金) 18:51:12.09

一時期ブームに乗ってscala採用した企業は今どうやってメンテナンスしてるんだろ

**デフォルトの名無しさん** · 2019/06/07(金) 18:52:53.52

どうって？

**デフォルトの名無しさん** · 2019/06/07(金) 19:45:47.00

文献の貯蔵は十分か？

**デフォルトの名無しさん** · 2019/06/07(金) 20:33:49.35

>>284
何言語使えば将来のメンテが安心？COBOL？

**デフォルトの名無しさん** · 2019/06/07(金) 20:58:05.33

rustだったgoのがメンテしやすいだろ。

**デフォルトの名無しさん** · 2019/06/07(金) 21:41:24.93

両方書いてそう思うとは思えないな

**デフォルトの名無しさん** · 2019/06/07(金) 21:42:46.89

scalaはtwitterが使ってたよね

**デフォルトの名無しさん** · 2019/06/07(金) 21:49:11.58

>>290
両方書いてそう思うが。
逆に両方書いてそう思わないのが不思議。

**デフォルトの名無しさん** · 2019/06/07(金) 22:27:17.36

そうか
感性の違いだな

**デフォルトの名無しさん** · 2019/06/07(金) 22:33:20.57

scalaはコンパイル重杉重三さんなのが致命的だったね
劣化scalaのkotlinなんぞに負けるとは情けない

**デフォルトの名無しさん** · 2019/06/08(土) 00:09:04.82

何と戦ってるか知らんが
scalaで負けたならkotlinを投入しても結果はほぼ同じだろ
結果を変えたいなら学習コストも保守コストも桁違いの手段を使えばいい

**デフォルトの名無しさん** · 2019/06/08(土) 08:10:32.53

>>293
サンクコストにひきづられるかどうかの違いだよ。
まあそれも感性か。

**デフォルトの名無しさん** · 2019/06/08(土) 08:36:13.18

>>292
>>293
これ興味ある。感性の違いで片付けずに戦ってみてくれないか？
規模の違いとかoopっぽく書いたかどうかとかなんかな
それとも人員確保の話なのかな

**デフォルトの名無しさん** · 2019/06/08(土) 10:32:52.62

行数の分だけバグは増えるぞ

**デフォルトの名無しさん** · 2019/06/08(土) 13:00:28.02

暗黙の動作が多い言語ほどバグを引き起こす。

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

>>288 バカ言ってんじゃないよ。どこからそんな考えが出てくるのやら。情報処理試験からも削除された化石言語だぞ。

情報処理試験の C Java Python なら心配する事は無い。

**デフォルトの名無しさん** · 2019/06/08(土) 13:29:35.68

>>299
それはただの副作用ですよね

**デフォルトの名無しさん** · 2019/06/08(土) 14:11:25.45

「ただの」と言い切ってしまう感性のやつはプログラムをやらない方がみんな幸せそうだと思うよ。

**デフォルトの名無しさん** · 2019/06/08(土) 14:41:41.32

>>299
rupyのことですね分かります

**デフォルトの名無しさん** · 2019/06/08(土) 15:21:17.99

手続き型でコードをたくさん書くのが幸せと感じる、個人の趣味と混同するようなレベルの低いプログラマーとは
いっしょに仕事したくないね

**デフォルトの名無しさん** · 2019/06/08(土) 15:49:24.97

>>300
どう見ても冗談だと思うけど…

**デフォルトの名無しさん** · 2019/06/08(土) 16:27:41.85

>>305 どこが？むしろ COBOL の方が冗談きついだろ。

**デフォルトの名無しさん** · 2019/06/08(土) 16:41:08.79

COBOLは何十年前のコードがそのまま動くし
今書いたコードが突然非互換アップデートで死ぬ心配もない

**デフォルトの名無しさん** · 2019/06/08(土) 17:46:22.81

マシンには読めても人には読めなくなる。マシンが読むには不要な意味や意図が読めないのなら、そのシステムは進化も変化もできなくなる

**デフォルトの名無しさん** · 2019/06/08(土) 18:21:42.01

COBOLが悪いんやない
設計も実装もできない趣味で手続き型量産してる>>302みたいなガイジがCOBOL書いたから悪いんや

**デフォルトの名無しさん** · 2019/06/08(土) 18:23:20.95

レッテル貼りとは情けない

**デフォルトの名無しさん** · 2019/06/08(土) 18:24:28.68

>>307 全くどうしようもない奴だな。誰がCOBOL で書かれたシステムをメンテナンスするんだ？
COBOL なんて老人ホームの人間しかメンテナンス出来ないぞ。少し強調しすぎたが。

言語と言うのはどんなニッチな言語でもかなりの期間は使い続けられるが、それをメンテナンスできる人間が継続して育つかと言うのとは別問題。

**デフォルトの名無しさん** · 2019/06/08(土) 18:29:56.76

COBOLはついこの前まで原発を動かしていた
メンテナンス出来る人間は一応いる

というか今でも日本のどこかで動かしてるんじゃないの？

**デフォルトの名無しさん** · 2019/06/08(土) 18:30:53.46

というか今でも日本のどこかで動かしてるんじゃないの？というのは原発のこと

**デフォルトの名無しさん** · 2019/06/08(土) 18:40:57.88

>>311
COBOLなんか誰でもできる
不足しているのはCOBOL工ではなく、メインフレームを運用できる技術者
オープン系より遥かに難易度が高く、高度な修練が必要とされる職人芸の世界

**デフォルトの名無しさん** · 2019/06/08(土) 18:44:49.33

>>311
python2とかRuby1.xとかPHP4とかのメンテは
人が育つとかの次元じゃねーぞ

**デフォルトの名無しさん** · 2019/06/08(土) 18:53:06.08

今から本気の本気でscala勉強しようとする人はいるのか？
しかも超優秀で使い物になる人で

**デフォルトの名無しさん** · 2019/06/08(土) 19:53:22.51

>>315
cobolのシステムより価値がなく
cobol並にレガシーな言語
悪夢だわな

**デフォルトの名無しさん** · 2019/06/08(土) 19:58:45.02

>>317
COBOLは言語処理系自体が消えるとかは
無いのでそこはちょっと違う

**デフォルトの名無しさん** · 2019/06/08(土) 21:56:54.48

コンテキストによって使えるAPI制限できる言語ってありますか？
割込みコンテキストとかイベントループでsleep禁止のような

**デフォルトの名無しさん** · 2019/06/09(日) 03:00:13.29

>>319
言語自体に？聞いたことない
というかコーディングルールで決めてLINTみたいなもので自動チェックさせるんじゃない？

**デフォルトの名無しさん** · 2019/06/09(日) 03:38:53.80

あとはRoslynのAnalyzerはめっちゃ強力で自由度も高い

**デフォルトの名無しさん** · 2019/06/09(日) 06:10:20.02

コンテキストってのを明示的にsleepに渡すのがセオリーだよな
つまりsleepの引数を一個増やす

ただしコンテキストの捏造はないものとする
その型のコンストラクタ使用禁止
同じ型の変数定義禁止またはその変数への代入禁止や所有権移動禁止

**デフォルトの名無しさん** · 2019/06/09(日) 06:22:10.99

センスがないな

**デフォルトの名無しさん** · 2019/06/09(日) 07:15:38.36

>>297
俺はGoが嫌いだからそれはできないな