次世代言語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/03(木) 02:21:14.79

>>361
ありがとう。
出来ればそのスライドとやらのリンクを貼ってくると助かる。
もう覚えてないってんならしょうがないけど…

**デフォルトの名無しさん** · 2018/05/03(木) 02:34:51.07

あった
mallocの旅(glibc編)

**デフォルトの名無しさん** · 2018/05/03(木) 02:49:34.78

>>363
ありがとう

**デフォルトの名無しさん** · 2018/05/03(木) 09:06:54.27

dockerがgoで実装して十分パフォーマンス発揮してる時点で
組み込みレベルでないならそこまでGCいらんことは示されただろう。

**デフォルトの名無しさん** · 2018/05/03(木) 09:30:32.45

GCはあっても無くてもいいけど
スタックかヒープかくらいは選ばせて欲しい

**デフォルトの名無しさん** · 2018/05/03(木) 09:51:10.41

正直なところ、カスがGCなし言語で書いたものより、適当にGCあり言語で書いたもののが
ランタイム速度も速いでしょ。
バカがクソみたいな議論してる間にgoのGCの性能上げてたgoogleは正解だよ。

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

仮にDockerがPythonで実装されていたらやはりパフォーマンス足りなかったんだろうか？

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

>>351
スタックベースじゃないRAIIはメモリの断片化の原因になるぞ

**デフォルトの名無しさん** · 2018/05/03(木) 11:00:48.14

1. 性能が足りないとクレーム
2. 厳しいノルマ
3. データ改竄
4. 1のクレームがぴたりと止む

こういう事案なら1から4まで全員怪しいよね

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

https://www.google.co.jp/amp/ascii.jp/elem/000/001/496/1496211/amp/

**デフォルトの名無しさん** · 2018/05/03(木) 13:26:06.53

firacodeにカスタマイズ機能つければいいのか

**デフォルトの名無しさん** · 2018/05/03(木) 13:46:19.78

dockerで示されるパフォーマンスなんかないだろ

**デフォルトの名無しさん** · 2018/05/03(木) 14:20:45.28

パフォーマンスにちょっと興味を持つだけで怪しい奴らが集まってくる
Pythonのようにパフォーマンスに完璧に無関心にならないとすぐ腐敗する

**デフォルトの名無しさん** · 2018/05/03(木) 14:35:25.51

ボトルネックだけCythonとかでなんとかするスタイルはやはり正しかったということか

**デフォルトの名無しさん** · 2018/05/03(木) 14:43:47.18

そもそもRAIIはパフォーマンスのためのものじゃないだろ

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

dockerって正気か？動作中は何もしてないぞ？
# go のGCが優秀になったのは認める

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

なぜgoのGCだけを改善するの？
全てのGCを平等に改善しないとダブスタだと叩かれるかもしれないよ

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

どういう意味だ？

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

>>378の他のレスも含めて何言ってるのか分からないものばかりだから、考えても無駄かと思うよ

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

解説は詩を殺す

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

goのGCと同じものをC++で実装できないのかな
C++のGCが優秀にならないかな
そういう意味

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

やっぱり意味わからん。
その場合の主語は誰よ？

**デフォルトの名無しさん** · 2018/05/03(木) 23:47:35.35

>>382
C++のGCって一体なにを指しているのだろう。

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

やっぱここにいる奴は馬鹿ばっかりなんだな。

**デフォルトの名無しさん** · 2018/05/04(金) 00:17:24.19

C++のGC……？

**デフォルトの名無しさん** · 2018/05/04(金) 00:21:24.66

>>383
次世代の誰かだろ
正確な予知はできない

**デフォルトの名無しさん** · 2018/05/04(金) 00:51:59.59

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

**デフォルトの名無しさん** · 2018/05/04(金) 01:35:42.99

一方賢い俺はだいぶ前にNGした

**デフォルトの名無しさん** · 2018/05/04(金) 05:56:35.74

C++でGCとか言うとバットマンのコスプレしたハーブ・サッターにビンタされるらしいぞ

**デフォルトの名無しさん** · 2018/05/04(金) 06:17:07.59

きっとスマートポインタなんかじゃやだもんって意味かと思いました。

**デフォルトの名無しさん** · 2018/05/04(金) 10:09:56.44

極めて大きな最適化の自由度とはなんだったのか

**デフォルトの名無しさん** · 2018/05/04(金) 10:34:38.24

>>392
メモリアドレスが抽象化されてれば、実行時の状況や統計情報に基づいたメモリレイアウトの最適化ができるね
理論的には、一緒に使われるものをメモリ上で近くに置いたりしてキャッシュヒット率を上げたりできる

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

>>393
それは抽象データ型を定義できる言語ならどれでも可能か
それともC++やRustでは不可能か
これが問題だ

**デフォルトの名無しさん** · 2018/05/04(金) 14:10:07.69

この知ったかぶり
抽象データ型なんか関係ないだろ

**デフォルトの名無しさん** · 2018/05/04(金) 15:02:25.96

>>393
ってもそれ空理空論であって、
x[i,j,k] みたいな配列のメモリレイアウトをアクセスパターンから
決めるという単純な処理ですらどの処理系にも実装の予定すらないだろう

「c/c++では有能なプログラマがちゃんと判断して書くから最適な結果が得られる可能性が高い」
という言説の方がまだ現実的

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

>>396
単純に隙間を詰めるだけなら普通にやってるし、それだけでもメモリのアクセス効率や利用効率は改善するよ

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

>>397
それアクセスパターンと関係ないでしょ
話通じてないな

**デフォルトの名無しさん** · 2018/05/04(金) 15:09:57.46

アクセスパターンからの最適化というのは、

巨大な配列だけどアクセスされるのはごく一部
→スパース配列を用いる

2次元で同じyについて近しいxで連続してアクセスされることが多い
→ cでいう v[y][x] というように同じy座標のものを連続して並べる

こういうこと

**デフォルトの名無しさん** · 2018/05/04(金) 15:12:34.97

実装が隠蔽されていればそういう最適化の自動化が可能だという>>393に対して、
それはそうだが絵に描いた餅過ぎると否定的なことを言ったのが>>396
以上

**デフォルトの名無しさん** · 2018/05/04(金) 15:24:22.35

ヒープの話から来てるからあくまでメモリアロケートした単位での最適化と考えるべきでしょ
話を拡大解釈して通じてないのはお前だと思う

**デフォルトの名無しさん** · 2018/05/04(金) 15:40:45.66

>>401
393をそう読むのなら話通じないな
別にお前が無違ってると主張する気は無いよ
思想と言論の自由は認めるから黙れとも言わないし

**デフォルトの名無しさん** · 2018/05/04(金) 15:45:30.86

あ、いや俺が間違ってる気がしてきた
コンパクションで並べるとかいう話か

それでもやっぱり
>>396
＞「c/c++では有能なプログラマがちゃんと判断して書くから最適な結果が得られる可能性が高い」
＞という言説の方がまだ現実的

だと思う

**デフォルトの名無しさん** · 2018/05/04(金) 17:35:05.26

で、有能なC++プログラマはヒープの断片化をどうやって回避するの？
一般的な回避策としてはまとめて静的に確保するわけだけど、それだとRAII的な方法論を否定してることになるよね

**デフォルトの名無しさん** · 2018/05/04(金) 17:41:04.90

生ポインタをprivateメンバーにすれば再配置できるんだろ

**デフォルトの名無しさん** · 2018/05/04(金) 18:45:44.08

そもそもRAIIを肯定するのも否定するのもC++プログラマの自由だ
この自由を尊重すれば、極めて大きな最適化の自由度はC++にもあるんじゃないか
自由を奪ったら最適化の自由度もなくなるのは当たり前だ

**デフォルトの名無しさん** · 2018/05/04(金) 18:55:41.39

C++は何も縛らないからなんでも出来る理論本当に嫌い

**デフォルトの名無しさん** · 2018/05/04(金) 19:00:50.09

縛ったほうが最適化の自由度は上がる
C/C++はポインタのせいで配列アクセスの並列化がやりづらいのは有名な話だ

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

>>407
じゃあ逆の理論はなんなの
一長一短理論
どっちもどっち理論かね

**デフォルトの名無しさん** · 2018/05/04(金) 19:12:50.22

>>409
>>408

**デフォルトの名無しさん** · 2018/05/04(金) 19:24:33.12

GCは、あるプログラマにとっては仕事を単純にしてくれるが、別のプログラマにとっては仕事を複雑にする要因になるという特性があるんだよね

**デフォルトの名無しさん** · 2018/05/04(金) 20:34:01.38

>>411
プログラマに、というよりは作ろうとする対象によってではないかな。

**デフォルトの名無しさん** · 2018/05/04(金) 22:10:23.06

「設定より規約」で複雑な設定を不要にするために規約で縛って単純にすることはある
最適化とは関係ない

**デフォルトの名無しさん** · 2018/05/04(金) 22:27:54.24

>>413
全然レイヤが違うぞ…はぁ

**デフォルトの名無しさん** · 2018/05/04(金) 22:29:07.68

もういいや

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

>>414
全然違うレイヤでしか評価されない概念だからね

型宣言を省略して単純にした言語はあまり評価されない
だからC++のように複雑な言語がずっと勝ち続ける

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

言語レベルでは縛りを減らして、ツールもしくはプロジェクト毎の規約で矯正する方が成功してる印象。

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

Ruby使いはなんでもRails基準で話するから困惑させられるわ。

規約で縛るのと、設定させるのはまた別の次元の話な気がする。

規約で縛った上でさらに明示的に設定させるなんて思想もあるし、
明示的に設定すること、と言う一文すら大きく捉えたら「規約」だと思うんだが。

misra然り、規約で担保される部分も否定はしないけど、
そんなこと考えなくても言語レベルで無茶は出来ないってのは、結構有益だと思うよ。
goが他の言語だと警告で済ますものをコンパイルエラーにしてたりとか。

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

それはわかる。
ただ「言語レベルで無茶させない」機能を実装するために「言語実装が無茶してる」
っていう本末転倒レベルのコンパイラが増えてる。

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

何かを実装しやすくする為の機能、とバグを減らすための安全装置としての機能、と分類した時に後者が気に入らんて訳だな。
古いタイプのハカー思想的にはそうだろうね。
まあでも人間にコード書かせてる内は後者を充実させて行くしか無いでしょう。

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

バグを減らすための機能はコードを書きやすくするための機能でもあって欲しい。Fortranはその辺のバランス感覚が地味に良い

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

[][][] [[[ ] X_[[[ [] ][ [] ][][[[]

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

このスレ的にDart 2はどうなの？

**デフォルトの名無しさん** · 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