次世代言語10[Rust Swift TypeScript Dart]

**デフォルトの名無しさん** · 2018/04/25(水) 07:02:27.60

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2018/05/05(土) 22:28:11.15

>>423
哀れな水子霊
供養してあげよう

**デフォルトの名無しさん** · 2018/05/06(日) 11:13:25.80

>>420
半分だけはその通り。
ただセキュリティーについても結局は効率や速度を要求されるからって話なんだよ。
安全のためにって効率を落とすようなルールを作っておいて
ノルマは下げないみたいな現場ではセキュリティーホールつくようなハックが流行るってこと。
ルールを厳しくして逆に流出なんてパターンは結局これ。

**デフォルトの名無しさん** · 2018/05/06(日) 11:29:16.72

悪事の限りを尽くしてきたサイコパスが
効率悪化だけは許さない真面目キャラになるのなんでだろう

**デフォルトの名無しさん** · 2018/05/06(日) 12:54:13.10

安全性重視と言えば聞こえはいいが
やってることはWarningをErrorにしてるだけだからな

**デフォルトの名無しさん** · 2018/05/06(日) 13:00:40.56

>>427
明確にエラーなら、それを前提にした最適化ができる

**デフォルトの名無しさん** · 2018/05/06(日) 13:12:21.81

まあ正直Worningでいいとは思う

**デフォルトの名無しさん** · 2018/05/06(日) 13:18:55.75

>>425
unsafeなりなんなりあるかと。
効率や速度というのは、安定動作している事が確実に出来てからやっとテーブルに上げることができる話題であって、
それで落ちる効率なんてのは最初からサボってた証拠とみなす方が多いかと思うよ。

ルールを厳しくして結局流出ってのは、また別の尺度かと。
流出したとしても、それは理由もはっきりさせられるし、なによりソフトウエアの瑕疵ではなくて運用の問題の話になってくる。

**デフォルトの名無しさん** · 2018/05/06(日) 14:32:39.98

セキュリティーについての効率化云々とか、半可通だなあとしか言えんわ…

**デフォルトの名無しさん** · 2018/05/06(日) 15:54:07.22

レイヤの上書きし続けるのやめろ

**デフォルトの名無しさん** · 2018/05/06(日) 15:58:41.42

いくらコンパイラが怒らないからと言え、セキュリティーホールを突くようなハックとやらをしてたら流石にコードレビューではねるんじゃね？
どういうコードかイマイチ想像がついてないけど。
インラインアセンブラが禁止されてるからハンドアセンブルしたコードか入ってるconst char[]を無理矢理呼び出すとかかな。

単純にそのプロジェクトで使ってる静的解析が誤認するようにコードを書く事を、静的解析のセキュリティーホールと勘違いしてるのか、
それとも、バッファオーバーランしないようにするにあたって、根本的に長さを指定できる関数を使わずに付け焼き刃でバッファにクソ長い配列使うみたいなコードなのか(でもこれは静的解析で怒られそう)

一体何が、コーディングの上でセキュリティーホールを突くようなハックなんだろう？
ピアレビューがあれば瞬殺されて終わりな気もするし。

**デフォルトの名無しさん** · 2018/05/06(日) 16:29:24.39

>>421
Fortranって現役なんか？聞いたことないが

**デフォルトの名無しさん** · 2018/05/06(日) 16:32:16.64

>>434
現役だよ

**デフォルトの名無しさん** · 2018/05/06(日) 16:36:08.57

スパコンでは現役。計算物理屋とかFORTRANしか書けないおっさんも居るしね。
まあ数値計算系のコード書いてる連中なんてgitも知らなかったりするレベルで
超絶的に遅れてるから意見なんて無視していいよ

**デフォルトの名無しさん** · 2018/05/06(日) 16:41:56.05

>>434
現役かと言われたら、現状数値解析以外では老害しか使っとらん感じで口ごもっちゃうけど、そんな状況に反して最新の言語仕様は結構いい。そして老害はFortranの良い仕様は使っとらん
ある意味逆に次世代言語感あると思う

**デフォルトの名無しさん** · 2018/05/06(日) 17:13:53.77

ベンダーがきっちり面倒見てるのも大きいわな。Fortranは。
老害と呼ばれるコードが生き残れるのも、新しいものがサポートされていくのも。

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

まあ新しいもののサポートは遅いがな

**デフォルトの名無しさん** · 2018/05/06(日) 18:53:07.67

まあ運用の問題と言えばそうだけどね。
実際どこぞのrustコードなんて結局unsafe丸がこみコードになってるって話だよ。
レビュアーがまともならってのもその通りだが
P○zyさんとことか有名どこでもそんなもんですよ。

**デフォルトの名無しさん** · 2018/05/06(日) 19:31:39.25

}]] [[《_["[[]]" 〈[]》》 [][][]0,1》》〈〉 [] } } "B,V,0%%%,*1BVLO,SASA1`}}//%\\0,1\"VL"\

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

>>440
そのP○zyさんのコードはどこで見れるの？

**デフォルトの名無しさん** · 2018/05/07(月) 17:37:45.62

Fortran現役ってすげーな。
なんか便利な構文あるの？
スペースがなくても構文が認識するって凄いね。何というか分野によって現役だったりするし、web系とか組み込み系とか分野毎に次世代を考えたほうが良いのかも

**デフォルトの名無しさん** · 2018/05/07(月) 18:29:43.67

数値計算の新しいアルゴリズムってあるの？

動画の圧縮とかだったらどんどん新しくなってるけど

**デフォルトの名無しさん** · 2018/05/07(月) 18:42:27.46

アルゴリズムというよりは非プログラマが数学物理をプログラムに落とし込みやすいって所じゃないか？
統計メインの生物系なんかはもうRやPythonに移ってるけど

**デフォルトの名無しさん** · 2018/05/07(月) 21:30:21.40

>>443
まあ、分野についての言及は必要だろうね。

**デフォルトの名無しさん** · 2018/05/07(月) 22:27:02.76

よし、じゃあワシがwebの代表として次世代言語はrustであることをここに宣言しよう

**デフォルトの名無しさん** · 2018/05/07(月) 23:32:28.33

今phpのlaravelしててミドルウェアとかバリデーションとかルーターとかマイグレーションとか
それ自体はフレームワークの機能なんだけど言語仕様としても使えそうなのがチラホラあるけど
こういうの言語に使われることないんかな？

**デフォルトの名無しさん** · 2018/05/07(月) 23:45:44.05

>442
はいよ
http://tanakh.jp/posts/2016-12-20-rust-pezy-sc.html

**デフォルトの名無しさん** · 2018/05/08(火) 00:32:28.71

一元論が無理なら八百万って極端すぎる
二刀流くらいがちょうどいい

**デフォルトの名無しさん** · 2018/05/08(火) 07:49:53.07

C++の置き換え言語としてRustには期待している。ただ構文がなんかうっとうしいなあ。
ruby風のラムダは気に入ってるが。

**デフォルトの名無しさん** · 2018/05/08(火) 08:43:30.21

>>445
Numpy相当のベクトル記述が出来るたった一つのコンパイル言語。それがFortran

**デフォルトの名無しさん** · 2018/05/08(火) 10:01:01.47

>>452
確かにあれは書きやすいし速い
GPGPUでの(それをラップしたライブラリでの)行列演算に対するアドバンテージって何かあるのか？
分岐がモリモリ入ってくる場合くらいしか思いつかないが

**デフォルトの名無しさん** · 2018/05/08(火) 13:34:11.30

>>453
なんのことを指しているんだ？

**デフォルトの名無しさん** · 2018/05/08(火) 17:08:07.13

>>452
現実のFortranプログラミングは大量に宣言したスカラー配列を添字でゴリゴリ回すだけだけどな
行列やベクトルの演算のセマンティクスなんか一切残らん

**デフォルトの名無しさん** · 2018/05/09(水) 01:16:05.28

haskellの方がCより速いってさ

https://superstrings.io/once-more-on-haskell-vs-c-performance-a54498bfa91

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

>>456
https://superstrings.io/once-more-on-haskell-vs-c-performance-a54498bfa91f

**デフォルトの名無しさん** · 2018/05/09(水) 02:26:18.12

なんですぐばれるウソをつくのだろう？

**デフォルトの名無しさん** · 2018/05/09(水) 02:35:21.53

>>457
すばらしいね。
Cのコードに
__attribute__((optimize("unroll-loops")))
付けると100倍早いけどw
あと、手元の環境で gcc は何故か -O だけunroll付けたのと同様に早くて　-O2 以上は遅かった。
バグと言うべきなのかな。

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

>>453
コンパイラのやる気さえあれば、ライブラリでは不可能な最適化なんていくらでもでできるだろ
実際にやってるかはしらん

**デフォルトの名無しさん** · 2018/05/09(水) 07:10:29.94

乱数生成が遅いってどこかで見たような、Haskell

**デフォルトの名無しさん** · 2018/05/09(水) 07:59:31.19

>>461
それって言語の問題ではなくコンパイラの実装の問題？
それとも言語仕様として計算量の大きい生成アルゴリズムが規定されてたりするんだっけ？

**デフォルトの名無しさん** · 2018/05/09(水) 08:01:55.30

あ、ごめん。ライブラリの乱数生成の関数を呼んだらということかと思ったけど、自分で乱数生成の処理を書いたらということかな。

**デフォルトの名無しさん** · 2018/05/09(水) 08:15:55.42

>>463
ごめん、そこまで詳しくないので、誰か補足を。記憶だと前者だったかな。

**デフォルトの名無しさん** · 2018/05/09(水) 08:17:13.45

https://qiita.com/philopon/items/8f647fc8dafe66b7381b

この辺の話？

**デフォルトの名無しさん** · 2018/05/09(水) 09:54:11.86

>>458
せっかくコンパイラ作ったんだからみたいな貧乏性だな
一方、富豪的プログラマはインタプリタを使う

**デフォルトの名無しさん** · 2018/05/09(水) 21:36:31.89

なんか知らんが定期的にCより速いって話が出てくるな。
高級かつランタイム速度が落ちないってなんかおかしいとか思わないもんなのかな。

**デフォルトの名無しさん** · 2018/05/09(水) 22:20:41.60

さ、最適化をダイナミックに出来るから……

**デフォルトの名無しさん** · 2018/05/09(水) 23:00:53.08

理想を追求する精神は忘れなくて良いやろ

**デフォルトの名無しさん** · 2018/05/10(木) 02:12:17.66

高級品だと遅くなるならC++がCより速くなることはないんだろうなあ
フムフム

**デフォルトの名無しさん** · 2018/05/10(木) 08:10:24.35

実際、もしもコードを書く人がコンパイラを書いた人よりも賢いならばCの方が早速いｗｗ

**デフォルトの名無しさん** · 2018/05/10(木) 09:54:42.57

コンパイラの最適化能力的には今でもFortranが頭ひとつ抜けてるんだっけ

**デフォルトの名無しさん** · 2018/05/10(木) 10:07:40.42

async awaitの存在のお陰でTypeScriptが使いやすさで一歩先言ってる感あるな。
VasualStudioでもサポートしてるんだよね。mac版試してみたい

**デフォルトの名無しさん** · 2018/05/10(木) 15:49:44.61

>>472
どうせバックエンド同じなので、C言語でもpragmaとattribute駆使すればFortranと同じになるはず

**デフォルトの名無しさん** · 2018/05/10(木) 16:11:32.31

>>474
しんどー

**デフォルトの名無しさん** · 2018/05/10(木) 16:20:28.17

rebuildfmで聞いたがswiftは機械学習との親和性を高める方向でラトナーは頑張ってるみたいね。

**デフォルトの名無しさん** · 2018/05/11(金) 00:25:42.85

にむにむ

**デフォルトの名無しさん** · 2018/05/11(金) 11:38:41.21

フォートランはスタックフレームを使わないから早いらしい

**デフォルトの名無しさん** · 2018/05/11(金) 19:21:18.09

>>467
昔々 Java の方が C++ より速いなんて話もあった。
JIT で速くなるとか。

しかしC++だったとしてもややこしい機能を使わずC言語風に作って最適化掛かったらお終いのような気がしてならない。

**デフォルトの名無しさん** · 2018/05/11(金) 20:24:29.02

Cはポインタが自由すぎて最適化難しいとはよく聞く

**デフォルトの名無しさん** · 2018/05/11(金) 21:16:38.36

Javaの場合はいくら局所的に速くなっても、JITそのものにかかる時間だったり
あるいは膨大なロード時間を計測に含めてしまうと台無しだからなあ
もちろん速いとアピールしたいベンチマークではその辺が含まれないようにするし
遅いとアピールしたい場合は

**デフォルトの名無しさん** · 2018/05/11(金) 21:22:37.76

どっちかというとマルチコアを活かした最適化って人間が頑張るしかないんじゃないかな。
だからgoでgoroutineとか、
関数型言語推しになるんでわ

**デフォルトの名無しさん** · 2018/05/11(金) 21:41:43.97

>>481
javaに限らずインタプリタ系も起動時間含めて time で測ってドヤってる　Qiita の記事とか消滅して欲しい

**デフォルトの名無しさん** · 2018/05/11(金) 21:43:50.20

>>480
ポインタをintやchar*に変換する自由を利用してFFIのようなものを作れるよ
自由にCを呼び出すことで他言語が速くなる

**デフォルトの名無しさん** · 2018/05/11(金) 22:13:19.06

>>484
なぜその内容で>>480に安価つけるし

**デフォルトの名無しさん** · 2018/05/11(金) 23:06:50.43

>>485
内容に問題はないので、わからないなら自分で考えるか質問を変えてみてはどうかな

**デフォルトの名無しさん** · 2018/05/11(金) 23:15:21.11

>>484の意図(自由過ぎるポインタにはメリットもあるよ)もわかるし
>>485の反応(最適化の話題から逸れてるだろ)もわかるんだけど
正直>>486はぞっとするほど怖い。なんだろうこの不気味な感じは

**デフォルトの名無しさん** · 2018/05/11(金) 23:16:13.67

なんやこいつ。
まあええわこのスレには会話通じんやつがおるみたいやし時間の無駄やわ。深く考えんとこ

**デフォルトの名無しさん** · 2018/05/11(金) 23:19:46.30

>>487
>>484からその意図を読み取れるのはすげー行間把握力だと思うわ
>>486が怖いのは同意

**デフォルトの名無しさん** · 2018/05/11(金) 23:20:50.68

「不気味罪という罪はない」とか言われたらゾッとするかもしれないが
そういうことを平気で言う奴は今の世の中にはいっぱいいるな

**デフォルトの名無しさん** · 2018/05/11(金) 23:24:44.89

この感じどうせまた例のADHDやろ。つついてもうたことを後悔してるわ

**デフォルトの名無しさん** · 2018/05/11(金) 23:25:19.88

>>480

**デフォルトの名無しさん** · 2018/05/11(金) 23:30:08.91

>>480 はコンパイラの最適化を受けての発言でいわゆるaliasの問題の
ことを言っていると思われる
で >>484 はコンパイラ関係ないFFIを持ち出してしったかをかます
で >>485 がもっともなツッコミ
で >>486 で上から目線で地面見てドやる

→キモイ

まとめてみました

**デフォルトの名無しさん** · 2018/05/12(土) 00:31:38.38

C / C++ はとりあえず OpenMP 相当のものを標準化して実装して欲しいわ
他の言語よりクライアント側で使うこと多いから１つ１つの処理もスケールさせたい

**デフォルトの名無しさん** · 2018/05/12(土) 00:39:55.31

アルゴリズム変える以外に速くする方法なんてのは
結局倉庫番を上手く解くって話にしかならんわ。

**デフォルトの名無しさん** · 2018/05/12(土) 00:48:56.95

？？
それアルゴリズムでは？

**デフォルトの名無しさん** · 2018/05/12(土) 00:52:27.47

あーもうめちゃくちゃだよ

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

なんかgoogle ioでwasmからdom操作できるようになるって話があったらしい。

**デフォルトの名無しさん** · 2018/05/12(土) 01:04:46.62

地獄の始まりじゃないでしょうね（震え）

**デフォルトの名無しさん** · 2018/05/12(土) 01:13:51.18

みんなアルゴリズムよりむしろデータ構造を変えたがる
CのポインタもJSのdomもデータ構造だろう
でもデータ構造を変えるのは速くするのが目的とは言ってないかも

**デフォルトの名無しさん** · 2018/05/12(土) 01:38:25.14

>>457
>On Xeon Thinkpad P50 with Ubuntu, compiled with gcc -O3 this runs about 15.3 ms ― more than 20% slower than haskell!

あんまり関係ないが
3年前のレッツノートRZ4の最下位モデル、
Core M-5Y10 ベースクロック0.8GHz で
Visual Srudio 2017 でコンパイルしたバイナリも
ちょうど 15.3ms だわ

2コア4スレッドのcpuなので openmp で 4並列にしたら5.7ms

**デフォルトの名無しさん** · 2018/05/12(土) 08:55:56.45

>>496
いやメモリやレジスタにデータやコードを載せるタイミングの話なんだが。
「アルゴリズム」はもう少しソフトなレイヤーを指したつもり。

**デフォルトの名無しさん** · 2018/05/12(土) 10:24:39.71

>>501
最適化上手く行けば0.2ｍｓぐらいになると思うで
i5-3550 で 0.08ms

**デフォルトの名無しさん** · 2018/05/12(土) 10:28:01.57

>>498
reactが早くなるってか。
ようやく90年代のクラサバに追いつくなw

**デフォルトの名無しさん** · 2018/05/12(土) 10:32:35.98

GoogleはSUNと同じ愚を犯してるように見える。

**デフォルトの名無しさん** · 2018/05/12(土) 10:34:13.54

wasmのDOM実装は最初からロードマップに入ってる

**デフォルトの名無しさん** · 2018/05/12(土) 10:46:00.14

jsの出番が減るのか最近の仕様は好きなんだけどな。typescriptが直接wasm吐くようになってほしい

**デフォルトの名無しさん** · 2018/05/12(土) 10:47:42.87

>>505
sunはコンテナーをいち早く実現してたり
zfs出したり、先進的な企業だったよな。金が稼げなかったけど。
googleは金があるから問題ない

**デフォルトの名無しさん** · 2018/05/12(土) 10:52:24.71

>>507
Blazorに期待してる

**デフォルトの名無しさん** · 2018/05/12(土) 10:55:45.44

JavaScriptからwasmへのコンパイルができるようになったら普及は速いんだろうけど、いつになるかなぁ。
そのころにはwasmのエコシステムも十分整備されてそう。

**デフォルトの名無しさん** · 2018/05/12(土) 11:01:20.26

>>507
各種apiのリファレンス実装として続いてくんじゃないかとは思ってる
正直TS→wasmは期待しちゃうよね

**デフォルトの名無しさん** · 2018/05/12(土) 11:13:10.47

rustでwasm吐くとdom操作もメモリ効率が良い感じになるのだろうか。
個人的にはgoで全部できるようになりそうで嬉しい。

meteor.jsというのがあってね。コンセプト的にすごく良かったんだけどエコシステムがいろいろ終わってた。wasmでもう一度復活するかも

**デフォルトの名無しさん** · 2018/05/12(土) 11:31:33.64

Rustでブラウザ本体を書き直す動きがJSの部分にまで広がる
ブラウザを作れない言語には速い遅いという以前の問題がある

**デフォルトの名無しさん** · 2018/05/12(土) 13:14:14.79

>>508
思い出は美化されるね。
不便なコマンド、SysV系転向、長いことジャーナリング無し、ftpのlsがユーザのロケールでパース困難、NFSの進歩の遅さ、etc
罪を数えたらキリが無いよ

**デフォルトの名無しさん** · 2018/05/12(土) 13:53:25.93

>>491
なんでも俺のせいにすなw

**デフォルトの名無しさん** · 2018/05/12(土) 14:06:23.00

よかった、透視能力なんてなかったんだ

**デフォルトの名無しさん** · 2018/05/12(土) 14:10:21.47

>>508
SUNは我田引水に失敗して凋落したのだ。
自社の高価な機器を売るためにメモリーイーターな言語を広めたり、自社の機器以外では性能が発揮できないように互換環境を禁止したり。

**デフォルトの名無しさん** · 2018/05/12(土) 14:13:17.43

Googleは現在我田引水のため色々やってるが、消費者にとっては良いことは何もない。
吉と出るか凶と出るか。
一方、MSは戦場から早々に離脱したので、不戦敗となるのか、勝ちもしないが負けもしないのか。

**デフォルトの名無しさん** · 2018/05/12(土) 17:45:08.76

>>503
dot関数自体の最適化はほぼ完璧に行われています
gcc だと 100 回繰り返してるところを1度で済ます
最適化が起きてるだけでは？
速度もちょうど100倍だし。

そうじゃないと
>i5-3550 で 0.08ms

1G回の積和を0.08msで完了ということは毎秒125Gの積和を実行したことになりますから、
演算性能は125GFlopsメモリ帯域は1000GB/sになる (←あり得ない)

**デフォルトの名無しさん** · 2018/05/12(土) 17:51:25.31

最後の計算間違ってるか
結果はあってるけど10M個の積和を0.08ms、という計算か。

**デフォルトの名無しさん** · 2018/05/12(土) 18:44:38.63

>>519
ああ、確かに。引数変わらないから１００回ループが１回に省略されてるな…

**デフォルトの名無しさん** · 2018/05/13(日) 08:36:01.91

Cはハスケルの１００倍はやかったってこと？

**デフォルトの名無しさん** · 2018/05/13(日) 11:23:16.33

GCのベンチマークって無いのかな
一番速いのはGo言語？