次世代言語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/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みたいに基本一つで必要に応じてエラーハンドラの中で分岐でいい

**デフォルトの名無しさん** · 2022/10/30(日) 20:11:15.05

>>794
それ、エラーハンドリングの書き方の違いで結局多分岐じゃん

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

スタックフレームを遡る時点でとんでもない副作用だから
今の時代にはふさわしくないわな

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

副作用？

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

日本ではどっちもサッパリだけど海外だとZig＞＞＞Nimだな
次スレはNim外してZigでよろしく

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

日本ではどっちもサッパリだけど海外だとZig＞＞＞Nimだな
次スレはNim外してZigでよろしく

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

例外は重いから出来るだけ避けたい

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

やたらZig人気あるけど理解できん
構文もそんなにわかりやすいか？

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

ZigはZenでケチついたけど、トラブルは片付いたのかね？

**デフォルトの名無しさん** · 2022/10/31(月) 06:43:44.47

Zenなんて無視でいいだろｗ

**デフォルトの名無しさん** · 2022/10/31(月) 06:49:37.53

じゃあ、Bun の話

**デフォルトの名無しさん** · 2022/10/31(月) 12:50:48.82

Goは日付フォーマットがウンコ

**デフォルトの名無しさん** · 2022/10/31(月) 14:07:28.91

>>794
ワロタw
問題の本質を分かってない
Go推奨してるやつの半分以上はこのレベルなんだよなぁ

**デフォルトの名無しさん** · 2022/10/31(月) 23:47:17.25

いつも通り
何か言ってそうで何も言ってなくて

ワロタw

**デフォルトの名無しさん** · 2022/11/01(火) 16:40:48.61

>>806
問題の本質を教えてくれないか？

**デフォルトの名無しさん** · 2022/11/02(水) 02:06:41.97

本物のスコットランド人論法やな

**デフォルトの名無しさん** · 2022/11/02(水) 08:42:08.53

>>794はJavaですら catch (IOException | SQLException ex) とか書けるのを知らないアホ

**デフォルトの名無しさん** · 2022/11/02(水) 09:32:19.73

>>810
それはまさにJavaのcatchが多分岐を前提にしているからこそ必要になった構文だよね
後から追加されたってことは実際に多くの人が「多分岐を前提としたエラーハンドリングはクソ」と感じていたということでしょ
バカにされたからって無理筋でつっかかるなよみっともない

**デフォルトの名無しさん** · 2022/11/02(水) 10:05:26.78

本質を選択する
本質に集中する

メンバーを書かなければ中身のないただの箱になる

**デフォルトの名無しさん** · 2022/11/02(水) 12:50:51.28

>>811
いや
多分岐は全然オッケーだけどまとめたい時もあるよねというだけ

**デフォルトの名無しさん** · 2022/11/02(水) 13:33:21.09

そもそも多分岐を前提としてないエラーハンドリングなんてないからw

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

>>814
多分岐を想定してるのと多分岐が大前提でデフォなのはデザインの志向としては全然違うでしょ
例えばGoの言語仕様をデザインする上でそりゃ多分岐のエラーハンドリングを想定していないわけはないけど、結果としてエラーの多分岐に対する第一級のサポートは何もない

**デフォルトの名無しさん** · 2022/11/02(水) 18:28:17.60

スマン、こいつの言ってる多分岐のエラーハンドリングってはいったいどういうコードなのか誰かエスパーしてくれんか。

**デフォルトの名無しさん** · 2022/11/02(水) 18:33:51.20

そもそも「多分岐」ってワードが聞き慣れないので
話が耳に入ってこない
自分で言葉作っちゃうやつと議論してもムダに終わる

**デフォルトの名無しさん** · 2022/11/02(水) 18:44:46.71

>>816
catch (～) {
}
catch (～) {
}
...

みたいなのじゃね？
こっちの方が中でifするよりネストが減ってエレガントだよね

**デフォルトの名無しさん** · 2022/11/02(水) 18:52:44.54

>>818
tryのネストがあるだろ。
ネストの深さだけでいうとifのほうがどちらかというと分があるんじゃね。

Goのエラー処理は、そもそも大域脱出したいとかスタックトレースをたどらないといけないような呼び出し階層の深いコード書くなというメッセージ的な側面もありそう。

**デフォルトの名無しさん** · 2022/11/02(水) 18:56:30.02

>>819
tryのネスト？
try {
try {
...
こんなコード書く人居る？？？？？？

**デフォルトの名無しさん** · 2022/11/02(水) 19:01:47.22

まあ呼び出し階層を削減しろって意見は分からんでもないが
それはエラーハンドリングとは別ベクトルの問題だろ

**デフォルトの名無しさん** · 2022/11/02(水) 19:13:58.62

>>808
そんなことよりこれへの回答まだ？

**デフォルトの名無しさん** · 2022/11/02(水) 19:17:17.91

typescriptの可能性は無限大やで

「Webpack」より700倍高速な次世代バンドルツール「Turbopack」が登場
https://gigazine.net/news/20221102-turbopack-webpack-javascript-rust/

**デフォルトの名無しさん** · 2022/11/02(水) 19:45:11.50

Rustの可能性、なｗ

**デフォルトの名無しさん** · 2022/11/02(水) 19:45:24.48

typescriptなんかマジで要らないｗ

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

Webで型なんかいるか？
型チェックしてエラーになっても死ぬのは許されないから
適当にごまかす処理を書くしかない
厳密なチェックしてもかえって厄介であんまり意味ないと思うんだよな

**デフォルトの名無しさん** · 2022/11/02(水) 20:03:05.34

>>826
俺はOption型強制ぐらいで十分だと思ってる

**デフォルトの名無しさん** · 2022/11/02(水) 20:49:43.63

IsやAsやtype switchやvalue switch使って
シコシコと手動でネストさせたコードを書かなきゃいけないのがクソじゃなかったらなんなんだろうな

**デフォルトの名無しさん** · 2022/11/02(水) 21:14:35.40

>>823
Typescriptは文法好きだけどこうやってあっという間にエコシステム入れ替わるから真面目なバックエンド、ビジネスでは使えんのよね
フロントはいつか総とっかえするからまあいいかって感じだけど

**デフォルトの名無しさん** · 2022/11/02(水) 21:34:50.83

「シェルピンスキーのギャスケット」を描画する機会はあまり無いのでは

**デフォルトの名無しさん** · 2022/11/02(水) 22:02:22.20

extern "C" 以外のABIが意味不明 → 全部静的リンク → 一部変更があれば全部入れ替える

**デフォルトの名無しさん** · 2022/11/02(水) 22:17:31.20

正直ここまでコンパイル前提にするならJSとの互換性なくても良くねーか？
開発者のレベルが上がってるし
そこはもう割り切ってやろうよ

**デフォルトの名無しさん** · 2022/11/02(水) 22:45:19.27

TypeScriptには変換後のJSに対してハックを入れない(ただしbabelを目的とする場合は除く)というポリシーがあるようで、
JSに対する後方互換性よりもそっちの方が重い足枷になっている

**デフォルトの名無しさん** · 2022/11/02(水) 22:48:25.19

>>829
新しいものが出てきたからってすぐに乗り換える必要はないんだぜ？

**デフォルトの名無しさん** · 2022/11/02(水) 23:13:38.47

>>834
新しく始めるときにあれ前とテンプレが違う、、、ってのが最悪なのよ

**デフォルトの名無しさん** · 2022/11/02(水) 23:23:41.46

誰が変えるんだよ？変えなきゃいいだけ。

**.NET MAUI HighScool** · 2022/11/03(木) 11:03:31.92

すまん最近Blazor始めたけどTypeScript使うならC#使ったほうが良くね？って結論出てしまったわ
動的型付け言語だしオブジェクト指向だし作った人同じだし

**.NET MAUI HighScool** · 2022/11/03(木) 11:05:23.52

>>825
C#でいいもんなw
C#はバックエンドで使用可能だからハイブリット運用が楽
Node.jsとかいらんかったんや

**.NET MAUI HighScool** · 2022/11/03(木) 11:07:05.12

すまんなんか勢いで動的型付け言語って書いたけど静的型付けだったわ

**デフォルトの名無しさん** · 2022/11/03(木) 11:42:59.08

Blazorは面白いけど業務でお目にかかることはないだろう

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

ふつうは用途によって使い分けると思うがBlazorとか言っているからWebアプリの話か。
UIフレームワークがRazorってところがネックだな。WPFなんかが使えたら喜んで乗り換えるんだが。

**.NET MAUI HighScool** · 2022/11/03(木) 12:02:08.40

>>841
これ
XAML最強！！

**デフォルトの名無しさん** · 2022/11/03(木) 12:04:17.91

とは言ってもRazorしか使えない現状じゃあやっぱりReact+Typescriptだな。

**.NET MAUI HighScool** · 2022/11/03(木) 12:05:38.67

>>843
なぜ？
React使う必要ある？？？

**デフォルトの名無しさん** · 2022/11/03(木) 12:41:33.82

素のhtml/cssだけでWebアプリ組むのはさすがに大変なんで。

**.NET MAUI HighScool** · 2022/11/03(木) 12:44:06.01

>>845
？
ウェブコンポーネントの概念知らない？

**デフォルトの名無しさん** · 2022/11/03(木) 12:59:20.91

>React使う必要ある？？？
>ウェブコンポーネントの概念知らない？

この2つの質問はどう繋がっているんだろう？

**.NET MAUI HighScool** · 2022/11/03(木) 13:06:37.73

>>847
Reactを使う必要があるか？に対してHTML,CSSを使うのはめんどくさいからという問いが帰ってきたわけだな
それで俺はHTMLやCSSをゴリゴリ書く必要がないコンポーネント使えばよくね？
と返したわけだ

**デフォルトの名無しさん** · 2022/11/03(木) 13:13:35.86

>ウェブコンポーネントの概念知らない？

が

>それで俺はHTMLやCSSをゴリゴリ書く必要がないコンポーネント使えばよくね？

という意味だったと？
わかんねーよｗ

**.NET MAUI HighScool** · 2022/11/03(木) 13:21:39.39

まぁ伝わりづらかったのはすまんと思ってる
だがまぁ言いたいことは伝わったしいいや

**デフォルトの名無しさん** · 2022/11/03(木) 13:55:48.74

>>843
Razorも慣れると便利よ
Reactと違って直感的だしDIもサポートされてる

**デフォルトの名無しさん** · 2022/11/03(木) 15:08:12.26

Zig言語最新版 0.10.0 リリースされた
https://ziglang.org/download/

**デフォルトの名無しさん** · 2022/11/04(金) 17:16:01.21

うねいへの要望

・受け取りボックスの下の次ページと最終ページの間に次10ページと次100ページを追加する
・カードを選択した場合に、ピックアップ機能で絞り込んだ場合、絞り込み外をグレーアウトでなく非表示にする
・1つ1つ開封する機能に加えて、一斉開封機能を追加する
・開封したものがハロの場合、指定した機体に自動で合成する機能を追加する

開封を楽しむゲームじゃないんだから、ユーザの気持ちを考えて、ちゃんと利便性を上げるように！

**デフォルトの名無しさん** · 2022/11/04(金) 17:16:51.56

誤爆スマソ

**デフォルトの名無しさん** · 2022/11/04(金) 18:54:33.04

日本語版作成中

Zig 言語リファレンス
https://gist.github.com/voluntas/6febea855571bbe19901f0f096245adc

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

Zigはいつ頃バージョン１になるの？