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

次世代言語Part7[Go R ..

2:デフォルトの名無しさん
17/10/19 17:56:35.46 EPSDvC75.net
そろそろSwiftとTypeScript入れときたかったので

3:デフォルトの名無しさん
17/10/19 19:23:30.17 33xh/nBB.net
5chってなんだよ

4:デフォルトの名無しさん
17/10/19 19:35:46.24 C3Fl3waR.net
２ちゃんねる、正式に「５ちゃんねる」に名称変更！色々あって5chが誕生！
URLﾘﾝｸ(www.yukawanet.com)

5:デフォルトの名無しさん
17/10/19 23:31:42.71 nu6ztsFr.net
TSは普通に現代だろ
生JSはもうやれない

6:デフォルトの名無しさん
17/10/19 23:43:07.41 1zFRkFBm.net
生JSもVSCodeによってコード補完がTypeScriptと比べてさほど遜色ないレベルにまで引き上げられたからなあ
結局MSが本気で開発環境を作ればどんな言語でもゴリ押しできることが証明されてしまった

7:デフォルトの名無しさん
17/10/20 00:38:29.46 2lESXdgM.net
次世代というか、2010年代の企業発の静的型付け言語でまとめてみた
まだ載ってないのだとNim Hack Julia Crystal辺りがいいのかな

8:デフォルトの名無しさん
17/10/20 01:01:22.11 eMg2A2/G.net
>>6
限定的な型補完のみだろ
静的チェックには絶対型が必要

9:デフォルトの名無しさん
17/10/20 01:56:31.26 Ka6W9rl7.net
>>6
JS含む動的言語は大抵ダックタイピングって時点で補完が効かないじゃん。
個人的には「ダックタイピングのほうがインターフェース書かなくて済むから
手軽で良い」って言ってる奴がマジで理解できん
補完できなきゃどのメソッド呼べるのかいちいちコードかドキュメント見に行かんとならんからむしろ面倒

10:デフォルトの名無しさん
17/10/20 02:15:40.71 yLtxI7rs.net
>>9
型が決まってれば動的言語だろうと補完できるでしょ

11:デフォルトの名無しさん
17/10/20 02:54:33.08 Ka6W9rl7.net
>>10
JSDocに型を書いてないコードとかあったら発狂したくならない?
仕事じゃ周りのアホどもが書いてくれないからよくにあるんだけど

12:デフォルトの名無しさん
17/10/20 03:57:09.23 YyMx7jsp.net
>>9
最初にコード補完をIDEに組み込んだのは動的言語

13:デフォルトの名無しさん
17/10/20 04:05:45.74 Ka6W9rl7.net
>>12
それは知らんかった
何て言語?

14:デフォルトの名無しさん
17/10/20 05:20:27.14 VprmOZRL.net
>>13
皆さんよくご存じのVBです。

15:デフォルトの名無しさん
17/10/20 06:44:15.18 dSzguJuu.net
>>14
バカいうんじゃないSmalltalkに決まっとるがな

16:デフォルトの名無しさん
17/10/20 06:50:33.12 VprmOZRL.net
>>15
URLﾘﾝｸ(en.wikipedia.org)

17:デフォルトの名無しさん
17/10/20 07:06:06.25 eMg2A2/G.net
>>9
ﾎﾝｺﾚﾝｺﾞ

18:デフォルトの名無しさん
17/10/20 11:11:11.05 P8/EFRxC.net
>>16
何を調べるにしてもウィキペ情報は参考程度に留めておいたほうがいいよ
ご多分に漏れずこの件に関しても間違っていてちょっとググっただけでも
少なくとも1980年代にはコンテキストを考慮した補完機能を有するAliceというPascalのIDEが出ていることがわかる
URLﾘﾝｸ(www.atarimagazines.com)
だから動的言語が初かの真偽はともかくVBがしかも1990年代にもなってから「最初」ということはあり得ない

19:デフォルトの名無しさん
17/10/20 13:06:03.49 6HQ5gdkc.net
動的か静的かよりも暗黙に型変換するのかしないのかのが重要。

20:デフォルトの名無しさん
17/10/20 14:49:05.79 RMJRt52l.net
typescriptの凄さってIDEの機能言語に組み込んだことだよな。
リファクタリングの機能を言語に用意してるから、
どのエディターでも使える。

21:デフォルトの名無しさん
17/10/20 14:53:55.28 yLtxI7rs.net
>>16
>>18
Wikipediaが間違ってるんじゃなくてお前らの読み方が間違ってるだけだろ
最初にコード補完をIDEに組み込んだのはVBなんて事どこにも書いてない

22:デフォルトの名無しさん
17/10/20 14:55:26.74 yLtxI7rs.net
>>11
JSDocとコード補完と何か関係あるの？

23:デフォルトの名無しさん
17/10/20 18:06:03.89 yevn4/qi.net
折角の補完機能ガン無視してVimで書いててすまん
Vimに補完つけると重いんだよな

24:デフォルトの名無しさん
17/10/20 18:12:51.51 UMfeFQLW.net
vimの補間が重い…？

25:デフォルトの名無しさん
17/10/20 18:49:47.42 yevn4/qi.net
Jedi-vimとか謎に重くならん？
あれ？そうでもない？

26:デフォルトの名無しさん
17/10/20 18:59:15.83 YvXWjlAq.net
>>20
MSは昔からやってるけどね
MSにとって目新しいのは、コンパイラ及びエディタをコード補完やリファクタリングに対応させるためのオープンなプロトコルを策定したこと
これほど早い段階でそのレベルにまで達するのはMSにしかできないこと

27:デフォルトの名無しさん
17/10/20 21:43:00.33 x/nMj/Ym.net
誰だよ未だにプログラミング言語未満のRustをスレタイにいれてるやつ
ハロワ以上のプログラムをことごとくコンパイル弾く欠陥品、言語としての体をなしていない

28:デフォルトの名無しさん
17/10/20 22:07:39.64 6WjQxFol.net
普通にrestでwebserverたててるが…

29:デフォルトの名無しさん
17/10/20 22:07:46.81 6WjQxFol.net
Rustね

30:デフォルトの名無しさん
17/10/20 22:29:29.77 dSzguJuu.net
名前間違う時点でろくすっぽ使ってないのバレバレ

31:デフォルトの名無しさん
17/10/20 22:33:08.26 6WjQxFol.net
晩酌してたのとRest APIと混ざったんだよ
めちゃめちゃ使ってるっちゅーの

32:デフォルトの名無しさん
17/10/20 23:15:48.68 KNQSc5p/.net
自動補完は正直うざいからオフにする

33:デフォルトの名無しさん
17/10/20 23:58:05.68 K0f4yEve.net
>>31
じゃあさくっと木構造実装してみてよ

34:デフォルトの名無しさん
17/10/21 00:09:44.49 WA0WypxL.net
>>33
ほい
enum Tree<T> {
Leaf(T),
Node(Box<Tree<T>>, Box<Tree<T>>),
}

35:デフォルトの名無しさん
17/10/21 00:44:54.19 DO/riCmW.net
まあそれが一番素直な実装だね。
問題は循環するかもなグラフの場合。持ち主が曖昧になるから。

36:デフォルトの名無しさん
17/10/21 01:18:33.12 EatcavDb.net
>>34
データ構造定義だけ書かれてもな
それに対して余計なアロケーション発生させずにappendとdelete実装してみてくれよ
できるもんなら

37:デフォルトの名無しさん
17/10/21 02:15:10.99 VqKLKVGY.net
問題はTypeScriptに対して競合としてflowがあることだよな。
Reactを使うのにTypeScript使っててすごく便利なんだけどReactがflow押ししそうで怖い。

38:デフォルトの名無しさん
17/10/21 03:03:32.99 WA0WypxL.net
>>36
まずはCかC++でお前の言う無駄なアロケーションのないappendとdelete付きの木構造とやらを書け。
そしたらそれをRustで書き直してやるよ。

39:デフォルトの名無しさん
17/10/21 05:46:24.53 VmqPmNn/.net
>>37
Web系に言語は作れないってのはさすがにCoffeeやDartで世間に理解されたと信じたい

40:デフォルトの名無しさん
17/10/21 10:28:21.87 wl/wLs0J.net
>>20
IDEの機能を言語に組み込むぐらい、LISPもSmalltalkもとっくの昔にやってるじゃん。

41:デフォルトの名無しさん
17/10/21 10:29:25.77 wl/wLs0J.net
おまえらが次世代と呼んでいる機能のほとんどが60年代の再発明だなw

42:デフォルトの名無しさん
17/10/21 11:01:34.95 sh0YDQHh.net
>>37
うちの案件フロウ使ってるわ
最初の技術選定でクソ馬鹿野郎が生JS選択したせい
しかも途中で辞職、いやいなくなってくれてせいせいしたが
んで、どうしようもないから後付けでフロウ
クソみたいな生JSに後から挿入れられるのはメリットだわな
ライブラリの対応はゴミだけど

43:デフォルトの名無しさん
17/10/21 11:46:16.50 DO/riCmW.net
>>41
まあそういうところもあるけど、Rust なんかはだいぶ機能を整理した方かなとは思うよ。
実際に作って使ってみるとボローイングの解決しづらさがよくわかるってのはある。
理�

44:_と実践は繰り返してなんぼ。

45:デフォルトの名無しさん
17/10/21 12:04:58.67 SwYl7d2P.net
言語レベルのリファクタリングを備えたTypeScript 2.5がリリース
URLﾘﾝｸ(www.infoq.com)

46:デフォルトの名無しさん
17/10/21 13:02:01.91 VqKLKVGY.net
>>42
Typescriptも該当ディレクトリ内にXXXX.d.ts(XXXは生jsのファイル名)を置くだけで
型が付与できるけどな。しかも生jsの箇所をいじらずに。
どっちがいいかは何とも言えないが。

47:デフォルトの名無しさん
17/10/21 13:03:37.91 VqKLKVGY.net
jsというかTypeScriptを使ってるんだけど。async-awaitマジでいいわ
と思ったが例えばclassのコンストラクタをasync対応してくれたらな～って思うわ
初期化時に非同期関数使いたいと詰む。

48:デフォルトの名無しさん
17/10/21 13:38:53.78 ZiJpfJlj.net
>>46
c#でずいぶんお世話になってるから嬉しいわ

49:デフォルトの名無しさん
17/10/21 13:51:38.02 sh0YDQHh.net
>>45
ま？

50:デフォルトの名無しさん
17/10/21 14:20:00.52 SGUxbDYw.net
>>46
わざわざasyncのinitializeメソッド作るの馬鹿らしいよな、仕方ないんだけど

51:デフォルトの名無しさん
17/10/21 14:32:26.28 7p4/5GBE.net
>>46
constructor() {
　(async () => {
　 await this.hogeAsync();
　})();
}
インスタンス作成側ではawait newとかできないけど、分かってて使えば
今のとここれで特に問題ないわ。

52:デフォルトの名無しさん
17/10/21 18:32:34.18 VqKLKVGY.net
>>50
非同期関数がそのクラスの生成タイミングで終わる保証無いだろ。
大概ストレージとかネットワークアクセスしてるわけだし。
それで事足りてんの？マジで？

53:あ
17/10/21 18:53:01.32 RC5niii9.net
>>9
使ってみたらわかるが、ちょっと頭おかしいレベルで補完効くぞ。
関数の型が、「Date | "不正日付" | "演算不能"」と、stringの中身まできちんと出してきたときにはびっくりした。

54:デフォルトの名無しさん
17/10/21 19:06:53.76 guA6ZzKE.net
コンストラクタ非同期にしたい時は>>51の言ってる問題があるから、値をセットするだけのprivate constructor準備してpublicは別に公開したほうがいい
例↓
class Hoge{
private constructor(public foo:string){}
async create():Promise<Hoge>{
const foo=await asyncFunction();
return new Hoge(foo);
}
}

55:デフォルトの名無しさん
17/10/21 21:09:59.24 sahtjmhq.net
>>41
lisper召喚したいのか?

56:デフォルトの名無しさん
17/10/21 22:04:06.57 HyKk2sND.net
Lisperとかもしいるなら是非来て欲しい

57:デフォルトの名無しさん
17/10/21 22:07:10.31 1X5jAkAY.net
LisperはSmalltalker以上にめんどくさいぞやめとけ

58:デフォルトの名無しさん
17/10/21 23:03:18.92 P/rJp3kV.net
>>43
> 理論と実践は繰り返してなんぼ。
同意

59:デフォルトの名無しさん
17/10/22 01:10:34.37 yUcYB3x3.net
めんどくささを恐れてはならぬ。

60:デフォルトの名無しさん
17/10/22 01:34:14.15 jKdYjftV.net
その通り
テキストエディタで打ったコードにこそ温もりがある
補完や静的解析なんて邪道
日本人ならPHPを使うべき

61:デフォルトの名無しさん
17/10/22 01:56:35.88 bmxwOMJ1.net
>>59
日本人ならとか言うんならRuby使えよ。。。
何でPHPなんだよアホちゃうかと。。。

62:デフォルトの名無しさん
17/10/22 02:06:21.14 ZsHOZNag.net
HSPだろ。

63:デフォルトの名無しさん
17/10/22 02:11:19.39 IdeA6XVs.net
ひまわりちゃうかな

64:デフォルトの名無しさん
17/10/22 05:30:54.86 MmMCQJb7.net
Elixirってダメなん？将来性ないの？
サーバーがCowboyとかいう変なやつになるからダメなのかな

65:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 09:43:14.05 jKdYjftV.net
>>60
偽装・不正・いい加減がモットーのジャップランド土人村にとって
PHPほど相性のいい言語はない
PHPは日本人なんだよ、わかるか？

66:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 11:54:18.65 r0jppfs8.net
>>52
それは裏でTypeScriptの型情報を再利用してる。
だから標準APIとか有名所は使える。でも自分でライブラリを作るととたんに効かなくなるぞ。

67:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 12:05:58.19 HAzBzhoi.net
>>52の内容なら型アノテーションに頼らずとも型推論だけでいけるだろう。

68:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 13:12:06.46 yUcYB3x3.net
>>63
将来性とかさ～自分で判断しろや。
それともここで将来性あるとか言われたらなんも考えずにその言語使っちゃうわけ？
将来メンテされなけりゃおれがやるくらいの気概をもって言語使ってほしいわ。

69:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 15:32:24.31 bmxwOMJ1.net
>>64
それはあくまで偏見の塊の君の個人的意見だろ。
そんなこと言い出したら
「日本人はもともと職人気質の人間が多いから
使いこなすのに職人レベルの技術が求められるC++と相性がいい。
だからC++こそ日本人のための言語だ。」
なんていう、今俺が適当に作ったトンデモ論法でも通っちまうだろうが。

70:あ
17/10/22 15:36:36.11 dq05v2c8.net
>>65
違うよ。自作関数の戻り値と、それが代入されてる変数のヒントに出る。
自分でライブラリ作ってもバッチリ出てくれるけど、doc書いといたら間違いは更にないな。

71:名無しさん＠そうだ選挙に行こう！ Go to vote!
17/10/22 15:57:37.80 rLFHcAK9.net
>>63
Elixirいいよ
将来性はコミュニティの頑張り次第
Phoenixはよく出来てる
実質的にWebアプリに用途が限定されるだろうから
このスレでは人気ない

72:デフォルトの名無しさん
17/10/22 20:08:52.70 yoTgiwcF.net
>>68
いや、日本人はPHPでしょ
空気読んで面倒臭いことはナーナーにして
今が良ければそれでよし
当事者がたんまりお金盗って無事退職した後、
年単位越しでツケ払って大騒ぎ
PHPですか？いいえ、日本です

73:デフォルトの名無しさん
17/10/22 21:46:29.44 c7gPCMa+.net
日本の技術力ガーとか言ってたくせに
結局全部嘘ばかり
バカチョン以下やでホンマ
そりゃペチパーが闊歩しますわ

74:デフォルトの名無しさん
17/10/22 23:53:22.71 sz7LIs8a.net
ponyはまだまだマイナーだな

75:あ
17/10/23 01:37:49.26 ko03P2Yp.net
>>72
多分お前よりはまともなもの作ってるとおもうわ。

76:デフォルトの名無しさん
17/10/23 03:02:27.50 vIdD1XI1.net
haskellがやっと外れたなｗスレタイ

77:デフォルトの名無しさん
17/10/23 03:18:43.18 7Pp5HgLl.net
PHp本当に速くなったからな
相変わらずポーリングも特殊操作でしかできないクソだけど

78:デフォルトの名無しさん
17/10/23 04:14:09.67 1oD0q36r.net
異常者の迷言「PHPは日本人」「日本人はPHP」

79:デフォルトの名無しさん
17/10/23 08:27:35.76 +M73J5jp.net
気に食わない奴でも合法なら許す
違法なら許さない
この優先順位を歪めるから無法地帯になるのだ

80:デフォルトの名無しさん
17/10/23 08:52:16.45 xr09IWoG.net
>>70
Elixirってrubyに強く影響受けてる言語なんだよな。
Phoenix触ってたらRailsの匂いを感じる。
でも今は動的言語は弱い気がする。Elixir + 型が欲しい
TypeScriptが触ってて気持ちいいからサーバサイドもJSがいい気がする。

81:デフォルトの名無しさん
17/10/23 10:51:25.73 WMNCDJb0.net
Elixirの問題は込み入ったことやるとErlangに足突っ込まなきゃいけないことで
プロダクションコードに突っ込むには人材要求が高すぎること

82:デフォルトの名無しさん
17/10/23 14:31:56.92 f3vYk0Y4.net
結局ネットワーク系統のエラー処理は低レイヤーに突っ込んでいかないとどうにもならんよ。
抽象レイヤーでなんとかしたいって願望はわかるけどさ。

83:デフォルトの名無しさん
17/10/23 17:32:43.36 KBSkknSp.net
Elixir（というかBEAM=ErlangVM)の場合はプロセス復活のために型情報が必要だし
静的にしたからって型情報は省略できない

84:デフォルトの名無しさん
17/10/23 19:47:51.56 fT3gFD4f.net
C++を書きたくないんだが代替言語は今だとrustとdどっちがゆうぼ？
最近はnimと言うのが注目されてるとも聞いたが……

85:デフォルトの名無しさん
17/10/23 20:22:06.86 ANMjmVZt.net
誠に残念ながら今そのポジションはGoの一強

86:デフォルトの名無しさん
17/10/23 20:45:12.65 LSzHPC1F.net
Cよりスピード出るのはNimだけ！

87:デフォルトの名無しさん
17/10/23 20:50:25.75 Y0tE+5bm.net
ジャップランド土人村企業が詐欺のために求めているのはPHPだけ！

88:デフォルトの名無しさん
17/10/23 21:14:10.32 kb3Oh+Sb.net
どうかんかえてもRustだろ

89:デフォルトの名無しさん
17/10/23 21:25:58.19 xr09IWoG.net
>>84
Goも弱点が多い言語だけど初期の学習コストとか考えると
rustよりGoかな。
もちろんrustもいいんだけどc++並に学習コスト高そう感ある。

90:デフォルトの名無しさん
17/10/23 21:47:48.94 C8zrSpyb.net
Rustは言語と名乗れる水準に達してないのでGo
深くシステムに触るのには向いてないがな

91:デフォルトの名無しさん
17/10/23 22:05:15.62 fT3gFD4f.net
Goなのか……
他言語が純粋な次世代Cを目指してる中、Goは微妙に設計思想が違うイメージだからあえて外したんだが……やっぱりgoogle正義なのか

92:デフォルトの名無しさん
17/10/23 22:05:44.54 f3vYk0Y4.net
>>83
c++ で何を書くつもりなの？
無理に c++ で書かなきゃならんものって最近は減ってると思うけど。

93:デフォルトの名無しさん
17/10/23 22:17:08.30 fT3gFD4f.net
>>91
c++ で書かれたオープンソースプログラムのdllプラグイン
悲しいことにc++ 選ぶ理由なんて結局既存ソースがc++ だからの理由に尽きる……

94:デフォルトの名無しさん
17/10/23 22:32:24.88 QdR3J7Zg.net
>>90
goとか言ってる連中の言うこと本気にするなよ。
goは数年周期でバズってるだけでC++の代替なら
Dかrustって考えは間違ってないしrust理解できないやつが
こことrustスレで騒いでるだけだぞ。
Dはもう流行らんだろうが、rustは学習コストより標準ライブラリの弱さが面倒。
自分で書くか外部ライブラリに依存しまくるかで基本的なスレッドプールすら無い。
低レベル向けだから結局自分で書くならrustでいいし、それが嫌ならDでいいよ。
rustとD位の差なら正直好みの差。

95:デフォルトの名無しさん
17/10/23 22:40:54.47 5YqbDQKx.net
>>92
ならやっぱりrustじゃない？
bindgen使えばc++のヘッダもパースしてc ffi用のglue code生成してくれる。
bindgenがどの程度まで万能かは俺もよくは知らんけど、
mozillaがfirefox quantumでservoとgeckoの橋渡しのために使ってるくらいだから
結構まともに動くんじゃないかとは思ってる。

96:デフォルトの名無しさん
17/10/23 23:08:38.91 Y0tE+5bm.net
おまんらの大好き　ぷ～えちピーーﾌﾞﾘﾌﾞﾘｯ　でも使えばええじゃろｗ

97:デフォルトの名無しさん
17/10/23 23:35:53.28 b+23gIO2.net
みんなサンクス。
Goは学習コスト低いらしいから後追いでもなんとかなりそうだし、とりあえずrustで書いてみることにするわ
一刻も早くc++ が絶滅する事を祈る

98:デフォルトの名無しさん
17/10/24 00:05:09.11 9ZgmGLcB.net
TypeScriptとGoを交互に触ってるけど
やっぱりnull安全な言語とそうじゃない言語の差が際立つな。
Goのほうは早速null pointerアクセスで落ちる。

99:デフォルトの名無しさん
17/10/24 00:39:57.10 7j3gEWSq.net
c++が絶滅したら今c++で書かれてる様々なコードベースが色んな言語に分裂するんだぜ
バベルの塔

100:デフォルトの名無しさん
17/10/24 00:51:24.05 MROfWTvM.net
バベルの塔を高くし過ぎたからしょうがないね

101:デフォルトの名無しさん
17/10/24 01:31:49.56 KQRKQofh.net
>>93
既存のまともに動いてるCコード移植しようとしてまともにコンパイルも通らなかった経験からまともな言語の水準に達してないといってるわけだが
少なくともRustでものが書けると信じこんでるお前よりはRust理解してるぞ

102:デフォルトの名無しさん
17/10/24 02:18:45.70 EjQaHC6N.net
>>100
お前が前に沸いたアンチと同一人物かどうかは分からんが、前に言った木構造をとっとと書きやがれ。
それすらできないならお前はC、C++もそもそもまともに出来てないんだから黙ってろ。
> 38
> >>36
> まずはCかC++でお前の言う無駄なアロケーションのないappendとdelete付きの木構造とやらを書け。
> そしたらそれをRustで書き直してやるよ。

103:デフォルトの名無しさん
17/10/24 07:07:12.19 ZX4BnJ5l.net
>>101
まずRustの木構造をちゃんと動くように書いてから言えよ

104:デフォルトの名無しさん
17/10/24 08:36:29.96 uX1ymmQB.net
rust で木構造云々言ってる奴って、コンパイラすら通せない rust コードしか書けない奴だろ。
Cで書いてあった平衡木のライブラリを rust に移植したけど、
> それに対して余計なアロケーション発生させずにappendとdelete実装してみてくれよ
こんなん普通に出来るぞ。
Option<Node> に get_or_insert() するだけ。
かなり苦労したのは木の回転だけど、それでも rust 用に頭を使ったら、
take() して mem::swap, mem::swap, mem::swap, そして代入の 5 行で終わり。
全体を通して余計なアロケーションなんて普通に無い。
rust は学習コスト結構高いけど、初歩の初歩で躓いた落ちこぼれ>>100,>>102 とかは何を言う権利も無いよ。

105:デフォルトの名無しさん
17/10/24 10:27:36.72 rYGI+fQg.net
Cのコードを示せないrustアンチは糞ゴミだけど、動くコードを示していない>>103も何も言えていない

106:デフォルトの名無しさん
17/10/24 11:02:52.32 pkngrV2F.net
自分の頭を撃ち抜くCのプログラム書いても運良く助かってる人は
Rustのコンパイル通せなくなるよね

107:デフォルトの名無しさん
17/10/24 11:29:48.61 Bfcpp5kd.net
そういう、Rustのコンパイルが通らなければ危険なコードって決めつけるRust信者本当にうぜえ
Rustが言語として表現できる範囲が狭いのをごまかすための方便でしかないのに

108:デフォルトの名無しさん
17/10/24 11:31:23.83 9ZgmGLcB.net
TypeScriptは本家のplaygroundを

109:触るだけで凄さが分かるんだけど https://www.typescriptlang.org/play/ rustってそういうのある？ちょっと試すとかできる？

110:デフォルトの名無しさん
17/10/24 11:33:53.63 Pu0WJP1A.net
>>105
自分の頭というよりユーザーにデバッグのコストを転嫁して儲けてるな
運が良いというより確信犯的に

111:デフォルトの名無しさん
17/10/24 13:43:56.97 wa8jpGkt.net
>>107
ググるとかしない人？単にTypeScript宣伝したいだけ？
URLﾘﾝｸ(play.rust-lang.org)
もとよりゆるふわTypeScript使いがRustのコンパイルを通せるとも思えないので端から試す気ゼロだろうけど…

112:デフォルトの名無しさん
17/10/24 13:56:01.66 Bfcpp5kd.net
選ばれた人しかコンパイラ通せない言語とかそれプログラミング言語って言えないよね

113:デフォルトの名無しさん
17/10/24 14:30:25.93 9ZgmGLcB.net
>>109
そこは知ってるけど全然補完が効かないんだけど。rust使いは
しょぼいエディターで頑張る感じ？
TypeScriptはplaygroundから補完が効きまくって楽しい。

114:デフォルトの名無しさん
17/10/24 16:07:36.55 0CxPdYg4.net
AltJSであるtsとRustのブラウザ上で動くplaygroundの機能差を語りたかったの？マジで？
Rustサゲしてる人はこの程度ってレッテル貼っていいの？

115:デフォルトの名無しさん
17/10/24 16:17:29.04 VubGQCWP.net
単にプロダクト開発のスキルの違いだな
MSの開発環境チームのメンバーはHelloWorldの代わりにインテリセンス実装するんだろう

116:デフォルトの名無しさん
17/10/24 16:23:54.68 rmRTTRfd.net
>>112
単純にPlaygroundの質からして違うってだけの話だろ
その程度もみとめられないよかよ

117:デフォルトの名無しさん
17/10/24 18:42:18.67 bbIPnu9e.net
なぜrustの対抗馬にTypeScriptが挙がるのかまるで理解できない
用途が全然違うだろ……

118:デフォルトの名無しさん
17/10/24 19:07:54.15 x0LH18ak.net
WebAssemblyが期待されてるから、あながち間違いでもない

119:デフォルトの名無しさん
17/10/24 21:40:46.56 eZrIsy4p.net
>>113
ほんとMSってそういう所は笑えるくらいすごいよな
Rust開発者たちも見習ってほしい
一応rustもコード補完にrlsとかいうヤツあるけどなんかまだいまいちなんだよな。
vscodeにrust(rls)っていうエクテンション入れて使ってるんだけど、
クロージャ書いてるときは補完が効かないのは俺だけ？
あとlint?(エラー・警告を赤・緑の下線で表示してくれるやつ)が
時々なんの前触れもなく急に無反応になるんだけどそれも俺だけ？

120:デフォルトの名無しさん
17/10/24 22:14:01.00 FaGN7Q1b.net
少人数のMS社員が片手間でVSCode作ってみたら一瞬で天下獲れちゃいましたというチート集団
MSがRust推せば余裕でGo潰してベターC++の定番を奪えるだろうな

121:デフォルトの名無しさん
17/10/24 22:51:21.66 z3aqO0G+.net
片手間ってことはないし、エディタ作成なんてのは人数増やせばいいものでもない。
まあチート軍団ってのは確かだけど。
しかし Rust とか c++ みたいに教条主義的な言語ってやっぱ信者が湧くね。
わかりやすくていいとは思うけど。

122:デフォルトの名無しさん
17/10/24 23:14:23.65 MOiTAdLh.net
片手間とか余裕とか、良い子は絶対に真似してはいけない情報ばっかり教えるんだよな
そんなところに信者を集めたら怠け者の集団ができそうだ

123:デフォルトの名無しさん
17/10/25 00:51:09.03 KYsAJ7k0.net
>>36じゃないけど、雑に平衡木（AA木）Cで実装してみた。
つってもWikipediaのまるコピだが。
#include <stdio.h>
#include <stdlib.h>
typedef struct tree {
int value

124:; 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); } } （続く）

125:デフォルトの名無しさん
17/10/25 00:51:31.44 KYsAJ7k0.net
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;
}
（まだ続く）

126:デフォルトの名無しさん
17/10/25 00:52:33.16 KYsAJ7k0.net
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;
}
（続く）

127:デフォルトの名無しさん
17/10/25 00:52:56.15 KYsAJ7k0.net
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;
}

128:デフォルトの名無しさん
17/10/25 00:53:17.67 KYsAJ7k0.net
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;
}
肝心の関数まで遠いなほんと

129:デフォルトの名無しさん
17/10/25 00:55:17.25 KYsAJ7k0.net
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;
}
おしまい。まじこんなクソコードに何レスもついやしてすまん。

130:デフォルトの名無しさん
17/10/25 00:56:55.22 KYsAJ7k0.net
改めて書いてみて思ったが、平衡木って平衡保つための操作がポインタのつけかえ多くて
確かにRustにはキツそうだなとか思ったり
データコピーなし縛りで実装するのはRust歴1週間の自分には無理そうだ

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

132:デフォルトの名無しさん
17/10/25 01:53:05.61 KYsAJ7k0.net
そういう、どうしても生ポインタごそごそつけかえる必要がある基幹アルゴリズムは、unsafeでくるんでやれって感じなのかね
実際この平衡木の実体が複数スレッドから独立に操作されるとか考えると割と困る

133:デフォルトの名無しさん
17/10/25 06:54:35.09 2hh4Hzpf.net
gitみたいに、古いデータを消去することなく
しかも変更のない部分はいちいちコピーしないアルゴリズムを考えるんだ
そうすれば古い方のデータに別スレッドから安全にアクセスできるよ

134:デフォルトの名無しさん
17/10/25 10:38:32.59 1aquIA8S.net
結局たかが赤黒木すらRustでは書けないって認識でいいの？
ほんとプログラミング言語名乗るなよ

135:デフォルトの名無しさん
17/10/25 10:59:08.02 2hh4Hzpf.net
>>131
その認識は間違いだけど正解を無料で教えてくれるボランティアが足りないね
GNUみたいなボランティアがいっぱいいないとプログラミング言語を名乗れないのが現実

136:デフォルトの名無しさん
17/10/25 11:14:21.26 j3LwAfcI.net
Rustの問題は後発のくせにIDE連携が弱すぎる。
KotlinとかSwiftとか後発の言語は大概IDEと一緒に提供してるから
最初から補完がきっちり効く。
Goも昔はイマイチだったけど改善してるから許せる。
TypeScriptは言語そのものにIDE連携のための機能をたっぷり盛り込んでいるから
見習ってほしいって話。
初学者程IDE連携が必要だからな。言語仕様が優れてていても
ツールとして使い勝手が良くなきゃ使わんよ。
それにRustの立ち位置って
OS開発とブラウザ開発くらいしかメリットが思い浮かばんのだけども
CLIならGoだし
WebならPHPとかRubyとかGoとか乱立状態だし
WEBのクライアントサイドならTypeScriptだし
スマホならKotlinかSwiftかObjC
このどこにRustが入り込むの？

137:デフォルトの名無しさん
17/10/25 11:47:25.56 2hh4Hzpf.net
そもそもC++があまり成功してないから改善するためにRustがある
C/C++と合計して考えるとJavaより上だけど合計しなければC++は成功してないよ

138:デフォルトの名無しさん
17/10/25 12:31:23.13 L5aebztM.net
C++が成功してないwwwwwwwwwww
どこの平行宇宙ですかwwwwwwwwwwwwwwwww

139:デフォルトの名無しさん
17/10/25 13:46:26.44 egHPItlD.net
まあ c++ がうまくいってればこんなに言語がたくさんできることはなかっただろうね。
c++ の存在意義は今や高級な機能をどれだけランタイム速度落とさずに入れられるのかの
実験場って位置づけかな。

140:デフォルトの名無しさん
17/10/25 13:55:53.69 L5aebztM.net
C++は完璧な言語だとか口が割けても言えないのは間違いないが、Rustなんて言語ですらない汚物使うくらいならC++使うわなあ

141:デフォルトの名無しさん
17/10/25 15:45:07.57 +h/lSeC6.net
ID:KYsAJ7k0のコードのRust版まだー？

142:デフォルトの名無しさん
17/10/25 16:40:52.54 GfXNw50M.net
>>133
rlsあるし十分やん

143:あ
17/10/25 18:10:38.69 Wj9s3Y5p.net
TSは手段と目的がたまに入れ替わるのが見てるとちょっもモヤモヤするな。
C#が最近もう一度好きになってきた。

144:デフォルトの名無しさん
17/10/25 19:10:42.88 ajBcpsg9.net
>>138
まあまあ今ごろコンパイラに怒られてる頃だしもうちょっと待ってやろうぜwwwwww

145:デフォルトの名無しさん
17/10/25 20:35:19.01 rCcyDoqV.net
rustスレよりもりあがっとるやんここ

146:デフォルトの名無しさん
17/10/25 20:59:03.30 EAW9qNH5.net
cに名前空間とラムダとattribute((cleanup))が入るだけでもだいぶ助かるのに。
なんでcの規格のバージョンアップは遅いんだ？
c++みたく3年毎にしてくれたらいいのに。

147:デフォルトの名無しさん
17/10/25 21:12:25.50 7dSKsD7g.net
>>142
あそこモジラの工作員しかいねえし
Rustが言語ですらないただの汚物って正しい認識を共有できる人がちゃんといるのは素晴らしいと思う

148:デフォルトの名無しさん
17/10/25 22:58:44.78 egHPItlD.net
>>143
C++みたく闇鍋状態にしたくないからだろ。

149:デフォルトの名無しさん
17/10/25 23:13:35.98 GfXNw50M.net
モジラが2ch見てるわけねーだろ
糖質かよ

150:デフォルトの名無しさん
17/10/25 23:16:03.33 j3LwAfcI.net
rustをそこまで毛嫌いする必要もないと思うけどな
rustのメモリオーナーシップモデルとかコードの改善に貢献するという話もあるし
ちょっと気にはなってる。

151:デフォルトの名無しさん
17/10/26 00:20:17.07 9syp6YaG.net
rustアンチって同一人物だろ
コンパイル通らなくてイライラしてるんだね＾＾
コテ付けて、どうぞ

152:デフォルトの名無しさん
17/10/26 00:21:04.60 T1ShqX6y.net
rustは何がそんなに駄目なんだろ
そこ迄言われると学びたくなってくる

153:デフォルトの名無しさん
17/10/26 00:26:09.28 9syp6YaG.net
>>149
他の言語にはない所有権システムが原因で学習コストが高い
使いこなせば強力だけどとても難しい機能
それで使いこなせてない人が「コンパイル通らない」って発狂してる
例えると、初めてHaskell言語触る人が「変数に代入出来ないから何も出来ない！Haskellは欠陥言語！」って言ってるような物

154:デフォルトの名無しさん
17/10/26 00:31:32.93 zsf3GtyN.net
rustのコンパイルを通せない低級汚グラマーが
嫉妬で腐してるだけだろ
腐ってるのはテメーの言語センスだろってね

155:デフォルトの名無しさん
17/10/26 00:32:53.75 9syp6YaG.net
Haskell言語って何だ
夜は誤字増えるから寝よう

156:デフォルトの名無しさん
17/10/26 00:50:43.34 T1ShqX6y.net
>>150
なるほど、でも面白そうだな
パフォーマンスは良いって聞くし
haskellも好きだし一通り触ってみるかな

157:デフォルトの名無しさん
17/10/26 03:24:21.96 EtDTWIur.net
まあ御託はいいからデータコピーなしの平衡二分木をRustで書いてからにしてくれよ
Cのコードは出たぞ

158:デフォルトの名無しさん
17/10/26 05:10:18.37 IaYxMsud.net
Haskellなら副作用だらけのコードは断固拒否するだけだが
Rustで副作用を拒否すると延々と粘着されそう
ついでにPythonは静的型を拒否するだけだが
Goはジェネリクスがない件で永久にいじめられるんだろう

159:デフォルトの名無しさん
17/10/26 07:04:11.52 hnEjL22C.net
Haskellは速さは捨てて副作用を無くすことに全振りしてるけど、Rustはそうではないからな

160:デフォルトの名無しさん
17/10/26 09:12:10.17 ZXFAdbhr.net
Rustはunsafeつかえば（ffiしたほうがはやいだろうが）できないことはないと思ってるんだが違うのかな？

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

162:デフォルトの名無しさん
17/10/26 10:42:13.95 1t2EMvpb.net
>>157
初めからプログラム全体をunsafeで囲ってある状態を仕様にすればいいのにな
>>158
バズワードだろうがなんだろうが、速くて書きやすけりゃ正義よ

163:デフォルトの名無しさん
17/10/26 10:47:47.28 Y5WhyQQy.net
最近は新しいOSSもGoで書かれてるの多くてうんざりする
再来年辺りには「Goは終わった」とか言われだしてScalaと同じ道を辿るのわかりきってるのにWeb系の馬鹿共は何度同じ間違いを繰り返すのか

164:デフォルトの名無しさん
17/10/26 11:10:35.34 8qIiNs+I.net
個人的にはDが一番純粋なc++ 後継って感じで頑張って欲しいんだけどなぁ
まったく流行る兆しがない……
別に新しい言語を求めてるんじゃないんだ。c++ からc互換を取り除いて標準ライブラリと文法見直してくれるだけでいいんだ

165:デフォルトの名無しさん
17/10/26 11:45:28.73 xVKEuI/f.net
>>160
「新しいOSSもGoで書かれてるのが多」いのに
「再来年辺りには『Goは終わった』とか言われだ」すのか。すげえな
まあGo2.0の漏れ聞く噂によると可能性なくもないんだが

166:デフォルトの名無しさん
17/10/26 11:47:37.13 xVKEuI/f.net
>>161
GC言語な時点でそりゃねえわ
全く同じ理由でGoもC++の完全な後継ではないと思ってるけど

167:デフォルトの名無しさん
17/10/26 11:54:33.47 Y5WhyQQy.net
>>162
Scalaという前例があるからね
特にビッグデータ系はScalaのOSSが多くて悲惨だよ
壮大な糞の山が残されてしまった

168:デフォルトの名無しさん
17/10/26 12:17:09.48 xVKEuI/f.net
>>164
Scalaが廃れた理由は、言語のバージョンアップ戦略がクソof

169:クソだったってのとコンパイル回りの性能が悪いっていう言語自体の特徴、それから置き換えを狙っていたはずのJavaの進化に取り残されたことっていう色々と複合的な原因がある Goがその後追いをするかって言われると、少なくとも書きやすさの面でC++がGoに勝てる目は向こう5年はないだろうし、バージョン戦略は少なくとも1系の間は下位互換性崩さんだろうしな

170:デフォルトの名無しさん
17/10/26 12:19:58.53 xVKEuI/f.net
不安があるとするなら、なんか1系と完全に互換性なくすとか言われてるGo2.0なんだよな
この辺の方針次第では、おっしゃる通り再来年にはゴミの山になってる可能性が無視できない
Swiftがクソバージョンアップでもなんとか成功してるのはプラットフォーム囲い込んでるのがでかい

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

172:デフォルトの名無しさん
17/10/26 12:28:38.79 P+s05bng.net
#[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)
}
}
（続く）

173:デフォルトの名無しさん
17/10/26 12:29:34.82 P+s05bng.net
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
}
(まだ続く)

174:デフォルトの名無しさん
17/10/26 12:30:37.02 P+s05bng.net
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
}

175:デフォルトの名無しさん
17/10/26 12:31:04.94 P+s05bng.net
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
}

176:デフォルトの名無しさん
17/10/26 12:31:51.05 P+s05bng.net
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
}

177:デフォルトの名無しさん
17/10/26 12:34:16.58 P+s05bng.net
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レスに収まらんかった）

178:デフォルトの名無しさん
17/10/26 12:37:30.92 P+s05bng.net
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使ってる。
あとは、裏でも使ってないと思う。

179:デフォルトの名無しさん
17/10/26 12:39:25.88 xVKEuI/f.net
Rustトーシロの初見だけどこんなにunwrap必要なの怖いって気分になるな……
CのポインタをOption<Box<>>で表現してるからしゃーないとはいえ

180:デフォルトの名無しさん
17/10/26 12:39:26.85 P+s05bng.net
ここまでやったらもう飽きた。
誰かメソッド構文とかコンビネータとかをきちんと使ったRustyなコードに書き換えて。

181:あ
17/10/26 12:42:49.23 +cEqlMCT.net
Rust嫌いな奴はCをすぐ引き合いに出すが、misraの案件やったら死ぬんじゃねえかなって思う。
GC言語も悪くはないぞ。ちゃんとGCの動き考えれば、正しく開放「されてない」理由もわかるだろ。
最初からデカイ配列を握って離さない、それを切り貼りして使う、みたいなJavaのプロジェクトあるしな。

182:デフォルトの名無しさん
17/10/26 12:50:10.86 P+s05bng.net
>>175
あくまでも愚直に書いてるからこんなにunwrapとas_refとas_mutだらけになる。
if letとかコンビネータとかをきちんと使えばこんなひどいコードにはならないよ。

183:デフォルトの名無しさん
17/10/26 16:47:19.95 hnEjL22C.net
rustのコード<>だらけで読みにくい
これはlispの括弧みたいに慣れたら読みやすいものなのか？

184:デフォルトの名無しさん
17/10/26 17:58:11.26 9syp6YaG.net
>>153
難しいとは言ってもOOP→関数型のパラダイムシフトに比べれば簡単だけどね

185:デフォルトの名無しさん
17/10/26 20:01:45.08 mFTohykf.net
>>154
おい、お前でてこいよ

186:デフォルトの名無しさん
17/10/26 21:09:45.15 LcYnzbeR.net
rust も haskell も理解できても面倒だし無駄に言語に気使ってるだけじゃねーかって
思うんだが、信者はききやしない。。
「お前らは理解できないものを理解できる俺偉い」で思考停止しちゃってんだよ。

187:デフォルトの名無しさん
17/10/26 21:15:34.16 hnEjL22C.net
一番言語に気を遣わないといけないのはC++だがなｗ

次ページ