21/04/26 23:42:53.23 y3Z2xzaE.net
>>301
自分で書いてて全然理解できてない奴らが量産されて、キーボードを叩く拳に血が混じりながら
意味不明なコードを誰かが直す。なんというおそろしい未来かw
333:デフォルトの名無しさん
21/04/26 23:56:56.13 MHmHz52r.net
linuxにいちゃもんつけてる人はいないが
rustユーザーがlinuxにいちゃもんつけてると主張する人はいる不思議
334:デフォルトの名無しさん
21/04/27 01:41:47.11 Wan/QADt.net
来年は組み込みRust元年になるやで
335:デフォルトの名無しさん
21/04/27 02:20:03.39 +/hUQLiN.net
あわしろ氏もそう言ってますね。
336:デフォルトの名無しさん
21/04/27 02:20:38.76 GJuK6dTy.net
何で今年じゃないの？
337:デフォルトの名無しさん
21/04/27 02:36:39.16 lIgwswD1.net
panicのせいで実質組み込みでも死んじゃったな
linusやりすぎだぞ
338:デフォルトの名無しさん
21/04/27 02:51:16.77 53lThlBD.net
>>332
Linux カーネルで受け入れられないからと言って組み込みで panic が使えないわけじゃないでしょ。
339:デフォルトの名無しさん
21/04/27 08:06:21.79 C32SFGMy.net
>>325
URLﾘﾝｸ(play.rust-lang.org)
元ネタこれなんですが
min('a,'b)的な考え方だと確かにf3について納得できる気がしますが、今度はf1が通るのがわからなくなります
f1を&'a &'b Tの参照がひとつ外せて&'b Tと考え
f0は'b:'aなので&'b Tから&'a Tに変換可能と考えると
f2が通ってf3が通らないことが理解できない
rust難しい。。
340:デフォルトの名無しさん
21/04/27 08:11:26.79 Xxuu6Rq/.net
>>326
だから作るにあたって参考になる資料とか実装例はあるのかって話なんだが
OSを作るみたいな資料はあってもその多くはCとアセンブラを前提としているし
それを参考にしたらC流になってしまうだろ
341:デフォルトの名無しさん
21/04/27 08:43:32.76 W9X9APV9.net
実用的なOSとしてはこの辺かな。
URLﾘﾝｸ(github.com)
あとは研究論文レベルでは、Rustの所有権システムをOSの権限管理周りに使って堅牢なシステムを作ろう、みたいなのもある。
342:デフォルトの名無しさん
21/04/27 12:44:22.23 /+bIFNU8.net
こんなんCで書いてるのと変わらんだろ。。
URLﾘﾝｸ(github.com)
343:デフォルトの名無しさん
21/04/27 13:52:57.49 B18ZzSzj.net
>>337
インラインアセンブリでもRustを使うとコンパイル時に強力なチェックが！
あるわけないよな…Cでいいと思います
344:はちみつ餃子
21/04/27 14:21:05.00 gsHoUi4w.net
OS 全体の中でも低レイヤ寄りの部分はしょうがないでしょ。
どうせほとんどインラインアセンブリなら C でもいいが Rust で駄目という理由にもならんし。
345:デフォルトの名無しさん
21/04/27 15:07:33.38 V9b4VlmB.net
>>339
Rustは書き辛いし、生成されるコードや意味解釈に闇がある。
346:デフォルトの名無しさん
21/04/27 15:26:51.13 +CyfYLC3.net
言語の設計思想をOS全体に広げて実用的に成功した例ってあるの？
LispOSみたいなのは全部失敗してるじゃん
Cはもともとアセンブラで書かれてたOSを高級言語で書き直せるように
言語自体を後から設計したものだからね
Rustがシステム記述言語として使われたいなら、Linusに意向に100%従って
言語仕様をどんどん書き換えていかないとダメ絶対
347:デフォルトの名無しさん
21/04/27 16:09:23.12 sPb/VVK7.net
ここまでRedoxの話を避けているのはなぜ
348:デフォルトの名無しさん
21/04/27 17:15:40.85 MBTyAJrN.net
Redoxとか使ったことないし……
349:デフォルトの名無しさん
21/04/27 19:00:31.49 UNWScvKY.net
>>341
forth?
350:デフォルトの名無しさん
21/04/27 19:17:36.18 SeQzLHjb.net
forthとかなつかしいなオイ
351:デフォルトの名無しさん
21/04/27 20:00:34.98 B18ZzSzj.net
FORTH作者「FORTHには申し訳ないことをした…」
ホントだよ！
FORTHがきちんとケアされ続けた世界線を見てみたい
352:デフォルトの名無しさん
21/04/28 00:25:46.13 zZPOP3tR.net
forthって今も使われとるのだろか。。
353:デフォルトの名無しさん
21/04/28 01:56:40.25 RzWjm9zz.net
昔はＢＩＯＳ とか forth で書かれてたけど今はどうかなー
354:デフォルトの名無しさん
21/04/28 03:06:12.66 k8H8q1SE.net
Rustは配列に添え字アクセスする時、必ず境界チェックされるよね？
355:デフォルトの名無しさん
21/04/28 06:10:01.83 Er4sy6AA.net
言語設計とOSが一体ていうのがどのくらいまでを指すかにもよるけど
Smalltalk は元々は言語=OSみたいなシステムだったな
356:デフォルトの名無しさん
21/04/28 10:12:57.76 HN4XQcog.net
>>349
言語仕様的にチェックされるかという意味ならYes
357:デフォルトの名無しさん
21/04/28 10:51:18.82 EDIdYwla.net
>>351
ライブラリの実装ではチェックされるようなコードになっているが
最適化で消えるかも知れないので実行時に必ずしもチェックされるとは限らないという意味？
358:デフォルトの名無しさん
21/04/28 11:29:39.09 1OyY1L+6.net
コンパイル時に境界チェックを外せると確定してない限り最適化しようが境界チェックはやる
359:デフォルトの名無しさん
21/04/28 13:16:17.19 BfdKSrwu.net
例のLKML見直してて思ったけど
unsafeなコードetcが不変条件を破壊した場合に対する安全な対処法って今なんかあるのかな
360:デフォルトの名無しさん
21/04/28 13:47:19.78 3EuQZ3Ew.net
こんなとこじゃね
URLﾘﾝｸ(doc.rust-lang.org)
361:デフォルトの名無しさん
21/04/28 15:27:12.87 jQpDsyge.net
二重投稿になるかも知れませんが、[0; n] で、n要素のi32 型の配列という
意味になるようですが、n が実行時にしか決まらない変数でも大丈夫ですか？
その場合、データ領域はスタック領域から確保するのでしょうか。
362:デフォルトの名無しさん
21/04/28 18:08:50.70 HN4XQcog.net
>>356
まずはリファレンスを
URLﾘﾝｸ(doc.rust-lang.org)
363:デフォルトの名無しさん
21/04/28 18:22:21.07 t+PzYqgO.net
>>354
不変条件の種類によるけど最悪 undefined behavior になるから対処は無理じゃないかな
コンパイラの最適化レベル落とすとかで振る舞いを予測可能にすることは出来るのかも
364:デフォルトの名無しさん
21/04/28 19:36:40.90 jQpDsyge.net
>>357
でも、Box::new([0; n])と書いた場合には、nはコンパイル時に決まらない値
でもいいの？
365:デフォルトの名無しさん
21/04/28 20:41:55.42 m2UbhZH5.net
いいに決まってんだろハゲ！
366:デフォルトの名無しさん
21/04/28 20:43:40.06 XWuZH88T.net
Vec::with_capacity使えよ
367:デフォルトの名無しさん
21/04/28 21:18:06.47 EDIdYwla.net
試せば2秒で分かるんだから試しなよ
368:デフォルトの名無しさん
21/04/28 21:32:36.01 lX6x7Umv.net
２秒で試してみろや
369:デフォルトの名無しさん
21/04/28 21:34:25.75 lX6x7Umv.net
うまくいかなかったとしてほかに問題がないか状況を切り分け周辺を調査
誤りのない環境を整備
学習内容を保存し整理
単純な文法ひとつでも最低３０分
370:デフォルトの名無しさん
21/04/28 22:27:00.95 GVcFAhra.net
Rustの場合
｢2秒で試せる｣ || ｢試すしたら2秒でわかる｣
error: 意図が曖昧です
Cの場合
｢2秒で試せる｣
｢2秒で試してみろやカス｣
371:デフォルトの名無しさん
21/04/29 00:40:38.91 xah6OenV.net
Golangが難しかったのでRustにきました
よろしくおねがいします
372:デフォルトの名無しさん
21/04/29 00:53:02.27 90w9Shfm.net
ゴールデンウィークに釣りですか
373:デフォルトの名無しさん
21/04/29 12:40:02.43 K/HFYMcp.net
Animal から、C++ の継承のようなことをした構造体(?)を Dog とした時、
Box<T> a; で T を Animalのようなものにして、a には、実際には Dog
への参照を入れるようなことは出来ますか？
374:はちみつ餃子
21/04/29 13:12:17.47 x0Vd7BP9.net
>>368
dyn かな？
完全に一致する機能というわけではないけど、
Rust ではトレイトに dyn キーワードを付けると (C++ で言うところの) 抽象クラスのように機能する。
375:デフォルトの名無しさん
21/04/29 13:33:28.09 K/HFYMcp.net
>>369
URLﾘﾝｸ(stackoverflow.com)
↑には、Questionの人の書いたのももしかしたら動作するかも知れないけど
Answerの人に従えば、以下のようにするのが正しいのかな？
trait Function {
fn value(&self, arg: &[f64]) -> f64;
}
struct Add {}
struct Multiply {}
impl Function for Add {
fn value(&self, arg: &[f64]) -> f64 { arg[0] + arg[1] }
}
impl Function for Multiply {
fn value(&self, arg: &[f64]) -> f64 { arg[0] * arg[1] }
}
impl Add {
fn new() -> Add { Add {} }
fn new_boxed() -> Box<Add> { Box::new(Add::new()) }
}
impl Multiply {
fn new() -> Multiply { Multiply {} }
fn new_boxed() -> Box<Multiply> { Box::new(Multiply::new()) }
}
fn main() {
let x = vec![1.0, 2.0];
let funcs: Vec<Box<dyn Function>> = vec![Add::new_boxed(), Multiply::new_boxed())];
for f in funcs {
println!("{}", f.value(&x));
}
}
376:デフォルトの名無しさん
21/04/29 17:34:51.47 HuHtKfqb.net
C++でis-a関係の継承使うデータはRustだとenum使う方が単純になるケースもある
struct AnimalData { ... }
struct DogData { ... }
struct CatData { ... }
#[non_exhaustive]
enum Animal {
Dog (AnimalData, DogData),
Cat (AnimalData, CatData),
}
この方法にも色々欠点はあるけど（クレートの外で新しいAnimalを追加できないとか）
trait使う抽象化が大袈裟だと思ったら考えてみて
377:デフォルトの名無しさん
21/04/29 17:51:11.31 GXfM8nV1.net
>>370
継承とは違うけど
そのユースケースはfnかFn使えば十分じゃないの？
let functions: Vec<fn(f64, f64) -> f64> = vec![|x, y| x + y, |x, y| x * y];
for f in &functions {
println!("{}", f(1.0, 2.0));
}
378:デフォルトの名無しさん
21/04/30 01:35:27.25 7VhEvZ/Q.net
>>372
簡単な例として書いただけで、同じ表示結果を得ることが目的ではないので
そういうこととは趣旨が違う。
さまざまな種類の多態なオブジェクトを1つのリストの中に入れるということは
オブジェクト指向に置いて基本的な概念の一つで、Polymorphismの基本なので、
継承的なものを使わずに同じ結果を書けたとしてもそれは違う。
379:デフォルトの名無しさん
21/04/30 15:35:29.77 dTeJW22U.net
ポリモーフィズムを理解してないようなやつでもRustをはじめるようになったんだな
380:デフォルトの名無しさん
21/04/30 17:06:26.25 8uDUVNfy.net
c++と同じで難しくてランタイム速度最強てなところが厨を呼び寄せてる
381:デフォルトの名無しさん
21/04/30 18:24:08.88 K785SuXO.net
C++やってたら配列のインデックスアクセスが安全かどうかや
ディスパッチがスタティックかどうかを普通気にするよね
382:デフォルトの名無しさん
21/04/30 20:47:52.42 eR/nI2gV.net
グーグルやMSが「Rust」言語でOS開発、背景に国家による諜報活動の影＝日経 xTECH中田敦
背景に国家による諜報活動の影っていう根拠が１つも示されてないんだけど、こいつの言ってることマジなん？
それとも日経新聞のおなじみの「飛ばし」によるクリック集め？
383:デフォルトの名無しさん
21/04/30 21:05:00.75 MgEdsK0p.net
GAFAMって言いたいだけ
384:デフォルトの名無しさん
21/04/30 21:27:01.84 8uDUVNfy.net
マイクロソフトがwindows書くのにc++使って後悔した話も知らん層が今も同じようなことやろうとしてんだろ。。
バカは歴史に学ばない。
385:デフォルトの名無しさん
21/05/01 00:25:31.33 6VZJr73m.net
これ見てたら、いきなり日本語で「ネコ」って出てきてびっくりした
URLﾘﾝｸ(www.programming-idioms.org)
実は、お前らの中の誰かが書いてんのか？
386:デフォルトの名無しさん
21/05/01 05:47:22.98 5xLRGYfU.net
>>380
URLﾘﾝｸ(www.publickey1.jp)
今、プログラムやる若い層じゃアニメとアニメに出てくる簡単な日本語は基礎教養だぞ
github見たらアニメキャラアイコンだらけだ
387:デフォルトの名無しさん
21/05/01 08:00:51.92 GEnkdmRT.net
NANI
388:デフォルトの名無しさん
21/05/01 17:02:13.98 1WejqaZh.net
>>379
>マイクロソフトがwindows書くのにc++使って後悔した話
興味有るので詳しく :
389:
21/05/01 17:21:37.61 m+tkSw04.net
>>379
流出したソースを見る限り、MS は C で Windows を書いていたようですよ‥‥
390:デフォルトの名無しさん
21/05/01 17:53:57.44 /Wzn7OVr.net
そういえば初期WindowsのWindow管理のサンプルコード見た記憶がある
ツリーリンクリストが構造体に埋め込む形で自作されてた
391:デフォルトの名無しさん
21/05/01 17:54:25.77 /Wzn7OVr.net
コードの８割方コメントだった
392:デフォルトの名無しさん
21/05/02 09:31:00.53 /RYlgP4n.net
The Windows Research Kernel AKA WRK
URLﾘﾝｸ(github.com)
393:デフォルトの名無しさん
21/05/02 09:42:02.70 3kB7D+rP.net
9割がCか
394:デフォルトの名無しさん
21/05/02 09:51:42.31 3kB7D+rP.net
まあLinuxもCと一部アセンブラだから似たようなものか
395:デフォルトの名無しさん
21/05/02 12:27:53.91 Jc9e5ibu.net
当時の言語状況からして他に選択肢なんかなかったと思うがねぇ。
他の言語選択してたら駆逐されてた可能性すらある。
396:デフォルトの名無しさん
21/05/02 12:37:35.62 anCj3LhS.net
NT kernelが開発されたのが1990年代か
C++も既にあったがまだ浸透してなかったかな
397:デフォルトの名無しさん
21/05/02 13:45:15.23 c1rmI49h.net
チュートリアルやってたらトレートオブジェクトってのの説明が意味不明級だったぜ
URLﾘﾝｸ(tourofrust.com)
なんじゃこりゃ
398:デフォルトの名無しさん
21/05/02 14:35:17.11 n4dQrb8u.net
>>392
Javaの知識があれば
trait object： interfaceとして渡されたオブジェクト
という感じで説明できるけど何か使い慣れた言語はあるかね
399:デフォルトの名無しさん
21/05/02 15:05:16.82 c1rmI49h.net
>>393
もしかしてExistential Container(和訳不明)が独立のオブジェクトとして括り出さている感じですか？
なおC#が一番使い慣れているのですが、この範囲ではJavaと大きく違わなさそうでしょうか・・・・
400:デフォルトの名無しさん
21/05/02 15:36:14.52 hSgvj4Ff.net
>>392
The Bookの該当箇所を読むのを勧める
Java/C#のインターフェースと基本的には同じだけど違う部分もある
URLﾘﾝｸ(doc.rust-lang.org)
その少し後に出てくるBoxのコードに出てくる
`animals: Vec<Box<dyn NoiseMaker>>`の
Box<dyn NoiseMaker>がTrait Object
Trait Objectは動的サイズの型なので&NoiseMakerやBox<dyn NoiseMaker>のようにポインタの形になる
そのチュートリアルは前後のページとどう関係があるのかについて説明がほぼないのでわかりにくいかもね
401:はちみつ餃子
21/05/02 15:50:22.98 VAfyzxcR.net
他の言語の概念と対応付けるよりはそれ自体として理解したほうがいいのは確かだと思う。
(理解できずに行き詰まるくらいなら雑な理解でも一旦前に進んだほうがいいかもしれんけど。)
言語機能ってひとつだけを取り出して使えるものじゃなくて、他の言語機能との連携の中で活きてくるものだから
個別の言語機能を他言語の言語機能と対応付けて理解しても綺麗に繋がらない感じがする。
402:デフォルトの名無しさん
21/05/02 15:58:09.22 TmCNx2ML.net
URLﾘﾝｸ(doc.rust-lang.org)
こっちじゃ`dyn Trait`のことをtrait objectと呼んでいるようだけど
というか俺はこれだと思ってた
Traitを実装する具体型の値のアドレスと、その型に対するTrait実装のvtableの組
403:デフォルトの名無しさん
21/05/02 16:04:49.31 n4dQrb8u.net
>>394
C#はあまり詳しくないけど、例えばListのAddRange関数の引数の(IEnumerable collection)が近いかな
AddRangeにはIEnumerableを実装してればどんな型でも渡せるはず（ArrayList、HashSet, etc）
これをAddRangeの視点で見ると、渡されたcollectionが実際に何の型かは分からないけど
IEnumerable（interface≒trait）を実装してることは分かってるから
そのGetEnumeratorを呼んでIEnumeratorを受け取ってそこから取り出せる要素を全部追加すれば
目的の動作は果たせることになる
このAddRangeの引数のcollectionがIEnumerableトレイトを実装したtrait objectって感じ
404:デフォルトの名無しさん
21/05/02 17:25:27.83 hSgvj4Ff.net
>>397
正確に言うとリファレンスに書いてる通りdyn Trait型のオブジェクトがTrait Object
&dyn TraitやBox<dyn Trait>はTrait Objectを指してるfat pointer
でも実用上は&dyn TraitやBox<dyn Trait>のfat pointerのこと自体を
Trait Objectというものとして理解したほうがわかりやすいので
The Bookや他の解説書でも区別してないのが多い
405:デフォルトの名無しさん
21/05/03 09:09:00.34 AyvebyYK.net
>>76
Visual Rust#やろ
406:デフォルトの名無しさん
21/05/03 11:04:52.91 L2uysNOu.net
URLﾘﾝｸ(marketplace.visualstudio.com)
407:デフォルトの名無しさん
21/05/03 15:28:19.67 lWPqbdGD.net
囲い込んでブラックボックス強要するあたりはMSと相性いいかもな
408:デフォルトの名無しさん
21/05/04 15:41:01.40 6lvPuDrb.net
facebookも財団に参加したのか
appleも時間の問題かな
intelとかのCPUメーカーにも参加して欲しい所だが
409:デフォルトの名無しさん
21/05/04 17:15:37.01 lMvsmKDJ.net
CPUメーカーが参加するとどういうことが嬉しいの？
LLVMなら分かるんだけど
410:デフォルトの名無しさん
21/05/04 20:03:06.80 6lvPuDrb.net
まあ元intelのエンジニアも開発に参加しとるけどね
411:デフォルトの名無しさん
21/05/04 20:33:44
412:.63 ID:PCq3WtR4.net
413:デフォルトの名無しさん
21/05/04 21:04:23.81 mgj/rIpW.net
rustが低レイヤーの開発言語としては覇権取りそうね
今から勉強しとくのが良さそう
414:デフォルトの名無しさん
21/05/04 22:09:05.61 mvlmOZ0b.net
低レイヤーの仕事をしたことないってのがよくわかるわ。
415:デフォルトの名無しさん
21/05/05 00:03:56.29 UOumGkwv.net
>>405
エンジニア個々人が参加するのは普通にあると思うんだけど
企業として支援することにどんなうまみがあるのかなと思って
ただ改めて思うとintelもソフトウェアたくさん出しててrust使う旨みはあるから支援する意味はありそうだね
416:デフォルトの名無しさん
21/05/05 01:46:02.42 E1emjEBd.net
SHやArmのRustコンパイラをメーカーが出たらｶﾞﾁ
417:はちみつ餃子
21/05/05 03:09:13.31 o0iQ7lyN.net
うまみっていうか、それが上手くいくかどうかなんて事前にはわからん。
ほどほどに有用そうなものに支援してたらどれかひとつくらいはいい感じって程度の話だろ。
418:デフォルトの名無しさん
21/05/05 05:31:11.89 rumk0idO.net
協力し合うと同時にあまり勝手しないように牽制するのも目的なので
419:デフォルトの名無しさん
21/05/05 12:35:13.44 UNdhfIGe.net
どうも頭の悪い輩が多いなと思ってたけど、
この言語、ある程度まではスクリプト的に書けるからなんだな。。
なんとなくおかしなこと言ってる奴の感覚がわかってきたわ。
420:デフォルトの名無しさん
21/05/05 13:37:38.31 ZpSbA1Y5.net
>>413
> この言語、ある程度まではスクリプト的に書けるからなんだな。。
短く簡単に書けるようにするのはRustの課題の一つだと思ってるので、どういう観点から「スクリプト的に書ける」とおっしゃるのか伺いたいです
よく比較に上がるC++よりはよっぽど記述量多くなるよね？
421:デフォルトの名無しさん
21/05/05 14:30:15.37 UNdhfIGe.net
そりゃautoなんかを使いまくった最近のスクリプト厨のc++ならそうだろうけれど、
普通に仕事で読むc++コードはそういう感じではないからね。
てかc++と一口に言っても年代で全く別言語だわ。
そういうスクリプト的な書き方をした場合、rustのがc++より快適に感じるのはまあわかるよ。
問題もrustのが少なく感じる。そういう書き方だけしてる場合はね。
422:デフォルトの名無しさん
21/05/05 14:59:14.54 ZpSbA1Y5.net
炎上学習法かってくらい何も理解してない感じでワロス
423:デフォルトの名無しさん
21/05/05 15:13:12.13 UOumGkwv.net
autoと動的型付けの区別が付いていない...?
424:デフォルトの名無しさん
21/05/05 15:19:43.76 nBZStdai.net
型再構築なんてむしろ厳格に型付けされた言語から生まれたんだが
425:デフォルトの名無しさん
21/05/05 15:21:51.15 2WIXJ/st.net
C#でvarキーワードが導入された時も
基本型の変数にvar使うのやめましょうみたいな規約を
意味不明な根拠で良い規約と信じて導入しようとする
おかしな人達がそこら中に居た
後にEffective C#かそこらの書籍で
ローカル変数はvar使えと明確に書かれるようになって
老害ザマァと思ったものだ
426:デフォルトの名無しさん
21/05/05 15:46:10.02 sMGymnD4.net
正義が世俗の愚劣さに屈した
427:はちみつ餃子
21/05/05 15:47:19.58 o0iQ7lyN.net
ローカル変数の場合は型がすぐ隣に書いてあるような状況だろうからな。
428:デフォルトの名無しさん
21/05/05 16:17:27.41 UNdhfIGe.net
ほらね。
好き勝手な自分流でコード書いてるだけで人のコードを読んでないのが丸わかりなコメントしてても
全く気づかないバカしかいない。
429:デフォルトの名無しさん
21/05/05 16:25:26.72 GNJam4rN.net
>>421
ようするに型情報を二重に書いてるようなものだよな
情報の多重化であり
小さなDRY�
430:ｴ則違反 こんな簡単な理屈を理解出来ない奴が不思議
431:デフォルトの名無しさん
21/05/05 16:30:24.49 sMGymnD4.net
書かれておらずメソッドで戻り値を取得するような場合
C#もJavaも型で呼び出し先が変わる仕組みなので
意図せずに処理の流れまで変わってしまう
432:デフォルトの名無しさん
21/05/05 16:44:03.35 GNJam4rN.net
>>424
お前は日本語勉強しろよ
普通に読解不能なんだよ
必要な所には型を書く
当たり前
不要な所に書いてると
「何故書いてるのだろうか？
何か理由を見落としてるだろうか？」
と注意深いプログラマを考えさせるのでエネルギーの無駄
433:
21/05/05 16:50:12.99 tRoHSHAj.net
>>416
＞炎上学習法
懐かしい言葉ですね‥‥
434:デフォルトの名無しさん
21/05/05 16:59:13.24 sMGymnD4.net
>>425
varにするようになったら全部varにするだろ？
435:デフォルトの名無しさん
21/05/05 17:40:56.63 iUhohRzs.net
>>416
相手してるお前も同罪やぞ
すぐ見分けつくだろ
436:デフォルトの名無しさん
21/05/05 18:09:53.05 UOumGkwv.net
VSCode + rust-analyzer だとletやメソッドチェーンのところに型が表示されるし
今時の開発環境使っていればローカル変数の型がぱっと見で分からなくて苦労することは少ないのでは
437:デフォルトの名無しさん
21/05/05 18:14:24.50 GNJam4rN.net
>>427
何を言っとるんだお前は？
右辺値と同じ型で「困る」時は型を書くに決まってるだろ
下手するとvarの仕様も理解せずに混乱した事を書いてんじゃないだろうな
438:デフォルトの名無しさん
21/05/05 18:51:20.46 cJbqSzge.net
ゲェーQZ居着いてんのかよこのスレ
バカなくせに出しゃばりでウザいからC++スレから出てくんなよ
439:デフォルトの名無しさん
21/05/05 19:01:51.22 sMGymnD4.net
>>430
後から右辺値の型が変わったら気が付かないうちに影響が波及するじゃん
440:デフォルトの名無しさん
21/05/05 19:41:05.57 E1emjEBd.net
var xの型が何であるかはxの初期化のときただ一度きりの右辺の型で決まるんｼﾞｬﾈｰﾉ
だとしたら後から右辺値の型が変わることに関して
varの導入で傷口が広がったことにはならない
441:デフォルトの名無しさん
21/05/05 19:44:32.97 E1emjEBd.net
二回目以降の右辺値はxに対する代入でしかありえない
それらはxに対して（暗黙の型変換等を経て）代入可能ならコンパイルが通るし、
代入不可能ならエラーになる。
xの初期化時にvarを使おうが使うまいが（明示的に型を書こうが）変わらない話
442:デフォルトの名無しさん
21/05/05 20:38:12.35 UOumGkwv.net
せめてletの話をしろよ
443:デフォルトの名無しさん
21/05/05 20:48:36.67 vgXZGrp9.net
RustのletはJS由来？ それともHaskell？
444:デフォルトの名無しさん
21/05/05 21:09:59.09 1EwqoC8k.net
JavaScriptにもletあるけど語源調べたら普通に英単語のletで短縮形ってわけじゃないらしい
445:デフォルトの名無しさん
21/05/05 21:24:20.68 ra+BilqN.net
BASICの時代からletはあったけどな
446:デフォルトの名無しさん
21/05/05 21:31:43.51 ZsCzZm1J.net
letはlisp系から始まったイメージ。
447:デフォルトの名無しさん
21/05/05 22:26:24.94 vWJ975z5.net
RustのletはML系由来だろ
448:デフォルトの名無しさん
21/05/05 22:44:48.04 UOumGkwv.net
最初のrustcはocamlで書かれてたくらいだしML系の影響は色濃そう
449:
21/05/05 22:49:49.94 tRoHSHAj.net
>>431
ｽﾚﾘﾝｸ(tech板:839番)
450:デフォルトの名無しさん
21/05/06 01:02:12.67 SpjdL+PT.net
let mut にするか var にするかの決定で、
目立たないけどRustに貢献した人という記事が最近書かれたので貼っとく
URLﾘﾝｸ(brson.github.io)
451:デフォルトの名無しさん
21/05/06 01:05:25.16 ut0g6JOd.net
>>443
3行でまとめて
452:デフォルトの名無しさん
21/05/06 01:35:02.38 SpjdL+PT.net
デイブ・ハーマン（Dave Herman）というECMAScript委員会のMozillaの代表者の人がいました。
リポジトリ上のコミットログでは目立ちませんが、彼の好みがRustチームの好みを作り、チームの組織と維持に重要な役割を果たしていました。
彼はチームの決定をほとんど穏やかに受け入れていましたが、let mut と var のどちらにするかについては var を使うというチームの決定に同意しませんでした。
453:デフォルトの名無しさん
21/05/06 01:36:11.91 V2I8vwdu.net
>>421
でも、
BYTE c = 'a';
と
let c = 'a';
では間違い易さが違う。後者は、int か BYTE か SBYTE か分からない。
454:デフォルトの名無しさん
21/05/06 01:37:37.69 V2I8vwdu.net
Rustだと、明示するには、
let c:i8 = 'a';
とキータイプが多くなってしまうな。
455:デフォルトの名無しさん
21/05/06 01:40:47.77 V2I8vwdu.net
例えばの話、演算子も優先順位が決まっているので、
if ( (a >= 5 && a <= 10) || (b>=10 && b <=20) ) {・・・}
見たいな条件も、優先順位の括弧を省略できるかも知れないが、勘違いや
記憶違いを防ぐために書いた方がいいと言われている。
int c = 'a';
char c ='a';
auto c = 'a';
ではやはり、autoはバグの原因になりそう。
456:デフォルトの名無しさん
21/05/06 01:47:50.96 V2I8vwdu.net
それと、型を明示した方が後から見たときにプログラマの脳内の想定もわかり易い。
float a = 1.0f;
float b = a + 5.0f;
みたいなものも、もし、
auto a = 1.0f;
auto b = a + 5.0f;
と書くと b は、double 型になってしまうかもしれないが、テストしても
間違いに気づかず、僅かに速度低下やメモリーを多く食ってしまう
かもしれない。また、思想にもよるが、1.0f などと書かずに
float a = 1;
float b = 5;
と書きたい人も居ると思う。これの方が、後から double 型に変えたときに
右辺を訂正する必要がないメリットもある。
457:デフォルトの名無しさん
21/05/06 03:19:29.71 EVf7RH7G.net
>>446
rustの文字リテラルはu8でもi8でもなくてcharな
それはそれとして型やら括弧やらを明示的に書くことは禁じられてないんだから書けばよいのでは
言語の問題というよりはコーディング規約でなんとかすべき領域かと
タイプ数が多くなるとかはデフォルトをどちらに倒すかの問題で世間の嗜好とずれてるなら多少手間がかかるのは諦めるしかない
458:デフォルトの名無しさん
21/05/06 03:21:51.36 EVf7RH7G.net
誤解を招きそうだから補足しておくとrustのcharはユニコードのコードポイントが格納される32bit符号なし整数型な
459:デフォルトの名無しさん
21/05/06 06:46:11.97 AMAuzv83.net
>>443
こういうのいいな
460:デフォルトの名無しさん
21/05/06 10:08:34.61 VcsxCBNr.net
>>445
var使おうとしてたってマジかー
let (mut a, b) = get_foo_tuple();
みたいなやつとかvarじゃ困るから必然だと思ってたのに
461:デフォルトの名無しさん
21/05/06 10:15:22.90 lmEaR3VD.net
>>445の要約の最後たぶん間違ってる
デイブ氏はキーワードを重ねるとmutableな変数の使用を躊躇させる効果が生じて
プログラマのコーディング方式の選択を咎めることになるから反対だったらしい
チームの決定は初めからlet mutで彼は（珍しく）反対したけど最終的には受け入れた
462:デフォルトの名無しさん
21/05/06 11:35:13.23 hCHdFqbq.net
つまり暗黙の型変換は癌
463:デフォルトの名無しさん
21/05/06 11:48:56.26 f
464:owE0ZYM.net
465:デフォルトの名無しさん
21/05/06 11:52:26.38 a37uwZNi.net
いないいない
466:デフォルトの名無しさん
21/05/06 14:35:25.59 SpjdL+PT.net
>>454
すまん、指示代名詞の指してる先を読み違えた
デイブ氏はvar押しだったんだな
467:デフォルトの名無しさん
21/05/06 16:00:35.75 acc3YL8w.net
タイプ数で優劣を決めようとするアホとは次元が違うな
468:デフォルトの名無しさん
21/05/06 16:31:20.99 q/dBsf9f.net
タイプ数は少ない方が問答無用で良い
469:デフォルトの名無しさん
21/05/06 17:13:47.97 EVf7RH7G.net
fn, ret, cont, break の時代に回帰するか
470:デフォルトの名無しさん
21/05/06 17:27:07.40 ut0g6JOd.net
タイプ数は少ない
って基本型が少ない言語が好みなのかと思った
471:デフォルトの名無しさん
21/05/06 19:28:16.24 fowE0ZYM.net
<?rust
println!("hello rust!!");
?>
472:デフォルトの名無しさん
21/05/06 21:17:13.93 O03dxxkK.net
>>448
型を明示したってバグるくせによく言うのぜ
473:デフォルトの名無しさん
21/05/06 22:42:35.79 pupGSg3O.net
タイプ数が少ないようが絶対良いんなら
むかしGAMEとかいうすべてのキーワードが1文字の言語があったからそれでも使え
474:デフォルトの名無しさん
21/05/06 23:22:18.38 fowE0ZYM.net
Rust ～地図にない場所～
475:デフォルトの名無しさん
21/05/07 03:50:05.38 vAByX/Kb.net
>>464
型明示はバグの軽減に繋がる。
>>465
絶対的に良いわけではないが、let a:i32 = 5; と int a = 5; だと後者の方が楽。
476:デフォルトの名無しさん
21/05/07 07:04:16.43 aU3MjDw9.net
>>467
intが32bitだといつから錯覚していた？
477:デフォルトの名無しさん
21/05/07 08:21:08.42 Dsa6ajo4.net
Announcing Rust for Windows v0.9
URLﾘﾝｸ(blogs.windows.com)
478:デフォルトの名無しさん
21/05/07 09:19:02.07 iG4irUX1.net
言ってる側から落とし穴に嵌っててワロタ
479:デフォルトの名無しさん
21/05/07 10:35:21.40 8IfDDxiK.net
let a = 5_i32;
型は右側だけで決めるのじゃ
両側で合わせるのは無駄、変更するときも面倒じゃろ
・・なに？
aがi32だと明示してバグを軽減したいじゃと？
それなら行を分けるのじゃ
１行にまとめるとせっかくの明示が埋もれてしまうからの
let a: i32; // この行の存在は大きいぞい
a = 5_i32;
480:デフォルトの名無しさん
21/05/07 12:08:53.04 B2UdQUpV.net
>>468
そこまでいうなら、int32 a = 5; や i32 a = 5; と書けばいい。
なお、Rustではこの書き方が出来ない。
481:デフォルトの名無しさん
21/05/07 12:20:12.52 B2UdQUpV.net
>>468
ちなみに、組み込み以外のほとんどのC/C++コンパイラでは、intは32BIT型。
デスクトップマシン用のC/C++では、32BIT/64BIT のどちらでも、intは、
32BIT型のはずで、少なくとも VC++では必ず int は 32BIT。
482:デフォルトの名無しさん
21/05/07 12:24:00.34 w+YL5YRG.net
>>472
int32_tな
483:デフォルトの名無しさん
21/05/07 12:51:05.27 B2UdQUpV.net
>>474
typedef int int32;
typedef int i32;
とすればよいだけ。
484:デフォルトの名無しさん
21/05/07 12:57:04.52 w+YL5YRG.net
>>475
それintが32bitじゃない環境でアホみたいにミスリーディングになるけど？
いい加減スレチだし「int32_t 標準ライブラリ」でググって理解したらこの話終わりにして？
485:デフォルトの名無しさん
21/05/07 13:31:50.44 B2UdQUpV.net
>>476
そんな基本的なことは当たり前で、そのような環境では、
typedef __int32 int32;
typedef __int32 i32;
とする。
486:デフォルトの名無しさん
21/05/07 13:40:18.27 8gopO5Ce.net
どういうバグを作る可能性があるかという点が共有されてないから議論空回りしている感
487:デフォルトの名無しさん
21/05/07 13:42:32.36 B2UdQUpV.net
というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
だと思ったんだ。もし、int32_t が使える環境で賢く使いたい人は、
typedef int32_t int32;
typedef int32_t i32;
typedef int32_t Int32;
などとすればいいという話。
前提とする知識が低すぎる人がいるから困る。
488:デフォルトの名無しさん
21/05/07 13:45:35.27 eN8Lkrsa.net
何を議論してるのか全然分からん
489:デフォルトの名無しさん
21/05/07 14:02:25.02 SIz+0gIF.net
1レス目で即NG
相手してるやつも同じカテゴリなので即NG
490:はちみつ餃子
21/05/07 14:03:01.68 xLSEaA6V.net
議論なんかするつもりがないんだろう。
491:デフォルトの名無しさん
21/05/07 14:40:46.39 r6L15P9a.net
>>479
>というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
>だと思ったんだ。
誰がどこでそんな話をしたのか
ログ辿っても全然分からない件
ついでに言えば
グローバル名前空間の中に標準ライブラリがブチ込む型名として
_tサフィックス以外あり得んので
何も馬鹿なことなんか無い
つーか本当に誰もそんな話してないな
これ突っ込んだら
どんなガイジレスを返すのか興味津々
>>480
論点不明のドッジボールだからな
今はどこでも似たようなやり取りが見られて
5ch終わってる感がハンパない
俺は句点付きが特に頭おかしいと思うけど
レスバ相手はEQがヤバイ感じだが
句点付きはIQがヤバイ
492:デフォルトの名無しさん
21/05/07 14:57:30.94 DUMB7Vls.net
メジャーなGUIアプリで使われているrust製GUIライブラリってなにがありますか？
GUI使いたいんですが長いものにまかれたいので
493:はちみつ餃子
21/05/07 15:02:55.52 xLSEaA6V.net
>>484
プラットフォーム (OS) によって違うんじゃない？
その中ではある程度に淘汰されてると思うけど、
あらゆる環境で万能な決定版は無いと思う。
494:デフォルトの名無しさん
21/05/07 15:53:14.60 B2UdQUpV.net
>>483
>句点付きはIQがヤバイ
実際にIQ150越えてるので、ノーマル一般人が理解できないだけではないか。
495:デフォルトの名無しさん
21/05/07 16:08:00.06 r6L15P9a.net
>>486
証拠うpしてくれ
ID付き画像とかなら最高だ
IQ150超えでもこんなガイジレスするのか
マジで興味あるわ
496:デフォルトの名無しさん
21/05/07 17:04:02.49 +x2jPaur.net
メモリ不足でカーネルパニックが起きることの問題がわからない
普通のパソコン用途に使われてたらユーザーランドのソフトがOOM Killerに殺されようがOS丸ごとクラッシュしようが作業内容が失われるのは変わらん
サーバー用途でも一部のプロセスが殺されて中途半端の状態で動き続けるよりいっその事OSまるごとクラッシュしたほうがいいと思う
497:デフォルトの名無しさん
21/05/07 17:16:13.01 8gopO5Ce.net
>>488
rustでLinuxのドライバー書く話？
メモリ不足時にどうハンドリングされるべきかは使い方によって違うので一律パニックするのは良くない
例えば例に挙げてるOOM Killerだってカーネルがパニックしたら実行されないわけで
498:デフォルトの名無しさん
21/05/07 17:22:12.18 r6L15P9a.net
>>488
何かあった時止まればいいシステムばかりじゃないだろ
ペースメーカーとか原子炉とか
細かいことは知らんけど
昔、組み込み屋のおっさんが最初から1Mぐらい確保して
何かあったらそれを解放してどうにかするみたいなこと言ってた
知らんけど
499:はちみつ餃子
21/05/07 18:25:34.58 xLSEaA6V.net
>>488
システムは単独で動いているわけではない。
カーネルがパニックすることがあって良いという前提で設計して、パニックしうる前提で運用できるならそれでも構わんのだが、
Linux のカーネルでパニックを許すなら今 Linux を基礎にしているあらゆるシステムの運用体制を見直さざるを得ない。
カーネルパニックが絶対に駄目というわけじゃないんだ。
(もちろん発生しないに越したことは無いが。)
Linux では起こさないという前提に皆が従っているので変えられないという話なんだよ。
500:デフォルトの名無しさん
21/05/07 18:53:57.67 XbWp/RIC.net
割り込みが飛んでくる環境で例外なんか扱おうとしたら普通に死ぬだろ
501:デフォルトの名無しさん
21/05/07 19:12:04.63 RYgnWswQ.net
>>488
失われる作業内容の範囲があるだろ。
クライアントOSのWindowsですらBSODで切れる奴が多かったんだから、サーバーOSでそんな考えが許されるはずがない。
502:デフォルトの名無しさん
21/05/07 19:35:24.51 FlZ9PpDj.net
差し当たりRustの言語を広く浅く学習したいのですが、「実践Rustプログラミング入門」の言語部分(100ページ程度)が分量が少なめで気になっています
この本で大きく抜けている文法や機能ってありますか？
503:デフォルトの名無しさん
21/05/07 20:06:32.24 xz5IWUMT.net
>>494
The Bookと比べれば一目瞭然
504:デフォルトの名無しさん
21/05/07 20:11:06.98 8H8V34/d.net
>>493
サーバーOSのほうがクライアントOSよりクラッシュには寛容だぞ
サーバー側の開発したことないのかな？
505:デフォルトの名無しさん
21/05/07 20:22:58.56 fmyiQrUP.net
>>496
最近は仮想化＆分散で寛容になっているの？
506:デフォルトの名無しさん
21/05/07 21:23:40.41 EDSX1EuR.net
>>494
最近の本だからasyncまであるし、そんなに大きな抜けはないかな
広く浅くならまぁいいんじゃないかと
もし細かい部分が気になったらthe bookで補完すればいい
507:デフォルトの名無しさん
21/05/07 21:36:25.19 7aFGtcIv.net
>>497
むしろchaos engineeringで積極的に落とす
508:デフォルトの名無しさん
21/05/07 21:52:45.82 Z7WMK8Ny.net
ペースメーカーとか原子炉とか、ノンストップシステムでは常に複数動いている
Kubernetes などでは、ネットワーク分断に備えて、
正常な状態を多数決で決めるから、3, 5, 7 みたいな奇数を動かす
2対2とか偶数だと、どちらが正常か判断できないから
509:500
21/05/07 22:00:09.91 Z7WMK8Ny.net
Netflix などは常に、システムを攻撃して落としたりして、テストしてる。
サイボウズのkintone は、毎日システムを破棄して、作り直しているとか
Kubernetes を使っているのかな？
510:デフォルトの名無しさん
21/05/08 00:03:29.89 4agfhhA1.net
非常時の処理はカーネルの中心部が決めることで
枝葉のモジュールに決定権はないという話なんじゃないの？
511:デフォルトの名無しさん
21/05/08 00:07:56.54 OofXJFgO.net
レイヤーがめちゃくちゃな話しとるな。
OSみたいなハードウェアに直触るものとkubernetesみたいな分散管理のソフトじゃ
全然話が違う。
実際kubernetesはGC付きのgolangが実装だろ。
512:500
21/05/08 01:02:28.51 P6P/nG6A.net
ノンストップシステムでは常に複数動く。
デュアルシステムとか
東証・富士通製のarrowhead は、3重だったかな？
それでも、ラックか何かの接続部分が落ちて、システムダウンした
ネットワークが集中している部分の故障が、最も怖い
513:デフォルトの名無しさん
21/05/08 08:40:46.17 e+sagIsH.net
>>492
なんでじゃ
割り込みルーチンに入るときの退避と出るときの復旧をきちんとやっていれば
割り込みルーチン以外の処理は割り込みルーチンが呼び出されることに対して透過的に動作できる
一部のハードなリアルタイムOSみたいに（多重割り込み前提で）割り込みルーチンから
通常コンテキストに直接「ジャンプ」してタスクをたたき起こすみたいなケースでもなければ割り込みの存在は
通常コンテキストで何をやろうと一切影響は無い
（もちろん割り込み禁止、みたいな直接割り込みに影響する命令を実行したら話は別だがそれは普通特権命令でOS以外は実行できな
い
カーネルでの例外が問題なのは、
例外機構を持たないCならスタックポインタの調整で済むところを
デストラクタがある高級な言語だと例外が通過する際に自動変数として構築されていたオブジェクトを
例外が通過する関数全てについて解放してやらねばならない
（それでいて一方、自動変数として構築される可能性はあっても
例外発生時に構築されていないオブジェクトに対しては何もしてはいけない
という点
これは例外を飛ばすだけでその経路全部が同一のコンパイラで書かれなければならないことを意味する
途中に手で書いたアセンブラのルーチンなどあろうものならスタックをぶち壊してハードウェアの例外でいきなり
落ちるということになってそんなことがOS内で起きたら計算機上の資源の安全が担保されない。
OSとしては失格である
514:デフォルトの名無しさん
21/05/08 08:53:39.11 e+sagIsH.net
、と思ったが
よく考えたら「手で書いたアセンブラのルーチン」があったらコンパイラはそれを知らない関数としてスタックポインタの調整以外のことを
しなかったら良いのかorz、
ここは「例外通過時にC++や異なるベンダーのRustコンパイラみたいな例外を捕捉する関数をコンパイルいたRustコンパイラが預かり知らない
巻き戻し処理が必要なルーチン」があったら、ということに訂正
、
515:デフォルトの名無しさん
21/05/08 09:44:38.32 9PfSgf27.net
なんだこいつ
IQ64だな
516:デフォルトの名無しさん
21/05/08 10:15:07.28 e+sagIsH.net
IQは関係無いやろうがｷﾞｷﾞｷﾞｷﾞｷﾞ、
517:デフォルトの名無しさん
21/05/08 11:11:59.29 52U5aUmg.net
JAVAみたいな言語があるからnewしたまま放ったらかしでメモリ管理もろくに出来ない馬鹿で溢れかえって居るんだよな
518:デフォルトの名無しさん
21/05/08 11:36:05.31 jLEsHVNz.net
ついさっき知ったけど、new() はT だけじゃなく Result<T> を返していいんだな
519:デフォルトの名無しさん
21/05/08 12:01:48.48 9PfSgf27.net
newはシンタックスじゃなくてただの慣例だからね
慣例ではResultを返すのはお作法に反するはず
520:デフォルトの名無しさん
21/05/08 12:03:38.57 OofXJFgO.net
別にjavaがない頃からそういうバカはいたけどね
521:デフォルトの名無しさん
21/05/08 12:09:19.46 rOsHiSsL.net
メモリ管理もろくに出来ない馬鹿
・Linuxカーネルにカーネルスタックメモリ内の情報を読み取られる脆弱性
・「WebKit」にゼロデイ脆弱性 ～「macOS Big Sur 11.3.1」や「iOS/iPadOS 14.5.1」などが公開
・BIND9に脆弱性、アップデートや回避策を
522:デフォルトの名無しさん
21/05/08 12:14:25.93 lGQPC/Vw.net
>>509
因果関係が逆で、
頭が悪くてその程度ももともと出来ない人は昔はCやC++でプログラムできなかった
がVBやJavaやC#やJSやPythonやRubyではできた。
523:デフォルトの名無しさん
21/05/08 13:11:23.63 RJ95z4qm.net
>>511
newとかfromでResult返すのたまに見かけるけど
どうするのがおすすめなの？
try_newとかtry_fromにするのが良いのかな
524:デフォルトの名無しさん
21/05/08 13:37:14.67 jLEsHVNz.net
>>511
ただの慣例じゃなくて、clippy先生の指導対象らしい
URLﾘﾝｸ(rust-lang.github.io)
Checks for new not returning a type that contains Self.
525:デフォルトの名無しさん
21/05/08 14:30:50.83 yMDwHl+j.net
手動でスタックポインタの調整ってバグや脆弱性の温床
526:じゃね？
527:デフォルトの名無しさん
21/05/08 17:15:39.08 3vrEhaHR.net
医療機器や原発の制御システムとかが不意にリセットしないとか思っている時点で
組み込みとか高信頼性システムとかを全く知らないんだなって思う
ああいうのは最悪暴走したらリセットして最低限の機能は提供出来るように
作るのが基本だからね。そうしないと想定外の事態がおきた時に詰む
528:デフォルトの名無しさん
21/05/08 17:18:46.34 jLEsHVNz.net
そんなコーナーケースの為に俺たちの使い心地が悪くなるようなら耐えられないな
529:はちみつ餃子
21/05/08 17:23:48.71 //zoyCL6.net
暴走した場合にでもうてる手札を用意しておくってのと、
暴走しないように細部まで検証しておくってのは両立する話
530:デフォルトの名無しさん
21/05/08 17:27:07.74 QshNNe4V.net
いうほどコーナーケースってほどでもないだろ。
割と考慮されて当然のケースだわ。
まあlinux単体がその品質を担保できてるとも思わんけど。
531:デフォルトの名無しさん
21/05/08 17:33:15.67 3vrEhaHR.net
原子力関係だけでなく航空機や宇宙機もだが制御不能になるのが一番ヤバイんで
バグ出しは常識的な範囲で行って、あとはリカバリ系に注力した方がシステムの信頼性は向上する
歴史的に見ても事故るシステムの多くはこの辺をガバっている事が多いし
532:デフォルトの名無しさん
21/05/08 17:57:46.72 e+sagIsH.net
別に
ハイテク旅客機が落ちるのは自動制御と手動操縦のモード切替仕様を
パイロットが熟知しておらず緊急時に操縦桿を奪い合う格闘になったから
であってソフトは仕様通りだった
『ハイテク飛行機はなぜ落ちるか』（ブルーバックス）のｲﾝｼﾃﾞﾝﾄの数々を見たらﾜｶﾙ
原子炉の制御系はそもそも暴走させないように金かけて形式検証する
人間が本気になったらどんだけバグをなくすために金と手間を掛けられるかというと
スペースシャトルのSSMEの制御装置のソフトがどんだけ徹底したデバッグが行われたかを見たらﾜｶﾙ
533:デフォルトの名無しさん
21/05/08 18:17:53.56 57+jEKOs.net
>>523
人間が使う物であればUIも当然システムに含まれる
判りにくいUIは良いシステムとは言えない
ソユーズや神舟はADA使ったりしていないけど
スペースシャトルより死人は少ない。米式が唯一の正解とは限らない
むしろスペースシャトルはシステム設計に失敗した例だろ
534:デフォルトの名無しさん
21/05/08 18:22:37.13 e+sagIsH.net
UIの仕様バグと>>518が言っている暴走する系のバグは話がちげう
535:デフォルトの名無しさん
21/05/08 18:36:29.80 57+jEKOs.net
組み込み機器でも多くのケースで不測の事態に備えてウォッチドックタイマを使うよね
トリガを何にするかやリセット時に何をするかは設計手腕が問われるところだけど
536:デフォルトの名無しさん
21/05/08 19:38:20.73 RJ95z4qm.net
>>516
fn new() -> Result<Self, T> は警告出ないよ
537:デフォルトの名無しさん
21/05/08 19:42:36.17 PnHrKWCk.net
newでResult返すのはいいけどfromは駄目だろ
というかFrom trait実装しろ
538:デフォルトの名無しさん
21/05/08 19:46:07.47 RJ95z4qm.net
>>528
そもそも impl From<T> Result<Foo, E> はcoherenceの関係でエラーになるよね
Intoはできるけど
FromStr なり TryFrom を使うべきというのはそう
539:デフォルトの名無しさん
21/05/08 20:23:33.19 jLEsHVNz.net
>>527
そりゃ Result はそこに書いてある a type that contains Self だからね
540:デフォルトの名無しさん
21/05/08 21:10:37.46 vIQ3GRO1.net
cのコードをrustに変換してくれるライブラリってありませんか？
541:デフォルトの名無しさん
21/05/08 22:23:50.74 8Oybw0Jl.net
>>531
c2rust
542:デフォルトの名無しさん
21/05/09 12:16:13.70 RMo+m9mc.net
その場合誰がRustコンパイラと戦うんじゃ……
543:デフォルトの名無しさん
21/05/09 13:34:11.17 DdW1Qm5g.net
1.52来てたのね
544:デフォルトの名無しさん
21/05/09 23:13:05.64 T2j6cCMq.net
例外処理って何が有難いの？Cでプログラム書いてて例外がなくて困ったことないんだけど
もしかしてただのシンタックスシュガー？
545:デフォルトの名無しさん
21/05/09 23:31:00.87 LUIc58fP.net
戻り値の設定に近いものを一箇所にまとめられる。
546:デフォルトの名無しさん
21/05/10 00:03:43.87 sciUqTyU.net
どのレベルの話？
初心者の質問だとすると、関数の失敗を成功と区別するため。
戻り値で区別するんでなくて仕組みで。
547:デフォルトの名無しさん
21/05/10 00:10:05.03 EWDopcLj.net
例外の存在意義が分からない
戻り値で判別する方が可読性も高いし何も不足を感じない
548:デフォルトの名無しさん
21/05/10 00:21:25.87 giJ6lOgz.net
>>538
スレチ
549:デフォルトの名無しさん
21/05/10 07:17:37.24 aMiH/GVN.net
fileへのwriteとか毎行エラーチェック入るのしんどい
550:デフォルトの名無しさん
21/05/10 10:07:49.01 ro06Xyvc.net
>>538
開いた後、必ず閉じる処理が必要な場合があるが、それをxとすると、
関数のある場所でエラーを発見した時、呼び出し元へ返りたくても、
xを閉じてからでなくてはならない。xが複数有ったり、今後もxの
量が増えていくような場合、エラーが起きる場所全てでxを正確に全て
閉じてからreturnするのは難しい。なので、昔から、xを閉じる処理は
関数の最後の方に書いておいて、その直前にラベル lab_ex:; のような
ものを書いておいて、エラーが起きたときにはlab_exにgoto文
で飛ばすようなことが行われることが多かった。
でも、goto文は好まれ無い事があって、
try, catch 構文を使うと、goto文を使わなくてもそれが出来るようになる
ことが例外処理の一つのメリット。
551:デフォルトの名無しさん
21/05/10 10:12:49.59 ro06Xyvc.net
>>541
BOOL func()
{
BOOL rc = TRUE;
open_some(x);
if ( !func2() ) {
printf( "エラーだよ\n" );
rc = FALSE;
goto lab_ex;
}
・・・
lab_ex:;
close_some(x)
return rc;
}
↑のようなものが、例外処理を使えばgoto文を使わなくても書けるようになる。
ただし、goto文が何でそんなに嫌われるかは謎と言えば謎ぞの一つではあり、
lab_ex:; が見た目的に「浮く」からではないか、という説がある。
しかし、論理構造的にはgoto分がそんなに分かりにくいわけではない。
552:デフォルトの名無しさん
21/05/10 10:13:54.77 Pi5UB1M6.net
そういやCで bail: ラベルが多用されてたなーっていうのを
anyhowクレートの bail! マクロで思い出した
553:デフォルトの名無しさん
21/05/10 10:16:15.81 pIvV80n0.net
>>541,542
クソスレチ
554:デフォルトの名無しさん
21/05/10 10:23:18.20 ro06Xyvc.net
>>542
例外処理を使った場合、goto文が要らない：
BOOL func()
{
BOOL rc = TRUE;
open_some(x);
try {
func2() ; // 例外発生の可能性有り
func3() ; // 例外発生の可能性有り
}
catch(...) {
printf( "エラーだよ\n" );
rc = FALSE;
}
close_some(x)
return rc;
}
555:デフォルトの名無しさん
21/05/10 10:23:53.36 ro06Xyvc.net
>>545
ただし、この場合、x をクラスのオブジェクトで、x がデストラクトされる
時に自動的に close_some()を呼び出すようになっていれば、そもそも
goto文は不要なので、例外処理でやらなくても最初からgoto文が現れない。
しかし、すべてがクラスオブジェクトになっているわけではない。
典型的な例は、
BOOL last_flags = g_flags;
g_flags = 一時的なフラグ設定;
・・・
if ( xxx ) {
// エラー発生:
rc = FALSE;
goto lab_ex;
}
lab_ex:;
g_flags = last_flags;
return rc;
のようなもの。
556:デフォルトの名無しさん
21/05/10 10:40:58.67 u82ImyiI.net
後藤さんいい加減にしてくださいよ…
557:デフォルトの名無しさん
21/05/10 13:07:54.71 H09R880S.net
Linuxや*BSDなどのカーネルはgoto文が誰に遠慮することもなく堂々と使われてますよ
そして可読性は何も損なわれていない
言語屋さんだけじゃないの？構造化でgotoがどうたらとかそれに代わる言語機構が
必要だとか言ってるのは
そして新たに言語を学ぶ人が無批判にそれらを盲信することが代々続いてる
ようにしか見えない
558:デフォルトの名無しさん
21/05/10 13:38:27.10 FH4+0Y9S.net
多くの言語はハードウェアとしてCPU例外や、I/Oに対する入出力の（ハードウェア的）例外と、多くは
復帰可能なエラー分岐処理にて、プログラミング言語で「包括的に捕捉して後処理」するためにある。
例外の反対者はResult/Option/(Either)のようなものがあるのに、なぜ言語に例外を取り入れて、信頼性を
低下させるような隠された制御フローを導入するのかと主張します。
しかし例えばファイルへの出力で"fwrite"ではOSの上層では実際に書き込まれず、"fclose"で書き込まれたり
あるいは"fflush"でメモリー上とディスクが同期されるなどは、同期的な、従来の戻り値を確認しただけでは
正確な判断ができない。（これは言語のライブリーがBufferを使用しているとは別の話、たとえばディスク
容量が足りなくなった場合など、意図するプログラムは失敗する可能性があります。）
またResultなどが使用できるの場合は、ハードウェアやIOに依存しない場合にできるだけです。他にも、不正な
ゼロ除算などの発生は、カーネルでも、組み込みでも、CPU例外に対しては特定の例外の種類によりあらかじめ
決められたアドレスに強制的にジャンプします。C言語自身はCPUの挙動を定義していませんので、この制御の
フローの移動はCプログラミング言語の機能ではなくCPUメーカーの実装です。
つまり、標準のC自体だけでは、統一的にエラー処理を記述するということ自体が出来ていませんし、実行制御
フロー記述し完全掌握してコントロールするという事自体があやふやです。
（ゼロ除算でジャンプしなくてHALTするようなCPUがあるかもしれませんが知りません）
559:デフォルトの名無しさん
21/05/10 13:43:11.18 FH4+0Y9S.net
多くの例外がある言語(RustやGoのpanicも含む)では、上記の例ではファイル出力とは無関係な処理でも
即座に後処理へ移動します。ですが、ここに1つの問題があり、多くは捕捉した後にほぼ「自動的に」
ディストラクタに記述された処理をスレッド毎に存在するスタックを遡って巻き戻しを行います。
（例外の反対者はこれを隠された制御フローというが、決して信頼性が低下するわけではないです、
カーネルの例外ハンドラを例に挙げれば、ただ挙動が合わない事と、多くの例外がある言語でのCPU例外の
捕捉はリカバリが不可能に近く、挙動が保証できない事でディストラクタ実行させて意味があるのかという
矛盾もあります）
それ以外の例外処理は概念的にはスレッドローカルグローバル変数とifとgoto/returnの組み合わせにしか
ならないので信頼性が低下したりはしません�
560:Bまた、C言語や昔の言語でgotoが嫌われていたのは、ラベルが 存在しないgotoだったりループ中のgotoだったり、プログラムのモジュール化を壊す制御であったためなども あります。try-catch-finallyとは無関係ですが、同様に可読性が悪いように見えてしまうため、冤罪にされます。 そもそもアセンブラであればJMP命令にしかならない事をいつまでもグチグチ言うのは悪い癖です
561:デフォルトの名無しさん
21/05/10 15:15:38.71 ro06Xyvc.net
>>550
後半、BASIC言語を振り返ってみると、ラベルの無いgoto文はむしろラベルありより綺麗に書けていた。
gosubはラベル方式の方が良かったが。
Cのgotoはラベルが必須なのでラベルが浮いてしまって嫌われているという説がある位。
562:デフォルトの名無しさん
21/05/10 15:18:53.59 ro06Xyvc.net
例外処理の問題点は、
try {
f1();
・・・
f2();
・・・
f3();
・・・
f4();
・・・
}
とtryブロックの中に沢山の関数呼び出しが有った場合、コード上ではどこでも例外が
起きる可能性を捨てきれないため逆に危険な可能性を排除しにくいことがある。
例えば、fputc()やfwrite()などで例外が起きることが分かっているならそれはそれで
良いが、全く関係のないf1, f2, f3, f4でもどれかは例外が起きる可能性があるなら
非常にプログラミングしにくい。
563:デフォルトの名無しさん
21/05/10 15:21:55.24 ro06Xyvc.net
>>551
例えば、BASICでは以下の様な感じになるので、ラベルが無い事でむしろすっきり
見易かった。gosub文はまた別でいまの関数の様な感じで名前が付いている方が
分かり易かった。これは経験を積まないと理解しにくいかも知れない。
100 if xxx = yyy goto 120
110 ・・・
120 ・・・
564:デフォルトの名無しさん
21/05/10 18:35:05.49 mFjZyrFq.net
>>548
構造化の無い暗黒時代に戻りたくないわ。
制御構文と構造化設計を破壊するぐらいならgoto使わないほうがマシ。破壊しない程度だったら許容できるかね。
565:デフォルトの名無しさん
21/05/10 18:45:12.97 QB4+qLHE.net
Rustは学習コスト高いって言われてるけど
Scala辺りと比べても難しいですか？
566:デフォルトの名無しさん
21/05/10 19:40:11.34 RQLzh3xR.net
>>555
別に特別難しいわけではないと思う
いろんな言語からパクってきてる要素が多くて、これまで一つの言語しか使ったことない人は学ぶべきことが多いってだけで
ScalaとC++くらい経験あれば余裕だろう
567:デフォルトの名無しさん
21/05/10 21:15:30.50 aMiH/GVN.net
コンパイラの文脈解析がこんだけ普及したのだから
safe gotoが存在するべきだ
568:デフォルトの名無しさん
21/05/10 21:21:46.54 10iSv1/R.net
言語自体よりも、情報技術の基礎が要求されるんじゃないの
569:デフォルトの名無しさん
21/05/10 21:38:27.66 +CGjcQmG.net
>>555
やってみるのが一番早いよ
URLﾘﾝｸ(ideone.com)
こーいうところを使うとPC側にコンパイラとか用意せずに試せる
570:デフォルトの名無しさん
21/05/10 23:10:53.18 Ai0jiWQm.net
>>559
>>1にもあるけどURLﾘﾝｸ(play.rust-lang.org)のほうがいろいろ充実してる
てかideoneは1.33.0とかなのか、結構古いね
571:デフォルトの名無しさん
21/05/10 23:22:34.42 rt96Jr4B.net
playground、いつのまにか以前書いたコードが残るようになっててなんかうざったいんだけど、
初期のhello worldの状態に戻すのってどうやるの？（クッキー削除とかはなしで
572:デフォルトの名無しさん
21/05/10 23:29:40.57 4UvCiOpM.net
んな面倒なことするくらいならrustupインストールすりゃええやん
573:デフォルトの名無しさん
21/05/11 00:01:56.34 bFiGc/cl.net
>>549
ファイルへの書き込みは返り値promise等でもらっておいて他の作業を進めて
どうしても書き込み完了していないと作業を先へ進めてはいけないところでようやくawait等することで
例外処理も遅延(手続き的な後ろ化と多段時の上位化)ができますよね
あとOSカーネル内の話は
例外と割り込みをごっちゃにしているように見えます
いずれにせよカーネル内ではtry例外使わずとも多段にエラー返り値を返していけばいいだけでしょう
エラー割り込み時もメモリ不足もシステムコールならエラー値返すわけですし
574:はちみつ餃子
21/05/11 02:56:09.45 sf6ddr3r.net
>>555
Rust はそれほど難しいというわけでもないと思う。
C に ML 風の型システムを付けたって程度。
普通のプログラマにとって目新しいと言えるのはライフタイムの概念くらい。
でもそのひとつが馴染み無さ過ぎるというか、
他の言語では意識せずに済まさせようとしてきたところを
あえて露骨に管理しようとしてるところがしんどいとは感じるかもね。
575:デフォルトの名無しさん
21/05/11 03:24:21.67 BXZYJdJz.net
>>564
Rustのライフタイムは、鶏と卵の関係の様な部分で言語の動作が分からない。
どっちがどっちに影響を与えているのかの部分が。
自動判定の仕組みも一部だけ説明されていて一般法則が書いておらず、その場しのぎ的な言語仕様なのかもしれない。
576:デフォルトの名無しさん
21/05/11 04:47:35.34 +XHXxVLE.net
non lexical lifetimeでググれば詳細な仕様出てくるだろ
577:デフォルトの名無しさん
21/05/11 05:08:47.84 BXZYJdJz.net
>>566
出てこないと思うが。
578:デフォルトの名無しさん
21/05/11 08:24:36.99 hJ8vQWaq.net
>>561
通りすがりですが、保存せずにただ試すだけなら
1.シークレットモードで新規タブ
2.playgroundのサイトを開く（ブックマーク登録からとか）
3.コード入力かコピペ作業
でどうでしょうか?
579:デフォルトの名無しさん
21/05/11 10:55:34.68 nxCZKmfr.net
>>567
nll rfcで検索したら出てくるよ
580:デフォルトの名無しさん
21/05/11 12:37:05.27 BXZYJdJz.net
>>569
そこには例が書かれてるだけで、数学みたいな意味でのちゃんとした厳密仕様は書いてないと思うんだよ。
Rustのライフタイムは数学規則のように機械的にパターンで処理できるような一般化された規則にはなってないという意味において。
581:デフォルトの名無しさん
21/05/11 12:42:48.49 yczyG8TY.net
厳密な仕様があるのは理想だけど、規格化された言語ですら数学的に厳密な仕様なんて存在しないしな
最終的にはCoqのソースコードで示される、とかはあるかもしれないが
582:デフォルトの名無しさん
21/05/11 12:47:18.80 BXZYJdJz.net
>>571
CやC++は数学的なパターンで処理できるようになってる。
そこにヒューリスティックなものは入ってない。
583:デフォルトの名無しさん
21/05/11 12:55:41.33 r1e7nJBc.net
the abstract syntax tree でのライフタイムの解析から
the control-flow graph でのライフタイムの解析にしたって言ってるから
かなりマシン語に近いとこで判定してるってことだわな。
ここにいる奴に聞くだけ無駄w
584:デフォルトの名無しさん
21/05/11 18:36:37.89 efUOVNNI.net
>>571
純lispくらいかね。
あるいはBrainfuckとか。
585:デフォルトの名無しさん
21/05/11 18:56:14.78 jWdOrz94.net
issue #25860って未だに解決されてないんだよね？
行きあたりばったりでライフタイム仕様決めてきた結果w
586:デフォルトの名無しさん
21/05/11 19:03:56.93 wl2jzTgT.net
Rustと原子力発電は人類には早すぎたんや…
587:デフォルトの名無しさん
21/05/11 19:52:59.74 8+nUEbRM.net
Rust嫌う人ってなんでみんな #25860 の話するのって言われてんぞ
588:デフォルトの名無しさん
21/05/11 22:03:42.47 1AWmjfgF.net
>>576
太陽光発電は、ある意味原子力発電と言えるのではないだろうか。
589:デフォルトの名無しさん
21/05/12 08:51:30.06 1N4enQMj.net
Rust 2021 Editionは10月リリース予定
URLﾘﾝｸ(blog.rust-lang.org)
590:デフォルトの名無しさん
21/05/12 10:38:41.98 qFi3vx5o.net
1.56.0からか
591:デフォルトの名無しさん
21/05/12 10:40:17.60 1N4enQMj.net
2021 Edition ざっと読んでみたけど、次の2点以外は些末な変更だな
for e in [1, 2, 3] {}
がエラーにならなくなる
(IntoIterator for arrays)
クロージャーが構造体をフィールド単位でキャプチャーするようになる
(Disjoint capture in closures)
592:デフォルトの名無しさん
21/05/12 21:45:20.66 rLfxFtSp.net
2018で勉強してますが仕様変わりますか？
593:デフォルトの名無しさん
21/05/12 22:08:40.92 fyx4mRuh.net
URLﾘﾝｸ(www.google.com)
「Windows用Rust」のバージョン0.9がリリース
何か誤解を与えそうな記事タイトルだ
594:デフォルトの名無しさん
21/05/13 00:09:46.25 JmJXN960.net
リポジトリ名的にwindows-rsのが適語か？
595:デフォルトの名無しさん
21/05/13 00:34:31.53 hcgdol/O.net
>>582
マイナーチェンジだし2018も継続して使えるし特に問題ないよ
596:デフォルトの名無しさん
21/05/13 00:46:54.51 oO6nJ4P1.net
何年か前なら喜んでたんだけどな、どうしよ何の興味も沸かない
Docker触り始めた辺りからWindows用は趣味でも書かなくなってしまった…
597:デフォルトの名無しさん
21/05/13 07:59:13.00 OSZsGS3x.net
>>583 多分windowsクレートの説明文のRust for Windowsの直訳だとは思うけどこれは誤解するわ
598:デフォルトの名無しさん
21/05/13 11:06:57.34 mHvpW2NY.net
Rust for Windowsという名前がミスリーディング
(A) Rust (crate) for Windows (development)をRust for Windowsに略したら誰でも誤解する
狙ってるのかもしれないが
Windows API bindgen for Rustあたりが適当
599:デフォルトの名無しさん
21/05/13 12:50:12.69 OSZsGS3x.net
このクレート普通にソフト作るのに使ったら移植性無くなるからライブラリ用かな?
600:デフォルトの名無しさん
21/05/13 14:22:28.44 p1C3K64x.net
防衛省が中国のハッカーとやり合える人材を募集中 年収最高２０００万円
ｽﾚﾘﾝｸ(poverty板)
601:デフォルトの名無しさん
21/05/13 14:34:12.09 EmFUnxGS.net
クラッカーにうってつけじゃないか
602:デフォルトの名無しさん
21/05/13 15:04:14.32 67slJFqF.net
年収最低はいくらからですかね
603:デフォルトの名無しさん
21/05/13 15:10:36.53 ENK4De8l.net
最高が2000万円ってだけね。。
こういうので平気で300万円とかいい出すのが今の日本やで。
604:デフォルトの名無しさん
21/05/13 18:36:08.63 hcgdol/O.net
>>589
Windows専用のアプリを作る用途もあるのでは
一般的ではないかもだけど
605:デフォルトの名無しさん
21/05/13 18:39:15.84 oBGJ4/nI.net
Rust for Windowsを欲しがったのはMicrosoft自身だろう
既にVSのインストーラー内部などでRust使用中なので
606:デフォルトの名無しさん
21/05/13 19:27:59.33 4YggBXb4.net
rust for windowsで作る本作ってくださいお願いします
607:デフォルトの名無しさん
21/05/13 19:29:13.29 vZYCxDQa.net
>>594 Windows専用のアプリが作りたいならC#でも使えばいいと思うけど...
608:デフォルトの名無しさん
21/05/13 19:3
609:0:20.99 ID:vZYCxDQa.net
610:デフォルトの名無しさん
21/05/13 19:30:58.76 vZYCxDQa.net
おっとミスって2回書き込んでしまった
失礼
611:デフォルトの名無しさん
21/05/13 20:59:04.54 vzWwtH6K.net
>>590
そういう技術者にも射撃練習とかやらせるのだろうか？
612:デフォルトの名無しさん
21/05/13 21:40:48.09 NNemQTGQ.net
>>595
もうメジャーな用途で使われてんのか
613:デフォルトの名無しさん
21/05/13 21:45:54.80 vzWwtH6K.net
windowsもそろそろNTカーネルを捨てる時期が来るだろうし色々模索はしてるんだろうな
614:デフォルトの名無しさん
21/05/13 21:57:03.92 WjgS+eLl.net
もし仮にNTカーネル捨てたとしてLinuxカーネル一択だと思うがな
615:デフォルトの名無しさん
21/05/13 22:08:50.47 vzWwtH6K.net
Linuxへの接近はここ数年目立ってるし無くはない話だな
独占市場と過去の互換性を捨てきれるか
仮想環境で過去の互換性を維持することも考えられる
616:デフォルトの名無しさん
21/05/14 08:10:59.62 FBkeGRqg.net
>>604
NTカーネル捨てるのはビジネスとして有り得ない。
せいぜいwsl路線を強化してlinuxカーネルを取り込んでいく方向だろ。
617:デフォルトの名無しさん
21/05/14 08:37:43.19 BI4FO4HO.net
カーネルを捨てて切り替えるとか出来るわけないだろ
618:デフォルトの名無しさん
21/05/14 08:52:11.24 9b8NT0Ot.net
3才児が｢ぼくはうちゅうひこうしになるんだ！｣って言ってるようなもんだから生暖かく見守ってやれ
619:デフォルトの名無しさん
21/05/14 10:22:28.00 6SQ932Rj.net
OSカーネルに対するコンプレックスがすごい人がいるんだろ。
この前のlinuxドライバに関する議論でもそういうの感じるわ
620:デフォルトの名無しさん
21/05/14 11:10:24.23 bMDjGf5Y.net
rustがgolangより人気が出ると思っていいですか？
621:デフォルトの名無しさん
21/05/14 11:14:13.19 5xLewDJ4.net
>>609
Goはガーベッジコレクションがあるから？
622:デフォルトの名無しさん
21/05/14 11:29:33.68 6SQ932Rj.net
GCとランタイム速度に困ったことのある奴だけ気にすればええ。
623:デフォルトの名無しさん
21/05/14 13:23:04.93 TMXA3cLH.net
goとrustどっちが良いか迷うならgoやっといた方が潰しが効くと思う
自分はrust好きだからrust使うが
624:デフォルトの名無しさん
21/05/14 14:57:53.07 85G96vHL.net
両方やっとけ
625:デフォルトの名無しさん
21/05/14 15:16:48.50 678S/iU6.net
なんでマイナー言語のはずのgoがよく言及されるようになったのかと思っていたら、AWSで使える言語の一つになっていた。
Azureでも使えるようだ。
626:デフォルトの名無しさん
21/05/14 15:45:19.02 WB7bczPS.net
goがマイナー。。。..
627:デフォルトの名無しさん
21/05/14 15:46:03.80 BI4FO4HO.net
サーバープログラムみたいな閉じた環境で、出来るここまでと決まってて
要らないこと考えたくないなら制約された言語選んだほうが良いかもな
628:デフォルトの名無しさん
21/05/14 15:47:17.23 6SQ932Rj.net
goでほとんど問題ないんだが、それだとrustの出番なくなっちゃうからね。
629:デフォルトの名無しさん
21/05/14 16:15:48.73 1T0ViQH9.net
Go言語がマイナーならこの言語はどんだけマイナーになっちゃうのよ
630:デフォルトの名無しさん
21/05/14 16:25:56.91 Z0ePaP6y.net
goとrustの違いが分からないような知識量ならgoやった方が不幸にならないかと
631:デフォルトの名無しさん
21/05/14 16:48:29.92 678S/iU6.net
参照型はローカル変数にだけ入れて一時的な目的だけに使うことに徹してスクリプト言語の様な書き方だけに専念すればRustはスクリプト言語であるかのように使えて、習得は難しくないかも。
参照型を構造体の中に入れようとしたとたんCやC++では考える必要の無かった難しい問題が生じる。
632:デフォルトの名無しさん
21/05/14 17:00:31.58 dvkZe6EK.net
メジャー言語
c java vba
633:デフォルトの名無しさん
21/05/14 17:40:01.47 N2rlLeCr.net
Rustを勉強したら低レベルが理解出来る！！！わけねえだろ
URLﾘﾝｸ(www.akiradeveloper.com)
634:デフォルトの名無しさん
21/05/14 19:36:04.21 5xLewDJ4.net
例えばWeb系ならばRustがベスト
WasmでGC抱える言語をわざわざ選ぶメリットないからね
635:デフォルトの名無しさん
21/05/14 19:44:16.91 6SQ932Rj.net
こういう詐欺師が普通におるからrustは信用できんわ
636:デフォルトの名無しさん
21/05/14 19:51:45.41 WB7bczPS.net
rustに対するコンプレックスすごい人いるね
637:デフォルトの名無しさん
21/05/14 20:26:02.54 0Bqgd+6M.net
詐欺師はどこにでもいるからな
とはいえ、webならwasmは正しくないとは思うがwasmならrustは結構正しいと思う
638:デフォルトの名無しさん
21/05/14 20:32:01.67 6SQ932Rj.net
wasm,rustでまともに開発してたら絶対そんなこと思わんわ。。どいつもこいつも馬鹿すぎる
639:デフォルトの名無しさん
21/05/14 20:40:33.59 WB7bczPS.net
それで、どんなまともなものを作っているんですか
640:デフォルトの名無しさん
21/05/14 20:46:14.11 5xLewDJ4.net
>>624
とこが詐欺？
あなたはWebブラウザ上のWasmでRustではなくGoを用いているのですか？
641:デフォルトの名無しさん
21/05/14 21:18:15.11 TMXA3cLH.net
>>627
それはあなたがまともにrust使えてないだけなんじゃないですかねぇ
642:デフォルトの名無しさん
21/05/14 21:22:56.09 yxEaYkUD.net
話が具体的で説得力がある
643:デフォルトの名無しさん
21/05/14 21:38:43.40 2w1FBHD8.net
>>572
形式的に書けているのは構文規則だけで
意味規則は自然言語で書かれているやんけ
644:デフォルトの名無しさん
21/05/14 22:59:38.34 R2Ezzb7N.net
「Rustはスクリプト的に書ける」とかいう謎の言葉言う奴沢山いるけどなんぞ？
同一人物か？
645:デフォルトの名無しさん
21/05/14 23:07:50.74 TMXA3cLH.net
我々が知らないところでevcxrが流行ってるのかもしれない
646:デフォルトの名無しさん
21/05/14 23:23:46.43 72ZodHJE.net
google謹製のREPLね
エベクサ？
647:デフォルトの名無しさん
21/05/15 02:09:59.05 BphhllcO.net
>>633
Rubyと同じようなメソッドチェーンを使ったコードを見かけたから。
648:デフォルトの名無しさん
21/05/15 03:17:16.69 vuo6fbRn.net
ドットでメソッド呼び出しする言語は大概そういうライブラリ設計あるでしょ
649:デフォルトの名無しさん
21/05/15 11:05:39.24 DTE+piln.net
>>637
C++やJavaでは見たこと無い。
JSでも余り見かけない。
650:デフォルトの名無しさん
21/05/15 11:12:58.76 Y+SvMVkX.net
そもそもメソッドチェーンって「スクリプト的」なのか？
651:デフォルトの名無しさん
21/05/15 11:24:14.14 C+CtGbiq.net
前々からヤベェやつだとは思ってたが
レベルの低さが想像をはるかに超えてた
652:デフォルトの名無しさん
21/05/15 11:27:04.30 MS0dCBGJ.net
c言語みたいにcsvパーサーも自前で用意するような環境だとそらスクリプト的だろうね。
653:デフォルトの名無しさん
21/05/15 12:00:43.05 A3vQNOxR.net
unityとかUEがrustに対応しないかなあ
654:デフォルトの名無しさん
21/05/15 12:00:58.11 ZgJC7yuF.net
cargoみたいなパッケージマネージャがあるのもスクリプト的な要素のうちなのか？
655:デフォルトの名無しさん
21/05/15 12:10:16.46 MS0dCBGJ.net
cargoは低レイヤー慣れてる人からすれば邪魔でしかないけどね。
656:デフォルトの名無しさん
21/05/15 12:20:50.35 DTE+piln.net
SourceforgeなどでRustが好きといっている人の大部分はレベルが低いだろう。
そもそもこの世の中、大多数から受けるものにレベルが高いものがあったためしがない。
好きな言語ランキング上位のJS、Pythonも初心者向け言語であることは誰もが認めることだし。
657:デフォルトの名無しさん
21/05/15 12:40:11.21 UqP25wMI.net
sourceforge？？？
stackoverflowの調査かなんかと勘違いしたの？
658:デフォルトの名無しさん
21/05/15 12:41:57.93 ZgJC7yuF.net
>>644
どういうこと？ベアメタル向けでもcargo使うのが主流だと思っていた
659:デフォルトの名無しさん
21/05/15 12:47:56.99 ZgJC7yuF.net
>>645
使用者のレベルの高低と言語のレベル(?)の高低は一致するという主張かな？
言語のレベルが高いというのが最先端のテクノロジーを取り込むという意味ならrustの目指すところではないと思う
他の言語で実証されたコンセプトを取り込むと宣言してる(た?)はず
高レベルな言語が必要な人はこんな普及言語じゃなくてもっと尖った言語を使うか自分で作るべきなのでは
660:デフォルトの名無しさん
21/05/15 12:49:38.36 DTE+piln.net
>>646
ああ、そっちだった。
Stackoverflowも来てる人の頭の良さは一般大衆と同じくらいだから同じ。
661:デフォルトの名無しさん
21/05/15 12:53:14.42 DTE+piln.net
>>648
そういうことじゃなくて、
・Rustをほとんど使っても見てないのに勝手に「好き」と言っていることが分かってる。
・Stackoverflowのような沢山の人が集まる場所の調査では、必ずJSやPythonのような初心者向けの言語が人気となるわけだから、そこの人々が好きだと思う言語は、JSやPythonのような感覚で使えると勝手に思い込んである蓋然性が高い。
ただし、現実はRustは実際には使ってないのに勝手に言っている。
ということ。
662:デフォルトの名無しさん
21/05/15 13:20:44.67 YOv93GRR.net
stackoverflowの調査の話なら、調査内容を勘違いしている
あれは「今Rustを使っている人が、今後もRustを使い続けたいかどうか」のアンケート結果をmost lovedと言ってるだけ
だからJSやPythonユーザの意見は入ってない
そもそもloveって言葉に語弊があるし、日本語にしたときに「人気の」とかなって余計訳がわからなくなってる
663:デフォルトの名無しさん
21/05/15 13:25:20.53 YOv93GRR.net
たぶん「最も嫌嫌使っている人が少ない言語」みたいなのが正確な気がするな
664:デフォルトの名無しさん
21/05/15 14:15:44.60 MW7lNw7H.net
「今使ってる人が次も使いたいと思うか？」ってJetBrainsの調査でも毎回入れてくる項目だな
海外のアンケートではよく見るやつ
665:デフォルトの名無しさん
21/05/15 14:17:03.39 DTE+piln.net
>>651
もし前半の通りなら、今Rustを使ってる人なんて極一握りの物好きだけだから
「love」なのは当たり前で調査結果が意味が無い。
666:デフォルトの名無しさん
21/05/15 14:19:45.06 eXXN4CKf.net
一生でどれか一つのプログラミング言語しか覚えられないとして
Rust選ぶ人いますか？
選択したとして別にその言語がいきなりマスターできるわけでなく
ただその言語しか覚えられないというだけですが
667:デフォルトの名無しさん
21/05/15 14:23:36.58 DTE+piln.net
今rustを使ってる人って、自ら進んで使おうとした人に限られるから
嫌いな人がほとんどいないのは当たり前だから、調査結果にバイアスが
掛かりすぎていることになるな。
668:はちみつ餃子
21/05/15 15:05:35.65 pVi51x8H.net
そういえば C++ でメンバ関数の評価順序に関して設計者も気づいてなかった考慮漏れが見つかった
(よくあるパターンが実際には未定義だった) って話があったな。
URLﾘﾝｸ(www.open-std.org)
C++17 で修正されているはずだけど。
宣言的な表現や関数的な表現をプログラミング言語に取り込む試みは数多いが
現実は順序からは逃れられぬのだ……。
669:デフォルトの名無しさん
21/05/15 15:16:25.44 HcoKJY+/.net
Rustがスクリプト的に書けるかどうかはおいといて、
個人用のツール書く言語をPythonからRustに乗り換えたっつー話は一応あるな
URLﾘﾝｸ(hayatoito.github.io)
670:デフォルトの名無しさん
21/05/15 15:20:52.26 DTE+piln.net
>>658
Googleがnode.jsで書いていたものをRustにしたと聞いたぞ。
671:デフォルトの名無しさん
21/05/15 15:23:50.02 TrqVEcq2.net
全部書き直すのは逆に効率悪そう
速度的にキツイ場合のみでいいんじゃないか
672:？
673:デフォルトの名無しさん
21/05/15 15:32:34.68 H/3gPTTR.net
どちらかといえば速度よりも変更頻度が動機になると思う
静的チェックツールも増えてはいるけどコンパイル型はいじる時の安心感が違う
674:はちみつ餃子
21/05/15 15:37:59.52 pVi51x8H.net
>>660
言語を跨いで呼出すときはその境界で色々な処理が挟まったりもするので、
まだらに入り乱れるような形になるとそれはそれで実行性能の足を引っ張ることもある。
状況次第なので一概には言えないけど、言語を変更すると決めたなら
そこそこ大きい単位で乗り換えるのが妥当な場合は結構あると思うよ。
675:デフォルトの名無しさん
21/05/15 17:32:17.46 jwQMP5Oj.net
>>661
それはあるね
個人用のツールだとそんなに真面目にテストも書かないから
動的型だと忘れた頃に改修したくなって詰む
676:デフォルトの名無しさん
21/05/15 18:53:39.15 IpomZGOJ.net
>>642
MSがdotnet対応のRust#出したらUnityワンチャンあるんやない？
677:デフォルトの名無しさん
21/05/15 19:10:58.08 Y+SvMVkX.net
そこはRust/CLIで。
678:デフォルトの名無しさん
21/05/15 21:52:45.98 TrqVEcq2.net
GCのあるrustに存在意義などない
679:デフォルトの名無しさん
21/05/15 22:13:28.16 Y+SvMVkX.net
GCとデストラクタが共存するC++/CLIはなかなか興味深い言語だった。
680:デフォルトの名無しさん
21/05/16 11:00:47.47 9EXRd3vl.net
RustのGCって初期はまた復活されるかもーみたいなノリじゃなかったっけ？
681:デフォルトの名無しさん
21/05/16 11:12:01.38 SPtqbmz9.net
RC関連についてはやるとか？
682:デフォルトの名無しさん
21/05/16 12:07:45.66 MDYO1Tug.net
@ pointerとか ~ pointerとかあった頃の話？
683:デフォルトの名無しさん
21/05/16 15:06:48.66 JH7fFMWR.net
>>665
確かにそっちか
>>666
GCがあるRustって言うよりはunsafeを外部リンクで呼び出してるようなもんだろ
684:デフォルトの名無しさん
21/05/17 10:53:44.01 ZSkTvtbm.net
rustが覇権を取るにはPHPみたいにドキュメントの翻訳をたくさん作ること
そしてサンプルコードを盛り込むこと
685:デフォルトの名無しさん
21/05/18 19:40:20.00 A1yOEMnk.net
>2021 Editionは2021年10月にリリースされる。今回のエディションは「Rustの使用感を大きく改善する」ものになるという
あんまり前にこんな発表しないでほしい
やる気なくなる
686:デフォルトの名無しさん
21/05/18 19:44:35.79 Gj41gD2H.net
>>673
ちゃんと発表資料見れば分かるけど、大して使用感変わらんよ
クロージャー使いまくりの人が一番恩恵を受けるかな
687:デフォルトの名無しさん
21/05/18 20:19:55.73 Z0RWJbQc.net
所有権は移動するときのほうにマークが出るべきなんじゃあ
688:デフォルトの名無しさん
21/05/19 07:47:56.56 X700JkCT.net
まぁコストかかるのはコピーだし
689:デフォルトの名無しさん
21/05/19 08:05:05.13 o3bqBTNO.net
Rustの真似をしようとする言語がないのがふしぎだ
690:デフォルトの名無しさん
21/05/19 12:30:25.52 HmkTJiD6.net
URLﾘﾝｸ(en.m.wikipedia.org)(programming_language)
wikipedia見ただけだけど Crystal, Elm
691:デフォルトの名無しさん
21/05/19 12:30:46.25 HmkTJiD6.net
など影響を与えた言語は列挙されてた
692:デフォルトの名無しさん
21/05/19 12:42:47.10 9T1L9lvJ.net
>>678
Elmのどこが？と思ってソースを読んだら
関数型言語なら大体持ってるEither型の名前を Result, Ok, Error にしたところがRust由来とな
うーむ持ってきたのは名前だけなのにInfluencedか
693:デフォルトの名無しさん
21/05/19 12:59:40.27 u9Tr9lyP.net
Gleam
URLﾘﾝｸ(gleam.run)
OwnershipやLifetimeの考え方を採用した言語はまだ聞いたことがない
694:デフォルトの名無しさん
21/05/19 13:11:21.07 bDX8SBSl.net
所有権の考え方を採用している言語としてはC++などがあります
695:デフォルトの名無しさん
21/05/19 14:00:04.90 NOe9g/vN.net
まあインスタンスの共有については何らかの言語サポートが入ってもおかしくないかもね
696:デフォルトの名無しさん
21/05/20 01:09:22.49 WwVMFHF+.net
DにもOwnership入ったとか小耳に挟んだだけなら
697:デフォルトの名無しさん
21/05/20 17:03:02.09 VKAk8Olu.net
URLﾘﾝｸ(forest.watch.impress.co.jp)
凄いね
698:デフォルトの名無しさん
21/05/20 17:06:31.55 13olK3Lw.net
>>685
UIがReactというのが残念
699:デフォルトの名無しさん
21/05/20 18:20:18.69 PiC1UW/o.net
逆に何ならいいんだよ
700:デフォルトの名無しさん
21/05/20 18:33:43.55 UXe9/StR.net
GUIフレームワークをRustで作るうまみあまりなさそう
701:デフォルトの名無しさん
21/05/20 19:39:25.12 QrP75Wi1.net
Rustで作ってあるなら絶対大丈夫だな！
702:デフォルトの名無しさん
21/05/20 22:57:01.82 HbCDuKW4.net
設計がクソだとダメ
ダメなヤツはなにやってもダメ
703:デフォルトの名無しさん
21/05/21 11:45:49.77 r1IBz1vL.net
>>538
(1)もちろん例外を使わずとも関数呼び出し等がエラー値を返すことで全て実現できます
(2)ところがエラー値が返ってくると毎回if文やmatch等でエラー時はそこですぐreturnする等の処理を書く必要があって面倒かつコードが醜いため例外の使用が好まれました
(3)Rustでは関数の返り値型をResult<T,E>とすることに加えて「?」オペレーター(旧try!マクロ)を使うことで(2)の処理を自動化しました
つまり関数等呼び出し毎にifやmatch等で返り値エラーチェック＆returnの記述をしなくても末尾に「?」を記述するだけで済みます
これでチェーンも出来て具体的には
b = a.hage()?.hige()?.hoge()?
と書くだけでhage()でエラーが返れば早期エラーreturnしますしhige()やhoge()でエラーでも同様です
関数の返り値型がResult<T,E>であることが使用条件です
これはもちろん正常値の<T>型とエラー<E>型のenumです
これらにより関数を多段に深く呼び出していても深い所でのエラーがすぐにreturnを多段にしてエラーが戻って来ます
したがってRustでは例外を使わなくても困らないのです