次世代言語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/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パワーがあれば楽出来る言語使うのは当然。

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

>>311 はあ？マイコンって何を指してるか知らんが、今のスマホのパワーは、数年前のデスクトップを凌駕してるぞ。

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

>>311
ああごめん、>>306への話ね

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

>>313 だから、>>311 も>>306 もなんか的外れに見えるという話。
見る視点がまるで違う。

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

>>313
そそ。
PICとかそこまで小さい規模の話。
スマホでもゲームとかはCやC++もあるだろうけど、楽出来る分にはCは無いわな。

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

100円のチップでPythonが動く時代なんだぞ。自動車の自動運転のマイコンなんか、下手なPCよりパワーはあるぞ。

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

>>316
自動運転用の石はそうだが、パワステ制御だけとか小さい石は今でも8ー16bitだし、CPU全体じゃそっちのが数は多い。(80%)
IntelやARMは小さいパイで大きく稼げる市場を独占しただけで。

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

自動運転のマイコンってどこの石使ってるんだろ？

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

少なくとも日本車はルネサス製マイコン使ってる。
Casl2とかニーモニックがそのまんま。
まさに試験が企業の求める人材発掘の篩になってる。

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

でもワイウェッブ系だから

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

>>318 今はARMだろ。中央のは、NVidia とか、Intel を使ってるのかな？
自動車って、何十とCPUを使ってるから何がメインかというのは難しいのでは？

Nvidia もIntel も実態はARMコアを使ってるみたいだけど。
ルネサスも震災以降はダウンして、ユーザーからのARMを使えという声に応じざるを得なくなったみたいだし。

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

>>321
ルネサスって元は日立とどっかの合資で出来たとこだっけ

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

>>322 NECとか、日本連合だね。

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

>>307
Go は better C ではなく better C++ なんだけどな
better C 目指しているのは Rust

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

ざっくりした言い回しは自然と情報量が落ちてしまうので難しいもんだが、GoはやっぱりCompiled PythonとかC++とJavaの中間とって言語機能をC並に絞ったとかの複雑な立ち位置の印象だ

Rustもbetter C 兼 replacing C++の印象

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

まあ別に無理やり結びつける必要はないんだけどね。

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

理論的には理想に近い言語でも、実用環境が限られたり、スピード的に極端に落ちると現実的ではなくなるからね。

やはり言語的に洗練されていて、環境を選ばずに動き、スピードの解がある言語は伸びる。

Javaは、環境を選ばずに伸び、スピードの解はJITでまあまあ解決した。

Pythonは色々難しい問題がありそうだが、PyPyはJITで動いてるしいずれ本家がJITをサポートする様になるんじゃ無いのかな。Cythonは直接Cに落ちるが互換性の問題があるし。

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

goは構文が糞すぎて糞
ゲネリクスとかそう言う問題以前
変数宣言さえ糞
設計した奴はガイジの糞
グーグルって俺よりバカなんだなと思うわ

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

goは触れば触るほど、Cでも良かったよね
Cのほうが論理的に簡単にできるよねってことが多過ぎる

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

Goの勝手にセミコロン補完される仕様がホントクソ

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

チュートリやってたら変数宣言だけで4つくらい出てきてガイジかな？って気持ちになった

**デフォルトの名無しさん** · 2019/02/25(月) 01:58:52.98

Lisp方言やPythonとRubyのように類似品を乱立させるやり方は古臭い

Java Kotlin C# TypeScript Go
の中からRubyと同じ失敗を繰り返す言語が続出すると思うと残念だ

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

この中だとGoとKotlinが危ないな。
typescriptも、ecmaに型アノテーション
付く形で合流しそう。

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

>>331
なんであんなふうにすんだろねｗ

**デフォルトの名無しさん** · 2019/02/25(月) 07:38:01.51

>>333
esのデコレーションは今でも同等機能をコードで補完できるんだよな
コードを組み上げられる能力があればtsもゴミみたいにしか感じられなくなるね

**デフォルトの名無しさん** · 2019/02/25(月) 08:01:49.36

C#はどうよ。俺は好きなんだけど。

**デフォルトの名無しさん** · 2019/02/25(月) 08:52:20.78

最近のC#はあまりにも先端が突っ走りすぎてて、従来の「哀れな底辺ドカタにも最先端の言語を」という重要な役割を見失いつつある
>>336のようなC#のファンですら大抵3つ4つくらい前のバージョンで知識が止まってる状況で、
自社開発でWebサービスやってますみたいな極一部の「別にC#でなくてもいい層」ばかりを相手にしている
次期バージョンでは.NET Coreでしか使えない機能が出てきて足切りが始まり、プラットフォームが完全に分断される

**デフォルトの名無しさん** · 2019/02/25(月) 09:01:20.29

.NET Standardで基本事足りるとはいえ、その他のオープンなライブラリ側もおっつけてない感じあるなぁC#

**デフォルトの名無しさん** · 2019/02/25(月) 09:15:21.64

Goは並列化処理は書きやすい

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

>>328
Goは大学出たての経験値の低い人でも書けるお馬鹿さん言語を意図して設計されとるんやで

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

.NET Coreと.NET Frameworkの間でライブラリを共通化するためのAPIセットを定義するのが.NET Standardの主目的であったが、
その.NET Standardが次のバージョンで.NET Frameworkを切り捨てるというギャグのような話

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

>>337
趣味でもC#書くけど、それでも確かに正直.NET Coreの3を先食いしてる人達からすると数世代遅れてるな。
Span<T>とかはそりゃ確かにパフォーマンスは雲泥だろうけど、それ要るの結構限られてない？とか。

個人的にはあの断捨離は失敗しそうだから、そこから色々拾い上げてるMonoの方が良いんでないの？と思ってる。

Windowsだとほぼバイナリポンで動くというメリットが、クソ多いファイル数にかき消されてる気がして仕方ない。

.NET FW切り捨てるのはちょっと無理があるんじゃねえかなって思ってるけど、やるんだろうな…。

**デフォルトの名無しさん** · 2019/02/25(月) 09:45:47.12

スマホゲー開発はだいたいC#だし、Unityがゲームエンジンとして標準的だからしぶとく残るんじゃないか
コンシューマーゲーはまだまだC++だけど

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

>>340
最初はそんな意図なかっただろうに
反知性主義云々に乗っ取られて終わったな

**デフォルトの名無しさん** · 2019/02/25(月) 10:08:23.24

>>341
最初からCoreへの移行のための共通化じゃね
Coreに欠けてたGUIが解決したらFrameworkから追い出し始めるのは
むしろ自然だと思うけど

**デフォルトの名無しさん** · 2019/02/25(月) 10:35:02.24

>>342
普通の人が何も意識しなくてもアプリのパフォーマンスが良くなるってのがSpanを含めた最近の変更やで

**デフォルトの名無しさん** · 2019/02/25(月) 10:41:49.82

C++を切り捨てるつもりが
いつの間にかC#自身の古いバージョンを切り捨てる話に変わっている
これがPython Rubyと同じ失敗

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

>>346
そうなんだが、実際問題そこまでパフォーマンスに悩んだ事あんま無いんだよな。
ゲームとかなら顕著なんだろうけど。

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

C#は言語自体は面白いんだけどな
特に非同期処理は一日の長があるだけにライブラリが非常によく整備されてるし、
課題だった非同期処理のパフォーマンスも最近では飛躍的に改善されてるし
非同期シーケンスなど他言語に先駆けた取り組みも積極的に行われてる
しかし最近のMSはサイドバイサイドに甘えすぎなんだよ
既存資産との折り合いをつける努力を完全に放棄している
Azure関係とかもちょっとSDKのバージョン上げたりするとそのたびにぶっ壊れる有様でほんと酷い

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

C#もC++みたいなキメラルート歩んでるのか

**デフォルトの名無しさん** · 2019/02/25(月) 16:42:45.71

>>333
ecma に型アノテーション入って TS がオワコンになるは本当にあり得る未来だね
CoffeeScript もそんな感じで廃れた歴史が実際あるわけだし

**デフォルトの名無しさん** · 2019/02/25(月) 16:46:51.54

C が best だという意見だけは同意しかねる
Go は滅多にクラッシュしないよ。メモリー管理の機構とかちゃんとしてるからだと思うけど
C++ で開発してたときはしょっちゅうコアダンプ吐いてた印象だった。やっぱ確実に進歩はしてるよ

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

>>350
てか最近の言語は全てキメラルートだよ。

**デフォルトの名無しさん** · 2019/02/25(月) 23:28:58.22

>>352
何を言ってるんだ貴様は

**デフォルトの名無しさん** · 2019/02/26(火) 00:36:46.92

>>352
えーと、正直コアダンプ吐くような事態が起きるのは、単にあなたのプログラムがポカしているからじゃないかなーという説が

**デフォルトの名無しさん** · 2019/02/26(火) 00:48:01.56

むしろプログラマはポカするものという前提の元で設計されてるのが昨今の言語じゃない？
Rustなんかモロそんな感じだし

**デフォルトの名無しさん** · 2019/02/26(火) 07:15:05.85

>>352みたいな低知能がアホなことをしないためにガチガチな仕様で不便な言語が生まれてるんだよな

**デフォルトの名無しさん** · 2019/02/26(火) 08:01:09.47

知能が高ければミスしないのか、興味深い

**デフォルトの名無しさん** · 2019/02/26(火) 08:42:54.19

まあ世の中のプログラマの大半が低脳だから、Goの方向性は間違ってはいないよ

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

反知性主義万歳！

**デフォルトの名無しさん** · 2019/02/26(火) 09:16:52.41

人は…過ちを繰り返す

**デフォルトの名無しさん** · 2019/02/26(火) 09:29:07.33

どちらの言語も、規模と高度な最適化(→複雑さ)両方が必要なシステムを
手に負えるようにするためだと思うけどね

GoはYoutube実装に使われていて
Rustに至っては言語仕様とツールチェーンを実装した本人達を言語ユーザーと想定したものだし