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

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

Nodeみたいにシングルスレッドなのであれば例外も扱えることができるが
これを両立してる言語は存在しないね
0763デフォルトの名無しさん
垢版 |
2022/10/23(日) 13:46:11.16ID:NS3+KJ7P
実際、D言語にはGCがあるけど、LLVMを使ってるLDCでコンパイルすれば
C++にかなり近い実行速度になるし、GCはそんなに遅くない気はする
0767デフォルトの名無しさん
垢版 |
2022/10/23(日) 14:13:26.72ID:ioVOctq2
>>754
別に書き換える必要はないと思うよ
新規で始めるならGoとかRust使った方が面白いのではないかと言うこと
0768デフォルトの名無しさん
垢版 |
2022/10/23(日) 14:51:49.61ID:/lSuGz6a
そもそもJavaとWebって相性が悪い
なぜならオブジェクト指向とWebの相性がそもそも悪いから
アホがOOPを意識して書くとオーバーエンジリアリングになりがちで、基本的に手続型の方が適してる
Spring Bootとか重厚すぎて終わってる
OOPが向いてるのはGUIとか

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

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

漏れやすいのは確かだけど、エラー表現が全く統一されてないC、C++に比べると圧倒的に楽なのは事実
0776デフォルトの名無しさん
垢版 |
2022/10/23(日) 19:26:33.97ID:HOBBKeJ+
Rustのエラー処理に慣れると他の言語使えんよ
anyhowとthiserrorのコンボこそあらゆるプログラミング言語のエラー処理のエデンと感じる
0780デフォルトの名無しさん
垢版 |
2022/10/23(日) 22:33:19.11ID:u5B1k/fb
>>776
InvalidArgumentみたいな標準的なのを各レイヤーごとにいちいち自分で名前決めて定義しないといけないのはどうかと思う

プロジェクトがかわってもRust使ってる場合に標準的に使えるエラー型は用意して欲しい
まあanyhowレベルで浸透するならcrateの形でも提供でもいい
0781デフォルトの名無しさん
垢版 |
2022/10/24(月) 00:00:17.86ID:c7GaYtEs
うむ
0783デフォルトの名無しさん
垢版 |
2022/10/24(月) 08:44:13.82ID:Nh76Mk4a
let hoge
try {
hoge = maybeThrow()
} catch (err)
{
エラー処理
}

hogeをここで使用

スコープが分断されるのが嫌い
かといって全部try catchでまとめて囲むのも嫌だ
0786デフォルトの名無しさん
垢版 |
2022/10/24(月) 13:45:05.88ID:SEdanpUe
思いついてやったぞ
3項演算子みたいに書けるトライキャッチがあればいいんだろう
0787デフォルトの名無しさん
垢版 |
2022/10/24(月) 13:46:20.16ID:rCA25jH/
なんでこっちにしなかったんだろう
スコープを考えたら絶対こっちの方が良いのに

try {
.....
catch (e) {
.....
}
}
0789デフォルトの名無しさん
垢版 |
2022/10/24(月) 13:50:06.34ID:SEdanpUe
let hoge = maybeThrow() ? catch(err){
//エラー処理１
//エラー処理２
//エラー処理３
};

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

case e => HogeException
case e => FugaException

みたいにすればすげーわかりやすい気がするが
この構文は前から俺が温めていたものだ
特に出す機会はないがw
0793デフォルトの名無しさん
垢版 |
2022/10/24(月) 22:37:32.41ID:J+qP7U3e
stderrに文字を書き込んでexitしてもターミナルは終了しない
というマルチタスク的なUIを

シングルタスクで擬似的に再発明する機能がcatchだ
catchしなければ全部終了するから
0794デフォルトの名無しさん
垢版 |
2022/10/30(日) 13:17:58.74ID:bFRBVv52
多分岐を前提としたエラーハンドリングはクソだと思うわ
GoやTSみたいに基本一つで必要に応じてエラーハンドラの中で分岐でいい
0795デフォルトの名無しさん
垢版 |
2022/10/30(日) 20:11:15.05ID:LsgJ3Yzj
>>794
それ、エラーハンドリングの書き方の違いで結局多分岐じゃん
0796デフォルトの名無しさん
垢版 |
2022/10/30(日) 20:17:26.90ID:mEHydPb0
スタックフレームを遡る時点でとんでもない副作用だから
今の時代にはふさわしくないわな
0798デフォルトの名無しさん
垢版 |
2022/10/30(日) 21:21:33.37ID:+1c8jgme
日本ではどっちもサッパリだけど海外だとZig＞＞＞Nimだな
次スレはNim外してZigでよろしく
0799デフォルトの名無しさん
垢版 |
2022/10/30(日) 21:21:43.43ID:+1c8jgme
日本ではどっちもサッパリだけど海外だとZig＞＞＞Nimだな
次スレはNim外してZigでよろしく
0802デフォルトの名無しさん
垢版 |
2022/10/31(月) 00:55:44.52ID:8RrIgicz
ZigはZenでケチついたけど、トラブルは片付いたのかね？
0805デフォルトの名無しさん
垢版 |
2022/10/31(月) 12:50:48.82ID:+v2gX208
Goは日付フォーマットがウンコ
0806デフォルトの名無しさん
垢版 |
2022/10/31(月) 14:07:28.91ID:ghuRVpi7
>>794
ワロタw
問題の本質を分かってない
Go推奨してるやつの半分以上はこのレベルなんだよなぁ
0811デフォルトの名無しさん
垢版 |
2022/11/02(水) 09:32:19.73ID:jjpE9iF+
>>810
それはまさにJavaのcatchが多分岐を前提にしているからこそ必要になった構文だよね
後から追加されたってことは実際に多くの人が「多分岐を前提としたエラーハンドリングはクソ」と感じていたということでしょ
バカにされたからって無理筋でつっかかるなよみっともない
0812デフォルトの名無しさん
垢版 |
2022/11/02(水) 10:05:26.78ID:E44dP1ZR
本質を選択する
本質に集中する

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

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

Goのエラー処理は、そもそも大域脱出したいとかスタックトレースをたどらないといけないような呼び出し階層の深いコード書くなというメッセージ的な側面もありそう。
0821デフォルトの名無しさん
垢版 |
2022/11/02(水) 19:01:47.22ID:oICVsRnV
まあ呼び出し階層を削減しろって意見は分からんでもないが
それはエラーハンドリングとは別ベクトルの問題だろ
0824デフォルトの名無しさん
垢版 |
2022/11/02(水) 19:45:11.50ID:HzsLyTHT
Rustの可能性、なｗ
0826デフォルトの名無しさん
垢版 |
2022/11/02(水) 20:02:06.24ID:5K2+hbiB
Webで型なんかいるか？
型チェックしてエラーになっても死ぬのは許されないから
適当にごまかす処理を書くしかない
厳密なチェックしてもかえって厄介であんまり意味ないと思うんだよな
0828デフォルトの名無しさん
垢版 |
2022/11/02(水) 20:49:43.63ID:xJvT1Cbm
IsやAsやtype switchやvalue switch使って
シコシコと手動でネストさせたコードを書かなきゃいけないのがクソじゃなかったらなんなんだろうな
0829デフォルトの名無しさん
垢版 |
2022/11/02(水) 21:14:35.40ID:92BXP9jc
>>823
Typescriptは文法好きだけどこうやってあっという間にエコシステム入れ替わるから真面目なバックエンド、ビジネスでは使えんのよね
フロントはいつか総とっかえするからまあいいかって感じだけど
0831デフォルトの名無しさん
垢版 |
2022/11/02(水) 22:02:22.20ID:E44dP1ZR
extern "C" 以外のABIが意味不明 → 全部静的リンク → 一部変更があれば全部入れ替える
0832デフォルトの名無しさん
垢版 |
2022/11/02(水) 22:17:31.20ID:jyU6y3CY
正直ここまでコンパイル前提にするならJSとの互換性なくても良くねーか？
開発者のレベルが上がってるし
そこはもう割り切ってやろうよ
0833デフォルトの名無しさん
垢版 |
2022/11/02(水) 22:45:19.27ID:jjpE9iF+
TypeScriptには変換後のJSに対してハックを入れない(ただしbabelを目的とする場合は除く)というポリシーがあるようで、
JSに対する後方互換性よりもそっちの方が重い足枷になっている
0837.NET MAUI HighScool
垢版 |
2022/11/03(木) 11:03:31.92ID:P57hKE9o
すまん最近Blazor始めたけどTypeScript使うならC#使ったほうが良くね？って結論出てしまったわ
動的型付け言語だしオブジェクト指向だし作った人同じだし
0838.NET MAUI HighScool
垢版 |
2022/11/03(木) 11:05:23.52ID:P57hKE9o
>>825
C#でいいもんなw
C#はバックエンドで使用可能だからハイブリット運用が楽
Node.jsとかいらんかったんや
0839.NET MAUI HighScool
垢版 |
2022/11/03(木) 11:07:05.12ID:P57hKE9o
すまんなんか勢いで動的型付け言語って書いたけど静的型付けだったわ
0841デフォルトの名無しさん
垢版 |
2022/11/03(木) 11:44:07.71ID:tn2ZhR3p
ふつうは用途によって使い分けると思うがBlazorとか言っているからWebアプリの話か。
UIフレームワークがRazorってところがネックだな。WPFなんかが使えたら喜んで乗り換えるんだが。
0842.NET MAUI HighScool
垢版 |
2022/11/03(木) 12:02:08.40ID:P57hKE9o
>>841
これ
XAML最強！！
0844.NET MAUI HighScool
垢版 |
2022/11/03(木) 12:05:38.67ID:Kj7ywx2W
>>843
なぜ？
React使う必要ある？？？
0846.NET MAUI HighScool
垢版 |
2022/11/03(木) 12:44:06.01ID:Kj7ywx2W
>>845
？
ウェブコンポーネントの概念知らない？
0847デフォルトの名無しさん
垢版 |
2022/11/03(木) 12:59:20.91ID:tn2ZhR3p
>React使う必要ある？？？
>ウェブコンポーネントの概念知らない？

この2つの質問はどう繋がっているんだろう？
0848.NET MAUI HighScool
垢版 |
2022/11/03(木) 13:06:37.73ID:fiCeisHS
>>847
Reactを使う必要があるか？に対してHTML,CSSを使うのはめんどくさいからという問いが帰ってきたわけだな
それで俺はHTMLやCSSをゴリゴリ書く必要がないコンポーネント使えばよくね？
と返したわけだ
0849デフォルトの名無しさん
垢版 |
2022/11/03(木) 13:13:35.86ID:tn2ZhR3p
>ウェブコンポーネントの概念知らない？

が

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

という意味だったと？
わかんねーよｗ
0850.NET MAUI HighScool
垢版 |
2022/11/03(木) 13:21:39.39ID:lb4yYaZW
まぁ伝わりづらかったのはすまんと思ってる
だがまぁ言いたいことは伝わったしいいや
0853デフォルトの名無しさん
垢版 |
2022/11/04(金) 17:16:01.21ID:GPuumgjE
うねいへの要望

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

開封を楽しむゲームじゃないんだから、ユーザの気持ちを考えて、ちゃんと利便性を上げるように！
0857デフォルトの名無しさん
垢版 |
2022/11/04(金) 19:56:14.70ID:5+z9Ldzg
0.1アップするのに10ヶ月かかったことから計算すれば
1 = 0.100.0 とすると
72年後くらい
0858デフォルトの名無しさん
垢版 |
2022/11/04(金) 20:58:27.13ID:DH/gCa9u
そんくらいは人月の威力でどうにかなるでしょ
作業者が10人だとすれば72年
100人で7年
700人だと1年

世界中から参加者を募ると爆速になる
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況