プログラミング言語 Rust 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/05/21(日) 14:04:29.55

Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。

http://www.rust-lang.org/
https://github.com/rust-lang/rust

Servo
https://servo.org/
https://github.com/servo/servo

◆前スレ
プログラミング言語 Rust 2
http://echo.2ch.net/test/read.cgi/tech/1478023960

**デフォルトの名無しさん** · 2017/07/29(土) 12:41:44.44

vim + project.vim + rust.vimもいいぞ
コード量が多いと流石にIntelliJ使うけど

**デフォルトの名無しさん** · 2017/07/29(土) 12:52:24.62

IDEAとvscodeってどっちがおすすすめ？

**デフォルトの名無しさん** · 2017/07/29(土) 12:52:42.83

おすすめ？

**デフォルトの名無しさん** · 2017/07/29(土) 14:45:43.16

>>313
噂をすればなんとやら
facebookexperimental/mononoke: A Mercurial source control server, specifically designed to support large monorepos.
https://github.com/facebookexperimental/mononoke

>>351
メモリ安全性以外での所有権の活用例としては、すでにボディを書き込み始めたHTTPレスポンスに新たにヘッダを書き込めないことを静的に保証する、とかいうのがある
https://docs.rs/hyper/0.10/hyper/server/index.html#an-aside-write-status
ヘッダを書き込んだレスポンスの所有権を奪って、ボディだけを書き込める型にして返している
https://docs.rs/hyper/0.10/hyper/server/response/struct.Response.html#method.start

**デフォルトの名無しさん** · 2017/07/29(土) 16:04:35.17

もののけ

**デフォルトの名無しさん** · 2017/07/29(土) 16:29:29.84

ideaのrustプラギンはメソッドチェインが深くなるとハイライトされなくなって、リネームとかも取りこぼすことがある。それ以外はよくできてて満足

**デフォルトの名無しさん** · 2017/07/29(土) 16:43:27.84

>>351
所有と借用は、設計の考え方として言語問わず有効なので、コンパイラに強制されるのはかなり嬉しい。

と言うのも、所有を考えないで動的メモリを使ったプログラムは、シングルスレッドであっても、ライフタイム問題を起こしやすいんだよね。
他人にヤラれると殺意がわく。

**デフォルトの名無しさん** · 2017/07/29(土) 16:55:38.17

>>351
借用に関しては、不意の同期漏れ防止と思ってる。

ご存知の通り、マルチスレッドでは、同じオブジェクトを触るときに同期処理を入れないと、データ破壊しちゃうじゃん？
C言語だと、この危険な状態がデフォルトで、気付くかどうかは人間次第。
でも、rustはコンパイラがその危険な状態を防いでくれると言うだけだと思う。

**デフォルトの名無しさん** · 2017/07/29(土) 17:08:36.25

>>351
最後、OS無しはどうかなー。

自分ならこうするかなっていうテキトーな意見だけど、生メモリアクセスが必要な部分（デバドラとか）はC/C++で書いて、アプリ部をrustで書いてFFIバインドかなー。

**デフォルトの名無しさん** · 2017/07/29(土) 17:23:05.64

Rustの素晴らしさを理解するにはC++を理解する必要がある？

**デフォルトの名無しさん** · 2017/07/29(土) 17:27:03.96

>>360
メモリ安全にかけるのがrustなら
最初から最後までrustで書けるべきじゃない？

**デフォルトの名無しさん** · 2017/07/29(土) 17:41:05.57

>>362
最初から最後までメモリ安全じゃなくてもいいんじゃない？
適材適所で使い分ければ。

マルチスレッド問題はアプリ側に多い問題かなーって。
デバドラ最下層になると、そもそもマルチスレッド要件が無かったり、メモリイメージが生で見える触れる方が融通があって便利だったりするし。

ドメイン境界で考えて、rustを適用する範囲内で潔白なのが重要と思ってる。
この潔白さは、開発者の人数が多いドメイン（アプリ）で、真価を発揮するんじゃないかなと。

**デフォルトの名無しさん** · 2017/07/29(土) 18:00:00.71

racer + flycheck-rust でマクロ補完って無理？
println!とかwrite!とか毎回全部打つのがダルい

**デフォルトの名無しさん** · 2017/07/29(土) 18:10:49.31

>>363
結局cには勝てないのか。
rustってgcがないからメモリイメージを直接いじりやすいのかと思ってたよ。
redoxとかも結局c++に頼ってたりするんかな？

**デフォルトの名無しさん** · 2017/07/29(土) 18:13:03.21

>>363
あと最初から最後までメモリ安全のほうが良くない？
少なくともメモリ関連のバグを撲滅できるんであればrustの価値はあると思うんだ。
逆にできないならrustの存在意義ってなんだろ。

goは並行処理が言語機能に組み込まれてる。
rustはメモリ安全が売りだと思うんだけど、
そこってなかなか地味な売りな気がして

**デフォルトの名無しさん** · 2017/07/29(土) 18:57:22.38

>>365
Cに頼る→負けてるって事じゃないと思うけどね。
実際アセンブリ言語はなくならないわけだし。

CPU の高機能化、メモリの大容量化、プログラムの大規模化、があって、開発効率を高めるために、プログラムの大部分がC言語に置き換わったわけじゃん。
で、マルチコア全盛の時代になって、正常稼働面での重大要因としてメモリ安全性が注目されてrustが生まれたのだから、メモリ安全のメリットの大きいところだけrustに置き換わるってのが、普通の流れじゃないのかなーと思うよ。

別にCを駆逐する必要はないしょ。

**デフォルトの名無しさん** · 2017/07/29(土) 19:02:32.30

>>366
そもそも、ハードに近い層でのメモリ安全性って何？って話だと思うんだ。

で、メモリ安全の話が出てこない領域なのだから、rustの出番が無いって事で良いんじゃない？

**デフォルトの名無しさん** · 2017/07/29(土) 19:05:29.70

>>361
むしろC++をうまく使うために、rustの意味論（セマンティクス）を勉強して欲しい、って思う。

**デフォルトの名無しさん** · 2017/07/29(土) 19:59:14.72

goができたのはgoogle社内のc++プロジェクトの置き換えのためだけどrustってどんな動機でできたの？。
まさかブラウザ開発のため？

**346** · 2017/07/29(土) 20:14:02.81

>>347
キャッシュを無効にして毎回警告を出すにはどうしたら良いでしょうか？

**デフォルトの名無しさん** · 2017/07/29(土) 20:22:55.12

>>369
俺もRustはじめてからC++が少しよく書けるようになりました

**デフォルトの名無しさん** · 2017/07/29(土) 21:18:30.65

>>355
へー、monorepo用だからモノノケとな

mercurialをベースに仮想ファイルサーバーにする予定とは、なかなか壮大な計画だ

**351** · 2017/07/29(土) 21:52:24.31

レスありがとうございます

>>355,358-359
なるほど。やはり並列処理時の安全性を担保する機能なのですね
組み込みでRTOSもどきを作って並列処理させるなんて場合には有効なのかな

>>360
構文上罠が多いC/C++の代替となる言語を探していてRustを検討しています
なのでC/C++を使わずにC/C++相当のことを行いたいです
警告もエラーも無しに動作だけがおかしいとか勘弁して欲しいです
他にDも検討していますが何となく新しい方が何かと便利かなと思ったり・・・

**デフォルトの名無しさん** · 2017/07/30(日) 03:44:39.97

以前にこのスレであったら良いと言われていたOptionのEntry風APIが実装されて、しかも既にstabilizeされている
std: Stabilize `option_entry` feature ・ rust-lang/rust@ee064c3
https://github.com/rust-lang/rust/commit/ee064c380652fb7e40c1620fd74fb1406989d009

**デフォルトの名無しさん** · 2017/07/30(日) 08:00:41.23

>やはり並列処理時の安全性を担保する機能なのですね

race condition の解消はあくまでもメモリ安全の一部でしかない

**デフォルトの名無しさん** · 2017/07/30(日) 08:02:46.70

>他にDも検討していますが何となく新しい方が何かと便利かなと思ったり

Dが検討対象に入って、かつ、低水準用途なの？
意味わからんな

**デフォルトの名無しさん** · 2017/07/30(日) 08:03:42.92

351からは実際にプログラム組んだことの無い人の気配がプンプンしてる。

**デフォルトの名無しさん** · 2017/07/30(日) 11:40:03.02

cargo check のメッセージが加工しづらい
https://github.com/rust-lang/rust/issues/42653これ追加されて欲しい

**デフォルトの名無しさん** · 2017/07/30(日) 16:21:42.29

たぶんnode.js育ちの人だと思うけど、実質1行ないし3行で完結してるクレートが出てきてるね

**デフォルトの名無しさん** · 2017/07/30(日) 17:42:42.26

clippyインストールできないclippyインストールできないclippyインストールできない
clippyインストールできないclippyインストールできないclippyインストールできない
clippyインストールできないclippyインストールできないclippyインストールできない
修正したコミットがが日曜の夜にコミットするって作者が言ってるけど遅すぎ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

**デフォルトの名無しさん** · 2017/07/30(日) 19:43:29.15

CランタイムをスタティックリンクしたくてRUSTFLAGSに以下のフラグを設定しています。

RUSTFLAGS='-C target-feature=+crt-static'

これを環境変数で設定するのではなくCargo.tomlで指定するにはどうすればいいんでしょうか？
http://doc.crates.io/config.html を参考に下のように書いてみたのですが効いてないようでした。

[build]

rustflags = ["-C target-feature=+crt-static"]

オプションの書き方が違っているんですかね？

**デフォルトの名無しさん** · 2017/07/30(日) 19:51:11.45

["-C", "target-feature=+crt-static"]
でどうかしら

**デフォルトの名無しさん** · 2017/07/30(日) 20:00:04.61

うーん、このへん試してみたんですけどだめなんですよね。

["-C", "target-feature=+crt-static"]

["target-feature", "+crt-static"]

**デフォルトの名無しさん** · 2017/07/30(日) 22:39:37.27

>>381
一時的に古いnightly使えば良いのでは

**デフォルトの名無しさん** · 2017/07/30(日) 23:38:44.64

まだruct学んで2日目だけど
これパッケージ入れる時のコンパイルが長いね
補完強化のためにracer入れようとしたらsyntax_syntaxから全然進まなくてCTRL+C押しちゃったよ
基本的なものを覚えるだけならパッケージなんて入れなくても良さそうだけど
ステップアップしたときにそれなりのスペックのPC持ってないと学習するのが厳しい言語って感じ

**351** · 2017/07/31(月) 01:33:05.73

>>377
C/C++より判りやすく罠が少なくC/C++で出来ることは全て出来る言語を探しています

>>378
ネイティブに動くプログラムで一番経験があるのはアセンブラ(組み込み)です
C/C++はなんの警告もなくメモリがぶっ壊れるし、どこが壊しているのかも判りにくいし
苦手です

**デフォルトの名無しさん** · 2017/07/31(月) 09:17:51.12

アセンブラは型がないぶんさらにメモリ壊しやすいと思うが

**デフォルトの名無しさん** · 2017/07/31(月) 13:44:43.25

ライフタイムもコンパイル時に検査してライフタイムの外側からアクセスする処理もコンパイルエラーにするって

これって結局
全部ローカル変数になるってこと？
プログラム全体を通してアクセスする変数はmain関数で用意したローカル変数だからmain関数を抜けたあとは全部開放しちゃうからメモリリークも起きない？

cとかでもやろうと思えばできるって事？
cでmallocとかfreeを使わず、
全部変数定義してつかえばrustと同じ？

**デフォルトの名無しさん** · 2017/07/31(月) 16:54:10.50

メモリに限らずリソース確保全般を行わないプログラムって何ができるのか
可変サイズの入力を受け取るならmallocがほぼ必須じゃない？
1行MAX_LENGTH文字までのテキストしか処理しないとか？

**デフォルトの名無しさん** · 2017/07/31(月) 17:16:32.22

rustってどんな分野に向いてるのかいまいちわからないんだけど
webに使うのはおすすめできる？

**351** · 2017/07/31(月) 19:18:45.74

C/C++は言語仕様的にメモリの破壊を誘発しやすいと思っているんだけどそう思うのは自分だけなのだろうか

>>388
プロジェクトやプログラムの規模という要素もあるけどメモリを自由に管理できるアセンブラの方が見通しが良く
メモリ破壊に関するリスクも制御しやすいと思う。人間が理解しやすいように並べることも出来るし
もしメモリを壊した時もC/C++より何が起きるかを予測しやすいと思う

個人的にはメモリアクセスの規約を登録できてコンパイル時にそれをチェックしてくれると嬉しいんだけどな

**デフォルトの名無しさん** · 2017/07/31(月) 19:24:58.57

アセンブリ的な観点でCの挙動が予想できないと言っているようならRustなんて余計に抽象的で分かりづらいと思うのだが
Volatile関連の制御とかだって面倒なだけだし

**351** · 2017/07/31(月) 21:28:38.42

>>393
C/C++はメモリマップを意識しないと安全を確保できないけど、マッピングするのはコンパイラでありリンカでありOS
そのような状態で想定しないメモリアクセスが起きた時の挙動を予想することは自分には出来ないです
C/C++でバリバリ書いている人はこの程度出来て当たり前なのかな

**デフォルトの名無しさん** · 2017/07/31(月) 22:26:49.07

C/C++というレベルじゃなくて
LinuxのABIやldのリンカスクリプトがわからんレベルの人と予想

**デフォルトの名無しさん** · 2017/08/01(火) 18:09:39.02

>>391
いわゆるWebアプリを書く言語としてはおすすめしない。

**デフォルトの名無しさん** · 2017/08/01(火) 18:17:25.28

>>392
C/C++に慣れていないだけでは。
もしくは動的なメモリ確保を想定していないとか。

**デフォルトの名無しさん** · 2017/08/01(火) 18:21:43.31

>>394
(わりと一般的な)OS上で動かす限り、アセンブリ言語で書いても
リンカとローダが介在することには変わりないと思うけど。

**デフォルトの名無しさん** · 2017/08/01(火) 18:52:10.83

>>351はOS無しと言っている

**デフォルトの名無しさん** · 2017/08/01(火) 19:26:38.99

>>351
OSなしアセンブラを必要とする層で使える汎用高級言語を探してるならRustは適さないからお帰り
そういう言語が存在する気はしないけど夢追い人っぽいから応援はしてるよ

**351** · 2017/08/01(火) 19:28:04.99

新しめのプログラミング言語は十中八九メモリの安全を謳っているけどこれってC/C++でメモリの破壊や
メモリアクセス違反を多発させる事例が多いからと思っているけど違うのかな
これらの低減を目的にC/C++の代替言語としてRustやDなどを検討するっておかしな事なのだろうか

**デフォルトの名無しさん** · 2017/08/01(火) 21:16:08.18

>>400
まじかーgcがないってOS無しで動かせる唯一の言語だと思ってたから残念
例えばESP8266とかESP32で使えたらいいとか思ってたよ。

webが利用用途じゃないって残念すぎるな。
そうするとrust使ってる層って仕事でc++を使ってる組み込み関係の層が
趣味的に触る言語ってことかな。

**デフォルトの名無しさん** · 2017/08/01(火) 22:02:02.77

お前の中ではGC有無とOS要否は直結するのか(驚愕

ESPがどういうチップセット構成なのか知らんけど
ARM CPUならクロスコンパイルして動かせるんじゃね
多分、同じ程度の努力でGC載ってるGoも動くと思うけど

**デフォルトの名無しさん** · 2017/08/01(火) 22:04:43.31

cargo checkすると
warning: the option `Z` is unstable
というメッセージが出るそうなんですがこのメッセージを出す方法を教えて頂けませんか？

**デフォルトの名無しさん** · 2017/08/01(火) 22:04:54.04

Webに関してはそれなりに精力的に開発されているから将来的には使い物になる可能性もある
crates.ioとかだってRust製だしね

**351** · 2017/08/01(火) 22:43:53.38

>>402
ググるとラズパイ(タダのLinuxだが)向けコードをRustで書いてみたとか、プレステ1用のコードをRustで書いてみた
とか出てくるんだよね。自分が組み込みに使えるんじゃないかと思ったのもその辺が目にとまったから
昔よりかなり良くなっているとは言え汎用機と比べるとデバッグ手段は限定されるし、コンパイル時にコードの妥当性が
ある程度保たれるというのはメリットだと思う
組み込みで「どこかのメモリを壊しているようだが皆目見当が付かない」なんて事態は可能な限り回避したいしね

**デフォルトの名無しさん** · 2017/08/02(水) 00:38:23.97

>>400
いや、そういう用途向けでしょ。
実際にOSの実装に用いられてるし。

**デフォルトの名無しさん** · 2017/08/02(水) 00:46:25.26

上の人はOSを書こうとしているんじゃなくてOS無しのままコードを書くつもりなんでないの？
言い換えると、extern crate coreすら出来ないやつ

**デフォルトの名無しさん** · 2017/08/02(水) 01:03:22.66

なんか勘違いしてる人がいるね
Rustが強いのは「ちゃんとラップしてあげれば」どんな環境でも「安全に」動かせること
例えばとあるレジスタを触っているときに他のレジスタを触れないようにするとかも（場合によってはコンパイルエラーのレベルで）できる
ただこのラップするっていうのが一番面倒で、そこで安全を担保できなければ＝unsafe祭りならむしろCのが楽とも言える
ちょっとググったらArduinoでRustを動かすためのライブラリもあるからその辺り参考にすると良さそう

>>408
OS書くのもOS無しで書くのも変わらないと思うんだけど、coreを含められないってどういう状況？
libcoreは何にも依存してないからそんな状況ありえないと思ってた

**デフォルトの名無しさん** · 2017/08/02(水) 01:08:41.51

アセンブリ君

**351** · 2017/08/02(水) 01:16:10.65

あー・・・何となく判ってきた。組み込みでそのようなコードを書くのか判っている人からレスが付いていたのか

**デフォルトの名無しさん** · 2017/08/02(水) 01:21:03.63

>>396
>>405
今は使い物にならないって事？
向いてると思って趣味のWEBアプリに採用したけどやめたほうがいいのかな
Golangは古臭すぎて使う気起きないし
正直速度はどうでもいいけど構文が好き

**デフォルトの名無しさん** · 2017/08/02(水) 01:21:20.56

coreだって何にも依存しないというわけではない、けれどそれは自分で用意すれば良いしね
rust_begin_panicとかをどうやって用意するのかは知らないけど

**デフォルトの名無しさん** · 2017/08/02(水) 01:22:27.24

RustでもOS書けるでしょ
(もちろんCと同じく最低限のアセンブラはいるが)
ぐぐればいろいろ見つかるぞ

**351** · 2017/08/02(水) 01:38:12.16

>>411ミスった。訂正
×　組み込みでそのようなコードを書くのか判っている人
○　組み込みでどのようなコードを書くのか判っていない人

>>409
>例えばとあるレジスタを触っているときに他のレジスタを触れないようにするとかも（場合によってはコンパイルエラーのレベルで）できる
そういう話を聞きたかった。レジスタの操作順までコンパイラレベルで面倒を見てくれたらありがたいと思う
xに値を書き込む時はyのnビットを1にしてからxへ書き込むとかあるしな。その定義を作る気力があるかはともかくとして

>そこで安全を担保できなければ＝unsafe祭りならむしろCのが楽とも言える
ペリフェラルレジスタだけunsafeにしてすればと思ったけどそう単純な話ではないのかな
もちろん入力値のチェックは必要になるだろうけど

**デフォルトの名無しさん** · 2017/08/02(水) 02:29:19.43

>>413
確かにmemcpyとかあるね、忘れてた
まあこの辺りはCでも間違いなく自分で書くとこなので大したコストじゃないね
> rust_begin_panic
組み込みならシリアルにでもログ出して無限ループとかが普通かな？
こういうのはOS系のプロジェクトがとても参考になる

>>415
> その定義を作る気力があるかはともかくとして
実行時チェックなら多少楽になるだろうしそこは（精神的）コストとの相談だね

> ペリフェラルレジスタだけunsafeにしてすればと思ったけどそう単純な話ではないのかな
個人的にはunsafe使い始めると至る所で使うようになっちゃうのでお勧めしない
Rustの思想的にも未定義の挙動を許すunsafeはできるだけ避けるべきだしね
そんなの気にせずチェックしたいとこだけチェックさせるLint的な使い方もありっちゃあり

**デフォルトの名無しさん** · 2017/08/02(水) 07:02:07.94

redoxのアセンブラで書いてる所すらもrust(高級言語)で書きたいって夢を語ってるんじゃないの？
結局何がしたいのか分からんな・・・

そこについては諦めているなら既に実用化されているし
そこを追っているならチップ毎のクロスコンパイラ作りを頑張れとしか言いようがねぇよ

**デフォルトの名無しさん** · 2017/08/02(水) 08:11:06.98

>>415
レジスタまで意識する用途なら、高級言語を使わないのが正解では

> xに値を書き込む時はyのnビットを1にしてからxへ書き込むとかあるしな。
それこそボード固有の話になるので。
高級言語でやるとしたら機能レベルで関数化して中身はインラインアセンブリで頑張るとか。
何れにせよ言語レベルで対応する話ではないな。

**デフォルトの名無しさん** · 2017/08/02(水) 10:50:44.07

>>412
>向いてると思って趣味のWEBアプリに採用した

やってみたら良いと思う。
仮にミスマッチだったとしても、過程や結果を公開すれば、色んな人の役に立つ。

**デフォルトの名無しさん** · 2017/08/02(水) 12:12:53.41

rustっていまのところ
何にも向いてないということか。

golangみたいにgoといえば並列処理！みたいなウリがないとなかなか厳しいな。
とりあえずwebはgoでいいや。

**デフォルトの名無しさん** · 2017/08/02(水) 12:21:18.09

>>419
webアプリ作るならunsafe必須とか？
cもc++も触った事ないからunsafeだけは無理なんだけど…

**デフォルトの名無しさん** · 2017/08/02(水) 12:56:49.05

変なチューニングに走らない限りはunsafeは不要
ただしRailsでいうところのDoorkeeperやPaperclipみたいな便利ツールが少ないからそのあたりは自力でどうにかする必要がある
あと、現状で主要なフレームワークはみんなsynchronous。ただしRocketはそう遠くない将来にasync対応しそう。Ironはそもそもやる気があるのか分からん

**デフォルトの名無しさん** · 2017/08/02(水) 15:19:15.45

>>422
unsafeは不要なのか、よかった
Railsは使ったことないから分からない
今まではNode.jsでexpress使ってたからそのまで分厚いフレームワークは使ったことない
rustってイベントループじゃなくてスレッドだよね？10K問題はどうなの？

**デフォルトの名無しさん** · 2017/08/02(水) 16:38:11.64

goでいいや、という人はまさにgoでよいのでは。
goではいやだ、という人むけ。

**デフォルトの名無しさん** · 2017/08/02(水) 16:42:18.62

goとかいうmapもnull安全もないうんこは絶対NG

**デフォルトの名無しさん** · 2017/08/02(水) 17:58:49.69

goが嫌だと言うなら
kotlinという選択肢もある。
これだとアンドロイドアプリももれなく使えるようになるし、
null安全だし。
何よりideが既にある

**デフォルトの名無しさん** · 2017/08/02(水) 18:06:51.08

過疎だからいいけどrustの話しようぜ

**デフォルトの名無しさん** · 2017/08/02(水) 18:07:43.92

kotlinもscalaもjvm言語だからあまりnull安全じゃない

**デフォルトの名無しさん** · 2017/08/02(水) 19:54:07.78

rustはno_coreにしてベアメタルでリージョンにメモリ管理やってもらうだけに全振りすればいいよ！
え？ヒープ使いたい？rustc_privateでalloc系をだな。
アセンブリもcpu毎にアセンブラ用意するのが面倒くさいからrustのinline asm使おうぜ。

>>404
そのまんま。
cargo checkはZオプション付けてるだけだから「Zオプションは安定してないから注意しろよ」ということ。

>>428
言ってる意味がわからない。

**351** · 2017/08/02(水) 20:02:49.43

>>416
unsafeを使わないと任意のアドレスを読み書きできない(＝レジスタにアクセス出来ない)と思っていたけど他の手があるのか

**デフォルトの名無しさん** · 2017/08/02(水) 20:28:52.05

本格的にOS無しの世界に入ったことが無いから適当だけど、関数型プログラミングの道具が使える、とか？>Rustのメリット
代数的データ型とかラムダ式orクロージャが簡単に扱えるとか。

趣旨から外れるけど、Cの世界に入れるのと同じような感じでRustの世界に入ることができるのも個人的には良いと思ってる

**デフォルトの名無しさん** · 2017/08/02(水) 20:31:53.85

>>429
javaのライブラリ使える代わりにjavaライブラリはnull安全じゃないよって事

**デフォルトの名無しさん** · 2017/08/02(水) 20:54:36.60

>>429
＞cargo checkはZオプション付けてるだけ
補足するなら、これは非標準のcargo-checkサブコマンドの挙動であって、
標準のcargo checkは--emit metadataを使っているから警告は出ない

**デフォルトの名無しさん** · 2017/08/02(水) 21:09:38.43

>>429
>>433
普通に使ってれば表示されないメッセージなんですね
cargo checkが出力するエラーや警告などをもう少し調べたいんですけど
これってどこに乗ってるんでしょうか？
cargoのリポジトリクローンしてから適当なエラーでgrepしてもヒットしないんです

**デフォルトの名無しさん** · 2017/08/02(水) 22:00:58.19

>>432
VMじゃなくてライブラリの話ね。
ceylonみたいなjavaとのシームレスな通信を捨ててるJVM言語はどうだろうか？

>>434
cargo-checkっていうthaad partyのサブコマンドがあるんだけど、
後にcargo自身に全く同じサブコマンド名でちょっと違うコマンドが追加されたの。
だからcargo-checkの方つかってるはず。

`cargo install --list`してみ。

ttps://github.com/rsolomo/cargo-check

**デフォルトの名無しさん** · 2017/08/02(水) 22:13:46.45

物騒なpartyのサブコマンドだな

**デフォルトの名無しさん** · 2017/08/02(水) 22:28:55.57

THAAD partyﾜﾛﾀ

**デフォルトの名無しさん** · 2017/08/03(木) 00:45:37.29

>>430
unsafeを使わないとできないってのはその通りだけど
> もちろん入力値のチェックは必要になるだろうけど
って処理を含めた関数を作ってunsafeな部分を支配下に含めることでunsafeでない処理にするってことが言いたかった
例えるとmallocの戻り値チェックを入れてOption<&mut T>を返す関数を作ってラップすることでunsafeでなくするって感じ
これを面倒くさがるとぬるぽに遭遇するがちゃんとラップすればガッが「一切」必要なくなるわけだ
でも今度はfreeしてない問題が発生するからスマポ作って・・・と徐々に面倒くさくなってきて > コストとの相談

>>431
ライフタイムとか借用とかの安全機能抜きにしてもパターンマッチとか他の言語機能で見てもRustは魅力的だよな
・・・まずい、mainにunsafe付けてBetter CとしてRustを使う世界もありな気がしてきたぞ

**デフォルトの名無しさん** · 2017/08/03(木) 04:52:30.89

Java の参照は、Nullable だから、
Kotlin で扱う場合、すべて、Nullable にすると面倒

そこで、Kotlin では、Platform Type (下の3) と言うものを作った

String 変数型に、Null 代入時、
1. String で、実行時に、IllegalStateException
2. String? で、Nullable だからOK
3. 型を省略(String!) で、実行時に、デリファレンスでヌルポ

1. は、インスタンスにアクセスする前に、代入時にエラー。
3. は、1よりひどく、インスタンスにアクセスして、ヌルポ

**デフォルトの名無しさん** · 2017/08/03(木) 07:06:29.97

Kotlin信者が必死だなw

JVM要する時点で組み込み/低レイヤーに向かねーんだよ、土俵が別次元だ馬鹿
Android ARTはJVMじゃない？そのランタイムサイズ、Rustのランタイムサイズの何倍になってるのか分かってんの？

**デフォルトの名無しさん** · 2017/08/03(木) 08:03:17.08

スレチ削除申請頼む

**デフォルトの名無しさん** · 2017/08/03(木) 08:29:31.88

組み込みスレ?

**デフォルトの名無しさん** · 2017/08/03(木) 08:39:41.14

>>441
いちいちスレチだけでレス削除してくれるほど運営も暇じゃねーよ
板違いのスレも最近は「落ちるまで放置してね」の方針なのに

**デフォルトの名無しさん** · 2017/08/03(木) 10:32:34.73

rust 1.21.0使ってますが英語苦手なので日本語ページ見てます
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/if.html
このページの一番最後
「else のない if では、その値は常に () となります」とあるので
let x = 0;
let y = if x == 1 { 1 };
println!("{}", y);
って書いたんですけどbuildしてもエラーになります
error[E0317]: if may be missing an else clause
()になりませんどうしてですか？

**デフォルトの名無しさん** · 2017/08/03(木) 10:33:20.99

>>440
ちなみにkotlin/native 開発中だからそれでrustと同じ土俵に立てるよ。
llvmの中間コード吐けるようになる。
rustより学習コストは低くて関数型チックな言語構文使ってるから
kotlin vs rustが勃発するな。
問題はandroid開発者を取り込めるからユーザー数は圧倒的
IDEも標準が存在する。
という点で色々rustは不利。
rustはwebAssenbryあたりで本領発揮できればいいんだけど。

**デフォルトの名無しさん** · 2017/08/03(木) 10:35:36.32

>>444
エラーメッセージ観るとelse節がないって怒ってるね
yに代入するんだからelseないと値が不定になるでしょ

**デフォルトの名無しさん** · 2017/08/03(木) 10:39:45.44

>>444
ごめんちゃんと読んでなかった

fn main() {
let x = 5;

let y = if x == 5 { () };
println!("{:?}",y)
}
これだと動くよね。型を() に統一しないとダメなんじゃない

**デフォルトの名無しさん** · 2017/08/03(木) 10:52:53.58

>>447
なるほどそういうことですか
省略しないほうがいいですね
ありがとうございました

**デフォルトの名無しさん** · 2017/08/03(木) 16:58:16.30

IntelliJ Rustプラグインが、（IDEの）公式プラグイン化した
ついでにちょっとおせっかいな表示も始めた
関数呼び出し部分に仮引数名を補完表示とか、省略された型宣言を補完表示とか

**デフォルトの名無しさん** · 2017/08/03(木) 22:02:43.27

有料化しなきゃどうでもいいかな

**デフォルトの名無しさん** · 2017/08/03(木) 22:11:43.17

JetBrainsが開発に参加しているというだけでもそれなりに心強い