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

**デフォルトの名無しさん** · 2022/04/17(日) 17:52:35.38

スレタイ（順番はRedMonk準拠）以外の言語もok

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

**デフォルトの名無しさん** · 2022/04/18(月) 14:49:14.45

「プログラミング言語によるセマンティクスと最終的に生成されるコードは全く無関係」そんな訳ない、RustはLLVMのIRを前提に
コードが吐かれるし、コードのリンケージをアトリビュート指定できる。C言語だって同様だし、むしろ、ハードウェアよりの低レベルな
システムプログラミングが可能な言語であれば、生成されるバイナリが厳密に言語の「セマンティック」を決める。
例えば今どきのCPUには分岐予測命令があるが、これに対応するstd::intrinsics::likelyのような分岐予測にヒントを与える、
セマンティクスはCPUがサポートされていれば100%生成されるバイナリがそうなる事を望む。無関係などありえない

**デフォルトの名無しさん** · 2022/04/18(月) 14:53:46.39

>>47
Rustをgccと組み合わせて動かす試みあるから
LLVM前提ではないのでは？

**デフォルトの名無しさん** · 2022/04/18(月) 14:57:34.06

>>45
その言語のセマンティクスとしてimmutableで渡すケースでも
値をポインタで渡すか値自体を渡すかはどちらでも構わないから言語のセマンティクスとは別問題

もっと顕著にわかりやすい例
構造体を一つ返す関数があったとする
小さい構造体なら値を返すだろうが
大きな構造体なら領域を用意してそこに書き込んでそのポインタを返すかもしれない
あるいは関数を呼ぶ側が領域を用意してそのポインタを裏引数として渡してそこへ返す値を書き込むかもしれない
このように3種類考えられるが呼ぶ側と呼ばれる側で一貫していれば目的を果たす
プログラマーはその生成コードが3種類のどれになるかを把握する必要はない
つまりそこで明白にレイヤーが分離される

**デフォルトの名無しさん** · 2022/04/18(月) 14:59:44.25

>>33
もし文字列のベクタに文字列を追加する関数があったとき文字列が参照渡しでその関数が実行された後もその文字列が読まれていると、その関数は文字列をmoveすることができずコピーしなくてはならなくなるからじゃないかな。
メモリコピーは遅いから絶対に許さない人にはデフォルトがmoveのほうがいいのかも。

**デフォルトの名無しさん** · 2022/04/18(月) 15:02:16.44

>>48
現状はIR前提でしょ、完成してない未来のものを持ち出すのであれば何とでもいえる。というか上で言ってる本題とはずれる
そんなところに食いついて来てしょーもないわ

**デフォルトの名無しさん** · 2022/04/18(月) 15:06:33.88

>>47
Rustでもセマンティクスと生成コードは独立だよ
例えば>>49の関数が構造体を返す例
生成コードは言語仕様で定められていないしあなたも方法を答えられないでしょう
実際にRustで大きな構造体を返すと所有権を活用して驚きの最適化したコードを生成するよ

**デフォルトの名無しさん** · 2022/04/18(月) 15:10:05.22

>>51
開発中で完成してないとは言っても実行バイナリの
生成もできないという状態ではないから
あなたの話とは違うというか
あなたの主張は間違ってるという例になってますよね

**デフォルトの名無しさん** · 2022/04/18(月) 15:19:05.87

>>52
「生成コードは言語仕様で定められていないしあなたも方法を答えられないでしょう」
え？RustにもちゃんとFFIなどextern "C" {}ブロックがあるでしょ？生成コードは言語仕様で定められているし、このようなデータの受け渡しは
参照や可変参照の制限、ボローチェックなどがOFFになる。C言語やD言語やNimも同様でしょ、これが出来ない言語はシステムプランニングが
できる言語とは言えない。
「Rustで大きな構造体を返すと所有権を活用して驚きの最適化したコード」
どのような驚きのバイナリを生成しようと、例えばゲームエンジンのUnityなどでデータを渡す場合に所有権をRust側で保持したままのような
コードではUnityなどでメモリー管理されるので問題が出る。だから呼び出し間でどのようにデータを受け渡すか当然指定できる

**デフォルトの名無しさん** · 2022/04/18(月) 15:20:54.20

>>53
何を言いたいのか1つも分かりません。。。あなたの勝ちでゴリラのようにマウンティングをしてください、どうぞ

**デフォルトの名無しさん** · 2022/04/18(月) 15:33:12.79

>>54
FFIを理解していないアホですか？
例えばそのextern "C"した時のみC言語の受け渡しインタフェースに従うだけ
どの言語でもFFI使わなければ各言語が自由自在の方法を取る

**デフォルトの名無しさん** · 2022/04/18(月) 15:38:01.47

>>39
引数のサイズが一定サイズ以上だとポインタで渡す

それはそれで他者が変更したときの挙動が変わるから怖いよね。
特に並列作業時。

>>50
const参照をデフォルトにしたら、そのあたりは引き渡し時にmoveを明記するんだろうね。あるいはCOWで実装するか。

もしかしたらRustに「権利を持つオーナーは極力少なく・小さくする」というポリシーでもあるのかな？

**デフォルトの名無しさん** · 2022/04/18(月) 15:47:16.94

>>56
さっきからID変えて絡んでこなくてよいですよ、「extern "C"した時のみC言語の受け渡しインタフェースに従う」セマンティクスと生成コードが決まりますよね。
アホと言えば誰もしもが感情的になるわけではないです。FFI使わなければなんて話をしていませんし、「プログラミング言語によるセマンティクスと最終的に
生成されるコードは全く無関係」という理想論のような現実を知らないコンピューターサイエンス学科の学生のような言葉を否定してるだけです。

**デフォルトの名無しさん** · 2022/04/18(月) 15:50:35.11

>>57
デフォルトで引数は不変が前提なので引数の型の定義を変更してポインタ渡しになったとしても基本的には挙動は変化しない。
引数のアドレスをとってれば挙動が変化するかもしれないけど、Nim言語は明示的に変数のアドレスをとることは危険な行為で自己責任でやれってことになってるから。

**デフォルトの名無しさん** · 2022/04/18(月) 16:01:25.50

>>58
普通のプログラムでC言語FFIなんて使わないです、そして、その特殊ケースはどうでもよい話です
一般的に言語が定めるセマンティクスと生成コードは別階層なので独立しています

**デフォルトの名無しさん** · 2022/04/18(月) 16:06:01.92

>>57
静的型付けで型サイズが定まる普通の言語ならば大丈夫
引数や返り値がポインタ渡しになるか値直接渡しになるか
型サイズ次第で変化しても一貫していれば構わない

**デフォルトの名無しさん** · 2022/04/18(月) 16:44:49.00

>>57
> それはそれで他者が変更したときの挙動が変わるから怖いよね。
> 特に並列作業時。
横レスだけど、明らかにそういう話じゃない

**デフォルトの名無しさん** · 2022/04/18(月) 17:00:59.75

普通にカーネルのシステムコールするだけでC言語のFFI使ってますよ、DBアクセスするにもSQLiteでもMySQLでもPostgresqlでも使用してますし
TCP/IPスタックにアクセスするにもFFI使ってます、もしや特殊なのはあなたなのでは？ガン無視されて独立しているのは、そんな詰まらないことで
言い張るあなたなのでは？

**デフォルトの名無しさん** · 2022/04/18(月) 17:04:14.33

Kotlinみたいな出力先がjvmとjsとネイティブがあるのは
このひとの中でどう解釈するんだろ

**デフォルトの名無しさん** · 2022/04/18(月) 17:15:12.72

>>63
そんなことは誰でも知っているがこの流れとは無関係な話
各FFIはそのFFIの指定に従う
逆に言えば各言語の普通のコードではFFIなんて関係ないので各言語で完全に自由
だから引き数や戻り値のサイズに拠ってポインタ渡しか否か変わる言語もある

プログラマーはそれらを知らなくてもプログラミングできる
各言語が定めるセマンティクスだけ理解すればプログラミングできる
つまりセマンティクスと生成コードは完全に独立した別階層であり無関係

**デフォルトの名無しさん** · 2022/04/18(月) 17:19:02.78

この話の終着点どこ？
「お前はアホだから黙れ」が立証できれば満足するの？

**デフォルトの名無しさん** · 2022/04/18(月) 17:22:10.87

>>33
変数の代入がmoveなのに関数引数の時だけ参照になるのは紛らわしくない？

**デフォルトの名無しさん** · 2022/04/18(月) 17:33:30.39

>>59
あ、不変前提ね。勘違いしてました。

>>67
変数もデフォルトで不変借用にする、とか。戻り値の受けが面倒臭くなりそうだけど。

**デフォルトの名無しさん** · 2022/04/18(月) 17:41:53.44

>>68
Cの(ポインタ)参照が前置＆だから
Rustの(借用)参照も前置＆にした現状仕様がわかりやすいと思うけど、なぜ変えたいの？

**デフォルトの名無しさん** · 2022/04/18(月) 17:58:50.26

>>68
変数の代入をデフォルトで参照にするとmutが絡んできたときにborrow checker周りでとてつもなく面倒になりそうな気がする

**デフォルトの名無しさん** · 2022/04/18(月) 21:11:14.78

rustはライフタイム周りが途方もなく汚く見える
ウンコに触れたくない

**デフォルトの名無しさん** · 2022/04/18(月) 21:16:17.21

Rust「エラーには回復可能なエラーと回復不可能なエラーがあってResult<T, E>を使って~(長文)」
エンジニア「TとEって何だよ」「"?"って何?」「Box<dyn Error>って何?」

Golang「ほぼ
if err != nil {
panic(err)
}
でいい」
エンジニア「そうだったのか！」「やっと理解できた！」「Goって美しい」

何も言い返せんかったは・・・

**デフォルトの名無しさん** · 2022/04/18(月) 21:19:09.66

twitterでイキってるバカをそんなに晒すなよ。

**デフォルトの名無しさん** · 2022/04/18(月) 21:22:52.28

なおイキッテルのはRUSTERのもよう
ＧＯに完全敗北してどんな気持ち？

**デフォルトの名無しさん** · 2022/04/18(月) 21:26:10.80

null安全じゃない言語とかこのご時世にあるんですね

**デフォルトの名無しさん** · 2022/04/18(月) 21:39:04.08

スレタイの言語でも
Goとかnilチェックするコードを書き忘れてもコンパイルエラー出ないね
安全じゃない言語多すぎ

**デフォルトの名無しさん** · 2022/04/18(月) 21:42:30.77

GOはポイント使わなければ安全だぞ
ただし初期値に０と””が入る

**デフォルトの名無しさん** · 2022/04/18(月) 22:25:39.31

>>77
このif文を書き忘れたらコンパイルエラーになるの？

>>72
> if err != nil {

**デフォルトの名無しさん** · 2022/04/18(月) 22:30:25.57

>>74
これってgoありがたがる人を馬鹿にしたツイートじゃないの？

**デフォルトの名無しさん** · 2022/04/18(月) 22:44:34.76

Goはnil安全ではない
if err != nil {を書き忘れたり
return nil, nilしちゃっていると死ぬ

nil以外にも存在しない時の値で死ぬ
例えばstring.Index()は未発見時に-1を返す
返り値が-1かどうかチェック忘れてもコンパイルエラーとならない
そのまま-1を使ってしまい実行時に死ぬ

いずれのケースもRustではコンパイルエラーとなるため安全
Goは危険だらけ

**デフォルトの名無しさん** · 2022/04/18(月) 22:55:48.31

分かりにくい人「円周率は3.141592...と無限に続く数字で、よく近似の3.14が使われます。」
視聴者「何で3桁なの？」「2の後は何なんだよ」「近似って何？」

分かりやすい人「円周率って色々言われてるけど、実は3なんです！」
視聴者「そうだったのか！」「やっと理解できた！」「数学って美しい」

https://twitter.com/zugaaanzubababa/status/1506569845693100035
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2022/04/18(月) 23:02:13.65

Goでは「値が存在しないこと」を安全に表す方法がないことが敗因
RustではOption<T>型のNoneで安全に表せるところ

**デフォルトの名無しさん** · 2022/04/19(火) 00:46:26.38

なおシェアはＧＯが圧勝したもよう
ＲＵＳＴボーイズは一生夢見て低賃金でこき使われる童貞野郎

**デフォルトの名無しさん** · 2022/04/19(火) 01:34:09.77

goはCがシンプルで使いやすいと思う人向けの言語じゃないかと思う

**デフォルトの名無しさん** · 2022/04/19(火) 01:36:19.32

言語機能をモリモリにしたい誘惑に抗ってランタイムを充実させるという判断できる自制心はすごいと思う

**デフォルトの名無しさん** · 2022/04/19(火) 01:53:00.90

Ruby 3.0 のJIT は、MJIT で、
Ruby VM のバイト(中間)コードを、C コードに変換してから、
Cコンパイラでネイティブコードに変換していた

Ruby 3.1 のJIT は、YJIT で、
バイトコードから直接ネイティブコードに変換する。
ただし、x86_64 のみに対応

条件分岐があっても、10回実行した分岐だけを変換する。
実行されない分岐は変換しない

遅延変換・Lazy Basic Block Versioning（LBBV）

これで、Rails のプロジェクトが、20% ほど速くなったらしい

**デフォルトの名無しさん** · 2022/04/19(火) 07:43:43.07

ゴミが20%早くなかったからってどうしたってゆうね

**デフォルトの名無しさん** · 2022/04/19(火) 07:46:59.67

>>81
今さらゆとり

**デフォルトの名無しさん** · 2022/04/19(火) 07:51:59.99

>>87
でもRuby on railsってまだまだ使われてるよね？
有名どころでも、クックパッド、Airbnb、Gunosy、クラウドワークス、
食べログ、価格.com、Twitter、 Hulu、 GitHub

**デフォルトの名無しさん** · 2022/04/19(火) 08:03:56.92

>>81
偽物を「実は」という詐欺師。

**デフォルトの名無しさん** · 2022/04/19(火) 09:17:26.14

>>89
大規模railsを別言語で書き直しましたという
ニュースは時々出てくるけど逆は聞かないからなあ…

**デフォルトの名無しさん** · 2022/04/19(火) 09:29:29.07

>>89
業界や会社によってはCOBOLだって使われてる。
いったんそれでシステム組んじまったら中々移行は出来んもんだよ。

**デフォルトの名無しさん** · 2022/04/19(火) 09:35:08.80

>>80 >>82
Goはなぜそんな危険な言語仕様にしたの？

**デフォルトの名無しさん** · 2022/04/19(火) 10:22:52.12

R○byは業界のSPA移行とPythonブームによって思いのほか綺麗に消えてくれたのは良かった
まあPHPなんかに比べたらまだ「恥を知る」人間が多かったんだろうね

**デフォルトの名無しさん** · 2022/04/19(火) 11:21:50.97

>>94
PHPユーザに失礼なやつだな

お前あれだろ？
刺し身に直接わさびを付けるタイプだろ。醤油でわさびをとかさないで刺し身につけて食べてね？どうよ？

**デフォルトの名無しさん** · 2022/04/19(火) 12:34:56.06

>>94
言語マニアならpythonよりRubyの方がマシだろ。Pythonみたいにメソッドと関数が混在するのは書いててキモい。
python4でNim方式を採用してほしいわ。

**デフォルトの名無しさん** · 2022/04/19(火) 12:39:13.85

もちろんプログラム記述方式としてはPythonは最悪
あれが普及するのは害悪しかない

**デフォルトの名無しさん** · 2022/04/19(火) 13:49:45.55

>>95
直接わさびを口に運び刺身を投入して咀嚼した後に醤油を飲むタイプです

PHPユーザに対し失礼な発言は謝罪して撤回させていただきます。この度は申し訳ございませんでした。

**デフォルトの名無しさん** · 2022/04/19(火) 14:55:17.88

インデントでスコープ区切るのあんまり好きじゃない

**デフォルトの名無しさん** · 2022/04/19(火) 16:35:48.82

Haskellもインデントでスコープを区切ってた気がするけど一応ブレースでくくることもできるんだっけ

**デフォルトの名無しさん** · 2022/04/19(火) 18:18:04.08

>>98
人類最底辺のゴミPHPoorに謝罪など必要ない
奴らに必要なのは死あるのみ

**デフォルトの名無しさん** · 2022/04/19(火) 18:22:33.15

PHP使う人ってなんであんなアヘアヘ君ばかりなの？昔からああなの？

**デフォルトの名無しさん** · 2022/04/19(火) 22:14:20.79

>>96
けっこう同意。

**デフォルトの名無しさん** · 2022/04/19(火) 22:34:55.70

>>102
障害者手帳持ちでも書けるとガイジを集めたから
ガイジが作ってガイジが保守して、真人間は近寄らないか万一深淵を覗いてもすぐに逃げるから
ガイジだけが残った
それがPoopHPoor

**デフォルトの名無しさん** · 2022/04/19(火) 22:35:00.77

言語の良し悪しと普及率はあんまり関係ないってことだな

**デフォルトの名無しさん** · 2022/04/19(火) 23:10:14.27

良し悪しは文法だけでは決まらないしね
全部作り直すとかできないから、まず既存資産との互換性とかがめちゃくちゃ重要だしなあ

**デフォルトの名無しさん** · 2022/04/19(火) 23:14:51.60

Haskellはとてもいい言語だと思うけど、まあ今後も広くは普及しないだろうね

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

Java(8以前)とPHPとVB.NETは案件も人材もロクなのにあたったことないし関わりたくない

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

障害者雇用枠だししゃーない

**デフォルトの名無しさん** · 2022/04/20(水) 13:03:13.18

小一時間でゲームをつくる──7つの定番ゲームのプログラミングを体験 (WEB+DB PRESS plus)
https://www.あmazon.co.jp/dp/4297127458

この本面白いね。
コンソールに出すアスキーアートだけでゲームを作るところと最小限の工程ごとに動作確認するところがユニークだ。

誰かこのなかのどれかのゲームをGoやRustに移植してgithubあたりにアップしてくれないか？
その出来栄えでその言語の優劣を競うというのはどうだろうか？

**デフォルトの名無しさん** · 2022/04/20(水) 15:11:07.62

コード書けない奴が何の優劣を語るんだ？
LOC？

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

>>110
urlミスってるよ

**デフォルトの名無しさん** · 2022/04/20(水) 16:19:25.49

コードが書けないやつだからこそnull安全なんてほとんど誰もありがたかってない事を上のように一生懸命言い出す

**デフォルトの名無しさん** · 2022/04/20(水) 16:51:22.63

>>113
これだからGo信者は… 本当に現代人？

**デフォルトの名無しさん** · 2022/04/21(木) 11:50:52.34

　　　　　　　　　／:|.　　　　　　　　　　　　　　／:|
　　　　　　　／　 .:::|　　　　　　　　　　　／　 :::|
　　　　　　　 |　　...:::::|　　　　　　　　　　/u　　::::|
　　　　　　　i　　ﾉ (　￣￣⌒ﾞﾞ^――／　　　::::::::|
　　　　　　/＿,, ⌒　　u　　 . _　　　　　　　 ::::::::::::＼
　　　　　／　＼＼ﾞ.ｌ | 　/ ::／／￣●￣￣/　　::::::::＼
　　　　　|●　::::::|　 . | | / ::::　/　　　::::::::::／／u　　:::::::＼
　　　　/i,.＼_:::::::|　　　u:::::　/ 　　:::::::::／／　　　　　:::::::::＼
　　　　/　＼( (＼|.　 ::::::.　　 /／￣））　　　　　　　　　:::::::::＼　　
　　　 /　u　 ) )＿　^　 ^　￣￣　,,､（（　　　　　　i し.／ :::::::::::::＼
　　　/　/　/_＿,,_＿＿_,／￣　＼　　）)u　　　　ﾉ　(　　::::::::::::::::::::＼
　　/　　ヽ　|.. |　／└└└└＼../＼（（＼　　　　　'~ヽ　　:::::::::::::::::／
　　＼　) し ∨.|llllｌlllllllllllllllllllllllllll∨lllll|　）　/　　／　　　 :::::::::::::::::／
　　　＼⌒ |　|.|llllllllllll;／⌒／⌒　　〕　　　　　　　　　::u::::::::::::::::／
　　　　 |　 |　|.|lllllllll;　　　./　.　　 .　|　　　　　　　　::::::::::::::::::::／
　　　　 .|　 |　|.|llllll|′　　/　　　　
　　　　　.|　|　|.|llll| 　　　| 　　　　.∧〔　　　/　　　u:::::::::::::|
　　　　　ヽ｝.∧lll　　　　|　　　　../　/　　／　　　:::::::::::::::::＼
　　　　　　i/|　＼┌┌┌┌┌ /. ／　／:::　　　　　:::::::::::::::::i
　　　　　　(　ﾞﾞ^^¨^¨ﾞﾞ¨　￣￣￣| i／:::::::::::　u　　　　　　　　i
　　　　　　ヽｰ─￢ｰ～ｰ――i |　:::::::::::::

**デフォルトの名無しさん** · 2022/04/21(木) 13:08:35.07

>>93
Goは言わば並列対応スクリプトC言語だからだよ
だから今どきの言語と異なりC言語のように地道に記述量が増えるとともに安全軽視で自己責任

**デフォルトの名無しさん** · 2022/04/21(木) 14:17:09.70

男の人って気持ち悪い…
どうして少女をそんなに汚したがるの？
お母さんに悪いとわおもわないの？

**デフォルトの名無しさん** · 2022/04/21(木) 15:09:04.59

そらごらんなさいRustの悪影響を

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

アイGoー

**デフォルトの名無しさん** · 2022/04/21(木) 15:52:10.80

Rustならシンプルに分かりやすく書きやすい上に
うっかりミスもコンパイルエラーで検出されるから良いよな

**デフォルトの名無しさん** · 2022/04/21(木) 17:31:45.76

Rustの話は専用の隔離部屋でお願いします

Rust part14
https://mevius.5ch.net/test/read.cgi/tech/1644596656/

次スレタイトルからRustの文字を削除してください

**デフォルトの名無しさん** · 2022/04/21(木) 17:40:50.87

比較の話だからここでいいんじゃね
そもそもアンチ側が悪影響とか言い出してきっかけ作っているし
アンチを各言語本スレへ誘導するのはダメだろ

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

比較の話も含めて >>121 の専用スレでやって下さい

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

言語同士の比較はここでやる
Rust単独の話は向こうでやる
それだけだ

以上

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

むしろここが隔離スレだと思ってた

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

ここは次世代言語スレ
次世代言語の話題や機能や比較に議論まで何でもOK
各言語の本スレに迷惑がかからないようここで行なうこと推奨

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

>>114
このように誰もGoのことなど挙げてないのに、Rustの超ビギナーの信者は異様に敵視を行う。

例えば、代表的なNull安全言語は、RustがまさにそうだがOptionを使うからNullなんて無いのだが、matchを書いたとしてもNoneで
異常を処理しないような事を書いてしまえば、Nullで落ちたりするプログラムと大して変わらない。unwrapを連打するようなプログラムは
論外だとしても、それはNullをチェックしないプログラムと何ら変わりない。
Qitaの有害記事、「null安全でない言語は、もはやレガシー言語だ」のせいで、このような思想を植え付けられている人があまりに多い。
大切なことは異常系をきちんと処理できているかということで、言い訳では「ちゃんとやるのを忘れているかもしれないのでは」という指摘に
コンパイルが通らないだの、Rustでしかそうならない事を都合が悪いのか、短い考察だけで反論しています。
コンパイルが通ろうと通らななかろうと、”ちゃんとやるのを忘れて”いれば同じです。

また、たしかにNull安全は、Java/KotlinのようなNullが奥深くに根ずく言語であれば恩恵は大きいでしょう。しかしGoのような言語は
扱うデータはstructであり、Nullが無い訳ではないが、奥深くに潜む”参照”データー構造を設計思想から良しとはしていない言語である。
一部の言語設計者ではリンクリストのような、非効率で何も考えてないデーター構造を逆にレガシーと呼びます。
もちろん、if err != nil { }が古臭く邪魔で嫌、あちこちに現れるので受け付けないという意見は分かるし、これを簡略化するために
Null条件演算子やNull合体演算子が欲しいという要望もわかる。しかし、それが導入された、もしくはされていないからといって
それはNull安全言語とは厳密には関係ない。

**デフォルトの名無しさん** · 2022/04/21(木) 20:11:11.38

>>127
> このように誰もGoのことなど挙げてないのに
>>72,74,80,82

**デフォルトの名無しさん** · 2022/04/21(木) 20:19:15.04

>>127
＞このように誰もGoのことなど挙げてないのに、Rustの超ビギナーの信者は異様に敵視を行う。

このように誰もRustのことなど挙げてないのに、Goの超ビギナーの信者は異様に敵視を行う。

以下略

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

>>127
それは君の主張が間違っている
Rustではある型Tの変数に対してnull相当(nilやundefined等含む)を代入出来ない
そのため君の主張する処理し忘れがあってもnull相当を扱ってしまう危険性は起きない

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

ほらまたTとか言い出したこれだからRusterは

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

Goだって最近Tって書けるようになったでしょ
スレタイの言語皆Tって書くのでは

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

・Rustにはnullという概念のものが存在しない
・存在するかしないかを示したいならば代数的データ型であるenum Optionを用いる
・扱う型をT型とするとOption<T>型となるため型が異なり処理を忘れてミスすることも起きようがない

**デフォルトの名無しさん** · 2022/04/21(木) 22:33:53.95

Nim, Zig, Rust, C++でコンパイル時に実行されるコードを比較した記事。
https://castillodel.github.io/compile-time-evaluation/

**デフォルトの名無しさん** · 2022/04/21(木) 22:39:37.71

>>133
糞バカ中世ジャップランド土人どもはOption.get()するだけだぞ

**デフォルトの名無しさん** · 2022/04/21(木) 22:55:52.73

>>135
Optionにget()メソッドはありません

**デフォルトの名無しさん** · 2022/04/21(木) 23:17:57.08

ほぼOptionのNoneと言ってるのに、null相当(nilやundefined等含む)を代入とか、Option<T>型となるため型が異なりとか
もう誤魔化して言いくるめる気にしか見えない。。。
どれだけNull安全で助かってるか、なんてコードを書いてればそんなに無いでしょ。確かにNullが無いのだから、Nullのような状態で
クラッシュ/panicする事態は減るでしょう。コンパイルが通った時点でNull安全性が保障されるなんてのも、今どきの多くの言語は
外付けながらLint系の警告をしてくれます。もちろん言語に統合されてない後付けで「美しくない」とかそういうのはあるでしょうが。
そして手続き型プログラミングを初めて数年の初心者なら沢山のミスを犯すのかもしれんけどさ、そもそも宣言と同時に初期化を
する重要性は、関数型プログラミングでも少しでもしていれば分かるはずでそんな経験もなく、旧Java系なんかからRustへ移ったら
感嘆するように見えるのかもしれんが、そんなしつこく言うほど便利な場面って具体的にどういう時よ？逆にさ？
次はNan安全言語とか、-+Inf安全言語とかやるのかい？

**デフォルトの名無しさん** · 2022/04/21(木) 23:28:25.00

Rustのアドバンテージを認めざるを得ないから認めつつ
それでも批判したいから言い掛かり長文
みっともない

**デフォルトの名無しさん** · 2022/04/21(木) 23:47:03.05

>>137 その通りだからきみはJavaとかHaskellとか使えばいいと思うよ

Rustの良いところを教えてほしいなら普通に指導を乞えばいいのに

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

null安全をlinterが警告してくれる言語なんてあったっけ？

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

>>140
未初期化変数へのアクセスのことを言ってそうな気がする
それ以外のケースでnullの問題踏んだことない人なのかもしれない

**デフォルトの名無しさん** · 2022/04/22(金) 02:18:54.02

>>134
Goが無いのはGoでは不可能なの？

**デフォルトの名無しさん** · 2022/04/22(金) 16:02:25.23

Rustにいいところなんてないよ
面倒なだけ

**デフォルトの名無しさん** · 2022/04/22(金) 16:09:03.51

色々とプログラミングが楽で快適だからRust使ってるわ

**デフォルトの名無しさん** · 2022/04/22(金) 18:41:08.80

普通に煽りじゃない反論ができない時点でRustニワカのキモさが良くわかる。Null安全を全否定してないのに
「指導を乞え」とか「JavaとかHaskellとか使え」とか「それ以外のケースでnullの問題踏んだことない」とか
Nullのような状態でクラッシュ/panicする事態は減るって書いてるのに文字も読めもしない。
”それほど強調して、気持ち悪く粘着してNull安全言語なんて宣伝してることがRustのために良くない”って話だよ
言語の悪口を言ってるんじゃない、おまえのようなキモくて何も答えられないで煽りだけクズを論ってんの

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

自分でこれが煽りじゃない反論だと思ってるならヤバい

**デフォルトの名無しさん** · 2022/04/22(金) 19:15:01.24

Rustより良い言語が出現したらそれを検討する予定
今のところそういう言語がないためメイン言語はRustのまま