次世代言語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/11(日) 23:44:01.66

C++をNGした

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

小資本が大資本と戦う武器としてC++は良い選択になりえる。
時は来た。
今は良いタイミングだ。

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

C++が速いのではなく早いならこのスレでは時期尚早でもう話すこと無いな

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

オレもNGするか…さようならC++、信者に恵まれなかった言語よ

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

Webサービス開発に絞った話な。
リリースの速さ必要ならRoR
堅さが必要ならJava, Scala, Go
これからはインフラ親和性も必要だから、サーバレスならGo, Python, Node

RoRの劣化コピーのオレオレFWで内ゲバやってるPHPは、もう選択肢にすらあがらんだろ
まともな審美眼と技術力を持ってればね

**デフォルトの名無しさん** · 2018/03/12(月) 00:00:42.95

Nodeは危険すぎると感じたな。

**デフォルトの名無しさん** · 2018/03/12(月) 00:30:16.07

>>304
具体的に何が？

**デフォルトの名無しさん** · 2018/03/12(月) 00:38:32.62

危険性を理解したうえで使ってるのかと思ったらそうでもないんだな。

**デフォルトの名無しさん** · 2018/03/12(月) 00:52:06.18

敏感ヴォーイの被害妄想かい？ｗ

**デフォルトの名無しさん** · 2018/03/12(月) 01:26:46.12

私が思うに、決定性を持つアルゴリズムで解析ができないものはすべて危険であり、ネットワークでは避けたほうが良い。
ここに反論するものはいるだろうか？

**デフォルトの名無しさん** · 2018/03/12(月) 01:30:16.67

一方で、決定性を持つアルゴリズムは様々な理由をつけてネットワークから排除されてきた。
これはおそらく大衆の無知につけ込んだ出来事に違いない。
おそらく、決定性と言われても何のことかわからない人は、これを読む者の中にも多いだろう。
とりわけウェブエンジニアには無知が多い。
無知にも務まる時代から、無知でなければ務まらない時代へ。
そんな感じすらある。

**デフォルトの名無しさん** · 2018/03/12(月) 01:39:07.46

純粋関数の徒か？

**デフォルトの名無しさん** · 2018/03/12(月) 01:40:40.08

現状でウェブ上のすべてのものが危険であり、容易にハックされ得る。
狙われた瞬間降参するしかないのだ。
原理的に防ぐ方法が無いからだ。
SUNとMSはその点を熟知しており、ルールを変えようとするここ試みがあった。
この点に気が付いたものは少ないだろう。
そして試みは打倒された。
なぜそのような事が起こるのか。
それは銃を売るものも必要、そしてほとんどのものは自分は打たれないと考えるからであろう。

**デフォルトの名無しさん** · 2018/03/12(月) 01:43:53.06

キミのシステムは危険だ！チュドーン。

**デフォルトの名無しさん** · 2018/03/12(月) 10:40:24.64

まぁ、nodeオンリーだと確かに辛いところは出てくるな。
JSでQRコードの画像作るロジックが言うほど重くないんだけどそれなりに時間かかる処理になってて、そのせいで全然パフォーマンス出ねえって思ったことある。
結局そこはGoで書いたQRコード作るだけのサーバにリクエストすることにした。
タイトなループが書けないは最初から考えとかないと辛い。

**デフォルトの名無しさん** · 2018/03/12(月) 11:00:05.16

>>313
QRコード画像を作る処理ですら重いんかnode.js。

**デフォルトの名無しさん** · 2018/03/12(月) 11:05:26.37

まあ、技術者にありがちな典型的な「やりたかっただけ」だろうな
自分が一番よく分かってると思うが、辛いと思い込もうとしてるだけで、もっとシンプルでメンテや運用コストの低い解決方法は間違いなくあったはず

**デフォルトの名無しさん** · 2018/03/12(月) 11:11:22.42

そもそもqr生成なんてクライアントでやれやｗ
https://www.cssscript.com/flexible-client-side-qr-code-generator/

**デフォルトの名無しさん** · 2018/03/12(月) 11:34:32.52

node_modulesの中を見るとゲロを吐きたくなる

**デフォルトの名無しさん** · 2018/03/12(月) 12:43:15.24

>>314
重くはないが、シングルスレッドなので詰まる。
cluster使ったところで、ワーカー数使い切る。
npmにモジュールあったから、へぇと思いながら使ったらこうなった感じ。
やりたかったからと言うより要件だったから、かな。

>>316
クライアントは台数凄いけど基本IE8のエンタープライズモードという悲しいイントラネットなのよ。
ブラウザは無力と思わないとどうにもならん。
そいつらがリアルタイム更新したいとかで、万台のlongpollをどう捌こうと言うところで白羽の矢がたった感じ。
それ自体は良かったよ。

node_modulesはせめて圧縮できないかねえと思ってしまう。

**デフォルトの名無しさん** · 2018/03/12(月) 20:08:05.60

>>318
ワーカー数使い切るってどういう事？
基本cpu数で回していくもんじゃないの？

**デフォルトの名無しさん** · 2018/03/12(月) 20:30:18.54

>>319
cpu数立てても、全部同じように同じタイトなループがあるハンドラで詰まって、結果フリーな子が居なくなるって意味のつもりだったよ。
外部へのioだったり、外部プロセスだったりと非同期で帰ってくるものを使わないと当たり前だけど意味無かった。
clusterも結局プロセス立ってるけど、そいつら自体はシングルスレッドだし。

**デフォルトの名無しさん** · 2018/03/12(月) 21:58:15.37

>>320
それってつまり実装の問題ってことか。
現在はasync-awaitを使えるから非同期処理もだいぶ書きやすくなったし、結果は変わってきそう。

**デフォルトの名無しさん** · 2018/03/12(月) 22:03:20.44

>>316
IE8でもbabelとか使えばクライアントサイドで行けたんじゃないのかな

**デフォルトの名無しさん** · 2018/03/12(月) 22:18:38.74

babelは嫌いなのと、そもそも保証がしにくいのと、ポリフィルまみれになってパフォーマンスがゴミレベルになる。
エンタープライズモードはちょっと理解できないレベルに落とされてたりするし。
console.logが無いってどういう事？ってレベル。

**デフォルトの名無しさん** · 2018/03/12(月) 22:30:10.56

console.log無いとかひどいなｗ

**デフォルトの名無しさん** · 2018/03/13(火) 01:11:16.42

しかしグーグルさんもkotrinに肩入れしたりdart2出したり、どうしたいのかね？

**デフォルトの名無しさん** · 2018/03/13(火) 01:43:11.12

Googleに開発環境や言語のセンスが絶望的に無くて常に迷走してるのは今に始まったことじゃないでしょ
ビジネスを理解してるMSやAmazonにはどうやっても勝てんよ

**デフォルトの名無しさん** · 2018/03/13(火) 02:39:23.57

PythonのライブラリはC言語とOSのセンスを踏襲することが多い
一方JavaやJavaScriptのセンスはSmalltalkの影響が微レ存

**デフォルトの名無しさん** · 2018/03/13(火) 08:37:52.99

googleの社員は皆思い思いに、プロジェクトを進めてる感じ。
でも結果的に技術的多様生が有効に働いてる。chromeがあるからインターネットプロトコルまで手を入れることが可能になったし。
appleはいずれ終わるけどgoogleは底が見えないよね。

**デフォルトの名無しさん** · 2018/03/13(火) 09:43:42.39

【イーサリアム】Solidity本スレDAPPS】
https://mevius.5ch.net/test/read.cgi/tech/1520901794/

**デフォルトの名無しさん** · 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棒で叩くのは危ない