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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2022/09/17(土) 19:05:49.83ID:6v3irpfN
スレタイ以外の言語もok

前スレ
次世代言語28 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1661739736/
2022/10/18(火) 15:54:59.76ID:CM7CURt5
>>735
＞　このOSは、デスクトップPCやスマートフォン向けではなく、モノのインターネット（IoT）、おそらくはスマートホームを対象としたものだ。
2022/10/18(火) 15:58:15.67ID:RrYbmX3O
Zig言語 日本語マニュアル
https://ja.wikibooks.org/wiki/Zig

これは助かる
2022/10/19(水) 08:41:14.53ID:1HFYTZZW
>>736
だから何？
2022/10/19(水) 11:24:46.83ID:e814Cfcc
>>735
だから何？
2022/10/19(水) 12:28:59.25ID:GEPyqTO9
>>738
PCのOSじゃないのか、がっかり
2022/10/19(水) 12:29:54.54ID:GEPyqTO9
>>739
グーグルがRustで本格的にOSつくりだしたことで、Rustの覇権が決定的なものとなった
2022/10/19(水) 12:36:32.14ID:ym3Y2idE
Google Researchだから論文出して飽きたら終わりだよ
2022/10/19(水) 13:04:51.36ID:6gvt48Sb
ハードを遠隔操作するOSは飽きるんじゃなくてハードが規制される
言語は規制されないから終わらない
2022/10/20(木) 06:12:38.97ID:LB7mrsJk
>>741
RTOSだとRustの制約がきつすぎて他の言語と変わらなくなりそうだと思うがね。

特にAliasing XOR Mutabilityをマルチスレッドで有効活用するのはキツイんじゃね？Mutex、RwLock、Atomicの管理で破綻しそうだし、熟成するまでせっかちなGoogleが我慢できるとも思えん。
2022/10/22(土) 09:25:03.56ID:gR6VtGLA
Rustが覇権取ってくれるのは一向に構わんがはよ流行れよとｗ
いつまで同じこといってんのよ～って感じやな
Goが下火になってきてるのはいいことやとは思う
はよGoを滅ぼしてくれよRustさんよぉ
746デフォルトの名無しさん
垢版 |
2022/10/22(土) 09:59:05.95ID:Kx4jEG6I
Rustも流行らないよ
borrow checkerが厳しすぎる
2022/10/22(土) 11:11:33.12ID:g8L2LKV+
>>745
用途が全然違うのになぜ比較したがるのか
RustはCとC++の代替言語な
2022/10/22(土) 11:37:42.63ID:7/DIukmA
そりゃあどんな物でもお金と交換できると思ってるならなんでも比較できると思うだろう
2022/10/22(土) 13:08:21.47ID:OES5lhv+
>>745
Webサービスに使うならGoで良いんじゃない？
GCあっても誤差レベルだし
ライブラリも豊富だから作りやすいでしょう
非同期ランタイムとか面倒なこともないし
2022/10/22(土) 21:40:08.13ID:YfyYmLnG
>>749
>GCあっても誤差レベルだし
これマジで言ってる？ｗ
751デフォルトの名無しさん
垢版 |
2022/10/22(土) 23:03:08.03ID:iDqDSmph
Rustが覇権を握った世界でもCは使われるんじゃないの？
小さなプログラムでもRustが上なのか？
2022/10/22(土) 23:50:16.06ID:OES5lhv+
>>750
？
2022/10/23(日) 08:05:47.52ID:JTB6G86q
>>751
メモリの開放処理が不要なツールとかだと、明示的にメモリ解放サボれるCが有利なケース作れたりするんかな。
そんなケースで勝てなくてもいいとは思うけど。
2022/10/23(日) 08:33:25.76ID:mcEZ9b2B
>>749
正直Webサービスって別にGoじゃなくてもいいよね感半端ない
JavaでもRubyでもC#でもいいし
Goの利点なんて全然ないわ
Goルーチンなんて全然いらんし
2022/10/23(日) 09:03:11.53ID:UH4lwye7
>>754
でもISUCONでは一番人気だしスケールしやすく簡単にかけて可読性がよくパフォーマンスが出るのは事実なのでは？
Goが一番輝くのはDockerやKubernetesで使われてるようにクラウド関連の周辺ツールやバックエンドだな

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

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

あくまでもRustはCを置き換える言語だね
2022/10/23(日) 09:15:11.78ID:mcEZ9b2B
>>755
でもいらねーんだよ
JavaやらのGCだってどんどん進化してるし
別にGoじゃなくてもDocker、k8sでスケールできるし
Goじゃなきゃ非機能要件を満たせないなんてことまずねーんだよ
それにエラー処理が糞だからなぁ
2022/10/23(日) 09:43:25.00ID:H9SBWcx0
javaとgoはスピンアップ速度で違いが出る
2022/10/23(日) 10:06:55.74ID:UH4lwye7
>>756
エラー処理がクソってのもお前の感想でしかない
例外の方がクソって考えてる人もそれなりにいるわけなんでね
俺からしたらGoよりJavaの方が終わってる点が圧倒的に多いと思ってるでね
俺はISUCONで一番Goが使われててJavaなんて誰も使ってないっていうデータを示してるわけだが

お前の感想なんか誰も聞いてないよ
2022/10/23(日) 10:21:24.89ID:UH4lwye7
スケールできるってのはあくまでも効率よくって話な
ISUCON12の初期実装でもGoとJavaでは5倍ほど差があったとのことだし、同じように実装しても普通に差が出るんだから
当然効率よくスケールできるという話になるわけ
2022/10/23(日) 11:03:30.61ID:JTB6G86q
>>758
いやー、Goのエラー処理は適当やってると問題起きた時につらいんだよね。スタックトレース付けてなかったりすると、どこで問題起きてるかがわからない。
スタックトレースをエラー処理に組み込んでないってのが、JVM言語やってた人間からすると信じがたい。
2022/10/23(日) 12:37:24.57ID:aumvRfST
軽量スレッドを使った並行並列処理する上で例外は相性が悪いからオミットされて代わりに値として扱ってるってのがまずあるね
Goが作られた最大の理由は効率よくマルチコアを利用するってのだし

Nodeみたいにシングルスレッドなのであれば例外も扱えることができるが
これを両立してる言語は存在しないね
2022/10/23(日) 13:40:15.59ID:Ru+lcIaK
JVMでできることが何故LLVMでできないの？
2022/10/23(日) 13:46:11.16ID:NS3+KJ7P
実際、D言語にはGCがあるけど、LLVMを使ってるLDCでコンパイルすれば
C++にかなり近い実行速度になるし、GCはそんなに遅くない気はする
2022/10/23(日) 14:00:57.32ID:VfLJCoFB
ていうか、Rustってなんでこんなに必死なの？
2022/10/23(日) 14:06:22.10ID:Ru+lcIaK
生殺与奪の権を自分で握っているから
2022/10/23(日) 14:08:45.41ID:ioVOctq2
>>759
Javaの場合はフレームワークもそれなりに重いからね
2022/10/23(日) 14:13:26.72ID:ioVOctq2
>>754
別に書き換える必要はないと思うよ
新規で始めるならGoとかRust使った方が面白いのではないかと言うこと
2022/10/23(日) 14:51:49.61ID:/lSuGz6a
そもそもJavaとWebって相性が悪い
なぜならオブジェクト指向とWebの相性がそもそも悪いから
アホがOOPを意識して書くとオーバーエンジリアリングになりがちで、基本的に手続型の方が適してる
Spring Bootとか重厚すぎて終わってる
OOPが向いてるのはGUIとか

public static void mainとかアホじゃねーの
2022/10/23(日) 15:33:35.06ID:iZvinCS0
public static final int countdown
2022/10/23(日) 15:54:26.44ID:9PrlG1Sf
違うと思う
相性が悪いわけではなかった
「今後必要になるプログラミング言語」を見てみると当時javaがどう思われていたのかが分かる
2022/10/23(日) 16:47:45.25ID:uJU0x2Ru
>>756
「でも」の意味がわからなすぎて草
「Goじゃなきゃ非機能要件を満たせない」なんて、その言語がチューリング完全じゃないみたいじゃん

極論過ぎて言いたいことがぼやけてるぞ
2022/10/23(日) 16:48:56.95ID:uJU0x2Ru
>>760
適当にするからでしょ。
そもそもその場で処理しているはずであって、スタックトレースに頼る実質超巨gotoな例外の方がどうかしてると思う。
2022/10/23(日) 16:53:17.98ID:Ru+lcIaK
メッセージ送信とかいう概念がwebと相性がいいのは分かる
その概念が何故オブジェクトの概念と密結合になってるのかが分からない
2022/10/23(日) 17:12:16.99ID:JTB6G86q
>>772
理想はまぁそうなんだけどさ。現実そうでないコードがどうやっても紛れ込むんだから根性で解決とかは勘弁。
2022/10/23(日) 17:25:00.01ID:UH4lwye7
>>774
errcheckとか活用すればいいし、コーディングする際は必ず戻り値を確認すればいい

漏れやすいのは確かだけど、エラー表現が全く統一されてないC、C++に比べると圧倒的に楽なのは事実
2022/10/23(日) 19:26:33.97ID:HOBBKeJ+
Rustのエラー処理に慣れると他の言語使えんよ
anyhowとthiserrorのコンボこそあらゆるプログラミング言語のエラー処理のエデンと感じる
2022/10/23(日) 19:54:48.16ID:xpNFRiXA
まあ所詮Haskellの焼き直しなんですけどね
2022/10/23(日) 20:01:27.37ID:608cGiLj
原理試作と実用製品の関係みたいなもん
2022/10/23(日) 20:52:58.51ID:Ru+lcIaK
DelphiとC#とTypeScriptの関係みたいなもんでしょ
780デフォルトの名無しさん
垢版 |
2022/10/23(日) 22:33:19.11ID:u5B1k/fb
>>776
InvalidArgumentみたいな標準的なのを各レイヤーごとにいちいち自分で名前決めて定義しないといけないのはどうかと思う

プロジェクトがかわってもRust使ってる場合に標準的に使えるエラー型は用意して欲しい
まあanyhowレベルで浸透するならcrateの形でも提供でもいい
781デフォルトの名無しさん
垢版 |
2022/10/24(月) 00:00:17.86ID:c7GaYtEs
うむ
2022/10/24(月) 08:19:36.09ID:vANHr58d
もう少し例外を使用しても良いのではないか...
https://qiita.com/MasayaMizuhara/items/98c0d490f1633d9b636f
例外処理は処理コストが掛かるらしいことを確かめようとしたら、意外とそうでもなかった話]
https://katzchang.hatenadiary.org/entry/20081021/p1
2022/10/24(月) 08:44:13.82ID:Nh76Mk4a
let hoge
try {
hoge = maybeThrow()
} catch (err)
{
エラー処理
}

hogeをここで使用

スコープが分断されるのが嫌い
かといって全部try catchでまとめて囲むのも嫌だ
2022/10/24(月) 11:09:28.71ID:SEdanpUe
それ以上の描き方思いつかないならそれで我慢しろとしか言いようがねえな
2022/10/24(月) 12:54:58.71ID:kFwD+FAK
try {
const hage = ......
// ここでハゲる
}
catch .....
2022/10/24(月) 13:45:05.88ID:SEdanpUe
思いついてやったぞ
3項演算子みたいに書けるトライキャッチがあればいいんだろう
2022/10/24(月) 13:46:20.16ID:rCA25jH/
なんでこっちにしなかったんだろう
スコープを考えたら絶対こっちの方が良いのに

try {
.....
catch (e) {
.....
}
}
2022/10/24(月) 13:47:17.46ID:SEdanpUe
ラムザキャッチと名付ける
2022/10/24(月) 13:50:06.34ID:SEdanpUe
let hoge = maybeThrow() ? catch(err){
//エラー処理１
//エラー処理２
//エラー処理３
};

こういう見映えだとラムダ式に似てるだろ
790デフォルトの名無しさん
垢版 |
2022/10/24(月) 18:46:24.56ID:8+UVFZyO
>>787
それも少し数増えたら見づらいだろ。
2022/10/24(月) 19:24:34.71ID:m3/1dAn6
そうか？

case e => HogeException
case e => FugaException

みたいにすればすげーわかりやすい気がするが
この構文は前から俺が温めていたものだ
特に出す機会はないがw
2022/10/24(月) 19:29:48.11ID:LLDppSf/
>>787
例外ってすげー祖先まで遡る事もあるって知らないの？
2022/10/24(月) 22:37:32.41ID:J+qP7U3e
stderrに文字を書き込んでexitしてもターミナルは終了しない
というマルチタスク的なUIを

シングルタスクで擬似的に再発明する機能がcatchだ
catchしなければ全部終了するから
2022/10/30(日) 13:17:58.74ID:bFRBVv52
多分岐を前提としたエラーハンドリングはクソだと思うわ
GoやTSみたいに基本一つで必要に応じてエラーハンドラの中で分岐でいい
795デフォルトの名無しさん
垢版 |
2022/10/30(日) 20:11:15.05ID:LsgJ3Yzj
>>794
それ、エラーハンドリングの書き方の違いで結局多分岐じゃん
2022/10/30(日) 20:17:26.90ID:mEHydPb0
スタックフレームを遡る時点でとんでもない副作用だから
今の時代にはふさわしくないわな
2022/10/30(日) 21:12:37.95ID:A2hghp/9
副作用？
798デフォルトの名無しさん
垢版 |
2022/10/30(日) 21:21:33.37ID:+1c8jgme
日本ではどっちもサッパリだけど海外だとZig＞＞＞Nimだな
次スレはNim外してZigでよろしく
799デフォルトの名無しさん
垢版 |
2022/10/30(日) 21:21:43.43ID:+1c8jgme
日本ではどっちもサッパリだけど海外だとZig＞＞＞Nimだな
次スレはNim外してZigでよろしく
2022/10/30(日) 21:24:41.43ID:d1FOMSru
例外は重いから出来るだけ避けたい
2022/10/30(日) 21:52:12.74ID:mEHydPb0
やたらZig人気あるけど理解できん
構文もそんなにわかりやすいか？
802デフォルトの名無しさん
垢版 |
2022/10/31(月) 00:55:44.52ID:8RrIgicz
ZigはZenでケチついたけど、トラブルは片付いたのかね？
2022/10/31(月) 06:43:44.47ID:4lYEr6WH
Zenなんて無視でいいだろｗ
2022/10/31(月) 06:49:37.53ID:gpqFhr3z
じゃあ、Bun の話
805デフォルトの名無しさん
垢版 |
2022/10/31(月) 12:50:48.82ID:+v2gX208
Goは日付フォーマットがウンコ
806デフォルトの名無しさん
垢版 |
2022/10/31(月) 14:07:28.91ID:ghuRVpi7
>>794
ワロタw
問題の本質を分かってない
Go推奨してるやつの半分以上はこのレベルなんだよなぁ
2022/10/31(月) 23:47:17.25ID:rwQMN8uU
いつも通り
何か言ってそうで 何も言ってなくて

ワロタw
2022/11/01(火) 16:40:48.61ID:1fqXVNhi
>>806
問題の本質を教えてくれないか？
2022/11/02(水) 02:06:41.97ID:S5a8978Q
本物のスコットランド人論法やな
2022/11/02(水) 08:42:08.53ID:EJy9x2LF
>>794はJavaですら catch (IOException | SQLException ex) とか書けるのを知らないアホ
2022/11/02(水) 09:32:19.73ID:jjpE9iF+
>>810
それはまさにJavaのcatchが多分岐を前提にしているからこそ必要になった構文だよね
後から追加されたってことは実際に多くの人が「多分岐を前提としたエラーハンドリングはクソ」と感じていたということでしょ
バカにされたからって無理筋でつっかかるなよみっともない
2022/11/02(水) 10:05:26.78ID:E44dP1ZR
本質を選択する
本質に集中する

メンバーを書かなければ中身のないただの箱になる
2022/11/02(水) 12:50:51.28ID:k32CSUhG
>>811
いや
多分岐は全然オッケーだけどまとめたい時もあるよねというだけ
814デフォルトの名無しさん
垢版 |
2022/11/02(水) 13:33:21.09ID:2ZJAy0Zn
そもそも多分岐を前提としてないエラーハンドリングなんてないからw
2022/11/02(水) 15:11:19.41ID:W1v41eym
>>814
多分岐を想定してるのと多分岐が大前提でデフォなのはデザインの志向としては全然違うでしょ
例えばGoの言語仕様をデザインする上でそりゃ多分岐のエラーハンドリングを想定していないわけはないけど、結果としてエラーの多分岐に対する第一級のサポートは何もない
816デフォルトの名無しさん
垢版 |
2022/11/02(水) 18:28:17.60ID:GwKq235T
スマン、こいつの言ってる多分岐のエラーハンドリングってはいったいどういうコードなのか誰かエスパーしてくれんか。
2022/11/02(水) 18:33:51.20ID:m8w2BBVr
そもそも「多分岐」ってワードが聞き慣れないので
話が耳に入ってこない
自分で言葉作っちゃうやつと議論してもムダに終わる
2022/11/02(水) 18:44:46.71ID:ZqFrwRdn
>>816
catch (〜) {
}
catch (〜) {
}
...

みたいなのじゃね？
こっちの方が中でifするよりネストが減ってエレガントだよね
2022/11/02(水) 18:52:44.54ID:OGyWRdOS
>>818
tryのネストがあるだろ。
ネストの深さだけでいうとifのほうがどちらかというと分があるんじゃね。

Goのエラー処理は、そもそも大域脱出したいとかスタックトレースをたどらないといけないような呼び出し階層の深いコード書くなというメッセージ的な側面もありそう。
2022/11/02(水) 18:56:30.02ID:oICVsRnV
>>819
tryのネスト？
try {
try {
...
こんなコード書く人居る？？？？？？
2022/11/02(水) 19:01:47.22ID:oICVsRnV
まあ呼び出し階層を削減しろって意見は分からんでもないが
それはエラーハンドリングとは別ベクトルの問題だろ
2022/11/02(水) 19:13:58.62ID:jyU6y3CY
>>808
そんなことよりこれへの回答まだ？
823デフォルトの名無しさん
垢版 |
2022/11/02(水) 19:17:17.91ID:j64WQohl
typescriptの可能性は無限大やで

「Webpack」より700倍高速な次世代バンドルツール「Turbopack」が登場
https://gigazine.net/news/20221102-turbopack-webpack-javascript-rust/
824デフォルトの名無しさん
垢版 |
2022/11/02(水) 19:45:11.50ID:HzsLyTHT
Rustの可能性、なｗ
2022/11/02(水) 19:45:24.48ID:qyHEkcPy
typescriptなんかマジで要らないｗ
2022/11/02(水) 20:02:06.24ID:5K2+hbiB
Webで型なんかいるか？
型チェックしてエラーになっても死ぬのは許されないから
適当にごまかす処理を書くしかない
厳密なチェックしてもかえって厄介であんまり意味ないと思うんだよな
2022/11/02(水) 20:03:05.34ID:5K2+hbiB
>>826
俺はOption型強制ぐらいで十分だと思ってる
828デフォルトの名無しさん
垢版 |
2022/11/02(水) 20:49:43.63ID:xJvT1Cbm
IsやAsやtype switchやvalue switch使って
シコシコと手動でネストさせたコードを書かなきゃいけないのがクソじゃなかったらなんなんだろうな
2022/11/02(水) 21:14:35.40ID:92BXP9jc
>>823
Typescriptは文法好きだけどこうやってあっという間にエコシステム入れ替わるから真面目なバックエンド、ビジネスでは使えんのよね
フロントはいつか総とっかえするからまあいいかって感じだけど
2022/11/02(水) 21:34:50.83ID:t/iark2f
「シェルピンスキーのギャスケット」を描画する機会はあまり無いのでは
2022/11/02(水) 22:02:22.20ID:E44dP1ZR
extern "C" 以外のABIが意味不明 → 全部静的リンク → 一部変更があれば全部入れ替える
2022/11/02(水) 22:17:31.20ID:jyU6y3CY
正直ここまでコンパイル前提にするならJSとの互換性なくても良くねーか？
開発者のレベルが上がってるし
そこはもう割り切ってやろうよ
2022/11/02(水) 22:45:19.27ID:jjpE9iF+
TypeScriptには変換後のJSに対してハックを入れない(ただしbabelを目的とする場合は除く)というポリシーがあるようで、
JSに対する後方互換性よりもそっちの方が重い足枷になっている
2022/11/02(水) 22:48:25.19ID:1ThO0l2A
>>829
新しいものが出てきたからってすぐに乗り換える必要はないんだぜ？
2022/11/02(水) 23:13:38.47ID:92BXP9jc
>>834
新しく始めるときにあれ前とテンプレが違う、、、ってのが最悪なのよ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況