次世代言語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/01(火) 15:26:12.15

つまり、書かないとボローチェッカを満たせないというのももちろん理由の一つだけど
実行時のコストを可視化するという意味でも書いておいたほうがいいというわけ
Rustは実行速度が速くないといけない言語なんでね

**デフォルトの名無しさん** · 2018/05/01(火) 15:53:34.08

2種類のコストの概念を学習するのが面倒臭い
だから色々なコストを無視して作ったフリーソフトが無双してるんだと思う

**デフォルトの名無しさん** · 2018/05/01(火) 19:39:03.13

リスト内包表記が読みにくいって人たまに見かけるけど、このスレにもおる？

**デフォルトの名無しさん** · 2018/05/01(火) 19:42:50.63

Haskellのリスト内包表記がモナドと知った時の衝撃
まあ3項演算子と同じで慣れよね

**デフォルトの名無しさん** · 2018/05/01(火) 19:49:54.02

doといい、内包表記といい、全部ちゃんと何かのシンタックスシュガーになっているのには恐れ入るわ
ユーザーからしてみればそこまでしてもらわなくてもいいっちゃいいもん。
開発側の強い拘りを感じて好きだわ

**デフォルトの名無しさん** · 2018/05/01(火) 19:52:14.09

Fortranのあれは内包表記と扱って良いものか悩む

**デフォルトの名無しさん** · 2018/05/01(火) 20:23:57.89

RustはDみたいに.mapとか.filterとか繋げるのが主流かいな？

**デフォルトの名無しさん** · 2018/05/01(火) 20:31:00.33

拘りっつーか関数型言語なんでそりゃそう作るでしょうよ
適当に文法導入してそれが関数に還元できないものだったら理論破綻するじゃん

**デフォルトの名無しさん** · 2018/05/01(火) 20:37:38.61

そういえば純粋関数型だったな。Haskellは
純粋の意味を忘れておった

**デフォルトの名無しさん** · 2018/05/01(火) 20:45:19.66

>>319
Dはやったことないから知らんけど多分同じ
C#のLINQみたいな感じでメソッドチェーンする

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

>>322
Rustは速くなくっちゃいけないとの事だけど、それって速いの？

**デフォルトの名無しさん** · 2018/05/01(火) 21:29:57.85

早いの？ってなにに対して？

**デフォルトの名無しさん** · 2018/05/01(火) 21:35:11.22

>>324
ループで書いた場合

**デフォルトの名無しさん** · 2018/05/01(火) 21:42:41.95

ループってCのループ？

**デフォルトの名無しさん** · 2018/05/01(火) 21:55:33.38

>>326
え、rustのループとCのループって速度違うの！？
じ、じゃあCのループで

**デフォルトの名無しさん** · 2018/05/01(火) 22:04:27.49

rustのmap,filterとcで同等のことをするのは、真ん中とって同じくらい速いと考えてよろしいですよ

**デフォルトの名無しさん** · 2018/05/01(火) 22:07:47.19

おお、マジかすげー！！

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

でしょ、rustおススメさ

**デフォルトの名無しさん** · 2018/05/02(水) 00:38:20.18

rustは速さとモダンな記述のバランスが良い

**デフォルトの名無しさん** · 2018/05/02(水) 00:58:58.35

大変非本質的なことを書いて申し訳ないんだが、<>と::に拒否反応が出る。俺だけかな

**デフォルトの名無しさん** · 2018/05/02(水) 01:41:11.00

無茶苦茶な事敢えて言うがやっぱプログラミングするに至って世界に記号が足りない。だから2個記号を並べるというダメな記法になる
ついでにアルファベットも50個くらいにしてくれ

**デフォルトの名無しさん** · 2018/05/02(水) 01:45:52.01

やっぱりAPLって神だわ

**デフォルトの名無しさん** · 2018/05/02(水) 01:47:50.27

Vimでなんかのプラグイン入れてhaskell書いてたらラムダ式のバックスラッシュをλに変えられて草生えた

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

>>333
Juliaみたいにユニコード完全対応するとギリシャ文字を変数に使えたりするが
いまいち流行りそうな感じがしない

**デフォルトの名無しさん** · 2018/05/02(水) 10:25:48.10

変数とかじゃなくて記号としてだろ

λとか { (x,y) | x ∈ R, y ∈ R } とかアリではあるのだろうけど入力面倒そうでもある。
Int や Real を意味する派手な(縦線が二本線)大文字の I や R も欲しい

**デフォルトの名無しさん** · 2018/05/02(水) 10:53:03.53

Agdaとかその辺徹底してる。

作者自身が教えてる動画で、その記号どうやって打つのて何度も聞かれてて、
最後は何でユニコードにするの？て聞かれて、だってそっちの方が美しいじゃん？て答えて失笑されてた。
めんどくせ、こりゃ流行らんわと思ったけど、慣れると\より\lambdaて打ちたくなる不思議。

**デフォルトの名無しさん** · 2018/05/02(水) 11:41:13.27

中置の二項演算ができたら記号は何でもいい
他には分数のように縦に並べたい

**デフォルトの名無しさん** · 2018/05/02(水) 17:37:54.83

欧米の人たちは∈∧∋とかどうやって入力してるんだろう？

**デフォルトの名無しさん** · 2018/05/02(水) 17:37:57.52

>>337
わかる

**デフォルトの名無しさん** · 2018/05/02(水) 18:15:31.48

Unicode打ち込むエディタとして、Junoは良く出来てる

**デフォルトの名無しさん** · 2018/05/02(水) 18:41:04.95

そんなクソ機能、バグを生み出す元でしかないわ。

**デフォルトの名無しさん** · 2018/05/02(水) 20:25:38.31

>>339
Vimで表現出来なそうでつらみ

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

RAIIとGCってどっちがパフォーマンス優れているの？直感としてはGCの方が効率良さそうに感じるんだけど

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

感じるならしょうがないけど
GCは解放していいオブジェクトがどうか判定しなきゃいけないけど
RAIIだと不要だよね

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

究極的には圧倒的にGC
GCはメモリの再配置が可能という極めて大きな最適化の自由度があるからね

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

>>346
RAIIで面倒見きれるような単寿命のオブジェクトはほとんどGCのコスト無いんだぜ

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

再配置できるのはメモリアドレスを抽象化してる場合でしょ
GCとは直接関係ない

◆QZaw55cn4c · 2018/05/03(木) 01:14:39.15

>>347
メモリの再配置なんて、C++ に慣れた身からみると、いかにもにコストが高そうだが…

>>349
その「メモリアドレス抽象化」はアプリケーションに益をもたらす性質があるのでしょうか？

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

>>348
RAIIが短寿命？
関数スコープのスタックにオブジェクトを置くだけがRAIIじゃないよ
どっちにせよ同じ条件でRAIIより速くはならんでしょ

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

解放のコストもさることながら、確保のコストが気になります

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

>>350
やっぱり第一にメモリコンパクションじゃない？
アクセス透過性みたいなのも原理的にはできるだろうけどプログラミング言語レベルで
そういうの実現してるのはなさそう

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

>>352
気になるんならしかたないけど
確保はほぼ違いがないよね

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

補足すると
GC言語はヒープを多用する傾向はあるけど
そういう場合スレッドローカルなヒープだったりするからね

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

>>355
スレッドローカルなヒープってどういうこと？
普通のヒープ(Cのmallocとか)とどう違うん？

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

>>356
あるスレッド専用のヒープってこと
そのスレッドしか使わないから排他処理がいらないので速い
スタック確保とそれほど差がつかない
cでもglibcとかだとスレッドローカルをミックスして使ってたと思う確か

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

RAIIを徹底したらスタックでメモリ管理出来るようになったりするんだろうか？

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

>>357
すまん。また質問なんだが、
ミックスして使ってるってどう言うこと？
それとRustのjemallocとかだとまたglibcと違う動きをするの？
取り敢えずjemallocの方が速いらしいぐらいしか知らないんだけど…

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

ごめん。意味が伝わりにくい書き方をした。
ミックスして使ってるって言ってもglibcは一体どうやって
スレッドローカルなヒープとそうでないヒープの区別をしてるの？

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

>>359
うろ覚えなんで間違えてたらすまんだけど、
最初は普通にグローバルヒープひとつではじまる
普通に各スレッドがロックをとってメモリをとってくるんだけど
もしロックがとれない状況になるとスレッドローカルなヒープを
作成するとかだったと思う
どっかに詳しく説明してるスライドショーがあるはず

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

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