次世代言語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/25(火) 10:46:45.22

>SmithyはAWSの内部でIDLとして10年ほど使われてきたものを
>ベースとしていると、次のように説明されています。

仕様だけでなくツール群も出してくれるのなら有用そうだけど
どうなんだろうな

**デフォルトの名無しさん** · 2019/06/25(火) 15:47:23.82

>>489
適用分野違うけど
XAML的なもの？
（いちおう.NET系言語からはどれでも使える）

**デフォルトの名無しさん** · 2019/06/25(火) 15:59:47.36

Intel、新プログラミング言語「Data Parallel C++」を開発中
https://news.mynavi.jp/article/20190625-848112/

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

>>491
全く違う
ドザワールドでいうならCOMのIDLに相当する
死んだ魚みたいな目をしてる先輩のオッサンに聞いてみ

**デフォルトの名無しさん** · 2019/06/25(火) 20:47:57.50

懲りずにまたIDLか

**デフォルトの名無しさん** · 2019/06/25(火) 21:49:39.83

COM もそうだけど、おまえらRPC 使わねえの？

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

COMはRPCできるの知らないの？

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

COMなんて今更作らないだろ
おれは情けないことに今いじってるが
それに比べたら、gRPCとか流行ってるのに、おまえら使ったことねえの？

**デフォルトの名無しさん** · 2019/06/25(火) 23:38:22.11

ttps://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

TypeScriptが最強言語らしいぞ
型無し糞言語がゴミというのもはっきりデータとして出てしまったね
3バカ頭がP言語あたり、いい加減首吊って死んだほうがいいんじゃないか？

**デフォルトの名無しさん** · 2019/06/25(火) 23:49:53.60

Ｗｅｂ画面なんて壊れてても気にしないからコミット取り消さないし
そもそも画面実装とかサーバに比べて問題の範囲が限定的でたいして難しくないだろ
最初から扱ってる問題が言語ごとにちがうんだ
この表ってか論文で一緒にしてるのおかしい

あ、型なし言語はあかんと思います

**デフォルトの名無しさん** · 2019/06/25(火) 23:52:48.51

CLIで完結する同期的バックエンドの方が楽やわ

**デフォルトの名無しさん** · 2019/06/26(水) 02:11:17.37

言語の生と死の1bitは他のなによりもリアルだな
1bitがビッグデータより重い

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

関数型使えないって今どきありえないと思うんだよね
一昔前のOOPがわからないおじさんと同じレベルのこと言ってる

**デフォルトの名無しさん** · 2019/06/28(金) 17:48:17.39

vlangを試してみた　2019-06-25
https://kogara324.hatenablog.com/entry/2019/06/25/225613

【プログラミング言語】モダンなV言語がリリースされたので触ってみる　2019-06-23
https://www.pavlog.tokyo/entry/v-programming-language
V言語は、保守可能なソフトウェアの構築のために設計された静的型付言語です。Goに似て
いて、Oberon, Rust, Swiftの影響を受けています。

The V Programming Language (公式)
https://vlang.io/

**デフォルトの名無しさん** · 2019/06/28(金) 22:46:29.05

またふやしたんか

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

vlang、言語作成の過程を見るにはちょうどいいな。
ソースもまだそんなでかくないし。

**デフォルトの名無しさん** · 2019/06/29(土) 16:52:27.05

printfに限らず困ったらC呼べるのは案外実用的かも？
（というかライブラリ整備で楽したい？）

**デフォルトの名無しさん** · 2019/06/29(土) 19:33:30.32

なんのvなん？

**デフォルトの名無しさん** · 2019/06/29(土) 21:37:36.03

Kotlin もよろしく

**デフォルトの名無しさん** · 2019/06/30(日) 18:33:18.81

>>507
既存の言語全てに勝利する、VictoryのVだそうだ

**デフォルトの名無しさん** · 2019/06/30(日) 20:00:00.91

そのうちV2言語とかV2AB言語とか出そう

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

すでに VB はあるがな

**デフォルトの名無しさん** · 2019/06/30(日) 20:15:14.87

ブイブリュは下痢糞の漏れ出る音を模した言語だろ

**デフォルトの名無しさん** · 2019/07/01(月) 22:32:36.99

VuriVuriVuriBuryuryuryu！！！！VucchichiBBBchichichiVuriririVBVBVuuubbb！！！！！！！

**デフォルトの名無しさん** · 2019/07/01(月) 23:11:18.59

vlangはたしかにgoのダッサダサな部分を洗練させた感があるけど、肝心のgoroutineはないのかね？

**デフォルトの名無しさん** · 2019/07/02(火) 08:38:42.74

あるっつの

**デフォルトの名無しさん** · 2019/07/02(火) 10:18:10.05

https://vlang.io/docs#memory
>For more complex cases manual memory management is required.
>This will be fixed soon.

ずっと will be fixed soon のままになると予想

GCも参照カウントもデストラクタもRustのようなライフタイムも無しで
手動でないメモリ管理を実現するそうだが

**デフォルトの名無しさん** · 2019/07/02(火) 10:24:59.91

大学の情報系出た奴にありがちな、前人の基礎研究を舐めてる典型的な馬鹿だな

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

肝心なとこが未実装とか…
そこが他言語と異なるセールスポイントちゃうんか

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

Goの対案を出せとか、ありがちなことを言われたのかな
言われた通りにしてもバカにされるだけというありがちなパターンかな

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

>>515
まだ無いっしょ。
今のはネイティブスレッドって書いてないか？

**デフォルトの名無しさん** · 2019/07/02(火) 13:00:27.32

>>516
rustみたいにガチガチじゃなきゃいいよ

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

いっそエスケープは一切禁止でスタックベースのリソース管理しかできない言語があってもいい
非同期処理さえうまく扱えれば実用的だと思う

**デフォルトの名無しさん** · 2019/07/02(火) 13:30:43.80

リージョン推論かな?
ライフタイムとリージョンの違いってなんだっけ

**デフォルトの名無しさん** · 2019/07/02(火) 14:38:03.95

言語機能の複雑さという代償はあったが
GC無しでリージョン推論を実現したのがRust

記述性のためGCを入れつつも遅延を最小にすべく
GCの性能向上に努めたのがGO

一方vlangの公式によると
https://vlang.io/
> V manages memory at compilation time (like Rust)
https://vlang.io/compare
> - No GC
> That's why the language is so simple

・Rustのようにコンパイル時にメモリ管理される
・Goのように書けるがGC不要
・それでいてRustのような複雑さは無い
・という予定(まだ未実装)

本当にこの通り実現するなら
GoとRustの設計者達にマウント取れるレベル

**デフォルトの名無しさん** · 2019/07/02(火) 14:52:15.52

金集めのためのハッタリ・詐欺かもね。
どう実装するかは集めた金でバカンス中に考えるんでしょ。

**デフォルトの名無しさん** · 2019/07/02(火) 14:59:25.78

ちなみに自動メモリ管理が未実装なので、以下の記事によると
hello worldやvlangコンパイラ自体もメモリリークしているとのこと

https://christine.website/blog/v-vaporware-2019-06-23
> The compiler itself also leaks memory

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

Haskellの副作用問題やRustのグラフ構造問題のような
原理主義の藁人形がいなくなるまで無視すればいい

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

まあ本当にできたらスゲェわ
V言語に乗り換えるわ

**デフォルトの名無しさん** · 2019/07/02(火) 16:00:36.62

どうせプログラム終了すればOSが使ったメモリ全部解放するから
長時間動かすプログラムのベストプラクティスは定期的に自動で状態保存→リブート→復元？
ある意味合理的な富豪プログラミングｗ

**デフォルトの名無しさん** · 2019/07/02(火) 16:03:59.36

cloud の go はそれだな

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

>>526
ｗｗｗ

**デフォルトの名無しさん** · 2019/07/02(火) 18:59:24.21

>>526
あっ・・・（察し）

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

>>478
オマエオモシロイナ

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

rust以外にもベアメタルな新言語は色々あったよ。clayとかBitCとかdecaとかcycloneとか
安全性についてはスルーした言語や挑戦して失敗した言語もあった
vlangはそこを吹かしてるから地雷にしか見えない

**デフォルトの名無しさん** · 2019/07/02(火) 20:14:41.10

ベアメタルってはじめて聞いた
これからの時代はベアメタルだな！

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

>>524
goの方向が正解だわ。
GCがあることで他資源管理に集中できるし。
ただchannelでのブロックによるgoroutineリークは想定してなかった言語ミスだと思う。
そこは改善の余地ありだわ。

**デフォルトの名無しさん** · 2019/07/03(水) 01:59:42.47

>>524
Rustとは異なる一つの解として、フロー解析を頑張るという方向性はアリだと思う
Rustのように人間が明示的に型を付けることによって制御するんではなく、TypeScriptの型推論みたいにコンパイラが頑張ってフローから生存範囲を割り出す
Vには期待してないが、MSあたりが本気で取り組めば実用的なものはできそう

**デフォルトの名無しさん** · 2019/07/03(水) 11:04:20.52

>>537
それは>>517も言うような前人を甘く見た考えだよ・・

Rustも生存期間の推論をやってるし
GC言語もコンパイル時やJITでエスケープ解析してヒープでなく
スタックに配置してGCの負荷を減らしたりしてる

特にGoは静的解析にかなり力を入れてる
MSも.NETでとっくに本気で取り組んでいる

コンパイル時間との兼ね合いもあるけど
GC言語にとっての理想形の一つは実行時のGCコストゼロだから

**デフォルトの名無しさん** · 2019/07/03(水) 12:16:45.29

自分ができると思うのは甘い
MSが総力を挙げて取り組めばできる

主語が小さいなら悲観、主語が大きいなら楽観する現象

**デフォルトの名無しさん** · 2019/07/03(水) 12:42:18.44

それは事実だから仕方ない
結局OSSの成功例は企業製のものばっかりだったりするし

**デフォルトの名無しさん** · 2019/07/03(水) 18:10:18.83

じゃあMSが新しい言語作るのをじっと待ってるのが正解なんだな

**デフォルトの名無しさん** · 2019/07/03(水) 21:19:23.77

Microsoft､高性能メモリアロケータ｢mimalloc｣公開
https://news.mynavi.jp/article/20190625-847906/

**デフォルトの名無しさん** · 2019/07/03(水) 23:27:22.96

TypeScriptのような型推論は、原理的には可能なんだろうけど現実的には計算量が爆発すると思ってた。
まさか実際にやってのけるとはなぁ。

**デフォルトの名無しさん** · 2019/07/03(水) 23:33:43.13

人間がエラーを理解できなそう

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

rubyが型ゆるくて逝ったように型推論とかやめて明示しようって話になる。
バカは何度でも同じ過ちを繰り返す。

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

rubyがバカなだけじゃん
自分とこの失敗の恥を他人とこに押し付けるなｗ

**デフォルトの名無しさん** · 2019/07/04(木) 02:43:53.90

template引数が爆発的に増えてきてから型推論を考えるのが理にかなっている
先に型推論を作り込んで後でtemplateが欲しくなっても時既に遅し

**デフォルトの名無しさん** · 2019/07/04(木) 08:23:42.62

>>546
バカがやった失敗をしっかり見ろって話なんだが。
やっぱり見ないのがバカたる所以なんだよね。

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

次世代言語(笑)
実績があるFortranこそ至高

並列Fortranに関するシンポジウムのご案内(第5回)
｢並列Fortranの現状と展望｣ ~Fortranはどこへ向かうのか?~
http://site.hpfpc.org/home/events/parallel_fortran_sympo5

**デフォルトの名無しさん** · 2019/07/06(土) 09:52:45.57

FORTRAN派はJuliaに乗り換えてくれればいい

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

Juliaは呼ばれる側には向いてないからどちらが良いとか以前に代替にならない

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

インデクスが1始まりな時点で終わってんだよ。

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

グローバル変数にGCは不要だから昔の言語は速い
しかもスタックもボローチェッカーも不要
今の多数派は速度と学習コストを犠牲にしてでもグローバル変数禁止を優先する

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

>>553
速度と学習コストを優先してグローバル変数を多用したいなら、今でもそれができる言語は使用可能なのだから好きに選択すればいいんじゃね？

**デフォルトの名無しさん** · 2019/07/06(土) 11:12:54.20

他言語から呼ぶのに配列を転置したりインデクスを1オリジンにしたり面倒くさいんだよ教授のライブラリ
と学生の頃思ったわ

**デフォルトの名無しさん** · 2019/07/06(土) 12:46:36.15

>>554
結果だけでなく過程にも色々と好みがあんだよ
予告なしで突然その行動をするのか
あるいは言いたいことを全部言ってから行動するのか

**デフォルトの名無しさん** · 2019/07/06(土) 14:57:38.96

グローバル変数が早いってどういう理論？
全ての変数に対応できるような糞で固めモリ確保するの？ばかなのしぬの？

**デフォルトの名無しさん** · 2019/07/06(土) 15:04:47.10

間接アドレッシングより直接アドレッシングの方が速いとか
メモリ上の位置が固定されるから速いとか
有利な面はあるんじゃね

知らんけどω

**デフォルトの名無しさん** · 2019/07/06(土) 15:24:12.97

ローカル変数の方が速そう
大抵最適化でレジスタ上のみの存在になるし

**デフォルトの名無しさん** · 2019/07/06(土) 15:35:24.84

集積度でCPUにレジスタ・キャッシュが貴重だった頃の(ry
RISC以降は組み込みですらローカル変数のほうが速度出るはず

**デフォルトの名無しさん** · 2019/07/06(土) 15:54:52.39

GCが遅いだけだな
ローカル変数が遅いなんて誰かに言わせても仕方ない
人に言わせたいことではなく自分が言いたいことを語れよ

**デフォルトの名無しさん** · 2019/07/06(土) 16:15:05.44

ドンッ！！

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

>>556
日本語でok

**デフォルトの名無しさん** · 2019/07/12(金) 04:42:18.60

>>557
メモリ確保やらスタックやらのオーバーヘッドがグローバル変数だと起こりにくい、ということなんじゃね？

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

スタックと比較した場合、計測せにゃわからんが結論だろ。
結局はキャッシュヒット率の問題だったりするわけだし。

**デフォルトの名無しさん** · 2019/07/12(金) 21:53:30.16

キャッシュのこと考えたらグローバル変数のアクセスは遅いだろ

**デフォルトの名無しさん** · 2019/07/13(土) 07:24:03.78

フォートランがなぜCより速いかしってる？

**デフォルトの名無しさん** · 2019/07/13(土) 09:15:34.94

速くないから

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

FortranはCより自由度に劣る代わりに最適化しやすいからな
気を使わなくてもベクトル化や拡張命令の対応をコンパイラがやってくれるから
京とかのスパコンでの大規模計算の分野で使われてる

**デフォルトの名無しさん** · 2019/07/13(土) 09:58:32.38

ライブラリがちゃんと書いてあるから

**デフォルトの名無しさん** · 2019/07/13(土) 10:36:53.09

お前フォートランだと信じてたフォートランは実はCだから

**デフォルトの名無しさん** · 2019/07/13(土) 10:47:30.74

答え：フォートランが速いのは全部グローバル変数しか使ってないから

**デフォルトの名無しさん** · 2019/07/13(土) 11:32:19.83

マジかよ俺もグローバル変数買ってくるわ（笑）

**デフォルトの名無しさん** · 2019/07/14(日) 00:27:06.85

>>569
ポインタの働きまで考慮すると、最適化しにくくなるからな。

**デフォルトの名無しさん** · 2019/07/14(日) 01:15:43.60

そろそろＣ言語が不要になるという話をちらほらきくな
ＬＬＶＭだのＪＶＭだの人間に扱いやすいマシン語もあるし
Ｒｕｓｔもあるし

Ｃはもともと言語の位置づけがまったく中途半端だった

**デフォルトの名無しさん** · 2019/07/14(日) 01:17:09.73

本木でいってんのか全角

**デフォルトの名無しさん** · 2019/07/14(日) 06:19:39.69

>>575
VMがマシン語とか沸いてんのか

**デフォルトの名無しさん** · 2019/07/14(日) 06:56:24.70

Rustはasycn/awaitもひとまず纏まって良いとは思うんだけどCが要らなくなるかと言われると同意しかねる
というのも高速化の為の低レイヤcalleeとしては型や機能がリッチで自身からの呼び出しAPIと他言語向けAPIの調整が煩雑じゃないかなと

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

cがいらなくなるとかもう30年くらい言われ続けてるんでないの？
ほんとバカだな〜と思うわ。

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

組み込みとかが存在する限りCも無くらなんだろうな
万が一、nimが流行ったらそれこそ無くならなくなる

**デフォルトの名無しさん** · 2019/07/14(日) 09:47:22.39

なんてことだた・・・次世代言語はCだったんだ・・・

**デフォルトの名無しさん** · 2019/07/14(日) 09:53:07.69

HaskelからC言語を生成するのが最強

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

最適化に適した中間言語はないのか

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

言語のシェア最大化問題のようなものを解きたい需要があるんだよね
C言語が最適解ではないという認識はバカではない
でも具体的にどこの誰がどういう取引をしたいのか考えないから供給も何もない

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

全ての言語に勝利(VICTORY)を約束したV言語が最初で最後の統一言語になるから
見とけよ見とけよ

**デフォルトの名無しさん** · 2019/07/14(日) 11:06:30.77

Vはメモリ管理の方針だけでも示してくれ

**デフォルトの名無しさん** · 2019/07/14(日) 11:12:03.05

次世代言語を越えるいい感じのメモリ管理で記述もGOより簡単になる予定やぞ

**デフォルトの名無しさん** · 2019/07/14(日) 21:17:25.26

>>567
それがどういうわけかこの板では嫉妬の対象らしくて詐欺とかになっちゃうらしい

**デフォルトの名無しさん** · 2019/07/14(日) 21:29:35.23

>>588
idで自演バレバレですよ