次世代言語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/02/08(金) 22:58:31.86

V言語
まだ公開されてないから実態は不明
https://volt.ws/lang

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

>>212
それ、コンパイラじゃなくてコンバトラー

**デフォルトの名無しさん** · 2019/02/09(土) 13:49:27.53

>>187
Cじゃなきゃできない事はあってもC++じゃなきゃってもんはそんなないし
大体の場合C++以外を使う方がベストプラクティスな場合の方が多い

**デフォルトの名無しさん** · 2019/02/09(土) 13:54:05.42

Rubyガイジあ暴れてた時は普通のヤツかと思ってたけどコイツどうしようもないガイジだな

◆QZaw55cn4c · 2019/02/09(土) 14:07:51.62

>>214
たしかに
C で書く必要があるという話はよくききますね

>>214-215
まじめに相手をしながら同時に罵倒するなんて、あなたも私と同じく分裂症的ですね…

**デフォルトの名無しさん** · 2019/02/09(土) 17:25:06.31

そりゃ180～190レスくらいまで読んで思った事とそこから先最後まで読んだ間の時間差で思うことも変わるだろ

**デフォルトの名無しさん** · 2019/02/10(日) 12:40:50.35

Js
Jquery

こういうやつ信用できねえわ
初心者なんだなってわかる

**デフォルトの名無しさん** · 2019/02/10(日) 13:33:25.21

JAVA

**デフォルトの名無しさん** · 2019/02/10(日) 14:07:04.85

JqueryをJapan-queryだと思い込んでるガイジだろなぁ

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

>>209
VM有り言語はそれほど廃れるとは思わんけどどうなんだろ。役割がかぶってるって結構抽象的では？
進化するとなると、VMごとデプロイ出来るようになって、VM無し言語と対して変わらなくなると思うよ。今の.net coreみたいに。
VMがあれば動くってのは割と強くて、Script系の不可侵だと思ってる部分も本質的にはそれとあまり異なる理由ではないと思う。

Goだってバイナリサイズえげつなくて、殆どのランタイムを内包してるからアレなんだし。

◆QZaw55cn4c · 2019/02/10(日) 15:15:35.65

>>221
VM のメリットななんですか？屋上に屋を重ねる感が強くて、VM のメリットがよくわからない…

**デフォルトの名無しさん** · 2019/02/10(日) 15:21:10.21

ライトワン、ラン１０ビリオネアデバイスだろ

**デフォルトの名無しさん** · 2019/02/10(日) 15:26:57.11

VM言語のメリットはランタイムが別だからバイナリファイルがコンパクトにできる事じゃない？Goとの比較

昔は同一のバイナリが複数のOSで使えるなんて言われてはいたけど蓋をあけてみれば全然そんな事はないし

◆QZaw55cn4c · 2019/02/10(日) 15:50:42.06

>>224
＞バイナリが複数のOSで使えるなんて言われてはいたけど
write once, debug evrywhere......

**デフォルトの名無しさん** · 2019/02/10(日) 15:57:46.27

C#(.NET Nativeビルド), Java(Android RuntimeやSubstrateVMでのビルド)もGoと同じくGC付きのネイティブバイナリ
一方で基本ネイティブの言語もLLVMで動的プロファイル利用のJITを使うことも出来る
この辺の壁は徐々に消えつつある

**デフォルトの名無しさん** · 2019/02/10(日) 16:04:10.07

結局jAVAも11からワンバイナリ打線なんだよなあ

**デフォルトの名無しさん** · 2019/02/10(日) 16:17:41.04

実際Juliaってどうなの？
この記事いいことばっか書いてあるけど

CやPython、Ruby、Rの長所を取り込んだ「Julia」が成長するワケ
https://japan.zdnet.com/article/35132510/

◆QZaw55cn4c · 2019/02/10(日) 16:24:03.71

>>228
＞「Ruby」の動的型付け、
これだけなら単なる癌にしかみませんが…

https://julialang.org/
＞Optionally typed
Julia has a rich language of descriptive datatypes, and type declarations can be used to clarify and solidify programs.
まあ妥当かな…

**デフォルトの名無しさん** · 2019/02/10(日) 17:04:50.60

JULIAは、日本のAV女優。C-more Entertainment所属。身長:158cm。スリーサイズ:B101・W55・H84cm。血液型:AB型。趣味:自分磨き、読書。特技:簿記２級、猫に懐かれる事。

**デフォルトの名無しさん** · 2019/02/10(日) 17:33:00.78

簿記２級ってことは商業高校であまり成績よくなかったほうかな？援交しまくりで。
普通高校で２級ならすごい。

**デフォルトの名無しさん** · 2019/02/10(日) 18:29:32.01

SmalltalkならVMあればOS間互換は言うに及ばず
40年越しの環境でもそのまま動くんだけどな…ｗ
http://www.cdglabs.org/thinglab/

**デフォルトの名無しさん** · 2019/02/10(日) 18:57:18.28

Javaみたいな出来損ないでVMの欠点とか言われても

**デフォルトの名無しさん** · 2019/02/10(日) 19:35:12.91

>>222
OSやCPU等が違ってもVMがあれば同じVM用のコンパイル済みバイナリがそのまま動くってのが利点ではないかな。
まあしかし実際にはVMごとに違うバグがあったりして中々理想通りにはいかんことがJavaで証明されてしまった感があるわけだが。

**デフォルトの名無しさん** · 2019/02/10(日) 19:39:43.57

PGはどれも出来損ないだからな

**デフォルトの名無しさん** · 2019/02/10(日) 19:41:11.34

SEになればいいのか？

**デフォルトの名無しさん** · 2019/02/10(日) 20:30:52.78

>>228
配列アクセスが1始まりだったり、掛け算記号が必要なかったり、
教科書にある数式をそのまま使えるように意識された言語という印象。
推してるやつも理論よりすぎて個人的には好きになれん。

**デフォルトの名無しさん** · 2019/02/11(月) 12:20:42.21

>>222
移植性は昔から言われてることだけど、コンパイラも作るのが楽だし、中間言語は都合の良い命令セットが定義できるからサイズも小さくなる。

何より、コンパイラの改良とVMの改良を分離出来るので、割と柔軟に改良できる。
使う言語のバージョンと、VMのバージョンに厳密な区切りが要らないと言うか。
最低限このバージョンが要る、ぐらいは必要だけど。

新しい言語のバージョンを使って、古いVMで動かすって事が不可能ではなくなる感じかな。
逆も然りで、古いバージョンの頃に書いたものを、最新のVMで動かすことも不可能じゃない。こっちは割とよくある。

ネイティブバイナリ吐いてると、そのへんキツイと思う。特に標準ライブラリがその言語で実装されてるGoとか。

**デフォルトの名無しさん** · 2019/02/11(月) 12:25:06.71

過去Javaは確かに辛かった時代もあるけど今は安定してるし、Monoも割と安定してるぞ。
.netは.net Native使わんでも、ngenかければ良い。

**デフォルトの名無しさん** · 2019/02/11(月) 12:38:03.57

でもjAvAは有料化して死んだよね

**デフォルトの名無しさん** · 2019/02/11(月) 12:51:24.69

JavaはDockerに乗せるには重すぎる

**デフォルトの名無しさん** · 2019/02/11(月) 12:52:13.71

死んだかどうかはともかく
有料化はしてないよ

**デフォルトの名無しさん** · 2019/02/11(月) 13:05:51.95

date、localdateとか混在してjavaめんどい

**デフォルトの名無しさん** · 2019/02/11(月) 13:46:40.87

>>243
バカなコミッターがDateを完全に消去しなかったせい
今後も互換性テストの呪いでいつまでも残り続ける

**デフォルトの名無しさん** · 2019/02/11(月) 13:56:32.92

ログまわりもひでぇしな
java書くくらいなら転職するわ

**デフォルトの名無しさん** · 2019/02/11(月) 14:32:39.08

>>229
>>237
なるほど
実用というよりまだ実験レベルっぽいんだね

**デフォルトの名無しさん** · 2019/02/11(月) 14:54:39.14

Javaの日付周りは闇かもなぁ。

**デフォルトの名無しさん** · 2019/02/11(月) 15:23:01.36

commonsや独自のutilで特段大きな問題を感じたことはない

**デフォルトの名無しさん** · 2019/02/11(月) 20:43:19.19

>>246
実験レベルというよりは本来が実プロダクトより実験を目的に作られてる面が大きい
目的にと言うと言い過ぎかもしれないが作っているコミュニティが理論や実験寄りなので

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

>>249
オレの考えた最強の言語！
みたいなやつかw

**デフォルトの名無しさん** · 2019/02/11(月) 23:16:48.45

なろう系言語ｗｗｗ

**デフォルトの名無しさん** · 2019/02/11(月) 23:41:47.02

>>250
何も間違ってないけど雑な数値計算実験やアルゴリズム実験には本当にイケてるのよ？
漸進的型付けでも型推論と最適化が程よい塩梅で効いてるし私は好き

**デフォルトの名無しさん** · 2019/02/12(火) 01:05:03.07

雑な実験でいいならcかc++くらい使えばいいのにと思うけどね。

**デフォルトの名無しさん** · 2019/02/12(火) 08:24:33.10

>>232
不人気でユーザがいなくなっちゃった言語が
40年越しの環境でそのまま動いても意味ないけどね

**デフォルトの名無しさん** · 2019/02/12(火) 08:31:43.79

雑な実験をC++でやるのには何の問題もないけどそれでもなお煩わしい（ex.tupleとかpairとかがびみょい）
ていうかC++こそ本腰入れた実験に使うんもん（分野によります）だし普段はもっと雑に書きたいなという気持ち

Cは無いかなー
できるけどC++以上にやりたくない

**デフォルトの名無しさん** · 2019/02/12(火) 09:25:59.07

実験って何の実験？
大抵の場合c++は向いてないと思うけどね
ハマってる時間がもったいない

**デフォルトの名無しさん** · 2019/02/12(火) 09:36:40.65

高性能計算は言語の選択肢がほとんど無いので……

**デフォルトの名無しさん** · 2019/02/12(火) 12:22:11.18

そういうコアな計算部分にc++の機能あんまりいらないと思うけどね
結局パフォーマンス必要ならcudaにオフロードとかするんだろうし
構文的なところは凝らないのが正解だよ

**デフォルトの名無しさん** · 2019/02/12(火) 14:19:55.88

>>254
他言語のコミュニティメンバーがもう誰にも使われなくなった言語の
しかも40年前の環境を復活させたんなら逆に凄いことだな！

**デフォルトの名無しさん** · 2019/02/12(火) 15:29:47.85

よし、FORTH を復活させよう

**デフォルトの名無しさん** · 2019/02/12(火) 21:08:01.13

CとC++とFortranで型システムが一番マシ（個人の感想）なのがC++って選び方なので

**デフォルトの名無しさん** · 2019/02/12(火) 21:32:38.15

雑にやりたいのに型システムにこだわるのが間違い

**デフォルトの名無しさん** · 2019/02/12(火) 21:35:55.50

論文のために数回動けばいいようなコード
　→ Python (主要な計算部分はライブラリ任せ)
雑とは真逆の実用ライブラリ
　→ C (NumPyなど)

というのが数値解析などの分野の人達の感覚では

そしてライブラリ使ってない箇所もあわよくば早くしたいけど
動的言語からあまり離れたくという欲張りさんのために
NumbaやJuliaなどがある

**デフォルトの名無しさん** · 2019/02/12(火) 21:42:29.55

>>262
だから雑にやるときはJuliaって言ってるんだよなぁ

**デフォルトの名無しさん** · 2019/02/13(水) 11:27:30.70

>>263 python でNumpy やNumba を動かせばよいだけの話。　
pythonをNumbaでJIT化すれば高速に動く。
だから数値解析、統計、機械学習などでpython が広まっている。

numbaを利用したpythonループの高速化
https://qiita.com/ken223/items/311032e45f7cd9fb6be6
numpy.sum() より　numba でJIT化したほうが若干早い

全体をもっと高速化したい場合はCythonでコンパイルすることになるが、若干ソースに変更が伴うのが欠点。

**デフォルトの名無しさん** · 2019/02/14(木) 08:13:11.35

そのへんのPythonをネイティブにする類、GILはどうなるの？

**デフォルトの名無しさん** · 2019/02/14(木) 09:24:39.49

>>266 明示的に書けば良いのでは？

Cython のスレッド並列処理
https://www.isus.jp/products/python-distribution/thread-parallelism-in-cython/
Cython の特長の 1 つは、ネイティブ並列処理 (英語) をサポートすることです (cython.parallel モジュールを参照)。
cython.parallel.prange 関数は並列ループに使用できるため、Python* でスレッド並列処理を使用して、インテル® メニー・インテグレーテッド・コア (インテル® MIC) アーキテクチャーを活用することができます。

インテル® Distribution for Python* 2017 の Cython

**デフォルトの名無しさん** · 2019/02/14(木) 10:58:54.92

>>266
nogil=TrueでGIL無しになる

**デフォルトの名無しさん** · 2019/02/14(木) 18:56:49.51

それは良さそうだな。

**デフォルトの名無しさん** · 2019/02/14(木) 20:55:14.89

もうjulia使うのが目的になっとるな。。

**デフォルトの名無しさん** · 2019/02/16(土) 02:33:00.49

>>121
パイプ演算子だけで何が出来んだよｗ

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

関数のカリー化がないのにパイプ演算子だけ持ってきちゃったElixirはなんか変だよな。
パイプ演算子というよりUFCS。ピリオドにしておけばよかったのに。

**デフォルトの名無しさん** · 2019/02/17(日) 20:53:38.23

ユーチューブみてたら外人さんが今年はじめるおすすめ言語でGoあげてたけどどうなの？

https://youtu.be/Wp6Z2wVyPeY

**デフォルトの名無しさん** · 2019/02/18(月) 00:25:05.73

PHPよりはマシ程度

**デフォルトの名無しさん** · 2019/02/18(月) 10:03:46.42

外人って誰？
お前の友達？

**デフォルトの名無しさん** · 2019/02/18(月) 10:32:14.54

>>273
英語わらないけど
パイパンなのはなんとなくわかった

**デフォルトの名無しさん** · 2019/02/18(月) 10:38:37.16

Goはいい言語だと思うが文法がきらいという理由で俺個人としてはやりたくない。

**デフォルトの名無しさん** · 2019/02/18(月) 10:39:27.28

Goは悪くないけどGoやるくらいならCで良いって思っちゃう

**デフォルトの名無しさん** · 2019/02/18(月) 11:33:15.82

Cって爆発するんでしょ？

**デフォルトの名無しさん** · 2019/02/18(月) 14:31:28.10

シーッ！

**デフォルトの名無しさん** · 2019/02/18(月) 16:23:53.97

どうしてRustはこんなにおデブちゃんなの？ｗｗｗ
https://developers.google.com/web/updates/2019/02/hotpath-with-wasm#conclusion

CやAssemblyScriptと比べて割に合わなさ過ぎだろうｗｗｗｗｗ

**デフォルトの名無しさん** · 2019/02/18(月) 17:03:38.39

その下の節の Update: Rust で 370B になったとあるけど

**デフォルトの名無しさん** · 2019/02/18(月) 17:11:02.34

人力でそんな手間書けるくらいなら最初からCで書くよね普通。

**デフォルトの名無しさん** · 2019/02/18(月) 17:54:25.43

これ最終的に全部機械語で書けって流れ？

**デフォルトの名無しさん** · 2019/02/18(月) 18:36:38.63

なぜ機械語が出てくるのかが分からんなw

**デフォルトの名無しさん** · 2019/02/18(月) 19:42:42.37

手間っつってもそんなでもなくない？
普通に-Osオプション的なのもデバッグ情報の削除もCでやるでしょ

**デフォルトの名無しさん** · 2019/02/18(月) 19:47:35.74

連投になって悪いがなんならltoも普通にCでやるだろうし存外普通の事しかやってないぞ？

**デフォルトの名無しさん** · 2019/02/18(月) 20:19:28.46

c + lint で済む話をバカが無視するからコンパイラに組み込んだみたいな話、本当バカ。

**デフォルトの名無しさん** · 2019/02/18(月) 21:50:19.37

普通ならなぜデフォにしないの？
Cパイセンに華持たせてるの？

**デフォルトの名無しさん** · 2019/02/19(火) 07:58:57.65

実装してる人に、聞くのが早そうだな。

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

当然ながらデバッグし易さやコンパイル時間などとトレードオフがあるので
特化をデフォルトにする必要は無い

Cは現役だし使うことを誰も止めはしない
比較は構わないけど推されてもここでは単純にスレチ

**デフォルトの名無しさん** · 2019/02/19(火) 10:27:13.34

デバッグし易さやコンパイル時間などを考慮した結果、せっかくwasmのクセに性能はす、す、すくりぷとげんごｗｗのじゃばすくりぷとｗｗｗと大して変わらずｗｗ５倍ｗも巨大なwasmバイナリをデフォで吐いてしまうビチグソ言語（）があるらしいｗｗｗ

CやAssemblyScriptは性能大して変わらなくてもデフォでジャバｽｸﾘﾌﾟﾄ（）よりサイズ小さいのにどう言い訳すんのこの新世代（）うぇぶ言語ｗｗｗｗｗ

**デフォルトの名無しさん** · 2019/02/19(火) 10:59:22.66

楽しそうで何より

**デフォルトの名無しさん** · 2019/02/19(火) 17:44:22.10

>>271
ビルダーパターンを置き換えられるとか

**デフォルトの名無しさん** · 2019/02/19(火) 22:52:49.55

>>278
クラスタ分散周りのコード書くならgoが良いと思われる。

**デフォルトの名無しさん** · 2019/02/21(木) 08:38:19.03

IEEE ランキング
https://news.mynavi.jp/article/20180806-674740/

**デフォルトの名無しさん** · 2019/02/24(日) 13:15:52.70

A better C = Go
A better Perl = Python
A better Java = Kotlin
A better Javascript = TypeScript
A better Lisp = Clojure

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

>>297
PythonとPerlって言うほど用途被ってるか？
個人的には
A better Python = Node.js
だって思うけどな

**デフォルトの名無しさん** · 2019/02/24(日) 13:28:03.32

Groovyは？

**デフォルトの名無しさん** · 2019/02/24(日) 13:29:59.40

A bitter C++ = D

**デフォルトの名無しさん** · 2019/02/24(日) 13:35:04.27

俺はKotlinよりScala推しだけどバックについてる規模がなあ

**デフォルトの名無しさん** · 2019/02/24(日) 18:42:02.16

>>297
Goにbetter Cはま

**デフォルトの名無しさん** · 2019/02/24(日) 18:42:38.76

だ無理だ。
バイナリが大き過ぎる。

**デフォルトの名無しさん** · 2019/02/24(日) 18:47:20.41

A poorer C = Go
A poorer Perl = Python
A poorer Java = Kotlin
A poorer Javascript = TypeScript

しっくり来るな

**デフォルトの名無しさん** · 2019/02/24(日) 18:50:58.08

>>303
まだというかずっとじゃね
GCやgoroutineスケジューラのサイズは削れないし
用途がいくらか被るにせよ、性質的にCの代わりを目指したものでもないし

**デフォルトの名無しさん** · 2019/02/24(日) 18:55:07.72

他の言語が無駄な機能を増やすほどCがbetterということに気づかされる。

**デフォルトの名無しさん** · 2019/02/24(日) 19:04:15.79

>>306
betterというか完全にbestだね
使いやすいけどとっつきにくさがどうしてもあるから
優しいとされる他の言語が重宝されがちになるが

**デフォルトの名無しさん** · 2019/02/24(日) 19:04:42.82

>>306 Cは、アセンブラみたいなものだからな。

**デフォルトの名無しさん** · 2019/02/24(日) 19:04:43.79

>>305
禿同。
Goは鯖で速度重視専用な気がする。
マイコンの規模で使える気がしない。

**デフォルトの名無しさん** · 2019/02/24(日) 19:05:34.94

なら他の言語使ってる人気は全員馬鹿だな

**デフォルトの名無しさん** · 2019/02/24(日) 19:16:29.07

違う。
それだけマイコン使う分野がマイナーってだけ。
CPUパワーがあれば楽出来る言語使うのは当然。