次世代言語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/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で自演バレバレですよ

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

>>589
ん？

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

>>587
その肝心の部分が今後良い感じになる予定(つまり、今の所まだ未定)とか言う
非常にお粗末な言語なんだが…
そもそも、そんな簡単に良い感じにメモリ管理ができるなら
Rustがあれほど所有権だのライフタイムだので苦労してるのは何故なの？っていうね…

まぁ本当に良い感じになるなら俺だってRustなんか捨てて華麗に掌返り決めるけど、
現状では詐欺と言われても致し方ないかと

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

vlangのメモリ管理はcomming soonだぞ。新規性のあるアイデアがあるようにも見えないんで、今のソースの記述レベルじゃ安全性は多分担保できない

**デフォルトの名無しさん** · 2019/07/15(月) 00:00:15.46

goみたいなものになってそれgoでよくね？になりそう。

**デフォルトの名無しさん** · 2019/07/15(月) 00:01:00.40

rustからクソみたいなもの取り除いたものになるならワンチャンあるかもだが。

**デフォルトの名無しさん** · 2019/07/15(月) 00:01:07.01

でもGOくそやん

**デフォルトの名無しさん** · 2019/07/15(月) 00:04:16.85

見えてる地雷ではあったけどソース公開後空気やん
他言語と比較できるレベルでないし20年後にまた来てください

**デフォルトの名無しさん** · 2019/07/19(金) 02:35:55.06

msはrust高評価だぞ
https://www.atmarkit.co.jp/ait/spv/1907/18/news122.html

**デフォルトの名無しさん** · 2019/07/19(金) 08:57:55.99

えぇ…自前で作ってるBosqueはどうすんだ…

**デフォルトの名無しさん** · 2019/07/19(金) 09:10:29.62

A proactive approach to more secure code
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/

C++ does have its virtues that make it attractive and in some cases essential:
it is blisteringly fast, it has a small memory and disk footprint, it’s mature, it’s execution predictable, its platform applicably is almost unparalleled and you can use it without having to install additional components.
If only the developers could have all the memory security guarantees of languages like .NET C# combined with all the efficiencies of C++.
Maybe we can: One of the most promising newer systems programming languages that satisfy those requirements is the Rust programming language originally invented by Mozilla.

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

>>598
bosqueは実験目的なのとまだ出たばかり。
実用目的のrustと比べるものじゃない。

**デフォルトの名無しさん** · 2019/07/19(金) 09:19:54.00

ﾎﾞｽｹﾃ…

**デフォルトの名無しさん** · 2019/07/19(金) 09:27:26.11

今時C++が使われる様な場面で代わりになりそうな次世代言語ってそりゃRust以外ないだろ

**デフォルトの名無しさん** · 2019/07/19(金) 11:08:45.37

Bosqueは学術的/実験的なのもあるけど
GC前提だから将来的にもC++/Rustと競合することは無いよ

**デフォルトの名無しさん** · 2019/07/19(金) 17:00:17.92

むしろ言語には縁故があるから
自前でC++コンパイラ作れるようなやつなら縁故でRust高評価
自前でF#作ったら尚更

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

BosqueとKotlinはコンパイラをセルフホスティングできていない言語
GoとRustとTypeScriptはコンパイラをセルフホスティングできている言語

**デフォルトの名無しさん** · 2019/07/20(土) 02:53:55.85

なおSwift

**デフォルトの名無しさん** · 2019/07/20(土) 12:29:21.00

まあc++の使われてる範囲って結構狭いけどね。

**デフォルトの名無しさん** · 2019/07/20(土) 12:43:44.66

PCとスマホの分断により、おま環GUIの価値がなくなった
バベルの塔が崩壊した
言語よりもGUIを重視するべき理由はもうない

**デフォルトの名無しさん** · 2019/07/20(土) 14:19:34.60

rust に c++ の [[nodiscard]] みたいなのってある？

**デフォルトの名無しさん** · 2019/07/20(土) 14:21:53.77

>>605
できないってことはないのでは？現時点ではやってないか、またはやってる事実をあなたが知らないだけで。
VM使っててVM部分まで作れるわけじゃないからというのであればKotlinにはNativeが出来つつあるのでやがてVMなしで問題なく動くやつは出来上がる。

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

language serverのことでは？