TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
0からの、超初心者C++相談室
プログラミングのお題スレ Part15
Deep learning
Google NaCl プログラミング 2mol
Excel VBA 質問スレ Part62
Borland Developer Studio 2006 No.13
シェルスクリプト総合 その29
お前らプログラミング言語どうやって覚えたんや？
Javaはもう死んだの？
Microsoft Silverlight その9

Rust Part6


1 ：
Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust Part5
http://mevius.2ch.sc/test/read.cgi/tech/1518347244/

2 ：
どなたかが間違えてわっチョイ付きで立ててしまつたようなので立て直しました

3 ：
間違いではないのでは？

4 ：
ﾜｯﾁｮｲ必要なかたはこちらへ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
http://mevius.2ch.sc/test/read.cgi/tech/1514107621/

5 ：
>>1おつ！

6 ：
http://bzc.yeatczh9a.xyz/nyep/34gfw/wgen99mhwrwthw/hrtwthw/hwry45

7 ：
あらし以外でワッチョイ嫌な人ってなんなの？

8 ：
どうんすんだよこのきちがい様スレ

9 ：
ﾜｯﾁｮｲなしが正当

10 ：
>>9
いや、だからあらし以外でっていってるじゃん

11 ：
IDあるしﾜｯﾁｮｲまったく要らないでしょ
どうせ自演するやつは環境変えられるわけだし、根本的に荒らしを警戒するほどの書き込みも無いし
ﾜｯﾁｮｲの必要性を感じたこと無いし、ﾜｯﾁｮｲがあってよかったと思ったこともない

12 ：
と言って必死にワッチョイなしへ持って行こうとする荒らしｗｗ

13 ：
必要性ないってのは分からなくもないんだが、
だからってアリのスレを使わない理由にはなってないんだけど。

14 ：
>>7
>>13
そう思うんならお前がそっちにカキコめばよし
それだけのこと
俺はこっちにカキコむ

15 ：
いや、その通りであっちのスレに書き込む人いなんいんだよ。
あんたが多数派なの。それは事実なんだけど、2ちゃんてそういう感じなんだね。

16 ：
ワッチョイあると書き込み減るんですよ、事情は人それぞれでしょうけど
使わない理由になりませんか？

17 ：
ワッチョイは運営がサボるための口実。入れると荒らしレス以上に書き込みが減る

18 ：
https://www.haiku-os.org/blog/nielx/2018-07-05_the_state_of_rust_on_haiku/
haiku(BeOSの生残り)でもrust使えそう

19 ：
>>17
ＳＮ比がよくなる方が助かるよ

20 ：
2ちゃんてのはそういうとこなんだね。
まあこの板だけかもだけど。

21 ：
そういうってどういう？

22 ：
プログラミングRust待ちきれん

23 ：
>>22
なんで？

24 ：
え？「待ちきれない」に理由が要るの？

25 ：
忍耐力の欠如

26 ：
煩悩

27 ：
いまさら書籍なんぞに何を期待するんだろう？
APIの最新情報は公式に揃ってるし

28 ：
(日本語で)体系的に学びたいって事じゃないの？
APIリファレンス読んだだけじゃその言語特有のイディオムみたいなものは学べないし

29 ：
そーなん
rustに限らず本なんてここ10年手に取ったことすらないわ
ネットが未発達な時代は本で読んでたけど…

30 ：
これは俺の持論だけど、
ネットは確かに情報量は多いけど断片的な情報しか手に入らないし
間違った情報(書いた本人が勘違いしてるだけの場合も含む)も多い
そんなのを自分で精査していく手間を考えると、
お金払ってでも本を買ったほうが効率的に有用な情報を手に入れられるよ

31 ：
誤解を招く前にいちおう補足しとくと
>>29で本って言ってるのは「プログラミング言語の本」て意味
そんでもってネットで十分て言ってるのは
「ネットでAPIリファレンス見るだけで十分」て意味

>>28
人生で最初の言語は体系的に学んだほうがいいかもしれない（のかな？）
二個目以降は真顔でAPIリファレンス引くだけのことと感じてる

>>30
まぁそれはあるね
・ニワカなやつほど語りたがる
・ノイズのっけた二次情報を発信したがる
・意味も無く薄めた二次情報を発信したがる
・独自解釈で歪めた二次情報を発信したがる
という点では注意が必要だ
Qiitaみたいなもんはほんと公害

32 ：
Rust難しすぎ（＞＿＜）

33 ：
将棋でも棋書読まずに定跡そっちのけだけど滅茶苦茶力戦になったら強い人っているよね

34 ：
https://i.imgur.com/0YbMsqj.jpg

35 ：
俺はプログラミング言語の本を買うのはやさしいC以来15年ぶりだ
あと一週間だね

36 ：
別にこれで良いと思うんだが。
https://y-yu.github.io/trpl-2nd-pdf/book.pdf

37 ：
日本人は目的より手段を優先する人が多いからしょうがない
少：××をしたいから勉強する
多：勉強をしてから出来る事を探す

38 ：
はぁ？w

39 ：
紙の本じゃないと脳に染みてこない体質
絵的なものなら電子媒体でも全然いいんだけど

40 ：
>>34
Rust が last か・・・

41 ：
>>37
怖くて外に出られないから武器を延々と収集するマニアみたいなものだな。

42 ：
>>39
印刷すれば？

43 ：
いやマジで「××を勉強したい」などと言う人に「それ勉強して何をしたいの？」と
質問しても明確な答えが返ってこないケースはかなり多い
日本の教育制度がそういう風潮だから当然っちゃ当然なんだが能率は良くないよね

44 ：
>>43
ま、勉強する事そのものが目的の場合もあるとは思うけどな。
その場合はパズル解きたくなるのと同じようなものね。
遊びであり趣味であり好きでやってるだけ。
だから上達する必要がないんだけど何かに迫られてやってるわけじゃないので結果的にかなり上達する。
野球が好きで毎日野球ばっかりやってて結果的にプロ並みに上達してしまうみたいなのと同じ。
本人は主観的には遊んでただけで一切努力していない。

45 ：
自分のささやかな経験を拡大解釈して知ったかぶるケースはかなり多いよね
海外では興味があっても使い道がないなら手を出すなと教育してるわけ？

46 ：
https://twitter.com/hidemotoNakada/status/1025289812503228416
まだC++で消耗してるの？
(deleted an unsolicited ad)

47 ：
なんか尻に変なurl付いたなんだこれ

48 ：
『プログラミングRust』って、電子書籍版出ないの？

49 ：
>>44
趣味ならそれでも良いかもしれないけど実践的じゃないよね
日本は大規模なプロジェクトが苦手だしな。宇宙・航空なんか最たる例

>>45
日本は手段偏重。技術偏重とも言える。逆に目的や結果は軽視される

50 ：
原発ダム高速鉄道高層ビルに大規模なプロジェクトは枚挙に暇ないがないけどなあ

本を買うって話でそんな脈絡ないことを言い出すあたり、遺伝子にも環境にも恵まれなかった失敗作なんでしょうなあ

51 ：
別に好きでやってるのはいいと思うよ。
実践することとの区別のついてないバカが実際にいて困るってだけ。

52 ：
好きなの使わなきゃ楽しくないじゃん
なんでそれがバカなんだ？

53 ：
日本人は大規模なの下手だと思うよ
鉄道やなんやらは一見大きく見えるが小規模理論でスケールできる例なんだろう

実用OSなどの大規模なソフトウェアは本当に苦手で
日本からは決して生まれて来ないと思う
（TRONが実用になってたらこの案は引っ込める）

あとオーケストラとかサッカーとか
動的に複雑に協調していくようなもんは全て下手だと思う
というより、欧米の連中がなぜかそこをうまくこなしてると思う

54 ：
鉄道を持論で小規模扱いするんか
ソフトウエアの世界で弱いのは英語ができないからだよ
オーケストラは知らんがスポーツは個人競技だって欧米が強い、フィジカルの違いだから

プログラマなのになんでそんな無茶苦茶なこと言うんだよ

55 ：
原発は大事故を起こしたばかりじゃないか
自分が言う大規模というのは一人の人間が全体を把握できないという意味
日本は個人で全体を把握できる物は強いが、それが出来ない物は弱い
鉄道だって構成要素は使い回しが多く種類は以外と多くない
プログラム関係なら汎用OSなんかが該当するかな

この話を突き詰めていくとアメリカで言うシステムエンジニアリングに行き着くんだよね
日本人には理解されない事が多いけど

56 ：
>>55
おおむね同意
日本人がすぐれてるのは職人芸の延長だと思う
コケシ作ったりするような、ああいうサイズ感は得意
個人の勤勉さがうまく働く例だと思う

「一人の人間が全体を把握できない」という表現もなるほどなぁと思う
俺はもっと単純に「複雑さがあるレベルに達すると」くらいに考えてた

57 ：
>>56
白状すると元ネタはこれ
マツドサイエンティスト・研究日誌 保存版 システムエンジニアリング（その４） 超人にならなくていい
ttp://anoda.web.fc2.com/weblog/20050424.html
そっち系の本職の人の記事だが本来の意味のシステムエンジニアリングについて解説している
この業界ですらみんな判っているわけではなく打ち上げて間もない衛星を管理不十分でお釈迦にしたばかりだし

58 ：
語れば語るほど薄っぺらいが、たいていの人はこういう時期があったので、生暖かく見守っているのだよ

59 ：
日本には誇り高きSIerがあるじゃないか

60 ：
最近は義務教育や高校で近似解や数値計算も教えるのかな？
今のご時世コンピュータを使用してはいけないとかナンセンスだよね

61 ：
>>55
まあわからんでもないかな。ある種の細かい部分の差異を捨てられない感覚がある。
大規模な場合にそういう差異が生じることを前提に組まなきゃならんって場面で
うまく切り捨てられない印象。

62 ：
冷笑系になるのも一つの道ではある

63 ：
日本は島国だから、争わない遺伝子が多い

他国では戦争が多いから、逆らう人 : 従順な人 = 7 : 3
などだが、日本人だけは逆

日本では、体制を変えたり、乱を起こすような、乱世向きの人は嫌われる。
従順な治世向きの人が好まれる

日本人は、命令・洗脳・支配されると喜ぶ。
人の上に立ちたくない。
反発力がない。

だから同じ事を、飽きずにずっとやれる

64 ：
ステロタイプの日本人像ばかりで飽きれる
持論ですらないし
持論じやないから反論に対して反論できず言い張るだけ
こんな奴らがプログラマやってるなんて信じられない
IT土方なんて揶揄されるのも仕方ないな

65 ：
ここはいつからポエムスレになったんだ

66 ：
>>57
（´･∀･`）ﾍｰ
俺も白状すると指揮者の小澤さんって人が書いた本に（タイトル忘れた）
オーケストラとかやると日本人はからっきしダメ
欧米人はなぜか不思議と音楽になっていくが
日本人はなぜかうまく行かない不思議がある
みたいなのを昔読んでひっかかってたのが元ネタ
あの本では合奏そのものに対する歴史とか
個人レベルでの音に対する感覚とかを原因と考えてたような記憶

>>61
切捨てかぁ…それあるな！！
これは俺が個人的にみっけた法則なんだけど
日本人の動画は長い！つべでも三分くらいある！
要点以外の前後関係を大事にすると言えなくも無い
海外の事故動画なんて数秒、一分未満だけど
日本人が上げてるどうがは五分とかある印象

>>65
もうやめるから許して…

67 ：
1.28.0
どうや？

68 ：
自分自身大して能力が高いわけでもないし、日本的な方法でやっていたら中々成果物が出来上がらない

>>61
細部にこだわりたくなる気持ちはわかる。でもそれをやっていると全体が進まなくなるので
なるべく俯瞰的に、客観的に見るように心がけているな

>>66
もう一人挙げると川口淳一郎氏も優秀なシステムエンジニアだな。初代はやぶさの総指揮官をやった人
中古で良ければ著書がブックオフ等で100円位なので読んでみるといろいろ考えさせられると思う

>動画
手間を掛けたシーンから捨てろ！的な話を聞いた事がある。客観的に見て冗長になっていないか注意せよ
って事なんだが細部にこだわりすぎていると中々難しい

69 ：
プログラミングRust、どっかのイベントで早売りしてたのね

70 ：
英語版パラパラと見てみたけどrustが日本語で錆だからとunicodeキャラクターの例に錆持ち出してみたり文字列の例で顔文字ಠ_ಠ使ってみたり日本フレンドリーな著者だなと思った。

71 ：
行ったけど売切れで買えなかったよorz

72 ：
本に書いてあることは時代遅れって聞いたことがある。大体あっている気はする

73 ：
本を買うのは最新が知りたいんじゃなくて基礎が知りたいからでしょ

74 ：
The Rust Programming Languageの第二版はだいぶわかりやすいドキュメントになってるな。
rust使わなくてc++だけの人でも読む価値あるわ。

75 ：
安西先生。自動テストがしたいです。

>>73
2018でその基礎が変わるんだよ。
NLLとかモジュールとかマクロとかraw identとか。
あとedition導入されると新しい機能は
その都度追加される様になるから紙じゃ追いつけなくなる。

>>74
rustのdoc全部いちいち細かいところ間違えてて
ミスリードしまくりだったのが異常だったんだよ。
今マシになってきてる。

76 ：
たぷたぷたぷ

77 ：
rust2018なる風呂敷についてよく知らんけど、基礎を覆すほどのもんじゃないと思うけど
アップデートあったら差分だけ把握すれはいいでしょ

78 ：
全部いちいち細かいところ間違えるはどう考えても不正確な物言い

79 ：
筋が悪い
才能が無い

80 ：
筋子がうまい

81 ：
>>77
Python2と3くらい変わるから別物だよ

82 ：
ほう具体的には？
どこで互換性捨ててるの？

83 ：
>>82
単純にキーワード増えるから過去のコードが動かなくなる
今まで Trait と書いていたところを dyn Trait と書かないとコンパイルエラーになる

84 ：
あ、増えるキーワードはasync awaitね

85 ：
>>83がPython2と3がどれ程違うかを知らないってことは分かった

86 ：
過去のコードが動かなくなる以上の情報いる？

87 ：
いやそれくらいgrepでよゆうっすよ１００万行ファイル置換しましょうオッケー大丈夫！

88 ：
dyn traitはオプションなんですけども
既に追加されているけど元気にコンパイルてるよ
async/awaitについてはどんな理屈で動かなくなるのか想像すらできない

89 ：
キーワード増えるってあらかじめ予約してた奴でしょ？

90 ：
>>86
勿論「いる」
同じ「過去のコードが動かなくなる」でも程度次第で修正の手間が全然違う

91 ：
>>89
新たに追加されるし削除もされる。

92 ：
pythonの場合2to3でも動かないやつあったけどcargo fixで直らないやつあるん？
動かなくなるコードよりNLLで動くようになる放置コードの方が多そう

93 ：
異なるeditionのcrateを混ぜて使えるんで、簡単な所からcargo fixしていけばいいんでないの？

94 ：
過去のコードが動くことは保証されてるぞ
ちゃんとeditionの説明読んで

95 ：
うーんめんどくさいから教えてよ

96 ：
何もしなければそのまま動く
Cargo.toml に edition="2018" と書くと新しい構文やキーワードが有効になる
crateごとにeditionは混在可能

なので破壊的変更はない

97 ：
>>94
保証されているとドキュメントに書いてある
（コンパイラやcargoがそう作られてるとは言っていない）

98 ：
自分では試してないならそう言えばいいのに。

99 ：
えっ!? 試せるの？
まだ予告されただけなんじゃ…

100 ：
今だ！100ゲットォォｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

101 ：
>>96
edition導入後は上位互換+edition違いのcrateがリンク可能っていう
話だから既存のソースコードで新しい機能使うならソースコードレベルの変更が必要だし、
キーワードの変更も決まってる（try追加とsizeof削除以外はもう反映されてる）から破壊的変更はあるよ。
それに下位を気にせず新しい機能を導入するためのeditionだし。

>>99
ただの機能セットのスナップショットだから以前からnightlyで色々使えるよ。
C++2aとかes2018みたいにn年ごとに新しい仕様出ますってわけじゃなくて新しいjavaみたいに出来た機能から追加されるんだよ。

102 ：
>>101
> 新しいjavaみたいに出来た機能から追加され


詳しい解説サンクス

103 ：
>>101
edition=2018という指定を加えるとコンパイルが通らなくなることはあっても
何もしなければコンパイルは通るんだから破壊的変更ではないよ
Cargo.tomlを含む、コードをいじらなければ以前から動いていた物はコンパイルは通る

104 ：
プログラミングrust届いた

105 ：
かおうか迷ってる
第二版がすぐでるんならそれまでまつ

106 ：
約5千円か。俺としてはちょっと高く感る値段だな。
3千円ぐらいだったら迷わず買ってるかも知れん。

107 ：
電子書籍で千円までだな

108 ：
そこでSafari Booksですよ

109 ：
今みんな本買わないから中古価格が下がるペース遅くて、充分に読んでからでもそこそこの値段で売れてありがたい
通して読むにはやっぱり本がいい

110 ：
いまさら本に何を期待するのか本当に不思議
じゃね禁止

111 ：
じゃね is 何？

112 ：
とにかく電子書籍にして欲しい
分厚い本は邪魔だし、電車の中で読めない

113 ：
ディスプレイで読むと疲れる
電子書籍はページの行き来に不便
したがって本を読む

114 ：
電子書籍は斜め読みザッと見できないから嫌い

115 ：
電子書籍は単語検索できるから好き
紙だとどの辺にあったか思い出してその範囲を1ページ1ページ探さないといけないから糞

116 ：
>>115
紙でも索引がついてれば大抵どうにかなる
それより、紙は抽象的なことをパラパラめくりで検索できるから好き
電子書籍だと「あの図のあるページが見たい」とか思うとまともな検索手段がないから糞
忘れっぽい俺なんかは「あれだよ、あれ」って思いながら探すから紙じゃないと無理

ま、人それぞれだわな

117 ：
しおりが中途半端なんだよな

118 ：
>>116
そういう問題解決こそSE/PGの腕の見せ所では？

119 ：
んなあほなw

120 ：
マクロ使いすぎの人多すぎでは

121 ：
>>120
Scalaの悪い所をまねてるようだ
変に技巧派が目立って、人を遠ざける

122 ：
5千円ぐらいの本は、分厚すぎる！

3千円ぐらいの、もっと薄い本を出せ！

123 ：
Packtのように頻繁に電子書籍セールやって$10とかで買えて、且つ糞本じゃなければいい

124 ：
オライリーの買ったけど、入門本としては有志翻訳のThe Programming 〜のが良くない？

125 ：
>>124
具体的にはどの辺が？

126 ：
rust書いてるとhaxe思い出す。

127 ：
みんなどういうモチベでrustやってるのん

128 ：
Rustをマスターすれば成仏できる

129 ：
Rustをマスターすればモテモテに

130 ：
Rustをマスターすれば童貞懐妊して、生まれた幼女とイチャイチャできるよ

131 ：
オライリーのRust本、いつのまにかPDF版も発売してるやん
少し安い

132 ：
なんでカニなの？
https://i.imgur.com/pDYq0hU.jpg
https://i.imgur.com/hGWqtv2.jpg

133 ：
>>132
コンピュータ研究者のカニチャーハン氏に敬意を表する為

134 ：
カニチャーハンってカーニハンとなんとなく似てるな。
きっとカニチャーハン&リッチーって書いてあっても気づかないだろうな。

135 ：
5000円は高い。その価値あるの？

136 ：
価値を知らないのに高いと評するのか

137 ：
知らないので顧客が価値を認めるような観点を提示せよ

138 ：
馬鹿は客じゃないから去りたまえ

139 ：
>>137
英語版の話だけどamazonのレビューでけっこう高評価ついてるよ
少なくともその人たちは買って良かったって判断したんじゃない？

140 ：
カニチャーハンのことかと思ってた…

141 ：
紙の本は5184円、電子書籍は4147円。
https://www.oreilly.co.jp/books/9784873118550/

142 ：
https://doc.rust-jp.rs/the-rust-programming-language-ja/1.6/book/dining-philosophers.html
これ酷くね？
Rustならではのどんなやり方で問題を解決するのかと思えば
こんなのって

143 ：
>>125
後者のが順を追って説明してくれてる…気がする
習熟者から見るとそうでもない？

144 ：
あ、あとタイトル間違えてたね
>>132の比較のつもりだった

145 ：
>>142
そんなのって？どう酷いの？

146 ：
いやだって、なんでわざわざこの題材っていう
リソーススタベーションに対する
Rustならではのスマートな解答があるのかと思えば、ナニコレ
ならなんでこの題材にしたのか不明

147 ：
Rustにスマートさなんてないただある種の間違いが少なくなると主張している

なにをやるにもつっかかる
Rustだけに

148 ：
Rustは並列性がどうとか言ってなかったっけ
それで最初の題材でコレもってくるセンスが謎

149 ：
何が謎か分からん

150 ：
>>146
ここは書いた本人的にもいまいちだったと思っていたらしく、本家では結構前に削除されてる。
まあチュートリアルならせめてmutexではなくchannelだとは思う。

151 ：
うーむそうかな
並列処理ではmutexはかなり一般的で本質的だと思うけど
ロックを得ないことに安全に並列処理はできないのだし

152 ：
結局なんでカニなん？

153 ：
mutexがスコープ抜けた時点で勝手に解放されるのが恰好いい的な？

154 ：
>>151
一般的で本質的ってのはその通りだと思うけど、
チュートリアルで一番最初に導入すべきかというと、そうでもないのでは？って感じかな。

155 ：
カニチャーハン氏はRustに全然関係してないからね

156 ：
Kernicharhan & Ritchie

157 ：
>>152
おまいら(rustacean)の先祖がミジンコ、もとい甲殻類(crustacean)だから

158 ：
rustらしさといえば&と&mutの仕組みがそのままスレッド間でも使えるところとか
RAIIとかmoveも良いけどc++にもあるので

159 ：
rustらしく書いたコードって、&と&mutが大量に出てきて、なんか見た目ごちゃついてない？
move多用で書きたくなる

160 ：
clone多用しないならそれで良い

161 ：
&やmutはまだいいけどライフタイムとジェネリクスが入り乱れると頭抱える
自分じゃ書けないからライブラリのコード読むときだけど

162 ：
impl traitでちょっと楽になったけど、書きながら試行錯誤しているときに関数にして切り出すのが面倒
ちゃんと設計しろよって言われるかもしれんが、rustの仕様とライブラリ全部きっちり頭に入れるのも非現実的だと思ってる

163 ：
絶対に必要、ってとこ以外でmoveするとclippyに怒られてくやしい

164 ：
>>150
バグってるからだぞ。

他人の書いたマクロが拷問だよな。

165 ：
わるい。バグは修正したんだった。削除した理由はこっち。
ttps://github.com/rust-lang/rust/pull/30595

> まあチュートリアルならせめてmutexではなくchannelだとは思う。
これも冒頭二段落に書いてある。

166 ：
存在型と量化子安定してたのか。
( ﾟ∀ﾟ)o彡ﾟG・A・T!!
( ﾟ∀ﾟ)o彡ﾟG・A・T!!
( ﾟ∀ﾟ)o彡ﾟG・A・T!!

167 ：
Vecのswap_remove()って賢いやり方だな
どこ発祥の文化？　C++あたり？

168 ：
交換を一回しかしない配列の回転の応用だからJon BentleyのProgramming Pearlsだな。

169 ：
>>168
へー、ピアソンから出てた『珠玉のプログラミング』か
読んでみたい

170 ：
>>169
つまらんよ

171 ：
古典ですな。
今読んでもそんな悪くない本だと思う。

172 ：
rustfmt-nightlyがビルドできないお(´・ω・`)

173 ：
古めのnightlyじゃないと無理

174 ：
PR出ててもうマージされてた(｀・ω・´)

175 ：
VSCodeでRust Tool Missingと出てたからクリックしたらエラーたくさん出た。
ググったらNightlyのコンパイラじゃないとRacer(レイサーってのがRust Toolのこと？)は入れられないと
あったから。とりあえずRust Nightlyを入れた。
その後、また同じように入れようとしてみる。
cargo install racer && cargo install rustfmt && cargo install rustsym Updating registry `https://github.com/rust-lang/crates.io-index`

ダメだった！エラーが5個くらい出る。
どうすれば良いの？

176 ：
>>175
IntelliJを入れる

177 ：
>>175
rust関係ないからcodeスレへ。アドオン何使ってるかもちゃんと書けよ。

178 ：
VSCodeって言っちゃったのがまずかった
VSCodeのターミナル（WSLのzsh）で出たエラーだから、MacでもLinuxでも、このエラー起こると思う！
最近Rustインストールした人で、同じエラー出ている人いないかな？
GithubのRacerに書かれてある方法で試してみる・・

179 ：
エラーを書かずに同じエラーとわ

180 ：
これはすごい

https://github.com/EbTech/rust-algorithms

181 ：
Rustで使いやすいGUIツールキットってどんなのがあるんだろうな
マルチプラットフォームかつネイティブでそこそこのパフォーマンスを得られるのが良い
wxWidgetsは有名だけどwxRustは3年放置されている。使えるのかな

182 ：
良い塩梅に発酵したときが食べ頃

183 ：
>>181
gtk-rsは?
前にちょっと触ってみただけだから実用レベルかは知らんが
今でも積極的にコミットされてるから期待はできそう

純Rust製ならPistonが作ってるconrodかな？winitとgliumをベースにしてるっぽい？
こっちは使ったことすら無いんで全く分からん
純Rust製に惹かれたが、なかなか時間が作れなくて放置中…
因みにwinitはイベント管理用でgliumはOpenGLのクレートね

184 ：
>>183
ggr-ksに見えた

185 ：
>>178
GithubのRacerに書いてあるとおりにやったらいけた
Rust Nightlyを入れただけではダメで
rustup toolchain add nightly
cargo +nightly install racer
でいけた。Multirustという機能があるからNightlyを使いたければ毎回指定するということを初めて知った

186 ：
>>184
+1

187 ：
>>184
ワロタ

188 ：
rlsじゃなくてracer使うのか

189 ：
RLSだけでいいの？それならRLSでいきたい
でもNightlyをデフォルトに設定したらRLSがスタートできなかった

190 ：
Rusty Codeっていうのにした

191 ：
>>183
ありがとう。GTK+が無難ですかね。gtk-rsを試してみます

純Rustは確かに惹かれますがこれってネイティブなのだろうか・・・

192 ：
Intellij Rustの作者が作ってるlibsyntax2がLSPを提供するようになってる
https://github.com/matklad/libsyntax2/tree/master/crates/server

racerの代わりになる日が来るだろうか？
IDE機能の提供はコンパイラでやるのが一番いいんだろうけど

193 ：
>>183
>>191
gtkってマルチプラットフォームと言えるの？
Linuxでしかまともに動かないイメージ
まあWindowsでは最低限は動くのかもしれんけどmacOSではダメダメでしょう

194 ：
>>193
そうなの？
まぁ今回の用途はWindowsとLinux/*BSDで動けばよし
たしかGIMPはGTKだったはず

195 ：
え、エレクトロン

196 ：
そもそもgimpを作るためにgtk作ったわけで…

197 ：
GTKは糞

198 ：
マイナー言語のGUIにはGtkバインディングぐらいしかないのが現実

199 ：
GTKのバインディングがあるならTkのバインディングも・・・と思ったら見あたらない？
Tkも一応ネイティブだったはず。機能面はぱっとしないが今回の用途には足りるかも

>>195
その手のWeb技術ベースのってアプリケーション側からウィジェットを更新する術に乏しい
印象があるけどそうでもないのかな

200 ：
ウィジェットってこの文脈だとどいう意味？

201 ：
OS(フレームワーク)ネイティブのGUIコンポーネントって意味だと思う。
というか、こっちの意味での利用のほうがコンピュータ的には一般的だったかと。

202 ：
Windows向けRustのリンカがlldになるのはいつかな

203 ：
GIMPはMotif・・・。うん。わかってるよ。

>>191
msvcツールチェーンでビルド面倒くさいから頑張れ。

204 ：
何かやるのに言語からつくっちゃえって、どうなんだろ。

205 ：
なにかやるわけでもないのに言語だけ作るほうが珍しい気もするぞ。
で、どの言語のこと言ってるの？

206 ：
>>205
Rust

207 ：
Cの事じゃないのか。

208 ：
GUIといえばlibuiはどうだろう？

というかRustでGUIって面倒くさそう

209 ：
面倒臭いと思うよ

GUIだと大抵はイベントハンドラ多用する場合が多いから
Rustだと多分クロージャを渡すことになって
キャプチャする変数の所有権が絡んできて面倒なことになる

可能な限りデータを全て不変にして参照カウンタ使うのが一番楽そう
誰かもっと良い方法知ってたら教えて

210 ：
キャプチャ必要かな。しなけりゃいいんじゃね？
RxやReduxみたいなのならRustでもできるような気がするが。

211 ：
wasm来たらhtmlでいいじゃん

212 ：
>>209
相互/循環参照があり得るから参照カウンタじゃ無理だよ。
メモリ管理面の煩わしさを考慮するならjavaみたい
にイベントハンドラをtraitにしてユーザーデータ自身に
実装させればいいけど、今ではこのアプローチ自体が煩わしいと思う。

あと参照カウンタの場合一度に多すぎる解放処理が発生して
UIがもたつく可能性があるね。
トレーシングGCなら必要ないなら遅らせるからこういう事は起きない。

rustでトレーシングGC使う場合rootingはプログラマが行う必要があるから
自前でメモリ管理するのと同じだし、それ以外にGUIのシーングラフ自体にトレーシングGCがいるね。
ffiで既存のgui利用してrustからはデータ渡すだけにするのが簡単だと思う。

213 ：
yewとrelmが気になる

214 ：
ちなみにWEB開発のサーバーサイドでRustって現実味あるの？
Goがたまに使われてるから、Rustにもチャンスあるのかなと思ったけど

215 ：
君が作ればチャンスは無限大

216 ：
Goは手軽さと性能のバランスが丁度いいから

217 ：
現実味の程度による

218 ：
予算と工数的に競技志向のFPSのバトルサーバならRustも現実的だけどマッチングサーバなら現実的じゃないとかありそうよね

219 ：
現実になるかどうかは言語じゃなくでプログラマ次第でしょ
俺は現実に使ってるけど

220 ：
それ言い出したらアセンブラでもcでもプログラマ次第だわな。

221 ：
言語の決定権が

222 ：
適材適所で言語を選べるか？って事でしょ

223 ：
Rubyでいう

v = [1, 2, 3].map(){|e| e.to_f }

をrustで書きたくて、以下のように書いたんだけど、

let v = [1, 2, 3].iter().map(|x| *x as f32).collect();

vの型が推論できなくてコンパイルが通らない。助けて！

224 ：
let v = [1, 2, 3].iter().map(|x| *x as f32).collect::<Vec<_>>();
とか
let v:Vec<_> = [1, 2, 3].iter().map(|x| *x as f32).collect();

collectをジェネリックにする代わりに型推論できなくするのは良いアイデアだったのか

225 ：
rust的にはturbofish使うもんだけど型注釈をよく見かけるね。

226 ：
>>224
参考になりました！
これどちらも vec<f32> になるんですよね？
ヒープ確保じゃなくてスタックの配列への変換は無理ですかね？

227 ：
>>226
ttps://stackoverflow.com/questions/26441916/dynamic-array-allocation-on-stack-in-c
Cでも駄目で、C++ならオッケーだったけな。Rustはできなかった。

もしできるようになっても、その関数の下にどれくらいコールスタックが積まれているのか、
この関数の上にどれくらい呼び出しが控えているかを熟慮しないとすぐstack overflow起こすんで、よっぽどクリティカルでなければやらんほうがええんじゃないか

228 ：
>>227
逆やー。
Cではオプション扱い、C++では不可

229 ：
>>228
追いかけきれてるわけではないけど、
allocaについても言及されているrfc#1909の第一段階が、8/19にマージされてるっぽい。

近い将来にallocaが完全サポートされる感じなんですかねぇ？

230 ：
んーん、なるほど。
Rustには現状、スタックを伸長するalloca相当がないから件の場合、固定配列を求める事は出来ないってことですかね。

231 ：
cloneていつ付けてる？
不用意にcloneするのを避けたくて最小限にしていたんだけどテスト書くとき辛い
derefでcloneされるのはcopyついているやつだけ？

232 ：
テストの時辛いってのは
↓のアトリビュートじゃ解決できないの？

#[cfg_attr(test, derive(Clone))]

233 ：
omg
それでいきますわ！ありがとう！

234 ：
>>224
> 型推論できなくする
できるよ。
rust by exampleを例にすると
ttps://play.rust-lang.org/?gist=3cbef33631cbed2a2f0dce6439da4942&version=stable&mode=debug&edition=2015

上記の`i32::from_str`や`<i32 as std::str::FromStr>::from_str`のi32を見て推論してる。
ただのstd::str::FromStrでは推論できないってエラーになる。

235 ：
低コストで探索できるらしいB+木ってなんぞや。ググるといっぱい出てくるがどいつもこいつも抽象的
「で、それがどう活用できるのか？」と言う疑問が解決しない
もちろんRustでコーディングする予定

236 ：
>>235
てけとーにググってきたやつ
https://christina04.hatenablog.com/entry/2017/05/17/190000

で、B+ツリーはリーフノード間にリンクがある構造。

リンクがあると何が嬉しいかというと、
データベースで値の範囲で検索する際、先頭が見つかればリンクをたどってレコードが抽出できる。一例として。

237 ：
B木とそのバリエーションは、ディスクのように一定の大きさを持ったブロック単位で読み書きする
記憶装置上に置くのに適した木構造。
そういう使い方をしないんだったら効率が悪い木構造でしかない。

238 ：
ありがとう

>>236
そのような説明はいっぱい出てくるんですがそれを実用へ落とし込むのに必要なピースがわかりません
データベースやファイルシステムを作れる人ならその説明で十分なのだろうと思いますが
自分はそのような経験がないので「ファイルシステム」や「B+木」等のキーワードからその不足分にたどり
着けないでいます

>>237
まさしくその用途を考えています
・大容量のボリュームを扱う (数百GB〜TB)
・ファイルをたくさん入れる (万〜)
・ファイルの中身へのアクセスコストが低い
・充填率に優れる
・フラッシュメモリベースのメディアで使用する
みたいなファイルシステムを作れないかなーと。個人が扱うファイルシステムだとFAT32あたりがよく使われると思いますが
そろそろ最大ボリュームの上限を突破しそうだし、ディレクトリの探索が容易じゃないし(特にLFN使用時)
充填率も良いとは言えないしと、いろいろ課題が多いのでいっそ俺ファイルシステムを作ろうかと

239 ：
B木の実装は、共立出版の「ファイル構造」という本が詳細に分かりやすく説明されていてよかった。
残念ながらもう絶版らしいが。

240 ：
bit別冊は大部処分したけど似た本はもう無いと判断して捨てなかった一冊

今ファイルシステムの勉強しようと思ったらLinuxや*BSDのソースコードよむぐらいしか無さそう

241 ：
>>239
英語版ならまだあるようだし、pdfでも見れるな。

242 ：
1.29.0来たね

243 ：
来たー

244 ：
ありがとう

>>239-241
尼のマケプレの値段ヤバイですね。原書？のPDFは入手できたので見てみます

>今ファイルシステムの勉強しようと思ったらLinuxや*BSDのソースコードよむぐらいしか無さそう
うへぇ。ファイルシステムドライバの仕様がどうなっているのかを理解した上で、ジャーナリングや
スナップショットなどの付加機能を分離しつつ読む必要がありそう
オープンソースといえどもこの辺の情報はお世辞にも豊富ではないのもつらいところです

245 ：
まあ読むならext3ぐらいからじゃないかな？
losetupやbrdで小規模なデバイス上にmkfsしてhexdump使って媒体構造見るとか
system tapやblktraceで処理やアクセス箇所見るとか
crashでカレントプロセス覗くとか
printk仕込んで処理フロー確認するとか

昔勉強したけど他に何やったかもう覚えてないや

246 ：
まさかこんなところで共立出版というガチな名前を聞くとは思わなかった。
ねねっちがいるのかこのスレには。最近Rと統計ばっかだよねあそこ。

ところでファイル構造の古書店の通販見つけたけど長すぎてurl貼れない。

247 ：
共立出版って大学数学やら物理やらの教科書としてはまあまあ使われてるんじゃない？

248 ：
テキストとワインバーグ本とすべての人のためのJavaプログラミングのところだね。

249 ：
>>247
共立出版で情報系の教科書としては次の２つのシリーズは好著が多い良いシリーズだ
・情報数学講座
・アルゴリズムサイエンスシリーズ

あと、共立出版でプログラミングの本と言えばとっくに時代遅れになっているが
カーニハン＆リッチーの『プログラミング言語Ｃ』は外せない
恐らくこの訳書は初版と第２版とを合わせると、共立出版の情報系の書籍の中で圧倒的な部数を稼いだはず

それ以外にもカーニハン本の翻訳を日本で最初に出したのは共立出版だ
『プログラム書法』、『ソフトウェア作法』、『プログラミング作法』とね

今の若い人たちは存在していたことすら知らないだろうけど、共立出版は bit という月刊誌を出していた
これはB5版のころはソフトウェア技術者にとっての教養雑誌で、理論的な話題の記事も載せていたし
チューリング賞の受賞記念講演の翻訳も毎年載せていた

上に名前が出てた『ファイル構造』は元は bit誌の別冊か臨時増刊として出版されたものが
需要が多かったので増刷を機に単行本化されたものだ

だが部数が徐々に減ってきたのをテコ入れとばかりに編集長が変わって、版型をB5版からA4版に変え
記事も教養的なのから実用的なもの中心に変えてしまったら、昔からの読者の多くが離れて
急激に廃刊（建前上は休刊）に追い込まれた

bit誌の廃刊以降、共立出版の情報科学系の書籍の出版点数はかなり減少したような印象がある
現在の共立出版は数学書の出版に特に力を入れているみたいだね

250 ：
bit本誌、いまだに捨てられなくて本棚1段占領している。
ユニマガは引っ越しの時に全部捨てちゃったが。

251 ：
rustの複数行文字列って空白消されちゃうの？

https://stackoverflow.com/questions/29483365/what-is-the-syntax-for-a-multiline-string-literal

252 ：
>>251
そんな話してない

253 ：
ここで質問しても許されるのでしょうか？ダメそうなら、申し訳ないです。
S式を使って遊ぼうとしてRustで見様見真似で書こうとしたんですが、コンパイルすらできません…。
ヘッタクソなコードで恐縮ですが、以下の52行目で「`s` does not live long enough」と怒られます。
https://pastebin.com/94ZPh2dL

まず、's'がスタックに確保されていて、parseから返った先で（つまり、スタックが解放されたあとで）
sを使う可能性があるから駄目だと言っているという認識ですが、正しいのでしょうか。
また、どのように対処すればよろしいでしょうか。

たぶん、根本的なところから理解できていないのだと思いますが、ご教授お願いいたします。

254 ：
Nodeがsへの参照を持っているのにsが解放されちゃうからじゃないかなあ

255 ：
みたかんじsymbolを&strじゃなくてStringにしてsをmoveさせればよいと思うけど

256 ：
>>253
>sを使う可能性があるから駄目だと言っているという認識ですが、正しいのでしょうか。
合ってる。
sはparse関数の中で確保されてる。
そのsの借用(as_strしてるから借用することになる)をparse関数の外に出そうとしてるから
sの借用がsより長命になるのでrustではエラーになる。
sはparse関数の呼び出しが終わると解放されるからこれはダングリングポインタだよね。

>また、どのように対処すればよろしいでしょうか。
この場合、Node<'a>は文字列のsymbolフィールドを所有する側だから&strじゃなくてStringにすればいい。
apiの設計の時点でownd valueとborrowed valueを意識すればいい。
あとleftとrightが借用になってて、これはこれで設計的に間違いじゃないんだけど問題出るかも。

257 ：
コピーのコストが嫌だからとりあえず参照にしとこう、の精神は早々に破綻するよね
似たようなパーサ書いてて同じようにコンパイラにボロクソに言われたことがある

それ以来、このデータは誰が持っているべきなのか？を意識して書くようにして、
コンパイラに怒られたら「何か抜け道がきっとある」って思うようになれたし、リファレンス探すと大体解決するようになったよ

258 ：
The Creator

259 ：
皆さん、お返事ありがとうございます。
とても参考になります。
もう少し、頑張ってみます。

# ピンポイントで質問できるのは、本当にありがたいです。

260 ：
ありがとう。File Structuresを眺めていますが英語なのであまりはかどらないです
二分木およびその発展系の説明は十中八九キーとして数字が使われているけど
ファイルシステムの入力はファイルパスであり可変長の文字列。この部分はどう埋めればいいのだろうか
ハッシュテーブルでも使えという話なのか？しかしそれならハッシュテーブルを使ってファイルのメタデータを
探索してしまった方が早そうだけどそういう問題ではないんだろうな

261 ：
最近でたオライリーの本って
Rust公式ドキュメントの2018でもSecond Editionでもなく
明らかに初版が元になってるよね時期的に

262 ：
>>260
ブロック管理に使うからキーは数字で問題ない

263 ：
>>261
つまりオライリーの本は地雷？

264 ：
Second Edition出てるんだっけ？
ググってみても First Edition, Third Release が 2018-6-22 としか見つからないんだけど。

265 ：
目次の構成はSecondに近いか？

サンプルプログラムの発行時期は10ヶ月前だからそんなに古くはないのかもな

オライリー原書
http://shop.oreilly.com/product/0636920040385.do
公式ドキュメント日本語訳
https://doc.rust-jp.rs/

ちな最新の2018版ってGithubみた感じリアルタイムに更新されてるっぽいな
https://doc.rust-lang.org/book/index.html

266 ：
>>262
ありがとう。あれ？自分が勘違いしているのかな
B+木やB*木をファイルのメタデータの探索に使っていると思っていたけどそうではなくデータを格納しているブロックの探索に使っているということ？

267 ：
翻訳元のISBNと原書3rd releaseのISBNが違うことは確認したけど、たぶんこのerrataに載ってる修正くらいだろう。
https://www.oreilly.com/catalog/errata.csp?isbn=9781491927212

268 ：
>>261,265
オライリーのカニ本の初版一版は1.17.0。TRPLの日本語訳は相当古い。
2018はverでいうと1.31.0に相当する。いまのstabuleは1.29.0。
それにTRPLでもまだ文書化されてない機能あるしな。
非初学者向けならStep Ahead with Rustもある。

269 ：
6週間で0.1バージョン上がるから一年半前のバージョンか
進化はえーな

270 ：
>>266
> ファイルシステムの入力はファイルパスであり可変長の文字列
ファイルシステムへの入力は inode、dir、dentry がほとんどじゃないか？
create：dir と dentry をキーにinode作成
readdir：dir をキーに dirent を作成
open：inode をキーに open
ext4 を少し読んだ感じこうだった
inode 番号をキーに管理すればよいのでは？

271 ：
https://play.rust-lang.org/?gist=d668e212c4d0abf7d0e9fd4c76ea4a56&version=stable&mode=debug&edition=2015

これどうしたらいい？

272 ：
>>271
これってたぶん自己参照構造体(self-referential struct)の話だよね？
自己参照構造体は未定義動作の危険性があるので現状のRustでは表現できない
詳しくは↓の「自己参照構造体」のところを読んで
ttps://qiita.com/ubnt_intrepid/items/df70da960b21b222d0ad

273 ：
RC使うが正解

274 ：
>>273
>>271の場合だとRc使っても無理な気がするんだけど…
ソースコード見せて

275 ：
>>271
>>272と同意見だけど27行目でどうやっても自分の参照を関数外に出すから無理だな。
借用じゃなくてBoxでもってクローンすればよくね？

276 ：
タプルにFromStrトレイトを実装するのって無理なんですか？

https://ideone.com/iNMuPL

277 ：
implしたい型か、traitのどっちかが自分のものでないと駄目って制約があるから駄目です
何でこんな制約があるかは理解してないけど

278 ：
open等させるものか！っていう強い意志。new type patterns使え。

279 ：
Rustに関しての発信の多い日本人のツイッターアカウントを何人か教えて
フォローしてRustの情報集めたい

280 ：
普通に検索すりゃいいじゃん

281 ：
言い方を変える
オススメの情報発信者を教えて！

282 ：
お前がなるんだよ！

283 ：
ここの人々
https://www.rust-lang.org/ja-JP/team.html

284 ：
人でないのも混ざってるようだが・・・

285 ：
rustの懐は深い

286 ：
この写真のことかな
https://avatars3.githubusercontent.com/u/26415?s=400&v=4

287 ：
rustlang の Discord に Rust(Steam) をクレクレしてるのが出現してる
さすがにベタすぎるのでネタかと思ったけど
「Rust言語は誰にでもフリーだよ！」と住人にやさしく説明されててちょっと笑った
そういう仕込みのフリとオチだったのかもしれないが

288 ：
Rust信者ってブロッキングにも賛成なんだろうなあ
邪悪だ

289 ：
そうなん？俺もブロッキング支持しよ〜

290 ：
async/awaitのあたりがきれいに書けないなら、ブロッキング＋スレッドの方が実用的でしょ

291 ：
いやいやがんばってノンブロッキング対応してるでしょ

292 ：
同音異語のボケをマジレスされる>>288が不憫。

293 ：
1.30出た

294 ：
モジラがバックにいてカワンゴが布教してる技術なんてよく使う気になるよなお前ら

295 ：
>>294
じゃあ君がバックに付け

296 ：
>>295
やだよ放射性廃棄物の後処理すんの
世に出して広めた奴が責任もって片付けろよ

297 ：
rustのポジションは他に居ないからありがたく使ってますけど

298 ：
>>294
じゃあ、かの有名なMicrosoftがRustを使っていれば貴方も使う気になるってわけですね
ttps://www.reddit.com/r/rust/comments/8ub964/microsoft_announces_using_rust_to_build_some_of/
はい。これでめでたしめでたし

ところで、ドワンゴが例のRust製分散システムをオープンソースにしてた。
ttps://dwango.github.io/articles/frugalos/

299 ：
>>296
じゃあ君は最初はバックがどうこう言ってたけど実はそんなこととは無関係に嫌ということかな？

300 ：
ただの廃棄物じゃなくて放射性廃棄物ってどういう比喩なのか
阿片みたいに観戦力があり周囲に広がるということ？
それとも単に処分に困るというだけ？

301 ：
バカが扱うと光ってしぬとか？

302 ：
モジラの由来がゴジラだからだろ

303 ：
遠回しすぎ

304 ：
暗号通貨関連でよくRustが使われてるってホントなの？

305 ：
>>304
残念ながらC++, Java, Goと比べたらゴミカスや

306 ：
家の非力なデスクトップにgentooを入れたんですが
firefoxをコンパイルしたらrustもコンパイルしてくれました
rustも含めて都合14時間かけてコンパイルしたfirefoxを使うだけじゃ勿体無いので
rustを勉強してみようと思ったのですが
スクリプト言語とjavaを触った程度の人が始めるには
ハードルが高い言語なんでしょうか？

何かとっかかりになる良いサイトとか本がありましたら
教えてくれると嬉しいです
Python歴7年Java歴2年の趣味プログラマです
rustでgtkアプリを作ってみたいです

307 ：
問題はやるかやらないかだけ

308 ：
【おい何だこれ、俺ムカついて】　久本雅美、マチャミに、創価学会に入れって、俺ね囲まれたんですよね
http://rosie.2ch.sc/test/read.cgi/liveplus/1541989783/l50

309 ：
ヤル気はマンマンなんですが
まだgentooのインストール途中でxfceにfirefoxが入ってるだけなんですよね
帰宅したらvscodeも入ってるはずなので今夜からコンパイル流しながら勉強する予定です

ただ、あんまり初心者向けの日本語情報が見当たらない気がするので
いいサイトがあれば知りたいな、と思った次第です

310 ：
私もRustでGtkアプリ作りたいマンです

311 ：
Qtがいいです(´・ω・`)

312 ：
Azulとかどうよ
とりあえずサンプルビルドしたら普通に起動した

313 ：
とりあえずslackに入ってみるとよい

314 ：
皆さんいろいろとありがとうございます
とりあえずプログラミング言語Rustの日本語訳pdfを見つけたので
それ見て勉強してみたいと思います

これ凄いですね
無料で配布しちゃって良いんでしょうか
下手なwebの情報探すより公式見たほうが良さそうですね

315 ：
布教のために気合い入れて書いたんだろうと思う

316 ：
Gitとは何かの説明まであって驚くよな
さすがにそのレベルの人は門前払いしたほうがその人のためにもいいと思うが

317 ：
>>316
あれはRust初心者だけでなくプログラミング初心者も対象としてるんじゃないの？
だから初歩的なところから教えてるんだろうと思っていたが

まぁ、プログラミング初心者がいきなりRustから始めるってどうなのよ？とは思うけど

318 ：
Cとかでメモリの扱いミスってしかも落ちずにおかしな動作する、みたいなのの経験がないとイマイチRustの有り難みは感じられないようなとも思いつつ
かといってRustのためにC勉強するってのもなんか本末転倒なきもするし

319 ：
なまじ他言語を知ってるから難しいという点もあるんじゃない
初心者がベテランが作るようなものをrustで書くのは辛いだろうけど、初心者が作るようなものを書く分にはむしろ易しい気がする
セットアップ楽だし

320 ：
Mozillaはドキュメント書くの得意だよな
オワコンブラウザには勿体無さすぎる才能

321 ：
なぁに、まだまだこれから。

などという言葉が出始めたら終わりは近い。

322 ：
書店でオライリーのRust本をパラパラと読んでみたけど
式の可読性の面ではC++の悪いところを引きずってるように思える

323 ：
>>322
どの辺が？

324 ：
可読性って言うやつw

325 ：
try!(try!(try!(foo).bar()).baz()) とか？

326 ：
try!(try!(try!(try!(foo).bar()).baz()) とか)

327 ：
?演算子使えよ

328 ：
オライリーのRust本は?登場以前なの？

329 ：
前なの

330 ：
え？前なの？
手元の蟹本だと、
7.2.4節 エラーの伝搬に"?演算子"のこと書かれてるんだけど

331 ：
muslでビルドすると普通にlinuxでビルドしたときよりメモリ食うんだけどなんで？

332 ：
>>331
標準のライブラリだと、メモリ上にロード済みのコードを共有するからじゃないの？

333 ：
libcとかがダイナミックリンクじゃない分てことだよな
色々検証していたんだがそれだけじゃなくリークしてるように見える

334 ：
>>318
だがそれが一番の近道だよ。
結局 c -> c++ -> rust の順で学ばないと意味わからんだろう。

335 ：
>>333
valgrindで見たら？

336 ：
>>334
いやCはともかく少なくともC++は要らんだろ

337 ：
>>335
見てみたらリークはしてなかった
100mbくらいあるヒープに確保された値を1分に1度入れ替えているんだけど、ヒープに確保された領域って即解放されるわけではない？

338 ：
アロケータがmallocになってるからっぽい

339 ：
あれjemallocやめたの？

340 ：
まだjemllocがデフォルトだけどナイトリーでは既に外されていて近々デフォルトではなくなる

それとは別の話で、俺がビルドしたのがmuslビルド用のdockerイメージで、それにはjemalloc入ってないからシステムアロケータで動いてたんだよね

341 ：
Announcing Rust 1.31 and Rust 2018

https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html

342 ：
過疎ってるのは人気廃れたかrust

343 ：
2018安定化でむしろ盛り上がっているのでわ
うちはリプレイス案件２つにrust使うことにした

344 ：
>>343
何系？Web？

345 ：
んだ、webだ

346 ：
なんかサイトの雰囲気がらっとかわったな。

347 ：
まともなﾔﾂなら将来が保証されない言語なんかを採用しないからな
一時的に使用するﾄﾞｶﾀ向け案件なら試用にぴったり

まとも思考してたら、将来も間違いなく保証されてるc/c++を使う

348 ：
FacebookやDropboxが採用してるし
最近だとAmazonがRustでVMMを作ってる

349 ：
>>348
Facebook採用してたっけ？あそこはDだったような…
MSの間違いじゃない？MSだったらAzureの中の一部で採用してたはず…
因みにGoogleも自社製エディタに(たぶん20%ルールでだけど)採用してるね
もしFacebookも採用してるならApple以外の主要IT企業は全て採用してることになるな
(AppleはObjectiveC/C++とSwiftしか使わないしね…)

350 ：
まあクソアプリほどどの言語で書いたかとかアピールするよね。

351 ：
クソアプリほどオープンソース？

352 ：
半角こんなとこまで現れてんのか

353 ：
>>349
低レイヤーでC++の次世代言語って意味合いではDとRustって似たとこあるよね
大きな違いはバックボーンとしてMozilaという巨大コミュニティがあるところだけど

354 ：
クソ言語ほどHNでポイント稼ぐよな

355 ：
ハンドルネーム？

356 ：
Rustは良いけどMozillaの将来が心配
MSも撤退するしこれから更に厳しくなりそう

357 ：
>>356
MSが撤退っていうのはブラウザエンジンの話をしてるのか？

358 ：
ただの糖質だろ

359 ：
ブラウザエンジンの話
Mozillaが厳しくなるとRustにも影響がある

360 ：
>>359
Mozillaはなんだかんだ言っても一応非営利団体だから
MSみたいにブラウザエンジンを手放すようなことはしないはず
つまり、Firefox(Gecko)が消える時はMozilla自体が消える時と同時で、
流石にMozilla自体が消えるとは考えにくい…

361 ：
いうてもWebメールじゃないSMTP式のメールのメーラーとしてはMozilaのThunderbirdのシェアってそこそこ高くない

362 ：
ThunderbirdはMozillaから切り離されるんじゃないの

363 ：
ブラウザに関してはグーグルが死なせないと思うけどな

364 ：
MDNって言うほど貧弱じゃなくない？

365 ：
仮にMozillaがどうにかなってもRustは大丈夫だろ

366 ：
楽観的だな(笑)

367 ：
初期はMozilla頼みだったけど、今はそうでもないという認識

368 ：
なんか新しくマクロ増えたみたいだけど使い勝手どう？

369 ：
stableって今1.31.0だろ。
「nightlyが久々にやらかした+distマシンの環境壊した+CI壊した」でnightlyが三日止まっててまだ1.32.0だからdbgマクロくらいしか違いないぞ。

370 ：
モナド変換子がほしい

371 ：
　 ∧＿∧　　／￣￣￣￣￣
　（　´∀｀）＜　・・・
　（ ⊃ .旦| 　＼＿＿＿＿＿
　 し＿）___）

372 ：
モサド変監視ほしいの？

373 ：
Rustのドキュメント日本語サイトが404になってた

374 ：
心の中に404はあるよ

375 ：
パイプと型変換だけで十分なところにモナドを要求する馬鹿。

376 ：
こっちの日本語サイトは生きてるけど
https://doc.rust-jp.rs/
本家は多言語対応辞めたんかな見つからない
https://www.rust-lang.org/

377 ：
下の方に旧サイトへのリンクがある

378 ：
どんなに否定したって下のお口は正直ですからね

379 ：
旧サイトのほうがいいなすっきりしてて
情報量的にもデザイン的にも

380 ：
なんか安っぽくなったね。詐欺のベンチャーみたいなページになった。
以前のデザインのほうが圧倒的に良い

381 ：
駆けつけでいきなり言語の特徴とplayground見せるのは話が早くていいよね。
なんか気になればそのままナビゲーションヘッダのリンク辿ればいいし。

382 ：
>>380
ほんそれ

383 ：
現在開催中のこのAIコンテストの説明のサンプルコードにRustが選ばれているあたりRustは世界一素晴らしいプログラミング言語であることが分かる

http://russianaicup.ru/p/quick

384 ：
Rustと最初の3文字が一致しているので親しみを抱いてるんですかね

385 ：
どうかなあいやでも俺もそう思う

386 ：
今年こそRustを日本中で流行らそうな

387 ：
せやな

388 ：
別に流行らんでも使ってりゃいいじゃん。

389 ：
俺は使ってるから君らも使えよ

390 ：
流行ろうが流行らなかろうが使う

391 ：
マイナー言語やってるけどしんどい😭
いずれRustに乗り換える💪

392 ：
仕事で使えないから趣味で使いたいけどスマホアプリとか作れるようにならんかな
wasmでやれるん?

393 ：
android用のglueある

394 ：
所有権借用はなんとなく理解できたがライフタイムだけよくわからない
なにがわからないのかすらわからない

395 ：
元々わからなかったけどNLLでよりわからなくなった

396 ：
lifetime関係のエラーが出たら、一歩引いて考えないとドツボにはまる
どうして借用にしたのか、誰が責務を負うべきなのかとかを見直していくと、まあまあ綺麗な形でエラー出なくなるから楽しい

397 ：
>>394
ライフタイムは変数のスコープと一緒だよ。
ただrustの場合、関数の引数に対してライフタイム指定ができたりするんだが、
それを省略した場合なんかのルールが結構複雑なんでわかりづらくなってる。
まあ色々検討した結果が今の状況なわけでこれはこれでしょうがないんだが。

398 ：
きようもrust書いた
たのしかった

399 ：
らすたまだあるかな

400 ：
>>397
>ライフタイムは変数のスコープと一緒だよ。
ちげーよ。extentの方だよ。

401 ：
ide使いたい初心者なんだけどintellijもvscodeも補完が微妙だった。
エディタ上で赤く無くてもコンパイルしたらエラー出る。なんか設定おかしいのかな。。

402 ：
RustのIDE環境はまだまだ未発達なのです(´；ω；｀)

403 ：
あきらさんowやめてrustの解説に専念してほしい

404 ：
>>403
いやまずお前は他人に依存してないで公式ドキュメントちゃんと読んでQiitaでも読み漁れよ

405 ：
Juiceのユーザっているのかなぁ
ActcastはRustで書かれてるらしいけど

406 ：
>401
intellij rustだけど補完もリファクターも、traitの実装も出来る。

407 ：
文字列を返却する関数ってどう書くんだっけ？

408 ：
>>407
Rustの文字列には何種類かありまして……

409 ：
メンドクセーッ

410 ：
javaにも2,3種類あるだろ

411 ：
>>406
マジで？俺のintellijはあんまりintelliやないんやけど。
(0..10).
これでfor_eachとかの補完できる？

412 ：
intelliJ rustもrust(rls)も全部が全部補完出来るわけじゃないよ。
むしろRange系がほとんど補完効かない。

413 ：
rlsって2016年に登場した時いつか脱racerするとか言ってたと思うんだけど何で未だにracerに頼ってるんだろ？
clangはclangdとかcclsとかあってどっちもコンパイラを使って強力に補完出来るけどrustも同じような方針で実装出来ないの？

414 ：
>>412

> intelliJ rustもrust(rls)も全部が全部補完出来るわけじゃないよ。
> むしろRange系がほとんど補完効かない。
そうなんか。まあそれは慣れればええ話か。
ide上で赤くないのにコンパイルエラーになるのは何か環境構築に失敗してるのかな？
単純なシンタックスエラーは赤くなるんだけど、所有権まわりは赤くなってない気がする。

415 ：
>>413
racerはfallbackしたときだけでそれ以外はコンパイラ使うよ。
インクリメンタルコンパイルがまだまだだから出来ること限られるだろうけど。

>>414
>所有権まわりは赤くなってない気がする。
赤線つくね。マウスオーバーでエラー内容もshort版を整形したようなの確認できる。
quick fixが弱いけど。

rlsならrust-srcとrust-analysis。intellij rustならrust-src入ってる？

416 ：
>>415
できた!ありがと。
intellij-rustの設定おかしかったみたい。

417 ：
Rustで簡単なゲームを作ってみたいんだがフレームワークは何が良いんだろうな
SDLやDirectX、OpenGL等のラッパーは一応あるようだけど

418 ：
言語レベルで静的にstructを差し替える方法って無いんかな？
マルチプラットフォームのアプリを仮定するとして
アプリはSystem構造体下のメソッドを経由して低レベルの機能へアクセスする
System構造体の中身はビルド時に決まる物だし実行中に選択するのはコストの無駄
ビルド時にコンパイル＆リンクするファイルを差し替える方法はあるが・・・

419 ：
target_os とかとは違うの？

420 ：
静的リンクならcfgマクロ使った条件付きコンパイルしかないよ。

421 ：
ありがと
#cfg[(target_os=〜
struct System {
とか書くしかないのか

というかググっていてもマルチプラットフォームのアプリを作る例って出てこないんだけど
どういう風にするのが好ましいのだろうか。Cargoの使用例とか全然判らん
ターゲットによってコンパイラも変わるし、リンカやリンカに渡されるオプションも変わる
リンク後に追加の処理が必要になるケースもあったり

422 ：
有名なcrateはだいたいマルチプラットフォームになってるでしょ

423 ：
そのレベルじゃなくて一つのプロジェクトで
１．Windowsでビルドする/動く
２．Linux/FreeBSDでビルドする/動く
３．Linuxでクロスビルドする/別アーキテクチャのプラットフォームで動く
みたいなのをやりたい。１〜２はともかく３はベアメタルに近いのでコアのソースはno_std付きになる

クレートもWindowsAPIへアクセスする場合Cargo.tomlに
[dependencies]
winapi = "〜
kernel32-sys = "〜
とか書くけどコレをつけたまま他のプラットフォームでビルドできるのか？とか
仕様上無視してくれるならそれで良いけどはっきりしないと無用なトラブルの元
クレートを使わずにソースにexternを並べていって条件付きコンパイルすればその心配は
なくなりそうだけど各種定義とか、IA32/AMD64環境下の差異の吸収とかいろいろ面倒だし

424 ：
>>423
有名なcrateはだいたいちゃんとそれこなしてるから見てきなよ

425 ：
スマン
Carge＆winapiを使ってWindowsAPIを叩くサンプルを作ろうとしたらそこまでたどり着けん
use出来なくて詰まっている

extern crate winapi;
use winapi::minwindef::BOOL;
>cargo build
error[E0432]: unresolved import `winapi::minwindef`
--> src\main.rs:4:13
|
4 | use winapi::minwindef::BOOL;
| ^^^^^^^^^ Could not find `minwindef` in `winapi`
パスがおかしいっぽいのでソースを見るべきだが、Cargoが取ってきたソースがどこにあるのか判らない
というかコレを調べられないと非対応環境でどう振る舞うのかも調べられない

rustcでコンパイルするFFI直でWindowsAPIを叩くコードは動作させられている

426 ：
Cargo.toml に

[target.’cfg(target_aech = "x86_64")’.dependencies]

とか書けるけど、これでも不十分？

427 ：
cargoがとってきたのはホームの下の.cargoにあるよ

質問がいまいち判然としないけど

428 ：
WEB開発でフロントエンドもバックエンドもRustで開発できるようになるみたいだね
そしてJavascriptは衰退するらしい
まさに次世代の言語か？

429 ：
Javascriptを倒すのは無理

430 ：
>>426
それでいけそうかも。というかwinapiにそんな書き方があった

>>427
ありがと。見つかった
README.mdにあったサンプルはビルドできた
1〜2年前のコードだとビルドできないようだ

いくら発展途上の言語とはいえ1〜2年前の情報が使えないのはつらいなぁ
車輪の再発明になってもFFIで書いていった方が良いのか？

というかみんなどうしているの？情報の有効期限が1年もないんじゃ
ちょっと前のを修正するにもドキュメントはないしソースとにらめっこになっちゃうよね

431 ：
nightlyでも使っていない限りは、基本的に過去のコードはビルドできると思うけど

432 ：
>>418
rustにとって一年前は古いけどwinapi::minwindefは今はwinapi::shared::minwindefよ。
apiが変更されただけだからまずdoc読めばいいよ。
あとrustupでrust-docインストールすればthe cargo bookもあるからそれも読んで。

433 ：
>>432
0.3.x以降はCargo.tomlにfeaturesを書かないとダメらしい
あとunsafe祭りになってしまいそうなんだがwinapiの仕様でFAなんかな

434 ：
ttps://docs.rs/winapi/0.3.6/winapi/um/minwinbase/struct.OVERLAPPED_u.html
これってどうやって初期化すればいいんだろ？
ReadFile/WriteFileでOVERLAPPEDを使いたいんだが

435 ：
よく知らんけどOVERLAPPEDをmem::zeroedで初期化して引っ張ってくるんじゃないの

436 ：
>>435
ありがと。それでとりあえず出来た

437 ：
TryFrom/TryInto がもうすぐか

438 ：
型のパターンマッチってメンテナンス性が悪かったりする？

439 ：
ML系の関数型言語の経験があるなら全く問題ない
経験ないならHaskell/OCaml/F#あたりのうち最低一つは触れてみることを強くお勧めする

440 ：
どれ？

441 ：
>>438

442 ：
やっぱRustに限らず新しめの言語できる人って英語もスラスラ読み書きできるもんなの
読むのは時間かければ何とかなるけど書けないから質問する場所が限られる

443 ：
パターンマッチは型で分岐するというより型に当てはめるという感覚の方が近い
OO言語でマサカリ投げられるような型で分岐するというのとは似て非なるものなんだが、
そのへんの微妙な感覚を掴んでからでないと糞コードの温床になりそう

444 ：
>>442
slackで聞くといい

445 ：
何かのIDEで
(0..10).
の補完が効くようになったら教えて

446 ：
RangeはIteratorを直接実装するからcurrent scopeにIteratorがuseされてない状態でIteratorのメソッド解析出来ないと無理だろうね。
useされてないトレイトのメソッド使ったら自動でuseする機能のほうが先。

447 ：
良記事

Learning Rust via Advent of Code
https://www.forrestthewoods.com/blog/learning-rust-via-advent-of-code/

448 ：
トイレット

449 ：
https://volt.ws/lang
https://volt.ws/game
V言語とかいうやつ、GUIアプリとか3Dゲームとかを開発するために作られたらしいけど、GCがないとか1500万行のコードを1秒でコンパイル出来るとかバイナリサイズが極小とかC/C++とのやりとりが簡単とか
これが本当だったらRust負けちゃうんでは
実際Rustで低レイヤーやってる人少ないだろうし

450 ：
詳細知らんけど低レイヤーに適した言語が出てくること自体は歓迎できるんじゃないの

451 ：
言語は言語の良さだけでは流行らないんだよ
RustもGoもまあまあ悪くない言語である上で十分なステマを行ったから流行った

452 ：
それ使ったアプリがよほど良くて、開発者をうまく集められて、コミュニティが育たなければ無理だろうな
ソース非公開のうちは勝負にもならん

453 ：
幾ら優れていようと後ろ盾がなきゃD言語の二の舞だろ

454 ：
コンパイルが速いならジェネリクスも無いんじゃないかね。安全性については対nullしか無いっぽいし

455 ：
OCamlとかジェネリクスあるけどgoよりコンパイル速いよ
っていうか21世紀のOCamlが欲しかった（OCamlはそんなに古い言語ではないけど）

456 ：
Rustほど丁寧なエラーメッセージ出してくれる言語もないでしょ
そういうのを捨てて速度を取った言語とは比べられない

457 ：
> Rustほど丁寧なエラーメッセージ

冗談だよな？　って思ったけど最近のは丁寧なのかな

458 ：
全然だぞ。

459 ：
Vってvoltのことか。あれgoに毛が生えた程度の言語よ。

>>457
今のはコマンドプロンプトのバッファが足らなくなるくらい丁寧だけど
答えそのものを教えてくるから書いたコードがだめな理由が初学者に理解できないのは変わらないと思う。

460 ：
>>449
どうググるとそれ出てくるの?
「volt　プログラミング言語」でググって出てくるのこれなんだけど

Volt Programming Language ・ GitHub
https://github.com/VoltLang
http://www.volt-lang.org/

461 ：
大体はGoとかと一緒で言語名+langで検索するのがいいんじゃない？

四文字もあって他の情報が上に来るのも珍しいが

462 ：
googleで言語名+langで検索するとgoを検索結果にねじ込んでくるから-go必須

463 ：
rustでググってrustってゲームがトップに来なくなったのはグーグルさんが僕の検索履歴から判定しているだけ

464 ：
https://trends.google.co.jp/trends/explore?geo=JP&q=%2Fm%2F0zm_2_r,%2Fm%2F0dsbpg6
https://i.imgur.com/7uP3Dl5.png

465 ：
Rust初心者です。
リスト構造を使ったスタックの実装で躓いてます。
なぜ間違っているのか教えてください
https://gist.github.com/rust-play/e54d15602fa8a1d8f7a17521f85d1133

466 ：
>>465
http://cglab.ca/~abeinges/blah/too-many-lists/book/first-push.html
かいつまんで言うと、&mutなオブジェクトが一瞬でもinvalidな状態になるから。
mem::replaceを使うと、self.listの値を取り出して代わりに別の値を置く、という処理が一度に行える
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8d12416b3f7bc4aa44bf360df11de1be

467 ：
>>466
ありがとうございます。
変更可能な"参照"で持ってきたもの(&mut self)から所有権をムーブさせることはできないという解釈で大丈夫ですかね。

置き換えるときはmem::replaceを使うようにします。

468 ：
クソコード教えるんじゃねぇ。Optionの中身をNoneと入れ替えるならOption::take使え

469 ：
アアン？Option::takeのソース見ての物言いだろうなあテメェ

470 ：
中身見たのならなおのことOption::take使うべきでは

471 ：
>>455
OCamlは、文字コードの扱いとWindows環境の扱いが
もう少し良くなってくれると嬉しいな。

472 ：
インデントのスペース幅は2が良かったなぁ
clang-formatもprettierも2がデフォだし
C#でさえ2を結構見かけるようになってきた
rustに強く影響を与えたであろうocamlもhaskellも2が多い
世界的に2が標準になりつつある気がする

473 ：
漢なら8

474 ：
Pythonをインデント2で書く奴だけはマジでR
あれはガチで読めない
他の言語なら好きにしろ

475 ：
インデントはTABキー派だな

476 ：
ocamlからリスト引き継いでくれたらよかったのになあ
しかしそうするならもはやocamlそのものでいいってことになりかねないかな

477 ：
>>474
それだとgoogle連中には全員死んでもらわんとならんな。

478 ：
noto sansにindent 3をわかってくれるのはねねっちだけか。
今は源真ゴシック等幅+Source Code Proだけど。
Source Han Codeはちょっと違うんだよ。

479 ：
Cica派です

480 ：
googleのstyleguideではスペース幅4を推奨してるのにgithubのgoogleのpythonレポジトリはスペース幅2が多いな
pythonはpep8を重視してるイメージがあるけど堂々と無視出来るのは凄い

rustもrustfmt.tomlでtab_spaces = 2を設定してる人が結構いるわ
https://github.com/search?l=TOML&q=tab_spaces&type=Code
3にしてる人さえいる

481 ：
ちんこことゴッドエイムあきらを探しに来ました。

482 ：
なんでtab2だとみにくいんだ？

483 ：
インデントで制御構造を表現する言語だと、深いネストから戻るときにどのレベルに戻ったのか識別できなくなる

484 ：
タブ2で見ずらくなるようなネストの深さと関数の長さになるのが悪いと
言いたいところだがgoogleのオフィシャルコードは結構ど汚くて上の条件を無視してる。
個人的には3が視認性の上では一番良いと思ってはいるが、流石に2,4と互いに素な数だと
プログラム的になんか嫌なこと起きそうで自分では使ってないな。

485 ：
タブ幅小さくして、その分変数名を分かりやすく長くするんだよ

486 ：
>タブ2で見ずらくなるようなネストの深さと関数の長さになるのが悪いと
2派と4派の対立は4が深すぎるか、2が浅すぎるかなのに「2で見ずらくなる深さ」って想定おかしくね？
3派は間とって3だよ。こっちは普及してないのが問題。

487 ：
Scalaみたくスタイルガイド作っちゃえばいいのに
そうすれば「スタイルは公式に従うように」の一言で済む

488 ：
ハードタブなら各自好きな幅にすればいいから揉めないのにね。

489 ：
回りの多数派にあわせるだけの話
こういうのにこだわるやつは大抵バカ
可読性w

490 ：
なんてここでタブ・スペース論争してんだ
どうせ一人でしか書かねえくせによ〜

491 ：
インデントってrustfmtの話？

492 ：
>>489
ほんこれ
見やすさとか人によって違うしどうでもいい

493 ：
エディタファシストなのでエディタを開発したことないやつは駆除されるべきなのではと考え始めて来た。やばい

494 ：
昔々学生の頃に学校のワークステーション使ってXlibでドット編集してXPMファイルで出力するなんてものを作った覚えがある。
あらから29年。時の経つのは早いものぢゃ。

495 ：
29年前にRust使えたんだ
すごいな

496 ：
読み込んで表示するより出力の方がはるかに簡単だしな

497 ：
>>494
xlib ダイレクト記述、とは猛者ですね…
私も最近になって xlib をバシバシ触ろうと思っていますが、いい参考書はありませんか？

498 ：
XlibってCの悪いところを煮詰めたような設計だったな
Rustとの相性は最悪だろう

499 ：
日本語の参考書はX11R5の大昔に出た本ぐらいじゃないかな

500 ：
うん。新しいXlibの本は知らないなあ。
探す気も起きないから知らないだけかも知れないが。

501 ：
>>498
なんというか、オブジェクトを作って操作するような感じなので今時の言語用のオブジェクト指向に合わせたラッパーは作れると思うが、需要はほとんどないような気がする。

502 ：
xlibの使いやすいラッパーとしてはgtk+などなどがあるんわけで…

503 ：
GTKはクソ

504 ：
ちゃんとgtk-rsあるやん

505 ：
>>465です
スタックにpopを実装しました
pop自体はうまく動いているようですが…
popした時の対象の物がどのタイミングで破棄されているのかを調べようと思いstd::ops::Dropを実装しようとしましたがうまくいきません。
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f1a2a2a35c3dc424f3814557afa5974c
何がいけないのでしょう

506 ：
haskellでの、文字列[Char]を切り貼りみたいな事をするには、
Vec<char>を操作するので合っているのかな？

507 ：
>>487
>>480

508 ：
クローン技術で乗り切った

509 ：
>>505 Dropを実装した型の値がdropされるとき、フィールドは全てvalidじゃないといけない。
そのままメモリ解放するだけ＝Drop未実装ならいいんだけど、drop中にinvalidなフィールドにアクセスできちゃうのがダメだというのが問題
解決案は、ここでもOption::takeかmem::replaceでNoneにすげ替える

けど、まずはLearning Rust With Entirely Too Many Linked Listsを写経してみた方が良いよ
今のListの定義だと無駄なメモリを食うし、パターンマッチとstructは相性があんま良くないし、これから先も似たような穴にハマると思われる

510 ：
Rustいいらしいですよって話を会社でしたら、
テックリードが「RustでできることはCやC++でもテストとツールで十分やってけるからイラネ」って言ってたけどマ？

511 ：
&str で関数に渡すと解放されてしまって使い回すこどができないのですが
使い回す方法ありませんか

512 ：
コーディングスタイルを徹底的に統制できるならマ

513 ：
>>510
コンピュータでできることは人の手と頭でできるよ

514 ：
>>512
じゃあうちにはたしかに要らんなあ
そんな統制がいるほどの人数でもないし

回答サンクス

515 ：
>>510
そのリードが C++でauto_ptrがdeprecatedになった理由とMove Semanticsと右辺値参照の関係をちゃんと説明できる人なら C++ でいい

516 ：
人間が信用できないからこそCよりRustだろ
気を付けてコーディングすればミスはなくなる、ってのは戦前の日本軍的な精神論だ
コンパイラ先生に怒られながら厳しい指導の下にやっとコンパイルしていただくのがRust

この記事とか参考になるかも
https://tomo-wait-for-it-yuki.hatenablog.com/entry/2019/02/05/210746

517 ：
プログラミングは製造業だからな
厳格なチェックは本来あって当然

518 ：
>>511
&str is 何？

519 ：
>人間が信用できないからこそCよりRustだろ
>気を付けてコーディングすればミスはなくなる、ってのは戦前の日本軍的な精神論だ
ぴんとこないな。
rustの場合、お役所とおせばテストなど自前でしなくともokっていう
変な信用を生んでるだけだろ。そっちのがよっぽど日本的だと思うがね。

520 ：
>>519
今時の言語なので、ユニットテストは標準で整備されてるよね
コンパイラは計算ミスや仕様間違いまではチェックしないので

521 ：
考え得る全パターンをいつもテストできるならいいんじゃないの

522 ：
メモリ破壊はユニットテストで検出されないケースも多い

523 ：
注意力ってのは慣れると省力できるようになるけど、有限リソースだし個人の習熟度と体力に依存するんで、目に見えない負債になる
新しい言語を理解するコストは償却できるけど、注意深さってのはソースコードを触る限りはコストを発生し続ける
機械がチェックできることは機械にやらせた方が絶対に良い

524 ：
製品にするコードってどうせMISRA C辺りの静的解析噛ますし
今時ならvalgrindもテスト項目に入ってるだろうし
Rustなら全部コンパイラがやってくれる！と言われても、
いやCにも外部ツール入れれば同じことできるし……としか思わんのだよな

個人的にはクラスよりトレイトの方がしっくりくるからそれだけでもRustは意味があると思うが

525 ：
>>523
枯れてないコンパイラの癖に合わせる方がよっぽど注意力を削ぐと思う。
コンパイラになんでも機能ぶっこむより524のように構成した方がどのツールが文句言ってるのか
よっぽどわかりやすい。
機械にチェックさせるのはいいがシステムとしてモジュラリティーが高いツールの組み合わせのが
結局使いやすいし、ロバストになる。

526 ：
どうでもいいけど言語の持つ表現力とかは完全に無視なん？

527 ：
>>526
C++の方がノイズが多いくらいで表現力自体は大差ないわ
もちろん、そのノイズによる可読性や生産性の低下は決して無視できるものではないが

528 ：
>>525
Cだって作成当初よりコンパイラでチェックする範囲広げてるけど
全否定？

529 ：
>>526
CやC++との比較でそこ（表現力）に触れずに
「Rustは安全！C/C++はfree/delete忘れがーアクセス違反がー領域の破壊がー」ばっか言ってる人が多いのが疑問って話な

俺はトレイトに可能性感じてるから期待してるよ
C++のテンプレートとか関数オブジェクトとか書きたくねえし

あとチェッカーとコンパイラ分けるべきか合体させるべきかについては、
どっちにも善し悪しあるからCとRustどっちが優れてるとかはないと思ってる

530 ：
https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/
MISRAに適合しててvalgrindでチェックしてもこういうのは無理じゃない？他に例が思いつかないけど

531 ：
Cじゃ確かに無理かもわからんが、C++のstd::vectorならatメソッドで同じことできるぞ

毎回アクセス範囲が適切か確認するから結局オーバーヘッドになってほぼ使われんがな

532 ：
基本はIndex::indexを呼んで必要なとき(オーバーヘッドが気になるとき)にunsafeで囲む
C++は全関数がunsafeで意識せずVec::get_uncheckedを使うようなもの
オーバーヘッドの問題でunsafeで囲んだらRustだってツールじゃムリ五十歩百歩って言われるかもしれないけど、五十歩の方がいい

533 ：
MozillaやRust作者の人達が、valgrindやチェックツールの使い方を知らない
アホ揃いだと思ってるの？

534 ：
>>533
MozillaやRust作者の人達の過激な信者が
valgrindやチェックツールの存在を知らないか軽視してるせいで
Rustの宣伝に対して過剰にC/C++をディスってるアホ揃いだと思ってる

もちろんそうじゃないRust推しもいることは承知の上だ

逆に、「そういうツール使えばC/C++だけで十分Rustなんてイラネ」って意見も
ベクトル違うだけで同じくらいアホだと思ってるがな

だからこそトレイトの使い方だとかモジュールの仕組みだとか
外部ライブラリ（crate）の扱い方の方向での他言語との比較が
あんまり見えないことが問題だと思うんだが

そういう意味で話題提供すると、cargoって結構disられてるけど
どの変がクソなのかいまいち分からん
キャッシュサーバ持てないって話ならnpmとかbundleとかgo getも大概では？

535 ：
>>519
ほんそれ

536 ：
みんな同じ話題について話してるのか？
好き勝手独り言言ってるようにしかみえない。

537 ：
これがいつもの流れだ

538 ：
そりゃーRust信者とRustアンチしかいねえからな
話が噛み合うわけない

539 ：
Rustだと（unsafeなし、コンパイラのバグなしなら）プログラムの全実行パスでメモリリークや破壊がないことが保証できると思うけど、
C/C++で同等のチェックができるツールってある？
valgrindは単にvalgrindで実行したパスで問題なかったことが分かるだけって理解なんだけど。
もしあるならそれはそれで使ってみたい。

540 ：
>>539
俺もその認識なんだけどvalgrindナメてたかな
Firefoxのcssのバグはテスト書いて発覚した感じなんだけど

541 ：
その手の静的解析ツールはたいてい商用製品だね。一番手頃なのはVSで使えるSALかな。

542 ：
顔本のinferがオープンソースで全パス調べてくれるやつだな

企業ならcoverity課金してるだろ

543 ：
inferは知らなかった。ちょっと試してみる。
まぁ商用含めても原理的に検出率100%とはいかないだろうけど、
Rustだって標準ライブラリ内のunsafeバグとかあるからいい勝負なのかな。

544 ：
全パスチェックしてもRustのコンパイル時のチェックには及ばない
全パスチェック程度で済むものならば、Rustにあんなややこしい概念を持ち込む必要はないんだよ

545 ：
言語として縛りを強制するってとこに旨みがあるよね
静的チェックを過大評価云々は的を外した無意味な議論

546 ：
Rcなりunsafeなりあるわけでなんだかね。
rustを意識してプログラムをすることに意味はあるがrustの実装系を使うことに
そこまで意味はない。

547 ：
俺はweb屋さんだけどサーバ書くならrustが最高とおもってる
これって過激な信者？

548 ：
信者だアンチだディスったディスってないでrustを語れよ

549 ：
coverityとかの静的解析って誤検出が結構ある
で誤検出かどうかの人力解析も超めんどくさい
かつ1度の解析にめっちゃ時間かかる

これがあるからC/C++でもRust同等とかないわ

550 ：
>>547
web屋さんはもともとC++なんて使ってないし使う人が順調に増えていってる印象
問題はweb屋さん以外にどうアピールするか

551 ：
どうせ一時の流行で終わるんだから被害は少ないほうがいい
Scalaとかも中途半端に業務系が乗っかってきはじめた矢先に梯子外されて死屍累々の惨状だったし

552 ：
>>551
なんか梯子外された事件あったっけ？
Java8の登場でScalaがただの難解なJava8になった話？

553 ：
scala十分流行ってるでしょ

554 ：
えっ

555 ：
Javaは今でもクソ言語なのでScalaとは比べるべくもない
単に日本の人月制度とマッチしなかっただけ
Rustもそうなる
学習コストの高い良い言語より学習コストの低い低単価で人を集められる言語

556 ：
色んな業界があるのに一緒くたにして評価できなくない？

557 ：
>>555
JavaやPHPはともかく、そういう意味でCやC++がコスト低い言語とは思えんが

558 ：
個人的な経験だけど、Rustのコンパイラを単純に黙らせるようにソース修正していくと物凄く汚くなることが良くある
ので、そもそもの設計を見直すようになったり、かくあるべしって仮設を明確にするクセが身についた気がするよ

559 ：
>>557
低学歴のC/C++職人様はつぶしが利かないからスキルの割に高くないイメージ

560 ：
資源の共有状態を見直すってのはrustは置いといてもプログラムをに置いてやっぱ本質だなと思う。

561 ：
ArcとかMutexとかRwRockが気に入ってる
最初めんどくさかったけどよく考えたら当たり前に必要なんだよね
そこを隠蔽しないことでコストのトレードオフをプログラマに意識させるのがよい

562 ：
練習で他言語のプログラムを移植してみたらコンパイラに
ガンガン怒られて本人が壊れるような使い方しないからと手抜きしていた部分が
洗い出されてなるほどなあと思った

563 ：
>>558
黙らせるだけで終わってしまうわ

564 ：
rustでguiだと何使う？
やっぱgtk？

565 ：
rustに限らず他の言語でもgtkぐらいしかないでしょう

566 ：
んなこたーない

567 ：
orbtk?
redoxのguiだけど、windowsでも動いたよ。

568 ：
GTKは糞

569 ：
>>561
当たり前じゃねえから
PythonとかPerlとかRubyで書かれたプログラムにはないけどちゃんと動く
それともこれらの言語で書かれたものはプログラムじゃないとか言っちゃう系？

570 ：
>>569
パイソンだって排他制御書くじゃん

571 ：
RwRockが自然に必要ってのは言い過ぎだわな。
必要なところは必要だろうがそれがあまりに多いのは多分設計ミスってる。

572 ：
ですから必要なところは必要と言ってるだけじゃないですか
当たり前にってのは原理的に必要と言ってるだけだよ

573 ：
>>569
Rustの設計思想理解してないのか
単にアホなのか

574 ：
まぁ自分の書いている範囲内しか見えない人は普通にいるだろう。
どの言語だってライブラリや処理系レベルでは排他制御はあるし、
逆にどこにもなかったら単に間違ってる。

575 ：
Perlは知らんがRubyやPythonには
GILっていう排他制御が言語処理系に含まれてることを考えると
非常に味がある

576 ：
Luaって息してないの？

577 ：
>>576
他の言語が息できない分野でエラ呼吸してるよ

578 ：
>>575
GILは複数スレッドの競合によってインタプリタがぶっ壊れるのを防ぐために必要な、インタプリタ自身の内部的な排他制御
アプリケーションコードで行う排他制御の代わりにはならないよ
インタプリタがスレッドセーフでない糞実装であるための苦肉の策で、
Rust含め元々スレッドセーフな「まともな処理系」なら全く必要のないもの

579 ：
そういや Perl でマルチスレッドのプログラムは作ったことないなあ。fork してマルチプロセスにするのはよくやるが。

580 ：
>>575
GILは欠陥扱いだろ…

581 ：
そうか、今時の人はみんなLock-freeアルゴリズム使いこなすんだな
Mutexなんて見たことないんだ

582 ：
OSかそれに近いコア領域とかトランザクション必要なデータベースでも書かん限り
MutexとかLockとかが必要だとは思わんなー
Web系にもてはやされてるらしいけど君らそもそもそれオーバーキルどころか逆に足枷ならん？って思う

583 ：
そういうあんたは並行処理どうやってんの？

584 ：
>>583
そもそもそんなに並行処理をOSやミドルウェア頼りじゃなくて自分で書くが必要な場面て例えばどこ？
と質問に質問で返してみる

585 ：
念のため言っとくと、別にロックなんて無駄だとか言いたいんじゃなくて
ArcとかMutexとかRwRockが当たり前に必要とかいうマウンティングに反論してるだけな

586 ：
>>584
仮にお前がミドルウェア使うだけの些末プログラマ
だとしてもミドルウェアがマルチスレッドで動いていたり、
複数のミドルウェアを使う場合は
排他処理が必要なケースは普通に出てくるだろ

587 ：
>>585
rustをc++の代替候補として考えるなら使って当然
並行処理でこそrustの有り難みが生きるわけだし
マウンティングに感じるのは単にお前が並行処理に馴染みがないからだろ

588 ：
>>586
それはそんな使い方する方が何かしらおかしい
排他制御ってのは本当に必要なところ以外ではやらないように回避するもんだ

>>587
Rustの旨味がそこにあるのは否定しないが、
それが全プログラマが当たり前のように使いこなせるべきっていうのは
ただのマウンティングだろうに

589 ：
>>588
排他が必要だからするにきまってんじゃん
そういうところに思考が及ばないやつはjsだけ使ってりゃいいと思うよ

590 ：
プログラマーがリソースの共有状態を意識すれば
無駄な排他制御しなくても大丈夫だという主張かねえ

591 ：
RwRockってRwLockの間違い？
そういう言葉遊びのライブラリでもあるの？

592 ：
RwLockが少ない設計で組めたぜ！って自慢するならともかく
RwLockめっちゃ使ってますなんてアピールする奴は普通にバカだろ。

593 ：
単に日本語の問題では？
多分解釈が二通りある。
マルチスレッドプログラムにとって排他制御は当たり前に必要
プログラマにとって排他制御は当たり前に必要

個人的には文脈から前者と理解したけど、後者だと思うなら言い過ぎだというのは分かる。

594 ：
lockをrockと間違ってもしれっとしてるやつもかなりのバカだよね
ソフトウェアの超頻出単語じゃん

595 ：
だからプログラマにとって当然の能力という意味で言ってないって
めっちゃ使ってるとも言ってないって
隠蔽しないから必要性とコストを意識できていいねって言ってるやんけ

誤字はすまんかったけど

596 ：
まあ俺が採用だったらここまであからさまな地雷は避けるわ。

597 ：
なぜ自分が採用に関与できない雑魚だと表明してしまうのか理解できないけど、そうしたほうがお互い幸せになれるだろうね

598 ：
>>596
お前は派遣だろ目を覚ませ( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ

599 ：
こういう奴らに並列実装なんてさせるから地獄を見ることになるんだよな。。

600 ：
Rustなら地獄を見そうなコードは
コンパイラが怒るからよかったじゃん

601 ：
Mutexとかもはや古典技術でしょ
Rust使う領域では理解してて当然と言っていいよ
これがマウントだとしたらキレイなマウント

602 ：
>>601
そういうことばっか言ってるからいつまでも二流言語と違うんか？

603 ：
フリーランチの時代はとっくに終わってるのに気づいてないんだ…
プログラミング界の横田庄一だな

604 ：
横田庄一と聞いてすぐに誰の事かわかる人は横田庄一

605 ：
いやちょっと待て、横井だよな？

606 ：
>>605
すまん横井だw
よっこいしょういち

607 ：
Rockといい横田といい、この程度のことも注意できない奴だから
こんな口うるさい姑みたいなやりたいこともやりにくい言語をもてはやすんだと納得

608 ：
横井さんも刺身食えなかったらしいからな
排他処理に拒否反応示すのも無理はない
Rustはやめときな

609 ：
Rustは刺身だった

610 ：
サビだけにな

611 ：
ふふ

612 ：
>>600
rustでコンパイル通れば安全というわけじゃないっていう例なんだが。。
やっぱバカに並列化コードは触らせないほうがいいな。

613 ：
競合条件がなくなることはないけど、データ競合はほぼ回避してるぞ
安全じゃなくなるのはデータ競合のときなんだから、安全じゃなくなる例になってないぞ

経験上デバッグが難しかったりするのは大体がデータ競合によるものなんで、Rustは並行処理にも威力があるぞ

614 ：
兵庫県警の件、brendan eichが証人受けるとまで言い出して面白いことになってるけど、
アレが駄目ならビジーウェイト書いてるやつ全員逮捕だよな。組み込み勢狙われるぞｗ

615 ：
>>613
普通に考えてスレッドでやるメリットってデータ競合が生じるようなアクセスを
考えなきゃならんパターンなわけでそれはrustだろうとなんだろうと楽になんかならんという
当たり前のことがわかってない。
そういうある種のアクセスパターンに対する制限なり証明なんてのは設計をよっぽどシンプルにせにゃ
適応できんってのがまともに実装してれば分かるもんだがな。

616 ：
>>615
Rustでコンパイラエラー出さずに競合で壊れるようなサンプルある？

617 ：
人間には難しいから機械にやってもらうってことだろ
楽になってるやん

618 ：
Rustでsql扱いたい時ってなにつかえばいいんですかね

619 ：
DBか

620 ：
diesel

621 ：
>>616
話が通じてないのはよくわかった。
コンパイラエラーが出ていないが意図通りの動作でない例はいくらでも作れるよ。
てか他の言語でもロックなりアトミックなオブジェクトなり作ることについてそんなに困ってない。

622 ：
>>621
いくらでも作れるなら見てみたいのですが

623 ：
作れるかどうかじゃなくて作らないとコンパイルエラーになるかどうかが問題

624 ：
例えば、同じ型のArc領域二つ作って複数のスレッドが更新し合うプログラムで
特定の条件でうっかり逆の領域に書き込むように作ってしまったパターンみたいな
単純な仕様の間違いまでRustでコンパイルエラーにしてくれるのか？

人間っていうのは並列計算のモデルが複雑になると
把握しきれないからうっかりこういうことする率が上がるんだよ
だからどんなにRustがコンパイル時安全だろうと
人間がきちんと計算モデル把握できなきゃ結局バグはなくならない

で、人間が把握できるレベルまで設計を単純にできれば
CだろうがRustだろうが大して開発レベルに差はつかない
ライブラリと表現力の差がちょっとRustに分があるくらいで
積み上がったC資産の量でひっくり返るレベル

625 ：
プログラマならコードで語ってほしいなあ

626 ：
>>625
そりゃコードの話はしてないからなあ
一生リーダブルコードでも読んでろ

627 ：
Rustでもこんな書きかたしたら駄目だよと言う
例も出せなきゃ単にRust理解してないのかと思われるよ

628 ：
>>627
だから書き方の話なんてしてねえよ設計の話してんだよ
言語以前の話なんだよ
代入する変数を間違えるレベルのミスはRustだって面倒みてくれないし、
そういうミスは複雑な並行をする設計にしたらいくらでも起こるって話になんでコードがいるんだよ

629 ：
あ、それともRustなら代入する先の変数を型が同じ別の変数と間違えるレベルのミスもカバーしてくれるとかそういう話ある？
それなら俺が悪かった

630 ：
人間が把握できるレベルまで設計を単純にできれば開発レベルに差はつかない君

631 ：
まあ簡単なことをわざわざ複雑にしたがる君はどこでもいるよね
意地でもバッチ使わない奴とかマジで害悪

632 ：
データ競合の話をしてくれ

633 ：
>>628
>>629
Rustなら不注意な変数の扱いをコンパイラが
検出してくれる
という話をしてるときに設計ミスなら
何でも起こりうるとかドヤ顔されても
はぁそうすかーとしか返せんけど
何しにきたの？

634 ：
仕様の間違いを言語が指摘してくれるなら何も書く必要ないな

635 ：
だから変数の不注意な取り扱いの話だろ？
変数の取り違えは不注意な取り扱いじゃないのか？

636 ：
最初は安全でないケースはいくらでもあるとか言ってたのに、なんで話をそらすかね
レッテル貼るのが好きで論破ァしたいのは伝わってきた

637 ：
>>635
お前話理解してないなあ

638 ：
お前らまだやってるのか。
まあ、仕様が間違ってる部分でコンパイラ通らなかった事はある。
分岐やステートマシンが網羅性満たしてないとか。

639 ：
>>612
Rustでコンパイル通るけど危険なコードの
例を出してくれれば議題になると思うのに残念だ

640 ：
rustの偉い人教えてください。

rustではポインタ演算できますか？
unsefeという指定をすればできる？
関数ないでしなきゃいけなくてオーバーヘッドになったりしないでしょうか。

641 ：
Rustでポイント演算が必要な場面ってどんなとき？

642 ：
オーバーヘッドになるかは、自分でLLVMコードを比較しないと分からないと思うよ

643 ：
Rustのguiライブラリーでつかいやすいものありますか

644 ：
中間コードを見てパフォーマンスを語るアホ
しってた？最適化はLLVMの仕事なんだよ？

645 ：
しってた？低レイヤの最適化はLLVMの仕事じゃないんだよ？

646 ：
rustのコードは最適化有効にするとllvmの時点でかなり消えてるから最適化の有無でrustcが吐いたllvm-irの比較できるよ。

>>643
用途とプラットフォームによるから要件指定して出直して。

647 ：
>>646
比較はできても実際にオーバーヘッドになるかどうかは最終的な機械語を見るまで分からないよね

648 ：
検査例外みたいなもの？Result

649 ：
>>643
OrbTKとAzulとDruid試してどれが良かったか俺に教えてくれ
どれもまだ作りかけって感じみたいだが

650 ：
>>648
無視できるから検査か実行時で言えば実行時。ただ、例外機構はpanicの実装がそれ。

651 ：
>>641
c言語側で構造体の配列を共有メモリに置いたのをアクセスしたいです。
rustではこうしろ、でもいいので教えてください。

652 ：
>>651
共有が可変ならコンパイラ通せないなそれ。raw pointer使いたいだけならcだけでやったほうが良い。

653 ：
https://crates.io/crates/shared_memory
これダメ？

654 ：
>>653
それはosの機能使ってるだけだから元々c使ってるならrust追加する意味がない。
よく読んでないけどservoのipc-channel見た感じ共有メモリ使ってないみたいだし、rust使うなら安全性優先してそうなるだろうね。
当然の帰結だけど潜在的に安全ではない方法で書かれたコードとrustは相性悪いよ。

655 ：
>>652
ありがとうございます。🙇
一応サイズやオフセットの情報は貰えそうなんですけどね......。

656 ：
>>646
>>649
すみません
環境はWindowsを想定しています

657 ：
>>649
azulはWYSIWYGじゃないmorphicにcssもどき付けてオブジェクト指向じゃなくてPFにした感じ。要はReact。

658 ：
危険なオペレーションをunsafeで包んで安全なインターフェースを提供できるのがrustの良さなのに
潜在的に安全性ではない方法とrustの相性が悪いとはどういうことなのか

659 ：
RustってCと比べて何ができるんですか？

660 ：
おんなじことをめんどくさくかつ安全に書けます

661 ：
>>658
インターフェイスを安全にしたところで潜在的に危険な部分は残るからでは？

662 ：
>>655
Cで確保した構造体の配列に対してオフセット計算したいならこれとか使うけど。
https://doc.rust-lang.org/std/primitive.pointer.html#method.offset

663 ：
vlangのサイトが少し更新されて改めて日本でも多少話題になってるな

https://vlang.io/
これがすべて本当ならRustにとって大打撃だが

664 ：
読んだけど詐欺だろ
こんなのできるわけない
どっかで非現実的なこと要求してきたりして実用できないポンコツだろう
PatreonやPayPalでのDonateを募っている。
サイトにサンプルコード書いてある以外以外誰もコンパイルしたことなければコンパイルしたコード動いてるとこ見たこともない

665 ：
>>663
話題になっているならスレ立ててこのスレから独立したまえ

666 ：
比較するならもっとちゃんと比較してほしい。
載ってるサンプルソースじゃ単純過ぎて何で書いても大差ないし。
循環参照ありのコンテナ型とかCライブラリの安全なラッパーみたいな所有権とライフタイムがバリバリ出てくるやつが見てみたいが。

667 ：
>>663
リリースは夏じゃんか、出てからでいいよ
金を集めてトンズラするための宣伝な気もする

668 ：
とりあえず否定から入ったり、
趣味で作ってるものに責任感求めたり
やな日本人

669 ：
存在しないものは盲信できない。
キミ新興宗教に気を付けなね。

670 ：
ヴェーパーウェアって最近聞かないな

671 ：
出てから考えればいいよ
標準ライブラリが400KBとかネタっぽいけど

672 ：
Rustて30GBもくうの？

673 ：
>>672
racer用にソースコードと、クロスコンパイル環境いっぱい落としたらそんくらいになりそうな気もするが、
最小限のターゲットで30Gは使わんと思う

674 ：
slackに行けないコミュ障老人スレはここですか

675 ：
>>662
ありがとうございます。
rustの勉強本格的に始めたいと思います。

676 ：
slackとかMozillaの息のかかった詐欺師の巣窟じゃん
むしろどこに行く理由があるのかわからん

677 ：
Mozillaの陰謀説久しぶりに来たな

678 ：
>>663
コンパイルしたやつに型の情報とか残ってないとホットリロードってできないですよね？

679 ：
rustやるにしても日本人と絡むのはやめとけ。
マジでバカしかいないから。

680 ：
rust興味あるけど仕事で使ってる人いるの

681 ：
副業解禁で激変する若者世代とマネージャー世代のキャリア観
https://www.businessinsider.jp/post-107782
フリーランスの職種20個の仕事内容と平均年収をわかりやすく解説
https://www.proof0309.com/entry/shokushu
時給1万円のバイトも。会社員向きのプチ副業を、“バイト芸人”が教える
https://headlines.yahoo.co.jp/article?a=20190226-00127948-bizspa-bus_all
副業が「会社にバレる人」と「バレない人」の大差
https://headlines.yahoo.co.jp/article?a=20190303-00268007-toyo-bus_all
正社員の10%以上が副業　中には過重労働で体調崩す人も
https://headlines.yahoo.co.jp/hl?a=20190227-00010000-wordleaf-bus_all
「副業で年2000万円稼ぐ男」に学ぶキャリア戦略
https://headlines.yahoo.co.jp/article?a=20190221-00266856-toyo-bus_all
加速する「副業社会」正社員の4割が「副業したい」 気になる収入はどれくらい？
https://headlines.yahoo.co.jp/hl?a=20190218-00010001-danro-life
おすすめ副業22選を現役フリーランスが解説【在宅も可能】
https://www.proof0309.com/entry/zaitaku-hukugyou
会社を辞めてフリーランスで働きたいあなたが知っておくべき10のこと
https://www.businessinsider.jp/post-165731
フリーランスと会社員､働き方の根本的な差 広がる｢雇用されない働き方｣の課題とは何か
https://toyokeizai.net/articles/-/263055
フリーランス人口は増える！今後は仕事もプロジェクト単位になる!？
https://freelance.mts-career.com/population/
どのくらい稼げるの？フリーランスエンジニアの単価・報酬・年収の話
https://findy-code.io/engineer-lab/engineer-unitprice-income

682 ：
>>680
この求人なんかはRustの開発経験要求してたりするよ

https://jobs.atcoder.jp/offers/82

683 ：
>>682
数Cがあった頃に高校で数Cが選択されずに数Cが範囲外の大学行った人が
何故かマやってたら必須要件満たせないんだな。
薬学系が何故かデスマやっててお薬貰ってたりしないだろうか。

684 ：
>>682
これで400〜はクソやろ

685 ：
ほんそれ
今時下限400の会社なんて人集まらないでしょ

686 ：
>>682
内容が逃げられた所の補充くさくてこえーわ。

687 ：
dieselのreplace_into(UPSERTみたいな)で更新したい項目を絞り込みたい時ってどうすればいいですか？

688 ：
https://twitter.com/hashtag/rust_jp

↑こういうのチェックしてます？
(deleted an unsolicited ad)

689 ：
誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 12053
https://you-can-program.hatenablog.jp

690 ：
while let Ok(t) = honyarara() {}
と書いた時にtがcannot infer typeと言われた場合どういうふうに型を指定すれば良いのでしょうか？

具体的にはこれの後半のデシリアライズの部分をループに書き換えたいのですが…
https://gist.github.com/rust-play/fa2d277652052fcbd6a72273a0cb70ce

691 ：
while let Ok(v) = a as Result<String, ()> {

692 ：
>>691
()の部分も指定したらいけました、ありがとうございました

693 ：
rustでreduxやろうとするとかなかなか面白い。案の定middleware周りで詰まってるが
これがうまく処理できれば結構いいんじゃないか。
https://github.com/rust-redux/rust-redux

694 ：
本気で手を出したこと無いんだけど、そういうフレームワークをRustに持ってきて良い感じのabstractにできるの？
メモリとかリソースの確保のコードで見づらくなったりしない？

695 ：
また今年のsurveyでもrustが一番好かれている言語になったな
rust好きなんだけど正直ここまで好かれる理由がわからない

696 ：
C++に嫌気が差した潜在的なユーザーが多かったのでは？

697 ：
ブロックがその最後の値を持つ式だというのはいい。
そして、式にセミコロンを付けると文になるというのもわかる。
でもその両者を混ぜるとあんな残念な文法に。

698 ：
c言語とどっちが性能高いの？
なんかRustの方が性能良いみたいなベンチがちょっとあるみたいだけど。

699 ：
>>697
> でもその両者を混ぜるとあんな残念な文法に。

その残念な文法は具体的にどこをどうすれば良い文法になるの？

700 ：
こうする。

Bosque Programming Language
https://www.microsoft.com/en-us/research/project/bosque-programming-language/

> The Bosque programming language is designed for writing code that simple, obvious, and easy to reason about for both humans and machines.

https://github.com/Microsoft/BosqueLanguage

701 ：
残念ってのはブロックの最後にセミコロンを付けちゃうと値を返せないってとこね。
>>697に書いたようにそれぞれ合理的な選択を組み合わせた結果だから解決策があるとは限らない。
ただ、式文はUnit型じゃなくて式の値を持つってことにするのは無理だったのかな。

702 ：
>>695
イヤでも使わなきゃならないのが優れた言語
嫌な奴はさっさと逃げ出して残った少数にもてはやされるのが（ｒｕ

>>698
ベンチの取り方も知らないみじく者にもてはやされるのが（ｒｕ

703 ：
>>34の画像ってどこのサイトからもってきたの？

704 ：
>>701
代入が値を返す場合、代入された値が戻り値へとmoveされてしまうから問題がありそう

705 ：
代入式の値はUnitでいいんじゃなかろうか。もともとCのような代入の連鎖はできないわけだし。

706 ：
https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=765849a4e776e00b0c614fc941b02ecf
Defaultを実装してない構造体のフィールドのうちDefaultを実装してるフィールドだけまとめてdefault()で初期化するような記述方法は無いでしょうか？

イメージとしては
let s = S { nd: NonDefault::new( "foo" ), u: Default::default(), i: Default::default() } ;
の部分を
let s = S { nd: NonDefault::new( "foo" ), _: Default::default() } ;
のような形で書けないでしょうか

707 ：
>>706
マニュアルに
SomeOptions { foo: 42, ..Default::default() };

708 ：
>>707
ありがとうございます、ただそれだとSomeOptionsがDefaultを実装している場合の記法ですよね？
(実際試してもthe trait bound `SomeOptions: std::default::Default` is not satisfiedとなります)

質問としてはSomeOptions自体はDefaultを実装していないけど、そのフィールドのうちDefaultを実装している型の値はまとめてdefault()で初期化したいってことなんですが…

709 ：
そういうときは初期化子直接使うんじゃなくてコンストラクタ定義すんのよ

710 ：
新刊の「実践Rust入門」が売れているらしいね

711 ：
κeenさんの所でもまだ出てないのに売れてるらしいと書かれてたけどどういう事なんアレ？

712 ：
先行販売というのがありまして

713 ：
都内の大型書店には結構出てるし電子版は連休前が発売日だったはず

714 ：
電子版と紙で発売日違うのか。なるほど。

715 ：
結局ここまでまともなソフトが出ないってのはそういうことなんだな。

716 ：
>>715
え？どういう意味？

717 ：
急にアンチRustが勝ったのか

718 ：
はい論破

719 ：
メインでrust使ってる企業あったら入りたいもんだけど、実際使ってる企業あるの？
モダンな言語だとせいぜいGoとかelixirじゃない？

720 ：
世界コンピュータ将棋選手権に出た強豪ソフトがRust製で
公開予定

721 ：
人間からすれば強豪でも、予選落ちで強豪ソフトと呼ぶのは違う気もする

722 ：
Rustの本どんなもんかとアマゾンで見てみたら、
中華業者の星5レビューばっかで色々と察した
そもそもの話の言語自体が胡散臭いのも納得

723 ：
ライフタイム引数のクソさはもうどうにもならんな。
変な省略ルールとかつけて逆に分かりづらくなるとか本末転倒もいいとこだ。

724 ：
省略ルールのありなしに関わらず分かりづらいだけでは

725 ：
アマゾンのレビュー1件しか無いんだが

726 ：
https://ja.wikipedia.org/wiki/Rust_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E)
>実行時速度性能はC言語と同等程度である[8]。

これマジ？

727 ：
こんな記事を見つけた

＞Rustのコードを用いたこのためのテストの平均はCコードの実行したものの3.040倍と同じくらいだ。

＞この関数により、我々はRustが平均的に2.036倍Cよりも遅いことを知った。

やはりCの方が速いな。省メモリという点でもCが一番だし

728 ：
＞Rustが事実上Cよりも遅いままで終わってしまったという事実は、より落胆させられた。

＞また、全体を通してRust言語は、
この手の高水準な完成されたシステムを作る手助けをすること、
そしてこの領域において少量の変更で効果的にCを置き換えることができることを示すことができた。

現状のRustはCを置き換えれないけど、
将来的な改善まで含めればできるはずだと主張してるな。。

729 ：
鬼が笑うなｗ
実現してから言えとｗｗ

730 ：
Cと同等はさすがに無理にしても、もう少しCに迫る性能が出ないと、C／C++から脱出したい人の受け皿にはなれないんじゃないか？ あるいはCの2〜3倍遅い程度なら許容範囲内ということで割り切るしかないんだろうか。

731 ：
2015年の記事だぞ

732 ：
それが許容できるならNim早く1.0になーれ

733 ：
>>732
nimのllvm版 nlvm はどうよ？

734 ：
>>724
ライフタイムとムーブについてはそこまで複雑な概念ではないよ。
ライフタイムに対するシンタックスがヘンテコなだけで。

735 ：
RustでLinuxカーネルを書き直す時代はこなさそうだな

736 ：
>>726,727
メモリを自分で面倒見る分とセキュリティチェック甘い分早いだけだからcでリージョン使ってメモリ管理して配列の境界チェックとかもすれば似たようなもんだ。
rustのpanicはきれいに落とすぞ。ただ、ランタイムデカイ分とrust用のメタデータ含む分でフットプリントはcの方がいいと思う。

>>734
リージョン推論間違えるか効率悪い位ならリージョン指定させてほしい時はある。

737 ：
>>735
新しいOS作れば？
なんだったらAndroidみたいにLinuxの上に構築。

738 ：
それをRustでやってもCで書かれたOSを上回れないという話でしょ

739 ：
パフォーマンスとかどうなんだろな

https://www.redox-os.org/jp/

740 ：
https://discourse.redox-os.org/t/redox-performance/966

まだ初期段階だから比較しないで、みたいな事言ってる

最終段階までいってもCを超えると思えないんだが
しかもLinuxは組み込みでも使われてるがそれはCが省メモリだからで
Rustが勝てる見込みは無いと思うんだがなあ

741 ：
原理的には負ける理由もないと思うけどな。
Cは基本ノーチェックで脆弱性が見つかったらチェック入れるのに対して
Rustはいろいろチェック入ってるのをunsafeで外してパフォーマンス上げていくから
最終的に同じところに収束する気がする。
まぁ途中段階とか未知の脆弱性を放置する前提なら勝てないんだけど。

742 ：
中華ステマ企業が今押せと言われてるイチオシの言語Rust使ってるやつおるん？

743 ：
いつもの
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html

744 ：
そのサイトいっつも思うんだけどベンチマークの並べ方恣意的じゃない？
vs Cではmandelbrotが下の方にあるけど
vs Javaでは上から2番目

Rustが勝利している項目では太字だけど
Cが勝利している項目では太字にならない

vs C++では、5項目でRust勝利、5項目でC++勝利で互角なのに、
Rustだけ太字でしかもRustが勝利したベンチマークから並べられてる。

俺はそのサイト少しも信用してない

745 ：
さらに言えば言語によって使用されるベンチマークがいつも違う。
勝たせたい言語のためにベンチマークを選択している可能性がある。

新手のマーケティングじゃないの？

746 ：
恣意的の意味するところがわからんけど
C++からだとRustに勝ったベンチマークだけ太字
C++が勝利したベンチマークから並べられるよ
使用されるベンチマーク云々はちょっとわからん

747 ：
>>742
Amazon Intel Microsoft Dropbox Nokia Fastly DiscordはGitHubでみた

748 ：
中国語ブログの方がRustに対して冷静な評価をしてる印象
https://www.oschina.net/translate/rust-vs-cpp
https://www.cnblogs.com/Bob-wei/p/5680648.html

彼らはRustの将来をどちらかと言えば悲観的に見ている

749 ：
ソース公開されて比較的新しいコンパイラを使って測定されるbenchmarksgameは信頼ならなくて
2016年に書かれた中国語のブログにあったフィボナッチ数列のベンチマーク(ソース非公開)の方が冷静？

750 ：
rust推す人もステマする暇があったらrust dockerでも実装すりゃいいのに。
性能と安全性でいえばgoの実装以上のものができるんでしょ？

751 ：
中華ステマ企業がって話があったから中国語圏でどうなのかなと思って調べただけ

あとそのサイトを信じるなら、5項目でRust勝利、4項目でC勝利で、
RustがCより速いという事になる。
その結論は信じがたい。

752 ：
ソースあるから実行すれば？https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html
俺はdockerを実装しなきゃいけないことになったから

753 ：
モジラのステマと買収から中国の陰謀まで進化したのか

754 ：
rustで書かれたコンテナエンジンはオラクルが作ってたろ
goのgcによるボトルネックがひどすぎるとかで

速度のベンチマークなんてほとんど意味ないだろ
生産性のがはるかに大切

755 ：
n-bodyのソースとか見ればわかると思うけど、メモリレイアウトとかSIMDとかほぼCと同等まで詰めてあるから、Cに勝っても何の不思議もない。
実質gccとllvmの最適化対決って感じでは。

Arena使って素朴に書かれたbinary-treesが勝ってるのは結構すごいと思う。

756 ：
railcar誰も使っちゃいねえ。。

757 ：
そりゃ互換実装なんてよっぽどメリットがないと使われないでしょ。
railcarは完全互換ですらなかったし。

firecrackerとかlucetみたいな独自路線の方がまだ見込みあるんじゃない？

758 ：
googleに中国人社員どれくらい居るんやで

759 ：
>>757
オーバーヘッドもなくセキュリティー的にも安定な実装というメリットがある
はず。

760 ：
http://yaneuraou.yaneu.com/2019/05/23/3%e5%b9%b4%e4%bb%a5%e4%b8%8a%e8%aa%b0%e3%82%82%e7%99%ba%e8%a6%8b%e3%81%a7%e3%81%8d%e3%81%aa%e3%81%8b%e3%81%a3%e3%81%9f%e6%8e%a2%e7%b4%a2%e9%83%a8%e3%81%aebug%e3%81%8crust%e3%81%ab%e3%82%88%e3%81%a3/
C++をRustで書き直したらバグ発見とのこと
なかなか面白いな

761 ：
コンバイル時かと思ったら実行時の検知かよ…

762 ：
GitHub’s Top 100 Most Valuable Repositories Out of 96 Million
ttps://hackernoon.com/githubs-top-100-most-valuable-repositories-out-of-96-million-bb48caa9eb0b
rust 5位だてよ

763 ：
ランキングもベンチマークもいくらでも恣意的に操作できる

実際に製品としてどんくらい世に出たかが全てだけど
Rustはどこの企業も口を揃えて「内部実装で使ってます」って言うだけで
動いてるコードを見たことがない

764 ：
>>763
企業で使ってもクローズドソースならそもそも何使っても見れないんじゃない？

765 ：
AWS https://github.com/firecracker-microvm/firecracker
Fastly https://github.com/fastly/lucet
Dropbox
Microsoft https://github.com/Azure/iotedge https://github.com/dropbox?utf8=%E2%9C%93&q=&type=&language=rust
Intel https://github.com/intel?utf8=%E2%9C%93&q=&type=&language=rust
Cloudflare https://github.com/cloudflare?utf8=%E2%9C%93&q=&type=&language=rust

恣意的に集めてみたけど使ってる証拠にはなれないんだな

766 ：
全く使う気にならないツールばっかりってのがすげーな。

767 ：
俺もAWSは使う気になれんな

768 ：
プロダクトがあるか無いかより、「xxxで作ってたものをrustで作り直したよ！」って話が多いのが気になる
既存の作り直しよりも新規性のある何かが出来て、それを皆が使いたくなって言語が広まるってのが普通だと思ってる
(goならdockerとか)
rustでそういうのがまだ見えないのはちょっと嫌な感じはしてる

769 ：
もともとC++は辛いので作り直せる言語を作ろう
だからしょうがないんじゃない

770 ：
C++はまだ進化中(複雑化中)だし、C++使ってる分野では特に移行する必要がないというか

771 ：
Rustは学習を終えたとしてC++より開発効率良いの？

772 ：
>>768
重箱の隅で申し訳ないが、Goなのはk8sだと思う

Rustでキラーアプリ出ないのはある意味当然で
そういうものって未完成でもとりあえずぶち上げてコンセプト見せないと流行らないんだが
Rustって真逆で完璧に作らないと動かない言語だから
キラーアプリの作成とそもそも相性が悪い

773 ：
つまりrustで作られたものは完全無欠ってこと？
そんなばかな

そもそもなんでメジャーな採用事例を気にする必要があるの？
自分が作ってるプロダクトがrustと相性がよければ使えばいいだけじゃん

774 ：
キラーアプリってあれか
RubyがRailsで人気爆発あるいは
ディープラーニングやるならPython
みたいな話期待してるのか？

775 ：
C++にはキラーアプリがないと思うけどそれでいいと思う

776 ：
そもそもキラーアプリが言語の普及に影響したのってRailsくらいだと思うけど。
別にdockerやk8sのユーザがgoで実装しなければならないってことはないでしょ。

777 ：
>>771
rustで学習を終えてc++で作るのが一番効率が良い。
つまり学習用と割り切ればかなり意味のある言語ではある。

778 ：
メモリエラーを気にするならfortran使えば？

779 ：
Kotlinもよろしく

780 ：
C++で痛い目にあってからRust覚えた後にC++の最新verに戻るのが最適解

じゃないとRustの諸々の安全装置がなぜあるか理解し難く面倒臭いだけと思われてしまう

781 ：
C++に戻るつもりが戻れなくなってしまったな。
最新ならC++の言語機能には特に不満はないけど、標準のテスト・ビルドツール・パッケージマネージャがないのが辛すぎる。
戻った人たちはその辺どうしてるんだろう…。

782 ：
困ってない
標準にこだわる理由は？

783 ：
いろんなOSSを触ってるとプロジェクト毎に独自の流儀で、それぞれにいちいち合わせるのが面倒だし、
新規プロジェクトでも何を採用するかで悩む。
別に標準化とかされなくてもデファクトスタンダードが一つに決まってれば十分なんだけど。

784 ：
C++とくらべりゃRustのほうがスッキリしてるやろ
Cのほうがもっとスッキリしてるけど

785 ：
cargoが糞すぎて標準だと困る。

786 ：
> 標準のテスト・ビルドツール・パッケージマネージャ

最近のプログラミング言語はそれぞれがこのシステム作るよな
言語を超えた協調もなく

787 ：
意味わからない
どゆこと？

788 ：
>>786
そりゃ、ライブラリの名前だけでも共用すればいいのに、と思いますがそれもできていないし…

789 ：
なんの意味が？？

790 ：
Ruby のBundler で、各プロジェクト毎に、異なる依存ライブラリを管理するのが便利だから。
それで、Node.js のnpm, yarn も同じように作った

他にも、Vagrant, Chef, Homebrew など、バージョン管理はRuby で作られる

791 ：
クソ言語のことは聞いてない。

792 ：
cargoで困ってない

793 ：
vagrantもchefもrubyで作られてるからだしょ？
そもそも言語じゃないし
何が言いたいのかさっぱり分からん

794 ：
「俺のやりやすいやり方に周りは合わせろ」ってことだろ。よくあるクソ意見だよ。

795 ：
Cargoは近年稀に見るクソパッケージ管理ツールだろ
これなら散々クソクソ言われてきたけど
最近pipenv出してきたPythonの方がマシまである

796 ：
具体性具体性

797 ：
https://keens.github.io/blog/2018/08/26/cargonodokogaiinoka/

ビルドとパッケージ管理を変に混ぜてグダってる。
こういう言語にありがちなビルド速度軽視が大問題。

798 ：
ひとつの仕事をうまくこなせと言いたい

799 ：
クソのクソクソにありがちなグダっぷり？

800 ：
ビルド速度が遅いビルドツールの代表のsbtより遅いのがクソ
crates.ioに強依存しててオフラインビルドができないのがクソ
gitに強依存しててアーカイブ形式で配布できないのがクソ
そもそもcrates.ioの運営がクソ

あといくつ欲しい？

801 ：
ビルド速度が遅いのをパッケージマネージャのせいだと、言語の違うものと比べて言われてもなんともな
crates.io関連はこれ
https://github.com/rust-lang/cargo/issues/5655#issuecomment-488347426
https://github.com/rust-lang/cargo/issues/6589
アーカイブ形式は無理っぽい
https://github.com/rust-lang/cargo/issues/1139#issuecomment-69398250
>The ABI for a library is not stable between compilations, even when theoretical ABI-compatible modifications are made.
あといくつ？

802 ：
gitへの依存ってあったっけ？
crates.ioからはソースアーカイブDLだから
gitプロトコルは使ってないと思うけど。

803 ：
>>800
ビルド前のスクリプト実行は出来るのにビルド後のスクリプト実行が出来ない
も追加しといて

804 ：
勉強中なんだけど、rustってそんなにビルド遅いの？

805 ：
>>804
「ビルドする度にコーヒーブレイク」と揶揄される某言語より遅い

806 ：
>>805
いやあれよりは速いよ
まあかなり遅い部類に入るのは認めるが…

807 ：
某言語って何？
いじわるしないで教えろよ！

808 ：
遅さではscalaが有名かな
まぁrustが遅いのは遅い

809 ：
前実測したけどscalaより遅かったぞ？
依存ライブラリ数の差の可能性はあるが

810 ：
scalaとビルド速度競ってる時点でお察しのクソ言語

811 ：
まあ仕事で使ってなきゃビルド時間なんか気にならんもんな。
遊びでやってる層にはコンパイル時になんでもやるってのは受けがいいんだろ。

812 ：
ていうか何をビルドして計ってるんだよ…
一切出てこないまま話は進んでるのか？

813 ：
折角なのでHelloWorldのコンパイル速度比較してみた。
まぁ条件は適当なので参考程度だが。
毎回ビルドキャッシュ削除した状態からの10回平均。

C: 41.9ms
C++: 150.9ms
go: 211.4ms
D: 307.3ms
Rust: 320.1ms
Java: 346.5ms
Erlang: 1005ms
Haskell: 1106ms
C#: 3000ms
Scala: 6712ms

こうしてみるとCは異常に速いけど、Rustはまぁ普通と言ってもいいかもね。

814 ：
そういうことじゃねーよばか。。

815 ：
ビルドが遅いのはコンパイラの遅さだから根本的には別問題。
cargoがロクに並列ビルドできないのもこっち側。

>>800,801
- 不要な条件付きの依存関係が要求されてビルド/テストできない
- rustup wrapperが遅すぎて色々タイムアウトする

が抜けてる。issue乱立しすぎて最新のissueがどれか分からんからリンクは貼らん。
無駄にissue分けすぎて他にも細かいのが色々あるけど、結局は中央リポジトリに依存しすぎ、オフラインモードが使い物にならない、
パッケージマネージャとビルドツール融合してどっちとしても使い物にならないに集約される。

>>804
intellij rustがon the fly analyze実装したから設定から有効にして試せばいいよ。
サンプルプロジェクト程度じゃ影響ないから実践に近いプロジェクトで試さないと分からないけど。

816 ：
しかし実際遅さが気になるプロジェクトってどんなサイズ？
普段開発してるソース1万行で依存クレート100個くらいの規模だと気になったことがないんだけど。
もちろんクリーンな状態からの初回ビルドはそれなりにかかるけど、ソース書いてるときに依存クレートの再ビルドってほぼ発生しないし。

817 ：
>>814
どゆこと

818 ：
rustで競技プログラミングが流行りだす？

819 ：
>>818
ないない
競プロはメモリリークしてようがコーナーケースでバッファオーバーフローしようが
とにかく規定の入力に対して速く答えを返すものを
エラーハンドリングとか考えず手早く実装するのが正義
Rustと一番相性が悪い分野だろ

820 ：
>>815
端的に集約するとそれだよな
未だにこれが「他の言語のパッケージマネージャーの良いところを集めて地雷を回避した理想的なパッケージマネージャー」とか言ってるやつは
それこそ金掴まされてるとしか思えんくらいにクソ

821 ：
困るのは分かったけどなんで困るの？
2年くらい仕事で使ってるけどあーカーゴって便利だなぁとしか思ってなかったわ

822 ：
明らかにMozillaに金掴まされたな

823 ：
それならRustの歌でも作って武道館で歌うくらいやるけどなあ

824 ：
笛吹こうぜ

825 ：
なんでMozillaは俺には金掴ませてくれないの？

826 ：
なんかもうちょっと具体的に
こういうことやると苦労する破綻するという例が欲しいな
他の言語やツールとの同等のことやろうとした比較があるとなお良し

827 ：
困る人は是非積極的にcargoにissueたてるなりpull req送って欲しい
人的リソースが足りないのよ

828 ：
Mozillaに金掴まされてるは例のキチの常套句だったなそういえば

>>826
まずcrates.ioそのものは、使う側じゃなくてライブラリ公開する側になったらクソだとわかる
こればっかりは使って体験してくれとしか言えん

ビルドの遅さは、例えばDockerみたいなコンテナの相性がよろしくない

crates.ioに強依存してるから、aptでいうところのsquidみたいなことができない

これらの問題はカジュアルユースなら問題にはならんだろうが、プロユースには耐えんのよ

829 ：
aptでいうsquid？ミラーがほしいってこと？
俺の周りのプロはもうそんなことやってないけど。。。
multi stage buildでもしたらいいんじゃないの

830 ：
それはプロユースに耐えんのではなくて、そういう職場もあるってだけの話では？
crates.ioは複数ライブラリ公開しててもクソさが分からんしなぁ。
逆にこのパッケージリポジトリは素晴らしい、とかあるの？

831 ：
>>828
ビルドが遅いという以外何が問題と言ってるのかわからん

832 ：
それで十分だろ。
それがわからんやつはboostマンセーして人に迷惑かけてもなんとも思ってない馬鹿と同列にしか思わん。

833 ：
出来上がったバイナリが速ければ問題ないんじゃない?

834 ：
せ…せいさんせいがおちるだろう！

835 ：
rustを良い言語だと評価してるやつはrustとより酷い言語しか使ったことないんだろうよ、VBAとか

836 ：
最初から期待している点は2つ
１つはHaskellで実証されてる、型システムが豊かであることの安全性と利便性をC並みに低レベルな世界に持ち込んで組み込み業界に1石を投じること
もう一つはオブジェクト指向を言語仕様に取り込まなくてもオブジェクト指向でやりたいことの大部分は実現可能だと証明して、OOPパラダイムを衰退させること

837 ：
とあるツールをcargoでビルドしたら、同じcrateが重複してバージョン違いで使われてて驚いた
そんなのアリなんか

Compiling env_logger v0.5.13
Compiling env_logger v0.6.1

838 ：
a crateとb crateがそれぞれ違うバージョンに依存してたらそうなるだろう
アリというかそうじゃなきゃ困るだろう
そうじゃない言語もあるけど

839 ：
hogehoge-sys みたいな外部のライブラリに依存するcrateだと異バージョン混在できなくてつらい
.soを実行時にリンクする都合上仕方ないのだけど

840 ：
絶対に
絶対に
所有権の移動のほうに記号がつくべきだった

841 ：
>>836
それ以外の部分がクソ過ぎてやっぱダメだわってなってるのが今
以前はこのスレにRustへの苦言かきこんだらボロクソに言われたもんだが
今では俺以外にもRustはクソって声が増えてる。良い傾向

842 ：
rust好みだよ。

843 ：
まあ使ってみないと本当の意味でダメさ実感できないからな。
実際にさわってみたやつが増えて夢から醒めたんだろｗ

844 ：
とある言語についてはいかがかと思う節もあるな〜

845 ：
これ以上バカを現場に増やさないためにプログラム教育にはビルドって科目も入れるべきだな。

846 ：
お前にとってクソで大嫌いなのはわかったから冷静になれよ

847 ：
>>840
それは無理があるんじゃないか？
&で借用が妥当だと思うけど

&は借用の記号と同時に型の情報としての意味も有るはずだから
その点で問題が起きると思うが…

848 ：
例えば移動に記号をつけようとすると
T型と&mut T型の変数を移動する際はそれに全部記号を付ける羽目になるぞ
それでも良いのか？
ちなみに&T型は移動ではなくコピーなので除外したがコピーであって借用ではない
>>840はコピーはどうすべきだと思っているが知らないが
コピーにも記号を付けろと言うならさらに面倒なことになる
本当にそれでも良いのか？

849 ：
'=' の現状のrustの意味の統一を考えれば現状の仕様が妥当だわな。

850 ：
まだ他にも問題はあるぞ
例えば移動をmoveで借用を記号無しにすると
let a = 1_i32;
でaはi32型でなく&i32型になる。なぜなら記号無しは借用だから。
aがi32型になるためには
let a = move 1_i32;
と書かなければならない

さらに言うと
let a = move 1_i32;
let b = a;
let c = b;
でaはi32型、bは&i32型、cは&&i32型となるわけだ

俺はそんなヤバイ言語は使いたくないぞ

851 ：
この際に言いたくなったから言わせてもらうけど
時々「俺の方が良い言語作れる」とか言ってるヤツがいて
それに対する反論に「じゃあコンパイラ作ってみろよ」とか返してるヤツいるけど
そもそもコンパイラを作る実力が有るか無いか以前に
言語をデザインすることの難しさを分かってないヤツが多すぎて
コンパイラを作る段階にも至っていないっと思うわけよ

852 ：
俺は言語を作るセンスないし他のやつもなさそうだしお前にもなさそうだからこの話題はやめとこな
不毛だからな

853 ：
>>850
記号なし=はコピーで統一したらよい
Ｃ＋＋はやってるじゃん

854 ：
>>853
ポインタの基本をコピーじゃなくてムーブにしたいからムーブの方を記法的に容易にしたんだし、auto_ptrのセマンティクスの非統一による悲劇を避ける為にムーブに統一したんだよ？
議論の順番が滅茶苦茶だぁ

855 ：
uniqueとshareでなんとかなってるじゃん

856 ：
メモリ以外のリソースはコピーできないものが大半じゃね？

857 ：
変数がどの範囲で利用可能なのかぱっと見わからんのが酷すぎる

858 ：
>>856
コピーできないようなまとまったオブジェクトをほいほい変数移さないだろ

859 ：
>>853
取り敢えず借用を記号無しにするのは無理であることは納得してくれたの？

そして移動はどうするの？rustだと移動も結構しょっちゅう使うんだけど…
例えばBox型とかString型とかVec型とか&mut T型とか…
移動もコピーもどちらも=なのが判りづらいってのは一理有るんだけど、
それらの移動に全てmove等の記号をつけていくのはあまりにも面倒だと思うよ

860 ：
>>857
ぱっと見でわかるってどんな感じなの？

861 ：
>>860
所有権を手放すときに記号つく

>>859
そっちを&にして
右辺値が無名で宙ぶらりんのときはつけないでいいことにしたら

862 ：
>>861
そっちってどっち？移動を&にするの？じゃあ借用はどうするのよ？
さっぱり言ってる意味が分からん
てか最初の質問に答えてくれないかな？納得したの？してないの？

863 ：
>>862
してない。俺も言ってることよくわからん

864 ：
>>863
えぇ…
じゃあ君は借用は記号無し=がいいってこと？
でも君さっき記号無し=はコピーが良いって言ったよね？

865 ：
だからやめろといったのに

866 ：
borrowこそ新しい概念なんだからそれに記号でもつけりゃよかったんだ

867 ：
変にc++のシンタックスと似るようにしたのは良くないかもな。
moveが基本だったり引数の意味がだいぶ違うわけだから。

868 ：
>>866
だからそのborrow(借用)に&と'a(ライフタイム)という記号が付いてんだろうが
頭大丈夫か？

869 ：
こわ びびるわ

870 ：
少なくとも所有権の移動は右辺に影響するんだからそっちにも記号がつくべきだった

あと見た目即所有権帰ってくるやつまで&で書くから見づらい
誰に貸していつ帰ってくるのかわかんねー

871 ：
2年rust書いてるけど君らのいう分かりにくい、が分らん
フューチャーが分かりにくい、なら抱き合って同意するけど

872 ：
経験者が経験上困らんっていうんならいえることない

873 ：
>>871
分かる。futureはマジで難しいよね
Pin/Unpinまでは辛うじて理解できたんやが、Wakerの方が分からん。
誰かRawWakerVTableの解説してくれ…

でもfutureの難しさはasync/awaitが導入されればそれに隠蔽されるから
利用するだけのユーザーならあと少しの辛抱や

874 ：
継続的に数年使ってる人は新機能が出たら新機能だけ覚えればいいんだろうけど
初めて触る人はその累積してきた機能全部を掌握するのは無理

875 ：
どの言語の話

876 ：
rustをシステム系じゃないエンジニア(C++の仕事してない)が使うメリットって何かある？

877 ：
>>874
C++のことかな

878 ：
廃止された機能や推奨されない機能も覚えておく必要がある
特にC++で言えばunicodeの変換(std::codecvt**)が超糞

879 ：
誰も使ってなかったから大丈夫だぞ

880 ：
「誰も使ってなかった」ことも含めて
その累積してきた機能全部(結局全部になるだろうな)を掌握する必要がある訳だろ

881 ：
なるほど素晴らしい観点っすね、実行不能という点に目をつぶれば。

882 ：
でぇじょうぶだ
[[deprecated]]
がある

883 ：
それついたの思いっきりつかってるｗｗｗ
昔のが商売人の都合で切られてるんだもん
つかうよ

884 ：
DX8ですね判ります

885 ：
rustでIDE補完が甘いのは誰も気にしてないんか？
そもそもみんなIDE使ってないんか？

886 ：
yes
yes

887 ：
なるほど
ありがと

888 ：
カドカワから月末に訳本の
プログラミング言語Rust 公式ガイドが出るけど2018対応じゃないよね？
Rust本が増えてきたのは嬉しい

889 ：
>>885
intelijのrustプラグイン

890 ：
>>888
バカが飛び付いて社内に導入しようとするの潰すの
毎回労力がかかってしゃーないからやめて欲しいんだけどな
クソ言語の本出すの

891 ：
>>890をクビにしたほうがいろんな労力減りそう

892 ：
いやもうクビにされたから

893 ：
無能なアンチがいるということは、安心して使っていいってことだな

894 ：
なんで潰すんだ？何に恐れているんだ？

895 ：
>>888
TRPLの翻訳だと思うけど
TRPL本家は2018対応済みで、webで公開されてる日本語訳は未対応。
本家に追従して対応した可能性もあるかと。

896 ：
そりゃクソコード残して辞めてくことだろ。
まじでRと思うわ。

897 ：
それは言語の所為じゃないだろ
レビューしないの？
しないにしても同じクソでもJavaやC++よりマシだと思うんだが

898 ：
言語関係ねーじゃんメンテする能力がないんだろ
諦めてgoで作り直せ

899 ：
>>895
ググったらTRPLでした
ただ紙の原著は2018年発売でRust 2018未対応
紙の翻訳なのか最新のWebの翻訳なのかは不明

900 ：
borrow checker通せない人にとってはすべてのコードが読めない糞コードなのだろう

901 ：
>>897
社内でそいつしか使わないから当然レビューも不能
上の人間も「いいじゃんやってみれば」で話にならない
結果まともにレビュー通ってないクソが本番に出てトラブル
作ったやつは雲隠れ

って流れを見たことあるよ。Rustじゃないけど

902 ：
もちろん言語のせいではないのだが
そういう輩は実績作りのためだけに新しくてより複雑なクソルールの多い言語を選ぶ傾向にある

903 ：
ボローチェッカに苦しめられてる人は
なにか他から移植をしようとでもしてるのかな？
ゼロからかくぶんにはボローチェッカなんて
ただただすがすがしいだけと思うけど
チェックご苦労さんですってもんだけど

904 ：
>>901
そういう体制だとCでもJavaでも言語に関係なく
色々問題起きてるだろ

905 ：
未知の言語を読むストレスは理解できるけど
一件正しそうなぶっ壊れたロジックを探し当てる方がはるかに辛い
Rustなら完璧だなんて思わないけど同じ条件で雲隠れされるならJavaやCよりはるかにマシ

906 ：
使いたいだけのバカに限ってRefCell使いまくりとかボローチェックなんか
関係ねーわなクソコード残していくわけだがな。

907 ：
結局プンプンの人達は何か言いたいん？
初心者が使ったら他言語より酷いことになるって話？
作り逃げされた時に他言語よりメンテきついって話？
それともrust関係ない話？

908 ：
>>907
結局どの言語だろうとワナビのキッズが使ってレビューも不完全なら悲惨なことになるし
Rustはそういうワナビホイホイなところがある言語で
キッズを拡散すんのは勘弁してくれってことよ

新しいものの宿命みたいなとこはある

909 ：
Rustを使いたいって奴はボローチェッカ最高勢だろ
筋の通らない話だ

910 ：
ボローは着てても心は錦

911 ：
ついにMSもmozillaのステマの被害者になったのか

912 ：
iotedgeの話？

913 ：
FireFoxでプライベートブラウジングモードにしたら
指定してダウンロードしたページまでブラウザ終了時に消しやがる
しかもfilesはそのままでトップのhtmlだけ

きっとＲｕｓｔの融通の利かなさのせいでこんな仕様なんだ
不条理すぎる

914 ：
空白行がちょっとわざとらしいかな

915 ：
>>913
Rust導入してからアドオンの互換性切るわバグ増えるわシェア1割切るわで
いいところのない火狐

916 ：
Itaniumみたいな失敗の仕方しとるな。

917 ：
dbっていうか、
OracleとかSqlserverに読み書きするような
アプリはあまり現実的でない？

918 ：
なんで？

919 ：
オラクルを使う常駐物のアプリを
一個書いたんだけど
プロプラなdb向けだと
crateの充実度的な意味で
大変だったし、保守してけるか
ちょっと不安だったので。

920 ：
プログラム板にキチガイ降臨中！botに一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
https://mevius.2ch.sc/test/read.cgi/tech/1559872586/

142 名前：a4 ◆700L1Efzuv 投稿日：2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な　俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか？
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人なんて復活ねーから。

921 ：
cargoの自動ダウンロード機能を使わないワークフローのチュートリアルが欲しい
足りないコードを示してくれるのは助かるけど知らないうちにGPLな奴が混じっていたなんて事態は避けたい

922 ：
https://github.com/onur/cargo-license

923 ：
パッケージで
依存するパッケージたちの実行可能な環境やライセンスやインストールサイズをパッケージインストール前に分かったりしない？

924 ：
>>923
実行環境以外はcrates.ioのAPIから取れるみたいだから可能は可能。
ツールになってるものはぱっとは見つからなかったけど
jsonパースしながら依存関係辿るだけだし適当に作ればいいのでは。

925 ：
【出資】松本卓朗 人工知能詐欺【注意】
https://rio2016.2ch.sc/test/read.cgi/rikei/1560859403/

926 ：
考えてみれば当たり前なんだがcargoはrust周辺しか面倒を見てくれない。他に依存するライブラリがあっても関与しない
つまりビルドは出来るが実行出来ないということが起きる。コード次第ではpanicして何が足りないかすら出力されない
ドキュメントに何を用意すべきなのかちゃんと書いていないcrateも少なからずあって不完全なメッセージ片手に探し回る羽目になる

927 ：
だいたいリンクでエラーにならない？

928 ：
Firefoxに重大なセキュリティ欠陥
Rust安全神話崩壊

929 ：
馬鹿に説明って難しいよな

930 ：
動的リンク

931 ：
https://www.itmedia.co.jp/news/articles/1906/19/news060.html

2019年06月19日 07時19分 公開
Firefoxに危険度最高の脆弱性、既に攻撃を確認

Array.popの問題により、JavaScriptを操作する際に脆弱性が発生する可能性がある




これ本当にRustのせいじゃないの？

932 ：
https://developer.mozilla.org/ja/docs/Mozilla/Projects/SpiderMonkey
SpiderMonkey は 、C / C++ で書かれた JavaScript エンジンです。Firefoxを含む、Mozillaの複数の製品で使用されており、MPL2 ライセンスの下で利用できます。

933 ：
GPL or LGPLコードに依存せずにSVGをレンダリングできるライブラリってないかな？
resvgが使えるかと思ったら
>librsvg is heavily tied to GNOME, which makes it painful to distribute outside the Linux ecosystem
とか書いてあるくせにgdkやglibを要求してくるようだ

934 ：
>>931
リポジトリ上で見る限り、今回のバグで修正されたのはC++のコードみたいだけど。

935 ：
>>933
https://mevius.2ch.sc/test/read.cgi/tech/1443092077/

936 ：
おい！なんだかバズってるfacebookのlibraのmoveはrustで書かれてるらしいぞ！！

937 ：
すまん別にバズってはなかった

938 ：
Rustが脆弱性の原因になると宣伝がパーになるから
あっちこっちでC++のせいにする小細工が行われております

939 ：
え？MozillaがRustの宣伝の為にFirefoxに脆弱性を！？

940 ：
ものごとの原因は人間の主観

941 ：
https://hg.mozilla.org/releases/mozilla-release/rev/99a829d2a2a7859b10508b6f05e99780c5e2dc68
http://imgur.com/2cTynR3.jpg
確かにC++のせいではないな…どちらかといえばRustか…

942 ：
さっぱりわからん
範囲チェックがどうとかって書いてあるけど
バッファオーバーフロー起こしてたってこと？

まんまＣ＋＋のせいじゃないの？

943 ：
バグフィックスってかいてあるけどこれが脆弱性修正？
なんがんあんだかわからん

944 ：
>>939
Rustなら安全に書けるとか言っておいてしっかり脆弱性作り込んだから
これはRustではなくC++のせいだからと火消しに回ってるの
日本語わかる？

945 ：
>>944
だよな。今回は完全に"Rust"が脆弱性作ったわ…

>>942,943
小細工をやめろ

946 ：
客観的でない陰謀論者が必死ですね

947 ：
これはJavaScriptが悪いな

948 ：
もう病気だな

949 ：
ElementAccessHasExtraIndexedProperty

凄まじく怪しげな物に変更されとるな。

950 ：
c++ぽくないコードだな

951 ：
確か何か変なコーティング規約で作ってなかったっけ

952 ：
Chromiumのソースもそんなん(長い関数クラス名とか)だけど

953 ：
どういう経緯で何が起こって開発元は原因は何だとしてるのか
ちゃんと説明しろ

954 ：
>>953
「セキュリティに関わるのでお答えできません。知りたきゃソース見ろ」
だそうです

955 ：
危険、危険と騒ぐ無知は有害。速やかに排除すべき

956 ：
C++はRustだった
今すぐモジラのステマ言語C++を使うのをやめろ

957 ：
別にfirefoxなくても困らんよ？

958 ：
それでもFireFoxがいい
軽さとセキュリティの誠実さ
ブックマーク回りはころころ変わってひどいけど

959 ：
GoogleやMicrosoftのWebブラウザは十数枚開いただけでメモリ消費がやばいことになる
Mozillaならそんなことない

960 ：
実践Rustのソートが全くわからん

961 ：
何ページ？おっちゃんが教えたる

962 ：
実践Rustって、電子書籍版を8インチタブレット(iPad mini)でちゃんと読める大きさ？
前に出たRust本は余白カット表示してギリギリって感じだった

963 ：
ソーティングネットワークのあたり

964 ：
>>959
逆だろ
火狐はタブ10個も開けばカクツキ起きるしそれからほどなくしてフリーズ
Chromeはもちろんクソクソ言われてるEdgeすらも
動作の安定面では火狐なんぞには負けん
ちなWin10

965 ：
>>960
本のステップで分ける説明より、2→4→8→... と増えていく図を見たほうが分かりやすいと思った

ttps://www.cs.rutgers.edu/~venugopa/parallel_summer2012/bitonic_overview.html

966 ：
>>964
FireFoxで１０タブ開いてみたけどなんも変わらんよ？

967 ：
>>966
20~30くらい同時に開くとビジーになるからビジーとフリーズの区別がついてないんだと思う。

968 ：
IEやChromeで100Tabとか開いたらメモリを食いつぶしてまとも動かないよ

969 ：
ffモナ

970 ：
その分今でもメモリ周りでバギーってのは笑わせますね。

971 ：
Firefoxなら100タブくらい大丈夫だよ。IE、Chromiumでそんな事したら他の作業が出来なくなってしまうけど
実際に比べた上でFirefoxを使っている。開発やっていると開くページがどんどん増える

972 ：
ffが大丈夫だと思うのは気のせい

973 ：
Rust→IR→Cが実用出来るようになるのはいつだ
LLVMが対応していないアーキテクチャでRustを使いたいねん
それともトランスパイラを作った方が早いかなぁ

974 ：
>>973
V言語使えよ

975 ：
IR to Cは昔できたのにな

976 ：
524 デフォルトの名無しさん sage 2019/07/02(火) 14:38:03.95 ID:ep8keXko
言語機能の複雑さという代償はあったが
GC無しでリージョン推論を実現したのがRust

記述性のためGCを入れつつも遅延を最小にすべく
GCの性能向上に努めたのがGO

一方vlangの公式によると
https://vlang.io/
> V manages memory at compilation time (like Rust)
https://vlang.io/compare
> - No GC
> That's why the language is so simple

・Rustのようにコンパイル時にメモリ管理される
・Goのように書けるがGC不要
・それでいてRustのような複雑さは無い
・という予定(まだ未実装)

本当にこの通り実現するなら
GoとRustの設計者達にマウント取れるレベル
526 デフォルトの名無しさん sage 2019/07/02(火) 14:59:25.78 ID:ep8keXko
ちなみに自動メモリ管理が未実装なので、以下の記事によると
hello worldやvlangコンパイラ自体もメモリリークしているとのこと
https://christine.website/blog/v-vaporware-2019-06-23
> The compiler itself also leaks memory
531 デフォルトの名無しさん 2019/07/02(火) 18:22:15.31 ID:NqAwj9wC
>>526
ｗｗｗ
532 デフォルトの名無しさん sage 2019/07/02(火) 18:59:24.21 ID:8dHuftNb
>>526
あっ・・・（察し）

977 ：
>>973
rust2cトランスレータはとっくの昔にあるしとっくの昔にどれも開発止まってる
rust->llvm->c->任意のコンパイラで出来るじゃん。

978 ：
>>974
生ポインタ使えるの？新しすぎるせいからしい情報が見つからんかった

>>977
今出てくるCバックエンドの話って関数レベルで使えれば御の字みたいなのばっかりに見える
プロジェクトレベルで実用に耐えるワークフローがあるなら詳細を知りたい

979 ：
>>608
横田さん潜伏中に生魚あたってハイタのかな？排他だけに。
なかなかRockだね！Lockだけに。

980 ：
>>978
>プロジェクトレベルで実用に耐えるワークフローがあるなら詳細を知りたい
rustでは見たこと無いね。操作的意味論に基づいて命令列とグルーコードに変換するものばかり。
というかそれ以外は難しいと思う。

981 ：
>>980
やっぱりそうか、残念。LLVMのバックエンドは作れる気がしないしトランスパイラの方が望みがあるけど
それでもELFのパーサとジェネレータ、変換元機械語のデコーダは最低必要だな
こういうのって処理系やエミュレータ等でしばしば使われるけど、単体のライブラリとなるとx86とかの
有名なアーキテクチャですらなかなかないんだよな

982 ：
Cと比べたらノウハウ少ないかもしれんけど、LLVMバックエンド作るのってそんなに面倒なの？
LLVM->Cって抽象度上げる方向だし参考になるものがもっと少ない気がする。ecmascriptenくらいじゃない？

983 ：
>>982
Rust to Cは自分の手に負えそうにないので他力本願です
ググって出てくる情報を見る限り最適化コンパイラを自作できるくらいの理解がないとLLVMの理解とバックエンドの開発は難しそうに感じます
各言語やアセンブラを使える程度の理解では歯が立ちそうにないです

なので機械語 to 機械語(もしくはアセンブラ to アセンブラ)の方がまだ望みがあるかなと

984 ：
バイナリ変換ってかなり壮大な研究テーマでは…。
どうしてもLLVMに触れたくないならLLVM-IR to アセンブリを自作するほうがまだましかな。

結局素直に勉強してLLVMバックエンド作るのが一番早いと思うけど。

985 ：
んなことするならc使った方がマシ

986 ：
>>984
LLVM IRってレジスタ数が青天井ですしstd付きとはいえHello worldですら十数本使っているようです
何処まで増えるのか判りませんがレジスタを数百本使うIRとか吐かれたら何とかなる気がしません

勉強すると言ってもどこから手を付ければいいのか判らない状態ですし最近は相対的にローレベルな
情報自体が減少しています。運良く自分が理解できる資料や教材に巡り会えない限り難しそうです

987 ：
オレオレ → LLVM はレジスタ何本あってもOK
LLVM → CPUネイティブ は良きに計らえ

オレらの仕事は前者
気にすんな

988 ：
そこまで部分の最適化って自分でやらにゃならんし
計算と制約を記述するのに適したその手前までの中間言語ってないじゃろか
Ｌｉｓｐとかか

989 ：
バイナリ変換ってダブルバッファリング的な事しないと整合性とれねー気がした。

990 ：
いみふめい

991 ：
>>988
レジスタが1〜2本足りないくらいなら使用頻度の低いのからメモリに逃がす方法で何とかなりそうだけど
全然足りない場合全く別の方法が必要そうですが思いつかないです。自分にとっては高度な問題です

Rustと言うかLLVMが吐けてターゲットとの相性が良さそうなアーキテクチャを選ぶ必要があるけどこれも難問かな
IA32/AMD64はメジャーだけど建て増ししすぎでアドレッシングモードとかスーパーカオスだし無駄に命令も多い
ARM7あたりが無難だろうか。分岐処理が特徴的なようだけどRISCの割にレジスタが少なめなのも好条件か
純RISC系は命令セットが単純だけどレジスタが多くてLLVM IRと同じ問題が出てきそう

992 ：
キューイングしてガンガン処理して節目でプログラムカウンタを1増やす。とか理想を語る俺。

993 ：
2つのvectorの同じインデックスの要素を比較したいときってどうかくのがスマートなんでしょう

994 ：
>>993
zip

995 ：
MISPならツールチェイン揃ってるからPS系ハードで動かないことはない

996 ：
コンパイラチェッカーについて簡潔にまとまっている資料とかないんだろうか
数ヶ月ぶりに触ったらすっかり記憶の彼方だわ

997 ：
次スレ立てた
Rust Part7
http://mevius.2ch.sc/test/read.cgi/tech/1563114707/

998 ：
RustってVisual Studio Codeとかでビルドしたりインテリセンスが利いたりするようにならんの

999 ：
質問いいですか？∩(　´Α｀)

1000 ：
いいよ

1001 ：
2ch.scからのレス数が1000に到達しました。

フリーソフトなどに使われる言語は？
【iPhoneも】Titanium Mobileスレッド【Androidも】
Excel VBA 質問スレ Part62
sizeof(char)が必ず1でも、省略すべきではない
ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
LLにおける関数型プログラミング
Jenkins
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
自然言語処理スレッド　その５
C++相談室 part148
--------------------
+ JavaScript の質問用スレッド vol.123 +
世論調査のソースやデータを集めるスレ・13
【FFBE】FINAL FANTASY BRAVE EXVIUS Lv2213【イカサマコイン】
会計検査院で働いてるけど質問ある？　検査2日目
【スペオペ】スペースオペラTRPG総合
テキスト入力専用ツール 「ポメラ」 Vol.43
【物申す系YouTuber】軟骨【阿江春果】
お前らが思っていることをストレートに書いていけ
壇蜜が好きなオヤジ
【ぐ】GUを自由に語ろう　ジーユー81【g.u.】
【いつも口だけ】黒澤のクソつまらない配信アンチ専用6【嘘の塊】
ニコンがフォトコンからフィルム撮影作品を排除
神バンド専用スレ 18
スティーヴン・セガール STEVEN SEAGAL 28
ＥＭＰ攻撃スレッド
1人1字ずつ書いて まいやんじゃあね。 と1000までメッセージを贈ろう
なぜヨガはカルトに目を付けられるのか？
窪塚
熱帯亜熱帯を野生生物保全その他の視点でレスるスレ
[PS3]MW3 - チート/ハック(CoD:MW3)
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼