>>8
このブログが良識のある人の記事に見えるってのはある意味すごいと思う。
マジで言ってんの？ネタじゃなかったから単なるバカだよ？
Nimやったことないんだけど、このブログ書いた奴のせいで
俺の中でのNimへの風評被害が超激しいんだけど。 >>8
ネタにマジレスしてるはてな民多くてワラタ
2chもはてブも変わらねえな
インターネットはこうでなきゃな >>9
正しくRustとNimを比較してRustにいいとこなどないと論理的に談断じてる
そこまで言うなら反論記事よろ
>>10
マジレスも何も事実じゃん 金子勝とかNimキチガイとかrustアンチするにしても筋悪すぎるしアンチを装った信者の犯行では
Nimおじさんの布教の熱意は見習いたい
Rustオタは身内で盛り上がってるだけだからな
ここまで理論的な反論なし
まあできないんだろうね。言語未満Rust
Nimとの対比でRustは言語未満のゴミだと暴かれている上に
それを布教してるやつらは金子先生の鋭い指摘で詐欺集団だと暴かれているのに
信者は人格攻撃して矛先を反らすだけ
よっぽど反論できなくて悔しいんだろうね
Rustはプログラミング言語未満というのは >>8 の意見だと思うけどプログラミング言語の定義が曖昧すぎて反論のしようがないしそれで勝利宣言されてもね >>16
書いたらモジラからお給金出るでしょ
>>17
意味のあるプログラム書こうとしたら
とたんに借用とかでコンパイル通らなくなってまともにプログラミング出来ないものがプログラミング言語と言えるのか？
まあMalbolgeやBrainfuckがプログラミング言語と呼べるキ◎ガイならRustもプログラミング言語かもね あとその人か反論記事消したのも
本当はRustが使い物にならないことを察してしまったけど
それを言うと信者に突撃されるからぼかして消しただけでしょ
表向きの理由で全消しするのは不自然だから
あぁ、Rustのネガキャンするとお給料がでるのか……
提灯記事書いてモジラからお金もらうにはどうしたらよいのですか？
「俺がコンパイル通せるコード書けないからRustは糞」って主張で首尾一貫してるところはすごい
それとも世のRustで書かれてるアプリケーションは実はすべて別の言語で書かれているという主張だろうか
はたまたRustで書かれてるものはどんなものであれまともなものとは認めないかな
オープンソースでRustで書かれてるやつも
なんとかコンパイルだけ通したような
保守性も何もない個人が脳トレで書いたようなものばかり
まともな製品として書かれたコードはGithubにも見つからなかったぞ
ソースコード公開してるものがそうなんだから
企業がRust使ってると称するなにかは実際にはRustなんて使っておらず
適当な別の言語で書いてRust使ってると言えばモジラから金が出る
そういう仕組みと考えるのが自然な訳だ
で、このアーカイブ記事に対する論理的な反論はできないと。
あと、GitHubのまともなコードが見つからなかったって点も
どの辺がまともじゃないのかについてはコードでは示せないと。
それで自分の言葉に説得力があると思ってるのが不思議でならないんだが。
あと、俺にも「モジラからお金もらう方法」を教えて。
ホントにもらえるんだったら絶対に反論記事書いてあげるから。
ぐぇ crate uuid のインターフェースが換わりよった
ParseError が std::error::Error を impl しなくなったのは何故だ……
>>28
なんで取り下げられた記事に反論しないといけないの？
取り下げたってことは「この記事は間違いだった」というメッセージでしょ
モジラから金貰う方法とか俺に聞くなよ
モジラのページにある自称Rust使ってる企業に聞いてくれよ >>29
な。Rustなんて使うからそうなる
一貫したインターフェースを提供することすらできん言語だ 取り下げた理由も書いてあるのに読まずに決めてかかってるのほんとブレねぇな
まともな製品という言い方もそうだけどまともかどうかの判断基準は「俺が気に入るかどうか」以上のものがあるように読みとれなかったので議論にならない
論理的な会話ができてないのはどちらなんだか
>>31
レスしてもらったのはありがたいが
俺はお前さんから見ればRust信者だわ すまん
元よりどんな言語使ってもインターフェース変更はある
今回は、追従する作業に五分も掛からんかった
後はテスト流して終わり
インターフェースの変更が出来ないのを理由に
開発が鈍化されるよりマシだと思うよ クソな例挙げようと思ったが挙げるまでもなく>>29が素晴らしい例を出してくれたな
Nimの人のブログにもあったが、ロジックと関係ないスコープ切りが必要なせいでコードがスパゲッティになるとか、
ハッシュテーブルと所有権がコンフリクトして動的計画法が書けないとか
所有権のせいでそもそも循環グラフ書けないとか
いくらでもクソな所出してやれるが？ それ以上に、難解すぎてロジックと関係ないコード上の手入れが膨れ上がって
結果ロジックにバグが増えたりインターフェイスの非互換が発生したりするんだよ
だから致命的に壊れた言語って言ってる
反論ブログの人が今でも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について文句言ってるんだからせめて型検査くらいは通ったソースにしてくださいね
HashMapのエントリーへのポインタは新しいエントリー追加したらreallocなどが呼ばれて無効になるかもしれないので取り回すのがそもそも間違い
この流れ見ると、NLLはRustのハードルを思った以上に下げるのでは？と思わずにはいられない
その程度のエラーで投げるやつは少数派なんじゃ。。。とおれは思うけど。
まぁ、それでハードルが下がるのならそっちのほう良いとは思う。
けど、その程度で前に進めなくなるならすぐに別の問題にもぶち当たってやっぱり投げちゃうと思うよ。
そういう奴らはRustはともかく、多分C, C++でも自分で書いたバグに潰されると思う。
結局GC付きの言語でしか書けないんじゃない？
念のため言っておくけど、GC付きの言語を批判する意図はないよ。
おれTypeScript好きだし、Goも嫌いじゃない。
確かにここが解決しても型合わせとかで匙投げそうだな……
型の方はScalaとかSwiftとか別の言語で似たようなのがあるから参考にできる文献多そうだけど
ジェネリックとトレイト境界の辺りとか最初は結構苦労した記憶がある。
特にfuturesクレートを初めて読んだときは?!??!?ってなった。
Rustは良い言語だけれど「難解」というところだけは否定できない。
そういえば、結局「モジラからお金もらう」方法教えてくれなかったなぁ。
お金欲しいのに
ちゃんとしたもの作れるわけないだろという主張してたのが昔は複数いたと思うが
Quantumが出たあたりで流石に取り下げたようだが
モジラは詐欺会社と言い張る一人だけが猛烈に頑張ってる
安全性を最大限に気にしたい心配性な人向けの言語だよRust
そういう人たちはC/C++のコーディングで余計なことまで心配しすぎてストレスかかってるんだよ
かわいそうな人たちなんだよ
心配しないと鼻から悪魔が出るのがC/C++なので心配しすぎということはない
例のアンチだが動的計画法がどうだ循環参照がどうだって騒いでたから
てっきりhtml5everくらい複雑なコード組もうとして悩んでたのかと思ってたけど
まさかのフィボナッチ数列でつまづいていたとは予想外だったわ
そういえば今年のstackoverflowのアンケート結果っていつ出るんだろう？
そもそも毎年いつ頃出てるのか知らないんだよね
これでRustが愛され言語ランキング1位から順位落としてたら
また「ついにクソ言語未満のボロが出てきたな」とか騒ぎだすんだぜきっと
前スレで、別のランキングでRustの順位が10位圏内に入ってなかったことについて
「工作ブーストが切れたな」とか言ってたからそういう方向になるんじゃね
unsafe使えば書けるだろ
C++みたいに全部unsafeな言語よりは安全
C++ならゲーム
C#ならWindowsフォームアプリケーション
PHPならWebアプリケーション
Pythonなら機械学習
Rustは？
ここはアンチが立てたキチガイ隔離スレです。
キチガイ以外書き込まないでね
本スレが過疎ってレベルじゃないし実質こっちが本スレだろ
隔離（）スレに勢いで負ける言語があるらしい
ほんとID:yl4ANYczは戦犯
コンパイルできない厨が最後のコンテンツだったのに…
いわゆるnewtypeパターンをLLVM IRで見てみると
ごく単純なコードで使う分には中身の要素に最適化されてるけど、
それ使って配列を作っただけで最適化されなくなる
こんくらいでゼロコスト抽象化とか言ってるの？
typeでは新しい型作れないし、
結局新しい効率的な型を作る方法さえないんだな
Rustで書くと実行時のメモリ使用量が増える感じは確かにある
>>81
ゼロコスト抽象化はトレイトやジェネリクスを言っててnewtypeパターンは関係ないと思うゾ
Cに比べたらC++もRustもGoもランタイムの分だけメモリ使用量は増えるよね
C++にはランタイム存在しないとか大笑いなギャグを素で言う輩は知らん むしろ今まで並列コンパイルをしていなかったのかという驚きがね...
型推論とかボローチェッカーとか大変だろうしと思ってたが、並列コンパイルで早くなるのは助かるよね
コンパイルを速くするためにプログラムの速度を犠牲にする
自称低級言語があるらしい
言語じゃなくコンパイラの話だぞ
速度を求めたリリースビルドは並列なしに切り替えられる低級調製可能なコンパイラすごいよね(棒読み
言語仕様には興味あるけど実装は興味ありませんって奇特な方には人気出そうな言語だね。
低レイヤ書く人は仕様より吐かれるバイトコードの方にしか興味ないから
完全にターゲティングに失敗してるよなこの言語
むしろコンパイルを通すことが難しくても効率的で安全なマシンコードを出力して欲しい奇特な人向けだけどな
性能無視して生産効率だけを求めるならボローチェッカーとかunsafeとかトレイトとか面倒な言語仕様はマジ辛い
ただ緩く書きたいだけならSwiftとかGoの方が絶対良いよな
ランタイムが馬鹿でかかろうが、goroutineが冗長コストだろうが、言語仕様が楽なそれらは生産効率が断然良い
安全はともかく、Rustが効率的なマシンコードを出力するというのは同意しかねる
ソースとマシンコードが一対一になる言語は安心感あるな
100デフォルトの名無しさん2018/03/01(木) 00:41:00.21
【お知らせ】Packt出版より Network Programming with Rust が発売されました。
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内に処理があるなら最適化で消えるのでは
良く分からないけどReleaseにしてASM見ると消えてるみたい
MIRに対する最適化は現時点ではそれほどやられてなさそう
>>106
Debugなのを忘れた状態で見てcall nanka2があったので駄目かと思っていましたが
Releaseだと消えるようですね、すいません 言語仕様で消えるってどっか書いてある？探したけど見つからんかった
>>108
最適化の話だから言語仕様では決められてないと思う あのtanakhですら擁護できなくなってきたRustとかいう何か
やっぱクソ言語じゃん
逆にたなこふ氏が好きな言語って何だよ
Haskellくらいだろ
>>114
Rust評価高いくてGoは糞って評価だな。 絶対一緒に仕事したくないようなコード書きそうな人柄なのがよくわかるのはいいことだね。
スタック使うかヒープ使うか考えなきゃいけないしマジで低級言語だなRust
低級プログラミング言語というときの低級は必ずしも蔑む意味とはならない
どう読んでも>>118は事実を言っただけでrustを誉めても貶してもいないと思うが…
「CはPythonよりも低級言語」これC言語を蔑んでる意味で取るアホなんているの？ 蔑んでいるように見えるのはあなた自身が心の奥底でRustを蔑んでいるのです
1つのstructにいっぱい詰め込むと初期化が面倒なんですが
よくインターネット上の広告で半年でエンジニアに！みたいなのあるけど、インターネット不得手、プログラム未経験者が真剣に半年頑張れば本当にそんなこと可能なんですか？
可能ならその理由はなんでしょう？人材が足りていないというのは存じ上げていますが
>>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開発に向いてない要素あんるんかな？
ごめん。聞き方がふんわりしてた。
webのバックグラウンドで動いてるrestAPIサーバに向いてない要因は何かあるのかな？
SPAとかマイクロサービスとかの構成でjavaとかgoとかの代わりに成り得るのかなって。
一応WebAssemblyで吐けばRustのコードとJavaScriptのコードを混在出来るけど
軽く触っただけなんでデバッグなどの開発環境の事は未知数
サーバ側でしょ？言語としては代わりになるだろうけど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として利用してるからそこが未知数
まあそれらのライブラリを使わなきゃいいんだろうけど
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無い言語の方が循環参照の時の解放が面倒、C++でもweak_ptr使う必要出てきたり
c++はやっぱraiiが便利。
gcあったって結局outofmemoryerrorになるなからなぁ。
だったらrustのようにコンパイラが所有権やライフタイムをチェックしてくれるのはいいと思う。
けど学習障壁高過ぎとも思う。
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上での動作だったりするからローレベルの情報は減少傾向だけど 集まったのかな？それとも応募が無かったか。
どちらにせよ気概は応援する
会社的にゲームのサーバーサイドかな
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 が出版取消されました。
セキュアプログラミングとかいって締め付ければ締め付けるほど
インシデントが増える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
数百万はかなり適当に発言した
実際はどれくらいなんだろうな？ >>251
せめてchromeと同じシェア取ってから言って欲しいもんだ 257デフォルトの名無しさん2018/03/31(土) 14:32:47.34
Write once, run anywhere なんていう開発プラットフォームがあるらしい
Electronって言うんだって
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はどうなんですかねえ？
わざわざRustスレまできて延々粘着アンチとかかまってほしい爺さんみたいで見苦しいからやめろ
>>273
かまってほしい爺さんに、かまってほしい爺さんみたいとかやめてくんない？
あんた人の心あんの？ 275デフォルトの名無しさん2018/03/31(土) 21:14:47.08
かま爺
いくらモノがクソでも流行ってるって一点で考慮に入れる必要はあるし、
逆にどんなに良いものでも流行ってなければ選外になるのは事実よね
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
Rustできちんとコード書ける実力あるなら
CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な てか｢一応読み書きはできるようにはなったけどC/C++の落とし穴を知らないせいで危ないコード書いてる初心者｣こそRustやるべきだよな
>>56みたいな
>>56がなんでエラーになるのか理解できないって事はC/C++でもvectorへの参照を何も考えないで使い回してたりするって事だし ああそれはあるかもな
実用というより教育目的な言語としては確かにアリだ
>>288
>Rustできちんとコード書ける実力あるなら
>CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な
出来ないからC++ではValgrindとかのツール使ってチェックしてるんだろ
じゃあツールを必ず使うようにすればいいじゃんって話にはなるが… そもそもValgrindみたいなメモリリークをチェックする類のツールって
Rustのボローチェッカと比べるとどの程度信用できるのかね？
あまり信用出来ない
スマートポインタを(適切に)使ってればそもそも解放忘れはしないし
配列に確保しっぱなし系のリークは検知してくれない
>>293
>あまり信用できない
>配列に確保しっぱなし系のリークは検知してくれない
そっか、やっぱりRustのボローチェッカには劣るか
>スマートポインタを(適切に)使ってればそもそも解放忘れはしない
「適切に」ってところがポイントだよね
たとえ熟練のC++erがどれだけ注意してコーディングしてたって
「うっかりミス」はいつか絶対に起きるんだし 295デフォルトの名無しさん2018/04/01(日) 12:42:04.82
C++でボローチェッカをエミュレーションできないの？
valgrind使うと実行時間とてつもなく遅くなるし実行時間長いプログラムだと辛い
ASANでも2倍くらい遅くなるので辛いのは同じ
コンパイル時に静的に分かる方が嬉しいし、たまにしか通らないパスもチェックされるのでより安全
まあ結局unsafe部分はチェックできないけどね。
その場合でもコンパイル通ったからと主張しだす輩で溢れてる。
C++20では生ポが非推奨になるらしいけど
unsafeはチェックできないのと同様に意味がないですね
他言語呼んでもメモリリーク起きないとかこのスレでも喚いてた輩がいたわけだが。
drop trait を明示的に書かなっきゃならんとかそいつら全く理解してないだろ。
>>302
非推奨になるってどういうこと？
rustみたいにunsafeブロックみたいなのを導入するってこと？
C++は基本的にはCとの互換があるから無理だと思ってたんだけど… 生ポインタ使えることがC++の唯一のメリットなのに
それを非推奨にするなら別の言語使ったほうがマシだろ
RustがC++に実用面で勝ってることなんかある？
勝っているかどうかは知らんが
cargo/crates.io相当のものがないから
新規アプリをC++で書く気はしなくなってしまった。
もしかして最近は便利になってたりするんだろうか。
しかしインスタンスを変に共有しなけりゃ解放タイミングを
いちいち気にしなくていいって発想は面白い。
参照カウントガベージコレクションにもスマートポインタにも興味ない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だけ学べばいいなんてことはない
>>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の実装の中身とか見たことないけど、混在してても問題ないのかな？ >>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しようとは思わないかもしれない。 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でまともなもん作れるつもりか？
実用的・実積も曖昧だな
どの程度を実用的で実積があると呼ぶのか具体例を提示してくれ
突き詰めていくと「バグらない」も程度によりけりだしな
Excelだってバグるときゃバグるし…
話に入れないからって「………結局駄目！」ってダサすぎない？
jsのファミコンエミュレータをrustで実装し直したらパフォーマンス負けたらしいｗｗｗ
>>357
JSに負けるとか草しか生えんなwwwwwww >>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と比べてから言えよ まあメモリの管理モデルが違う言語同士でやりとりすれば
色々苦労するのは当たり前なんだよね。
それなのに「rustは勝手に解放してくれる」とか言い張っちゃう信者が有害な訳だよ。
rustが悪いというよりか、こういう馬鹿が多いところが問題。
Haskellは副作用が無いとか参照透過性があるって言った時に
C FFIを持ち出して反論するのと同様の不毛さを感じる
不毛？現実によくあることなのにね。。
言語の一番下ではアセンブラが動いてるんだから、そことどう調和もしくは隠蔽させるかってのは
コンピュータ言語にとって本質でしょうが。
は？何で一番下が機械語じゃなくてアセンブラなの馬鹿なの？
結局Rustはサーバ向けでもコマンドツール向けでもGUI向けでも組み込み向けでもない
って事実はほんと覆らんよ
話に入れないからって「………結局駄目！」ってダサすぎない？
jsのファミコンエミュレータをrustで実装し直したらパフォーマンス負けたらしいｗｗｗ
>>372
メモリ管理みたいな重要なことについてデララメ振りまいて、
「理解しない奴がrust批判してる」とか言い出してる方が恥ずいわ。 上の流れ素直に読んでも、
メモリ管理も全部C側で完結させるのが一番いいって結論にしかならんぞ？
Rustのいいところなんぞ皆無だ
というかコンパイラにメモリ管理任せるのが無理だろ。FFIのためにいちいちDrop定義するとか非効率でしかない
メモリ管理はGCに任せるか完全手動にするかの二択なのに、無理矢理そこにヘンテコリンなソリューションもどき持ち込んで混乱引き起こしてるだけじゃん
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる
>>377
うおっ!
ここにきてまさかのRAIIを否定し始めるとか予想外すぎたわ!
お前C++のスマポってなにか知ってる？ >>379
ほとんどのコンパイラで採用されてない仕様書上にしかない機能なんざ知らんよ 実際混乱引き起こしてるまともじゃない方法なのは上の流れで自明だろ
>>380
よろしい。そんな君にはJavaがおすすめだ。そっちで元気にやりたまえ。 以前も言われてたけど「ひまわり学級の子が普通の授業に出て暴れてる」って表現が実に的確で草
間違ったものを間違った奴が流行らせようとしてるんだからそれには「違う」って言っとかないとダメだろ
話にならんと放置したらいずれ手遅れになるほど蔓延する
そうならないうちに叩いておくべきなんだよ
混乱引き起こしてるのは違いないけどさ
「俺の頭の中で混乱を引き起こしてる」って正確に書こうよ
>>385
上のFFI絡みの流れは俺じゃないけど？ 完全手動でメモリ管理するのは混乱起きないからいいよね～
>>387
コンパイラに丸投げするよりは良いな
混乱しないって意味だとGCが一番だが >>375
上のやり取りは俺じゃないけど？
散々間違いがあったら指摘してくれって書いてたのがデタラメを振りまいた？
間違いの指摘に礼を言って終えるところに、鳴りを潜めていたアンチがウキウキで「混乱を引き起こしたRust！！！」と喚き立てた
このスレでも何回もやってる流れじゃんクソダセー インタプリタへの丸投げ>完全手動でメモリ管理>コンパイラへの丸投げ
実行開始までの混乱しない順だなどう考えても
>>391
外から内ゲバ眺めてやっぱこの言語くだらねって思ってるだけ
C++の（後方互換維持のための苦しい構文追加以外）なにが悪いんだか >>393
スマポが何かを知らないヤツがC++を語り始めたぞ… >>378
ていうかこれ知りたい
Rustの何が(例:MIR)どう機械語との相性が悪く
それに対してC/C++のまともなアプローチの具体例を教えて >>395
代弁してやろう。
「自力で頑張る」
以上 >>395
結局解放処理は自分で書くんだろ？
メモリ上の確保のされ方はコンパイラにはわからないんだから
結局中途半端にしか自動化できないから無意味で、それなら自分で管理した方が結果的に良いって話 解放の仕方を実装したら、後はコードのどの場所で何回確保しても自動で解放される事が分かってないっぽいね
>>398
だってRAIIもスマポも知らないんだもん。しょうがないじゃん >>397
C FFIとかの一部分で解放処理を書くんだよ
お前が言ってる通り「手動」だしお前の好きな「手動」でよかったな
中途半端にとは言っても機能するし「無意味」と言い切るには典型すぎる誤謬
で>>395にまともに答えてくれる？どう相性が悪いの？どんなアプローチ？ Q. Rustの何がどう機械語との相性が悪く、それに対してC/C++のまともなアプローチの具体例を教えて
A. 結局中途半端にしか自動化できないから無意味で、それなら自分で管理した方が結果的に良い
Rustアンチ君との最後のやり取りがこれなのか…？悲しい
>>404
YOUがワッチョイのほうで話題ageれば ここはネタスレだからこれでいいよ
まともな話題ないし
そう思うんなら勝手にそっちでやってくれ
いちいちこっちに宣伝しないでよろしい
せめてスレ立てたやつくらいはあっち書き込んでくれよ。
ワッチョイスレ（本スレ）には俺しかいない。
>>384
大元に言わないで、ここでグダってる時点で説得力無いけどな。 それもあるが日本語の記事でrustマンセーしてるやつは大抵バカっていうのもある。
会話になってないし
時間おいたところで>>395に答えなくてもいいことにはならないからね 自分から「機械語のレベルと相性が悪い(>>378)」と言ってるのに
「具体的にはどういうこと？(>>395)」と聞かれて、
その返答(>>397)に機械語のことが一切出てこないのは流石に草 英語で説明する以前に日本語でのコミュニケーションに難ありなのか
日本語ネイティブじゃない方なのかな
機械語との相性のいいC,C++のソリューションって、機械語バイト列を関数ポインタにキャストして呼び出すとかじゃないの？
そんなことRustでできるようになって欲しくはないな。
rustで書かれたjitなかったっけ？
ところでrustで書かれたウィルスとかマルウェアとかないよな。
goならMiraiで使われてたけど。
C/C++の弱い型付けによるキャストは機械語と関係ないだろ
Rustは強い型付けしか原則許してなくてunsafe使えば弱い型付けも出来るけど好んでする必要性はないよねー
プログラミング言語と機械語の間はC/C++もRustもLLVM IRで仲介されてるから、どっちかだけが相性良いとかなさそう
LLVM IRじゃなくGas仲介するとこう違うんだよ、くらいの反論を期待してみるテスト
>>427
フロントエンドの話してるのに、バックエンドがLLVMだから違いなどない！は、おかしいのでは？
そんなこと言い始めたら、言語仕様の優劣など語るに値しないということになってしまう。 >>427
Any使ったdowncastはunsafeじゃないけどどういうコードの話してんの？ rustでフォントをレンダリングしたいのですがfont-rsやfreetypeなどの設定逆引き的なサイトってありませんかね？
チュートリアル的なサイトは見つかるのですがそこから突っ込んで使用したい場合に参考になりそうな情報がみあたらないです
レンダリングされる線を任意の幅にしたいです
極細フォントを使って線幅1ピクセル×2＝計2ピクセルでアンチエイリアス無しみたいな感じの結果が欲しいです
具体例を補足します
出力が2値の場合に普通にレンダリングした物を減色してしまうと線幅の不均一になったりディザが掛かってしまって
表示品質が極端に悪くなってしまうのでそれを防止したいです
たとえば「田」みたいな字をレンダリングして減色するとある線は1ピクセルだけど別の線は2ピクセルになってしまったり
交わるところに不要なドットが出現したりします
それを全て任意の線幅に統一したいです
ここはアンチスレなので、まともな質問はslackへどうぞ
434デフォルトの名無しさん2018/05/02(水) 04:26:15.76
えぇ。。
Rustってカルトみたいなもんだよな
実態はスカスカで教祖の金儲けに使われてるだけなのに、信者は正義と信じて疑わない辺り
slackなんて内輪の集会に逃げ続けて表の評価に曝されることを避けてる時点でまともなプログラミング言語じゃない
>>436
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる >>437
お前はさっさとその答え教えてくれよ
Rust批判するにしてもコンピュータの知識皆無すぎるわ。批判側がお前と同じ知的レベルに見られるのがクソ >>438
へー今日はたくさん書き込むつもりなんだ こちらはまともなアンチとキチガイアンチのスレになります。
win10 rs4にしてからrustdocが遅い。
rs4にMeltdown/Spectre対応のパッチも含まれてたんだろうか。
Windows defenderが動いてるとかでは
少なくとも5chではgoよりrustの方が盛り上がってるな。
同じリストを他言語でも作ってみたら？
どれだけバカなこと言ってるかわかると思うよ。
>>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経由で情報交換する方針 数十GBのオブジェクト管理は、gc待ちきついからオフヒープでとか、（これ聞いたときよりgcは良くなってる）
goroutineで確保したメモリは解放せずgoが管理するから、常駐で同時に大量に走ると解放されないとかはあるみたい。
以下の場合に&*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() って言う認識だったのが間違ってたのか
ありがとう
久しぶりにRustやろうと思ったけど公式リファレンスが最新版に追いついてないのな
どっかに変更履歴のまとめとか無いのかな
>>427
公式リファレンスって何のことを指してるんだ？
APIリファレンスならきちんと最新版に追従してるし、
チュートリアル(The Book)も2nd Editionがきちんと出てる
バージョンアップの追従ならリリースノート見るかRustの公式ブログ見れば大体分かると思う
Rustは6週間に1回のハイペースでマイナーバージョンアップ繰り返してるから
The Bookのほうは最新版に追いつくこと自体がほぼ不可能だと思うけど
(つい最近もimpl traitがstable化されたばっかりだし…) そのimpl traitが気になってまたRustやろうと思ったんだけどね
全機能の索引みたいなのがないと学習効率が落ちる
rustって生産性高い？
安全性が高まって結果的に高くなるということではなくね
やっぱでかいプログラムじゃなきゃ使う効果ない？
Javaでnull参照が10億ドル単位の損害と言われてるので
RustはJavaより10億ドルほど生産性が高い
まあ、ネタにマジレスになるが、
その論法だと俺の未完成言語は誰もバグを生み出してないので
Rustより生産性が高いなｗ
>>478
分母分子共にゼロなので計算不能ってやつね。 チーム開発に良さそうな気がするけどメンバーのレベルにかなり依存しそう
自分がGCなしの言語使ってた時の経験だと、ヌルポより、freeした後にアクセスするバグの方が多かったから、オーナーを一つにするrustはいいと思う。
まあ、objective-cのARCでいいじゃんとも思うけど。
そこでoptionalですよ
こいよ継承クラス、ポリモーフィズムなんて捨ててかかって来い！
実際、null非許容のポインタが欲しい
483デフォルトの名無しさん2018/05/17(木) 15:59:25.11
誰がヌルポなんか 、ヌルポなんか怖かねぇ！
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が一番良い感じだと思う
必要に応じて同期、非同期、アクターモデルと使い分けられるし
>>490
もう入ったから消せませんってのは横暴なようにも見えるがしようがないとも思う
一度入れてしまった機能をまた使えなくするとか、それこそ混乱するし…
そもそも何故impl trait を引数の位置にも書けるようにしたのかは確かに甚だ疑問ではあるけど…
引数の位置でジェネリクスとトレイト境界じゃなくてimpl trait じゃないとダメなケースとかある？
無いなら、warning出してジェネリクスとトレイト境界に書き直すように促すのが妥当じゃないかな？ こういうところでマウンティングとらないといけない辺り
言語（笑）開発チームとやらも内情はどうなってることやら
<T: Trait> foo: T
と
foo: &Trait
との比較で特殊なケースを除き前者の方が効率良いが
syntax上後者の方が簡単なので
初心者が誤って後者を使ってしまうケースがあった
これを防ぐためにimpl Trait および &dyn Traitを導入し
&Traitをdeprecateすることになった
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
D49IO
もう入ったから消せません
は正論
何故クソ機能の進入を許してしまったのか、どうすれば食い止められたのかについて追求すべき
ジェネリクスの型変数って引数と戻り値の型を揃えるとかそういう使い方をすべきであって
Traitをimplした型を受け取るという意味ではimpl Traitを使うべきだと思う
ただimpl Traitを導入するなら1.0の時点で導入してて欲しかった
こういうところでマウンティングとらないといけない辺り
言語（笑）開発チームとやらも内情はどうなってることやら
javaのジェネリックスが理解できてないやつが多いだけ。
>>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で書いてまっせっていうバカなアピールするのは。
まあCloudflareも日本にリージョンあるしな
wtftwっていうタイル型WM、設定ファイルまでrustで書くのどうなんだろ
設定ファイルはluaあたりが無難？
>>513
いやもうなかったことにしたがってるじゃんw
それなのに変なのに付きまとわれてるっていう。 >>516
「なかったことにしたがってる」というソースをプリーズ Dropboxのbrotliデコンパイラが昨日更新されてたから
24時間以内のホットな情報だ
519デフォルトの名無しさん2018/05/31(木) 22:43:34.41
Rustが失脚すると得をする組織があるの？
どうしてそこまで情熱的にRustを貶すの？
>>515 ざっとコンフィグファイル見たらXMonadのコンフィグよりは理解しやすいように思った
xmonad.hsはもっと宣言的に書けて、モナドとか上手く作って見栄えは良くできるんだけど、
馴染みのない演算子(<+>とか)使いまくるんで、よっぽどHaskellに慣れ親しんだ人でないと全容が理解できない
設定ファイルのフォーマットを開発言語と同じにするのはdwmから続くタイル型WMの流儀だし、
思ったより読めていいと思うよ。 >>519
前段 モジラとその小判鮫以外の全組織が喜ぶ
後段 技術的にカスなものを貶すのは技術者の義務だろ >>521
>技術的にカスなものを貶すのは技術者の義務だろ
じゃあPHPではなく敢えてRustをdisる理由は？
あちらの方が広く使われてるからより害悪だと思うが >>522
あれを使ってるやつも害悪性は理解してるからな。
こういう技術的にインテリな要素のある言語って信者がとにかく頑なで
実際のプログラムの現場で非常に問題になることが多い。 んー例えば
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる
>>525
んー例えば
コンパイルが通せなくて自尊心が傷ついて自ら会社をやめちゃう問題とか
この話どこまで事実か知らないけど仮に本当だったとしても
これって言語の問題というよりチームのプログラマの腕を過大評価
もしくは計算に入れてなかったというマネジメントの問題だよね んー例えば
プラズマクラスター付き家電が話に出てきたら今まで黙ってたのに凄い勢いでエセ科学だと解説し出すよね
いや、この粘着をクビにするためにRust導入したんでしょ
性格異常だもん
老害をふるい落とすために新しい言語を取り入れてるって話？
このフィボナッチ数列も書けないあほ
何度言い返せなくなっても数日後に甦る粘着性
C++で実行時にエラーが出るようなコードを書きまくったのでしょう。性格の悪さと溢れる自尊心から誰の耳も貸さなかったのでしょう。
プログラマーとして生きるよりかは、匿名掲示板で巨悪組織Mozzilaと闘うBBS戦士の方が社会的に良さそう
たとえばドワンゴとかDropboxとか
Rustを採用した企業自体を叩く行為をよくしているよな
あれ見るとちょっと辛くなる
槍玉にあげる例が1個しかないのがダサ過ぎるわ。しかもその例も対象が特殊だし
>>534は「それRustでやる意味がある？」という疑問に全く応えられないのが問題
LLVM IR-> PEZY-SCというコンパイラがあるんだったら、LLVMがバックエンドの他言語でもいいよねって話
それができないなら、LLVM->PEZY-SCは未完成か現実に即してないんじゃねえのって話 rustでやってみたって記事にrustでやる意味あるの？って疑問が出てくるのが不思議なんだけど
rustでも出来た、以外に意味はないでしょう
>>534
安全じゃないコード も 書けるってことに価値があるんだろ？
C/C++以外の他言語では書くことさえできない。でもC/C++は安全性を売りにはしていない
Rustは安全性を売りにしつつ、必要に応じて安全性を捨てる選択もできるということに価値がある
で、たまたまその記事が安全性を捨てることが必要な数少ない例の1つだったってだけ 安全でもなんでもないって
unsafeあるやんけ！危険危険！
前後の文脈一切分からんけどとにかく危なそうなこと書いてあるやんけ！
つって叩いてるんだろうなｗ
>>535
その手の問いにそいつが素直に答えたこと無いからあきらめよう たまたまねw
どんだけコード例出しても言い出しそうだなw
そもそもコード例が少ない訳で、推進してる奴のコードがそんなもんなら
十分否定的な要素だけどね。
ちょっとrustの記事書いただけで代表的な推進派扱いかよ
>>541
お前さんの理屈だと、Rustじゃこんなに危険になる！って事だろ？
じゃあ、Rustではそういう危険な書き方しか出来ない！って示さなきゃな。
俺は中立だが、あんまり非論理的なdisりはアンチ＝低能と思わせたがってるピエロにしか見えんよ。 既に20万行はコードあるからレビューがてら指摘したら喜ばれるよ
>>541
ほんとだどこが問題で悪いのか全然書かない
具体的に言及しだすとフィボナッチ数列とか機械語レベルとか、残念なことになるのが自分でもわかってたのか
まあ本人が書いた通り「ドヤしたいだけ」とか…なんかな？前もマウンティング取られたとか訴えてたし… またいつもの、ボロクソにされたらしばらく潜伏してから復活するパターンかな
たまには芸風変えたら
Rustの不満は言語仕様やrustcよりcargoやその辺の連携(情報の少なさも含む)にある
既成のクレートを探すのはcrates.ioになると思うけどライセンスってどうやって調べるんだろ
同様にクレート間の依存関係も判りにくい
どちらも一式を落としてきて中身を確認しないと判らないような・・・
Cargoで自動ダウンロードして・・・みたいな使い方をしていると意図せずGPL/LGPLになっていた
みたいなライセンス事故が起きそう
>>549
$ cargo install cargo-lichking
$ cargo lichking check
一先ずlichkingでチェックできるよ LGPLのstatic linkとかやめて欲しいよね
>>550
えぇー・・・わざわざインストールしないと出来ないのかよ。とりあえずやってみるか
依存関係はどうすりゃいいんだ？no_stdでも使える奴だけ探したいとか >>552
no_stdかどうかについては、Cargo.tomlのcategoryパートに"no-std"があるかどうかぐらいしか確認するすべなさそう(2017-2-10に追加されたっぽい)。
皆が皆付けてるとは思えないので、参考程度にしかならないだろうけど。 ちょうどいい機会だから、カーゴのギフハブべったり依存をやめて抽象化してほしいわん
crates.ioべったりは分かるけどGitHub依存って何
>>561
ええ…？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で書こうが他の言語で書こうがどっちにしろ従来のアドオンの一部は動かないよ。 今回は1週間も我慢できなかったのか
ほかに行く場所ないの
>>569
非効率になるのを嫌ったってことみたいですね
stdでもつには重すぎるってのは理解はできるけど 確かに不便なんだよなー
自分は結局
ioの関数呼ぶ前にinfo!でログ出すとか
戻ってきたio::Errorをmap_errでPathBuf埋め込んだ自前のErrorに変換するとかしてます 2回もpath書くの全然かっこよくないから、少し重くてもなんでもいいから便利なライブラリがあれば使うわ
トレイトオブジェクトってなんでトレイトオブジェクトって呼ぶん？
ようはヒープに動的に作られたストラクトだら？
何らかのTraitを実装したオブジェクトだから、じゃ駄目なの？
変に勘ぐって誤解してるよ。スタックにある構造体でもトレイトオブジェクトになる
traitは写像の集合で本来的には定義域の集合でないものなので、それとして扱う場合を特別にトレイトオブジェクトって呼んでるんじゃないの？
>>575
ヒープにある構造体である、とはどこにも書いてないよね
複数の異なる型を同じ関数や構造体で持っておきたいけど、
型が違うからコンパイル時にサイズが決まらないんで困ったねって状況を解決するのがトレイトオブジェクト
そういう事態じゃなければfn foo<T: TraitFoo>(obj: T)とかやって型毎に関数をコンパイラに作ってもらうのが普通 なんらかのトレイトじゃなくて特定のトレイトを実装したなんらかの型ってことかな
D言語の再来と言われるRustには注目しています。
さすがに「C#とか糞wwこれが俺の考えた最強言語ww」→「結局C#が全部正しかったですｻｰｾﾝww」で終わったただの中二言語と一緒にするのは失礼
>>571
1.0待てなくてもう現行のfailureにどっぷり浸かっとる。
failureはいいぞ！ D言語は最近顔本コミットを受けて活発化してる
Rustは採用企業が全く増えなくなって資金も枯渇
メインコミッタもリンゴのSwiftやらにヘッドハントされて
もう将来ないでしょ
もちろん言語のエコシステムとしての将来がないってだけで、
ライフタイムとかの実装系の先駆としての意義はあったとおもうが
なんで急に元力士の名前が出てきたんだ？
二の舞って言いたかったのか？
>>590
なんかfailureのissues見ると、現状のstd::errorの設計は失敗作扱いみたいだな
それって共通認識なんかな？ Haskellかじってて、Rustに興味出てきたんだけど、なに、廃れつつあるの？
廃れるもクソも、Rustが世間の注目を浴びたことなど未だかつて無い
大丈夫、大丈夫。
ユーザーが年々すごい勢いで減っているDに比べりゃ
規模は小さいもののRustは年々少しずつ増えてるわけだから
今後普及するかどうかはともかく少なくとも廃れちゃいないし、
学習コストが高いから敬遠されてるだけで注目もされてる
それにHaskellと同じで勉強しといて損はない言語だと思うし
そもそも普及を目指してるような気配もないよな
バッテリ同梱などと言い出しもしないばかりか
randすらクレイトになってるから
rustcだけで楽しんでると涙目（´・ω・｀）になる
Dのユーザが減ってRustのユーザが増えてる世界線はどこにありますか？
別に趣味でやってりゃいいんでないの。
ライフタイムとか所有権の感覚は他言語でも役にはたつでしょ。
wasm やるなら stdweb と wasm-bindgen のどちらを使ったらいいですかね?
もしくは他の選択肢の方がいいとかありますか?
>>595
std::error+error_chain/log crateの問題点を
解決するためにfailure/slog crateが
作られたからだいたいそんな感じだと思う。
failureの方は今nurseryだし。
failureのエラーとstd::errorのエラーを相互変換できるから
移行や依存ライブラリがstd::error使ってる場合に対応簡単だよ。
まあ、1.0待ったほうがいいけど。 >>602
wasm-bindgenはhost bindings proposalの実装でstdwebはweb apiのrustバインディング。
host bindings proposalはWebAssembly用の(ホストとの)ffiみたいなもん。 >>602
stdwebベースのyewとか面白いよ
Reactっぽいことが出来る >>604
>>605
レスどうもです
host binding（wasm-bindgen）が後発で
cargo-webがあるstdwebの方が開発サイクルが楽そうという感じがしてます
yewも見てみます >>603
stdの下にあるけど非推奨、みたいなのが今後だんだん増えてくるのかな >>607
使ってはいけない標準ライブラリとかC言語のgetsかよwwwww
21世紀の言語とは思えねえなwwwwwおもちゃもいいところwwwwwww 愛され言語ナンバーワンに2年連続で輝いたのに人気ない扱いは意味不明だ
>>612
純粋に聞くがお前の周りでRustサイコーって言ってるエンジニア何人いる？ >>614
いくらでも組織的に水増しできる問答や投票になんの意味が？ >>615
その程度の言語が世界一位って統計的におかしいと思わん？ >>617
お前と匿名の一人で統計語ろうっておかしいと思わん？ あとこいつ好感度と使用者の数をごっちゃにしてるの？凄いよそれは
フィボナッチ数列も書けないだけはあると思うよ
フィボナッチ数列って円周率みたくいまもなお計算され続けてたりするのかな
どう考えてもRustなんかよりJavaのほうが愛好家多いだろ
プロダクトの数考えろよ
624デフォルトの名無しさん2018/06/20(水) 22:24:58.84
ハンバーガーはマクドナルドが世界一売上高いんだから、マクドナルドのハンバーガーが世界一美味いに決まってるだろ？
>>617
なんで一つのサンプルで統計的にとらえるんだ？
プログラマー的におかしいと思わん？ >>623
それ>>8でオレが貼った記事な
このスレでも反論の余地の出なかった良記事。Nimについてはともかく
Rustのクソさについては本当によくまとまってる だからさー。文句あるなら記事に反論してみなよ
取り下げられた記事以外誰も出せないまま人格批判だけとか全く理論的じゃないし
そういう人ばっかだよねRust信者って
>>631
archive. fo/7NUr2
なんかある？ >>633
だから取り下げられた記事は反論にならないって
本人が間違いだって取り下げたんだから >>634
読んでもねぇのに自分勝手に判断して否定するバカが
「理論的じゃない」とかよく言えたな
その言葉そっくりそのままお返しするよ >>635
自分勝手じゃないよ？
そもそも論を取り下げたのは向こうじゃん
取り下げられた論が議論の俎上に上がるのはおかしいでしょ ある人がどのレベルでプログラミングしてるか、という差がある
ある人にとってはプログラミングとは設計作業に他ならず
ある人にとってはプログラミングが指の労働でしかない
書き間違えるから、書き忘れるから、という理由でもって
しょうもないバッドノウハウを拝み続ける者すらいる
塩と砂糖を入れ間違う、塩を入れ忘れる、自称料理人
そーいうレベルのプログラマ
クソ言語はRuで始まるの法則。
ソースはRubyｗｗｗｗｗ
>>636
何故取り下げたかの理由も書いてあったがそっちのほうは完全に消えたかな…
アーカイブすら残ってなさそうだ…
「他の記事を貶めるような記事は品性が疑われるからやっぱり取り下げる」
みたいな理由だっと思うけど、どうせお前はそれも認めないんだろ…
………ふぅ………もういいよ……
お前の頭ん中ではRustはクソ言語で良いよ…… まあ人気であることは否定できないし好きに言わせとけば
rustは個人開発向けで仕事に使うものじゃないのね。
Cargo.tomlに対応するrustcの最低バージョン番号を書く方法ってある？
キチガイがまともなふりして質問するふりするんだよなー
>>653
俺は英語なら分かるんだけど、日本語はさっぱり分からん >>654
すげーな
オライリーのやつKindleで読んでるけどまず訳すのが大変だわ 訳さず英語で読んだ方が…
情報の早さ・量・正確さが段違いだし原著読むと意外と難しい単語使われてない。
bind(bound)を束縛とかアホかと。
せめて結びつけとかにしろよと。
翻訳のセンス無さすぎ。
もしくはわざと小難しくして地位を守ってるのか…
結びつけだとassociateの訳ともとれそう
英語と一対一で対応できる和訳の方があとから英語情報に触れるときのハードルを下げると思う
>>658
get / put / take なんかで言い換えしたからといって、わかりやすくなったとは思わない それにしても～を～に束縛しますとかセンス無さすぎる。
明治時代の翻訳見習ってほしい。
漢籍の素養が必要だが…
逆に聞くが「変数にbindする」って日本語にどう訳したら自然なんだ？「結びつける」は別の意味になるぞ
明治期のアレは翻訳っていうよりは対応する訳語を創出するって感じだから、単純な翻訳じゃないぞ
「縛りつける」みたいな感じになるしかないと思うんだが
束縛は単純に漢語にしただけで大差なかろう
>>652
ありがとう
一応そういうのあるんだ
そのページの下に書いてある、edition 指定出来るようになるのを期待、という感じかな > 翻訳のセンス無さすぎ。
お前にはあるかのような口ぶりで
> せめて結びつけとかにしろよと。
↑こんなこと言い放ちつつも
> もしくはわざと小難しくして地位を守ってるのか…
束縛っていうふつうの単語を小難しく感じると白状し
地位を守るだのなんだのという珍妙な価値観まで丸出しにするとは恐れ入る
まあ、英語のbindからして数理論理の変数束縛と同じ単語を別の意味で使いまわしてる
近い分野なんだから専門用語もう少し考えてくれても良かったのに
慣れちゃってるから気づきもしなかったけど代入からして大概だよな。
英語だと単にassignだぞ。
その点、グーグルは気が利いてて、
「錆は、安全性、スピード、並行性に重点を置いたシステムプログラミング言語です。
以前のバージョンのRustが錆びてインストールされている場合、」
だからな
「バインドする」で良いのでは
traitとかcrateとか訳すとよくわからなくなるもの多いし全部カタカナでよい
タイプアノテーションのないバリアブルのタイプはライトサイドをエバリューションしたときのタイプになります
是々非々だな。
型アノテーションのない変数の型は右側を評価したときの型になります
束縛するはバインドするでよかった。SMの趣味ないし。
誰に確認したわけじゃないが、変数に何か値を設定するのが代入で、値に名前を付けるのが束縛だという認識
fn foo(...) {...} は、ある関数に対しfooという名前をつけるので「関数をfooに束縛する」とは言うかもしれないけど、
「fooに関数を代入している」とは言わない、みたいな
単にイミュータブルかミュータブルかの違いでないの？
>>673
伝統的な表現だと宣言に近いニュアンスかな rustはバインドしていない状態の変数も合法だからややこしい
let hoge;
hoge = 100; // これをコメントアウトするとコンパイルできない
println!("{}", hoge);
初心者なんですが、文字列を作成して返す関数を作るときって、
fn hoge() -> String { "hoge".to_string() }
と書くものですか？
それとも
fn hoge() -> &'static str { "hoge" }
と書くべきでしょうか？
Stringもstrも返す可能性があるなら Cow<str> で
それ以外なら使えるときは &str を使うのが良いのでは
Stringとstrを両方残しちゃうあたり
優柔不断でグダグダな言語に思えてしまう
>>683
せめて理論的に反論しろよグダグダ言語の信者 >>685
えぇ・・・ソース見るしかないのかよ・・・
リファレンスマニュアル見てもちゃんと書いてないんだよな
さらにググってもリファレンスマニュアルが引っかかってこない罠 C言語ライブラリの関数を3回呼び出すコードと格闘すること数時間。ようやく動いた
まだ不明点は残っている
・#[link(～のkindが何を示しているのか判らない
C FFIの使用例を見るとよく見るんだが・・・
・C言語配列の渡し方が不明
元は
>int p[]={16,9};
>foo(p);
とりあえず
>foo("\x10\x09".as_ptr());
などと書けばデータ上は整合するから動くけどどう見てもスマートな記述方法ではない
・文字リテラルの仕様が不明
↑の表記を得るのに数回試行錯誤した
データの与え方もCStringを使った(＝\x00終端する)方法は出てくるけど、そうではない方法は
中々見つからなかった。結局↑の表記に落ち着いたが
>>689
ありがとう。kind値について書いてありますね。静的リンクだとkind = "static"らしいですが
付けても付けなくてもファイルサイズは大差ないようです。何が違うのだろう Cの配列は第一級の値じゃないからas_ptrが正攻法だと思う
>>689によればFFIで使用できる物として
・#[repr(C付きのstruct
・#[repr(C付きのenum
・box？
・vec
・str
が挙がっているけどCと互換性があるのはこれらのみって事なのだろうか
vecを試してみたら動いたけどextern時に安全じゃないから#[repr(C)]付きのstruct使えなどと言いだした
>>691
マジかよ！確かに文字列は汎用性が高いけど可読性が良くない・・・必要に応じて抽象化しろという事か Rustの側では変更しないけどCの側で変更するような変数ってmutにしないと駄目よね？
あっ、ヤベェ・・・いきなり重大なバグ出してら
× 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"に変換してくれるようなのが欲しい
ちなみに間違っている状態でも呼んだC関数は正常に終了します。まさにunsafeです。怖いです
何か対策を考えないと大事故を起こしそう
要素数2しかないのにstructを書くのはコード効率の点からも可読性の面からもあまり良いとは思えないし・・・
いろいろ試してみたら
>let p: [i32; 2] = [16, 9];
>foo(&p);
ならいけるようだ。コンパイラは何も言わないけどこの表記が適切かどうかは不明
Rubyだと
foo([16,9].pack("i2")) #配列をint2個分の文字列(＝8byteのバイナリ列)に変換
とか書けるんだよなぁ。コストは安くないけど>>694みたいなポカミスは起こらない >>696
何がしたいかよく分からんが
何故に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と対応する型は何かを考えれば良い >>697
いや、isizeはまずいんじゃない？
例えばx86_64だとisize:64bit,int:32bitだし。
libcクレートのc_intならアーキテクチャ毎に適切なサイズになるから
こちらがいいかと。 ついでに言うとFFIするときの型はプリミティブ型以外でも
とりあえずlibcクレートを探すといい。
まぁマイナーなアーキテクチャだと間違ってたりすることもあるから
確認は必要だけど。
>>698
あれ？そうだっけ？
うかっりしてたゴメン
そう言えばCのintはポインタのサイズに合わせるんじゃなくて
アーキテクチャ毎に変わるんだったっけか 調べたらCのintにRustで対応する型はisizeじゃなくてstd::os::raw::c_intだったわ
libcのc_intとの違いがよく分からん
対応アーキテクチャの数か？
>>702
一応libcはno_stdでも動くというメリットがあった気はする。
逆にプリミティブ型限定でも依存ライブラリ増やしたくないならstdなのかな？ >>704
資料が少ないのはまだ普及してない言語では仕方がない
FFIとか皆が頻繁に使う機能じゃないようなものはなおさら
Cの配列とRustの配列は互換があるはずだけど
悪いがその情報をどこから手に入れたかは覚えていないし
信用されても困る(ついさっきも間違えたしね)
場合によっては資料探すよりソースコード読んだほうが早いことも多いし
根気良く調べるしかないとしか言いようがない
あとはFFIみたいなunsafe部分は出来る限り念入りにテストを書くとか 今のnightlyだとclippyビルド出来ないよね？
ビルド出来る最後のバージョンと、それをインストールする方法教えてください
RustのABIについてはドキュメント増やすことはできるだろうけど
それ以前の問題としてCのABI知らないとFFIつらいのでは
付き合ってくれてありがとう
まとめると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があれば一通り出来そうか
vecもas_ptr用意されているし非推奨と言うことはないはず
sliceにderefできるし
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へ入れるようにしたら所有権で怒られて動かなくなった
同じコードでも型によって所有権の移動のしかたが違うのか
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();
あとC関数の引数＆戻り値はmove（ポインターか実値）しないとだめじゃない？
&付けて参照渡しにするのはよく分からない、たぶん未定義動作じゃないかなあ
>>707
clippyは最新のnightlyは**追ってない**けど常に開発中だから
ビルドできるバージョンは常に変わる。
自分の環境のビルドできる最大のnightlyに合わせろしか言えん。
常にclippyを使い続けたいなら環境の方をclippyに合わせないとだめ。
>>709
- 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レイアウトならクレートあるぞ。 Rustだけ覚えればいい時代はまだ来ない
C/C++の知識皆無では
>>716
英語で出る分には多目に見たが、日本語で出るんなら出版社の不買運動だな
どこが訳すか知らんけど >>712
ありがとう、そういうオチか。&で正常に動かないのも納得です
暗黙の変換って便利ですけど理解が浅いとハマる元だったりしますよね
不適切な入力を入れると自分が書いたつもりのコードとは無関係っぽいエラーを出して？？？になったり
>>713
#[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はポインタのサイズらしいしこっちの方が楽かも てかrust覚えるなら普通にc++のスマポくらいは知っとかんとわけわからんだろ。
今日発売の新しいrust本買った人いるのかな
評判良ければKindle出た頃に買おうかなと思うけど
725デフォルトの名無しさん2018/06/27(水) 20:11:21.04
貧乏なのでPacktの糞本を$10セールの時しか買えない
オライリーの本って、オンラインに無料であるやつとおなじやなかったん？
>>727
オライリーの原著は去年12月に発売、今年8月に訳本
今日発売された英語の本は公式ドキュメント(第2版)の印刷版
版元はno starch press >>721
他の人も似たようなこと書いてるけど、Cの配列は結局はポインタに過ぎないから
C側がポインタを求めれば、当然Rust側でもポインタを渡す
あと>>711の
>同じコードでも型によって所有権の移動のしかたが違うのか
は半分正解で半分不正解
正確には、型によって違うんじゃなくて、Copyトレイトをimplしてるか否かで違う
u32はCopyトレイトをimplしてるから所有権はmoveじゃなくてcopyされる
c_voidはCopyトレイトをimplしてないから所有権をmoveしようとする
The Bookちゃんと読んだ？読んでないなら一度きちんと通読することを勧める rustやるのにあったほうがいい前提知識ってどれくらい？
c++とhaskellがまともに出来ないときつい？
いや最低限c++のコンストラクタ、デストラクタの動くタイミングくらいは知っとかないと無理だろ。
>>729
一応deriveでCopy(とClone)を実装すればいいらしいと言うところまでは確認しているのですが
１．std::os::raw::c_voidへ追加で実装できるのか未確認(できたとしてもモンキーパッチになってしまう)
２．別名の型を新規に作る(usizeもしくはusizeへのエイリアスに対するメリットが思いつかない)
なもんで問題なさそうならusizeで良いかなと・・・
というかCのライブラリを使うと>>721みたいなケースは良くあると思うけど他の人はどうしているんだろ
libcのc_voidもlib.rsを見るとstd::os::raw::c_voidと同じみたいだし同様の現象が起きそうです
ググると引数はc_voidを使って戻り値はusizeを使っているようなコードも出てくるしusizeが正攻法なのか？
ちなみにこのコードだとusizeを使ってもmutが不要の警告が出るんですよね。これもそんな事を言われても
困るのですが >>732
えーなんで？rust書いてる人の大半は知らないでしょ こりゃC++まだ覚えてない人はrustなんか勉強してる場合じゃないねｗ
c++といってもRAIIとスマートポインタくらいで良いのでは
知らなくてもtrplなど読めばなんとかなるとは思うが
代数的データ型なども同様
あとは用途次第だけどFFIやるならCのメモリレイアウトくらいは押さえておいた方がよい
そんないい加減なことでいいのだろうか？
ちゃんとC/C++一から十まできちんと理解した方がよいのでは？
それからじゃないとそこがいい加減でRustなんて本当に使えるようになったと言える？
C++完全に理解した人間なんて世界中に何人いるやら
むしろCすら知らないほうが変な先入観とか無くて所有権とかライフタイムとか素直に理解しやすそうな気もする
必要という理由が分からない
言語なんて使いながら覚えていくもんでしょ
>>738
RustはC/C++分かってないと書けない
→C/C++を分かるまでやる
→C/C++がわかってしまえばそもそもRustなんて不要だと気づく
→Rustを捨てる >>730
確かにC++とHaskellが出来きればRustの習得にはそれほど苦労しないだろうとは思う
ただ、理解できるまでにかかる時間量の問題であって、それがないとキツイってわけじゃない
むしろ、Rustの学習するためにC++とHaskellを先に学習するとか時間の無駄
The Bookが懇切丁寧に解説してくれるので前提知識はなくても全く問題ないと思う
ただし、Goみたいな言語と違ってサンプルコード読めばある程度理解できて
何となくで書けてしまうような言語ではないのでThe Bookの熟読は必須
それと、FFIする場合はある程度のCの知識は必要だよ FFIしたいけどCは知らん、とかレアケースだから
そんな心配はせんでいい
別にRustは大して関数型言語じゃないし、Rustのために他の関数型言語から、っていうのは本末転倒すぎるな
全然モナドってないし、関数型言語フレーバーぐらいでしょ
748デフォルトの名無しさん2018/06/28(木) 17:13:53.31
C++は速いがコーディングストレスで禿げる
Rustで若干のパフォーマンスを犠牲にしてでも、いかに毛髪を守れるかがテーマ
>>748
C++程度で禿げてたらRustのコンパイル通らん
Rustのコンパイル通せるならC++でやる方がよいコード書ける
つまりRustは実用にならん。C++er養成ギプスって話ならわかる 結論： やっぱりC++からしっかりやったほうがよい
>>750
違う違う、そもそもRustは不要って結論な
C++勉強してC++そのまま使い続ければいい 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
>>746
単純に最初期のRustコンパイラはOcamlで組まれてたからって事情でないの >>749
C++より潜在的なメモリ管理バグを減らせるってのは十分有用な話では リストとリスト操作をなんで組み込んでくれなかったのかな？
::とか@とかあるだけでだいぶ捗るよね（一部の人にとって）
パフォーマンス面だけで言えば、リンクトリストは問題外だからじゃない？
コンパイルできないおじさんのコードもNLL有効にしたらコンパイルできたから
来年にはrust書けるようになるよ
別にどの言語だろうと所有権を考えるってのは普遍的に必要だとは思うぞ。
rustだろうとc++だろうとはたまた動的言語でもメモリ以外にも資源管理なんて
問題はどこにでも出てくるわけで。
consとかが使えないのはmutとの兼ね合いもあるんじゃないの
あれ完全にイミュータブルリスト向けだもんよ
>>734
なるほど。c_voidの正体はそれでしたか
引数は既成Cライブラリの仕様なのでなるべく変更したくありません
*mutを使うコードを検討していて気がつきましたがRustの生ポインタにfunc1が返すアドレスを入れると
Cと同じ危険を抱えますよね。func3でアドレスがNULL=0になりますからその後に触ると当然クラッシュします > Please never sell Rust to Microsoft!
ちょっとわらった
Visual StudioでRustサポートされないかな
rlsが不安定すぎるのでMSが作り直して欲しい...
rlsもracerもポンコツよね
あんまり力入れてないのかな
intelliJ使えばええやん
インテリじゃない人もタダで使えるよ
支援機能だけ考えるとそうなんだけどさ
手に馴染んだemacsから離れるのは簡単じゃない
intellijをつかうのです…
vsなんかよりよっぽどいいですよ…
>>763
従来のborrow checkerの制約が緩くなるだけだから従来の理解してれば不自由なく使えるはず intelij買ったけどemacs使っちゃうのよね。コード書くのにmouseが必要になるのが受け付けないみたい。
intellijちゃん自力でパースしてるのアホでしょ
CLionもclang使わず自力でやってるけどリリースから随分経つのに初歩的なバグ残ってるみたいだし
>>734の方法だとこんな感じなのかな
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にする必要がありそうだけど 英語は多めに見るおじさん、今頃rustについて必死で勉強して弱点探してるのかな
>>780
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のプロトタイプはないよね？ func1のxはu8だからunsigned charかuint8_tだね
>>782
func1の引数はRustのコンパイラにその型を使えと言われたから
func2の引数はfunc1の返値に合わせた
func3の引数はfunc1が返したアドレスが格納されているアドレス。Cで言うポインタのポインタでABC **z
自分も詳しいわけではないので勘違いしているかもしれないが一応動いている >>784
ダブルポインタだったのか
それなら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)で大丈夫なはず ダブルポインタはあんま想定してなさげな気はする。
俺だったらもう一枚、インターフェイスかましてもう少し楽なインターフェイスにしてから
rustと繋げるわ。
結局C/C++ある程度わかってないと話にならないよね。
経験ないやつはいきなりrust勉強してる場合ではない。
コンパイルできないならまずプログラミングを勉強しなおしたほうがいいよ
FFIの話をrust全体の話に主語をでかくしてるおっさんがおるな
FFIもrustの魅力の一つなのですが？
C/C++知らないやつはいつまでたってもrustを全て分かったことにならない
半人前のまま
別に必要なとこだけ使うスタンスでもいいけど半人前のクセにいっぱしのrustプログラマーヅラしないでね
昔はアセンブラ知らずにC++語るなとか言われてたが時代は変わったもんだな
結局どの言語を選べばいいのかわからなくなった
C++？Go？
rustを視野に入れながらgoという選択はない
kotkinかswiftかgoかってなら分かるけど
分からないなら無理してrust使わなくていいって意味じゃろ
>>802
おー、できた
ありがとう
ローカル関数だと外部変数キャプチャできないし、クロージャだと再帰できないし、
同時にしたいときどうすんのかなーって思ってたから
そんなに使うこともないだろうけど、心に留めときます >>785
ありがとう。なるほどそういう書き方もあるのか。確かに書き換わるので&mutの方が適切ですね
欲しいのはアドレスなのだからと単にアドレス演算子&を付けていました
unsafe外から任意のアドレスにあるデータへアクセスするにはその部分を関数化するようなのかな
一般的に言うプロパティの読み書きをプログラマブルに出来れば綺麗に書けるけど無理なんだろうなぁ
()無しの関数呼び出しとも言えるけどこれが出来る言語は少ない >>805
例えば何に驚いてんの？
Rustの目的はシステム言語だが、目的から乖離してるとこって何？ マルチパラダイムの場合、驚き最小の原則の法則に反するかどうかは実装者の責任じゃないだろうか
抽象的なことしか言わなくなったんだよ
機械語のレベルと相性が悪いし
>>807
半分はその通りだが、それならc++で良くね？になるぞ。 811デフォルトの名無しさん2018/07/01(日) 13:37:40.54
恥ずかしくて外国人には見せられない掲示板だ
そもそもcの呼び出しはメモリ管理モデルのギャップがあるんだから
どうあがいてもc++のが簡易にできるのは当然なんだよ。
>ローカル関数だと外部変数キャプチャできないし、クロージャだと再帰できないし、
ここに関してはクロージャでないものをクロージャと呼ばなければ誰も驚かなかっただろうな。
javaは似非クロージャのことはラムダ式と呼んでるし。
Haskellの「外側のシンボルを参照することによる暗黙的な部分適用」はクロージャと呼ばれてるから
アレが許されるなら少なくともJavaのはクロージャと呼んでいい
>>815
javaのアレは元々クロージャ導入するつもりが、
仕様と実装でクソ揉めて妥協案としてクロージャ
じゃないものとしてラムダ式を作ったんやで。
だから意図的な"クロージャではないモノ"よ。
メモリ管理にgc使うからエンクロージャの束縛の解放に
制限ないから実質クロージャだし第一級関数だけど。 hyper使って簡単なwebアプリ描いてみたけどわりと素直に書けるのね
>>803は本当に満足してるのだろうか
>>802のやり方だとパラメータ増えてるじゃん
こういうのは既存のシグネチャに合わせられないと
単にひとつの関数を小洒落た書き方にしてみましたってだけにしかならないのでは >>818
一応満足してるよ
スッキリ書けないことがわかったから、素直にループで書くか、ローカル関数作って引数で渡そうと思えた
Rustは関数型じゃなくて手続き型だし、特に不満ではない >>819
RefCell使うなら、Rustで書く意味ないだろ >>820
すまん、クロージャでないとできない用途(環境をキャプチャーして高階関数に渡す等)を想定していると
勝手に気を回してしまったみたいだ クロージャじゃないとできない用途って具体的にどういうものなの
想像つかなかったので単純な興味本位
例えば最適化ライブラリなどに目的関数を渡す場合などで
引数以外からパラメータを注入する必要がある場合。
>>822
キャプチャ自体はクロージャで出来るから別に困ってないかな
たまたま再帰させたくなったときがあっただけだから クロージャじゃなきゃできないことじゃなくて、
クロージャの再起呼び出しじゃなきゃできないことを聞きたかった
引数以外のパラメーターを差し込む場合、普通は再起は必要ないよね
1.28はrustdocするときソースコードのlintするようになったんの？
deny属性に違反するソースコードがドキュメント生成時にエラー投げる。
>>822
クロージャがある言語は普通、関数とクロージャ区別しないからその感覚はおかしくないと思う。
でもクロージャの実装上の制約とかライフタイムとかでループで書いたほうがいいと思うコードはある。 >>826
それは、てっきり最初の>>800がキャプチャと再帰を同時に使いたいことがあったんとばかり >>826
ある種の動的なtree構造に対して探索、実行を繰り返すとか。。
やっぱ具体的じゃねーな。。 最近rustの勉強始めたものです
この言語ってstatementなのかexpressionなのかをどういう方針で決めてんでしょう？
ifがexpressionなのはわかったけど、letはなぜstatementなんだろ？
他の関数型言語のようにexpressionでもよかろうに、と思った
古いCで良く在る if ( (let a = f()) != 0 ) {} みたいなのが嫌だったんだろう。
そもそも、変数束縛が値を持つ必然性は無いよね。
>>833
あ、ごめん。大嘘だった。
if let なんてのあったのね… 他の関数型言語のletは随分来歴が違うイメージ。
let x = ... in expはラムダ式の糖衣構文の一種なので関数型なら容易に実装できて便利に使えるのに対し、
rustのletは手続き型の変数宣言の方が近い
schemeのletとdefineが全然意味が違うのを知ってると違和感無い
>>836
それは let a = (let b = c) がだめな理由にはなるけど
>>831の言ってる関数型言語風の let a = (let b = c in d) がだめな理由にはならないよね >>837
ブロック式で let a = { let b = 1; let c = b + 1; b + c }; と書ける
けどミュータブルな変数を書けるからコードが関数型言語風になるかどうかは書き手次第 >>836
>>839
ほー勉強になりました
fnもいまいち釈然としないけど
もうちょっと読み進めてみます あるstructもとに任意のフィールドを追加した別のstructを定義することってできる？
イテレータ系はみんなそれやってる
mapとかfilterとか、元のイテレータ＋変換・フィルター関数みたいな構造体を返してくる
へー今気がついた
strはmutの有無にかかわらずRO領域に配置される
sliceはmutの有無にかかわらずRW領域に配置される
つまり今風のOS上だと
strをポインタ経由で書き換えようとするとメモリアクセス違反
sliceをmut無しで宣言した物でもポインタ経由で書き換えられる
リンカの設定にもよると思うけどマイコンなどで使うときは注意が必要そう
えぇ…安全に使えないじゃん。キツツキに縛りつけてる意味ないじゃんrustの存在意義が…
unsafeの話でしょ
脊椎反射したいつもの人が見事に釣られている
もちろん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にいるはずと思い込んでいるとハマるケースがありそう
任意の場所に配置するアトリビュートとかあるのかな
どうもありがとう。でもちょっとニュアンスが違う。
struct 2d {x, y}
struct 3d extends 2d { z }
で3dが2dのxとyのフィールドと独自のzを持つようなかんじ
マクロで出来ないか精一杯やってみたが出来なかった
元となるstructごとにマクロ作ればできるんだけどそれじゃ意味ないし
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つに
rustからrust-bindgenが吐いたC++のクラス使うのめんどくさいな
ところで、全然話変わるんだけどさ、mutってどう発音してる？
自分は「むっと」ってよんじゃってて、なんか、かっこわるいんだけど。
864デフォルトの名無しさん2018/07/08(日) 13:33:35.86
みゅう太
>>862
いつまでtanakhなんてスパコン詐欺師を崇めるんだろうなこのスレの住人 「nvidiaの倒し方、知らないでしょ?オレらはもう知ってますよ」
実際green500で倒してるんだからたいしたものだよ
WebアプリをRustで書くって、どういう需要があるの？
ラズパイみたいな環境？
車買ったらムダにドライブしたくなるじゃん。すぐ飽きるのに。
あんな感じ。
クライアントサイドとサーバサイドで同じコードが使えるって話ちゃうのん?
同じ言語
だな
それはnode.js環境も同じだが
全部rustって需要はあんまりない気がするけど、サーバ側ならかなりマッチしてる
サーバーサイド → Rust
クライアントサイド → Rust
ブラウザ → Rust
完璧じゃないか
やたらノンブロッキングに拘ってるけど、それが本当に必要な人ってごく一部だよね
人気サービスの中の人だけ
普通はスレッド立てまくりで対応可能だし、たまに台数増やすだけで問題ないでしょ？
真のアイルランド人はノンブロッキングなど必要としないｗｗｗ
>>884
白紙の未来を絶望に染めてやろう。
あれもうかなり古いぞ。
rust 2018で今よりさらに変わるんだぞ。
エラーハンドリングもモジュールもTraitも重要な部分全部かわるぞ。
nightlyで結構実装済みだから現行のnightlyですら違うぞ。
macro 2.0はいいぞ！ >>885
Rust 2018にエラーハンドリングの変更とかあったっけ？
Rust 2018での追加・変更って"module, impl trait, Generators/async/await, macros 2.0, NLL, SIMD"だけじゃなかったっけ？
もしかしてdo catchがstable化されるの？それとも、それ以外で変更があるの？
エラーハンドリングで互換性を崩すような変更があるならかなり痛いんだけど… RustもC++みたいに何年かおきに大きく変更されるの？
こないだ1.0になったばかりな気がするんだが。仕事じゃつかえないな
こないだってもう3年前だぞ
C++が仕事で使えるんだから使えるだろ
てか、Swiftなんてもう4でそろそろ5になるとか言ってるんだぞ
あれが仕事で使えるんだからRustなんか楽勝だろ
実際仕事で使っている人たちがいるのに使えないということは、別のところに問題があるのよ
安定性以前にまともにfibが書けない言語だから仕事じゃ使えない
車輪の再発明を抑止し過ぎるとnode.jsみたいになるからね
やり過ぎはだめってことよな
たかだか一行二行のプログラムのnpmパッケージであふれ、しかも子孫含めた被参照ダウンロードが100万とかざらで、さらにそれがバグっている。
Rust関係ないけど最近ArchLinuxのAURに細工されたパッケージが上げられててほんのちょっとだけ話題になったんだけど
正直自分が使うcrateやそれの依存関係まで含めて全部書いてる人が信用できるかとかソースまでチェックしてる人なんていないよね…？
イカンなぁと思いながら盲目的に使っちゃってるわ(´・ω・`)
CPUのL2キャッシュを作った人の叔母の恋人がテロリストがどうか気にするところから始めたほうがいいな
某ファイルシステムの作者が奥さんを殺してしまってな
904デフォルトの名無しさん2018/07/13(金) 18:29:15.55
怖いなぁ、戸締まりすとこ…
そういえばRUSTという殺し合いをするゲームがありますね
crate以前に詐欺企業Mozillaが信用できないから
Mozillaが詐欺企業なら、Mozilla以上に言う事やる事がコロコロ変わるAppleや
個人情報を収集しまくりのGoogleやMicrosoftはどうなってしまうんだろうなｗ
crates.ioを見に行かないようにして、社内で確認済みのcrateしか置いてない社内リポジトリだけ
参照するような設定って出来るんだっけ？
>>909
cargoはそこらへん腐ってるから無理。
出来はするけどcrates.ioをクローンするツールの開発が
殆ど動いてないしクローンしてもそのローカルリポジトリを管理するツールがない。
ここらへんはoffline modeも絡んでくるけど、
どうせ欠陥機能作って廃止してまた作っての繰り返しでめちゃくちゃになるだけ。 crates.ioのソースを持ってきてローカルに立ち上げてhostsで向ければ出来上がりじゃん
cargoが便利コマンドすぎて、原始的な事がやりづらくなってる問題
便利っつーかモジュラリティーの低い構造になってるだけだろ。。
バカ設計だわ。
>>908
go使うよ。32bitsマシン以上向けならgoで十分だ。 仕事じゃ使えないのは言語じゃなくてお前だって言われてるのに何故goが出てくる
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる
「機械語のレベルと相性が悪い」が "All your base are belong to us" みたいに見えてきた
なんかもう根本的に解ってないなっていう感じからくる面白さがある
モジラに職を奪われたおじさんと
そのおじさんの物まねをするおじさん達のスレ
Cやアセンブラなどの低レベルな処理と連動する場合unsafeを使わざるを得ないが、言語の仕様上普通に書くとunsafe祭りになってしまい
ソースコードの可読性が低下するのが残念。抽象化したくてもこれまた仕様的に完全な抽象化が出来なかったりするし
gcが有って良いならgo。 ない方が良いならnimってことか
まだ学習し始めたばかりでみんなが何を言っているのかよくわからない。
どいつもこいつも適当なことをそれっぽく言ってるだけだから気にしなくておk
>>926
一体いつからNimにはGCがなくなったんだ…？(困惑) >>930
狂人の真似をすれば実際狂人
つまりみんな本物のRustに職を奪われたおじさんなんだよ バトー「つまり、本物の "Rustによる被害者" というのは最初の一人だけで、
残りは全て模倣犯による狂言だったってのか？」
トグサ「ああ。狂言を読んだ者は初めのうちは怒りを覚える。
だが、その理不尽な怒りを抱えきれなくなると、
衝動的に自らが "Rustによる被害者" になりすますことで、
狂言によって植え付けられた怒りを共有しようとしていたんじゃないか」
バトー「実在しない "Rustによる被害者" たちが連鎖するってわけか……。
── 最初の一人はとうの昔に死んじまってるのにな」
>>922
懐かしいなAYBか。文法エラーを直しても通じないのがいいよなｗ
"All of your bases belong to us."
"お前らの卑しいものすべては我々に首ったけ"
ヒドイｗ rustに職を奪われたおじさんなんて実際は存在しないわけだが。。
まあそういう人がいると思った方が幸せな人がいるのは事実。
Rustに職を奪われたおじさんなんて名称なんてどうでもよくて
fibも書けない確かな"存在"がぐちぐち居座るせいで幸せになれない
良かった。Rustに職を奪われたおじさんは居ないんだ。
NLLがstabilizeされたらfibを書けないおじさんもfib書けるようになって成仏できるよ
>>940
「fibを書けないアホ」が「木構造を書けないアホ」に変わるだけと予想 rustでfibが書けたり、木構造が書けることをここまで自慢してくる輩って。。
自慢も何もプログラマを名乗るなら最低限それくらい書けて当然だろ？ってこと
例えば、「俺は数学者だ」とか言ってる奴が微積分すら理解出来てなくて
「でも、因数分解ならできるし」とか言ってたら全力でぶっ叩くだろ？
つまりは程度の問題ってわけ
そして俺はRustでfibや木構造すら書けない奴はどうせ他の言語使ったって
ろくなコード書いてないだろうからそんな奴がプログラマを名乗るなんて片腹痛いわ！と思ってるだけ
このスレに迷い込んだ新規にはfibをどんな書き方をしたらrustで問題になるのか想像もつかない
>56でしょ？
fibがかけなくて5時間も喚いた挙げ句
答えを大量に示されても礼のひとつも言えない
下らない批評をしては論破されて潜伏を繰り返しているあほ
「rustに職を奪われた」「fibを書けない」もこいつの本質ではないんだよな
>>56もそもそも拾い物みたいだしなぁ…… （検索に引っ掛かる ツイッターでrust-lang-ja.orgのドメインが～みたいな話が先月からあるみたいだけど
このスレでは誰も話題にしてない？
fib拾いものなのか
正しくないfibすら書けないおじさんだったか
>>949
Slackでは話題に出てたけど ここでは出てないかな
>>951
流石にplaygroundには貼ったんでしょうね コード4行目で検索 >>952
ほんとだ4行目だけを直接検索したら出た
しかも解決法までご丁寧に解説してあった
>>56はそれも読まなかったのか…
はたまた、読んでも理解できなかったのか… 推察するに日本語が読めなくて、「できない」だけで飛び付いたんだろうなあ
こんな奴でもC++は書ける（自称）って辺りが日本のプログラマの闇だな
955デフォルトの名無しさん2018/07/16(月) 16:24:01.28
軽々しくC++書けるなんて口にしようものなら茂みからマサカリが飛んでくるぞ
C/C++ については、いつまでたっても「書ける」とはいいきれない存在ですね…
仕様が結構複雑だからなのか？
確かにAppleScriptは中途半端に英文風で多彩かつ何でこれダメなのってパターンも多くread onlyに相応しいな
昔はAdaの称号だったと思うが
Eclipse Corrosion使ってるやついないの？
Rustでプラグイン機構を持ったアプリを作る場合、本体とプラグインでjsonでやり取りするのが無難？
それとも動的リンクでいける？
それOSやRustコンパイラがどういうコード作るかによるのでは？
なんとなく出来そうな気はするけど。
コンパイラのバージョンアップでABI変わる可能性があるから
* 本体とプラグインが同じバージョンでコンパイルされてることを保証する
* extern "C" なインターフェースだけ使う
とかの工夫は必要そう
extern "C"してもバイナリ互換のない変更したら同じじゃね？
本体側からメモリマネージャをエクスポートして.dll/.so側に使わせるってできたっけ
crates.ioで中身のない、クレート名の予約だけの人増えすぎじゃね？
rustはweb周りをもっと押したほうがいいな
新しいのに飛びつくのはあの連中(俺も)だからな
未発達かな
hyperやactix webがあるじゃん
async awaitベースのtokioがでるまで待った方がよさそう
今日からRustやってみる
C言語とPythonとSchemeがちょっとずつしか分からないけど大丈夫かしら
Rustで本格的にプログラミング覚えた人っていますかね...？
C++知らないと窮屈なだけで何でこんなもんが必要なのか意味不明じゃね
Ready at Dawn Studiosって言うアメリカのゲーム会社が今後の開発は全てRustでするってよ
新しい言語だからrustからって人はなかなかいないと思うけどおすすめだな
根気は必要だけど
初心者スレ無いようなのでここで質問させてください
トレイトって他の言語で言うところのインタフェースみたいなもん？
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できるインタフェースと違って
既存の型に対してあとからいつでも実装を保証？できる
のがトレイト？ Selfが使えるかは言語の特徴でtraitの特徴じゃないんじゃない
あと外部で定義されたtraitを外部で定義された型には実装できない制限がある
sheep.nakedがfalseなのはバグじゃまいか
お前らそれよりtraitがコンストラクタ持ってることにツッコめよ。
Ready at DawnってCSやってたけどあれもrustで書くつもりだろうか。
>>905
gowにはrustlungちう病気が出てくるぞ >>988 ありがとうございます！もっと勉強します >>990-992
そこなんですよ
コンストラクタをトレイト側にかけちゃうのが何か凄み感じるんですよ
インタフェースじゃせいぜいObject型で返すくらいのもんでして インターフェースは型だけどトレイトは型じゃないって気付いたときに理解が進んだ音がした
lud20230202120217ca
このスレへの固定リンク： http://5chb.net/r/tech/1518347244/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「Rust Part5 」を見た人も見ています：
・Rust Part7
・Rust part6
・Rust Part6
・[FPSサバイバルMMO] Play Rust Part34
・【ニューギン】CR CYBORG009 CALL OF JUSTICE Part5
・Levi Strauss & Co.リーバイス/Levi's part 175
・次世代言語Part7[Go Rust Swift Kotlin TypeScript]
・Rust part9
・Rust part13
・Rust part12
・Rust part10
・Rust part16
・Rust part18
・Rust part11
・RUST ２日目 part3157
・CRUSTスレ Part.12
・RUST その２ part3158
・CR牙狼 GOLD STORM翔 Part5
・C vs C++ vs Rust Part.3
・C vs C++ vs Rust Part.2
・DANCERUSH STARDOM Part7
・DANCERUSH STARDAM Part9
・DANCERUSH STARDOM part2
・DANCERUSH STARDOM Part14
・NOCTURNAL BLOODLUST part12
・NOCTURNAL BLOODLUST part9
・NOCTURNAL BLOODLUST part8
・【雑談】avast！Anti-Virus Part1
・DANCERUSH STARDOM プレイヤースレ Part8
・【PS3/PS4】PlayStation Plus Part 298【VITA】
・【PS3/PS4】PlayStation Plus Part 251【VITA】
・【PS3/PS4】PlayStation Plus Part 274【VITA】
・【PS3/PS4】PlayStation Plus Part 276【VITA】
・Just Cause/ジャストコーズ 総合スレ Part9
・【PS3/PS4】PlayStation Plus Part 284【VITA】
・【PS3/PS4】PlayStation Plus Part 272【VITA】
・【PS3/PS4】PlayStation Plus Part 254【VITA】
・【PS4】PlayStation Plus Part 355【PS4/VITA】
・【PS4】PlayStation Plus Part 354【PS3/VITA】
・【PS3/PS4】PlayStation Plus Part 279【VITA】
・【PS3/PS4】PlayStation Plus Part 267【VITA】
・【HMD】Oculus Quest Part.27【VRStandalone】IP付
・【HMD】Oculus Quest Part.16【6DoF VRStandalone】
・Levi Strauss & Co.リーバイス/Levi's part 173
・Levi Strauss & Co.リーバイス/Levi's part 157
・Levi Strauss & Co.リーバイス/Levi's part 167
・Levi Strauss & Co.リーバイス/Levi's part 171
・【HMD】Oculus Quest Part.19【6DoF VRStandalone】
・【PS4/XBOX】RUST Console Edition Part 4【サバイバル】
・【iPad】REFLEC BEAT plus Part58
・【SUBARU】WRX STI/S4 (VA) Part13５
・【BrownDust】ブラウンダスト part25
・【BrownDust】ブラウンダスト part35
・iPhone 8/8 Plus Part5©2ch.net
・次世代言語11[Rust Swift TypeScript Dart]
・【TLoU】The Last of Usシリーズ Part95
・【Russian】システマ Part 4【Martial Arts】
・Just Because！ （ジャストビコーズ） Part.35
・【PS4】Ghost of Tsushima ゴーストオブツシマ Part165
・Rust part24 (225)
・Rust part23Rust part21Rust part21 (5)
・Farthest Frontier Part5
・Huawei P10/P10Plus Part5
・DANCERUSH STARDOM Part24
18:28:00 up 5 days, 3:36, 2 users, load average: 9.28, 8.59, 8.34
in 0.0609290599823 sec
@0.0609290599823@0b7 on 112508
|
