次世代言語24 Go Nim Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2022/03/22(火) 03:23:41.60

スレタイ以外の言語もok

前スレ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

**デフォルトの名無しさん** · 2022/03/25(金) 11:55:17.22

>>168
実行速度が求められたり、複雑さなのに安定性が求められるものに向いている気がする
口では何と言っていても実態では安定性にそれほど価値を置いてないケースも多々あるから

**デフォルトの名無しさん** · 2022/03/25(金) 11:58:21.38

>>170
NLL入ってからborrow checkerに怒られることはほとんどなくなったよ

>>172
単によく知らないから質問しただけなんだけど、
Nimは低レベルを扱いやすくする機能は特にないってことか
Cへとトランスパイルされるのは低レベルへの対応というよりも、対応プラットフォーム増やすことや性能稼ぐことが目的という理解で正しい？

**デフォルトの名無しさん** · 2022/03/25(金) 12:12:09.59

NimはDと同じようなイメージだな
C++からいろいろ便利にしましたって感じなんだけど、それを言うならC++20だって良くなってるし、わざわざ乗り換えるほどでもないよね、ってなりがち
Rustくらいの特徴が何があれば、多少面倒でも乗り換える人は出てくるんだろうけど

**デフォルトの名無しさん** · 2022/03/25(金) 12:12:46.01

>>174
以前のRustコンパイラはたしかに厳しすぎて吐くエラーも見にくかったけど
non lexical lifetime対応した今のRustコンパイラは普通に書いていれば困ることはなく
コンパイラの出すエラーも非常に見やすくて何が問題なのかすぐわかる上に
何を直すと良いかのアドバイスもあったりしてコンパイラ親切さトップ言語になったね

**デフォルトの名無しさん** · 2022/03/25(金) 12:28:24.72

>>175
Rustはbetter c じゃなくてsmart/simplified c++あたりだわな。
Rustよりマイルドなc++標準サブセット出ないかな。

**デフォルトの名無しさん** · 2022/03/25(金) 12:29:22.46

Rustとかどうでもいいよねｗ興味もないしそのうち消えてなくなるよｗ

**デフォルトの名無しさん** · 2022/03/25(金) 12:33:45.17

>>178
もちろんRustより良い言語が出てくればそうなるし良い言語が出てくるのは良いこと
しかし現状ではRustより良い言語がないし他に登場する気配もない

**デフォルトの名無しさん** · 2022/03/25(金) 13:20:25.76

Rustより良い言語が出て自然と消えるのは良いことだろ
ただ、今のところはRustは良い言語だし使いたいと思う

**デフォルトの名無しさん** · 2022/03/25(金) 14:31:56.50

Rust は、Linux カーネルの開発の一部で取り入れるよ、っていう話で初めて注目した。

**デフォルトの名無しさん** · 2022/03/25(金) 14:32:33.84

>>176
おかげでよりブラックボックス化したけどな。まともな文法定義がもうできなくなってる。

**デフォルトの名無しさん** · 2022/03/25(金) 15:05:30.24

>>182
例えばどういう問題が発生してるの？

**デフォルトの名無しさん** · 2022/03/25(金) 15:22:50.24

>>182
NLL導入で文法には影響ないと思うけど何のことが言いたいの？

**デフォルトの名無しさん** · 2022/03/25(金) 16:28:19.83

>>184
セマンティクスのことを言いたいんじゃないか？

**デフォルトの名無しさん** · 2022/03/25(金) 16:42:28.63

具体例を上げてないしレス乞食じゃないの？

**デフォルトの名無しさん** · 2022/03/25(金) 16:50:09.59

>>185
文法定義を気にする人がそんな変な用語の使い方するはずないと思う

**デフォルトの名無しさん** · 2022/03/25(金) 18:08:36.16

>>182
何もブラックボックス化していないし文法定義に変化はない
Rustを叩く人はなぜデタラメばかり言うのだろうか

**デフォルトの名無しさん** · 2022/03/25(金) 19:28:43.78

>>184 >>188
え？より厳密になってんじゃないの？

機能の安定化とNLLのバックポートを備えたRust 1.36
Rust 2015でNLLがサポートされたため、古いボローチェッカは間もなく言語から削除されることになる。この移行を安全に行なうために、新たなボローチェッカでは、古いボローチェッカでは受け入れられていたが、新たなボローチェッカでは違反になるコードに対して、警告を発するようになる予定だ。

**デフォルトの名無しさん** · 2022/03/25(金) 19:46:16.71

そろそろ次の次世代出てきませんか

**デフォルトの名無しさん** · 2022/03/25(金) 19:52:52.64

>>189
それは古いborrow checkerのバグでコンパイル通ってなかったコードがエラーなるということだと思う
基本的には新しいborrow checkerの方が制約は緩いはず

**デフォルトの名無しさん** · 2022/03/25(金) 19:53:32.69

>>191
バグでコンパイル通ってなかった、ではなく、バグでコンパイル通ってしまっていた、が正しい

**デフォルトの名無しさん** · 2022/03/25(金) 20:22:05.99

でもバクだろうと通らなくなるんだから文法変わってるという意見が正しいな、ごちゃごちゃ並べ立て言い訳してるみたいだけど

**デフォルトの名無しさん** · 2022/03/25(金) 20:27:31.26

>>193
文法じゃないでしょ

**デフォルトの名無しさん** · 2022/03/25(金) 20:29:27.44

文法ってのが構文+意味論みたいなのを指してるなら
NLL導入前後で構文は変わらず意味論は変わったから、まぁ全体としては変わってるでいいんじゃない？
それはそれとして文法定義ができないってのは意味不明だけど

**デフォルトの名無しさん** · 2022/03/25(金) 20:34:34.89

>>193
文法は一切変わっていない
大雑把に言うと
以前はコードの文字通りに追うだけで借用ライフタイムを無駄に広く取ってチェックしていた
だから厳しすぎて今では通る普通のコードが通らなかったりした
変更以降は実際に使われている状況を追うことで借用ライフタイムを実用の意味あるものとした
だからほとんどのケースで緩くなってプログラミングする上で困ることがなくなった

**デフォルトの名無しさん** · 2022/03/25(金) 20:56:18.04

>>189 で言われてるNLL導入でコンパイル通らなくなるcrateって
https://github.com/rust-lang/rust/issues/60680
で挙げられてるやつのことかな

壊れる是非はともかくcraterみたいな取り組みは他の言語もパクって欲しい

**デフォルトの名無しさん** · 2022/03/25(金) 20:58:59.81

>>196
フロー解析に頼るって信者的にどうなの？
あくまで型でチェックしてるのが美しいんじゃなかったのか

**デフォルトの名無しさん** · 2022/03/25(金) 21:02:27.36

>>196
ある２つの形式言語ＡＢで、同じ文章がＡで受理してＢで拒否するんだったら、そりゃ「ＡＢは文法が違う」としか言えんな。

まぁ、だからと言って言語自体を否定する類の話じゃないけど、Rustを神聖視するあまり横車を押そうとするのはアホに見えるからやめたほうがいいよ。

**デフォルトの名無しさん** · 2022/03/25(金) 21:14:19.83

>>197
crate.ioのこと？
ruby gemとかpython pip とかけっこう一般的な話だと思うけど、何か違うの？

**デフォルトの名無しさん** · 2022/03/25(金) 21:17:24.39

>>199
その程度で文法が変わったとは言わないと思う
その解釈だと今後もRustは文法がどんどん変わる計画となっている
例えばライフタイムについても現在stableでは通らないものがnightlyでは通るように更に緩くなっていくことが確定している
一方でeditionが変われば今まで通っていた記述がエラーとなるなど通らなくなることもある
Rustは今後もどんどん使いやすく向上していくよ

**デフォルトの名無しさん** · 2022/03/25(金) 21:18:41.95

バカだから他の言語より劣ること分かってないんだよｗ

**デフォルトの名無しさん** · 2022/03/25(金) 21:19:38.13

Rustっていうゴミ言語なんてどうでもいいよねｗ

**デフォルトの名無しさん** · 2022/03/25(金) 21:23:34.44

Rustプログラマーは給料上がっていくだろうね
そうすると人口も増えていく
パイソンもそうだったし

**デフォルトの名無しさん** · 2022/03/25(金) 21:23:43.31

>>201
最終的にライフタイムや借用を人間が一切明示しなくなってGCなしC#みたいになるのがゴールなの？
それでいいのか信者は

**デフォルトの名無しさん** · 2022/03/25(金) 21:24:25.90

>>201
通らなかったものが使えるようになるのはただの拡張だがその逆は破壊的変更。
後者がそう頻繁にあるとは思わんがな。

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

>>201
>その解釈だと今後もRustは文法がどんどん変わる計画となっている

当たり前だろ。
お前は何を言っているんだ？形式言語の文法を何だと考えているんだか。
そういうアホな主張をするからRust信者は狂信者扱いされるんだよ。

**デフォルトの名無しさん** · 2022/03/25(金) 21:28:33.82

>>205
まずは基礎知識を学習すべし
知識なく語るのは愚か

**デフォルトの名無しさん** · 2022/03/25(金) 21:34:20.09

>>198
せめてライフタイムとは何かを学ぼうよ
型チェックとは全く関係ない話だよ

**デフォルトの名無しさん** · 2022/03/25(金) 21:40:29.03

>>200
craterはcrates.ioの全クレートをコンパイルしてみてコンパイラのバージョンアップで壊れるやつがいないかどうかチェックする仕組みのこと
スクリプト言語だとチェックできるのが構文エラーくらいしかないからあまり意味はないかも

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

>>207
確かに言語の拡張も文法が変わったと言える
どのプログラミング言語も常に文法を変えながら拡張されていくのだろう

**デフォルトの名無しさん** · 2022/03/25(金) 22:14:57.99

>>205
意味が分からないな
コンパイラが正確に正誤を判定してくれるならそれが最善だろ

**デフォルトの名無しさん** · 2022/03/25(金) 22:16:06.05

>>182
>まともな文法定義がもうできなくなってる。
意味不明

**デフォルトの名無しさん** · 2022/03/25(金) 22:30:28.83

>>201
同じコードで通る/通らないが変わるのなら、それは普通は「文法の変更」という。
なぜなら、

Error: コード生成が出来ない
Warinig: コードは生成可能だが、普通はこんな事をする必要もないからバグだよね？

だから。ここをRustはおそらく(haskell信者が一時期言ってた)

・Rustのアプリにはバグがない。なぜなら、バグのあるコードは全てコンパイラが落とすから

をやりたいのだろう、通常は警告のところをエラーにしてる。
ただこれは一部馬鹿にとっては逆効果で、

・エラーがなければ全て良し

だと勘違いしてしまってるように見える。
（別人だが）フレームワークにドキュメントで禁止されてるコード食わせてドヤってる馬鹿とか、
>>98 もそう。今時のエディタだと文字列/正規表現リテラルは色が付くが、
エスケープを失敗するとコード全体がリテラルの色になる。いくら馬鹿でもこれを無視はしないだろ。
従う気があればエディタで『予定と違う場所に』色が付くだけで十分なんだよ。
本来は警告も無視せず、一つ一つ問題がないか確認するものだし。
その辺面倒くさがってエラーに一本化した結果、悪癖が付いてしまってる。

ただまあこれはいいとして、
Go(2009)/Docker(2013)だから、これはタイミング的にも「これで勝つる！」だったのだろう。
とはいえDockerは普通の人が組むアプリではないので他案件/構造も引き続き募集中だが、
結局Rust(2010)にはないのか？本当にメモリ安全な言語がなくて困ってる奴がいれば飛びついているはずで、
時期的には2014頃に何か出現しててもおかしくないのだが。
未だに何もないのなら、所詮は馬鹿向けC++で、ポシャる見通しの方が高いだろうよ。

**デフォルトの名無しさん** · 2022/03/25(金) 22:38:33.17

>>214はまたいつもの意味不明なことしか言えないキチガイだな

**デフォルトの名無しさん** · 2022/03/25(金) 22:39:20.33

Dockerのくだり分からん

**デフォルトの名無しさん** · 2022/03/25(金) 22:43:28.74

Ruby on Railsのようなキラーアプリ(ライブラリ)はRustにないのか、っていう話でしょ
そもそもRustはシステムプログラミング言語だし、そういう低レイヤーに縁がないエンジニアはこれからも使う可能性低いっしょ

**デフォルトの名無しさん** · 2022/03/25(金) 22:49:09.03

>>199
文法って言ったらシンタックスであってコンパイラはシンタックスだけをチェックしてるわけじゃないんだから
コンパイラが受理しないからと言って文法が違うとはならないでしょ

>>214
文法の変更って言ったら普通は例えばBNFが変わるとかそういう話でしょ

**デフォルトの名無しさん** · 2022/03/25(金) 22:49:43.62

>>214
君は書き込みをする前に二つの点を改善しなさい
一つ目は意味の分かる文章を書くこと
頭をゼロにして読み返してみればおかしなところに気付くはず
二つ目は批判したい対象についてもっと学習すること
妄想で話を進めるから意味不明と間違いが多い

**デフォルトの名無しさん** · 2022/03/25(金) 22:55:01.03

>>216
（スレ的に昔の話を混ぜ込んでわかりにくくなってたのならすまん）

90で言ったとおり、Dockerを組みたいのならGoは多分最適で、結果、
Go(2009)/Docker(2013)と順当な期間でデビューし、その界隈では広く使われるに至ってる。
Dockerのアイデアが先にあって偶々出てきたGoに飛びついたのか、
GoにインスパイアされてDockerの構造を思いついたのかは分からんが。

Rustが「他の言語では現実的に不可能な」レベルの得意分野があるのなら、
同様に、Rustが最適だ、と思えるアプリが既にあるか、開発中のはず。

俺は何度も言ってるが(C)を目指すべきだと思ってるので、（89参照)
その言語が得意とする構造等があれば、
俺が作りたいアプリにそれが含まれてたらその言語を使う、というだけ。
(言語の習得が目的ではない)

**デフォルトの名無しさん** · 2022/03/25(金) 23:09:22.77

>>220
前にもデタラメと意味不明なことを書いていた人だったのか
浅はかな知識ならびに自分勝手にこうでなければならないと決めつけた話を元に暴走しているためにデタラメと意味不明になっている

**デフォルトの名無しさん** · 2022/03/25(金) 23:13:11.92

>>194
顔真っ赤で内容ゼロの反論してきて不覚にもワロタｗ

**デフォルトの名無しさん** · 2022/03/25(金) 23:17:57.63

>>218
文法=構文って思ってるのは分かるけど皆がそうとは限らないよ
自分だったら構文と意味論の区別が問題になるようなこのケースで
文法なんてあいまいな用語は使わないけど
強いて言うなら構文と意味論は両方文法に含まれると思っている

**デフォルトの名無しさん** · 2022/03/25(金) 23:20:42.33

ほとんどが単発IDの自演だぞｗ

**デフォルトの名無しさん** · 2022/03/25(金) 23:20:59.36

>>193
いわゆる普通に文法を意味するところのsyntaxは変わっていない

**デフォルトの名無しさん** · 2022/03/25(金) 23:25:23.45

>>223
カジュアルに文法って言葉使ってるなら自分も気にしないんだけど
>>182 が文法定義って言ってたり
>>199 で形式言語って言ってたりして
それどういう意味で言ってるの？ってのが気になってつっかかってしまった

**デフォルトの名無しさん** · 2022/03/25(金) 23:26:20.50

>>220
実際、Rustの最高のターゲットはシステムプログラミングだから、そういう意味ではCと似ている
だからLinuxカーネル、Android OSみたいな巨大プロジェクトでも採用されるまでに至った

その他の有名事例はFirefoxは常識として、Dropboxのファイルストレージ、DiscordのStateサーバ、Figmaのmultiplayerサーバ、AWSのS3/CloudFront/Bottlerocketとかかな

https://www.rust-lang.org/production/users
細かく挙げればここにあるようにいくらでもあるけど、眺めてみると件数としてはhigh performanceを求めて採用する事例が多いかな

**デフォルトの名無しさん** · 2022/03/25(金) 23:32:52.17

>>218
> コンパイラが受理しないからと言って文法が違うとはならないでしょ
少なくともCではほぼ同義だし、他言語でもそんなもんだと思うけど。

Cの場合は「自分の足を撃て」で躊躇なく撃つ言語なので、エラーは、

・シンタックスエラー
・記憶領域(変数のサイズ）等が確定的でなく、オブジェクトコードに出来ない
　(これはC特有で、要はソースを食わせる順が間違ってたりしててサイズを知らない物が存在した場合。
　2パスコンパイルをしてる他言語では発生しない)

だから、他言語でもコンパイルが通らない＝文法エラー、という認識が普通だと思うよ。

Rustの場合は他言語だと警告のところをエラーにしてるから話がおかしくなる。
元々全部警告にしてたら、誰も文法が変わったとは認識しないだろうよ。
だけどそういうコードの存在自体を許さないのだから、エラーにしているわけで。

元々コンパイラは色々情報持ってるんだから、気づいたおかしなところも吐いてくれ＝警告で、
なら警告チェックを厳しくしてバグ検出出来るんじゃね？＝リンターなわけ。
だから簡易リント機能は元々コンパイラにあって、さらにそれを強化して専用にした物がリンターと呼ばれる。

で、ここで「文法が変わった」かどうかを争ってても意味ないと思うが。
他言語出身者なら、同じコードで通る/通らないが変わるのなら、「文法が変わった」と認識するし、
コンパイラ屋なら、構文解釈に変更なくリント機能だけが強化/緩和されたのなら、「文法は変わってない」と言い張るだろうさ。
(実際にリント機能部分だけの変更なのかは知らんが）

**デフォルトの名無しさん** · 2022/03/25(金) 23:36:20.64

例えば自分はWebでReact/Next.jsを使っているんだけど
そこで使われているトランスパイラがRust製のswcへ変わったよ
色んな分野で代替する新たな良いものが出てくるとRust製が多いね

**デフォルトの名無しさん** · 2022/03/25(金) 23:41:25.24

>>228
Cみたいなシンタックスにセマンティクスが浸食してる言語例に出すあたりマジで何も分かってないんですね

それにCのエラーだってシンタックスエラー以外に型エラーとかいろいろあるでしょ

とにかく文法という言葉の使い方が独特すぎるからあなたの言うところの文法とは何かをちゃんと定義して欲しい
コンパイル時にエラーと判断されうるものは全て文法という理解で良い？
リンク時エラーも文法エラー？

**デフォルトの名無しさん** · 2022/03/25(金) 23:57:36.32

>>227
> Linuxカーネル
それ前も言ったけど、forkしただけで、採用されてないよ。

> Firefox
結果シェアはズタボロに落ちて最早ゴミ。対応面倒で切られてる始末だろ。

> Discord
ブログにあった件なら、生存オブジェクトが大量にあるのにGC言語(Go）を使った点が間違ってる。
ただ、Go側で「GC非対象ヒープ」を（自前ででも）用意すれば済んだ話。
あれで言語移行したのはただの趣味だと思うよ。

他は知らんが、Goでも採用実績なんていくらでもあるし、Rustよりは多いと思うよ。
それを全部見るのは無理なので、折角詳しくて布教したがってる連中が居るのだから聞いてみるか、というわけ。
Goの連中はピンポイントでDockerを出してきたし、納得するものでもある。
Rustにはねえのか？という話。
(ただしDockerと同様の物を俺が組む事は多分無いので、他案件/構造も募集）

>>229
本当に「この言語じゃないと現実的に無理」なら、「書き換え」ではなく「新分野を開拓」出来るはずだ。
Dockerの構造は「新規」だよ。

**デフォルトの名無しさん** · 2022/03/26(土) 00:05:21.48

>>231
そんな言いがかりみたいなでたらめ並べてうれしいのかね
それともそれら次々とRustで置き換わっていく恐怖に怯えての言動かね

**デフォルトの名無しさん** · 2022/03/26(土) 00:18:45.11

ドッカーは確かにgoで書かれているが、作ったイメージをコンテナとして動かすランタイムはRustで書かれてたりするのだよね
抽象化されてることすら知らなそうけど

**デフォルトの名無しさん** · 2022/03/26(土) 00:19:28.54

>>231
そんなにGo使いたいならRustのことを気にせずGo使ってどうぞ
Goも良い言語だから安心してね

**デフォルトの名無しさん** · 2022/03/26(土) 00:22:51.04

実際、Dockerほどの人気があるプロダクトはめったに生まれないからね

**デフォルトの名無しさん** · 2022/03/26(土) 00:27:20.02

ランタイムあるからGoだけではコンテナランタイム作れないって聞いたんだけど本当？

**デフォルトの名無しさん** · 2022/03/26(土) 00:30:14.44

>>232
> 次々とRustで置き換わっていく恐怖に怯えての言動かね
自意識過剰すぎ。

というか、俺はお前らがそこまで言語に拘る意味が分からない。
それが適してたらそれを使うだけ、だろ。

俺がその言語作ったわけでもないし、その言語を使えば俺が偉くなるわけでもないし。
お前が修得出来たのなら、俺も修得出来るし、他の人も同様に修得出来るだけ。
修得で無理に差別化しようとするからおかしな事になるのだと思うが。

>>234
Goは味見して糞言語だったからもう使う気はないがな。
同じ事を何度も書かせて、しかも、それを悪いとしてない事が無理だ。
俺が切れたのはJSONのタグ記述だが。
（ああGo的には自動生成出来るような仕組みがあるから問題ないんだ！としている事は知ってる）

**デフォルトの名無しさん** · 2022/03/26(土) 00:33:29.42

Dockerコンテナランタイムは色々あってもちろんRust製もある

**デフォルトの名無しさん** · 2022/03/26(土) 00:35:20.61

>>237
じゃあ自分の使いたい言語を使っていいよ
こんなスレに文句を書きに来てるぐらいだから、本当はRustのことが気になって気になってしょうがないんだろうけど

**デフォルトの名無しさん** · 2022/03/26(土) 00:43:54.51

dockerのどの辺がRustで書かれてんの？？？ｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/26(土) 00:44:14.12

>>237の人は前スレから一貫していて
Goに対してもクソ言動と批判しつつ
Rustを叩くための棍棒としてGoを使っている
C#については絶賛

**デフォルトの名無しさん** · 2022/03/26(土) 00:44:35.30

>>239
リスカブス乙
俺は定期的に他言語情報をクロールしてるだけだよ。

ただNimがCソースを吐くとは知らなかったのでちょっと気になってるが。（使うとは言ってない）

**デフォルトの名無しさん** · 2022/03/26(土) 00:51:02.81

>>241
> C#については絶賛
してねえだろ。
実際GUIは糞で、JSの方が数段マシ。そりゃ世の中のGUIがHTMLになるのも納得だよ。
GUIのメインスレッド＋サブスレッドの構造もよろしくないと思ってる。
（ここら辺も既に書いたが）

ただな、どの言語にも一長一短はあるんだよ。みんな色々考えて、改善してきてるわけだから。
だから、○○言語最強！ではなくて、言語特性を理解した上で選択、としたいわけ。

**デフォルトの名無しさん** · 2022/03/26(土) 00:54:11.51

>>241
それに対してガイガー君がC#を叩く構図だね
もちろんそれ以外の時はガイガー君はRust叩き
二人ともロクでなし

**デフォルトの名無しさん** · 2022/03/26(土) 00:54:44.30

Firefoxが墜ちたのは旧エクステンションを切ったからで…(またこの話？)

**デフォルトの名無しさん** · 2022/03/26(土) 00:58:24.45

>>242
そういうのが気になるなら vlang もいいかもね

**デフォルトの名無しさん** · 2022/03/26(土) 01:01:58.12

>>243
JavaScriptも良い言語だけど
型が弱いしTypeScriptは中途半端だから
最近Rustに移ったよ
もちろんサーバーサイドだけでなくブラウザサイドもRustでWASM
WASM⇔JavaScriptのオーバヘッドは誤差範囲とわかり実用的

**デフォルトの名無しさん** · 2022/03/26(土) 01:25:19.73

俺はC#を叩いたことは一度もないｗ
間違いを指摘し続けてただけだぞｗ
Rustは変なビジネスチャンスばかり狙った信者が嘘八百並べ立ててるから、すごい怪しげな新興宗教になってるｗ

**デフォルトの名無しさん** · 2022/03/26(土) 01:29:08.29

半年くらい前までは俺も静かにRustの普及を望んでたんだけどねｗ
今はもう・・・やばい印象しか受けない

**デフォルトの名無しさん** · 2022/03/26(土) 01:57:44.71

>>249
ガイガー君は嘘つきだな
Rustの配列とスライスの違いすら知らないことがこのまえ発覚したことで全てバレた
Rust初心者でも知っていることなのにな

**デフォルトの名無しさん** · 2022/03/26(土) 02:31:08.59

[T]がarrayで&[T]がスライスだと間違って覚えてただけだろｗ原因はarrayを初期化以外で使ってなかったからってちゃんと書いたｗ
多分Rustをやってる期間は多分お前よりはるかに長いよｗ

**デフォルトの名無しさん** · 2022/03/26(土) 03:04:03.73

>>251
そんな間違いする人を初めて見た
正解は[T]がスライスで&はその参照
&が参照を意味するだけにすぎないことも知らない時点でRustを知らないと確定

**デフォルトの名無しさん** · 2022/03/26(土) 03:36:58.66

ないないｗきっといっぱいいるｗこんな説明だからｗ
https://doc.rust-lang.org/book/ch04-03-slices.html

**デフォルトの名無しさん** · 2022/03/26(土) 04:31:22.21

>>251
> [T]がarrayで&[T]がスライスだと間違って覚えてただけだろｗ

酷くおバカな間違いだな
Rustを使ったことがないからそういう勘違いをしてしまう
ちゃんと公式ドキュメントの各1行目を読もうぜ

配列
https://doc.rust-lang.org/std/primitive.array.html
A fixed-size array, denoted [T; N], for the element type, T, and the non-negative compile-time constant size, N.

スライス
https://doc.rust-lang.org/std/primitive.slice.html
A dynamically-sized view into a contiguous sequence, [T].

**デフォルトの名無しさん** · 2022/03/26(土) 06:43:20.01

それはAPIリファレンスだろｗ

**デフォルトの名無しさん** · 2022/03/26(土) 07:50:27.56

>>62
それ、C/C++が全く出来ないレベルじゃん。メモリやポインターの理解が出来てないから実行時デバッグに時間が掛かる。普通は処理を書いたら動くことを確認するだけで済む。

**デフォルトの名無しさん** · 2022/03/26(土) 07:54:07.76

>>251
> 多分Rustをやってる期間は多分お前よりはるかに長いよｗ

はるかに長い期間やっててそれでは知能が低いです

**デフォルトの名無しさん** · 2022/03/26(土) 08:12:28.41

>>256
それはそういう話じゃないと思うぜ
C++とRustの両方使いこなせると分かるが
低レベルであるポインタアクセスがRustでは無くなり抽象化された参照アクセスとなり
安全でないアクセスがコンパイル時点で排除されるためその種の実行時デバッグが無くなる
その件だと思われる

**デフォルトの名無しさん** · 2022/03/26(土) 08:24:24.55

>>257
ただの記憶違いに知能は関係ないｗ実際それで困ったことがないからなｗ

**デフォルトの名無しさん** · 2022/03/26(土) 08:47:16.92

>>259
その件は君が嘘をついていると明確になっている
その件の書き込みを見ると君はarrayとsliceを勘違いしただけでなく関数からarrayで返すと明言している
一方でその関数は返り型宣言で必ず[T; N]が現れる
このNは定数であるからさらに宣言することになりarrayでNの存在を忘れる人はいない
しかし君はarrayを[T]だと間違えて覚えていたわけだから矛盾する
君はRustのコードを書いたことがないという結論となる

**デフォルトの名無しさん** · 2022/03/26(土) 09:14:29.48

何を勘違いしちゃったのか知らないけど、こう書いてあるんだけどｗ
「arrayは定義はあるんだけど、今まで初期化にしか使わなかったから、使わなすぎて間違って覚えてたｗ」

**デフォルトの名無しさん** · 2022/03/26(土) 09:23:18.54

>>260
正確にはガイガー君はsliceで受けてArrayで返すと言っている
この発言の時点でガイガー君はRustを知らないと証拠

動的サイズのスライスで受けて固定サイズの配列を返すのは不可能だからだ
Nが判明しないと配列で返せないが実行時になるまでスライスの長さは不明
この点からもガイガー君はRustを知らない

**デフォルトの名無しさん** · 2022/03/26(土) 09:51:30.12

ニュアンスが違うんだよｗ
「それは俺のポリシーとして、可能ならVecを返すならVecを受けたいだけｗ
今回のケースではメリットとかないよｗ
同様にsliceで受けたらArrayで返したいし、iteratorを受けたらiteratorを返したいｗ」
slice->&[T]
array->[T]

**デフォルトの名無しさん** · 2022/03/26(土) 09:55:08.60

はるかに長い期間やってるのにこの有様
子供の遊びかな？

**デフォルトの名無しさん** · 2022/03/26(土) 09:56:51.30

実際のロジック書くのに使ってたのVecだもんｗ

**デフォルトの名無しさん** · 2022/03/26(土) 10:02:36.56

結局TypeScriptがどの場においても最強って言いたいの？

**デフォルトの名無しさん** · 2022/03/26(土) 10:18:06.61

間違ってても普通に説明すりゃいいのにお互いに煽りながら主張しあってるから、くだらない議論が余計に長引く

**デフォルトの名無しさん** · 2022/03/26(土) 10:39:18.75

TypeScriptさいきょー

**デフォルトの名無しさん** · 2022/03/26(土) 10:44:45.97

>>263
Vecを返す関数は原則引数の型はVecにしたいということ？
敢えてそうする理由ってなにかあるの？

**デフォルトの名無しさん** · 2022/03/26(土) 11:44:23.82

goとtypescriptどっちかを捨てればいいのに

tcshやrubyを捨てるみたいに

**デフォルトの名無しさん** · 2022/03/26(土) 12:29:34.61

新しい言語はどれも配列の宣言があまりきれいじゃない気がする

Cなどの型名変数名[要素数]だと何か都合が悪いのだろうか
それともやってる感を出すために変えてるの？

**デフォルトの名無しさん** · 2022/03/26(土) 12:37:22.57

>>271
固定長で問題ないならそれが一番いいが、
大体において固定長である事自体がものすごく不便だから。