Rust part16

**デフォルトの名無しさん** · 2022/06/27(月) 08:17:03.45

公式
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/

**デフォルトの名無しさん** · 2022/07/15(金) 21:39:01.85

>>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<_>>が使えた

**デフォルトの名無しさん** · 2022/07/15(金) 22:48:49.30

#[derive(Clone)]のコーナーケースに遭遇した
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=487e64c7c762fb0e015e1bc9b1267fbd

**デフォルトの名無しさん** · 2022/07/15(金) 22:50:32.95

やっぱりrustcはバグが多いね

**デフォルトの名無しさん** · 2022/07/15(金) 23:12:58.85

>>362
標準ライブラリのderiveは型パラメータに無条件にトレイト制約課すようになってるから
derivativeみたいな制約を自分で指定できるcrateを使うと良いよ
https://github.com/mcarton/rust-derivative

**デフォルトの名無しさん** · 2022/07/16(土) 00:28:56.56

>>361
get()がCopyを要求するからってのもあるけど
古いThe BookにはCellはCopy専用・RefCellはCopy以外も使えるという説明があったので
それが日本語訳とかで残ってたんじゃないかな

**デフォルトの名無しさん** · 2022/07/16(土) 23:27:56.53

>>360
!Syncで参照無しならデータ競合を起こさない、という点を使った用法だな
便利だから公式サポートすればいいのにな

**デフォルトの名無しさん** · 2022/07/20(水) 00:26:56.65

StackOverflowで「好きな言語No.1」だそうだが、調査方法に問題が有り、
二位以下も聞いた事が無いような言語ばかり。

**デフォルトの名無しさん** · 2022/07/20(水) 01:36:05.55

>>367
お前の観測範囲が狭いだけ。

**デフォルトの名無しさん** · 2022/07/20(水) 08:04:49.97

CarbonとかいうRustとC++のあいのこみたいなのが出てきた

**デフォルトの名無しさん** · 2022/07/20(水) 12:35:25.82

Carbonは最強言語ぞ

**デフォルトの名無しさん** · 2022/07/20(水) 12:39:05.42

RustがCarbonに勝ててるところが見つからないな

**デフォルトの名無しさん** · 2022/07/20(水) 12:45:18.87

Rust vs Carbonスレ立ててそっちでやれ

**デフォルトの名無しさん** · 2022/07/20(水) 13:30:14.44

このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい

**デフォルトの名無しさん** · 2022/07/20(水) 13:30:16.81

このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい

**デフォルトの名無しさん** · 2022/07/20(水) 14:11:36.68

1.0が出てからにしてください

**デフォルトの名無しさん** · 2022/07/20(水) 14:52:25.57

CarbonとRustは名称の紛らわしさではどっこいどっこいだな

**デフォルトの名無しさん** · 2022/07/20(水) 14:54:39.84

ほーん
https://github.com/carbon-language/carbon-lang

**デフォルトの名無しさん** · 2022/07/20(水) 17:02:14.65

とりあえずcarbon自体のコードの8割がcarbonで書かれるエコシステムが確立してからだろう

**デフォルトの名無しさん** · 2022/07/20(水) 19:50:56.65

JSのTypeScript
C++のCarbonって感じかね

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

**デフォルトの名無しさん** · 2022/07/20(水) 20:00:37.08

Rustはあらゆる面で安全と高速の両立する抽象化を実現した言語だから
現在のCarbonのドキュメントを見る限りRustの領分に入ってきていないでしょう
それよりもC++と書き方がかなり変わっていて互換性がなく別言語の様相でCarbonは中途半端な立ち位置に見える

**デフォルトの名無しさん** · 2022/07/20(水) 20:01:46.68

Carbonは「Rustが難しすぎるから簡単にしたい」とは言ってなくて、C++と相互運用できる言語を目指してるだけっぽいからなぁ
結果的にRustより難しくなっても驚かないけど

**デフォルトの名無しさん** · 2022/07/20(水) 20:33:50.16

そもそもCarbonの使い所ってC++のレガシーコードが大量にあるところだから
C++も当然マスターしてないといけなくて、学習量は明らかに増えてる気もする

**デフォルトの名無しさん** · 2022/07/20(水) 20:52:36.69

ドラゴンボールのゲームでドドリアの色違いでカーボスと言うのがいたのを思い出した

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

**デフォルトの名無しさん** · 2022/07/20(水) 21:27:24.19

Carbonって中途半端すぎね？
まともな言語設計者ならオブジェクト指向もう採用しないと思うんやけどなんか継承機能もあるみたいだし
なんでこういう中途半端のところもC++参考するんだよこういうところこそRust参考にしろよ

**デフォルトの名無しさん** · 2022/07/20(水) 21:44:56.66

>>384
C++とシームレスに相互運用することが最優先課題だから、そこはC++と同じにしておかないとそもそも存在意義がなくなる

**デフォルトの名無しさん** · 2022/07/20(水) 22:16:07.31

ま、2-3年後にどうなってるかだな
バックにGoogleいるらしいから開発終了なんてことはなさそうだが

**デフォルトの名無しさん** · 2022/07/20(水) 22:21:24.71

>>386
逆じゃね？企業だからこそ開発者の熱意とか関係なくコストに見合わないとなれば容赦なく切られるかと
Goみたいに社内で使うことが確定してしまえば安泰だけど

**デフォルトの名無しさん** · 2022/07/20(水) 22:28:16.35

SDGsの流れ的にCarbonは使われなくなる運命

**デフォルトの名無しさん** · 2022/07/20(水) 22:43:27.67

なる、元素記号Cからの名称か

**デフォルトの名無しさん** · 2022/07/21(木) 00:45:01.09

5年たったらまたオブジェクト指向が再燃してるかもしれない
と言うか業務では大規模開発にはオブジェクト指向が必須なんだな

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

**はちみつ餃子** ◆8X2XSCHEME · 2022/07/21(木) 00:52:44.62

話題が逸れるが >>384 が C++ の型システムをオブジェクト指向と呼んでるっぽいのが気になる。
オブジェクト指向はオブジェクト同士がメッセージを送りあう形でプログラムを構成する思想のことで、
それを言語機能としてどのように支援するのかには様々なバリエーションが有りうる。
型システムとは独立した概念だよ。
ふんわりした概念なので定義によるが Rust もオブジェクト指向 (をサポートする) 言語に分類されることはある。

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

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

**デフォルトの名無しさん** · 2022/07/21(木) 00:54:52.22

話題が逸れるが、...で読む気失せたわ

**デフォルトの名無しさん** · 2022/07/21(木) 00:58:24.47

>>391
前半は正しいが
後半のクラス継承システム程度で十分という点には賛同しかねる
今までの現実の多くのケースはクラス継承システムしか使えない環境だったから無理矢理にそれを使っているだけである

**デフォルトの名無しさん** · 2022/07/21(木) 01:00:56.06

似たような機能のものを大量に書く場合どのように実装するのが楽かどのように管理するのが楽か

モジュールではないな

**デフォルトの名無しさん** · 2022/07/21(木) 01:15:53.78

>>394
その点ではRustもC++も同じオブジェクト指向なので何を主張したいのかわからない

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

**デフォルトの名無しさん** · 2022/07/21(木) 03:25:39.61

いくらRustが有望だと言われていても、ポインターがないと使いづらい場面ってあるよな
ツリー構造とか、ポインターなしで大して実行速度も落とさず記述する技があるようだけど・・・・大掛かりなことをするのなら労力を割くのもいいけど、ちょっと使うだけには労力がかかりすぎる

**デフォルトの名無しさん** · 2022/07/21(木) 04:26:36.96

ポインタあるじゃん

**デフォルトの名無しさん** · 2022/07/21(木) 05:01:15.84

>>396
Rustにも様々なポインタがあり
様々な仕様と様々な安全度合いで記述できる

**デフォルトの名無しさん** · 2022/07/21(木) 08:09:40.58

>>385
Rustからわかるように、求められているのは膝を打ち抜く自由の無いc++であり、コーダーに使わせる言語。
unsafeはc++で実装すりゃいいので、継承とかは使うだけに限定するという手もある。

**デフォルトの名無しさん** · 2022/07/21(木) 13:48:15.98

>>391
話し手がなにをオブジェクト指向の言語としているのかどうか判断する程度の読解力は持ち合わせてくれないかな？
RustはC++のように継承を導入することによってもたらされる問題を回避するためにclassじゃなくてtraitを基本的なプログラムの構成要素として採用することで既存のオブジェクト指向言語と一線を画すというプログラミング言語史に残る進歩を達成していた

**デフォルトの名無しさん** · 2022/07/21(木) 15:49:13.07

>>400
Haskellの型クラスの方が先だろ。

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

**デフォルトの名無しさん** · 2022/07/21(木) 16:58:11.12

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

**デフォルトの名無しさん** · 2022/07/21(木) 17:50:57.39

traitの画期的な部分はc++のabstract classで実現できないの？

**デフォルトの名無しさん** · 2022/07/21(木) 17:54:16.35

>>402
何が言いたいのかよくわからないけど型クラスになくてtraitにあるものって何？

associate typeはrustの発明だと思うけど、そういうこと言いたいわけでもなさそうだし

**デフォルトの名無しさん** · 2022/07/21(木) 18:07:36.13

自分が崇拝する神だけが唯一正しいと妄信して
他人の考え方を徹底的に糾弾排斥するのがカルト

カルト化した人間とまともな議論ができると思うな

**デフォルトの名無しさん** · 2022/07/21(木) 18:19:30.67

>>404
公式サイトにすら出典付きで載ってあることなんだけどなんでここで聞くの？
繰り返しになるがtraitの型クラス以外の側面に気づけないのはお前が単に馬鹿なだけ

**デフォルトの名無しさん** · 2022/07/21(木) 19:01:28.92

>>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.

**デフォルトの名無しさん** · 2022/07/21(木) 19:15:30.44

>>407
traitの方が表現力低いって言ってるじゃねーか

**デフォルトの名無しさん** · 2022/07/21(木) 20:10:50.68

レスバスレ使ってくれませんか？

**デフォルトの名無しさん** · 2022/07/21(木) 20:48:28.30

>>407
それURLがprevで始まっているように古い情報ページ
わざわざそれを出すのは何か意図がある？

**デフォルトの名無しさん** · 2022/07/21(木) 21:43:04.55

>>408
正しい情報を啓蒙するのは面倒だということを知らしめる意図じゃない？

**デフォルトの名無しさん** · 2022/07/21(木) 21:59:42.36

>>404
Rustのトレイトは
トレイト境界を実装で指定できるだけでなく
トレイト境界を型宣言でも指定できるなど
様々な点で型クラスと異なるよね？

**デフォルトの名無しさん** · 2022/07/21(木) 22:56:58.50

幽霊型🥺

**デフォルトの名無しさん** · 2022/07/21(木) 23:06:53.32

>>404
associated typeもhaskell由来

**デフォルトの名無しさん** · 2022/07/21(木) 23:56:47.54

>>412
トレイトに関しては当然Haskellの型クラス由来の部分が多いけど互いに片方にしかないものもあり異なる側面があるわけか

**デフォルトの名無しさん** · 2022/07/22(金) 00:02:56.00

>>412
よくわかんないからコードで書いて

**デフォルトの名無しさん** · 2022/07/22(金) 00:07:23.73

今のところ型システムは完全下位互換だよ

**デフォルトの名無しさん** · 2022/07/22(金) 00:22:12.08

>>416
普通のこれだろ
struct Foo<T: Trait1 + Trait2> {
　inner: T,
}

**デフォルトの名無しさん** · 2022/07/22(金) 00:32:54.07

>>418
これが>>402が言う型クラス以上の意義があるものなの？

**デフォルトの名無しさん** · 2022/07/22(金) 00:45:08.67

402の話は402に聞け
少なくとも>>418は型定義の時点で制約できるから意義がある

**デフォルトの名無しさん** · 2022/07/22(金) 00:46:45.91

>>418
-XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language.

**デフォルトの名無しさん** · 2022/07/22(金) 01:09:40.70

>>421
いきなり何かわからない話を向けられても困る
解説せよ

**デフォルトの名無しさん** · 2022/07/22(金) 01:43:49.12

トレイトのどの辺が「洗練された新たなプログラム構成要素」と感じるのか全然分からん
俺の中ではインターフェースと一緒の扱い

Rustが画期的だったのはOwnership/Referenceルール + Borrow Checker
この点に異論ある人はいないよね？

**デフォルトの名無しさん** · 2022/07/22(金) 02:15:42.10

>>423
一般的なインタフェースなんて
Trait Boundsもimpl Traitもdyn Traitもないゴミ

>>419
その点でも差異があるだけでなく
Rustのトレイトは基本概念こそHaskellの型クラスと同じだがそれ以外は各々の言語に適応してかなり異なる

**はちみつ餃子** ◆8X2XSCHEME · 2022/07/22(金) 03:26:24.88

>>424
そりゃ言語に合わせて変えるところがあるのは当たり前だが、
基本概念が同じだというなら類似物ではあるだろう。
カテゴリ分けしたらおおよそ同じところに分類するよ……。

**デフォルトの名無しさん** · 2022/07/22(金) 03:47:26.49

>>425
それは違うのではないかな
例えばHaskellはRustのtraitでのdyn(動的解決)とimpl(静的解決)といった重要な基本概念を欠いているよ

**デフォルトの名無しさん** · 2022/07/22(金) 05:52:26.07

C++の欠点は、何でもできること。
その欠点をなくして、わかりやすくしたのがRust。
バイナリ界のJavaと言い換えても良い。
ほとんどのプログラマはC++よりRustを使うほうが良い。

**デフォルトの名無しさん** · 2022/07/22(金) 08:04:03.49

>>410
だから最新情報に誘導しろよ。
無能か？

**デフォルトの名無しさん** · 2022/07/22(金) 09:31:13.18

>>427
これからRustはIT土方専用言語になっていくんだろうなあ

**デフォルトの名無しさん** · 2022/07/22(金) 09:55:09.86

>>424
>一般的なインタフェースなんて
>Trait Boundsもimpl Traitもdyn Traitもないゴミ

言語化できてないから本質を理解できていように見える

Trait Boundはジェネリック型の型制約で一般的なインターフェイスも型制約として機能する
一般的なインターフェイスは動的ディスパッチなのでdyn Trait相当

impl Traitがmonomorphizationのことを言ってるならそれはTraitの機能じゃなくGenericsの機能
C++で20年前から使えるよね？
C++以外でもSwiftみたいに一部の言語はGenericsのspecialization機能があるけど一般的にはオーバーロード使ってstatic dispatchにすることが可能

**デフォルトの名無しさん** · 2022/07/22(金) 10:57:57.42

>>418
javaのgenericsでextends使うとできるやつかな？

**デフォルトの名無しさん** · 2022/07/22(金) 11:30:46.07

Java厨は出て来ないで下さいうざいだけです

**デフォルトの名無しさん** · 2022/07/22(金) 11:34:22.85

>>429
msとかgoogleとかの狙いはそうだろ。
土方がコーティングしてもバグが入り込まない。
その代わり難易度が上がっているからコーダーの単価上がりそうだけど、msとかgoogleはそんなの気にしないだろうし。

**デフォルトの名無しさん** · 2022/07/22(金) 13:14:37.08

>>432
rustの画期的な部分なんだろ？言い返せないのかよダサいなお前

本当に革新的なのは>>423あたりなんじゃないの

**デフォルトの名無しさん** · 2022/07/22(金) 14:36:57.37

kumagiとか見てると、google社員でもc++触らせたらあかん奴ってのが結構いるのがわかる。

**デフォルトの名無しさん** · 2022/07/22(金) 14:59:23.46

>>431
Javaのジェネリクスは変な制限が多く
インタフェース指定していって問題があってもコンパイルエラーとならず実行時エラーとなるものがあるなどJavaは論外
他にも問題多すぎてRustに何ひとつ勝てないから新システムを機会にJava→Rustとなったものも出てきている

**デフォルトの名無しさん** · 2022/07/22(金) 15:43:33.15

>>434
Ownership/reference自体はc++にもあるからあんまり革新的とは思えないな。

コールスタック&RAIIを中心にしてメモリ管理ルールを再構築して、厄介なヒープメモリの管理をできるだけ避けて高速化しているのが特徴だと思う。
革新的なのはそのルールを徹底していることくらいかと。

**デフォルトの名無しさん** · 2022/07/22(金) 17:12:05.71

安全性とゼロコスト抽象化の制約下で開発効率を高める仕組みを導入していることがRustの特徴だよね
言語仕様や処理系実装上での苦労や工夫はいろいろあるが、それらによって実現される機能自体が目新しいものというわけではない

**デフォルトの名無しさん** · 2022/07/22(金) 17:40:06.82

Rustが発明したのかどうかはしらんけど、Borrow Checkerは他の普通の言語にはない仕組みで、目新しく感じるけどなあ
Borrow Checkerが効かないようなコードを書くんだったらRustを使う意味が感じられないぐらいにはね

**デフォルトの名無しさん** · 2022/07/22(金) 17:44:11.14

>>436
インターフェースの問題とJavaの問題を混同するのが論外

**デフォルトの名無しさん** · 2022/07/22(金) 18:05:15.33

Borrow checker自体は2000年頃のCycloneの時点でほぼできていたっぽい
Rust独自なのは多分shared xor mutableとmove by defaultじゃないかな

**デフォルトの名無しさん** · 2022/07/22(金) 19:11:51.06

>>437
そう。
C++には何でもある。
それが欠点。
必要なものに厳選して誰でも使えるようにしたのがRust。
C++のアイデアとJavaの実用性、二つの遺伝子を組み合わせたのがRust。
ちなみにお母さんがJava、お父さんはHaskellという建前だけど、本当のお父さんはC++。
Haskellさんは、自分の子供だと信じてる。

**デフォルトの名無しさん** · 2022/07/22(金) 21:06:16.19

キモいな
Javaは遺伝子引き継いでないから代理出産に違いない

**デフォルトの名無しさん** · 2022/07/22(金) 21:16:25.55

>>442
javaの立ち位置なんて、無関係な癖に建物の影からチラチラこちらをうかがって変な妄想してる気味悪い知らない奴だよ。

**デフォルトの名無しさん** · 2022/07/22(金) 21:29:36.07

>>435
あの人はプログラミング能力だけの人じゃなくてDBとか分散システムのアルゴリズムが主戦場の人でしょ。
プログラム読み書き堪能に越したことはないけど、そこだけで人を評価するのは視野が狭いよ。

**デフォルトの名無しさん** · 2022/07/23(土) 04:53:27.63

>>444
意味不明なこと言わないで

**デフォルトの名無しさん** · 2022/07/23(土) 05:40:41.12

>>435
C++だけでなくRustも理解できてない？

＠
純粋に疑問なんですけどRust使ってる中で「値オブジェクトマジ助かる！」って事あるんですか。
適当に参照で渡したデータが意図せず書き換えられて伝搬して困る典型ケースはコンパイラが潰してくれる認識なんですが。

**デフォルトの名無しさん** · 2022/07/23(土) 08:37:27.70

>>447
それはRustじゃなく値オブジェクトを理解できてない
院卒の新人だったりしない？

**デフォルトの名無しさん** · 2022/07/23(土) 09:37:03.85

Googleは金の亡者

**デフォルトの名無しさん** · 2022/07/23(土) 11:55:37.32

>>448
低レイヤーのプログラマーは値オブジェクトとか知らないほうが普通
アーキテクチャ設計といったらCPUやメモリアーキテクチャの事だと思ってたりするw

**デフォルトの名無しさん** · 2022/07/23(土) 13:10:56.93

OwnershipルールとReferenceルールがWhat
Borrow CheckerはHowに相当

Howにももちろん価値はあるが
それと同じくらいWhatをシンプルに絞り込んだものにしたことにも価値がある

後知恵で見れば当然に見えるようなシンプルなルールを作るのはものすごく難易度が高い

**デフォルトの名無しさん** · 2022/07/23(土) 16:15:20.09

>>451
わかる
Rustのメモリ周りや、UnixとかRISC-Vみたいに、システムを動作させるに必要な機能の数をできるだけ小さくするのって難しいけど、完成品を見ると当たり前じゃんみたいな印象を受ける

**デフォルトの名無しさん** · 2022/07/23(土) 18:34:20.81

>>445
残念ながらスパナーとか普通に実装してるgoogleにおいてはあんまり価値のある能力ではないよ。

**デフォルトの名無しさん** · 2022/07/23(土) 19:04:05.94

ISO、C++標準化委員のグレイドン・ホアレ氏はC++0xの標準化過程で、後方互換性を削ぎ落せば理解しやすくなることに気が付く。
そして私的プロジェクトとして実装し始めた。
2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。

**デフォルトの名無しさん** · 2022/07/23(土) 19:21:14.26

C++標準化委員の人でもあったんか
それにしてもRustっていいネーミングだよな
なんかしっくりくる

**デフォルトの名無しさん** · 2022/07/23(土) 19:57:02.71

正直なところ一般的な単語とか1文字とかの言語名はやめて欲しいと思わなくもない。

**デフォルトの名無しさん** · 2022/07/23(土) 20:43:26.21

>>453
逆じゃね。自分たちで作ってるからこそアルゴリズム方面の知識の意味があるのでは

**デフォルトの名無しさん** · 2022/07/23(土) 21:05:19.84

>>454
Hoareはホーアかホアだと思うんだが
ホアレはどこの国の読み方？

**デフォルトの名無しさん** · 2022/07/23(土) 21:18:57.29

日本じゃね？

**デフォルトの名無しさん** · 2022/07/23(土) 21:28:49.17

>>456
昔は大変だったけど今時はグーグルさんもだいぶ賢くなって来たから〇言語や〇 langでいける

**デフォルトの名無しさん** · 2022/07/23(土) 22:37:12.56

>>454
>2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
2006年の間違いじゃない？

ちなみに>>451に書いてるReferenceルールやBorrow CheckerはGraydon時代にできたものじゃないよ