TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
くだすれDelphi(超初心者用)その55
【GUI】wxWidgets(旧wxWindows) その5【サイザー】
JavaScriptは消滅すべきだったよな
Google App Engine for java
ふらっと C#,C♯,C＃（初心者用） Part141
自然言語処理スレッド　その４
Git 16
くだすれDelphi(超初心者用)その55
Windows 10 UWPアプリ開発 Part 2
Rust Part5

Rust Part5


1 ：2018/02/11 ～ 最終レス ：
Mozilla発のRust言語のスレ

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

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

前スレ
https://mevius.2ch.sc/test/read.cgi/tech/1507970294/

2 ：
>>1補足

関連スレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.sc/test/read.cgi/tech/1514107621/

スレタイと本文を簡素にして、リンクを追加
ワッチョイの有無は話し合って決めてくれ

3 ：
ﾜｯﾁｮｲが怖いアンチ専用スレ

4 ：
乱造されたくそ言語のひとつ

5 ：
真正キチガイとそのとりまき専用スレです。

6 ：
本スレ

プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
http://mevius.2ch.sc/test/read.cgi/tech/1514107621/

7 ：
Announcing Rust 1.24
https://blog.rust-lang.org/2018/02/15/Rust-1.24.html

8 ：
http://wolfbash.hateblo.jp/entry/2017/07/30/193412
やはりRustはクソの言語未満
良識ある人はきちんとわかっている

9 ：
>>8
このブログが良識のある人の記事に見えるってのはある意味すごいと思う。
マジで言ってんの？ネタじゃなかったから単なるバカだよ？
Nimやったことないんだけど、このブログ書いた奴のせいで
俺の中でのNimへの風評被害が超激しいんだけど。

10 ：
>>8
ネタにマジレスしてるはてな民多くてワラタ
2chもはてブも変わらねえな
インターネットはこうでなきゃな

11 ：
>>9
正しくRustとNimを比較してRustにいいとこなどないと論理的に談断じてる
そこまで言うなら反論記事よろ

>>10
マジレスも何も事実じゃん

12 ：
金子勝とかNimキチガイとかrustアンチするにしても筋悪すぎるしアンチを装った信者の犯行では

13 ：
Nimおじさんの布教の熱意は見習いたい
Rustオタは身内で盛り上がってるだけだからな

14 ：
ここまで理論的な反論なし
まあできないんだろうね。言語未満Rust

15 ：
Nimとの対比でRustは言語未満のゴミだと暴かれている上に
それを布教してるやつらは金子先生の鋭い指摘で詐欺集団だと暴かれているのに
信者は人格攻撃して矛先を反らすだけ

よっぽど反論できなくて悔しいんだろうね

16 ：
悔しいんじゃなくてバカらしい。
あと、書いたところでこっちにメリットがない。
具体的なメリットを提示してくれるなら書くかも。
反論記事なら雑だけど一応あった。
書いた後であまりのバカらしさに自ら記事を消したらしい。
アーカイブは残ってるから、それでも読んでろ。
http://ubnt-intrepid.hatenablog.com/entry/2017/10/03/135742

17 ：
Rustはプログラミング言語未満というのは >>8 の意見だと思うけどプログラミング言語の定義が曖昧すぎて反論のしようがないしそれで勝利宣言されてもね

18 ：
>>16
書いたらモジラからお給金出るでしょ

>>17
意味のあるプログラム書こうとしたら
とたんに借用とかでコンパイル通らなくなってまともにプログラミング出来ないものがプログラミング言語と言えるのか？
まあMalbolgeやBrainfuckがプログラミング言語と呼べるキ◎ガイならRustもプログラミング言語かもね

19 ：
あとその人か反論記事消したのも
本当はRustが使い物にならないことを察してしまったけど
それを言うと信者に突撃されるからぼかして消しただけでしょ
表向きの理由で全消しするのは不自然だから

20 ：
ほんそれ

21 ：
あぁ、Rustのネガキャンするとお給料がでるのか……

22 ：
提灯記事書いてモジラからお金もらうにはどうしたらよいのですか？

23 ：
「俺がコンパイル通せるコード書けないからRustは糞」って主張で首尾一貫してるところはすごい

24 ：
それとも世のRustで書かれてるアプリケーションは実はすべて別の言語で書かれているという主張だろうか

25 ：
はたまたRustで書かれてるものはどんなものであれまともなものとは認めないかな

26 ：
2番目が正解だな

27 ：
オープンソースでRustで書かれてるやつも
なんとかコンパイルだけ通したような
保守性も何もない個人が脳トレで書いたようなものばかり
まともな製品として書かれたコードはGithubにも見つからなかったぞ

ソースコード公開してるものがそうなんだから
企業がRust使ってると称するなにかは実際にはRustなんて使っておらず
適当な別の言語で書いてRust使ってると言えばモジラから金が出る
そういう仕組みと考えるのが自然な訳だ

28 ：
で、このアーカイブ記事に対する論理的な反論はできないと。
あと、GitHubのまともなコードが見つからなかったって点も
どの辺がまともじゃないのかについてはコードでは示せないと。
それで自分の言葉に説得力があると思ってるのが不思議でならないんだが。
あと、俺にも「モジラからお金もらう方法」を教えて。
ホントにもらえるんだったら絶対に反論記事書いてあげるから。

29 ：
ぐぇ crate uuid のインターフェースが換わりよった
ParseError が std::error::Error を impl しなくなったのは何故だ……

30 ：
>>28
なんで取り下げられた記事に反論しないといけないの？
取り下げたってことは「この記事は間違いだった」というメッセージでしょ

モジラから金貰う方法とか俺に聞くなよ
モジラのページにある自称Rust使ってる企業に聞いてくれよ

31 ：
>>29
な。Rustなんて使うからそうなる
一貫したインターフェースを提供することすらできん言語だ

32 ：
取り下げた理由も書いてあるのに読まずに決めてかかってるのほんとブレねぇな

33 ：
まともな製品という言い方もそうだけどまともかどうかの判断基準は「俺が気に入るかどうか」以上のものがあるように読みとれなかったので議論にならない
論理的な会話ができてないのはどちらなんだか

34 ：
>>31
レスしてもらったのはありがたいが
俺はお前さんから見ればRust信者だわ　すまん

元よりどんな言語使ってもインターフェース変更はある
今回は、追従する作業に五分も掛からんかった
後はテスト流して終わり

インターフェースの変更が出来ないのを理由に
開発が鈍化されるよりマシだと思うよ

35 ：
クソな例挙げようと思ったが挙げるまでもなく>>29が素晴らしい例を出してくれたな

Nimの人のブログにもあったが、ロジックと関係ないスコープ切りが必要なせいでコードがスパゲッティになるとか、
ハッシュテーブルと所有権がコンフリクトして動的計画法が書けないとか
所有権のせいでそもそも循環グラフ書けないとか
いくらでもクソな所出してやれるが？

36 ：
それ以上に、難解すぎてロジックと関係ないコード上の手入れが膨れ上がって
結果ロジックにバグが増えたりインターフェイスの非互換が発生したりするんだよ
だから致命的に壊れた言語って言ってる

37 ：
>>32
だから信者からの突撃回避だろってそれ

38 ：
反論ブログの人が今でもRust書いてるのも、アイコンがRustのマスコットキャラなのも信者の突撃回避なのですね
Nimのブログ記事にブコメしてるのもみんな信者かMozillaの工作員なんですね

39 ：
コンパイラが理解できない所有権の問題がある場合はunsafeというescape hatchがあってプログラマの責任でコードが書けるようになっている
これはすごく実用的な割り切りだと思うんだけど>>35はまた意見が違いそう

40 ：
コンパイラが賢くあるべきなのか、コードを書く側が賢くあるべきかとい二つの考え方があって
>>35は後者、Rustは前者の立場をとっていて単純に趣味に合わないだけなんだと思うが

41 ：
比較対象にされてるNimはまともなプログラミング言語とのことで、まともな言語とはまともな製品を作れる言語とのことらしいが
そうなるとNimはRust以上に普及しててまともな製品がリリースされていないと矛盾しないか

42 ：
>>41
個人で作ってる言語と
国際的詐欺会社がバックにいるのとじゃどうしても個人が負けるわ

43 ：
Mozillaが詐欺企業なんて聞いたことないけどどういう罪状があるのか詳しく教えて欲しい

44 ：
こんだけアンチが常駐する言語スレも珍しい
PHPより酷く感じる

45 ：
スレ人口少ないのもあるが常駐されたところで同じ主張繰り返すだけで特に実害がないからでは
別スレもあるし

46 ：
ほんとうにMozillaが金をばらまいてRustを普及させようとしているなら断る人もいるはずで
世界的にやっているにもかかわらずそのことに言及してるのがこのスレにいる一人だけという時点で信憑性も何もないというのがね

47 ：
言語について批判できるんだから変なMozilla批判は引っ込めたほうが説得力持たせられるのに
もったいない

48 ：
札束でぶん殴られて断れないような、そういう相手を選んでるだろうしな
あのMercurialもGitにボロ負けしてるから、資金で殴れば下るだろうって狙われたんだろう

49 ：
>>30
お前しか「モジラに金もらってる」なんて言ってる奴がいないんだからお前に聞くしかないだろ？
バカなの？脳味噌に草でも生えてんの？
あとGitHubの件はスルー？コード例はやっぱり出せないの？
動的計画法はRustじゃ書いたことないから分からんけども、書けないのはお前だけじゃないの？
「書けない部分を具体的にコード例で示して」毎回言ってるよね？
「同じことを何度も言わせるな」って注意されたことないの？今注意したからもう同じこと言わせないでね。
循環参照についてはRcとWeak使えば書ける。可変にしたければさらにRefCell使えばいい。
それも何度も言ってるよね？ボケてんの？草以外に花も咲いてそうだな。
RcやRefCellが気に入らんならお前とはスタイルが合わないってだけの話だ。去ね。

50 ：
あと最悪、動的計画法や循環参照がお前に書けなかったとしても、
書けてるやつのライブラリを使えばいいだけの話では？
自分で書くよりまずライブラリを探す。今の時代はこれが常識だろ？
車輪の再開発は勉強するときだけやってればいいんだよ。

51 ：
今まで触れずにおいてやったのにそこまで言われたから言うけど
「書けないもの」の「ソースコード用意しろ」ってひどい矛盾したこといってるの分かってます工作員さん？

52 ：
コンパイルが通らないソースコードなら書けるよね

53 ：
どうせ次はRustは触るのも汚らわしいから書かないとか言うんだろうな

54 ：
Rustでコンパイルエラーしてるソースコードを
コンパイルエラーした状態のままでいいから見せろって言ってるの。
あと、「C(他言語でも可)だとこう書けるのに。。。」っていうソースも載ってればベスト。
分かってもらえます？

55 ：
borrow checkerについて文句言ってるんだからせめて型検査くらいは通ったソースにしてくださいね

56 ：
http://play.integer32.com/?gist=a352230e08bc0a76fb5f116bd3c7abf4&version=stable

これで満足？

57 ：
http://play.integer32.com/?gist=97a7043af5e6ae63f81bc41b2eccc945&version=stable

58 ：
HashMapのエントリーへのポインタは新しいエントリー追加したらreallocなどが呼ばれて無効になるかもしれないので取り回すのがそもそも間違い

59 ：
ちゃんとソースコード読みこんでないから何がしたいのよく理解してないけど
取り合えずコンパイル通すだけならすぐ出来たよ。
http://play.integer32.com/?gist=9333d5344adb9cdf5ef8292a20ec6c24&version=stable

60 ：
NLL有効にしたら元のコードでも通った

http://play.integer32.com/?version=nightly&mode=debug

61 ：
俺はスコープ切る方が好きかな～
http://play.integer32.com/?gist=e73044b8a25fa1c2403ee1ccb74356f6&version=stable

62 ：
URL間違えた
http://play.integer32.com/?gist=d9f081dd40e2e0d06e224dc0e20ee41c&version=nightly

63 ：
瞬殺されてて草

64 ：
この流れ見ると、NLLはRustのハードルを思った以上に下げるのでは？と思わずにはいられない

65 ：
その程度のエラーで投げるやつは少数派なんじゃ。。。とおれは思うけど。
まぁ、それでハードルが下がるのならそっちのほう良いとは思う。
けど、その程度で前に進めなくなるならすぐに別の問題にもぶち当たってやっぱり投げちゃうと思うよ。
そういう奴らはRustはともかく、多分C, C++でも自分で書いたバグに潰されると思う。
結局GC付きの言語でしか書けないんじゃない？
念のため言っておくけど、GC付きの言語を批判する意図はないよ。
おれTypeScript好きだし、Goも嫌いじゃない。

66 ：
確かにここが解決しても型合わせとかで匙投げそうだな……
型の方はScalaとかSwiftとか別の言語で似たようなのがあるから参考にできる文献多そうだけど

67 ：
ジェネリックとトレイト境界の辺りとか最初は結構苦労した記憶がある。
特にfuturesクレートを初めて読んだときは?!??!?ってなった。
Rustは良い言語だけれど「難解」というところだけは否定できない。
そういえば、結局「モジラからお金もらう」方法教えてくれなかったなぁ。
お金欲しいのに

68 ：
ちゃんとしたもの作れるわけないだろという主張してたのが昔は複数いたと思うが
Quantumが出たあたりで流石に取り下げたようだが
モジラは詐欺会社と言い張る一人だけが猛烈に頑張ってる

69 ：
>>68
モーレツに墓穴掘ってるけどね

70 ：
安全性を最大限に気にしたい心配性な人向けの言語だよRust
そういう人たちはC/C++のコーディングで余計なことまで心配しすぎてストレスかかってるんだよ
かわいそうな人たちなんだよ

71 ：
心配しないと鼻から悪魔が出るのがC/C++なので心配しすぎということはない

72 ：
例のアンチだが動的計画法がどうだ循環参照がどうだって騒いでたから
てっきりhtml5everくらい複雑なコード組もうとして悩んでたのかと思ってたけど
まさかのフィボナッチ数列でつまづいていたとは予想外だったわ

そういえば今年のstackoverflowのアンケート結果っていつ出るんだろう？
そもそも毎年いつ頃出てるのか知らないんだよね
これでRustが愛され言語ランキング1位から順位落としてたら
また「ついにクソ言語未満のボロが出てきたな」とか騒ぎだすんだぜきっと

73 ：
前スレで、別のランキングでRustの順位が10位圏内に入ってなかったことについて
「工作ブーストが切れたな」とか言ってたからそういう方向になるんじゃね

74 ：
Rustが、コードのスタイルガイド「Rust Style Guide」と自動整形ツールを導入する理由。
コードをめぐる議論を省き、メンタルの負担を減らし、プログラマを参加しやすくする
http://www.publickey1.jp/blog/18/rustrust_style_guide.html

75 ：
unsafe使えば書けるだろ
C++みたいに全部unsafeな言語よりは安全

76 ：
C++ならゲーム
C#ならWindowsフォームアプリケーション
PHPならWebアプリケーション
Pythonなら機械学習

Rustは？

77 ：
ここはアンチが立てたキチガイ隔離スレです。
キチガイ以外書き込まないでね

78 ：
本スレが過疎ってレベルじゃないし実質こっちが本スレだろ
隔離（）スレに勢いで負ける言語があるらしい

79 ：
まあそうなんだけどね

80 ：
ほんとID:yl4ANYczは戦犯
コンパイルできない厨が最後のコンテンツだったのに…

81 ：
いわゆるnewtypeパターンをLLVM IRで見てみると
ごく単純なコードで使う分には中身の要素に最適化されてるけど、
それ使って配列を作っただけで最適化されなくなる
こんくらいでゼロコスト抽象化とか言ってるの？

typeでは新しい型作れないし、
結局新しい効率的な型を作る方法さえないんだな

82 ：
私にも敵が視える

83 ：
Rustで書くと実行時のメモリ使用量が増える感じは確かにある

84 ：
>>81
トレイトの特殊化でも無理？

85 ：
バグかもしれないからissue立てたら

86 ：
>>81
ゼロコスト抽象化はトレイトやジェネリクスを言っててnewtypeパターンは関係ないと思うゾ


Cに比べたらC++もRustもGoもランタイムの分だけメモリ使用量は増えるよね
C++にはランタイム存在しないとか大笑いなギャグを素で言う輩は知らん

87 ：
その理屈で言うとlibcもランタイムになりそう

88 ：
「Rust 1.24」リリース、コード整形ツール「rustfmt」をプレビュー導入 | OSDN Magazine
https://mag.osdn.jp/18/02/17/163000
> ビルドの速度は改善するが、出力されたバイナリの実行速度は少し遅くなるとしている。

89 ：
むしろ今まで並列コンパイルをしていなかったのかという驚きがね...
型推論とかボローチェッカーとか大変だろうしと思ってたが、並列コンパイルで早くなるのは助かるよね

90 ：
コンパイルを速くするためにプログラムの速度を犠牲にする
自称低級言語があるらしい

91 ：
言語じゃなくコンパイラの話だぞ
速度を求めたリリースビルドは並列なしに切り替えられる低級調製可能なコンパイラすごいよね(棒読み

92 ：
言語仕様には興味あるけど実装は興味ありませんって奇特な方には人気出そうな言語だね。

93 ：
低レイヤ書く人は仕様より吐かれるバイトコードの方にしか興味ないから
完全にターゲティングに失敗してるよなこの言語

94 ：
むしろコンパイルを通すことが難しくても効率的で安全なマシンコードを出力して欲しい奇特な人向けだけどな
性能無視して生産効率だけを求めるならボローチェッカーとかunsafeとかトレイトとか面倒な言語仕様はマジ辛い

ただ緩く書きたいだけならSwiftとかGoの方が絶対良いよな
ランタイムが馬鹿でかかろうが、goroutineが冗長コストだろうが、言語仕様が楽なそれらは生産効率が断然良い

95 ：
安全はともかく、Rustが効率的なマシンコードを出力するというのは同意しかねる

96 ：
やはりD言語が最強か

97 ：
ソースとマシンコードが一対一になる言語は安心感あるな

98 ：
やはりアセンブラか

99 ：
【ＵＦＯ】　　山本太郎も横浜で遭遇　　≪＂◇″型の発光体≫　　世界にテレパシー放送　　【大宣言】
http://rosie.2ch.sc/test/read.cgi/liveplus/1519704223/l50

100 ：
【お知らせ】Packt出版より Network Programming with Rust が発売されました。

101 ：
https://play.rust-lang.org/?gist=0bed0aa16c0679665fee05cc6bfda41f&version=nightly
fn nanka() -> Option<u32>{
println!("nanka called");
None
}
fn nanka2() -> Option<u32>{
println!("nanka2 called");
None
}
fn nanka3() -> Option<u32>{
println!("nanka3 called");
None
}

fn main() {
match (nanka(), nanka2(), nanka3()){
(None, _, _) => println!("nanka ha None"),
(Some(_), Some(_), Some(_)) => println!("some"),
(_, _, _) => println!("else")
}
}

nanka2, nanka3が呼ばれなくて困る！って副作用があるパターンぐらいじゃないですか？
nanka1がNoneと判定した時点ですぐprintしてくれないものでしょうか

102 ：
println!("nanka2 called"); とか副作用あるよね

103 ：
まさに副作用あって呼ばれなきゃ困るパターン書いてて草

104 ：
遅延評価の言語ではないから言語仕様的に全部評価することが保証されてるからなぁ
副作用なくて同じcrate内に処理があるなら最適化で消えるのでは

105 ：
横着してたから気づかなかった…

>>104
https://play.rust-lang.org/?gist=548477e609761c03d062880ceebec28a&version=stable
MIR見る限りあるっぽいです(これ副作用ないですよね？)

106 ：
良く分からないけどReleaseにしてASM見ると消えてるみたい
MIRに対する最適化は現時点ではそれほどやられてなさそう

107 ：
>>106
Debugなのを忘れた状態で見てcall nanka2があったので駄目かと思っていましたが
Releaseだと消えるようですね、すいません

108 ：
言語仕様で消えるってどっか書いてある？探したけど見つからんかった

109 ：
rust推進派のtanakhがrustのダメ出しを始めた

https://twitter.com/tanakh

110 ：
会社大変だから許してあげよう

111 ：
>>108
最適化の話だから言語仕様では決められてないと思う

112 ：
あのtanakhですら擁護できなくなってきたRustとかいう何か
やっぱクソ言語じゃん

113 ：
逆にたなこふ氏が好きな言語って何だよ
Haskellくらいだろ

114 ：
ほら
https://twitter.com/tanakh/status/907645555467104256

115 ：
いくつか言語……？ってなるのが混じってるな

116 ：
>>114
Rust評価高いくてGoは糞って評価だな。

117 ：
絶対一緒に仕事したくないようなコード書きそうな人柄なのがよくわかるのはいいことだね。

118 ：
スタック使うかヒープ使うか考えなきゃいけないしマジで低級言語だなRust

119 ：
低級プログラミング言語というときの低級は必ずしも蔑む意味とはならない

120 ：
>>118は別に蔑んでないと思うが…

121 ：
118が低級

122 ：
どう読んでも>>118は事実を言っただけでrustを誉めても貶してもいないと思うが…
「CはPythonよりも低級言語」これC言語を蔑んでる意味で取るアホなんているの？

123 ：
初心者は大体そのように取るよ

124 ：
はいはいわかったわかった

125 ：
枯れてる言われて古いんだなと思ってそう

126 ：
高級言語のcobol最強ですかね

127 ：
蔑んでいるように見えるのはあなた自身が心の奥底でRustを蔑んでいるのです

128 ：
はいはいわかったわかった

129 ：
1つのstructにいっぱい詰め込むと初期化が面倒なんですが

130 ：
new()用意しとけ

131 ：
derive(Default)使えば

132 ：
よくインターネット上の広告で半年でエンジニアに！みたいなのあるけど、インターネット不得手、プログラム未経験者が真剣に半年頑張れば本当にそんなこと可能なんですか？
可能ならその理由はなんでしょう？人材が足りていないというのは存じ上げていますが

133 ：
ごめんなさい誤爆しました

134 ：
>>132
言われたことやるだけなら可能じゃね？

135 ：
>>8
今更だけどこれ書いた奴もブコメした奴も誰一人rustまともに使ったこと無さそうで草

136 ：
>>135
少なくとも書いた奴はまともに使ってないだろうな
matchの仕様が理解できないからって仕様バグと決めつけてるアホだし…

137 ：
俺の技量不足なんだろうけどmutmut地獄は確かにわかる

138 ：
>>137
mutが面倒ってのは分からなくはないんだが、かと言ってどうするの？
不変のほうをconstにすると次はconst地獄になるだけだよ

139 ：
C++erだったのでconst地獄はむしろ慣れてるので歓迎

140 ：
一方、記述の美しさを重視する Nim では let と var に分けた

141 ：
Nimは引数を可変にしようとすると下記のようになる。
proc test(x: var string): string =
x = x & " world"
return x

var x = "hello"
let y = test(x)
echo y

関数宣言で引数にvarと書かなきゃ可変にできないんじゃRustとそれほど手間は変わらない
それに、宣言はvarと書かせるクセに呼び出し側がtest(var x)じゃなくてtest(x)となるのが解せない
これじゃ呼び出し側を見ただけじゃxが不変か可変か判断できない
C++と同じ類の過ちを犯してる
簡潔ではあるかもしれないが全然美しくない（美しいの定義によるが…）

https://play.nim-lang.org/?gist=9e8b6b6059cf8640f6c71fd2075b07c8

142 ：
あとRustの場合はそもそもmutは出来るだけ使うなという方針だから
mutの記述が面倒なのはワザとやってるという点もあるし…

143 ：
なるほど

144 ：
> これじゃ呼び出し側を見ただけじゃxが不変か可変か判断できない
珍しいご意見ですよね。

145 ：
>>144
よくよく考えるとRustも呼び出し側にmut付けること自体は必須ではないんだよな
所有権を借用するために大抵は&mutを書かされるってだけで…
渡す変数の型がもともと&mut Tだった場合は書かなくてもいい…
Rustの場合は呼び出し側で&mut書く羽目になる経験が多かったので
俺が勝手に「可変にしたければmutを絶対に書かないといけない」という勘違いをしていただけか…
でも、書かされた方が読むときには分かりやすいので個人的にはこっちの方が好き

俺自身がNimはどうしても好きになれなくて不満点を挙げたつもりが自ら墓穴を掘ってしまった感じだな
一般的にはNimの方がよっぽど簡潔で美しいのかもしれない…
ただ単に俺の感性の方が狂ってるだけっぽいな…

146 ：
そんな珍しくもない気もするが

147 ：
俺もそんな珍しくもないと思う

148 ：
「変数」が値に名前を付けたイメージに人とメモリ領域に名前を付けたイメージの人と

149 ：
データがメモリのスタック領域ヒープ領域あるいは別の領域などどこに記憶されるのかという低レベルなことを考慮しながらプログラミングしなきゃならない

変数とは何かと言えば
スタック領域の特定のメモリ番地に名前をつける行為でしかなく

所有権の委譲って何かと思えばそのメモリ番地の名前を変える行為でしかない

クソ

150 ：
分かりやすい説明だね

151 ：
GBAのプログラムを書いてみたいな。どうせならRustでやってみるか
ARMポートあったよね。Thumbコードも吐けるのかな

とか思ってググっていたら先人がいた。考えることはみんな一緒かｗ

152 ：
Unityが北欧のニートから生まれたって話を聞いて
Rustでゲームエンジン作ればワンチャンあるんじゃないかと思い始めてきた。

153 ：
気のせい。

154 ：
あるかもね

155 ：
unsafe使い始めたらCのがやっぱ楽じゃね？ってことにすぐなる。

156 ：
そしてメモリ周りのバグで悩まされた時にやっぱRustで書いときゃ良かったってなる

157 ：
バグなんてメモリに限ったことじゃないのにね

158 ：
要因の種類が減るのは良いことだ

159 ：
rust未経験者なんだけど、この言語ってweb開発には向いてないの？
goより高度なこと出来るならweb開発も全然苦じゃないように思うんだけど
何かしらweb開発に向いてない要素あんるんかな？

160 ：
DOMいじれんの？

161 ：
ごめん。聞き方がふんわりしてた。
webのバックグラウンドで動いてるrestAPIサーバに向いてない要因は何かあるのかな？
SPAとかマイクロサービスとかの構成でjavaとかgoとかの代わりに成り得るのかなって。

162 ：
一応WebAssemblyで吐けばRustのコードとJavaScriptのコードを混在出来るけど
軽く触っただけなんでデバッグなどの開発環境の事は未知数

163 ：
>>160
無理

164 ：
サーバ側でしょ？言語としては代わりになるだろうけどwebに向いてる部分てのが何を指してるかによるんじゃない

165 ：
hello world出たからもう初心者と言っても過言ではない。。

>>164
個人的には静的言語ならどれも大差ないと思ってるんだけど、
その方面では全然注目されてないように見えたから何か原因があるのかなって。

166 ：
>>161
以前Goでサーバーサイド書いたことあって、バイナリ一つデプロイするお手軽さがとにかく良かった

といってもほんとに小機能で、WAFにEcho使って静的ファイル(CSS・画像)とか
レスポンスにDBから引っ張ったJSON返すRESTfulの出来損ないみたいのだけど

開発はWindows、デプロイ先がCentOSだったんだけど、
WindowsでCentOS用のバイナリ吐けるし、プロセスの再起動監視も今はDocker-composeがやってくれてるし(restart: always オプション)

Windowsで開発してPUSH、CIツールがCentOS用にバイナリ吐いて、CentOSではバイナリ受け取ったら
$ docker-compose down && docker-compose up -d --build
叩くだけでデプロイ完了っていう超絶お手軽、もちろんデプロイはAnsibleやItamaeで自動化しても良い

167 ：
hello worldが10個出た。

>>166
goのシングルバイナリ良さそうだよね。
全然分かってないんだけど、rustでもちょびっと頑張れば
クロスコンパイルできるって認識なんだけど間違ってるのかな？

168 ：
Rust経験浅いんで良く分かってない、一応nickelってWAFあるしrustupでコンパイル出来るから土台はあるけど
RustってわりとカジュアルにC製のライブラリをdllとして利用してるからそこが未知数
まあそれらのライブラリを使わなきゃいいんだろうけど

169 ：
rustupでクロスコンパイル

170 ：
FizzBuzz動いたー レベルアップ感ないけど

>>168
そうか。シングルバイナリじゃないとクロスコンパイル先の環境で動かすのは
なかなか大変そうやね。やっぱその分野はgoが強いってことなんね。

171 ：
>>165
そういう観点なら学習コストが高いのがじゃくてんだと思う

172 ：
>>165
個人的にはGCありなしの差が大きい気はする。
特にweb系はGCがあって当たり前だから
急にlifetimeとか言われても…ってなりそうな。
C/C++だと結局脳内でlifetime管理してるから
そこの学習コストは相対的には低い。

173 ：
>>172
おれもGC有り無しはでかい要因だと思う
今までJS, Ruby, PHP, Java辺りしか使うことのなかったWeb屋にとっては
「メモリ管理？なにそれ？おいしいの？」状態だろうし…

174 ：
>>171
>>172
なるほど。確かにWEB系だと短い納期＋人海戦術で乗り切ることも多いから
そういうのには辛そうだね。でも言語仕様的にWEB(の裏のサービス)が不得意という
訳では無さそうだから、細く長くやるようなサービスなら導入もアリっちゃアリという認識でいいのかな。

>>173
そだね。なんにもわからんわw っていうかWEBやっててGCであんまり困ったことないかも知れん。
困ったことがないことに起因して難易度が上がった言語を「使いたいです」って提案するにはちょっと強引さが必要そうやね。



今、初心者用の練習問題やってるんだけどメモリの管理なんて全然出てこない。
みんなどうやってRUSTの勉強してるの？やっぱり何か動くもの作ってみるのが早いかな？

175 ：
簡単なApp serverならrocketが楽だった
早くstableで動くようになってほしい

176 ：
>>174
ん？君もしかしてWeb屋なの？
そして「GCなし」ってのがどういう状態かよく分かってない感じ？
C or C++のご経験は？

177 ：
GCは甘え。
プロなら自分で管理するべき。

178 ：
GC無い言語でもファイルディスクリプタの解放は自前でする必要あるしリークの根幹はどっちも変わらんと思うけどな
むしろGC無い言語の方が循環参照の時の解放が面倒、C++でもweak_ptr使う必要出てきたり

179 ：
c++はやっぱraiiが便利。
gcあったって結局outofmemoryerrorになるなからなぁ。
だったらrustのようにコンパイラが所有権やライフタイムをチェックしてくれるのはいいと思う。
けど学習障壁高過ぎとも思う。

180 ：
Nodeのメモリーリークはみんな苦戦してるみたいだけど。

181 ：
Nodeは全部グローバル変数にするのが悪いんや

182 ：
>>180, >>181
Nodeはよくメモリリークが問題とか言われてるけど原因はそこなの？
グローバル変数を平気で乱用するほど皆バカなの？
イベントハンドラの解除忘れとかじゃないの？

183 ：
エラーにならないことが多すぎる。
忖度しすぎ言語の称号を与えたい。

184 ：
Nodeの問題点を一言でいえば、Javascript。

185 ：
>>174
コストかけられるなら規模の大小関わらず大アリだよ

186 ：
>>175
ありがと。ちょっと試してみる。

>>176
ぽんこつWEB系IT土方だよ。javaとjavascriptくらいしかやってない。
javaでは走ってるGCがrustだと黒魔術によって必要ないっていう認識やで。

>>185
そうか。大アリか。ありがと。

187 ：
>>182
イベントハンドラ解除は他言語でも明示的に書く必要ある
だけどクラスのデストラクタ・ファイナライザに書いといて各スコープで変数の寿命をちゃんと管理するコーディングの基本を守ってるだけで問題ないと言える
ここはRAII使えるC++やRustが最強、なんせ何も書かなくてもスコープから外れたらそれぞれデストラクタ・Dropを呼んでくれるんだし
次点でC#のDisposeとusingなどの専用構文、Javaはtry..finallyあるから及第点

でもグローバル変数だとそんなの働かない、プログラマが仕様とにらめっこしながらリークに気を使わないといけない、めんどい

188 ：
>>186
Cさえやったことないんじゃメモリ管理について説明するのは難しいな
ざっくり説明すると

C言語ではmalloc, freeを使ってプログラマが自力でメモリ管理を行う
よって、きちんとメモリ管理ができていない場合は実行時にバグになる。

対して、GCありの言語は実行時にGCがバックグラウンドで動いて自動でメモリ管理を行ってくれる
メモリ管理は実行時に自動で行われるのでプログラマは基本的にメモリ管理を行う必要はない
ただし、GCの挙動をしっかり理解していないとメモリリークのバグになることもある

そして、Rustはメモリ管理をコンパイラがコンパイル時に行う
つまり、メモリ管理ができていない場合はコンパイルエラーになる
コンパイラが正しくメモリ管理を行うためにRustには
所有権・借用・ライフタイムというルールが存在する
このルールを守らないとコンパイルが通らないため絶対に理解する必要があるが
このルールをきちんと理解してコードを書くのがなかなかに難しい
それと、このルールを完璧に遵守しようとすると循環参照さえ出来なくなる
なので循環参照等の少し複雑なことをやろうとした場合は
標準ライブラリとして用意されているRc, Weak, RefCell等の使い方も知る必要がある
因みにRc, Weak, RefCellの中身ではunsafeコードが多用されていている
unsafeコードの中ではルールを無視できる代わりにコンパイラがチェックを行わない
つまり、unsafeの中だけはCと同じように自力でメモリ管理する必要がある
だからこの言語は他言語と比べて学習コストが圧倒的に高い

189 ：
「ざっくり」と言っておきながら気付けばそれなりの長文になってるな…

190 ：
なんで聞かれてもいないことを長文で答えるのか
プログラマにはありがちだけど

191 ：
>なので循環参照等の少し複雑なことをやろうとした場合は
>標準ライブラリとして用意されているRc, Weak, RefCell等の使い方も知る必要がある
>因みにRc, Weak, RefCellの中身ではunsafeコードが多用されていている
>unsafeコードの中ではルールを無視できる代わりにコンパイラがチェックを行わない
>つまり、unsafeの中だけはCと同じように自力でメモリ管理する必要がある
>だからこの言語は他言語と比べて学習コストが圧倒的に高い
この辺考えたら結局C++で、できる限りスマートポインタ使うってのと大して変わらなくね？
て話になりそう。

192 ：
ライブラリの中でunsafe使ってたからといって、そのライブラリ使用したコード全てがunsafeになる訳でなし
気にし過ぎじゃないか

193 ：
いやなるで
unsafe内Cのリソース確保を呼んだなら同じく解放処理も呼ばないとリークする

194 ：
>>193
いや、ならねーよ
内部でunsafe使ってるからunsafeになるなら関数にもunsafeつけて前提条件つけないといけない

195 ：
>>188
今やってるサンプル問題はその辺り無しでも解ける難易度だから
rustのつらみがイマイチ分かってないんだよね。
何個か前のスレにあった木構造っていうのをやってみればええんやろか。
難し過ぎるやろか。

>>190
こんなぽんこつに教えてくれてるんやからありがたい話やで。

196 ：
>>187
JavaもC#みたいにできるようになりました…
どうせみんなKotlinとかScala使うからいいけど

197 ：
>>195
webか目的ならwebアプリを作るべきでしょう
使いもしないデータ構造やアルゴリズムなんて判断基準にならないでしょ

198 ：
java10出たってどうせ現場じゃ使わせてくれないんだろ？
んで未だにstrutsとかオレオレフレームワーク強要するんだろ？

199 ：
WindowsでRust使っている人ってほとんどいないんだろうな
rustupを実行する前にVC++をインスコしろとか書いてあるし

200 ：
生で動かす組み込み系の情報収集をしているんだけど半年前よりはだいぶ増えた感があるけどまだまだ少ないなぁ
特にRust以外のツールとCargoの連携について説明されている記事はほとんど見あたらない
ローレベルではユーザーツールやアセンブラ、リンカとビルドシステムの連携は必須だからな

Cargo前提のRustだとシェルスクリプトやバッチファイルでビルドというわけにも行かないし(それらに必要な情報も同じく少ない)
既成のCライブラリやクレートを使う記事はちらほらあるけどそれらが使えないケースだと参考にならない

このへんで役立ちそうな記事って今のところこれくらいしか見つけられていない
ttps://nkon.github.io/Rust-embedded/

もっともRust抜きでも最近は高レベルのフレームワークを使っていたりOS上での動作だったりするからローレベルの情報は減少傾向だけど

201 ：
「業務でRustを書きたいエンジニア募集！」みたいだよ

https://www.wantedly.com/projects/97207

202 ：
>>201
ごめん、募集終了してたわｗ

203 ：
集まったのかな？それとも応募が無かったか。
どちらにせよ気概は応援する

204 ：
会社的にゲームのサーバーサイドかな
C++からの乗り換えならビルド時間の削減が一番効果あるかもね

205 ：
ニコ生は、Rust で、各サーバーに分かれているシステムを、
統合しようとしているらしい

Rust, Elixir は注目されてる

206 ：
>>200
rustでおもちゃのOS書いてる(た)んだけどローレベルな部分にも適してるみたいなことを謳ってる割にcargoがほんとクソなんだよなぁ

207 ：
>>206
またcargoがクソって話か…別にそれほど使いづらいとは思わないんだけど…
(使い方に関する情報が少ないという意味で使いづらいという意見なら分かるんだけど…)
どこら辺がクソと思ってて、どうなってれば満足なわけ？
なんだか実現不可能なくらい賢いツールを「ないものねだり」してるように聞こえるんだよね…
というわけで、実在するツールで最も理想に近いツール(もちろん他言語のパッケージ管理ツール)の例を挙げてくれる？

208 ：
Rustのwebフレームワークでなんとなく一番使えそうなRocketとかいうのがnightlyでしか動かない

209 ：
組み込みでパッケージ管理ツールの需要はあまり無いはず。ビルド管理ツールの方が重要
しかも言語の垣根を越えて使いやすい奴

システムプログラミング用を謳っているんだから
「Cやアセンブラで生で動くプログラムを書いたことがあるんだけどRustに興味がある」
位の人を対象にしたチュートリアル的な物が欲しいな。もちろんある程度実践的な内容で

そういえば調べている中でLチカのウェイトにビジーループを使っているコーディング例がいくつも出てきた
自分はタイマと割り込みを使うのが普通だと思っていたんだけど(勉強するという意味でも)最近は違うのかな？

210 ：
ビルド管理ツールでも良いから、とりあえず、使いやすいツールの例を挙げて欲しんだけど…
「〇〇というツールがあって、××が出来て便利。それに比べてcargoは…」みたいなさぁ…
「使いやすい奴」とだけ書かれても「使いやすい」の基準がさっぱり分からん

211 ：
>>207
ごく普通に使うぶんには俺もディスるほどではないとは思うよ
ただOS書いたりみたいな部分では不満を感じることが多かった

例えばビルドスクリプトとしてのbuild.rsがビルド前のいわゆるpreしかなくてpost的な使い方が出来ないとか
カスタムターゲット書くにしてもlinker-flavorとかそれに対応するリンカに渡されるオプションの一部とかがコンパイラのソースにハードコーディングされてるんで制約ばっかで柔軟性が低いとか

212 ：
rustのwebフレームワークはもうひと世代先のが出るまで本命は決まらなそうだ

213 ：
>>207
> (使い方に関する情報が少ないという意味で使いづらいという意見なら分かるんだけど…)

自分で書いてるじゃん

214 ：
>>209
タイマ割り込みは環境依存度が高いから、サンプルとして適さないんじゃね？

215 ：
>>208
nightlyすぐコンパイルエラーになるよね
まあだからnightlyなんだけど

216 ：
hyperは非同期シングルスレッド対応してるけど、他のFWはまだ未対応でマルチスレッドベースばかりだね

ironは今はメンテされてないし、とりあえず業務で簡単なAPIサーバー構築時にはrocket使ったわ

217 ：
>>205
ニコニコみたいな机の上でのお勉強しかできないバカばっか揃えた結果
クソみたいなサービスしか作れない技術力のない会社がRust使う選択したなら、
逆神でRustつかわないのが正しい選択って公になったようなもんだな

218 ：
でも、ドワンゴ江添は「C++11/14 コア言語、江添 亮、2015」と言う、

神の書を書いてるから、一流の伝道師！

219 ：
tokioがマルチスレッドを標準にしてくみたいだからhyperもマルチスレッドに寄ってくんじゃないかなあ

220 ：
RustのORMのDieselってテストに対応してますか？
開発用DB使うタイプ、モック使うタイプどちらでもいいんですけど…

221 ：
>>218
典型的な机の上のお勉強だけ得意な人やん

222 ：
ほんそれ

223 ：
てか奴はコード書いてないこと宣言してるしな。
そゆとこは正直で良いと思うが、プログラマとしてはクソだな。

224 ：
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006

これは、日本の大企業から、猛者を数十人集めて、
欧州委員会に問い合わせながら作った本

C++11/14 コア言語、江添 亮、2015

それに比べて、江添はたった一人で作ったのじゃないか？
超人的すぎるやろw

225 ：
江添ってイケダハヤトみたいな胡散臭い人たちと同じカテゴリーなんでしょ
実力はないけど口が達者だから信者が多い
芸人向き
そのうち討論番組とかでテレビ出演とかしちゃいそう

226 ：
江添は標準化委員会の一人だからな
一人で書けるのは確かに並大抵じゃないだろうが
一人で書けなきゃそれはそれでヤバイ

227 ：
まあ次世代の池田信夫といっていいんじゃないかな。

228 ：
やまもといちろう、清水亮、津田大介あたりだな

229 ：
やまもといちろうのしったか芸は凄いｗ

230 ：
ニコ生ってたしかRust使ってるんだっけ？
Rust江添の今後に期待

231 ：
>>230
だからニコニコごときが選択したってことは使えん技術ってことだろ
ネトフリとかが採用したら考えるが

232 ：
Rust採用事例
ニコニコ←負け組
火狐←負け組
Mercurial←負け組
泥箱←個人情報お漏らし

採用する気にもならん事例のオンパレード

233 ：
顔本もテストプロジェクトかなんかで使ってた記憶があるが、
そういやここもお漏らししたっけな

234 ：
【悲報】Packt出版より出る予定だった Rust Blueprints が出版取消されました。

235 ：
>>234
資源の無駄だからな。当然の結果

236 ：
また来たのかよ

237 ：
Rustってキラーアプリあんの？

238 ：
ErlangとScalaもディスってるんだ
https://github.com/dwango

239 ：
セキュアプログラミングとかいって締め付ければ締め付けるほど
インシデントが増えるw
本質はそういうところじゃないってことがよくわかる。

240 ：
>>239
じゃあ本質はどこにあるんだよ？
自分には分からないからってだけが理由でそうじゃないと決めつけるのは勝手だけど…

241 ：
開発効率やランタイム速度を気にしなけりゃ既存の言語でも安全に作るなんてのは
簡単なんだよ。
そのトレードオフをどれだけ解決できるかが本質。

242 ：
開発効率やランタイム速度を気にしないことが本質？

243 ：
おぉっとここで日本語の分からないバカが登場～

244 ：
>>241
安全に作るのが簡単ねぇ…
簡単だったらGoogleがバグ(セキュリティホール)の発見に
多額の報奨金を出すのはおかしいとか考えないのかね？
君にとっての"安全"の基準が分からないんだが…

245 ：
>>244
グーグルにとってみたらそっちのがよっぽど楽、つまり開発効率がいいからでしょ。
理解不足の人がいるようなのでもう一度言うけどトレードオフの問題だっつーの。

246 ：
>>245
極論だな
開発効率を無視するなら安全に作ることは可能ってことだろ
開発効率を無視するってのはつまり開発期間が無限大と仮定するってことだぞ
開発期間が無限大でなければ安全に作ることが不可能なら
それは実質、安全に作ることは不可能って事と同義だからな

結局言いたいことは"開発効率・ランタイム速度"と"安全"がトレードオフの関係にあり、
それをいかにして解決するかが本質ってことだろ
で、その"解決"が何を指すのかっていう一番肝心な部分が抜け落ちてるぞ
"トレードオフの均衡点をどこに置くべきかを探る"のが解決なのか
それとも"トレードオフの関係自体を壊そうとする"ことが解決なのか
あるいはその両方か

あと、Googleは開発効率を優先して報奨金を出してるわけじゃないだろ
そもそもリリースした後のものは開発ではなく保守なんだから
あれは完璧に安全なものを作るのは不可能だから苦肉の策として行ってるだけ

てゆーか、ツッコミどころが多すぎるんですけど…

247 ：
>>238
もちろん
Erlangは状態中途半端にブッ壊すだけだし
Scalaなんてもはや新規で使うところどこにもねえだろ

248 ：
>>246
バカじゃね？
Rustがその解決になってるかって観点がどこにもない

トレードオフの落としどころとしてRustにはなんの実績もないし、CやC++と周辺ツール合わせた環境に勝る性質もなにもないって言ってんの
ValgrindやCoverityみたいなツールに比べた優位性あるの？
ただ書きにくい言語がひとつ増えただけじゃん

249 ：
お前が元気で帰ってきてくれてよかったよ

職は見つからなかったんだね

250 ：
>>248
"解決"が何を指すのかを聞いているのにそれには答えずに
Rustは"解決"していないとだけ答える…
会話が噛み合わない…どうすればいいのか…

251 ：
実績がないって言うのもFirefoxの一部は既にRustで置き換えられてるのに
君がそれを実績として認めないってだけだろ
ブラウザを一から実装しなおして、それが大きなバグを出すこともなく
Chromeと同レベルの実行速度を実現してるってだけでも充分に実績として認められると思うが。
Chromeに比べればシェアは少ないがそれでも世界中で数百万という人間がFirefoxを使ってるんだぞ

252 ：
そこは何億人ものって言わなきゃｗ

253 ：
>>252
数百万はかなり適当に発言した
実際はどれくらいなんだろうな？

254 ：
3億人くらい？

255 ：
Javaなんて30億のデバイスで動いてんだぞ！

256 ：
>>251
せめてchromeと同じシェア取ってから言って欲しいもんだ

257 ：
Write once, run anywhere なんていう開発プラットフォームがあるらしい
Electronって言うんだって

258 ：
native modules はい論破。

259 ：
chromeメモリ食いすぎなのでfirefox59に乗り換えたよ

260 ：
>>256
"せめて"でChromeと同じシェアなのかよ。ハードル高すぎだろ
そんなのどんな言語使ったって数年じゃ無理だわ
もちろんChromeと同じC++を使って作り直しても無理だわ
どうやら君の御眼鏡にかなう言語はこの世のどこにも無さそうだな

261 ：
Rustで書き直したら安全で高速なプログラムが簡単に書けるんだろう？

ならchromeのシェアを奪うのなんてすぐじゃないか
本当にRustにそれだけの性能があるなら

262 ：
Chromeは昔のIEと同じくらい危険なブラウザになってきたよな。
やはり危険度はシェアで決まるんじゃないだろか。
そもそもあれだけ複雑で奇怪で大きなソフトウェアにバグが無いわけないし。
いやもちろん、HaskellやJavaやJavascriptのような安全な言語で書かれていれば一切のバグは無いんだろうけどさ。

263 ：
ここRustスレだったかｗ
じゃあ、Rustのような安全な言語で書かれてればバグは無いんだろうけどさ。

264 ：
Chromeの開発者がRustで書き直したいと書き込んでるのは見たことあるけどな。
でも、書き直すったってそもそも発祥がKHTMLだしな。
Googleは出来損ないのブルドーザーみたいなもんだ。

265 ：
HaskellはともかくJSやJavaは安全なのかね？
まあスレチだが

266 ：
>>261
>Rustで書き直したら安全で高速なプログラムが簡単に書けるんだろう？
誰もそんなこと一言も言ってないだろ。勝手に曲解しないでほしいな
C++よりはRustの方が設計が良いってだけ
そう言ったら次は"C++より良いって言うんならC++で書かれてるChromeより
Rustで書かれたFirefoxのシェアが少ないのはおかしい"って言い出すんだろ
既存資産はC++のほうが何十倍もある。資産が少ないってのはそれだけで不利だ
言語設計はダメだが資産の多いC++か、言語設計は良いが資産の少ないRustか、
どちらを選ぶかは人によって意見が変わるところだろう
資産の問題に関しては時間が解決してくれるかもしれない…希望的観測に過ぎないが…

>ならchromeのシェアを奪うのなんてすぐじゃないか
すぐなわけないだろ。
ブラウザを選ぶ基準なんて数え切れないほど色んな要素が絡み合ってるんだよ
その中には"なんとなく、みんなが使ってるから"なんてしょうもない理由も多く存在する
全ての人間が合理的な判断を下すわけじゃないんだ。そんな単純に事が運ぶわけがない

だから、ツッコミどころが多すぎるんだって…

267 ：
Boostはオナニーし過ぎのグロRみたいなもんだが使わざるを得ないって話か。

268 ：
Javascriptのお勉強をした結果、GCは何の解決にもならないことが分かった。
むしろ危険。
ライブラリがリークについて何も考えていないんだもん。

269 ：
なんでだろ～なんでだろ～と検索した結果、あの有名な企業のブログで解決策を発見。
曰く、ライブラリがリークするようにできてるから、一定時間で再起動とか。
そんなのが多すぎた。

270 ：
ぐだぐだ言い訳してるのを総合すると
「モノは良いけど使い手が少ないせいで流行らない」ってか？
使い手が少ないのはものが悪いってことだろ。残念でした

271 ：
Go言語見てみろ
モノはいろいろと微妙だがCやC++と比べて強烈な利点があるから、リリースがRustと同じか遅いくらいなのに流行ってるだろ

Rustはどうなんですかねえ？

272 ：
つまりPHPが最良の言語ってわけか

273 ：
わざわざRustスレまできて延々粘着アンチとかかまってほしい爺さんみたいで見苦しいからやめろ

274 ：
>>273
かまってほしい爺さんに、かまってほしい爺さんみたいとかやめてくんない？
あんた人の心あんの？

275 ：
かま爺

276 ：
いくらモノがクソでも流行ってるって一点で考慮に入れる必要はあるし、
逆にどんなに良いものでも流行ってなければ選外になるのは事実よね

PHPが流行ってるのは時代的に残念な背景があるとはいえ、
Goが流行るのは明確な理由があるんじゃないか？

277 ：
それについて掘り下げる意義はないと思いますよ

278 ：
まあ確かにないな
せめて日本語で本が出る程度には流行って欲しいが……

今のRustに足りないものってなんだろうな
RubyのRailsみたいに、ある領域のキラーフレームワークみたいなのが欲しいが
Rustがそれを作れる領域って今のところWebAssemblyくらいしかないんだよな
しかもそのWebAssemblyも、GCが入ったらGoとの立ち位置が逆転するし

279 ：
それはgoが流行っている理由を語るのと同義ではないですか

280 ：
Goこそブランドの影響だと思うけどなｗ
Googleって会社も初期メンバーこそキレキレの人間だったのかもしれんが
ブランドイメージが先行しだしたころから
そこにはそこに憧れて集っちゃった凡人がうじゃうじゃだということを忘れてはならない

281 ：
rustは
ゼロ抽象化みたいな機能ブランドに憧れて集まっちゃった凡人がうじゃうじゃだよね

282 ：
機能ブランドってなに？中身ないの？

283 ：
ないよ。あったらもっと人集まってるよ

284 ：
RustはCやC++を書くのに疲れた人のための言語という位置付けなのに
Rustを書ける奴は別にCやC++書くのに困らないって
イカれた習得難易度に作ってしまったのがそもそもの失敗

Rustのターゲットは別にRustなんて使わなくてもいいかそもそもRustを使えないかの二択
ドンピシャなターゲットが存在しないから流行りようがない

285 ：
rustを書ける人でcやc++で困らないと結論した人が沢山いるということですか？

286 ：
>>284
>RustはCやC++を書くのに疲れた人のための言語という位置付け
これは事実だけど、C++より簡単に書けることを目指して作ったわけじゃなくて
ポインタ周りのバグ(特にバッファオーバーフローなどが原因のセキュリティホール)
に悩まされてきた人間のために作られた言語だからな
セキュリティを考えてない奴からすれば無用な長物にしか見えないんだろう

287 ：
>>286
訂正：無用な長物→無用の長物

288 ：
>>286
Rustできちんとコード書ける実力あるなら
CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な

289 ：
てか｢一応読み書きはできるようにはなったけどC/C++の落とし穴を知らないせいで危ないコード書いてる初心者｣こそRustやるべきだよな
>>56みたいな

>>56がなんでエラーになるのか理解できないって事はC/C++でもvectorへの参照を何も考えないで使い回してたりするって事だし

290 ：
ああそれはあるかもな
実用というより教育目的な言語としては確かにアリだ

291 ：
>>288
>Rustできちんとコード書ける実力あるなら
>CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な
出来ないからC++ではValgrindとかのツール使ってチェックしてるんだろ
じゃあツールを必ず使うようにすればいいじゃんって話にはなるが…

292 ：
そもそもValgrindみたいなメモリリークをチェックする類のツールって
Rustのボローチェッカと比べるとどの程度信用できるのかね？

293 ：
あまり信用出来ない
スマートポインタを(適切に)使ってればそもそも解放忘れはしないし
配列に確保しっぱなし系のリークは検知してくれない

294 ：
>>293
>あまり信用できない
>配列に確保しっぱなし系のリークは検知してくれない
そっか、やっぱりRustのボローチェッカには劣るか
>スマートポインタを(適切に)使ってればそもそも解放忘れはしない
「適切に」ってところがポイントだよね
たとえ熟練のC++erがどれだけ注意してコーディングしてたって
「うっかりミス」はいつか絶対に起きるんだし

295 ：
C++でボローチェッカをエミュレーションできないの？

296 ：
C++ちゃんとかけるならRustも楽勝でしょ。

297 ：
>>288
できないよ、人間だもの

298 ：
valgrind使うと実行時間とてつもなく遅くなるし実行時間長いプログラムだと辛い
ASANでも2倍くらい遅くなるので辛いのは同じ
コンパイル時に静的に分かる方が嬉しいし、たまにしか通らないパスもチェックされるのでより安全

299 ：
まあ結局unsafe部分はチェックできないけどね。
その場合でもコンパイル通ったからと主張しだす輩で溢れてる。

300 ：
どこに溢れてるの？

301 ：
脳内

302 ：
C++20では生ポが非推奨になるらしいけど
unsafeはチェックできないのと同様に意味がないですね

303 ：
他言語呼んでもメモリリーク起きないとかこのスレでも喚いてた輩がいたわけだが。
drop trait を明示的に書かなっきゃならんとかそいつら全く理解してないだろ。

304 ：
>>302
非推奨になるってどういうこと？
rustみたいにunsafeブロックみたいなのを導入するってこと？
C++は基本的にはCとの互換があるから無理だと思ってたんだけど…

305 ：
生ポインタ使えることがC++の唯一のメリットなのに
それを非推奨にするなら別の言語使ったほうがマシだろ

306 ：
RustがC++に実用面で勝ってることなんかある？

307 ：
勝っているかどうかは知らんが
cargo/crates.io相当のものがないから
新規アプリをC++で書く気はしなくなってしまった。
もしかして最近は便利になってたりするんだろうか。

308 ：
全称命題にするからすぐ反論される

309 ：
ペチパーのわしでも書けるのが勝ってる

310 ：
しかしインスタンスを変に共有しなけりゃ解放タイミングを
いちいち気にしなくていいって発想は面白い。

311 ：
いや、それ当たり前のことだから。

312 ：
RustでWebブラウザ作ってる人いるね


https://twitter.com/uint256_t/status/952818644433555456

313 ：
参照カウントガベージコレクションにもスマートポインタにも興味ないrust信者すごいね

314 ：
GCに興味ないのはともかく
BoxとかRcとかモロにスマートポインタだから興味ないとか以前の問題なんだが？

315 ：
というかなんで今になって参照カウンタGCなんて超素朴なGC実装を引き合いに出すのかが分からん
Goですらそんなもん使ってねえぞ

316 ：
……まさかとは思うがC++のshared_ptrのことを指して参照カウントGCと称してないよな？

RustではRcとかArcがそれに該当するから、この文脈でも完全に的はずれになるが

317 ：
>>315
Swiftは参照カウント方式のGC採用していたような気がするが
ARCってやつ

318 ：
久しぶりに見に来たらアンチが帰ってきてるじゃん。
せっかくだから、おれも反論レスを書き込むことにする。

319 ：
>>288
こんなこと言っちゃってる時点でセキュリティに気を使ってないのバレバレだよね
セキュリティ関係に詳しくなくて分からないんなら素直に分からないって言いなよ

320 ：
>>299
unsafeなんてC FFIしようとか考えない限りあまり使うことないよ
tokio-coreとかhyperとかhtml5everとかのソースコード見てきなよ
unsafe使ってる箇所なんて10箇所あるかないかってところだから。
コード全域に気を配らなきゃならないのか、たった10箇所程度に気を付けてれば良いのか、
どちらが楽(安全)なのかは火を見るよりも明らかだよね

321 ：
>>303
これに関しては自分がC FFIのコードを滅多に書かないから「そうだったっけ？」くらいにしか考えなかったけどよく考えたら全然違うよね。
まず、値渡しなら引数・戻り値ともに何の問題もない。そのまま渡せばいい。
ポインタ渡し(Box<T>)だった場合はCの関数の引数が所有権か借用のどちらを欲してるのかを確認して、
所有権を欲しがってるならBox::into_raw(x)で所有権を渡せばいいし、
借用が必要ならx.as_ref() as *const _ もしくはx.as_mut() as *mut _で渡せばいい。
戻り値の方ではC側から所有権が渡されてるはずだからBox::from_raw(px)でBox<T>に戻せばOK。
文字列(String)の場合はCStringに変換してから後はBox<T>と同様にinto_raw, from_raw使えばいいだけ。
Vec<T>とかを渡そうとする場合はx.as_ptr()またはx.as_mut_ptr()と場合によってはmem::forget(x)が必要になるんじゃないかな？
受け取る場合はVec::from_raw_parts(px, len, cap)を使えばいいはず。(前述のとおりC FFIはあまり詳しくはないので間違ってたら指摘して下さい)
unsafeの中に何を書けば良いのかはC側のどんな関数を呼ぶのか次第で変わってくるけど、少なくともDropトレイトに関しては全く必要ない。
Box<T>やVec<T>等にあらかじめ実装されてるDropトレイトに任せればいいだけ。むしろ君はDropトレイト使って一体何する気だったのか…？

322 ：
Rustのアンチするのは一向に構わんが、せめて嘘をつくのはやめようね。

323 ：
C FFIとやらを使うためにはRustの知識だけでなくCの知識も必要
Rustだけ学べばいいなんてことはない

324 ：
>>323
cの関数呼ぶんだから当然だろ

325 ：
>>321
Rustで確保したリソースをCに渡す場合は確かにdropいらないけど、
C側で確保したリソースについては必要では？
Cから何かハンドルが帰ってきて最後にCでcloseするパターン。

326 ：
>>325
Rust側でDropしないためにDropの実装を上書きする必要があるということ？

327 ：
>>326
Cの関数内で確保したリソースは
当然Rustデフォルトのdrop実装では解放されないから
自分でdrop実装して解放する必要がある、という話。

328 ：
>>325
>>303は「メモリリーク」って書いてあるからヒープに確保されたメモリの解放に関しては
Dropトレイトを実装する必要性なんか全く無いってことを>>321で説明してる。

>>325の言ってる「リソース」ってのはファイルとかソケットとかのことを言ってるんだよね
そっちはメモリリークとはまた別の話になるので状況によるんじゃないかな…
ただ、OSが提供してるリソース(ファイルやソケット)くらいなら、File, TcpListenerとかには
Windows用とUnix用にそれぞれinto_raw_xxx(), from_raw_xxx(), as_raw_xxx()とかが用意されてるから
それを使えば後のことはFile, TcpListenerのdrop実装に任せてしまって問題ないはず。
C側(ライブラリ)で独自に実装されてるリソース(close等の後処理が必要な実装)の場合は
close部分をRustのDropトレイトの実装として移植する必要はあるだろうね。
(もう一度言うけど、自分は普段はC FFIを使わないから詳しくはないので、間違ってたら指摘して下さい)

329 ：
>>328
メモリリークに限定するとしても
CでmallocしたポインタがRustに渡ってきた場合
Rustが勝手に解放するわけにはいかないから
drop実装してfreeを呼ぶ必要がある。

330 ：
>>329
ちょっと言ってる意味がわからない
Cでmallocされたものであっても所有権ごと渡されていれば解放の責任はRustにある
ていうか、Rust側で勝手に解放しちゃいけないと言ってるのに
Dropトレイトの実装でfreeしたらやっぱりRust側で勝手に解放しちゃってるじゃん
言ってること矛盾してない？

CとRustで型のメモリレイアウトが一致してればあとはBox型に任せるだけだよ

Cから渡されてくるポインタの型のメモリレイアウトが公開されていなければ
(つまりvoidポインタだったりオペーク構造体(オペークポインタ)だったなら)話は別だけど。

その場合はRustはハンドルをもらうだけでいかなる操作(メモリの解放(free)も含む)もC FFIでC側に
頼むしかない(メモリレイアウトがわからない限りはRust側ではどうあがいても何も出来ない)ので
Dropトレイト実装してdrop時にC側にメモリの解放処理も頼む必要がある

331 ：
FFIの場合jemallocかシステムのmallocかの違い問題になることありそう

332 ：
>その場合はRustはハンドルをもらうだけでいかなる操作(メモリの解放(free)も含む)もC FFIでC側に
>頼むしかない(メモリレイアウトがわからない限りはRust側ではどうあがいても何も出来ない)ので
>Dropトレイト実装してdrop時にC側にメモリの解放処理も頼む必要がある

だからDropトレイトを意識的に実装せにゃならんと始めから言ってるだろうに。
このタイプは絶対仕事でモメるわ。

333 ：
>>322
だったら「Rust側からはメモリレイアウトが分からないようなvoidポインタや
オペーク構造体がC側から渡された場合は」という前提条件をきちんと書け。
条件を何も書かずに「drop trait を明示的に書かなきゃならん」とだけ書かれれば
全ての場合で必要だと言っているようにしか見えない。

あと、>>321で「全く」と書いてしまったことは悪かったと思っている
>>321を書いてる時点は上記のような可能性に気づいていなかった…申し訳ない。

お前みたいに「特定の条件下でしか適用されないこと」に対して条件を書かずに結論だけ書いて
「自分はきちんと伝えた」とか思っちゃってるキチガイとの仕事とかこっちの方から願い下げだから。

334 ：
>>331
そこは自分も同じことを思った。
mallocとjemallocの実装の中身とか見たことないけど、混在してても問題ないのかな？

335 ：
>>333 訂正
>>322 → >>332

336 ：
>>330
「勝手に」の部分が曖昧だったので正確に書くと、
Rustはメモリ解放すべきタイミングは知っている
（すなわちCから受け取ったポインタのlifetimeが切れたとき）
Rustはメモリ解放の方法は知らない
（なぜならCのmallocがシステムのmallocなのかjemallocなのか別の何かなのか知るすべがないから）
なので方法について教えるためにdropを実装する。
（このdropでCのfreeを呼べば、mallocと同じメモリアロケータが保証される）

ちなみにメモリアロケータ間の互換性はないので、
例えばlibcでmallocしてjemallocでfreeすると多分SEGVする。
コード例は以下でもどうぞ。
https://stackoverflow.com/questions/31486519/how-do-i-free-a-char-allocated-via-ffi-in-rust

337 ：
>>336
マジか…mallocとjemallocは混在できないのか…
そうなると、C側でmallocされてれば必ずC側にfreeしてもらうしかないということか…
じゃあ今まで俺が書いた方法じゃダメなケースもあるじゃん…すまん。
自分の無知を晒す羽目にはなったが、むしろ今知れてよかったわ。
でも、そうなると新たな疑問が…

338 ：
jemallocじゃなくてシステムのアロケーター使うオプションだかfeatureだか使えば良いかな

339 ：
>>336
間違いの指摘と情報提供のお礼言うの忘れてた。Thanks!

あと、これってRustでのC FFI に限った話じゃないよね？
C同士でさえもアロケータに何を使ってるか次第で同じ問題が発生する。
Cは時々使ってたのに(しかも仕事で)これを知らなかったのはヤバいな…
恐らく今まではたまたま同じアロケータを使ってたから問題が起きてなかっただけか…
戻り値で文字列(char *)が来た時とかこっちで勝手にfreeしてたぞ…(^_^;)
まあ、どのアロケータ使ってるかなんて誰も気にも留めてなかったし大丈夫だろうけど、
今後は気を付けないとな…

340 ：
すべての有用なライブラリがRust製にならない限り
Rustだけを学べばよいという状況は訪れずCやC++の習得も必須

341 ：
>>339
どういたしまして。

C同士の場合は普通glibcへの動的リンクだし
LD_PRELOADとかでjemallocなんかに差し替えても
プログラム全体で差し替わるから特に問題にはならないかと。
もしメモリアロケータを静的リンクしたライブラリとかを使っていればまずいはず。
ただそういう場合はリソースハンドルっぽいAPIになりがちなので
そのままfreeしようとは思わないかもしれない。

342 ：
>>340
そりゃそうだろ、なにいってんだ

343 ：
やくに立たねー結局cか。rustって趣味だな。

344 ：
C/C++だけ覚える
or
RustとC/C++を覚える

学習コスト高すぎRust

345 ：
>>343
趣味でモジラの栄養やるとかどんなドマゾだよ

346 ：
今の会話見るだけでもRustがいかに欠陥言語かわかるのに
それでもRust使うって言うんだからなあ
全部C/C++で書く方が遥かに効率いいしバグも出んわ

347 ：
C覚えるの必須当たり前ってんなら構文もっとC系に寄せれば良かったのに。

348 ：
今までの流れからその結論は極端すぎるだろ
もう少し工夫しろ

349 ：
いつのまにか、FFI使うことが前提になってる流れって、rustをdisりたい勢の必死さがうかがえて、ある意味、面白い。

350 ：
>>339
CのfreeはNULLなら何もしないと保証されてるけど
解放済みアドレスへのfreeはセグフォ発生するぞ

351 ：
Cの資産に寄生しないとろくなもん作れないのに
そのCとの連携部分が腐ってるってことじゃん

使いもんにならねえって評価は妥当だと思うが？
それともPure Rustでまともなもん作れるつもりか？

352 ：
まずまともなもんを先に定義してくれ

353 ：
バグらない
動く
実用的
上記3点の実績がある

354 ：
実用的・実積も曖昧だな
どの程度を実用的で実積があると呼ぶのか具体例を提示してくれ

突き詰めていくと「バグらない」も程度によりけりだしな
Excelだってバグるときゃバグるし…

355 ：
本スレは相変わらず過疎だしまじ終わったなこの言語

356 ：
話に入れないからって「………結局駄目！」ってダサすぎない？

357 ：
jsのファミコンエミュレータをrustで実装し直したらパフォーマンス負けたらしいｗｗｗ

358 ：
>>357
JSに負けるとか草しか生えんなwwwwwww

359 ：
>>354
Linuxくらいバグらないならいいよ

360 ：
>>357
噂に尾ひれがつく瞬間を目の当たりにして草
多分これ↓のことだろ
http://blog.bokuweb.me/entry/2018/02/08/101522
誰かC x wasmで書き直してみろよ。きっと似たような結果になるから

>>359
ついにLinuxと同レベルじゃないと認めないとか言い始めたぞ…

361 ：
>>357,358
ブラウザ JS版 Wasm版
Chrome 63 4.36ms 5.68ms
Firefox 58 5.76ms 3.98ms
Safari 11 9.98ms 4.21ms

う～ん草しか生えんね 草草草の草ァ！だね

362 ：
>>361
wasmじゃなくてRustと比べてから言えよ

363 ：
>>362
草しか生えんわｗｗｗ

364 ：
まあメモリの管理モデルが違う言語同士でやりとりすれば
色々苦労するのは当たり前なんだよね。
それなのに「rustは勝手に解放してくれる」とか言い張っちゃう信者が有害な訳だよ。
rustが悪いというよりか、こういう馬鹿が多いところが問題。

365 ：
Haskellは副作用が無いとか参照透過性があるって言った時に
C FFIを持ち出して反論するのと同様の不毛さを感じる

366 ：
不毛？現実によくあることなのにね。。
言語の一番下ではアセンブラが動いてるんだから、そことどう調和もしくは隠蔽させるかってのは
コンピュータ言語にとって本質でしょうが。

367 ：
は？何で一番下が機械語じゃなくてアセンブラなの馬鹿なの？

368 ：
コンピュータ言語ｗ

369 ：
アセンブラと機械語は1:1で訳せるから…

370 ：
アセンブリやろ

371 ：
結局Rustはサーバ向けでもコマンドツール向けでもGUI向けでも組み込み向けでもない

って事実はほんと覆らんよ

372 ：
話に入れないからって「………結局駄目！」ってダサすぎない？

373 ：
jsのファミコンエミュレータをrustで実装し直したらパフォーマンス負けたらしいｗｗｗ

374 ：
>>372
悔しかったら反論してみたらぁ？

375 ：
>>372
メモリ管理みたいな重要なことについてデララメ振りまいて、
「理解しない奴がrust批判してる」とか言い出してる方が恥ずいわ。

376 ：
上の流れ素直に読んでも、
メモリ管理も全部C側で完結させるのが一番いいって結論にしかならんぞ？

Rustのいいところなんぞ皆無だ

377 ：
というかコンパイラにメモリ管理任せるのが無理だろ。FFIのためにいちいちDrop定義するとか非効率でしかない

メモリ管理はGCに任せるか完全手動にするかの二択なのに、無理矢理そこにヘンテコリンなソリューションもどき持ち込んで混乱引き起こしてるだけじゃん

378 ：
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる

379 ：
>>377
うおっ!
ここにきてまさかのRAIIを否定し始めるとか予想外すぎたわ!
お前C++のスマポってなにか知ってる？

380 ：
>>379
ほとんどのコンパイラで採用されてない仕様書上にしかない機能なんざ知らんよ

381 ：
実際混乱引き起こしてるまともじゃない方法なのは上の流れで自明だろ

382 ：
>>380
よろしい。そんな君にはJavaがおすすめだ。そっちで元気にやりたまえ。

383 ：
以前も言われてたけど「ひまわり学級の子が普通の授業に出て暴れてる」って表現が実に的確で草

384 ：
間違ったものを間違った奴が流行らせようとしてるんだからそれには「違う」って言っとかないとダメだろ
話にならんと放置したらいずれ手遅れになるほど蔓延する
そうならないうちに叩いておくべきなんだよ

385 ：
混乱引き起こしてるのは違いないけどさ
「俺の頭の中で混乱を引き起こしてる」って正確に書こうよ

386 ：
>>385
上のFFI絡みの流れは俺じゃないけど？

387 ：
完全手動でメモリ管理するのは混乱起きないからいいよね～

388 ：
>>387
コンパイラに丸投げするよりは良いな
混乱しないって意味だとGCが一番だが

389 ：
>>375
上のやり取りは俺じゃないけど？
散々間違いがあったら指摘してくれって書いてたのがデタラメを振りまいた？
間違いの指摘に礼を言って終えるところに、鳴りを潜めていたアンチがウキウキで「混乱を引き起こしたRust！！！」と喚き立てた
このスレでも何回もやってる流れじゃんクソダセー

390 ：
はいはい内ゲバですね
ほんとくだらん言語

391 ：
>>390
内にいるつもりなんだお前

392 ：
インタプリタへの丸投げ>完全手動でメモリ管理>コンパイラへの丸投げ
実行開始までの混乱しない順だなどう考えても

393 ：
>>391
外から内ゲバ眺めてやっぱこの言語くだらねって思ってるだけ
C++の（後方互換維持のための苦しい構文追加以外）なにが悪いんだか

394 ：
>>393
スマポが何かを知らないヤツがC++を語り始めたぞ…

395 ：
>>378
ていうかこれ知りたい
Rustの何が(例:MIR)どう機械語との相性が悪く
それに対してC/C++のまともなアプローチの具体例を教えて

396 ：
>>395
代弁してやろう。
「自力で頑張る」

以上

397 ：
>>395
結局解放処理は自分で書くんだろ？
メモリ上の確保のされ方はコンパイラにはわからないんだから

結局中途半端にしか自動化できないから無意味で、それなら自分で管理した方が結果的に良いって話

398 ：
解放の仕方を実装したら、後はコードのどの場所で何回確保しても自動で解放される事が分かってないっぽいね

399 ：
>>398
だってRAIIもスマポも知らないんだもん。しょうがないじゃん

400 ：
>>397
C FFIとかの一部分で解放処理を書くんだよ
お前が言ってる通り「手動」だしお前の好きな「手動」でよかったな
中途半端にとは言っても機能するし「無意味」と言い切るには典型すぎる誤謬

で>>395にまともに答えてくれる？どう相性が悪いの？どんなアプローチ？

401 ：
>>400
今の説明でわからんなら一生わからんよ

402 ：
>>401
あっ! 逃げたww

403 ：
Q. Rustの何がどう機械語との相性が悪く、それに対してC/C++のまともなアプローチの具体例を教えて
A. 結局中途半端にしか自動化できないから無意味で、それなら自分で管理した方が結果的に良い

Rustアンチ君との最後のやり取りがこれなのか…？悲しい

404 ：
いい加減ワッチョイスレに移動しようぜ

405 ：
>>404
実際問題ワッチョイは過疎る

406 ：
>>404
YOUがワッチョイのほうで話題ageれば

407 ：
ここはネタスレだからこれでいいよ

まともな話題ないし

408 ：
ワッチョイは運営が管理を放棄するための口実

409 ：
ワッチョイあった方が良い派です

410 ：
いちおう指摘しておくと以下にわっちょい付きのスレはある。
https://mevius.2ch.sc/test/read.cgi/tech/1514107621/l50

411 ：
そう思うんなら勝手にそっちでやってくれ
いちいちこっちに宣伝しないでよろしい

412 ：
せめてスレ立てたやつくらいはあっち書き込んでくれよ。
ワッチョイスレ（本スレ）には俺しかいない。

413 ：
人が集まってる(勝ち残った)方が本スレ

414 ：
アンチスレの方が人多いっていい加減認めようぜ

415 ：
>>414
いちおうアンチスレも存在するんだぜ
http://mevius.2ch.sc/test/read.cgi/tech/1509028624/

416 ：
>>384
大元に言わないで、ここでグダってる時点で説得力無いけどな。

417 ：
英語で説明する気力がないんだろ

418 ：
それもあるが日本語の記事でrustマンセーしてるやつは大抵バカっていうのもある。

419 ：
会話になってないし
時間おいたところで>>395に答えなくてもいいことにはならないからね

420 ：
もう答えた
>>397

421 ：
自分から「機械語のレベルと相性が悪い(>>378)」と言ってるのに
「具体的にはどういうこと？(>>395)」と聞かれて、
その返答(>>397)に機械語のことが一切出てこないのは流石に草

422 ：
英語で説明する以前に日本語でのコミュニケーションに難ありなのか
日本語ネイティブじゃない方なのかな

423 ：
機械語との相性のいいC,C++のソリューションって、機械語バイト列を関数ポインタにキャストして呼び出すとかじゃないの？
そんなことRustでできるようになって欲しくはないな。

424 ：
できるよ
推奨してないけど

425 ：
JITとかそういう用途？

426 ：
rustで書かれたjitなかったっけ？

ところでrustで書かれたウィルスとかマルウェアとかないよな。
goならMiraiで使われてたけど。

427 ：
C/C++の弱い型付けによるキャストは機械語と関係ないだろ
Rustは強い型付けしか原則許してなくてunsafe使えば弱い型付けも出来るけど好んでする必要性はないよねー

プログラミング言語と機械語の間はC/C++もRustもLLVM IRで仲介されてるから、どっちかだけが相性良いとかなさそう
LLVM IRじゃなくGas仲介するとこう違うんだよ、くらいの反論を期待してみるテスト

428 ：
>>427
フロントエンドの話してるのに、バックエンドがLLVMだから違いなどない！は、おかしいのでは？
そんなこと言い始めたら、言語仕様の優劣など語るに値しないということになってしまう。

429 ：
>>427
Any使ったdowncastはunsafeじゃないけどどういうコードの話してんの？

430 ：
このRustのチャットみたいなのって公式のもの？

https://gitter.im/rust-lang/rust

431 ：
rustでフォントをレンダリングしたいのですがfont-rsやfreetypeなどの設定逆引き的なサイトってありませんかね？
チュートリアル的なサイトは見つかるのですがそこから突っ込んで使用したい場合に参考になりそうな情報がみあたらないです
レンダリングされる線を任意の幅にしたいです
極細フォントを使って線幅1ピクセル×2＝計2ピクセルでアンチエイリアス無しみたいな感じの結果が欲しいです

432 ：
具体例を補足します
出力が2値の場合に普通にレンダリングした物を減色してしまうと線幅の不均一になったりディザが掛かってしまって
表示品質が極端に悪くなってしまうのでそれを防止したいです
たとえば「田」みたいな字をレンダリングして減色するとある線は1ピクセルだけど別の線は2ピクセルになってしまったり
交わるところに不要なドットが出現したりします
それを全て任意の線幅に統一したいです

433 ：
ここはアンチスレなので、まともな質問はslackへどうぞ

434 ：
えぇ。。

435 ：
https://rust-jp.herokuapp.com/

rustのslack
↓のサービス使ってオープンにすればよい
http://slackarchive.io 👀
Rock54: Caution(BBR-MD5:b95868ef2c0ed5e765a4d10ada4cf289)

436 ：
Rustってカルトみたいなもんだよな
実態はスカスカで教祖の金儲けに使われてるだけなのに、信者は正義と信じて疑わない辺り

slackなんて内輪の集会に逃げ続けて表の評価に曝されることを避けてる時点でまともなプログラミング言語じゃない

437 ：
>>436
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる

438 ：
>>437
お前はさっさとその答え教えてくれよ
Rust批判するにしてもコンピュータの知識皆無すぎるわ。批判側がお前と同じ知的レベルに見られるのがクソ

439 ：
>>438
へー今日はたくさん書き込むつもりなんだ

440 ：
こちらはまともなアンチとキチガイアンチのスレになります。

441 ：
いやどっちもキチガイだから

442 ：
>>436
表の評価(2ch)wwww

443 ：
少しずつRustの研究が出てきたね
ttps://arxiv.org/abs/1804.10806

444 ：
win10 rs4にしてからrustdocが遅い。
rs4にMeltdown/Spectre対応のパッチも含まれてたんだろうか。

445 ：
Rustを導入している企業・組織の一覧をご覧ください


https://www.rust-lang.org/ja-JP/friends.html

446 ：
Windows defenderが動いてるとかでは

447 ：
少なくとも2chではgoよりrustの方が盛り上がってるな。

448 ：
impl traitはよ

449 ：
パフォーマンスとマルチスレッドを理由にRustを採用という事らしい

https://logmi.jp/282807

450 ：
ドワンゴといい、ヤバい会社の指標としていいねw

451 ：
機械語のレベルと相性が悪いしなw

452 ：
>>450
>>445
これでもそんな知恵遅れみたなこと言うの？

453 ：
同じリストを他言語でも作ってみたら？
どれだけバカなこと言ってるかわかると思うよ。

454 ：
ああそりゃ分かるだろうね、是非作ってみたまえよ

455 ：
>>449
謳い文句通りの「速度とマルチスレッド」で選んだら後でめんどくさいよ。
MIRの導入もなかなか成果出てないし、同期はセマフォ/ミューテックスしかなくて
javaみたいに高レベルから低レベルまで自分で書けるわけじゃないし、
non blocking ioも、lock free collectionもなくて外部ライブラリへの依存度が極めて高いし、
cargo腐ってるせいでrustのtooling絡みのissueが日に日に増えるし。

rustの良いところは言語の部分だからコアな機能使わないなら他言語のほうが良い。
土方の要求には合わないでしょ。

それよりimpl traitまだー？

456 ：
間も無くなんだから静かに待ってなさい

457 ：
>>449
これってgoでは無理だったんかね？
単純に趣味の問題？

458 ：
goって言語仕様でマルチスレッドによるデータレースを起こさない仕組みってあるの？
無かったらその部分が大きいのでは？

459 ：
goはchannel経由にすれば自動的にアトミック
mutex部分が隠ぺいされてるので意識する必要が無い

460 ：
むしろrustがなぜチャネル的なもの入れなかったんだ？

461 ：
標準にも外部crateにもいっぱいあるだろ
ライブラリとしてではなく言語仕様としてという意味か？

462 ：
>>459
言ってることがよくわからんメモリ共有は基本的にmutexみたいな物はついてない気がするけど。基本的にchannel経由で情報交換しない方針にすれば
データ競合は防げるって話では？

rustってデータ競合がコンパイル時点で防げるって意味がわからん。
そんなことがかのうなん？

463 ：
>>462
X 基本的にchannel経由で情報交換しない方針
○ 基本的にchannel経由で情報交換する方針

464 ：
>>463
詳細はこちら
Goでスレッド（goroutine）セーフなプログラムを書くために必ず注意しなければいけない点
https://qiita.com/ruiu/items/54f0dbdec0d48082a5b1

465 ：
数十GBのオブジェクト管理は、gc待ちきついからオフヒープでとか、（これ聞いたときよりgcは良くなってる）
goroutineで確保したメモリは解放せずgoが管理するから、常駐で同時に大量に走ると解放されないとかはあるみたい。

466 ：
>>462
それが売りの一つなんだから当然出来る
具体的にはこれでも読んでくれ

https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/concurrency.html

467 ：
以下の場合に&*fで具体的にどうなってるのかが分からない
*でderefされてトレイトオブジェクトの実態になって、&を付けることで再度トレイトオブジェクトになってる？
ちなみにexec(f.deref())だとそのまま通るけど、これはBoxのderefが&Tを返すからだよね？
*だとBoxのderefで返った&Tではなく、さらにderefされてTが返っているってこと？


fn create() -> Box<Fn()> {
Box::new(|| println!("test"))
}
fn exec<F: Fn()>(f: F) {
f()
}
fn main() {
let f = create();
exec(&*f);
}

468 ：
Derefを実装した型に対しての*xは*x.deref()の糖衣構文
つまり、&*xは&*x.deref()と同じで、それはつまり、x.deref()と同じ

469 ：
なるほど
*x ==x.deref() って言う認識だったのが間違ってたのか
ありがとう

470 ：
impl trait来たな

471 ：
きた

472 ：
久しぶりにRustやろうと思ったけど公式リファレンスが最新版に追いついてないのな
どっかに変更履歴のまとめとか無いのかな

473 ：
>>427
公式リファレンスって何のことを指してるんだ？
APIリファレンスならきちんと最新版に追従してるし、
チュートリアル(The Book)も2nd Editionがきちんと出てる
バージョンアップの追従ならリリースノート見るかRustの公式ブログ見れば大体分かると思う

Rustは6週間に1回のハイペースでマイナーバージョンアップ繰り返してるから
The Bookのほうは最新版に追いつくこと自体がほぼ不可能だと思うけど
(つい最近もimpl traitがstable化されたばっかりだし…)

474 ：
>>473
間違えた
X >>427
○ >>472

475 ：
そのimpl traitが気になってまたRustやろうと思ったんだけどね
全機能の索引みたいなのがないと学習効率が落ちる

476 ：
rustって生産性高い？
安全性が高まって結果的に高くなるということではなくね
やっぱでかいプログラムじゃなきゃ使う効果ない？

477 ：
Javaでnull参照が10億ドル単位の損害と言われてるので
RustはJavaより10億ドルほど生産性が高い

478 ：
まあ、ネタにマジレスになるが、
その論法だと俺の未完成言語は誰もバグを生み出してないので
Rustより生産性が高いなｗ

479 ：
>>478
分母分子共にゼロなので計算不能ってやつね。

480 ：
チーム開発に良さそうな気がするけどメンバーのレベルにかなり依存しそう

481 ：
自分がGCなしの言語使ってた時の経験だと、ヌルポより、freeした後にアクセスするバグの方が多かったから、オーナーを一つにするrustはいいと思う。
まあ、objective-cのARCでいいじゃんとも思うけど。

482 ：
そこでoptionalですよ
こいよ継承クラス、ポリモーフィズムなんて捨ててかかって来い！

実際、null非許容のポインタが欲しい

483 ：
誰がヌルポなんか 、ヌルポなんか怖かねぇ！

484 ：
C#だとぬるり

485 ：
C#の発想元はJavaよってC#もぬるぽ(意味不)

486 ：
1.27.0-nightly (2f2a11dfc 2018-05-16)がregressionしとる。
issueある。待つヨロシ。

>>427,473
the rust referenceのことじゃね？the bookとは別にあるだろ。
全然追いついてないよアレ。そもそもまだ仕様書がない言語だし。
" best-effort document"って書いてあるでしょ

487 ：
httpサーバでありかつクライアントであるみたいなプログラム書く場合、現状hyper一択なのかね？
acitx-webとか誰か使ってない？

488 ：
最初rocketで書いてたけどactix-webで書き直してる
今だとactix-webが一番良い感じだと思う
必要に応じて同期、非同期、アクターモデルと使い分けられるし

489 ：
>>488
良い感じか。使ってみるか。ありがとう

490 ：
https://github.com/rust-lang/rfcs/pull/2444
有志「クソ機能入ったのいらねえから消そうぜ」
大勢「いいな！賛成」
独裁開発チーム「もう入ったから消せませーーーーんwwwwww（クローズ&ロック）」

systemdかよって

491 ：
>>490
もう入ったから消せませんってのは横暴なようにも見えるがしようがないとも思う
一度入れてしまった機能をまた使えなくするとか、それこそ混乱するし…
そもそも何故impl trait を引数の位置にも書けるようにしたのかは確かに甚だ疑問ではあるけど…
引数の位置でジェネリクスとトレイト境界じゃなくてimpl trait じゃないとダメなケースとかある？
無いなら、warning出してジェネリクスとトレイト境界に書き直すように促すのが妥当じゃないかな？

492 ：
例があるけどすっきり書きたいみたい
https://github.com/phaazon/rfcs/blob/undo-universal-impl-trait/text/1951-expand-impl-trait.md

493 ：
こういうところでマウンティングとらないといけない辺り
言語（笑）開発チームとやらも内情はどうなってることやら

494 ：
たしかにどっちで書くべきかよくわからんくなった

495 ：
<T: Trait> foo: T
と
foo: &Trait
との比較で特殊なケースを除き前者の方が効率良いが
syntax上後者の方が簡単なので
初心者が誤って後者を使ってしまうケースがあった
これを防ぐためにimpl Trait および &dyn Traitを導入し
&Traitをdeprecateすることになった

496 ：
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

D49IO

497 ：
もう入ったから消せません
は正論

何故クソ機能の進入を許してしまったのか、どうすれば食い止められたのかについて追求すべき

498 ：
ジェネリクスの型変数って引数と戻り値の型を揃えるとかそういう使い方をすべきであって
Traitをimplした型を受け取るという意味ではimpl Traitを使うべきだと思う
ただimpl Traitを導入するなら1.0の時点で導入してて欲しかった

499 ：
こういうところでマウンティングとらないといけない辺り
言語（笑）開発チームとやらも内情はどうなってることやら

500 ：
javaのジェネリックスが理解できてないやつが多いだけ。

501 ：
Rust始まる前に終わったか

502 ：
始まる要素が欠片でもあっただろうか

503 ：
>>495
それはdyn Traitの実装理由であっても、
引数位置のimpl Traitを実装した理由の説明になってない

504 ：
fn foo(a: &dyn Trait)
と
fn foo<T: Trait>(a: T)
では前者の方がlightweightでは

505 ：
target/debug 以下に生成されるdepsとかbuildって何なの？
goとかにはないよね？
gtk-rsだと500MB消費しちゃうんだけど他のプロジェクトで使い回しとか出来ないの？

506 ：
>>505 環境変数CARGO_TARGET_DIRを指定してやれば再利用してくれるよ
ただ、vscodeのrustプラグインの何かがこの環境変数を考慮してないんで挙動がおかしくなったことがあるんで注意

507 ：
>>506
おお流石に出来たんですね

プラグインがおかしくなるのはrls側の問題ですかね🤔

508 ：
Rustと言えばcookpad。

509 ：
>>501
最近Rustの話聞かなくなったな

510 ：
HNはリリースの度に話題になってるけど

511 ：
日本の企業くらいだよ。
rustで書いてまっせっていうバカなアピールするのは。

512 ：
まあCloudflareも日本にリージョンあるしな

513 ：
>>511
泥箱って日本企業だっけ

514 ：
日本の企業って凄いんだなー

515 ：
wtftwっていうタイル型WM、設定ファイルまでrustで書くのどうなんだろ
設定ファイルはluaあたりが無難？

516 ：
>>513
いやもうなかったことにしたがってるじゃんw
それなのに変なのに付きまとわれてるっていう。

517 ：
>>516
「なかったことにしたがってる」というソースをプリーズ

518 ：
Dropboxのbrotliデコンパイラが昨日更新されてたから
24時間以内のホットな情報だ

519 ：
Rustが失脚すると得をする組織があるの？
どうしてそこまで情熱的にRustを貶すの？

520 ：
>>515 ざっとコンフィグファイル見たらXMonadのコンフィグよりは理解しやすいように思った
xmonad.hsはもっと宣言的に書けて、モナドとか上手く作って見栄えは良くできるんだけど、
馴染みのない演算子(<+>とか)使いまくるんで、よっぽどHaskellに慣れ親しんだ人でないと全容が理解できない

設定ファイルのフォーマットを開発言語と同じにするのはdwmから続くタイル型WMの流儀だし、
思ったより読めていいと思うよ。

521 ：
>>519
前段 モジラとその小判鮫以外の全組織が喜ぶ
後段 技術的にカスなものを貶すのは技術者の義務だろ

522 ：
>>521
>技術的にカスなものを貶すのは技術者の義務だろ
じゃあPHPではなく敢えてRustをdisる理由は？
あちらの方が広く使われてるからより害悪だと思うが

523 ：
>>520
ほうほう

524 ：
>>522
あれを使ってるやつも害悪性は理解してるからな。
こういう技術的にインテリな要素のある言語って信者がとにかく頑なで
実際のプログラムの現場で非常に問題になることが多い。

525 ：
ほーん具体的にどんな問題がおきたの？

526 ：
んー例えば
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる

527 ：
>>525
んー例えば
コンパイルが通せなくて自尊心が傷ついて自ら会社をやめちゃう問題とか

この話どこまで事実か知らないけど仮に本当だったとしても
これって言語の問題というよりチームのプログラマの腕を過大評価
もしくは計算に入れてなかったというマネジメントの問題だよね

528 ：
んー例えば
プラズマクラスター付き家電が話に出てきたら今まで黙ってたのに凄い勢いでエセ科学だと解説し出すよね

529 ：
いや、この粘着をクビにするためにRust導入したんでしょ
性格異常だもん

530 ：
老害をふるい落とすために新しい言語を取り入れてるって話？

531 ：
このフィボナッチ数列も書けないあほ
何度言い返せなくなっても数日後に甦る粘着性
C++で実行時にエラーが出るようなコードを書きまくったのでしょう。性格の悪さと溢れる自尊心から誰の耳も貸さなかったのでしょう。
プログラマーとして生きるよりかは、匿名掲示板で巨悪組織Mozzilaと闘うBBS戦士の方が社会的に良さそう

532 ：
たとえばドワンゴとかDropboxとか
Rustを採用した企業自体を叩く行為をよくしているよな
あれ見るとちょっと辛くなる

533 ：
>>526
具体的には？

534 ：
例えばここみたいに安全でもなんでもないドヤしたいだけのクソなrustコードが量産されるとか。
ttp://tanakh.jp/posts/2016-12-20-rust-pezy-sc.html

535 ：
だから具体的はどこが問題なの？

536 ：
槍玉にあげる例が1個しかないのがダサ過ぎるわ。しかもその例も対象が特殊だし

>>534は「それRustでやる意味がある？」という疑問に全く応えられないのが問題
LLVM IR-> PEZY-SCというコンパイラがあるんだったら、LLVMがバックエンドの他言語でもいいよねって話
それができないなら、LLVM->PEZY-SCは未完成か現実に即してないんじゃねえのって話

537 ：
rustでやってみたって記事にrustでやる意味あるの？って疑問が出てくるのが不思議なんだけど
rustでも出来た、以外に意味はないでしょう

538 ：
新しいこと覚えられないから焦ってるんじゃね

539 ：
>>534
安全じゃないコード　も　書けるってことに価値があるんだろ？
C/C++以外の他言語では書くことさえできない。でもC/C++は安全性を売りにはしていない
Rustは安全性を売りにしつつ、必要に応じて安全性を捨てる選択もできるということに価値がある
で、たまたまその記事が安全性を捨てることが必要な数少ない例の1つだったってだけ

540 ：
安全でもなんでもないって
unsafeあるやんけ！危険危険！
前後の文脈一切分からんけどとにかく危なそうなこと書いてあるやんけ！
つって叩いてるんだろうなｗ

>>535
その手の問いにそいつが素直に答えたこと無いからあきらめよう

541 ：
たまたまねw
どんだけコード例出しても言い出しそうだなw
そもそもコード例が少ない訳で、推進してる奴のコードがそんなもんなら
十分否定的な要素だけどね。

542 ：
grep出来ねえのか^^;

543 ：
ちょっとrustの記事書いただけで代表的な推進派扱いかよ

544 ：
>>541
お前さんの理屈だと、Rustじゃこんなに危険になる！って事だろ？
じゃあ、Rustではそういう危険な書き方しか出来ない！って示さなきゃな。
俺は中立だが、あんまり非論理的なdisりはアンチ＝低能と思わせたがってるピエロにしか見えんよ。

545 ：
既に20万行はコードあるからレビューがてら指摘したら喜ばれるよ

546 ：
>>541
ほんとだどこが問題で悪いのか全然書かない
具体的に言及しだすとフィボナッチ数列とか機械語レベルとか、残念なことになるのが自分でもわかってたのか

まあ本人が書いた通り「ドヤしたいだけ」とか…なんかな？前もマウンティング取られたとか訴えてたし…

547 ：
#[no_mangle]
pub fn _Z8pzc_vadd(a: *const f64, b: *const f64, c: *mut f64, n: usize) {
    let tid = (get_pid() * get_maxtid() + get_tid()) as isize;
    let threads = (get_maxpid() * get_maxtid()) as isize;

    for i in (tid..n as isize).step_by(threads) {
        unsafe {
            *c.offset(i) += *a.offset(i) * *b.offset(i);
        }
    }
    flush();
}
まあこういうコード見てもアホかこいつと思わん連中なら話してもしょうがないしな。。
やっぱrustスゲーわ。

548 ：
またいつもの、ボロクソにされたらしばらく潜伏してから復活するパターンかな
たまには芸風変えたら

549 ：
Rustの不満は言語仕様やrustcよりcargoやその辺の連携(情報の少なさも含む)にある

550 ：
既成のクレートを探すのはcrates.ioになると思うけどライセンスってどうやって調べるんだろ
同様にクレート間の依存関係も判りにくい
どちらも一式を落としてきて中身を確認しないと判らないような・・・

Cargoで自動ダウンロードして・・・みたいな使い方をしていると意図せずGPL/LGPLになっていた
みたいなライセンス事故が起きそう

551 ：
>>550
$ cargo install cargo-lichking
$ cargo lichking check

一先ずlichkingでチェックできるよ

552 ：
LGPLのstatic linkとかやめて欲しいよね

553 ：
>>551
えぇー・・・わざわざインストールしないと出来ないのかよ。とりあえずやってみるか
依存関係はどうすりゃいいんだ？no_stdでも使える奴だけ探したいとか

554 ：
>>553
ライセンスをついては、crate名が既知なら、

ttps://crates.io/api/v1/(クレート名)

でjson取れるので、そこから再帰的に依存辿れば収集はできそう

555 ：
>>553
no_stdかどうかについては、Cargo.tomlのcategoryパートに"no-std"があるかどうかぐらいしか確認するすべなさそう(2017-2-10に追加されたっぽい)。

皆が皆付けてるとは思えないので、参考程度にしかならないだろうけど。

556 ：
ちょうどいい機会だから、カーゴのギフハブべったり依存をやめて抽象化してほしいわん

557 ：
は？

558 ：
crates.ioべったりは分かるけどGitHub依存って何

559 ：
goと勘違いしてるのでは

560 ：
rustダメじゃん
firefoxは言語オタに支配されたのか？

【IT】高速化を進めてアドオンを排除したFirefox、ついにシェアが１０％切る★2
https://asahi.2ch.sc/test/read.cgi/newsplus/1528388348/

561 ：
FirefoxのシェアでRust叩きって前スレでもやったじゃん
http://mevius.2ch.sc/test/read.cgi/tech/1507970294/100-

562 ：
？
前やったから何？

563 ：
なんで筋の通らない批判を平然とするのか不思議

564 ：
>>562
ええ…？FFアドオン排除でRustディスは気にならないのか
以前の試みはアドオンとRustを絡めてみた感じだったな
↓のレスをいつものごとく無視し数日潜んでRust叩きを試みていたけど、スレを跨いで同じ材料出すなよ


109 デフォルトの名無しさん sage 2017/11/15(水) 14:21:13.24 ID:FBksKtwj
>>108
失敗してるやん
Rustなんかで書き直したせいでアドオン全滅してる

114 デフォルトの名無しさん 2017/11/15(水) 14:36:17.78 ID:bBOLEH2G
>>109
それは設計の段階で従来のアドオンとの互換性の一部を捨てるように仕様変更したからだよ。
firefoxのアドオンは自由度が高すぎるが故に、セキュリティに問題を抱えやすかったし、
アドオン同士が衝突して落ちるとかも結構あったから、そこら辺をChromeと同レベルくらいに制限して、
セキュリティと安定性を取る方向に方針転換した。
仕様が変わってるんだから、Rustで書こうが他の言語で書こうがどっちにしろ従来のアドオンの一部は動かないよ。

565 ：
今回は1週間も我慢できなかったのか
ほかに行く場所ないの

566 ：
>>556の話だけど、
>>556はhg使えなかった時代で止まってんじゃないの？

567 ：
>>566
gitとgithubはちがうよ？

568 ：
キチガイ帰ってきてよかった

569 ：
相変わらず宗教じみてんな

570 ：
何でio::Errorにファイル名入ってないんだろう？　不便だなーと思ってたけど
検索してみたら、前は入ってたのに1.0リリース前に削除されたんだとさ

https://internals.rust-lang.org/t/add-filename-information-to-io-error/

571 ：
>>570
非効率になるのを嫌ったってことみたいですね
stdでもつには重すぎるってのは理解はできるけど　確かに不便なんだよなー

自分は結局
ioの関数呼ぶ前にinfo!でログ出すとか
戻ってきたio::Errorをmap_errでPathBuf埋め込んだ自前のErrorに変換するとかしてます

572 ：
>>571
ここで紹介されてる、failureを拡張して let file = File::open(path).with_path(path)?; と書けるようにするのが
カッコいいなと思った
https://github.com/rust-lang-nursery/failure/issues/189

failureは1.0に向けてまだまだ変えていくみたいだし、これ書いた焦げ寿司氏も参加するみたいだから
期待してるわ
throw!マクロが標準化したら、?の時みたいにrustプログラムの見た目変わりそう

573 ：
2回もpath書くの全然かっこよくないから、少し重くてもなんでもいいから便利なライブラリがあれば使うわ

574 ：
トレイトオブジェクトってなんでトレイトオブジェクトって呼ぶん？
ようはヒープに動的に作られたストラクトだら？

575 ：
何らかのTraitを実装したオブジェクトだから、じゃ駄目なの？
変に勘ぐって誤解してるよ。スタックにある構造体でもトレイトオブジェクトになる

576 ：
うーんここにはそういうニュアンスでは書いてない気がするんだけどなあ
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/trait-objects.html

577 ：
traitってなんだよ

578 ：
>>577
特性

579 ：
わかんねえよw

580 ：
traitは写像の集合で本来的には定義域の集合でないものなので、それとして扱う場合を特別にトレイトオブジェクトって呼んでるんじゃないの？

581 ：
>>576
ヒープにある構造体である、とはどこにも書いてないよね

複数の異なる型を同じ関数や構造体で持っておきたいけど、
型が違うからコンパイル時にサイズが決まらないんで困ったねって状況を解決するのがトレイトオブジェクト
そういう事態じゃなければfn foo<T: TraitFoo>(obj: T)とかやって型毎に関数をコンパイラに作ってもらうのが普通

582 ：
マス科の淡水魚じゃなかったけ

583 ：
それはトラウト
トラウトサーモン。

584 ：
なんらかのトレイトじゃなくて特定のトレイトを実装したなんらかの型ってことかな

585 ：
D言語の再来と言われるRustには注目しています。

586 ：
さすがに「C#とか糞wwこれが俺の考えた最強言語ww」→「結局C#が全部正しかったですｻｰｾﾝww」で終わったただの中二言語と一緒にするのは失礼

587 ：
そうだな。D言語に失礼だ

588 ：
C#に、な

589 ：
まるでD言語が死に絶えたみたいな口振り

590 ：
え？とっくに死に絶えたでしょ

591 ：
>>572
1.0待てなくてもう現行のfailureにどっぷり浸かっとる。
failureはいいぞ！

592 ：
D言語は最近顔本コミットを受けて活発化してる

Rustは採用企業が全く増えなくなって資金も枯渇
メインコミッタもリンゴのSwiftやらにヘッドハントされて
もう将来ないでしょ

593 ：
もちろん言語のエコシステムとしての将来がないってだけで、
ライフタイムとかの実装系の先駆としての意義はあったとおもうが

594 ：
終わってみればdartの舞の海だったな。

595 ：
なんで急に元力士の名前が出てきたんだ？
二の舞って言いたかったのか？

596 ：
>>591
なんかfailureのissues見ると、現状のstd::errorの設計は失敗作扱いみたいだな
それって共通認識なんかな？

597 ：
Haskellかじってて、Rustに興味出てきたんだけど、なに、廃れつつあるの？

598 ：
廃れるもクソも、Rustが世間の注目を浴びたことなど未だかつて無い

599 ：
大丈夫、大丈夫。
ユーザーが年々すごい勢いで減っているDに比べりゃ
規模は小さいもののRustは年々少しずつ増えてるわけだから
今後普及するかどうかはともかく少なくとも廃れちゃいないし、
学習コストが高いから敬遠されてるだけで注目もされてる
それにHaskellと同じで勉強しといて損はない言語だと思うし

600 ：
そもそも普及を目指してるような気配もないよな
バッテリ同梱などと言い出しもしないばかりか
randすらクレイトになってるから
rustcだけで楽しんでると涙目（´・ω・｀）になる

601 ：
Dのユーザが減ってRustのユーザが増えてる世界線はどこにありますか？

602 ：
別に趣味でやってりゃいいんでないの。
ライフタイムとか所有権の感覚は他言語でも役にはたつでしょ。

603 ：
wasm やるなら stdweb と wasm-bindgen のどちらを使ったらいいですかね?
もしくは他の選択肢の方がいいとかありますか?

604 ：
>>596
std::error+error_chain/log crateの問題点を
解決するためにfailure/slog crateが
作られたからだいたいそんな感じだと思う。
failureの方は今nurseryだし。

failureのエラーとstd::errorのエラーを相互変換できるから
移行や依存ライブラリがstd::error使ってる場合に対応簡単だよ。
まあ、1.0待ったほうがいいけど。

605 ：
>>603
wasm-bindgenはhost bindings proposalの実装でstdwebはweb apiのrustバインディング。
host bindings proposalはWebAssembly用の(ホストとの)ffiみたいなもん。

606 ：
>>603
stdwebベースのyewとか面白いよ
Reactっぽいことが出来る

607 ：
>>605
>>606
レスどうもです
host binding（wasm-bindgen）が後発で
cargo-webがあるstdwebの方が開発サイクルが楽そうという感じがしてます
yewも見てみます

608 ：
>>604
stdの下にあるけど非推奨、みたいなのが今後だんだん増えてくるのかな

609 ：
はよRust4.0くらいにならんかな

610 ：
>>608
使ってはいけない標準ライブラリとかC言語のgetsかよwwwww
21世紀の言語とは思えねえなwwwwwおもちゃもいいところwwwwwww

611 ：
きたきたw

612 ：
テンション高杉wwww

613 ：
愛され言語ナンバーワンに2年連続で輝いたのに人気ない扱いは意味不明だ

614 ：
>>613
純粋に聞くがお前の周りでRustサイコーって言ってるエンジニア何人いる？

615 ：
標本数1～2のデータよりこれ見ません？
https://insights.stackoverflow.com/survey/2018/#technology-most-loved-dreaded-and-wanted-languages

616 ：
>>614
2/6人かな

617 ：
>>615
いくらでも組織的に水増しできる問答や投票になんの意味が？

618 ：
>>616
その程度の言語が世界一位って統計的におかしいと思わん？

619 ：
>>617
dreadedに水増ししたの？ｗ

620 ：
>>618
お前と匿名の一人で統計語ろうっておかしいと思わん？

621 ：
あとこいつ好感度と使用者の数をごっちゃにしてるの？凄いよそれは
フィボナッチ数列も書けないだけはあると思うよ

622 ：
フィボナッチ数列って円周率みたくいまもなお計算され続けてたりするのかな

623 ：
どう考えてもRustなんかよりJavaのほうが愛好家多いだろ
プロダクトの数考えろよ

624 ：
GithubではJavaScriptが一番多いからJavaScriptが一番愛された言語だよ(お前の中で)
この記事オカズに1年ぐらい黙れそう？
http://wolfbash.hateblo.jp/entry/2017/07/30/193412

625 ：
ハンバーガーはマクドナルドが世界一売上高いんだから、マクドナルドのハンバーガーが世界一美味いに決まってるだろ？

626 ：
>>618
なんで一つのサンプルで統計的にとらえるんだ？
プログラマー的におかしいと思わん？

627 ：
そういや何でmainが必要なんだろね

628 ：
Nimへの風評被害記事を貼るのはやめろ

629 ：
初見の人のために何度も貼るけど↓が本スレ

http://mevius.2ch.sc/test/read.cgi/tech/1514107621/

ここはキチガイと戯れるスレ

630 ：
>>624
それ>>8でオレが貼った記事な
このスレでも反論の余地の出なかった良記事。Nimについてはともかく
Rustのクソさについては本当によくまとまってる

631 ：
真正のアホだった

632 ：
だからさー。文句あるなら記事に反論してみなよ

取り下げられた記事以外誰も出せないまま人格批判だけとか全く理論的じゃないし
そういう人ばっかだよねRust信者って

633 ：
ここ本スレじゃなかったのか
お邪魔しました

634 ：
>>632
archive. fo/7NUr2
なんかある？

635 ：
>>634
だから取り下げられた記事は反論にならないって
本人が間違いだって取り下げたんだから

636 ：
>>635
読んでもねぇのに自分勝手に判断して否定するバカが
「理論的じゃない」とかよく言えたな

その言葉そっくりそのままお返しするよ

637 ：
>>636
自分勝手じゃないよ？
そもそも論を取り下げたのは向こうじゃん
取り下げられた論が議論の俎上に上がるのはおかしいでしょ

638 ：
ある人がどのレベルでプログラミングしてるか、という差がある
ある人にとってはプログラミングとは設計作業に他ならず
ある人にとってはプログラミングが指の労働でしかない

書き間違えるから、書き忘れるから、という理由でもって
しょうもないバッドノウハウを拝み続ける者すらいる
塩と砂糖を入れ間違う、塩を入れ忘れる、自称料理人
そーいうレベルのプログラマ

639 ：
クソ言語はRuで始まるの法則。
ソースはRubyｗｗｗｗｗ

640 ：
>>637
何故取り下げたかの理由も書いてあったがそっちのほうは完全に消えたかな…
アーカイブすら残ってなさそうだ…
「他の記事を貶めるような記事は品性が疑われるからやっぱり取り下げる」
みたいな理由だっと思うけど、どうせお前はそれも認めないんだろ…

………ふぅ………もういいよ……
お前の頭ん中ではRustはクソ言語で良いよ……

641 ：
まあ人気であることは否定できないし好きに言わせとけば

642 ：
Rubyスレいってこい

643 ：
>>637
そういう人だね
お前だけは確実に

644 ：
rustup update stable

645 ：
クソ言語に固執し続けるクソ人間

646 ：
1.27.0がstableになったんね

647 ：
rustは個人開発向けで仕事に使うものじゃないのね。

648 ：
ソースは？

649 ：
Cargo.tomlに対応するrustcの最低バージョン番号を書く方法ってある？

650 ：
ネタスレで質問するやつはキチガイ

651 ：
スレチ
Rustスレに行け

652 ：
キチガイがまともなふりして質問するふりするんだよなー

653 ：
>>649
https://qiita.com/tatsuya6502/items/8b31e2b162aff78787fe
プロジェクトフォルダにrust-toolchainファイル置いてその中で指定出来るみたい
toolchain指定なんでrustup必須になるのと固定指定しかできないっぽいけど

654 ：
みんな英語どうやって勉強したの

655 ：
>>654
受験勉強で

656 ：
>>654
俺は英語なら分かるんだけど、日本語はさっぱり分からん

657 ：
>>655
すげーな
オライリーのやつKindleで読んでるけどまず訳すのが大変だわ

658 ：
>>656
英語圏に生まれたかったと切に思う

659 ：
訳さず英語で読んだ方が…
情報の早さ・量・正確さが段違いだし原著読むと意外と難しい単語使われてない。
bind(bound)を束縛とかアホかと。
せめて結びつけとかにしろよと。
翻訳のセンス無さすぎ。
もしくはわざと小難しくして地位を守ってるのか…

660 ：
結びつけだとassociateの訳ともとれそう
英語と一対一で対応できる和訳の方があとから英語情報に触れるときのハードルを下げると思う

661 ：
>>659
get / put / take なんかで言い換えしたからといって、わかりやすくなったとは思わない

662 ：
それにしても～を～に束縛しますとかセンス無さすぎる。
明治時代の翻訳見習ってほしい。
漢籍の素養が必要だが…

663 ：
逆に聞くが「変数にbindする」って日本語にどう訳したら自然なんだ？「結びつける」は別の意味になるぞ

明治期のアレは翻訳っていうよりは対応する訳語を創出するって感じだから、単純な翻訳じゃないぞ

「縛りつける」みたいな感じになるしかないと思うんだが
束縛は単純に漢語にしただけで大差なかろう

664 ：
>>653
ありがとう
一応そういうのあるんだ
そのページの下に書いてある、edition 指定出来るようになるのを期待、という感じかな

665 ：
> 翻訳のセンス無さすぎ。

お前にはあるかのような口ぶりで

> せめて結びつけとかにしろよと。

↑こんなこと言い放ちつつも

> もしくはわざと小難しくして地位を守ってるのか…

束縛っていうふつうの単語を小難しく感じると白状し
地位を守るだのなんだのという珍妙な価値観まで丸出しにするとは恐れ入る

666 ：
まあ、英語のbindからして数理論理の変数束縛と同じ単語を別の意味で使いまわしてる
近い分野なんだから専門用語もう少し考えてくれても良かったのに

667 ：
慣れちゃってるから気づきもしなかったけど代入からして大概だよな。
英語だと単にassignだぞ。

668 ：
その点、グーグルは気が利いてて、
「錆は、安全性、スピード、並行性に重点を置いたシステムプログラミング言語です。
以前のバージョンのRustが錆びてインストールされている場合、」
だからな

669 ：
「バインドする」で良いのでは
traitとかcrateとか訳すとよくわからなくなるもの多いし全部カタカナでよい

670 ：
a に 1 を綴じます。

671 ：
タイプアノテーションのないバリアブルのタイプはライトサイドをエバリューションしたときのタイプになります

672 ：
是々非々だな。
型アノテーションのない変数の型は右側を評価したときの型になります
束縛するはバインドするでよかった。SMの趣味ないし。

673 ：
束縛と代入ってなにか違うんけ？

674 ：
誰に確認したわけじゃないが、変数に何か値を設定するのが代入で、値に名前を付けるのが束縛だという認識
fn foo(...) {...} は、ある関数に対しfooという名前をつけるので「関数をfooに束縛する」とは言うかもしれないけど、
「fooに関数を代入している」とは言わない、みたいな

675 ：
緊縛と挿入!

676 ：
単にイミュータブルかミュータブルかの違いでないの？

677 ：
>>674
伝統的な表現だと宣言に近いニュアンスかな

678 ：
rustはバインドしていない状態の変数も合法だからややこしい

let hoge;
hoge = 100; // これをコメントアウトするとコンパイルできない
println!("{}", hoge);

679 ：
初心者なんですが、文字列を作成して返す関数を作るときって、
fn hoge() -> String { "hoge".to_string() }
と書くものですか？
それとも
fn hoge() -> &'static str { "hoge" }
と書くべきでしょうか？

680 ：
その例だと関数にする必要なくない

681 ：
>>679
テケトーにググっただけ

つ https://qiita.com/Mizunashi_Mana/items/db88cb0bff002abce1ae

682 ：
Stringもstrも返す可能性があるなら Cow<str> で
それ以外なら使えるときは &str を使うのが良いのでは

683 ：
Stringとstrを両方残しちゃうあたり
優柔不断でグダグダな言語に思えてしまう

684 ：
はあ…？

685 ：
C FFIに関する技術資料ってどこにあるんだろ？
ttps://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/ffi.html
にチュートリアルはあるけどexternの記述方法とかがわからない
見よう見まねで書けなくはないけどそのまま行くのは事故の元だし
ついでにlibcが何をしているのかもわからない

686 ：
>>685
CのヘッダからRustのインターフェースを自動生成してくれる
bindgenを追っかけてみればよいかと
https://github.com/rust-lang-nursery/rust-bindgen

687 ：
>>684
せめて理論的に反論しろよグダグダ言語の信者

688 ：
>>687
ごめんなさい
論はどこですか？

689 ：
>>686
えぇ・・・ソース見るしかないのかよ・・・
リファレンスマニュアル見てもちゃんと書いてないんだよな
さらにググってもリファレンスマニュアルが引っかかってこない罠

690 ：
>>685,686
unsafeまわりの文書に入ってる（ただしdraft）
https://doc.rust-lang.org/nomicon/ffi.html
公式文書はgithubのorganization（rust-lang、rust-lang-nursery）から探している

691 ：
C言語ライブラリの関数を3回呼び出すコードと格闘すること数時間。ようやく動いた
まだ不明点は残っている
・#[link(～のkindが何を示しているのか判らない
　C FFIの使用例を見るとよく見るんだが・・・
・C言語配列の渡し方が不明
　元は
　>int p[]={16,9};
　>foo(p);
　とりあえず
　>foo("\x10\x09".as_ptr());
　などと書けばデータ上は整合するから動くけどどう見てもスマートな記述方法ではない
・文字リテラルの仕様が不明
　↑の表記を得るのに数回試行錯誤した

データの与え方もCStringを使った(＝\x00終端する)方法は出てくるけど、そうではない方法は
中々見つからなかった。結局↑の表記に落ち着いたが

>>690
ありがとう。kind値について書いてありますね。静的リンクだとkind = "static"らしいですが
付けても付けなくてもファイルサイズは大差ないようです。何が違うのだろう

692 ：
Cの配列は第一級の値じゃないからas_ptrが正攻法だと思う

693 ：
>>690によればFFIで使用できる物として
・#[repr(C付きのstruct
・#[repr(C付きのenum
・box？
・vec
・str
が挙がっているけどCと互換性があるのはこれらのみって事なのだろうか
vecを試してみたら動いたけどextern時に安全じゃないから#[repr(C)]付きのstruct使えなどと言いだした

>>692
マジかよ！確かに文字列は汎用性が高いけど可読性が良くない・・・必要に応じて抽象化しろという事か

694 ：
Rustの側では変更しないけどCの側で変更するような変数ってmutにしないと駄目よね？

695 ：
あっ、ヤベェ・・・いきなり重大なバグ出してら
×　foo("\x10\x09".as_ptr());
○　foo("\x10\x00\x00\x00\x09\x00\x00\x00".as_ptr());
こうだよな
標準で[16: i32, 9: i32]を"\x10\x00\x00\x00\x09\x00\x00\x00"に変換してくれるようなのが欲しい

696 ：
うわこれは読みたくないw
難しいもんだな

697 ：
ちなみに間違っている状態でも呼んだC関数は正常に終了します。まさにunsafeです。怖いです
何か対策を考えないと大事故を起こしそう
要素数2しかないのにstructを書くのはコード効率の点からも可読性の面からもあまり良いとは思えないし・・・
いろいろ試してみたら
>let p: [i32; 2] = [16, 9];
>foo(&p);
ならいけるようだ。コンパイラは何も言わないけどこの表記が適切かどうかは不明

Rubyだと
foo([16,9].pack("i2"))　#配列をint2個分の文字列(＝8byteのバイナリ列)に変換
とか書けるんだよなぁ。コストは安くないけど>>695みたいなポカミスは起こらない

698 ：
>>697
何がしたいかよく分からんが
何故にC側がintの配列なのにRust側では文字列を使おうとしてるんだ？
C側がintってことはRust側で対応する型はisizeだろ
(Cのintが事前に32bitと分かってる場合はi32でも可
同様に64bitだと分かっている場合は対応する型はi64)

つまり、Cで
int[] x = {16, 9};
なら、Rustで同じデータを表すものは
let x: [isize; 2] = [16, 9]; // let x = [16_isize, 9]; でもおk
って書けば良いはず

Rubyと同じように考えようとするから変なことになる
RustでFFIするならCと対応する型は何かを考えれば良い

699 ：
>>698
いや、isizeはまずいんじゃない？
例えばx86_64だとisize:64bit,int:32bitだし。
libcクレートのc_intならアーキテクチャ毎に適切なサイズになるから
こちらがいいかと。

700 ：
ついでに言うとFFIするときの型はプリミティブ型以外でも
とりあえずlibcクレートを探すといい。
まぁマイナーなアーキテクチャだと間違ってたりすることもあるから
確認は必要だけど。

701 ：
とりあえず仕返しにrubyスレ荒らそうぜ
http://mevius.2ch.sc/test/read.cgi/tech/1523954817/

702 ：
>>699
あれ？そうだっけ？
うかっりしてたゴメン

そう言えばCのintはポインタのサイズに合わせるんじゃなくて
アーキテクチャ毎に変わるんだったっけか

703 ：
調べたらCのintにRustで対応する型はisizeじゃなくてstd::os::raw::c_intだったわ
libcのc_intとの違いがよく分からん
対応アーキテクチャの数か？

704 ：
>>703
一応libcはno_stdでも動くというメリットがあった気はする。
逆にプリミティブ型限定でも依存ライブラリ増やしたくないならstdなのかな？

705 ：
>>698
あなたの言うとおりですが、そのような情報はどこをから得られるのか・・・
>>690等のFFIに関する資料に書いてあるようには見えません
std::os::raw::c_intも>>703を見て探してみたら
ttps://doc.rust-lang.org/std/os/raw/index.html
ここにあるのか

配列等の長さが変わる型のC互換性に関する情報もどこにあるんだろ
アドレスの連続性とメモリの確保が保証されている必要があると思いますが

706 ：
>>705
資料が少ないのはまだ普及してない言語では仕方がない
FFIとか皆が頻繁に使う機能じゃないようなものはなおさら
Cの配列とRustの配列は互換があるはずだけど
悪いがその情報をどこから手に入れたかは覚えていないし
信用されても困る(ついさっきも間違えたしね)
場合によっては資料探すよりソースコード読んだほうが早いことも多いし
根気良く調べるしかないとしか言いようがない
あとはFFIみたいなunsafe部分は出来る限り念入りにテストを書くとか

707 ：
>>705
arrayとsliceの連続性保証はここですかね。
https://doc.rust-lang.org/reference/type-layout.html#array-layout

708 ：
今のnightlyだとclippyビルド出来ないよね？
ビルド出来る最後のバージョンと、それをインストールする方法教えてください

709 ：
RustのABIについてはドキュメント増やすことはできるだろうけど
それ以前の問題としてCのABI知らないとFFIつらいのでは

710 ：
付き合ってくれてありがとう

まとめるとFFIで使えるのは
・#[repr(C付きのstruct
・#[repr(C付きのunion
・#[repr(C付きのenum　←条件付き
・box？
・vec　←非推奨？
・str
・array
・slice
・std::os::rawの中にある物
このへんで良いのかな
std::os::rawの中とarray、struct、union、strがあれば一通り出来そうか

711 ：
vecもas_ptr用意されているし非推奨と言うことはないはず
sliceにderefできるし

712 ：
IDが変わっています

vecの件
>extern {fn foo(p: &std::vec::Vec<i32>);}
>foo(&vec![16, 9]);
これだと
>warning: `extern` block uses type `std::vec::Vec<i32>` which is not FFI-safe: this struct has unspecified layout
>・・・
> = help: consider adding a #[repr(C)] or #[repr(transparent)] attribute to this struct
と言われ正常に動作しない。クラッシュはしないが実行結果がおかしい
>extern {fn foo(p: *const i32);}
>foo(vec![16 as i32, 9 as i32].as_ptr());
これなら問題ないようだ。奥が深い

あとC関数から帰ってきたアドレスをu32へ入れていたのをc_voidへ入れるようにしたら所有権で怒られて動かなくなった
同じコードでも型によって所有権の移動のしかたが違うのか

713 ：
RustのVec自体には確かCとの互換性はないはずだよ
ただし、Vecはsliceにderefが可能でsliceはCの配列と互換がある

vec![16 as i32, 9 as i32].as_ptr()
はVecに対してas_ptr()メソッドを呼んでるように見えるけど
(ドキュメントを確認すれば分かるが)実際にはVecにas_ptr()メソッドなんて定義されていない
as_ptr()はsliceの方に定義されていて、暗黙的にderefされてからas_ptr()が呼ばれてる
つまり上のコードは丁寧に書き直すと↓と同じ意味(のはず)
let vec: Vec<i32> = vec![16, 9];
let slice: &[i32] = vec.deref();
let ptr: *const i32 = slice.as_ptr();

714 ：
あとC関数の引数＆戻り値はmove（ポインターか実値）しないとだめじゃない？
&付けて参照渡しにするのはよく分からない、たぶん未定義動作じゃないかなあ

715 ：
>>708
clippyは最新のnightlyは**追ってない**けど常に開発中だから
ビルドできるバージョンは常に変わる。
自分の環境のビルドできる最大のnightlyに合わせろしか言えん。
常にclippyを使い続けたいなら環境の方をclippyに合わせないとだめ。

>>710
- cの配列はraw pointer
- 配列以外ならrepr(C)してメモリレイアウト合わせるか
- C側でopaque pointer定義してas_ptr
- 汎用ポインタはrust側は

pub enum Void;
type VoidRef = *mut Void;

- cのvoid*がrust側にほしいならlibcクレート
- VLAや不完全配列はrustnomicon読む

まずC abi覚えろ。

std140レイアウトならクレートあるぞ。

716 ：
Rustだけ覚えればいい時代はまだ来ない
C/C++の知識皆無では

717 ：
オライリーの訳本が8月に出るのね

718 ：
本が出る頃には内容が古くなってるやつだろ

719 ：
>>717
英語で出る分には多目に見たが、日本語で出るんなら出版社の不買運動だな
どこが訳すか知らんけど

720 ：
不買運動何人参加するの？大規模にやろうぜ

721 ：
英語なら多目に見るｗｗｗｗｗｗｗｗ

722 ：
>>713
ありがとう、そういうオチか。&で正常に動かないのも納得です
暗黙の変換って便利ですけど理解が浅いとハマる元だったりしますよね
不適切な入力を入れると自分が書いたつもりのコードとは無関係っぽいエラーを出して？？？になったり

>>714
#[link(name = "・・・")]
extern {
　fn func1(x: *const u8) -> u32;
　fn func2(y: u32);
　fn func3(z: &u32);
}
fn main() {
　unsafe {
　　let mut a = func1("foo.dat".as_ptr()); //C側でメモリが確保されアドレスが帰ってくる
　　func2(a); //アドレスを使って処理
　　func3(&a); //確保したメモリを解放
　}
}
これは動きます。u32をstd::os::raw::c_voidにするとfunc2のaで
>use of moved value: `a`
>= note: move occurs because `a` has type `std::os::raw::c_void`, which does not implement the `Copy` trait
そんな事を言われても困る・・・ついでにenumなので格納されているアドレス値の確認も面倒
usizeなら問題ない。ドキュメントが正しいならusizeはポインタのサイズらしいしこっちの方が楽かも

723 ：
訳本情報どこにある？

724 ：
てかrust覚えるなら普通にc++のスマポくらいは知っとかんとわけわからんだろ。

725 ：
今日発売の新しいrust本買った人いるのかな
評判良ければKindle出た頃に買おうかなと思うけど

726 ：
貧乏なのでPacktの糞本を$10セールの時しか買えない

727 ：
訳本amazonにあったわ
早速予約した

728 ：
オライリーの本って、オンラインに無料であるやつとおなじやなかったん？

729 ：
>>728
オライリーの原著は去年12月に発売、今年8月に訳本

今日発売された英語の本は公式ドキュメント(第2版)の印刷版
版元はno starch press

730 ：
>>722
他の人も似たようなこと書いてるけど、Cの配列は結局はポインタに過ぎないから
C側がポインタを求めれば、当然Rust側でもポインタを渡す

あと>>712の
>同じコードでも型によって所有権の移動のしかたが違うのか
は半分正解で半分不正解
正確には、型によって違うんじゃなくて、Copyトレイトをimplしてるか否かで違う
u32はCopyトレイトをimplしてるから所有権はmoveじゃなくてcopyされる
c_voidはCopyトレイトをimplしてないから所有権をmoveしようとする

The Bookちゃんと読んだ？読んでないなら一度きちんと通読することを勧める

731 ：
rustやるのにあったほうがいい前提知識ってどれくらい？
c++とhaskellがまともに出来ないときつい？

732 ：
そんなわけないだろw
どっちかてと根気が必要だ

733 ：
いや最低限c++のコンストラクタ、デストラクタの動くタイミングくらいは知っとかないと無理だろ。

734 ：
>>730
一応deriveでCopy(とClone)を実装すればいいらしいと言うところまでは確認しているのですが
１．std::os::raw::c_voidへ追加で実装できるのか未確認(できたとしてもモンキーパッチになってしまう)
２．別名の型を新規に作る(usizeもしくはusizeへのエイリアスに対するメリットが思いつかない)
なもんで問題なさそうならusizeで良いかなと・・・
というかCのライブラリを使うと>>722みたいなケースは良くあると思うけど他の人はどうしているんだろ
libcのc_voidもlib.rsを見るとstd::os::raw::c_voidと同じみたいだし同様の現象が起きそうです
ググると引数はc_voidを使って戻り値はusizeを使っているようなコードも出てくるしusizeが正攻法なのか？

ちなみにこのコードだとusizeを使ってもmutが不要の警告が出るんですよね。これもそんな事を言われても
困るのですが

735 ：
>>734
Cで確保したポインタ（特に○○ハンドルみたいなリソース）は普通はopaque structで受けると思う。
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/ffi.html#%E3%82%AA%E3%83%9A%E3%83%BC%E3%82%AF%E6%A7%8B%E9%80%A0%E4%BD%93%E3%81%AE%E8%A1%A8%E7%8F%BE

どちらかというと、func2の引数が参照渡しでなくて値渡しなのが問題では。
見た感じfunc2では借用して呼び出し後に返してもらえばいいっぽいけど。

736 ：
>>733
えーなんで？rust書いてる人の大半は知らないでしょ

737 ：
こりゃC++まだ覚えてない人はrustなんか勉強してる場合じゃないねｗ

738 ：
c++といってもRAIIとスマートポインタくらいで良いのでは
知らなくてもtrplなど読めばなんとかなるとは思うが
代数的データ型なども同様

あとは用途次第だけどFFIやるならCのメモリレイアウトくらいは押さえておいた方がよい

739 ：
そんないい加減なことでいいのだろうか？
ちゃんとC/C++一から十まできちんと理解した方がよいのでは？
それからじゃないとそこがいい加減でRustなんて本当に使えるようになったと言える？

740 ：
C++完全に理解した人間なんて世界中に何人いるやら

741 ：
Cはともかく、C++に時間を割く必要はないじゃろ

742 ：
むしろCすら知らないほうが変な先入観とか無くて所有権とかライフタイムとか素直に理解しやすそうな気もする

743 ：
必要という理由が分からない
言語なんて使いながら覚えていくもんでしょ

744 ：
>>739
RustはC/C++分かってないと書けない
→C/C++を分かるまでやる
→C/C++がわかってしまえばそもそもRustなんて不要だと気づく
→Rustを捨てる

745 ：
>>731
確かにC++とHaskellが出来きればRustの習得にはそれほど苦労しないだろうとは思う
ただ、理解できるまでにかかる時間量の問題であって、それがないとキツイってわけじゃない
むしろ、Rustの学習するためにC++とHaskellを先に学習するとか時間の無駄
The Bookが懇切丁寧に解説してくれるので前提知識はなくても全く問題ないと思う
ただし、Goみたいな言語と違ってサンプルコード読めばある程度理解できて
何となくで書けてしまうような言語ではないのでThe Bookの熟読は必須
それと、FFIする場合はある程度のCの知識は必要だよ

746 ：
FFIしたいけどCは知らん、とかレアケースだから
そんな心配はせんでいい

747 ：
別にRustは大して関数型言語じゃないし、Rustのために他の関数型言語から、っていうのは本末転倒すぎるな

748 ：
全然モナドってないし、関数型言語フレーバーぐらいでしょ

749 ：
C++は速いがコーディングストレスで禿げる
Rustで若干のパフォーマンスを犠牲にしてでも、いかに毛髪を守れるかがテーマ

750 ：
>>749
C++程度で禿げてたらRustのコンパイル通らん

Rustのコンパイル通せるならC++でやる方がよいコード書ける

つまりRustは実用にならん。C++er養成ギプスって話ならわかる

751 ：
結論： やっぱりC++からしっかりやったほうがよい

752 ：
>>751
違う違う、そもそもRustは不要って結論な

C++勉強してC++そのまま使い続ければいい

753 ：
C++98
C++03
C++TR1
C++11
C++14
C++17
C++20
C++23
C++26
C++29
C++32
C++35
C++38

754 ：
なんだコンパイルできないおじさんか。。

755 ：
>>747
単純に最初期のRustコンパイラはOcamlで組まれてたからって事情でないの

756 ：
>>750
C++より潜在的なメモリ管理バグを減らせるってのは十分有用な話では

757 ：
リストとリスト操作をなんで組み込んでくれなかったのかな？
::とか@とかあるだけでだいぶ捗るよね（一部の人にとって）

758 ：
パフォーマンス面だけで言えば、リンクトリストは問題外だからじゃない？

759 ：
コンパイルできないおじさんのコードもNLL有効にしたらコンパイルできたから
来年にはrust書けるようになるよ

760 ：
別にどの言語だろうと所有権を考えるってのは普遍的に必要だとは思うぞ。
rustだろうとc++だろうとはたまた動的言語でもメモリ以外にも資源管理なんて
問題はどこにでも出てくるわけで。

761 ：
consとかが使えないのはmutとの兼ね合いもあるんじゃないの
あれ完全にイミュータブルリスト向けだもんよ

762 ：
https://www.reddit.com/r/rust/comments/8ub964/microsoft_announces_using_rust_to_build_some_of
MSもRust使ってるんですか
やるしかない

763 ：
>>735
なるほど。c_voidの正体はそれでしたか

引数は既成Cライブラリの仕様なのでなるべく変更したくありません

*mutを使うコードを検討していて気がつきましたがRustの生ポインタにfunc1が返すアドレスを入れると
Cと同じ危険を抱えますよね。func3でアドレスがNULL=0になりますからその後に触ると当然クラッシュします

764 ：
NLLいまだに理解できなくて使えない

765 ：
>>762
actixとactix-webのメインコントリビュータもよく見ると普通にMS所属の人だった
ttps://github.com/actix/actix/graphs/contributors
ttps://github.com/actix/actix-web/graphs/contributors

766 ：
MSは英語なので、大目に見てもらえる

767 ：
> Please never sell Rust to Microsoft!

ちょっとわらった

768 ：
言語に関してはMSがオーナーになるのは大勝利だろ

769 ：
ではここからはC# おじさんどぞー

770 ：
MSには新しいプログラミング言語のQ#があるから

Q# 【量子プログラミング】
https://mevius.2ch.sc/test/read.cgi/tech/1513059627/l50

771 ：
汎用言語でないからRustと競合はしないな

772 ：
Visual StudioでRustサポートされないかな
rlsが不安定すぎるのでMSが作り直して欲しい...

773 ：
rlsもracerもポンコツよね
あんまり力入れてないのかな

774 ：
intelliJ使えばええやん
インテリじゃない人もタダで使えるよ

775 ：
支援機能だけ考えるとそうなんだけどさ
手に馴染んだemacsから離れるのは簡単じゃない

776 ：
ワイもIDE使いこなせない

777 ：
intellijをつかうのです…
vsなんかよりよっぽどいいですよ…

778 ：
>>764
従来のborrow checkerの制約が緩くなるだけだから従来の理解してれば不自由なく使えるはず

779 ：
intelij買ったけどemacs使っちゃうのよね。コード書くのにmouseが必要になるのが受け付けないみたい。

780 ：
intellijちゃん自力でパースしてるのアホでしょ
CLionもclang使わず自力でやってるけどリリースから随分経つのに初歩的なバグ残ってるみたいだし

781 ：
>>735の方法だとこんな感じなのかな
enum ABC {}
#[link(name = "・・・")]
extern {
　fn func1(x: *const u8) -> *mut ABC
　fn func2(y: *mut ABC);
　fn func3(z: &*mut ABC);
}
fn main() {
　unsafe {
　　let a = func1("foo.dat".as_ptr()); //C側でメモリが確保されアドレスが帰ってくる
　　func2(a); //アドレスを使って処理
　　func3(&a); //確保したメモリを解放(以降aを触ってはいけない)
　}
}
中身にアクセスしたいならenumを#[repr(C)]付きのstructにして構造を定義すればいいのかな
読み書きするRustのコード全てをunsafeにする必要がありそうだけど

782 ：
英語は多めに見るおじさん、今頃rustについて必死で勉強して弱点探してるのかな

783 ：
>>781
func1とfunc2は関数プロトタイプがわかるけど
fn func1(x: *const u8) -> *mut ABC; → ABC* func1(const char *x);
fn func2(y: *mut ABC); → void func2(ABC *y);
fn func3(z: &*mut ABC);に相当するCのプロトタイプはないよね？

784 ：
func1のxはu8だからunsigned charかuint8_tだね

785 ：
>>783
func1の引数はRustのコンパイラにその型を使えと言われたから
func2の引数はfunc1の返値に合わせた
func3の引数はfunc1が返したアドレスが格納されているアドレス。Cで言うポインタのポインタでABC **z
自分も詳しいわけではないので勘違いしているかもしれないが一応動いている

786 ：
>>785
ダブルポインタだったのか
それならvoid func3(ABC **z); → fn func3(z: *mut *mut ABC);

let mut p = func1(...);
let pp = &mut p as *mut *mut ABC;
func3(pp); // 単にfunc3(&mut p)で大丈夫なはず

787 ：
ダブルポインタはあんま想定してなさげな気はする。
俺だったらもう一枚、インターフェイスかましてもう少し楽なインターフェイスにしてから
rustと繋げるわ。

788 ：
結局C/C++ある程度わかってないと話にならないよね。
経験ないやつはいきなりrust勉強してる場合ではない。

789 ：
コンパイルできないならまずプログラミングを勉強しなおしたほうがいいよ

790 ：
FFIの話をrust全体の話に主語をでかくしてるおっさんがおるな

791 ：
FFIもrustの魅力の一つなのですが？
C/C++知らないやつはいつまでたってもrustを全て分かったことにならない
半人前のまま
別に必要なとこだけ使うスタンスでもいいけど半人前のクセにいっぱしのrustプログラマーヅラしないでね

792 ：
昔はアセンブラ知らずにC++語るなとか言われてたが時代は変わったもんだな

793 ：
結局どの言語を選べばいいのかわからなくなった
C++？Go？

794 ：
Coqを選べばいいと思うよ

795 ：
目的に合ったもの
やりたいものをやればいい

796 ：
迷うならGoでいいんでは。

797 ：
Prolog

798 ：
rustを視野に入れながらgoという選択はない
kotkinかswiftかgoかってなら分かるけど

799 ：
分からないなら無理してrust使わなくていいって意味じゃろ

800 ：
腐ってないでお前らも俺と一緒にRustで競技プログラミングしようぜ！

https://yukicoder.me/submissions?submitter=5971

801 ：
クロージャで再帰が出来ないのって所有権的な問題？

802 ：
rustは競プロには向かない
https://users.rust-lang.org/t/rust-for-competitive-programming/17682

803 ：
クロージャの再帰ってこれのこと？

recursion - Is it possible to make a recursive closure in Rust? - Stack Overflow
https://stackoverflow.com/questions/16946888/is-it-possible-to-make-a-recursive-closure-in-rust

804 ：
>>803
おー、できた
ありがとう
ローカル関数だと外部変数キャプチャできないし、クロージャだと再帰できないし、
同時にしたいときどうすんのかなーって思ってたから
そんなに使うこともないだろうけど、心に留めときます

805 ：
>>786
ありがとう。なるほどそういう書き方もあるのか。確かに書き換わるので&mutの方が適切ですね
欲しいのはアドレスなのだからと単にアドレス演算子&を付けていました

unsafe外から任意のアドレスにあるデータへアクセスするにはその部分を関数化するようなのかな
一般的に言うプロパティの読み書きをプログラマブルに出来れば綺麗に書けるけど無理なんだろうなぁ
()無しの関数呼び出しとも言えるけどこれが出来る言語は少ない

806 ：
相変わらず驚き最大の言語だな

807 ：
>>806
例えば何に驚いてんの？
Rustの目的はシステム言語だが、目的から乖離してるとこって何？

808 ：
マルチパラダイムの場合、驚き最小の原則の法則に反するかどうかは実装者の責任じゃないだろうか

809 ：
抽象的なことしか言わなくなったんだよ
機械語のレベルと相性が悪いし

810 ：
>>808
半分はその通りだが、それならc++で良くね？になるぞ。

811 ：
日本語でこんなに議論が行われてることに驚いた

812 ：
恥ずかしくて外国人には見せられない掲示板だ

813 ：
そもそもcの呼び出しはメモリ管理モデルのギャップがあるんだから
どうあがいてもc++のが簡易にできるのは当然なんだよ。

814 ：
>>811
このスレは英語推奨だぞ

815 ：
>ローカル関数だと外部変数キャプチャできないし、クロージャだと再帰できないし、
ここに関してはクロージャでないものをクロージャと呼ばなければ誰も驚かなかっただろうな。
javaは似非クロージャのことはラムダ式と呼んでるし。

816 ：
Haskellの「外側のシンボルを参照することによる暗黙的な部分適用」はクロージャと呼ばれてるから
アレが許されるなら少なくともJavaのはクロージャと呼んでいい

817 ：
>>816
javaのアレは元々クロージャ導入するつもりが、
仕様と実装でクソ揉めて妥協案としてクロージャ
じゃないものとしてラムダ式を作ったんやで。
だから意図的な"クロージャではないモノ"よ。

メモリ管理にgc使うからエンクロージャの束縛の解放に
制限ないから実質クロージャだし第一級関数だけど。

818 ：
hyper使って簡単なwebアプリ描いてみたけどわりと素直に書けるのね

819 ：
>>804は本当に満足してるのだろうか
>>803のやり方だとパラメータ増えてるじゃん
こういうのは既存のシグネチャに合わせられないと
単にひとつの関数を小洒落た書き方にしてみましたってだけにしかならないのでは

820 ：
連投になって申し訳ないが、環境をRefCellで持ち出す例を見つけた
ttps://wandbox.org/permlink/hkwccgD2oXp0fTm7
組み合わせて、802の2番目の例のstructを更にRefCellに入れたらシグネチャ変えずに行けるかな

821 ：
>>819
一応満足してるよ
スッキリ書けないことがわかったから、素直にループで書くか、ローカル関数作って引数で渡そうと思えた
Rustは関数型じゃなくて手続き型だし、特に不満ではない

822 ：
>>820
RefCell使うなら、Rustで書く意味ないだろ

823 ：
>>821
すまん、クロージャでないとできない用途(環境をキャプチャーして高階関数に渡す等)を想定していると
勝手に気を回してしまったみたいだ

824 ：
クロージャじゃないとできない用途って具体的にどういうものなの
想像つかなかったので単純な興味本位

825 ：
例えば最適化ライブラリなどに目的関数を渡す場合などで
引数以外からパラメータを注入する必要がある場合。

826 ：
>>823
キャプチャ自体はクロージャで出来るから別に困ってないかな
たまたま再帰させたくなったときがあっただけだから

827 ：
クロージャじゃなきゃできないことじゃなくて、
クロージャの再起呼び出しじゃなきゃできないことを聞きたかった
引数以外のパラメーターを差し込む場合、普通は再起は必要ないよね

828 ：
風雲再起ぃ～！！

829 ：
1.28はrustdocするときソースコードのlintするようになったんの？
deny属性に違反するソースコードがドキュメント生成時にエラー投げる。

>>823
クロージャがある言語は普通、関数とクロージャ区別しないからその感覚はおかしくないと思う。
でもクロージャの実装上の制約とかライフタイムとかでループで書いたほうがいいと思うコードはある。

830 ：
>>827
それは、てっきり最初の>>801がキャプチャと再帰を同時に使いたいことがあったんとばかり

831 ：
>>827
ある種の動的なtree構造に対して探索、実行を繰り返すとか。。
やっぱ具体的じゃねーな。。

832 ：
最近rustの勉強始めたものです
この言語ってstatementなのかexpressionなのかをどういう方針で決めてんでしょう？
ifがexpressionなのはわかったけど、letはなぜstatementなんだろ？
他の関数型言語のようにexpressionでもよかろうに、と思った

833 ：
KCX

834 ：
古いCで良く在る if ( (let a = f()) != 0 ) {} みたいなのが嫌だったんだろう。
そもそも、変数束縛が値を持つ必然性は無いよね。

835 ：
>>834
あ、ごめん。大嘘だった。
if let なんてのあったのね…

836 ：
他の関数型言語のletは随分来歴が違うイメージ。
let x = ... in expはラムダ式の糖衣構文の一種なので関数型なら容易に実装できて便利に使えるのに対し、
rustのletは手続き型の変数宣言の方が近い

schemeのletとdefineが全然意味が違うのを知ってると違和感無い

837 ：
>>832
この辺読めばいいかと。
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/functions.html#%E5%BC%8F%E5%AF%BE%E6%96%87

letは所有権移動だけど、返り値を認めちゃうと
束縛先と返り値のどちらに移動すべきか分からない、ということかな。

838 ：
>>837
それは let a = (let b = c) がだめな理由にはなるけど
>>832の言ってる関数型言語風の let a = (let b = c in d) がだめな理由にはならないよね

839 ：
えっ、毎回コピーすんの？
それ無駄じゃね？

840 ：
>>838
ブロック式で let a = { let b = 1; let c = b + 1; b + c }; と書ける
けどミュータブルな変数を書けるからコードが関数型言語風になるかどうかは書き手次第

841 ：
>>837
>>840

ほー勉強になりました
fnもいまいち釈然としないけど
もうちょっと読み進めてみます

842 ：
あるstructもとに任意のフィールドを追加した別のstructを定義することってできる？

843 ：
イテレータ系はみんなそれやってる
mapとかfilterとか、元のイテレータ＋変換・フィルター関数みたいな構造体を返してくる

844 ：
へー今気がついた
strはmutの有無にかかわらずRO領域に配置される
sliceはmutの有無にかかわらずRW領域に配置される
つまり今風のOS上だと
strをポインタ経由で書き換えようとするとメモリアクセス違反
sliceをmut無しで宣言した物でもポインタ経由で書き換えられる
リンカの設定にもよると思うけどマイコンなどで使うときは注意が必要そう

845 ：
えぇ…安全に使えないじゃん。キツツキに縛りつけてる意味ないじゃんrustの存在意義が…

846 ：
再現コードはよ

847 ：
unsafeの話でしょ
脊椎反射したいつもの人が見事に釣られている

848 ：
もちろんunsafe中の話です
fn main(){
　let s:[i32;2] = [10, 20];
　println!("s[0]={}", s[0]);
　unsafe{*(s.as_ptr() as *mut i32)=30}
　println!("s[0]={}", s[0]);
}
実行結果
s[0]=10
s[0]=30
これそのものが問題になるケースは少ないだろうけど
ROにいるはずと思い込んでいるとハマるケースがありそう

任意の場所に配置するアトリビュートとかあるのかな

849 ：
これのArrayのとこに書いてない？

https://doc.rust-lang.org/book/second-edition/ch03-02-data-types.html

850 ：
>>843
返すんじゃなくて定義したいんだけども

851 ：
>>842>>850
stackoverflowとリファレンスを見た限りstruct定義の入れ子はサポートしてない
https://stackoverflow.com/questions/23629201/nested-structs-in-rust
https://doc.rust-lang.org/reference/items/structs.html

852 ：
どうもありがとう。でもちょっとニュアンスが違う。

struct 2d {x, y}
struct 3d extends 2d { z }

で3dが2dのxとyのフィールドと独自のzを持つようなかんじ
マクロで出来ないか精一杯やってみたが出来なかった
元となるstructごとにマクロ作ればできるんだけどそれじゃ意味ないし

853 ：
設計見直したら？

854 ：
>>852
Rust Design PatternsにはDerefでやるのはアンチパターンだと書いてあるけど、別の似たようなサイトではお勧め扱いだった気がする
https://github.com/rust-unofficial/patterns/blob/master/anti_patterns/deref.md

855 ：
struct A {int size; char data[];}
みたいなのをRustから読み書きするインターフェイスを考えてみた
enum PTR {}
struct A {p:*mut PTR}
impl A {
　fn new(ptr:*mut PTR) -> Self {A {p:ptr}}
　fn get_size(&mut self) -> i32 {unsafe {*(self.ptr as *mut i32).offset(0)}}
　fn set_size(&mut self, n:i32) {unsafe {*(self.ptr as *mut i32).offset(0) = n;}}
　fn data(&mut self) -> &mut [u8] {unsafe{std::slice::from_raw_parts_mut((self.ptr as *mut u8).offset(4), self.get_size() as usize)}}
}
fn main() {
　let mut s:[u8;14] = [10,0,0,0,1,2,3,4,5,6,7,8,9,0];
　let mut x = A::new(s.as_ptr() as *mut PTR);
　println!("x.get_size()={}", x.get_size());
　println!("x.data()[0]={}", x.data()[0]);
　println!("x.data()[1]={}", x.data()[1]);
　x.set_size(7);
　println!("x.get_size()={}", x.get_size());
　x.data()[1] = 225;
　println!("x.data()[1]={}", x.data()[1]);
　println!("s[5]={}", s[5]);
}
実行結果
x.get_size()=10
x.data()[0]=1
x.data()[1]=2
x.get_size()=7
x.data()[1]=255
s[5]=255
美しくないコードだ・・・
メインのRustコードにunsafeを書きたくないので全てstructに突っ込んだらこうなった
dataはslice経由で比較的自由に読み書き出来るけど、sizeは任意のアドレスを挿している数値型の作り方が判らないので関数が2つに

856 ：
rustからrust-bindgenが吐いたC++のクラス使うのめんどくさいな

857 ：
ところで、全然話変わるんだけどさ、mutってどう発音してる？
自分は「むっと」ってよんじゃってて、なんか、かっこわるいんだけど。

858 ：
当然、「みゅっと」でしょ

859 ：
怒ってるのね

860 ：
鬼太郎のCVほっぽりだして産休に入るみゅ

861 ：
mjúːtəbl

862 ：
ミュート

863 ：
tanakhがrustのクロージャー再帰を望んでいる

https://twitter.com/tanakh/status/1015609559673475073

864 ：
そりゃ入れないほうがいい証左になるなw

865 ：
みゅう太

866 ：
>>863
いつまでtanakhなんてスパコン詐欺師を崇めるんだろうなこのスレの住人

867 ：
国内の会社は大目に見てもらえないから大変だなあ

868 ：
NEDOとかダメだろ

869 ：
「nvidiaの倒し方、知らないでしょ?オレらはもう知ってますよ」

870 ：
実際green500で倒してるんだからたいしたものだよ

871 ：
https://github.com/saschagrunert/webapp.rs

これいいね、Webアプリを完全Rustで作成

872 ：
WebアプリをRustで書くって、どういう需要があるの？
ラズパイみたいな環境？

873 ：
車買ったらムダにドライブしたくなるじゃん。すぐ飽きるのに。
あんな感じ。

874 ：
クライアントサイドとサーバサイドで同じコードが使えるって話ちゃうのん?

875 ：
同じ言語
だな
それはnode.js環境も同じだが

876 ：
期待できる点は速くて安全

877 ：
全部rustって需要はあんまりない気がするけど、サーバ側ならかなりマッチしてる

878 ：
webassebly

879 ：
サーバーサイド → Rust
クライアントサイド → Rust
ブラウザ → Rust
完璧じゃないか

880 ：
Yewのベンチマークって他に誰か取ってた？

881 ：
やたらノンブロッキングに拘ってるけど、それが本当に必要な人ってごく一部だよね
人気サービスの中の人だけ
普通はスレッド立てまくりで対応可能だし、たまに台数増やすだけで問題ないでしょ？

882 ：
だからそれは並列性が必要ってことでしょ

883 ：
真のアイルランド人はノンブロッキングなど必要としないｗｗｗ

884 ：
アイルランドいつ統一するん？

885 ：
オライリーの奴予約した

886 ：
>>885
白紙の未来を絶望に染めてやろう。

あれもうかなり古いぞ。
rust 2018で今よりさらに変わるんだぞ。
エラーハンドリングもモジュールもTraitも重要な部分全部かわるぞ。
nightlyで結構実装済みだから現行のnightlyですら違うぞ。
macro 2.0はいいぞ！

887 ：
この仕事してるならそんなの普通じゃん

888 ：
>>886
Rust 2018にエラーハンドリングの変更とかあったっけ？
Rust 2018での追加・変更って"module, impl trait, Generators/async/await, macros 2.0, NLL, SIMD"だけじゃなかったっけ？
もしかしてdo catchがstable化されるの？それとも、それ以外で変更があるの？
エラーハンドリングで互換性を崩すような変更があるならかなり痛いんだけど…

889 ：
https://github.com/rust-lang/rfcs/blob/master/text/2388-try-expr.md
2018からtryがキーワードとして予約される（catchは廃案）
editionが未完成だと実装できないから2018リリースにはきっと間に合わない

890 ：
RustもC++みたいに何年かおきに大きく変更されるの？

891 ：
こないだ1.0になったばかりな気がするんだが。仕事じゃつかえないな

892 ：
こないだってもう3年前だぞ
C++が仕事で使えるんだから使えるだろ
てか、Swiftなんてもう4でそろそろ5になるとか言ってるんだぞ
あれが仕事で使えるんだからRustなんか楽勝だろ

893 ：
swiftなんてappleのDSL

894 ：
C99勢が砦

895 ：
実際仕事で使っている人たちがいるのに使えないということは、別のところに問題があるのよ

896 ：
安定性以前にまともにfibが書けない言語だから仕事じゃ使えない

897 ：
突然の自己紹介

898 ：
>>50辺りの流れは何回見ても本当に秀逸

899 ：
車輪の再発明を抑止し過ぎるとnode.jsみたいになるからね
やり過ぎはだめってことよな

900 ：
どゆこと？

901 ：
たかだか一行二行のプログラムのnpmパッケージであふれ、しかも子孫含めた被参照ダウンロードが100万とかざらで、さらにそれがバグっている。

902 ：
Rust関係ないけど最近ArchLinuxのAURに細工されたパッケージが上げられててほんのちょっとだけ話題になったんだけど

正直自分が使うcrateやそれの依存関係まで含めて全部書いてる人が信用できるかとかソースまでチェックしてる人なんていないよね…？
イカンなぁと思いながら盲目的に使っちゃってるわ(´・ω・`)

903 ：
CPUのL2キャッシュを作った人の叔母の恋人がテロリストがどうか気にするところから始めたほうがいいな

904 ：
某ファイルシステムの作者が奥さんを殺してしまってな

905 ：
怖いなぁ、戸締まりすとこ…

906 ：
そういえばRUSTという殺し合いをするゲームがありますね

907 ：
crate以前に詐欺企業Mozillaが信用できないから

908 ：
Mozillaが詐欺企業なら、Mozilla以上に言う事やる事がコロコロ変わるAppleや
個人情報を収集しまくりのGoogleやMicrosoftはどうなってしまうんだろうなｗ

909 ：
> 仕事じゃ使えない

おじさんのことじゃん

910 ：
crates.ioを見に行かないようにして、社内で確認済みのcrateしか置いてない社内リポジトリだけ
参照するような設定って出来るんだっけ？

911 ：
RFCはあるみたいだけどまだ出来ないのかな
https://github.com/rust-lang/rust/issues/44931

912 ：
>>911
まだ半分も済んでないね

913 ：
>>910
cargoはそこらへん腐ってるから無理。
出来はするけどcrates.ioをクローンするツールの開発が
殆ど動いてないしクローンしてもそのローカルリポジトリを管理するツールがない。
ここらへんはoffline modeも絡んでくるけど、
どうせ欠陥機能作って廃止してまた作っての繰り返しでめちゃくちゃになるだけ。

914 ：
crates.ioのソースを持ってきてローカルに立ち上げてhostsで向ければ出来上がりじゃん

915 ：
cargoが便利コマンドすぎて、原始的な事がやりづらくなってる問題

916 ：
便利っつーかモジュラリティーの低い構造になってるだけだろ。。
バカ設計だわ。

917 ：
>>909
go使うよ。32bitsマシン以上向けならgoで十分だ。

918 ：
仕事じゃ使えないのは言語じゃなくてお前だって言われてるのに何故goが出てくる

919 ：
Rust使えないから

920 ：
Rust(が/を)使えないから
どっち

921 ：
にほんごむずかしいあるね

922 ：
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる

923 ：
「機械語のレベルと相性が悪い」が "All your base are belong to us" みたいに見えてきた
なんかもう根本的に解ってないなっていう感じからくる面白さがある

924 ：
モジラに職を奪われたおじさんと
そのおじさんの物まねをするおじさん達のスレ

925 ：
LLVMについていけないおじさん

926 ：
Cやアセンブラなどの低レベルな処理と連動する場合unsafeを使わざるを得ないが、言語の仕様上普通に書くとunsafe祭りになってしまい
ソースコードの可読性が低下するのが残念。抽象化したくてもこれまた仕様的に完全な抽象化が出来なかったりするし

927 ：
gcが有って良いならgo。 ない方が良いならnimってことか

928 ：
まだ学習し始めたばかりでみんなが何を言っているのかよくわからない。

929 ：
どいつもこいつも適当なことをそれっぽく言ってるだけだから気にしなくておk

930 ：
ここはアンチの溜まり場だよ

931 ：
今日は本物がいないな

932 ：
>>927
一体いつからNimにはGCがなくなったんだ…？(困惑)

933 ：
>>931
狂人の真似をすれば実際狂人
つまりみんな本物のRustに職を奪われたおじさんなんだよ

934 ：
https://nim-lang.org/docs/gc.html
RustはできないしNimも詳しくない専門性なしのおじさん

935 ：
お前らもモジカスに親を殺されてみろよ

936 ：
バトー「つまり、本物の "Rustによる被害者" というのは最初の一人だけで、　
　　　　残りは全て模倣犯による狂言だったってのか？」

トグサ「ああ。狂言を読んだ者は初めのうちは怒りを覚える。
　　　　だが、その理不尽な怒りを抱えきれなくなると、
　　　　衝動的に自らが "Rustによる被害者" になりすますことで、
　　　　狂言によって植え付けられた怒りを共有しようとしていたんじゃないか」

バトー「実在しない "Rustによる被害者" たちが連鎖するってわけか……。
　　　　── 最初の一人はとうの昔に死んじまってるのにな」

937 ：
>>923
懐かしいなAYBか。文法エラーを直しても通じないのがいいよなｗ
"All of your bases belong to us."
"お前らの卑しいものすべては我々に首ったけ"
ヒドイｗ

938 ：
rustに職を奪われたおじさんなんて実際は存在しないわけだが。。
まあそういう人がいると思った方が幸せな人がいるのは事実。

939 ：
Rustに職を奪われたおじさんなんて名称なんてどうでもよくて
fibも書けない確かな"存在"がぐちぐち居座るせいで幸せになれない

940 ：
良かった。Rustに職を奪われたおじさんは居ないんだ。

941 ：
NLLがstabilizeされたらfibを書けないおじさんもfib書けるようになって成仏できるよ

942 ：
>>941
「fibを書けないアホ」が「木構造を書けないアホ」に変わるだけと予想

943 ：
rustでfibが書けたり、木構造が書けることをここまで自慢してくる輩って。。

944 ：
自慢も何もプログラマを名乗るなら最低限それくらい書けて当然だろ？ってこと
例えば、「俺は数学者だ」とか言ってる奴が微積分すら理解出来てなくて
「でも、因数分解ならできるし」とか言ってたら全力でぶっ叩くだろ？
つまりは程度の問題ってわけ
そして俺はRustでfibや木構造すら書けない奴はどうせ他の言語使ったって
ろくなコード書いてないだろうからそんな奴がプログラマを名乗るなんて片腹痛いわ！と思ってるだけ

945 ：
このスレに迷い込んだ新規にはfibをどんな書き方をしたらrustで問題になるのか想像もつかない

946 ：
fibってなんですか？

947 ：
>56でしょ？
fibがかけなくて5時間も喚いた挙げ句
答えを大量に示されても礼のひとつも言えない
下らない批評をしては論破されて潜伏を繰り返しているあほ
「rustに職を奪われた」「fibを書けない」もこいつの本質ではないんだよな

948 ：
ここはネタスレなんで

949 ：
>>56もそもそも拾い物みたいだしなぁ……　（検索に引っ掛かる

950 ：
ツイッターでrust-lang-ja.orgのドメインが～みたいな話が先月からあるみたいだけど
このスレでは誰も話題にしてない？

951 ：
fib拾いものなのか
正しくないfibすら書けないおじさんだったか

952 ：
https://www.google.co.jp/search?q=%E2%80%9Ca352230e08bc0a76fb5f116bd3c7abf4%E2%80%9C
？

>>950
検索にも引っ掛からないし誰が困るんだろう

953 ：
>>950
Slackでは話題に出てたけど　ここでは出てないかな

>>952
流石にplaygroundには貼ったんでしょうね　コード4行目で検索

954 ：
>>953
ほんとだ4行目だけを直接検索したら出た
しかも解決法までご丁寧に解説してあった
>>56はそれも読まなかったのか…
はたまた、読んでも理解できなかったのか…

955 ：
推察するに日本語が読めなくて、「できない」だけで飛び付いたんだろうなあ
こんな奴でもC++は書ける（自称）って辺りが日本のプログラマの闇だな

956 ：
軽々しくC++書けるなんて口にしようものなら茂みからマサカリが飛んでくるぞ

957 ：
C/C++ については、いつまでたっても「書ける」とはいいきれない存在ですね…
仕様が結構複雑だからなのか？

958 ：
Rustは「書ける」んですか？

959 ：
Go使うよ。

960 ：
perlがライトオンリー言語なんて言われていたけどリードオンリー言語なんてのもあるんだな。
http://wiki.c2.com/?ReadOnlyLanguage

rustはノミネートされてないから「書ける」と思うよ（すっとぼけ

961 ：
確かにAppleScriptは中途半端に英文風で多彩かつ何でこれダメなのってパターンも多くread onlyに相応しいな
昔はAdaの称号だったと思うが

962 ：
Eclipse Corrosion使ってるやついないの？

963 ：
Rustでプラグイン機構を持ったアプリを作る場合、本体とプラグインでjsonでやり取りするのが無難？
それとも動的リンクでいける？

964 ：
jsonでどうやるんだ。
ttps://crates.io/crates/libloading

965 ：
それOSやRustコンパイラがどういうコード作るかによるのでは？
なんとなく出来そうな気はするけど。

966 ：
コンパイラのバージョンアップでABI変わる可能性があるから
* 本体とプラグインが同じバージョンでコンパイルされてることを保証する
* extern "C" なインターフェースだけ使う
とかの工夫は必要そう

967 ：
プログラミングRust待ちきれないどす

968 ：
extern "C"してもバイナリ互換のない変更したら同じじゃね？

969 ：
本体側からメモリマネージャをエクスポートして.dll/.so側に使わせるってできたっけ

970 ：
crates.ioで中身のない、クレート名の予約だけの人増えすぎじゃね？

971 ：
rustはweb周りをもっと押したほうがいいな
新しいのに飛びつくのはあの連中(俺も)だからな

972 ：
未発達ってだけじゃ？

973 ：
壁乳

974 ：
未発達かな
hyperやactix webがあるじゃん

975 ：
未発達すき

976 ：
async awaitベースのtokioがでるまで待った方がよさそう

977 ：
プログラミング言語Rust発売まだ？
はやくして

978 ：
今日からRustやってみる
C言語とPythonとSchemeがちょっとずつしか分からないけど大丈夫かしら
Rustで本格的にプログラミング覚えた人っていますかね...？

979 ：
C++知らないと窮屈なだけで何でこんなもんが必要なのか意味不明じゃね

980 ：
C出来るならありがたみ分かるだろ

981 ：
Ready at Dawn Studiosって言うアメリカのゲーム会社が今後の開発は全てRustでするってよ

982 ：
泡沫ゲームメーカーの

983 ：
海外だから多めに見てもらえる

984 ：
新しい言語だからrustからって人はなかなかいないと思うけどおすすめだな
根気は必要だけど

985 ：
これPHPが2%もあってPHPの代わりになるほどRustはまだ便利ではなさそうだな

https://github.com/imos/icfpc2018

986 ：
比較対象間違ってないか？

987 ：
意味不明すぎて笑ってしまった

988 ：
初心者スレ無いようなのでここで質問させてください
トレイトって他の言語で言うところのインタフェースみたいなもん？

https://doc.rust-lang.org/rust-by-example/trait.html

trait Animal {
fn new(name: &'static str) -> Self;
}
impl Animal for Sheep {
fn new(name: &'static str) -> Sheep {
Sheep { name: name, naked: false }
}
}

この、Selfを使うようなことはインタフェースじゃできないよね？
1) Selfを使える
2) 独自クラスの定義にのみimplementsできるインタフェースと違って
　　既存の型に対してあとからいつでも実装を保証？できる
のがトレイト？

989 ：
Selfが使えるかは言語の特徴でtraitの特徴じゃないんじゃない
あと外部で定義されたtraitを外部で定義された型には実装できない制限がある

990 ：
sheep.nakedがfalseなのはバグじゃまいか

991 ：
お前らそれよりtraitがコンストラクタ持ってることにツッコめよ。

Ready at DawnってCSやってたけどあれもrustで書くつもりだろうか。

992 ：
コンストラクタ？

993 ：
質問するための例でしょ、野暮だなあ

994 ：
write!マクロってキモい

https://play.rust-lang.org/?gist=630529d9c9c65ee7e3a7ea9a2524e841&version=stable&mode=debug&edition=2015

995 ：
write!マクロって本当キモい

https://play.rust-lang.org/?gist=54a890fbc7093117363802bf84a9cd0a&version=stable&mode=debug&edition=2015

996 ：
>>906
gowにはrustlungちう病気が出てくるぞ

997 ：
>>989 ありがとうございます！もっと勉強します

998 ：
>>991-993
そこなんですよ
コンストラクタをトレイト側にかけちゃうのが何か凄み感じるんですよ
インタフェースじゃせいぜいObject型で返すくらいのもんでして

999 ：
あ、これはやばい理解パターンだ。。

1000 ：
インターフェースは型だけどトレイトは型じゃないって気付いたときに理解が進んだ音がした

1001 ：
Rust part6
http://mevius.2ch.sc/test/read.cgi/tech/1532697692/

1002 ：
2ch.scからのレス数が1000に到達しました。

メガデモを語る fr-08
国産オープンソースDIコンテナSeasar2 その16
Java入門・初心者質問スレ Part.7
Google App Engine for java
スレ立てるまでもない質問はここで 149匹目
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part19
Borland Developer Studio 2006 No.13
VB.NET質問スレ(Part43)
Swift part11
おまいらはディープラーニングの検定試験受けるの？
--------------------
◆◆◆　2015年7月9日に在日は強制送還されたのにバカウヨはいつまでチョン連呼してるの？ Part7
とうふさんをすこれ←なんだよこれ
【「家族のみ１回１０分かけ放題」ならＯＫ】「電話かけ放題」はダメ　携帯広告、自主基準改定へ
【鹿児島４歳女児虐待死】鹿児島の児相、女児を保護せず 県警は必要性を伝達
【魔力】書き込むと願いが必ず叶うスレ【強力】1581
【速報】ウォンドル1220　 KOSPI -3.87%　 KOSDAQ -4.3%
ウエスト・サイド・ストーリー【ステアラ】Part6
JA〓JA〓農協SEX業務日誌〓JA〓JA
ノーヘルの奴らって人生舐めてるよね
【無人】サウナ道16【有人】
【JDI 】ジャパンディスプレイ【税金救済】 Part.5
今聴く洋楽
【バーチャルYoutuber】にじさんじアンチスレ9【渋谷ハジメ応援スレ】
憲法9条の心を失った時に日本の再生が始まる
【ゲンダイ】安倍応援団は大慌て　政策「石破ビジョン」予想外の高評価　アベノミクスの失敗も解説
【最強台風】大型の台風19号　福島から太平洋に抜ける　中心気圧は975hPa ★97
For no one はもっと評価されていい
生き物苦手板自治スレ
【新型コロナ】WHO、「免疫パスポート」に反対…ロックダウン緩和の目安として、抗体検査の結果を利用する動きに釘 [みんと★]
万双　鞄　財布　小物　part49
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼