Rust Part5
■ このスレッドは過去ログ倉庫に格納されています
>>427
公式リファレンスって何のことを指してるんだ?
APIリファレンスならきちんと最新版に追従してるし、
チュートリアル(The Book)も2nd Editionがきちんと出てる
バージョンアップの追従ならリリースノート見るかRustの公式ブログ見れば大体分かると思う
Rustは6週間に1回のハイペースでマイナーバージョンアップ繰り返してるから
The Bookのほうは最新版に追いつくこと自体がほぼ不可能だと思うけど
(つい最近もimpl traitがstable化されたばっかりだし…) そのimpl traitが気になってまたRustやろうと思ったんだけどね
全機能の索引みたいなのがないと学習効率が落ちる rustって生産性高い?
安全性が高まって結果的に高くなるということではなくね
やっぱでかいプログラムじゃなきゃ使う効果ない? Javaでnull参照が10億ドル単位の損害と言われてるので
RustはJavaより10億ドルほど生産性が高い まあ、ネタにマジレスになるが、
その論法だと俺の未完成言語は誰もバグを生み出してないので
Rustより生産性が高いなw >>478
分母分子共にゼロなので計算不能ってやつね。 チーム開発に良さそうな気がするけどメンバーのレベルにかなり依存しそう 自分がGCなしの言語使ってた時の経験だと、ヌルポより、freeした後にアクセスするバグの方が多かったから、オーナーを一つにするrustはいいと思う。
まあ、objective-cのARCでいいじゃんとも思うけど。 そこでoptionalですよ
こいよ継承クラス、ポリモーフィズムなんて捨ててかかって来い!
実際、null非許容のポインタが欲しい C#の発想元はJavaよってC#もぬるぽ(意味不) 1.27.0-nightly (2f2a11dfc 2018-05-16)がregressionしとる。
issueある。待つヨロシ。
>>427,473
the rust referenceのことじゃね?the bookとは別にあるだろ。
全然追いついてないよアレ。そもそもまだ仕様書がない言語だし。
" best-effort document"って書いてあるでしょ httpサーバでありかつクライアントであるみたいなプログラム書く場合、現状hyper一択なのかね?
acitx-webとか誰か使ってない? 最初rocketで書いてたけどactix-webで書き直してる
今だとactix-webが一番良い感じだと思う
必要に応じて同期、非同期、アクターモデルと使い分けられるし https://github.com/rust-lang/rfcs/pull/2444
有志「クソ機能入ったのいらねえから消そうぜ」
大勢「いいな!賛成」
独裁開発チーム「もう入ったから消せませーーーーんwwwwww(クローズ&ロック)」
systemdかよって >>490
もう入ったから消せませんってのは横暴なようにも見えるがしようがないとも思う
一度入れてしまった機能をまた使えなくするとか、それこそ混乱するし…
そもそも何故impl trait を引数の位置にも書けるようにしたのかは確かに甚だ疑問ではあるけど…
引数の位置でジェネリクスとトレイト境界じゃなくてimpl trait じゃないとダメなケースとかある?
無いなら、warning出してジェネリクスとトレイト境界に書き直すように促すのが妥当じゃないかな? こういうところでマウンティングとらないといけない辺り
言語(笑)開発チームとやらも内情はどうなってることやら <T: Trait> foo: T
と
foo: &Trait
との比較で特殊なケースを除き前者の方が効率良いが
syntax上後者の方が簡単なので
初心者が誤って後者を使ってしまうケースがあった
これを防ぐためにimpl Trait および &dyn Traitを導入し
&Traitをdeprecateすることになった 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
D49IO もう入ったから消せません
は正論
何故クソ機能の進入を許してしまったのか、どうすれば食い止められたのかについて追求すべき ジェネリクスの型変数って引数と戻り値の型を揃えるとかそういう使い方をすべきであって
Traitをimplした型を受け取るという意味ではimpl Traitを使うべきだと思う
ただimpl Traitを導入するなら1.0の時点で導入してて欲しかった こういうところでマウンティングとらないといけない辺り
言語(笑)開発チームとやらも内情はどうなってることやら javaのジェネリックスが理解できてないやつが多いだけ。 >>495
それはdyn Traitの実装理由であっても、
引数位置のimpl Traitを実装した理由の説明になってない fn foo(a: &dyn Trait)
と
fn foo<T: Trait>(a: T)
では前者の方がlightweightでは target/debug 以下に生成されるdepsとかbuildって何なの?
goとかにはないよね?
gtk-rsだと500MB消費しちゃうんだけど他のプロジェクトで使い回しとか出来ないの? >>505 環境変数CARGO_TARGET_DIRを指定してやれば再利用してくれるよ
ただ、vscodeのrustプラグインの何かがこの環境変数を考慮してないんで挙動がおかしくなったことがあるんで注意 >>506
おお流石に出来たんですね
プラグインがおかしくなるのはrls側の問題ですかね🤔 日本の企業くらいだよ。
rustで書いてまっせっていうバカなアピールするのは。 まあCloudflareも日本にリージョンあるしな wtftwっていうタイル型WM、設定ファイルまでrustで書くのどうなんだろ
設定ファイルはluaあたりが無難? >>513
いやもうなかったことにしたがってるじゃんw
それなのに変なのに付きまとわれてるっていう。 >>516
「なかったことにしたがってる」というソースをプリーズ Dropboxのbrotliデコンパイラが昨日更新されてたから
24時間以内のホットな情報だ Rustが失脚すると得をする組織があるの?
どうしてそこまで情熱的にRustを貶すの? >>515 ざっとコンフィグファイル見たらXMonadのコンフィグよりは理解しやすいように思った
xmonad.hsはもっと宣言的に書けて、モナドとか上手く作って見栄えは良くできるんだけど、
馴染みのない演算子(<+>とか)使いまくるんで、よっぽどHaskellに慣れ親しんだ人でないと全容が理解できない
設定ファイルのフォーマットを開発言語と同じにするのはdwmから続くタイル型WMの流儀だし、
思ったより読めていいと思うよ。 >>519
前段 モジラとその小判鮫以外の全組織が喜ぶ
後段 技術的にカスなものを貶すのは技術者の義務だろ >>521
>技術的にカスなものを貶すのは技術者の義務だろ
じゃあPHPではなく敢えてRustをdisる理由は?
あちらの方が広く使われてるからより害悪だと思うが >>522
あれを使ってるやつも害悪性は理解してるからな。
こういう技術的にインテリな要素のある言語って信者がとにかく頑なで
実際のプログラムの現場で非常に問題になることが多い。 んー例えば
Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる >>525
んー例えば
コンパイルが通せなくて自尊心が傷ついて自ら会社をやめちゃう問題とか
この話どこまで事実か知らないけど仮に本当だったとしても
これって言語の問題というよりチームのプログラマの腕を過大評価
もしくは計算に入れてなかったというマネジメントの問題だよね んー例えば
プラズマクラスター付き家電が話に出てきたら今まで黙ってたのに凄い勢いでエセ科学だと解説し出すよね いや、この粘着をクビにするためにRust導入したんでしょ
性格異常だもん 老害をふるい落とすために新しい言語を取り入れてるって話? このフィボナッチ数列も書けないあほ
何度言い返せなくなっても数日後に甦る粘着性
C++で実行時にエラーが出るようなコードを書きまくったのでしょう。性格の悪さと溢れる自尊心から誰の耳も貸さなかったのでしょう。
プログラマーとして生きるよりかは、匿名掲示板で巨悪組織Mozzilaと闘うBBS戦士の方が社会的に良さそう たとえばドワンゴとかDropboxとか
Rustを採用した企業自体を叩く行為をよくしているよな
あれ見るとちょっと辛くなる 例えばここみたいに安全でもなんでもないドヤしたいだけのクソなrustコードが量産されるとか。
ttp://tanakh.jp/posts/2016-12-20-rust-pezy-sc.html 槍玉にあげる例が1個しかないのがダサ過ぎるわ。しかもその例も対象が特殊だし
>>534は「それRustでやる意味がある?」という疑問に全く応えられないのが問題
LLVM IR-> PEZY-SCというコンパイラがあるんだったら、LLVMがバックエンドの他言語でもいいよねって話
それができないなら、LLVM->PEZY-SCは未完成か現実に即してないんじゃねえのって話 rustでやってみたって記事にrustでやる意味あるの?って疑問が出てくるのが不思議なんだけど
rustでも出来た、以外に意味はないでしょう >>534
安全じゃないコード も 書けるってことに価値があるんだろ?
C/C++以外の他言語では書くことさえできない。でもC/C++は安全性を売りにはしていない
Rustは安全性を売りにしつつ、必要に応じて安全性を捨てる選択もできるということに価値がある
で、たまたまその記事が安全性を捨てることが必要な数少ない例の1つだったってだけ 安全でもなんでもないって
unsafeあるやんけ!危険危険!
前後の文脈一切分からんけどとにかく危なそうなこと書いてあるやんけ!
つって叩いてるんだろうなw
>>535
その手の問いにそいつが素直に答えたこと無いからあきらめよう たまたまねw
どんだけコード例出しても言い出しそうだなw
そもそもコード例が少ない訳で、推進してる奴のコードがそんなもんなら
十分否定的な要素だけどね。 ちょっとrustの記事書いただけで代表的な推進派扱いかよ >>541
お前さんの理屈だと、Rustじゃこんなに危険になる!って事だろ?
じゃあ、Rustではそういう危険な書き方しか出来ない!って示さなきゃな。
俺は中立だが、あんまり非論理的なdisりはアンチ=低能と思わせたがってるピエロにしか見えんよ。 既に20万行はコードあるからレビューがてら指摘したら喜ばれるよ >>541
ほんとだどこが問題で悪いのか全然書かない
具体的に言及しだすとフィボナッチ数列とか機械語レベルとか、残念なことになるのが自分でもわかってたのか
まあ本人が書いた通り「ドヤしたいだけ」とか…なんかな?前もマウンティング取られたとか訴えてたし… またいつもの、ボロクソにされたらしばらく潜伏してから復活するパターンかな
たまには芸風変えたら Rustの不満は言語仕様やrustcよりcargoやその辺の連携(情報の少なさも含む)にある 既成のクレートを探すのはcrates.ioになると思うけどライセンスってどうやって調べるんだろ
同様にクレート間の依存関係も判りにくい
どちらも一式を落としてきて中身を確認しないと判らないような・・・
Cargoで自動ダウンロードして・・・みたいな使い方をしていると意図せずGPL/LGPLになっていた
みたいなライセンス事故が起きそう >>549
$ cargo install cargo-lichking
$ cargo lichking check
一先ずlichkingでチェックできるよ LGPLのstatic linkとかやめて欲しいよね >>550
えぇー・・・わざわざインストールしないと出来ないのかよ。とりあえずやってみるか
依存関係はどうすりゃいいんだ?no_stdでも使える奴だけ探したいとか >>552
ライセンスをついては、crate名が既知なら、
ttps://crates.io/api/v1/(クレート名)
でjson取れるので、そこから再帰的に依存辿れば収集はできそう >>552
no_stdかどうかについては、Cargo.tomlのcategoryパートに"no-std"があるかどうかぐらいしか確認するすべなさそう(2017-2-10に追加されたっぽい)。
皆が皆付けてるとは思えないので、参考程度にしかならないだろうけど。 ちょうどいい機会だから、カーゴのギフハブべったり依存をやめて抽象化してほしいわん crates.ioべったりは分かるけどGitHub依存って何 rustダメじゃん
firefoxは言語オタに支配されたのか?
【IT】高速化を進めてアドオンを排除したFirefox、ついにシェアが10%切る★2
https://asahi.5ch.net/test/read.cgi/newsplus/1528388348/ >>561
ええ…?FFアドオン排除でRustディスは気にならないのか
以前の試みはアドオンとRustを絡めてみた感じだったな
↓のレスをいつものごとく無視し数日潜んでRust叩きを試みていたけど、スレを跨いで同じ材料出すなよ
109 デフォルトの名無しさん sage 2017/11/15(水) 14:21:13.24 ID:FBksKtwj
>>108
失敗してるやん
Rustなんかで書き直したせいでアドオン全滅してる
114 デフォルトの名無しさん 2017/11/15(水) 14:36:17.78 ID:bBOLEH2G
>>109
それは設計の段階で従来のアドオンとの互換性の一部を捨てるように仕様変更したからだよ。
firefoxのアドオンは自由度が高すぎるが故に、セキュリティに問題を抱えやすかったし、
アドオン同士が衝突して落ちるとかも結構あったから、そこら辺をChromeと同レベルくらいに制限して、
セキュリティと安定性を取る方向に方針転換した。
仕様が変わってるんだから、Rustで書こうが他の言語で書こうがどっちにしろ従来のアドオンの一部は動かないよ。 今回は1週間も我慢できなかったのか
ほかに行く場所ないの >>555の話だけど、
>>555はhg使えなかった時代で止まってんじゃないの? 何でio::Errorにファイル名入ってないんだろう? 不便だなーと思ってたけど
検索してみたら、前は入ってたのに1.0リリース前に削除されたんだとさ
https://internals.rust-lang.org/t/add-filename-information-to-io-error/ >>569
非効率になるのを嫌ったってことみたいですね
stdでもつには重すぎるってのは理解はできるけど 確かに不便なんだよなー
自分は結局
ioの関数呼ぶ前にinfo!でログ出すとか
戻ってきたio::Errorをmap_errでPathBuf埋め込んだ自前のErrorに変換するとかしてます >>570
ここで紹介されてる、failureを拡張して let file = File::open(path).with_path(path)?; と書けるようにするのが
カッコいいなと思った
https://github.com/rust-lang-nursery/failure/issues/189
failureは1.0に向けてまだまだ変えていくみたいだし、これ書いた焦げ寿司氏も参加するみたいだから
期待してるわ
throw!マクロが標準化したら、?の時みたいにrustプログラムの見た目変わりそう 2回もpath書くの全然かっこよくないから、少し重くてもなんでもいいから便利なライブラリがあれば使うわ ■ このスレッドは過去ログ倉庫に格納されています