22/07/09 20:07:34 kZfneOfi.net
>>313,315
ああ、Rustが決めた安全性か
まあ>>274みたいなのには目をつぶるならそれでいいんじゃねw
はたから見たらオナニーにしか見えないけど
>>314
そうだよ、突き詰めたらレベルの違いでしかない
普通のひとは突き詰めること自体が馬鹿らしいって思うからこんなことで揉めたりしないけど
322:デフォルトの名無しさん
22/07/09 20:08:04 TbjkUF4v.net
>>318
うっかりunsafe関数を呼び出しのは不可能
Rustコンパイラが通さない
323:デフォルトの名無しさん
22/07/09 20:29:03 r2wQepG1.net
C++が敗北した理由が安全性を疎かにしたことは事実だけど
当時は安全性なんてそこまで重視されていなくて速ければよい時代だった
さらに安全性と速さを両立させる使い物になるプログラミング言語が出てくるとは想像できなかった
ここ数年でC++がようやく退場する時代となったたけでありそれ以前はC++の天下であった
324:デフォルトの名無しさん
22/07/09 20:47:42.85 FBd+xess.net
― フクオジ書 12:4-5
325:デフォルトの名無しさん
22/07/09 21:21:56.68 6ug5/LDh.net
>>319
そのレベルの違いが重要なわけじゃん
326:デフォルトの名無しさん
22/07/09 21:26:07.86 rB16NsHU.net
>>318
実際にプログラミングをしたことがないからアンチはそんな間違った発言をうっかりしてしまう
327:デフォルトの名無しさん
22/07/09 21:36:29.93 TbjkUF4v.net
>>319
天と地ほどの差がある
コンパイル時点でエラーとして弾いてくれてコンパイラが修整すべき点をアドバイスしてくれるRust
コンパイラは何も言わずに通してしまい実行運用中に問題が発覚するC/C++
328:デフォルトの名無しさん
22/07/09 21:37:18.68 FBd+xess.net
「前提条件が保証できていない」に触れていないのはうっかり読み飛ばしたのかな？それともわざとかな？
329:デフォルトの名無しさん
22/07/09 21:40:36.28 N6dBVNoC.net
マ板のコテハンが常駐するとどのスレも不毛地帯になるな
330:デフォルトの名無しさん
22/07/09 21:51:31.23 8h5AdXRe.net
>>323
レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ
>>325
> まあ>>274みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない
331:デフォルトの名無しさん
22/07/09 22:07:58.78 dPnpzXnF.net
アンチ連呼おじさんの主張は「おまえらはプログラミングしたことが無い」
332:デフォルトの名無しさん
22/07/09 22:17:01.66 5J/+jd/X.net
話は単純
RustはC++における問題のうちみんなが挙げてるような重要な部分を解決してしまった
それにプラスしてC++よりpRustの方がプログラミングしやすい点も非常に大きい
333:デフォルトの名無しさん
22/07/09 22:18:10.11 GNVCknQf.net
コテハンとは一体
334:デフォルトの名無しさん
22/07/09 22:29:14.97 FBd+xess.net
>>330
そうだな
そしてRustが解決したという「問題」の範囲を大きく見せて誇大広告している人がいたのでぶっ叩かれたと
単純な話だ
335:デフォルトの名無しさん
22/07/09 22:30:12.39 dcG9hbvO.net
>>329
「おまえらはもうプログラミングしていないだろ」
じゃないのか
若い時はしていたんだろうが、おっさん・爺になって仕事ではもうプログラミングしていない
比較は必死にするが実際のRustプログラミング話が無いおじさん・爺のRustスレだからな
336:デフォルトの名無しさん
22/07/09 22:36:53.48 qKBLdUt5.net
年寄りはRustに構わないで欲しい
黙ってCでも書いてて
337:デフォルトの名無しさん
22/07/09 22:44:39.49 3KUXTO+D.net
>>332
Linus含めたLinux開発陣も同じ結論
C++はダメな言語なので不採用
Rustは良い言語なので採用
338:デフォルトの名無しさん
22/07/09 22:46:38.67 dcG9hbvO.net
>>334
歳をとってもうプログラミングしていないん(実質現役引退)だから
Cすら仕事で書いていないだろ
339:デフォルトの名無しさん
22/07/09 22:59:01.59 hVKa6Imk.net
> 287 名前：デフォルトの名無しさん [sage] 投稿日：2022/07/09(土) 11:50:07.31 ID:lwwTn4Ql [2/3]
> どちらにしてもRust使っても気楽にコーディングできるわけでもなく
> メモリ構造考えなければいけないんですね
読んでなるほどなと思った
よくわかんないけどとりあえず動けばいいという人と、
ちゃんと理解して自分の思う通りに動かしたい人の違いだなと
340:デフォルトの名無しさん
22/07/09 23:05:49.23 dcG9hbvO.net
>>335
俺,win使っているが
そのよい言語のRustをコンパイルするのに(C/C++する気ないのに)駄目な言語のmsvcを入れないと
とコンパイルできないてのがな
で、なんでmsvc必要なんだ？
ひょっとしたら、linuxでもgccとかを入れないと駄目なのか
341:デフォルトの名無しさん
22/07/09 23:15:33.27 yHOdCoxc.net
>>337
その人があまりにも知識不足の可能性が高い
Rustでも他の言語と同様に(C互換FFIを除いて)メモリ構造なんて公開も保証もしていない
ほとんどのプログラミング言語はメモリ構造なんて低いレベルで使うものではなくもっと抽象度の高い部分でその定義と保証がなされるもの
だからRustでも他の言語と同様にメモリ構造は考えなくて良いし考えてはいけない
メモリ構造は言語として保証していないし保証しないからこそ大胆なコンパイル最適化を行なっている
話を戻してその人はメモリ構造ではなくデータ構造と言いたかったのではないか？
データ構造は他の言語と同様にRustでも考えなければならない
それがプログラミングの中心だから
342:デフォルトの名無しさん
22/07/09 23:30:15.11 hVKa6Imk.net
>>338
そんなこと知らずに、そういうレスしているところにドン引きだな
自分で調べた？
調べたら、その結果をここで報告よろしく
343:デフォルトの名無しさん
22/07/09 23:45:37.10 yHOdCoxc.net
>>338
Rust批判派があまりにも知識不足で驚いた
ちなみにこちらはLinuxだがrustc(＝Rustコンパイラ)だけあればコンパイルできる
344:デフォルトの名無しさん
22/07/10 00:12:02.83 VXHYDjJa.net
>>339
SwiftとかABI stabilityを実現してるやつは仕様としてメモリレイアウトを定義して公開してるやろ
345:デフォルトの名無しさん
22/07/10 00:13:44.27 ZPTgd3k2.net
>>341
["rust linker cc not found"] [検索]
346:デフォルトの名無しさん
22/07/10 00:16:59.60
347:CjJVLv20.net
348:デフォルトの名無しさん
22/07/10 00:18:51.99 z1Ut0loV.net
隔離スレ復活させないとノイズだらけできつくなってきた
349:デフォルトの名無しさん
22/07/10 00:30:08.21 tvXCky2C.net
>>342
そのABIはコンパイル後のバイナリのフォーマットの話だぜ
今回の『気楽にコーディングできるわけでもなくメモリ構造考えなければいけないんですね』はプログラミングの際の話だから関係ない
プログラミングする上でメモリ構造は考えなくていい
例えばRustの型VecやStringなども各々のがどんなメモリ構造になるかは規定も公開もない
もちろんソースコードを読めば内部のデータ構造までは分かるがそれに依存してコードを書いてはいけないし依存できないよう抽象化されたインタフェースのみ規定公開されている
350:デフォルトの名無しさん
22/07/10 00:33:22.94 tvXCky2C.net
>>345
同感
アンチ活動は別のスレでやってほしい
ここ本スレでやるのはマナー違反だと思う
今後Rustへのアンチ活動は以下のスレへ書くこと
Rustアンチスレ
ｽﾚﾘﾝｸ(tech板)
351:デフォルトの名無しさん
22/07/10 01:01:37.00 /Pm6re6i.net
複オジに絡んだ俺がバカだったわw
352:デフォルトの名無しさん
22/07/10 01:02:48.63 qjKEOyYX.net
>>343
なるほど、
>341
>ちなみにこちらはLinuxだがrustc(＝Rustコンパイラ)だけあればコンパイルできる
は、比較的新しいrustを使えばgcc(リンカ)イラネってことか
rustでリンカ作った方がgccのリンカよりずっと良いものになるだろうからな
353:デフォルトの名無しさん
22/07/10 01:09:37 ZPTgd3k2.net
ｽﾚﾘﾝｸ(tech板)
隔離対象をアンチに限定しない汎用隔離スレ立てた
もう全部こっちでやってくれ
354:デフォルトの名無しさん
22/07/10 01:48:41.75 LxkGLd0V.net
>>350
おまえ低能だな
そんな内容と設定ではそのスレは過疎って終わることくらい予測できるだろ？
355:デフォルトの名無しさん
22/07/10 04:45:49.56 T5qatPVB.net
荒らしてるのはLinux板の連中か。
356:デフォルトの名無しさん
22/07/10 08:32:10.98 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へ戻すという無駄な操作は最適化で消えるようだ
URLﾘﾝｸ(godbolt.org)
357:デフォルトの名無しさん
22/07/10 12:00:25.54 oYFJk9+G.net
>>351
それをわざと狙ってんだろうなww
いかにもやりそうなこと
358:デフォルトの名無しさん
22/07/10 13:59:32.22 blpABUiA.net
>>354
この手の人は自分が排除されることを最も恐れてるんだよ
そうならないための策ならなりふり構わず何でもやる
自分が排除される側にいる自覚がなければそんなことやらない
359:デフォルトの名無しさん
22/07/10 19:54:18.59 /ZDhY4rW.net
>>308
糞言語で自意識過剰の公開オナニーをする信者、マジきもい
360:デフォルトの名無しさん
22/07/10 23:37:14 nSquZ6Rt.net
>>308
プログラミング言語界に大革命をもたらした画期的な言語だな
361:デフォルトの名無しさん
22/07/11 00:14:06.35 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:デフォルトの名無しさん
22/07/11 10:40:05.73 1W23UOpt.net
const 地獄 ← 判る
static_cast うぜー ← 判る
Rust 万歳 ← 判らん
363:デフォルトの名無しさん
22/07/13 23:59:24.88 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:デフォルトの名無しさん
22/07/15 21:39:01.85 qV4GyRtM.net
>>360
CellでVec使えるのか
何か間違って学習していた
URLﾘﾝｸ(qiita.com)
＞ 1. Cellの中身の型はCopyをimplしていなければならない
URLﾘﾝｸ(dev.classmethod.jp)
＞ ・Cellの中の型はCopyトレイト実装が必須
URLﾘﾝｸ(qiita.com)
＞ Cell は値の "移動" によって内部可変性を実装するため <T> は Copy 可能な "値" 向けのコンテナーで、
＞ i32 や Copy trait を実装した何かを扱うのに"適した"コンテナーです。
URLﾘﾝｸ(zenn.dev)
＞ Cell<T> の大きな制約として， T は Copy トレイト境界があることです．
実際にはCellはCopyを要求していない
やってみたら>>360のコードが動いてCell<Vec<_>>が使えた
365:デフォルトの名無しさん
22/07/15 22:48:49.30 fFdw7/F8.net
#[derive(Clone)]のコーナーケースに遭遇した
URLﾘﾝｸ(play.rust-lang.org)
366:デフォルトの名無しさん
22/07/15 22:50:32.95 SBkpZpFk.net
やっぱりrustcはバグが多いね
367:デフォルトの名無しさん
22/07/15 23:12:58.85 nxNpCMHU.net
>>362
標準ライブラリのderiveは型パラメータに無条件にトレイト制約課すようになってるから
derivativeみたいな制約を自分で指定できるcrateを使うと良いよ
URLﾘﾝｸ(github.com)
368:デフォルトの名無しさん
22/07/16 00:28:56.56 730D9OZt.net
>>361
get()がCopyを要求するからってのもあるけど
古いThe BookにはCellはCopy専用・RefCellはCopy以外も使えるという説明があったので
それが日本語訳とかで残ってたんじゃないかな
369:デフォルトの名無しさん
22/07/16 23:27:56 MG4+BxCd.net
>>360
!Syncで参照無しならデータ競合を起こさない、という点を使った用法だな
便利だから公式サポートすればいいのにな
370:デフォルトの名無しさん
22/07/20 00:26:56.65 XqWqiApN.net
StackOverflowで「好きな言語No.1」だそうだが、調査方法に問題が有り、
二位以下も聞いた事が無いような言語ばかり。
371:デフォルトの名無しさん
22/07/20 01:36:05.55 bF1qPY0V.net
>>367
お前の観測範囲が狭いだけ。
372:デフォルトの名無しさん
22/07/20 08:04:49 XbfHqe9W.net
CarbonとかいうRustとC++のあいのこみたいなのが出てきた
373:デフォルトの名無しさん
22/07/20 12:35:25 FCfDFeLf.net
Carbonは最強言語ぞ
374:デフォルトの名無しさん
22/07/20 12:39:05 MUkQlR/e.net
RustがCarbonに勝ててるところが見つからないな
375:デフォルトの名無しさん
22/07/20 12:45:18 ThH+Z+BW.net
Rust vs Carbonスレ立ててそっちでやれ
376:デフォルトの名無しさん
22/07/20 13:30:14 S6pSKHOi.net
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい
377:デフォルトの名無しさん
22/07/20 13:30:16 S6pSKHOi.net
このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい
378:デフォルトの名無しさん
22/07/20 14:11:36.68 xLuB33a9.net
1.0が出てからにしてください
379:デフォルトの名無しさん
22/07/20 14:52:25.57 IMMZUJf4.net
CarbonとRustは名称の紛らわしさではどっこいどっこいだな
380:デフォルトの名無しさん
22/07/20 14:54:39.84 igxVbWbR.net
ほーん
URLﾘﾝｸ(github.com)
381:デフォルトの名無しさん
22/07/20 17:02:14.65 xLuB33a9.net
とりあえずcarbon自体のコードの8割がcarbonで書かれるエコシステムが確立してからだろう
382:デフォルトの名無しさん
22/07/20 19:50:56 hGf+NvAH.net
JSのTypeScript
C++のCarbonって感じかね
どうなるんだろうね
確かにC++を無くすのは勿体ないがまだ0.1か いつ1.0になるかなぁ 10年後くらいか
Rustよりも難しくはなくメモリ管理も楽になるのかな
383:デフォルトの名無しさん
22/07/20 20:00:37 xdIX6xM1.net
Rustはあらゆる面で安全と高速の両立する抽象化を実現した言語だから
現在のCarbonのドキュメントを見る限りRustの領分に入ってきていないでしょう
それよりもC++と書き方がかなり変わっていて互換性がなく別言語の様相でCarbonは中途半端な立ち位置に見える
384:デフォルトの名無しさん
22/07/20 20:01:46 sReX4jGj.net
Carbonは「Rustが難しすぎるから簡単にしたい」とは言ってなくて、C++と相互運用できる言語を目指してるだけっぽいからなぁ
結果的にRustより難しくなっても驚かないけど
385:デフォルトの名無しさん
22/07/20 20:33:50.16 sReX4jGj.net
そもそもCarbonの使い所ってC++のレガシーコードが大量にあるところだから
C++も当然マスターしてないといけなくて、学習量は明らかに増えてる気もする
386:デフォルトの名無しさん
22/07/20 20:52:36.69 oyesoq1v.net
ドラゴンボールのゲームでドドリアの色違いでカーボスと言うのがいたのを思い出した
どちらかと言うとザーボンの色違いがカーボスなら納得なんだけど…
387:デフォルトの名無しさん
22/07/20 21:27:24.19 mJssGRdK.net
Carbonって中途半端すぎね？
まともな言語設計者ならオブジェクト指向もう採用しないと思うんやけどなんか継承機能もあるみたいだし
なんでこういう中途半端のところもC++参考するんだよこういうところこそRust参考にしろよ
388:デフォルトの名無しさん
22/07/20 21:44:56.66 qLBZujX3.net
>>384
C++とシームレスに相互運用することが最優先課題だから、そこはC++と同じにしておかないとそもそも存在意義がなくなる
389:デフォルトの名無しさん
22/07/20 22:16:07.31 gROTqHCf.net
ま、2-3年後にどうなってるかだな
バックにGoogleいるらしいから開発終了なんてことはなさそうだが
390:デフォルトの名無しさん
22/07/20 22:21:24.71 9oJrmZpV.net
>>386
逆じゃね？企業だからこそ開発者の熱意とか関係なくコストに見合わないとなれば容赦なく切られるかと
Goみたいに社内で使うことが確定してしまえば安泰だけど
391:デフォルトの名無しさん
22/07/20 22:28:16.35 3tivAU0I.net
SDGsの流れ的にCarbonは使われなくなる運命
392:デフォルトの名無しさん
22/07/20 22:43:27.67 xLuB33a9.net
なる、元素記号Cからの名称か
393:デフォルトの名無しさん
22/07/21 00:45:01.09 g1dckGB4.net
5年たったらまたオブジェクト指向が再燃してるかもしれない
と言うか業務では大規模開発にはオブジェクト指向が必須なんだな
モジュールでは全体が見通せない
394:はちみつ餃子
22/07/21 00:52:44.62 /hG5LMVG.net
話題が逸れるが >>384 が C++ の型システムをオブジェクト指向と呼んでるっぽいのが気になる。
オブジェクト指向はオブジェクト同士がメッセージを送りあう形でプログラムを構成する思想のことで、
それを言語機能としてどのように支援するのかには様々なバリエーションが有りうる。
型システムとは独立した概念だよ。
ふんわりした概念なので定義によるが Rust もオブジェクト指向 (をサポートする) 言語に分類されることはある。
それはそれとして、 C++ の型システムもベストとは言えないが最悪というわけでもない。
実際にかなり多くの場面で活用されている実績は認めないといけない。
要するに「この程度で十分」ではあるんだよ。
C++ の本当につらいところは C から引き継いだガバガバさや歴史的事情のワケわからんところであって、
型システムの根本的な改善はそれほど切実に必要だとは思わないな。
C++ が駄目だと否定するんじゃなくて C++ みたいなことを C++ より上手くやるという方向性はアリだろう。
395:デフォルトの名無しさん
22/07/21 00:54:52.22 0vTmbBj3.net
話題が逸れるが、...で読む気失せたわ
396:デフォルトの名無しさん
22/07/21 00:58:24.47 MOkaWH3B.net
>>391
前半は正しいが
後半のクラス継承システム程度で十分という点には賛同しかねる
今までの現実の多くのケースはクラス継承システムしか使えない環境だったから無理矢理にそれを使っているだけである
397:デフォルトの名無しさん
22/07/21 01:00:56.06 g1dckGB4.net
似たような機能のものを大量に書く場合どのように実装するのが楽かどのように管理するのが楽か
モジュールではないな
398:デフォルトの名無しさん
22/07/21 01:15:53.78 MOkaWH3B.net
>>394
その点ではRustもC++も同じオブジェクト指向なので何を主張したいのかわからない
Rustの基本はselfに見られるようにオブジェクト指向
違いはC++がクラス継承なのに対してRustはトレイト
ジェネリックから見るトレイト境界による型制約となり
逆の視点から見るとトレイト付加によるメソッド拡張となる
399:デフォルトの名無しさん
22/07/21 03:25:39.61 DiLbgRco.net
いくらRustが有望だと言われていても、ポインターがないと使いづらい場面ってあるよな
ツリー構造とか、ポインターなしで大して実行速度も落とさず記述する技があるようだけど・・・・大掛かりなことをするのなら労力を割くのもいいけど、ちょっと使うだけには労力がかかりすぎる
400:デフォルトの名無しさん
22/07/21 04:26:36.96 VmE9g8Ff.net
ポインタあるじゃん
401:デフォルトの名無しさん
22/07/21 05:01:15.84 hbmQrHo+.net
>>396
Rustにも様々なポインタがあり
様々な仕様と様々な安全度合いで記述できる
402:デフォルトの名無しさん
22/07/21 08:09:40 HHuzACnI.net
>>385
Rustからわかるように、求められているのは膝を打ち抜く自由の無いc++であり、コーダーに使わせる言語。
unsafeはc++で実装すりゃいいので、継承とかは使うだけに限定するという手もある。
403:デフォルトの名無しさん
22/07/21 13:48:15.98 xy799ZfA.net
>>391
話し手がなにをオブジェクト指向の言語としているのかどうか判断する程度の読解力は持ち合わせてくれないかな？
RustはC++のように継承を導入することによってもたらされる問題を回避するためにclassじゃなくてtraitを基本的なプログラムの構成要素として採用することで既存のオブジェクト指向言語と一線を画すというプログラミング言語史に残る進歩を達成していた
404:デフォルトの名無しさん
22/07/21 15:49:13.07 Q1uK5/Rv.net
>>400
Haskellの型クラスの方が先だろ。
「プログラミング言語史に残る進歩」とかさすがに恥ずかしいレベル。
405:デフォルトの名無しさん
22/07/21 16:58:11.12 xy799ZfA.net
>>401
RustのtraitをただのHaskellの型クラスの類似物としてしか認識できないのはお前が単に馬鹿だから
Rustのtraitは本来継承もmixinとも違ったC++のclassより洗練された新たなプログラムの構成要素だっていう側面が理解できていない馬鹿が多すぎる
ただRustではこのtraitという構成要素に実用上の面から今度は型クラスという機能も持たせているというだけで話の順序が違う
こんぐらいRust書いていたらtraitには単に型クラスだけの意義だけじゃないってわかると思うんやがお前にはそういった才能もないただのネット上で繰り返し喧伝されている宣伝にしか注目する脳がないいわばにわかの部類の奴だということがわかった
406:デフォルトの名無しさん
22/07/21 17:50:57.39 eNA5340i.net
traitの画期的な部分はc++のabstract classで実現できないの？
407:デフォルトの名無しさん
22/07/21 17:54:16 F7Gtvv1S.net
>>402
何が言いたいのかよくわからないけど型クラスになくてtraitにあるものって何？
associate typeはrustの発明だと思うけど、そういうこと言いたいわけでもなさそうだし
408:デフォルトの名無しさん
22/07/21 18:07:36 ySHdWcK4.net
自分が崇拝する神だけが唯一正しいと妄信して
他人の考え方を徹底的に糾弾排斥するのがカルト
カルト化した人間とまともな議論ができると思うな
409:デフォルトの名無しさん
22/07/21 18:19:30.67 xy799ZfA.net
>>404
公式サイトにすら出典付きで載ってあることなんだけどなんでここで聞くの？
繰り返しになるがtraitの型クラス以外の側面に気づけないのはお前が単に馬鹿なだけ
410:デフォルトの名無しさん
22/07/21 19:01:28.92 HGs+QJMA.net
>>406
そういうのを誘導しないからお前はダメなんだよ。
prev.rust-lang.org/ja-JP/faq.html#how-do-rust-traits-compare-to-haskell-typeclasses
How do Rust traits compare to Haskell typeclasses?
Rust traits are similar to Haskell typeclasses, but are currently not as powerful, as Rust cannot express higher-kinded types. Rust’s associated types are equivalent to Haskell type families.
411:デフォルトの名無しさん
22/07/21 19:15:30.44 F7Gtvv1S.net
>>407
traitの方が表現力低いって言ってるじゃねーか
412:デフォルトの名無しさん
22/07/21 20:10:50.68 SY914jbi.net
レスバスレ使ってくれませんか？
413:デフォルトの名無しさん
22/07/21 20:48:28.30 rGFlKcYB.net
>>407
それURLがprevで始まっているように古い情報ページ
わざわざそれを出すのは何か意図がある？
414:デフォルトの名無しさん
22/07/21 21:43:04.55 vaotA28G.net
>>408
正しい情報を啓蒙するのは面倒だということを知らしめる意図じゃない？
415:デフォルトの名無しさん
22/07/21 21:59:42 vJeGD7jb.net
>>404
Rustのトレイトは
トレイト境界を実装で指定できるだけでなく
トレイト境界を型宣言でも指定できるなど
様々な点で型クラスと異なるよね？
416:デフォルトの名無しさん
22/07/21 22:56:58.50 crFoTo11.net
幽霊型🥺
417:デフォルトの名無しさん
22/07/21 23:06:53.32 XUR5FOR
418:i.net
419:デフォルトの名無しさん
22/07/21 23:56:47.54 vrEITS91.net
>>412
トレイトに関しては当然Haskellの型クラス由来の部分が多いけど互いに片方にしかないものもあり異なる側面があるわけか
420:デフォルトの名無しさん
22/07/22 00:02:56.00 Dec8FkF+.net
>>412
よくわかんないからコードで書いて
421:デフォルトの名無しさん
22/07/22 00:07:23.73 3PGiuxDq.net
今のところ型システムは完全下位互換だよ
422:デフォルトの名無しさん
22/07/22 00:22:12.08 hXBfLf2I.net
>>416
普通のこれだろ
struct Foo<T: Trait1 + Trait2> {
inner: T,
}
423:デフォルトの名無しさん
22/07/22 00:32:54.07 /9LzCqck.net
>>418
これが>>402が言う型クラス以上の意義があるものなの？
424:デフォルトの名無しさん
22/07/22 00:45:08.67 hXBfLf2I.net
402の話は402に聞け
少なくとも>>418は型定義の時点で制約できるから意義がある
425:デフォルトの名無しさん
22/07/22 00:46:45.91 Dec8FkF+.net
>>418
-XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language.
426:デフォルトの名無しさん
22/07/22 01:09:40.70 hXBfLf2I.net
>>421
いきなり何かわからない話を向けられても困る
解説せよ
427:デフォルトの名無しさん
22/07/22 01:43:49.12 kvE65+oR.net
トレイトのどの辺が「洗練された新たなプログラム構成要素」と感じるのか全然分からん
俺の中ではインターフェースと一緒の扱い
Rustが画期的だったのはOwnership/Referenceルール + Borrow Checker
この点に異論ある人はいないよね？
428:デフォルトの名無しさん
22/07/22 02:15:42.10 g+hZIhYV.net
>>423
一般的なインタフェースなんて
Trait Boundsもimpl Traitもdyn Traitもないゴミ
>>419
その点でも差異があるだけでなく
Rustのトレイトは基本概念こそHaskellの型クラスと同じだがそれ以外は各々の言語に適応してかなり異なる
429:はちみつ餃子
22/07/22 03:26:24.88 fX2QhDiX.net
>>424
そりゃ言語に合わせて変えるところがあるのは当たり前だが、
基本概念が同じだというなら類似物ではあるだろう。
カテゴリ分けしたらおおよそ同じところに分類するよ……。
430:デフォルトの名無しさん
22/07/22 03:47:26.49 u1/oKmBi.net
>>425
それは違うのではないかな
例えばHaskellはRustのtraitでのdyn(動的解決)とimpl(静的解決)といった重要な基本概念を欠いているよ
431:デフォルトの名無しさん
22/07/22 05:52:26 FhKnOINS.net
C++の欠点は、何でもできること。
その欠点をなくして、わかりやすくしたのがRust。
バイナリ界のJavaと言い換えても良い。
ほとんどのプログラマはC++よりRustを使うほうが良い。
432:デフォルトの名無しさん
22/07/22 08:04:03.49 FDKNW5k7.net
>>410
だから最新情報に誘導しろよ。
無能か？
433:デフォルトの名無しさん
22/07/22 09:31:13.18 8cs6kRrX.net
>>427
これからRustはIT土方専用言語になっていくんだろうなあ
434:デフォルトの名無しさん
22/07/22 09:55:09.86 aK9LU/qI.net
>>424
>一般的なインタフェースなんて
>Trait Boundsもimpl Traitもdyn Traitもないゴミ
言語化できてないから本質を理解できていように見える
Trait Boundはジェネリック型の型制約で一般的なインターフェイスも型制約として機能する
一般的なインターフェイスは動的ディスパッチなのでdyn Trait相当
impl Traitがmonomorphizationのことを言ってるならそれはTraitの機能じゃなくGenericsの機能
C++で20年前から使えるよね？
C++以外でもSwiftみたいに一部の言語はGenericsのspecialization機能があるけど一般的にはオーバーロード使ってstatic dispatchにすることが可能
435:デフォルトの名無しさん
22/07/22 10:57:57.42 GQh1j6M0.net
>>418
javaのgenericsでextends使うとできるやつかな？
436:デフォルトの名無しさん
22/07/22 11:30:46.07 emgmw9dd.net
Java厨は出て来ないで下さいうざいだけです
437:デフォルトの名無しさん
22/07/22 11:34:22.85 LVIZaCij.net
>>429
msとかgoogleとかの狙いはそうだろ。
土方がコーティングしてもバグが入り込まない。
その代わり難易度が上がっているからコーダーの単価上がりそうだけど、msとかgoogleはそんなの気にしないだろうし。
438:デフォルトの名無しさん
22/07/22 13:14:37.08 GQh1j6M0.net
>>432
rustの画期的な部分なんだろ？言い返せないのかよダサいなお前
本当に革新的なのは>>423あたりなんじゃないの
439:デフォルトの名無しさん
22/07/22 14:36:57 ZDp8+ZKO.net
kumagiとか見てると、google社員でもc++触らせたらあかん奴ってのが結構いるのがわかる。
440:デフォルトの名無しさん
22/07/22 14:59:23.46 hnGDX2CP.net
>>431
Javaのジェネリクスは変な制限が多く
インタフェース指定していって問題があってもコンパイルエラーとならず実行時エラーとなるものがあるなどJavaは論外
他にも問題多すぎてRustに何ひとつ勝てないから新システムを機会にJava→Rustとなったものも出てきている
441:デフォルトの名無しさん
22/07/22 15:43:33.15 yLavWCdC.net
>>434
Ownership/reference自体はc++にもあるからあんまり革新的とは思えないな。
コールスタック&RAIIを中心にしてメモリ管理ルールを再構築して、厄介なヒープメモリの管理をできるだけ避けて高速化しているのが特徴だと思う。
革新的なのはそのルールを徹底していることくらいかと。
442:デフォルトの名無しさん
22/07/22 17:12:05.71 efNbKFVE.net
安全性とゼロコスト抽象化の制約下で開発効率を高める仕組みを導入していることがRustの特徴だよね
言語仕様や処理系実装上での苦労や工夫はいろいろあるが、それらによって実現される機能自体が目新しいものというわけではない
443:デフォルトの名無しさん
22/07/22 17:40:06.82 whw2xWQR.net
Rustが発明したのかどうかはしらんけど、Borrow Checkerは他の普通の言語にはない仕組みで、目新しく感じるけどなあ
Borrow Checkerが効かないようなコードを書くんだったらRustを使う意味が感じられないぐらいにはね
444:デフォルトの名無しさん
22/07/22 17:44:11.14 t0V8WW9J.net
>>436
インターフェースの問題とJavaの問題を混同するのが論外
445:デフォルトの名無しさん
22/07/22 18:05:15.33 K++ItniC.net
Borrow checker自体は2000年頃のCycloneの時点でほぼできていたっぽい
Rust独自なのは多分shared xor mutableとmove by defaultじゃないかな
446:デフォルトの名無しさん
22/07/22 19:11:51.06 yoEBUVfk.net
>>437
そう。
C++には何でもある。
それが欠点。
必要なものに厳選して誰でも使えるようにしたのがRust。
C++のアイデアとJavaの実用性、二つの遺伝子を組み合わせたのがRust。
ちなみにお母さんがJava、お父さんはHaskellという建前だけど、本当のお父さんはC++。
Haskellさんは、自分の子供だと信じてる。
447:デフォルトの名無しさん
22/07/22 21:06:16.19 UonvlDt9.net
キモいな
Javaは遺伝子引き継いでないから代理出産に違いない
448:デフォルトの名無しさん
22/07/22 21:16:25.55 i57cd+Nw.net
>>442
javaの立ち位置なんて、無関係な癖に建物の影からチラチラこちらをうかがって変な妄想してる気味悪い知らない奴だよ。
449:デフォルトの名無しさん
22/07/22 21:29:36.07 zWgtMzpY.net
>>435
あの人はプログラミング能力だけの人じゃなくてDBとか分散システムのアルゴリズムが主戦場の人でしょ。
プログラム読み書き堪能に越したことはないけど、そこだけで人を評価するのは視野が狭いよ。
450:デフォルトの名無しさん
22/07/23 04:53:27 Yc68YnRu.net
>>444
意味不明なこと言わないで
451:デフォルトの名無しさん
22/07/23 05:40:41.12 xoLMiefm.net
>>435
C++だけでなくRustも理解できてない？
＠
純粋に疑問なんですけどRust使ってる中で「値オブジェクトマジ助かる！」って事あるんですか。
適当に参照で渡したデータが意図せず書き換えられて伝搬して困る典型ケースはコンパイラが潰してくれる認識なんですが。
452:デフォルトの名無しさん
22/07/23 08:37:27.70 0xKT+wLu.net
>>447
それはRustじゃなく値オブジェクトを理解できてない
院卒の新人だったりしない？
453:デフォルトの名無しさん
22/07/23 09:37:03.85 bR39w9BX.net
Googleは金の亡者
454:デフォルトの名無しさん
22/07/23 11:55:37.32 8Uydd8B4.net
>>448
低レイヤーのプログラマーは値オブジェクトとか知らないほうが普通
アーキテクチャ設計といったらCPUやメモリアーキテクチャの事だと思ってたりするw
455:デフォルトの名無しさん
22/07/23 13:10:56 RBxCW/xN.net
OwnershipルールとReferenceルールがWhat
Borrow CheckerはHowに相当
Howにももちろん価値はあるが
それと同じくらいWhatをシンプルに絞り込んだものにしたことにも価値がある
後知恵で見れば当然に見えるようなシンプルなルールを作るのはものすごく難易度が高い
456:デフォルトの名無しさん
22/07/23 16:15:20.09 tefRxlpq.net
>>451
わかる
Rustのメモリ周りや、UnixとかRISC-Vみたいに、システムを動作させるに必要な機能の数をできるだけ小さくするのって難しいけど、完成品を見ると当たり前じゃんみたいな印象を受ける
457:デフォルトの名無しさん
22/07/23 18:34:20.81 u2Y0Vizw.net
>>445
残念ながらスパナーとか普通に実装してるgoogleにおいてはあんまり価値のある能力ではないよ。
458:デフォルトの名無しさん
22/07/23 19:04:05.94 ehQy/P8s.net
ISO、C++標準化委員のグレイドン・ホアレ氏はC++0xの標準化過程で、後方互換性を削ぎ落せば理解しやすくなることに気が付く。
そして私的プロジェクトとして実装し始めた。
2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
459:デフォルトの名無しさん
22/07/23 19:21:14 NE7ljYY1.net
C++標準化委員の人でもあったんか
それにしてもRustっていいネーミングだよな
なんかしっくりくる
460:デフォルトの名無しさん
22/07/23 19:57:02.71 uphZtYPd.net
正直なところ一般的な単語とか1文字とかの言語名はやめて欲しいと思わなくもない。
461:デフォルトの名無しさん
22/07/23 20:43:26.21 PgM2fTTz.net
>>453
逆じゃね。自分たちで作ってるからこそアルゴリズム方面の知識の意味があるのでは
462:デフォルトの名無しさん
22/07/23 21:05:19 IDFlcwhf.net
>>454
Hoareはホーアかホアだと思うんだが
ホアレはどこの国の読み方？
463:デフォルトの名無しさん
22/07/23 21:18:57.29 91gi6HhK.net
日本じゃね？
464:デフォルトの名無しさん
22/07/23 21:28:49.17 zqWGCIwO.net
>>456
昔は大変だったけど今時はグーグルさんもだいぶ賢くなって来たから〇 言語や〇 langでいける
465:デフォルトの名無しさん
22/07/23 22:37:12.56 SkYdpzS6.net
>>454
>2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
2006年の間違いじゃない？
ちなみに>>451に書いてるReferenceルールやBorrow CheckerはGraydon時代にできたものじゃないよ
466:デフォルトの名無しさん
22/07/24 09:21:08.56 lG8qI40d.net
>>461
じゃあいつできたの？
467:デフォルトの名無しさん
22/07/24 09:29:10.51 TkuAh24s.net
RustじゃなくてHoareの方が検索性は高かったと思う
言語に自分の名前つけたっていいじゃん、最初だけイタい人扱い受けるだけだし
468:デフォルトの名無しさん
22/07/24 12:23:10 A2ivE9+A.net
でも本当にHoareなんて名前付けたら絶対Tony Hoareのほうだと思われるやろな
469:デフォルトの名無しさん
22/07/24 12:53:11.52 lG8qI40d.net
>>464
ほんこれ
あんな有名人とfamily nameが一緒とかすごい偶然だよな
470:デフォルトの名無しさん
22/07/24 13:06:01.37 hnBeY/7d.net
木村拓哉と苗字が同じ木村君みたいな。
471:デフォルトの名無しさん
22/07/24 13:06:50.57 iVL8opWs.net
すごい偶然ですねえ・・・ えっ
472:デフォルトの名無しさん
22/07/24 13:35:38.58 q7gbemmZ.net
Rust-Oneとか見たいな感じの名前が良かったんじゃないかとｗ
473:デフォルトの名無しさん
22/07/24 13:48:30.68 q7gbemmZ.net
新言語を作る際にはありふれた言葉を使うなってコンセンサスがあれば…
C java go Perl Ruby Rust ...
474:デフォルトの名無しさん
22/07/24 13:53:14.16 iVL8opWs.net
せめて後ろに +lang した名前を正式名称にしてくれりゃなあ
Javalang、Clang、Golang、Rustlang...
clangは名前衝突するから今更ムリだけど
475:デフォルトの名無しさん
22/07/24 14:08:13.51 6QULAMze.net
RustとかGoはもう今じゃメジャーだから大分マシだけど
上の方に出てるCarbon？だのみたいな新しい知名度低いようなのにとっちゃ検索されづらいのって結構大きいデメリットじゃないのかね
476:デフォルトの名無しさん
22/07/24 14:11:15.69 q7gbemmZ.net
Car-bonおすすめ
477:デフォルトの名無しさん
22/07/24 17:26:22 AIK5SBoS.net
Rustでは検索にこまったことないけどなぁ
CやGoではそれなりに困ったことある
特にC
478:デフォルトの名無しさん
22/07/24 17:35:43.91 nz/s3YoW.net
>>469
perlは違うくね
入れるならpython
479:デフォルトの名無しさん
22/07/24 18:34:31.10 kd/zxSl1.net
Pythonはまさかちょっとしたイタズラ心で命名した言語が
30年経ってこれほどまでに普及するとは思ってないだろうなぁ。
480:デフォルトの名無しさん
22/07/24 20:35:51.30 T5Io3liY.net
ゲームのRustが人気になっていても問題なく検索できてるなぁ
481:はちみつ餃子 ◆8X2XSCHEME
22/07/25 09:42:55 OE8E5RfU.net
パーソナライズ (その人のアクセス傾向を検索結果に反映する) がそこそこ機能してるっぽいという話はあるなぁ。
個人情報保護の法律との兼ね合いが難しいみたいだが。
482:デフォルトの名無しさん
22/07/25 11:46:03.92 fotNOYOj.net
RustはCやC++の後継にはならないな。
483:デフォルトの名無しさん
22/07/25 12:46:43.99 /yXgS7y/.net
CはC言語で検索してもC++が出てきやがるからな
迷惑な言語だわC++
484:デフォルトの名無しさん
22/07/25 14:10:01.30 fotNOYOj.net
全然、思想や人柄が違う人を後継者に立てようとしても無理が有るな。
485:デフォルトの名無しさん
22/07/25 19:30:13.93 qs4kuyp6.net
>>456
その例でいってとにかくクソダメなのが Go
言語仕様も前時代的なウンコみたいな仕様だが何がだめといって名前がクソすぎ
ついでにいうとマスコットが致命的にキモすぎる
486:デフォルトの名無しさん
22/07/25 20:08:08.67 uz33IoOs.net
goはgolangって呼び方が一般化してるから問題なくね？
親会社もalphabetだし、仮に一般名詞でも検索してやんよっていう自信の現れなのかも。
あとlisp monsterのほうが可愛いよね
487:デフォルトの名無しさん
22/07/25 21:31:20 o3/zkeTE.net
langってなに？
488:デフォルトの名無しさん
22/07/25 21:42:28 GF1rw+EH.net
ゴラン高原はイスラエルが不法に占領してるシリアの土地であり、日本政府
489:はシリア高原と呼称するそうだぞ。
490:デフォルトの名無しさん
22/07/26 07:10:48 4TZ4RWr2.net
今ちいかわってキモいキャラが流行ってるように
Gopherくんもいずれ世界的なマスコットキャラクターになるよ
491:デフォルトの名無しさん
22/07/26 08:04:10.89 B/e7/0Va.net
>>484
それはGolan
492:デフォルトの名無しさん
22/07/26 08:15:07.77 RlhOzjvN.net
今マイコン用クレートでメジャーなのってどのあたり？
自分で作るにあたり参考にしたいのだが
493:デフォルトの名無しさん
22/07/26 08:36:59.30 +EhcIf+H.net
>>487
おれたちが知るわけないだろバカか？
494:デフォルトの名無しさん
22/07/26 08:37:23.50 jFWmtimM.net
言語の名前がGopherだったらよかったのに
495:デフォルトの名無しさん
22/07/26 09:10:32.87 gGUkeHRo.net
プロトコルの方のgopherについて調べる人が困るでしょ
496:デフォルトの名無しさん
22/07/26 09:38:10.98 hAg2HYen.net
プロトコルはイーサリアムとビットコインで実現出来ます
この2種類以外は今後不要になります
497:デフォルトの名無しさん
22/07/26 09:42:41.59 xvJteLGG.net
😲
498:デフォルトの名無しさん
22/07/26 09:57:43.88 khPn0eWd.net
>>491
草
499:デフォルトの名無しさん
22/07/26 11:19:17.05 wEdk200U.net
Web3なんて流行るわけねーだろ
スマートコントラクトの開発コスト高すぎ＆不便すぎ
500:デフォルトの名無しさん
22/07/26 11:50:54.04 m36KkBXx.net
それに引き換えBorrow Checkerは開発コスト低くて便利だね
501:デフォルトの名無しさん
22/07/26 11:55:05.12 xpFZew7X.net
Rust=Web3 だからWeb3業界の勢いが無くなったら影響受けるよ
502:デフォルトの名無しさん
22/07/26 11:59:58.82 EbLORSqB.net
>>496
意味不明
503:デフォルトの名無しさん
22/07/26 12:14:19.05 /Gebh7sM.net
Etherはイーサーだけど
Ethereumはァセーリアム
日本語読みだと外人に通じないから注意な
504:デフォルトの名無しさん
22/07/26 12:46:34 NppJ7uYb.net
>>487
AVR-HALとかいうやつ使ってる
505:デフォルトの名無しさん
22/07/26 14:54:22.29 6ZBHWj0q.net
３年以内にMoveが天下取るとか言われてるけど本当かね
506:デフォルトの名無しさん
22/07/26 14:58:00.69 m36KkBXx.net
本当だから高くなる前にいっぱい買っておけ
507:デフォルトの名無しさん
22/07/26 21:01:19.60 WAPUil1D.net
ʕ◔ϖ◔ʔ
508:デフォルトの名無しさん
22/07/27 00:16:39.59 Zq3V4Tcb.net
>>500
Moveってなに？
509:デフォルトの名無しさん
22/07/27 01:54:06.44 qGGsA3uX.net
>>503
最新のブロックチェーン言語も知らない奴はここから消えて
510:デフォルトの名無しさん
22/07/27 05:50:23.11 Zq3V4Tcb.net
>>504
あれLibraってまだ生きてんの？
ぜんぜん音沙汰聞かないけど
511:487
22/07/27 07:28:03.29 6+JEeGDS.net
>>499
ありがと。見てみます
どのくらいのさじ加減が使いやすいのかが難しい・・・
512:デフォルトの名無しさん
22/07/27 07:32:05.65 6nSf0k+r.net
>>503
ダイハツの軽自動車
513:デフォルトの名無しさん
22/07/27 10:27:27.45 IW7fj0uw.net
>>505
名前変えた後継含めて公式に死んでる
514:デフォルトの名無しさん
22/07/27 19:19:33.01 U29fl458.net
>>505
世界に殺された
もし生まれたら恐ろしいことになってただろうしな
515:デフォルトの名無しさん
22/07/28 00:38:58 z/Vvst4i.net
アレはAptosとして生き残った
大型の資金調達を連発して次の投機の標的になってる
516:デフォルトの名無しさん
22/07/30 22:19:27.63 wZaxY20D.net
std::io::Result<()>
↑の()ってなんすか？
Ok(());
↑の()も。
「空」を意味してるってことでいいんですか？
517:デフォルトの名無しさん
22/07/30 22:34:27.43 PnFWbFUc.net
5つの何かを返す関数なら
return (a, b, c, d, e);
0つの何かを返す関数なら
return ();
と考えてもよく何も返さないこと
518:デフォルトの名無しさん
22/07/30 22:39:27.64 xUdiS2xM.net
URLﾘﾝｸ(doc.rust-lang.org)
519:デフォルトの名無しさん
22/07/30 22:41:59.23 wZaxY20D.net
>>512
>>513
どうもありがとう
520:デフォルトの名無しさん
22/08/01 16:04:37.53 ElZDPbmW.net
Meta社のバックエンドにRust推奨だってよ。
URLﾘﾝｸ(www.publickey1.jp)
521:デフォルトの名無しさん
22/08/02 02:20:06.29 M8Mca9lV.net
bevy 0.8
URLﾘﾝｸ(bevyengine.org)
522:デフォルトの名無しさん
22/08/02 23:33:57 FkNkpg49.net
bevyとFyrox Engineはどちらの方が良いのかな
人気度はbevyな気がするが
523:デフォルトの名無しさん
22/08/04 02:28:39.18 xaY+36ag.net
Rustでプラグインシステム組むならwasiが安牌かな
524:デフォルトの名無しさん
22/08/04 09:59:47.35 CkQzFtco.net
プラグインシステムとは
525:デフォルトの名無しさん
22/08/04 12:38:32.91 pLEfRi/j.net
エディタとかツールの機能拡張だよ。
RubyとかJVMとかある程度の動的さを持つランタイムがあると開発楽だけど、GoやRustみたいにスタティックリンク、シングルバイナリが基本になると
たしかにwasmベースで作るのが筋が良いのかねぇ。
526:デフォルトの名無しさん
22/08/04 12:57:45 qyv7p4eK.net
おいおいww
527:デフォルトの名無しさん
22/08/04 13:50:49.10 ck4xiQdl.net
クロスプラットフォームで同一バイナリが動いてそこそこ高速で組み込み用途に向いてる
という条件だとLuaかwasm
528:デフォルトの名無しさん
22/08/04 13:51:05.48 ck4xiQdl.net
JSでも良いが
529:デフォルトの名無しさん
22/08/04 15:10:31.96 b+TNnTjV.net
プラグインというよりマクロの実行環境の話だな
Luaやwasmはホストアプリにランタイムを同梱する必要がある
530:デフォルトの名無しさん
22/08/04 15:23:41.09 1k9fnhsy.net
Luaやwasmを使うようなスクリプト型(スクリプト言語のことではなくて、上位レイヤのシナリオだけをユーザーに書かせる方式)の拡張って、
よほどホスト側にプラットフォームとしての魅力がない限りは成立しないよ
ホストがスクリプトに対して提供している機能以上のことはできないわけだからな
そうじゃなくて、やりたいのはホストにない機能を追加できるプラグイン機構じゃないの？
531:デフォルトの名無しさん
22/08/04 15:39:46.71 9TNfUmNd.net
>>520
Rustでやりたいってことは実行速度を重視してるんだろうし動的リンクしかないだろ
しかしwasmにしてもいいっていうならJavaScriptやらLuaの活用も検討しろ
532:はちみつ餃子
22/08/04 15:55:10.42 hPtMGH66.net
そういえば Rust の proc macro を wasm としてコンパイルしたらどないやという話はあったんじゃなかったっけ？
最終的にどういう結論になったのか追ってないんやが……。
必要な機能は Rust コンパイラの中に全部あってシステムの外とやり取りする必要もないから良い案に思える。
533:デフォルトの名無しさん
22/08/04 17:17:23 KbhCPu0a.net
>>525
Luaやwasmからホストの用意した機能を呼び出す形だけでなく
ホストからLuaやwasm側の処理を呼び出す形も実装可能だよ
DLLに比べると相当手間がかかるけど
534:デフォルトの名無しさん
22/08/04 17:19:43 ck4xiQdl.net
動的リンクするにしてもABIがunstableだからインターフェースはextern "C"で公開せざるを得ないし
それなりの量のグルーコードが必要になるかと
その辺良い感じにどうにかしてくれるcrateがあるかもしれないけど
535:デフォルトの名無しさん
22/08/04 17:29:05.26 1k9fnhsy.net
>>528
そうしたとしてもホスト側に存在しない(ホストからスクリプトに対して公開されていない)機能は使えないでしょ？
536:デフォルトの名無しさん
22/08/04 17:46:52.95 CkQzFtco.net
URLﾘﾝｸ(qiita.com)
コメント欄も含めるとなかなか情報がまとまっています
537:デフォルトの名無しさん
22/08/04 17:49:06.27 8PPO9uzK.net
良さげ記事
538:はちみつ餃子
22/08/04 17:58:11.58 hPtMGH66.net
>>530
ホスト側を経由せずに外にアクセスするのは禁止できたほうが嬉しいことも多いだろ？
俺が使っているソフトでプラグイン機構があるものというと画像ビューアとかメッセンジャとかだが
それほど自由に外の世界にアクセスする必要はないし、不必要ならアクセスさせないに越したことは無い。
(悪意あるプラグインを作り難くなるので。)
制限があるというのと制限を付けられるのは表裏一体なのでそんなの場合によるとしか……
539:デフォルトの名無しさん
22/08/04 18:01:34.69 9TNfUmNd.net
>>529
> 動的リンクするにしてもABIがunstable
あー、そうだったわ
めんどくさいんだった
540:デフォルトの名無しさん
22/08/04 18:42:08.03 pLEfRi/j.net
野良プラグイン入れて環境壊して上等！って時代でもないからねえ。
ある程度、できること制限できるようにしたプラグイン機構も大事な時代よ。
そういう点でwasmがセキュリティとパフォーマンスのバランスが取れていて魅力という層もあるでしょ。
541:デフォルトの名無しさん
22/08/04 18:42:45.33 KbhCPu0a.net
>>530
そりゃ広い意味で言えばどんな機能だってホスト側に存在してなければ使えない
「ホストにない機能を追加できるプラグイン機構」ってどんなものイメージして言ってるの？
542:デフォルトの名無しさん
22/08/06 12:18:12.84 z/fLyAW1.net
今の環境で正しくレンダリングされる10年前に作られたWebサイトは多くない
同様にTauriで作成されたアプリが10年後でも問題なく使用できるのだろうか
543:デフォルトの名無しさん
22/08/06 20:40:11.73 6gQA87rg.net
Tauriはバックとフロントが明確に分離されているからOS標準ブラウザに変更があっても修繕はしやすそう
Macとかだと突然仕様変えてきそうで怖いな
544:デフォルトの名無しさん
22/08/07 00:00:20.59 pGypWfdH.net
Rustでライブラリをどうやって選定してんの？
crate.io見て人気のを選んでんの？
GETだけのためにhttpclient使おうとしたらtokio入れて使えとか全然意味わからんしコンパイルしたら
これを使うには2018使えと2022使えが出てくる…
他のに変えても変わらず
GETなんてコピペ産業で実現させてくれよ
use
初期化
GET
これで終わらせてくれ
545:デフォルトの名無しさん
22/08/07 00:05:00.47 pGypWfdH.net
別に
use
GET
の2行でもいい
546:デフォルトの名無しさん
22/08/07 00:19:22.87 thO2Aez3.net
>>539
まあ今はそういう人向けの言語じゃないからね
とりあえずreqwestのblocking clientでやってみて合わなそうならあきらめろん
547:デフォルトの名無しさん
22/08/07 00:27:13.75 pGypWfdH.net
crate.ioにwebclient一覧が並べてあるけど結局最近のダウンロード数見て判断なんだろうなと
どれもtokio使ってるしCurlコマンドみたいに一発でGETやPOSTって感じでもない
tokio必須と言うことは標準でasyncライブラリの完成度が低いんだろうけど
憶測が当たってるかどうかもよくわからない
548:はちみつ餃子
22/08/07 00:48:31.33 yGip1YMx.net
>>542
Rust は標準ライブラリの中に非同期ランタイムを持ってない。
言語として非同期を扱えるようにしつつ具体的な部分は外部のクレートに任せられるように
分離に成功しているという意味では十分に完成度は高いとも言える。
549:デフォルトの名無しさん
22/08/07 01:05:02.63 nCVSRdWl.net
>>539
簡単これだけ
#[async_std::main]
async fn main() {
let uri = "URLﾘﾝｸ(httpbin.org)
let s = surf::get(uri).recv_string().await.unwrap();
assert_eq!(s, "Hello, World!");
}
Cargo.tomlの[dependencies]に適当に
async-std = { version = "*", features = ["attributes", ] }
surf = "*"
550:デフォルトの名無しさん
22/08/07 05:20:01.36 FgVTxKNL.net
簡単に使いたいなら、非同期じゃなくて同期版のhttpクライアントライブラリ使いなよ
551:デフォルトの名無しさん
22/08/07 08:15:04.13 PrNdTuny.net
Goを素直に使っとけ
標準ライブラリでそのままできる上に非同期もGoroutineを使うだけ
テスト用のライブラリも用意されてるからクライアントサーバーもそのままテストできる
552:デフォルトの名無しさん
22/08/07 08:22:19.17 nCVSRdWl.net
>>546
Goなんていうものは不要
Rustで簡単に使える
553:デフォルトの名無しさん
22/08/07 08:29:14.86 PrNdTuny.net
標準ライブラリでHTTPクライアント・サーバー・テスト・非同期を全て統一的に扱えるってのはかなり強みではある
Rustはランタイムコストをゼロに近づけるためライブラリ化しているが、それは必ずしも利用者にとってメリットがあるわけではない
あくまでもOSやドライバなどを作る上でランタイムコストを削らないと適さないからそうなっているだけ
>>539 みたいな人にはまず用途を考えた上で高レイヤーのプログラムを作りたいのであれば素直にRust以外の言語を使うことをお勧めする
554:デフォルトの名無しさん
22/08/07 08:59:18 9InYic2G.net
>>548
あまりにも狭い視野と酷い誤解をなさっているようだが
ウェブ関係はRustのメリットが十分にある分野で実際にRustで利用が多い分野
555:デフォルトの名無しさん
22/08/07 09:24:53.04 OveVhBWN.net
複オジ相手にするのは隔離スレか実質隔離スレの次世代スレだけにしろ
556:デフォルトの名無しさん
22/08/07 09:37:06.87 VV/7IoC0.net
>>548はいつものRustアンチのキチガイかな
RustはOSやドライバ用と嘘をついてそれ以外なら他の言語を使うべきと誘導する書き込みがそっくり
557:デフォルトの名無しさん
22/08/07 10:46:09.01 W6kFcilw.net
キチガイ同士ここ以外で仲良くやっとけよ
邪魔なんだよ
558:デフォルトの名無しさん
22/08/07 12:14:32.05 46MSroSz.net
キチガイ隔離スレのココが機能していてなにより
559:デフォルトの名無しさん
22/08/07 12:50:43.08 45kFT7pS.net
次世代スレの方もﾜｯﾁｮｲ付ければ例のバカが寄り付かないことがほぼほぼ実証されつつあるので
あとは過疎を恐れず移行すれば万事解決です
560:デフォルトの名無しさん
22/08/07 13:58:05.65 ZjeWku4d.net
まだ実証されてないってことね
じゃあバスで
561:デフォルトの名無しさん
22/08/07 14:08:40.83 XsO6imG4.net
過疎やん
【ﾜｯﾁｮｲあり】プログラミング言語 Rust
ｽﾚﾘﾝｸ(tech板)
562:デフォルトの名無しさん
22/08/11 07:14:02.75 wbWFySKV.net
structに不変なフィールドを持たせるにはどうしたらいいのですか？
const定数ではなく、インスタンスごとに初期化時に値を設定したら、その後は変更不可能。
他のフィールドは変更可能でも。
563:はちみつ餃子
22/08/11 10:33:56.78 5k4DsUHs.net
>>557
直接的にメンバに指定を付けることは出来ない。
Rust のアクセス制御はモジュールが基本単位になっていて、
「メンバに pub が付いていない」「そのモジュールの中でメンバを変更することがない」ならば変更不可能なメンバになる。
564:デフォルトの名無しさん
22/08/11 11:32:02.59 wbWFySKV.net
>>558
ありがとうございます。
565:デフォルトの名無しさん
22/08/13 13:13:02.04 hNN+KHup.net
>>45-47
URLﾘﾝｸ(www.youtube.com)
566:デフォルトの名無しさん
[ここ壊れてます] .net
>>560
言語としてのRustにはピクリとも興味がわかなかったが
なんだか急にRustに興味がわいてきたぞー
567:デフォルトの名無しさん
22/08/16 13:03:21.19 RcKGtcJQ.net
VSCode + CodeLLDB + LLDBでデバッグしているのですが、ポインタに関して見方がよくわかりません
Borrowed pointer typeの参照先の値ってデバッガ上でどうやったら見れるんですか？
568:デフォルトの名無しさん
22/08/18 15:17:30.09 nMYke7rH.net
参考までに、mutはドイツ語で勇気の意味です。
569:デフォルトの名無しさん
22/08/19 15:36:33.17 MNFQes9z.net
スレチ
570:デフォルトの名無しさん
22/08/19 15:56:19.49 WZnrgrRN.net
今の時代ってcc++rustなんて、低レイヤーをやってる人以外は不要だな
Java Script全盛のこの時代にいちいちコンパイルするなんて面倒で仕方ない
571:デフォルトの名無しさん
22/08/19 17:51:45.38 jOBplE6P.net
釣りは隔離スレでどうぞ
572:デフォルトの名無しさん
22/08/21 14:52:30.50 j3ukytx2.net
RUST大流行だな
ほんと紛らわしい
573:デフォルトの名無しさん
[ここ壊れてます] .net
この言語開発した人、Swiftにいっちゃったみたいだけど追い出されたの？
574:デフォルトの名無しさん
22/08/21 21:36:56.87 RCuqOQsW.net
確か燃え尽き症候群で自分から離れたんじゃなかったかな
575:デフォルトの名無しさん
[ここ壊れてます] .net
嘘のようにボロ負けしたんだろうな
576:デフォルトの名無しさん
22/08/22 12:22:08.49 +Lu+Ewk5.net
ジャバスクリプト全盛の時代にネイティブこんぱいらなんて
不要だろ。
jsでカーネルのラードンをつくる猛者まで出てきた
577:デフォルトの名無しさん
22/08/25 01:05:28.98 YZq8nn1p.net
Arc<HashMap<T1, T2>>みたいにした場合って、どの範囲でスレッドセーフになるんですか？
578:デフォルトの名無しさん
22/08/25 02:02:11.07 sE5vq5kZ.net
範囲はHashMap全体たが
Arc単体で提供するスレッドセーフはimmutableな共有所有のみ
その例だとHashMapは読み取り専用になる
他を要求するなら他と組み合わせる
まずArcは置いといて単独所有の時
整数やブールならAtomicXxxでスレッドセーフ
一般的な型ならMutex<T>
読み取り同時複数ならRwLock<T>
それぞれコストが異なるので使い分ける
その上で共有所有ならArc<.....>をそれらの上に被せる
579:デフォルトの名無しさん
22/08/25 02:06:21.10 mMVVZ1qM.net
T1, T2がSend/Syncな前提だよね？
580:デフォルトの名無しさん
22/08/25 21:50:49.35 sE5vq5kZ.net
もちろんTがSync+Sendの時のみ
Arc<T>はSync+Sendとなる
581:デフォルトの名無しさん
22/08/25 23:42:19.60 3Alfspxr.net
条件を満たせなければコンパイラが指摘してくれるところがRustの良さ
間違えていても安全でなくてもコンパイルが通ってしまい実行時に酷い目に合う従来の言語
582:デフォルトの名無しさん
22/08/26 03:34:10.56 7ybirmBf.net
Test
583:デフォルトの名無しさん
22/08/26 10:06:51.61 i2SIEm4o.net
>>576
コンパイル通ったら安心と思い込む馬鹿
584:デフォルトの名無しさん
22/08/26 10:39:24.20 z3bi9+6P.net
そいつには触れるな
585:デフォルトの名無しさん
[ここ壊れてます] .net
>>578
思い込みで誤読しているあんたが馬鹿っぽい
>>576にはそんなこと書かれていない
586:デフォルトの名無しさん
22/08/27 02:23:31.10 4TEBlXJK.net
>>578
日本語読めないバカ
587:デフォルトの名無しさん
[ここ壊れてます] .net
>>578
うちの会社にもいるわ
ビルド出来たってドヤ顔のバカ
そんなものは、ある程度の言語の知識があればいいだけ。
588:デフォルトの名無しさん
22/08/27 13:37:40.60 VvCUXBS7.net
デバッグスキル0の奴がビルドだけでOKとか思いたがるんだわ。
589:デフォルトの名無しさん
22/08/27 14:27:59.40 fe4GQDaF.net
>>582
その会社ヤバくない？
大丈夫？
590:デフォルトの名無しさん
[ここ壊れてます] .net
確証バイアスかな？
591:デフォルトの名無しさん
22/08/27 20:57:03.41 0qPHVCED.net
>>585
お前ヤバくない？
大丈夫？
592:デフォルトの名無しさん
22/08/31 02:03:15.88 Lk5NPDCj.net
最強無敵言語age
593:デフォルトの名無しさん
22/08/31 08:04:44.83 +Igep1U8.net
>>587
入門者相手には最強だよな。
594:デフォルトの名無しさん
[ここ壊れてます] .net
急に書き込み減ったけどもう飽きられたの？
Scalaのときもそうだったけどエンジニアがこういう読みにくい言語で現場を遊び散らかして負債だけ残すの何とかして欲しいわ
595:デフォルトの名無しさん
[ここ壊れてます] .net
?の意味とか;の違いとか、すぐに調べられないからバッドノウハウ化しているよね。FAQとかダメダメだし。
せめて検索性に配慮して記号を決めればな。?::くらいにしても問題ないだろうに。
596:デフォルトの名無しさん
[ここ壊れてます] .net
ピークを過ぎた感はある
Scalaで遊んでたのはDDDとか高レイヤの好きな意識高い系が中心だったからまあそこまで酷い負債にはなってないけど、
その点Rustの負債はタチが悪そうだな
597:デフォルトの名無しさん
[ここ壊れてます] .net
Amazonがプログラミング言語「Rust」を使っている理由
URLﾘﾝｸ(japan.zdnet.com)
Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、GoogleやMicrosoftとともにRust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。
AWSのソフトウェアエンジニアで、Rustの普及に取り組む、
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。
Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。
「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
598:デフォルトの名無しさん
22/08/31 10:44:22.32 nTGfEW2M.net
>>590
そういう基本的なのはチュートリアルに書いてあるんだから何をあらためて検索する必要があるっていうんだ？
599:デフォルトの名無しさん
22/08/31 12:13:30.34 Fgf/9Zy6.net
>>590
文法は場当たり的に学ばないで初学者向けドキュメント読んだ方が良いと思うけどそれは置いておいて、
rust operatorでググって出てくるこれ参照して演算子の意味調べてもう一度ググれば良いのでは
それすらめんどくさい？
URLﾘﾝｸ(doc.rust-lang.org)
600:デフォルトの名無しさん
22/08/31 12:30:09.46 836P0mbg.net
question markとかsemicolonで調べればいいんだよ
601:デフォルトの名無しさん
22/08/31 12:34:08.26 J/OAC0EF.net
例えば
question mark site:doc.rust-lang.org
で検索すれば必要な解説がすぐ見つかる
602:デフォルトの名無しさん
[ここ壊れてます] .net
>>593
公式に「チュートリアル」てあったっけ？
THE Book読めということかしらん？
>>594
Error propagationとかStatement and item terminatorぐらいしか記載無いんだけど……
>>595
公式の解説出てこないんだけど、公式には説明無いんかね？
603:デフォルトの名無しさん
[ここ壊れてます] .net
>>596
おお、ここまで指定すれば見つかりますな。公式トップに検索窓ぐらい欲しいところだけど。
604:デフォルトの名無しさん
[ここ壊れてます] .net
>>597
エラーとか文に関わるものということが分かれば、関連するリファレンス探すとっかかりにはなるんじゃないかと
少なくとも記号よりは検索しやすい
605:デフォルトの名無しさん
22/08/31 13:39:17.87 lcZ+Kyy5.net
所有権チェックはありがたいけど、lintみたいにビルドと分けた方が使い勝手よかったと思うがな。
606:はちみつ餃子
22/08/31 13:42:22.79 nTGfEW2M.net
>>597
> THE Book読めということかしら
せやで。
まあそれに限らなくてもいいけどどんな入門書でも ? の説明がないなんてことはないでしょ。
常識的な手順通りに学習してれば ? が大まかに何をする演算子なのかくらいは知っているはずだし、
エラー処理にかかわるものだと知ってればもっと細かいドキュメントを探すのにも苦労するってことはない。
なるべく一発で検索できたほうが便利というのはわからんでもないが、
演算子であると同時に制御構文の類でもあり、周辺の機能と連携するのできちんとした理解をしようとすれば
どうせ色々と見るはめになる。
607:デフォルトの名無しさん
22/08/31 15:08:14.60 Fgf/9Zy6.net
>>600
所有権チェックをなくすってどういうこと？
referenceが有効な間に元データをmoveした場合に警告だけ出してコード自体はコンパイルできるようにするとかそういうこと？
608:デフォルトの名無しさん
22/08/31 16:15:20.37 bi3oBo/Y.net
コンパイル(ビルド)時に所有権チェックの結果を使ってメモリの解放処理を挿入してるんだから分けるのは無理
609:デフォルトの名無しさん
22/08/31 16:22:04.68 UXqUoG+N.net
ビルドしなくてももっと気軽にわかるようにしろってことか？
linterの領域外れてる気もするが
610:はちみつ餃子
22/08/31 16:50:31.19 nTGfEW2M.net
細かな所有権の整合性を後回しにしてとりあえず動く (ように見える) ところまでもっていきたいという気持ちはわからんもでない。
でもなー、そういうことすると整合性がとれてないままの未定義コードが世に溢れてしまうのは確実だろう。
611:デフォルトの名無しさん
22/08/31 16:56:11.73 LCT5ihCl.net
所有権周りのエラーって基本的なデータ構造に起因することが多いからなぁ
後から直そうとか思うと結局全部作り直すはめになるから
一度チェックなしモードとかで作っちゃうと永遠にそのままだろうね
612:デフォルトの名無しさん
22/08/31 17:04:46.18 BdHQqSBt.net
マンホールって卑猥な単語じゃね？
613:デフォルトの名無しさん
22/08/31 19:07:16.13 th8cAM8K.net
>>592
そのうち、他の分野のライフサイクルみたいに、製造時、利用時といった感じで電力効率が語られるようになるんかね。
614:デフォルトの名無しさん
22/08/31 20:09:18.42 iogMBVhq.net
>>601
the book読めというのはさすがに初心者殺しだと思うけどなぁ。
公式に絶壁の学習曲線をどうにかしようという意識はあるのかしらん？
615:デフォルトの名無しさん
22/08/31 20:22:19.87 3b0JioqE.net
学習曲線をどうにかしようという気合はめちゃめちゃあるが、バカを賢くしようというつもりはないだろう
616:はちみつ餃子
22/08/31 20:35:16.89 nTGfEW2M.net
>>609
えっ、なじみのない所有権システムとかも含めてめっちゃわかりやすく解説した the book を
用意してくれるなんてスゲー親切だと思うが、何が不満なんだ？
(俺自身は英語あんまりわからんので日本語訳を読んだ。)
617:デフォルトの名無しさん
22/08/31 20:38:24.92 SRFkQuBk.net
>>609
the bookは初心者のためのもの
Rustを全く知らなくてもちゃんと順を追って理解できるように書かれている
？は自分でエラー処理を書くようになり、
さらに自分の関数でResultなどを返すようになり、
そこでErr(e) => return Err(e)などを書くようになり、
そこでのショートカット表現として必要になるものだから
the bookでも同じ順で学べる
？をいきなり調べたい時や詳細を知りたい時は
the Rust referenceを開いて🔍をクリックして
question markと打てば該当ページに辿り着く
618:デフォルトの名無しさん
22/08/31 20:53:00.34 bW00GV9W.net
>>605
>>606
同意。
619:デフォルトの名無しさん
22/08/31 21:03:24.41 p14sgl1j.net
すべてがunsafeな世界になる
620:デフォルトの名無しさん
22/08/31 21:22:41.70 rT6IO02J.net
生きている限り安全なんてない
621:デフォルトの名無しさん
22/08/31 23:52:36.28 X48LRlQ+.net
ポエムはいいです
622:デフォルトの名無しさん
22/09/01 00:17:11.56 gQhEx8vQ.net
そうそうポエムいいよなぁ
みつヲ
623:デフォルトの名無しさん
22/09/01 01:28:45.35 v92yFclD.net
今時、ネイティブ吐く必要なんて全くない
tsでもvscのようなソフトが作れるんだし。
624: ユーザーランドではネイティブはもはや不要だろ
625:デフォルトの名無しさん
22/09/01 02:19:44.48 UU16wx/t.net
もしかしてelectron知らないのかしら
626:デフォルトの名無しさん
22/09/01 08:30:45.73 +imQtRK+.net
スクリプトって知らないのかしらん？
627:デフォルトの名無しさん
22/09/01 09:29:49.86 WQm7Gv/J.net
vscはコア部は全部C++だけど。
そのうえに薄くjs乗ってるだけやがな。
628:デフォルトの名無しさん
22/09/01 09:46:54.90 NH2cx+n6.net
Tauri (Rust) vs. Electron (C++)の戦いの結果…
＞ Electronの代替を目指す軽量なRust製フレームワーク「Tauri」
＞ URLﾘﾝｸ(www.publickey1.jp)
＞
＞ Electronはフロントエンドの基盤としてChromiumを組み込んでいますが、
＞ Tauriでは代わりに各OSが備えているWebViewの機能を、抽象化レイヤのwry経由で呼び出すことで、
＞ クロスプラットフォームを実現しつつChromiumを不要にしています。
＞ フレームワーク内にChromiumを組み込まないことでセキュリティも向上すると、Tauri開発チームは説明しています。
↓ 「マジ？！」と思っていたらマジだった！！
＞開発フレームワーク「Electron」に複数の脆弱性
＞URLﾘﾝｸ(news.mynavi.jp)
＞
＞Electronは、HTML5やCSS、JavaScriptといったWeb技術を用いてデスクトップアプリケーションを開発することができるフレームワークで、
＞Microsoft TeamsやVisual Studio Code（VSCode）、Discordなどの人気アプリケーションでも利用されている。
＞今回のElectronの脆弱性に関する発表は、米国で開催されたサイバーセキュリティカンファレンス「Black Hat USA 2022」の次のセッションで行われたもの。
＞研究チームがElectronを使用して開発された20のアプリケーションを調査し、そこで発見された複数の脆弱性について報告した。
＞発見された脆弱性の一例としては、以下が挙げられている。
＞・VS Codeにおけるリモートコード実行の脆弱性
＞・Discordにおけるリモートコード実行の脆弱性
＞・Microsoft Teamsにおけるクロスサイトスクリプティング脆弱性
＞・ChromeのCSP（Content Security Policy）バイパスの脆弱性
＞・V8のリモートコード実行の脆弱性
629:デフォルトの名無しさん
22/09/01 12:18:02.95 Wlby5VAy.net
>>621
そうなん？わりとネイティブが薄くてTSが主体だと思ってた。
630:デフォルトの名無しさん
22/09/02 12:29:12.76 EMfEx7SW.net
GUIがtsの時点でお察し
やたらとモッサリしてんじゃん
631:デフォルトの名無しさん
22/09/02 22:13:08.24 06QeBluE.net
--emit asmで吐かれるアセンブラリストのフォーマットの資料ってどっかにある？
gas系っぽく見えるけどちょいちょい判らないのが・・・
632:デフォルトの名無しさん
22/09/02 22:55:35.95 TRifMPKk.net
--emit=asm -C "llvm-args=-x86-asm-syntax=intel”とかで指定できるみたいよ
633:デフォルトの名無しさん
22/09/04 14:45:48.94 c9grlmUi.net
VScodeがもっさりは感じたことないな
ネイティブのVSのほうが重すぎ
634:デフォルトの名無しさん
[ここ壊れてます] .net
関数の入出力はu8だけど関数内の計算はi32で行いたい場合って普通どんな感じで書くの？
635:デフォルトの名無しさん
22/09/05 15:19:35.29 TAlRHagA.net
そんなユースケースあるの？
636:デフォルトの名無しさん
22/09/05 15:31:51.51 TaR2CBOa.net
>>629
隔離スレでドヤりたいというユースケース
637:デフォルトの名無しさん
22/09/05 15:54:23.38 vyOP5LW0.net
いつも隔離スレのここが機能してくれて助かってます
638:はちみつ餃子
22/09/05 16:16:12.15 QNR7HRCU.net
>>628
一旦変換すりゃいいだけなんじゃないの。 知らんけど。
639:628
22/09/05 17:50:42.31 Y4+oTyIj.net
例えばこんなの
fn func(x: u8, y: u8) -> u8 {
let x32 = x as i32;
let y32 = y as i32;
let z32 = (((x32 - y32) * 170) >> 16) + y32;
return z32 as u8;
}
4行使うのは冗長かなーと思わなくもなく・・・
テンポラリ変数の名前を考えるのもちょっと面倒だし
640:デフォルトの名無しさん
22/09/05 17:54:10.85 vXwuqGKm.net
>>633
シャドーイングできるからテンポラリの変数名は不要だよ
let x = x as u32;
でいい
641:デフォルトの名無しさん
22/09/05 19:20:47.36 g3RfqaIY.net
>>633
行数短くしたいだけなら
fn func(x: u8, y: u8) -> u8 {
let (x, y) = (x as u8, y as u8);
(((x - y) * 170) >> 16) + y) as u8
}
とは書けるけどやってることは全く同じだしこれで期待に応えられてるかは分からん
642:デフォルトの名無しさん
22/09/05 19:21:35.07 g3RfqaIY.net
>>635
2行目間違えた
as i32 に読み替えて
643:デフォルトの名無しさん
[ここ壊れてます] .net
>>633
その例は手動で最適化すると
fn func(_x: u8, y: u8) -> u8 {
y
}
それはともかく
行数を節約したいという間違った価値観を捨てることをおすすめ
644:デフォルトの名無しさん
[ここ壊れてます] .net
x < y の場合考慮してなさそう
645:デフォルトの名無しさん
22/09/05 21:53:26.61 wI2HBmBd.net
ホントだごめん訂正
fn func(x: u8, y: u8) -> u8 {
y - (x < y) as u8
}
646:デフォルトの名無しさん
22/09/06 00:31:42.49 EiVnVIDc.net
結局u8で返すなら
途中でi32使わずとも
工夫するとu8のままだけで算出できちゃったりするわけか
647:デフォルトの名無しさん
22/09/06 00:52:56.28 uJFa29+7.net
逆方向にシフトした場合は？
そんな用途があるのか知らんけど
648:デフォルトの名無しさん
22/09/06 01:12:27.41 EiVnVIDc.net
>>641
それはu8部分の下位8bitが常にゼロとなって
足しても引いても影響ないかな
649:628
22/09/06 11:02:40.94 xGSGq1SQ.net
スタンダードな書き方みたいなのはないのかな
なら>>634で行こうと思います
あと>>633は右シフトを間違えていました
16ではなく8です
650:デフォルトの名無しさん
22/09/07 08:11:56.26 8saglJYc.net
Rustのバイトオーダーってそのターゲットのネイティブ(x64ならリトルエンディアン)で良いの？
651:デフォルトの名無しさん
22/09/07 08:24:04.31 41cUJGIp.net
もちろん
そして依存しないよう3種類用意されてる
assert_eq!(0x01020304, u32::from_be_bytes([1, 2, 3, 4])); // big endian
assert_eq!(0x04030201, u32::from_le_bytes([1, 2, 3, 4])); // little endian
assert_eq!(XXX, u32::from_ne_bytes([1, 2, 3, 4])); // native endian
652:デフォルトの名無しさん
22/09/07 23:31:51.68 qqHULq33.net
native endianというのは初めて聞いたのですが、これはどういうものなのですか？
653:デフォルトの名無しさん
22/09/07 23:54:21.35 En8I5Kb5.net
この場合 >>644も書いているようにコンパイルターゲット環境のエンディアンのこと
特にターゲット指定がなければ自分の使っているPC環境で通常はx64などlittle endianになりますが
そこでleと指定してはダメで環境に応じて適切に対応させるためにneを使います
一方でAPIなどでエンディアンが指定されてる時は指定通りbeかleを使います
654:デフォルトの名無しさん
22/09/08 00:04:41.95 nmwPOGZ0.net
>>645
サンクス。u32とかにはfrom_leとかあるみたいですね。こっちの方が使う機会は多そう
デフォルトのバイトオーダーを変更したり、変数やフィールド単位でバイトオーダーを設定する
みたいな芸当は流石に無理なのかな・・・ググったけどそれっぽい情報は見つけられなかった
655:デフォルトの名無しさん
22/09/08 00:19:17.65 8UoQH6yi.net
>>648
操作に最適なバイトオーダーは使用CPUで決まるネイティブエンディアン
だから原則としてネイティブエンディアンのみでプログラミングする
例外として外部とのやりとりなどエンディアン指定がある時はその境界で変換
656:はちみつ餃子
22/09/08 00:23:28.76 MG9wnc1h.net
>>648
内部的に色々な表現を有りということにするならやりたい操作を個別に定義するしかないよ。
でも普通はそんな煩雑なことをしたくないから
内部的には一環した表現を使って必要な変換は入出力のみというのが一般的な構成だし、
言語やライブラリも基本的には一般的な構成に倣っている。
657:デフォルトの名無しさん
22/09/08 01:11:28.44 U6/gufpm.net
>>648
変数やフィールドのメモリ上の表現�
658:ｪ特定のエンディアンにしたいのであれば、 #[repr(C)] struct BeU32([u8; 4]); みたいな構造体を用意して impl Be32 { fn get(&self) -> u32 { u32::from_be_bytes(self.0) } fn ser (&mut self, v: u32) { self.0 = v.to_be_bytes(); } } こういうアクセサを実装すれば良いかと 何の役に立つのかはよくわからないけど、特定のエンディアンでシリアライズされたデータにそのままアクセスしたい場合とかに便利なのかな
659:デフォルトの名無しさん
22/09/08 01:21:33.97 5HeI/FQK.net
mansplainers
660:デフォルトの名無しさん
22/09/08 15:55:57.30 Vswe11EN.net
RustをOpenMPIに対応させるようなプロジェクトってありますか？
661:デフォルトの名無しさん
22/09/08 16:49:24.48 mLv3aAxt.net
「Rust OpenMPI」でGoogle検索
662:デフォルトの名無しさん
22/09/08 18:02:42.70 U6/gufpm.net
OpenMP なのか Open MPI なのかどっち
663:デフォルトの名無しさん
22/09/08 20:45:38.87 Vswe11EN.net
知りたいのはOpenMPIの方です
ググるとOpenMPIとOpenMPを勘違いしたと思われるRayonを紹介する記事が出てきたり、OpenMPがらみのサイトが出てきたり、なかなか状況が分かりません・・・・
664:デフォルトの名無しさん
22/09/08 20:53:50.25 RwfCQI7B.net
一番上のrsmpiは違うの
665:デフォルトの名無しさん
22/09/08 21:56:17.41 fa0yFdt8.net
MPIはHPC以外では使う必要ないです
機械学習でも有用だとは思いますが
そもそもフレームワークが対応していないから
全部自前で作ってるような人以外は必要ないです
666:デフォルトの名無しさん
22/09/09 01:14:31.51 4b4Wyf25.net
Open MPIに限らずMPIはアプリから見たらただのライブラリだからRust側で特別な対応は不要で単にCの関数を呼び出せばよいだけでは
667:デフォルトの名無しさん
22/09/09 08:12:49.36 auDHI5c1.net
良くありがちな奴だと思うけど
struct ARGB32 {A: u8, R: u8, G: u8, B: u8,}
みたいに書くとスネークケースじゃないと警告が出るけどどう書くのがRust流なの？
これ小文字にしちゃったら少なからず可読性が落ちるよね
668:デフォルトの名無しさん
22/09/09 08:31:41.27 WeF8ASv0.net
#[allow(non_snake_case)]
しかしフィールド名だけ小文字にすれば不要
struct ARGB32 {a: u8, r: u8, g: u8, b: u8,}
そして可読性が落ちると思わない
669:デフォルトの名無しさん
22/09/09 09:24:21.25 4b4Wyf25.net
構造体名もCamelCaseでArgb32とすべきかな
670:デフォルトの名無しさん
22/09/09 12:29:38.55 6YdHvwwi.net
識別子を極端に省略するのは良くないという現代のプログラミングの流儀と業界の略語でコンフリクトしてるよね。
略語を使わずに書くとこうかね？
Color<T>{alpha: T, red: T, green: T, blue: T}
CMYはどうなるとか言い出すやつがいると面倒そうだけど。
671:デフォルトの名無しさん
22/09/09 12:42:45.67 VsTRsG1f.net
enum Color {
Red,
Blue,
Green,
RGB(u32, u32, u32),
HSV(u32, u32, u32),
HSL(u32, u32, u32),
CMY(u32, u32, u32),
CMYK(u32, u32, u32, u32),
}
672:デフォルトの名無しさん
22/09/09 13:41:22.02 4b4Wyf25.net
最低限ガイドには従った方が良いと思う
URLﾘﾝｸ(rust-lang.github.io)
acronymはひとつ単語として扱うとあるから Rgb とか Argb とすべき
あとは適当なグラフィック系ライブラリの実装を見て真似してみたら良いのでは
規約に従ってないライブラリも多いけど
そもそも既存crate使えば独自にArgb型定義する必要もなくなるかもしれない
673:はちみつ餃子
22/09/09 14:02:11.22 gp9Eay33.net
API ガイドラインってことは、 API として公開しない (内部的な) 名前は雑でいいってことだよね。
674:デフォルトの名無しさん
22/09/09 14:15:33.61 +r9uXbjm.net
>>661
個人的にはこっちの方が好きだけど
規約的にダメなら仕方ない