いつの間にか、公式サイトが日本語で表示されるようになっとる！
日本語だと特に「システムプログラミング言語」って何かバズワード臭く聞こえるなあ
そらRust自体が元々が言語としてまともに機能してない欠陥品なんだからバズワード頼りになるのは当然よ
>>7
プログラミング言語いくつか知ってれば他の言語なんて多少解説読むだけですぐ理解できるぜ、みたいなのをぶち壊してくる言語よね
慣れれば生産性が高いのは分かるけど、チーム開発にはとても適用できない…… C++ std::unique_ptrを使い倒してればすぐ理解できるぜ？(白目
事細かなエコシステムや凶悪なボローチェッカは慣れたら愛すべき馬鹿として愛せるけど、他人に勧めるものじゃないよな
まぁRustじゃないといけないケースってのは少ないから、好事家の中で流行ってれば良いと思って使ってる
俺はコーディング規約でガチガチにしないと使えないC++よりチーム開発に向いてると思うけど。
コンパイルが通らない時に、相談できる人がチームに居ればね
alexcrichton、いつもissueのopen/closeの操作をミスりまくってて笑う
Rustをある程度緩く使えるライブラリ…
Rust使う意味あるか？
Rustのborrow checkerに勝てるレベルのやつはそもそもRustなんて使わずにC++使ってりゃいいしな。
いや、気を使うの面倒だからborrow checkerに任せたいわw
どうせC++でもValgrindなりそれに類するツールでチェックするわけだし、言語仕様で縛ってくれるのは楽だ
C++でチーム開発したことないやつもいそうだしな。
C++から来たやつと、関数型とかから来たやつで感想も違うみたいだし
If it compiles, it worksが概ね成立するのは魅力だよな
tokioが代表だけど、tokeiとかhayakuとか、謎日本語名crateが幾つか有るのは
中二病開発者が多いから？
外人の日本語タトゥー的な…
hayakuは「端役」にも読めるが
>>18
Rust使ってるクズなんて中二病患者とモジカス工作員だけなんだから妥当だろ。 メンヘラは特定の言葉に執着があるからNGしやすい。
kuchikiなんてのもあるな
あとコミッターに@BurntSushiとか@mitsuhikoみたいなのがいる
@briansmithはアイコンが「ス」だし
ところで、Boxをboxキーワードにする件はどうなったん？
そんなどうでもいいことよりクロージャがまともに使えない問題とトレイト境界の問題（これら結構重なる部分あるけど）はいつ解決するの？
昨日のRust入門者の集いは、50人ぐらい集まったのか
少し前のScalaぐらいの盛り上がりある？
やっぱ本当に入門したいやつは勝手にずかずか入ってくるよなー
こんなにRustは欠陥品っていうのは広まってるのにまだ始めようとするかわいそうな騙された人がいるのか。
それとも流行らないことに業を煮やしたモジラさんが雇ったサクラか？
>>29
Rustなんてありがたがる信者に糖質言われるならむしろ本望だな。 少なくとも俺が、Rustはまともに物がつくれないコンセプト崩壊の欠陥言語、っていってることについて、このスレの住民はなんら答を出していない。
ベンチマークの結果が良いとか悪いとか以前にまともにコードが書けない言語のどこがC++の後継言語だ？
C++で書いたバグのないコード（Valgrindチェック済み）をRustに移植してもコンパイルが通らないって時点でお察しなんだよ。
だって、このスレにいる奴はRustコードが書けるから答えも何もないし・・・
なんでこんなに長いこと必死にRust否定を続けてるのか分からんかったけど
自分がRustコードが書けなくて、第二のコードが書けなくて傷つく奴が出ないように、という正義感からだったのか
プログラミング言語の学習コストなんてあってないようなものだ、みたいなプライドを打ち砕かれた可哀想な子なんだな
>>31
cppで書いたコードはcppで使えばいいのでは？
俺が書いたcのコードは、'a'bつけたのと、ポインタインクリメントやめたくらいで割と素直に移植できたけど。
バグが無いってのは、今まで俺事故ったことねえって言う奴くらい、どう正しいか証明するの大変な事だよ。
そういえば、valgrind、スタック変数の境界チェックできるようになったの？ >>34
experimentalだがSGCheckが使えるな。 >>35
おお、そうなのか。
ちゃんと動けばそこそこ良さそうと思ってたし、見てみようかな。
クソ遅いのももう少しマシになってくれてれば良いんだが…。あれも知らんだけなのかな。 公式HPでシステムプログラミング言語、って書いてあるのが読めないで、なんちゃってアプリ作ろうとしたんじゃないかな？
web系だとライブラリのマッシュアップって感じが普通だからライブラリ不足が不満になるのかな。
それ以前に、コンパイルの通るコードが書けなくて挫折してるんでしょ
サーバフロントエンドのマッシュアップだとHTTP I/Fで特に支障は出ないと思うぞ
バックエンドだとライブラリ側がC I/Fが提供してるならさほど面倒はなかった
Rustって最近知ったんだけどどういう目的で使うのがよろしいの？
JavaScriptしか知りませんって人が入門してるらしいけど、全員投げ出すと思うわ。
C/C++経験者しか残らんだろう。
第二言語がRustだったら絶望するよな
第5言語くらいじゃないと
>>43
C++に不満なときこれで置き換える。
ネットワーク系だったらGoのがいいかも。 guiアプリ作る時はrust的にはやっぱxul使うの？
PHPerをScalaに大ジャンプさせようとして大やけどしたチャットワークの悲劇に学ぶべき。
>>46
なるほどー
RubyとかPythonのC拡張の部分をRustで置き換えたりあるいは機械学習や分散処理らへんでRustが有用にはならないだろうか GUIと言えば、GTKの中の人がRustに乗り気で、既に一部置換が始まってるというのが面白い
>>52
C++, python
むかしLisp
かじったのはruby, java , javascript, objective-c >>43
OSとかミドルウェアとかそういうの向け。あと組み込み。
ネイティブの速度が必要だけど、CとかC++やって苦労した人向け。 >>55
同程度のエキスパートのチームだとして、やっぱC++より苦労するかなぁ？ ベンチマークの順位はそこまで気にならないが、そこのコードでrayonとfutures使っているのを見て触らないとと思った
>>52
Java,C/C++,C#
政治的、宗教的な意味合いはなく只で使えるものを探していた結果 >>52
C、Ruby
それと使い込んではいないけどJava、JavaScript、Common Lisp 焼寿司さんが日本語ツイートにリプ付けてるの見かけたけど、日本語分かるんかな？
Google翻訳かな
>>55
一番上のjavaがまだ最適化の余地があるのが気になる
けどガシガシ書きたくないからあんなもんだろうな。 obj-cやc++の立場は、、、
goがbetter cってのは、rustがbetter cってのと同じくらい不可思議だなw
ごめんGo知らずに適当に言ったわ。
Goはなんなの
もうcでいいじゃん
メモリーリークさせる馬鹿に合わせる必要なんかなかったんだよ
>>75
Rustはバカには使えない
バカはCを使わせてもまともには書けない
Cをまともに書けるならRustなんて不自由な言語はなくても問題ない
よってRustは不要 長年C/C++やってた連中は始めから眼中になかっただろ。
Swiftしかり、新しいものに飛びつくのはいつも歴史を学ばない若い連中。
C/C++より(なぜか)性能良いから、borrow checkerに勝てるなら良い言語だがなぁ
問題は、若者も老害もborrow checkerに勝てないから使えない
学習曲線の改善を今年の目標に掲げてたはずだけど、どうにもなる気がしねぇwww
2chなんて年寄りしか見てないからここの意見なんて全くあてにならんよなー
ここ見てない若い人のほうがメインなユーザーだろうし
ちゆ 12歳(おっさん感
Cに比べりゃC++, Rustはランタイムの分のオーバーヘッドが絶対的に存在するから
そこを引き合いに出すならどうやっても勝てんしな
実用性のあるコードを書いた時の性能はどうだかねぇ
>>83
性能はそこまで気にしなくても良い気もする
最近のPC高性能だし
ネイティブでメモリ管理出来るってだけでそこらへんの言語よりは速いし まあプロダクションでのパフォーマンスはServoとQuantumが示してくれるでしょ
>>85
Non-lexical lifetime以外よく分からない Cで書くには煩雑なものを相手にしたときに、
実際Rustがどんだけの結果を出せるか、
というのがみんなの興味だろう。
ちっさいサンプルプログラムみたいなんをコンパイルして、
それでベンチマークテストして結果比較したって、
そんなもんは誰も嬉しくはないし驚きも無い。
オーバーヘッドの一点のみで語りつくせるんなら、
バイナリエディタと機械語でOSだって作れる。
それはオーバーヘッドの無い、最速最軽量だろうね。
free挿入するよりcopying gcの方が速いし
無駄なオーバーヘッドなくそうとしたらlibstdの実装みたいに
raw pointerだらけになるからそんなこと気にしなくていいよ。
jitのおかげでロジックそのまま書いても速いなんてことが
起こらないから将来、最適化は必要になるだろうけど過剰な最適化は必要ない。
抽象度の高いまま低レベルな領域でも書けるからいいんだよ。
javaだと整数型の型を揃えようとするからバイト列の操作とか苦手だけどrustはそういうのないのよ。
>>87
ベンチマークって基本そういう系多いからね
ファイルアクセスとか考えたら速度ほとんど変わらないのに ベンチマークはオーバーヘッドが無視できるよう(特定)処理を大量回数ループさせてる
という意味が分かってないから、そういうこと言っちゃうんだろうねぇ
もっと勉強しろ、若造どもが
オーダが同じでもオブジェクト生成や関数呼び出し等々のオーバーヘッドは係数部分に効いてるんやで
Rustはzero-cost abstractionだのコンパイラによる関数最適化でC言語とさして変わりないんやで^^
VMだと係数にもろに影響するやがな
>>91
だから若造はいないんだって。
Cとか言い出す老人しかいないの。 本当のおっさんや老害はRustスレなんてこないだろ。
ワイは偉そうに古参風を吹かせてた>>77だがまだビンビンの学生やで。 ワイ周辺だと学生はそれなりに見る
よくはてなブログに書いてる人も学生でしょ
そりゃ、おっさんの大多数は新しい言語が嫌いだからね
まだ2chは若者に人気だったのか
slackとかじゃないの
それランタイムじゃなくライブラリ
no_mangleでマングル名消してもランタイムはリンク解消できないだろうねぇ
#![no_std]すればliballocとlibpanic_unwindはlibstdは勝手に外れなかったっけ？
libcoreはliballocにリンクしていないし#![needs_panic_runtime]もしてない
Rustランタイムって具体的には何してくれるの？
ファイナライザ呼び出しとパニック時のスタックダンプ表示？
あとOS無しの環境でプログラム動かす時とかもそうだけど
要するにそういうときだけ
その辺の整備は優先度低いだろうからな。
トレイト境界の特殊化とか知恵の輪みたいな型システムのサポートとかもっとやることがある
IoTブームを考えると、組み込み系が一番Rustを活かせる場だと思う
パフォーマンスが良いし、アップデート出来ない環境で脆弱性の心配が減るのも良い
メモリフットポイントも、先行事例を見るにまあぼちぼちなんとかなってるようだ
新興言語が使い物にならないのはSwiftが証明しちゃってるしな。
学習コストが高いし、仕様変更も多すぎて管理コストがかさむ。
仕事では使い物にならない。
IoTはなんだかんだいってバックエンドCフロントエンドECMAScriptが主流になるんじゃないかな。
マングリングなんかはコンパイル時に解決してるのでは
strはただのデータと長さのペアの構造体
ランタイムとはなんなのか
解決してないから、場合によってはno_mangleが必要なわけでな
プログラムロード時に展開して処理中はオーバーヘッドないだろうけども
IoTブームを考えるとRustの選択肢はありだろうけど
流行りを無視したら性能良く容量少ないバイナリ吐くCかギリギリC++かなぁ
ガチな組み込みは老人ばかりでC/C++で難なく安全なコード書くし
組み込み系の仕事やってると業務での採用提案は現実的には思えんわ
>>115
ガチ組み込みでもC++使うんだ。
自動車とかだとCのみだよね。
家電とか？ >>116
自動車は普通にc++使ってる部分もあるよ。 ハードウェアは未だにZ80が現役のパチンコでもZ80要らないところなら色々使うで。
ソフト部分がjavaかC#か、最近はunityだから格差が大きい。
こういうニッチなところならrustのno_coreも入り込めるかも
ごめん言い忘れた。
いまだにC++使わないのなんか軍事兵器くらいやで戦闘機のOSとか
その辺はAdaが使われてる印象だったんだがCも使われてんのか。
今、MISRA Cを使ってるようなところが、Rust向きだと思う
飛行機なんかはメモリ確保命令は使わずに上書きでやりくりするんでしょ？
リアルタイム性が要求されるから決定的瞬間にアロケーションや解放なんて処理始まったら死ゾ
>>125
そうならばメモリアクセス安全に寄ったRustは不向きの用途だな。
専用ランタイム作らん限り。 >>123
組み込み業界、Ada使うくらいなら素直にアセンブラ使うわw
>>119
他言語へのAPI公開のため最近はまたC言語が流行ってるやぞ
RustもGoもSwiftもC言語とのI/FはあるけどC++とのI/Fはないから、流行りに合わせてCにしとこってのはままある
まぁRustはbindgenとかいう変態ツールでC++マングル名を回避する荒業に出てるからなくても困らんのだけども >>125
ATS2 みたいな機能を Rust も組み込めば良いのに。 >>117
そーなんだ。俺がやってたのはもう10年くらい前だからさすがにかわったのか impl Into<[u8]> for Hoge {
これがエラーになってしまうのですが、どうやればInto<[u8]>を実装できるのでしょうか？
impl<T: [u8]> Into<T> for Hoge {
これも試してみたのですがシンタックスエラーになってしまいました。
logとかrandとか、標準ライブラリではないけと、ほぼ公式ライブラリ化してるcrateのリストって、どこかにある？
>>136
いい感じだね
Authors欄がThe Rust Project Developersになってるcrateのリストが
公式サイトのどこかにあるかなと思ったけど無いなあ そういうのがstdに無いのが不便で仕方ないんだがどうしてそうなったの
>>141
FAQにも無いように見えたしググり方も分からなかったんや
ありがとナス >>133
そこにもlifetime指定できたのですね。ありがとうございます！ C++のとき=で右辺の状態が変わるのが人間の直観によろしくないと
非常に明白な結論が出てるのに
なんで変えなかったんですかね
思考が著しく阻害される
記号が <- だったらよかったのにって？
まあ慣れだと思うけど。
それを言い出したら左辺の状態が変わるのも"直感によろしくない"しなあ
>>145
代入ってよく使うのに2文字はだるすぎ
慣れれば=でも問題ない >>51
valgrindの扱えない 一般のuse-after-free って何だ？ >>149
メモリ以外も含めたリソースの解放後の使用って意味じゃね？ファイルとか >>150
ファイルに関してはValgrindには--track-fds=yesがあるから例として微妙では
もうちょっとドメイン固有なもの、例えばSerdeでDeserializerを２回使うのを防ぐとかの方がありがたみが強そう valgrindみたいな実行時チェックとコンパイル時の静的チェック比較してどうするの
https://docs.rs/try/1.0.0/try/
>Since the introduction of the ? operator, its supporters have preffered its use, ignoring the valid criticism of the ? operator almost hiding the error propagation operation.
彼は一体誰と戦っているのだろう…… というか、try!をdeprecateする話なんてあったか？
Rust 1.13以前をサポートするcrate（特にnursery系）ではバリバリ現役じゃん
そういや、crates.ioに公開されてるものって
対応してるrustcのバージョンが不明確だな
mioは本質的にstd::netを使ってなくねなどと重箱の隅を突いてみる
tokioもサーバサイドで使うぶんには効率的よ？と直前のレスをちゃぶ台返し
エアプログラミングで卓上で論じる分には楽しいけど、実際使ってみようとしたらドキュメント少なすぎるだろ
futuresのtutorialみたらtokio.ioに飛ばされてスッゲーあっさりとしか書かれてないでやんの
な？Rustってまともに使える言語じゃないだろ？
だからもう騙されるのは終わりにしようぜ。
言語じゃなくライブラリの問題なんだよなぁ、言語仕様で躓いたPG(笑)はスクリプト言語にでもおかえり
ソース追い回しても分かんなかったよ, crate futuresのソースがC++のマクロ地獄みたいなの
解決したらそりゃそうだと納得なんだが、sink.and_thenのErrとstream.into_future().and_thenのErrが一致しないのは罠だと思った
お前ら両方ともtrait Futureのand_thenなのに違う型をツラっと返すなよな・・・
sinkから作ったFutureとstream(のinto_future)から作ったFutureがand_thenで連結できないのかと悩んだよ
むしろ同じエラー型しか返せないとしたら面倒臭いわな
例えばfutures_cpupoolで常にio::Errorしか返せないとかだったら扱いにくいのなんのって
Futureの操作元(今回はStream)をエラー時にも返したい時がある的な振る舞いは未だに理解できんぞ
sinkはErrでstreamは(Err, Stream)とかイミフ、どうせなら両方ともタプルにしてくれよ
それはそうだが、StreamFuture::Errorの型はあれはちょっとなあ……
所有権を返したいってのはなんとなく分かるが
reqwest、HTTPヘッダやMIMEタイプまでそれぞれ別個にタイプセーフとかクレイジーだな、いい意味で
いや、hyperのせいか
gitよりmercurialが好きです(半ギレ
pijul(とdarcs)は初めて存在を知ったけどほーって感じ
Pull Requestはサービスプロバイダに依存するから、VCS自体にPR管理機能を持つのは良いのかもねぇ
Rustはgithubに依存しすぎだろ
GoogleやMicrosoftも似たようなサービス始めるみたいだし、もっと中立的になった方がいい
github依存度で言ったらGoよりましじゃないかな？自前でcrates.io持ってるし。
まあgithubに依存してなくてもやらかしたnpm見てるとgithub依存も最悪ではないみたいに思ってしまうがな。
というかgithub以外のまともなホスティングサービスがないのが悪い
Scala/JavaのIvyみたいに、crates.io互換鯖を自由に立てられるようにしようとか
crates.ioのログインにgithubアカウント以外も使えるようにしようとかの動きは無いのかな？
まあそれはともかく、gitとhgのサポートが既にあるのに
pijulとかいうまだまともに使えないVCSをwritten in Rustってだけで突っ込むのは
内輪のノリがきつすぎてイタい子なんだなあって感想
>>177
Haskellのdarcs優遇と同じ現象だな >>178
ghcすらdarcsを捨てたと言うのにな。
というか今気づいたけどcargoってSubversion対応してねえのか。pijulとやらより
そっち先じゃねえの？ >>175
bitbucketがあるだろ！！(今度こそマジギレ
sourceforgeのgitサポートがもう少し早ければ幾つかの連立もあったろうけど
sourceforgeは遅れるわGoogle Codeはへっぽこだわでgithub+git一強になったこのご時世は嫌だねぇ
pijulが強制されるわけでもなく、今まで通りcrates.ioホスティングがデフォルトだからgithub(git)に依存してないでしょ
個人的には面白いVCSだとは思うけど、率先して採用するプロジェクトはなさそう cargoのdependenciesにbitbucketのmercurialを書けるようにするissueは、前に見かけた気がする
たしか、やる気がないわけではないけど、使いやすいライブラリが無い的な返答だったような
直にリンクするとGPLになるとか
>>177
内輪云々というか、たまたま気が向いた人がPRを送ってきたから受け入れたってだけの話じゃないの？
それを言い出したら標準ライブラリだってredoxサポートのためのコードがたくさんあるし >>181
普通にrepositoryのURI指定でhg://bitbucket.org/hoge/hageみたいにしとけば動いた覚えがあるぞ
githubもgit://github.com/hoge/hageにするし、VCS, 接続サーバを意識してなくないかな
今更subversionやcvsを使う気は無いけど、誰かPR出してみようぜ
rejectされるなりacceptされるなり、どっちに転んでも笑い話だと思う pijul(ピフル)試してみた
・ドキュメント無さすぎ
・パッチのハッシュがクソ長いし、指定時に省略できない
・SSH周りがいろいろおかしい。agent使えないとか
・エラーメッセージが全く役に立たない。コード読んで初めて原因が分かる感じ
・現在のバージョンを特定するタグ、IDのようなものが未実装
・複数ファイルの追加は一つずつ指定する必要がある。ディレクトリ一括とかダメ
・ワーキングディレクトリ内の未追加ファイルを一覧するコマンドが無い。要記憶力
・ワーキングディレクトリ内の状態を一覧するコマンドが無い
・ファイルとして受け取ったパッチの取り込みを行うコマンドが無いので、自分で.pijulディレクトリの中にコピーするらしい
結論：実用にはあと2年は待ちたい。すぐ使いたいならdarcs使え
>>185
こんなVCSサポートに入れるとかRustが実用考えて作られてないのがようわかるわ。 pijul対応はpijulの開発者たちがドッグードするためなんじゃないの
pijul自体がpijulで管理されてるからcargoサポートがないと不便そう
何かRustディスることに血道を上げてる粘着がおるな
自分の言葉で批判しようとするとフルボッコにされるから、最近は他人のまともな批判に乗っかってせせこましいレスしかできなくなってるが
>>159とか>>186とか Cと++は今世紀いっぱいは現役だからな
それ以外は覚える価値なし
>>187
取り込まれたPR見れば分かるけど、VCSサポートって言っても、cargo newの後に
自動で pijul init を呼ぶだけの処理しかしてない
Mercurialのサポートとほとんど同じレベルだが、Mercurialの場合は hg init 呼んだ後に
さらに .hgignore ファイルも追加してくれるとこだけが違う
尚、この自動で追加される .hgignore は文法ミスってて使えない なんでお前らはこんな文法はゴミクズ、コンパイラはエラーしか吐かない、ライブラリはカス未満の
クソモジラの息がかかってる言語なんてありがたがってるのか本気でわからんのだが
モジラから金もらってる以外の理由あんの？
>>191
git://みたいにpijul://みたいなプロトコルのサポートも入ったのかと思ってたけど
initだけなら大した話ではないわな
それぐらいならsvnだろうがcvsだろうが
PR出したら簡単に取り込まれそう そういえばsvnはgit init相当の処理はないから
cargo newの時にやることないな
cvsもよく知らないけど同じかな
ああ、ほんとそんだけなのか。
pijulリポジトリやhgリポジトリからもcargoとってこれるとかではないんだな。
--vcs=gitすると.gitignoreも出来るんだね
ところでThe BookがSecondEdition出てるんだけどこれいつからあるんだっけ
>>200
上の方まさに「The Book」のSecond Editionの書籍版じゃん。 食事する哲学者は、なんでThe Bookから消されてしまったんや
Second Editionはどういう意図か知らないけど、
"str".to_string()
"str".to_owned()
の代わりに
String::from("str")
を全面的に使うようにしてるね
String("str")みたいなコストラクタは無いの？
Tokio対応したHyperがリリースされたな
これからWebフレームワークも対応していくのだろうか
pijul試してたら、なんかいつの間にかファイルが壊れて、テキストとバイナリがまぜこぜになったファイルが出来てしまった
またpijulが使い物にならないからrustはだめとか言うおっさんがくるぞ
crates.ioで、中身無しで名前だけ（たくさん）抑えてる人が居るね
rustって名前のcrate登録しようと思ったら、とっくに取られてた
更新止まったの除くとcrates.io使ってるのあんまりないよ。
ホスティング直接探しに行くとrustのライブラリ結構ある。
それより依存型が欲しい。
>crates.io使ってるのあんまりないよ。
ドユコト？
>>225
どゆこと？
より一般化してUnsized Rvaluesにしたけど、Openのまま3か月放置？ >>226
関連するissueがまだopenのままに見える Futuresに詳しい人教えて
Zero-costを謳ってTraitでコスト削減してるのは理解したんだが
id_rpc(&my_server).and_then(|id| {
get_row(id)
}).map(|row| {
json::encode(row)
}).and_then(|encoded| {
write_string(my_socket, encoded)
})
ってやった場合に
AndThen x2, Map x1を初期化時に作るコストについては
実行時のコストには乗らないから度外視って理解であってる？
Aaron Turonのブログ読んでもそこは言及してないように読めるので教えてくれい
コンパイラの最適化で消えるか、消えないにしてもstackいじるだけだから無視できるほど小さいコストなんだと思う
んー、その擁護は微妙に納得いかないかな...
AndThen, Mapは状態変数を保持するenumを内包するstructなので消えないはずだよねぇ
まぁstackいじるだけという言い分として、ならば実行時のcallでBoxFutureを返すのはバッドノウハウってことか
BoxFutureを返すのと、Futureを実装したstructを返すのと、どっちがZero-costに近いかは測ってみるか
サンプルだとBox<Future>だけど、Tokioは一律structを実装してるから、後者の方が早いんだろうけども
すまん、よくよく考えたら実行中にBox<Future>を返すのは動的にステートマシンのタスクを増やす行為だからNGだ
Futureを返さなきゃと.boxed()使ってたけど、素直にPollで結果を包むだけでよかった
futuers-rsは
これfutuereじゃねぇじゃねーか、並列計算してないパイプラインをfutuere呼ぶなよ
↓
すぐにfutures-cpupoolを見つける
までが予定調和。
Zero-cost ~~futures and~~ streams in Rust
これZero-costじゃねぇじゃねーか
↓
Zero-cost(コストがないとは言ってない)
までが予定調和だったわ
下手な自作設計よりは全然コスト軽いけど鵜呑みは良くないね
まず future の綴を覚えるところからお願いします
aturon氏の記事（Zero-cost futures in Rust）を読めば"zero cost"というのは「直にステートマシンを書いたのと同様のコードにコンパイルする」という意味で言っていると分かるはずで、
状態変数があるからzero costじゃないなどという指摘は出てこないと思うのだけど
traitってGoのinterfaceに似てる
って言ったら型警察に起こられるんだろうか
>>237
？
だからコストがないって訳じゃないと理解したんだが
タスク構築のための初期化アロケーションとか、ステートマシンのための状態管理(分岐)の少量コストはあるって解説してるよな
言葉遊びによるZero-cost警察の方なら触ってスマン zero costは宣伝文句で、zero overheadくらいが妥当では
実行はゼロコストかも分からんが書くコストが青天井なので結局意味のない言語
Aaron Turonのブログを引用しながら実は別の意味で言ってましたとか草
javaはzero-overheadの語を使うけどrustはzero-costを使うよね。
zero-overheadだと追加の余計なコストがかからないという意味がわかるけど、
zero-costだとコストそのものがないと言っているのかzero-overheadと同じ意味で使ってるのか定かではないと思う。
Rustでzero-cost (abstraction)といったら抽象化レイヤーによるコストが0という意味だろうね
激おこな警察官が多くて誰がどの立場で何を擁護してるのかワケワカメ
とりあえずまぁfuturesやtokioを下手に使うとコストがゴリゴリ上がってくのは分かった
ステートマシン(AndThenやMap)も抽象化しきれなかったのかstructでI/F切られてるし注意して使わんとな
そりゃ、真にコストゼロはありえないだろう
一般に気にされてるのは、C/C++より多いかどうかでしょ
だれかGUIライブラリ書いて
そしたら社内ツールでC#の替わりに使うで
ゼロコストがabstractionにかかっていることをつい忘れちゃう
まあ普通に考えたら、futuresでもIteratorでもMapを実現したいなら値と関数は保持しないといけないし、AndThenも前と次の値を持ってないといけないよね
ラッパー構造体のコストは引数がコピーじゃなければメモリ的にもCPU的にもゼロだったはず
>>248
別にC/C++と比較してコストがあるかは気にしてないぞ
C++ TemplateとRust Traitは実質同じ所に行き着くんだから比較するほどの意味もなし
>>250
IteratorやMapを抽象化できないのか？、できないならコスト削減できない不適切なLibではないのか？とは思わないのかねぇ
Rustに限らず新興言語はキーワードだけ拾って素晴らしいものだ！みたいな賛美ユーザが多いね
>>249
https://github.com/kenz-gelsoft/wxRust
もう動かないかもしれないけど
去年くらいのwxWidgetsが3.2.0でFFI周りのI/Fを非公開にしてwxHogeHogeが全滅した >>150
コンパイラだってバカ正直にMap構造体を用意してそこにクロージャをそのままぶち込むようなコードは生成しないんやで >>251
>IteratorやMapを抽象化できないのか？
まあ確かにHKTが欲しいと思わないこともないな >>249
GTKはまともに使えるっぽいけどそれじゃだめなの？
俺はgtkあんま好きじゃないからいやなんだけど >>247
>コストがゴリゴリ上がってくのは分かった
何を突然ファビョってるんだか
タスクごとのヒープアロケーション数はΘ(1)に抑えられているだろ 最近の公式の動きを見ていると、WebフレームワークはRocketを推していく方針に見えるな
>>257
何でよりによってnightlyを要求するRocketなん？ >>256
タスク数に合わせてO(n)になってると思うんだけどそれは度外視なのかな？ オラクルがrustでコンテナランタイム作っとるってよ
オラクルの時点でお察し案件じゃん
まあオラクルとモジラは業界のゴロ同士仲がよろしいんですなあ
google という名前のcrateが上がってて、
説明文が "Google is evil"
バージョン番号が "6.6.6"
Rust公式がTwitterで"Rocketの新バージョンがリリースされたぜ"とか呟いてて、それに対して"Ironの何が悪いんだ"的なクソリプが付いてるの笑う
RustのSlackでmame氏にCでポインタとか触ったことありますか？って聞いてるやついてワロタ
関連型ってさなんでいるの？
CeylonやC#みたいにgenericsのin/outで実現できない？
>>261
ライブラリの問題とかそういう回避方法はないのかと考察したけど、goroutineの仕様上無理ぽって結論なのか
rustが最適な言語かどうかは懐疑的だけど、go以外の使える新興言語ってのは他にないし仕方ないのかねぇ >>269 in/outの方が劇的に良かったりするの？MSDNとか読んでもすぐに理解できなかった >>271
良くなったりするわけじゃなくて全く同じもの。
単にrustのジェネリックスに制限があるだけ。
in/outや+/-なのはjavaの境界ワイルドカード型の定義が
長いから短くなったものでキーワードにするかシギルにするかの好みの違い。 C#とか知らないから適当なことを言うけど、in/outって要は型パラメータの反/共変性を指定する構文ってこと？
Rustはクラスがないからあまり関係ないような気が
そもそも関連型と型パラメータは全く別物だし
新しい言語は早い段階から使い始めれば
バージョンアップ時は変更点だけ覚えればいいけど
バージョンアップが重なったあとから始めようとすると覚えることいっぱいすぎ
Rustよ
もっとシンプルに
Cargoがhigh level過ぎでrustcがlow level過ぎな課題はいつ解決するんかな
他のビルドツールを使ったプロジェクトにrustを入れるのが今は面倒
ていうか時報の反応速度が高くて笑う
まさかリリースの度に待機してるのか？
> ・loopのbreakで値を返せるようになった
遂に来たか。
時報であることに使命を感じて全力待機してそう, 機械の鑑だよホント
雑談の種になるよう頑張ってるんだよ、そんなあげつらうことないでしょ
というかどこに行けばRustの話をしていいのか分からない。英語ならRedditがあるけど
あれ、associated constsはstabilizeされたんじゃなかったのか
>>286
現行のbetaではfeature gateが外れているから次のstableに乗るはず rust-jpのSlackとか？
ところでLLしか触ったことなかった俺も最近Rust使い始めてみたんだけど、有識者から見てRustで1番理解が大変なの（あるいは抑えておかなきゃならないとこ…）はどのあたりなのか教えて欲しい。
>>288
トレイト
ムーブ
参照（borrowing）
Javaも触ったことないならトレイトは最初難しそう slackの質問に対するリアクションありすぎてこわい
>>289
ありがとう
公式のチュートリアルみたいなやつ進めてるんだけど今のところトレイトオブジェクトらへんでちょっと理解に苦しんでる rustって現場で使われ始めてるの？
メモリ管理周りのメンタルモデルって他の言語に応用利いたりする？
コードがきれいになるとか？
始めるモチベが欲しい。
>>292
1.クソコードをコンパイルさせてくれない
2.コンパイル通すの少し大変だけど実行時エラーが本当に出ない
3. 速い
4.パッケージマネージャーがよくできてる
1は本当に大きくて、自分のコードとコンパイラが喧嘩になると大抵自分のアーキテクチャが悪く、直すとちゃんと正しい実装になって感動する。つまり正しいコードが書けるようになる >>294
もう一つ。仕事で使ってたりする？
goのcliツールはよく見るんだけど
rust製って何が有名なのかね？
ブラウザ以外で 仕事で使ってるかは別としてcliツールは作りやすい印象
ripgrepしか紹介できないんだがなんかないのか
redoxosのシェルやエディタはunix用としてもビルドできるし
有名かは別として
ripgrepはもちろんだが、tokeiも便利だよ
ion-shellもよく出来てる
おお、色々情報ありがとう。
今のところgoのcliツールのほうが目立ってるのは、単純に1.0のリリース時期の違いによるものなのかな。
redox は気になるなー。rustのメモリ管理の仕組みからいってバグが少ないosになるのかな。ちょっと試してみたいかも。reduxと名前が似てるのがなんかやだけど
goのツールをパクって速いのを作ればいいのか？
goのツールは何があるの？
俺が知ってるのは
peco、ghq 辺りかな。
ghqは常用してるけど最近重くなってきてるからぜひrustで軽くなるならして欲しい。
多分gitにアクセスしてる部分がボトルネックな気がするけど。
あとgitをrustで書き直したらはやくなるとかないかね。
ライナスに喧嘩売ることになるかもだけど。
それをきっかけにlinuxをcにこだわるのをやめてくれるかもw
>>307
Facebookが社内向けにMercurial(Python + C)をRustで一部？書き直したら速かったらしい
俺も、社内向けツールを前任者がgoで書いたのを幾つかRustに移植してる
ただの練習素材として移植してたけど、2〜3倍速くなったよ >>313
おおー。魅力的な話だね。
メモリの使用量もrustだと減るようなきがするんだけどそのへんどうかな。 rustは今の日本だと凄腕のプログラマが使ってるところはちょいちょい見かけるな。
もっとwebの人たちがたくさん布教すればいいんだろうけど、やっぱrust自体が難しいのかね。
C++とよくセットで名前が出てくるから、ビビる人が多いのかなーとも思う
最近真面目に勉強し始めたけど潜在的に難解なバグを生み出す汚いコードを平気で書く人だと
コンパイルが通らないので辛いと思う。
若干煽り気味に言えばPHPやRailsだけやってプログラミングを分かった気になってちゃんと勉強してない人には無理。
ios -> objc, swift
android -> kotlin,java
web frontend -> typescript, javascript
web backend -> go,ruby,php
ってイメージだがrustはどこに入るの？
webassemblyの今後の成熟具合によっては、
web frontendに食い込んでいくかも
>>318
希望的観測で言えば、
今までC/C++で書かれていたようなもの全てと、今goで書かれているものの半分 -> rust
WebAssemblyをほんとに必要としてるのは、ごく一部の人だと思う >>320
例えばc++ でUE4って書かれてるけど
そこをrustでってのはあるのかな？
ゲームエンジンとかはc++ってイメージだけどそれがrustでどうなるのか興味あるなー。
c++よりバグが少なくなってメモリ使用量も減るなら
家庭用ゲーム機とかの性能向上に役立ちそうだけど。 >>321
ゲームエンジンそのものがRustで書かれているのでなければ移行はないと思ってる
自分は据え置き開発だけど、ライブラリやツールやアセットパイプライン含めてC++ならそのまま利用する方が楽だし、ゲーム会社ならC++の資産やノウハウも蓄積されてる >>323
環境的にc++14使うくらいは許されてるの？ >>324
基本C++11かな
部分的に14の機能も使えるかも
そのうち使えるようになると思われる >>320はゲームエンジンそのものがrustにならんかのーって話じゃないの
その上っ面はC++のままで良いんでない >>327
なんややっぱりそうなんだ。
やっててあんまり面白いとも思えなかったしね。
今シンタックスのところを読んでるけど、goより学習コストは高いなーと思った。
メモリ管理のメンタルモデルは学習を避けることができないから、尚の事学習コストは高いよね。
使い始めに関してはc++より難しいんと違う？ goを学習するモチベーションとなったのはgoroutineで並列処理を簡単に書けるからだったんだよね。
phpのバッチ処理を学習期間は2,3日で
goで並列処理を書けるようになった。
まぁ書けたってだけでgoの流儀って独特だから、その後の深淵に結構はまっていったんだけど。
深層学習の為のpython。
iosのためのswift。
みたくrustの始めるきっかけとなる分野ってなんかないのかな？
rustを書きはじめる皆さんのきっかけを教えてください。
>>329
社内でのC++開発に疲れて代替を探して。
ブライベートで使って、社内もこれにしたいと妄想する。そして誰も社内でRust使えない。 >>313
Rustにしちゃって、あなたの後任が困るとか、そういうことはないの？
社内でもRust認められてる？ コードに問題があればcargo runでエラーが出ますけど
ビルドせずチェックだけを行う方法ないですか？
あと定番のlintツールも教えてください
>>331
前任者も認められてたからgo使ったわけじゃなく、goがもっとマイナーだった頃に勝手に使ってただけだし
俺も存在するかどうかわからない後任者など気にしてない
うちは大きな会社じゃないので、何を採用するかはプロジェクトリーダー次第 rustって課題を解いていく感じの学習サイトってないすかね？
goとかjsだとあるんだけど、、、
>>337
わぉ。ありがとうございます。普通にあってよかった nightlyって頻繁に更新ありますか？
モバイルに接続してるのであんまり通信したくないからstable選んだんですけど
clippyがnightlyでしかインストールできないのつらい
cargo checkだと全てのrsファイルをチェックするので
cargo check hoge.rsみたいに特定のファイルを指定してチェックする方法ありませんか？
Stableでは無理
Incremental compilationの安定化を待ちなされ
>>342
あ、そのモジュールが他のモジュールに全く依存していない場合はrustc hoge.rs --crate-type=lib --emit=metadataが一応使えるんだった
ただしこれはカレントディレクトリにゴミをまき散らすからあまりおすすめできない 目の前の便利な箱で調べること出来ない教えて君は
実はRustで作った人工知能試験で動作試験してるんじゃなかろうな
いまbookやってるんですけど
fn main() {
let x = 1;
println!("Hello")
}
これ1回目buildすると
warning: unused variable: `x`
--> src/main.rs:2:9
|
2 | let x = 1;
| ^
|
= note: #[warn(unused_variables)] on by default
って出るのですが、2回目buildするとこの警告が出なくなる
なんででしょうか？
rustってまだ安定してない感じ？
開発環境は何がおすすめなんです？
vscodeを試したけどあんまりrustに対応してない感が
Rustについて調べているのですが2点ほど質問です
・所有権、借用権ってどのようなケースを想定した機能なのか？
並行処理を行うコードを書く時には同期ミスによる破壊を防止できて便利そうだけど上手い活用ケースを想像できない
・OS無しで動かすコードを書くケースでRustが謳うメリットはどの程度いかせるのか？
メモリマップドレジスタへアクセスするためにunsafeと生ポインタを多用することになる
このようなケースでコンパイル時の安全性の検査条件などはカスタマイズできたりするのか
vim + project.vim + rust.vimもいいぞ
コード量が多いと流石にIntelliJ使うけど
ideaのrustプラギンはメソッドチェインが深くなるとハイライトされなくなって、リネームとかも取りこぼすことがある。それ以外はよくできてて満足
>>351
所有と借用は、設計の考え方として言語問わず有効なので、コンパイラに強制されるのはかなり嬉しい。
と言うのも、所有を考えないで動的メモリを使ったプログラムは、シングルスレッドであっても、ライフタイム問題を起こしやすいんだよね。
他人にヤラれると殺意がわく。 >>351
借用に関しては、不意の同期漏れ防止と思ってる。
ご存知の通り、マルチスレッドでは、同じオブジェクトを触るときに同期処理を入れないと、データ破壊しちゃうじゃん？
C言語だと、この危険な状態がデフォルトで、気付くかどうかは人間次第。
でも、rustはコンパイラがその危険な状態を防いでくれると言うだけだと思う。 >>351
最後、OS無しはどうかなー。
自分ならこうするかなっていうテキトーな意見だけど、生メモリアクセスが必要な部分（デバドラとか）はC/C++で書いて、アプリ部をrustで書いてFFIバインドかなー。 Rustの素晴らしさを理解するにはC++を理解する必要がある？
>>360
メモリ安全にかけるのがrustなら
最初から最後までrustで書けるべきじゃない？ >>362
最初から最後までメモリ安全じゃなくてもいいんじゃない？
適材適所で使い分ければ。
マルチスレッド問題はアプリ側に多い問題かなーって。
デバドラ最下層になると、そもそもマルチスレッド要件が無かったり、メモリイメージが生で見える触れる方が融通があって便利だったりするし。
ドメイン境界で考えて、rustを適用する範囲内で潔白なのが重要と思ってる。
この潔白さは、開発者の人数が多いドメイン（アプリ）で、真価を発揮するんじゃないかなと。 racer + flycheck-rust でマクロ補完って無理？
println!とかwrite!とか毎回全部打つのがダルい
>>363
結局cには勝てないのか。
rustってgcがないからメモリイメージを直接いじりやすいのかと思ってたよ。
redoxとかも結局c++に頼ってたりするんかな？ >>363
あと最初から最後までメモリ安全のほうが良くない？
少なくともメモリ関連のバグを撲滅できるんであればrustの価値はあると思うんだ。
逆にできないならrustの存在意義ってなんだろ。
goは並行処理が言語機能に組み込まれてる。
rustはメモリ安全が売りだと思うんだけど、
そこってなかなか地味な売りな気がして >>365
Cに頼る→負けてるって事じゃないと思うけどね。
実際アセンブリ言語はなくならないわけだし。
CPU の高機能化、メモリの大容量化、プログラムの大規模化、があって、開発効率を高めるために、プログラムの大部分がC言語に置き換わったわけじゃん。
で、マルチコア全盛の時代になって、正常稼働面での重大要因としてメモリ安全性が注目されてrustが生まれたのだから、メモリ安全のメリットの大きいところだけrustに置き換わるってのが、普通の流れじゃないのかなーと思うよ。
別にCを駆逐する必要はないしょ。 >>366
そもそも、ハードに近い層でのメモリ安全性って何？って話だと思うんだ。
で、メモリ安全の話が出てこない領域なのだから、rustの出番が無いって事で良いんじゃない？ >>361
むしろC++をうまく使うために、rustの意味論（セマンティクス）を勉強して欲しい、って思う。 goができたのはgoogle社内のc++プロジェクトの置き換えのためだけどrustってどんな動機でできたの？。
まさかブラウザ開発のため？
>>347
キャッシュを無効にして毎回警告を出すにはどうしたら良いでしょうか？ >>369
俺もRustはじめてからC++が少しよく書けるようになりました >>355
へー、monorepo用だからモノノケとな
mercurialをベースに仮想ファイルサーバーにする予定とは、なかなか壮大な計画だ レスありがとうございます
>>355,358-359
なるほど。やはり並列処理時の安全性を担保する機能なのですね
組み込みでRTOSもどきを作って並列処理させるなんて場合には有効なのかな
>>360
構文上罠が多いC/C++の代替となる言語を探していてRustを検討しています
なのでC/C++を使わずにC/C++相当のことを行いたいです
警告もエラーも無しに動作だけがおかしいとか勘弁して欲しいです
他にDも検討していますが何となく新しい方が何かと便利かなと思ったり・・・ >やはり並列処理時の安全性を担保する機能なのですね
race condition の解消はあくまでもメモリ安全の一部でしかない
>他にDも検討していますが何となく新しい方が何かと便利かなと思ったり
Dが検討対象に入って、かつ、低水準用途なの？
意味わからんな
351からは実際にプログラム組んだことの無い人の気配がプンプンしてる。
たぶんnode.js育ちの人だと思うけど、実質1行ないし3行で完結してるクレートが出てきてるね
clippyインストールできないclippyインストールできないclippyインストールできない
clippyインストールできないclippyインストールできないclippyインストールできない
clippyインストールできないclippyインストールできないclippyインストールできない
修正したコミットがが日曜の夜にコミットするって作者が言ってるけど遅すぎ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
CランタイムをスタティックリンクしたくてRUSTFLAGSに以下のフラグを設定しています。
RUSTFLAGS='-C target-feature=+crt-static'
これを環境変数で設定するのではなくCargo.tomlで指定するにはどうすればいいんでしょうか？
http://doc.crates.io/config.html を参考に下のように書いてみたのですが効いてないようでした。
[build]
rustflags = ["-C target-feature=+crt-static"]
オプションの書き方が違っているんですかね？ ["-C", "target-feature=+crt-static"]
でどうかしら
うーん、このへん試してみたんですけどだめなんですよね。
["-C", "target-feature=+crt-static"]
["target-feature", "+crt-static"]
>>381
一時的に古いnightly使えば良いのでは まだruct学んで2日目だけど
これパッケージ入れる時のコンパイルが長いね
補完強化のためにracer入れようとしたらsyntax_syntaxから全然進まなくてCTRL+C押しちゃったよ
基本的なものを覚えるだけならパッケージなんて入れなくても良さそうだけど
ステップアップしたときにそれなりのスペックのPC持ってないと学習するのが厳しい言語って感じ
>>377
C/C++より判りやすく罠が少なくC/C++で出来ることは全て出来る言語を探しています
>>378
ネイティブに動くプログラムで一番経験があるのはアセンブラ(組み込み)です
C/C++はなんの警告もなくメモリがぶっ壊れるし、どこが壊しているのかも判りにくいし
苦手です アセンブラは型がないぶんさらにメモリ壊しやすいと思うが
ライフタイムもコンパイル時に検査してライフタイムの外側からアクセスする処理もコンパイルエラーにするって
これって結局
全部ローカル変数になるってこと？
プログラム全体を通してアクセスする変数はmain関数で用意したローカル変数だからmain関数を抜けたあとは全部開放しちゃうからメモリリークも起きない？
cとかでもやろうと思えばできるって事？
cでmallocとかfreeを使わず、
全部変数定義してつかえばrustと同じ？
メモリに限らずリソース確保全般を行わないプログラムって何ができるのか
可変サイズの入力を受け取るならmallocがほぼ必須じゃない？
1行MAX_LENGTH文字までのテキストしか処理しないとか？
rustってどんな分野に向いてるのかいまいちわからないんだけど
webに使うのはおすすめできる？
C/C++は言語仕様的にメモリの破壊を誘発しやすいと思っているんだけどそう思うのは自分だけなのだろうか
>>388
プロジェクトやプログラムの規模という要素もあるけどメモリを自由に管理できるアセンブラの方が見通しが良く
メモリ破壊に関するリスクも制御しやすいと思う。人間が理解しやすいように並べることも出来るし
もしメモリを壊した時もC/C++より何が起きるかを予測しやすいと思う
個人的にはメモリアクセスの規約を登録できてコンパイル時にそれをチェックしてくれると嬉しいんだけどな アセンブリ的な観点でCの挙動が予想できないと言っているようならRustなんて余計に抽象的で分かりづらいと思うのだが
Volatile関連の制御とかだって面倒なだけだし
>>393
C/C++はメモリマップを意識しないと安全を確保できないけど、マッピングするのはコンパイラでありリンカでありOS
そのような状態で想定しないメモリアクセスが起きた時の挙動を予想することは自分には出来ないです
C/C++でバリバリ書いている人はこの程度出来て当たり前なのかな C/C++というレベルじゃなくて
LinuxのABIやldのリンカスクリプトがわからんレベルの人と予想
>>391
いわゆるWebアプリを書く言語としてはおすすめしない。 >>392
C/C++に慣れていないだけでは。
もしくは動的なメモリ確保を想定していないとか。 >>394
(わりと一般的な)OS上で動かす限り、アセンブリ言語で書いても
リンカとローダが介在することには変わりないと思うけど。 >>351
OSなしアセンブラを必要とする層で使える汎用高級言語を探してるならRustは適さないからお帰り
そういう言語が存在する気はしないけど夢追い人っぽいから応援はしてるよ 新しめのプログラミング言語は十中八九メモリの安全を謳っているけどこれってC/C++でメモリの破壊や
メモリアクセス違反を多発させる事例が多いからと思っているけど違うのかな
これらの低減を目的にC/C++の代替言語としてRustやDなどを検討するっておかしな事なのだろうか
>>400
まじかーgcがないってOS無しで動かせる唯一の言語だと思ってたから残念
例えばESP8266とかESP32で使えたらいいとか思ってたよ。
webが利用用途じゃないって残念すぎるな。
そうするとrust使ってる層って仕事でc++を使ってる組み込み関係の層が
趣味的に触る言語ってことかな。 お前の中ではGC有無とOS要否は直結するのか(驚愕
ESPがどういうチップセット構成なのか知らんけど
ARM CPUならクロスコンパイルして動かせるんじゃね
多分、同じ程度の努力でGC載ってるGoも動くと思うけど
cargo checkすると
warning: the option `Z` is unstable
というメッセージが出るそうなんですがこのメッセージを出す方法を教えて頂けませんか？
Webに関してはそれなりに精力的に開発されているから将来的には使い物になる可能性もある
crates.ioとかだってRust製だしね
>>402
ググるとラズパイ(タダのLinuxだが)向けコードをRustで書いてみたとか、プレステ1用のコードをRustで書いてみた
とか出てくるんだよね。自分が組み込みに使えるんじゃないかと思ったのもその辺が目にとまったから
昔よりかなり良くなっているとは言え汎用機と比べるとデバッグ手段は限定されるし、コンパイル時にコードの妥当性が
ある程度保たれるというのはメリットだと思う
組み込みで「どこかのメモリを壊しているようだが皆目見当が付かない」なんて事態は可能な限り回避したいしね >>400
いや、そういう用途向けでしょ。
実際にOSの実装に用いられてるし。 上の人はOSを書こうとしているんじゃなくてOS無しのままコードを書くつもりなんでないの？
言い換えると、extern crate coreすら出来ないやつ
なんか勘違いしてる人がいるね
Rustが強いのは「ちゃんとラップしてあげれば」どんな環境でも「安全に」動かせること
例えばとあるレジスタを触っているときに他のレジスタを触れないようにするとかも（場合によってはコンパイルエラーのレベルで）できる
ただこのラップするっていうのが一番面倒で、そこで安全を担保できなければ＝unsafe祭りならむしろCのが楽とも言える
ちょっとググったらArduinoでRustを動かすためのライブラリもあるからその辺り参考にすると良さそう
>>408
OS書くのもOS無しで書くのも変わらないと思うんだけど、coreを含められないってどういう状況？
libcoreは何にも依存してないからそんな状況ありえないと思ってた あー・・・何となく判ってきた。組み込みでそのようなコードを書くのか判っている人からレスが付いていたのか
>>396
>>405
今は使い物にならないって事？
向いてると思って趣味のWEBアプリに採用したけどやめたほうがいいのかな
Golangは古臭すぎて使う気起きないし
正直速度はどうでもいいけど構文が好き coreだって何にも依存しないというわけではない、けれどそれは自分で用意すれば良いしね
rust_begin_panicとかをどうやって用意するのかは知らないけど
RustでもOS書けるでしょ
(もちろんCと同じく最低限のアセンブラはいるが)
ぐぐればいろいろ見つかるぞ
>>411ミスった。訂正
× 組み込みでそのようなコードを書くのか判っている人
○ 組み込みでどのようなコードを書くのか判っていない人
>>409
>例えばとあるレジスタを触っているときに他のレジスタを触れないようにするとかも（場合によってはコンパイルエラーのレベルで）できる
そういう話を聞きたかった。レジスタの操作順までコンパイラレベルで面倒を見てくれたらありがたいと思う
xに値を書き込む時はyのnビットを1にしてからxへ書き込むとかあるしな。その定義を作る気力があるかはともかくとして
>そこで安全を担保できなければ＝unsafe祭りならむしろCのが楽とも言える
ペリフェラルレジスタだけunsafeにしてすればと思ったけどそう単純な話ではないのかな
もちろん入力値のチェックは必要になるだろうけど >>413
確かにmemcpyとかあるね、忘れてた
まあこの辺りはCでも間違いなく自分で書くとこなので大したコストじゃないね
> rust_begin_panic
組み込みならシリアルにでもログ出して無限ループとかが普通かな？
こういうのはOS系のプロジェクトがとても参考になる
>>415
> その定義を作る気力があるかはともかくとして
実行時チェックなら多少楽になるだろうしそこは（精神的）コストとの相談だね
> ペリフェラルレジスタだけunsafeにしてすればと思ったけどそう単純な話ではないのかな
個人的にはunsafe使い始めると至る所で使うようになっちゃうのでお勧めしない
Rustの思想的にも未定義の挙動を許すunsafeはできるだけ避けるべきだしね
そんなの気にせずチェックしたいとこだけチェックさせるLint的な使い方もありっちゃあり redoxのアセンブラで書いてる所すらもrust(高級言語)で書きたいって夢を語ってるんじゃないの？
結局何がしたいのか分からんな・・・
そこについては諦めているなら既に実用化されているし
そこを追っているならチップ毎のクロスコンパイラ作りを頑張れとしか言いようがねぇよ
>>415
レジスタまで意識する用途なら、高級言語を使わないのが正解では
> xに値を書き込む時はyのnビットを1にしてからxへ書き込むとかあるしな。
それこそボード固有の話になるので。
高級言語でやるとしたら機能レベルで関数化して中身はインラインアセンブリで頑張るとか。
何れにせよ言語レベルで対応する話ではないな。 >>412
>向いてると思って趣味のWEBアプリに採用した
やってみたら良いと思う。
仮にミスマッチだったとしても、過程や結果を公開すれば、色んな人の役に立つ。 rustっていまのところ
何にも向いてないということか。
golangみたいにgoといえば並列処理！みたいなウリがないとなかなか厳しいな。
とりあえずwebはgoでいいや。
>>419
webアプリ作るならunsafe必須とか？
cもc++も触った事ないからunsafeだけは無理なんだけど… 変なチューニングに走らない限りはunsafeは不要
ただしRailsでいうところのDoorkeeperやPaperclipみたいな便利ツールが少ないからそのあたりは自力でどうにかする必要がある
あと、現状で主要なフレームワークはみんなsynchronous。ただしRocketはそう遠くない将来にasync対応しそう。Ironはそもそもやる気があるのか分からん
>>422
unsafeは不要なのか、よかった
Railsは使ったことないから分からない
今まではNode.jsでexpress使ってたからそのまで分厚いフレームワークは使ったことない
rustってイベントループじゃなくてスレッドだよね？10K問題はどうなの？ goでいいや、という人はまさにgoでよいのでは。
goではいやだ、という人むけ。
goとかいうmapもnull安全もないうんこは絶対NG
goが嫌だと言うなら
kotlinという選択肢もある。
これだとアンドロイドアプリももれなく使えるようになるし、
null安全だし。
何よりideが既にある
kotlinもscalaもjvm言語だからあまりnull安全じゃない
rustはno_coreにしてベアメタルでリージョンにメモリ管理やってもらうだけに全振りすればいいよ！
え？ヒープ使いたい？rustc_privateでalloc系をだな。
アセンブリもcpu毎にアセンブラ用意するのが面倒くさいからrustのinline asm使おうぜ。
>>404
そのまんま。
cargo checkはZオプション付けてるだけだから「Zオプションは安定してないから注意しろよ」ということ。
>>428
言ってる意味がわからない。 >>416
unsafeを使わないと任意のアドレスを読み書きできない(＝レジスタにアクセス出来ない)と思っていたけど他の手があるのか 本格的にOS無しの世界に入ったことが無いから適当だけど、関数型プログラミングの道具が使える、とか？>Rustのメリット
代数的データ型とかラムダ式orクロージャが簡単に扱えるとか。
趣旨から外れるけど、Cの世界に入れるのと同じような感じでRustの世界に入ることができるのも個人的には良いと思ってる
>>429
javaのライブラリ使える代わりにjavaライブラリはnull安全じゃないよって事 >>429
＞cargo checkはZオプション付けてるだけ
補足するなら、これは非標準のcargo-checkサブコマンドの挙動であって、
標準のcargo checkは--emit metadataを使っているから警告は出ない >>429
>>433
普通に使ってれば表示されないメッセージなんですね
cargo checkが出力するエラーや警告などをもう少し調べたいんですけど
これってどこに乗ってるんでしょうか？
cargoのリポジトリクローンしてから適当なエラーでgrepしてもヒットしないんです >>432
VMじゃなくてライブラリの話ね。
ceylonみたいなjavaとのシームレスな通信を捨ててるJVM言語はどうだろうか？
>>434
cargo-checkっていうthaad partyのサブコマンドがあるんだけど、
後にcargo自身に全く同じサブコマンド名でちょっと違うコマンドが追加されたの。
だからcargo-checkの方つかってるはず。
`cargo install --list`してみ。
https://github.com/rsolomo/cargo-check >>430
unsafeを使わないとできないってのはその通りだけど
> もちろん入力値のチェックは必要になるだろうけど
って処理を含めた関数を作ってunsafeな部分を支配下に含めることでunsafeでない処理にするってことが言いたかった
例えるとmallocの戻り値チェックを入れてOption<&mut T>を返す関数を作ってラップすることでunsafeでなくするって感じ
これを面倒くさがるとぬるぽに遭遇するがちゃんとラップすればガッが「一切」必要なくなるわけだ
でも今度はfreeしてない問題が発生するからスマポ作って・・・と徐々に面倒くさくなってきて > コストとの相談
>>431
ライフタイムとか借用とかの安全機能抜きにしてもパターンマッチとか他の言語機能で見てもRustは魅力的だよな
・・・まずい、mainにunsafe付けてBetter CとしてRustを使う世界もありな気がしてきたぞ Java の参照は、Nullable だから、
Kotlin で扱う場合、すべて、Nullable にすると面倒
そこで、Kotlin では、Platform Type (下の3) と言うものを作った
String 変数型に、Null 代入時、
1. String で、実行時に、IllegalStateException
2. String? で、Nullable だからOK
3. 型を省略(String!) で、実行時に、デリファレンスでヌルポ
1. は、インスタンスにアクセスする前に、代入時にエラー。
3. は、1よりひどく、インスタンスにアクセスして、ヌルポ
Kotlin信者が必死だなw
JVM要する時点で組み込み/低レイヤーに向かねーんだよ、土俵が別次元だ馬鹿
Android ARTはJVMじゃない？そのランタイムサイズ、Rustのランタイムサイズの何倍になってるのか分かってんの？
>>441
いちいちスレチだけでレス削除してくれるほど運営も暇じゃねーよ
板違いのスレも最近は「落ちるまで放置してね」の方針なのに >>440
ちなみにkotlin/native 開発中だからそれでrustと同じ土俵に立てるよ。
llvmの中間コード吐けるようになる。
rustより学習コストは低くて関数型チックな言語構文使ってるから
kotlin vs rustが勃発するな。
問題はandroid開発者を取り込めるからユーザー数は圧倒的
IDEも標準が存在する。
という点で色々rustは不利。
rustはwebAssenbryあたりで本領発揮できればいいんだけど。 >>444
エラーメッセージ観るとelse節がないって怒ってるね
yに代入するんだからelseないと値が不定になるでしょ >>444
ごめんちゃんと読んでなかった
fn main() {
let x = 5;
let y = if x == 5 { () };
println!("{:?}",y)
}
これだと動くよね。型を() に統一しないとダメなんじゃない >>447
なるほどそういうことですか
省略しないほうがいいですね
ありがとうございました IntelliJ Rustプラグインが、（IDEの）公式プラグイン化した
ついでにちょっとおせっかいな表示も始めた
関数呼び出し部分に仮引数名を補完表示とか、省略された型宣言を補完表示とか
JetBrainsが開発に参加しているというだけでもそれなりに心強い
あのプラグインの作者、前にPR出したらクッソ丁寧なダメ出ししてくれた
PRコメントの数倍のレスが返ってきてビビったわ
引き続きコミュニティベースで発展するといいのう、MozillaもJetBrainsもあんま要らんことするでないぞ
>>444,446,447,448
型が一致してないからや。
if式のelse句省略して戻り値の型にunitが推論されるのに
thenの方の戻り値の型がunit以外になるからエラーになる。
たぶん、rustc --explain 0317すればクソ丁寧に教えてくれる Windows用のtar.gzを落としてきて適当に解凍
.\rust\binへパスを張って
>rustc hello.rs
error[E0463]: can't find crate for `std`
error: aborting due to previous error(s)
>
えぇぇー・・・・ｗ
.\rustcの中を見てもライブラリらしき物が見あたらないのでどこにいるのかと探したら
.\rust-std-i686-pc-windows-msvcの下にいた。.\rustc\libの下に移動したらコンパイルは
通ったがリンカがないと怒り出す
面倒なのでVC++のコマンドプロンプトからパスを張ってようやくコンパイル＆リンクに成功
無事に実行出来た
というか実行ファイルがかなりでかいな。100KBくらいある。全部込みじゃしゃーないか
あと-vや-C link-args=が無視されているように見える
そもそも今日日tar.gzなんてどこから落としてきたんだっていう
他のインストール方法ー→スタンドアロンなインストーラーにビルド済みを固めたtar.gzがある
何らかの信念があって、rustupを避けてるわけ？
オンラインによるインストールは可能な限り避けるようにしている。あとで環境の再現が必要になった時に詰む可能性がある
メモリ安全が重視されるのって、ハッキングとかに使われるから？
脆弱性になるからってのもそうだけど、単純にSEGVでプログラムが落ちるのを防ぐためというのもある
代わりにunwrapで落ちまくり
いや、うそ
それ以外のバグだと落ちはしない？
>全部込みじゃしゃーないか
msvc toolchainでstaticリンクになったっけ？
>>464
リンカにどんなコマンドが渡されているのか確認できないので詳細は判らない あ、なんか変だ。訂正
× コマンド
○ オプション
>>467
英語で原典的な本が出るから遠からず日本語訳も出るだろ
ただし日本語訳の翻訳の質がどうなるかは全く安心できないことは
近年のプログラミング関連の英語書籍の日本語訳を見れば理解できるだろう 書籍は情報が古すぎて当てにならんぞ。
文書化自体あんま力入れてないからソースコード読むのが一番早いよ。
訳のレベルに関係なく出せば売れるからかな
需要が少なすぎて競争にならないから訳の質がいい物が出ない？
>>469
どのサイトのソースコード読むのがいいですか？ >>470
> 需要が少なすぎて競争にならないから訳の質がいい物が出ない？
そうじゃない
英語の理工学書の翻訳の質はここ20年ほどの間に明らかに著しく低下した
その原因として考えられるのは、訳者が使命感を持たなくなり単に副収入とかの経済的で利己的な目的で翻訳をするようになったことと
それ以上に訳者が大衆化したことも大きい（かつてだと理工学書の翻訳は、ほぼ完全にいわゆる一流大学の教授の専権事項だったが今は全く違う）
またそういう一流大学教官による訳書であっても、近年は、ゼミで原書を読ませて学生（院生？）たちに素訳を出させて適当につなぎ合わせて
訳書として出版したのでは？と疑われるレベルの訳すら出現しているのは、明らかに近年の訳者のモラルの低下（使命感の欠如）の例だろう
近年の訳の質の低下に関してもう一つ重要なファクターとしては、最近の訳者が英語（特に会話面で）は達者になったのかも知れないが
明らかに昭和後期の訳者たちよりも日本語の文章力が低下していることだ（その結果として訳の日本語文が読むに耐えないレベルに堕している訳書が少なくない） というかそもそも書籍を出す以上利益を見込むわけだけどRustの書籍が出たところで到底コストに見合う利益をあげられるとは思えん
唐突に小論文もどきが発生していて笑う
steveklabnikやcarols10centsは大学の教官ですらないだろうけれどそれは良いのか
「監訳者」がいるが「訳者」が書いてない本って、やっぱそんなもんだろうね
あるいは機械翻訳をちょこっと手直ししただけとか
名前を表に出すって内容に責任を持つってことだから、名前重要よ
>>472
なにも今にはじまったことじゃない
＞ゼミで原書を読ませて学生（院生？）たちに素訳を出させて
＞適当につなぎ合わせて訳書として出版したのでは？
プログラミング言語C とてそうやって作られた、といわれている 典型的な老害で笑える
ピアソンの技術書とか今出したら炎上間違いなしってレベルの翻訳もあっただろ
Googleのエンジニアですらやばい翻訳とかするのにたかが大学教授如きが完璧に翻訳できる訳がない
>>478
> 典型的な老害で笑える
> ピアソンの技術書とか今出したら炎上間違いなしってレベルの翻訳もあっただろ
外資系や新興の出版社が出す本は訳書に限らず酷いのは昔から
編集担当者が日本語文のチェックを碌にしないしそういう新興出版社は人脈を持っていないゼロからのスタートだから良い訳者が無かったからね
問題は、近年は、老舗と言える理工系出版社から出されている訳書でも翻訳の質が急激に堕ちて来たことだ
その原因は翻訳の大衆化と訳者のモラルや使命感の低下にあると言ってるのだよ
> Googleのエンジニアですらやばい翻訳とかするのにたかが大学教授如きが完璧に翻訳できる訳がない
馬鹿ですか？
そんな高度で難解な技術書など存在しても極く一握りで、そんな極めて特殊な例を取り挙げて反論するなどナンセンス
そんなナンセンスで反論だと思ってる君の知性を疑うね
そもそもそんな難解な技術書を読んで理解できる人間も一握りだ
そんなレベルの人間ならば原書で読めるから翻訳する必要性も希薄
問題は、かつてならば普通の質で翻訳されていた難易度が平凡なレベルの教科書・技術書・学術書ですらまともな日本語訳でないのが量産されるようになったという点 アカデミアを知ってる気取りの学生の臭いがプンプンするけど、そんなことを書き込んでいる暇があったら期末試験の勉強しとけよな
>>472
> 英語の理工学書の翻訳の質はここ20年ほどの間に明らかに著しく低下した
それ何か根拠があって言ってんの？ どうせお前の妄想だろ。
長々と言い訳せんで良いよ、消えろ。 計算機学の正式な教育を受けたことがないからわからないけど，たとえば数学では大学2年までに学ぶべき科目の教科書は翻訳でも日本語教科書でも定番と呼べる本が出揃ってるんだよね
そんな中で使命感を持って初学者向けの本を訳したがる人はそうそういないでしょ
技術書界隈でもそんな現象が起こってるじゃないの
>>483
解析学と線形代数の定番を教えてください、できればギャップの極度に少ないものを
翻訳じゃなくて、「解析概論」（高木）よりは親切なやつを
是非！ 杉浦本と斉藤本じゃあかんの（多変数の議論に飛躍が入るのはしょうがない）
でもここ20年でネット利用者の情報リテラシーと日本の国際的な技術的地位はかなり落ちたよな
近年は、技術書の日本語翻訳版が出るころには、次のメジャーバージョンがリリースされて買う気を失う傾向
ITは元々レベル低かったんじゃない？ハードは強かったけどソフトはそんなに
Rust関係なくてスマネ
>>491
全てとは言わないけど分野によっては世界トップクラスだったよ
１．コンピュータアーキテクチャ＆オペレーティングシステム
Windowsが走るコンピュータアーキテクチャを開発、販売していた数少ない国の一つ
そのためにWindowsのカスタマイズも行っていた
２．日本語ワードプロセッサ
３．日本語入力変換システム
この二つは語るまでもないよね。ユーザーは積極的に捨てたけど
４．低レベルの実装、解析
かつては日本製のBIOSパッチとか野良BIOSとかがあった。このへんの技術は１とも絡むね どうでもいいけどexaって打ちづらいから普通にlsでええわってなる
>>482
それ以前から理工学書を読んでいる人間ならば多くが同様の感想を持っているわけだが
読んでない人間は知らんがね
他人の投稿が気に入らず読みたくないならば、お前がこのスレを読まずに消えれば済むこと A. 20年前と今の理工学書を比べられる、2chのドマイナーな言語スレにいる
->アカデミック関係者の可能性
B. 自分の意見の論拠が薄い、的確なソースを出せない印象論
->実体験であるなら妥当
C. スレ違いの話を得々と語る、煽りに慣れていない
->コミュニケーションに難あり
>>497が本当に一流大学の教官である可能性は微粒子レベルで存在する
が、話の中身は与太話だし、何を言ったかだけを判断するなら塵芥と同じ扱いでよろし >>497
結局「根拠は無い」というレスして恥ずかしくないの？ 1つのパッケージをインストールするだけでも時間が何十分とかかる
萎える〜
>>504 環境変数としてCARGO_TARGET_DIRを適当なところに置くと、以前にビルドしたcrateを利用してくれるよ
まあバージョンが違ったりしたらやり直しだから気休めにしかならんかもしれんが ライフタイムがよく分からんから、ライフタイム定義なしで動くプログラムは作れるようになったんだけど、
ここから必要に応じて参照使いまくりでライフタイムしまくりが出来るようになるにはどうしたらいいでしょうか？
>>507 個人的な経験談だけど、ライフタイムが複雑で分かりにくいときはデザインから見直した方が良い場合が多い
単にコピーされるのを嫌って参照にすると駄目で、元の値の完全な従属物のときだけ参照を使うと大抵はうまくいく
メンバ変数間の参照はキツいので手を出さない、グラフとか所有権が複雑なのも自分じゃ作らずにライブラリにしておく、とか rustで検索してもほとんどゲームの話題しか検索に引っかからなくて草
rustの日本コミュニティーないの？
>>508
え、同じstruct内でメンバ変数間の参照は出来ないでしょ？ Arcでもダメなんだっけ？使う機会がないからTutorialで読んだきり見たことないけど
>>507
lifetimeはextentとregionをごちゃまぜにした語だから
lifetimeに言及してる部分は実際にはextentの話かregionの話に分かれる。
だからextentとregionを理解すればいいよ。
特にscopeとextentの区別がついてないやつが非常に多いからそこ気をつける。 何かextentとregionを説明したものってある？
>>517
extentはscopeとよく一緒に説明されるからそこら辺で検索。
言語によってはextentの事をlifetimeと呼ぶから
そういう言語のlifetimeを詳しく解説してる本とか当たってもいい。
ただし、rustのextentとregionを混同したlifetimeの事と
extentをlifetimeと呼ぶ文化におけるlifetimeの区別は
事前にちゃんと付けておいたほうがいいね。
rustのlifetimeは無駄にややこしくしてるから頑張って。
regionの説明はほとんど見かけないから近道は論文読む。
実装ならRTSJとCycloneくらいしかない。
region理解するならzone/arena（両方同じもの）とリージョン多相とリージョン推論も理解した方がいい。
あとrust固有の話だとrustのリージョン多相は部分多相も備えてる。 無駄に話を複雑にした挙句論文を読めときたか、少し前にいたイキリ大学生かよ
普通に公式のThe Rust Programming Languageを読んで現行Stringを使ってるなら&strにして組み直して見たら？
structのメンバに参照があると否応でも意識/理解せざるを得ないと思うぞ
>>519
いざ言われてみるとstructで参照を持つのってどんなときか思いつかんのだけど じゃあまずlifetimeについて考える前に、参照のメリット/デメリットについて考えような
公式サイトのドキュメント読んでこい
c++だと参照保持すると生存期間管理ないからあぶないからやらない
スマートポインタ使う
そのへんの感覺の違いがまだなれない
impl Traitがstableに入ったらどうなるか分からないけど、MapとかFilterとかがstructに参照+独自データって形になってるよ
あとはCharIndicesとか。実際のソースはちょいと違うけど元のデータへの参照+と現在位置っていう形になってる
昨日Slackに参加した人たちはお前らって認識で合ってる？
コンパイル済みのバイナリパッケージを公開してほしいけどそういうのは実現可能ではない？
>>528
具体的にどのあたりが使いづらいと思っているの？ >>527
cargoにそんな感じのサブコマンドあった気がする PathはPath::new(&str)が参照を返すから使いづらい(参照を使いこなせない)
PathBuf使えば楽になったよ！
>>529
返り値で返せないとか
PathBufすると変換いるしめんどい
引数の文字列のライフタイムで怒られる
とか >>532
>返り値で返せないとか
>引数の文字列のライフタイムで怒られる
fn file_stem<'a, P: AsRef<Path>+?Sized>(path: &'a P) -> Option<&'a OsStr> {
let path = path.as_ref();
path.file_stem()
}
これじゃダメ？
>PathBufすると変換いるしめんどい
to_ownedやintoするのもめんどくさけりゃ、もう死んでしまえ こんな使いづらさでしょ
fn path<'a>(name: &str, ext: &str) -> &'a Path {
Path::new(&format!("{}.{}", name, ext))
// error[E0597]: borrowed value does not live long enough
}
まぁこれも死んでしまえ事例ではあるが
別所にOsStrの所有権(ライフタイム)がある場合に参照だけで済ますためのPathなので
動的に生成したOsStrでPath(参照)だけを返せると思うなよバーカというね
impl Traitっていつstableはいるんだっけ？
>>536
特に時期は決まってないはず
少なくとも次のstableではない owned valueとborrowed valueの区別がついてないだけじゃん
まあ、Sizedと!Sized (DST)の区別がつきづらいってのもあるとは思う
strとString然り、[T]とVec<T>然り、OsStrとOsString、トレイトオブジェクト、そしてPathとPathBuf……
>>538-539
それらが区別はついても
その上でライフタイムを理解してないと使いづらいという話じゃないの
>>534なんかはPathがborrowed valueで!Sizedなのは分かった
それはそれとしてPathのまま返すにはどうしたらいいの？って
ライフタイムをきちんと理解してない初学者は躓くわけじゃん ええぇ、今までPathが返り値で返せないの意味を分かってなかったのかw
!Sizedな型は+Sizedとかで型サイズを固定させて返すとか頑張るんでしょ、Pathは出来なかった気がするけど
PathBufはDeref type Pathがあるからまぁなんとか
str, String等の命名規則がStr, StrBufじゃないのは気に入らん、みたいなのは分からいでもない
なんか歴史的背景があるんだろうけど、考えるのが面倒でそのまま受け入れてる
習いたての頃に[u8]を引数に取ろうとして躓きまくったのを思い出す
そういやこれって何でわざわざコンパイラー組み込みでファットポインターを定義してるんだ？
struct Path<'a> { start: *mut (), end: *mut (), marker: PhantomData<&'a PathBuf> }じゃダメなのか？
>>544
それだとimpl AsRef<Path> for PathBufとかが出来ない PathがSizedじゃないってのが初学者的にめんくらったわ
strと同じだと思えば理解できた
>>537
nightlyって1.21って出るけどそこに入るわけじゃないのね >>542
いかにもRust FAQに載ってそうな話題だと思ったが、ちらっと見た感じ、載ってないな
和訳も1割ぐらいしか進んでないし >>541
>>542の言うとおりそこはライフタイム関係ないから
デフォルトがムーブセマンティックスで、
借用はsubstructural type systemに守られてるってこと覚えたらライフタイム知らなくても分かる。
>>547
特に決まってないよ。
nightlyの途中でマージされたのがいきなり次のstableに入ることもあるし。 ちょっと聞きたいんだけどrustのマクロって裏でどういうコードが生成れてるか分かる機能ってあります？
Cのプリプロセッサなら生成コードが出力できるけど、、、
Webにいるプログラマって、マサカリとかに代表されるように人格が狂ってる人多いよね。正しければ正義的な。
2ちゃんはさらにひどいけど、そうじゃなくても。
実社会でプログラマの地位が認められてないからかなぁ。
>>550
&PathじゃなくてPathを返すって話だよ
Path: !Sizedだから参照を経由しない形では返せない（fn() -> Pathと書けない）というお話ね
>error[E0277]: the trait bound `[u8]: std::marker::Sized` is not satisfied in `std::path::Path`
こういう流れを見ると本当にDSTは理解されづらいんだなあと思う
>>551
Nightlyで、rustc -Z unstable-options --pretty=expanded foo.rs
これのラッパとしてcargo-expandというものもある
https://github.com/dtolnay/cargo-expand Path:newが&Pathを返すというstdライブラリ仕様を言及してたのかよwww
そりゃ失礼、そんな所よりそれをどうやって使うかを話してるつもりだったわ
>>558
標準ライブラリのパブリックな型ではOsStrくらいじゃないかな
from系の関数も含むのなら、std::slice::from_raw_partsとかstd::str::from_utf8とかもある
標準ライブラリ外のクレートでもstrに対するラッパとかでそういうのがあった気がする >>554
オレも値受け取った後の話だと思ってたわ ごめん言い忘れたぜ。
>> 558
fn new<S: AsRef<T> + ?Sized>(s: &S) -> &Self
に一般化出来るの全部。transmuteしてるだけだもん。
>>562
これ系の実装がやたら低レベルなのってどうにかならんもんなのかねえ…… とは言え、Pathみたいにnewtypeパターンでnewtypeの元の型の参照からnewtypeの型の参照を得るケースなんてそう多くないからな(というかDSTくらいでしかやらない)
transmuteもやむなしだろう
newなんて普通過ぎる名前が悪い
sliceよろしくfromにしておけばよかったんだ
IntelliJ Rust Pluginのエディタが型表示をヒントとして表示するようになってクッソウゼェw
一瞬便利かなと思ったけどやり過ぎだと思ってオフにしたった
futuresでチェーンしてると型名が長すぎて実態のコードが画面外に追いやられてたわ
変数名にフォーカスしたら型名表示くらいのFRやPRは出てないものかしら
>>567
その機能を持ってきたJavaだと型名が短いからいいんだけどね みんな何でRust書いてるの？IntelliJ派？
Path(PathBuff)に拡張子を追加するにはどしたらいいすか
f.txtをf.txt.zipにするてきな。
ggrksなので雑に答えてみる
let path = Path::new("f.txt");
let new_name = format!("{}.{}", path.to_str().unwrap(), "zip");
let new_path = Path::new(&new_name);
print!("{:?}", new_path);
これ以上雑な実装はねーだろ(ﾁﾗｯﾁﾗｯ
やっぱそーなっちゃうんですねー。
ありがとうございました。
さすがにこれ以上エレガントなのはないですね
元から&mut Stringや&mut OsStringを持っていてそれを&Pathに変換するような場面なら、素直にStringやOsStringの時点でpushとかで加工した方が手軽だと思う
OwnedなPathBufしか持っていないのなら一旦OsStringに変換してから拡張子を足してPathBufに戻す
&Pathや&strしか持っていないのなら、そもそもその状態では書き換えようがないからto_ownedする
&mut PathBufしか持っていないのなら、多分設計が良くない。&mut OsStringを受け取れるようにできないか検討しよう
エディタわりとバラバラなのな
俺はVimだけど何となく気になった
来るかなぁと思ってたが、案の定エレガントじゃない回答(>>575)がきたぞw
卓上で語るのが好きでコードに落とせない子なんだろうなぁ
>>575はそのバリエーションで実装に落としてあげるとエレガントな回答になるからちょっとやってみ？ >>577
1番目
fn f(path: &mut OsString) -> &Path {
path.push(".zip");
Path::new(path)
}
let mut path = "f.txt".into();
assert_eq!(Some("f.txt.zip"), f(&mut path).to_str());
2番目（assertionは省略）
fn g(path: PathBuf) -> PathBuf {
let mut path: OsString = path.into();
path.push(".zip");
path.into()
}
3番目
fn h(path: &Path) -> PathBuf {
let mut path: OsString = path.into();
path.push(".zip");
path.into()
}
ついでに4番目（実際に使うべきでないが）
fn i(path: &mut PathBuf) {
unsafe {
(*(path as *mut _ as *mut OsString)).push(".zip")
};
} 1〜3がすごく無駄なバリエーションでワロタ
まとめてこれでいいじゃん, 分けて挙げた意味あるのかいな
let path = f(PathBuf::from("f.txt"));
let path = f(Path::new("f.txt"));
let path = f(OsString::from("f.txt"));
fn f<P: AsRef<Path>>(path: P) -> PathBuf {
let mut path: OsString = path.as_ref().into();
path.push(".zip");
path.into()
}
cloneする奴としない奴を同列に語るのはどうなんだって感じだがな
4を頑張れば>>573を超える雑な実装にできる可能性がありそうだけど無理かなぁ
まぁ無理か・・・ つまり、雑さ選手権であると言う事を見落とした事が>>575の敗因か() PathBuf::pushじゃいかんのか
let buf = path.to_parh_buf();
buf.push(".zip");
buf.as_ref()
一番良いのはPathの元になったOwnedな型にpushすることだと思うが
let mut buf: PathBuf = "f.txt".into();
buf.push(".zip");
println!("{:?}", buf); // => "f.txt/.zip"
>>581
関数f内でのPath/PathBufのメモリ確保処理に差はないから必要なら後からas_pathでもしたらいいんじゃね
むしろas_refやintoのオーバーヘッドを気にすべきかのう, 100万回くらいループしたら1秒くらいの差が出るかも？ 失礼、PathBuf.pushだと/がついてしまうのか
だれも>>550に肝心なこと言ってやらないのな。
>>550
関数が&Path返すだけじゃE0597はでねぇのよ。たとえば>>534のは
>fn path<'a>(name: &str, ext: &str) -> &'a Path {
>Path::new(&format!("{}.{}", name, ext))
>}
&format!("{}.{}", name, ext)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
この中でnameとextをdropするからE0597出るんだよ。
まあ、罠だけど。ただの面倒くさいっていう見本みたいだし。
借用を関数の中で結合して返すってのが潜在的に危険だから
やり様は色々あるけど↓が一番簡単。
https://play.rust-lang.org/?gist=e4937a92f292952a620eaa7bffa51c21&version=stable
>>563
無理、rustはこういう型シノニムを構造体でラップしたfat pointerとして定義するからtransmuteは必要になる。
こういうnewtypeがやりたいのはunsafe消すこと。
名前からtransmuteしてるようには見えないから名前が悪いのよ。
>>565
from/intoは使い方決まってる >>587
Path::newやas_ref、intoは単に型システム上の操作であってnoopなのでは(検証してない)
だってPathやらPathBufやらはOsStrやOsStringに対する単なるnewtypeでしょ let mut buf = PathBuf::from("hoge.txt");
let mut ext = buf.extension().map(OsString::from).unwap_or(OsString::new);
ext.push(".zip");
buf.set_extension(&ext);
>>590
Path::into::<PathBuf>はstr::into::<String>と同じでメモリアロケーション走るはず
as_refはほぼnoop fn f<T: Trait>(t: T) のトレイトによる分岐はnoopだけど、as_ref, intoはnoopとは限らんよねぇ
impl AsRef, Intoの実装でゴチャゴチャ処理するモノもあるだろうし
Path, PathBufに限ってはinnerを返すだけっぽいからコンパイラによる最適化でnoopになるかな
2,3回前のリリースでもコンパイラ最適化を抜本見直ししてたし、どうなってるかワカラン(自分も検証する気ない)
雑に拡張子生成部のワンライナーを目指した(改行がないとは言っていない
let new_ext = ".zip";
let mut buf = PathBuf::from("hoge.txt");
let ext = buf.extension()
.map(OsString::from).map(|mut ext| {ext.push(new_ext); ext})
.unwrap_or(new_ext.into());
buf.set_extension(&ext);
std::path::Componentsのimpl AsRef<Path>みたいな地雷もいるけどな！ > as_refがnoop
地雷を踏み抜かないように使いたい所存
ミス。
> type Item = Option
の Option<> は要りません。
>>597
impl<'a, T> Iterator for &'a Fooじゃダメな理由とかある？ impl<'a,T> Iterator for &'a Foo<T> {
type Item = &'a T;
fn next(&mut self) -> Option<&T> {
Some(&self.x)
}
}
これはこれで error[E0495]: cannot infer an appropriate lifetime for lifetime parameter in generic type due to conflicting requirements
エラーが出ます。
>>600
nextの戻り値のlifetimeが不足している
Option<&'a T>にしなくちゃ >>601
おお、出来ました！ ありがとうございます。
a.next() ではなく (&a).next() となってしまうのが心残りです。
関連型 Item のライフタイム問題が無ければ素のコードで行けるのに、
何故こんなことになってしまうのか…… >>602
Vecとかみたいに、&'a Foo<T>をラップするstruct Iter<'a, T>とfn iter(&self) -> Iter<'a, T>を作った方がエルゴノミクス的に良さそうではある
>>597のコードで動かないのは、Iterator::nextのレシーバのライフタイムが匿名だからself.xが後で書き換えられるのを防げないことによるものだろう
Iteratorトレイトの仕様上、仕方がない ていうかあんまり本質的な問題ではないけどtakeを使うべき場面だな
Copyは良いがCloneは避けたい
Cloneどんどんやって良いようなプログラムならrustで書かなくても良い
error-chainのまともなサンプルがないんだけど、みんな使ってないのかな
crates.ioのreverse dependenciesが10ページを超えているようなcrateを「みんな使ってない」はずがない
GitHubのexamplesでなんやかんや事足りるからなあ
テキストエディタも高機能な奴は起動が遅かったり動作が重い印象がある
>>611
error-chain、なんか使いにくそうと勝手に思い込んでる >>615
むしろ、Rust界隈でまともな日本語記事とやらがどれだけあるのやら…… >>613
Notepad++ってちょっと重い。SakuraEditorより重いと思う。あとSDIで使えなかった気がする 直受けの50万 客：いつまでもうちにいていいよ
3次受けの50万（客は70万払ってる) 客：短期延長していい？
5次受けの50万（客は110万払ってる) 客：作り終わったらとっと出てけ できなかったら即退場だ
長時間労働 高稼働 高スキル要求が多い
零細フリーランスサイトは5次受けから誰もできない難易度の高い仕事 余り物の仕事を紹介してくる。40万円代でやってくれと
これならJIETから3次でいったほうがいいな
446非決定性名無しさん2017/08/02(水) 22:12:48.95
JIETに毎月5千円払えば３次から入場できるだろ？
高額をうたうフリーランスのサイトはだいたい５次から４５万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした
473非決定性名無しさん2017/08/03(木) 15:21:30.71
JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の
間でやらしている。
372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ
それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト
自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む
標準的なステーメントや型、メソッドなどがずらずら並んだ資料とかないのかな
エディタ用に定義ファイルを作りたいのだがLearning的なページだと全部載っていなくて・・・
いくつか↓のコードについて質問させてください。
https://play.rust-lang.org/?gist=b2fe59eb7aee706b6acb67bb9709967f&;version=stable
1. PartialEqが実装されていないというエラーが出てしまうのですがどう対応したら良いのでしょうか？
試しに
#[derive(PartialEq)]
pub trait Serialize {
としたところerror: `derive` may only be applied to structs, enums and unionsというエラーが出てしまいました。traitにPartialEqを持たせることはできないのでしょうか？
2. error[E0277]: the trait bound `std::vec::Vec<&Serialize>: std::iter::FromIterator<Value<'_>>` is not satisfiedというエラーですが、これはどのようなコードにすれば良いのでしょうか？解決方法が全く思い浮かびませんでした。
ちなみに、enumでArray(Vec<Value>)ではなくArray(Vec<&'a Serialize>)となっている理由は外から型？を追加したいためです。
よろしくお願い致します。 トレイトと型、ライフタイムパラメータと型パラメータの区別が付いてないような、
pub enum Value<'a> {
Nil,
Array(Vec<&'a Serialize>),
}
これとか、書くなら
pub enum Value<'a, T> where T: 'a + Serialize, {
Nil,
Array(Vec<&'a T>),
}
こうでは？
> impl<'a> Serialize for Value<'a>
...
一応impl<'a> PartialEq for &'a Serializeはできる
クソの役にも立たないからやるべきでないが
>>625
ありがとうございます！
頂いたpub enum Value<'a, T> where T: 'a + Serialize, {を入れてみたところ以下のようなエラーになりました
error[E0243]: wrong number of type arguments: expected 1, found 0
--> src/value/serialize.rs:10:24
|
10 | impl<'a> Serialize for Value<'a> {
| ^^^^^^^^^ expected 1 type argument
この場合Serializeを実装した型を追加で指定しないといけないと思うのですが、例えば
struct UUID {
uuid: u128,
}
impl Serialize for UUID {
}
こんな感じの型をライブラリ使用者が外部から追加しようとした場合、教えていただいた書き方だとどのように指定すれば実現できるのでしょうか？
あと最後の…（省略されてる？）が気になります…
>>626
そんな書き方もできるんですね！参考になります！ >error[E0243]: wrong number of type arguments: expected 1, found 0
この場合、impl<'a, T> Serialize for Value<'a, T>としなければならない。というかエラーメッセージが言っていることそのもの
ところで、Value::Arrayには複数種類の型の値を入れることを想定している？
だとしたら>>625のような型パラメータによる手法は適さないと思う
実現したい事が分からないから具体的な提案はできないけれど、とりあえずArrayのなかに&SerializeやT: Serializeを持たせる以外の方針が必要だと思う
例えば、serde_json::ValueだとArrayの中にT: Serializeでなく、Valueを入れ子に持っている >>628
> ところで、Value::Arrayには複数種類の型の値を入れることを想定している？
はい、いろんな型を入れたいです。
今現在↓みたいになっていて（コンパイルできない）改行が多くて書き込みできなかったので改行を減らしてあります。
pub enum Value<'a> {
Nil, Bool(bool), Int8(i8), Int16(i16), Int32(i32), Int64(i64), UInt8(u8), UInt16(u16), UInt32(u32), UInt64(u64),
Float32(f32), Float64(f64), Binary(Vec<u8>), String(String), Array(Vec<&'a Serialize>), Map(HashMap<String, &'a Serialize>),
}
これをライブラリとして公開して、そのライブラリの使用者が
struct UUID {
uuid: u128,
}
impl Serialize for UUID {
fn serialize(&self) -> Vec<u8> {
unimplemented!()
}
}
こんな感じにSerializeをUUIDに実装すればArray(Vec<&'a Serialize>)の中に入れられるのではないかと思い実装しました（だめだったのですが…）
serde_jsonも参考にしたのですがArrayの中にValueを入れてしまうとライブラリの使用者が型を追加できないのではと思って上の感じにしました。
何かいい方法はないのでしょうか？ >>631
すみません、sageのこと忘れてました… rustの使用者は型をガチガチに固めて型安全であることを至上としてる風があるから
利用者が自由に型を追加できることの方にスッキリしない印象を持つのではなかろうか
例えば、hyperのHTTP Headerとかね
それでも尚そうしたいのであればrmpvなやり方は正しいんじゃないのかね
>>633
なるほど
rmpv方式でやってみようと思います！ ライブラリを作る側はゆるゆるにする、使う側はギチギチにする、だったかな
何の言語における誰の格言だい？
Rustライブラリの話じゃないよな, Rustはno_std + unsafeでもしないと作る時すらギチギチだものな
>>638
ありがとう。
本家ソース読んでると、ドキュメント化されてない文法とか現れて時々困惑する。 impl-specializationってfor T以外に具象型でも出来たのか。パラメタ型が現れればいいのか。
>>640
まだRFC #1331が出来てないから正式な文法は存在しない。
自分が使ってるrustcのソース読む以外に文法知る術はないよ。 チルダ記号~、owned pointer が廃止されてから余ってるけど、何かに使わないのかね
オフラインで開発するときにどうすべきかを書いたドキュメントってないの？
インストール方法とかライブラリの取得・展開方法とか
最近のpythonではpipでコンパイル済みのバイナリをダウンロードしてインストールしてくれるけど
rustの世界でもこうなりませんかね
前も同じ質問してたな
rpmやbrew, windows storeにバイナリをアップすればいいんじゃないの
ユーザ向けのバイナリ配布環境なんてrustやcargoが整備するモノじゃないでしょ
どうせrustやcargoを扱うのは開発者で
開発者はバイナリよりソースの方が色んな面で助かる
>>643,647
めんどくせぇ話ししてんな。
alexcrichtonが頑なに拒み続けてるからオフラインでcargoは*まとも*につかえね。
依存crateが全部ローカルにあれば問題ないけど、そもそも外部crateがcargoに
依存してるせいで結局、ネットワークにアクセスする。それにapache archivaみたいなのが
rustにはないからローカルで管理もできんし、cargo-vendorもcargo-local-registryも開発止まってる。
現状、依存グラフの全てを事前にローカルにダウンロードするツールがない。
cargo側のindexもcargo.lock更新する必要もないのに
ネットワークアクセスしてオフラインでクラッシュする問題は
そろそろ落ち着いてきたけど、rustcの依存関係調べるあたりが
腐ってるからそっちも影響してくる。これの問題は今、
インクリメンタルコンパイル実装の障害になってるからどうにかしてる最中。
海外は日本と違って無線LAN環境普及してるからか、
ちょっとオフラインになっただけでテストすら走らせられなくなったりでissue飛びまくってんだけどね。
結局replaceも糞でpatchに置き換わるし。 自宅ならともかくモバイルで開発しようとするとオンライン必須は迷惑
rustc直打ちなら問題ないけど非標準のCrateをどうするんだという話に
モバイルもさることながらオフライン限定サーバとかあるしなあ
よく分からんけど、週末カフェでテザリングしながら開発する分には全く困ったことないけどな
海外っつーか米国は半端に無線LANが整備されまくってるから大変そうだなぁとは思う
>>652
> よく分からんけど、週末カフェでテザリングしながら開発する分には全く困ったことないけどな
節子それはオンラインだ。
飛行機に乗ってる時とかはそれなりの時間オフラインになりそう。 >>653
清太よ、>>649の「自宅ならともかくモバイルで開発しようとするとオンライン必須は迷惑 」へのレスだよ
この「モバイルで開発」はテザリングを指しているのではないのであれば、どういう環境のこと言ってるんだろうね 移動中という状態を除外したら移動体通信ではなくて只の無線通信
>>656
そういう公式ツールの増大は開発環境を複雑＆巨大にするばかりだからやめて欲しい
cargoサブコマンドを公式rust libよろしく外部に吐き出してしまえば鬱陶しい文句も出なくなりそう >>659
Refを返すのは思いつきませんでした。
ありがとうございます。それでもよい気がするのでやってみます。 このスレで話題にするのはアレかもしれないが、 Servo nightly build が
いつ試してみても盛大にぶっ壊れていて、開発順調なのか心配になる。
Rust で開発していると mutability で詰むことがあって、よーく考えてデータ構造なり
を変更すればうまく解決できることが多いし、コードもより良くなっていることが多い。
でもその変更って毎回異なった自明でないものだし、局所的なもので済まないこともある。
Servo くらい大規模なプログラムになったとき、もうどうしようもなく詰んだりしないんだろうか。
やっぱブラウザ作るには向いてません
てなったら悲しいな
気づいたら struct のメンバがほとんど RefCell になってるとかありそう。
Rustに熟知してれば変更は自明であり、機能分解点を精査してれば変更は局所的なもので済むんでないかな
小規模なモノを無計画に作るにはRustは適さない言語だと心底思う
Servoは長いこと開発続けてるけどあんまり精力的に開発する気なさそうだよなぁ
Mozillaが営利団体として潰れそうだし・・・実際Mozilla Japanは潰れてるorz
キノコ雲を見上げるsteveklabnikの画像がRust界隈でにわかにミーム化しつつあって笑う
servoで作ったモジュールがfirefoxに取り込まれていっているし、実験プロジェクトとしては成功なのでは
Rustに限った話ではないですけど
・構文解析
・ハイライト
・オブジェクト追跡
・入力補完
などの機能を持ち高速に動作するテキストエディタってないですかね？
JavaやNode.jsを使った物は総じて動作が重いですし、Cなどで書かれてネイティブな物は機能性で劣る気がします
>>667
Node.jsで作ったエディタが重いってそれVSCodeの前で言えるの？ ageるなアホ
VSCodeつーかAtomは実際重たいからな
あとスレッドぶん回すからノートPCで動かすとバッテリー消費がシャレにならん
JetBrainsのCLionにRust Plugin入れたらブレークポイントも貼れるし良いぞ
誰かJetBrainsから有料版出る前にブレークポイント貼れるようにするPR出さないかねぇ
地味に高いから購入する気にはならんのだよな
Rustプラグインを単体の製品にするとは思えんけどねえ
彼らは例えばScalaのプラグインとかも手がけているけど別に製品化している訳じゃないし
VSCode重たくて殺意生える
いちいちワンテンポ遅いんじゃ
vi使えよ、viの軽さに慣れたらvimはそりゃ重たいでしょ
>>670
Scalaなんて10年以上前に流行った言語のIDEを今更有料化しても売れないだろうからな
Rustは今現在流行ってる(?)言語だし売るんじゃねーのかね Atom (Electron) が Blink から Servo に乗り換えれば軽くなるのだろうか？
vscodeって重いよな？起動も動作も軽快とは言い難い
むしろvscodeが軽快に使えているという人がいるならどのような環境で使用しているのか聞きたいわ
SSDを乗せた標準電圧版Coreiモバイルノートでも結構もっさりだし
もっさりとかいう言葉じゃ意味不明だからせめて数値で言ってくれ
何を妥協して「せめて」なのか分からんが数値あげてやろう
MacBookでIntelliJが6時間くらい保つ所が3時間くらいしか保たない程度に無駄処理多い
プロセス上の待機スレッド数も10〜20くらい違った覚えがある
待機中でもそんだけスレッド回してるから、コーディング中、ビルド中の負荷もでかくなるよね
VSCodeを愛用してるコーダーはemacs愛用してるコーダー並みにマゾだと思う(viユーザ感
>>678
あ、レスするならついでに「せめて」で説明要求を妥協した点を教えてくれい
確認してる範囲であれば答えるよ 全くだ、重たいと事実を指摘されても発狂することなく
重たくても他に良い所があるから使ってるんだと言い切っていたemacs愛用者は良い人たち
>>675
バックエンドRust, フロントエンドSwift, 通信プロトコルJSON, プラグインサンプルPython
ごった煮過ぎて笑うわw rustってやっぱりスペックいいパソコンと高速なネット回線がないと厳しいですね
普通の言語だと処理の一部を関数に切り出すのとか簡単に出来るけどRustだと返り値の方が分からなくてそれが難しいことがあるよね
let a: () = { ... };
でコンパイラがエラーとして正しい型を教えてくれるぞ。
クロージャにすれば良い
なあに、きっと最適化で普通の関数と同じ扱いになるさ（適当）
スクワット中なんじゃないの, 筋力ついたらリリースされるでしょ
なんかnightlyにPythonのジェネレータ入ったとか聞いたんだけど誰得？
もうtokioつかFutureあるし。
いつまでたってもスライスパターンが標準にならないのなんで？
ほかの関数型言語みたいな言語標準？のリストと、そのパターンマッチ、があればいいけど
そういうつもりもないんならスライスパターンをはよ強化＆標準装備してほしいんだが
私は最強のRust以外のプログラミング言語で書く気はありません
Featureを駆使するので楽になるのはそうだが、
逐次処理的に書けるasync/awaitの方がさらに楽なので
それを実現するための要素としてgeneratorは必要
あとIteratorの実装も楽になる
>>692
なんていうか、自分のチームの優位性を示してドヤろうとしたけど決定的な証拠がなかったから自分に有利な調整をしたという感じだな
特定のチームへの非難をしつつそのチームの人間のツイートを自分の主張の補強に使っているのもいろいろアレ
まあ競技プログラミング界のゴタゴタはどうでも良いけどとりあえずRustを巻き込まないで欲しいわ >>692に対してちょこちょこマジレスがいるけど
正規化の文章の注釈[4]でウォーズマン理論とか引っ張り出してるからな マヌケは見つかったようだな…ロクにリンク先も読めないのに批判する口だけの能無しが…
ウォーズマン理論により各言語の普及率(PG人口比)でスコアを倍加すると
数の暴力が発揮されJavaが最強のプログラミング言語であることが証明される
とでも言えば風情があるのかね？
ネタに対する模範解答って『やはりRust最強だな！』とか？
>>705
風情の有無を話してるのであって、寒さ暑さを話してるんじゃないんだけど
>>706
まずはageないことから始めよう、な？ >>702
わび・さび ですよね、わかります
I know. sorry & rust お前ら、associated constantsがstableになったってのにいつまで下らない話を続けているんだ
impl Trait と トレイト境界の特殊化の実装が先だろ……
これのせいで書けないコードあるんだぞ
きっとimpl periodのうちに全部実装してくれるよ（適当）
async を汎用的に実装するなら モナド ( M<T> ) 的な高階型が必要?
そもそもwasmなんて誰が必要としてるんだという問題がある
実際現状wasm使うよりV8の方が速いだろ
asmjsが早いんだからランタイム側の対応が十分進めばwasmも早くなるでしょ
>>719
Rustなんて実用にならない言語未満使うくらいなら、クソとはいえ言語の体なしてるJS使うわクソ rustってまだ俺の中で実験言語だけど
そろそろプロダクト作ってる人とか出てる？
>>727
噂では泥箱あたりが使い倒してるとか
ずっと前から言われてるけど未だにコードの一つも公開されてないからただの提灯持ちで実際は使われてないと見てるがね Rustが1.0過ぎてから今に至るまで、Rust使ってるって主張する企業は
モジカス自身と個人情報おもらしの一件で何かしら話題とお金が欲しい泥箱しか見ないって時点で色々と察するべきなんだよ
お前らいい加減目を覚ませ
>>730
そのうちモジラのフロント企業じゃないのはいくつだい？ dropboxやsamsungもmozillaのフロント企業の可能性が・・・？
実はmozillaってすごい会社なんじゃね
rustっていまいち売りがないよな。
ちょっとしたツールを作るっていうのには向いてない気がする。
Goくらいの適当言語がちょうどいい。
ちょっとしたではなく、きちんとしたソフトウェアを書くための言語だよ
Rustは、型システムがきちんとしてないとイライラしてしまう人向けの言語だよ
システムに近いところを触るバックエンドのデーモン等に向いた言語だよ
パッケージのインストールだけで長時間かかるのだけ何とか改善してくれる神様たちっていないんですかね
issueにそういう要望とか出ないものですかね
前にも出てたけど、CARGO_TARGET_DIRを設定すればさっきそれコンパイルしたじゃん！ってのが無くなる
まあコンパイルそのものは遅い方だからそれは我慢する
Celeronの1コア、メモリ1GBなのでパッケージによっては5時間経ってもコンパイルが終了しないんですよね
例えばclippyとか。
パッケージのアップデート毎に結局更新されたものをコンパイルし直すからCARGO_TARGET_DIRの設定してもあまり変わらないような気もします
Core i7やryzen、メモリ8GBとかだともっと早く終わりますかね？
コンパイラ、コンパイラドライバ、パッケージマネージャをそれぞれ独立して利用しやすくして欲しい
ポストC/C++を目指しているはずなのに言語仕様と関係のない制約が増えるのは勘弁
>>745
java, phpが独立した3rd tools乱立でひどいことになったから
次世代は低レベルと高レベルの2レイヤーを公式に提供しようぜって現代の風潮でそれに沿ってると思うが
あいつら個々に独立したビルドシステム, テスター, パッケージマネージャー, ランチャーが乱立して辛い
rustやgoは公式で色んなものが利用しやすく整備されてて涙が出るよ, マジで
rustの公式ツールに不満があるなら3rd toolsを自分で作れば良いよ
誰も作るなとは言ってなくて、作ること自体は止められないはず、賛同する人がどれほどいるのか懐疑的だけど 低レベル:rustc, 高レベル:cargo って意味な
Rust＝Cargoな感じになっているように思うのは俺だけなのか？とりあえずCargoを使え的な記事ばかりでrustcを活用する記事はほとんど見ない
ちょっと高度な事をしようとすると絶望的に情報がない。さらにrustcの不安定性(機能しないオプションがある)が追い打ちをかけるｗ
まあ今のRustとmakeを組み合わせようとはちょっと思えないな
ビルドにcmakeを要求するのに、エラーメッセージが分かりづらくて
はっきりとcmakeの必要性が分からないcrateが結構ある
依存ライブラリ一つ一つまでreadme読まないし
build.shからmake叩いて、更にmakeからant叩いてたjava全盛期に比べれば多少はね
cmakeの代わりにbuild.rs(及びgcc-rs)使えば良いんだろうけど、build.rs書くの面倒でcmakeに走ってる予感
gcc-rsの機能拡張としてファイルパターンマッチ的なものが提供されたらcargoからcmakeも駆逐されるかもねー
あんまりbuild.rs使わないから既にデファクトスタンダードなcrateが存在してたらすまぬ
そこまで分かっててなんでRust使い続けようと思うんだお前ら……
だってRust会社で使えないしー が1位でRustむずいよーこわいよー が2位か
CrateがCargo前提になっていて他のビルドマネージャやrustcからは実質的に使えないよな？
cargoって裏でやってることはrustcのラッパじゃなくて独自の方法でコンパイルしてるのか？
ひでえ仕様だな
>独自の方法でコンパイルしてる
そんなことはないはずだが、どこからそんな情報が出てきたんだ？
crateが実質cargo専用になってるってbuild.rsとかその辺のことか？
crates(.ioからのダウンロード、及び、crateの依存解決/分割ビルド)が実質cargo(コマンド)専用と言いたんじゃないのかな
curlでダウンロードして、rustcで.rlib作る分割コンパイルすれば出来なくはない
cargoコマンドのコードは開示されてるから自分で頑張れ, https://crates.io/crates/crates-io
rustcを使いこなせずcargo未満/rustc以上ツールの車輪の再発明を熱望する無能と
rustのコンパイルできるコードを書けず挫折したアンチが合わさり話が明後日に向かっておるわ cargo install に download-only オプションがつけばいい流れ？
>type hello.rs
fn main() {
println!("Hello World!");
}
>rustc -V
rustc 1.19.0 (0ade33941 2017-07-17)
>rustc hello.rs
>rustc -v hello.rs
>
-vが効いていないように見えるけど仕様なの？
コンパイラやリンカに与えられているオプションとかを見たいんだけどどうしたらいい？
スコープでインスタンスの寿命を静的に管理しようってのは面白いと思うのだが、
再帰的な構造とか扱う場合の簡易さをも少し考えるべきだったね。
まああんまこだわらなければ結構使いやすい気はするけど。
まあ raw pointer 使えば何とでもなるし（震え声）。
木構造は書けるでしょ
難しいのは巡回するグラフ構造
木にせよ一般のグラフにせよライフタイム管理が面倒くさい
ぐええ、隣接リストとアリーナの違いがよく分からない
768はこれがまともじゃないっていいたかったんでしょ。
CやC++ならポインタ持っておくだけで簡単に実現できるのに……
Rc+RefCellな型を用意するだけでもマシになるか
ていうか練習ならともかく実際に使うプログラムでポインタをつないでグラフを表現することなんてそんなに頻繁にあるか？
取りうる表現の中で効率性が最悪な部類じゃん
Vecに対するLinkedListみたいなもんだろこれ
オブジェクト指向っぽいAPIを触るときはだいたいその形にならない？
じゃああんたは現実世界でツリー構造のものをどうやって表すの？
>>779
VecじゃなくあえてLinkedList使う場面普通にあるんだが…… linux の赤黒木の実装はポインタベースではあったな。
しかし個人的には配列実装のが結局速いって気はする。
Effective Hogeでそういうことは言及されてるけど
Rustはどうだかなとドキュメント見たらSecond Editionで"Effective Rust"の節自体が削られとる:-(
Stack vs Heapはどこかに記述されてた覚えがあるから、ツリー/リスト操作もどこかに潜り込んでるのかなぁ
配列ベースの実装はポインタの代わりにindex使うだけだからできることはあんまり変わらんわな
配列の方がデータの局所性高そうで速そうではある
データ構造によって速い操作が違うという基本的な概念がない奴おるな
vectorのmutabilityの問題があるの理解できてる？
>>787
まあそういう無能がありがたがる言語なんだろうなRust mutabilityはRefCell使えば良いのでは
Refcell使わずにVecの中身を直接触る必要ある？
>>791
いや、それでいいかも
rcさえなくなればborrowをユーザに書かせなくてすむからそれでいいや 低レイヤーできます！ってアピールしたい言語なんだろうけれど、
あんま向いてない言語な気はする。
低レイヤを書くにはチェッカーが強すぎて邪魔で、高レイヤを書くには全くカジュアルさがない
どっちにもなれない哀れな言語よ
並列で大規模で低レイヤーな領域に向いた言語だからどれか一つでも欠けてる領域で使いづらいと思うのは仕方ない
低レイヤーはやっぱC言語だな。
ポインタの習得が難しい事以外に欠点ないじゃんこの言語。
Rustはもっとポインタ扱いやすくして出直してきな。
rustの並列処理って言うほど特化(最適化)されてる気はしないけどな・・・
スレッド跨いだオブジェクトの所有権譲渡も保障されてはいるけど、従来言語/ライブラリに比べてめっちゃ便利という感じはしない
futures-awaitとかyieldを使うと変わるのかねぇ、無くても困りはしないしと使ってないけどfutures-awaitは使ってみるかな
C だっていろいろ批判はあるだろ。
型がゆるいとか、名前空間がグローバルしかないとか。
まあそれを差し引いてもやっぱ有効な言語と思うけど。
>>798
Rustのコンパイル通す実力あるならCのその辺りの問題なんてないものと同じだから
Rustなんて使わずCでいいじゃんってなるんだよな とか思ってたら、yieldの方が公式nightlyにマージされたのか
futures-awaitもnightly要求するし素直にyieldの方を使ってみよ, stableにはいつ来るのかなぁ
ID:6DzbMbn9っていつものモジラ/Rustネガキャン君だろ
>>803
さすがにあのレベルの基地と一緒にされるのは心外 いつものコンパイル通らなくて発狂してる基地外かと思ったわ
コンパイラーよりも自分が信用できるならC使えばよいと思う
Rustのコンパイルが通るならCを使えば良い君まだいたのか
自分の言葉通りRustに拘わらずにCを使っていれば良いのに
macro_rules! make_macro {
($id:ident) => (
macro_rules! concat_idents!{test_, $id} {
}
);
}
make_macro!{foo}
こういうの無理なのか。
RustやSwiftとかの次世代言語ってOracle製品やSAPみたいな所あるよな。
無駄に抽象化して変な専門用語作って、プリミティブなエンジニアを寄せ付けない感じとか。
コマンドラインで一発で出来るようなことを、独自用語だらけのGUIでポチポチ操作させてんの。
こういう文化は本当に良くない。優秀なエンジニアはみんな逃げてしまう。
>>810
コンパイル時に全部解決しなきゃいかん
てな話のがよっぽど根性論だと思うが。 人間が気をつけてコードを書けばバグが出ないはずというのは根性論では
人に依存するC/C++は日本的
システムが面倒を見てくれるRustはアメリカ的
バグが出ないことよりも手法に熱中しちゃう方が日本的だなとか思っちゃうけど。
〜的ってつければなんだって形容詞になるの？
人に依存するC/C++はC/C++的
システムが面倒を見てくれるRustはRust的
C/C++でもバグが出ないほど規模が小さい or 言語への習熟度が高いならC/C++使えばよいし
そうじゃないならRust使えば良いとしか言ってないのだが
単純に「巡回グラフを始めとした自己再帰型のデータ構造を書き下せない（コンパイラが通してくれない）」って時点で、書けないプログラムの存在を認めてしまってるんだよなRustは
その上C言語にはValgrindやらcppcheckやら、金かかっていいならCoverityやら、いくらでもその手のツールはあるわけで、
Rustならではの点ってどこにもない割に欠点だけ目立つ訳よ
肝心の抽象化も機能足りてないしな。Nightly使えばなんぼかマシだが
△全部Rustだけ
◯全部safe Rustだけ
Escape hatchの類は使いたくないというsafe Rust信仰の裏返しというツンデレなのでは
できるできないレベルの話をしているのか、やりやすいやりにくいレベルの話をしているのかどっち
できない => できるよ => やりにくい => そうねー => 応答終了, 最初に戻る
こんなのをずっと繰り返してるイメージだ
モジラ/Rustネガキャン君とRustのコンパイルが通るならCを使えば良い君の二人なのかな
二人とも長いこといるし、コンパイル通せないRustが相当憎いんだろうなぁと思ってる
Cだって肝になるところをアセンブリで書くのはまれによくあることだし、
Rustで書きにくいところをCで書いたっていいよな
Rustのコンパイルが通るならCを使えば良い君は、暗黙のうちにCで完全なメモリ管理を行うことの困難さを訴えているんだよきっと
てか細かいとこ C で書いてあとは軽い言語から呼ぶとか普通してるじゃん。
一つの言語で無理やりやろうとするからどっちつかずになるんじゃないのかね。
>>828
RustがC(++)の後継目指してるとか言わなきゃこんなに言わんよ C(++)の座が奪われると危機感を感じて
「Rustのコンパイルが通るならCを使えば良い」と必死なのかw
置き換わるにはまだまだ先が長いから安心して自分の巣にお帰りに
Rustのコンパイルが通るならCを使えば良い（自分はできるとは言っていない）
実際に使ってる人たちは本当にいつかRustがC(++)に置き換わると思ってるの？
RustがC/C++の後継目指してるなんて公言してるのか
一応Goもc++の置き換えを想定した言語らしい。もっともgoogle社内の話だが
>>830
×まだまだ先が長い ○先にモジカスが世界から消滅する
先が長いとか言ってる時点でモジカスのステマに荷担してると理解しろ
Rustがプログラミング言語を名乗ってるのはモジラが自由をお題目にしてるのと同じレベルの害悪だ 複数のResultのNGをXORでまとめて(途中match分岐入れず)処理するのてどうすればいい？
超極稀に失敗する変な返り値を格納しても副作用の無い処理の連なりをゴソっと捨てる方法
>>833
少なくとも firefox の c/c++ 部分の書き換えを想定してるだろう。
まあ c/c++ と一口に言っても結構レイヤーは広いように思う。
てきとうなサーバープロセスなら確かに go は書きやすいよ。
rust にそういうエリアがあると思えんというところが問題の焦点じゃないかね。 >>836
求めてるものかどうかわからんが、Iterator<Item=Result<t, E>>はcollectでResult<Vec<T> , E>などにできる >>839
そういや、こうやって変数のシャドウイングを積極的に使っていくのってどうなんだろうな？
俺はよくやってるけど、スタイルにうるさい人から怒られるかもとか思ったり collectも#inlineついてるなら手でfor書くのと同じになりそうだけど遅くなるのか
ExactSizeIteratorとただのIteratorで違うとかならわかるんだが
OCamlだと普通なんで読みにくさを感じたことは無いなあ
むしろその変数はそこで終わりです、もう頭に入れとかなくても良いよってことだから脳にやさしいとまで感じる
>>842
collectの関数コールは最適化されて消えるけど、collect内でVectorを作る分があるからな
メモリ確保して、要素をコピーしてって誤差程度だけどコストが乗っかる
filterまでだとFilterは作るけど要素のコピーはしてない感じだったから
他言語, 他ライブラリのfilterメソッドの戻りで配列/リストを作り直すIF/実装に比べて比較的早そうだと思った なるほど、Vec作るコストという意味なら確かにcollectはコスト掛かるね
まとめて処理というのがIteratorの要素からなる配列などのデータ構造を作って何かすると理解していたけど、
そうでないならば
f.map(¦x¦ {do_something(); }).collect::<Result<Vec<()>, _>>()
とすれば作られるのはVec<()>で、要素サイズ0だからヒープからはメモリ割り当てられないはず
これやるぐらいならfor使った方が
一方C言語ならそんな面倒なこと考えずにallocしてforでいい
学習コスト高くて性能も低い言語Rust
>>847
mallocとcallocのことをまとめてallocって言うんだがまさかRust民そんなことも知らない？ 俺たち、ついさっきまでzero-allocationな実装方針について話してなかったっけ……？
定義による
スタックから確保するものと
ヒープから確保するものを
どちらもallocと呼ぶなら含んでる
>>849
ゼロアロケーションつっても最初の一回はallocするだろ？
その後forでナメながら変換すれば単純で早くてコンパイルも通ってモジカス涙目みんな幸せって言ってんの
無駄に難しく考えるモジカスシンパらしい話だな
>>850
非標準関数はNG 基地外って同じ言葉を連呼するからNGし易くて助かる。
要素サイズ0のVecはヒープからメモリ獲得しないと明言したはずなのですが
>>846の書くヒープアロケートするCコードはスタックアロケーションのみのRustコードより高性能なんだよきっと >>853
造語症っていうんだっけか？
それはそうとRustでCのmallocやcallocと同じ操作ってBoxであってVecではないよなあ。 低級言語で書けばそれだけで性能が良くなるって勘違いはよくあるよな
>>856
どっちもヒープを使ってるから同じでええやろ 話が明後日の方向に行ってるけど
>>844の主点はVecを作るコストではなくVecに要素コピーするコストの方だぞ
filterで除外した要素をcollect内でVecにせっせとコピーするからちょっち時間かかる
ちなみにC(++)でベタに実装するとこんな感じでリスト作成、要素コピーするからドングリの背比べ
std::list<char*> filter_collect(std::list<char*> v) {
std::list<char*> new_v;
for (auto i = v.begin(); i != v.end(); i++) {
if (*i != NULL) {
new_v.push_back(*i);
}
}
return new_v;
}
std::list<char*> v{"Hello", NULL, "World"};
auto new_v = filter_collect(v);
モジラ/Rustネガキャン君とRustのコンパイルが通るならCを使えば良い君が
よりよいCコードを挙げてくれるのをちょっと待ってみようか, 流石にこれは汚すぎる （そもそもの>>836が何をしたいのかいまいち分かっていないなんて言えない） (大丈夫、俺も分かってない...多分>>841さんの実装例が期待コードだったんだろうと匙投げた) 仕様分からないのに実装しようとするRustの文化すげー
そういえばRustってそもそもまだ言語仕様がなかったっけな（RFCが通ってない）
そんな言語を良しとするモジカスとそのお友達
RubyやLua等も商用でも使われているけど公式な言語仕様って存在しなかった気がする
RFCが通るとはどういう意味だろう
まさかIETFの話ではないだろうな
どうせならいっそ新しいepochでbare Traitのシンタックスでimpl Traitのセマンティクスを表すように変えて欲しくもあるけれど、motivationでも言われている通り互換性の観点からしてまあ無理だわな
理念には同意できるけど、うーむ……ダサい
じゃあ討論してるIssueに行って、ダセェからこうしようぜって具体例を提案してこい
良さげだったら(y)押してやんよ
これがダサいとかいうならimplとかpubなんてクソの山だろ
>>868
impl Traitのセマンティックスに置き換えたところで例えばVec<Display>にi32とStringを両方突っ込もうとしてエラーになるようなへまをする連中は消えないだろ
>>869
もうFCP過ぎてマージされてるんだよなあ rustの三文字文化好き
mut, str, len, vec, rev
Contextual keywordって書いてある
let str = "Hello";
let str: &str = str;
これで普通にコンパイル通るしな。
変数名に出来ないのは>>872の中じゃ mut だけだろう。 str, len, rev
あたりは変数名として結構使うかな。
str , vec あたりは s, v くらい短くすることもある。
比較演算子 ==, <, > 等って、同じ型同士でしか定義できないのか
それはEqとOrdの話でしょ
PartialEqとPartialOrdは別の型同士でも定義できる
あ、ホントだ。出来たわありがとう。
use std::cmp::PartialEq;
struct Foo(i32);
impl PartialEq<i32> for Foo {
fn eq(&self, other: &i32) -> bool {
self.0 == *other
}
}
時報が壊れたと思ってたら、常時一ヶ月遅れの情報サイトをソースに時刻通知がきたよ
本人じゃなく模倣者だろうけど次回からは一次ソースのサイトをトリガーにしような！
1. 時報が壊れたことに怒っている
2. 一ヶ月遅れのinfoqをソースにしたことを怒っている
3. 模倣者であることに怒っている
4. その他
どれだと思う？
CもObjCもここ数年は仕様変更がないから、コンパイルはそのまま通る。
変なコード書いてなければ動作確認も問題なくパスする。
メンテナンスフリーって言われれば確かにそうかもな。
あとはフレームワークで非推奨にになったメソッド書き換える程度だけど、
これはSwiftと共通の作業だし、そもそもやらなくても動く。
とにかくSwift移行していない俺は毎年高みの見物してる。
これが小学生のおっぱいかよ・・・
12歳の乳とは思えんな・・・
rustの前にc++とhaskellぐらいはやっておくべき？
C++なんてやらんでいい。haskellよりOCaml寄りじゃね？
C++よりメモリ周りが「javaからgcとロック付きオブジェクトとモニタと
並列ライブラリがなくなった」代わりに低レベルなマルチスレッドコード書けば
型システムが守ってくれるモノが近い。
所有権の概念はC++のmove semantics回りが近いと思うけどな
まあゲーム作るとかじゃなければわざわざC++やらなくてもいいと思うけど
Rust言語による第一プロダクトのFirefox Quantumですが
ベータ版リリースの時点でアドオンがお亡くなりになったとか、不安定でどうしようもないとか、メモリ食い潰して落ちるとか
様々なお声が聞こえてきますね
これがRustという安全な言語で作ったプロダクトなんですってね
おめでとうございますモジラ信者と工作員の皆様
ベータ版の意味も知らないガイジやんけ
ガガイのガイｗ
>>894
API鞍替えのせいだから全く関係ない。
メモリも関係ないし、むしろ最近はバージョン上がるたびに消費メモリ減ってる。
というかパフォーマンス良くなったのは設計が変わったからで言語は関係ない。
言語関係する部分はC++よりマシだから書きやすくなったこと。 >>897
設計の変更って具体的に何を変えたの？マルチスレッドに強いとか？gpuぜんていとか？ >>898
HTMLの描画周りがマルチスレッド前提になっただけよ。
シングル前提でやるとHTML/CSSパース、DOM構築で同期取りまくりが減っただけ。
うちのmem 4g, 2core環境だとハードが足引っ張ってたから多分mem 8g, 4coreくらい要ると思う。
ここ数年のロースペックマシン以上が恩恵受けるんじゃ？
gpu前提はwebrenderだからまだ入ってないんじゃない。 あ、悪い。webrenderもう入ってるわ。
webrenderとstyloが入ってるからもうマルチスレッドにgpu前提。
Firefox爆速化件だけど、あのタイミングでRust化してればRustにも一気に注目集まったのにな。
もったいないな。
w3mの代替になるコンソールブラウザがほしいところ
lynks、links、EWW(Emacs)ではいかんかった？
それよりAmayaの後継をwhatwgに作って欲しい
>>909
6パターンだった頃は全部実行出来てたけど速度はバラバラでたしか#5が最速でC言語より速かった
きっと最適化を人間が制御するのは難しくて頑張らないとJavaやC#にも勝てない
現在7パターンあるけど4つがmake errorになるくらい言語仕様が不安定
実に参考になる >>909
mem順にしてもgz順にしてもcpu順にしてもD言語出てこないの悲しいな >>910
人間が頑張って最適化した結果、C gccが上回ったんじゃないのかね
D言語はプログラミング人口少ないから・・・
2000年代の流行った頃ならもうちょっとスコアが出てたんじゃないかな RustもJavaも血反吐吐くほど最適化してるんじゃないの？
ポインタ扱いにくい言語でそれやると逆にコードが汚くなるから、
C言語よりも酷いコードになってるかもしれんよ。
unsafe使ったらRustは更に早くなるのか・・・胸熱
取り敢えず、各コードを読んでから批評してはどうか
本家Rust Teamが改修して今のスコアだけど
彼らが直したのはI/Oにバッファ使おうぜってだけでそこまで変態的じゃないのよね
matchやmap, iterでクロージャー多用してるけど最適化コンパイルしたらif, forで書くのと同じ処理になるし
Option.mapは関数コールがあるから重たいかなと以前調べたら
LLVM中間コードの時点でインラインのif分岐(goto文)に展開されてベタコードと同じになるのかよと考えるのやめた
>>909
C gcc 5.38
Rust #7 5.56
C++ g++ #3 7.18
Java 8.38
↑この並びでみると、Rustの速さよりもむしろJavaの意外な速さに驚く Javaは実行時最適化がはまれば速い感じ
でも、カリカリにチューニングされたJavaコードは、クラスをあまり使わずArrayだらけだっりしてつらい
C言語の __func__ みたいなの無いのかよ〜
Javaやら.NET等のJIT系言語は速い速い言われるけど実際のアプリケーションでその速さを体感できたことは一度もないや・・・
>>909
rust#7はrayon使ってるから中身はcocoとfutureか。
ライブラリが頑張ってzero cost抽象化が効いてる感じかね。
javaはもうちょっと早くなるんだけどなぁ。
これ以上やるとjitとライブラリに丸投げして素直なコード書くことに
専念できなくなるからやりたくない感じ。
将来的にはconst arrayと、勝手にSIMD使ってもうちょっとマシになるかな。
>>919
連続してることが保証されないからカリカリにチューニングする時は配列には頼らないよ。
nio buffer使うことはあるけど。unsafe使わずに配列確保すると0クリアされて無駄に遅いし。
仮想関数テーブルなくしたほうが速いからメソッド検索>invokestaticのコストの時staticに変えるとか、
動的ディスパッチ自分で実装するときにconstant specific class bodyとtable switch組み合わせるとか。
>>921
ないけどrpすればすぐに入りそう。 >>923
>連続してることが保証されないから
それはもはやデータ構造として「配列」と呼ばれるものではないのでは…… >>923
javaの配列って連続領域の保証されてないの？ スレチだけど、JVMの実装仕様なんてベンダー依存でしょ, OracleとGoogleでも当然違うわ
だから言語として仕様化されてないの？ってことだろ。
c++だって実装バラバラだけど連続領域な仕様だろ。
Cはポインタ I/F仕様に引きづられて配列仕様も必然として明確にせざる得ないからでしょ
JVMはbyte codeの解釈さえあってれば良くて、データ操作の実装仕様は知るかよって話だよ
VM上では連続領域に見せかけても、実態は数チャンクに分けた配列の持ち方だってあろうよ
いやだから、データ構造としての「配列」のデータ操作の時間空間コストと
実装がズレてたらそれはもう「配列」じゃないから
一般的に配列と呼ばれるオブジェクトがメモリアドレス上でも断片化しないことを保証される処理系ってほとんど無いのでは？
ミュータブルオブジェクトへ要素を継ぎ足していったらコードからは連続的に見えてもメモリ配置は断片化するだろう
「要素を継ぎ足していったら」がそもそもオカシイ
要素継ぎ足せるのはそもそも配列じゃなくてロープかなんかだから
配列の要件ってインデックスで要素にアクセスすることくらいじゃないの？
要素のポインタをとって操作できる言語以外は実際の記憶領域が連続かそうでないか
判断する術はないと思うが。
ポインタ操作だって処理系依存でどんな変態実装も理論上はあり得ると思うけど
C/C++の仕様を調べる気力がない
>>933
> 配列の要件ってインデックスで要素にアクセスすることくらいじゃないの？
じゃリンクリストでもいいってわけ？
インデックス操作は内部でポインタたどってさ。 配列だとインデックスのアクセスにO(1)を期待してるが
それが保証できるのかという話じゃないの
>>936
お前は話の最初から読みなおせw
オーダーのことなんか誰も気にしてないよ チューニングで気にするのはメモリ配置よりCPUキャッシュに乗るかどうかでは
そのとき配列のサイズが気にされるというだけで
データ構造としての「配列」と言語機能としての配列は別の話だから。
O(1)でもO(n)でも a[i]と書けるなら配列だって感覚？
そう考えるのは自由だがまともな話はできなさそうだな。
そんなの処理系によるわ
動作は変わらないからどうでもいい
JavaScriptのArrayを配列と呼ぶのは間違いだ！
と吠えている人がいますね
>>943
>そんなの処理系によるわ
>動作は変わらないからどうでもいい
オーダーの違いはまさに動作の違い
> JavaScriptのArrayを配列と呼ぶのは間違いだ！
> と吠えている人がいますね
データ構造としての配列じゃないのはそうだろ
配列じゃなくてハッシュマップですよねー
というのがマトモなCS出身者の反応 引き続きオーダー厨がフィーバーしてんなw
>>946
>>926, >>928曰く、C言語には仕様として配列は連続領域であることが決まってるらしいよ
んで、Javaでは特に連続領域で実装することを仕様と定めてないよねーって話をしてんだろ >データ構造としての配列じゃないのはそうだろ
>配列じゃなくてハッシュマップですよねー
結局、それまで展開していたオーダー云々の論理はどっかにやって
「配列じゃないものは配列じゃない」ってかｗ
ポインタの値が連続でも実メモリ空間のアドレスは連続とは限らないし
そのあたりのアドレスの連続性の抽象化をOSでやるか言語の処理系でやるかの違いと思えば
配列の要素の仮想メモリ空間でのアドレスが必ずしも連続ではない言語処理系があっても良いと思う
>>949
配列とは、連続領域で確保されO(1)でアクセス可能なものと(俺の中で)定義する
それ以外の仕様、実装による配列は配列とは認めない
という論理で一応オーダー云々も彼の中では含まれてるんじゃないかな
ポインタのポインタで配列を設計したら、それはもうハッシュであり配列ではない的なことも言ってるし
多数の言語仕様, 言語処理系で配列ではないものが配列として扱われてて大変そうだなって思うね:D JSのArrayは配列じゃなくてリスト
TypedArrayが配列
メモリが連続化を気にするとかどれだけ低レベルな言語使ってるんだ
インターフェイスが同じなら実装とかどうでもいい
老害かよ
データ構造の読み書きのオーダーも仕様の内だけど、メモリ上のレイアウトまで仕様という考えはマイナーじゃない？
アドレスを当然のように明示的に扱う言語だと当然の範疇かもしれんし情報として提供して欲しいけど、そうでない言語ならn番目の要素へのアクセスがO(1)であれば配列でいい
で、Rustはアドレス直触りは可能だけど普通はやらない。Cみたいに構造体のメモリ上の表現がはっきり決まってるわけでもないし
>>951
> 配列とは、連続領域で確保されO(1)でアクセス可能なものと(俺の中で)定義する
そう思うのは勝手だけどそれに基づいて他人を批判するってどんだけ独善的なんだ array data structure でググるさま
>>952
(配列の定義を)お前がそう思うんならそうなんだろう お前ん中ではな
ちなみに、Rustスレ住民はRust言語を使ってるゾ
>>953
Rustのstructメンバは連続を保証してるんでなかったかいな
repr((C)で宣言した時に限ってるんだっけ、unsafe多用してる変態がいたら教えてくれ >>933
それって、(一次元)コンテナでは。
で、コンテナの実装方法として配列やらリンクドリストやらが存在する。 >>952
> インターフェイスが同じなら実装とかどうでもいい
そういう目的にはrust使う必要なくね？ >>953
Rustがそういう態度だと言うのなら、C/C++の代わりには使えないなぁ nightlyが仕様変更したりバグったりするのを逐一驚いてたら大変じゃない？
>>958
もともと配列やその他のデータ構造からインターフェースのみ抽出したものがコンテナなんで、
それを言語仕様の側からは単に配列と称していることはあるだろう。
仮にそれを認めないとしても、元の質問の「JVMの配列は連続しているか」が「JVMのコンテナ(?)は
連続しているか」になるだけ。 いるなぁC++のプロジェクトでarrayで十分なところに無駄にmap使いまくるやつ
おっさんプログラマとしては看過できないんだが(少なくとも仕事では)
これが時代なんだろうか
メモリコスト、CPUコストについて定量的に説明できるかな
自分もどちらかと言えば効率厨のつもりだけど
実行コストと可読性が大差ないなら好きな方を使えばいいと思う
さすがに array と map ではアルゴリズム自体違うわけだしそれはなしだろ。
Vec<f32> を Vec<f64>に変換したいのですがどうしたらいいでしょうか？
やりたいのは
&[f64]を引数として受け取る関数にVec<f32>の内容を渡したいのですが。
>>972
ありがとうございます
今回は外部ライブラリだからしょうがないかな
普通はなんのtraitで受けとるんでしょうか？ rustって難しいって聞くけどどうなの？
数百行程度のcliツールとか作るのにも適してる？
借用やライフタイムを理解できない内は難しいかもね。
%%%%4NEL%%%%
000-SAV-&1.0888214%ML<\47MBL%0.2\MSSSS4.213>
1.8882/%B/%SB/<\2/7BL\%\%B!B%47L%Si72B>%10.2%\
002%\B%===>>>52.B<\rbc/2.8>>\7B<<\7LB>>\72S\<%\42%><\br>001BYON$\%7L2%3.33GHz>>>2.3GHz<\br>
41.B%LB%"<<%11.6$%><<\86.1B>>2LB>"B???S3>>71$-?>6%<\br>
082@<\7L@@<\br>
\LOOP>0<1Entra >>975
RealがSupersetOf<f64>を継承してるから受け取る関数がf64を扱うならTrait Realを受ける形でも良さそう
Alga使ったことなくてどっちを使う方がスマートなのか分からんから、自分が取り回しやすいと思う形でどうぞ Rustの話をしないRust板の住人
言語として形になってないから言語のことを話せないんだろうなぁ
直近もまともな更新ないし、世間の話題も下火だし
工作員さんもっと頑張らないといけませんよ（ハナホジ）
tanakhのrustベタ褒めツイートでも列挙しようか
>>976
性能だすために生ポ触るとかしなければボローイングなんかも
そんな難しく考えずにコード書けるとは思う。
一部の馬鹿が言語機能をドヤしたいってのが一番流行るのを妨げてる。 じゃんじゃんクローンすればいいんだよ
性能に困ったときだけ再考すればいい
>>980
何代目の時報か知らんけど次スレよろ
あと、2年近くかかって取り込まれたrvalue static promotionをスルーするとかどうかしてんぜ ムーブセマンティクスをきちんと意識すれば借用はそこまで難しかないよね
まあそこでCの経験が却って邪魔になるところがあるわけだけど
QtをやったあとでもRustの有り難みって実感出来る？
borrowing というか mutable aliasing だけはやっぱり辛いなあ。
多くの場合 struct メンバの false sharing なんだよね…。
>>986
moveや借用は簡単なんだけど、その結果引き起こされる制限を回避していくのが面倒。 >>991
その「面倒」って感じるのがまさしくCの経験の負の遺産なわけよ lud20220919234809ca
このスレへの固定リンク： http://5chb.net/r/tech/1495343069/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「プログラミング言語 Rust 3 [無断転載禁止]©2ch.net 」を見た人も見ています：
・天才以外お断りプログラミング言語
・C#とかいう欠陥プログラミング言語
・【IT】プログラミング言語人気ランキング2020、2位に「大躍進」したあの言語
・理系大学一年が学ぶべきプログラミング言語
・【Lisp】プログラミング言語 Clojure #4【JVM】 [無断転載禁止]
・【IT】マルウェア解析のためのプログラミング言語トップ3
・【IT】人気プログラミング言語トップ10【2019版】
・プログラミング言語「COBOL」がTwitterトレンド入り
・プログラミング言語、Python一人勝ち。もうすぐ世界一人気のある言語に
・もうプログラミング言語はTypeScriptだけやっとけばいいだろ 何でもできるし
・なぜ日本製プログラミング言語「ruby」は廃れたのか？いまやubuntuにパッケージすら無い
・【朗報】今後プログラミング言語はJavaScriptの1強時代へ、これ以外の言語の学習は不要
・プログラミング言語を勉強したいから参考書買ったら1ページ目で挫折した。意味分からん。教えて嫌儲民
・【天才】スーパー中学生誕生、プログラミング言語わずか数週間で開発、U-22プログラミング・コンテスト2019
・【ＩＴ】プログラミング言語「COBOL」がTwitterトレンド入り AWS Lambdaのサポート言語に追加、技術者がざわつく
・日本のフリーランスプログラミング言語案件ランキング 「Python」がシェア拡大、ブロックチェーンや機械学習などの需要増で
・【Microsoft】Excel関数ベースのプログラミング言語「Microsoft Power Fx」登場 オープンソースで公開予定 [少考さん★]
・プログラミング言語って面白い？
・最も美しいプログラミング言語は？ Part6
・プログラミング言語バトルロワイヤル [無断転載禁止]
・プログラミング言語別の年収ランキング発表 [無断転載禁止]
・Microsoftってやたらと形式検証系のプログラミング言語作ってるけどさ
・【IT】Microsoft、プログラミング言語「P」を紹介 [無断転載禁止]
・PHPもJavaScriptも難しくて挫折したんだけどもっと簡単なプログラミング言語ってないのかよ
・今から始める？ 就職に有利なお勧めのプログラミング言語16選 [無断転載禁止]
・【IT】Google、プログラミング言語「Go 2」開発計画発表 [無断転載禁止]
・【IT】6月プログラミング言語人気ランキング、Kotlinが急増の傾向 [無断転載禁止]
・新型コロナウイルスの影響で「半世紀以上前のプログラミング言語の使い手」が急募される事態に
・プログラミング未経験だけど覚えたい言語がある
・一ヶ月でプログラミングを理解するのと、何か一つ言語を覚えたいのだが
・敵「プログラミングはやりたいことを見つけてからやれ」俺「よし見つけたぞ！C言語始めてみよう！」
・政府「小中学校でプログラミング必修にするよ！」どの言語をやるんだろう？ →安定の「ホームページ作成」
・一番プログラミングしてるって感じる言語といえば？
・C言語でTCP/IP通信勉強(プログラミング)したいんだが
・【プログラミング】止まらないC言語の下落 - 12月言語ランキング [無断転載禁止]
・職業訓練校プログラミング終了後 3
・ヒッキーの競技プログラミングするスレ 3完
・Androidプログラミング質問スレ revision54
・競技プログラミングにハマるプログラマのスレ 13
・小学校プログラミング教育、米MIT開発の学習ソフト「Scratch」使用へ
・【ＩＴ】プログラミングスクール卒業生は現場で使えない ★2 [Stargazer★]
・プログラミング始めたいんだが
・今日のプログラミングスレ
・プログラミングって儲かるの？
・プログラミングやってみたいんやが
・競技プログラミングにハマるプログラマのスレ 33
・プログラミングに自信ニキ来て
・競技プログラミングは役に立たない
・安価でプログラミングの教科書を作るスレ
・プログラミングはRyzenでやってもエエ？
・プログラミング分かる奴ちょっと来て
・プログラミングのお題スレ Part14
・趣味でプログラミングやってみたいんだけど
・プログラミングできる人ってすげえな
・副業でプログラミングやりたいんだが・・・
・プログラミング未経験だけどゲーム作るわ
・ペアプログラミング相手募集掲示板作ってみた
・プログラミングはできないけど上流・設計は得意
・60％の人間はプログラミングの素質がない←これ
・文系と理系どっちがプログラミングに向いてるんや？
・プログラミング始める=Windowsを消してUbuntuを入れる
・PCでプログラミングとかしないで電子回路作りたいんだが
・競技プログラミングにハマるプログラマのスレ 9
・【教育】「最強」のプログラミング教育ソフトとは？
・競技プログラミングにハマるプログラマのスレ 19
14:22:55 up 8 days, 23:31, 1 user, load average: 7.27, 7.43, 7.34
in 0.105220079422 sec
@0.105220079422@0b7 on 112904
|
