次世代言語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(火) 11:34:41.33

まあたしかにHaskellのHello worldなんて大した長さじゃないし、本の最初のほうに配置するべきよな
そして最初に配置している本は見たことがない。あるのか？

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

>>289
馴染みのある人間が　入門　を果たして読むのか。

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

Haskellの難易度はC++とほぼ同じと気付くまでにあと何年かかるかな

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

phpで並列処理が書きづらくて、goに触り始めて感動して。
ちょっと触ってみて使えるのを確認して、
goを本格的に触るようになった。
ちょっとしたモチベーションで気軽に始められる。
ローリスクハイリターンな感じ？

haskellとかrustに触るモチベーションって言語マニア以外は何があるかな？

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

>>290
関数型とはなんぞやをすっとばしても入出力を扱うには副作用・モナドあたりを先に
やる必要があるから仕方ないね

>>291
つまり馴染みのないあなたにはHaskellが「ヘビィ」かどうかなんて判断できないってことだよ

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

>>294
そんなんHello wordするためにはincludeを理解する必要があるって言ってるようなもんじゃん
IOアクションなんて最初は「おまじない」で良くね？

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

>>293
Haskellの方は知らん
RustはC++の代替え
C++はもう嫌だ

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

D……

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

>>294
そうかな。elixirも関数型言語だけど、だいぶ遊びやすかったけど。
俺みたいなショボいプログラマーはhaskellに近づかないほうが良いのかな。
素直にelm辺りを触ってみますわ。

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

C++にはbetter Cとかいうチート技があるから1秒で即戦力
1時間で自慢してるやつは恥を知れ

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

>>293
Haskell 勉強中なんだけど、ちょっとパーサーをいっぱい書く必要があって、パーサーを量産することがモチベーションになってる。Real world Haskell でチュートリアル的にJsonパーサー作れるくらいにはパーサー書きやすいんだと思う
でも環境周りとか正直鬱陶しいから、もしもっと書きやすい言語があったらそっちにしたい

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

>>272
ありがとう
それは書籍？

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

>>293
rustやhaskellを選択しない自分に劣等感を抱いてるのかね
他の言語をオタク専用であるかのように揶揄して自尊心を満たそうとするのはやめんしゃい

わしはGCとおさらばしたいしresult/optionの扱いが気に入ってrustを使ってる

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

>>301
特定の書籍ではないね。本屋に山ほどあるどの本でも良いのでわ？
もしくは最近だとmixiとかが社内研修用のコンテンツを無料で公開してるからそれを利用しても良いと思う。

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

GCフリーは確かに魅力だけど、充分に賢ければGC言語でもそこまで問題になる事は無いと思うが。

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

そこは状況によるし一概に否定出来ることではない

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

そういや、rustだと、自身も誰かから特定のイベントを受け取るか、誰もイベントを送り得なくなったら死ぬような感じの、
タイマーみたいな自発的にイベントを起こすイベントソースは誰か所有すべきなのかな。
タイマー起こしたやつってのも変だし。

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

Rustの Rc<T> 型の問題
Haskellの IO a 型の問題
難易度下げたいなら型を書くのをやめればいいんだよ

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

書きたくないなら省略すれば良い

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

>>307
とりあえずRustの話だが、Box<T>にせよRc<T>にせよ書かねえと
ボローチェッカを満足させられない or コストを可視化できねえんだよ

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

>>309
そうだね
チェックしたいなら学習コストを犠牲にすればいい
コスト下げたいならチェック機能を犠牲にすればいい

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

>>310
なんか勘違いされた気がするから補足
コストってのは学習コストのことじゃなくて実行時のコストのことね
Boxを明示することでヒープであるコストを可視化する
Rcを明示することで参照カウンタであるコストを可視化する

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

コードの短さこそ正義。ただし、可読性を損なわない範囲で

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