公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust
Web上の実行環境
https://play.rust-lang.org
前スレ
https://mevius.5ch.net/test/read.cgi/tech/1507970294/
Rust Part5
レス数が1000を超えています。これ以上書き込みはできません。
公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust
Web上の実行環境
https://play.rust-lang.org
前スレ
https://mevius.5ch.net/test/read.cgi/tech/1507970294/
関連スレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/
スレタイと本文を簡素にして、リンクを追加
ワッチョイの有無は話し合って決めてくれ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
http://mevius.5ch.net/test/read.cgi/tech/1514107621/
https://blog.rust-lang.org/2018/02/15/Rust-1.24.html
やはりRustはクソの言語未満
良識ある人はきちんとわかっている
このブログが良識のある人の記事に見えるってのはある意味すごいと思う。
マジで言ってんの？ネタじゃなかったから単なるバカだよ？
Nimやったことないんだけど、このブログ書いた奴のせいで
俺の中でのNimへの風評被害が超激しいんだけど。
ネタにマジレスしてるはてな民多くてワラタ
2chもはてブも変わらねえな
インターネットはこうでなきゃな
正しくRustとNimを比較してRustにいいとこなどないと論理的に談断じてる
そこまで言うなら反論記事よろ
>>10
マジレスも何も事実じゃん
Rustオタは身内で盛り上がってるだけだからな
まあできないんだろうね。言語未満Rust
それを布教してるやつらは金子先生の鋭い指摘で詐欺集団だと暴かれているのに
信者は人格攻撃して矛先を反らすだけ
よっぽど反論できなくて悔しいんだろうね
あと、書いたところでこっちにメリットがない。
具体的なメリットを提示してくれるなら書くかも。
反論記事なら雑だけど一応あった。
書いた後であまりのバカらしさに自ら記事を消したらしい。
アーカイブは残ってるから、それでも読んでろ。
http://ubnt-intrepid.hatenablog.com/entry/2017/10/03/135742
書いたらモジラからお給金出るでしょ
>>17
意味のあるプログラム書こうとしたら
とたんに借用とかでコンパイル通らなくなってまともにプログラミング出来ないものがプログラミング言語と言えるのか？
まあMalbolgeやBrainfuckがプログラミング言語と呼べるキ◎ガイならRustもプログラミング言語かもね
本当はRustが使い物にならないことを察してしまったけど
それを言うと信者に突撃されるからぼかして消しただけでしょ
表向きの理由で全消しするのは不自然だから
なんとかコンパイルだけ通したような
保守性も何もない個人が脳トレで書いたようなものばかり
まともな製品として書かれたコードはGithubにも見つからなかったぞ
ソースコード公開してるものがそうなんだから
企業がRust使ってると称するなにかは実際にはRustなんて使っておらず
適当な別の言語で書いてRust使ってると言えばモジラから金が出る
そういう仕組みと考えるのが自然な訳だ
あと、GitHubのまともなコードが見つからなかったって点も
どの辺がまともじゃないのかについてはコードでは示せないと。
それで自分の言葉に説得力があると思ってるのが不思議でならないんだが。
あと、俺にも「モジラからお金もらう方法」を教えて。
ホントにもらえるんだったら絶対に反論記事書いてあげるから。
ParseError が std::error::Error を impl しなくなったのは何故だ……
なんで取り下げられた記事に反論しないといけないの？
取り下げたってことは「この記事は間違いだった」というメッセージでしょ
モジラから金貰う方法とか俺に聞くなよ
モジラのページにある自称Rust使ってる企業に聞いてくれよ
な。Rustなんて使うからそうなる
一貫したインターフェースを提供することすらできん言語だ
論理的な会話ができてないのはどちらなんだか
レスしてもらったのはありがたいが
俺はお前さんから見ればRust信者だわ すまん
元よりどんな言語使ってもインターフェース変更はある
今回は、追従する作業に五分も掛からんかった
後はテスト流して終わり
インターフェースの変更が出来ないのを理由に
開発が鈍化されるよりマシだと思うよ
Nimの人のブログにもあったが、ロジックと関係ないスコープ切りが必要なせいでコードがスパゲッティになるとか、
ハッシュテーブルと所有権がコンフリクトして動的計画法が書けないとか
所有権のせいでそもそも循環グラフ書けないとか
いくらでもクソな所出してやれるが？
結果ロジックにバグが増えたりインターフェイスの非互換が発生したりするんだよ
だから致命的に壊れた言語って言ってる
だから信者からの突撃回避だろってそれ
Nimのブログ記事にブコメしてるのもみんな信者かMozillaの工作員なんですね
これはすごく実用的な割り切りだと思うんだけど>>35はまた意見が違いそう
>>35は後者、Rustは前者の立場をとっていて単純に趣味に合わないだけなんだと思うが
そうなるとNimはRust以上に普及しててまともな製品がリリースされていないと矛盾しないか
個人で作ってる言語と
国際的詐欺会社がバックにいるのとじゃどうしても個人が負けるわ
PHPより酷く感じる
別スレもあるし
世界的にやっているにもかかわらずそのことに言及してるのがこのスレにいる一人だけという時点で信憑性も何もないというのがね
もったいない
あのMercurialもGitにボロ負けしてるから、資金で殴れば下るだろうって狙われたんだろう
お前しか「モジラに金もらってる」なんて言ってる奴がいないんだからお前に聞くしかないだろ？
バカなの？脳味噌に草でも生えてんの？
あとGitHubの件はスルー？コード例はやっぱり出せないの？
動的計画法はRustじゃ書いたことないから分からんけども、書けないのはお前だけじゃないの？
「書けない部分を具体的にコード例で示して」毎回言ってるよね？
「同じことを何度も言わせるな」って注意されたことないの？今注意したからもう同じこと言わせないでね。
循環参照についてはRcとWeak使えば書ける。可変にしたければさらにRefCell使えばいい。
それも何度も言ってるよね？ボケてんの？草以外に花も咲いてそうだな。
RcやRefCellが気に入らんならお前とはスタイルが合わないってだけの話だ。去ね。
書けてるやつのライブラリを使えばいいだけの話では？
自分で書くよりまずライブラリを探す。今の時代はこれが常識だろ？
車輪の再開発は勉強するときだけやってればいいんだよ。
「書けないもの」の「ソースコード用意しろ」ってひどい矛盾したこといってるの分かってます工作員さん？
コンパイルエラーした状態のままでいいから見せろって言ってるの。
あと、「C(他言語でも可)だとこう書けるのに。。。」っていうソースも載ってればベスト。
分かってもらえます？
これで満足？
取り合えずコンパイル通すだけならすぐ出来たよ。
http://play.integer32.com/?gist=9333d5344adb9cdf5ef8292a20ec6c24&;version=stable
http://play.integer32.com/?version=nightly&;mode=debug
http://play.integer32.com/?gist=e73044b8a25fa1c2403ee1ccb74356f6&;version=stable
http://play.integer32.com/?gist=d9f081dd40e2e0d06e224dc0e20ee41c&;version=nightly
まぁ、それでハードルが下がるのならそっちのほう良いとは思う。
けど、その程度で前に進めなくなるならすぐに別の問題にもぶち当たってやっぱり投げちゃうと思うよ。
そういう奴らはRustはともかく、多分C, C++でも自分で書いたバグに潰されると思う。
結局GC付きの言語でしか書けないんじゃない？
念のため言っておくけど、GC付きの言語を批判する意図はないよ。
おれTypeScript好きだし、Goも嫌いじゃない。
型の方はScalaとかSwiftとか別の言語で似たようなのがあるから参考にできる文献多そうだけど
特にfuturesクレートを初めて読んだときは?!??!?ってなった。
Rustは良い言語だけれど「難解」というところだけは否定できない。
そういえば、結局「モジラからお金もらう」方法教えてくれなかったなぁ。
お金欲しいのに
Quantumが出たあたりで流石に取り下げたようだが
モジラは詐欺会社と言い張る一人だけが猛烈に頑張ってる
モーレツに墓穴掘ってるけどね
そういう人たちはC/C++のコーディングで余計なことまで心配しすぎてストレスかかってるんだよ
かわいそうな人たちなんだよ
てっきりhtml5everくらい複雑なコード組もうとして悩んでたのかと思ってたけど
まさかのフィボナッチ数列でつまづいていたとは予想外だったわ
そういえば今年のstackoverflowのアンケート結果っていつ出るんだろう？
そもそも毎年いつ頃出てるのか知らないんだよね
これでRustが愛され言語ランキング1位から順位落としてたら
また「ついにクソ言語未満のボロが出てきたな」とか騒ぎだすんだぜきっと
「工作ブーストが切れたな」とか言ってたからそういう方向になるんじゃね
コードをめぐる議論を省き、メンタルの負担を減らし、プログラマを参加しやすくする
http://www.publickey1.jp/blog/18/rustrust_style_guide.html
C++みたいに全部unsafeな言語よりは安全
C#ならWindowsフォームアプリケーション
PHPならWebアプリケーション
Pythonなら機械学習
Rustは？
キチガイ以外書き込まないでね
隔離（）スレに勢いで負ける言語があるらしい
コンパイルできない厨が最後のコンテンツだったのに…
ごく単純なコードで使う分には中身の要素に最適化されてるけど、
それ使って配列を作っただけで最適化されなくなる
こんくらいでゼロコスト抽象化とか言ってるの？
typeでは新しい型作れないし、
結局新しい効率的な型を作る方法さえないんだな
トレイトの特殊化でも無理？
ゼロコスト抽象化はトレイトやジェネリクスを言っててnewtypeパターンは関係ないと思うゾ
Cに比べたらC++もRustもGoもランタイムの分だけメモリ使用量は増えるよね
C++にはランタイム存在しないとか大笑いなギャグを素で言う輩は知らん
https://mag.osdn.jp/18/02/17/163000
> ビルドの速度は改善するが、出力されたバイナリの実行速度は少し遅くなるとしている。
型推論とかボローチェッカーとか大変だろうしと思ってたが、並列コンパイルで早くなるのは助かるよね
自称低級言語があるらしい
速度を求めたリリースビルドは並列なしに切り替えられる低級調製可能なコンパイラすごいよね(棒読み
完全にターゲティングに失敗してるよなこの言語
性能無視して生産効率だけを求めるならボローチェッカーとかunsafeとかトレイトとか面倒な言語仕様はマジ辛い
ただ緩く書きたいだけならSwiftとかGoの方が絶対良いよな
ランタイムが馬鹿でかかろうが、goroutineが冗長コストだろうが、言語仕様が楽なそれらは生産効率が断然良い
http://rosie.5ch.net/test/read.cgi/liveplus/1519704223/l50
0100デフォルトの名無しさん垢版
2018/03/01(木) 00:41:00.21fn 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してくれないものでしょうか
副作用なくて同じcrate内に処理があるなら最適化で消えるのでは
>>104
https://play.rust-lang.org/?gist=548477e609761c03d062880ceebec28a&;version=stable
MIR見る限りあるっぽいです(これ副作用ないですよね？)
MIRに対する最適化は現時点ではそれほどやられてなさそう
Debugなのを忘れた状態で見てcall nanka2があったので駄目かと思っていましたが
Releaseだと消えるようですね、すいません
https://twitter.com/tanakh
最適化の話だから言語仕様では決められてないと思う
やっぱクソ言語じゃん
Haskellくらいだろ
https://twitter.com/tanakh/status/907645555467104256
Rust評価高いくてGoは糞って評価だな。
「CはPythonよりも低級言語」これC言語を蔑んでる意味で取るアホなんているの？
可能ならその理由はなんでしょう？人材が足りていないというのは存じ上げていますが
言われたことやるだけなら可能じゃね？
今更だけどこれ書いた奴もブコメした奴も誰一人rustまともに使ったこと無さそうで草
少なくとも書いた奴はまともに使ってないだろうな
matchの仕様が理解できないからって仕様バグと決めつけてるアホだし…
mutが面倒ってのは分からなくはないんだが、かと言ってどうするの？
不変のほうをconstにすると次はconst地獄になるだけだよ
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
mutの記述が面倒なのはワザとやってるという点もあるし…
珍しいご意見ですよね。
よくよく考えるとRustも呼び出し側にmut付けること自体は必須ではないんだよな
所有権を借用するために大抵は&mutを書かされるってだけで…
渡す変数の型がもともと&mut Tだった場合は書かなくてもいい…
Rustの場合は呼び出し側で&mut書く羽目になる経験が多かったので
俺が勝手に「可変にしたければmutを絶対に書かないといけない」という勘違いをしていただけか…
でも、書かされた方が読むときには分かりやすいので個人的にはこっちの方が好き
俺自身がNimはどうしても好きになれなくて不満点を挙げたつもりが自ら墓穴を掘ってしまった感じだな
一般的にはNimの方がよっぽど簡潔で美しいのかもしれない…
ただ単に俺の感性の方が狂ってるだけっぽいな…
変数とは何かと言えば
スタック領域の特定のメモリ番地に名前をつける行為でしかなく
所有権の委譲って何かと思えばそのメモリ番地の名前を変える行為でしかない
クソ
ARMポートあったよね。Thumbコードも吐けるのかな
とか思ってググっていたら先人がいた。考えることはみんな一緒かｗ
Rustでゲームエンジン作ればワンチャンあるんじゃないかと思い始めてきた。
goより高度なこと出来るならweb開発も全然苦じゃないように思うんだけど
何かしらweb開発に向いてない要素あんるんかな？
webのバックグラウンドで動いてるrestAPIサーバに向いてない要因は何かあるのかな？
SPAとかマイクロサービスとかの構成でjavaとかgoとかの代わりに成り得るのかなって。
軽く触っただけなんでデバッグなどの開発環境の事は未知数
無理
>>164
個人的には静的言語ならどれも大差ないと思ってるんだけど、
その方面では全然注目されてないように見えたから何か原因があるのかなって。
以前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で自動化しても良い
>>166
goのシングルバイナリ良さそうだよね。
全然分かってないんだけど、rustでもちょびっと頑張れば
クロスコンパイルできるって認識なんだけど間違ってるのかな？
RustってわりとカジュアルにC製のライブラリをdllとして利用してるからそこが未知数
まあそれらのライブラリを使わなきゃいいんだろうけど
>>168
そうか。シングルバイナリじゃないとクロスコンパイル先の環境で動かすのは
なかなか大変そうやね。やっぱその分野はgoが強いってことなんね。
そういう観点なら学習コストが高いのがじゃくてんだと思う
個人的にはGCありなしの差が大きい気はする。
特にweb系はGCがあって当たり前だから
急にlifetimeとか言われても…ってなりそうな。
C/C++だと結局脳内でlifetime管理してるから
そこの学習コストは相対的には低い。
おれもGC有り無しはでかい要因だと思う
今までJS, Ruby, PHP, Java辺りしか使うことのなかったWeb屋にとっては
「メモリ管理？なにそれ？おいしいの？」状態だろうし…
>>172
なるほど。確かにWEB系だと短い納期＋人海戦術で乗り切ることも多いから
そういうのには辛そうだね。でも言語仕様的にWEB(の裏のサービス)が不得意という
訳では無さそうだから、細く長くやるようなサービスなら導入もアリっちゃアリという認識でいいのかな。
>>173
そだね。なんにもわからんわw っていうかWEBやっててGCであんまり困ったことないかも知れん。
困ったことがないことに起因して難易度が上がった言語を「使いたいです」って提案するにはちょっと強引さが必要そうやね。
今、初心者用の練習問題やってるんだけどメモリの管理なんて全然出てこない。
みんなどうやってRUSTの勉強してるの？やっぱり何か動くもの作ってみるのが早いかな？
早くstableで動くようになってほしい
ん？君もしかしてWeb屋なの？
そして「GCなし」ってのがどういう状態かよく分かってない感じ？
C or C++のご経験は？
プロなら自分で管理するべき。
むしろGC無い言語の方が循環参照の時の解放が面倒、C++でもweak_ptr使う必要出てきたり
gcあったって結局outofmemoryerrorになるなからなぁ。
だったらrustのようにコンパイラが所有権やライフタイムをチェックしてくれるのはいいと思う。
けど学習障壁高過ぎとも思う。
Nodeはよくメモリリークが問題とか言われてるけど原因はそこなの？
グローバル変数を平気で乱用するほど皆バカなの？
イベントハンドラの解除忘れとかじゃないの？
忖度しすぎ言語の称号を与えたい。
コストかけられるなら規模の大小関わらず大アリだよ
ありがと。ちょっと試してみる。
>>176
ぽんこつWEB系IT土方だよ。javaとjavascriptくらいしかやってない。
javaでは走ってるGCがrustだと黒魔術によって必要ないっていう認識やで。
>>185
そうか。大アリか。ありがと。
イベントハンドラ解除は他言語でも明示的に書く必要ある
だけどクラスのデストラクタ・ファイナライザに書いといて各スコープで変数の寿命をちゃんと管理するコーディングの基本を守ってるだけで問題ないと言える
ここはRAII使えるC++やRustが最強、なんせ何も書かなくてもスコープから外れたらそれぞれデストラクタ・Dropを呼んでくれるんだし
次点でC#のDisposeとusingなどの専用構文、Javaはtry..finallyあるから及第点
でもグローバル変数だとそんなの働かない、プログラマが仕様とにらめっこしながらリークに気を使わないといけない、めんどい
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内Cのリソース確保を呼んだなら同じく解放処理も呼ばないとリークする
いや、ならねーよ
内部でunsafe使ってるからunsafeになるなら関数にもunsafeつけて前提条件つけないといけない
今やってるサンプル問題はその辺り無しでも解ける難易度だから
rustのつらみがイマイチ分かってないんだよね。
何個か前のスレにあった木構造っていうのをやってみればええんやろか。
難し過ぎるやろか。
>>190
こんなぽんこつに教えてくれてるんやからありがたい話やで。
JavaもC#みたいにできるようになりました…
どうせみんなKotlinとかScala使うからいいけど
webか目的ならwebアプリを作るべきでしょう
使いもしないデータ構造やアルゴリズムなんて判断基準にならないでしょ
んで未だにstrutsとかオレオレフレームワーク強要するんだろ？
rustupを実行する前にVC++をインスコしろとか書いてあるし
特にRust以外のツールとCargoの連携について説明されている記事はほとんど見あたらない
ローレベルではユーザーツールやアセンブラ、リンカとビルドシステムの連携は必須だからな
Cargo前提のRustだとシェルスクリプトやバッチファイルでビルドというわけにも行かないし(それらに必要な情報も同じく少ない)
既成のCライブラリやクレートを使う記事はちらほらあるけどそれらが使えないケースだと参考にならない
このへんで役立ちそうな記事って今のところこれくらいしか見つけられていない
ttps://nkon.github.io/Rust-embedded/
もっともRust抜きでも最近は高レベルのフレームワークを使っていたりOS上での動作だったりするからローレベルの情報は減少傾向だけど
https://www.wantedly.com/projects/97207
ごめん、募集終了してたわｗ
どちらにせよ気概は応援する
C++からの乗り換えならビルド時間の削減が一番効果あるかもね
統合しようとしているらしい
Rust, Elixir は注目されてる
rustでおもちゃのOS書いてる(た)んだけどローレベルな部分にも適してるみたいなことを謳ってる割にcargoがほんとクソなんだよなぁ
またcargoがクソって話か…別にそれほど使いづらいとは思わないんだけど…
(使い方に関する情報が少ないという意味で使いづらいという意見なら分かるんだけど…)
どこら辺がクソと思ってて、どうなってれば満足なわけ？
なんだか実現不可能なくらい賢いツールを「ないものねだり」してるように聞こえるんだよね…
というわけで、実在するツールで最も理想に近いツール(もちろん他言語のパッケージ管理ツール)の例を挙げてくれる？
しかも言語の垣根を越えて使いやすい奴
システムプログラミング用を謳っているんだから
「Cやアセンブラで生で動くプログラムを書いたことがあるんだけどRustに興味がある」
位の人を対象にしたチュートリアル的な物が欲しいな。もちろんある程度実践的な内容で
そういえば調べている中でLチカのウェイトにビジーループを使っているコーディング例がいくつも出てきた
自分はタイマと割り込みを使うのが普通だと思っていたんだけど(勉強するという意味でも)最近は違うのかな？
「〇〇というツールがあって、××が出来て便利。それに比べてcargoは…」みたいなさぁ…
「使いやすい奴」とだけ書かれても「使いやすい」の基準がさっぱり分からん
ごく普通に使うぶんには俺もディスるほどではないとは思うよ
ただOS書いたりみたいな部分では不満を感じることが多かった
例えばビルドスクリプトとしてのbuild.rsがビルド前のいわゆるpreしかなくてpost的な使い方が出来ないとか
カスタムターゲット書くにしてもlinker-flavorとかそれに対応するリンカに渡されるオプションの一部とかがコンパイラのソースにハードコーディングされてるんで制約ばっかで柔軟性が低いとか
> (使い方に関する情報が少ないという意味で使いづらいという意見なら分かるんだけど…)
自分で書いてるじゃん
タイマ割り込みは環境依存度が高いから、サンプルとして適さないんじゃね？
nightlyすぐコンパイルエラーになるよね
まあだからnightlyなんだけど
ironは今はメンテされてないし、とりあえず業務で簡単なAPIサーバー構築時にはrocket使ったわ
ニコニコみたいな机の上でのお勉強しかできないバカばっか揃えた結果
クソみたいなサービスしか作れない技術力のない会社がRust使う選択したなら、
逆神でRustつかわないのが正しい選択って公になったようなもんだな
神の書を書いてるから、一流の伝道師！
開発用DB使うタイプ、モック使うタイプどちらでもいいんですけど…
典型的な机の上のお勉強だけ得意な人やん
そゆとこは正直で良いと思うが、プログラマとしてはクソだな。
これは、日本の大企業から、猛者を数十人集めて、
欧州委員会に問い合わせながら作った本
C++11/14 コア言語、江添 亮、2015
それに比べて、江添はたった一人で作ったのじゃないか？
超人的すぎるやろw
実力はないけど口が達者だから信者が多い
芸人向き
そのうち討論番組とかでテレビ出演とかしちゃいそう
一人で書けるのは確かに並大抵じゃないだろうが
一人で書けなきゃそれはそれでヤバイ
Rust江添の今後に期待
だからニコニコごときが選択したってことは使えん技術ってことだろ
ネトフリとかが採用したら考えるが
ニコニコ←負け組
火狐←負け組
Mercurial←負け組
泥箱←個人情報お漏らし
採用する気にもならん事例のオンパレード
そういやここもお漏らししたっけな
資源の無駄だからな。当然の結果
https://github.com/dwango
インシデントが増えるw
本質はそういうところじゃないってことがよくわかる。
じゃあ本質はどこにあるんだよ？
自分には分からないからってだけが理由でそうじゃないと決めつけるのは勝手だけど…
簡単なんだよ。
そのトレードオフをどれだけ解決できるかが本質。
安全に作るのが簡単ねぇ…
簡単だったらGoogleがバグ(セキュリティホール)の発見に
多額の報奨金を出すのはおかしいとか考えないのかね？
君にとっての"安全"の基準が分からないんだが…
グーグルにとってみたらそっちのがよっぽど楽、つまり開発効率がいいからでしょ。
理解不足の人がいるようなのでもう一度言うけどトレードオフの問題だっつーの。
極論だな
開発効率を無視するなら安全に作ることは可能ってことだろ
開発効率を無視するってのはつまり開発期間が無限大と仮定するってことだぞ
開発期間が無限大でなければ安全に作ることが不可能なら
それは実質、安全に作ることは不可能って事と同義だからな
結局言いたいことは"開発効率・ランタイム速度"と"安全"がトレードオフの関係にあり、
それをいかにして解決するかが本質ってことだろ
で、その"解決"が何を指すのかっていう一番肝心な部分が抜け落ちてるぞ
"トレードオフの均衡点をどこに置くべきかを探る"のが解決なのか
それとも"トレードオフの関係自体を壊そうとする"ことが解決なのか
あるいはその両方か
あと、Googleは開発効率を優先して報奨金を出してるわけじゃないだろ
そもそもリリースした後のものは開発ではなく保守なんだから
あれは完璧に安全なものを作るのは不可能だから苦肉の策として行ってるだけ
てゆーか、ツッコミどころが多すぎるんですけど…
もちろん
Erlangは状態中途半端にブッ壊すだけだし
Scalaなんてもはや新規で使うところどこにもねえだろ
バカじゃね？
Rustがその解決になってるかって観点がどこにもない
トレードオフの落としどころとしてRustにはなんの実績もないし、CやC++と周辺ツール合わせた環境に勝る性質もなにもないって言ってんの
ValgrindやCoverityみたいなツールに比べた優位性あるの？
ただ書きにくい言語がひとつ増えただけじゃん
職は見つからなかったんだね
"解決"が何を指すのかを聞いているのにそれには答えずに
Rustは"解決"していないとだけ答える…
会話が噛み合わない…どうすればいいのか…
君がそれを実績として認めないってだけだろ
ブラウザを一から実装しなおして、それが大きなバグを出すこともなく
Chromeと同レベルの実行速度を実現してるってだけでも充分に実績として認められると思うが。
Chromeに比べればシェアは少ないがそれでも世界中で数百万という人間がFirefoxを使ってるんだぞ
数百万はかなり適当に発言した
実際はどれくらいなんだろうな？
せめてchromeと同じシェア取ってから言って欲しいもんだ
0257デフォルトの名無しさん垢版
2018/03/31(土) 14:32:47.34Electronって言うんだって
"せめて"でChromeと同じシェアなのかよ。ハードル高すぎだろ
そんなのどんな言語使ったって数年じゃ無理だわ
もちろんChromeと同じC++を使って作り直しても無理だわ
どうやら君の御眼鏡にかなう言語はこの世のどこにも無さそうだな
ならchromeのシェアを奪うのなんてすぐじゃないか
本当にRustにそれだけの性能があるなら
やはり危険度はシェアで決まるんじゃないだろか。
そもそもあれだけ複雑で奇怪で大きなソフトウェアにバグが無いわけないし。
いやもちろん、HaskellやJavaやJavascriptのような安全な言語で書かれていれば一切のバグは無いんだろうけどさ。
じゃあ、Rustのような安全な言語で書かれてればバグは無いんだろうけどさ。
でも、書き直すったってそもそも発祥がKHTMLだしな。
Googleは出来損ないのブルドーザーみたいなもんだ。
まあスレチだが
>Rustで書き直したら安全で高速なプログラムが簡単に書けるんだろう？
誰もそんなこと一言も言ってないだろ。勝手に曲解しないでほしいな
C++よりはRustの方が設計が良いってだけ
そう言ったら次は"C++より良いって言うんならC++で書かれてるChromeより
Rustで書かれたFirefoxのシェアが少ないのはおかしい"って言い出すんだろ
既存資産はC++のほうが何十倍もある。資産が少ないってのはそれだけで不利だ
言語設計はダメだが資産の多いC++か、言語設計は良いが資産の少ないRustか、
どちらを選ぶかは人によって意見が変わるところだろう
資産の問題に関しては時間が解決してくれるかもしれない…希望的観測に過ぎないが…
>ならchromeのシェアを奪うのなんてすぐじゃないか
すぐなわけないだろ。
ブラウザを選ぶ基準なんて数え切れないほど色んな要素が絡み合ってるんだよ
その中には"なんとなく、みんなが使ってるから"なんてしょうもない理由も多く存在する
全ての人間が合理的な判断を下すわけじゃないんだ。そんな単純に事が運ぶわけがない
だから、ツッコミどころが多すぎるんだって…
むしろ危険。
ライブラリがリークについて何も考えていないんだもん。
曰く、ライブラリがリークするようにできてるから、一定時間で再起動とか。
そんなのが多すぎた。
「モノは良いけど使い手が少ないせいで流行らない」ってか？
使い手が少ないのはものが悪いってことだろ。残念でした
モノはいろいろと微妙だがCやC++と比べて強烈な利点があるから、リリースがRustと同じか遅いくらいなのに流行ってるだろ
Rustはどうなんですかねえ？
かまってほしい爺さんに、かまってほしい爺さんみたいとかやめてくんない？
あんた人の心あんの？
0275デフォルトの名無しさん垢版
2018/03/31(土) 21:14:47.08逆にどんなに良いものでも流行ってなければ選外になるのは事実よね
PHPが流行ってるのは時代的に残念な背景があるとはいえ、
Goが流行るのは明確な理由があるんじゃないか？
せめて日本語で本が出る程度には流行って欲しいが……
今のRustに足りないものってなんだろうな
RubyのRailsみたいに、ある領域のキラーフレームワークみたいなのが欲しいが
Rustがそれを作れる領域って今のところWebAssemblyくらいしかないんだよな
しかもそのWebAssemblyも、GCが入ったらGoとの立ち位置が逆転するし
Googleって会社も初期メンバーこそキレキレの人間だったのかもしれんが
ブランドイメージが先行しだしたころから
そこにはそこに憧れて集っちゃった凡人がうじゃうじゃだということを忘れてはならない
ゼロ抽象化みたいな機能ブランドに憧れて集まっちゃった凡人がうじゃうじゃだよね
Rustを書ける奴は別にCやC++書くのに困らないって
イカれた習得難易度に作ってしまったのがそもそもの失敗
Rustのターゲットは別にRustなんて使わなくてもいいかそもそもRustを使えないかの二択
ドンピシャなターゲットが存在しないから流行りようがない
>RustはCやC++を書くのに疲れた人のための言語という位置付け
これは事実だけど、C++より簡単に書けることを目指して作ったわけじゃなくて
ポインタ周りのバグ(特にバッファオーバーフローなどが原因のセキュリティホール)
に悩まされてきた人間のために作られた言語だからな
セキュリティを考えてない奴からすれば無用な長物にしか見えないんだろう
訂正：無用な長物→無用の長物
Rustできちんとコード書ける実力あるなら
CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な
>>56みたいな
>>56がなんでエラーになるのか理解できないって事はC/C++でもvectorへの参照を何も考えないで使い回してたりするって事だし
実用というより教育目的な言語としては確かにアリだ
>Rustできちんとコード書ける実力あるなら
>CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な
出来ないからC++ではValgrindとかのツール使ってチェックしてるんだろ
じゃあツールを必ず使うようにすればいいじゃんって話にはなるが…
Rustのボローチェッカと比べるとどの程度信用できるのかね？
スマートポインタを(適切に)使ってればそもそも解放忘れはしないし
配列に確保しっぱなし系のリークは検知してくれない
>あまり信用できない
>配列に確保しっぱなし系のリークは検知してくれない
そっか、やっぱりRustのボローチェッカには劣るか
>スマートポインタを(適切に)使ってればそもそも解放忘れはしない
「適切に」ってところがポイントだよね
たとえ熟練のC++erがどれだけ注意してコーディングしてたって
「うっかりミス」はいつか絶対に起きるんだし
0295デフォルトの名無しさん垢版
2018/04/01(日) 12:42:04.82できないよ、人間だもの
ASANでも2倍くらい遅くなるので辛いのは同じ
コンパイル時に静的に分かる方が嬉しいし、たまにしか通らないパスもチェックされるのでより安全
その場合でもコンパイル通ったからと主張しだす輩で溢れてる。
unsafeはチェックできないのと同様に意味がないですね
drop trait を明示的に書かなっきゃならんとかそいつら全く理解してないだろ。
非推奨になるってどういうこと？
rustみたいにunsafeブロックみたいなのを導入するってこと？
C++は基本的にはCとの互換があるから無理だと思ってたんだけど…
それを非推奨にするなら別の言語使ったほうがマシだろ
cargo/crates.io相当のものがないから
新規アプリをC++で書く気はしなくなってしまった。
もしかして最近は便利になってたりするんだろうか。
いちいち気にしなくていいって発想は面白い。
https://twitter.com/uint256_t/status/952818644433555456
BoxとかRcとかモロにスマートポインタだから興味ないとか以前の問題なんだが？
Goですらそんなもん使ってねえぞ
RustではRcとかArcがそれに該当するから、この文脈でも完全に的はずれになるが
Swiftは参照カウント方式のGC採用していたような気がするが
ARCってやつ
せっかくだから、おれも反論レスを書き込むことにする。
こんなこと言っちゃってる時点でセキュリティに気を使ってないのバレバレだよね
セキュリティ関係に詳しくなくて分からないんなら素直に分からないって言いなよ
unsafeなんてC FFIしようとか考えない限りあまり使うことないよ
tokio-coreとかhyperとかhtml5everとかのソースコード見てきなよ
unsafe使ってる箇所なんて10箇所あるかないかってところだから。
コード全域に気を配らなきゃならないのか、たった10箇所程度に気を付けてれば良いのか、
どちらが楽(安全)なのかは火を見るよりも明らかだよね
これに関しては自分が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の関数呼ぶんだから当然だろ
Rustで確保したリソースをCに渡す場合は確かにdropいらないけど、
C側で確保したリソースについては必要では？
Cから何かハンドルが帰ってきて最後にCでcloseするパターン。
Rust側でDropしないためにDropの実装を上書きする必要があるということ？
Cの関数内で確保したリソースは
当然Rustデフォルトのdrop実装では解放されないから
自分でdrop実装して解放する必要がある、という話。
>>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を使わないから詳しくはないので、間違ってたら指摘して下さい)
メモリリークに限定するとしても
CでmallocしたポインタがRustに渡ってきた場合
Rustが勝手に解放するわけにはいかないから
drop実装してfreeを呼ぶ必要がある。
ちょっと言ってる意味がわからない
Cでmallocされたものであっても所有権ごと渡されていれば解放の責任はRustにある
ていうか、Rust側で勝手に解放しちゃいけないと言ってるのに
Dropトレイトの実装でfreeしたらやっぱりRust側で勝手に解放しちゃってるじゃん
言ってること矛盾してない？
CとRustで型のメモリレイアウトが一致してればあとはBox型に任せるだけだよ
Cから渡されてくるポインタの型のメモリレイアウトが公開されていなければ
(つまりvoidポインタだったりオペーク構造体(オペークポインタ)だったなら)話は別だけど。
その場合はRustはハンドルをもらうだけでいかなる操作(メモリの解放(free)も含む)もC FFIでC側に
頼むしかない(メモリレイアウトがわからない限りはRust側ではどうあがいても何も出来ない)ので
Dropトレイト実装してdrop時にC側にメモリの解放処理も頼む必要がある
>頼むしかない(メモリレイアウトがわからない限りはRust側ではどうあがいても何も出来ない)ので
>Dropトレイト実装してdrop時にC側にメモリの解放処理も頼む必要がある
だからDropトレイトを意識的に実装せにゃならんと始めから言ってるだろうに。
このタイプは絶対仕事でモメるわ。
だったら「Rust側からはメモリレイアウトが分からないようなvoidポインタや
オペーク構造体がC側から渡された場合は」という前提条件をきちんと書け。
条件を何も書かずに「drop trait を明示的に書かなきゃならん」とだけ書かれれば
全ての場合で必要だと言っているようにしか見えない。
あと、>>321で「全く」と書いてしまったことは悪かったと思っている
>>321を書いてる時点は上記のような可能性に気づいていなかった…申し訳ない。
お前みたいに「特定の条件下でしか適用されないこと」に対して条件を書かずに結論だけ書いて
「自分はきちんと伝えた」とか思っちゃってるキチガイとの仕事とかこっちの方から願い下げだから。
そこは自分も同じことを思った。
mallocとjemallocの実装の中身とか見たことないけど、混在してても問題ないのかな？
>>322 → >>332
「勝手に」の部分が曖昧だったので正確に書くと、
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
マジか…mallocとjemallocは混在できないのか…
そうなると、C側でmallocされてれば必ずC側にfreeしてもらうしかないということか…
じゃあ今まで俺が書いた方法じゃダメなケースもあるじゃん…すまん。
自分の無知を晒す羽目にはなったが、むしろ今知れてよかったわ。
でも、そうなると新たな疑問が…
間違いの指摘と情報提供のお礼言うの忘れてた。Thanks!
あと、これってRustでのC FFI に限った話じゃないよね？
C同士でさえもアロケータに何を使ってるか次第で同じ問題が発生する。
Cは時々使ってたのに(しかも仕事で)これを知らなかったのはヤバいな…
恐らく今まではたまたま同じアロケータを使ってたから問題が起きてなかっただけか…
戻り値で文字列(char *)が来た時とかこっちで勝手にfreeしてたぞ…(^_^;)
まあ、どのアロケータ使ってるかなんて誰も気にも留めてなかったし大丈夫だろうけど、
今後は気を付けないとな…
Rustだけを学べばよいという状況は訪れずCやC++の習得も必須
どういたしまして。
C同士の場合は普通glibcへの動的リンクだし
LD_PRELOADとかでjemallocなんかに差し替えても
プログラム全体で差し替わるから特に問題にはならないかと。
もしメモリアロケータを静的リンクしたライブラリとかを使っていればまずいはず。
ただそういう場合はリソースハンドルっぽいAPIになりがちなので
そのままfreeしようとは思わないかもしれない。
そりゃそうだろ、なにいってんだ
or
RustとC/C++を覚える
学習コスト高すぎRust
趣味でモジラの栄養やるとかどんなドマゾだよ
それでもRust使うって言うんだからなあ
全部C/C++で書く方が遥かに効率いいしバグも出んわ
もう少し工夫しろ
CのfreeはNULLなら何もしないと保証されてるけど
解放済みアドレスへのfreeはセグフォ発生するぞ
そのCとの連携部分が腐ってるってことじゃん
使いもんにならねえって評価は妥当だと思うが？
それともPure Rustでまともなもん作れるつもりか？
動く
実用的
上記3点の実績がある
どの程度を実用的で実積があると呼ぶのか具体例を提示してくれ
突き詰めていくと「バグらない」も程度によりけりだしな
Excelだってバグるときゃバグるし…
JSに負けるとか草しか生えんなwwwwwww
Linuxくらいバグらないならいいよ
噂に尾ひれがつく瞬間を目の当たりにして草
多分これ↓のことだろ
http://blog.bokuweb.me/entry/2018/02/08/101522
誰かC x wasmで書き直してみろよ。きっと似たような結果になるから
>>359
ついにLinuxと同レベルじゃないと認めないとか言い始めたぞ…
ブラウザ JS版 Wasm版
Chrome 63 4.36ms 5.68ms
Firefox 58 5.76ms 3.98ms
Safari 11 9.98ms 4.21ms
う～ん草しか生えんね 草草草の草ァ！だね
wasmじゃなくてRustと比べてから言えよ
草しか生えんわｗｗｗ
色々苦労するのは当たり前なんだよね。
それなのに「rustは勝手に解放してくれる」とか言い張っちゃう信者が有害な訳だよ。
rustが悪いというよりか、こういう馬鹿が多いところが問題。
C FFIを持ち出して反論するのと同様の不毛さを感じる
言語の一番下ではアセンブラが動いてるんだから、そことどう調和もしくは隠蔽させるかってのは
コンピュータ言語にとって本質でしょうが。
って事実はほんと覆らんよ
悔しかったら反論してみたらぁ？
メモリ管理みたいな重要なことについてデララメ振りまいて、
「理解しない奴がrust批判してる」とか言い出してる方が恥ずいわ。
メモリ管理も全部C側で完結させるのが一番いいって結論にしかならんぞ？
Rustのいいところなんぞ皆無だ
メモリ管理はGCに任せるか完全手動にするかの二択なのに、無理矢理そこにヘンテコリンなソリューションもどき持ち込んで混乱引き起こしてるだけじゃん
CやC++のほうがまだまともなアプローチしてる
うおっ!
ここにきてまさかのRAIIを否定し始めるとか予想外すぎたわ!
お前C++のスマポってなにか知ってる？
ほとんどのコンパイラで採用されてない仕様書上にしかない機能なんざ知らんよ
よろしい。そんな君にはJavaがおすすめだ。そっちで元気にやりたまえ。
話にならんと放置したらいずれ手遅れになるほど蔓延する
そうならないうちに叩いておくべきなんだよ
「俺の頭の中で混乱を引き起こしてる」って正確に書こうよ
上のFFI絡みの流れは俺じゃないけど？
コンパイラに丸投げするよりは良いな
混乱しないって意味だとGCが一番だが
上のやり取りは俺じゃないけど？
散々間違いがあったら指摘してくれって書いてたのがデタラメを振りまいた？
間違いの指摘に礼を言って終えるところに、鳴りを潜めていたアンチがウキウキで「混乱を引き起こしたRust！！！」と喚き立てた
このスレでも何回もやってる流れじゃんクソダセー
ほんとくだらん言語
内にいるつもりなんだお前
実行開始までの混乱しない順だなどう考えても
外から内ゲバ眺めてやっぱこの言語くだらねって思ってるだけ
C++の（後方互換維持のための苦しい構文追加以外）なにが悪いんだか
スマポが何かを知らないヤツがC++を語り始めたぞ…
ていうかこれ知りたい
Rustの何が(例:MIR)どう機械語との相性が悪く
それに対してC/C++のまともなアプローチの具体例を教えて
代弁してやろう。
「自力で頑張る」
以上
結局解放処理は自分で書くんだろ？
メモリ上の確保のされ方はコンパイラにはわからないんだから
結局中途半端にしか自動化できないから無意味で、それなら自分で管理した方が結果的に良いって話
だってRAIIもスマポも知らないんだもん。しょうがないじゃん
C FFIとかの一部分で解放処理を書くんだよ
お前が言ってる通り「手動」だしお前の好きな「手動」でよかったな
中途半端にとは言っても機能するし「無意味」と言い切るには典型すぎる誤謬
で>>395にまともに答えてくれる？どう相性が悪いの？どんなアプローチ？
今の説明でわからんなら一生わからんよ
あっ! 逃げたww
A. 結局中途半端にしか自動化できないから無意味で、それなら自分で管理した方が結果的に良い
Rustアンチ君との最後のやり取りがこれなのか…？悲しい
実際問題ワッチョイは過疎る
YOUがワッチョイのほうで話題ageれば
まともな話題ないし
https://mevius.5ch.net/test/read.cgi/tech/1514107621/l50
いちいちこっちに宣伝しないでよろしい
ワッチョイスレ（本スレ）には俺しかいない。
いちおうアンチスレも存在するんだぜ
http://mevius.5ch.net/test/read.cgi/tech/1509028624/
大元に言わないで、ここでグダってる時点で説得力無いけどな。
時間おいたところで>>395に答えなくてもいいことにはならないからね
>>397
「具体的にはどういうこと？(>>395)」と聞かれて、
その返答(>>397)に機械語のことが一切出てこないのは流石に草
日本語ネイティブじゃない方なのかな
そんなことRustでできるようになって欲しくはないな。
推奨してないけど
ところでrustで書かれたウィルスとかマルウェアとかないよな。
goならMiraiで使われてたけど。
Rustは強い型付けしか原則許してなくてunsafe使えば弱い型付けも出来るけど好んでする必要性はないよねー
プログラミング言語と機械語の間はC/C++もRustもLLVM IRで仲介されてるから、どっちかだけが相性良いとかなさそう
LLVM IRじゃなくGas仲介するとこう違うんだよ、くらいの反論を期待してみるテスト
フロントエンドの話してるのに、バックエンドがLLVMだから違いなどない！は、おかしいのでは？
そんなこと言い始めたら、言語仕様の優劣など語るに値しないということになってしまう。
Any使ったdowncastはunsafeじゃないけどどういうコードの話してんの？
https://gitter.im/rust-lang/rust
チュートリアル的なサイトは見つかるのですがそこから突っ込んで使用したい場合に参考になりそうな情報がみあたらないです
レンダリングされる線を任意の幅にしたいです
極細フォントを使って線幅1ピクセル×2＝計2ピクセルでアンチエイリアス無しみたいな感じの結果が欲しいです
出力が2値の場合に普通にレンダリングした物を減色してしまうと線幅の不均一になったりディザが掛かってしまって
表示品質が極端に悪くなってしまうのでそれを防止したいです
たとえば「田」みたいな字をレンダリングして減色するとある線は1ピクセルだけど別の線は2ピクセルになってしまったり
交わるところに不要なドットが出現したりします
それを全て任意の線幅に統一したいです
0434デフォルトの名無しさん垢版
2018/05/02(水) 04:26:15.76rustのslack
↓のサービス使ってオープンにすればよい
http://slackarchive.io 👀
Rock54: Caution(BBR-MD5:b95868ef2c0ed5e765a4d10ada4cf289)
実態はスカスカで教祖の金儲けに使われてるだけなのに、信者は正義と信じて疑わない辺り
slackなんて内輪の集会に逃げ続けて表の評価に曝されることを避けてる時点でまともなプログラミング言語じゃない
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる
お前はさっさとその答え教えてくれよ
Rust批判するにしてもコンピュータの知識皆無すぎるわ。批判側がお前と同じ知的レベルに見られるのがクソ
へー今日はたくさん書き込むつもりなんだ
表の評価(2ch)wwww
ttps://arxiv.org/abs/1804.10806
rs4にMeltdown/Spectre対応のパッチも含まれてたんだろうか。
https://www.rust-lang.org/ja-JP/friends.html
https://logmi.jp/282807
>>445
これでもそんな知恵遅れみたなこと言うの？
どれだけバカなこと言ってるかわかると思うよ。
謳い文句通りの「速度とマルチスレッド」で選んだら後でめんどくさいよ。
MIRの導入もなかなか成果出てないし、同期はセマフォ/ミューテックスしかなくて
javaみたいに高レベルから低レベルまで自分で書けるわけじゃないし、
non blocking ioも、lock free collectionもなくて外部ライブラリへの依存度が極めて高いし、
cargo腐ってるせいでrustのtooling絡みのissueが日に日に増えるし。
rustの良いところは言語の部分だからコアな機能使わないなら他言語のほうが良い。
土方の要求には合わないでしょ。
それよりimpl traitまだー？
これってgoでは無理だったんかね？
単純に趣味の問題？
無かったらその部分が大きいのでは？
mutex部分が隠ぺいされてるので意識する必要が無い
ライブラリとしてではなく言語仕様としてという意味か？
言ってることがよくわからんメモリ共有は基本的にmutexみたいな物はついてない気がするけど。基本的にchannel経由で情報交換しない方針にすれば
データ競合は防げるって話では？
rustってデータ競合がコンパイル時点で防げるって意味がわからん。
そんなことがかのうなん？
X 基本的にchannel経由で情報交換しない方針
○ 基本的にchannel経由で情報交換する方針
詳細はこちら
Goでスレッド（goroutine）セーフなプログラムを書くために必ず注意しなければいけない点
https://qiita.com/ruiu/items/54f0dbdec0d48082a5b1
goroutineで確保したメモリは解放せずgoが管理するから、常駐で同時に大量に走ると解放されないとかはあるみたい。
それが売りの一つなんだから当然出来る
具体的にはこれでも読んでくれ
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/concurrency.html
*で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);
}
つまり、&*xは&*x.deref()と同じで、それはつまり、x.deref()と同じ
*x ==x.deref() って言う認識だったのが間違ってたのか
ありがとう
どっかに変更履歴のまとめとか無いのかな
公式リファレンスって何のことを指してるんだ？
APIリファレンスならきちんと最新版に追従してるし、
チュートリアル(The Book)も2nd Editionがきちんと出てる
バージョンアップの追従ならリリースノート見るかRustの公式ブログ見れば大体分かると思う
Rustは6週間に1回のハイペースでマイナーバージョンアップ繰り返してるから
The Bookのほうは最新版に追いつくこと自体がほぼ不可能だと思うけど
(つい最近もimpl traitがstable化されたばっかりだし…)
間違えた
X >>427
○ >>472
全機能の索引みたいなのがないと学習効率が落ちる
安全性が高まって結果的に高くなるということではなくね
やっぱでかいプログラムじゃなきゃ使う効果ない？
RustはJavaより10億ドルほど生産性が高い
その論法だと俺の未完成言語は誰もバグを生み出してないので
Rustより生産性が高いなｗ
分母分子共にゼロなので計算不能ってやつね。
まあ、objective-cのARCでいいじゃんとも思うけど。
こいよ継承クラス、ポリモーフィズムなんて捨ててかかって来い！
実際、null非許容のポインタが欲しい
0483デフォルトの名無しさん垢版
2018/05/17(木) 15:59:25.11issueある。待つヨロシ。
>>427,473
the rust referenceのことじゃね？the bookとは別にあるだろ。
全然追いついてないよアレ。そもそもまだ仕様書がない言語だし。
" best-effort document"って書いてあるでしょ
acitx-webとか誰か使ってない？
今だとactix-webが一番良い感じだと思う
必要に応じて同期、非同期、アクターモデルと使い分けられるし
良い感じか。使ってみるか。ありがとう
有志「クソ機能入ったのいらねえから消そうぜ」
大勢「いいな！賛成」
独裁開発チーム「もう入ったから消せませーーーーんwwwwww（クローズ&ロック）」
systemdかよって
もう入ったから消せませんってのは横暴なようにも見えるがしようがないとも思う
一度入れてしまった機能をまた使えなくするとか、それこそ混乱するし…
そもそも何故impl trait を引数の位置にも書けるようにしたのかは確かに甚だ疑問ではあるけど…
引数の位置でジェネリクスとトレイト境界じゃなくてimpl trait じゃないとダメなケースとかある？
無いなら、warning出してジェネリクスとトレイト境界に書き直すように促すのが妥当じゃないかな？
https://github.com/phaazon/rfcs/blob/undo-universal-impl-trait/text/1951-expand-impl-trait.md
言語（笑）開発チームとやらも内情はどうなってることやら
と
foo: &Trait
との比較で特殊なケースを除き前者の方が効率良いが
syntax上後者の方が簡単なので
初心者が誤って後者を使ってしまうケースがあった
これを防ぐためにimpl Trait および &dyn Traitを導入し
&Traitをdeprecateすることになった
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
D49IO
は正論
何故クソ機能の進入を許してしまったのか、どうすれば食い止められたのかについて追求すべき
Traitをimplした型を受け取るという意味ではimpl Traitを使うべきだと思う
ただimpl Traitを導入するなら1.0の時点で導入してて欲しかった
言語（笑）開発チームとやらも内情はどうなってることやら
それはdyn Traitの実装理由であっても、
引数位置のimpl Traitを実装した理由の説明になってない
と
fn foo<T: Trait>(a: T)
では前者の方がlightweightでは
goとかにはないよね？
gtk-rsだと500MB消費しちゃうんだけど他のプロジェクトで使い回しとか出来ないの？
ただ、vscodeのrustプラグインの何かがこの環境変数を考慮してないんで挙動がおかしくなったことがあるんで注意
おお流石に出来たんですね
プラグインがおかしくなるのはrls側の問題ですかね🤔
最近Rustの話聞かなくなったな
rustで書いてまっせっていうバカなアピールするのは。
泥箱って日本企業だっけ
設定ファイルはluaあたりが無難？
いやもうなかったことにしたがってるじゃんw
それなのに変なのに付きまとわれてるっていう。
「なかったことにしたがってる」というソースをプリーズ
24時間以内のホットな情報だ
0519デフォルトの名無しさん垢版
2018/05/31(木) 22:43:34.41どうしてそこまで情熱的にRustを貶すの？
xmonad.hsはもっと宣言的に書けて、モナドとか上手く作って見栄えは良くできるんだけど、
馴染みのない演算子(<+>とか)使いまくるんで、よっぽどHaskellに慣れ親しんだ人でないと全容が理解できない
設定ファイルのフォーマットを開発言語と同じにするのはdwmから続くタイル型WMの流儀だし、
思ったより読めていいと思うよ。
前段 モジラとその小判鮫以外の全組織が喜ぶ
後段 技術的にカスなものを貶すのは技術者の義務だろ
>技術的にカスなものを貶すのは技術者の義務だろ
じゃあPHPではなく敢えてRustをdisる理由は？
あちらの方が広く使われてるからより害悪だと思うが
ほうほう
あれを使ってるやつも害悪性は理解してるからな。
こういう技術的にインテリな要素のある言語って信者がとにかく頑なで
実際のプログラムの現場で非常に問題になることが多い。
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる
んー例えば
コンパイルが通せなくて自尊心が傷ついて自ら会社をやめちゃう問題とか
この話どこまで事実か知らないけど仮に本当だったとしても
これって言語の問題というよりチームのプログラマの腕を過大評価
もしくは計算に入れてなかったというマネジメントの問題だよね
プラズマクラスター付き家電が話に出てきたら今まで黙ってたのに凄い勢いでエセ科学だと解説し出すよね
性格異常だもん
何度言い返せなくなっても数日後に甦る粘着性
C++で実行時にエラーが出るようなコードを書きまくったのでしょう。性格の悪さと溢れる自尊心から誰の耳も貸さなかったのでしょう。
プログラマーとして生きるよりかは、匿名掲示板で巨悪組織Mozzilaと闘うBBS戦士の方が社会的に良さそう
Rustを採用した企業自体を叩く行為をよくしているよな
あれ見るとちょっと辛くなる
具体的には？
ttp://tanakh.jp/posts/2016-12-20-rust-pezy-sc.html
>>534は「それRustでやる意味がある？」という疑問に全く応えられないのが問題
LLVM IR-> PEZY-SCというコンパイラがあるんだったら、LLVMがバックエンドの他言語でもいいよねって話
それができないなら、LLVM->PEZY-SCは未完成か現実に即してないんじゃねえのって話
rustでも出来た、以外に意味はないでしょう
安全じゃないコード も 書けるってことに価値があるんだろ？
C/C++以外の他言語では書くことさえできない。でもC/C++は安全性を売りにはしていない
Rustは安全性を売りにしつつ、必要に応じて安全性を捨てる選択もできるということに価値がある
で、たまたまその記事が安全性を捨てることが必要な数少ない例の1つだったってだけ
unsafeあるやんけ！危険危険！
前後の文脈一切分からんけどとにかく危なそうなこと書いてあるやんけ！
つって叩いてるんだろうなｗ
>>535
その手の問いにそいつが素直に答えたこと無いからあきらめよう
どんだけコード例出しても言い出しそうだなw
そもそもコード例が少ない訳で、推進してる奴のコードがそんなもんなら
十分否定的な要素だけどね。
お前さんの理屈だと、Rustじゃこんなに危険になる！って事だろ？
じゃあ、Rustではそういう危険な書き方しか出来ない！って示さなきゃな。
俺は中立だが、あんまり非論理的なdisりはアンチ＝低能と思わせたがってるピエロにしか見えんよ。
ほんとだどこが問題で悪いのか全然書かない
具体的に言及しだすとフィボナッチ数列とか機械語レベルとか、残念なことになるのが自分でもわかってたのか
まあ本人が書いた通り「ドヤしたいだけ」とか…なんかな？前もマウンティング取られたとか訴えてたし…
たまには芸風変えたら
同様にクレート間の依存関係も判りにくい
どちらも一式を落としてきて中身を確認しないと判らないような・・・
Cargoで自動ダウンロードして・・・みたいな使い方をしていると意図せずGPL/LGPLになっていた
みたいなライセンス事故が起きそう
$ cargo install cargo-lichking
$ cargo lichking check
一先ずlichkingでチェックできるよ
えぇー・・・わざわざインストールしないと出来ないのかよ。とりあえずやってみるか
依存関係はどうすりゃいいんだ？no_stdでも使える奴だけ探したいとか
ライセンスをついては、crate名が既知なら、
ttps://crates.io/api/v1/(クレート名)
でjson取れるので、そこから再帰的に依存辿れば収集はできそう
no_stdかどうかについては、Cargo.tomlのcategoryパートに"no-std"があるかどうかぐらいしか確認するすべなさそう(2017-2-10に追加されたっぽい)。
皆が皆付けてるとは思えないので、参考程度にしかならないだろうけど。
firefoxは言語オタに支配されたのか？
【IT】高速化を進めてアドオンを排除したFirefox、ついにシェアが１０％切る★2
https://asahi.5ch.net/test/read.cgi/newsplus/1528388348/
http://mevius.5ch.net/test/read.cgi/tech/1507970294/100-
前やったから何？
ええ…？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で書こうが他の言語で書こうがどっちにしろ従来のアドオンの一部は動かないよ。
ほかに行く場所ないの
>>555はhg使えなかった時代で止まってんじゃないの？
gitとgithubはちがうよ？
検索してみたら、前は入ってたのに1.0リリース前に削除されたんだとさ
https://internals.rust-lang.org/t/add-filename-information-to-io-error/
非効率になるのを嫌ったってことみたいですね
stdでもつには重すぎるってのは理解はできるけど 確かに不便なんだよなー
自分は結局
ioの関数呼ぶ前にinfo!でログ出すとか
戻ってきたio::Errorをmap_errでPathBuf埋め込んだ自前のErrorに変換するとかしてます
ここで紹介されてる、failureを拡張して let file = File::open(path).with_path(path)?; と書けるようにするのが
カッコいいなと思った
https://github.com/rust-lang-nursery/failure/issues/189
failureは1.0に向けてまだまだ変えていくみたいだし、これ書いた焦げ寿司氏も参加するみたいだから
期待してるわ
throw!マクロが標準化したら、?の時みたいにrustプログラムの見た目変わりそう
ようはヒープに動的に作られたストラクトだら？
変に勘ぐって誤解してるよ。スタックにある構造体でもトレイトオブジェクトになる
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/trait-objects.html
特性
ヒープにある構造体である、とはどこにも書いてないよね
複数の異なる型を同じ関数や構造体で持っておきたいけど、
型が違うからコンパイル時にサイズが決まらないんで困ったねって状況を解決するのがトレイトオブジェクト
そういう事態じゃなければfn foo<T: TraitFoo>(obj: T)とかやって型毎に関数をコンパイラに作ってもらうのが普通
トラウトサーモン。
1.0待てなくてもう現行のfailureにどっぷり浸かっとる。
failureはいいぞ！
Rustは採用企業が全く増えなくなって資金も枯渇
メインコミッタもリンゴのSwiftやらにヘッドハントされて
もう将来ないでしょ
ライフタイムとかの実装系の先駆としての意義はあったとおもうが
二の舞って言いたかったのか？
なんかfailureのissues見ると、現状のstd::errorの設計は失敗作扱いみたいだな
それって共通認識なんかな？
ユーザーが年々すごい勢いで減っているDに比べりゃ
規模は小さいもののRustは年々少しずつ増えてるわけだから
今後普及するかどうかはともかく少なくとも廃れちゃいないし、
学習コストが高いから敬遠されてるだけで注目もされてる
それにHaskellと同じで勉強しといて損はない言語だと思うし
バッテリ同梱などと言い出しもしないばかりか
randすらクレイトになってるから
rustcだけで楽しんでると涙目（´・ω・｀）になる
ライフタイムとか所有権の感覚は他言語でも役にはたつでしょ。
もしくは他の選択肢の方がいいとかありますか?
std::error+error_chain/log crateの問題点を
解決するためにfailure/slog crateが
作られたからだいたいそんな感じだと思う。
failureの方は今nurseryだし。
failureのエラーとstd::errorのエラーを相互変換できるから
移行や依存ライブラリがstd::error使ってる場合に対応簡単だよ。
まあ、1.0待ったほうがいいけど。
wasm-bindgenはhost bindings proposalの実装でstdwebはweb apiのrustバインディング。
host bindings proposalはWebAssembly用の(ホストとの)ffiみたいなもん。
stdwebベースのyewとか面白いよ
Reactっぽいことが出来る
>>605
レスどうもです
host binding（wasm-bindgen）が後発で
cargo-webがあるstdwebの方が開発サイクルが楽そうという感じがしてます
yewも見てみます
stdの下にあるけど非推奨、みたいなのが今後だんだん増えてくるのかな
使ってはいけない標準ライブラリとかC言語のgetsかよwwwww
21世紀の言語とは思えねえなwwwwwおもちゃもいいところwwwwwww
純粋に聞くがお前の周りでRustサイコーって言ってるエンジニア何人いる？
https://insights.stackoverflow.com/survey/2018/#technology-most-loved-dreaded-and-wanted-languages
2/6人かな
いくらでも組織的に水増しできる問答や投票になんの意味が？
その程度の言語が世界一位って統計的におかしいと思わん？
dreadedに水増ししたの？ｗ
お前と匿名の一人で統計語ろうっておかしいと思わん？
フィボナッチ数列も書けないだけはあると思うよ
プロダクトの数考えろよ
この記事オカズに1年ぐらい黙れそう？
http://wolfbash.hateblo.jp/entry/2017/07/30/193412
0624デフォルトの名無しさん垢版
2018/06/20(水) 22:24:58.84なんで一つのサンプルで統計的にとらえるんだ？
プログラマー的におかしいと思わん？
http://mevius.5ch.net/test/read.cgi/tech/1514107621/
ここはキチガイと戯れるスレ
それ>>8でオレが貼った記事な
このスレでも反論の余地の出なかった良記事。Nimについてはともかく
Rustのクソさについては本当によくまとまってる
取り下げられた記事以外誰も出せないまま人格批判だけとか全く理論的じゃないし
そういう人ばっかだよねRust信者って
お邪魔しました
archive. fo/7NUr2
なんかある？
だから取り下げられた記事は反論にならないって
本人が間違いだって取り下げたんだから
読んでもねぇのに自分勝手に判断して否定するバカが
「理論的じゃない」とかよく言えたな
その言葉そっくりそのままお返しするよ
自分勝手じゃないよ？
そもそも論を取り下げたのは向こうじゃん
取り下げられた論が議論の俎上に上がるのはおかしいでしょ
ある人にとってはプログラミングとは設計作業に他ならず
ある人にとってはプログラミングが指の労働でしかない
書き間違えるから、書き忘れるから、という理由でもって
しょうもないバッドノウハウを拝み続ける者すらいる
塩と砂糖を入れ間違う、塩を入れ忘れる、自称料理人
そーいうレベルのプログラマ
ソースはRubyｗｗｗｗｗ
何故取り下げたかの理由も書いてあったがそっちのほうは完全に消えたかな…
アーカイブすら残ってなさそうだ…
「他の記事を貶めるような記事は品性が疑われるからやっぱり取り下げる」
みたいな理由だっと思うけど、どうせお前はそれも認めないんだろ…
………ふぅ………もういいよ……
お前の頭ん中ではRustはクソ言語で良いよ……
そういう人だね
お前だけは確実に
Rustスレに行け
https://qiita.com/tatsuya6502/items/8b31e2b162aff78787fe
プロジェクトフォルダにrust-toolchainファイル置いてその中で指定出来るみたい
toolchain指定なんでrustup必須になるのと固定指定しかできないっぽいけど
受験勉強で
俺は英語なら分かるんだけど、日本語はさっぱり分からん
すげーな
オライリーのやつKindleで読んでるけどまず訳すのが大変だわ
英語圏に生まれたかったと切に思う
情報の早さ・量・正確さが段違いだし原著読むと意外と難しい単語使われてない。
bind(bound)を束縛とかアホかと。
せめて結びつけとかにしろよと。
翻訳のセンス無さすぎ。
もしくはわざと小難しくして地位を守ってるのか…
英語と一対一で対応できる和訳の方があとから英語情報に触れるときのハードルを下げると思う
get / put / take なんかで言い換えしたからといって、わかりやすくなったとは思わない
明治時代の翻訳見習ってほしい。
漢籍の素養が必要だが…
明治期のアレは翻訳っていうよりは対応する訳語を創出するって感じだから、単純な翻訳じゃないぞ
「縛りつける」みたいな感じになるしかないと思うんだが
束縛は単純に漢語にしただけで大差なかろう
ありがとう
一応そういうのあるんだ
そのページの下に書いてある、edition 指定出来るようになるのを期待、という感じかな
お前にはあるかのような口ぶりで
> せめて結びつけとかにしろよと。
↑こんなこと言い放ちつつも
> もしくはわざと小難しくして地位を守ってるのか…
束縛っていうふつうの単語を小難しく感じると白状し
地位を守るだのなんだのという珍妙な価値観まで丸出しにするとは恐れ入る
近い分野なんだから専門用語もう少し考えてくれても良かったのに
英語だと単にassignだぞ。
「錆は、安全性、スピード、並行性に重点を置いたシステムプログラミング言語です。
以前のバージョンのRustが錆びてインストールされている場合、」
だからな
traitとかcrateとか訳すとよくわからなくなるもの多いし全部カタカナでよい
型アノテーションのない変数の型は右側を評価したときの型になります
束縛するはバインドするでよかった。SMの趣味ないし。
fn foo(...) {...} は、ある関数に対しfooという名前をつけるので「関数をfooに束縛する」とは言うかもしれないけど、
「fooに関数を代入している」とは言わない、みたいな
伝統的な表現だと宣言に近いニュアンスかな
let hoge;
hoge = 100; // これをコメントアウトするとコンパイルできない
println!("{}", hoge);
fn hoge() -> String { "hoge".to_string() }
と書くものですか？
それとも
fn hoge() -> &'static str { "hoge" }
と書くべきでしょうか？
テケトーにググっただけ
つ https://qiita.com/Mizunashi_Mana/items/db88cb0bff002abce1ae
それ以外なら使えるときは &str を使うのが良いのでは
優柔不断でグダグダな言語に思えてしまう
ttps://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/ffi.html
にチュートリアルはあるけどexternの記述方法とかがわからない
見よう見まねで書けなくはないけどそのまま行くのは事故の元だし
ついでにlibcが何をしているのかもわからない
CのヘッダからRustのインターフェースを自動生成してくれる
bindgenを追っかけてみればよいかと
https://github.com/rust-lang-nursery/rust-bindgen
せめて理論的に反論しろよグダグダ言語の信者
ごめんなさい
論はどこですか？
えぇ・・・ソース見るしかないのかよ・・・
リファレンスマニュアル見てもちゃんと書いてないんだよな
さらにググってもリファレンスマニュアルが引っかかってこない罠
unsafeまわりの文書に入ってる（ただしdraft）
https://doc.rust-lang.org/nomicon/ffi.html
公式文書はgithubのorganization（rust-lang、rust-lang-nursery）から探している
まだ不明点は残っている
・#[link(～のkindが何を示しているのか判らない
C FFIの使用例を見るとよく見るんだが・・・
・C言語配列の渡し方が不明
元は
>int p[]={16,9};
>foo(p);
とりあえず
>foo("\x10\x09".as_ptr());
などと書けばデータ上は整合するから動くけどどう見てもスマートな記述方法ではない
・文字リテラルの仕様が不明
↑の表記を得るのに数回試行錯誤した
データの与え方もCStringを使った(＝\x00終端する)方法は出てくるけど、そうではない方法は
中々見つからなかった。結局↑の表記に落ち着いたが
>>689
ありがとう。kind値について書いてありますね。静的リンクだとkind = "static"らしいですが
付けても付けなくてもファイルサイズは大差ないようです。何が違うのだろう
・#[repr(C付きのstruct
・#[repr(C付きのenum
・box？
・vec
・str
が挙がっているけどCと互換性があるのはこれらのみって事なのだろうか
vecを試してみたら動いたけどextern時に安全じゃないから#[repr(C)]付きのstruct使えなどと言いだした
>>691
マジかよ！確かに文字列は汎用性が高いけど可読性が良くない・・・必要に応じて抽象化しろという事か
× 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"に変換してくれるようなのが欲しい
難しいもんだな
何か対策を考えないと大事故を起こしそう
要素数2しかないのにstructを書くのはコード効率の点からも可読性の面からもあまり良いとは思えないし・・・
いろいろ試してみたら
>let p: [i32; 2] = [16, 9];
>foo(&p);
ならいけるようだ。コンパイラは何も言わないけどこの表記が適切かどうかは不明
Rubyだと
foo([16,9].pack("i2")) #配列をint2個分の文字列(＝8byteのバイナリ列)に変換
とか書けるんだよなぁ。コストは安くないけど>>694みたいなポカミスは起こらない
何がしたいかよく分からんが
何故に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と対応する型は何かを考えれば良い
いや、isizeはまずいんじゃない？
例えばx86_64だとisize:64bit,int:32bitだし。
libcクレートのc_intならアーキテクチャ毎に適切なサイズになるから
こちらがいいかと。
とりあえずlibcクレートを探すといい。
まぁマイナーなアーキテクチャだと間違ってたりすることもあるから
確認は必要だけど。
http://mevius.5ch.net/test/read.cgi/tech/1523954817/
あれ？そうだっけ？
うかっりしてたゴメン
そう言えばCのintはポインタのサイズに合わせるんじゃなくて
アーキテクチャ毎に変わるんだったっけか
libcのc_intとの違いがよく分からん
対応アーキテクチャの数か？
一応libcはno_stdでも動くというメリットがあった気はする。
逆にプリミティブ型限定でも依存ライブラリ増やしたくないならstdなのかな？
あなたの言うとおりですが、そのような情報はどこをから得られるのか・・・
>>689等のFFIに関する資料に書いてあるようには見えません
std::os::raw::c_intも>>702を見て探してみたら
ttps://doc.rust-lang.org/std/os/raw/index.html
ここにあるのか
配列等の長さが変わる型のC互換性に関する情報もどこにあるんだろ
アドレスの連続性とメモリの確保が保証されている必要があると思いますが
資料が少ないのはまだ普及してない言語では仕方がない
FFIとか皆が頻繁に使う機能じゃないようなものはなおさら
Cの配列とRustの配列は互換があるはずだけど
悪いがその情報をどこから手に入れたかは覚えていないし
信用されても困る(ついさっきも間違えたしね)
場合によっては資料探すよりソースコード読んだほうが早いことも多いし
根気良く調べるしかないとしか言いようがない
あとはFFIみたいなunsafe部分は出来る限り念入りにテストを書くとか
arrayとsliceの連続性保証はここですかね。
https://doc.rust-lang.org/reference/type-layout.html#array-layout
ビルド出来る最後のバージョンと、それをインストールする方法教えてください
それ以前の問題として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があれば一通り出来そうか
sliceにderefできるし
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へ入れるようにしたら所有権で怒られて動かなくなった
同じコードでも型によって所有権の移動のしかたが違うのか
ただし、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();
&付けて参照渡しにするのはよく分からない、たぶん未定義動作じゃないかなあ
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レイアウトならクレートあるぞ。
C/C++の知識皆無では
英語で出る分には多目に見たが、日本語で出るんなら出版社の不買運動だな
どこが訳すか知らんけど
ありがとう、そういうオチか。&で正常に動かないのも納得です
暗黙の変換って便利ですけど理解が浅いとハマる元だったりしますよね
不適切な入力を入れると自分が書いたつもりのコードとは無関係っぽいエラーを出して？？？になったり
>>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はポインタのサイズらしいしこっちの方が楽かも
評判良ければKindle出た頃に買おうかなと思うけど
0725デフォルトの名無しさん垢版
2018/06/27(水) 20:11:21.04早速予約した
オライリーの原著は去年12月に発売、今年8月に訳本
今日発売された英語の本は公式ドキュメント(第2版)の印刷版
版元はno starch press
他の人も似たようなこと書いてるけど、Cの配列は結局はポインタに過ぎないから
C側がポインタを求めれば、当然Rust側でもポインタを渡す
あと>>711の
>同じコードでも型によって所有権の移動のしかたが違うのか
は半分正解で半分不正解
正確には、型によって違うんじゃなくて、Copyトレイトをimplしてるか否かで違う
u32はCopyトレイトをimplしてるから所有権はmoveじゃなくてcopyされる
c_voidはCopyトレイトをimplしてないから所有権をmoveしようとする
The Bookちゃんと読んだ？読んでないなら一度きちんと通読することを勧める
c++とhaskellがまともに出来ないときつい？
どっちかてと根気が必要だ
一応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が不要の警告が出るんですよね。これもそんな事を言われても
困るのですが
Cで確保したポインタ（特に○○ハンドルみたいなリソース）は普通はopaque structで受けると思う。
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/ffi.html#%E3%82%AA%E3%83%9A%E3%83%BC%E3%82%AF%E6%A7%8B%E9%80%A0%E4%BD%93%E3%81%AE%E8%A1%A8%E7%8F%BE
どちらかというと、func2の引数が参照渡しでなくて値渡しなのが問題では。
見た感じfunc2では借用して呼び出し後に返してもらえばいいっぽいけど。
えーなんで？rust書いてる人の大半は知らないでしょ
知らなくてもtrplなど読めばなんとかなるとは思うが
代数的データ型なども同様
あとは用途次第だけどFFIやるならCのメモリレイアウトくらいは押さえておいた方がよい
ちゃんとC/C++一から十まできちんと理解した方がよいのでは？
それからじゃないとそこがいい加減でRustなんて本当に使えるようになったと言える？
言語なんて使いながら覚えていくもんでしょ
RustはC/C++分かってないと書けない
→C/C++を分かるまでやる
→C/C++がわかってしまえばそもそもRustなんて不要だと気づく
→Rustを捨てる
確かにC++とHaskellが出来きればRustの習得にはそれほど苦労しないだろうとは思う
ただ、理解できるまでにかかる時間量の問題であって、それがないとキツイってわけじゃない
むしろ、Rustの学習するためにC++とHaskellを先に学習するとか時間の無駄
The Bookが懇切丁寧に解説してくれるので前提知識はなくても全く問題ないと思う
ただし、Goみたいな言語と違ってサンプルコード読めばある程度理解できて
何となくで書けてしまうような言語ではないのでThe Bookの熟読は必須
それと、FFIする場合はある程度のCの知識は必要だよ
そんな心配はせんでいい
0748デフォルトの名無しさん垢版
2018/06/28(木) 17:13:53.31Rustで若干のパフォーマンスを犠牲にしてでも、いかに毛髪を守れるかがテーマ
C++程度で禿げてたらRustのコンパイル通らん
Rustのコンパイル通せるならC++でやる方がよいコード書ける
つまりRustは実用にならん。C++er養成ギプスって話ならわかる
違う違う、そもそもRustは不要って結論な
C++勉強してC++そのまま使い続ければいい
C++03
C++TR1
C++11
C++14
C++17
C++20
C++23
C++26
C++29
C++32
C++35
C++38
単純に最初期のRustコンパイラはOcamlで組まれてたからって事情でないの
C++より潜在的なメモリ管理バグを減らせるってのは十分有用な話では
::とか@とかあるだけでだいぶ捗るよね（一部の人にとって）
来年にはrust書けるようになるよ
rustだろうとc++だろうとはたまた動的言語でもメモリ以外にも資源管理なんて
問題はどこにでも出てくるわけで。
あれ完全にイミュータブルリスト向けだもんよ
MSもRust使ってるんですか
やるしかない
なるほど。c_voidの正体はそれでしたか
引数は既成Cライブラリの仕様なのでなるべく変更したくありません
*mutを使うコードを検討していて気がつきましたがRustの生ポインタにfunc1が返すアドレスを入れると
Cと同じ危険を抱えますよね。func3でアドレスがNULL=0になりますからその後に触ると当然クラッシュします
actixとactix-webのメインコントリビュータもよく見ると普通にMS所属の人だった
ttps://github.com/actix/actix/graphs/contributors
ttps://github.com/actix/actix-web/graphs/contributors
ちょっとわらった
Q# 【量子プログラミング】
https://mevius.5ch.net/test/read.cgi/tech/1513059627/l50
rlsが不安定すぎるのでMSが作り直して欲しい...
あんまり力入れてないのかな
インテリじゃない人もタダで使えるよ
手に馴染んだemacsから離れるのは簡単じゃない
vsなんかよりよっぽどいいですよ…
従来のborrow checkerの制約が緩くなるだけだから従来の理解してれば不自由なく使えるはず
CLionもclang使わず自力でやってるけどリリースから随分経つのに初歩的なバグ残ってるみたいだし
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にする必要がありそうだけど
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の引数はRustのコンパイラにその型を使えと言われたから
func2の引数はfunc1の返値に合わせた
func3の引数はfunc1が返したアドレスが格納されているアドレス。Cで言うポインタのポインタでABC **z
自分も詳しいわけではないので勘違いしているかもしれないが一応動いている
ダブルポインタだったのか
それなら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と繋げるわ。
経験ないやつはいきなりrust勉強してる場合ではない。
C/C++知らないやつはいつまでたってもrustを全て分かったことにならない
半人前のまま
別に必要なとこだけ使うスタンスでもいいけど半人前のクセにいっぱしのrustプログラマーヅラしないでね
C++？Go？
やりたいものをやればいい
kotkinかswiftかgoかってなら分かるけど
https://yukicoder.me/submissions?submitter=5971
https://users.rust-lang.org/t/rust-for-competitive-programming/17682
recursion - Is it possible to make a recursive closure in Rust? - Stack Overflow
https://stackoverflow.com/questions/16946888/is-it-possible-to-make-a-recursive-closure-in-rust
おー、できた
ありがとう
ローカル関数だと外部変数キャプチャできないし、クロージャだと再帰できないし、
同時にしたいときどうすんのかなーって思ってたから
そんなに使うこともないだろうけど、心に留めときます
ありがとう。なるほどそういう書き方もあるのか。確かに書き換わるので&mutの方が適切ですね
欲しいのはアドレスなのだからと単にアドレス演算子&を付けていました
unsafe外から任意のアドレスにあるデータへアクセスするにはその部分を関数化するようなのかな
一般的に言うプロパティの読み書きをプログラマブルに出来れば綺麗に書けるけど無理なんだろうなぁ
()無しの関数呼び出しとも言えるけどこれが出来る言語は少ない
例えば何に驚いてんの？
Rustの目的はシステム言語だが、目的から乖離してるとこって何？
機械語のレベルと相性が悪いし
半分はその通りだが、それならc++で良くね？になるぞ。
0811デフォルトの名無しさん垢版
2018/07/01(日) 13:37:40.54どうあがいてもc++のが簡易にできるのは当然なんだよ。
このスレは英語推奨だぞ
ここに関してはクロージャでないものをクロージャと呼ばなければ誰も驚かなかっただろうな。
javaは似非クロージャのことはラムダ式と呼んでるし。
アレが許されるなら少なくともJavaのはクロージャと呼んでいい
javaのアレは元々クロージャ導入するつもりが、
仕様と実装でクソ揉めて妥協案としてクロージャ
じゃないものとしてラムダ式を作ったんやで。
だから意図的な"クロージャではないモノ"よ。
メモリ管理にgc使うからエンクロージャの束縛の解放に
制限ないから実質クロージャだし第一級関数だけど。
>>802のやり方だとパラメータ増えてるじゃん
こういうのは既存のシグネチャに合わせられないと
単にひとつの関数を小洒落た書き方にしてみましたってだけにしかならないのでは
ttps://wandbox.org/permlink/hkwccgD2oXp0fTm7
組み合わせて、802の2番目の例のstructを更にRefCellに入れたらシグネチャ変えずに行けるかな
一応満足してるよ
スッキリ書けないことがわかったから、素直にループで書くか、ローカル関数作って引数で渡そうと思えた
Rustは関数型じゃなくて手続き型だし、特に不満ではない
RefCell使うなら、Rustで書く意味ないだろ
すまん、クロージャでないとできない用途(環境をキャプチャーして高階関数に渡す等)を想定していると
勝手に気を回してしまったみたいだ
想像つかなかったので単純な興味本位
引数以外からパラメータを注入する必要がある場合。
キャプチャ自体はクロージャで出来るから別に困ってないかな
たまたま再帰させたくなったときがあっただけだから
クロージャの再起呼び出しじゃなきゃできないことを聞きたかった
引数以外のパラメーターを差し込む場合、普通は再起は必要ないよね
deny属性に違反するソースコードがドキュメント生成時にエラー投げる。
>>822
クロージャがある言語は普通、関数とクロージャ区別しないからその感覚はおかしくないと思う。
でもクロージャの実装上の制約とかライフタイムとかでループで書いたほうがいいと思うコードはある。
それは、てっきり最初の>>800がキャプチャと再帰を同時に使いたいことがあったんとばかり
ある種の動的なtree構造に対して探索、実行を繰り返すとか。。
やっぱ具体的じゃねーな。。
この言語ってstatementなのかexpressionなのかをどういう方針で決めてんでしょう？
ifがexpressionなのはわかったけど、letはなぜstatementなんだろ？
他の関数型言語のようにexpressionでもよかろうに、と思った
そもそも、変数束縛が値を持つ必然性は無いよね。
あ、ごめん。大嘘だった。
if let なんてのあったのね…
let x = ... in expはラムダ式の糖衣構文の一種なので関数型なら容易に実装できて便利に使えるのに対し、
rustのletは手続き型の変数宣言の方が近い
schemeのletとdefineが全然意味が違うのを知ってると違和感無い
この辺読めばいいかと。
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/functions.html#%E5%BC%8F%E5%AF%BE%E6%96%87
letは所有権移動だけど、返り値を認めちゃうと
束縛先と返り値のどちらに移動すべきか分からない、ということかな。
それは let a = (let b = c) がだめな理由にはなるけど
>>831の言ってる関数型言語風の let a = (let b = c in d) がだめな理由にはならないよね
それ無駄じゃね？
ブロック式で let a = { let b = 1; let c = b + 1; b + c }; と書ける
けどミュータブルな変数を書けるからコードが関数型言語風になるかどうかは書き手次第
>>839
ほー勉強になりました
fnもいまいち釈然としないけど
もうちょっと読み進めてみます
mapとかfilterとか、元のイテレータ＋変換・フィルター関数みたいな構造体を返してくる
strはmutの有無にかかわらずRO領域に配置される
sliceはmutの有無にかかわらずRW領域に配置される
つまり今風のOS上だと
strをポインタ経由で書き換えようとするとメモリアクセス違反
sliceをmut無しで宣言した物でもポインタ経由で書き換えられる
リンカの設定にもよると思うけどマイコンなどで使うときは注意が必要そう
脊椎反射したいつもの人が見事に釣られている
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にいるはずと思い込んでいるとハマるケースがありそう
任意の場所に配置するアトリビュートとかあるのかな
https://doc.rust-lang.org/book/second-edition/ch03-02-data-types.html
返すんじゃなくて定義したいんだけども
stackoverflowとリファレンスを見た限りstruct定義の入れ子はサポートしてない
https://stackoverflow.com/questions/23629201/nested-structs-in-rust
https://doc.rust-lang.org/reference/items/structs.html
struct 2d {x, y}
struct 3d extends 2d { z }
で3dが2dのxとyのフィールドと独自のzを持つようなかんじ
マクロで出来ないか精一杯やってみたが出来なかった
元となるstructごとにマクロ作ればできるんだけどそれじゃ意味ないし
Rust Design PatternsにはDerefでやるのはアンチパターンだと書いてあるけど、別の似たようなサイトではお勧め扱いだった気がする
https://github.com/rust-unofficial/patterns/blob/master/anti_patterns/deref.md
みたいなのを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つに
自分は「むっと」ってよんじゃってて、なんか、かっこわるいんだけど。
https://twitter.com/tanakh/status/1015609559673475073
0864デフォルトの名無しさん垢版
2018/07/08(日) 13:33:35.86いつまでtanakhなんてスパコン詐欺師を崇めるんだろうなこのスレの住人
これいいね、Webアプリを完全Rustで作成
ラズパイみたいな環境？
あんな感じ。
だな
それはnode.js環境も同じだが
クライアントサイド → Rust
ブラウザ → Rust
完璧じゃないか
人気サービスの中の人だけ
普通はスレッド立てまくりで対応可能だし、たまに台数増やすだけで問題ないでしょ？
白紙の未来を絶望に染めてやろう。
あれもうかなり古いぞ。
rust 2018で今よりさらに変わるんだぞ。
エラーハンドリングもモジュールもTraitも重要な部分全部かわるぞ。
nightlyで結構実装済みだから現行のnightlyですら違うぞ。
macro 2.0はいいぞ！
Rust 2018にエラーハンドリングの変更とかあったっけ？
Rust 2018での追加・変更って"module, impl trait, Generators/async/await, macros 2.0, NLL, SIMD"だけじゃなかったっけ？
もしかしてdo catchがstable化されるの？それとも、それ以外で変更があるの？
エラーハンドリングで互換性を崩すような変更があるならかなり痛いんだけど…
2018からtryがキーワードとして予約される（catchは廃案）
editionが未完成だと実装できないから2018リリースにはきっと間に合わない
C++が仕事で使えるんだから使えるだろ
てか、Swiftなんてもう4でそろそろ5になるとか言ってるんだぞ
あれが仕事で使えるんだからRustなんか楽勝だろ
やり過ぎはだめってことよな
正直自分が使うcrateやそれの依存関係まで含めて全部書いてる人が信用できるかとかソースまでチェックしてる人なんていないよね…？
イカンなぁと思いながら盲目的に使っちゃってるわ(´・ω・`)
0904デフォルトの名無しさん垢版
2018/07/13(金) 18:29:15.55個人情報を収集しまくりのGoogleやMicrosoftはどうなってしまうんだろうなｗ
おじさんのことじゃん
参照するような設定って出来るんだっけ？
https://github.com/rust-lang/rust/issues/44931
まだ半分も済んでないね
cargoはそこらへん腐ってるから無理。
出来はするけどcrates.ioをクローンするツールの開発が
殆ど動いてないしクローンしてもそのローカルリポジトリを管理するツールがない。
ここらへんはoffline modeも絡んでくるけど、
どうせ欠陥機能作って廃止してまた作っての繰り返しでめちゃくちゃになるだけ。
バカ設計だわ。
go使うよ。32bitsマシン以上向けならgoで十分だ。
どっち
CやC++のほうがまだまともなアプローチしてる
なんかもう根本的に解ってないなっていう感じからくる面白さがある
そのおじさんの物まねをするおじさん達のスレ
ソースコードの可読性が低下するのが残念。抽象化したくてもこれまた仕様的に完全な抽象化が出来なかったりするし
一体いつからNimにはGCがなくなったんだ…？(困惑)
狂人の真似をすれば実際狂人
つまりみんな本物のRustに職を奪われたおじさんなんだよ
RustはできないしNimも詳しくない専門性なしのおじさん
残りは全て模倣犯による狂言だったってのか？」
トグサ「ああ。狂言を読んだ者は初めのうちは怒りを覚える。
だが、その理不尽な怒りを抱えきれなくなると、
衝動的に自らが "Rustによる被害者" になりすますことで、
狂言によって植え付けられた怒りを共有しようとしていたんじゃないか」
バトー「実在しない "Rustによる被害者" たちが連鎖するってわけか……。
── 最初の一人はとうの昔に死んじまってるのにな」
懐かしいなAYBか。文法エラーを直しても通じないのがいいよなｗ
"All of your bases belong to us."
"お前らの卑しいものすべては我々に首ったけ"
ヒドイｗ
まあそういう人がいると思った方が幸せな人がいるのは事実。
fibも書けない確かな"存在"がぐちぐち居座るせいで幸せになれない
「fibを書けないアホ」が「木構造を書けないアホ」に変わるだけと予想
例えば、「俺は数学者だ」とか言ってる奴が微積分すら理解出来てなくて
「でも、因数分解ならできるし」とか言ってたら全力でぶっ叩くだろ？
つまりは程度の問題ってわけ
そして俺はRustでfibや木構造すら書けない奴はどうせ他の言語使ったって
ろくなコード書いてないだろうからそんな奴がプログラマを名乗るなんて片腹痛いわ！と思ってるだけ
fibがかけなくて5時間も喚いた挙げ句
答えを大量に示されても礼のひとつも言えない
下らない批評をしては論破されて潜伏を繰り返しているあほ
「rustに職を奪われた」「fibを書けない」もこいつの本質ではないんだよな
このスレでは誰も話題にしてない？
正しくないfibすら書けないおじさんだったか
？
>>949
検索にも引っ掛からないし誰が困るんだろう
Slackでは話題に出てたけど ここでは出てないかな
>>951
流石にplaygroundには貼ったんでしょうね コード4行目で検索
ほんとだ4行目だけを直接検索したら出た
しかも解決法までご丁寧に解説してあった
>>56はそれも読まなかったのか…
はたまた、読んでも理解できなかったのか…
こんな奴でもC++は書ける（自称）って辺りが日本のプログラマの闇だな
0955デフォルトの名無しさん垢版
2018/07/16(月) 16:24:01.28仕様が結構複雑だからなのか？
http://wiki.c2.com/?ReadOnlyLanguage
rustはノミネートされてないから「書ける」と思うよ（すっとぼけ
昔はAdaの称号だったと思うが
それとも動的リンクでいける？
ttps://crates.io/crates/libloading
なんとなく出来そうな気はするけど。
* 本体とプラグインが同じバージョンでコンパイルされてることを保証する
* extern "C" なインターフェースだけ使う
とかの工夫は必要そう
新しいのに飛びつくのはあの連中(俺も)だからな
hyperやactix webがあるじゃん
はやくして
C言語とPythonとSchemeがちょっとずつしか分からないけど大丈夫かしら
Rustで本格的にプログラミング覚えた人っていますかね...？
根気は必要だけど
https://github.com/imos/icfpc2018
トレイトって他の言語で言うところのインタフェースみたいなもん？
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できるインタフェースと違って
既存の型に対してあとからいつでも実装を保証？できる
のがトレイト？
あと外部で定義されたtraitを外部で定義された型には実装できない制限がある
Ready at DawnってCSやってたけどあれもrustで書くつもりだろうか。
https://play.rust-lang.org/?gist=630529d9c9c65ee7e3a7ea9a2524e841&;version=stable&mode=debug&edition=2015
https://play.rust-lang.org/?gist=54a890fbc7093117363802bf84a9cd0a&;version=stable&mode=debug&edition=2015
gowにはrustlungちう病気が出てくるぞ
そこなんですよ
コンストラクタをトレイト側にかけちゃうのが何か凄み感じるんですよ
インタフェースじゃせいぜいObject型で返すくらいのもんでして
http://mevius.5ch.net/test/read.cgi/tech/1532697692/
新しいスレッドを立ててください。
life time: 166日 2時間 14分 54秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 「ドンドンショボくなる」大阪万博にまたまた“ガッカリ”報道、軟弱地盤のため「乗り物型」展示ゼロ [バイト歴50年★]
- 政府、コロナワクチン啓発に「YouTuber起用動画9本・3200万円支出」認める「接種の重要性など、正しい情報を知っていただくために」 ★2 [Hitzeschleier★]
- 他候補者に「おい売国奴」拡声器で罵声、「凸」と称して迷惑行為も…東京15区補選で何が起きているのか [バイト歴50年★]
- 『平和堂』公式X、いなり寿司誤認逮捕事件「いなりずしを渡した知人もダメ」投稿2件に「いいね」 「誤った操作」と陳謝 [Hitzeschleier★]
- パリ五輪公式服装、業者は非公表 JOC [おっさん友の会★]
- アニメ『魔導具師ダリヤはうつむかない』に関する報道について [朝一から閉店までφ★]
- スクリプとに負けないお🏡!
- ベジタリアン焼肉だのベジタリアンマヨネーズだの、素直に肉食わせないで済んだやろ
- 【悲報】能登半島「早く水くれ！」3ヶ月以上経ってまだこのレベル😨 [616817505]
- すまん、聲の形の女主人公がクソブスだったらどうなるん？ [207516352]
- 妻が突然生でさせてくれた！！！
- 日本史上最高のアスリート「筋トレしてる奴、全員バカですwトラやライオンは筋トレしません」 [308389511]