X

次世代言語15 Go Rust Bosque Kotlin TypeScript

■ このスレッドは過去ログ倉庫に格納されています
0502デフォルトの名無しさん
垢版 |
2019/06/27(木) 01:02:43.07ID:mUkuaqt3
関数型使えないって今どきありえないと思うんだよね
一昔前のOOPがわからないおじさんと同じレベルのこと言ってる
0503デフォルトの名無しさん
垢版 |
2019/06/28(金) 17:48:17.39ID:F+cepw8m
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/
0505デフォルトの名無しさん
垢版 |
2019/06/29(土) 07:03:32.03ID:8bAr7lLW
vlang、言語作成の過程を見るにはちょうどいいな。
ソースもまだそんなでかくないし。
0506デフォルトの名無しさん
垢版 |
2019/06/29(土) 16:52:27.05ID:RFSaJ24c
printfに限らず困ったらC呼べるのは案外実用的かも？
（というかライブラリ整備で楽したい？）
0508デフォルトの名無しさん
垢版 |
2019/06/29(土) 21:37:36.03ID:k/WM/TXw
Kotlin もよろしく
0510デフォルトの名無しさん
垢版 |
2019/06/30(日) 20:00:00.91ID:2juPiYlp
そのうちV2言語とかV2AB言語とか出そう
0511デフォルトの名無しさん
垢版 |
2019/06/30(日) 20:09:39.02ID:jEBvEs4p
すでに VB はあるがな
0514デフォルトの名無しさん
垢版 |
2019/07/01(月) 23:11:18.59ID:yt2EFQVJ
vlangはたしかにgoのダッサダサな部分を洗練させた感があるけど、肝心のgoroutineはないのかね？
0515デフォルトの名無しさん
垢版 |
2019/07/02(火) 08:38:42.74ID:QDdew1lC
あるっつの
0516デフォルトの名無しさん
垢版 |
2019/07/02(火) 10:18:10.05ID:ep8keXko
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のようなライフタイムも無しで
手動でないメモリ管理を実現するそうだが
0517デフォルトの名無しさん
垢版 |
2019/07/02(火) 10:24:59.91ID:EIrkP3Yf
大学の情報系出た奴にありがちな、前人の基礎研究を舐めてる典型的な馬鹿だな
0518デフォルトの名無しさん
垢版 |
2019/07/02(火) 12:15:31.11ID:0IWRI8p9
肝心なとこが未実装とか…
そこが他言語と異なるセールスポイントちゃうんか
0519デフォルトの名無しさん
垢版 |
2019/07/02(火) 12:28:00.79ID:7go+wzeH
Goの対案を出せとか、ありがちなことを言われたのかな
言われた通りにしてもバカにされるだけというありがちなパターンかな
0521デフォルトの名無しさん
垢版 |
2019/07/02(火) 13:00:27.32ID:V6TxZCKa
>>516
rustみたいにガチガチじゃなきゃいいよ
0522デフォルトの名無しさん
垢版 |
2019/07/02(火) 13:07:25.57ID:EIrkP3Yf
いっそエスケープは一切禁止でスタックベースのリソース管理しかできない言語があってもいい
非同期処理さえうまく扱えれば実用的だと思う
0524デフォルトの名無しさん
垢版 |
2019/07/02(火) 14:38:03.95ID:ep8keXko
言語機能の複雑さという代償はあったが
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の設計者達にマウント取れるレベル
0525デフォルトの名無しさん
垢版 |
2019/07/02(火) 14:52:15.52ID:NqAwj9wC
金集めのためのハッタリ・詐欺かもね。
どう実装するかは集めた金でバカンス中に考えるんでしょ。
0527デフォルトの名無しさん
垢版 |
2019/07/02(火) 15:55:49.14ID:7go+wzeH
Haskellの副作用問題やRustのグラフ構造問題のような
原理主義の藁人形がいなくなるまで無視すればいい
0529デフォルトの名無しさん
垢版 |
2019/07/02(火) 16:00:36.62ID:wuyggzG7
どうせプログラム終了すればOSが使ったメモリ全部解放するから
長時間動かすプログラムのベストプラクティスは定期的に自動で状態保存→リブート→復元？
ある意味合理的な富豪プログラミングｗ
0530デフォルトの名無しさん
垢版 |
2019/07/02(火) 16:03:59.36ID:dJ0Zw08U
cloud の go はそれだな
0531デフォルトの名無しさん
垢版 |
2019/07/02(火) 18:22:15.31ID:NqAwj9wC
>>526
ｗｗｗ
0534デフォルトの名無しさん
垢版 |
2019/07/02(火) 19:52:14.87ID:KyyCHPDG
rust以外にもベアメタルな新言語は色々あったよ。clayとかBitCとかdecaとかcycloneとか
安全性についてはスルーした言語や挑戦して失敗した言語もあった
vlangはそこを吹かしてるから地雷にしか見えない
0536デフォルトの名無しさん
垢版 |
2019/07/02(火) 22:15:30.17ID:hWBdgMuf
>>524
goの方向が正解だわ。
GCがあることで他資源管理に集中できるし。
ただchannelでのブロックによるgoroutineリークは想定してなかった言語ミスだと思う。
そこは改善の余地ありだわ。
0537デフォルトの名無しさん
垢版 |
2019/07/03(水) 01:59:42.47ID:ZPqKMvhJ
>>524
Rustとは異なる一つの解として、フロー解析を頑張るという方向性はアリだと思う
Rustのように人間が明示的に型を付けることによって制御するんではなく、TypeScriptの型推論みたいにコンパイラが頑張ってフローから生存範囲を割り出す
Vには期待してないが、MSあたりが本気で取り組めば実用的なものはできそう
0538デフォルトの名無しさん
垢版 |
2019/07/03(水) 11:04:20.52ID:XNaiDTR1
>>537
それは>>517も言うような前人を甘く見た考えだよ・・

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

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

コンパイル時間との兼ね合いもあるけど
GC言語にとっての理想形の一つは実行時のGCコストゼロだから
0539デフォルトの名無しさん
垢版 |
2019/07/03(水) 12:16:45.29ID:gRfGMTMZ
自分ができると思うのは甘い
MSが総力を挙げて取り組めばできる

主語が小さいなら悲観、主語が大きいなら楽観する現象
0540デフォルトの名無しさん
垢版 |
2019/07/03(水) 12:42:18.44ID:hoHjSSrx
それは事実だから仕方ない
結局OSSの成功例は企業製のものばっかりだったりするし
0541デフォルトの名無しさん
垢版 |
2019/07/03(水) 18:10:18.83ID:m32ejpp6
じゃあMSが新しい言語作るのをじっと待ってるのが正解なんだな
0543デフォルトの名無しさん
垢版 |
2019/07/03(水) 23:27:22.96ID:zQMV1srp
TypeScriptのような型推論は、原理的には可能なんだろうけど現実的には計算量が爆発すると思ってた。
まさか実際にやってのけるとはなぁ。
0545デフォルトの名無しさん
垢版 |
2019/07/04(木) 00:09:12.36ID:kZ6AZY+J
rubyが型ゆるくて逝ったように型推論とかやめて明示しようって話になる。
バカは何度でも同じ過ちを繰り返す。
0546デフォルトの名無しさん
垢版 |
2019/07/04(木) 00:50:15.12ID:syUh+sWg
rubyがバカなだけじゃん
自分とこの失敗の恥を他人とこに押し付けるなｗ
0547デフォルトの名無しさん
垢版 |
2019/07/04(木) 02:43:53.90ID:eYCKxaQ9
template引数が爆発的に増えてきてから型推論を考えるのが理にかなっている
先に型推論を作り込んで後でtemplateが欲しくなっても時既に遅し
0548デフォルトの名無しさん
垢版 |
2019/07/04(木) 08:23:42.62ID:kZ6AZY+J
>>546
バカがやった失敗をしっかり見ろって話なんだが。
やっぱり見ないのがバカたる所以なんだよね。
0550デフォルトの名無しさん
垢版 |
2019/07/06(土) 09:52:45.57ID:zcl3Wfgw
FORTRAN派はJuliaに乗り換えてくれればいい
0551デフォルトの名無しさん
垢版 |
2019/07/06(土) 10:09:15.59ID:yJlOMfg/
Juliaは呼ばれる側には向いてないからどちらが良いとか以前に代替にならない
0553デフォルトの名無しさん
垢版 |
2019/07/06(土) 11:03:51.51ID:4hi3BAKB
グローバル変数にGCは不要だから昔の言語は速い
しかもスタックもボローチェッカーも不要
今の多数派は速度と学習コストを犠牲にしてでもグローバル変数禁止を優先する
0554デフォルトの名無しさん
垢版 |
2019/07/06(土) 11:11:24.68ID:MhitVE0d
>>553
速度と学習コストを優先してグローバル変数を多用したいなら、今でもそれができる言語は使用可能なのだから好きに選択すればいいんじゃね？
0555デフォルトの名無しさん
垢版 |
2019/07/06(土) 11:12:54.20ID:NRY4HgVe
他言語から呼ぶのに配列を転置したりインデクスを1オリジンにしたり面倒くさいんだよ教授のライブラリ
と学生の頃思ったわ
0556デフォルトの名無しさん
垢版 |
2019/07/06(土) 12:46:36.15ID:4hi3BAKB
>>554
結果だけでなく過程にも色々と好みがあんだよ
予告なしで突然その行動をするのか
あるいは言いたいことを全部言ってから行動するのか
0557デフォルトの名無しさん
垢版 |
2019/07/06(土) 14:57:38.96ID:giRSX6GS
グローバル変数が早いってどういう理論？
全ての変数に対応できるような糞で固めモリ確保するの？ばかなのしぬの？
0558デフォルトの名無しさん
垢版 |
2019/07/06(土) 15:04:47.10ID:zcl3Wfgw
間接アドレッシングより直接アドレッシングの方が速いとか
メモリ上の位置が固定されるから速いとか
有利な面はあるんじゃね

知らんけどω
0560デフォルトの名無しさん
垢版 |
2019/07/06(土) 15:35:24.84ID:j6TJ9xhQ
集積度でCPUにレジスタ・キャッシュが貴重だった頃の(ry
RISC以降は組み込みですらローカル変数のほうが速度出るはず
0561デフォルトの名無しさん
垢版 |
2019/07/06(土) 15:54:52.39ID:4hi3BAKB
GCが遅いだけだな
ローカル変数が遅いなんて誰かに言わせても仕方ない
人に言わせたいことではなく自分が言いたいことを語れよ
0562デフォルトの名無しさん
垢版 |
2019/07/06(土) 16:15:05.44ID:aan9FGim
ドンッ！！
0564デフォルトの名無しさん
垢版 |
2019/07/12(金) 04:42:18.60ID:4xncqjus
>>557
メモリ確保やらスタックやらのオーバーヘッドがグローバル変数だと起こりにくい、ということなんじゃね？
0565デフォルトの名無しさん
垢版 |
2019/07/12(金) 07:53:38.13ID:Bn8x2zNm
スタックと比較した場合、計測せにゃわからんが結論だろ。
結局はキャッシュヒット率の問題だったりするわけだし。
0566デフォルトの名無しさん
垢版 |
2019/07/12(金) 21:53:30.16ID:4b6kN5JV
キャッシュのこと考えたらグローバル変数のアクセスは遅いだろ
0567デフォルトの名無しさん
垢版 |
2019/07/13(土) 07:24:03.78ID:THUdwCLa
フォートランがなぜCより速いかしってる？
0568デフォルトの名無しさん
垢版 |
2019/07/13(土) 09:15:34.94ID:AlkU9RI1
速くないから
0569デフォルトの名無しさん
垢版 |
2019/07/13(土) 09:49:57.15ID:y4NPM01z
FortranはCより自由度に劣る代わりに最適化しやすいからな
気を使わなくてもベクトル化や拡張命令の対応をコンパイラがやってくれるから
京とかのスパコンでの大規模計算の分野で使われてる
0572デフォルトの名無しさん
垢版 |
2019/07/13(土) 10:47:30.74ID:THUdwCLa
答え：フォートランが速いのは全部グローバル変数しか使ってないから
0575デフォルトの名無しさん
垢版 |
2019/07/14(日) 01:15:43.60ID:dk3FaKVW
そろそろＣ言語が不要になるという話をちらほらきくな
ＬＬＶＭだのＪＶＭだの人間に扱いやすいマシン語もあるし
Ｒｕｓｔもあるし

Ｃはもともと言語の位置づけがまったく中途半端だった
0578デフォルトの名無しさん
垢版 |
2019/07/14(日) 06:56:24.70ID:ryvUAmdj
Rustはasycn/awaitもひとまず纏まって良いとは思うんだけどCが要らなくなるかと言われると同意しかねる
というのも高速化の為の低レイヤcalleeとしては型や機能がリッチで自身からの呼び出しAPIと他言語向けAPIの調整が煩雑じゃないかなと
0579デフォルトの名無しさん
垢版 |
2019/07/14(日) 07:45:35.15ID:+8XuBzkV
cがいらなくなるとかもう30年くらい言われ続けてるんでないの？
ほんとバカだな〜と思うわ。
0580デフォルトの名無しさん
垢版 |
2019/07/14(日) 07:55:49.65ID:+79Cdwyg
組み込みとかが存在する限りCも無くらなんだろうな
万が一、nimが流行ったらそれこそ無くならなくなる
0584デフォルトの名無しさん
垢版 |
2019/07/14(日) 10:52:29.76ID:paZ1nCkk
言語のシェア最大化問題のようなものを解きたい需要があるんだよね
C言語が最適解ではないという認識はバカではない
でも具体的にどこの誰がどういう取引をしたいのか考えないから供給も何もない
0585デフォルトの名無しさん
垢版 |
2019/07/14(日) 10:56:34.40ID:2xqRxSvx
全ての言語に勝利(VICTORY)を約束したV言語が最初で最後の統一言語になるから
見とけよ見とけよ
0587デフォルトの名無しさん
垢版 |
2019/07/14(日) 11:12:03.05ID:kbgTNG98
次世代言語を越えるいい感じのメモリ管理で記述もGOより簡単になる予定やぞ
0588デフォルトの名無しさん
垢版 |
2019/07/14(日) 21:17:25.26ID:VYICulF9
>>567
それがどういうわけかこの板では嫉妬の対象らしくて詐欺とかになっちゃうらしい
0590デフォルトの名無しさん
垢版 |
2019/07/14(日) 22:05:08.08ID:VYICulF9
>>589
ん？
0591デフォルトの名無しさん
垢版 |
2019/07/14(日) 22:26:52.95ID://LKIq+W
>>587
その肝心の部分が今後良い感じになる予定(つまり、今の所まだ未定)とか言う
非常にお粗末な言語なんだが…
そもそも、そんな簡単に良い感じにメモリ管理ができるなら
Rustがあれほど所有権だのライフタイムだので苦労してるのは何故なの？っていうね…

まぁ本当に良い感じになるなら俺だってRustなんか捨てて華麗に掌返り決めるけど、
現状では詐欺と言われても致し方ないかと
0592デフォルトの名無しさん
垢版 |
2019/07/14(日) 23:31:36.82ID:BBEf0Qp/
vlangのメモリ管理はcomming soonだぞ。新規性のあるアイデアがあるようにも見えないんで、今のソースの記述レベルじゃ安全性は多分担保できない
0594デフォルトの名無しさん
垢版 |
2019/07/15(月) 00:01:00.40ID:MjmXYKrZ
rustからクソみたいなもの取り除いたものになるならワンチャンあるかもだが。
0596デフォルトの名無しさん
垢版 |
2019/07/15(月) 00:04:16.85ID:swODgMrH
見えてる地雷ではあったけどソース公開後空気やん
他言語と比較できるレベルでないし20年後にまた来てください
0598デフォルトの名無しさん
垢版 |
2019/07/19(金) 08:57:55.99ID:MqWaI42B
えぇ…自前で作ってるBosqueはどうすんだ…
0599デフォルトの名無しさん
垢版 |
2019/07/19(金) 09:10:29.62ID:aKZJYqz8
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.
0600デフォルトの名無しさん
垢版 |
2019/07/19(金) 09:12:45.57ID:c3q8AFcr
>>598
bosqueは実験目的なのとまだ出たばかり。
実用目的のrustと比べるものじゃない。
0601デフォルトの名無しさん
垢版 |
2019/07/19(金) 09:19:54.00ID:MqWaI42B
ﾎﾞｽｹﾃ…
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況