Rust part20

**デフォルトの名無しさん** · 2023/03/03(金) 00:45:28.73

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part19
https://mevius.5ch.net/test/read.cgi/tech/1673926892/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/06/08(木) 15:00:38.73

>>602
どう見ても式ではないが
仮に式っぽい何かだとしても関数宣言にだけ特別に書けるならやっぱり一貫性はないってことになるし

**デフォルトの名無しさん** · 2023/06/08(木) 20:13:04.97

関数型言語から拾っただけで深い考えはないだろ
関数型言語は　引数　-> 戻り値　とか　引数 ->　引数　-> 戻り値でカリー化したら引数の数が減ったりするので意味は通じるけど…

**デフォルトの名無しさん** · 2023/06/08(木) 20:15:30.41

オレオレ一貫性w
全然一貫してない

**デフォルトの名無しさん** · 2023/06/08(木) 20:45:27.43

「-> 戻り型」を批判してる人は先に採用したC++に対しても批判しているの？
ML系で何十年も使われて来た実績と視認性の良さからベストな記法

**デフォルトの名無しさん** · 2023/06/08(木) 21:09:50.06

ML系は関数呼び出しにかっこを使わないし
関数定義と型注釈を分けて書くし
Cスタイルとはだいぶ違う文法体系だよね
同じ記号を使っているという以外に共通点はないと思うよ

そしてx: TはPascalスタイルの型の付け方なんですね
TypeScriptの他にもScala、Kotlin、HaxeなどがPascalに従って(x: T): Uのように戻り値型注釈をつけます
参考までに

**デフォルトの名無しさん** · 2023/06/09(金) 02:12:57.64

sigplan noticeではindentationとlexical syntaxの話は禁止だったw

**デフォルトの名無しさん** · 2023/06/09(金) 17:20:52.23

syntaxで言うならライフタイムのsyntaxは今でも違和感あるわ。
具体的に使うわけでもない変数を定義するようなのはどうにかならんかったのか。

**デフォルトの名無しさん** · 2023/06/09(金) 18:41:37.13

>>611
型変数と同じじゃない？
あれも変数として使ってるわけじゃなく、こことここの型は同じってことを示すだけの変数なわけで

**デフォルトの名無しさん** · 2023/06/09(金) 18:57:57.14

変数として使ってないわけじゃないな
具体的なインスタンスが生成されるときに具体的なライフタイムが代入されると思うべきか

**デフォルトの名無しさん** · 2023/06/09(金) 18:59:26.79

型パラメータは変数じゃありません

**デフォルトの名無しさん** · 2023/06/09(金) 19:10:21.66

違和感あるようにしてるんだぞ
Bad Partsはあえて汚くなるような構文を選んでる

**デフォルトの名無しさん** · 2023/06/09(金) 19:42:24.19

>>609
Haxe草
君のバックボーンはなんとなくわかったよ

**デフォルトの名無しさん** · 2023/06/09(金) 20:20:27.29

rustのstructってなんで中身をカンマで区切るんですか？
C/C++/C#/Swiftはセミコロンだし、影響受けたとされるhaskellの直積型はスペースですよね、デフォルトでメモリースペースが最小になるように再配置されるから？
でもそれだと配列のように直線的に配置されるように感じてしまう気がするのだが

**デフォルトの名無しさん** · 2023/06/09(金) 20:32:17.49

内容の列挙だからカンマの方が自然だと思うけどセミコロンが使われがちなのは
構文解析（エラー復帰）しやすいからなのかな

let Point { x; y; } = p;
だと気持ち悪いからパターンマッチと関係あるかもしれない

**デフォルトの名無しさん** · 2023/06/09(金) 22:10:43.24

>>618
なるほど?構文解析が楽だからという理由はある程度は納得できるが、自然と感じる理由が個人的な嗜好で何となくなのかな?
ほかにカンマを使う場面は分割代入(destructuring)があるので、structを分解するときに対称性が良いからなのかと考えたり

**デフォルトの名無しさん** · 2023/06/10(土) 08:59:06.95

cでエンディアン確認するとき

unsigned long x = 0x12345678;
for( int i = 0; i < sizeof(long); i++ ){

**デフォルトの名無しさん** · 2023/06/10(土) 09:07:47.23

cでエンディアン確認するとき

unsigned long x = 0x12345678;
unsigned char *px = (unsingned char *)&x;
for( int i = 0; i < sizeof(long); i++ ){
　fprintf(stderr, "%X ", *px++ );
}
fprintf(stderr, "\n" );

てのをrustならどー書いたらええの>

**デフォルトの名無しさん** · 2023/06/10(土) 09:44:12.87

それと同じこともできるけど、単にエンディアン知りたいだけならこんな感じで

if cfg!(target_endian = "big") {
// big endian
} else {
// little endian
}

**デフォルトの名無しさん** · 2023/06/10(土) 09:56:44.54

>>622
エンディアンと書いたのは一例で
実際用意された型にバイトデータがどう格納されてるかを知りたい
ポインタキャストどー書くの?

forとかも変なことなってるけど
条件判断と goto ラベルさえあれば繰り返しは実行できるんだが,
rustにC/C++にあるgotoとかラベルってあるの?

**デフォルトの名無しさん** · 2023/06/10(土) 10:05:08.69

>>623
その場合はtransmuteかな
https://doc.rust-lang.org/std/mem/fn.transmute.html

gotoはない
ラベルはネストしたループから脱出するためのはある

**デフォルトの名無しさん** · 2023/06/10(土) 10:07:35.39

>>621
let x: i32 = 0x12345678;

// 直訳すると生ポインタなのでunsafe
use std::mem::size_of;
let mut px = &x as *const i32 as *const u8;
for _i in 0..size_of::<i32>() {
print!("{:x} ", unsafe { *px });
unsafe { px = px.add(1); };
}
println!();

// byte列とみなすメソッドを使うとsafe
for b in x.to_ne_bytes() {
print!("{b:x} ");
}
println!();

**デフォルトの名無しさん** · 2023/06/10(土) 10:13:46.29

エンディアン君を、ウッカリ助平と命名したい....

**デフォルトの名無しさん** · 2023/06/10(土) 10:25:42.92

>>624
>>625

**デフォルトの名無しさん** · 2023/06/10(土) 10:26:30.43

>>624
>>625
わざわざありがと
勉強になります

>>626
何ソレ?

**デフォルトの名無しさん** · 2023/06/10(土) 10:35:25.62

to_ne_bytesのneはnative endianの意味でleやbeもある
neを使ってlittle endian環境ならば
assert_eq!(0x12345678_u32.to_ne_bytes(), [0x78, 0x56, 0x34, 0x12]);
assert_eq!(0x12345678, u32::from_ne_bytes([0x78, 0x56, 0x34, 0x12]));

**デフォルトの名無しさん** · 2023/06/10(土) 15:12:50.25

テキストデータを画像にレンダリングして最終的に2値モノクロ画像を得たいんだけど
今だとどんなクレートを使うのがいいかな？
フォントレンダラはfont-rs・・・は放置されているしからfontdueとか？
2値化に影響するディザリングのオプションとかを指定できるとありがたい

**デフォルトの名無しさん** · 2023/06/10(土) 15:48:41.24

rusttypeとかab_glyphってのがダウンロード数多いみたい

**デフォルトの名無しさん** · 2023/06/12(月) 12:58:17.77

ただの思いつきだが、CやC++はメモリセーフではないだろ。ってことはプログラム中で結構無駄なメモリを消費してたりしないの？Rustはそこの所最適化されてるから究極的にはRustの方がCやC++よりも高速に動作するのでは？

**デフォルトの名無しさん** · 2023/06/12(月) 13:04:11.65

？

**デフォルトの名無しさん** · 2023/06/12(月) 14:15:17.58

ちょっと何言ってるかわからない

**デフォルトの名無しさん** · 2023/06/12(月) 16:35:03.90

メモリセーフかどうかと
メモリを無駄使いしてるかどうかに直接の関係はない

**デフォルトの名無しさん** · 2023/06/12(月) 16:47:01.05

メモリ安全性とメモリの利用効率に関係はないが、
安全性のために導入したライフタイム管理が最適化に影響する部分がないとは言えない。
依存関係が明瞭だからエイリアス解析がしやすく、
結果的に効果的に最適化しやすい可能性は高い。

しかし実行時でないと安全なアクセスであるかどうか検出が不可能な場合もあるから
それも込みで考えると Rust のほうがやや不利であると言える要素もある。
全体的な性能は互角か Rust のほうがやや遅いくらいじゃないの。知らんけど。

性能が互角くらいでより安全ならそのほうがいいじゃろ。

**デフォルトの名無しさん** · 2023/06/12(月) 18:28:52.16

メモリ安全にするために過剰なコピーや長いライフタイムになる実装をしてしまうことがあり、それをコンパイラがガードしてあげるからルールに従って書いてねってのがRustの思想だと思う。
逆に適当に書いても安全にするし出来るだけメモリ効率も配慮するよってのが他のGC言語

**デフォルトの名無しさん** · 2023/06/12(月) 18:44:13.30

そんな話一般論で語れる訳ないぞ
コードを出しな？

**デフォルトの名無しさん** · 2023/06/12(月) 20:02:49.65

>>636
そんなことはなくRustも適切な方法を選べる
そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん

**デフォルトの名無しさん** · 2023/06/12(月) 21:33:36.66

>>639
ここではメモリ安全性が実行効率に寄与するわけではないというのがトピックなので
安全性 (自動的な安全性の検証) を捨てることも出来るというのは話題の外。

**デフォルトの名無しさん** · 2023/06/12(月) 21:39:50.33

意味のない議論がほんと好きだねー

**デフォルトの名無しさん** · 2023/06/12(月) 21:44:05.58

コードが一切出てこないのが本当不思議

**デフォルトの名無しさん** · 2023/06/12(月) 21:45:00.87

>>640
Rustは実行効率を保ちながら安全性もある
Rustがやや不利でやや遅いと思い込んでいる具体的なケースのコードを出してごらん

**デフォルトの名無しさん** · 2023/06/13(火) 11:32:39.43

>>639
>そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん
ややどころか、大幅に遅くなるケースもあるぞ。
俺はこれ以上指摘しない。自分で分かるかどうかが技術力の試金石だ。

**デフォルトの名無しさん** · 2023/06/13(火) 11:35:33.48

また、
　「Rustは、どんな場合でも、効率を下げずに少数の関数の中に unsafe 箇所を閉じ込められる」
というのも嘘。

**デフォルトの名無しさん** · 2023/06/13(火) 11:43:16.69

ならお前はこれ以上指摘すんなよ未来に渡って

**デフォルトの名無しさん** · 2023/06/13(火) 11:53:41.84

>>644
デタラメ屋さんまた来たのか

**デフォルトの名無しさん** · 2023/06/13(火) 14:38:11.20

>>647
俺は一般プログラマより生まれつきだいぶ頭がいいので、通常のプログラマには
分からないのかも知れない。

**デフォルトの名無しさん** · 2023/06/13(火) 18:50:01.53

>>648
ぷw

**デフォルトの名無しさん** · 2023/06/13(火) 23:11:29.90

>>648
だいぶ頭良いプログラマーはこんなとこ来ねーからw

**デフォルトの名無しさん** · 2023/06/14(水) 17:49:14.80

可変長のバイナリデータを扱う場合の型ってやっぱvec<u8>あたり？
独自の型を定義する以外に他によさそうな型って何かあるかな

**デフォルトの名無しさん** · 2023/06/14(水) 20:22:43.85

>>651
Trait std::io::Readのrequired methodが
fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
であるように&[u8]でアクセスできれば何でもよい
そのうち可変で最もお手軽なのはVec<u8>
Trait std::io::Readのprovided methodの一つ
fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize> { ... }
もVec<u8>の可変参照を渡す仕様

**デフォルトの名無しさん** · 2023/06/14(水) 20:28:50.68

よくわからないんだけど
ライフタイムの例でよく出てくる関数の引数a,bを同じライフタイムの指定にするってやつは
どちらが選ばれるか分からないから使わないほうも長い方の寿命に合わせて残しておきますと言う解釈でいいの？

**デフォルトの名無しさん** · 2023/06/14(水) 20:57:15.56

>>653
その例となってる関数のコードくらいは書けよ

**デフォルトの名無しさん** · 2023/06/14(水) 23:11:40.84

たぶんこういう例のことかな
fn longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
if s1.len() >= s2.len() { s1 } else { s2 }
}
ここである呼び出しの時に
s1が'staticでs2が'x (!= 'static)だったとすると
'aとして寿命が短い'xの方が採用される
ただしこれはcovarianceである&Tの場合の話
invarianceである&mut Tの場合は逆になるので注意

**デフォルトの名無しさん** · 2023/06/14(水) 23:20:37.20

>>652
サンクス。やっぱvec<u8>が無難か
読みやすさだと構造体だけど要unsafeな上に
環境依存性も出ちゃうからな

**デフォルトの名無しさん** · 2023/06/14(水) 23:43:12.09

構造体とか要unsafeとか何をしたいのかわからないが
上限を決めてもよい用途ならば
ヒープを使わずともArrayVec<u8, CAPACITY>がスタック上のみで動く

**デフォルトの名無しさん** · 2023/06/14(水) 23:49:13.19

データの一部だけ可変長とかブロック構造の個数が
可変(ブロックの中身は固定)とかね

**デフォルトの名無しさん** · 2023/06/14(水) 23:54:41.98

staticは消滅しないから実質参考にならんので無視して短い方をaとする
これは対象が2つだからであって
static 1
その他　2
ならその他2の長い方になると言う考えでいいのかな？

**デフォルトの名無しさん** · 2023/06/14(水) 23:58:17.85

もう何言ってんだよ

**デフォルトの名無しさん** · 2023/06/14(水) 23:59:42.49

>>655
ライフタイムに関しては&も&mutもcovariantなので違いはありません

**デフォルトの名無しさん** · 2023/06/15(木) 00:08:38.46

Tに対して&Tはcovariant
Tに対して&mut Tはinvariant

**デフォルトの名無しさん** · 2023/06/15(木) 08:25:03.26

>>547
OptionとOnceCellの違い

&Tを得ることをgetと呼ぶようになった
【Option】fn as_ref(&self) -> Option<&T>
【OnceCell】fn get(&self) -> Option<&T>

&mut Tを得ることをget_mutと呼ぶようになった
【Option】fn as_mut(&mut self) -> Option<&mut T>
【OnceCell】fn get_mut(&mut self) -> Option<&mut T>

空にしてTを得ることをtakeと呼ぶのは同じ
【Option】fn take(&mut self) -> Option<T>
【OnceCell】fn take(&mut self) -> Option<T>

空(default)を作成することをnewと呼ぶこともできるようになった
【Option】fn default() -> Option<T>
【OnceCell】fn default() -> OnceCell<T> または fn new() -> OnceCell<T>

**デフォルトの名無しさん** · 2023/06/15(木) 11:48:36.10

トヨタの車載OSってRUSTなんだ

**デフォルトの名無しさん** · 2023/06/15(木) 18:17:26.02

ライフタイムもtraitも難しすぎてマジでわからん

**デフォルトの名無しさん** · 2023/06/15(木) 18:21:52.25

ライフタイムの質問してたものだけど
コードを書いてて完全に誤解していたことに気が付いた
コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
多分一般向けには流行らないわな

**デフォルトの名無しさん** · 2023/06/15(木) 18:38:09.80

ライフタイムって該当のメモリがいつまで確保されているかって話であって難しいところはなくね？
所望のタイミングまで開放してほしくないがどのようにするのが望ましいか？って話ならまだわかるが

**デフォルトの名無しさん** · 2023/06/15(木) 18:40:44.72

自明なときに省略できるせいで理解しづらくなってる気はする

**デフォルトの名無しさん** · 2023/06/15(木) 18:44:18.80

日本語がおかしかった
関数では引数に依存する戻り値の寿命がわからない
それで基本的に指定した複数の引数のライフタイムの一番短い奴に合わせて解釈する
そのライフタイムを元にコンパイル時にチェックしてダングリングを防いでる

一番寿命が短い奴に合わせてチェックしたら他はそれより長いのでダングリングが起こらないだろうと
こういうふうに言う人間があまりいないのが現状

**デフォルトの名無しさん** · 2023/06/15(木) 18:47:34.83

普通にコードを書いた時点でスコープや借用の関係で寿命は決まってる
それが範囲外になるかどうかボローチェックしてるんだけどそいつのためにライフタイムを明示してる

ライフタイムを明示してもコード上の寿命は伸び縮みしないけどエラーを見てコードを書いた人は修正ができる

**デフォルトの名無しさん** · 2023/06/15(木) 18:52:46.39

と言う解釈なんだけど今のところ
普通に違ってるかもしれない

**デフォルトの名無しさん** · 2023/06/15(木) 18:57:24.57

OnceCellってようやく俺たちの欲しいものが来てくれたか
RefCellもCellも複雑なデータ構造作ると面倒だったからな

**デフォルトの名無しさん** · 2023/06/15(木) 20:40:26.65

Cellの種類が増えるってのは悪い兆候だね

**デフォルトの名無しさん** · 2023/06/15(木) 20:43:39.64

Cellを使ったら負け
他の言語からの移植だと、なぜか増えてしまう

**デフォルトの名無しさん** · 2023/06/15(木) 21:23:13.49

>>669
結構何を言ってるか分からないが引数のライフタイムを省略した場合は全部同じライフタイムを持つことになるよ

**デフォルトの名無しさん** · 2023/06/15(木) 21:54:27.47

>>669
main()→sub()→...と呼ばれている時に
'mainと'subをそれぞれの関数で持っている分の寿命とすると
寿命の長さは'static＞'main＞'subだが
「'sub以上の集合」⊃「'main以上の集合」⊃「'static以上の集合」なので
実は'staticの方がサブタイプ(下位)

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str において
寿命'aはジェネリックなパラメータなので
longest('main, 'static)と呼び出されれば'aは上位の'mainとなり
longest('main, 'sub)と呼び出されれば'aは上位の'subとなる

一方で
fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'b str という関数だと
foo('main, 'static)と呼び出されれば'bはそのまま'staticとなり
foo('main, 'sub)と呼び出されれば'bはそのまま'subとなる
この場合はもちろん引数の短い方の寿命になるわけではない

fn bar<'a, 'b>(x: &'a str, y: &'b str) -> Bar<'a, 'b> という関数は
返り型が構造体(か何か)のBarでその内部に寿命'aのものと寿命'bのものを持つ
このように様々なケースがある

**デフォルトの名無しさん** · 2023/06/15(木) 22:01:26.73

>>672
OnceCellは前からあって広く使われていて今回stdに採り入れられた
once_cell::unsync::OnceCell が std::cell::OnceCell となった
staticで使われてきたSyncなOnceCellの方は別名となり
once_cell::sync::OnceCell が std::sync::OnceLock となった

**デフォルトの名無しさん** · 2023/06/15(木) 22:08:16.03

>>669
データフロー解析を知らないのだろうか?

**デフォルトの名無しさん** · 2023/06/15(木) 22:11:21.57

>>666
>コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
この”揃える”っていう感覚になる理由がこんがらがってる原因と見た

**デフォルトの名無しさん** · 2023/06/15(木) 22:12:42.39

>>674
負けではない
むしろCell類は内部可変性を与えてくれる便利で良いもの

>>673
性質の異なるものを使い分けられるから良いこと
コードの自由度や可読性も上がる

**デフォルトの名無しさん** · 2023/06/15(木) 22:15:38.46

>>676
上位下位にサブタイプにsubて嫌がらせか！

**デフォルトの名無しさん** · 2023/06/15(木) 22:39:43.11

>>675
まずこれは間違いだよね？
ライフタイムを省力すると全部別扱い

>>679
こんがらがってはいない
違うなら違う個所を訂正したらいいけど君には出来ないとみた

引数側のライフタイムは戻り値のライフタイムの検証のためのヒント

**デフォルトの名無しさん** · 2023/06/15(木) 23:12:41.78

>>682
こんがらがってないならまずは他人に理解できる日本語とコード例を書いてくれよ
間違いを指摘するとか以前に何を言いたいのかわからないんだって
俺だけじゃなくて何人も君が何を言いたいのか分からないって書いてるでしょ？

**デフォルトの名無しさん** · 2023/06/15(木) 23:29:09.39

>>682
>まずこれは間違いだよね？
>ライフタイムを省力すると全部別扱い
コンパイルエラーになるケースを含めて言えば「省略したら」全部別扱いは正しい
コンパイルエラーにならずに「省略できるのは」基本的に入出力で同じライフタイム扱いになる場合だから>>675の感覚もよくわかる
&と&mut違いで推論できる場合だけ例外

**デフォルトの名無しさん** · 2023/06/15(木) 23:59:14.48

>>682
ライフタイムの「仮引数」としては省略されると全部同じ扱いで合ってるよ。
https://doc.rust-lang.org/reference/lifetime-elision.html

一方で呼び出す側が認識しているライフタイムの「実引数」は違っていてもいい。
>>655の例で言えば、呼び出す側が x: &'b str と y: &'c str を渡して戻り値を z: &'d str に束縛するなら、'a は 'b: 'a, 'c: 'a, 'a: 'd を満たす最小のライフタイムに推論される。
そのような 'a があれば、&'b str <: &'a str etc. の部分型付け関係に基づいて、引数はすべて一度 &'a str にアップキャストされると思っていればいい。はず。
適切な 'a が無ければライフタイムに関するコンパイルエラーになる。
https://doc.rust-lang.org/reference/subtyping.html
https://rust-lang.github.io/rfcs/2094-nll.html

**デフォルトの名無しさん** · 2023/06/16(金) 00:20:26.24

Rustのコードが'まみれになるのはそういう理由だよね

**デフォルトの名無しさん** · 2023/06/16(金) 00:24:30.59

>>685
＞　パラメーター内の省略された各ライフタイムは、別個のライフタイムパラメーターになります。

**デフォルトの名無しさん** · 2023/06/16(金) 00:30:18.44

>>685
いや、全部別になる
参照引き数が2つあれば'aと'b別になる

ソース
https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html

The first rule is that the compiler assigns a lifetime parameter to each parameter that’s a reference.
In other words,
a function with one parameter gets one lifetime parameter: fn foo<'a>(x: &'a i32);
a function with two parameters gets two separate lifetime parameters: fn foo<'a, 'b>(x: &'a i32, y: &'b i32);
and so on.

(snip)

Let’s look at another example, this time using the longest function that had no lifetime parameters
when we started working with it in Listing 10-20:

fn longest(x: &str, y: &str) -> &str {

Let’s apply the first rule: each parameter gets its own lifetime.
This time we have two parameters instead of one, so we have two lifetimes:

fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &str {

このようにコンパイラは解釈する
そして戻り値が一意に決まらないのでコンパイルエラーとなる
そのためコンパイラは改善提案の一つとして全部同じにする提案コードを出す
fn longest<'a,>(x: &'a str, y: &'a str) -> &'a str {
全部同じ扱いと思い込んでいる人はこの提案をコンパイラが解釈したと逆に思ってしまったのではないか

**685** · 2023/06/16(金) 01:37:43.97

ほんまや申し訳ねえ
>>685はelisionのくだりは無視して明示した場合の話のつもりで読んでくだせえ

**デフォルトの名無しさん** · 2023/06/16(金) 05:23:01.54

厳格な言語て嫌いでな
Verilogはなんの問題もなかったのに
VHDLはとうとう挫折した
てか予約後長いし,マクロがないのが許せなかったんだが
その意味でJavaも結局書く気にもならなんだわ

**デフォルトの名無しさん** · 2023/06/16(金) 14:09:49.37

>>675
だけど思い込みを書いてしまってごめん
勉強になりました

**デフォルトの名無しさん** · 2023/06/16(金) 14:58:22.19

水ノ都さんこんにちは

**デフォルトの名無しさん** · 2023/06/16(金) 17:51:24.52

組み込み向けの解説記事でよさそうなのってない？
The Embedded Rust Bookは有名だけどSTM32ありきで書かれているしリンカとか肝心な部分の説明もないように見える
日本の人が書いているっぽいEmbedded Rust Techniquesの方がマシだがこれでも最低限か・・・

**デフォルトの名無しさん** · 2023/06/16(金) 18:25:34.38

>>693
The Book以外のドキュメントなら https://docs.rust-embedded.org/ からいろいろ探せるよ
あるいはEmbedded Rust Techniquesの人が書いてる「基礎から学ぶ組み込みRust」って本とか

**デフォルトの名無しさん** · 2023/06/16(金) 18:39:22.38

Rust好きがまあまあ見てそうなこのスレでもこのレベルなんだから一般に広まるのは無理ゲーだと思うわ

**デフォルトの名無しさん** · 2023/06/16(金) 19:23:08.87

問題点を具体的に言えずに曖昧に批判してるつもりの人がいるね

**デフォルトの名無しさん** · 2023/06/16(金) 19:40:36.76

自分でスレを読めばいい

お前の足りない脳を誰かがフォローしてボローチェックまでしてくれるなんて思うなよ

**デフォルトの名無しさん** · 2023/06/16(金) 19:42:26.19

言語の良し悪し以上にライブラリの分量が効いてくるんだわ。
そんでその大量にあるライブラリが利用しやすければなお良い。

やりたいことにマッチするライブラリがあるなら
自分で書かなくてよい部分が多くなるわけだし、
書く部分が少なければ少々の面倒くささなんてどうでもよくなる。

C や C++ の歴史の長さ故の物量に対抗するのは難しいけど
Rust は利用しやすさではかなり上回ってると思うので時間の問題だろ。

**デフォルトの名無しさん** · 2023/06/16(金) 23:38:46.36

>>695
単に5chがオワコンなだけだぞ

**デフォルトの名無しさん** · 2023/06/17(土) 20:33:46.40

>>683
ときにアセンブラで書必要に迫られる組込でRustあ日の目をみることなんてない

**デフォルトの名無しさん** · 2023/06/17(土) 21:26:17.31

>>694
その人は本を出していたのか。今度都内へ行ったときに見てみるか

**デフォルトの名無しさん** · 2023/06/17(土) 23:07:17.38

今日たまたま本屋で見かけた
売れるんかこれと思ったけど買う人がいる

**デフォルトの名無しさん** · 2023/06/18(日) 01:17:21.64

Rustでlinuxに機能を追加するならどんな機能が欲しい？みんな自由に言ってみて。

**デフォルトの名無しさん** · 2023/06/18(日) 09:07:15.46

>>695
ほんそれ

**デフォルトの名無しさん** · 2023/06/18(日) 09:08:49.10

>>698
crates.io はゴミだらけのイメージ(もちろんゴミじゃないのもあるがSN比が絶望的に悪い)