次世代言語17 Go Rust Kotlin TypeScript Julia

**デフォルトの名無しさん** · 2019/09/04(水) 22:10:19.21

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2019/09/24(火) 16:38:57.88

ぶっちゃけここまで学習に時間掛けてできることが

型

だけだもんなw
デメリット多すぎ時間泥棒で草ぁ！w

**デフォルトの名無しさん** · 2019/09/24(火) 17:01:14.71

型あり言語にするならもうHaskellぐらいやらないと意味ないと思うよ
モナドでガチガチにしばらなきゃ型の意味がないのはJavaやC#を見たらわかる
JSのグダグダな型を無理やり型付けして何かメリットがあるのだろうか
メリットがあると思い込んでるだけの
ポジショントークだと感じます

**デフォルトの名無しさん** · 2019/09/24(火) 17:03:17.65

馬鹿は極論を好む

**デフォルトの名無しさん** · 2019/09/24(火) 17:22:40.63

TypeScriptはJavaとC#のどちらに文法が似ているのでしょうか？

**デフォルトの名無しさん** · 2019/09/24(火) 17:36:38.11

ソースの見た目はどっちかというとJavaっぽい
思想は完全にC#(設計者が同じ)

**デフォルトの名無しさん** · 2019/09/24(火) 18:30:40.49

>>617
分かりました。
返信ありがとうございます。

**デフォルトの名無しさん** · 2019/09/24(火) 18:53:48.19

型が中途半端にあるくらいなら無い方がいいよね
Cのvoid*地獄を経験した人なら分かってくれるはず

**デフォルトの名無しさん** · 2019/09/24(火) 18:54:06.48

ここでメリットないないわめいてもどこの誰にも影響与えられないのに元気だなあ

**デフォルトの名無しさん** · 2019/09/24(火) 18:56:59.02

ここは自分が習得できなかった定番の言語を貶すことで精神の安定を図ろうとする人の集まりだから

**デフォルトの名無しさん** · 2019/09/24(火) 19:24:18.59

型のドキュメント性が好きなので多少でも静的に型がつく方が好き

**デフォルトの名無しさん** · 2019/09/24(火) 19:25:09.20

ライブラリで気に入ったのがある言語を選べばいいだろ
あとは本でも買ってパチポチすればいい

**デフォルトの名無しさん** · 2019/09/24(火) 19:31:10.70

typescript推しのくせにjavaは嫌みたいな馬鹿はよく見る。
結局ファッションなんだろ。

**デフォルトの名無しさん** · 2019/09/24(火) 19:40:24.74

":" に複数のセマンティクスがあるのがキモい

**デフォルトの名無しさん** · 2019/09/24(火) 19:54:01.70

キモナイ

**デフォルトの名無しさん** · 2019/09/24(火) 19:54:10.27

いや、メリットあるだろ
メリットあると思ってる人が多いからこれだけTSが普及したわけだし、Flowとかもあるんだから

**デフォルトの名無しさん** · 2019/09/24(火) 20:27:50.03

<table>を貶すことでcssとかが普及したよね

**デフォルトの名無しさん** · 2019/09/24(火) 21:31:24.59

>>619
何？void*地獄って？

**デフォルトの名無しさん** · 2019/09/24(火) 21:47:10.60

ts推すのはjsがあるからでしょ
だからjavaもよろしいとはならんでしょ
javaをよしとするならその時点で不採用だわ

**デフォルトの名無しさん** · 2019/09/24(火) 21:57:17.76

いつから特定言語に噛みつくだけのレベル低いスレになったんこのスレ？

**デフォルトの名無しさん** · 2019/09/24(火) 22:00:57.63

レベルは元から変わらん

**デフォルトの名無しさん** · 2019/09/24(火) 22:08:45.58

正直Javaは嫌いじゃない
採用してるところに地雷が多いだけ

**デフォルトの名無しさん** · 2019/09/24(火) 22:11:00.11

Ｊａｖａがある日Ｉｎｎｕｌｌａｂｌｅになったとする

このへんの言語ってそれでも絶対必要って言えるのあるか？

**デフォルトの名無しさん** · 2019/09/24(火) 22:11:50.27

妥協なき理念
Rustだけが輝いている

**デフォルトの名無しさん** · 2019/09/24(火) 22:18:31.59

>>634
お前はＪａｖａがある日Ｉｎｎｕｌｌａｂｌｅになるまで寝て待つのかね

**デフォルトの名無しさん** · 2019/09/24(火) 22:18:39.24

漸進的型付けのユルさが好きだ。

**デフォルトの名無しさん** · 2019/09/24(火) 22:20:14.14

Javaはプログラマーの質が両極端な印象がある

**デフォルトの名無しさん** · 2019/09/24(火) 22:28:05.22

漸進的型付が好きとかないわ
JavaScriptという負の遺産をなんとかマシにするための苦肉の策だろ
JavaScriptの魔術でどうしようもない汚物みたいなシグネチャになったOSSのTS化プロジェクトを知ってるが
悲惨なもんだわ

**デフォルトの名無しさん** · 2019/09/24(火) 22:31:50.62

Rustはアルゴリズムに集中したいのに邪魔される

**デフォルトの名無しさん** · 2019/09/24(火) 22:45:03.60

なにもかも兼ね備えた言語はないのか

**デフォルトの名無しさん** · 2019/09/24(火) 22:48:09.33

まぁ、厳密な静的型付け以外認めないという人から見れば動的型付けも漸進的型付けも
同じようなもんなんだろうけど。

**デフォルトの名無しさん** · 2019/09/24(火) 23:21:44.68

>>641
アセンブラ

**デフォルトの名無しさん** · 2019/09/24(火) 23:31:20.25

>>643
何でも作れると、何でも兼ね備えるは全く別のことだぞ。

**デフォルトの名無しさん** · 2019/09/24(火) 23:34:05.69

いや何でも作れるなら作って備えりゃいいだけだろバカか？

**デフォルトの名無しさん** · 2019/09/24(火) 23:50:39.21

よし、アセンブラで型システムを作って備えよう

**デフォルトの名無しさん** · 2019/09/24(火) 23:57:00.73

>>640
最初はOCamlで集中して後でRustで書き直したという伝説がある
OCamlなんか使って後のこと考えない性格だから集中できたのか

**デフォルトの名無しさん** · 2019/09/25(水) 00:08:18.35

>>641
なにもかも兼ね備えるとC++の様な闇鍋言語が出来上がる
突き抜けてるC++は好きだけどな

**デフォルトの名無しさん** · 2019/09/25(水) 00:09:20.32

>>646
メモリ管理も大変だからGCも備えときましょうね～

ってあれ？

**デフォルトの名無しさん** · 2019/09/25(水) 00:48:28.74

>>641
JavaScriptがまさにそうだな

**デフォルトの名無しさん** · 2019/09/25(水) 00:51:49.15

>>645
何でも備えた魔法の俺俺言語の処理系をアセンブラで実装したとして、それは俺俺言語が備えているのであってアセンブラが備えている訳ではないだろバカか？

**デフォルトの名無しさん** · 2019/09/25(水) 01:22:27.87

行くぞ英雄王ーーー
俺俺ライブラリの貯蔵は十分か

**デフォルトの名無しさん** · 2019/09/25(水) 03:12:27.73

トレースオン！
Unlimited OreOre Works！！

**デフォルトの名無しさん** · 2019/09/25(水) 03:21:21.46

うわつまんね＾＾；

**デフォルトの名無しさん** · 2019/09/25(水) 04:41:24.35

>>629
ライブラリから呼び出されるコールバック関数がvoid*を引数に取ってて
そのコールバック関数内で実際のポインタ型にキャストしてやらなきゃいけないやつ
純粋なCのライブラリで、特に非同期関連のやつによくある
というかvoid*すら知らないで型の話してたの？

**デフォルトの名無しさん** · 2019/09/25(水) 05:29:13.64

はつみみです

**デフォルトの名無しさん** · 2019/09/25(水) 05:35:28.51

>>655
void* じゃなくてvoid*地獄について聞いてんだが

**デフォルトの名無しさん** · 2019/09/25(水) 06:02:27.15

最近のJavaScriptってヒョロガリの人間にサイボーグパーツを無理矢理備えつけて強くしてる感あるよな
JavaScriptである必要性がない

**デフォルトの名無しさん** · 2019/09/25(水) 08:26:44.21

nullが存在しなかったらOptionl.Noneをデフォで何でもねじ込むようになるから無意味かもね

**デフォルトの名無しさん** · 2019/09/25(水) 08:57:03.50

メモリ管理だけはどうしても言語レベルで設定しなきゃならん。
lisp、c++みたいななんでも備えた言語でもそこだけは変わらん。

**デフォルトの名無しさん** · 2019/09/25(水) 09:22:26.41

>>650
型が無いしバイナリにコンパイルも出来ない

**デフォルトの名無しさん** · 2019/09/25(水) 09:33:39.69

>>659
その二つが一緒だと思うんだ

**デフォルトの名無しさん** · 2019/09/25(水) 11:51:53.15

nullは分岐を明示しないので例外が発生する位置を明示しない
使わないメモリを節約する代わりに使用中のメモリは断片化する

**デフォルトの名無しさん** · 2019/09/25(水) 12:26:59.15

java scriptはシングルスレッドなのが英断だよね
非同期地獄をpromise、async/awaitで解消してきた歴史もすばらしい
下回りでは平行タスクが多数走るんだけど上位はそんなこと知る必要なく動く
まさにIT土木作業員用言語として天才たちがデザインした結果だと思う

**デフォルトの名無しさん** · 2019/09/25(水) 13:21:11.06

「制御の反転」を提案したオブジェクト指向
に嫉妬してもう一回反転させたのがasync/awaitだ
ルサンチマンの結果だ

**デフォルトの名無しさん** · 2019/09/25(水) 14:12:53.64

javaでも新しめのjavaなら許容できる。ラムダきたし、ローカル変数の型推論もきたし。後、async/awaitいれてくれればね

**デフォルトの名無しさん** · 2019/09/25(水) 14:15:39.19

async/await褒めるなら最初に発明したのはC#のマイクロソフトの天才たちなの？

褒めるならそっちだな

**デフォルトの名無しさん** · 2019/09/25(水) 14:29:47.58

C#のasyncはF#由来
マイクロソフトには違いないけどMSのプロダクト部門じゃなくて MS Research の成果

**デフォルトの名無しさん** · 2019/09/25(水) 15:43:48.87

MS ResearchといえばBosque

**デフォルトの名無しさん** · 2019/09/25(水) 15:49:09.41

そっか。
そういや、.net core 3リリースされてc#にもnon nullable reference typesとか使えるようになるけど、既存のライブラリ特に標準のクラスライブラリ使うときはどうなってるの？

kotlinでjavaのAPI使うとき、アノテーションされてないとプラットホーム型とかいううんこになってnull safetyの魅力半減するけど。

**デフォルトの名無しさん** · 2019/09/25(水) 16:49:52.46

async/await が地獄じゃん
C# は死んだ、JavaScript も死んだ
Java は死ぬな

**デフォルトの名無しさん** · 2019/09/25(水) 17:10:50.79

マイクロソフトが関わった言語はみんな死んで行く

**デフォルトの名無しさん** · 2019/09/25(水) 17:44:08.64

>>672
なでしことアセンブラは？

**デフォルトの名無しさん** · 2019/09/25(水) 18:09:47.02

なでしこに手を出すとは…無茶しやがって…

**デフォルトの名無しさん** · 2019/09/25(水) 18:10:15.49

>>671
Javaはアノテーションで既に死んでる

**デフォルトの名無しさん** · 2019/09/25(水) 18:14:03.63

>>664
>シングルスレッドなのが英断
それは俺も思う

この前提を壊すことなくマルチスレッドを実現するWeb Workerの概念は
優れた並列機能を実現するgoroutineでのベストプラクティスと同じ

https://blog.golang.org/share-memory-by-communicating
> Do not communicate by sharing memory; instead, share memory by communicating.
メモリの共有で通信するな、通信してメモリを共有しろ

並列で重要なのはむしろスレッドの分離性、
各々がシングルとして動けることだった

**デフォルトの名無しさん** · 2019/09/25(水) 18:37:17.12

お手軽言語としては、シングルスレッド実行モデルの方が初心者も間違えにくいからいいけど、
パフォーマンス求めるとコンテキストの切り替えのコストが大きいわな。

**デフォルトの名無しさん** · 2019/09/25(水) 18:41:39.88

dartもjavascriptにトランスパイルされたりするからjavascriptをおもいっきり引きずる環境でjavascriptと同じシングルスレッド実行モデルで、isolateって言うが、isolateの切り替えのオーバーヘッドが結構あるらしい
https://medium.com/flutter-jp/isolate-a3f6eab488b5

**デフォルトの名無しさん** · 2019/09/25(水) 18:44:49.45

>>675
??

**デフォルトの名無しさん** · 2019/09/25(水) 18:45:07.98

色んなドメインが共存する現状が既にカオスなのに
マルチスレッド下でルール無用の資源の奪り合いしたらすごいことになりそう

**デフォルトの名無しさん** · 2019/09/25(水) 18:56:28.15

>>670
corefxの既存API（string.IsNullOrEmptyとか）にも使用頻度の高いものから順次対応されてるよ

**デフォルトの名無しさん** · 2019/09/25(水) 23:08:10.72

>>680
だから直列化トークンとクリティカルセクションをうまく使いなさいよ

**デフォルトの名無しさん** · 2019/09/25(水) 23:32:59.45

JavaのアノテーションもC#から来てるよな

**デフォルトの名無しさん** · 2019/09/25(水) 23:34:49.80

これマジ？

**デフォルトの名無しさん** · 2019/09/25(水) 23:40:50.67

一時期マルチコアの性能を活かすためにはスレッドが必要とか言われてたけど
ディープラーニングみたいな本当に並列処理しなきゃ話にならないものはGPGPUへ移ったから
もうスレッドは用済み

**デフォルトの名無しさん** · 2019/09/25(水) 23:47:35.85

用済みは言い過ぎ

**デフォルトの名無しさん** · 2019/09/26(木) 00:28:18.38

レイトレーシングが流行り始めてるからCPUの並列処理はこれから重要度が増えていくさ

**デフォルトの名無しさん** · 2019/09/26(木) 00:28:51.73

並列化が重要になる一方でコンテキストスイッチのオーバーヘッドが問題になって
そのトレードオフとして生まれたのが軽量スレッドだろ
async/await もそうだし golang もそう
関数型言語がもてはやされるのも相性が良いから

**デフォルトの名無しさん** · 2019/09/26(木) 01:04:15.23

>>582 Google が既に Java を捨てただろ。

**デフォルトの名無しさん** · 2019/09/26(木) 01:13:11.48

アルゴリズムは色々抽象化されたのに
データ構造がただの文字列とかって絶対おかしいって言い出したのがOOP
だが、ただの文字列は並列化と相性が良かった

言語を関数型にする必要はないよ
データ構造だけ変えろよ

**デフォルトの名無しさん** · 2019/09/26(木) 01:38:55.69

つっこみどころ満載で逆に萎えたわ

**デフォルトの名無しさん** · 2019/09/26(木) 01:57:27.49

>>690
なるほど…

**デフォルトの名無しさん** · 2019/09/26(木) 02:19:21.18

>>690
これコピペ？ｗ
めっちゃワロタｗｗｗ

**デフォルトの名無しさん** · 2019/09/26(木) 04:05:20.30

Rust製の新作

https://blog.cloudflare.com/warp-technical-challenges/

**デフォルトの名無しさん** · 2019/09/26(木) 05:43:43.22

TypeScriptってClassを使わないとJavaScriptが書けない人向けの介護ツールって認識でいいよね？

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

async/awaitぐらい無い言語でもライブラリレベルで実装してみせよ
ラムダ式が使える言語なら比較的ｶｿﾀｿに似たような書き方にできうる

**デフォルトの名無しさん** · 2019/09/26(木) 06:15:44.02

>>689
KotlinはまだJavaくね？
いや知らんけど

**デフォルトの名無しさん** · 2019/09/26(木) 07:16:46.29

>>695
それと型がないと頭が働かない知恵遅れ向け

**デフォルトの名無しさん** · 2019/09/26(木) 07:41:21.66

むしろTypeScriptにclassは要らん

**デフォルトの名無しさん** · 2019/09/26(木) 08:41:50.36

JSもGoもclass不要の言語だったのに
最近はclassの悪口を言う需要はRustに全部持って行かれた
他は「悪口はよくない」って小学生みたいな感情を持つだけの存在

**デフォルトの名無しさん** · 2019/09/26(木) 08:49:51.01

>>700
JSの一番面白いところはclass使えるのに誰も使わないところでもあるんだけどな

**デフォルトの名無しさん** · 2019/09/26(木) 09:25:13.63

Reactのhooks APIもクラスベース開発が嫌で嫌でしょうがなく開発整備されたものだからな。
だいたい状態をひとつにまとめてそのほかでは持たないように徹底することの障害になる。

**デフォルトの名無しさん** · 2019/09/26(木) 09:56:11.12

ストールマンってFSFから退任してたんだな

**デフォルトの名無しさん** · 2019/09/26(木) 10:13:51.92

JSにclass導入するならするで、メソッド名の参照は
関数にbind(this)したものをメモ化して返すgetter(*1)にするか
もしくは obj::method のような構文糖衣(*2)を入れるべきだった

https://ja.reactjs.org/docs/faq-functions.html
> this.handleClick = this.handleClick.bind(this);
中途半端だからこんなゴミみたいな行が必要になる

onClick={this.handleClick} (*1)
onClick={this::handleClick} (*2)

**デフォルトの名無しさん** · 2019/09/26(木) 12:53:24.65

Rubyなら、あらゆる言語の欠点が解消される。

何より、実装が、早い。
スタートアップとか、には必須。

新言語はRubyに決まり！！！！！！！！！

**デフォルトの名無しさん** · 2019/09/26(木) 13:27:51.81

>>705
シェア1.2%でランク外のマイナー言語がどうした？
https://www.tiobe.com/tiobe-index/

**デフォルトの名無しさん** · 2019/09/26(木) 13:34:16.90

Rubyが新言語とか笑わせるがTIOBEを持ってくるのもどうかしている

**デフォルトの名無しさん** · 2019/09/26(木) 13:35:59.57

TypeScript は関数のシグネチャの明示と最低限静的チェックを通る程度に安全なコードを *全員に* 強制するためのツール

そもそも多人数ないし長期で開発するならどうせ関数のシグネチャはDOCコメント書くことになるんだし
どうせ型書くんだから静的解析もしてしまった方が得

**デフォルトの名無しさん** · 2019/09/26(木) 13:42:40.38

kotlin以外どこで何する言語なのかわからない
一つ一つ幅利かせてる分野を教えてちょ

**デフォルトの名無しさん** · 2019/09/26(木) 14:28:50.55

フロントで型が重要になるシーンってどんなときなの？

**デフォルトの名無しさん** · 2019/09/26(木) 14:39:07.79

俺はJuliaしか知らんからよくわからん。

**デフォルトの名無しさん** · 2019/09/26(木) 14:52:00.95

>>710
自己を満足させるシーンで必要

**デフォルトの名無しさん** · 2019/09/26(木) 15:00:19.91

>>710
意識高い系のコードレビューをパスするために必要