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

**デフォルトの名無しさん** · 2022/09/17(土) 19:05:49.83

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/10/06(木) 19:23:24.18

>>694
追加機能とか便利になる機能とかは困ってるわけじゃないからなぁ。

**デフォルトの名無しさん** · 2022/10/06(木) 20:36:12.00

拡張子の話もういいよｗ

**デフォルトの名無しさん** · 2022/10/06(木) 22:34:31.24

やっぱりヘッダーファイルができた
C言語あたりから拡張子が必要になったんじゃないか
それまではソースファイル一つとオブジェクトファイル一つで
データは外から読んで、外に書き出すものだったから

**デフォルトの名無しさん** · 2022/10/07(金) 12:11:11.36

そもそもwikipediaをソースにしちゃうひとってω

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

>>683
.inc とか .m とかたまに観る

**デフォルトの名無しさん** · 2022/10/07(金) 12:14:03.56

>>675
.N88 とか .BAS より古いのか

**デフォルトの名無しさん** · 2022/10/07(金) 12:14:41.50

そんなの初めて聞いた
いったいどこの処理系だよ

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

>>699
.inc はまだしも .m はみたことないな

**デフォルトの名無しさん** · 2022/10/08(土) 00:54:36.30

>>700
Csave命令に拡張子はなかった
何冊か確認した
80年代のキッズ向けゲームプログラミングの本だ

**デフォルトの名無しさん** · 2022/10/15(土) 13:35:22.93

Siv3DやDXライブラリ等のゲーム制作用のフレームワークを使用したくてC++に初めて手を出そうと思うのですが
世の中の風潮がC++での新規開発はナンセンスでありC++を代替する言語（主にRust？）を選択すべきとあるようです
正直C++もRustも構文が複雑ですぐに忘れそうなので、NimかZigが良さそうと感じました
Zigは安定版がまだまだ先なので採用できませんがNimが流行っていないのは何か致命的な欠点があるからでしょうか

**デフォルトの名無しさん** · 2022/10/15(土) 13:37:39.38

ゲーム作りたいならunityかc++じゃないの？rustはいずれ台頭するかも知れないけど今はまだ成熟してない気がする。

**デフォルトの名無しさん** · 2022/10/15(土) 13:48:06.01

>>705
Unity等のゲームエンジンは使用せずプログラミング言語（GCは無しか軽めのやつ）でいきたいです
C++のフレームワークは最悪DLL化すればよいので、読みやすくコンパイルや実行速度が速い言語が良いです
総合するとNimが最有力かなと思いました
Nimがなぜこんなにも流行っていないのか不思議でなりません

**デフォルトの名無しさん** · 2022/10/15(土) 14:06:33.72

C++が嫌、Unityも嫌って趣味でするなら何でもいいけど
もし仕事ならそれは無理があるｗ

**デフォルトの名無しさん** · 2022/10/15(土) 14:14:29.81

普通にフレームワーク使えば良くないか？
こだわりがあるわけでもないみたいだし

**デフォルトの名無しさん** · 2022/10/15(土) 14:26:29.95

先週のレスだけど.mはObjective-C

**デフォルトの名無しさん** · 2022/10/15(土) 14:40:37.67

Nimは別に致命的な欠陥があるとかではないんだろうけど
わざわざ使う理由もないんだよな
構文が好きな人はいるだろうけど結局個人の好みなので
みんなで移行するほどの動機にはならない

**704** · 2022/10/15(土) 14:45:33.73

レスどうもです
ひとまずC++でいこうと思います
C++20とかで昔よりは書きやすく見やすくなっている気がしますし
何より日本語の参考情報・コミュニティが多いのが長期的に見れば問題発生時に助かるはず

**デフォルトの名無しさん** · 2022/10/15(土) 14:53:07.87

IT土方を目指すならRust
趣味や個人でやるんならNim

**デフォルトの名無しさん** · 2022/10/15(土) 14:54:50.47

土方がRustなんか使えないし使わないｗ

**デフォルトの名無しさん** · 2022/10/15(土) 15:10:11.71

人形劇ご苦労さん

**デフォルトの名無しさん** · 2022/10/15(土) 15:50:43.54

ゲームそのものを作るのはUnity/UE/cocos2dのいずれか又は全部で、それぞれの1stターゲットの言語を使ってやりつつ、エンジン自作はC++でやればいいと思う
一応Rustもこないだ見たらwindows-rsでDirectX 12も書けるしXamlも食えるようになってたのでナシではない
Windows以外のプラットフォーム向けなら何個かVulkanラッパーあるし
いずれにせよ修羅の道だけど

**デフォルトの名無しさん** · 2022/10/15(土) 16:31:40.59

>>706
ネイティブコンパイラじゃなくトランスレーターだから。
過去トランスレーターで流行ったのはTypescriptしかない。

**デフォルトの名無しさん** · 2022/10/15(土) 17:46:33.43

>>716
初期のC++もトランスレーターだったから流行らない原因をトランスレーターと言うのはちょっと違うと思うな

**デフォルトの名無しさん** · 2022/10/15(土) 18:11:19.69

セルフホスティングできない言語は2流

**デフォルトの名無しさん** · 2022/10/15(土) 18:13:42.88

ゲームでは、Unity 以外は無理

特に、C++ なんて10年以上は掛かる

**デフォルトの名無しさん** · 2022/10/15(土) 19:30:07.96

unity使うなら素直にc#だな。

**デフォルトの名無しさん** · 2022/10/15(土) 19:43:34.04

>>717
それはMicrosoftが開発言語に採用したからだ。

**デフォルトの名無しさん** · 2022/10/15(土) 19:48:13.86

Unreal Engine「あの・・・」

**デフォルトの名無しさん** · 2022/10/15(土) 20:13:38.24

>>721
それならますますトランスレーター関係ないだろw

**デフォルトの名無しさん** · 2022/10/15(土) 20:25:42.25

nim言語は普通にコンパイルして使う場合には
ネティブコードコンパイラと違いはない

nim c -d:danger -d:strip hello.nim

でバイナリの実行コードができるので。

**デフォルトの名無しさん** · 2022/10/16(日) 11:35:47.53

イケてない最大の理由は名前
kotlinとかnimとか名前がダサい
響きが野暮ったい

**デフォルトの名無しさん** · 2022/10/16(日) 11:59:35.86

錆に言われても…

**デフォルトの名無しさん** · 2022/10/16(日) 15:31:24.57

イケてないネーミングは

rust

が一番だわ w

**デフォルトの名無しさん** · 2022/10/17(月) 01:09:17.45

>>726
>>727
俺もそう思う。
初めて見た時なんで錆？って思ったわ。

**デフォルトの名無しさん** · 2022/10/17(月) 01:42:41.41

ゴタクはいいよ
なんでnimが流行ってないかお前らも考えろよ

おおかたロゴかマスコットキャラがキモかったんじゃねーの

**デフォルトの名無しさん** · 2022/10/17(月) 02:11:22.42

ゴタクｗｗｗ

**デフォルトの名無しさん** · 2022/10/17(月) 09:05:27.87

流行ってない泡沫言語なんて山のようにあるんだから考えるだけ無駄。
流行っている理由ならまだしも。

**デフォルトの名無しさん** · 2022/10/17(月) 10:09:48.88

まあ流行自体が目的でない限り、真の目的のために流行を犠牲にするのはごく普通の手段でしょ
対価を一円たりとも支払わない方針のほうが珍しい

**デフォルトの名無しさん** · 2022/10/17(月) 11:36:17.89

チャリンカスの言う事はわかんねえな

**デフォルトの名無しさん** · 2022/10/17(月) 16:14:18.51

単発お疲れ

**デフォルトの名無しさん** · 2022/10/18(火) 15:14:40.60

CNET Japan: グーグル、Rustで書かれたセキュアなOS「KataOS」を発表.
http://japan.cnet.com/article/35194751/

**デフォルトの名無しさん** · 2022/10/18(火) 15:54:59.76

>>735
＞　このOSは、デスクトップPCやスマートフォン向けではなく、モノのインターネット（IoT）、おそらくはスマートホームを対象としたものだ。

**デフォルトの名無しさん** · 2022/10/18(火) 15:58:15.67

Zig言語日本語マニュアル
https://ja.wikibooks.org/wiki/Zig

これは助かる

**デフォルトの名無しさん** · 2022/10/19(水) 08:41:14.53

>>736
だから何？

**デフォルトの名無しさん** · 2022/10/19(水) 11:24:46.83

>>735
だから何？

**デフォルトの名無しさん** · 2022/10/19(水) 12:28:59.25

>>738
PCのOSじゃないのか、がっかり

**デフォルトの名無しさん** · 2022/10/19(水) 12:29:54.54

>>739
グーグルがRustで本格的にOSつくりだしたことで、Rustの覇権が決定的なものとなった

**デフォルトの名無しさん** · 2022/10/19(水) 12:36:32.14

Google Researchだから論文出して飽きたら終わりだよ

**デフォルトの名無しさん** · 2022/10/19(水) 13:04:51.36

ハードを遠隔操作するOSは飽きるんじゃなくてハードが規制される
言語は規制されないから終わらない

**デフォルトの名無しさん** · 2022/10/20(木) 06:12:38.97

>>741
RTOSだとRustの制約がきつすぎて他の言語と変わらなくなりそうだと思うがね。

特にAliasing XOR Mutabilityをマルチスレッドで有効活用するのはキツイんじゃね？Mutex、RwLock、Atomicの管理で破綻しそうだし、熟成するまでせっかちなGoogleが我慢できるとも思えん。

**デフォルトの名無しさん** · 2022/10/22(土) 09:25:03.56

Rustが覇権取ってくれるのは一向に構わんがはよ流行れよとｗ
いつまで同じこといってんのよ～って感じやな
Goが下火になってきてるのはいいことやとは思う
はよGoを滅ぼしてくれよRustさんよぉ

**デフォルトの名無しさん** · 2022/10/22(土) 09:59:05.95

Rustも流行らないよ
borrow checkerが厳しすぎる

**デフォルトの名無しさん** · 2022/10/22(土) 11:11:33.12

>>745
用途が全然違うのになぜ比較したがるのか
RustはCとC++の代替言語な

**デフォルトの名無しさん** · 2022/10/22(土) 11:37:42.63

そりゃあどんな物でもお金と交換できると思ってるならなんでも比較できると思うだろう

**デフォルトの名無しさん** · 2022/10/22(土) 13:08:21.47

>>745
Webサービスに使うならGoで良いんじゃない？
GCあっても誤差レベルだし
ライブラリも豊富だから作りやすいでしょう
非同期ランタイムとか面倒なこともないし

**デフォルトの名無しさん** · 2022/10/22(土) 21:40:08.13

>>749
>GCあっても誤差レベルだし
これマジで言ってる？ｗ

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

Rustが覇権を握った世界でもCは使われるんじゃないの？
小さなプログラムでもRustが上なのか？

**デフォルトの名無しさん** · 2022/10/22(土) 23:50:16.06

>>750
？

**デフォルトの名無しさん** · 2022/10/23(日) 08:05:47.52

>>751
メモリの開放処理が不要なツールとかだと、明示的にメモリ解放サボれるCが有利なケース作れたりするんかな。
そんなケースで勝てなくてもいいとは思うけど。

**デフォルトの名無しさん** · 2022/10/23(日) 08:33:25.76

>>749
正直Webサービスって別にGoじゃなくてもいいよね感半端ない
JavaでもRubyでもC#でもいいし
Goの利点なんて全然ないわ
Goルーチンなんて全然いらんし

**デフォルトの名無しさん** · 2022/10/23(日) 09:03:11.53

>>754
でもISUCONでは一番人気だしスケールしやすく簡単にかけて可読性がよくパフォーマンスが出るのは事実なのでは？
Goが一番輝くのはDockerやKubernetesで使われてるようにクラウド関連の周辺ツールやバックエンドだな

CockroachDBやTiDBで使われてるように、その気になればDBみたいなプログラムにも適している

Rustはとっつきにくさがあるからここまで流行らないだろうね、そもそもGCが気になるケースってのは非常に稀だしOS開発ぐらいでしかまず使われないだろう
GCも当然進化しているわけだからJavaとかと比べてGoの停止時間は圧倒的に短いし、ある程度書き方を工夫することでスタックヒープにわける制御もできる
だからほとんどGCが問題になることもない

あくまでもRustはCを置き換える言語だね

**デフォルトの名無しさん** · 2022/10/23(日) 09:15:11.78

>>755
でもいらねーんだよ
JavaやらのGCだってどんどん進化してるし
別にGoじゃなくてもDocker、k8sでスケールできるし
Goじゃなきゃ非機能要件を満たせないなんてことまずねーんだよ
それにエラー処理が糞だからなぁ

**デフォルトの名無しさん** · 2022/10/23(日) 09:43:25.00

javaとgoはスピンアップ速度で違いが出る

**デフォルトの名無しさん** · 2022/10/23(日) 10:06:55.74

>>756
エラー処理がクソってのもお前の感想でしかない
例外の方がクソって考えてる人もそれなりにいるわけなんでね
俺からしたらGoよりJavaの方が終わってる点が圧倒的に多いと思ってるでね
俺はISUCONで一番Goが使われててJavaなんて誰も使ってないっていうデータを示してるわけだが

お前の感想なんか誰も聞いてないよ

**デフォルトの名無しさん** · 2022/10/23(日) 10:21:24.89

スケールできるってのはあくまでも効率よくって話な
ISUCON12の初期実装でもGoとJavaでは5倍ほど差があったとのことだし、同じように実装しても普通に差が出るんだから
当然効率よくスケールできるという話になるわけ

**デフォルトの名無しさん** · 2022/10/23(日) 11:03:30.61

>>758
いやー、Goのエラー処理は適当やってると問題起きた時につらいんだよね。スタックトレース付けてなかったりすると、どこで問題起きてるかがわからない。
スタックトレースをエラー処理に組み込んでないってのが、JVM言語やってた人間からすると信じがたい。

**デフォルトの名無しさん** · 2022/10/23(日) 12:37:24.57

軽量スレッドを使った並行並列処理する上で例外は相性が悪いからオミットされて代わりに値として扱ってるってのがまずあるね
Goが作られた最大の理由は効率よくマルチコアを利用するってのだし

Nodeみたいにシングルスレッドなのであれば例外も扱えることができるが
これを両立してる言語は存在しないね

**デフォルトの名無しさん** · 2022/10/23(日) 13:40:15.59

JVMでできることが何故LLVMでできないの？

**デフォルトの名無しさん** · 2022/10/23(日) 13:46:11.16

実際、D言語にはGCがあるけど、LLVMを使ってるLDCでコンパイルすれば
C++にかなり近い実行速度になるし、GCはそんなに遅くない気はする

**デフォルトの名無しさん** · 2022/10/23(日) 14:00:57.32

ていうか、Rustってなんでこんなに必死なの？

**デフォルトの名無しさん** · 2022/10/23(日) 14:06:22.10

生殺与奪の権を自分で握っているから

**デフォルトの名無しさん** · 2022/10/23(日) 14:08:45.41

>>759
Javaの場合はフレームワークもそれなりに重いからね

**デフォルトの名無しさん** · 2022/10/23(日) 14:13:26.72

>>754
別に書き換える必要はないと思うよ
新規で始めるならGoとかRust使った方が面白いのではないかと言うこと

**デフォルトの名無しさん** · 2022/10/23(日) 14:51:49.61

そもそもJavaとWebって相性が悪い
なぜならオブジェクト指向とWebの相性がそもそも悪いから
アホがOOPを意識して書くとオーバーエンジリアリングになりがちで、基本的に手続型の方が適してる
Spring Bootとか重厚すぎて終わってる
OOPが向いてるのはGUIとか

public static void mainとかアホじゃねーの

**デフォルトの名無しさん** · 2022/10/23(日) 15:33:35.06

public static final int countdown

**デフォルトの名無しさん** · 2022/10/23(日) 15:54:26.44

違うと思う
相性が悪いわけではなかった
「今後必要になるプログラミング言語」を見てみると当時javaがどう思われていたのかが分かる

**デフォルトの名無しさん** · 2022/10/23(日) 16:47:45.25

>>756
「でも」の意味がわからなすぎて草
「Goじゃなきゃ非機能要件を満たせない」なんて、その言語がチューリング完全じゃないみたいじゃん

極論過ぎて言いたいことがぼやけてるぞ

**デフォルトの名無しさん** · 2022/10/23(日) 16:48:56.95

>>760
適当にするからでしょ。
そもそもその場で処理しているはずであって、スタックトレースに頼る実質超巨gotoな例外の方がどうかしてると思う。

**デフォルトの名無しさん** · 2022/10/23(日) 16:53:17.98

メッセージ送信とかいう概念がwebと相性がいいのは分かる
その概念が何故オブジェクトの概念と密結合になってるのかが分からない

**デフォルトの名無しさん** · 2022/10/23(日) 17:12:16.99

>>772
理想はまぁそうなんだけどさ。現実そうでないコードがどうやっても紛れ込むんだから根性で解決とかは勘弁。

**デフォルトの名無しさん** · 2022/10/23(日) 17:25:00.01

>>774
errcheckとか活用すればいいし、コーディングする際は必ず戻り値を確認すればいい

漏れやすいのは確かだけど、エラー表現が全く統一されてないC、C++に比べると圧倒的に楽なのは事実

**デフォルトの名無しさん** · 2022/10/23(日) 19:26:33.97

Rustのエラー処理に慣れると他の言語使えんよ
anyhowとthiserrorのコンボこそあらゆるプログラミング言語のエラー処理のエデンと感じる

**デフォルトの名無しさん** · 2022/10/23(日) 19:54:48.16

まあ所詮Haskellの焼き直しなんですけどね

**デフォルトの名無しさん** · 2022/10/23(日) 20:01:27.37

原理試作と実用製品の関係みたいなもん

**デフォルトの名無しさん** · 2022/10/23(日) 20:52:58.51

DelphiとC#とTypeScriptの関係みたいなもんでしょ

**デフォルトの名無しさん** · 2022/10/23(日) 22:33:19.11

>>776
InvalidArgumentみたいな標準的なのを各レイヤーごとにいちいち自分で名前決めて定義しないといけないのはどうかと思う

プロジェクトがかわってもRust使ってる場合に標準的に使えるエラー型は用意して欲しい
まあanyhowレベルで浸透するならcrateの形でも提供でもいい

**デフォルトの名無しさん** · 2022/10/24(月) 00:00:17.86

うむ

**デフォルトの名無しさん** · 2022/10/24(月) 08:19:36.09

もう少し例外を使用しても良いのではないか...
https://qiita.com/MasayaMizuhara/items/98c0d490f1633d9b636f
例外処理は処理コストが掛かるらしいことを確かめようとしたら、意外とそうでもなかった話]
https://katzchang.hatenadiary.org/entry/20081021/p1

**デフォルトの名無しさん** · 2022/10/24(月) 08:44:13.82

let hoge
try {
hoge = maybeThrow()
} catch (err)
{
エラー処理
}

hogeをここで使用

スコープが分断されるのが嫌い
かといって全部try catchでまとめて囲むのも嫌だ

**デフォルトの名無しさん** · 2022/10/24(月) 11:09:28.71

それ以上の描き方思いつかないならそれで我慢しろとしか言いようがねえな

**デフォルトの名無しさん** · 2022/10/24(月) 12:54:58.71

try {
const hage = ......
// ここでハゲる
}
catch .....

**デフォルトの名無しさん** · 2022/10/24(月) 13:45:05.88

思いついてやったぞ
3項演算子みたいに書けるトライキャッチがあればいいんだろう

**デフォルトの名無しさん** · 2022/10/24(月) 13:46:20.16

なんでこっちにしなかったんだろう
スコープを考えたら絶対こっちの方が良いのに

try {
.....
catch (e) {
.....
}
}

**デフォルトの名無しさん** · 2022/10/24(月) 13:47:17.46

ラムザキャッチと名付ける

**デフォルトの名無しさん** · 2022/10/24(月) 13:50:06.34

let hoge = maybeThrow() ? catch(err){
//エラー処理１
//エラー処理２
//エラー処理３
};

こういう見映えだとラムダ式に似てるだろ

**デフォルトの名無しさん** · 2022/10/24(月) 18:46:24.56

>>787
それも少し数増えたら見づらいだろ。

**デフォルトの名無しさん** · 2022/10/24(月) 19:24:34.71

そうか？

case e => HogeException
case e => FugaException

みたいにすればすげーわかりやすい気がするが
この構文は前から俺が温めていたものだ
特に出す機会はないがw

**デフォルトの名無しさん** · 2022/10/24(月) 19:29:48.11

>>787
例外ってすげー祖先まで遡る事もあるって知らないの？

**デフォルトの名無しさん** · 2022/10/24(月) 22:37:32.41

stderrに文字を書き込んでexitしてもターミナルは終了しない
というマルチタスク的なUIを

シングルタスクで擬似的に再発明する機能がcatchだ
catchしなければ全部終了するから

**デフォルトの名無しさん** · 2022/10/30(日) 13:17:58.74

多分岐を前提としたエラーハンドリングはクソだと思うわ
GoやTSみたいに基本一つで必要に応じてエラーハンドラの中で分岐でいい