次世代言語9[Haskell Rust Kotlin TypeScript Dart]

**デフォルトの名無しさん** · 2018/03/06(火) 10:09:15.60

スレタイ以外の言語もok

前スレ
次世代言語Part8[Haskell Rust Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1512137301/

**デフォルトの名無しさん** · 2018/03/13(火) 21:12:42.56

ここで唐突に新言語が乱入だー

C言語の現代化を目指すC2
https://www.infoq.com/jp/news/2018/03/c2lang-modern-c

**デフォルトの名無しさん** · 2018/03/13(火) 23:32:12.39

これか
http://c2lang.org/
Cより良さそう

**デフォルトの名無しさん** · 2018/03/14(水) 00:03:14.25

>>331
まだCより良さそうなんて判断は無理だろ。マクロ周りが全貌も見えてないし。

**デフォルトの名無しさん** · 2018/03/14(水) 00:04:08.32

配列の範囲外アクセス検知強化してたら有能

**デフォルトの名無しさん** · 2018/03/14(水) 00:27:05.17

C2は機能は悪くないんだがCの記法を引きずってるのが足かせになりそう
まあそこを変えたらC2なんて名乗れなくなるか

**デフォルトの名無しさん** · 2018/03/14(水) 01:05:08.25

>>328
１つの言語でいいのになんでおもいおもいに勝手に言語作るの？

**デフォルトの名無しさん** · 2018/03/14(水) 01:10:36.80

ベストな言語は未だ存在しないからだよ

**デフォルトの名無しさん** · 2018/03/14(水) 01:13:29.13

まあ99.9%の仕事じゃ既存の言語使った方が効率いいわな。
本当のところ、新しい言語なんてマーケティング的な意味以上のものがあると思えん。

**デフォルトの名無しさん** · 2018/03/14(水) 02:02:52.14

同じものを作り続けるならそうだろうけど、普通要件に因るでしょう

**デフォルトの名無しさん** · 2018/03/14(水) 02:44:51.50

C2？
まーた波括弧言語か……

OCamlのシンタクスを波括弧にする改悪だけの凄まじいクソだったReasonのトラウマが……
Rust がML系シンタクスだったら良かった人生だった

**デフォルトの名無しさん** · 2018/03/14(水) 02:50:33.24

えーみんなオフサイドルール好きなの？

**デフォルトの名無しさん** · 2018/03/14(水) 03:09:29.30

勝手にc2とか名乗って問題にならないのかな
cの規格をc99、c11みたいに表示するから言語名＋数字はちょっと紛らわしいと思う

**デフォルトの名無しさん** · 2018/03/14(水) 03:47:25.69

フォーラムちょっと読んでみたけどまだまだ全然まともなものとは思えんで
フォーカスしてる用途が不便を楽しむ遊び、ポートする楽しさ以外見えてこない

**デフォルトの名無しさん** · 2018/03/14(水) 07:37:15.69

オフサイドルールなんて嫌
そもそもrustのブロックを表現できないじゃないか

**デフォルトの名無しさん** · 2018/03/14(水) 07:56:53.64

>>340
ML系シンタクスってオフサイドルールとは違うと思うけど？

**デフォルトの名無しさん** · 2018/03/14(水) 09:59:50.84

細かい字面の違いなんぞどうでもいいわ

**デフォルトの名無しさん** · 2018/03/14(水) 12:08:19.96

見た目は波括弧だが意味は中括弧か大括弧
一行で書けない長いやつ
だがラムダがあったら小括弧の内部に大括弧を書くことがあるから意味がない
Pythonの波括弧は集合か辞書を意味する
Haskellの波括弧は囲んだ部分のオフサイドルールを無効にする機能

**デフォルトの名無しさん** · 2018/03/14(水) 13:10:17.73

C2を名乗るなら既存のヘッダファイルとモジュールの両立を真っ先に考えないと
現状ヘッダファイルを手動で書き直さないといけないのでは、Cと互換性のない他の新興言語と何も変わらん
本家Cに提案されているモジュールが採用されたら存在意義を失う

**デフォルトの名無しさん** · 2018/03/14(水) 13:18:43.15

緊急速報

（＋）【IT】AMD製CPUに「致命的」欠陥悪用でPC乗っ取りも
https://asahi.5ch.net/test/read.cgi/newsplus/1520989318/

（BIZ+）【CPU】AMD製CPUに「致命的」欠陥悪用でPC乗っ取りも
https://egg.5ch.net/test/read.cgi/bizplus/1520995986/

（ゲハ）【PS4/XONE】AMDのCPUに致命的な欠陥【Ryzen】
https://krsw.5ch.net/test/read.cgi/ghard/1520998474/

**デフォルトの名無しさん** · 2018/03/14(水) 14:10:00.37

コンパイルはできるがリンクができないのが現代
未来ならまあわかるが現代化を目指してもやっぱりリンクができない

**デフォルトの名無しさん** · 2018/03/14(水) 18:19:32.06

C2使ってみようと思ったらこれCのコードに変換してるだけだった
これくらいなら同じものすぐに作れる人いそう

**デフォルトの名無しさん** · 2018/03/14(水) 18:36:37.90

それくらいの方が見通しが良くていいかもな

**デフォルトの名無しさん** · 2018/03/14(水) 18:54:14.79

Cのプリプロセスのマクロとかが遅いからとか書いてなかったか？
C2をCに変換するトランスパイラじゃ意味ないじゃん

**デフォルトの名無しさん** · 2018/03/14(水) 19:40:13.34

そんなんどこに書いてあるの？

**デフォルトの名無しさん** · 2018/03/14(水) 19:59:28.97

>>353
コンパイル時間を大幅に遅くするヘッダファイルの使用が問題ってそういうことじゃないの？

**デフォルトの名無しさん** · 2018/03/14(水) 20:12:57.97

Include先がまた別のファイルincludeする大連鎖include地獄のことを言ってるんじゃない？

**デフォルトの名無しさん** · 2018/03/14(水) 20:26:52.27

C with class じゃないですか。。

**デフォルトの名無しさん** · 2018/03/14(水) 20:53:53.48

ポリモーフィズムはともかく継承もインターフェイスも仮想関数も型クラス・トレイトも無いように見えるがこれをクラスと呼ぶのか……？

**デフォルトの名無しさん** · 2018/03/14(水) 23:12:31.41

Nim,Crystal あたりと合わせて altC って感じやな

**デフォルトの名無しさん** · 2018/03/14(水) 23:35:24.83

3つ眺めてみたけどnimに惹かれる。
こんな言語あったんか…なんでこんなん知ってんだお前ら

**デフォルトの名無しさん** · 2018/03/15(木) 03:29:44.83

nimいいじゃんこれ

**デフォルトの名無しさん** · 2018/03/15(木) 05:29:41.26

ここのスレに顔出しててNim知らないのか…
まじで知名度ないな

**デフォルトの名無しさん** · 2018/03/15(木) 07:38:27.49

NimはQiitaとかでたまに話題に上がるから
次世代系の中では比較的有名なのかと思ってた

**デフォルトの名無しさん** · 2018/03/15(木) 15:07:19.69

変な奴に好かれて評価を落とした言語という印象が付いてしまった感がある
実際触ると構文はPython機能はDelphiプラスD言語って感じで性能も良好なんだが
モダンな感じはしないのが弱いかな
特にPascal風のバリアントレコードを引きずってるのが痛い。代数的データ型ぐらい欲しい

**デフォルトの名無しさん** · 2018/03/15(木) 16:21:52.17

このスレ来てるのにNix言語も知らないってマジ？

**デフォルトの名無しさん** · 2018/03/15(木) 17:26:52.54

知らんかったから調べたけどこれはいいや…俺は惹かれなかった。しかし検索性悪いな

**デフォルトの名無しさん** · 2018/03/15(木) 20:25:23.49

>>339
波括弧こそ至高

**デフォルトの名無しさん** · 2018/03/15(木) 20:49:12.32

マクロとかメタプログラミング向けの機能以外はこれといった特徴無いように見えるね。
しいて言えばgoやrustみたいにアクが強すぎないところかな？
あるいは、pythonのようなオフサイドルールでネイティブコンパイルできるってのが
一部の人の琴線に触れるような気がしないでもない。

**デフォルトの名無しさん** · 2018/03/15(木) 20:52:20.23

何よりCを凌駕するというとんでもないパフォーマンスを持つという記事の存在が大きい

**デフォルトの名無しさん** · 2018/03/15(木) 21:48:11.64

バリアントレコード位しか c(++) より速くなる要素無いがな…

**デフォルトの名無しさん** · 2018/03/15(木) 22:05:28.04

cより速いとか大抵特殊な条件下だったりの煽り記事だけどね。

**デフォルトの名無しさん** · 2018/03/15(木) 22:37:00.89

煽り記事に煽られて有名になった言語

実際、結構複雑なことしてもc並みに速いんかねえ……？

**デフォルトの名無しさん** · 2018/03/15(木) 22:43:14.62

Cへのトランスパイラ言語は何やってるか判ってれば同等になるでしょ。
まあ、"Cより早い"　が意味があった試しは無い。

**デフォルトの名無しさん** · 2018/03/15(木) 22:51:44.82

複雑なことっていうのは、Cにどう変換されるか負えないくらい複雑なことってことだよ

**デフォルトの名無しさん** · 2018/03/15(木) 23:02:50.82

nim performance で検索してトップに出てくる
http://blog.johnnovak.net/2017/04/22/nim-performance-tuning-for-the-uninitiated/

ではレイトレースというごく単純な処理で出てくるコード見ながら色々やってるな
inline 指定したり

複雑な処理は c で書いても複雑(で恐らく遅いの)だから、
簡単な処理が速く書ければいいんじゃない？

上記ページによると Java と JS が数値計算案外速くて笑う

**デフォルトの名無しさん** · 2018/03/15(木) 23:19:56.51

昔LuaJITはぇーって盛り上がった事あったなあ…

**デフォルトの名無しさん** · 2018/03/16(金) 06:03:27.99

pythonが遅いからなぁ

**デフォルトの名無しさん** · 2018/03/16(金) 07:44:37.90

今年もrustが愛され言語No1に輝きましたな
スタックオーバーフローにはモジラの息のかかった人しかいないのかな

**デフォルトの名無しさん** · 2018/03/16(金) 09:48:10.52

支持率改竄が愛され陰謀論ナンバーワン

**デフォルトの名無しさん** · 2018/03/16(金) 20:00:27.38

>>231
オマエが馬鹿だろ。死ね

**デフォルトの名無しさん** · 2018/03/16(金) 20:38:34.09

Cより速いを名乗るには、C言語では吐けないアセンブリパターンを吐く必要があるはずだが
現実にはバックエンドが同じなんでC言語でも再現可能だからなあ
(処理系固有のattributeやpragmaを書き足す必要がある場合も多いだろうけど)

**デフォルトの名無しさん** · 2018/03/16(金) 21:14:11.01

そこでmasmですよ。

**デフォルトの名無しさん** · 2018/03/16(金) 21:27:41.47

現行バージョンのメジャーなライブラリでもmalloc/free (new / delete) が結構遅いから
rpmalloc 辺りを使うコード吐くだけで「処理によっては C より速い！」が実現できる気もする

**デフォルトの名無しさん** · 2018/03/16(金) 22:03:02.48

非標準のライブラリを使ってはいけないとかCが遅くなるルールを何個か追加すればいい
他にも、変更されたら困るデータはコピーを取る手間がかかる
immutableを保証すればその手間がないからCより速い

**デフォルトの名無しさん** · 2018/03/16(金) 22:48:15.19

そう言われてみると他のスレッドからアクセスされないメモリ/オブジェクトは
スレッドローカルなプールからアロケートするとか
その他のロックも省略できるとか色々最適化の余地あるな

**デフォルトの名無しさん** · 2018/03/16(金) 23:45:02.47

*2が勝手に足し算に変わるとか、そういう最適化を勝手にやってくれてるな
あとはどうあがいてもプロが最適化したCに勝てるわけがないし、素人が適当に書いたCと素人が適当に書いたnimのどっちが速いかだな

**デフォルトの名無しさん** · 2018/03/17(土) 00:00:18.49

>>385
前時代的の異物、死ね。
速度の必要な部分だけを切り出して、それだけをアセンブリコードにすればいいだけ。

**デフォルトの名無しさん** · 2018/03/17(土) 00:01:17.17

>>385
>>374のリンク先の記事はある程度参考になると思う

**デフォルトの名無しさん** · 2018/03/17(土) 00:02:21.86

なんで死ねって言われたのか理解できない
アセンブリコードまで自前で書くほうが前時代の遺物感強いと思うけどなあ

**デフォルトの名無しさん** · 2018/03/17(土) 00:44:26.42

>>388
理解できないなら、死ねばいいだけ。

**デフォルトの名無しさん** · 2018/03/17(土) 01:00:08.76

Cに代わる次世代言語はアセンブラやC、C++で書かれた
高速な実装を呼び出す1行のコードが書ければ十分ってことだろう。
そうしてそれがわからないなら死ねばいい、と。

**デフォルトの名無しさん** · 2018/03/17(土) 01:12:32.40

普通に考えたら高速な実装を書ける言語がアセンブラやC、C++だとすれば
Cに代わる次世代言語も同じように高速な実装を書けなきゃ代わりにならない

**デフォルトの名無しさん** · 2018/03/17(土) 01:36:41.05

その普通に考えるってのが前時代的だな
スピードではなくフライングで勝つサイコパスのような考えができない

**デフォルトの名無しさん** · 2018/03/17(土) 01:53:39.29

Nimは速い上にCよりずっと楽に書けるんだが

**デフォルトの名無しさん** · 2018/03/17(土) 02:01:20.25

>>392
ということは最近は「代わり」は置き換え可能な存在という意味ではなくなったんだね
それなら前時代的と言われても仕方がない

**デフォルトの名無しさん** · 2018/03/17(土) 10:06:45.76

まあ最近でも低レイヤーの仕事としてGPUのアセンブラチューニングって話はあるけど、
どうせユーザー側なら言語とか関係ないけどね。
結局どんな言語使ってもどうせライブラリ呼ぶだけのお仕事でしょう。

**デフォルトの名無しさん** · 2018/03/17(土) 10:13:19.41

Clojureの話する？

**デフォルトの名無しさん** · 2018/03/17(土) 10:17:40.12

プロが本気で書いたCに勝つのは無理だろ
でも最適化しやすくして読みやすく書いてもプロが本気で書いたC並の速度出る言語なら…

**デフォルトの名無しさん** · 2018/03/17(土) 10:47:29.26

なんで速さの勝負になるかよく分からんし
速さしか考えないならCは中途半端やろ

**デフォルトの名無しさん** · 2018/03/17(土) 10:59:08.85

>>394
バグを正解に置き換えるならいいが、バグではないものをその1bit棒で叩くのは危ない

**デフォルトの名無しさん** · 2018/03/17(土) 11:18:24.87

immutable云々はデバッグ目的で使えるからCを置き換える可能性はある
速さはおまけ

**デフォルトの名無しさん** · 2018/03/17(土) 11:46:47.41

強力なおまけは魅力的ね

**デフォルトの名無しさん** · 2018/03/17(土) 13:48:58.28

これまでどれだけの言語が
「Cと同等！」、「Cを置き換える！」って言って来たことか。

**デフォルトの名無しさん** · 2018/03/17(土) 14:38:29.12

Nimの特徴はC並みの実行速度でCより手軽に書けることですか…
なんだかGoとキャラが被ってる気が…
Nimって生ポインタ扱えるの？

**デフォルトの名無しさん** · 2018/03/17(土) 14:48:40.03

でもCより速いVM言語とかあるし。

**デフォルトの名無しさん** · 2018/03/17(土) 14:57:44.26

NimはどっちかというとOCamlに近い存在だろ
Cの置き換えは狙ってねえよ

**デフォルトの名無しさん** · 2018/03/17(土) 15:27:21.87

OCamlか…そういえばそんな言語あったなぁ
あれもモダンなコードが書けるうえにC並みに速いって話を聞く
Rustのコンパイラは初めOCamlで書かれていたということは知ってる
聞く限りにはかなり良さそうなのに全く普及する気配がないのは何故？

**デフォルトの名無しさん** · 2018/03/17(土) 15:27:38.42

実行状況に応じて実行しながら最適化ができるから原理的にはVM言語のほうが速くなる
まあその理屈だとインタプリタが最強なわけだが

**デフォルトの名無しさん** · 2018/03/17(土) 15:49:23.67

なんか知らんけどこのスレには熱心なOCamlアンチがいるよな

**デフォルトの名無しさん** · 2018/03/17(土) 15:57:42.27

なんか知らんけどこのスレには熱心なRustアンチもいるよな

**デフォルトの名無しさん** · 2018/03/17(土) 16:24:52.64

おるな

**デフォルトの名無しさん** · 2018/03/17(土) 18:15:28.10

>>403
Goは遅いぞ

**デフォルトの名無しさん** · 2018/03/17(土) 18:36:45.18

言うほど遅いか？

**デフォルトの名無しさん** · 2018/03/17(土) 18:40:43.08

>>412
Cとかと比べたらね
「速い」ってほど速くはない

**デフォルトの名無しさん** · 2018/03/17(土) 18:44:17.42

JVMよりちょっと速いレベルでしょ
一般的な用途では十分だけど

**デフォルトの名無しさん** · 2018/03/17(土) 18:59:01.64

そんな十分とか言い出すなら俺なんかPythonの速さでも十分だわｗ

**デフォルトの名無しさん** · 2018/03/17(土) 19:14:57.81

>>407
「実行状態を調べて最適化」なる余分な仕事の分だけ遅くなる
最適化でそのオーバーヘッドを取り戻せるかどうかは自明ではない

**デフォルトの名無しさん** · 2018/03/17(土) 19:40:49.75

>>390
あー。つまり、シェルスクリプト。

**デフォルトの名無しさん** · 2018/03/17(土) 19:58:26.68

シェルスクリプトは次世代言語だったのか……

**デフォルトの名無しさん** · 2018/03/17(土) 20:03:43.73

#!/bin/sh

ls

もう、これだけでCで書かれた超高速なlsが実行される。

**デフォルトの名無しさん** · 2018/03/17(土) 20:12:06.50

シェルスクリプトが次世代言語とは流石に分からんかったわ
死ななきゃならんのか……

**デフォルトの名無しさん** · 2018/03/17(土) 22:19:21.09

サイコパスあるある
死傷者が出ても見て見ぬふりをする

**デフォルトの名無しさん** · 2018/03/18(日) 01:12:13.80

Cに変わる言語は遅い部分をCで書いて"代替"するのか…

**デフォルトの名無しさん** · 2018/03/18(日) 02:11:42.71

速い遅いよりも矛盾をなんとかする方が重要だ
もし速さを優先して矛盾を野放しにしたらどうなるか全く予測できない

**デフォルトの名無しさん** · 2018/03/18(日) 02:55:12.96

こりゃまた難しいのがきた

**デフォルトの名無しさん** · 2018/03/18(日) 03:18:03.86

同じC言語でも速さに違いが出るのに

**デフォルトの名無しさん** · 2018/03/18(日) 11:11:10.49

ソフトだからね
なんで同じソフトが違うハードで動くのかという説明から始めないといけないかも

**デフォルトの名無しさん** · 2018/03/18(日) 14:10:28.16

Cの良さは
変換される機械語との違いが滑らか
それでいてメモリ部分はある程度抽象化してくれている。
てなところなんでないかね。

他の言語は「変換される機械語との違いが滑らか」を無視しすぎてる。

**デフォルトの名無しさん** · 2018/03/18(日) 14:13:46.06

先ずはそのよく分からん「変換される機械語との違いが滑らか」を定義するところからガンバレ

**デフォルトの名無しさん** · 2018/03/18(日) 14:27:58.24

セマンティックギャップの話かな