rustって難しいの？
使いにくい言語って結局クソじゃね？
有難がってるのって信者だけ？
>>3
厳しい先生だと思う。
でもそれは俺らのためでもあって、rust先生の審査を通ったプログラムは安全と言える。
ただ先生も普段が厳しすぎるとは思ってるので、わかってる奴ら用にunsafeって抜け道も用意してくれてる、、、
そんな感じ。 >>3
そう。信者と本山（モジラ）だけ
試しにAPIサーバでも書いてみりゃ即この言語使えねえってわかるぞ あと何度もいうけど「Rustのコンパイル通らないプログラムは危険」とかいうデマゴーグが嫌い
きちんと状態管理すりゃいくらでも正しく動くのに
やれstatic領域は排他制御しろだのやれこの変数はスコープ明示的に切れだのいらんことばっかいうのがRustコンパイラな
書きやすさは一旦置いといたとしても
保守のしやすさってどうなんだろうか
この言語は、保守しやすいコードへ導く言語なんだろうか
>>10
一度書いたものを書き換える度にコンパイラが奇声をあげるので変更もままならないという意味では保守性（）は高いかもな
メンテナンス性がまったくないともいう >>11
メンテナンス性はまったくない、でFA？
言語とのしてのメンテナンス性の傾向ってのは
さほど語られてるのを目にしないけど個人的には
Java
10年後数万行のコード見てもわりと整然としてる
あとから何度も手を入れて運用していける
Ruby
最初書きやすい、表現力が高い？と感じながらスイスイ書いていける
半年後、雑然としていてまったく読めない
クソみたいなコード書いた自分が悪いとはいえ
↑こういう感想を抱いている そもそもRustはプログラミング言語として破綻してるので、
モジラ信者でもない限り使わん触らんが一番幸せだ
悪いことは言わんからRustのことは忘れろ
>>13
ほんと定期的に沸くなこのアンチ
>>12
メンテナンス性でいうなら、最初に型さえうまく設計してれば結構拡張性あるから、
その辺はどっちかというとHaskellに近いかな
クセはあるけど型をきちんと理解して最初の設計に組み込んでおけばかなり自由が効く
最初の型合わせゲームは辛いけどな ID:OLs+Obq4 くらいの基地外になれば100年だって粘着する。
firefoxをRustで書けるわけないと言ってたのがMozilla以外使わないに後退したのか
>>16<br>
そりゃまぁ、事実としてmozillaがRustでfirefoxを書いちゃったからな
firefox Quantum beta 試してみたけど確かにchrome並みに速くなったな
そしてchromeよりメモリは食わないのが良い
でも正直、俺はメモリ不足を感じたことがないからChromeベースのVivaldiを使い続けるが
無事にfirefoxも出たことだしRustもう少し普及してくれないかなぁ quantam はcssしかrustになってないからまだ速くなるらしいぞ
>>18
ブラウザのレンダリング速度ってcssをどれくらい速く捌けるかが大部分なんじゃないの？
それ以外がRustになったところで速くなるといっても微々たるものなのでは．．．
Servoって確かJSエンジンは従来のSpiderMonkeyをそのまま使ってるんだよね
JSはGCあるし、DOM管理（Rust側のDOMオブジェクトとの連携）とかどうやってるのかよく分からんけど
DOM管理の部分とかがRustになったらさらに速くなるのかな？
今のQuantumってGecko全体の何%くらいがRustになってるんだろう？ というか Servo はいつになったらまともに動くようになるんだろう。
精力的に開発が行われているのに、数クリックでフリーズする状況が年単位で続いているのが謎すぎる。
>>21
数クリックでフリーズってどういう事？
普通に動くぞ >>22
定期的にバイナリ落としてきて Windows/Linux で試しているけれど、リンクを数回辿る
くらいの操作で入力を受けつけなくなる。 Windows と Linux は物理的にも違うマシン
だし、おま環じゃないと思うんだけどなあ。 >>23
下のサイトでnightlyビルドで公開されてるやつ試したが日本語サイトは全滅だった。
英語サイトならWikipedia, Github, Rustの公式サイトあたりは見れたぞ。
Amazon, youtube, google mapは動かなかったが。。。
ちなWin10ね
https://servo.org >>24
起動直後にそれらのサイトにアクセスすると普通に動くけれど、
そのままリンクを辿ったりするとフリーズしない?
こちらもそこで落とした Nightly on Win10. rocketというwebフレームワーク気になる
そもそもrustってwebサーバーに向いてる？🤔
trait Foo: Sized {
const BAR: Self;
const BAZ: Self = Self::BAR;
}
beta や nightly では通るのに、stable ではエラー出して通らないのな。
>>26
向いてはないな
web系は処理速度や信頼性、保守性よりも生産性が重要視される。
生産性ではRustはphpやruby on rails には劣る。
かといって向かないとも思わない。
現にRustのweb系のフレームワークは複数存在してるし、
どれも今のところ結構精力的に開発、更新されてる。
Rustはc++と比べて抽象化と並行性という意味では優れているから、
特にRocketは他言語のwebフレームワークにも負けないレベルの短いコード量で
Webサーバー作れる(あくまで個人的な感想。異論は認める)し、
将来的には並行性を活かしてパフォーマンスも改善されると思われる。
Rustが好きなら十分アリだと思う。
逆に目的のWebサーバーさえ作れれば言語なんかどれでも良い
って感じならRustはないな。
Rustは慣れるのにとにかく時間がかかるけど、慣れちゃえば
それほど生産性の低い言語だとは思わないし(高いとも思わないが)。。。
結局は学習コストがRustの一番の問題なんだよなぁ。。。
思ったより長文になった。すまぬ web系で一括りは雑でしよ
シングルスレッドでうぇいうぇいやってるアプリ層と下位の屋台骨支えてるところでは世界が違う
シンプルにまずはc++の代替を狙う言語でいい
仕事で使うレベルを考えるとc++の教育コストにうんざりしてるからrustには期待してる
そーいえばいつの間にかrustfmtのフォーマットが変わって
くそめんどいことになってるけど、
どうしてこうなったの
C/C++を覚えなきゃだめです
Rustを使うにしろGo言語を使うにしろです何の新しい言語を使うにしてもです
世のライブラリの大半はC/C++用に作られているわけです
Rustでラップされたライブラリ、代替できるRustで書かれたライブラリ、そんな便利なものがたくさんあればいいのですが
typedef struct Foo {
int x;
int * x_ref;
} Foo;
Foo foo;
foo.x = 11;
foo.x_ref = &foo.x;
C で書くとこんな感じになる、自分の要素への参照を要素として持つ構造体って、Rust じゃもしかして書けない？
苦心してこんなん書いてもやっぱ無理だし。
use std::mem;
struct Foo<'a> {
x: i32,
x_ref: &'a i32,
}
impl<'a> Foo<'a> {
fn new() -> Self {
let mut foo = Foo {
x: 32,
x_ref: unsafe { mem::uninitialized() },
};
foo.x_ref = &foo.x;
foo
}
}
前もこのスレで同じようなこと聞いてダメだったはず
一つの構造体の中に、配列とその中のどれかを指す参照が入ってる構造
解決策は、参照をやめてインデックスを持つ
let mut foo = vec![false; 20];
// fooの2番目と3番目をtrueにするには
foo[1] = true;
foo[2] = true;
// しかないでしょうか？
2番目と3番目以外がどうなってもいいなら
let mut foo = vec![true; 20];
実際のところ生産性ってどうなん？
GUIプログラムとかにも向いてる？
いい感じのGUIフレームワークがあったとして。
>>43
pythonでいえば
foo[1:2] = [True] * 2
みたいなことです
(1..3).for_each(|x| foo[x] = true);
といちいち書くのが面倒(な上処理が重そう)だったので伺いました
実装したいのはアトキンの篩です >>44
効率が悪いってのはindexアクセスを二回やるとこのこと？
ここは過疎ってるからまじめに聞きたければSlack行くとよいよ let mut foo = vec![false; 20];
println!("{:?}", foo);
foo.get_mut(1..3).unwrap().iter_mut().for_each(|v| *v = true);
println!("{:?}", foo);
コスト気にしてるみたいだけど、release でコンパイルすれば、結局
foo[1] = true;
foo[2] = true;
したのと変わらん結果になるんちゃうか？
>>45,47
そうなんでしょうか(LLVM IRも読めない)
それで進めようと思います
ありがとうございました
アトキンの篩は他の言語だとどれもヒープ
確保してforループでヒープ操作という感じですが
横着して同じような実装をRustで書くとas usizeばっかだしで一目でダメとわかるコードに… Kotlinのスコープ関数みたいなことができるcrateってありますか？
'a type と 'a + type の違いが分からん.
>>51 'a + typeじゃなくて'a + Traitじゃない？ >>52
なるほど！
最近Kotlin書くことが多くてスコープ関数使ってみたら、いちいち変数に入れなくてよかったり（変数名を考えなくていい）レシーバを指定しなくてよかったりして楽に感じたので、Rustでも同じようなことできるcrate公開されてないかなと思っていたところです！ >>53
おお、その通りだ。分かってなさすぎるな…。
fn hoge<'a, T: 'a + Trait>( x: &'a T );
&'a T が参照先オブジェクトの寿命を表しているのはいいとして、
'a + Trait の 'a の意味がよく分からない。 >>35
まず、そのままのコードでは new() の返り値が move されるときに
&x のアドレスが変わってしまう(実際には最適化で move されない
だろうけど言語仕様的には)ので、そのコードがエラーになるのは正当。
なので x か Foo 全体を box 化する必要がある。ただ box 化すれば
コンパイルが通るかというと、 box を deref して得られる参照は box
の中身の寿命ではなく box 自身の寿命になるので、 transmute で
チートする必要がある。
fn new() -> Self {
let mut foo = Box:new(Foo {
x: 32,
x_ref: unsafe { mem::uninitialized() },
});
foo.x_ref = unsafe{ mem::transmute::<_, &'static _>(&foo.x) };
foo
} 失礼。コンパイル通らないコードを貼り付けてしまった。
fn new() -> Box<Self> {
let mut foo = Box::new(Foo {
x: 32,
x_ref: unsafe { mem::uninitialized() },
});
foo.x_ref = unsafe { mem::transmute(&foo.x) };
foo
}
ありがとう。
move するとアドレスが変わるというのは無理矢理実験したときに気付いたけれど、
実際はこんな感じで Box 化された構造体の特定の変数への参照が欲しかったので、
>>38が言った前スレの>>507-514辺りを見て、こんな感じで解決してました。
use std::mem;
struct Bar(i32);
struct Foo {
x: Box<Bar>,
x_ref: &'static i32,
}
impl Foo {
fn new() -> Self {
let mut foo = Foo {
x: Box::new(Bar(10)),
x_ref: unsafe { mem::uninitialized() },
};
let dummy = mem::replace(&mut foo.x_ref, unsafe { mem::transmute(&foo.x.0) } );
mem::forget(dummy);
foo
}
} >>60
ああ、確かにリファレンスとはいえ forget() しとくべきだね。
このコードについては↓でも問題ないけど、まあ実際の初期化はもっと他にも
処理があるだろうから、一般にはこううまくは行かなかいか。
struct Foo<'a> {
x: Box<Bar>,
x_ref: &'a i32,
}
impl<'a> Foo<'a> {
fn new() -> Self {
let x = Box::new(Bar(10));
Foo {
x_ref: unsafe { mem::transmute(&x.0) },
x: x,
}
}
} Rcって何のためにあるんですか？ 所有権？ 借用じゃダメなん？
所有権持ってる変数のライフタイムを超えて借用できないからRc？
色んなコンテナや、色んなデータ構造に渡って持たせたいときはRc？
https://ideone.com/IP9Jk4
書いてみたらなんとなく納得行ったような気がする 標準に整数型のトレイトがないの意味わかんねぇ
std::net以上に需要あるでしょ
Haskellで言うNun型クラスみたいな奴ってことか？
トレイトでやろうとすると要定義メソッド多すぎたり、
累乗みたいな計算の実装が遠回りになったりしそうできつそうに見えるな
Haskellは数値も抽象化してるせいでパフォーマンスにかなり影響与えてるしね…
s/Nun/Num/
Scalaはその辺を、暗黙の型変換でシームレスに扱おうとして闇を量産してるんだよな
Rustは今んとこ特になんもしてない感じか
numクレートが標準にないのが嫌なんだろうけど、std::timeみたいに標準サポートやーめたってなりそう
Into/From使えば別に困らんしと需要は少ないのではなかろうか
https://ideone.com/XBh9VX
・AA treeを実装
・1.8.0で主に確認(ideoneは1.14.0)
・Rc<RefCell<Option<Node<T>>>>を中心に実装
・ふんだんにRc::clone()を乱発
・Tも<T: Copy>でコピーしちゃう
・肝心の木の操作部分は、wikipediaでの表現に近くなるように表現
・基本的によく分かってないので色々奇妙な事をしているかもしれない
昔からチラホラ「Rustで木構造は苦しい」と耳にしてて興味があったのと
最近ほかのスレで実装してた人がいたのをみて触発されたので書いた
最初はOption<Rc<Node<T>>>で書いてたけど
RcとRefCellの組み合わせを試してみたくなって方向転換
けっきょくどっちが正解だったのかは不明 ただのAA木に Rc なんて要らんだろ。Option<Box<Node<T>>> で済むだろ。
AA木の削除操作はwikipediaのやつだとpred(自分より小さい値のうち一番大きいもの)とsucc(自分より大きい値のうち一番小さいもの)を
子ノードから取ってきた後に子ツリーに対して再帰的にdeleteをしてくってなってるけど、ノードの値がNoCopyだとRc使うかunsafe使うかしないと無駄なコピーが発生しない？
>>70
「他スレで実装してた人」って俺のことだな。
↓のスレのことだろ？
次世代言語Part7[Go Rust Swift Kotlin TypeScript]
http://2chb.net/r/tech/1508403098/
木構造は持ち主(親)が1つに限定されるはずのでRcもRefCellもいらないと思うよ。
実際 、自分はOption<Box<_>>という形で実装してるし。
RcとRefCellの練習するんならグラフ構造とかがいいじゃないかな。
グラフ構造ならRcとRefCellはほぼ必須になるんじゃないかな。
グラフ構造はRustどころかC, C++でも実装したことないから詳しくは分からんけども。
>>72
俺の実装では、Option型のtakeメソッドを使ってるぞ。
そしてtakeメソッドの中ではunsafeが使われてる。だからコピーもないはず。
そのことじゃないのか？俺のほうが何か勘違いしてる？？ https://ideone.com/4BnXSI
・AA treeを実装
・1.8.0で主に確認(ideoneは1.14.0)
・今回はOption<Box<Node<T>>>中心に実装
・Tも<T: Copy>でコピーしちゃう
・肝心の木の操作部分は、wikipediaでの表現に近くなるように表現
・前の奴>>70のコピペから開始してるから妙なとこ残ってるかも
>>72
wikipedia見ただけでそのへんに着目できたのってすごい
前回は実はそこで一旦あきらめてコピーとOption<T>の導入に踏み切った
今回もTのコピーうんぬんについては挑戦せずそのまんまコピーしてる >>73 Option::takeを使って子ノードのsuccかpredの値を取ってくるとすると、その子ノードの値はNothingになるよね？
wikipediaの例だとその後にdeleteを再帰的に行うことで(delete内で適宜skew&splitを呼んでる)バランスを保つよう処理してるけど、Nothingが入ってる時点でうまく動く保証が無い
そのスレで書いてくれたものは要素としてCopyであるi32を使ってるから問題が見えないんじゃないかと思う
>>74 自分も>>73の例を見る前に多相型でちょっと書いてみて、どうすんだこれって気付いたんで偉そうなこと言えないっす
Rust固有の問題じゃないような気がしてるよ。C++とかで多相型にしてみたとしても、「子ノードの値を自身の値にする」って部分でコピーが行われる気がしてならない
一瞬だけどAA木の中に同じ値を持つノードが発生しているから、AA木の実装を綺麗に書こうとしたらT:Copy or T:Cloneって制約は必須なんじゃないかと >>75
ああ、なるほどね。
確かにi32の部分をTに置き換えると T: Copy か T: Clone が必須になるね。
これは確かに無駄なコピーが発生してるわ。
まぁ、この実装だとおそらく元になったwikipediaのコードの時点で
無駄なコピーが発生してることになるよね。
wikipediaの場合はi32(4byte)くらいならコピーしてもいいやってスタンスなのかな？
Tの場合は何byteになるか分からないからそういうわけにもいかないということかな？
これ以上は考えるのが面倒になってしまった。。。orz https://ideone.com/dFoFa9
・>>70の<T: Copy>を<T: Clone>に変更
・ついでにRc付きで運用してみて様子を観察
でっかい構造体の場合はこういうふうなのがマシなのかな
Clone運用してるとこに、さらにRcもってくると気持ちよすぎ
おかげで内部の操作に由来した余計な割り当ては無くなった
CloneトレイトとRcには敬意を表したい
>>75
そこんとこの苦悩はもうしゃあないのかな
それについてはもう思考停止します ×・>>70の<T: Copy>を<T: Clone>に変更
○・>>74の<T: Copy>を<T: Clone>に変更 rustのことはわからんけどコピーしないAA木は実装したことがあるので口を出させろください
「succかpredの値をnodeにコピーしてからsuccかpredを削除」しているわけなので
リンクを繋ぎ変えてsuccかpredとnodeをまるごと入れ替えるようにすれば、コピーは要らなくなりませんか
コピーしない実装も不可能じゃないと思うけど、削除時の再平衡をちゃんと理解してないから分からん
ちょっと勉強してみるわ
num crateって昔標準じゃなかったっけ？rustc_privateだけだっけ？
言語は割といい感じなのに何でcargoはこんなにウンコなん(´・ω・`)
ビルドとパッケージマネージャを一緒にしてcrates.io必須にして、他のビルドツールとの連携がつらいんでNIH症候群になりがちで、あんま好きになれないのがcargo
環境変数でビルド先のディレクトリが変わるけど、そこらへんのドキュメントも乏しいのが難点
戻り値の型をflow sensitiveに推論してくれなくて、rustcが推論間違えてそれに気付くのに一日潰れてしまった。
>>86,88
わかる。囲い込んでるのにcargo自身が大したこと出来なくて色々困るんだよね。
色々方針が変わるし。mvnと同じ問題起こしたnpmと同じことしてるし。
言語は良いんだよ。 >>90
hyperかな Webフレームワークのironやnickelがhyperに依存してる ウェブサーバーって書き方が悪かった
RocketやIronを使って実際に運営されてるウェブアプリはある？
小規模なTwitterクローンとかでいいんだけど
server書いてます。フレームワーク書いてますは沢山あるけど運用例聞かないね、そう言えば。
だってどこも使ってないもの
泥箱みたいなところはモジラから金もらって「使ってます」って提灯持ちしてるだけ
事例やソースが一切出てきてないのが証拠
いい加減Rustそのものがモジラのステマの産物だと認めろ。これはプログラミング言語ではない
ディスりにモジラ絡める時点で長いこと荒らしてるいつもの暇人だってすぐ分かるんだよなあ
自分から具体的な話ができないししてもすぐ反論されて終わるもんだから他人の愚痴に便乗するしかできなくなってる
ボローチェッカに自分のコード全否定されて頭がおかしくなった可哀想な子を生み出したRustの業は深い
ボローチェッカにボローボローに否定されたんやなぁってやかましいわｗｗｗ
仕事で使ってるけど、小さな会社なので、皆さんのご期待には沿えない。
>>97
せめてモジラの提灯持ち以外にまともにプロダクションで使ってる企業を出してから言えよ クローズドソースのときって、どういうスタイルなの？
crateのパスを相対で書きまくるのか、巨大ctateをつくるのか
>>106
まさかソースといってモジラの大本営発表持ち出してくるとは思わんかったわ
そんなもんただの提灯で何の意味もない。使ってる根拠にはならない
せめてそういう企業がGithubで公開してるものがあるとかなら認めるがそうじゃねえだろ ちょっと前までのfirefoxをRust使って書けるわけない失敗すると言い張ってからの
この流れは笑える
>>108
失敗してるやん
Rustなんかで書き直したせいでアドオン全滅してる >>107
昔と比べるとだいぶオープンソースな時代にはなったが、
全てがオープンソースで開発されるような時代ではない。
公式の発表を信じずに何を信じろと？
「俺を信じろ」とでも言うつもりか？
「公式」と「お前」どちらのほうが信用度が高いのかまさか君にはわからないのか？ まぁ、けど確かにここに載っているのは社内の一部の物好きな社員が
メンテの必要もないくらい簡単な社内ツールとかを作るのに
利用しているだけのような気はしているんだが、実際はどうなんだろうな？
少なくともブラウザから得た個人情報の横流しとステマで生計を立ててる非営利（）組織の大本営発表は信じるに値しない
>>109
それは設計の段階で従来のアドオンとの互換性の一部を捨てるように仕様変更したからだよ。
firefoxのアドオンは自由度が高すぎるが故に、セキュリティに問題を抱えやすかったし、
アドオン同士が衝突して落ちるとかも結構あったから、そこら辺をChromeと同レベルくらいに制限して、
セキュリティと安定性を取る方向に方針転換した。
仕様が変わってるんだから、Rustで書こうが他の言語で書こうがどっちにしろ従来のアドオンの一部は動かないよ。 >>113
あ、これネタだったの？
気づかずにマジレスしてしまったわ。すまん。 こっちとしちゃ糖質クンに「自分は視野狭窄している馬鹿なんだ」って気付いてもらうんじゃなく
ただどっちが妥当な話をしているのか周りに伝わればいいんだわ。乙。
Redditで、自社の既存のシステムをRustで書き直したよって言う投稿をよく見かける
自分で触った感じでも、プロトタイピングや全く新しいシステム作るときは他の言語でやった方が楽な気がするけど、
試行錯誤もRustでやった方がはやいわってなるのかね？
>>112
どちらが信用度が高いのか本当に分からなかったようだ。。。
君には呆れを通り越して憐れみを覚えるよ。 そういう大きな話じゃなくて、もっと身近な感じでrust使ってるかどうかを聞きたかったんだけど、ここまで>>101しか出てこないな rustでチェスの対戦サイト(サーバー)作りましたとかないわけ？
goとかscalaではいくつかあるけど(もちろんphpも)
今まで「担当者の趣味でなんとなく」C, Go, Python, Rubyで書かれていたツールをRustで書いて
おー速いやんとﾆﾔﾆﾔしてる段階
>>105
crateのパスは相対 >>121
やっぱ細かく分けてるの？
っていうほど巨大なプロジェクトじゃないかな？ Rustでコード書くのって意外と楽しいよね
クロージャもスッキリしてるし
そもそもあと実は俺はスネークケース文化が好き
map_or ←この時面がすき
mapOr ←こんな言語は（あるとしたら）嫌い
スクリプト言語を趣味でやってる俺ですが
firefoxの軽さに感動してrustに興味を持ちました
現在ネットでrustについて調べてる最中なんですが
c++の置き換えだとかっていう情報はよく書かれてますけど
実際c++を書いたことの無い自分にはいまいち掴めません
なんか他に特徴的なとこはあるんでしょうか？
マルチプラットフォームのguiアプリとか作ってみたいです
>>125
>なんか他に特徴的なとこはあるんでしょうか？
自分でガシガシ書く向けだよ。C++より綺麗に。JITなんざ頼らねぇ（れねぇ）、GC邪魔（やる余裕がない）って
領域向けに抽象度をある程度保ったまま書ける。メモリ管理にリージョン使うから解放タイミングが予測できるし、
組み込みもベアメタルもいける。nightlyは書式統一されたインラインアセンブラもある。
低レベル全部rustで書いてもいいし、ライブラリだけrustで書いてCから呼び出せばC++不要。
>firefoxの軽さに感動してrustに興味を持ちました
前にも言ったがfx57の速さにrustは関係ない。設計が根本的に変わった影響。
Servoにあるhtmlの並列トークナイズがfxに移植されたらさらに速くなる。
そんで、言語自体は遅いよ。コンパイラもまだ改善途中だし。
標準ライブラリのコードは速度のためにunsafeだらけで、
JIT/GCがある環境みたいにド直球で素直なコード書くもんじゃなくて、
速くなる部分はLLVMの部分だからコンパイラのバックエンドの違いでしかない。
tracing gcないから開放できないメモリがあるのは他と同じ。 >>119
会社で使うコマンドラインツールはほとんどRustで書いてる。
昔はPythonで書いたりしてたけど、使ってるうちにパフォーマンスが問題になったりすることが多くて
後で書き直したりするくらいなら最初からRustでいいや、と。 >>125
コマンドラインツールをRustでってのはときどき聞くんだけど、
GUIのアプリをRustでってのは聞いたことないな。
そもそもRust製のマルチプラットフォーム対応GUIフレームワークってのを聞いたことない。
Rust製のまともなGUIフレームワークとか存在してるの？ なるほど、コマンドラインツールか。
rust に合ってる領域かもって初めて納得した。
>>128
gnomeは積極的にRustに寄っていってたはず
他は知らん >>129
pecoとか見てるとコマンドラインツールをカジュアルに作るならgoのが向いてる気もするが……
rustにもrgあるし一概にどっちが優れてるとは言えんが gnomeってrustで置き換えていくの？
rustの実用的なGUIってgtkぐらいだと思うけどqtもそろそろ実用段階だったりするのかね
rustで書いてるosってrudoxだっけ？
あれってlinuxカーネルののrustによるリファクタリングって事でいいの？
l
>>134
完全な新しいos？
じゃあlinuxにかなうわけねーじゃん。ただの自己満プロジェクトかぁ >>135
OSとしての実用は自己満レベルでも、コードベース資産としては価値あるんじゃねーの？知らんけど
世の中にはいくらでも自己満OSプロジェクトあるんだからそこは許してやれ
あのGNUですらHurdってOSを自己満で書いてんだ 137デフォルトの名無しさん2017/11/16(木) 13:34:41.95
Rust Essentials - Second Edition
がPacktから出版されましたね
linixこそ個人のお遊びプロジェクトだったんじゃないのか
>>139
少なくとも自分はKonozamaくらってる >>136
LZ4圧縮とか、シェルとか、Redox OSはサブプロジェクトに結構見るべきものがある
Pijulプロジェクトで開発されたSSHライブラリとかもそうで、副産物がいい味出してる urxvtをrustで書き直して🙏
alacrittyはなしで🙅
>>138
そうね。その頃にはオープンソースなunix osが無かったからみんな喜んだ。でも今はlinuxがあるわけで。
まぁでもマイクロカーネルらしいし
ドライバはlinuxのが使えるとかすれば、化けるのかな？ >>144
歴史の知識もOSの知識も無いなら変なこと言わないほうが良い 147デフォルトの名無しさん2017/11/17(金) 01:43:43.14
茂みから鉞が跳んでくるぞ〜
BSDは訴訟がなければな。
あとminixも最初からライセンスが修正BSDだったらな。
linuxは未だにcで書かれてるわけだけど、
それがrustで書き直されたとしたらどうなるの？予想として。
メモリ使用量は減る？
バグは減るよね。
恐らくバグば減る、メモリ使用量は増える
C言語がサイズ減に全振りしているのをrustは安全側に振ってるからな
だがその前にLinusがブチ切れるだろ間違いない
let foo = Foo {
c: f1(),
a: f2(),
b: f3(),
};
let bar = (f1(), f2(), f3());
構造体やタプル構築の時って、式の評価順序はソースに記述されてる順序で確定してるんだっけ？
ここでいうと f1 -> f2 -> f3 で
そもそもgnuの成果物でもなんでもない不自由なコンパイラであるrustcでコード書くことを御大がよしとするわけねーだろっていう
GPLでrustc書き直してから出直してこい
>>131
確かに go でもいいのかもしれんが、rust で作るとしたら、
規模とかランタイム速度要求とか
良いところなんじゃないの？って気はしたよ。
少なくともＯＳやブラウザをこれで作るって話よりかよっぽど現実的な感じがする。 rustは明らかに大物を矛盾なく作り上げるの向きと思うんだけれどもな
小物なら正直メモリの心配なんかせずに「mallocの後にfree不要と(以下略)」式にOS任せにしても構わんし
見解の相違としか言いようがないな。
大物をGCなしで作るとか、よっぽどのプロジェクトじゃないとありえん気がするよ。
linuxをrustで書くとか
rustがcに勝る安全性の部分ではcではバグになりうる部分がrustではバグにならないということはあるだろうけど
移植にしろゼロから書き直すにしろ、これら以外のバグが新たに大量に発生するわけで（現行のcで書かれたものは長い間かけてそれらのバグを１つ１つ潰してきた結果であり）
>>158
そもそもブラウザこそGC使いたくない大物の代表みたいなもんで、rustはそのために作られたわけで >>159
そのうちAIを駆使してcからrustに理想的にTranslateする技術ができるよきっと AIは置いといて c2rust は同じく妄想した
ふと思ってググったら関数定義を rust で使えるようにするツールが引っ掛かった
c2rust.py
唐突な Python ワロタ
bindgenというのはある
が、c->rustのトランスパイラは無理だろう。ValidなCでもvalidなRustには自明には移せない
libcクレート使えば、見た目が半分CっぽいRustプログラムが書ける。
勉強中だが業務で初めてRust使う事になった
1000行程度のプログラムだけどこれを機会にスキルアップしないとだ
Rustを業務で使った結果、毎週の報告で「コンパイル通らないので修正中です」を繰り返し
全然進捗が出せずに左遷減給からの自主退社コンボをくらう>>167
モジラのステマなんて信じたばっかりにかわいそうにwwwwww コンパイル通らない、って聞くけど、ソースジェネレーターって無いの？
新興言語を業務に採用して爆死するパターンはSwiftで既に学んだから、
Rustの業務採用は考えられない。
Cで書いたコードがgccやclangできっちりコンパイル通るのに
rustに移植して通らないのはrustc（というかRustという言語）が腐ってるからだろ
多言語にベタに移植してコンパイル通らないって喚くって、アホそのもののコメント乙
バグがコンパイル時と実行時のどちらで見つかるかというだけの話なんだがなぁ
CのデバッグよりRustのコンパイル通す方が楽だわ…
>>174
何処から突っ込んでいいのかよく分からないのだが。
まず、君の言い方では「C(gcc or clang)でコンパイルが通ったものをそのまま他言語に
移植したらそれもコンパイルが通るはず(通らない言語は欠陥品)」と言っているように聞こえるんだが、
Cは「弱い静的型付け」の言語なので、Rustどころか「強い静的型付け」のJavaやC#
にさえCをそのまま移植するんじゃコンパイルは通らないぞ。
Java,C#の場合はジェネリックやインターフェースや(出来るだけ使いたくないが)キャストを
使用してコンパイラに対してしっかりと型安全を保証してやらなければコンパイルは通らない。
対して、Cは「弱い静的型付け」なのでコンパイルを通すだけなら場合によってはキャストすら必要なかったりする。
まさか、そのレベルから分かっていないのか？
だとしたらRustの所有権云々以前の問題なのだが。 そのレベルは移植の段階で調整しとるわドアホ
やっぱモジラ信者はRustのコンパイラこそ至高で、それを通せないプログラマの方がクソって論調か
相変わらず判で突いたような理論だな
俺が言ってるのは、別にマルチスレッドで動かすわけでもないプログラムを所有権どうこうで弾いて、
本来正しく動くはずのプログラムがコンパイルエラーになり、つまりプログラミング言語としてはご法度の、
書けないプログラムが存在するってことについて異議を唱えてる
このスレでも何回も言ってるのに未だに理解しないの
本当に工作員って感じだな
>>181
無理だと思うよ。
信者ガーとか言ってるのが居るけど、Codeで示せるなら最初から出してるだろうし。 mozillaが工作してるならこんなところじゃなくてtwitterなどでやるだろうし
工作員連呼してるのは自分自身が他言語の工作員だからでは
C/C++から移植して動かない例か。メンバー間参照(self-borrowing)がある構造体くらいしか思いつかんが、
Vec<T>に対する&T -> インデックス使う
Stringに対する&str -> インデックス使う
Map<K,V>に対する&V -> Entry<K,V>使う
異なるメンバーTに対応する&T -> enum使う
で大体対応できるような気がする
業務で速度重視でrustとgoの選択肢がある時にどっちを選ぶべきか悩んでしまう
個人的にはrustの方が好きだしパフォーマンスも出るんだろうけど、今後のメンテ(教育コスト含む)とか考えたらgoにすべきなのかなって
今更null安全でも無くmapやfilterも無い言語は…って感じではあるんだけど
グリーンスレッドは嬉しいが
目的による
外向きサーバ作るならGoのが学習コスト抑えられて楽にスケールする
Rustとの速度差はネットワーク帯域でつぶれて有意に出ないことが多い
長期間メンテするcmdツールやデータ管理ツール作るならRustの方がかっちりかけるから負債になりにくい
Goは気を抜くと容易にサクラダファミリア化する
>>186
なるほど
言語としてはrustなんだが、他の人達がついてこれるかが心配だ >>187 がRustを導入した結果、コンパイルが通らずにチームの生産性がだだ下がり
連帯責任で左遷、給与減、恨みを持った部下に夜道で襲われる未来がみえるぅー↑ Goはよく知らんけどnull安全もジェネリックもない言語使うくらいならC++でよくね？としか思わない
>>189
いやGCあるかないかは重要な要素でしょう。 Goは標準ライブラリが本当に標準だし、それ故にクロスコンパイルが楽ってのもあるな。
libcを選ぶなんて、しなくて良い。
つまりbetterc的な感じでかな。
goはrustよりはちょっとした気持ちでつかえる。
sshクライアントライブラリまで標準で、しかもopensshとかに頼らず全部自前であるとか、
どんだけ再発明しまくってんのとか。
次スレからワッチョイ有効にしようぜ
同一人物だと思うけどいい加減ウザい
ワッチョイしたらそんな変わる？
あんまり変わらん気もするが。
アカヒを遮断したら、差別書き込みが激減してたからね。
発言者が区別つくし、自演も面倒臭くなるからいいんじゃない？
ちょっと違う
「あらゆる」書き込みが減る
ﾜｯﾁｮｲだとそもそも書き込まないという人はそれなりにいる
都合よく自分の嫌なものだけが減るわけではない
そこは認識して受け入れないといかんよ
あとﾜｯﾁｮｲを途中でやめることは実質不可能なのでそれも覚悟すること
ワッチョイは自演にはそんなに効果はないと思う
日替わりのIDに代わって日をまたいで同一IPアドレスの奴をNGしやすくなるだけだと思う
そういや前にも書いたけど、2ch関連のクレート有るね
>>204
カジュアルな書き込みが全部減るんだよ
普通の雑談、普通の質問、普通の回答、普通の自演、普通の荒らし、普通の無自覚アスペ、全部だいたい均等に減る
残るのはﾜｯﾁｮｲ出ても構わないような本気の雑談、本気の質問、本気の回答、本気の自演、そして本気の荒らしと本気の無自覚アスペ
だからご利益的には各自手元でどうにかする分類タグとしての>>202だね、これ以外を喧伝してるのはなんもわかってねえ
で、わかったうえでの導入はご自由に 仮に過疎ったりうまくいかなくなったりして「ﾜｯﾁｮｲやめよう」という話になったとしても>>206のように言われて元に戻せない
不可逆なので覚悟だけはしておいておくれ ワッチョイ＆IPアドレス表示で問題ないと思うよ
IPアドレス表示されて困ることは特に無いし
自演対策には効果ないだろうけどIPアドレス代わらない奴でウザい奴はアボーンできるし
ボローチェッカさんに怒られてばっかりでめげそう(´・ω・`)
メンターがおればなあとよく思う
Option::as_mutとOption::as_refの存在に長いこと気付かないでいたせいで、自分の設計が悪いのか随分悩んだ
IP表示は抵抗ある
ワッチョイ導入はして欲しいけど
213デフォルトの名無しさん2017/11/21(火) 20:20:19.61
>>210
君に期待してるから叱るんだよ
本当に君を諦めたら適当にOK出して実行時に事故らせるよ >>210
一般論だけど
最初のうちは小さく作ってみるといいよ
一挙にいっぱいやろうとすると大変よ カジュアルな書き込みって漠然としてるな。
「このスレは○○だから書き込み辞めよう」って時点で既にカジュアルではない気がするけど。
そんな程度で書き込みを辞める奴の情報なんてしれてるだろ。
本気の質問・雑談で良いじゃないの。
>>215
いやーほんとRustプログラマの選民思想ここに極まれりって感じだな
Rustのコンパイラは選ばれし者しか通せない
通せない奴はプログラマとして失格、発言権など無い
モジラらしいわ 「選民思想だ！ 自分は排斥されてるんだ！」って完全に病人だなコイツ
>>216
どういう事？
コンパイルに関して言えば、コンパイラが文句言うように直せばコンパイルできるし、何より安全じゃん。
どっちかと言うと、選ばれしものしかまとまなソースが書けないCよりも一般寄りなくらいかと。
別にコンパイル通せなくても書き込みゃいいじゃん。これはゴミだ、って。主義主張は自由かと。
通せないやつには書き込む権利はない、と俺が言ってるように聞こえるならば、
つまり自分が「書き込む権利がないと言われてると思い込んでる、通せない奴」だって事？ >>219
何度もこれは言語未満のゴミだって根拠と共に書き込んでるのに
コンパイラ通せない奴の僻みだのなんだのいってキチガイ扱いしたのはてめえらじゃねえか >>220
どういう事？つまりコンパイル通せないって事？ イミフなdisリって単なる背乗りだから役立たずなんだがなあ。
じゃあどういう言語なら良いの？って聞くとダンマリw
シャドーとか所有権で挫折したのかな？
GC無しとか、動的っぽい使い方が出来るようにする為のもんだって分かってれば、あーこういうアプローチも有りなんだなと思えるけどね。
>>220
キチガイ扱いしたのは事実だが、「僻み」といったことは一度もないぞ。
暇だったし、過去レス検索して確認したから間違いない。
被害妄想甚だしいぞ。
第一、どこがコンパイル通せないかを具体的に書いてくれたら指摘してやるって言ってるだろ。
お前「Cを移植したらコンパイルが通らん」としか言わねえんだもん。
そんな漠然とした情報じゃ指摘しようがねぇよ。 僻みでも何でもなく、そこがいいところなのになぁ、だと思うけどね。俺も。
コンパイルできてたCも、多分misra案件だとまず静的解析ではねられるか上司にしこたま怒られる類だと思うよ。
rustってASTにアクセスできる仕組みってあったりするの？
>>226
何がしたいの？
nightly なら syntax クレートとか使えばできると思う。
使ったことないからよく分からんけど。
stableじゃ出来ないんじゃないかな？たぶん。。。
誰かもっと詳しい人いる？ >>220
で、どういう言語なら良いの？
またダンマリか、話題逸し？w 一般に普及した言語の仕事でクソ仕様にひどい目にあって
アンチになるというのなら理解できるが普及すらかまだわからない
新興言語でここまでアンチ活動する情熱の根源はどこだろう
リアルで実害を被ると言及することすら嫌になるよ
粘着ができるのも個人的に気に食わないの範囲に留まってるからさ
>>231
キチガイ扱いされてでもかまってもらいたいとか、とんだドMだな。
それはむしろキチガイ扱いされていることを喜んでいるという認識でよろしいか？ 一つの構造体の中にVecの実態とそのスライスを持たせるような事って出来ないのかな
バイト列を解析して、元データの実態と意味毎に分けたスライスを持たせたいなって思ったんだけど構造体作る時に同時に渡そうとしたら怒られる
とりあえず実態だけ持たせて特定の場所のスライスを返却するメソッドを持たせたけど設計的にこれでいいのかな？
>>229
普及した言語disると反論も大きいからねぇ。
かと言って余りにマイナー言語じやあ、disる場さえない。
なので自然に、中間の位置に有る言語に擦り寄ってくる。
昆虫の走光性みたいな知能。 >>234
じゃあ、Goのほうに行ってくれればいいのに。 この言語やっぱ参照をもつのは愚策だな
Lifetimeでインタフェース複雑になるし、ボローチェッカーが無理ゲーになる
この言語用の設計しないと
>>233 スライスも参照だからself-referential structになっちゃうからRustで素直には書けんよね。インデックスが今んところベストだと思うよ
その例だとバイト列に直接アクセスしない想定だと思うけど、個人的には解析結果は元データに従属したものと考えた方がスッキリするような気がする
&strに従属するCharIndices<'a>みたいな 言語をdisる意味ってマジでわかんないよな。
素直に自分の好みの言語スレでマンセー言ってるほうが建設的。
>>237
ありがと
やっぱり素直には出来ないよね
>>236 も書いてるけど、rustに適した設計をする必要がある感じだね
元々vm系言語やスクリプトばかりだったけど、rust始めてからスタックやヒープ、メモリコピーの発生とか意識するようになって今後の自分の為にもなってそうだ １．RustからHTMLレンダリングエンジンを使いたい
HTML＆CSS等をレンダリングしてビットマップを得たい
２．HTMLレンダリングエンジンの動作をカスタマイズしたい
不要な機能 JavaScript、ネットワークアクセス、audio or videoタグなど
改変する機能 CSS等にプロパティを追加して任意の動作をさせる、画像等へ任意のフィルタを適用など
候補はBlink、Gecko、Servoあたりを考えていますがRustから使うならやはりServo？
いずれにしろ組み込んだ上でさらにカスタマイズするような資料は見つけられない・・・
>>242
カスタマイズできるラスタライザーが欲しい
日本語が使えて画像を挿入できて線を引いたり出来るもの
入力はHTML以外にPDFやPostScriptなども考えたけどジェネレートや
レンダリング、デバッグを考えるとHTMLがお手軽かなと・・・
今考えているフローはこんな感じ
別ツール→言語(出力結果を制御するメタデータ付き)→ラスタライザー→ビットマップ＋α ノベルゲームだったらスクリプトやマルチメディア系のタグを殺す意味が判らない
>>243 librsvgでSVGをいじくり回すんじゃダメ?
・Rustバインディング(rsvg-rs)あり
・CSS,XSLT,DOM操作で加工可能 >>246
ありがとう。SVGって文字を扱えるんだっけ・・・って調べてみたら扱えるみたいですね
行けそうな気がしますがGPL/LGPL系のライセンスは使えるライブラリを制限するので避けたいです
C++だけどsvgrenとか？情報少なすぎてちゃんと動くのかすら不明。日本語フォントとか大丈夫なのだろうか
CでラップしてさらにRustでラップするようなのかな Javaも最初の頃はマトモに書いてもコンパイル通らなかったこといくらでもあったもんな。
>>215
本気の荒らしと本気の自演と本気の無自覚アスペはいいのか…？
自分に都合がよいものだけが都合よく残るって都合よく考えるなって言われてるんだろ RustでGUIってイケてる？っていうか、GUIライブラリ多すぎるだろ・・、
GtkとQtメインでやってるけど、JavaFXもいいし、Pythonなんてバインディング沢山あるし、
Rustなんてやりだしたら、もうキリがないよ・・・
もうどれか一つでGUI決めてくれねえかな・・。スゲエ、面倒。
おじいちゃん、GUIはブラウザってきまったでしょ？
GUIはElectronみたいな方向に行ったほうがいいのかね
Blink を Servo で置き換えた Selectron 来い
>>238
バカが調子に乗って新しい言語使って書き散らしたコードをメンテする経験をすればわかるようになるよ。 個人的に検討するGUIフレームワーク
簡単な奴→MS HTAやElectronなど。Webで使われている技術で実装できる
凝った奴→wxWidgets。高機能かつ高速、大抵の物は作れるが罠もある。もしくはAPI直叩き
昔結構悩んだけど結局上記あたりに落ち着いた。当時検討した物
GTK→LGPLウザイ。パフォーマンスが良くない(最近は良くなった？)
Tk→低機能で作れない物がある。パフォーマンスが良くない
Qt→LGPLウザイ。パフォーマンスが良くない
JavaFX→パフォーマンスは悪くないがJREの初期化(≒起動)に時間がかかる
>>256
バカに無計画にコードを書かせているバカが問題なのであって言語が悪いわけではないだろう >>249
良いだろ。というか、それらを止めるのは現実的な方法では不可能。イエスマンを集めて楽しくワイワイ()になるぞ。
記名制のフォーラムでも本気の荒らしや本気のアスペや本気の無自覚は幾らでも居たんだから。 hyperってシングルスレッドなんなね
ベンチマークも結果がバラバラでよう分からん
>>258
まあそうなんだが、
言語によって弾けるとする linus の意見には賛同するところはある。 >>256
そういうやつって言語関係なく台無しにしてるんじゃね？ >>262
確かに、そういう奴ってどの言語使っても大体はクソコードを書くだろうな。
ただし、ベストプラクティスを教えてくれるやつがいるかどうかで差はあると思う。
新興言語はベストプラクティスを教えてくれる奴が極端に少ないから、余計にひどくなる。
対して、普及している言語は周りにベストプラクティスを教えてくれる人がいれば
バカでもある程度はマシなコードを書く(書くことを強制される)んじゃないかな。 >>262
関係ないんだが
「関係ない」ということを理解せずに無駄に新しい言語推しで
現場嵐してくることが問題。まずはてめーのコードを直せと。 そのバカと言語disに走るID:OgtFvRibは同レベルだよ。
>>265
単語の断片に反応してるだけの思い付き厨だろうな。 >>264
それって人事が無能なだけじゃあ。まぁ日本にそういう会社は多いんだけどな いうほど言語disに走ってる訳ではないけどね。
ただ言語disに走る気持ちは理解できるってこと。
他の言語disパターンとしては単純に自分があんまり知らんから
理解する時間の節約のための dis かな。
rustは組み込み向けの新言語になると思ったけど、全然流行らんな
早くC++から脱したいのに
昔の一部の組み込み系では製品の安定を求めるために
コンパイラのバージョンアップすら信用しない（＝古いバージョンを使用し続ける）ことがあったなー
『"（Rustが売りにしてるような部分に関して）良いコード"を書きたいと思っているh人』にとっては素晴らしい言語となる可能性の高い言語がRust
『"良いコード"の定義が違う人』にとっては
『"良いコード"を書きたいと思っているわけではない人』にとっては
272デフォルトの名無しさん2017/11/26(日) 02:52:44.07
Rustがコケると得するのは誰か
>>269
目的より手段を優先する日本じゃ無理だろｗ
どうしてもやりたいなら自分で立ち上がるしかないんじゃないか >>273
rustが使いたいからその仕事を立ち上げるって明らかに手段と目的が入れ替わってますよね >>272
世界中のプログラマ
モジラのクソ提灯で言語未満の自称言語がひとつ減る訳だから >>276
執着というより単に語彙力がないだけかと。
コイツいつも大体同じようなことしか言ってないよ。 >>263
ガウディ本とかで計算モデルを理解してれば、慣れてるという理由で合わない用途に無理矢理押し込もうとしないんだろうけどね。 少なくともswiftに採用しようとしてる機能を先行実装しているだけでも価値ある
Rustが成功したから真似されたんじゃｗ
Ａｐｐｌｅ信者さすがの言い草
Swift の仕様変更と比べると、Rust のアップデートはかなり大人しいよな。
>>282
Ｒｕｓｔのメモリ管理の仕組みが破綻してないことを証明しただろ！
しかも実務にも耐えてる
これが成功でないわけがない >>284
循環グラフとか動的計画法とか書けない言語のどこが破綻がないのかいってみろ工作員 286デフォルトの名無しさん2017/11/27(月) 01:55:07.26
RustでDPできないの？
このエラーメッセージ、表示されるときと(当該箇所の修正をしていないのに)も関わらず表示されないときがある
Why?
error[E0605]: non-primitive cast: `{integer}` as `f64`
= note: an `as` expression can only be used to convert between primitive typ
es. Consider using the `From` trait
このエラーメッセージが表示されるのは
このエラーメッセージの示す箇所と全然無縁な箇所でコンパイルエラーが出たときに同時に表示される
そしてその他所であるコンパイルエラーを解消するとこのエラーメッセージも同時に消える
>>270
実際、g++ なんかはバージョン違うと相当挙動違うけどね。 >>289 エラー時には情報足りなくてusize等に推論してるから、かなあ
構文チェック -> 型推論&チェック -> ボローチェッカーって順番でエラー出してる感じだけど、
関係無い場所でのエラーのせいでas f64してるローカル変数の型推論が不十分な可能性がある
型推論は重い処理だから何らかの最適化のせいでエラー時の挙動が分からないのではないか Rustでイミュータブルに拘る人は何なの？ミュータブル使えよ
ミュータブルにする必要のない箇所をイミュータブルにする
基本はミュータブルで使え、ミュータブルしてなかったらコンパイラが教えてくれる、そのときイミュータブルに変更すればいい
Rustでイミュータブルに拘るのは、TypeScriptで型付けることに拘るようなもん
最近勉強し始めたんだけど、デフォでイミュータブルなのに思いのほかmutキーワード使う局面が多くて面食らってる。
イミュータブルに拘ると、Scalaとかでもそうだが、コピーだらけになる
コピーを恐れてるとイミュータブルを徹底できないよ
あ、そういうこと。むりやりイミュータブルにする人たちがいるのか
静的型付け初めてなんだけどいきなりRustは敷居高いだろうか
>>300
> イミュータブルに拘ると、コピーだらけになる
> コピーを恐れてるとイミュータブルを徹底できない
例出してみ イミュータブルとかメモリを富豪的に使うだけで性能はなんら上がらない、いかにもお偉いさんが机の上だけで考えたクソ手法だろ
なんでFortranやCが現役なのか考えたこともないやつがイミュータブルをもてはやす
それは言い過ぎだろ
なんでもイミュータブルにするべきとは思ってないが、
並列性が必要なプログラムではイミュータブルは重要視しているよ
並列性が性能に直結しない（難しい）のは残念な話だけど……
>>306
値変えないならコピーするしかないだろ。それが富豪的でなくてなんなんだ？
>>307
並列計算で必要なのはイミュータビリティじゃなくて、変数スコープ分離と外部依存性の無いアルゴリズムだ
大方MPIすら使ったことないんだろうが、
共有リソースにアクセスしなきゃいけない並列プログラム組んでる時点で
設計が破綻してるとみなせると思うがそこんとこどう考える？ このバカ、コンパイラが良きに計らうってことを知らんのか？
>>292
thx
なるほど、コンパイル途中でエラーすると一部の推論に失敗してしまうのか const に異常にこだわるくせに異常に長い関数書く馬鹿は見たことあるな。
その前に関数切り出せと。
たぶん Rust が一般に広まるとボローイングルールをまともに理解できなくて
コンパイルできないから関数に切り出さないバカが増えると思われる。
312デフォルトの名無しさん2017/11/28(火) 15:17:40.57
イミュータブルにすることでコンパイラによる最適化の余地が増えるんでないの？
ミュータブル派とイミュータブル派の宗教戦争勃発なの？
コンパイラが善きに計らうって、
つまりconstついてた（mut非指定の）変数がレジスタ割り当ての結果変更され得る最適化が起こるってことか？
さすかにそんな最適化は聞いたこと無いがソースあるのか？
即値展開ならわからんでもないが、それと並列は関係ないし
アマゾンでオライリーのProgramming Rust出てるのな
アーリー版じゃ無い完全版かな？
どうでも良いけど蟹座の俺が心惹かれる表紙
>>308
「使ったことない」って人を判断したがるのは使ったことを自慢したいから？
ある数学上の問題を高速に解くために 2000年ぐらいにMPI を数ヶ月触ったことある程度で
以降は関わってないけど、それはなんか関係あるのか？
設計が破綻しているかどうかは問題によるだろ
どんなに考えても共有リソースにアクセスしなきゃいけない並列プログラムなんて山ほどある
共有リソースへのアクセス削減なんてみんな取り組んでる
そのための一ツールとしてイミュータビリティは重要な概念だろJK
> 並列計算で必要なのはイミュータビリティじゃなくて、変数スコープ分離と外部依存性の無いアルゴリズムだ
「重要視」と言ってるのに「必要」と解釈するのか……
変数スコープ分離という用語は知らん >>314
kindle版の話か
紙版を注文しちゃってるんだが >>315
MPIは不変性は並列化に必ずしも必要じゃないって話の例に出しただけだから、
さわった上で不変性が必要って主張するならまあそうなんだろう
データを不変にして触るノードの分だけコピーすりゃそりゃデータ競合は起きないだろうが、
その分ノードへの転送量だってかかるし、メモリも食う
だから富豪的で、額面上の並列度は上がっても性能には寄与しないと言ってる
俺が知らないだけでもっと良い最適化が不変変数にかかるなら完全に俺が無知晒したでめでたしなんだが 業務のＤＢとかででっかいＢｅａｎやテーブルさわってるとＩｍｍｕｔａｂｌｅこだわると死ぬ気がする
ライブラリレベルだとImmutableすごいよさそうなんだが
immutableがいいのはソースの可読性が高まるのと、マルチスレッド化したときにリソースアクセスに問題ないのが保証できることでしょう。バグらなない自信があるなら効率を求めてmutableにするがよろし。
mut にするのもそこまで困難な言語設定ってわけでもないし、
デフォルトが immutable でもいいんじゃねとは思う。
まあ大規模に作ったことはないからその際の困難はわからんけど、そこまで問題にならんのでは？
mutにするのをめんどくさくするというのが
let mut構文を採用した理由なので
varはよっぽど何かない限り入らないと思う
Haskellのイミュータブルは永続データ構造？参照の使いまわし？
Rustのイミュータブルは？コピーしないと使いまわせない？
wasmに出力するのって、依存ライブラリも全部pure Rustじゃないとダメなの？
1.22でOptionにも?使えるようになって、haskellのMaybeモナドっぽく使えて捗るわ
ブロック内だけでも使えたら良いんだけど仕組み的に無理そうか
try catchみたいな構文検討されていたような
Rustを叩いている奴ってミラーレスカメラを叩いている一眼レフカメラ信奉者と同類に見える
大抵の場合は合理的な方が最終的に選択されるけどな
mutable変数扱うなバーカ、というメッセージだと思ってる
必要なら再宣言させるようにして人為バグを減らそうという魂胆は分かるぞ(Javaのfinal教徒感
BufReaderとかReadするStringとかにもmut必要何だからmut禁止とか無理じゃね？
不要なmutだったらワーニング出るでし、必要だったらコンパイルエラーになるでしょ
必要な形で使えば良いだけなのに一体何を議論してるんだ？
ミュータブルが気に入らないならhaskellおすすめ
Readした結果はmutableでいいのにlet mutと書かなければならんの面倒
人によってはletで再宣言するのかな
例えばさ
mutな変数1つ宣言してそこに足し上げていくのと、
非mutな計算結果同士を足して新しい非mutな計算結果を作るのと
素朴に考えれば前者の方が省リソースだよな
別にその程度コンパイラの最適化やレジスタ割り当てでどうとでもなるだろうとも思うが
https://qiita.com/koji_mats/items/62e85a87cc580e225796
これ見たんだけど、なんでwinがlet mut winじゃないんだろうって不思議に思った。
let win = gtk::ApplicationWindow::new(&app);
win.set_title("Vanilla Text");
で、コードを調べてみたら、こんな感じにFFIを呼んでるだけだから、
概念的にはオブジェクトを変更してるけどRust的にはmutが要らないという仕組みらしい。
ちょっと違和感無い？
fn set_title(&self, title: &str) {
unsafe {
ffi::gtk_window_set_title(self.to_glib_none().0, title.to_glib_none().0);
}
} ポインタの先がどう変更されようが、ポインタを持ってるだけの側は不変。
Rust的な設計の指針というかコツみたいのって無いですかね…
勉強のつもりで外部のCのライブラリとの間に入るちっちゃなFFIのラッパーを書いてみたんですが、Cの感覚で書く->コンパイラに怒られてあーなるほど修正ってのを繰り返してとりあえずは動くようになったんだけど
何をするにも
let foo = xxx ;
{
let bar = foo.xxx() ;
bar.yyy() ;
}
{
let baz = foo.zzz() ;
baz.www() ;
}
{
let bar = foo.xxx() ;
bar.yyy() ;
}
みたいに書かないといけなくて書いた本人でも｢何やねんこのウンコ！｣ってなってる(´・ω・`)
(Rustがって意味じゃなくて自分の書いたものがって意味で)
どんなエラー出してそんな醜いコード書いてるのかを説明してくれないと。
>>338
cと触れる部分はしょうがないんじゃないの？
その何回も触ってる部分をcで書いてインターフェイスを最小化した後で
rust から呼び出す方が正解なんじゃないかね。 Rustに限らず他言語で書かれたライブラリを利用するときは呼び出し元言語の作法に適合するように改修しないと使いにくいことが多いような
>>338
> Rust的な設計の指針というかコツみたいのって無いですかね…
私も知りたいです！ >>338 見た感じFoo::xxx : &mut Self -> BarとかFoo::zzz: &mut Self -> bazとなっているのでbarやbazが生きてるとfooにアクセスできないのが直近の原因だと思うけど、
xxxやzzzが本当にFooの変更を伴わないといけないのかを考えないといけない
CellやRefCellを使ってinterior mutabilityを導入したらFoo::xxx: &Self -> Barというメソッドにできる可能性がある
まあ実際のソースがどんなもんなのか知らないから適当だけど >>345
公式Twitterアカウントをフォローしてみれば、リツイートに含まれるアニメ画像の多さで分かるだろ 348デフォルトの名無しさん2017/12/02(土) 21:26:24.08
ジャパニメーション
そもそもエンジニアの時点でPCオタみたいなもんだろ
標準ライブラリAPIリファレンス見てるけど難しいなぁ。
map: HashMap<String, usize>をメンバーに持つ構造体Fooを作りHashMap::getをラップするメソッドを定義したいんだけど、
型表記をどう書けばStringとstrの両方を受け取れるようになれるの？
panic!で終わらすのでなくErr()を返してエラー時の挙動は呼び出し側に任せる・・・？
get で使うなら AsRef じゃなくて Borrow
Mercurialも、Python/CからRust/Pythonに切り替えるのか
> Python is also hindering us because it is a dynamic programming language.
>>358
ソースどこだよデマ乙
歴史あるVCSがRustみたいなゴミつかうわけねえだろ > For Mercurial, Rust is all around a better C.
> It is much safer, about the same speed, and has a usable standard library and modules system for easily pulling in 3rd party code.
>>359みたいな基地外君発狂しそう。 ソースはRedditwwwwwwwww
ソースは2chよりひでえwwwwwwwwwwww
一次情報はmercurial oxideなんだけどこれが公式mercurialとどんな関係があるかがRedditのスレで言及されてるんだが
モジカス連呼基地外君は発狂中だとurlしか読めないのね
>>360
mercurialにpythonで書かれた拡張機能がいっぱいあるからだろうかね 言語が錆でプロダクト名が水銀だから、プロジェクト名が酸化ってのもうまいことつけたな
Python3化を優先しないのは、斜め読みした感じだと「hgコマンドをPythonスクリプトから（必要に応じてPythonインタプリタを埋め込んだ）バイナリにしたい」ってあったから、順番的には確かにそっちは後だな
あとは、GILの性能自体はPython3で向上したとはいえ、GILそのものがなくなった訳ではないから、
それで得られる速度向上は並列化と比べてたいしたことないってのもあるんじゃね？
あとPython3はそもそも単純なベンチでは2より遅かった気がする
なるほどね。
個人的にはgitよりmercurialに頑張ってほしい
VCSは自身の機能や性能も大事だけどそれを使った開発プロセスの整備と提示が大切なんだなあとgithub見て思う
pijulにはちょっと期待してる
公式がマジで言ってんのかこれ。多分gitに負け続けて資金調達のためにモジラに泣きついた感じか。そこまで落ちぶれてたんか
けどまあwikiの他のNewFeature見てみた限り放置も多いみたいだし、これもそのまま忘れ去られる系だな
Rustで大きなプログラムは書けない
→Firefoxにしか使われない
→Mozilla以外はまともなプロダクトでは使われない
→負け組プロジェクトしか使われない
進化を楽しみにしてるぞ
コンパイル通せない事がそこまで彼のプライドを傷つけるとは……
コンパイルエラーが発生したときに、自動で「大変申し訳ありませんが、」の文字列を追加表示する
コンパイラプラグインを誰か開発すべき
Rustつかって書き直すなんて、言うだけはタダだし、言ったことでモジラから金がもらえるなら言うだろうね、落ち目のプロジェクトなら
個人的にはgitより好みだったけどな
そもそも言語変えて書き直すとか非現実的なことできると思ってんのお前ら
チャットワークは記憶に新しいぞ
それを解決できるのはスレッドの類をGC対象にできる言語のみだろう
Ponyはできたような気がする
ponyってあれか。スポンサー企業が一抜けしたやつか
これからやるのにGUIでいいプログラム言語教えてください。Microsoftは無しで。
>>385
おじいちゃん、GUIはブラウザってきまったでしょ？ 実際マジで綺麗なGUI作ろうと思ったらブラウザ使った方が良かったりするからなあ
wasm/WebGLのみターゲットにしたGUIツールキットcrateを作る人も出てくるんじゃないかね
簡易なもんつくるなら react をてきとうにいじるのが一番覚えること少ない気がする。
しばらくreact+reduxやってから久しぶりにC#に触ったらやっぱり.NET楽だと思ったわ。
Webアプリ前提ならReact一択でいいけど、スタンドアロンでいいならわざわざ選ばんなぁ。
.NET は何がどう依存してるかわかりずらくてデプロイするのが面倒じゃん。
Rustは何がどう依存してるかわかりずらくてプログラミングするのが不可能じゃん。
>>394
> ずらく
お前はまず日本語を学ぼうな。 399デフォルトの名無しさん2017/12/09(土) 00:27:43.89
英語やった方がいいと思う
日本語マニュアルなんてあるんだな。
相当本気なんだなRust。
Swiftなんて公式は未だに英語だけだぞ。
そういえばPEZYが自分とこのcpuでrust動かしてたな。
Cの代替として使ってるみたいだけど、mutとかunsafeとかめんどくさすぎて話しにならないな
やっぱRustは詐欺だな。詐欺会社同士モジラとは馬が合うんだろうな
普通の感覚持ってたら>>405と同じように使い物にならないって感想持てるよなあ RustはSmallTalkと並び称されるべき言語
Rustは死んでも血脈は残り続けるだろう
>>405
主要部分丸々Unsafeにした挙句
インラインアセンブラを書いてやればいいですとか
なんでもなさそうに書いてあってわろｗ プログラミングに限らず安全はタダで得られるはずがないのだが理解出来ない日本人は多い
>>406
なぜRustの苦手分野で語ろうとするのか？
これはJava等の高級言語では絶対に出来ないこともRustなら不格好にはなるものの
可能だということを示しているのであってRustで書いた全てのコードがこうなるわけではない。
低級なことをするときはこういう書き方が必要になるというだけだ。
Rustのいいところは低級なところをすべてunsafeでラップすることで、
それより上位層のコードに低級な部分を持ち込まなくて済むようになることだ。
そして、Rustの最大の特徴は高度な型システムとゼロコスト抽象化等の機能であり、
C++, Java以上の賢い抽象化の仕組みを実現しつつC++並みの実行速度で実現できる点である。
unsafeに関しては、あくまでC++の後継を狙っているので低級なコードを書く手段も用意しているというだけに過ぎない。
CやC++にRust程の抽象化や型安全、メモリ安全を保証する機能はあるだろうか？
「そうまでして安全性や抽象化を追求する必要があるのか？」と問われればそれは作るシステムや個人の趣向にもよるだろう。
欲しいと思う人もいるし、それはやりすぎだと思う人もいる。
Rustが苦手としている部分をとりあげて「ほらダメじゃん」とか言われても、
「Rustの得意なところじゃないんだから当たり前じゃん」としか言えない。
要約して一言で言うならば「論点がずれている」。
以上だ。何か反論はあるか？
長文失礼した。 ようわからん
unsafeでくるまれたところでデータ変な風にいじくられたら
結局上までおかしくなるんじゃないの？
>>412
要件に合わせて方式選択できて、必要であればその範囲を狭めることができるのがメリットでは？ >>411
詐欺師の長文は読むつもりもない
以上だ 404みたいに新しいCPUに移植して特殊な命令使うような話なら
C言語でもインラインアセンブラ使ったりするしかなかろう
>>412
別に上でおかしくならないことを保証してくれるとかではないよ。
単にメモリ保護違反とかが起こるなら必ずunsafe内で起こるってだけ。
それでもプログラム全域のどこで起こるか分からないCとかよりはましだろうってことかと。 >>411
rustのセールストークを真に受けちゃった人にしか見えない。 >ゼロコスト抽象化
実際にはzero-costじゃなくてzero-overheadだよなrustって。
わかりづらいけど正当なコストはちゃんと払ってるし。
ところで、javaのクソ翻訳にauto boxing and unboxingを「ボックス化」と訳す
トンデモ訳が蔓延してるんだけど、リージョンでメモリ管理するrustだと
正真正銘のboxed valueがあって、この訳が「ボックス化」だから逆に紛らわしい。
Javaの方が先にあるのに後発が正真正銘だとかどういう了見だよ
423デフォルトの名無しさん2017/12/13(水) 05:05:47.72
>>416
Haskellマスターtanakhが逮捕されたと誤解を招く書き方辞めろ 宣伝文句としてはbetter C++だけど、実際の使用例はbetter Cが多い
既成ライブラリの中でメモリ保護例外を吐いた経験がある人ならRustのありがたみが判るはず
マルチスレッドアプリケーションでトレースバックが参考にならないような状態だともう泥縄
そんなコードが散乱してる現場でrustのボローイングに関して
まともに対応できるとは思えんが。
よしんばあったとして、Rustに頼るのは間違ってるだろ
不運続きの人間がカルトにはまるようなもんだ
>>428
まあRustなんて有り難がってる時点でなあ >>429
いやそうじゃなくて、あんたみたいに知ったかぶってるやつが多い
そうじゃないのもいるけど しったかぶってるか？
C(++)の後継うたってる割に、動くCコードの移植がチェッカーに阻まれて不可能
グラフのような自己再帰構造が書けない
そもそも開発元が悪名高いモジラで、言語機能の改善がまったくなされないのに何故か使ってると称する会社だけが謎のペースで増える（恐らく金が動いてる）
例のスパコン詐欺会社で運用されていたらしいという負の実績
事実並べただけでRustがいかにクソか分かるだろ
金が動いてる部分だけはソースないが他は全部ソースつきだ
みんなランタイムエラーの方がコンパイルエラーより好きなわけ？？
んなこたないけどコンパイルエラー出なきゃいいっていう馬鹿が増えそうなのが心配。
>>431
そのまま移植しようとしたらそりゃ難しいに決まってんだろ しかもあのスパコン会社技術力は確かに高いし
社長がうんこだっただけで
まあ、アホほどいっぱい書き込むからそう見えるだけなんだけども。、
[][][] [][][] [] [][][][] [][] [][][][][] [][] [][] [] [][][][][]
[] [][][][ [][][][][] [][ [][] [] [][][] [] [][][] []
[][][][] [] [] [][][][][][ [] [][][] [][] [][] []
>>437
dgemmみたいな行列演算をチューニングするとどうしてもああいうコードになるんだよ。
てか多分 c で書いたのを話題のために無理やりrustに書き換えたんだろうね。。
unsafeで囲むとかもうrustで書く意味ないだろそれ。。 pezyの例には当てはまらないけど、Cに分けたモジュールリンクするぐらいなら、
unsafe丸囲みの方がビルドが単純になって意味がある。
この手のキチガイは荒らすことが目的だからワッチョイを付けてもいなくならないよ
unsafeで囲む意味が無いとかマジで言ってんの？
ここはunsafeだよって一目で分かる利点を理解していない？
ワッチョイもunsafeも同じように有用ってことだね
ボローチェッカじゃなくてモジラに親を殺されたんだな、かわいそうに
悪名高きとか言われても知らんがな。悪い話もいい話も聞かんが
元々なんでか知らんがMozillaが嫌いだったところに、
コンパイル通すまでがちょっと難しい言語をリリースして、なんか世界的にそこそこバズって
それを自分で使えなかったことで、正気を保てる限界を越えた感じかね
突撃荒らしのバイタリティが妙に高いのも納得できる
>>445
例のブログみたいに、全部を囲ったらチェッカーの意味ないじゃんって話では
言語機能としてのunsafeの有用性は分かる
確かに全体をunsafeで囲うなら現状はまだCで書いた方がいいと思う
Rustからだけ使うなら難しい線だが unsafeブロック内のRustコンパイラによるチェックはCコンパイラに劣るということ？
自前のstructのnewメソッドで外部crateのAWSクライアントを作って持たせて、インスタンスメソッドの中でそのクライアントを使いたいんだけど、
そのクライアントがgenerics使ってて実際に返ってくる型が分からない時にstructに持たせる方法ってないのかな
例えばこんな感じの。
[crate]
struct<A:Trait1, B:Trait2> Client<A, B>
[My code]
struct Hoge {
client: Client<?, ?>
}
ソース見たら更に別のバージョンが古めのcrateのモジュールがそこに入ってたりしてて、そうすると同じバージョンの依存crateをこっちでもexternして、それを自分のstructに書いたりしないといけないのかな？
