次世代言語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/23(月) 20:22:06.86

誠に残念ながら今そのポジションはGoの一強

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

Cよりスピード出るのはNimだけ！

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

ジャップランド土人村企業が詐欺のために求めているのはPHPだけ！

**デフォルトの名無しさん** · 2017/10/23(月) 21:14:10.32

どうかんかえてもRustだろ

**デフォルトの名無しさん** · 2017/10/23(月) 21:25:58.19

>>84
Goも弱点が多い言語だけど初期の学習コストとか考えると
rustよりGoかな。
もちろんrustもいいんだけどc++並に学習コスト高そう感ある。

**デフォルトの名無しさん** · 2017/10/23(月) 21:47:48.94

Rustは言語と名乗れる水準に達してないのでGo
深くシステムに触るのには向いてないがな

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

Goなのか……
他言語が純粋な次世代Cを目指してる中、Goは微妙に設計思想が違うイメージだからあえて外したんだが……やっぱりgoogle正義なのか

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

>>83
c++ で何を書くつもりなの？
無理に c++ で書かなきゃならんものって最近は減ってると思うけど。

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

>>91
c++ で書かれたオープンソースプログラムのdllプラグイン
悲しいことにc++ 選ぶ理由なんて結局既存ソースがc++ だからの理由に尽きる……

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

>>90
goとか言ってる連中の言うこと本気にするなよ。
goは数年周期でバズってるだけでC++の代替なら
Dかrustって考えは間違ってないしrust理解できないやつが
こことrustスレで騒いでるだけだぞ。

Dはもう流行らんだろうが、rustは学習コストより標準ライブラリの弱さが面倒。
自分で書くか外部ライブラリに依存しまくるかで基本的なスレッドプールすら無い。
低レベル向けだから結局自分で書くならrustでいいし、それが嫌ならDでいいよ。

rustとD位の差なら正直好みの差。

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

>>92
ならやっぱりrustじゃない？
bindgen使えばc++のヘッダもパースしてc ffi用のglue code生成してくれる。
bindgenがどの程度まで万能かは俺もよくは知らんけど、
mozillaがfirefox quantumでservoとgeckoの橋渡しのために使ってるくらいだから
結構まともに動くんじゃないかとは思ってる。

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

おまんらの大好き　ぷ～えちピーーﾌﾞﾘﾌﾞﾘｯ　でも使えばええじゃろｗ

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

みんなサンクス。
Goは学習コスト低いらしいから後追いでもなんとかなりそうだし、とりあえずrustで書いてみることにするわ
一刻も早くc++ が絶滅する事を祈る

**デフォルトの名無しさん** · 2017/10/24(火) 00:05:09.11

TypeScriptとGoを交互に触ってるけど
やっぱりnull安全な言語とそうじゃない言語の差が際立つな。
Goのほうは早速null pointerアクセスで落ちる。

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

c++が絶滅したら今c++で書かれてる様々なコードベースが色んな言語に分裂するんだぜ
バベルの塔

**デフォルトの名無しさん** · 2017/10/24(火) 00:51:24.05

バベルの塔を高くし過ぎたからしょうがないね

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

>>93
既存のまともに動いてるCコード移植しようとしてまともにコンパイルも通らなかった経験からまともな言語の水準に達してないといってるわけだが
少なくともRustでものが書けると信じこんでるお前よりはRust理解してるぞ

**デフォルトの名無しさん** · 2017/10/24(火) 02:18:45.70

>>100
お前が前に沸いたアンチと同一人物かどうかは分からんが、前に言った木構造をとっとと書きやがれ。
それすらできないならお前はC、C++もそもそもまともに出来てないんだから黙ってろ。

> 38
> >>36
> まずはCかC++でお前の言う無駄なアロケーションのないappendとdelete付きの木構造とやらを書け。
> そしたらそれをRustで書き直してやるよ。

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

>>101
まずRustの木構造をちゃんと動くように書いてから言えよ

**デフォルトの名無しさん** · 2017/10/24(火) 08:36:29.96

rust で木構造云々言ってる奴って、コンパイラすら通せない rust コードしか書けない奴だろ。

Cで書いてあった平衡木のライブラリを rust に移植したけど、
> それに対して余計なアロケーション発生させずにappendとdelete実装してみてくれよ
こんなん普通に出来るぞ。
Option<Node> に get_or_insert() するだけ。

かなり苦労したのは木の回転だけど、それでも rust 用に頭を使ったら、
take() して mem::swap, mem::swap, mem::swap, そして代入の 5 行で終わり。
全体を通して余計なアロケーションなんて普通に無い。

rust は学習コスト結構高いけど、初歩の初歩で躓いた落ちこぼれ>>100,>>102 とかは何を言う権利も無いよ。

**デフォルトの名無しさん** · 2017/10/24(火) 10:27:36.72

Cのコードを示せないrustアンチは糞ゴミだけど、動くコードを示していない>>103も何も言えていない

**デフォルトの名無しさん** · 2017/10/24(火) 11:02:52.32

自分の頭を撃ち抜くCのプログラム書いても運良く助かってる人は
Rustのコンパイル通せなくなるよね

**デフォルトの名無しさん** · 2017/10/24(火) 11:29:48.61

そういう、Rustのコンパイルが通らなければ危険なコードって決めつけるRust信者本当にうぜえ
Rustが言語として表現できる範囲が狭いのをごまかすための方便でしかないのに

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

TypeScriptは本家のplaygroundを触るだけで凄さが分かるんだけど
https://www.typescriptlang.org/play/

rustってそういうのある？ちょっと試すとかできる？

**デフォルトの名無しさん** · 2017/10/24(火) 11:33:53.63

>>105
自分の頭というよりユーザーにデバッグのコストを転嫁して儲けてるな
運が良いというより確信犯的に

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

>>107
ググるとかしない人？単にTypeScript宣伝したいだけ？
https://play.rust-lang.org/

もとよりゆるふわTypeScript使いがRustのコンパイルを通せるとも思えないので端から試す気ゼロだろうけど…

**デフォルトの名無しさん** · 2017/10/24(火) 13:56:01.66

選ばれた人しかコンパイラ通せない言語とかそれプログラミング言語って言えないよね

**デフォルトの名無しさん** · 2017/10/24(火) 14:30:25.93

>>109
そこは知ってるけど全然補完が効かないんだけど。rust使いは
しょぼいエディターで頑張る感じ？

TypeScriptはplaygroundから補完が効きまくって楽しい。

**デフォルトの名無しさん** · 2017/10/24(火) 16:07:36.55

AltJSであるtsとRustのブラウザ上で動くplaygroundの機能差を語りたかったの？マジで？
Rustサゲしてる人はこの程度ってレッテル貼っていいの？

**デフォルトの名無しさん** · 2017/10/24(火) 16:17:29.04

単にプロダクト開発のスキルの違いだな
MSの開発環境チームのメンバーはHelloWorldの代わりにインテリセンス実装するんだろう

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

>>112
単純にPlaygroundの質からして違うってだけの話だろ
その程度もみとめられないよかよ

**デフォルトの名無しさん** · 2017/10/24(火) 18:42:18.67

なぜrustの対抗馬にTypeScriptが挙がるのかまるで理解できない
用途が全然違うだろ……

**デフォルトの名無しさん** · 2017/10/24(火) 19:07:54.15

WebAssemblyが期待されてるから、あながち間違いでもない

**デフォルトの名無しさん** · 2017/10/24(火) 21:40:46.56

>>113
ほんとMSってそういう所は笑えるくらいすごいよな
Rust開発者たちも見習ってほしい

一応rustもコード補完にrlsとかいうヤツあるけどなんかまだいまいちなんだよな。
vscodeにrust(rls)っていうエクテンション入れて使ってるんだけど、
クロージャ書いてるときは補完が効かないのは俺だけ？
あとlint?(エラー・警告を赤・緑の下線で表示してくれるやつ)が
時々なんの前触れもなく急に無反応になるんだけどそれも俺だけ？

**デフォルトの名無しさん** · 2017/10/24(火) 22:14:01.00

少人数のMS社員が片手間でVSCode作ってみたら一瞬で天下獲れちゃいましたというチート集団
MSがRust推せば余裕でGo潰してベターC++の定番を奪えるだろうな

**デフォルトの名無しさん** · 2017/10/24(火) 22:51:21.66

片手間ってことはないし、エディタ作成なんてのは人数増やせばいいものでもない。
まあチート軍団ってのは確かだけど。
しかし Rust とか c++ みたいに教条主義的な言語ってやっぱ信者が湧くね。
わかりやすくていいとは思うけど。

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

片手間とか余裕とか、良い子は絶対に真似してはいけない情報ばっかり教えるんだよな
そんなところに信者を集めたら怠け者の集団ができそうだ

**デフォルトの名無しさん** · 2017/10/25(水) 00:51:09.03

>>36じゃないけど、雑に平衡木（AA木）Cで実装してみた。
つってもWikipediaのまるコピだが。
#include <stdio.h>
#include <stdlib.h>

typedef struct tree {
int value;
struct tree* left;
struct tree* right;
int level;
} tree_t;

int level(tree_t* t) {
if (t == NULL) {
return 0;
}
return t->level;
}

tree_t* leftEnd(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->left == NULL) {
return t;
} else {
return leftEnd(t->left);
}
}
（続く）

**デフォルトの名無しさん** · 2017/10/25(水) 00:51:31.44

tree_t* rightEnd(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->right == NULL) {
return t;
} else {
return rightEnd(t->right);
}
}

tree_t* skew(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->left == NULL) {
return t;
} else if (t->left->level != t->level) {
return t;
}
tree_t* l = t->left;
t->left = l->right;
l->right = t;
return l;
}
（まだ続く）

**デフォルトの名無しさん** · 2017/10/25(水) 00:52:33.16

tree_t* split(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->right == NULL) {
return t;
} else if (t->right->right == NULL) {
return t;
} else if (t->level != t->right->right->level) {
return t;
}
tree_t* r = t->right;
t->right = r->left;
r->left = t;
r->level += 1;
return r;
}
（続く）

**デフォルトの名無しさん** · 2017/10/25(水) 00:52:56.15

tree_t* decreaseLevel(tree_t* t) {
if (t == NULL) {
return t;
}
int ll = level(t->left);
int rl = level(t->right);
int expectedLv;
if (ll < rl) {
expectedLv = ll + 1;
} else {
expectedLv = rl + 1;
}
if (expectedLv < t->level) {
t->level = expectedLv;
if (t->right != NULL) {
if (expectedLv < t->right->level) {
t->right->level = expectedLv;
}
}
}
return t;
}

**デフォルトの名無しさん** · 2017/10/25(水) 00:53:17.67

tree_t* insertTree(tree_t* t, int v) {
if (t == NULL) {
t = malloc(sizeof(tree_t));
t->value = v;
t->left = NULL;
t->right = NULL;
t->level = 1;
} else if (v > t->value) {
t->right = insertTree(t->right, v);
} else {
t->left = insertTree(t->left, v);
}
t = skew(t);
t = split(t);
return t;
}
肝心の関数まで遠いなほんと

**デフォルトの名無しさん** · 2017/10/25(水) 00:55:17.25

tree_t* removeTree(tree_t* t, int v) {
if (t == NULL) { return t; }
else if (v == t->value) {
if (t->left == NULL && t->right == NULL) {
free(t);
return NULL;
} else if (t->left == NULL) {
tree_t* e = leftEnd(t->right);
int succ = e->value;
t->right = removeTree(t->right, succ);
t->value = succ;
} else {
tree_t* e = rightEnd(t->left);
int pred = e->value;
t->left = removeTree(t->left, pred);
t->value = pred;
}
} else if (v > t->value) { t->right = removeTree(t->right, v); }
else { t->left = removeTree(t->left, v); }

t = decreaseLevel(t);
t = skew(t);
t->right = skew(t->right);
if (t->right != NULL) {
t->right->right = skew(t->right->right);
}
t = split(t);
t->right = split(t->right);
return t;
}
おしまい。まじこんなクソコードに何レスもついやしてすまん。

**デフォルトの名無しさん** · 2017/10/25(水) 00:56:55.22

改めて書いてみて思ったが、平衡木って平衡保つための操作がポインタのつけかえ多くて
確かにRustにはキツそうだなとか思ったり

データコピーなし縛りで実装するのはRust歴1週間の自分には無理そうだ

**デフォルトの名無しさん** · 2017/10/25(水) 01:27:50.62

Rust 的にはそんなに派手に持ち主変えるな、もしくはコピーを使えって感覚なんだろう。
そういうのは上のレイヤーだったら正しいと思うけど、アルゴリズムなコードの場合は
ちと厳しいかもしれん。
付け替えが頻繁に発生する構造の場合は
int parent[]; int right[]; int left[];
みたいな配列実装しろてな記事は見た事なるな。
直感的ではないけど速度は出るし、まあ慣れてる奴からすればどっちも一緒といえば一緒かな。

**デフォルトの名無しさん** · 2017/10/25(水) 01:53:05.61

そういう、どうしても生ポインタごそごそつけかえる必要がある基幹アルゴリズムは、unsafeでくるんでやれって感じなのかね
実際この平衡木の実体が複数スレッドから独立に操作されるとか考えると割と困る

**デフォルトの名無しさん** · 2017/10/25(水) 06:54:35.09

gitみたいに、古いデータを消去することなく
しかも変更のない部分はいちいちコピーしないアルゴリズムを考えるんだ
そうすれば古い方のデータに別スレッドから安全にアクセスできるよ

**デフォルトの名無しさん** · 2017/10/25(水) 10:38:32.59

結局たかが赤黒木すらRustでは書けないって認識でいいの？
ほんとプログラミング言語名乗るなよ

**デフォルトの名無しさん** · 2017/10/25(水) 10:59:08.02

>>131
その認識は間違いだけど正解を無料で教えてくれるボランティアが足りないね
GNUみたいなボランティアがいっぱいいないとプログラミング言語を名乗れないのが現実

**デフォルトの名無しさん** · 2017/10/25(水) 11:14:21.26

Rustの問題は後発のくせにIDE連携が弱すぎる。
KotlinとかSwiftとか後発の言語は大概IDEと一緒に提供してるから
最初から補完がきっちり効く。

Goも昔はイマイチだったけど改善してるから許せる。
TypeScriptは言語そのものにIDE連携のための機能をたっぷり盛り込んでいるから
見習ってほしいって話。

初学者程IDE連携が必要だからな。言語仕様が優れてていても
ツールとして使い勝手が良くなきゃ使わんよ。

それにRustの立ち位置って
OS開発とブラウザ開発くらいしかメリットが思い浮かばんのだけども

CLIならGoだし
WebならPHPとかRubyとかGoとか乱立状態だし
WEBのクライアントサイドならTypeScriptだし
スマホならKotlinかSwiftかObjC

このどこにRustが入り込むの？

**デフォルトの名無しさん** · 2017/10/25(水) 11:47:25.56

そもそもC++があまり成功してないから改善するためにRustがある
C/C++と合計して考えるとJavaより上だけど合計しなければC++は成功してないよ

**デフォルトの名無しさん** · 2017/10/25(水) 12:31:23.13

C++が成功してないwwwwwwwwwww
どこの平行宇宙ですかwwwwwwwwwwwwwwwww

**デフォルトの名無しさん** · 2017/10/25(水) 13:46:26.44

まあ c++ がうまくいってればこんなに言語がたくさんできることはなかっただろうね。
c++ の存在意義は今や高級な機能をどれだけランタイム速度落とさずに入れられるのかの
実験場って位置づけかな。

**デフォルトの名無しさん** · 2017/10/25(水) 13:55:53.69

C++は完璧な言語だとか口が割けても言えないのは間違いないが、Rustなんて言語ですらない汚物使うくらいならC++使うわなあ

**デフォルトの名無しさん** · 2017/10/25(水) 15:45:07.57

ID:KYsAJ7k0のコードのRust版まだー？

**デフォルトの名無しさん** · 2017/10/25(水) 16:40:52.54

>>133
rlsあるし十分やん

あ · 2017/10/25(水) 18:10:38.69

TSは手段と目的がたまに入れ替わるのが見てるとちょっもモヤモヤするな。
C#が最近もう一度好きになってきた。

**デフォルトの名無しさん** · 2017/10/25(水) 19:10:42.88

>>138
まあまあ今ごろコンパイラに怒られてる頃だしもうちょっと待ってやろうぜwwwwww

**デフォルトの名無しさん** · 2017/10/25(水) 20:35:19.01

rustスレよりもりあがっとるやんここ

**デフォルトの名無しさん** · 2017/10/25(水) 20:59:03.30

cに名前空間とラムダとattribute((cleanup))が入るだけでもだいぶ助かるのに。
なんでcの規格のバージョンアップは遅いんだ？
c++みたく3年毎にしてくれたらいいのに。

**デフォルトの名無しさん** · 2017/10/25(水) 21:12:25.50

>>142
あそこモジラの工作員しかいねえし

Rustが言語ですらないただの汚物って正しい認識を共有できる人がちゃんといるのは素晴らしいと思う

**デフォルトの名無しさん** · 2017/10/25(水) 22:58:44.78

>>143
C++みたく闇鍋状態にしたくないからだろ。

**デフォルトの名無しさん** · 2017/10/25(水) 23:13:35.98

モジラが2ch見てるわけねーだろ
糖質かよ

**デフォルトの名無しさん** · 2017/10/25(水) 23:16:03.33

rustをそこまで毛嫌いする必要もないと思うけどな
rustのメモリオーナーシップモデルとかコードの改善に貢献するという話もあるし
ちょっと気にはなってる。

**デフォルトの名無しさん** · 2017/10/26(木) 00:20:17.07

rustアンチって同一人物だろ
コンパイル通らなくてイライラしてるんだね＾＾
コテ付けて、どうぞ

**デフォルトの名無しさん** · 2017/10/26(木) 00:21:04.60

rustは何がそんなに駄目なんだろ
そこ迄言われると学びたくなってくる

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

>>149
他の言語にはない所有権システムが原因で学習コストが高い
使いこなせば強力だけどとても難しい機能
それで使いこなせてない人が「コンパイル通らない」って発狂してる

例えると、初めてHaskell言語触る人が「変数に代入出来ないから何も出来ない！Haskellは欠陥言語！」って言ってるような物

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

rustのコンパイルを通せない低級汚グラマーが
嫉妬で腐してるだけだろ

腐ってるのはテメーの言語センスだろってね

**デフォルトの名無しさん** · 2017/10/26(木) 00:32:53.75

Haskell言語って何だ
夜は誤字増えるから寝よう

**デフォルトの名無しさん** · 2017/10/26(木) 00:50:43.34

>>150
なるほど、でも面白そうだな

パフォーマンスは良いって聞くし
haskellも好きだし一通り触ってみるかな

**デフォルトの名無しさん** · 2017/10/26(木) 03:24:21.96

まあ御託はいいからデータコピーなしの平衡二分木をRustで書いてからにしてくれよ
Cのコードは出たぞ

**デフォルトの名無しさん** · 2017/10/26(木) 05:10:18.37

Haskellなら副作用だらけのコードは断固拒否するだけだが
Rustで副作用を拒否すると延々と粘着されそう

ついでにPythonは静的型を拒否するだけだが
Goはジェネリクスがない件で永久にいじめられるんだろう

**デフォルトの名無しさん** · 2017/10/26(木) 07:04:11.52

Haskellは速さは捨てて副作用を無くすことに全振りしてるけど、Rustはそうではないからな

**デフォルトの名無しさん** · 2017/10/26(木) 09:12:10.17

Rustはunsafeつかえば（ffiしたほうがはやいだろうが）できないことはないと思ってるんだが違うのかな？

**デフォルトの名無しさん** · 2017/10/26(木) 09:59:20.18

Goはいつものgoogleのフカしで持ち上げられてる感がプンプンするぜ。
単なる昔ながらのVM使ってない静的型付け言語を
システムプログラミングとかいうバズワードを作って
スクリプトしか描いたことない奴らにいかにも新しいものであるかのように錯覚させてる。

**デフォルトの名無しさん** · 2017/10/26(木) 10:42:13.95

>>157
初めからプログラム全体をunsafeで囲ってある状態を仕様にすればいいのにな

>>158
バズワードだろうがなんだろうが、速くて書きやすけりゃ正義よ

**デフォルトの名無しさん** · 2017/10/26(木) 10:47:47.28

最近は新しいOSSもGoで書かれてるの多くてうんざりする
再来年辺りには「Goは終わった」とか言われだしてScalaと同じ道を辿るのわかりきってるのにWeb系の馬鹿共は何度同じ間違いを繰り返すのか

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

個人的にはDが一番純粋なc++ 後継って感じで頑張って欲しいんだけどなぁ
まったく流行る兆しがない……
別に新しい言語を求めてるんじゃないんだ。c++ からc互換を取り除いて標準ライブラリと文法見直してくれるだけでいいんだ

**デフォルトの名無しさん** · 2017/10/26(木) 11:45:28.73

>>160
「新しいOSSもGoで書かれてるのが多」いのに
「再来年辺りには『Goは終わった』とか言われだ」すのか。すげえな

まあGo2.0の漏れ聞く噂によると可能性なくもないんだが

**デフォルトの名無しさん** · 2017/10/26(木) 11:47:37.13

>>161
GC言語な時点でそりゃねえわ
全く同じ理由でGoもC++の完全な後継ではないと思ってるけど

**デフォルトの名無しさん** · 2017/10/26(木) 11:54:33.47

>>162
Scalaという前例があるからね
特にビッグデータ系はScalaのOSSが多くて悲惨だよ
壮大な糞の山が残されてしまった

**デフォルトの名無しさん** · 2017/10/26(木) 12:17:09.48

>>164
Scalaが廃れた理由は、言語のバージョンアップ戦略がクソofクソだったってのと
コンパイル回りの性能が悪いっていう言語自体の特徴、
それから置き換えを狙っていたはずのJavaの進化に取り残されたことっていう色々と複合的な原因がある

Goがその後追いをするかって言われると、
少なくとも書きやすさの面でC++がGoに勝てる目は向こう5年はないだろうし、
バージョン戦略は少なくとも1系の間は下位互換性崩さんだろうしな

**デフォルトの名無しさん** · 2017/10/26(木) 12:19:58.53

不安があるとするなら、なんか1系と完全に互換性なくすとか言われてるGo2.0なんだよな
この辺の方針次第では、おっしゃる通り再来年にはゴミの山になってる可能性が無視できない

Swiftがクソバージョンアップでもなんとか成功してるのはプラットフォーム囲い込んでるのがでかい

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

AA木のRust版の移植を練習がてらやったぞ。
みんなunsafeが必要とか言ってるが、別に必要なくない？
ポインタ演算もサイズの違う型の変換もしてるわけじゃないから生ポインタ扱う必要ないと思うんだけど。
だた、マジで愚直に移植したから全くRustっぽくはないし、
俺がバカなだけで無駄なオーバーヘッドが気づかんうちにいっぱい発生してるかもだから指摘よろしく。
一応何回か適当にinsertとremoveして正しく動いてるとこまでは確認してる。
みんなunsafe使わないとダメ的なこと言ってるから正直これでいいのか全然自信がない。

**デフォルトの名無しさん** · 2017/10/26(木) 12:28:38.79

#[derive(Debug)]
struct Tree {
value: i32,
left: Option<Box<Tree>>,
right: Option<Box<Tree>>,
level: isize,
}

fn level(root: &Option<Box<Tree>>) -> isize {
if root.is_none() {
return 0;
}
root.as_ref().unwrap().level
}

fn left_end(root: &Option<Box<Tree>>) -> &Option<Box<Tree>> {
if root.is_none() {
root
} else if root.as_ref().unwrap().left.is_none() {
root
} else {
left_end(&root.as_ref().unwrap().left)
}
}
（続く）

**デフォルトの名無しさん** · 2017/10/26(木) 12:29:34.82

fn right_end(root: &Option<Box<Tree>>) -> &Option<Box<Tree>> {
if root.is_none() {
root
} else if root.as_ref().unwrap().right.is_none() {
root
} else {
right_end(&root.as_ref().unwrap().right)
}
}

fn skew(mut root: Option<Box<Tree>>) -> Option<Box<Tree>> {
if root.is_none() {
return root;
} else if root.as_ref().unwrap().left.is_none() {
return root;
} else if root.as_ref().unwrap().left.as_ref().unwrap().level != root.as_ref().unwrap().level {
return root;
}
let mut left = root.as_mut().unwrap().left.take();
root.as_mut().unwrap().left = left.as_mut().unwrap().right.take();
left.as_mut().unwrap().right = root;
left
}
(まだ続く)

**デフォルトの名無しさん** · 2017/10/26(木) 12:30:37.02

fn split(mut root: Option<Box<Tree>>) -> Option<Box<Tree>> {
if root.is_none() {
return root;
} else if root.as_ref().unwrap().right.is_none() {
return root;
} else if root.as_ref().unwrap().right.as_ref().unwrap().right.is_none() {
return root;
} else if root.as_ref().unwrap().right.as_ref().unwrap().right.as_ref().unwrap().level != root.as_ref().unwrap().level {
return root;
}
let mut right = root.as_mut().unwrap().right.take();
root.as_mut().unwrap().right = right.as_mut().unwrap().left.take();
right.as_mut().unwrap().left = root;
right.as_mut().unwrap().level += 1;
right
}

**デフォルトの名無しさん** · 2017/10/26(木) 12:31:04.94

fn decrease_level(mut root: Option<Box<Tree>>) -> Option<Box<Tree>> {
if root.is_none() {
return root;
}
let left_level = level(&root.as_ref().unwrap().left);
let right_level = level(&root.as_ref().unwrap().right);
let mut expected_level = 0;
if left_level < right_level {
expected_level = left_level + 1
} else {
expected_level = right_level + 1
}
if expected_level < root.as_ref().unwrap().level {
root.as_mut().unwrap().level = expected_level;
if root.as_ref().unwrap().right.is_some() {
if expected_level < root.as_ref().unwrap().right.as_ref().unwrap().level {
root.as_mut().unwrap().right.as_mut().unwrap().level = expected_level;
}
}
}
root
}

**デフォルトの名無しさん** · 2017/10/26(木) 12:31:51.05

fn insert_tree(mut root: Option<Box<Tree>>, value: i32) -> Option<Box<Tree>> {
if root.is_none() {
root = Some(Box::new(Tree {
value: value,
left: None,
right: None,
level: 1, }));
} else if value > root.as_ref().unwrap().value {
root.as_mut().unwrap().right = insert_tree(root.as_mut().unwrap().right.take(), value);
} else {
root.as_mut().unwrap().left = insert_tree(root.as_mut().unwrap().left.take(), value);
}
root = skew(root);
root = split(root);
root
}

**デフォルトの名無しさん** · 2017/10/26(木) 12:34:16.58

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().value = succ;
} else {
let pred = {
let end = right_end(&root.as_ref().unwrap().left);
end.as_ref().unwrap().value
};
root.as_mut().unwrap().left = remove_tree(root.as_mut().unwrap().left.take(), value);
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); }

関数途中です（1レスに収まらんかった）

**デフォルトの名無しさん** · 2017/10/26(木) 12:37:30.92

root = decrease_level(root.take());
root = skew(root.take());
root.as_mut().unwrap().right = skew(root.as_mut().unwrap().right.take());
if root.as_ref().unwrap().right.is_some() {
root.as_mut().unwrap().right.as_mut().unwrap().right = skew(root.as_mut().unwrap().right.as_mut().unwrap().right.take());
}
root = split(root.take());
root.as_mut().unwrap().right = split(root.as_mut().unwrap().right.take());
root
}
終わり。
クソコードの上に長くてほんとすんません。

あと、おもてのコードでは一度もunsafeは使ってはないけど
Option型のtakeメソッドが所有権を誤魔化すために裏でunsafe使ってる。
あとは、裏でも使ってないと思う。

**デフォルトの名無しさん** · 2017/10/26(木) 12:39:25.88

Rustトーシロの初見だけどこんなにunwrap必要なの怖いって気分になるな……
CのポインタをOption<Box<>>で表現してるからしゃーないとはいえ

**デフォルトの名無しさん** · 2017/10/26(木) 12:39:26.85

ここまでやったらもう飽きた。
誰かメソッド構文とかコンビネータとかをきちんと使ったRustyなコードに書き換えて。

あ · 2017/10/26(木) 12:42:49.23

Rust嫌いな奴はCをすぐ引き合いに出すが、misraの案件やったら死ぬんじゃねえかなって思う。

GC言語も悪くはないぞ。ちゃんとGCの動き考えれば、正しく開放「されてない」理由もわかるだろ。
最初からデカイ配列を握って離さない、それを切り貼りして使う、みたいなJavaのプロジェクトあるしな。

**デフォルトの名無しさん** · 2017/10/26(木) 12:50:10.86

>>175
あくまでも愚直に書いてるからこんなにunwrapとas_refとas_mutだらけになる。
if letとかコンビネータとかをきちんと使えばこんなひどいコードにはならないよ。

**デフォルトの名無しさん** · 2017/10/26(木) 16:47:19.95

rustのコード<>だらけで読みにくい
これはlispの括弧みたいに慣れたら読みやすいものなのか？

**デフォルトの名無しさん** · 2017/10/26(木) 17:58:11.26

>>153
難しいとは言ってもOOP→関数型のパラダイムシフトに比べれば簡単だけどね

**デフォルトの名無しさん** · 2017/10/26(木) 20:01:45.08

>>154
おい、お前でてこいよ

**デフォルトの名無しさん** · 2017/10/26(木) 21:09:45.15

rust も haskell も理解できても面倒だし無駄に言語に気使ってるだけじゃねーかって
思うんだが、信者はききやしない。。
「お前らは理解できないものを理解できる俺偉い」で思考停止しちゃってんだよ。

**デフォルトの名無しさん** · 2017/10/26(木) 21:15:34.16

一番言語に気を遣わないといけないのはC++だがなｗ