Rust Part6
レス数が1000を超えています。これ以上書き込みはできません。
rustlang の Discord に Rust(Steam) をクレクレしてるのが出現してる
さすがにベタすぎるのでネタかと思ったけど
「Rust言語は誰にでもフリーだよ!」と住人にやさしく説明されててちょっと笑った
そういう仕込みのフリとオチだったのかもしれないが Rust信者ってブロッキングにも賛成なんだろうなあ
邪悪だ async/awaitのあたりがきれいに書けないなら、ブロッキング+スレッドの方が実用的でしょ いやいやがんばってノンブロッキング対応してるでしょ モジラがバックにいてカワンゴが布教してる技術なんてよく使う気になるよなお前ら >>295
やだよ放射性廃棄物の後処理すんの
世に出して広めた奴が責任もって片付けろよ rustのポジションは他に居ないからありがたく使ってますけど >>294
じゃあ、かの有名なMicrosoftがRustを使っていれば貴方も使う気になるってわけですね
ttps://www.reddit.com/r/rust/comments/8ub964/microsoft_announces_using_rust_to_build_some_of/
はい。これでめでたしめでたし
ところで、ドワンゴが例のRust製分散システムをオープンソースにしてた。
ttps://dwango.github.io/articles/frugalos/ >>296
じゃあ君は最初はバックがどうこう言ってたけど実はそんなこととは無関係に嫌ということかな? ただの廃棄物じゃなくて放射性廃棄物ってどういう比喩なのか
阿片みたいに観戦力があり周囲に広がるということ?
それとも単に処分に困るというだけ? 暗号通貨関連でよくRustが使われてるってホントなの? >>304
残念ながらC++, Java, Goと比べたらゴミカスや 家の非力なデスクトップにgentooを入れたんですが
firefoxをコンパイルしたらrustもコンパイルしてくれました
rustも含めて都合14時間かけてコンパイルしたfirefoxを使うだけじゃ勿体無いので
rustを勉強してみようと思ったのですが
スクリプト言語とjavaを触った程度の人が始めるには
ハードルが高い言語なんでしょうか?
何かとっかかりになる良いサイトとか本がありましたら
教えてくれると嬉しいです
Python歴7年Java歴2年の趣味プログラマです
rustでgtkアプリを作ってみたいです ヤル気はマンマンなんですが
まだgentooのインストール途中でxfceにfirefoxが入ってるだけなんですよね
帰宅したらvscodeも入ってるはずなので今夜からコンパイル流しながら勉強する予定です
ただ、あんまり初心者向けの日本語情報が見当たらない気がするので
いいサイトがあれば知りたいな、と思った次第です Azulとかどうよ
とりあえずサンプルビルドしたら普通に起動した 皆さんいろいろとありがとうございます
とりあえずプログラミング言語Rustの日本語訳pdfを見つけたので
それ見て勉強してみたいと思います
これ凄いですね
無料で配布しちゃって良いんでしょうか
下手なwebの情報探すより公式見たほうが良さそうですね Gitとは何かの説明まであって驚くよな
さすがにそのレベルの人は門前払いしたほうがその人のためにもいいと思うが >>316
あれはRust初心者だけでなくプログラミング初心者も対象としてるんじゃないの?
だから初歩的なところから教えてるんだろうと思っていたが
まぁ、プログラミング初心者がいきなりRustから始めるってどうなのよ?とは思うけど Cとかでメモリの扱いミスってしかも落ちずにおかしな動作する、みたいなのの経験がないとイマイチRustの有り難みは感じられないようなとも思いつつ
かといってRustのためにC勉強するってのもなんか本末転倒なきもするし なまじ他言語を知ってるから難しいという点もあるんじゃない
初心者がベテランが作るようなものをrustで書くのは辛いだろうけど、初心者が作るようなものを書く分にはむしろ易しい気がする
セットアップ楽だし Mozillaはドキュメント書くの得意だよな
オワコンブラウザには勿体無さすぎる才能 なぁに、まだまだこれから。
などという言葉が出始めたら終わりは近い。 書店でオライリーのRust本をパラパラと読んでみたけど
式の可読性の面ではC++の悪いところを引きずってるように思える try!(try!(try!(foo).bar()).baz()) とか? try!(try!(try!(try!(foo).bar()).baz()) とか) え?前なの?
手元の蟹本だと、
7.2.4節 エラーの伝搬に"?演算子"のこと書かれてるんだけど muslでビルドすると普通にlinuxでビルドしたときよりメモリ食うんだけどなんで? >>331
標準のライブラリだと、メモリ上にロード済みのコードを共有するからじゃないの? libcとかがダイナミックリンクじゃない分てことだよな
色々検証していたんだがそれだけじゃなくリークしてるように見える >>318
だがそれが一番の近道だよ。
結局 c -> c++ -> rust の順で学ばないと意味わからんだろう。 >>334
いやCはともかく少なくともC++は要らんだろ >>335
見てみたらリークはしてなかった
100mbくらいあるヒープに確保された値を1分に1度入れ替えているんだけど、ヒープに確保された領域って即解放されるわけではない? まだjemllocがデフォルトだけどナイトリーでは既に外されていて近々デフォルトではなくなる
それとは別の話で、俺がビルドしたのがmuslビルド用のdockerイメージで、それにはjemalloc入ってないからシステムアロケータで動いてたんだよね 2018安定化でむしろ盛り上がっているのでわ
うちはリプレイス案件2つにrust使うことにした まともなヤツなら将来が保証されない言語なんかを採用しないからな
一時的に使用するドカタ向け案件なら試用にぴったり
まとも思考してたら、将来も間違いなく保証されてるc/c++を使う FacebookやDropboxが採用してるし
最近だとAmazonがRustでVMMを作ってる >>348
Facebook採用してたっけ?あそこはDだったような…
MSの間違いじゃない?MSだったらAzureの中の一部で採用してたはず…
因みにGoogleも自社製エディタに(たぶん20%ルールでだけど)採用してるね
もしFacebookも採用してるならApple以外の主要IT企業は全て採用してることになるな
(AppleはObjectiveC/C++とSwiftしか使わないしね…) まあクソアプリほどどの言語で書いたかとかアピールするよね。 >>349
低レイヤーでC++の次世代言語って意味合いではDとRustって似たとこあるよね
大きな違いはバックボーンとしてMozilaという巨大コミュニティがあるところだけど Rustは良いけどMozillaの将来が心配
MSも撤退するしこれから更に厳しくなりそう >>356
MSが撤退っていうのはブラウザエンジンの話をしてるのか? ブラウザエンジンの話
Mozillaが厳しくなるとRustにも影響がある >>359
Mozillaはなんだかんだ言っても一応非営利団体だから
MSみたいにブラウザエンジンを手放すようなことはしないはず
つまり、Firefox(Gecko)が消える時はMozilla自体が消える時と同時で、
流石にMozilla自体が消えるとは考えにくい… いうてもWebメールじゃないSMTP式のメールのメーラーとしてはMozilaのThunderbirdのシェアってそこそこ高くない ThunderbirdはMozillaから切り離されるんじゃないの ブラウザに関してはグーグルが死なせないと思うけどな 仮にMozillaがどうにかなってもRustは大丈夫だろ 初期はMozilla頼みだったけど、今はそうでもないという認識 なんか新しくマクロ増えたみたいだけど使い勝手どう? stableって今1.31.0だろ。
「nightlyが久々にやらかした+distマシンの環境壊した+CI壊した」でnightlyが三日止まっててまだ1.32.0だからdbgマクロくらいしか違いないぞ。 ∧_∧ / ̄ ̄ ̄ ̄ ̄
( ´∀`)< ・・・
( ⊃ .旦| \_____
し_)___) Rustのドキュメント日本語サイトが404になってた パイプと型変換だけで十分なところにモナドを要求する馬鹿。 旧サイトのほうがいいなすっきりしてて
情報量的にもデザイン的にも なんか安っぽくなったね。詐欺のベンチャーみたいなページになった。
以前のデザインのほうが圧倒的に良い 駆けつけでいきなり言語の特徴とplayground見せるのは話が早くていいよね。
なんか気になればそのままナビゲーションヘッダのリンク辿ればいいし。 現在開催中のこのAIコンテストの説明のサンプルコードにRustが選ばれているあたりRustは世界一素晴らしいプログラミング言語であることが分かる
http://russianaicup.ru/p/quick Rustと最初の3文字が一致しているので親しみを抱いてるんですかね マイナー言語やってるけどしんどい😭
いずれRustに乗り換える💪 仕事で使えないから趣味で使いたいけどスマホアプリとか作れるようにならんかな
wasmでやれるん? 所有権借用はなんとなく理解できたがライフタイムだけよくわからない
なにがわからないのかすらわからない 元々わからなかったけどNLLでよりわからなくなった lifetime関係のエラーが出たら、一歩引いて考えないとドツボにはまる
どうして借用にしたのか、誰が責務を負うべきなのかとかを見直していくと、まあまあ綺麗な形でエラー出なくなるから楽しい >>394
ライフタイムは変数のスコープと一緒だよ。
ただrustの場合、関数の引数に対してライフタイム指定ができたりするんだが、
それを省略した場合なんかのルールが結構複雑なんでわかりづらくなってる。
まあ色々検討した結果が今の状況なわけでこれはこれでしょうがないんだが。 >>397
>ライフタイムは変数のスコープと一緒だよ。
ちげーよ。extentの方だよ。 ide使いたい初心者なんだけどintellijもvscodeも補完が微妙だった。
エディタ上で赤く無くてもコンパイルしたらエラー出る。なんか設定おかしいのかな。。 RustのIDE環境はまだまだ未発達なのです(´;ω;`) あきらさんowやめてrustの解説に専念してほしい >>403
いやまずお前は他人に依存してないで公式ドキュメントちゃんと読んでQiitaでも読み漁れよ Juiceのユーザっているのかなぁ
ActcastはRustで書かれてるらしいけど >401
intellij rustだけど補完もリファクターも、traitの実装も出来る。 >>407
Rustの文字列には何種類かありまして…… >>406
マジで?俺のintellijはあんまりintelliやないんやけど。
(0..10).
これでfor_eachとかの補完できる? intelliJ rustもrust(rls)も全部が全部補完出来るわけじゃないよ。
むしろRange系がほとんど補完効かない。 rlsって2016年に登場した時いつか脱racerするとか言ってたと思うんだけど何で未だにracerに頼ってるんだろ?
clangはclangdとかcclsとかあってどっちもコンパイラを使って強力に補完出来るけどrustも同じような方針で実装出来ないの? >>412
> intelliJ rustもrust(rls)も全部が全部補完出来るわけじゃないよ。
> むしろRange系がほとんど補完効かない。
そうなんか。まあそれは慣れればええ話か。
ide上で赤くないのにコンパイルエラーになるのは何か環境構築に失敗してるのかな?
単純なシンタックスエラーは赤くなるんだけど、所有権まわりは赤くなってない気がする。 >>413
racerはfallbackしたときだけでそれ以外はコンパイラ使うよ。
インクリメンタルコンパイルがまだまだだから出来ること限られるだろうけど。
>>414
>所有権まわりは赤くなってない気がする。
赤線つくね。マウスオーバーでエラー内容もshort版を整形したようなの確認できる。
quick fixが弱いけど。
rlsならrust-srcとrust-analysis。intellij rustならrust-src入ってる? >>415
できた!ありがと。
intellij-rustの設定おかしかったみたい。 Rustで簡単なゲームを作ってみたいんだがフレームワークは何が良いんだろうな
SDLやDirectX、OpenGL等のラッパーは一応あるようだけど 言語レベルで静的にstructを差し替える方法って無いんかな?
マルチプラットフォームのアプリを仮定するとして
アプリはSystem構造体下のメソッドを経由して低レベルの機能へアクセスする
System構造体の中身はビルド時に決まる物だし実行中に選択するのはコストの無駄
ビルド時にコンパイル&リンクするファイルを差し替える方法はあるが・・・ 静的リンクならcfgマクロ使った条件付きコンパイルしかないよ。 ありがと
#cfg[(target_os=〜
struct System {
とか書くしかないのか
というかググっていてもマルチプラットフォームのアプリを作る例って出てこないんだけど
どういう風にするのが好ましいのだろうか。Cargoの使用例とか全然判らん
ターゲットによってコンパイラも変わるし、リンカやリンカに渡されるオプションも変わる
リンク後に追加の処理が必要になるケースもあったり 有名なcrateはだいたいマルチプラットフォームになってるでしょ そのレベルじゃなくて一つのプロジェクトで
1.Windowsでビルドする/動く
2.Linux/FreeBSDでビルドする/動く
3.Linuxでクロスビルドする/別アーキテクチャのプラットフォームで動く
みたいなのをやりたい。1〜2はともかく3はベアメタルに近いのでコアのソースはno_std付きになる
クレートもWindowsAPIへアクセスする場合Cargo.tomlに
[dependencies]
winapi = "〜
kernel32-sys = "〜
とか書くけどコレをつけたまま他のプラットフォームでビルドできるのか?とか
仕様上無視してくれるならそれで良いけどはっきりしないと無用なトラブルの元
クレートを使わずにソースにexternを並べていって条件付きコンパイルすればその心配は
なくなりそうだけど各種定義とか、IA32/AMD64環境下の差異の吸収とかいろいろ面倒だし >>423
有名なcrateはだいたいちゃんとそれこなしてるから見てきなよ スマン
Carge&winapiを使ってWindowsAPIを叩くサンプルを作ろうとしたらそこまでたどり着けん
use出来なくて詰まっている
extern crate winapi;
use winapi::minwindef::BOOL;
>cargo build
error[E0432]: unresolved import `winapi::minwindef`
--> src\main.rs:4:13
|
4 | use winapi::minwindef::BOOL;
| ^^^^^^^^^ Could not find `minwindef` in `winapi`
パスがおかしいっぽいのでソースを見るべきだが、Cargoが取ってきたソースがどこにあるのか判らない
というかコレを調べられないと非対応環境でどう振る舞うのかも調べられない
rustcでコンパイルするFFI直でWindowsAPIを叩くコードは動作させられている Cargo.toml に
[target.’cfg(target_aech = "x86_64")’.dependencies]
とか書けるけど、これでも不十分? cargoがとってきたのはホームの下の.cargoにあるよ
質問がいまいち判然としないけど WEB開発でフロントエンドもバックエンドもRustで開発できるようになるみたいだね
そしてJavascriptは衰退するらしい
まさに次世代の言語か? >>426
それでいけそうかも。というかwinapiにそんな書き方があった
>>427
ありがと。見つかった
README.mdにあったサンプルはビルドできた
1〜2年前のコードだとビルドできないようだ
いくら発展途上の言語とはいえ1〜2年前の情報が使えないのはつらいなぁ
車輪の再発明になってもFFIで書いていった方が良いのか?
というかみんなどうしているの?情報の有効期限が1年もないんじゃ
ちょっと前のを修正するにもドキュメントはないしソースとにらめっこになっちゃうよね nightlyでも使っていない限りは、基本的に過去のコードはビルドできると思うけど >>418
rustにとって一年前は古いけどwinapi::minwindefは今はwinapi::shared::minwindefよ。
apiが変更されただけだからまずdoc読めばいいよ。
あとrustupでrust-docインストールすればthe cargo bookもあるからそれも読んで。 >>432
0.3.x以降はCargo.tomlにfeaturesを書かないとダメらしい
あとunsafe祭りになってしまいそうなんだがwinapiの仕様でFAなんかな ttps://docs.rs/winapi/0.3.6/winapi/um/minwinbase/struct.OVERLAPPED_u.html
これってどうやって初期化すればいいんだろ?
ReadFile/WriteFileでOVERLAPPEDを使いたいんだが よく知らんけどOVERLAPPEDをmem::zeroedで初期化して引っ張ってくるんじゃないの 型のパターンマッチってメンテナンス性が悪かったりする? ML系の関数型言語の経験があるなら全く問題ない
経験ないならHaskell/OCaml/F#あたりのうち最低一つは触れてみることを強くお勧めする やっぱRustに限らず新しめの言語できる人って英語もスラスラ読み書きできるもんなの
読むのは時間かければ何とかなるけど書けないから質問する場所が限られる パターンマッチは型で分岐するというより型に当てはめるという感覚の方が近い
OO言語でマサカリ投げられるような型で分岐するというのとは似て非なるものなんだが、
そのへんの微妙な感覚を掴んでからでないと糞コードの温床になりそう 何かのIDEで
(0..10).
の補完が効くようになったら教えて RangeはIteratorを直接実装するからcurrent scopeにIteratorがuseされてない状態でIteratorのメソッド解析出来ないと無理だろうね。
useされてないトレイトのメソッド使ったら自動でuseする機能のほうが先。 https://volt.ws/lang
https://volt.ws/game
V言語とかいうやつ、GUIアプリとか3Dゲームとかを開発するために作られたらしいけど、GCがないとか1500万行のコードを1秒でコンパイル出来るとかバイナリサイズが極小とかC/C++とのやりとりが簡単とか
これが本当だったらRust負けちゃうんでは
実際Rustで低レイヤーやってる人少ないだろうし 詳細知らんけど低レイヤーに適した言語が出てくること自体は歓迎できるんじゃないの 言語は言語の良さだけでは流行らないんだよ
RustもGoもまあまあ悪くない言語である上で十分なステマを行ったから流行った それ使ったアプリがよほど良くて、開発者をうまく集められて、コミュニティが育たなければ無理だろうな
ソース非公開のうちは勝負にもならん 幾ら優れていようと後ろ盾がなきゃD言語の二の舞だろ コンパイルが速いならジェネリクスも無いんじゃないかね。安全性については対nullしか無いっぽいし OCamlとかジェネリクスあるけどgoよりコンパイル速いよ
っていうか21世紀のOCamlが欲しかった(OCamlはそんなに古い言語ではないけど) Rustほど丁寧なエラーメッセージ出してくれる言語もないでしょ
そういうのを捨てて速度を取った言語とは比べられない > Rustほど丁寧なエラーメッセージ
冗談だよな? って思ったけど最近のは丁寧なのかな Vってvoltのことか。あれgoに毛が生えた程度の言語よ。
>>457
今のはコマンドプロンプトのバッファが足らなくなるくらい丁寧だけど
答えそのものを教えてくるから書いたコードがだめな理由が初学者に理解できないのは変わらないと思う。 >>449
どうググるとそれ出てくるの?
「volt プログラミング言語」でググって出てくるのこれなんだけど
Volt Programming Language ・ GitHub
https://github.com/VoltLang
http://www.volt-lang.org/ 大体はGoとかと一緒で言語名+langで検索するのがいいんじゃない?
四文字もあって他の情報が上に来るのも珍しいが googleで言語名+langで検索するとgoを検索結果にねじ込んでくるから-go必須 rustでググってrustってゲームがトップに来なくなったのはグーグルさんが僕の検索履歴から判定しているだけ >>465
http://cglab.ca/~abeinges/blah/too-many-lists/book/first-push.html
かいつまんで言うと、&mutなオブジェクトが一瞬でもinvalidな状態になるから。
mem::replaceを使うと、self.listの値を取り出して代わりに別の値を置く、という処理が一度に行える
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8d12416b3f7bc4aa44bf360df11de1be >>466
ありがとうございます。
変更可能な"参照"で持ってきたもの(&mut self)から所有権をムーブさせることはできないという解釈で大丈夫ですかね。
置き換えるときはmem::replaceを使うようにします。 クソコード教えるんじゃねぇ。Optionの中身をNoneと入れ替えるならOption::take使え アアン?Option::takeのソース見ての物言いだろうなあテメェ 中身見たのならなおのことOption::take使うべきでは >>455
OCamlは、文字コードの扱いとWindows環境の扱いが
もう少し良くなってくれると嬉しいな。 インデントのスペース幅は2が良かったなぁ
clang-formatもprettierも2がデフォだし
C#でさえ2を結構見かけるようになってきた
rustに強く影響を与えたであろうocamlもhaskellも2が多い
世界的に2が標準になりつつある気がする Pythonをインデント2で書く奴だけはマジで死ね
あれはガチで読めない
他の言語なら好きにしろ ocamlからリスト引き継いでくれたらよかったのになあ
しかしそうするならもはやocamlそのものでいいってことになりかねないかな >>474
それだとgoogle連中には全員死んでもらわんとならんな。 noto sansにindent 3をわかってくれるのはねねっちだけか。
今は源真ゴシック等幅+Source Code Proだけど。
Source Han Codeはちょっと違うんだよ。 googleのstyleguideではスペース幅4を推奨してるのにgithubのgoogleのpythonレポジトリはスペース幅2が多いな
pythonはpep8を重視してるイメージがあるけど堂々と無視出来るのは凄い
rustもrustfmt.tomlでtab_spaces = 2を設定してる人が結構いるわ
https://github.com/search?l=TOML&q=tab_spaces&type=Code
3にしてる人さえいる インデントで制御構造を表現する言語だと、深いネストから戻るときにどのレベルに戻ったのか識別できなくなる タブ2で見ずらくなるようなネストの深さと関数の長さになるのが悪いと
言いたいところだがgoogleのオフィシャルコードは結構ど汚くて上の条件を無視してる。
個人的には3が視認性の上では一番良いと思ってはいるが、流石に2,4と互いに素な数だと
プログラム的になんか嫌なこと起きそうで自分では使ってないな。 タブ幅小さくして、その分変数名を分かりやすく長くするんだよ >タブ2で見ずらくなるようなネストの深さと関数の長さになるのが悪いと
2派と4派の対立は4が深すぎるか、2が浅すぎるかなのに「2で見ずらくなる深さ」って想定おかしくね?
3派は間とって3だよ。こっちは普及してないのが問題。 Scalaみたくスタイルガイド作っちゃえばいいのに
そうすれば「スタイルは公式に従うように」の一言で済む ハードタブなら各自好きな幅にすればいいから揉めないのにね。 回りの多数派にあわせるだけの話
こういうのにこだわるやつは大抵バカ
可読性w なんてここでタブ・スペース論争してんだ
どうせ一人でしか書かねえくせによ〜 >>489
ほんこれ
見やすさとか人によって違うしどうでもいい エディタファシストなのでエディタを開発したことないやつは駆除されるべきなのではと考え始めて来た。やばい 昔々学生の頃に学校のワークステーション使ってXlibでドット編集してXPMファイルで出力するなんてものを作った覚えがある。
あらから29年。時の経つのは早いものぢゃ。 読み込んで表示するより出力の方がはるかに簡単だしな >>494
xlib ダイレクト記述、とは猛者ですね…
私も最近になって xlib をバシバシ触ろうと思っていますが、いい参考書はありませんか? XlibってCの悪いところを煮詰めたような設計だったな
Rustとの相性は最悪だろう 日本語の参考書はX11R5の大昔に出た本ぐらいじゃないかな うん。新しいXlibの本は知らないなあ。
探す気も起きないから知らないだけかも知れないが。 >>498
なんというか、オブジェクトを作って操作するような感じなので今時の言語用のオブジェクト指向に合わせたラッパーは作れると思うが、需要はほとんどないような気がする。 xlibの使いやすいラッパーとしてはgtk+などなどがあるんわけで… >>465です
スタックにpopを実装しました
pop自体はうまく動いているようですが…
popした時の対象の物がどのタイミングで破棄されているのかを調べようと思いstd::ops::Dropを実装しようとしましたがうまくいきません。
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f1a2a2a35c3dc424f3814557afa5974c
何がいけないのでしょう haskellでの、文字列[Char]を切り貼りみたいな事をするには、
Vec<char>を操作するので合っているのかな? >>505 Dropを実装した型の値がdropされるとき、フィールドは全てvalidじゃないといけない。
そのままメモリ解放するだけ=Drop未実装ならいいんだけど、drop中にinvalidなフィールドにアクセスできちゃうのがダメだというのが問題
解決案は、ここでもOption::takeかmem::replaceでNoneにすげ替える
けど、まずはLearning Rust With Entirely Too Many Linked Listsを写経してみた方が良いよ
今のListの定義だと無駄なメモリを食うし、パターンマッチとstructは相性があんま良くないし、これから先も似たような穴にハマると思われる Rustいいらしいですよって話を会社でしたら、
テックリードが「RustでできることはCやC++でもテストとツールで十分やってけるからイラネ」って言ってたけどマ? &str で関数に渡すと解放されてしまって使い回すこどができないのですが
使い回す方法ありませんか >>510
コンピュータでできることは人の手と頭でできるよ >>512
じゃあうちにはたしかに要らんなあ
そんな統制がいるほどの人数でもないし
回答サンクス >>510
そのリードが C++でauto_ptrがdeprecatedになった理由とMove Semanticsと右辺値参照の関係をちゃんと説明できる人なら C++ でいい 人間が信用できないからこそCよりRustだろ
気を付けてコーディングすればミスはなくなる、ってのは戦前の日本軍的な精神論だ
コンパイラ先生に怒られながら厳しい指導の下にやっとコンパイルしていただくのがRust
この記事とか参考になるかも
https://tomo-wait-for-it-yuki.hatenablog.com/entry/2019/02/05/210746 プログラミングは製造業だからな
厳格なチェックは本来あって当然 >人間が信用できないからこそCよりRustだろ
>気を付けてコーディングすればミスはなくなる、ってのは戦前の日本軍的な精神論だ
ぴんとこないな。
rustの場合、お役所とおせばテストなど自前でしなくともokっていう
変な信用を生んでるだけだろ。そっちのがよっぽど日本的だと思うがね。 >>519
今時の言語なので、ユニットテストは標準で整備されてるよね
コンパイラは計算ミスや仕様間違いまではチェックしないので 考え得る全パターンをいつもテストできるならいいんじゃないの メモリ破壊はユニットテストで検出されないケースも多い 注意力ってのは慣れると省力できるようになるけど、有限リソースだし個人の習熟度と体力に依存するんで、目に見えない負債になる
新しい言語を理解するコストは償却できるけど、注意深さってのはソースコードを触る限りはコストを発生し続ける
機械がチェックできることは機械にやらせた方が絶対に良い 製品にするコードってどうせMISRA C辺りの静的解析噛ますし
今時ならvalgrindもテスト項目に入ってるだろうし
Rustなら全部コンパイラがやってくれる!と言われても、
いやCにも外部ツール入れれば同じことできるし……としか思わんのだよな
個人的にはクラスよりトレイトの方がしっくりくるからそれだけでもRustは意味があると思うが >>523
枯れてないコンパイラの癖に合わせる方がよっぽど注意力を削ぐと思う。
コンパイラになんでも機能ぶっこむより524のように構成した方がどのツールが文句言ってるのか
よっぽどわかりやすい。
機械にチェックさせるのはいいがシステムとしてモジュラリティーが高いツールの組み合わせのが
結局使いやすいし、ロバストになる。 どうでもいいけど言語の持つ表現力とかは完全に無視なん? >>526
C++の方がノイズが多いくらいで表現力自体は大差ないわ
もちろん、そのノイズによる可読性や生産性の低下は決して無視できるものではないが >>525
Cだって作成当初よりコンパイラでチェックする範囲広げてるけど
全否定? >>526
CやC++との比較でそこ(表現力)に触れずに
「Rustは安全!C/C++はfree/delete忘れがーアクセス違反がー領域の破壊がー」ばっか言ってる人が多いのが疑問って話な
俺はトレイトに可能性感じてるから期待してるよ
C++のテンプレートとか関数オブジェクトとか書きたくねえし
あとチェッカーとコンパイラ分けるべきか合体させるべきかについては、
どっちにも善し悪しあるからCとRustどっちが優れてるとかはないと思ってる Cじゃ確かに無理かもわからんが、C++のstd::vectorならatメソッドで同じことできるぞ
毎回アクセス範囲が適切か確認するから結局オーバーヘッドになってほぼ使われんがな 基本はIndex::indexを呼んで必要なとき(オーバーヘッドが気になるとき)にunsafeで囲む
C++は全関数がunsafeで意識せずVec::get_uncheckedを使うようなもの
オーバーヘッドの問題でunsafeで囲んだらRustだってツールじゃムリ五十歩百歩って言われるかもしれないけど、五十歩の方がいい MozillaやRust作者の人達が、valgrindやチェックツールの使い方を知らない
アホ揃いだと思ってるの? >>533
MozillaやRust作者の人達の過激な信者が
valgrindやチェックツールの存在を知らないか軽視してるせいで
Rustの宣伝に対して過剰にC/C++をディスってるアホ揃いだと思ってる
もちろんそうじゃないRust推しもいることは承知の上だ
逆に、「そういうツール使えばC/C++だけで十分Rustなんてイラネ」って意見も
ベクトル違うだけで同じくらいアホだと思ってるがな
だからこそトレイトの使い方だとかモジュールの仕組みだとか
外部ライブラリ(crate)の扱い方の方向での他言語との比較が
あんまり見えないことが問題だと思うんだが
そういう意味で話題提供すると、cargoって結構disられてるけど
どの変がクソなのかいまいち分からん
キャッシュサーバ持てないって話ならnpmとかbundleとかgo getも大概では? みんな同じ話題について話してるのか?
好き勝手独り言言ってるようにしかみえない。 そりゃーRust信者とRustアンチしかいねえからな
話が噛み合うわけない Rustだと(unsafeなし、コンパイラのバグなしなら)プログラムの全実行パスでメモリリークや破壊がないことが保証できると思うけど、
C/C++で同等のチェックができるツールってある?
valgrindは単にvalgrindで実行したパスで問題なかったことが分かるだけって理解なんだけど。
もしあるならそれはそれで使ってみたい。 >>539
俺もその認識なんだけどvalgrindナメてたかな
Firefoxのcssのバグはテスト書いて発覚した感じなんだけど その手の静的解析ツールはたいてい商用製品だね。一番手頃なのはVSで使えるSALかな。 顔本のinferがオープンソースで全パス調べてくれるやつだな
企業ならcoverity課金してるだろ inferは知らなかった。ちょっと試してみる。
まぁ商用含めても原理的に検出率100%とはいかないだろうけど、
Rustだって標準ライブラリ内のunsafeバグとかあるからいい勝負なのかな。 全パスチェックしてもRustのコンパイル時のチェックには及ばない
全パスチェック程度で済むものならば、Rustにあんなややこしい概念を持ち込む必要はないんだよ 言語として縛りを強制するってとこに旨みがあるよね
静的チェックを過大評価云々は的を外した無意味な議論 Rcなりunsafeなりあるわけでなんだかね。
rustを意識してプログラムをすることに意味はあるがrustの実装系を使うことに
そこまで意味はない。 俺はweb屋さんだけどサーバ書くならrustが最高とおもってる
これって過激な信者? 信者だアンチだディスったディスってないでrustを語れよ coverityとかの静的解析って誤検出が結構ある
で誤検出かどうかの人力解析も超めんどくさい
かつ1度の解析にめっちゃ時間かかる
これがあるからC/C++でもRust同等とかないわ >>547
web屋さんはもともとC++なんて使ってないし使う人が順調に増えていってる印象
問題はweb屋さん以外にどうアピールするか どうせ一時の流行で終わるんだから被害は少ないほうがいい
Scalaとかも中途半端に業務系が乗っかってきはじめた矢先に梯子外されて死屍累々の惨状だったし >>551
なんか梯子外された事件あったっけ?
Java8の登場でScalaがただの難解なJava8になった話? Javaは今でもクソ言語なのでScalaとは比べるべくもない
単に日本の人月制度とマッチしなかっただけ
Rustもそうなる
学習コストの高い良い言語より学習コストの低い低単価で人を集められる言語 色んな業界があるのに一緒くたにして評価できなくない? >>555
JavaやPHPはともかく、そういう意味でCやC++がコスト低い言語とは思えんが 個人的な経験だけど、Rustのコンパイラを単純に黙らせるようにソース修正していくと物凄く汚くなることが良くある
ので、そもそもの設計を見直すようになったり、かくあるべしって仮設を明確にするクセが身についた気がするよ >>557
低学歴のC/C++職人様はつぶしが利かないからスキルの割に高くないイメージ 資源の共有状態を見直すってのはrustは置いといてもプログラムをに置いてやっぱ本質だなと思う。 ArcとかMutexとかRwRockが気に入ってる
最初めんどくさかったけどよく考えたら当たり前に必要なんだよね
そこを隠蔽しないことでコストのトレードオフをプログラマに意識させるのがよい 練習で他言語のプログラムを移植してみたらコンパイラに
ガンガン怒られて本人が壊れるような使い方しないからと手抜きしていた部分が
洗い出されてなるほどなあと思った rustに限らず他の言語でもgtkぐらいしかないでしょう orbtk?
redoxのguiだけど、windowsでも動いたよ。 >>561
当たり前じゃねえから
PythonとかPerlとかRubyで書かれたプログラムにはないけどちゃんと動く
それともこれらの言語で書かれたものはプログラムじゃないとか言っちゃう系? RwRockが自然に必要ってのは言い過ぎだわな。
必要なところは必要だろうがそれがあまりに多いのは多分設計ミスってる。 ですから必要なところは必要と言ってるだけじゃないですか
当たり前にってのは原理的に必要と言ってるだけだよ >>569
Rustの設計思想理解してないのか
単にアホなのか まぁ自分の書いている範囲内しか見えない人は普通にいるだろう。
どの言語だってライブラリや処理系レベルでは排他制御はあるし、
逆にどこにもなかったら単に間違ってる。 Perlは知らんがRubyやPythonには
GILっていう排他制御が言語処理系に含まれてることを考えると
非常に味がある >>576
他の言語が息できない分野でエラ呼吸してるよ >>575
GILは複数スレッドの競合によってインタプリタがぶっ壊れるのを防ぐために必要な、インタプリタ自身の内部的な排他制御
アプリケーションコードで行う排他制御の代わりにはならないよ
インタプリタがスレッドセーフでない糞実装であるための苦肉の策で、
Rust含め元々スレッドセーフな「まともな処理系」なら全く必要のないもの そういや Perl でマルチスレッドのプログラムは作ったことないなあ。fork してマルチプロセスにするのはよくやるが。 そうか、今時の人はみんなLock-freeアルゴリズム使いこなすんだな
Mutexなんて見たことないんだ OSかそれに近いコア領域とかトランザクション必要なデータベースでも書かん限り
MutexとかLockとかが必要だとは思わんなー
Web系にもてはやされてるらしいけど君らそもそもそれオーバーキルどころか逆に足枷ならん?って思う >>583
そもそもそんなに並行処理をOSやミドルウェア頼りじゃなくて自分で書くが必要な場面て例えばどこ?
と質問に質問で返してみる 念のため言っとくと、別にロックなんて無駄だとか言いたいんじゃなくて
ArcとかMutexとかRwRockが当たり前に必要とかいうマウンティングに反論してるだけな >>584
仮にお前がミドルウェア使うだけの些末プログラマ
だとしてもミドルウェアがマルチスレッドで動いていたり、
複数のミドルウェアを使う場合は
排他処理が必要なケースは普通に出てくるだろ >>585
rustをc++の代替候補として考えるなら使って当然
並行処理でこそrustの有り難みが生きるわけだし
マウンティングに感じるのは単にお前が並行処理に馴染みがないからだろ >>586
それはそんな使い方する方が何かしらおかしい
排他制御ってのは本当に必要なところ以外ではやらないように回避するもんだ
>>587
Rustの旨味がそこにあるのは否定しないが、
それが全プログラマが当たり前のように使いこなせるべきっていうのは
ただのマウンティングだろうに >>588
排他が必要だからするにきまってんじゃん
そういうところに思考が及ばないやつはjsだけ使ってりゃいいと思うよ プログラマーがリソースの共有状態を意識すれば
無駄な排他制御しなくても大丈夫だという主張かねえ RwRockってRwLockの間違い?
そういう言葉遊びのライブラリでもあるの? RwLockが少ない設計で組めたぜ!って自慢するならともかく
RwLockめっちゃ使ってますなんてアピールする奴は普通にバカだろ。 単に日本語の問題では?
多分解釈が二通りある。
マルチスレッドプログラムにとって排他制御は当たり前に必要
プログラマにとって排他制御は当たり前に必要
個人的には文脈から前者と理解したけど、後者だと思うなら言い過ぎだというのは分かる。 lockをrockと間違ってもしれっとしてるやつもかなりのバカだよね
ソフトウェアの超頻出単語じゃん だからプログラマにとって当然の能力という意味で言ってないって
めっちゃ使ってるとも言ってないって
隠蔽しないから必要性とコストを意識できていいねって言ってるやんけ
誤字はすまんかったけど まあ俺が採用だったらここまであからさまな地雷は避けるわ。 なぜ自分が採用に関与できない雑魚だと表明してしまうのか理解できないけど、そうしたほうがお互い幸せになれるだろうね >>596
お前は派遣だろ目を覚ませ( ‘д‘⊂彡☆))Д´) パーン こういう奴らに並列実装なんてさせるから地獄を見ることになるんだよな。。 Rustなら地獄を見そうなコードは
コンパイラが怒るからよかったじゃん Mutexとかもはや古典技術でしょ
Rust使う領域では理解してて当然と言っていいよ
これがマウントだとしたらキレイなマウント >>601
そういうことばっか言ってるからいつまでも二流言語と違うんか? フリーランチの時代はとっくに終わってるのに気づいてないんだ…
プログラミング界の横田庄一だな Rockといい横田といい、この程度のことも注意できない奴だから
こんな口うるさい姑みたいなやりたいこともやりにくい言語をもてはやすんだと納得 横井さんも刺身食えなかったらしいからな
排他処理に拒否反応示すのも無理はない
Rustはやめときな >>600
rustでコンパイル通れば安全というわけじゃないっていう例なんだが。。
やっぱバカに並列化コードは触らせないほうがいいな。 競合条件がなくなることはないけど、データ競合はほぼ回避してるぞ
安全じゃなくなるのはデータ競合のときなんだから、安全じゃなくなる例になってないぞ
経験上デバッグが難しかったりするのは大体がデータ競合によるものなんで、Rustは並行処理にも威力があるぞ 兵庫県警の件、brendan eichが証人受けるとまで言い出して面白いことになってるけど、
アレが駄目ならビジーウェイト書いてるやつ全員逮捕だよな。組み込み勢狙われるぞw >>613
普通に考えてスレッドでやるメリットってデータ競合が生じるようなアクセスを
考えなきゃならんパターンなわけでそれはrustだろうとなんだろうと楽になんかならんという
当たり前のことがわかってない。
そういうある種のアクセスパターンに対する制限なり証明なんてのは設計をよっぽどシンプルにせにゃ
適応できんってのがまともに実装してれば分かるもんだがな。 >>615
Rustでコンパイラエラー出さずに競合で壊れるようなサンプルある? 人間には難しいから機械にやってもらうってことだろ
楽になってるやん Rustでsql扱いたい時ってなにつかえばいいんですかね >>616
話が通じてないのはよくわかった。
コンパイラエラーが出ていないが意図通りの動作でない例はいくらでも作れるよ。
てか他の言語でもロックなりアトミックなオブジェクトなり作ることについてそんなに困ってない。 >>621
いくらでも作れるなら見てみたいのですが 作れるかどうかじゃなくて作らないとコンパイルエラーになるかどうかが問題 例えば、同じ型のArc領域二つ作って複数のスレッドが更新し合うプログラムで
特定の条件でうっかり逆の領域に書き込むように作ってしまったパターンみたいな
単純な仕様の間違いまでRustでコンパイルエラーにしてくれるのか?
人間っていうのは並列計算のモデルが複雑になると
把握しきれないからうっかりこういうことする率が上がるんだよ
だからどんなにRustがコンパイル時安全だろうと
人間がきちんと計算モデル把握できなきゃ結局バグはなくならない
で、人間が把握できるレベルまで設計を単純にできれば
CだろうがRustだろうが大して開発レベルに差はつかない
ライブラリと表現力の差がちょっとRustに分があるくらいで
積み上がったC資産の量でひっくり返るレベル >>625
そりゃコードの話はしてないからなあ
一生リーダブルコードでも読んでろ Rustでもこんな書きかたしたら駄目だよと言う
例も出せなきゃ単にRust理解してないのかと思われるよ >>627
だから書き方の話なんてしてねえよ設計の話してんだよ
言語以前の話なんだよ
代入する変数を間違えるレベルのミスはRustだって面倒みてくれないし、
そういうミスは複雑な並行をする設計にしたらいくらでも起こるって話になんでコードがいるんだよ あ、それともRustなら代入する先の変数を型が同じ別の変数と間違えるレベルのミスもカバーしてくれるとかそういう話ある?
それなら俺が悪かった 人間が把握できるレベルまで設計を単純にできれば開発レベルに差はつかない君 まあ簡単なことをわざわざ複雑にしたがる君はどこでもいるよね
意地でもバッチ使わない奴とかマジで害悪 >>628
>>629
Rustなら不注意な変数の扱いをコンパイラが
検出してくれる
という話をしてるときに設計ミスなら
何でも起こりうるとかドヤ顔されても
はぁそうすかーとしか返せんけど
何しにきたの? 仕様の間違いを言語が指摘してくれるなら何も書く必要ないな だから変数の不注意な取り扱いの話だろ?
変数の取り違えは不注意な取り扱いじゃないのか? 最初は安全でないケースはいくらでもあるとか言ってたのに、なんで話をそらすかね
レッテル貼るのが好きで論破ァしたいのは伝わってきた お前らまだやってるのか。
まあ、仕様が間違ってる部分でコンパイラ通らなかった事はある。
分岐やステートマシンが網羅性満たしてないとか。 >>612
Rustでコンパイル通るけど危険なコードの
例を出してくれれば議題になると思うのに残念だ rustの偉い人教えてください。
rustではポインタ演算できますか?
unsefeという指定をすればできる?
関数ないでしなきゃいけなくてオーバーヘッドになったりしないでしょうか。 Rustでポイント演算が必要な場面ってどんなとき? オーバーヘッドになるかは、自分でLLVMコードを比較しないと分からないと思うよ Rustのguiライブラリーでつかいやすいものありますか 中間コードを見てパフォーマンスを語るアホ
しってた?最適化はLLVMの仕事なんだよ? しってた?低レイヤの最適化はLLVMの仕事じゃないんだよ? rustのコードは最適化有効にするとllvmの時点でかなり消えてるから最適化の有無でrustcが吐いたllvm-irの比較できるよ。
>>643
用途とプラットフォームによるから要件指定して出直して。 >>646
比較はできても実際にオーバーヘッドになるかどうかは最終的な機械語を見るまで分からないよね >>643
OrbTKとAzulとDruid試してどれが良かったか俺に教えてくれ
どれもまだ作りかけって感じみたいだが >>648
無視できるから検査か実行時で言えば実行時。ただ、例外機構はpanicの実装がそれ。 >>641
c言語側で構造体の配列を共有メモリに置いたのをアクセスしたいです。
rustではこうしろ、でもいいので教えてください。 >>651
共有が可変ならコンパイラ通せないなそれ。raw pointer使いたいだけならcだけでやったほうが良い。 >>653
それはosの機能使ってるだけだから元々c使ってるならrust追加する意味がない。
よく読んでないけどservoのipc-channel見た感じ共有メモリ使ってないみたいだし、rust使うなら安全性優先してそうなるだろうね。
当然の帰結だけど潜在的に安全ではない方法で書かれたコードとrustは相性悪いよ。 >>652
ありがとうございます。🙇
一応サイズやオフセットの情報は貰えそうなんですけどね......。 >>646
>>649
すみません
環境はWindowsを想定しています >>649
azulはWYSIWYGじゃないmorphicにcssもどき付けてオブジェクト指向じゃなくてPFにした感じ。要はReact。 危険なオペレーションをunsafeで包んで安全なインターフェースを提供できるのがrustの良さなのに
潜在的に安全性ではない方法とrustの相性が悪いとはどういうことなのか >>658
インターフェイスを安全にしたところで潜在的に危険な部分は残るからでは? vlangのサイトが少し更新されて改めて日本でも多少話題になってるな
https://vlang.io/
これがすべて本当ならRustにとって大打撃だが 読んだけど詐欺だろ
こんなのできるわけない
どっかで非現実的なこと要求してきたりして実用できないポンコツだろう
PatreonやPayPalでのDonateを募っている。
サイトにサンプルコード書いてある以外以外誰もコンパイルしたことなければコンパイルしたコード動いてるとこ見たこともない >>663
話題になっているならスレ立ててこのスレから独立したまえ 比較するならもっとちゃんと比較してほしい。
載ってるサンプルソースじゃ単純過ぎて何で書いても大差ないし。
循環参照ありのコンテナ型とかCライブラリの安全なラッパーみたいな所有権とライフタイムがバリバリ出てくるやつが見てみたいが。 >>663
リリースは夏じゃんか、出てからでいいよ
金を集めてトンズラするための宣伝な気もする とりあえず否定から入ったり、
趣味で作ってるものに責任感求めたり
やな日本人 存在しないものは盲信できない。
キミ新興宗教に気を付けなね。 出てから考えればいいよ
標準ライブラリが400KBとかネタっぽいけど >>672
racer用にソースコードと、クロスコンパイル環境いっぱい落としたらそんくらいになりそうな気もするが、
最小限のターゲットで30Gは使わんと思う >>662
ありがとうございます。
rustの勉強本格的に始めたいと思います。 slackとかMozillaの息のかかった詐欺師の巣窟じゃん
むしろどこに行く理由があるのかわからん >>663
コンパイルしたやつに型の情報とか残ってないとホットリロードってできないですよね? rustやるにしても日本人と絡むのはやめとけ。
マジでバカしかいないから。 >>682
数Cがあった頃に高校で数Cが選択されずに数Cが範囲外の大学行った人が
何故かマやってたら必須要件満たせないんだな。
薬学系が何故かデスマやっててお薬貰ってたりしないだろうか。 ほんそれ
今時下限400の会社なんて人集まらないでしょ >>682
内容が逃げられた所の補充くさくてこえーわ。 dieselのreplace_into(UPSERTみたいな)で更新したい項目を絞り込みたい時ってどうすればいいですか? 誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 12053
https://you-can-program.hatenablog.jp while let Ok(t) = honyarara() {}
と書いた時にtがcannot infer typeと言われた場合どういうふうに型を指定すれば良いのでしょうか?
具体的にはこれの後半のデシリアライズの部分をループに書き換えたいのですが…
https://gist.github.com/rust-play/fa2d277652052fcbd6a72273a0cb70ce while let Ok(v) = a as Result<String, ()> { >>691
()の部分も指定したらいけました、ありがとうございました rustでreduxやろうとするとかなかなか面白い。案の定middleware周りで詰まってるが
これがうまく処理できれば結構いいんじゃないか。
https://github.com/rust-redux/rust-redux 本気で手を出したこと無いんだけど、そういうフレームワークをRustに持ってきて良い感じのabstractにできるの?
メモリとかリソースの確保のコードで見づらくなったりしない? また今年のsurveyでもrustが一番好かれている言語になったな
rust好きなんだけど正直ここまで好かれる理由がわからない C++に嫌気が差した潜在的なユーザーが多かったのでは? ブロックがその最後の値を持つ式だというのはいい。
そして、式にセミコロンを付けると文になるというのもわかる。
でもその両者を混ぜるとあんな残念な文法に。 c言語とどっちが性能高いの?
なんかRustの方が性能良いみたいなベンチがちょっとあるみたいだけど。 >>697
> でもその両者を混ぜるとあんな残念な文法に。
その残念な文法は具体的にどこをどうすれば良い文法になるの? こうする。
Bosque Programming Language
https://www.microsoft.com/en-us/research/project/bosque-programming-language/
> The Bosque programming language is designed for writing code that simple, obvious, and easy to reason about for both humans and machines.
https://github.com/Microsoft/BosqueLanguage 残念ってのはブロックの最後にセミコロンを付けちゃうと値を返せないってとこね。
>>697に書いたようにそれぞれ合理的な選択を組み合わせた結果だから解決策があるとは限らない。
ただ、式文はUnit型じゃなくて式の値を持つってことにするのは無理だったのかな。 >>695
イヤでも使わなきゃならないのが優れた言語
嫌な奴はさっさと逃げ出して残った少数にもてはやされるのが(ru
>>698
ベンチの取り方も知らないみじく者にもてはやされるのが(ru >>701
代入が値を返す場合、代入された値が戻り値へとmoveされてしまうから問題がありそう 代入式の値はUnitでいいんじゃなかろうか。もともとCのような代入の連鎖はできないわけだし。 https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=765849a4e776e00b0c614fc941b02ecf
Defaultを実装してない構造体のフィールドのうちDefaultを実装してるフィールドだけまとめてdefault()で初期化するような記述方法は無いでしょうか?
イメージとしては
let s = S { nd: NonDefault::new( "foo" ), u: Default::default(), i: Default::default() } ;
の部分を
let s = S { nd: NonDefault::new( "foo" ), _: Default::default() } ;
のような形で書けないでしょうか >>706
マニュアルに
SomeOptions { foo: 42, ..Default::default() }; >>707
ありがとうございます、ただそれだとSomeOptionsがDefaultを実装している場合の記法ですよね?
(実際試してもthe trait bound `SomeOptions: std::default::Default` is not satisfiedとなります)
質問としてはSomeOptions自体はDefaultを実装していないけど、そのフィールドのうちDefaultを実装している型の値はまとめてdefault()で初期化したいってことなんですが… そういうときは初期化子直接使うんじゃなくてコンストラクタ定義すんのよ κeenさんの所でもまだ出てないのに売れてるらしいと書かれてたけどどういう事なんアレ? 都内の大型書店には結構出てるし電子版は連休前が発売日だったはず 結局ここまでまともなソフトが出ないってのはそういうことなんだな。 メインでrust使ってる企業あったら入りたいもんだけど、実際使ってる企業あるの?
モダンな言語だとせいぜいGoとかelixirじゃない? 世界コンピュータ将棋選手権に出た強豪ソフトがRust製で
公開予定 人間からすれば強豪でも、予選落ちで強豪ソフトと呼ぶのは違う気もする Rustの本どんなもんかとアマゾンで見てみたら、
中華業者の星5レビューばっかで色々と察した
そもそもの話の言語自体が胡散臭いのも納得 ライフタイム引数のクソさはもうどうにもならんな。
変な省略ルールとかつけて逆に分かりづらくなるとか本末転倒もいいとこだ。 省略ルールのありなしに関わらず分かりづらいだけでは https://ja.wikipedia.org/wiki/Rust_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E)
>実行時速度性能はC言語と同等程度である[8]。
これマジ? こんな記事を見つけた
>Rustのコードを用いたこのためのテストの平均はCコードの実行したものの3.040倍と同じくらいだ。
>この関数により、我々はRustが平均的に2.036倍Cよりも遅いことを知った。
やはりCの方が速いな。省メモリという点でもCが一番だし >Rustが事実上Cよりも遅いままで終わってしまったという事実は、より落胆させられた。
>また、全体を通してRust言語は、
この手の高水準な完成されたシステムを作る手助けをすること、
そしてこの領域において少量の変更で効果的にCを置き換えることができることを示すことができた。
現状のRustはCを置き換えれないけど、
将来的な改善まで含めればできるはずだと主張してるな。。 Cと同等はさすがに無理にしても、もう少しCに迫る性能が出ないと、C/C++から脱出したい人の受け皿にはなれないんじゃないか? あるいはCの2〜3倍遅い程度なら許容範囲内ということで割り切るしかないんだろうか。 >>732
nimのllvm版 nlvm はどうよ? >>724
ライフタイムとムーブについてはそこまで複雑な概念ではないよ。
ライフタイムに対するシンタックスがヘンテコなだけで。 RustでLinuxカーネルを書き直す時代はこなさそうだな >>726,727
メモリを自分で面倒見る分とセキュリティチェック甘い分早いだけだからcでリージョン使ってメモリ管理して配列の境界チェックとかもすれば似たようなもんだ。
rustのpanicはきれいに落とすぞ。ただ、ランタイムデカイ分とrust用のメタデータ含む分でフットプリントはcの方がいいと思う。
>>734
リージョン推論間違えるか効率悪い位ならリージョン指定させてほしい時はある。 >>735
新しいOS作れば?
なんだったらAndroidみたいにLinuxの上に構築。 それをRustでやってもCで書かれたOSを上回れないという話でしょ https://discourse.redox-os.org/t/redox-performance/966
まだ初期段階だから比較しないで、みたいな事言ってる
最終段階までいってもCを超えると思えないんだが
しかもLinuxは組み込みでも使われてるがそれはCが省メモリだからで
Rustが勝てる見込みは無いと思うんだがなあ 原理的には負ける理由もないと思うけどな。
Cは基本ノーチェックで脆弱性が見つかったらチェック入れるのに対して
Rustはいろいろチェック入ってるのをunsafeで外してパフォーマンス上げていくから
最終的に同じところに収束する気がする。
まぁ途中段階とか未知の脆弱性を放置する前提なら勝てないんだけど。 中華ステマ企業が今押せと言われてるイチオシの言語Rust使ってるやつおるん? そのサイトいっつも思うんだけどベンチマークの並べ方恣意的じゃない?
vs Cではmandelbrotが下の方にあるけど
vs Javaでは上から2番目
Rustが勝利している項目では太字だけど
Cが勝利している項目では太字にならない
vs C++では、5項目でRust勝利、5項目でC++勝利で互角なのに、
Rustだけ太字でしかもRustが勝利したベンチマークから並べられてる。
俺はそのサイト少しも信用してない さらに言えば言語によって使用されるベンチマークがいつも違う。
勝たせたい言語のためにベンチマークを選択している可能性がある。
新手のマーケティングじゃないの? 恣意的の意味するところがわからんけど
C++からだとRustに勝ったベンチマークだけ太字
C++が勝利したベンチマークから並べられるよ
使用されるベンチマーク云々はちょっとわからん >>742
Amazon Intel Microsoft Dropbox Nokia Fastly DiscordはGitHubでみた ソース公開されて比較的新しいコンパイラを使って測定されるbenchmarksgameは信頼ならなくて
2016年に書かれた中国語のブログにあったフィボナッチ数列のベンチマーク(ソース非公開)の方が冷静? rust推す人もステマする暇があったらrust dockerでも実装すりゃいいのに。
性能と安全性でいえばgoの実装以上のものができるんでしょ? 中華ステマ企業がって話があったから中国語圏でどうなのかなと思って調べただけ
あとそのサイトを信じるなら、5項目でRust勝利、4項目でC勝利で、
RustがCより速いという事になる。
その結論は信じがたい。 モジラのステマと買収から中国の陰謀まで進化したのか rustで書かれたコンテナエンジンはオラクルが作ってたろ
goのgcによるボトルネックがひどすぎるとかで
速度のベンチマークなんてほとんど意味ないだろ
生産性のがはるかに大切 n-bodyのソースとか見ればわかると思うけど、メモリレイアウトとかSIMDとかほぼCと同等まで詰めてあるから、Cに勝っても何の不思議もない。
実質gccとllvmの最適化対決って感じでは。
Arena使って素朴に書かれたbinary-treesが勝ってるのは結構すごいと思う。 そりゃ互換実装なんてよっぽどメリットがないと使われないでしょ。
railcarは完全互換ですらなかったし。
firecrackerとかlucetみたいな独自路線の方がまだ見込みあるんじゃない? >>757
オーバーヘッドもなくセキュリティー的にも安定な実装というメリットがある
はず。 GitHub’s Top 100 Most Valuable Repositories Out of 96 Million
ttps://hackernoon.com/githubs-top-100-most-valuable-repositories-out-of-96-million-bb48caa9eb0b
rust 5位だてよ ランキングもベンチマークもいくらでも恣意的に操作できる
実際に製品としてどんくらい世に出たかが全てだけど
Rustはどこの企業も口を揃えて「内部実装で使ってます」って言うだけで
動いてるコードを見たことがない >>763
企業で使ってもクローズドソースならそもそも何使っても見れないんじゃない? 全く使う気にならないツールばっかりってのがすげーな。 プロダクトがあるか無いかより、「xxxで作ってたものをrustで作り直したよ!」って話が多いのが気になる
既存の作り直しよりも新規性のある何かが出来て、それを皆が使いたくなって言語が広まるってのが普通だと思ってる
(goならdockerとか)
rustでそういうのがまだ見えないのはちょっと嫌な感じはしてる もともとC++は辛いので作り直せる言語を作ろう
だからしょうがないんじゃない C++はまだ進化中(複雑化中)だし、C++使ってる分野では特に移行する必要がないというか Rustは学習を終えたとしてC++より開発効率良いの? >>768
重箱の隅で申し訳ないが、Goなのはk8sだと思う
Rustでキラーアプリ出ないのはある意味当然で
そういうものって未完成でもとりあえずぶち上げてコンセプト見せないと流行らないんだが
Rustって真逆で完璧に作らないと動かない言語だから
キラーアプリの作成とそもそも相性が悪い つまりrustで作られたものは完全無欠ってこと?
そんなばかな
そもそもなんでメジャーな採用事例を気にする必要があるの?
自分が作ってるプロダクトがrustと相性がよければ使えばいいだけじゃん キラーアプリってあれか
RubyがRailsで人気爆発あるいは
ディープラーニングやるならPython
みたいな話期待してるのか? C++にはキラーアプリがないと思うけどそれでいいと思う そもそもキラーアプリが言語の普及に影響したのってRailsくらいだと思うけど。
別にdockerやk8sのユーザがgoで実装しなければならないってことはないでしょ。 >>771
rustで学習を終えてc++で作るのが一番効率が良い。
つまり学習用と割り切ればかなり意味のある言語ではある。 C++で痛い目にあってからRust覚えた後にC++の最新verに戻るのが最適解
じゃないとRustの諸々の安全装置がなぜあるか理解し難く面倒臭いだけと思われてしまう C++に戻るつもりが戻れなくなってしまったな。
最新ならC++の言語機能には特に不満はないけど、標準のテスト・ビルドツール・パッケージマネージャがないのが辛すぎる。
戻った人たちはその辺どうしてるんだろう…。 いろんなOSSを触ってるとプロジェクト毎に独自の流儀で、それぞれにいちいち合わせるのが面倒だし、
新規プロジェクトでも何を採用するかで悩む。
別に標準化とかされなくてもデファクトスタンダードが一つに決まってれば十分なんだけど。 C++とくらべりゃRustのほうがスッキリしてるやろ
Cのほうがもっとスッキリしてるけど > 標準のテスト・ビルドツール・パッケージマネージャ
最近のプログラミング言語はそれぞれがこのシステム作るよな
言語を超えた協調もなく >>786
そりゃ、ライブラリの名前だけでも共用すればいいのに、と思いますがそれもできていないし… Ruby のBundler で、各プロジェクト毎に、異なる依存ライブラリを管理するのが便利だから。
それで、Node.js のnpm, yarn も同じように作った
他にも、Vagrant, Chef, Homebrew など、バージョン管理はRuby で作られる vagrantもchefもrubyで作られてるからだしょ?
そもそも言語じゃないし
何が言いたいのかさっぱり分からん 「俺のやりやすいやり方に周りは合わせろ」ってことだろ。よくあるクソ意見だよ。 Cargoは近年稀に見るクソパッケージ管理ツールだろ
これなら散々クソクソ言われてきたけど
最近pipenv出してきたPythonの方がマシまである ビルド速度が遅いビルドツールの代表のsbtより遅いのがクソ
crates.ioに強依存しててオフラインビルドができないのがクソ
gitに強依存しててアーカイブ形式で配布できないのがクソ
そもそもcrates.ioの運営がクソ
あといくつ欲しい? ビルド速度が遅いのをパッケージマネージャのせいだと、言語の違うものと比べて言われてもなんともな
crates.io関連はこれ
https://github.com/rust-lang/cargo/issues/5655#issuecomment-488347426
https://github.com/rust-lang/cargo/issues/6589
アーカイブ形式は無理っぽい
https://github.com/rust-lang/cargo/issues/1139#issuecomment-69398250
>The ABI for a library is not stable between compilations, even when theoretical ABI-compatible modifications are made.
あといくつ? gitへの依存ってあったっけ?
crates.ioからはソースアーカイブDLだから
gitプロトコルは使ってないと思うけど。 >>800
ビルド前のスクリプト実行は出来るのにビルド後のスクリプト実行が出来ない
も追加しといて 勉強中なんだけど、rustってそんなにビルド遅いの? >>804
「ビルドする度にコーヒーブレイク」と揶揄される某言語より遅い >>805
いやあれよりは速いよ
まあかなり遅い部類に入るのは認めるが… 遅さではscalaが有名かな
まぁrustが遅いのは遅い 前実測したけどscalaより遅かったぞ?
依存ライブラリ数の差の可能性はあるが scalaとビルド速度競ってる時点でお察しのクソ言語 まあ仕事で使ってなきゃビルド時間なんか気にならんもんな。
遊びでやってる層にはコンパイル時になんでもやるってのは受けがいいんだろ。 ていうか何をビルドして計ってるんだよ…
一切出てこないまま話は進んでるのか? 折角なのでHelloWorldのコンパイル速度比較してみた。
まぁ条件は適当なので参考程度だが。
毎回ビルドキャッシュ削除した状態からの10回平均。
C: 41.9ms
C++: 150.9ms
go: 211.4ms
D: 307.3ms
Rust: 320.1ms
Java: 346.5ms
Erlang: 1005ms
Haskell: 1106ms
C#: 3000ms
Scala: 6712ms
こうしてみるとCは異常に速いけど、Rustはまぁ普通と言ってもいいかもね。 ビルドが遅いのはコンパイラの遅さだから根本的には別問題。
cargoがロクに並列ビルドできないのもこっち側。
>>800,801
- 不要な条件付きの依存関係が要求されてビルド/テストできない
- rustup wrapperが遅すぎて色々タイムアウトする
が抜けてる。issue乱立しすぎて最新のissueがどれか分からんからリンクは貼らん。
無駄にissue分けすぎて他にも細かいのが色々あるけど、結局は中央リポジトリに依存しすぎ、オフラインモードが使い物にならない、
パッケージマネージャとビルドツール融合してどっちとしても使い物にならないに集約される。
>>804
intellij rustがon the fly analyze実装したから設定から有効にして試せばいいよ。
サンプルプロジェクト程度じゃ影響ないから実践に近いプロジェクトで試さないと分からないけど。 しかし実際遅さが気になるプロジェクトってどんなサイズ?
普段開発してるソース1万行で依存クレート100個くらいの規模だと気になったことがないんだけど。
もちろんクリーンな状態からの初回ビルドはそれなりにかかるけど、ソース書いてるときに依存クレートの再ビルドってほぼ発生しないし。 >>818
ないない
競プロはメモリリークしてようがコーナーケースでバッファオーバーフローしようが
とにかく規定の入力に対して速く答えを返すものを
エラーハンドリングとか考えず手早く実装するのが正義
Rustと一番相性が悪い分野だろ >>815
端的に集約するとそれだよな
未だにこれが「他の言語のパッケージマネージャーの良いところを集めて地雷を回避した理想的なパッケージマネージャー」とか言ってるやつは
それこそ金掴まされてるとしか思えんくらいにクソ 困るのは分かったけどなんで困るの?
2年くらい仕事で使ってるけどあーカーゴって便利だなぁとしか思ってなかったわ それならRustの歌でも作って武道館で歌うくらいやるけどなあ なんでMozillaは俺には金掴ませてくれないの? なんかもうちょっと具体的に
こういうことやると苦労する破綻するという例が欲しいな
他の言語やツールとの同等のことやろうとした比較があるとなお良し 困る人は是非積極的にcargoにissueたてるなりpull req送って欲しい
人的リソースが足りないのよ Mozillaに金掴まされてるは例のキチの常套句だったなそういえば
>>826
まずcrates.ioそのものは、使う側じゃなくてライブラリ公開する側になったらクソだとわかる
こればっかりは使って体験してくれとしか言えん
ビルドの遅さは、例えばDockerみたいなコンテナの相性がよろしくない
crates.ioに強依存してるから、aptでいうところのsquidみたいなことができない
これらの問題はカジュアルユースなら問題にはならんだろうが、プロユースには耐えんのよ aptでいうsquid?ミラーがほしいってこと?
俺の周りのプロはもうそんなことやってないけど。。。
multi stage buildでもしたらいいんじゃないの それはプロユースに耐えんのではなくて、そういう職場もあるってだけの話では?
crates.ioは複数ライブラリ公開しててもクソさが分からんしなぁ。
逆にこのパッケージリポジトリは素晴らしい、とかあるの? >>828
ビルドが遅いという以外何が問題と言ってるのかわからん それで十分だろ。
それがわからんやつはboostマンセーして人に迷惑かけてもなんとも思ってない馬鹿と同列にしか思わん。 出来上がったバイナリが速ければ問題ないんじゃない? rustを良い言語だと評価してるやつはrustとより酷い言語しか使ったことないんだろうよ、VBAとか 最初から期待している点は2つ
1つはHaskellで実証されてる、型システムが豊かであることの安全性と利便性をC並みに低レベルな世界に持ち込んで組み込み業界に1石を投じること
もう一つはオブジェクト指向を言語仕様に取り込まなくてもオブジェクト指向でやりたいことの大部分は実現可能だと証明して、OOPパラダイムを衰退させること とあるツールをcargoでビルドしたら、同じcrateが重複してバージョン違いで使われてて驚いた
そんなのアリなんか
Compiling env_logger v0.5.13
Compiling env_logger v0.6.1 a crateとb crateがそれぞれ違うバージョンに依存してたらそうなるだろう
アリというかそうじゃなきゃ困るだろう
そうじゃない言語もあるけど hogehoge-sys みたいな外部のライブラリに依存するcrateだと異バージョン混在できなくてつらい
.soを実行時にリンクする都合上仕方ないのだけど 絶対に
絶対に
所有権の移動のほうに記号がつくべきだった >>836
それ以外の部分がクソ過ぎてやっぱダメだわってなってるのが今
以前はこのスレにRustへの苦言かきこんだらボロクソに言われたもんだが
今では俺以外にもRustはクソって声が増えてる。良い傾向 まあ使ってみないと本当の意味でダメさ実感できないからな。
実際にさわってみたやつが増えて夢から醒めたんだろw これ以上バカを現場に増やさないためにプログラム教育にはビルドって科目も入れるべきだな。 お前にとってクソで大嫌いなのはわかったから冷静になれよ >>840
それは無理があるんじゃないか?
&で借用が妥当だと思うけど
&は借用の記号と同時に型の情報としての意味も有るはずだから
その点で問題が起きると思うが… 例えば移動に記号をつけようとすると
T型と&mut T型の変数を移動する際はそれに全部記号を付ける羽目になるぞ
それでも良いのか?
ちなみに&T型は移動ではなくコピーなので除外したがコピーであって借用ではない
>>840はコピーはどうすべきだと思っているが知らないが
コピーにも記号を付けろと言うならさらに面倒なことになる
本当にそれでも良いのか? '=' の現状のrustの意味の統一を考えれば現状の仕様が妥当だわな。 まだ他にも問題はあるぞ
例えば移動をmoveで借用を記号無しにすると
let a = 1_i32;
でaはi32型でなく&i32型になる。なぜなら記号無しは借用だから。
aがi32型になるためには
let a = move 1_i32;
と書かなければならない
さらに言うと
let a = move 1_i32;
let b = a;
let c = b;
でaはi32型、bは&i32型、cは&&i32型となるわけだ
俺はそんなヤバイ言語は使いたくないぞ この際に言いたくなったから言わせてもらうけど
時々「俺の方が良い言語作れる」とか言ってるヤツがいて
それに対する反論に「じゃあコンパイラ作ってみろよ」とか返してるヤツいるけど
そもそもコンパイラを作る実力が有るか無いか以前に
言語をデザインすることの難しさを分かってないヤツが多すぎて
コンパイラを作る段階にも至っていないっと思うわけよ 俺は言語を作るセンスないし他のやつもなさそうだしお前にもなさそうだからこの話題はやめとこな
不毛だからな >>850
記号なし=はコピーで統一したらよい
C++はやってるじゃん >>853
ポインタの基本をコピーじゃなくてムーブにしたいからムーブの方を記法的に容易にしたんだし、auto_ptrのセマンティクスの非統一による悲劇を避ける為にムーブに統一したんだよ?
議論の順番が滅茶苦茶だぁ メモリ以外のリソースはコピーできないものが大半じゃね? 変数がどの範囲で利用可能なのかぱっと見わからんのが酷すぎる >>856
コピーできないようなまとまったオブジェクトをほいほい変数移さないだろ >>853
取り敢えず借用を記号無しにするのは無理であることは納得してくれたの?
そして移動はどうするの?rustだと移動も結構しょっちゅう使うんだけど…
例えばBox型とかString型とかVec型とか&mut T型とか…
移動もコピーもどちらも=なのが判りづらいってのは一理有るんだけど、
それらの移動に全てmove等の記号をつけていくのはあまりにも面倒だと思うよ >>860
所有権を手放すときに記号つく
>>859
そっちを&にして
右辺値が無名で宙ぶらりんのときはつけないでいいことにしたら >>861
そっちってどっち?移動を&にするの?じゃあ借用はどうするのよ?
さっぱり言ってる意味が分からん
てか最初の質問に答えてくれないかな?納得したの?してないの? >>862
してない。俺も言ってることよくわからん >>863
えぇ…
じゃあ君は借用は記号無し=がいいってこと?
でも君さっき記号無し=はコピーが良いって言ったよね? borrowこそ新しい概念なんだからそれに記号でもつけりゃよかったんだ 変にc++のシンタックスと似るようにしたのは良くないかもな。
moveが基本だったり引数の意味がだいぶ違うわけだから。 >>866
だからそのborrow(借用)に&と'a(ライフタイム)という記号が付いてんだろうが
頭大丈夫か? 少なくとも所有権の移動は右辺に影響するんだからそっちにも記号がつくべきだった
あと見た目即所有権帰ってくるやつまで&で書くから見づらい
誰に貸していつ帰ってくるのかわかんねー 2年rust書いてるけど君らのいう分かりにくい、が分らん
フューチャーが分かりにくい、なら抱き合って同意するけど >>871
分かる。futureはマジで難しいよね
Pin/Unpinまでは辛うじて理解できたんやが、Wakerの方が分からん。
誰かRawWakerVTableの解説してくれ…
でもfutureの難しさはasync/awaitが導入されればそれに隠蔽されるから
利用するだけのユーザーならあと少しの辛抱や 継続的に数年使ってる人は新機能が出たら新機能だけ覚えればいいんだろうけど
初めて触る人はその累積してきた機能全部を掌握するのは無理 rustをシステム系じゃないエンジニア(C++の仕事してない)が使うメリットって何かある? 廃止された機能や推奨されない機能も覚えておく必要がある
特にC++で言えばunicodeの変換(std::codecvt**)が超糞 「誰も使ってなかった」ことも含めて
その累積してきた機能全部(結局全部になるだろうな)を掌握する必要がある訳だろ なるほど素晴らしい観点っすね、実行不能という点に目をつぶれば。 でぇじょうぶだ
[[deprecated]]
がある それついたの思いっきりつかってるwww
昔のが商売人の都合で切られてるんだもん
つかうよ rustでIDE補完が甘いのは誰も気にしてないんか?
そもそもみんなIDE使ってないんか? カドカワから月末に訳本の
プログラミング言語Rust 公式ガイドが出るけど2018対応じゃないよね?
Rust本が増えてきたのは嬉しい >>888
バカが飛び付いて社内に導入しようとするの潰すの
毎回労力がかかってしゃーないからやめて欲しいんだけどな
クソ言語の本出すの 無能なアンチがいるということは、安心して使っていいってことだな >>888
TRPLの翻訳だと思うけど
TRPL本家は2018対応済みで、webで公開されてる日本語訳は未対応。
本家に追従して対応した可能性もあるかと。 そりゃクソコード残して辞めてくことだろ。
まじで死ねと思うわ。 それは言語の所為じゃないだろ
レビューしないの?
しないにしても同じクソでもJavaやC++よりマシだと思うんだが 言語関係ねーじゃんメンテする能力がないんだろ
諦めてgoで作り直せ >>895
ググったらTRPLでした
ただ紙の原著は2018年発売でRust 2018未対応
紙の翻訳なのか最新のWebの翻訳なのかは不明 borrow checker通せない人にとってはすべてのコードが読めない糞コードなのだろう >>897
社内でそいつしか使わないから当然レビューも不能
上の人間も「いいじゃんやってみれば」で話にならない
結果まともにレビュー通ってないクソが本番に出てトラブル
作ったやつは雲隠れ
って流れを見たことあるよ。Rustじゃないけど もちろん言語のせいではないのだが
そういう輩は実績作りのためだけに新しくてより複雑なクソルールの多い言語を選ぶ傾向にある ボローチェッカに苦しめられてる人は
なにか他から移植をしようとでもしてるのかな?
ゼロからかくぶんにはボローチェッカなんて
ただただすがすがしいだけと思うけど
チェックご苦労さんですってもんだけど >>901
そういう体制だとCでもJavaでも言語に関係なく
色々問題起きてるだろ 未知の言語を読むストレスは理解できるけど
一件正しそうなぶっ壊れたロジックを探し当てる方がはるかに辛い
Rustなら完璧だなんて思わないけど同じ条件で雲隠れされるならJavaやCよりはるかにマシ 使いたいだけのバカに限ってRefCell使いまくりとかボローチェックなんか
関係ねーわなクソコード残していくわけだがな。 結局プンプンの人達は何か言いたいん?
初心者が使ったら他言語より酷いことになるって話?
作り逃げされた時に他言語よりメンテきついって話?
それともrust関係ない話? >>907
結局どの言語だろうとワナビのキッズが使ってレビューも不完全なら悲惨なことになるし
Rustはそういうワナビホイホイなところがある言語で
キッズを拡散すんのは勘弁してくれってことよ
新しいものの宿命みたいなとこはある Rustを使いたいって奴はボローチェッカ最高勢だろ
筋の通らない話だ ついにMSもmozillaのステマの被害者になったのか FireFoxでプライベートブラウジングモードにしたら
指定してダウンロードしたページまでブラウザ終了時に消しやがる
しかもfilesはそのままでトップのhtmlだけ
きっとRustの融通の利かなさのせいでこんな仕様なんだ
不条理すぎる >>913
Rust導入してからアドオンの互換性切るわバグ増えるわシェア1割切るわで
いいところのない火狐 dbっていうか、
OracleとかSqlserverに読み書きするような
アプリはあまり現実的でない? オラクルを使う常駐物のアプリを
一個書いたんだけど
プロプラなdb向けだと
crateの充実度的な意味で
大変だったし、保守してけるか
ちょっと不安だったので。 プログラム板にキチガイ降臨中!botに一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
https://mevius.5ch.net/test/read.cgi/tech/1559872586/
142 名前:a4 ◆700L1Efzuv 投稿日:2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な 俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか?
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人なんて復活ねーから。 cargoの自動ダウンロード機能を使わないワークフローのチュートリアルが欲しい
足りないコードを示してくれるのは助かるけど知らないうちにGPLな奴が混じっていたなんて事態は避けたい パッケージで
依存するパッケージたちの実行可能な環境やライセンスやインストールサイズをパッケージインストール前に分かったりしない? >>923
実行環境以外はcrates.ioのAPIから取れるみたいだから可能は可能。
ツールになってるものはぱっとは見つからなかったけど
jsonパースしながら依存関係辿るだけだし適当に作ればいいのでは。 考えてみれば当たり前なんだがcargoはrust周辺しか面倒を見てくれない。他に依存するライブラリがあっても関与しない
つまりビルドは出来るが実行出来ないということが起きる。コード次第ではpanicして何が足りないかすら出力されない
ドキュメントに何を用意すべきなのかちゃんと書いていないcrateも少なからずあって不完全なメッセージ片手に探し回る羽目になる Firefoxに重大なセキュリティ欠陥
Rust安全神話崩壊 https://www.itmedia.co.jp/news/articles/1906/19/news060.html
2019年06月19日 07時19分 公開
Firefoxに危険度最高の脆弱性、既に攻撃を確認
Array.popの問題により、JavaScriptを操作する際に脆弱性が発生する可能性がある
これ本当にRustのせいじゃないの? https://developer.mozilla.org/ja/docs/Mozilla/Projects/SpiderMonkey
SpiderMonkey は 、C / C++ で書かれた JavaScript エンジンです。Firefoxを含む、Mozillaの複数の製品で使用されており、MPL2 ライセンスの下で利用できます。 GPL or LGPLコードに依存せずにSVGをレンダリングできるライブラリってないかな?
resvgが使えるかと思ったら
>librsvg is heavily tied to GNOME, which makes it painful to distribute outside the Linux ecosystem
とか書いてあるくせにgdkやglibを要求してくるようだ >>931
リポジトリ上で見る限り、今回のバグで修正されたのはC++のコードみたいだけど。 おい!なんだかバズってるfacebookのlibraのmoveはrustで書かれてるらしいぞ!! Rustが脆弱性の原因になると宣伝がパーになるから
あっちこっちでC++のせいにする小細工が行われております え?MozillaがRustの宣伝の為にFirefoxに脆弱性を!? さっぱりわからん
範囲チェックがどうとかって書いてあるけど
バッファオーバーフロー起こしてたってこと?
まんまC++のせいじゃないの? バグフィックスってかいてあるけどこれが脆弱性修正?
なんがんあんだかわからん >>939
Rustなら安全に書けるとか言っておいてしっかり脆弱性作り込んだから
これはRustではなくC++のせいだからと火消しに回ってるの
日本語わかる? >>944
だよな。今回は完全に"Rust"が脆弱性作ったわ…
>>942,943
小細工をやめろ ElementAccessHasExtraIndexedProperty
凄まじく怪しげな物に変更されとるな。 Chromiumのソースもそんなん(長い関数クラス名とか)だけど どういう経緯で何が起こって開発元は原因は何だとしてるのか
ちゃんと説明しろ >>953
「セキュリティに関わるのでお答えできません。知りたきゃソース見ろ」
だそうです C++はRustだった
今すぐモジラのステマ言語C++を使うのをやめろ それでもFireFoxがいい
軽さとセキュリティの誠実さ
ブックマーク回りはころころ変わってひどいけど GoogleやMicrosoftのWebブラウザは十数枚開いただけでメモリ消費がやばいことになる
Mozillaならそんなことない 実践Rustって、電子書籍版を8インチタブレット(iPad mini)でちゃんと読める大きさ?
前に出たRust本は余白カット表示してギリギリって感じだった >>959
逆だろ
火狐はタブ10個も開けばカクツキ起きるしそれからほどなくしてフリーズ
Chromeはもちろんクソクソ言われてるEdgeすらも
動作の安定面では火狐なんぞには負けん
ちなWin10 >>960
本のステップで分ける説明より、2→4→8→... と増えていく図を見たほうが分かりやすいと思った
ttps://www.cs.rutgers.edu/~venugopa/parallel_summer2012/bitonic_overview.html >>964
FireFoxで10タブ開いてみたけどなんも変わらんよ? >>966
20~30くらい同時に開くとビジーになるからビジーとフリーズの区別がついてないんだと思う。 IEやChromeで100Tabとか開いたらメモリを食いつぶしてまとも動かないよ その分今でもメモリ周りでバギーってのは笑わせますね。 Firefoxなら100タブくらい大丈夫だよ。IE、Chromiumでそんな事したら他の作業が出来なくなってしまうけど
実際に比べた上でFirefoxを使っている。開発やっていると開くページがどんどん増える Rust→IR→Cが実用出来るようになるのはいつだ
LLVMが対応していないアーキテクチャでRustを使いたいねん
それともトランスパイラを作った方が早いかなぁ 524 デフォルトの名無しさん sage 2019/07/02(火) 14:38:03.95 ID:ep8keXko
言語機能の複雑さという代償はあったが
GC無しでリージョン推論を実現したのがRust
記述性のためGCを入れつつも遅延を最小にすべく
GCの性能向上に努めたのがGO
一方vlangの公式によると
https://vlang.io/
> V manages memory at compilation time (like Rust)
https://vlang.io/compare
> - No GC
> That's why the language is so simple
・Rustのようにコンパイル時にメモリ管理される
・Goのように書けるがGC不要
・それでいてRustのような複雑さは無い
・という予定(まだ未実装)
本当にこの通り実現するなら
GoとRustの設計者達にマウント取れるレベル
526 デフォルトの名無しさん sage 2019/07/02(火) 14:59:25.78 ID:ep8keXko
ちなみに自動メモリ管理が未実装なので、以下の記事によると
hello worldやvlangコンパイラ自体もメモリリークしているとのこと
https://christine.website/blog/v-vaporware-2019-06-23
> The compiler itself also leaks memory
531 デフォルトの名無しさん 2019/07/02(火) 18:22:15.31 ID:NqAwj9wC
>>526
www
532 デフォルトの名無しさん sage 2019/07/02(火) 18:59:24.21 ID:8dHuftNb
>>526
あっ・・・(察し) >>973
rust2cトランスレータはとっくの昔にあるしとっくの昔にどれも開発止まってる
rust->llvm->c->任意のコンパイラで出来るじゃん。 >>974
生ポインタ使えるの?新しすぎるせいからしい情報が見つからんかった
>>977
今出てくるCバックエンドの話って関数レベルで使えれば御の字みたいなのばっかりに見える
プロジェクトレベルで実用に耐えるワークフローがあるなら詳細を知りたい >>608
横田さん潜伏中に生魚あたってハイタのかな?排他だけに。
なかなかRockだね!Lockだけに。 >>978
>プロジェクトレベルで実用に耐えるワークフローがあるなら詳細を知りたい
rustでは見たこと無いね。操作的意味論に基づいて命令列とグルーコードに変換するものばかり。
というかそれ以外は難しいと思う。 >>980
やっぱりそうか、残念。LLVMのバックエンドは作れる気がしないしトランスパイラの方が望みがあるけど
それでもELFのパーサとジェネレータ、変換元機械語のデコーダは最低必要だな
こういうのって処理系やエミュレータ等でしばしば使われるけど、単体のライブラリとなるとx86とかの
有名なアーキテクチャですらなかなかないんだよな Cと比べたらノウハウ少ないかもしれんけど、LLVMバックエンド作るのってそんなに面倒なの?
LLVM->Cって抽象度上げる方向だし参考になるものがもっと少ない気がする。ecmascriptenくらいじゃない? >>982
Rust to Cは自分の手に負えそうにないので他力本願です
ググって出てくる情報を見る限り最適化コンパイラを自作できるくらいの理解がないとLLVMの理解とバックエンドの開発は難しそうに感じます
各言語やアセンブラを使える程度の理解では歯が立ちそうにないです
なので機械語 to 機械語(もしくはアセンブラ to アセンブラ)の方がまだ望みがあるかなと バイナリ変換ってかなり壮大な研究テーマでは…。
どうしてもLLVMに触れたくないならLLVM-IR to アセンブリを自作するほうがまだましかな。
結局素直に勉強してLLVMバックエンド作るのが一番早いと思うけど。 >>984
LLVM IRってレジスタ数が青天井ですしstd付きとはいえHello worldですら十数本使っているようです
何処まで増えるのか判りませんがレジスタを数百本使うIRとか吐かれたら何とかなる気がしません
勉強すると言ってもどこから手を付ければいいのか判らない状態ですし最近は相対的にローレベルな
情報自体が減少しています。運良く自分が理解できる資料や教材に巡り会えない限り難しそうです オレオレ → LLVM はレジスタ何本あってもOK
LLVM → CPUネイティブ は良きに計らえ
オレらの仕事は前者
気にすんな そこまで部分の最適化って自分でやらにゃならんし
計算と制約を記述するのに適したその手前までの中間言語ってないじゃろか
Lispとかか バイナリ変換ってダブルバッファリング的な事しないと整合性とれねー気がした。 >>988
レジスタが1〜2本足りないくらいなら使用頻度の低いのからメモリに逃がす方法で何とかなりそうだけど
全然足りない場合全く別の方法が必要そうですが思いつかないです。自分にとっては高度な問題です
Rustと言うかLLVMが吐けてターゲットとの相性が良さそうなアーキテクチャを選ぶ必要があるけどこれも難問かな
IA32/AMD64はメジャーだけど建て増ししすぎでアドレッシングモードとかスーパーカオスだし無駄に命令も多い
ARM7あたりが無難だろうか。分岐処理が特徴的なようだけどRISCの割にレジスタが少なめなのも好条件か
純RISC系は命令セットが単純だけどレジスタが多くてLLVM IRと同じ問題が出てきそう キューイングしてガンガン処理して節目でプログラムカウンタを1増やす。とか理想を語る俺。 2つのvectorの同じインデックスの要素を比較したいときってどうかくのがスマートなんでしょう MISPならツールチェイン揃ってるからPS系ハードで動かないことはない コンパイラチェッカーについて簡潔にまとまっている資料とかないんだろうか
数ヶ月ぶりに触ったらすっかり記憶の彼方だわ RustってVisual Studio Codeとかでビルドしたりインテリセンスが利いたりするようにならんの このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 352日 16時間 14分 50秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。