次世代言語15 Go Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2018/11/04(日) 20:30:10.42

スレタイ以外の言語もok

前スレ
次世代言語14 Elixir Crystal Julia Rust Swift
https://itest.5ch.net/mevius/test/read.cgi/tech/1536668904

**デフォルトの名無しさん** · 2019/03/17(日) 11:52:05.42

型無し糞ガイジの老害が死滅すれば済む話
頭のアホ毛＄から腐臭が漂ってくるんだよ、早く死ね

**デフォルトの名無しさん** · 2019/03/17(日) 14:54:23.26

エディタを終了してからテストを実行するのはターン制だから古臭いんだな
リアルタイムこそが現実であり次世代であるはずなのに一体なぜターン制が滅びないのか

**デフォルトの名無しさん** · 2019/03/17(日) 17:44:29.53

>>538
おだいじに。ちゃんとお薬のむんだよ。

**デフォルトの名無しさん** · 2019/03/17(日) 18:24:15.45

>>540
薬を飲むべきはおまえさんやで、型無し糞ガイジｗ

**デフォルトの名無しさん** · 2019/03/23(土) 08:00:57.82

次世代言語として必須機能はなんですか？

**デフォルトの名無しさん** · 2019/03/23(土) 09:10:22.60

高速で軽量、堅牢な非同期処理のサポート
デフォルト実装を定義できるインターフェイス（and/or 型クラス）
高度な型推論（もとより静的型）
高速なコンパイルとコンパクトな実行ファイル（非AltoJS、JVM言語）
関連して、セルフホスティングやブートストラップは完了済み

**デフォルトの名無しさん** · 2019/03/23(土) 09:23:43.23

>>54
様々なポリシーの元に設計されて良いだろうから必須なんて機能は無いんじゃないか

**デフォルトの名無しさん** · 2019/03/23(土) 09:24:21.62

>>544
>>542宛だった

**デフォルトの名無しさん** · 2019/03/23(土) 11:11:33.27

何を作りたいかによるよね。作りたいものが作りやすければ良いわけだから。

**デフォルトの名無しさん** · 2019/03/23(土) 22:35:21.72

皆さん的にvlangどうなの？

**デフォルトの名無しさん** · 2019/03/23(土) 23:03:36.39

実物待ちじゃないの

**デフォルトの名無しさん** · 2019/03/24(日) 13:56:01.89

ぶっちゃけTypeScriptが強最やろ

**デフォルトの名無しさん** · 2019/03/24(日) 14:23:51.27

強いかはともかく、最も美しいプログラミング言語の一つではある

**デフォルトの名無しさん** · 2019/03/24(日) 16:01:57.35

tsいいんだがjavascriptの呪縛から解き放ってやりたい感

**デフォルトの名無しさん** · 2019/03/24(日) 16:09:10.35

今のesならそんなに捨てたもんでもないと思うが。
まぁでも、tsにclassは要らなかったな。

**デフォルトの名無しさん** · 2019/03/24(日) 16:18:49.96

しょせんパフォーマンスでない言語

**デフォルトの名無しさん** · 2019/03/24(日) 16:34:58.29

esにもクラスはなくても良かったけどデコレータは早く来てほしいね
デコレータ風に組めなくもないけど面倒だしな

**デフォルトの名無しさん** · 2019/03/24(日) 18:01:12.81

tsはjsの呪縛でガンガンに縛られてるから全然いい言語に見えない

共有型からの流れのせいでコードに無駄な型判定が入ってて全然スマートじゃない

**デフォルトの名無しさん** · 2019/03/24(日) 19:00:10.91

>共有型からの流れのせいでコードに無駄な型判定が入ってて全然スマートじゃない

ちょっとピンとこないけど具体的にはどういう記述？

**デフォルトの名無しさん** · 2019/03/24(日) 19:23:03.00

http://js.studio-kingdom.com/typescript/handbook/advanced_types

型判定のiｆなどが邪魔すぎる
こういうのを見てスマートだと感じるなら毒されている

**デフォルトの名無しさん** · 2019/03/24(日) 19:32:49.50

それは無駄な判定とは思わないが、どう記述出来たらスマートだと言うんだろう。
パターンマッチとか？

**デフォルトの名無しさん** · 2019/03/24(日) 19:37:55.56

無駄っつーかanyって言ってるのに実際は2つの型しか認めないのは無責任やな

**デフォルトの名無しさん** · 2019/03/24(日) 19:44:07.97

>>557
直和型をパターンマッチで処理切り分けるのは、関数型言語からの流れで最近の流行りだと思うんだけどね
if 文で書くのはダサいな

>>559
any がダメだから string | number と書くというのが共用体型じゃないの？おれもtsはよく知らないんだけど

パターンマッチで切り分けて、すべての可能性を記述してない場合にはエラーにしてほしいね

**デフォルトの名無しさん** · 2019/03/24(日) 20:34:17.47

まぁパターンマッチ構文で多少記述がシンプルになるならそれもいいけど、逆に専用の構文に頼らずに
ifやswitchを使っても同等のことができているというのがいいところだと思うがなぁ。
シンタックスシュガーとして入れるなら後からでもできるんじゃね？

>パターンマッチで切り分けて、すべての可能性を記述してない場合にはエラーにしてほしいね

それをエラーにするような記述は今でもできる。パターンマッチなんてなくても。

**デフォルトの名無しさん** · 2019/03/24(日) 21:15:12.88

>>561
そんなのなくない？
String | Date | Number
だったとして、StringとNumberの処理しか書いてなくってそれがエラーにはならんやろ

やっぱScala最強やね
コンパイル速度ゴミで死んでしまったが

**デフォルトの名無しさん** · 2019/03/24(日) 21:22:23.00

>>562
TypeScriptは Discriminated Union 使えるよ
メンバのリテラル値によって型をマッチさせるという中々面白い仕様

**デフォルトの名無しさん** · 2019/03/24(日) 21:32:02.61

sbt言うほど遅いか？
Scala2.13でまたちょっと速くなるみたいだし
それにScala3まであと一年と考えるとScala最強説が蘇る可能性もあるで

**デフォルトの名無しさん** · 2019/03/24(日) 21:42:20.21

scala死んだ理由どう考えてもバージョン上がる度にコンパイル通らなくなる互換性のなさだろ
3なんかにしたら爆死以外見えない

**デフォルトの名無しさん** · 2019/03/24(日) 22:02:19.88

>>563
ここら辺見て ts 勉強させてもらったよ https://qiita.com/kobanyan/items/ca56df27de50ec267995
Discriminated Union はすべての可能性を記述してない場合にエラーとするための仕組みになってないだろ
その下に書いてある Exhaustiveness checking っていうのが求めてるものだ

でも、
--strictNullChecks つけて戻り値の型のでチェックするのはswitchの下にreturn 文書いちゃったらスリ抜けちゃわない？
default: return assertNever(s) を記述することでチェックするのは、その記述が無くてもエラーにしてほしいんだけど？

**デフォルトの名無しさん** · 2019/03/24(日) 22:17:38.55

>default: return assertNever(s) を記述することでチェックするのは、その記述が無くてもエラーにしてほしいんだけど？

どのパターンにもマッチしない場合に何もしないという場合はあるわけだから、エラーにするのか
しないのかを示さなきゃならないのは仕方ないだろう。
strictNullChecks付けるのを忘れるからデフォルトでonにしてほしいとか言ってるようなもん。

**デフォルトの名無しさん** · 2019/03/24(日) 22:46:49.41

>>567
case 文で全パターンを網羅できない場合には default 必須にして欲しい
どのパターンにもマッチしない場合に何もしないときは、その default の処理を空っぽにする
これを強制したい

**デフォルトの名無しさん** · 2019/03/24(日) 22:52:15.99

それはlintでやればいい。

**デフォルトの名無しさん** · 2019/03/24(日) 23:24:23.33

みんなが Lint かけてくれるわけじゃないので、コンパイル時チェックが望ましい
特に新しい言語作るのならばそうすべき

**デフォルトの名無しさん** · 2019/03/24(日) 23:25:57.15

あと、>>563は、言語の機能と、コーディングパターンの区別がついてないよね？

**デフォルトの名無しさん** · 2019/03/24(日) 23:29:21.26

>>571
言語の機能として公式ドキュメントに記載されてるんだよ
https://www.typescriptlang.org/docs/handbook/advanced-types.html

**デフォルトの名無しさん** · 2019/03/24(日) 23:54:07.40

>>572
Discriminated Union とか Exhaustiveness checking は、言語機能じゃなくて
いくつかの言語機能を組み合わせて実現可能なコーディングパターンの解説をしているように見えるよ？
そのドキュメントが Specification じゃなくて Hand book だし

**デフォルトの名無しさん** · 2019/03/25(月) 00:04:21.99

>>570
そういう腐った現場で強制してもコンパイル通すためだけのくそハックが横行するだけ。
事態をもっとややこしくする。

**デフォルトの名無しさん** · 2019/03/25(月) 00:28:45.64

>>574
コンパイル通すためのハックしてることがコード見ただけで分かるのが重要

**デフォルトの名無しさん** · 2019/03/25(月) 07:59:56.31

>>570

lintすら不要と思っている人が>>560のようなチェックをしたいと思うシチュエーションが考えにくいが。
PLがメンバーに強制するならlintごと使わせればいいわけだしな。

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

次世代言語を名乗るなら網羅性がチェックされたパターンマッチ構文は必須でしょ
TypeScriptのswitch文がJSからのしがらみで前時代的なのは仕方ない

**デフォルトの名無しさん** · 2019/03/25(月) 13:08:18.82

マイクロソフトの「TypeScript」など上昇--RedMonkプログラミング言語ランキング
Liam Tung （Special to ZDNet.com）翻訳校正：編集部 2019年03月25日 12時26分
https://japan.zdnet.com/article/35134639/

　Microsoftのプログラミング言語「TypeScipt」の人気が上昇しており、Appleの
「Swift」に続く順位についた。(中略)

　TypeScriptは2018年8月に発表された前回の調査から4つ順位を上げた。JavaScriptは
首位となっている。TypeScriptの最新の順位は、RedMonkが「これまでで最も成長の速い
プログラミング言語」とするSwiftの1つ下だ。

　RedMonkのStephen O'Grady氏は、「TypeScriptは確かにJavaScriptと近いことや、オプ
ションの静的型チェックなどの安全性を実現する機能からメリットを得ている。だが、機能
だけではこのペースで大きく前進できない。成長中の幅広いプロジェクトに活用されて
いるはずであり、これら全てが、TypeScriptの成長が目覚ましく、持続性のあるものと
なっている理由を示している」と説明している。(中略)

　TypeScriptよりも急速に成長している言語は「Kotlin」だ。Kotlinは前回から8ランク
アップし、今回の調査では20位となった。O'Grady氏によると、Kotlinの成長速度はSwiftに
次ぐレベルだという。

　KotlinはGitHubの「2018 Octoverse」レポートでも、GitHubで最もコントリビューター
人口が増えている言語となった。KotlinはGoogleが公式にサポートしているAndroidアプリ
開発言語であることからAndroidのアプリ開発者に人気で、Googleによると「Google
Play」で提供されているAndroidアプリのトップ1000のうち、27％でKotlinが使用されて
いるという。(後略)

**デフォルトの名無しさん** · 2019/03/25(月) 13:08:57.00

purescript全然流行ってないぞｗ
やっぱts人気なのはjs互換だから。良くも悪くも。

**デフォルトの名無しさん** · 2019/03/25(月) 13:17:36.44

npmがあってこそ

**デフォルトの名無しさん** · 2019/03/25(月) 13:40:39.94

tsといいkotlinといい、言語を流行らせるならまずは開発環境が大事というのがよくわかる結果だな

**デフォルトの名無しさん** · 2019/03/25(月) 13:43:55.66

Kotlin 万歳

**デフォルトの名無しさん** · 2019/03/25(月) 13:45:37.65

JSは言語というより環境
つまりSmalltalkがやりたかったことをやってるのが大事なポイントだ
それとJavaがやりたかったこと (JNI禁止) もまあやってる

**デフォルトの名無しさん** · 2019/03/25(月) 13:46:17.07

>>581
開発環境と作ったプログラム動かす環境、更にそれで確実に金儲けが出来そうだと思わせる状況があるとよい。

**デフォルトの名無しさん** · 2019/03/25(月) 14:07:09.12

まぁRailsもそうだったけど「これ作るならこれ！」みたいな洗脳が上手くできるかどうかだよね

**デフォルトの名無しさん** · 2019/03/25(月) 14:19:36.61

でも洗脳を解いてやったらC/C++をすらすら書けるようになるわけじゃないし
宗教があるのは難易度を下げるのがメインで洗脳は副産物

**デフォルトの名無しさん** · 2019/03/25(月) 15:04:53.80

Javaも部分的かつ牛歩だけど、モダン機能に追従していってる
https://qiita.com/nowokay/items/0e860819b6ffb1aca90a#switch%E5%BC%8F

言語でなく環境の方でもGraalVMを進めてるし一応止まってはいない感じ

**デフォルトの名無しさん** · 2019/03/25(月) 15:17:23.11

Javaは本質的な不便さから目を背けてミーハーな目立つ機能をつまみ食いしてる印象
いいかげん例外透過やクッソ使いづらい非同期APIをなんとかしろ

**デフォルトの名無しさん** · 2019/03/25(月) 15:51:46.88

javaは中間コンパイルしたあとのソースを見るとやる気なくなる

**デフォルトの名無しさん** · 2019/03/25(月) 16:00:12.57

Java「じゃあ互換性切り捨てて小鳥に寄せます」
ってならね？

**デフォルトの名無しさん** · 2019/03/25(月) 17:45:18.30

>>578
金で操作できるランキングに価値ねえよ
上位言語が企業のステマ言語って時点で疑問持てよ

**デフォルトの名無しさん** · 2019/03/25(月) 18:34:27.56

そもそもnumberとstringをいれれる型が邪魔すぎる

**デフォルトの名無しさん** · 2019/03/25(月) 18:51:00.60

javascriptの制限のせいでtypescriptには従来の言語のような関数オーバーロードがない
あるのは関数シグネチャーのエイリアスのようなもので中ではifなどで型の判定をして使い分けてる
非常に泥臭い

**デフォルトの名無しさん** · 2019/03/25(月) 18:55:41.13

パターンマッチはクソださいので必要ない

**デフォルトの名無しさん** · 2019/03/25(月) 19:03:37.93

javascript離れて独自拡張したら行く末はelmやpurescriptコースだからな。
そうなったtypescriptは誰も使わないし、
js互換の第二のtypescriptが登場してそっちに流れるだけ。
そうでないと言うのならelmやpurescriptが閑古鳥な理由を説明してほしい。

**デフォルトの名無しさん** · 2019/03/25(月) 19:05:06.35

ダサいとかいう非論理的な言葉で要不要を語るんじゃあない

**デフォルトの名無しさん** · 2019/03/25(月) 19:06:59.78

＞じゃあない

ださい

**デフォルトの名無しさん** · 2019/03/25(月) 19:11:19.73

>>593
tsのunionは、関数の引数だけじゃなくて、戻り値とかオブジェクトのプロパティにも使える
関数オーバーロードの変わりに使うものだと考えるのは、少しズレてる

**デフォルトの名無しさん** · 2019/03/25(月) 19:31:47.11

numとstringを入れられるプロパティの存在意義は？

**デフォルトの名無しさん** · 2019/03/25(月) 20:32:23.93

>>599
これは number と string とかだけじゃなくて、同じ interface を継承しないオブジェクトをひとつのプロパティに格納できたりする機能なんだよ
利点は intetface を用意して継承するよりも記述が減ることかな
普通の静的型付け言語だと any みたいな型を使う事になるけど、それよりもチェックを少し厳しくできるのが利点だね

**デフォルトの名無しさん** · 2019/03/25(月) 20:42:39.81

>>597
https://i.imgur.com/rQXUs9z.jpg

**デフォルトの名無しさん** · 2019/03/25(月) 20:47:57.44

正直オーバーロードは無くていいと思ってる
ジェネリクス等で処理出来ないなら名前変えた方がいい

多言語の境界でよく面倒事の原因になる

**デフォルトの名無しさん** · 2019/03/25(月) 20:48:32.11

>>600
でもそれを参照する場所で型チェックなどが発生するだろ
A型とB型を格納していたプロパティにC型を格納するようになったら
それぞれの場所でまた変更が必要になる
無駄じゃないかなって思う

**デフォルトの名無しさん** · 2019/03/25(月) 21:00:38.33

関数のオーバロードは正直なくてもいいかなと思うけど（別の名前にすればいいだけ）
その言語はオブジェクトのコンストラクタのオーバロードも多分ないよね
それはどうするか、ちょっと困るな

**デフォルトの名無しさん** · 2019/03/25(月) 21:00:47.68

オーバーロードと、実装を上書きするタイプのオーバーライドは絶滅すべき

**デフォルトの名無しさん** · 2019/03/25(月) 21:14:48.42

>>604
Go Rustはオーバロードが無く、ただのstaticなファクトリメソッドでやってるよ

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

fabs()再び

**デフォルトの名無しさん** · 2019/03/25(月) 21:24:14.16

オーバーロードがないとintのabsのほかにfloat用のfabsを用意しないといけない

**デフォルトの名無しさん** · 2019/03/25(月) 21:27:47.27

>>602
リーナスも似たようなこと言ってたな
記事探すの面倒だから貼らないが
（誰か探して貼ってくれないかなﾁﾗｯ）

**デフォルトの名無しさん** · 2019/03/25(月) 21:39:42.65

>>608
そっちはジェネリクスで対応するのでは

**デフォルトの名無しさん** · 2019/03/25(月) 22:26:27.11

オーバーロードだったらマクロのが少しはマシ。

**デフォルトの名無しさん** · 2019/03/25(月) 22:27:46.86

>>603
ts のunion は interface 無しでダックタイピング効くから、参照する時必ず型チェックが必要なわけじゃない
型自体の定義も type alias しておけば一箇所で済むし
静的型付け言語でany使うよりは、遥かに手間はかからないよ

**デフォルトの名無しさん** · 2019/03/25(月) 22:37:18.45

>>612
だったら余計にinterface付けろよと思うわ

**デフォルトの名無しさん** · 2019/03/25(月) 22:38:35.21

Go、Swift、Kotlinの3つは、文法ぐらい一緒にしてくれたら良かったのにな

**デフォルトの名無しさん** · 2019/03/25(月) 22:53:56.04

なんかこだわりがあったんだろう

**デフォルトの名無しさん** · 2019/03/25(月) 22:55:21.22

配列にしてもさあ、カッコの形とかにこだわりなんてあるんか？

**デフォルトの名無しさん** · 2019/03/25(月) 22:55:47.18

どんな言語使おうが、糞バカ中世ジャップランドSIと、土人ベトコンオフショアが合体すれば
全部ゴミにできるんだけどなｗ

**デフォルトの名無しさん** · 2019/03/25(月) 23:19:26.53

Kotlinはぱっと見Scalaかと思うくらい似てるよなー

**デフォルトの名無しさん** · 2019/03/26(火) 09:15:45.15

えっ？(笑)

**デフォルトの名無しさん** · 2019/03/26(火) 10:31:07.40

2019/03/06 15:42:58
2019年の愛され言語第1位、嫌われ言語第１位は?
https://news.mynavi.jp/article/20190306-784182/
「愛されプログラミング言語」
Python (51%)
Javascript (49%)
Java (37%)
HTML (34%)
C++ (23%)

嫌われプログラミング言語は以下
PHP (19%)
Objective-C (12%)
Java (11%)

対象となったプログラミング言語を愛している理由としては、その言語を学習するためのリソースや開発するためのリソースが充実していることが挙げられている。
逆に嫌っている理由としては、対象のプログラミング言語を使ったコーディングが楽しくないからという理由が多く挙げられている。

**デフォルトの名無しさん** · 2019/03/26(火) 11:13:59.02

忘れ去られた言語
ruupy

**デフォルトの名無しさん** · 2019/03/26(火) 14:00:36.03

>>621
俺は忘れてない。なぜならその名前を見たのは今が初めてだからだ。

**デフォルトの名無しさん** · 2019/03/26(火) 14:20:02.74

ごめんごめんpoopyだっけ？ｗ

**デフォルトの名無しさん** · 2019/03/26(火) 16:57:14.07

>>623
それについても俺は忘れてない。なぜなら以下同文

**デフォルトの名無しさん** · 2019/03/26(火) 17:32:40.93

rubooだったか？

**デフォルトの名無しさん** · 2019/03/26(火) 19:16:35.45

以下同文

**デフォルトの名無しさん** · 2019/03/26(火) 19:18:56.38

誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 99934
https://you-can-program.hatenablog.jp

**デフォルトの名無しさん** · 2019/03/27(水) 17:04:40.79

>>602
先にジェネリクスがあったらオーバーロードは不採用だったと思う

**デフォルトの名無しさん** · 2019/03/27(水) 17:15:00.98

>>627
あと一回見かけたらはてブロに通報するわ

**デフォルトの名無しさん** · 2019/03/27(水) 17:15:08.52

ジェネリックで必ず同じ操作になるならいいけど
そうでもないときはジェネリックではどうにもできない

**デフォルトの名無しさん** · 2019/03/27(水) 17:18:22.78

オーバーロード否定派は動的型付け言語か形無し言語がメインの人なんだろうか？

**デフォルトの名無しさん** · 2019/03/27(水) 18:22:56.09

Cはユーザーが定義できない演算子だけオーバーロードする
ユーザーが定義してない型の情報だけコンパイル後に残る

このユーザー定義型の不当な制限をなくすというC++の理念のおかげで
オーバーロードや実行時型情報ができた
めでたしめでたし

**デフォルトの名無しさん** · 2019/03/27(水) 19:26:19.13

ほとんどの言語が強制キャストできるのが原因で型安全でなくなっているのが
何とかならない

**デフォルトの名無しさん** · 2019/03/27(水) 19:52:11.21

>>631
静的型付けメインにも普通に居るよ
RustやGoも関数オーバーロードを導入しなかったし

作為的な例にはなるけどむしろ型システムの阻害要因になることもある
https://ideone.com/uJ1lyb
https://ideone.com/P96nVa

**デフォルトの名無しさん** · 2019/03/27(水) 19:59:52.56

後者の例で言うと、ライブラリの関数に気を利かせてオーバーロードを追加したところ
別のプロジェクトの既存コードがコンパイル出来なくなったとかもあり得る

**デフォルトの名無しさん** · 2019/03/27(水) 20:08:46.35

やはりリーナスは正しかった！
c最高！
c++はうんこ！

**デフォルトの名無しさん** · 2019/03/27(水) 20:12:19.93

暗黙の型変換を含めた場合のオーバーロードの地獄感は半端ない。

**デフォルトの名無しさん** · 2019/03/27(水) 21:04:39.85

それにテンプレートとADLが絡んでカオス