次世代言語Part7[Go Rust Swift Kotlin TypeScript]

**デフォルトの名無しさん** · 2017/10/19(木) 17:51:38.66

文字数制限きついので改題
スレタイ以外の言語もok

前スレ
次世代言語議論スレ[Rust Kotlin Haskell]第6世代
http://mevius.5ch.net/test/read.cgi/tech/1503924817/

**デフォルトの名無しさん** · 2017/10/27(金) 10:02:50.33

Rustが面倒そうなのは伝わったが
C側の奴がコピペ野郎のくせに暴れてるクズすぎてなんとも

**デフォルトの名無しさん** · 2017/10/27(金) 10:35:02.10

>>200
まともに書けるけど無料で教えてくれる人が少ないだけだってそろそろ気付けよ
普通は健康のためではなくカネのためにやってるから

**デフォルトの名無しさん** · 2017/10/27(金) 11:13:40.46

というかさ、Rustのコードバグってるんだけどwwwww
バwグwっwてwるwんwだwけwどwwwww
remove_treeで要素Removeできてないwwwww

Rustはコンパイル通れば安心できる（ドヤァ）とかいってバwグwっwてwるwwwww

**デフォルトの名無しさん** · 2017/10/27(金) 11:26:28.21

ここにRustは、安全性を高めると言いつつまともにアルゴリズムを書こうとすると制約回避のためにとてつもなく汚いコードになり、
バグもCより出やすくなることが公になりましたとさ

ちゃんちゃん

**デフォルトの名無しさん** · 2017/10/27(金) 11:40:28.33

>>198
言語に気を遣わないとすぐ自分の足元を撃ち抜く言語であるということに同意しないということ？

具体例っていざ言われると困るなあ。ふと思い出した阿呆な失敗談を一つ挙げると、クラスの値型配列を作れちゃうところとか、クラスは絶対ポインタで持たないといけないDとは対照的に感じたな

常識的に考えたらクラスの値型配列なんてやったらダメなのはわかるんだけど、なぜかやってしまって、コンパイル通ってんのに思ってたのと違う挙動して困ったわ。こういう常識的に考えたらわかるけど、考えないといけない部分があるから言語に気を遣わないとやっていけん。

これは全然大したことない例だけど、なんか他にもあったような気もするし思い出したら書き込むわ

**デフォルトの名無しさん** · 2017/10/27(金) 12:04:57.19

代入がなければ値型でもポインタでも同じ挙動だ
だから、代入しようとしたらコンパイルが通らない言語が現れた

**デフォルトの名無しさん** · 2017/10/27(金) 12:27:06.09

haskell追い出したら次はrustですか？

**デフォルトの名無しさん** · 2017/10/27(金) 12:49:17.54

追い出す権利はないね
あると思ってるやつは権利に甘えすぎ

**デフォルトの名無しさん** · 2017/10/27(金) 12:53:49.35

https://cpplover.blogspot.jp/2017/10/range-based-for.html

まあこう言う馬鹿がいなくなるまでは
実際のコードについて議論したほうがいいとは思うよ。

別にrustとかhaskellが悪いとは思わんけれど、コードなんて実際に現場で機能するかどうかが
一番重要なわけだから。原理に走ると都合の悪いことを無視し始めるのは気に入らん。

**デフォルトの名無しさん** · 2017/10/27(金) 13:27:23.45

>>203
すまぬ。すまぬ。完全なうっかりミスだったわ。
訂正した。

fn remove_tree(mut root: Option<Box<Tree>>, value: i32) -> Option<Box<Tree>> {
if root.is_none() { return root; }
else if value == root.as_ref().unwrap().value {
if root.as_ref().unwrap().left.is_none() && root.as_ref().unwrap().right.is_none() {
return None;
} else if root.as_ref().unwrap().left.is_none() {
let succ = {
let end = left_end(&root.as_ref().unwrap().right);
end.as_ref().unwrap().value
};
>> 訂正前 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value);
>> 訂正後 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), succ);
root.as_mut().unwrap().value = succ;
} else {
let pred = {
let end = right_end(&root.as_ref().unwrap().left);
end.as_ref().unwrap().value
};
>> 訂正前 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value);
>> 訂正後 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), pred);
root.as_mut().unwrap().value = pred;
}
} else if value > root.as_ref().unwrap().value { root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value); }
else { root.as_mut().unwrap().left = remove_tree(root.as_mut().unwrap().left.take(), value); }
...

**デフォルトの名無しさん** · 2017/10/27(金) 14:02:45.56

>>204
何度も言ってるがこのコードが汚いのは制約回避のためじゃなくて、Cのコードを愚直に移植してるからだぞ。
CのNULLを表現するためにOption型を使用してるから、コンビネータとかを
きちんと使わない限りはunwrapだらけになってコードが汚くなる。
Rustのコードが汚いんじゃなくてRustyに書いてないから汚いだけ。
同じことを何度も言わせないでくれ。

確かに、Rustはコンパイル通すために苦労するから、
執行錯誤してるうちにうっかりミスしやすくなるという考えはあるのかもな。
まあ、この程度のミスを犯す俺が単純にバカすぐるのか、これもRustの課題のひとつだと考えるかは
人によって意見が分かれてくるところじゃないか？みんなどう思う？

**デフォルトの名無しさん** · 2017/10/27(金) 15:02:03.76

カネもないし時間のゆとりもないからコードが汚くなった
言語よりもカネと時間の使い方が間違っている

**デフォルトの名無しさん** · 2017/10/27(金) 17:07:21.98

>>205
クラスの値型配列はごく基本的で有用なデータ構造なんだけど…

**デフォルトの名無しさん** · 2017/10/27(金) 17:26:21.22

いや俺もちゃんと具体例出すか。例えば
class Point { public: double x; double y; }; だの Point3D だのが定義できて、
vector<Point> や Point v[..] が扱えなかったらシステムプログラミングなんかできやしない
…かどうかは別として別に値型の配列は必要なデータ構造だし、
immutable であれば直感に反した動作もないのでは。

実際に用途の多くは inmutable なオブジェクトの配列で、
C++17 では vector<const T> が許容されるようになりそうな流れ。

**デフォルトの名無しさん** · 2017/10/27(金) 17:40:16.82

>>214
ああ、すまん。Dでは構造体は継承出来ない代わりに値型可能、クラスは継承出来る代わりに値型不能なんよ。そのイメージが残ってたわ。
継承したものを値型で混ぜ混ぜしてしまったというのが俺のミスなのです

**デフォルトの名無しさん** · 2017/10/27(金) 18:04:05.75

何でスレタイからHaskell外したんだよ
それならGo外せよ

**デフォルトの名無しさん** · 2017/10/27(金) 18:39:17.91

なんか元々の C のコードを Rust に下から生じた問題みたいに言ってるけれど
tree のアルゴリズムを実直に書けばそういうふうになるだろ。
それってつまり実直にアルゴリズムを記述するのに向いてないって言ってるようなもんだろ。

あ · 2017/10/27(金) 18:41:31.58

また無様なHaskellのコード見るの嫌だし、むしろスレタイには言語一切入れんでもいいだろ。

好きなら、なぜ好きかを推すだけで充分議論になるのに、
他の言語を貶めて、○○はゴミだから△△が良い、って論調にするのはちょっとおかしいんじゃないの？

ホームレスが椅子で寝るの見て、俺はブラック企業戦士だけど屋根のある部屋で椅子で寝てるだけマシ、って言ってるように聞こえるよ。
好きで椅子で寝てるなら椅子寝のこだわりぐらい書けよ。パイプ椅子なら圧倒的に互い違い派だ、とか。

**デフォルトの名無しさん** · 2017/10/27(金) 19:47:08.69

貶めるのが許せないという気持ちがよくわからない
例えば残業代未払いは許せるが貶めるのは許せないとか
なんでそういう優先順位になったのか理解できない

**デフォルトの名無しさん** · 2017/10/27(金) 20:10:28.34

エアプガイジの言ってることわかる訳ないんだから絡むな��

**デフォルトの名無しさん** · 2017/10/27(金) 20:13:53.36

Rust派の意見としては、

①TreeはCより汚いけど他のメリットが大きいから許せ

②もっとうまく書けるから俺が書いてやるぜ

③副作用のある木は糞

どれ？

**デフォルトの名無しさん** · 2017/10/27(金) 22:02:47.00

>>218
隔離スレだしな。
プログラマ自体、人口のほんの一部だし、複数の計算モデルが異なる言語を使いこなしてるのなんて更に希少種だから、もともと言語のマトモな比較が出来る奴が殆ど居ない。
だからここで言い合ってるのはおま環がデフォ。

**デフォルトの名無しさん** · 2017/10/27(金) 22:13:38.27

>>184
型がないと引数なり戻り値なりで与えられた情報をどう扱っていいかわからないでしょう

**デフォルトの名無しさん** · 2017/10/27(金) 22:23:07.44

返り値が返るのも
それも副作用って事にならないのはなんで？

**デフォルトの名無しさん** · 2017/10/27(金) 23:02:40.27

式に値があるのは副作用と言わないから

**デフォルトの名無しさん** · 2017/10/27(金) 23:04:58.68

>>224
主の作用だからだろ

**デフォルトの名無しさん** · 2017/10/27(金) 23:23:42.05

>>218
無様なHaskellコードって？

**デフォルトの名無しさん** · 2017/10/27(金) 23:45:39.75

>>211
ちゃんと具体的にコードを書いてくれて議論しやすくしてくれたのはありがたい。
tree を rust で実装しろって言われたら 10 人中 9 人は Box と Option を
使ったそういう構造体作ると思う。

**デフォルトの名無しさん** · 2017/10/27(金) 23:47:59.22

>>214
Pointの例に限って言えば同意できないな
大量の小さなベクトルを扱うような場合、構造体を使うより各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
C++系の言語で行持ちの方が好まれるのは、一番の理由は言語の性質上そのほうが扱いやすいからに過ぎない
最近は列指向DBなんかも普通に使われるようになって、データの列持ちが見直されつつある今、
列持ちのデータ構造をスマートに扱える言語があってもいいと思うわ

**デフォルトの名無しさん** · 2017/10/28(土) 00:01:16.09

>>229
Fortran, Juliaのことか？

**デフォルトの名無しさん** · 2017/10/28(土) 00:03:34.74

>>227
>無様なHaskellのコード

908 ：あ：2017/05/31(水) 09:15:21.09 ID:dc+IbjjD
>>905
具体的に上げろと言われてもなぁ。
<T>を持ったenumがOptionかcar(T)とcdr(<T,T>)である時くらいかな。

これのことじゃないの？（適当）

**デフォルトの名無しさん** · 2017/10/28(土) 00:24:09.93

てか
>>229
> 各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
これってどういう演算の時にそうなるんです？

**デフォルトの名無しさん** · 2017/10/28(土) 00:46:39.85

Rustアンチくんはペチパー

はっきりわかんだね

あ · 2017/10/28(土) 00:51:22.50

>>219
許せないんじゃなくて、健全ではないよね、と。
なんせ改善せずとも、自分があたかもまともであるかのように思える一番楽な方法だし、進歩もない。

>>222
ホントに。好きなら好きで良いんだよ。
バカで比べる事ができないなら素直に信者してりゃ良いの。
狂信者が戦争起こすような真似をネットでまでやらんでもよろしい。

>>227
>>231
しかも、結局すごくひねり倒してグダグダ言った割に、最後まで動くコードが出てこなかったんだけっけ。

**デフォルトの名無しさん** · 2017/10/28(土) 00:58:11.14

>>232
分かりやすいのはパディングが入るケース
ループのベクトル化もスカラー配列の方が効きやすいらしい

**デフォルトの名無しさん** · 2017/10/28(土) 01:07:07.63

>>235
うーむ……
もしかしてPoint3Dのベクトルに一括して行列を掛けたりする状況を想定しているのか？

**デフォルトの名無しさん** · 2017/10/28(土) 01:09:54.95

そういう状況でもない限りそもそもボトルネックにならないからな

**デフォルトの名無しさん** · 2017/10/28(土) 01:16:42.42

>>211
試行錯誤の過程でアルゴリズムぶっこわれるってのはよくあるが、そうならないためにテストコードがあるっちゃそうだから、
明確な欠点とは言えないかもな

まさかスレに貼るサンプルコードにまでテストコードつけろなんて言えねえし。

**デフォルトの名無しさん** · 2017/10/28(土) 04:09:54.80

>>234
ドアの奴なかな？
あれならHaskellのコード出てただろ
いつまで言ってるんだ

**デフォルトの名無しさん** · 2017/10/28(土) 09:04:44.68

コード出すという行動ではなく
コードが正義っていう知見への承認とか共感が欲しかったんじゃないか
だから行動だけでは駄目

あ · 2017/10/28(土) 09:19:59.46

>>239
じゃ、いつまで、スレタイにはHaskellが、って言ってんだよ(笑)

**デフォルトの名無しさん** · 2017/10/28(土) 10:25:15.53

なぜ私達は Python から Go に移行したのか
https://frasco.io/why-we-switched-from-python-to-go-19581e27de7c

**デフォルトの名無しさん** · 2017/10/28(土) 10:45:03.08

よくあんな無様な知ったかぶりしといて人のこと無様とか言えるな

**デフォルトの名無しさん** · 2017/10/28(土) 11:06:53.69

これだからペチプァは

あ · 2017/10/28(土) 11:20:03.53

>>243
自分が無様だと思ってる奴に無様だと言われるのはさぞ辛かろうが、
俺が無様なのとHaskell書いたやつが無様なのは別の事象で、

同時に無様でありえるんだから、その指摘はナンセンスだろ。
その理解力でHaskell最高！と思ってるのも面白いな。Maybeの真髄だろ。事象を整理するのは。

**デフォルトの名無しさん** · 2017/10/28(土) 11:28:14.87

なんだこいつなんで俺がHaskell 信者みたいな前提で煽って来てんだ

**デフォルトの名無しさん** · 2017/10/28(土) 11:36:54.21

もう最新規格のFortranで良いよ

**デフォルトの名無しさん** · 2017/10/28(土) 12:01:24.16

Fortranに第一級関数がついてimplicit noneがデフォルトになってinterface文をもうちょっと短く書けるようになって引数の型指定をCみたいに書けるようになって
配列の大きさ指定の関数に組み込みでない関数を使えるようになってgfortranのbind(C)周りのバグを解消してくれたらFortranでいいよ

**デフォルトの名無しさん** · 2017/10/28(土) 12:13:39.86

西京言語PHPを使えばいいじゃん（いいじゃん）

**デフォルトの名無しさん** · 2017/10/28(土) 12:20:24.44

PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい

**デフォルトの名無しさん** · 2017/10/28(土) 12:31:15.99

mod_perlとだったら大して変わらん気がする

**デフォルトの名無しさん** · 2017/10/28(土) 12:33:46.88

＞PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい

キリッ

ｗｗｗ

**デフォルトの名無しさん** · 2017/10/28(土) 17:09:33.99

皆がCGIという共通ルールを守る中
汎用性のない独自実装をしたphp

**デフォルトの名無しさん** · 2017/10/28(土) 17:24:26.31

まあ今更Perlとかって選択肢はないからね

**デフォルトの名無しさん** · 2017/10/28(土) 17:31:59.24

FacebookはなんでPHP推しなの？

**デフォルトの名無しさん** · 2017/10/28(土) 18:04:40.73

PHPをC++に変換するんだっけ
むしろJavaをC++に変換するのを誰もやらない理由を知りたい

**デフォルトの名無しさん** · 2017/10/28(土) 18:12:54.21

>>256
Javaは事実上サーバーでしか使われていないので、
全くメリットがないから

**デフォルトの名無しさん** · 2017/10/28(土) 18:27:47.92

phpのがサーバでしか使われてない印象
どっかで使ってる?

**デフォルトの名無しさん** · 2017/10/28(土) 18:32:36.63

>>254
別にCGIはperlでなくてもいいだろ
プロセスを起動するインタフェースのお約束だよな
perlは文字列処理が得意だっただけで

**デフォルトの名無しさん** · 2017/10/28(土) 19:01:45.06

PHPの特徴ってインスタンスの生存時間が極端に短い。ってこと。
request受けてからresponse返すまで。
だからGCが貧弱でも何の問題もないし。糞汚いコードでもメモリリークが問題にならない。

**デフォルトの名無しさん** · 2017/10/28(土) 19:13:14.28

>>256
GCC
http://news.mynavi.jp/news/2016/09/08/290/

あと、AndroidはJavaじゃないからノーカンなのかもしれないが、
以前はネイティブに全部変換していたのをやめた

**デフォルトの名無しさん** · 2017/10/28(土) 19:51:46.92

>>255
むしろPHPを積極的に潰そうとしてる印象なんだが
クソ挙動しかしないウンコ製造機PHPを潰すためにHHVMは作られたんだぞ

**デフォルトの名無しさん** · 2017/10/28(土) 20:44:53.33

>>255
最初は何も考えずにお手軽に作れたからPHPだった
大きくなりすぎてから管理コストを考えてノロノロと移行を企てている
そんなとこだろ

**デフォルトの名無しさん** · 2017/10/28(土) 21:07:01.93

それ以上ペチパーの心のより所を叩くのはやめてやれｗ
彼ら、憤死してしまうでｗｗｗ

**デフォルトの名無しさん** · 2017/10/28(土) 21:37:38.45

>>260
言ってること滅茶苦茶だな

**デフォルトの名無しさん** · 2017/10/28(土) 21:57:38.28

伝えようとすれば滅茶苦茶
隠そうとすればバレバレ
だから型情報とか一生懸命伝えようとする言語が報われない

**デフォルトの名無しさん** · 2017/10/29(日) 03:03:23.28

>>242
go 好きな人ってまともすぎてつまらんな。

**デフォルトの名無しさん** · 2017/10/29(日) 05:05:09.88

>>261
ARTは全部変換なんてしてない
元からJITとAOTの複合

**デフォルトの名無しさん** · 2017/10/29(日) 05:05:25.10

>>267
きんも

**デフォルトの名無しさん** · 2017/10/29(日) 17:16:13.61

>>268
http://gihyo.jp/lifestyle/clip/01/awt/201603/24
＞しかし，AOT方式をいざ導入してみると，サイズの大きなアプリのインストールや，
＞一度に複数のアプリをアップデートするような場合にコンパイルに時間がかかり，
＞場合によっては20分程度かかるケースが存在していたようです。
＞このインストール時間を問題と捉えて，Android NのARTでは，JIT方式をもう一度使うことになりました。

**デフォルトの名無しさん** · 2017/10/30(月) 08:01:20.39

>>242
GOいいな

**デフォルトの名無しさん** · 2017/10/30(月) 10:22:57.04

>>271
Goは色々足りないところも多いが、生産性にステガン振りしてるって点で評価できる
Rubyみたいに前借りではない

**デフォルトの名無しさん** · 2017/10/30(月) 11:06:54.77

Rubyの教訓は、「Perlよりマシ」に全振りしたけどPythonと比べると大したことなかった

**デフォルトの名無しさん** · 2017/10/30(月) 17:27:48.73

Goのどこに生産性があるんだよ

あ · 2017/10/30(月) 18:12:26.17

>>274
そりゃ、ひたすら書ける部分だろ。
迷わんぞ。書く量が多いだけで。

生産性と言うと表現力ばっかり取り上げられるが、単位時間あたりのアウトプットも見ないといかん。
その点、信じられないレベルで楽。

**デフォルトの名無しさん** · 2017/10/30(月) 19:01:45.29

>>275
行数多くなるから生産性が高いように見えるだけだろ

**デフォルトの名無しさん** · 2017/10/30(月) 19:15:05.61

そいつは関数型しったか野郎なので話すだけ無駄
無知が無知なりの常識で頑張って答えてくれるかも知れないけど参考にはならないだろう

**デフォルトの名無しさん** · 2017/10/30(月) 20:23:14.16

迷わずひたすらに書かれたF77のコード読みづらすぎ

**デフォルトの名無しさん** · 2017/10/30(月) 20:45:20.95

Goは構造体へのタグ埋め込みや、codegenまわりのツールが充実してるお陰で
ボイラープレートコードを書かんでいいのがでかい
それだけならLLでもできるが、テスト作ってから設置して実行するまでの作法が簡潔に固まってるのが更に強い

少なくとも時間当たりのテスト含めた成果物は他の言語と比べ物にならん

**デフォルトの名無しさん** · 2017/10/30(月) 21:31:16.17

逆に、汎用ライブラリ書こうとするととたんにinterface地獄になってボイラープレート増えるんだがな
だから、目の前の仕事の案件片付けるのに特化した言語だと思ってる

**デフォルトの名無しさん** · 2017/10/30(月) 22:18:12.05

>>221
ちょっといまさらだがRust版平衡木(AA木)をリファクタリングしたぞ。
まあ、だれも書いてくれそうになかったし、数日たったらまたやる気も出たから自分でやり直したわけだが。

基本的には②だが、すべて当てはまるな。
RustはNull安全なのでOption型のチェックが必須、コンパイラに所有権を伝えるためas_ref等が必要、
デフォルトはイミュターブルのためミュータブルを扱うためにmutキーワードが必要などが主な理由。
そこら辺の安全性と引き換えに多少は目をつぶってくれという感じはある。
③に関しては副作用もあるが、それよりもどちらかというと木構造の回転操作みたいな
変数の所有者が次々に代わるようなコードはRustでは所有権システムがあるため書きづらい。

とはいえ、前のコードに比べれば大分マシにはなったかと。
まあコードが綺麗か汚いかなんて個人の主観によるところが大きいから、まだ文句を言うやつもいると思うけど。。。
特に>>217なんかには「どんなアルゴリズムだろうが言語によって最適な書き方は違う」
ということをきちんと理解してもらいたい。

あと、コードのリンクを貼るという手段があることを知った。
比較できるように全て載せておく。
C版
https://wandbox.org/permlink/fc1xI7dDCdOMgysC
Rust版 before
https://wandbox.org/permlink/cbzzpLw97K2Tydk1
Rust版 after
https://wandbox.org/permlink/ppQOQREnDlpccpJV

**デフォルトの名無しさん** · 2017/10/30(月) 22:28:38.00

ほう

あ · 2017/10/31(火) 00:08:53.17

>>276
そーでもないぞ。

>>277
関数型以外シッタカの意識だけ高い系に言われてもな。
人をディスるんじゃなくて、自分を高めれば？
無理なんだろうけど(笑)

**デフォルトの名無しさん** · 2017/10/31(火) 00:13:46.41

関数型以外シッタカ←根拠なしのただのディス
からの
人をディスるんじゃなくて自分を高めれば？

自戒かな？

**デフォルトの名無しさん** · 2017/10/31(火) 00:16:52.10

そいつの相手しても得るもん無いってことくらいはそろそろ分かって欲しい

あ · 2017/10/31(火) 00:17:14.17

言い返されてそれはみっともないリアクションだな。
よほど、関数型言語が好きなんだね(笑)

専スレ立ててやれよ。次世代言語でもないわ。

あ · 2017/10/31(火) 00:19:38.37

好きなら好きで良いのに、なぜ固執するかわからん。
ナイフで整備できるようにネジを全部マイナスネジにしたロシア(？)の戦車みたいな間抜けな話と同じように、目的に対して使う道具なんか考えりゃ良いのに。

**デフォルトの名無しさん** · 2017/10/31(火) 00:26:46.01

よほど関数型言語が好きなんだね←誰もそんなことは言っていない

なぜ固執するかわからん←固執していない

誰と闘っているんだコイツは。少なくとも俺じゃねえな

**デフォルトの名無しさん** · 2017/10/31(火) 00:39:43.26

おまえら旧世代猿人類どもはウンコブラシのプェチピィのゲリクソピィでもプリプリしてろ

**デフォルトの名無しさん** · 2017/10/31(火) 01:21:58.60

>>281
コンパイル通らんのを試行錯誤してる間に答えが出てしまった悲しみ
まとめてもらって感謝。勉強してみるわ

**デフォルトの名無しさん** · 2017/10/31(火) 07:32:43.21

>>281
比較を載せてくれてありがたい。
やっぱり
C -> rust before -> rust after
となっていくごとに読みづらくなってるんだけれど。。

**デフォルトの名無しさん** · 2017/10/31(火) 07:35:28.96

>>270
それの何が反論になってると？
元から速度云々関係なしにネイティブ変換できない部分があったんだよ

**デフォルトの名無しさん** · 2017/10/31(火) 09:37:19.94

>>291
root.as_ref().unwrap().level
を
root->level
と書いて良いというシンタックスシュガーを導入すれば良い気がする

**デフォルトの名無しさん** · 2017/10/31(火) 09:56:03.51

unwrapはNoneだった場合にランタイムクラッシュする関数だから本来使ったらアカン関数
この辺はnil安全うたってる言語はおおむねそう

**デフォルトの名無しさん** · 2017/10/31(火) 10:23:24.56

Goは最初期Javaかっていう後退レベルだし、Rustは木構造すら数日かかりで必要な難解言語だしでどっちもクソ言語
はいこれで仲直り

**デフォルトの名無しさん** · 2017/10/31(火) 10:43:17.86

パラダイムシフトを強いる言語は地雷が多いな。
俺はリアクティブプログラミングで懲りた。

**デフォルトの名無しさん** · 2017/10/31(火) 10:44:19.94

数日がかりというが兎と亀みたいにRust以外の言語は寝てたから
Rustが一番早い

**デフォルトの名無しさん** · 2017/10/31(火) 11:07:20.83

その理屈だとCが一番じゃん？

**デフォルトの名無しさん** · 2017/10/31(火) 11:21:14.97

結局当面はC#系(TypeScript/Kotlin)の天下ということでよろしいか

**デフォルトの名無しさん** · 2017/10/31(火) 11:40:23.38

>>294
そういうこと。だからRust版 afterではunwrapはほとんど使用していない。
通常、Optionの中身を取り出すときはunwrap_or, unwrap_or_else, unwrap_or_default
のどれかを使用してNoneだったときはどうするのか指定する。
unwrapを使用するときはアルゴリズム的に中身が存在しないこと自体がありえなくて、
Noneならバグと判断してむしろそのタイミングで落ちてバグを知らせてほしい時のみ使用する。
この仕組みによってNullが存在しない(いわゆるNull安全な)言語を実現している。
多少書くのは面倒だが「10億ドルの損失」に比べればこのくらいカワイイもんだろってこと。

ちなみにC#なんかでも導入が検討されているらしいが、既存コードとの互換性が保てないので難儀しているようだ。
Type scriptみたいにコンパイルオプション付ければいいのにとか俺は思うんだが、なんか理由があるのかな？