[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/22 14:52 / Filesize : 279 KB / Number-of Response : 1015
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part16



1 名前:デフォルトの名無しさん mailto:sage [2022/06/27(月) 08:17:03.45 ID:gDlfKP6u.net]
公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

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

日本語の情報
https://rust-jp.rs/

※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 part15
https://mevius.5ch.net/test/read.cgi/tech/1652347700/

305 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 17:45:35.96 ID:bJtJfEbP.net]
Rust信者スレ作ったらそっちに移動してくれますか?

306 名前:デフォルトの名無しさん [2022/07/09(土) 17:54:41.59 ID:g+WH1rkE.net]
つまり、C++0xをパクって機能限定して簡単にしたのがRustだろ?

307 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 17:58:46.63 ID:QKZ/1qEu.net]
>>295
プログラミング言語の進化の中で、
そのメモリ自動解放における高速性と安全性の両立をRustが初めて実現したってことになるのかな

308 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:04:41.00 ID:SVLGLpJF.net]
Region-based Memory Management の構想は Cyclone から始まってる。
この段階では実用化したとは呼びにくいが、実現は出来ていた。

309 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:22:19.04 ID:HoR4NOuF.net]
>>304
C++以外からもいろいろパクってるからその言い方だと不正確に思う

310 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:46:05.22 ID:hyXSHlQu.net]
正確にはこうだな

プログラミング言語の進化の中で
メモリ自動解放における高速性と安全性の両立を実現した初めての実用的な言語がRust

311 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:55:55 ID:FBd+xess.net]
実用的の定義が無いので不正確です

312 名前:デフォルトの名無しさん [2022/07/09(土) 18:58:45 ID:g+WH1rkE.net]
C++0xがなかなか標準化されないので、それなら自分で作ろうと立ち上がったと本人が言ってるじゃん。

313 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:05:24 ID:hyXSHlQu.net]
>>309
そこは常識の範囲内で実用的をどのように定義しても>>308を満たすのはRustだけだから問題ない



314 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:22:48.72 ID:kZfneOfi.net]
別にC/C++でもちゃんと作れば高速性と安全性は両立してるよ
ちゃんと作るのが難しいかどうかの話でしかないだろ

315 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:29:47.99 ID:TbjkUF4v.net]
>>312
C/C++では不可能
うっかり危険なコードを書いてもコンパイラが通してしまう
Rustはコンパイラが指摘して通さないため安全

316 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:30:20.48 ID:6ug5/LDh.net]
難しさを度外視してちゃんと作ればいいと言うならアセンブラでも同じわけで。

317 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:36:03.58 ID:hyXSHlQu.net]
>>312
残念ながらCとC++は安全性を満たしていない
現状Rustだけが安全性と高速性を両立させている

318 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:48:49.13 ID:HoR4NOuF.net]
>>315
rustだけが満たしている根拠教えて

319 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:51:24.99 ID:zb7jG/MW.net]
じゃあChromeやSafari、Edgeじゃなく、お前のブラウザーふぁいあーふぉっくすにしろよ?安全じゃないんだろ?ぷゲラ

320 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:52:51.29 ID:FBd+xess.net]
うっかり前提条件が保証できていないunsafe fnの呼び出しを書いてもRustコンパイラは通してしまうではないですか

321 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:07:34 ID:kZfneOfi.net]
>>313,315
ああ、Rustが決めた安全性か
まあ>>274みたいなのには目をつぶるならそれでいいんじゃねw
はたから見たらオナニーにしか見えないけど

>>314
そうだよ、突き詰めたらレベルの違いでしかない
普通のひとは突き詰めること自体が馬鹿らしいって思うからこんなことで揉めたりしないけど

322 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:08:04 ID:TbjkUF4v.net]
>>318
うっかりunsafe関数を呼び出しのは不可能
Rustコンパイラが通さない

323 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:29:03 ID:r2wQepG1.net]
C++が敗北した理由が安全性を疎かにしたことは事実だけど
当時は安全性なんてそこまで重視されていなくて速ければよい時代だった
さらに安全性と速さを両立させる使い物になるプログラミング言語が出てくるとは想像できなかった
ここ数年でC++がようやく退場する時代となったたけでありそれ以前はC++の天下であった



324 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:47:42.85 ID:FBd+xess.net]
― フクオジ書 12:4-5

325 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:21:56.68 ID:6ug5/LDh.net]
>>319
そのレベルの違いが重要なわけじゃん

326 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:26:07.86 ID:rB16NsHU.net]
>>318
実際にプログラミングをしたことがないからアンチはそんな間違った発言をうっかりしてしまう

327 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:36:29.93 ID:TbjkUF4v.net]
>>319
天と地ほどの差がある
コンパイル時点でエラーとして弾いてくれてコンパイラが修整すべき点をアドバイスしてくれるRust
コンパイラは何も言わずに通してしまい実行運用中に問題が発覚するC/C++

328 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:37:18.68 ID:FBd+xess.net]
「前提条件が保証できていない」に触れていないのはうっかり読み飛ばしたのかな?それともわざとかな?

329 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:40:36.28 ID:N6dBVNoC.net]
マ板のコテハンが常駐するとどのスレも不毛地帯になるな

330 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:51:31.23 ID:8h5AdXRe.net]
>>323
レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ

>>325
> まあ>>274みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない

331 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:07:58.78 ID:dPnpzXnF.net]
アンチ連呼おじさんの主張は「おまえらはプログラミングしたことが無い」

332 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:17:01.66 ID:5J/+jd/X.net]
話は単純
RustはC++における問題のうちみんなが挙げてるような重要な部分を解決してしまった
それにプラスしてC++よりpRustの方がプログラミングしやすい点も非常に大きい

333 名前:デフォルトの名無しさん [2022/07/09(土) 22:18:10.11 ID:GNVCknQf.net]
コテハンとは一体



334 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:29:14.97 ID:FBd+xess.net]
>>330
そうだな
そしてRustが解決したという「問題」の範囲を大きく見せて誇大広告している人がいたのでぶっ叩かれたと
単純な話だ

335 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:30:12.39 ID:dcG9hbvO.net]
>>329
「おまえらはもうプログラミングしていないだろ」
じゃないのか
若い時はしていたんだろうが、おっさん・爺になって仕事ではもうプログラミングしていない
比較は必死にするが実際のRustプログラミング話が無いおじさん・爺のRustスレだからな

336 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:36:53.48 ID:qKBLdUt5.net]
年寄りはRustに構わないで欲しい
黙ってCでも書いてて

337 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:44:39.49 ID:3KUXTO+D.net]
>>332
Linus含めたLinux開発陣も同じ結論
C++はダメな言語なので不採用
Rustは良い言語なので採用

338 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:46:38.67 ID:dcG9hbvO.net]
>>334
歳をとってもうプログラミングしていないん(実質現役引退)だから
Cすら仕事で書いていないだろ

339 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:59:01.59 ID:hVKa6Imk.net]
> 287 名前:デフォルトの名無しさん [sage] 投稿日:2022/07/09(土) 11:50:07.31 ID:lwwTn4Ql [2/3]
> どちらにしてもRust使っても気楽にコーディングできるわけでもなく
> メモリ構造考えなければいけないんですね

読んでなるほどなと思った
よくわかんないけどとりあえず動けばいいという人と、
ちゃんと理解して自分の思う通りに動かしたい人の違いだなと

340 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:05:49.23 ID:dcG9hbvO.net]
>>335
俺,win使っているが
そのよい言語のRustをコンパイルするのに(C/C++する気ないのに)駄目な言語のmsvcを入れないと
とコンパイルできないてのがな

で、なんでmsvc必要なんだ?
ひょっとしたら、linuxでもgccとかを入れないと駄目なのか

341 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:15:33.27 ID:yHOdCoxc.net]
>>337
その人があまりにも知識不足の可能性が高い
Rustでも他の言語と同様に(C互換FFIを除いて)メモリ構造なんて公開も保証もしていない
ほとんどのプログラミング言語はメモリ構造なんて低いレベルで使うものではなくもっと抽象度の高い部分でその定義と保証がなされるもの
だからRustでも他の言語と同様にメモリ構造は考えなくて良いし考えてはいけない
メモリ構造は言語として保証していないし保証しないからこそ大胆なコンパイル最適化を行なっている

話を戻してその人はメモリ構造ではなくデータ構造と言いたかったのではないか?
データ構造は他の言語と同様にRustでも考えなければならない
それがプログラミングの中心だから

342 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:30:15.11 ID:hVKa6Imk.net]
>>338
そんなこと知らずに、そういうレスしているところにドン引きだな
自分で調べた?
調べたら、その結果をここで報告よろしく

343 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:45:37.10 ID:yHOdCoxc.net]
>>338
Rust批判派があまりにも知識不足で驚いた
ちなみにこちらはLinuxだがrustc(=Rustコンパイラ)だけあればコンパイルできる



344 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:12:02.83 ID:VXHYDjJa.net]
>>339
SwiftとかABI stabilityを実現してるやつは仕様としてメモリレイアウトを定義して公開してるやろ

345 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:13:44.27 ID:ZPTgd3k2.net]
>>341
["rust linker cc not found"] [検索]

346 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:16:59.60 ID: ]
[ここ壊れてます]

347 名前:CjJVLv20.net mailto: まあ>>287の書いてるメモリ構造という言葉はメモリレイアウトでもデータ構造でもないのは明らかだけどな []
[ここ壊れてます]

348 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:18:51.99 ID:z1Ut0loV.net]
隔離スレ復活させないとノイズだらけできつくなってきた

349 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:30:08.21 ID:tvXCky2C.net]
>>342
そのABIはコンパイル後のバイナリのフォーマットの話だぜ
今回の『気楽にコーディングできるわけでもなくメモリ構造考えなければいけないんですね』はプログラミングの際の話だから関係ない

プログラミングする上でメモリ構造は考えなくていい
例えばRustの型VecやStringなども各々のがどんなメモリ構造になるかは規定も公開もない
もちろんソースコードを読めば内部のデータ構造までは分かるがそれに依存してコードを書いてはいけないし依存できないよう抽象化されたインタフェースのみ規定公開されている

350 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:33:22.94 ID:tvXCky2C.net]
>>345
同感
アンチ活動は別のスレでやってほしい
ここ本スレでやるのはマナー違反だと思う

今後Rustへのアンチ活動は以下のスレへ書くこと
Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/

351 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:01:37.00 ID:/Pm6re6i.net]
複オジに絡んだ俺がバカだったわw

352 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:02:48.63 ID:qjKEOyYX.net]
>>343
なるほど、
>341
>ちなみにこちらはLinuxだがrustc(=Rustコンパイラ)だけあればコンパイルできる
は、比較的新しいrustを使えばgcc(リンカ)イラネってことか
rustでリンカ作った方がgccのリンカよりずっと良いものになるだろうからな

353 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:09:37 ID:ZPTgd3k2.net]
https://mevius.5ch.net/test/read.cgi/tech/1657382429/

隔離対象をアンチに限定しない汎用隔離スレ立てた
もう全部こっちでやってくれ



354 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:48:41.75 ID:LxkGLd0V.net]
>>350
おまえ低能だな
そんな内容と設定ではそのスレは過疎って終わることくらい予測できるだろ?

355 名前:デフォルトの名無しさん [2022/07/10(日) 04:45:49.56 ID:T5qatPVB.net]
荒らしてるのはLinux板の連中か。

356 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 08:32:10.98 ID:VKvLuEGz.net]
Cellを使っていて思ったんだが例えば

trait CellUpdateWith<T> {
fn update_with(&self, f: impl FnOnce(&mut T));
}

impl<T: Default> CellUpdateWith<T> for Cell<T> {
#[inline]
fn update_with(&self, f: impl FnOnce(&mut T)) {
let mut inner = self.take();
f(&mut inner);
self.set(inner);
}
}

このようにメソッドupdate_with()を用意しておけば
内部更新もわかりやすく記述できるな

let foo = Cell::new(vec![1, 2, 3]);
foo.update_with(|v| v.push(7));

身代わりにself.take()でdefault値を入れてCellから取り出し
self.set()でCellへ戻すという無駄な操作は最適化で消えるようだ
https://godbolt.org/z/19c4EbErG

357 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 12:00:25.54 ID:oYFJk9+G.net]
>>351
それをわざと狙ってんだろうなww
いかにもやりそうなこと

358 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 13:59:32.22 ID:blpABUiA.net]
>>354
この手の人は自分が排除されることを最も恐れてるんだよ
そうならないための策ならなりふり構わず何でもやる

自分が排除される側にいる自覚がなければそんなことやらない

359 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 19:54:18.59 ID:/ZDhY4rW.net]
>>308
糞言語で自意識過剰の公開オナニーをする信者、マジきもい

360 名前:デフォルトの名無しさん mailto:sage [2022/07/10(日) 23:37:14 ID:nSquZ6Rt.net]
>>308
プログラミング言語界に大革命をもたらした画期的な言語だな

361 名前:デフォルトの名無しさん [2022/07/11(月) 00:14:06.35 ID:triNevnR.net]
15年近くc/c++触ってなくて(ずっとjava触ってた)
rustの所有権とか何故こんな仕様になったのか経緯がわからなくて
最近のc11以降の仕様の?unique_ptrとかshared_ptrとかstd::moveとかstd::forward学んで
(元々boost にスマートポインタがあった記憶があるけど記憶が曖昧)
どうしてこう言う機能が出来たのか少しわかった

今のc++はconst 地獄だしとにかくコードが汚くなる
こりゃrust の方が良いわ

あと型名の付け方が好き。u32とかf32とか
昔cで書いてた頃typedefでわざわざ定義してたよ

362 名前:デフォルトの名無しさん [2022/07/11(月) 10:40:05.73 ID:1W23UOpt.net]
const 地獄 ← 判る
static_cast うぜー ← 判る
Rust 万歳 ← 判らん

363 名前:デフォルトの名無しさん mailto:sage [2022/07/13(水) 23:59:24.88 ID:qlTJEO+a.net]
>>353
もっと便利にできるぜ

use std::cell::Cell;

trait CellWithMethod<T> {
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R;
}

impl<T: Default> CellWithMethod<T> for Cell<T> {
#[inline]
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R {
let mut inner = self.take();
let result = f(&mut inner);
self.set(inner);
result
}
}

fn main() {
let foo = Cell::new(vec![1, 2, 3]);
foo.with(|v| v.push(7));
assert_eq!(4, foo.with(|v| v.len()));
assert_eq!(7, foo.with(|v| v[3]));
assert_eq!(vec![1, 2, 3, 7], foo.with(|v| v.clone()));
}



364 名前:デフォルトの名無しさん mailto:sage [2022/07/15(金) 21:39:01.85 ID:qV4GyRtM.net]
>>360
CellでVec使えるのか
何か間違って学習していた

https://qiita.com/wada314/items/24249418983312795c08
> 1. Cellの中身の型はCopyをimplしていなければならない

https://dev.classmethod.jp/articles/rust-smart-pointer/
> ・Cellの中の型はCopyトレイト実装が必須

https://qiita.com/usagi/items/fc329895cebd3466910e
> Cell は値の "移動" によって内部可変性を実装するため <T> は Copy 可能な "値" 向けのコンテナーで、
> i32 や Copy trait を実装した何かを扱うのに"適した"コンテナーです。

https://zenn.dev/mebiusbox/books/22d4c1ed9b0003/viewer/5df75e
> Cell<T> の大きな制約として, T は Copy トレイト境界があることです.

実際にはCellはCopyを要求していない
やってみたら>>360のコードが動いてCell<Vec<_>>が使えた

365 名前:デフォルトの名無しさん mailto:sage [2022/07/15(金) 22:48:49.30 ID:fFdw7/F8.net]
#[derive(Clone)]のコーナーケースに遭遇した
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=487e64c7c762fb0e015e1bc9b1267fbd

366 名前:デフォルトの名無しさん mailto:sage [2022/07/15(金) 22:50:32.95 ID:SBkpZpFk.net]
やっぱりrustcはバグが多いね

367 名前:デフォルトの名無しさん mailto:sage [2022/07/15(金) 23:12:58.85 ID:nxNpCMHU.net]
>>362
標準ライブラリのderiveは型パラメータに無条件にトレイト制約課すようになってるから
derivativeみたいな制約を自分で指定できるcrateを使うと良いよ
https://github.com/mcarton/rust-derivative

368 名前:デフォルトの名無しさん mailto:sage [2022/07/16(土) 00:28:56.56 ID:730D9OZt.net]
>>361
get()がCopyを要求するからってのもあるけど
古いThe BookにはCellはCopy専用・RefCellはCopy以外も使えるという説明があったので
それが日本語訳とかで残ってたんじゃないかな

369 名前:デフォルトの名無しさん mailto:sage [2022/07/16(土) 23:27:56 ID:MG4+BxCd.net]
>>360
!Syncで参照無しならデータ競合を起こさない、という点を使った用法だな
便利だから公式サポートすればいいのにな

370 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 00:26:56.65 ID:XqWqiApN.net]
StackOverflowで「好きな言語No.1」だそうだが、調査方法に問題が有り、
二位以下も聞いた事が無いような言語ばかり。

371 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 01:36:05.55 ID:bF1qPY0V.net]
>>367
お前の観測範囲が狭いだけ。

372 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 08:04:49 ID:XbfHqe9W.net]
CarbonとかいうRustとC++のあいのこみたいなのが出てきた

373 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 12:35:25 ID:FCfDFeLf.net]
Carbonは最強言語ぞ



374 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 12:39:05 ID:MUkQlR/e.net]
RustがCarbonに勝ててるところが見つからないな

375 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 12:45:18 ID:ThH+Z+BW.net]
Rust vs Carbonスレ立ててそっちでやれ

376 名前:デフォルトの名無しさん [2022/07/20(水) 13:30:14 ID:S6pSKHOi.net]
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい

377 名前:デフォルトの名無しさん [2022/07/20(水) 13:30:16 ID:S6pSKHOi.net]
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい

378 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 14:11:36.68 ID:xLuB33a9.net]
1.0が出てからにしてください

379 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 14:52:25.57 ID:IMMZUJf4.net]
CarbonとRustは名称の紛らわしさではどっこいどっこいだな

380 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 14:54:39.84 ID:igxVbWbR.net]
ほーん
https://github.com/carbon-language/carbon-lang

381 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 17:02:14.65 ID:xLuB33a9.net]
とりあえずcarbon自体のコードの8割がcarbonで書かれるエコシステムが確立してからだろう

382 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 19:50:56 ID:hGf+NvAH.net]
JSのTypeScript
C++のCarbonって感じかね

どうなるんだろうね
確かにC++を無くすのは勿体ないがまだ0.1か いつ1.0になるかなぁ 10年後くらいか
Rustよりも難しくはなくメモリ管理も楽になるのかな

383 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 20:00:37 ID:xdIX6xM1.net]
Rustはあらゆる面で安全と高速の両立する抽象化を実現した言語だから
現在のCarbonのドキュメントを見る限りRustの領分に入ってきていないでしょう
それよりもC++と書き方がかなり変わっていて互換性がなく別言語の様相でCarbonは中途半端な立ち位置に見える



384 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 20:01:46 ID:sReX4jGj.net]
Carbonは「Rustが難しすぎるから簡単にしたい」とは言ってなくて、C++と相互運用できる言語を目指してるだけっぽいからなぁ
結果的にRustより難しくなっても驚かないけど

385 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 20:33:50.16 ID:sReX4jGj.net]
そもそもCarbonの使い所ってC++のレガシーコードが大量にあるところだから
C++も当然マスターしてないといけなくて、学習量は明らかに増えてる気もする

386 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 20:52:36.69 ID:oyesoq1v.net]
ドラゴンボールのゲームでドドリアの色違いでカーボスと言うのがいたのを思い出した

どちらかと言うとザーボンの色違いがカーボスなら納得なんだけど…

387 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 21:27:24.19 ID:mJssGRdK.net]
Carbonって中途半端すぎね?
まともな言語設計者ならオブジェクト指向もう採用しないと思うんやけどなんか継承機能もあるみたいだし
なんでこういう中途半端のところもC++参考するんだよこういうところこそRust参考にしろよ

388 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 21:44:56.66 ID:qLBZujX3.net]
>>384
C++とシームレスに相互運用することが最優先課題だから、そこはC++と同じにしておかないとそもそも存在意義がなくなる

389 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 22:16:07.31 ID:gROTqHCf.net]
ま、2-3年後にどうなってるかだな
バックにGoogleいるらしいから開発終了なんてことはなさそうだが

390 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 22:21:24.71 ID:9oJrmZpV.net]
>>386
逆じゃね?企業だからこそ開発者の熱意とか関係なくコストに見合わないとなれば容赦なく切られるかと
Goみたいに社内で使うことが確定してしまえば安泰だけど

391 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 22:28:16.35 ID:3tivAU0I.net]
SDGsの流れ的にCarbonは使われなくなる運命

392 名前:デフォルトの名無しさん mailto:sage [2022/07/20(水) 22:43:27.67 ID:xLuB33a9.net]
なる、元素記号Cからの名称か

393 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 00:45:01.09 ID:g1dckGB4.net]
5年たったらまたオブジェクト指向が再燃してるかもしれない
と言うか業務では大規模開発にはオブジェクト指向が必須なんだな

モジュールでは全体が見通せない



394 名前:はちみつ餃子 mailto:sage [2022/07/21(木) 00:52:44.62 ID:/hG5LMVG.net]
話題が逸れるが >>384 が C++ の型システムをオブジェクト指向と呼んでるっぽいのが気になる。
オブジェクト指向はオブジェクト同士がメッセージを送りあう形でプログラムを構成する思想のことで、
それを言語機能としてどのように支援するのかには様々なバリエーションが有りうる。
型システムとは独立した概念だよ。
ふんわりした概念なので定義によるが Rust もオブジェクト指向 (をサポートする) 言語に分類されることはある。

それはそれとして、 C++ の型システムもベストとは言えないが最悪というわけでもない。
実際にかなり多くの場面で活用されている実績は認めないといけない。
要するに「この程度で十分」ではあるんだよ。
C++ の本当につらいところは C から引き継いだガバガバさや歴史的事情のワケわからんところであって、
型システムの根本的な改善はそれほど切実に必要だとは思わないな。

C++ が駄目だと否定するんじゃなくて C++ みたいなことを C++ より上手くやるという方向性はアリだろう。

395 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 00:54:52.22 ID:0vTmbBj3.net]
話題が逸れるが、...で読む気失せたわ

396 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 00:58:24.47 ID:MOkaWH3B.net]
>>391
前半は正しいが
後半のクラス継承システム程度で十分という点には賛同しかねる
今までの現実の多くのケースはクラス継承システムしか使えない環境だったから無理矢理にそれを使っているだけである

397 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 01:00:56.06 ID:g1dckGB4.net]
似たような機能のものを大量に書く場合どのように実装するのが楽かどのように管理するのが楽か

モジュールではないな

398 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 01:15:53.78 ID:MOkaWH3B.net]
>>394
その点ではRustもC++も同じオブジェクト指向なので何を主張したいのかわからない

Rustの基本はselfに見られるようにオブジェクト指向
違いはC++がクラス継承なのに対してRustはトレイト
ジェネリックから見るトレイト境界による型制約となり
逆の視点から見るとトレイト付加によるメソッド拡張となる

399 名前:デフォルトの名無しさん [2022/07/21(木) 03:25:39.61 ID:DiLbgRco.net]
いくらRustが有望だと言われていても、ポインターがないと使いづらい場面ってあるよな
ツリー構造とか、ポインターなしで大して実行速度も落とさず記述する技があるようだけど・・・・大掛かりなことをするのなら労力を割くのもいいけど、ちょっと使うだけには労力がかかりすぎる

400 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 04:26:36.96 ID:VmE9g8Ff.net]
ポインタあるじゃん

401 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 05:01:15.84 ID:hbmQrHo+.net]
>>396
Rustにも様々なポインタがあり
様々な仕様と様々な安全度合いで記述できる

402 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 08:09:40 ID:HHuzACnI.net]
>>385
Rustからわかるように、求められているのは膝を打ち抜く自由の無いc++であり、コーダーに使わせる言語。
unsafeはc++で実装すりゃいいので、継承とかは使うだけに限定するという手もある。

403 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 13:48:15.98 ID:xy799ZfA.net]
>>391
話し手がなにをオブジェクト指向の言語としているのかどうか判断する程度の読解力は持ち合わせてくれないかな?
RustはC++のように継承を導入することによってもたらされる問題を回避するためにclassじゃなくてtraitを基本的なプログラムの構成要素として採用することで既存のオブジェクト指向言語と一線を画すというプログラミング言語史に残る進歩を達成していた



404 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 15:49:13.07 ID:Q1uK5/Rv.net]
>>400
Haskellの型クラスの方が先だろ。

「プログラミング言語史に残る進歩」とかさすがに恥ずかしいレベル。

405 名前:デフォルトの名無しさん mailto:sage [2022/07/21(木) 16:58:11.12 ID:xy799ZfA.net]
>>401
RustのtraitをただのHaskellの型クラスの類似物としてしか認識できないのはお前が単に馬鹿だから
Rustのtraitは本来継承もmixinとも違ったC++のclassより洗練された新たなプログラムの構成要素だっていう側面が理解できていない馬鹿が多すぎる
ただRustではこのtraitという構成要素に実用上の面から今度は型クラスという機能も持たせているというだけで話の順序が違う
こんぐらいRust書いていたらtraitには単に型クラスだけの意義だけじゃないってわかると思うんやがお前にはそういった才能もないただのネット上で繰り返し喧伝されている宣伝にしか注目する脳がないいわばにわかの部類の奴だということがわかった






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<279KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef