Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

Mozilla発のRust言語のスレ

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

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

前スレ
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/07/05(日) 23:04:09.03

>>845
まず、

1) inference type（推論された型）と宣言時や実行時の型は別なんで、実行時の型はあくまで推論された型の外延でしかない。
すると、別の型互換のルール（たとえば、部分多相とか）がないと互換の型とみなせない。

2) 公開された部分を推論すると将来の変更で1)から互換性を失う場合がある。
最近型推論導入した言語が公開関数のシグネチャ等を推論しないのはこの問題が理由だと思う。

>ただ(0i64..10).sum()のケースはiter::Iterator::sumやiter::Sumの定義から
>各要素がi64だと決まってる限り新しいimplが追加されても結果の型もi64にしかならないと思うんだよね
これは単にメソッド呼び出しの生成規則:　expr0 ". " expr2　[Turbofish] "()"　のexpr0から推論しないルールが既にあるからできないだけじゃないの？
これを拡張すると2)から互換性を失う可能性がある。公開された型と関数のシグネチャに依存してるんで。

**デフォルトの名無しさん** · 2020/07/06(月) 00:48:42.43

ぶぶんたそー
まれいたそー

**デフォルトの名無しさん** · 2020/07/09(木) 06:01:23.92

Rustの構文を自分でPython風にしてるんだけど、このwhereのとこの構文がどうも末尾:と相性悪くてどうしたら綺麗になるか教えて欲しい。
問題点
* Self: Sizedの型指定の:と被る(引数の型はかっこに埋まってるからいい)
* 一行目の関数宣言の:があるのに二行目でもwhere使うために:がある(二行続くのは英文法的にもおかしい)
* whereの構文ルールが曖昧(改行入れたりできる) -> だから統一したい
fn sum<S>(self) -> S:
where Self: Sized, S: Sum<Self::Item>:
Sum::sum(self)

**デフォルトの名無しさん** · 2020/07/09(木) 19:57:31.40

Rust にトランスパイルされる Python 風構文の言語を作っているということかな？

fn sum<S>(self) -> S
where Self(Sized), S(Sum<Self::Item>):
Sum::sum(self)

こんな感じで class の継承っぽく書くのはいかが

**デフォルトの名無しさん** · 2020/07/09(木) 20:52:03.73

そう、そういう言語作ってる最中。
たしかにその構文もいいね！でもstruct S(i32);に見た目上だけど被るのと、トレイトのfn name<T: Num>とかも構文変える必要でてくるなぁ
個人的にはトレイトベースの言語だからT: Numは変えたくないだよね
こういうのもいいかも
fn sum<S>(self) -> S,
(Self: Sized, S: Sum<Self::Item>):

whereと同じような機能でしっくりくる構文持ってる他言語とかないのかなぁ

**デフォルトの名無しさん** · 2020/07/11(土) 09:57:59.11

Haskell 風にするとかどうよ

**デフォルトの名無しさん** · 2020/07/11(土) 19:10:01.60

Winrtよく知らないんだけどWindows環境でGUI簡単にいじれるようになったの？

**デフォルトの名無しさん** · 2020/07/11(土) 19:28:45.72

どうせマクロ地獄だろ

**デフォルトの名無しさん** · 2020/07/14(火) 15:40:35.77

let delta = input[0] - input[1];
println!("{}{}", if delta == 0 { "" } else if delta > 0 { "-" } else { "+" }, delta.abs());
このif delta == 0 { "" } else if delta > 0 { "-" } else { "+" }の綺麗な順番とかの定石の書き方ってある？

**デフォルトの名無しさん** · 2020/07/14(火) 16:21:46.36

match delta.cmp(&0) {
std::cmp::Ordering::Equal => "",
std::cmp::Ordering::Greater => "-",
std::cmp::Ordering::Less => "+",
}

**デフォルトの名無しさん** · 2020/07/14(火) 18:24:58.52

n == 0の時だけ記号なしにしてそれ以外は{:+}でフォーマット
(n > 0の時だけ{:+}にするのでも結果は同じ)

**デフォルトの名無しさん** · 2020/07/14(火) 20:20:46.59

>>855
>>856
ありがとう、両方いいね！

**デフォルトの名無しさん** · 2020/07/15(水) 17:09:04.17

msvcとgnuってどっちにすべきなん？

**デフォルトの名無しさん** · 2020/07/15(水) 20:29:35.32

両方有るってことはどっちにでも出来るってこった。
どちらかが良いなんてことはない。

**デフォルトの名無しさん** · 2020/07/15(水) 21:20:40.13

rustコンパイルできないけどな

**デフォルトの名無しさん** · 2020/07/16(木) 01:35:03.21

以下のコードでクロージャclの引数に型推論が効かないのってなんでですか？
fn main() {
let vv = vec![vec![1, 2, 3]; 4];
let cl = |a, b, c, d| vv[a][b] + vv[c][d];
//error[E0282]: type annotations needed
println!("{}", cl(3usize, 1usize, 2usize, 2usize))

}
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=a49b194930fcdfd894c2be4fc078be80

クロージャclの引数のところを |a: usize, b, c: usize, d| とすればコンパイルは通るのですが、aとcだけ型注釈が必要になるのも意味がわからないです

**デフォルトの名無しさん** · 2020/07/16(木) 23:09:40.63

jsonをパースして、その中身に対して更に値を追加し
最後にはまたjsonでシリアライズということをやりたいのですが、
serdeだと事前に入力と出力の型を定義していないと難しいですか？

from_stringでValue型に入れて、mapのようにキー名で値を取れることは分かったのですが
そこに新たに値を追加する方法がわからないです

**デフォルトの名無しさん** · 2020/07/16(木) 23:23:19.49

as_object_mut
あたりかな

**デフォルトの名無しさん** · 2020/07/17(金) 00:05:43.64

https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html

予定通り来た
Rocketがstableの仲間入り

**デフォルトの名無しさん** · 2020/07/17(金) 01:59:14.04

>>863
ありがとう神様

C#ならすぐなのに、
これは理解するのに時間がかかりそうだ。

**デフォルトの名無しさん** · 2020/07/18(土) 18:30:51.49

神がついてるから大丈夫

**デフォルトの名無しさん** · 2020/07/20(月) 13:18:08.21

actix-wevからRocketに移行します

**デフォルトの名無しさん** · 2020/07/21(火) 02:22:25.82

>>867
その理由は？

**デフォルトの名無しさん** · 2020/07/21(火) 18:35:05.91

スライスから差集合を作るの際にスライスをそれぞれhashsetにしてdifference呼ぶ以外で良い書き方ありますか？

**デフォルトの名無しさん** · 2020/07/22(水) 00:13:53.48

それぞれsortして先頭から比較していく

**デフォルトの名無しさん** · 2020/07/22(水) 01:18:16.47

>>869
シンメトリックじゃない単なる差集合なら
片方だけsetにしてもう片方の要素でループしながらチェックするのでもいい気がする
あと状況によってはBroom filterみたいなのを使うと高速化できるかも

**デフォルトの名無しさん** · 2020/07/22(水) 13:33:09.23

fn aaa(s: &str) {
if s == "aaa" {
compile_error!(r"If s is "aaa", compile error!");

}
}
fn main() {
// compile error!
aaa("aaa");
// can compile
aaa("aaaaaaaa");
}

こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな

**デフォルトの名無しさん** · 2020/07/22(水) 13:33:41.15

こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな
↓
こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルエラーになるんだけど回避方法ってないかな

**デフォルトの名無しさん** · 2020/07/22(水) 15:44:52.79

>>870
>>871
㌧

**デフォルトの名無しさん** · 2020/07/22(水) 15:48:48.87

ダブルクォートがaaaの部分で外れてるのが原因とかじゃなくて？

**デフォルトの名無しさん** · 2020/07/22(水) 15:58:57.61

aaa(r#"aaa"iiii"uuuuu"#)

**デフォルトの名無しさん** · 2020/07/22(水) 16:04:28.78

>>875
ごめん。ここに貼る用のデバッグコメ。
そこ直したら本題の条件分岐のコンパイルエラーにならないのがでてくる
compile_error!(r#"If s is "aaa", compile error!"#);

**デフォルトの名無しさん** · 2020/07/22(水) 18:44:16.24

compile_error!は条件付きコンパイルかマクロでしか使えないんじゃ？
compile_error!と記述してる行がコンパイルするコードに含まれることになったらコンパイルエラー

マクロを展開する段階では変数の値を評価できないから
文字列を受け取る関数に対して特定の文字列を渡すコードがあったらコンパイルエラーってのは無理な気がする

**デフォルトの名無しさん** · 2020/07/22(水) 22:19:16.93

aaaを手続きマクロにすればできるとは思うけど。

**デフォルトの名無しさん** · 2020/07/23(木) 01:38:31.65

最近RustのSlackでも出てきた福野泰介ってやつ声でかいよな
こいつどのコミュニティでも何かしら主張して目障りだわ

**デフォルトの名無しさん** · 2020/07/23(木) 01:41:56.15

Ubuntu Japanese Team に言いつけて潰してもらおうぜ

**デフォルトの名無しさん** · 2020/07/23(木) 18:56:28.53

環境はMacOS Catalina, Rustは1.45.0です
今弄ってる物(https://github.com/Nercury/rust-and-opengl-lessons)で
/lib/gl/src/lib.rs内に
include!(concat!(env!("OUT_DIR"), "/binding.rs"));
というのがあるのですがですがcargo buildすると
this error originates in a macro
error: couldn't read /Users/Path/target/debug/build/gl-71effbf83f5b03a9/out/binding.rs: No such file or directory (os error 2)
と表示されます
https://github.com/rust-analyzer/rust-analyzer/issues/1964
https://github.com/rust-skia/rust-skia/issues/10
などを見たのですが具体的な修正がわかりませんでした。
Rustは最近始めたばかりでincludeマクロやcargoの仕組みなどまだあまり詳しくありません
このinclude!を成功させる方法を教えてください
迷惑をかけてしまうかもしれませんがご教授お願いします

**デフォルトの名無しさん** · 2020/07/23(木) 19:05:44.31

福野泰介はたしかにどこでも目立つ。
自己顕示欲もあそこまでいったら面白い、反面教師として役立つ

**デフォルトの名無しさん** · 2020/07/23(木) 21:20:06.43

>>882
lib/gl/build.rsでOUT_DIRにbinding.rsを作成してる

ビルドスクリプトが意図した通りに動いているのか確認するために
build.rsを変更してbinding.rsのフルパスをprintlnでもするようにして
cargo build -vvしてみるといいと思う

ビルドスクリプトについて詳細知りたければこの辺読んで
https://doc.rust-lang.org/cargo/reference/build-script-examples.html

**デフォルトの名無しさん** · 2020/07/24(金) 00:48:59.83

>>884
ありがとうございます動きました！
非常に長文だった自覚はあるんですが分かりやすくすっきりした回答ありがとうございますm(_ _)m

**デフォルトの名無しさん** · 2020/07/24(金) 10:22:52.41

同じサーバー内でポート別にクライアント用サーバー(Nuxt)とAPI用サーバー(Rust)立ち上げるのってどう思う？
クライアント用サーバーは初回しか性能響かないからあれだけど、Rustの方が断然速いし、SPAだからルートの設定も全然しなくていいし、Rustの方でフロントページも返した方がいいんじゃないかと思ってるんだけども
要はRustを実行すればポート別に２つサーバーが立ち上がるようにするってこと

**デフォルトの名無しさん** · 2020/07/25(土) 18:01:19.70

RocketってRust公式サイトにも使われてるのか
迷ったらRocketで良さそうだな

**デフォルトの名無しさん** · 2020/07/26(日) 03:19:09.22

diesel使いづらくない？

**デフォルトの名無しさん** · 2020/07/26(日) 18:57:03.68

rustcの-C llvm-args=が取り得るオプションの説明ってどこかに書いてある？
clangのttps://clang.llvm.org/docs/ClangCommandLineReference.html#x86
あたりがそれっぽいけど説明が全くないのでデフォルト値も効果もよく判らない

**デフォルトの名無しさん** · 2020/07/26(日) 22:31:29.89

>>889
ここに書いてあるけど'--help'を渡せば一覧表示されるみたいよ
https://doc.rust-lang.org/rustc/codegen-options/index.html#llvm-args

$ rustc -C llvm-args='--help'

**デフォルトの名無しさん** · 2020/07/26(日) 23:02:23.88

あるモジュールクラスを別のモジュールで使いたい場合ってどう宣言するのが正しいの？

正直ドキュメント読んでも分からん

**デフォルトの名無しさん** · 2020/07/26(日) 23:58:47.45

>>890
サンキュ。そう使うのかよｗ　うちの環境では
>rustc -C llvm-args=--help　←'を付けると怒られる
でそれっぽいのが得られました。amd64で使用命令を選択するようなオプションは無いのか・・・

**デフォルトの名無しさん** · 2020/07/27(月) 00:46:16.95

--helpの最後に出てたけど
利用可能なオプションを全部表示するには
llvm-args=--help-hiddenってするみたい

**デフォルトの名無しさん** · 2020/07/27(月) 09:47:21.61

chronoのnext_monthないのってどう実現すればできる？

**デフォルトの名無しさん** · 2020/07/27(月) 10:10:01.73

>>894
そもそもnext_monthに何を期待するかによると思うが。30日後？31日後？翌月の同じ日？それが存在しない場合は？とか。その辺がはっきりすれば、その通りに実装すればいい。

**デフォルトの名無しさん** · 2020/07/27(月) 10:18:30.24

翌月の同じ日ならこれかな。
https://docs.rs/chrono/0.4.13/chrono/trait.Datelike.html#tymethod.with_month

**デフォルトの名無しさん** · 2020/07/27(月) 16:16:44.20

>>896
ありがとう、結局next_month自分で実装したけど、かなり頻繁に使われる類のメソッドだから正直きついな
with_monthもoptionで返すから31 -> 30の次月遷移したとしても安全だから実装しない理由が分かんないな
chronoは変なとこには手回ってるしよくわからん

**デフォルトの名無しさん** · 2020/07/27(月) 18:03:20.70

>>897
issueはあるけど別に誰かが反対しているわけでもなく、
単に誰も実装してないだけじゃない？
PR出してみればいいと思うけど。

https://github.com/chronotope/chrono/issues/290

**デフォルトの名無しさん** · 2020/07/28(火) 16:26:39.82

>>891
じけつ

main.rsでそれぞれのモジュールをmod宣言

**デフォルトの名無しさん** · 2020/07/29(水) 11:56:30.09

ed25519の公開鍵のssh-ed25519 ******の部分が欲しくて、ed25519_dalekっていうクレートで鍵作ってるんだけどPublicKey構造体のas_bytesでとってくるバイト列をstr::from_utf8でしてもエラーが出て秘密鍵の***部分にならないんだけど、どうすればいいか分かる？
https://docs.rs/ed25519-dalek/1.0.0-pre.4/ed25519_dalek/struct.PublicKey.html

**デフォルトの名無しさん** · 2020/07/29(水) 20:03:32.01

1byteずつ print!("{:02x}", b) するとかではなく？

**デフォルトの名無しさん** · 2020/07/29(水) 21:31:44.28

>>900
str::from_utf8でエラーになるのは
0~127までのUTF-8互換のASCII以外の文字が含まれてるからでは？

pemで見れる公開鍵のssh-ed25519 ******の部分は
keyの種別とDERエンコードしたkeyの値をBase64にしたものらしい

**デフォルトの名無しさん** · 2020/07/30(木) 13:54:57.65

>>901
やってみたらエラーはでないし、ハッシュっぽいものできたけど、大文字ないから >>902の方法っぽいかも
4ef6dcfda191770b64939c5657fc26e631c2caffa18e423c397d761d507ae82a%

>>902
ありがとう、やってみるわ

**デフォルトの名無しさん** · 2020/07/31(金) 22:54:06.06

bindgenにwindowsはllvmのプリビルドバイナリをインストールしなさいと書いてあるけど、
LIBCLANG_PATH設定し忘れるとwinのプリビルドバイナリには含まれてないllvm-configを使って<LLVM_ROOT>/binまでのパスを探すんで
llvm-configがないって怒られる罠がある。

LIBCLANG_PATHタイポして時間潰してしまった。

**デフォルトの名無しさん** · 2020/08/01(土) 14:02:57.08

やっぱactixよりrocketだな

**デフォルトの名無しさん** · 2020/08/01(土) 14:09:11.29

>>905
その理由は？

**デフォルトの名無しさん** · 2020/08/01(土) 15:02:20.03

なんか速そうじゃん

**デフォルトの名無しさん** · 2020/08/01(土) 15:19:22.53

>>906
ドキュメントがしっかりしてそう

**デフォルトの名無しさん** · 2020/08/01(土) 16:43:51.04

unsafeの個数が少ない方が勝ちって事でいいんじゃない？

**デフォルトの名無しさん** · 2020/08/01(土) 22:13:51.53

rocketってmultipartサポートしてないのか

**小石茶輝** · 2020/08/01(土) 23:31:58.80

unsafe という機能があるのは unsafe が必要だからです。
設計方針に対して必要以上に unsafe があるのはダメですが、
少なければ少ないほど良いというわけでもありません。

たとえば C++ を使っているときだって、
グラフィックドライバを書くときとかは
どうしたって (C++ 的には) 行儀の悪い書き方になってしまうでしょう。

行儀の悪い部分はなるべく低レイヤに押し込めて、
ロジック層が綺麗になるようにするのが望ましいなどといった習慣はありますが、
どの程度にするかの程度問題は設計方針によります。

actix は rocket よりも unsafe を多用してはいますが、
意図のはっきりした unsafe です。

あまりにも unsafe が多すぎるならもう Rust 使うのやめろよと思うかもしれませんが、
行儀の悪い書き方 (unsafe) がより明示的であるというだけでも
C++ よりは少しマシでしょう。

**デフォルトの名無しさん** · 2020/08/06(木) 21:31:08.70

rust案件が出てこないのは何で？

**小石茶輝** · 2020/08/06(木) 23:35:19.16

出てますよ。
あなたがそれをキャッチする立場にないだけです。

**デフォルトの名無しさん** · 2020/08/08(土) 01:19:04.76

stdの中でこれは外部ライブラリにした方がいいんじゃないかなって思うやつある？
逆に外部ライブラリからstdにした方がいいんじゃないかってやつとかもある？

**デフォルトの名無しさん** · 2020/08/08(土) 06:00:59.71

>>914
乱数ライブラリが標準ライブラリに入ってない言語とか他にあんの？

**デフォルトの名無しさん** · 2020/08/09(日) 00:20:40.65

乱数は用途によって必要な性質が色々だからなぁ。
どの分野を優遇すべきかってのは自明ではないでしょ。
全部盛りにするのも Rust 的ではないし。

でも、どの乱数ライブラリを使うにしても同じようなインターフェイスだとありがたいので、
乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
そのサンプル的な位置づけでひとつくらいは乱数ライブラリが入っていてもいいかなとは思う。

◆QZaw55cn4c · 2020/08/09(日) 00:37:01.23

>>916
MT だけでいいと思うのですが

**はちみつ餃子** ◆8X2XSCHEME · 2020/08/09(日) 00:43:58.48

>>917
メルセンヌツイスタは統計的な性質は良いけど暗号的には使い物にならんしデカい。
常にベストと言えるほど良い選択ではないよ。

◆QZaw55cn4c · 2020/08/09(日) 01:29:16.04

>>918
確かに暗号にMTを使うのはダメですね、暗号用には crypt-MT がありますね

**デフォルトの名無しさん** · 2020/08/09(日) 20:40:18.77

今はもうMTもそこまで・・・って話じゃないっけ
randクレート見るとそんなこと書いてあったような

**デフォルトの名無しさん** · 2020/08/09(日) 20:55:04.69

他の言語だって完璧な乱数だと思ってなくても
利用者の利便性を考えて標準ライブラリに含めてるんだろ
それが無いRustは変

**デフォルトの名無しさん** · 2020/08/10(月) 00:22:38.94

今どきMT法なんか使わん。

>乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
rand_coreがそれに当たるけどcoreだけだとバイト配列しか取得できんので分布器に生成器渡せん。
未知の生成器の実装すべて含めるのは無理、既知のものに絞っても要求する特性が人によって違うから標準にするのは無理。
結局はこうなるが、俺も標準ライブラリに乱数ほしい。

**デフォルトの名無しさん** · 2020/08/10(月) 01:32:59.38

cargo使ってるから別ライブラリでもあまり困らない
こと乱数に関してはデファクトスタンダードのcraete決まってるし迷うことないしね
標準ライブラリに入ってて欲しいのは初学者がcrate知らないとか探すのが手間だとか、コンパイルタイムが延びるのが嫌だとか、そういう理由？

**デフォルトの名無しさん** · 2020/08/10(月) 02:16:28.69

stdに入れて欲しいのはrandよりregexだな
標準ライブラリとして責任もってメンテされていくものなのかどうかが重要

**デフォルトの名無しさん** · 2020/08/10(月) 03:21:04.11

>>924
あちこちのcrateでregex使ってるから
コンパイル遅くする原因になってるわ

**デフォルトの名無しさん** · 2020/08/10(月) 04:22:44.62

Authors のところが The Rust Project Developers ってなってるやつは
事実上の標準みたいなもんと思ってええんけ？
将来の互換性が保証されるかどうかはともかくとして Rust と足並みがそろっているとは
思っていいよね？

**デフォルトの名無しさん** · 2020/08/10(月) 05:17:58.40

jsonrpc使ってみた。不可解な実装でワロタ

**デフォルトの名無しさん** · 2020/08/10(月) 23:12:44.03

外に出されたunicode系ライブラリが更新止まってていつかstdがサポートするunicodeのバージョンと互換性失うんじゃないかと思う。

>>926
事実上の標準っていうかc++のboostみたいなもんだけど足並み揃ってるかは別。

**デフォルトの名無しさん** · 2020/08/11(火) 13:18:54.05

use std::ops::{Rem, AddAssign};
pub fn get_days_of_month<T: Rem>(year: T, month: u32) -> u32 {
match month {
2 => if is_leap_year(year) { 29 } else { 28 },
4 | 6 | 9 | 11 => 30,
_ => 31,
}
}
pub fn is_leap_year<T: Rem>(year: T) -> bool {
match ((year % 100 as T) as i32, (year % 400 as T) as i32) {
(_, 0) => true,
(0, _) => false,
_ => year % 4 == 0,
}
}
pub fn next_day<N, T: AddAssign + Rem>(mut year: T, mut month: u32, mut day: u32) -> (T, u32, u32) {
let days_of_month = get_days_of_month(year, month);
day += 1;
if day > days_of_month {
month += 1;
day = 1;
}
if month > 12 {
year += 1;
month = 1;
}
(year, month, day)
}
non-primitive castエラーが出るんだけどどうすれば解決できる？
1 as Tでもできないし、1.parse()はstrじゃないから出来ない

**デフォルトの名無しさん** · 2020/08/11(火) 13:40:48.45

>>929
num-traitsのOneで制約すればT::one()でT型の1が得られる。

**デフォルトの名無しさん** · 2020/08/11(火) 17:18:59.34

>>930
i32 か u32を受け取るトレイト境界ってつくれない？
あとAdd<u32> for u64とかの実装していない理由とかって何？

**デフォルトの名無しさん** · 2020/08/11(火) 18:03:39.15

>>931
自分で作ればいい。
型変換は明示的にしろ、ってことだろう。

**デフォルトの名無しさん** · 2020/08/13(木) 18:54:36.47

ゲーム開発言語はrustに移行されるかな？

**デフォルトの名無しさん** · 2020/08/13(木) 23:00:02.19

プログラミング言語「Rust」、Linuxカーネルでの採用の道を模索
https://japan.zdnet.com/article/35157012/

**デフォルトの名無しさん** · 2020/08/14(金) 22:24:07.75

>>933
個人の開発に使ってるけどバインディングだらけになる。
ミドルウェア1から作る新規開発くらいじゃないとrustの恩恵がフルに受けられないと思う。
あと、コンパイル遅いのが辛い。

**デフォルトの名無しさん** · 2020/08/15(土) 03:05:14.85

ラズパイとかでコンパイルすると糞遅いのなんとかならんかな

**デフォルトの名無しさん** · 2020/08/15(土) 06:26:45.05

禁断のCPU換装とかないの？
DOS/Vパワーリポートとか買ってみたら。

**デフォルトの名無しさん** · 2020/08/15(土) 06:47:50.15

>>936
クロスコンパイルすれば？

**デフォルトの名無しさん** · 2020/08/15(土) 21:53:54.93

というよりなんでセルフコンパイルするんや？

**デフォルトの名無しさん** · 2020/08/15(土) 23:19:51.01

rustじゃないけど適当な設定で大きいライブラリビルドしたら過熱でラズパイ落ちた事あるわ

**デフォルトの名無しさん** · 2020/08/17(月) 18:33:01.49

Rより低いRust...
https://japan.zdnet.com/article/35158190/

**デフォルトの名無しさん** · 2020/08/18(火) 04:18:41.28

rustって日本で人気という勝手なイメージがあるけど世界的にはどうなんだろ

**デフォルトの名無しさん** · 2020/08/18(火) 04:32:12.17

ルスト？なにそれ？てかそんなの聞いた事ないんだけど

**デフォルトの名無しさん** · 2020/08/18(火) 15:54:29.74

>>941
Goの方がマスコットがかわいいからしゃーない。

**デフォルトの名無しさん** · 2020/08/18(火) 16:39:58.87

マスコットが気持ち悪い言語と言えばLISP

**デフォルトの名無しさん** · 2020/08/18(火) 18:04:09.30

>>944
いやいやいやいy・・かわいいかアレ？？
どぉおおおおおみてもキモい