Rust Part5 ->画像>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

前スレ
http://2chb.net/r/tech/1507970294/

>>1補足

関連スレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
http://2chb.net/r/tech/1514107621/

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

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

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

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

本スレ

プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
http://2chb.net/r/tech/1514107621/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ほんそれ

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

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

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

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

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

2番目が正解だな

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これで満足？

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

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

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

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

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

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

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

瞬殺されてて草

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rustは？

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

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

まあそうなんだけどね

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

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

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

私にも敵が視える

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

やはりD言語が最強か

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

やはりアセンブラか

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してくれないものでしょうか

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

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

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

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

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

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

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

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

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

https://twitter.com/tanakh

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

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

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

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

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

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

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

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

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

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

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

118が低級

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

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

はいはいわかったわかった

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

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

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

はいはいわかったわかった

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

new()用意しとけ

derive(Default)使えば

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

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

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

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

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

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

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

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

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

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

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

なるほど

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

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

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

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

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

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

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

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

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

クソ

分かりやすい説明だね

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

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

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

気のせい。

あるかもね

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

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

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

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

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

DOMいじれんの？

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

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

>>160
無理

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

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

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

>>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で自動化しても良い

hello worldが10個出た。

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

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

rustupでクロスコンパイル

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rust, Elixir は注目されてる

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

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

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

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

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

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

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

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

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

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

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

自分で書いてるじゃん

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

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

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

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

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

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

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

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

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

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

ほんそれ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また来たのかよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3億人くらい？

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

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

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

native modules はい論破。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

かま爺

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どこに溢れてるの？

脳内

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

>>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トレイト使って一体何する気だったのか…？

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

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

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

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

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

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

>>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を使わないから詳しくはないので、間違ってたら指摘して下さい)

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

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

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

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

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

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

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

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

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

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

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

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

>>333 訂正
>>322 → >>332

>>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

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

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

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

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

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

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

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

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

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

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

学習コスト高すぎRust

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コンピュータ言語ｗ

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

アセンブリやろ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上

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

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

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

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

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

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

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

>>401
あっ! 逃げたww

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

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

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

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

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

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

まともな話題ないし

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

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

いちおう指摘しておくと以下にわっちょい付きのスレはある。
http://2chb.net/r/tech/1514107621/l50

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

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

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

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

>>414
いちおうアンチスレも存在するんだぜ
http://2chb.net/r/tech/1509028624/

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

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

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

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

もう答えた
>>397

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

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

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

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

JITとかそういう用途？

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

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

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

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

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

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

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

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

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

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

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

えぇ。。

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Windows defenderが動いてるとかでは

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

impl traitはよ

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

https://logmi.jp/282807

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

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

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

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

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

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

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

それよりimpl traitまだー？

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

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

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

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

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

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

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

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

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

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

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

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

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

以下の場合に&*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);
}

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

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

impl trait来たな

きた

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C#だとぬるり

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

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

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

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

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

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

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

systemdかよって

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

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

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

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

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

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

D49IO

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

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

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

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

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

Rust始まる前に終わったか

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

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

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

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

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

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

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

Rustと言えばcookpad。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>520
ほうほう