次世代言語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/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はいつ頃バージョン１になるの？

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

0.1アップするのに10ヶ月かかったことから計算すれば
1 = 0.100.0 とすると
72年後くらい

**デフォルトの名無しさん** · 2022/11/04(金) 20:58:27.13

そんくらいは人月の威力でどうにかなるでしょ
作業者が10人だとすれば72年
100人で7年
700人だと1年

世界中から参加者を募ると爆速になる

**デフォルトの名無しさん** · 2022/11/04(金) 21:02:53.82

じゃお願いします

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

「人月の威力 - 納期を短くする銀の弾丸」フレデリック・ブラックス

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

低位な階層のライブラリがそろえば、
高位階層のライブラリ開発・機能実装が捗り、
メジャーアップデートは目に見えて進むことであろう

**デフォルトの名無しさん** · 2022/11/04(金) 23:47:10.54

その前提条件はどうやって満たされるかと言うと、やっぱり集まる人数が増えるからじゃなかろうか

**デフォルトの名無しさん** · 2022/11/04(金) 23:48:12.30

前提条件ってのは低レベルライブラリのことな

**デフォルトの名無しさん** · 2022/11/04(金) 23:56:01.86

もちろん、あらゆるプロジェクトに共通する事だが
「そうであったらいいなあ」という願望を含む

**デフォルトの名無しさん** · 2022/11/05(土) 00:52:15.14

>>729
流行ってないのは確かだが
流行れば良いってもんでもない

**デフォルトの名無しさん** · 2022/11/05(土) 01:28:25.52

良い言語であれば流行る🦍

**デフォルトの名無しさん** · 2022/11/05(土) 07:01:26.55

>>729
GCのせい

**デフォルトの名無しさん** · 2022/11/05(土) 12:58:03.66

良い言語が流行るんじゃないんだ
流行った言語が良い言語なんだ

**デフォルトの名無しさん** · 2022/11/05(土) 13:26:33.21

なぜ流行ったかとするとやっぱり魅惑的な音の響きだな
つまり人前で堂々とパイパイと発音すること自体が主目的だ

**デフォルトの名無しさん** · 2022/11/05(土) 18:40:47.55

やっぱりキラーフレームワークやライブラリがないといかんね
大抵流行ったもんにはそういうのがつきもんや

**デフォルトの名無しさん** · 2022/11/06(日) 00:14:21.72

じゃあニムの推しってどういうところなんだ？

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

GCするなら思い切ってbetter pythonに舵を切っても良いと思うが
python使いならトランスパイラとか気にしないだろうし

**デフォルトの名無しさん** · 2022/11/06(日) 06:32:56.43

GCといえば結局V言語は詐欺だったの？

**デフォルトの名無しさん** · 2022/11/06(日) 06:49:26.74

https://github.com/Naotonosato/Clawn
> メモリ管理
> Clawnはプログラム中の値の依存関係を静的に検証し、適切なタイミングでメモリの確保と解放を行うコードを自動的に挿入するメモリ管理機構を持っているため、プログラマがメモリについて意識する必要はありません。
>
> ただし、この機能は実験的で今後さらなる安定化及び最適化がなされる予定です。

次はClawn++でその次がDlawnかな？Clawn#かも
高校生だと思うんだけど勉強大丈夫なのかな？
開成中からどこ進んだんだろ？

**デフォルトの名無しさん** · 2022/11/06(日) 12:19:42.02

>>874
お前本人だろ

**.NET MAUI HighSchool** · 2022/11/06(日) 12:32:44.00

素直にC#使っとけばいいんだよ

**デフォルトの名無しさん** · 2022/11/06(日) 12:36:10.71

まあ確かにバックエンド、コンソール、Windowsデスクトップ、マルチプラットフォームならC#で良いと思う
でもフロントはやっぱReact使いたいんだわ
React.NETがあれば移行するんだけどねC#はXMLリテラルが無いから難しいだろうな

**デフォルトの名無しさん** · 2022/11/06(日) 18:08:14.48

>>877
XMLリテラルなんてJavaScriptにもないが。
JSXのことならあれプリプロセスで事前に単純な関数呼び出しに変換（たいていBabelで）してるだけだぞ？
<Foo><Bar attr1="test"/></Foo>
↓
React.createElement(Foo, null, React.createElement(Bar, {
attr1: "test"
}));
難しいもクソもない
プリプロセスなんだからあらゆる言語に同等なものを作れるだろう
価値を見出だされないないから作られないだけで

**デフォルトの名無しさん** · 2022/11/06(日) 18:19:41.71

>>878
プリプロセスで処理されるとか具体的な解析実装はどうでもよくて
TSXという言語の文法としてはあの要素はXMLリテラルとしか言いようがないだろう

**デフォルトの名無しさん** · 2022/11/06(日) 18:46:39.02

>>879
じゃXML使ったテンプレートエンジンじゃダメなの？
というかフロントでC#が使われないのはXMLリテラル（）のあるなしの問題じゃないんだけどな
つまり>>877の
> でもフロントはやっぱReact使いたいんだわ
> React.NETがあれば移行するんだけどねC#はXMLリテラルが無いから難しいだろうな
だと、暗にC#にXMLリテラルが無いからC#でReactみたいに書けるReact.NETのようなものが出ないと言ってるようだが、
そうではなく単純にパフォーマンスとランタイムの容量の問題でやってないだけ（あるいはあるのかもしれないけど流行ってないだけ）だと思うよ
C#をフロントで動かすわけだから
知らんけどBlazorとかで挑戦したんじゃないの？
でも流行らなかったのは詰まるところこれでしょ

**デフォルトの名無しさん** · 2022/11/06(日) 18:57:13.32

うわ

**デフォルトの名無しさん** · 2022/11/06(日) 19:06:37.80

人気の機能なら、フレームワークが対応するだろ

**デフォルトの名無しさん** · 2022/11/10(木) 01:33:05.52

Rustでメモリリーク、あれれ？
https://github.com/lapce/lapce/issues/1668

**デフォルトの名無しさん** · 2022/11/10(木) 09:48:20.76

メモリリークなのかそれ？

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

rustはメモリリークを防ぐ事を目標とはしません。

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

メモリリークはRustにおいてはメモリ安全であることを意味します。

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

そもそも誰かが安全を約束した記憶がないぞ

まずは記録、次に記憶、最後に安全だ

**デフォルトの名無しさん** · 2022/11/10(木) 19:37:50.25

>>886
*メモリリーク除く
て書くべきだよなぁ。

**デフォルトの名無しさん** · 2022/11/11(金) 09:36:33.47

つまり漏れても安全と

**デフォルトの名無しさん** · 2022/11/11(金) 09:53:10.02

問題は2種類ある
消してはいけない記憶を消すのは安全か？
記憶を消した方が得なのに記憶が残っているのは安全か？

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

Rustならメモリーリークがあっても安心安全なんだよ

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

>>891
これ、皮肉じゃなくてまじだから

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

メモリリークってメモリ安全ではないだろ
Rustのメモリ安全性に対する立場誤魔化しすぎやわ

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

メモリリークって処理系が対処しうる脆弱性なのかね。
どんな言語使ってもそこはアプリケーション開発者の責任にせざるを得ない気がする。

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

メモリリークで迷惑すんのはOSやユーザなのに
何言ってんだ

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

まぁよくあるのがイベントハンドラとかの登録解除忘れで
これはGCでも回収できないよね
そういう意味でもメモリリークは安全性に含まないという立場は妥当だと思うけど
（含めてもいいけど、そうすると全部の言語が不安全ということになるからあまり意味ない）

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

それはリソースリーク。広義のメモリリークかもしれんが

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

言語処理系自身がどのように努力しても回収できないメモリリークは言語処理系自身のバグでしょ
イベントハンドラの登録解除はプログラマが努力すればリークは防げる
ただrustにはプログラマがどのように努力しても解放できないメモリリークが存在する
だからrustはメモリ安全ではない

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

トロッコ問題も2種類ある
命に関わらないケースでじゃんじゃん犠牲者を出すタイプ
命に関わる時だけ突然必要悪や合理主義について語り出すタイプ

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

トロッコの定義がありません

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

メモリ安全性についてRustばかり注目されてるけど、Ponyも同等以上の安全性だよね
Ponyはアクターモデルで実現している

**デフォルトの名無しさん** · 2022/11/12(土) 14:24:46.04

>>901
アクターモデルの作り方わかってる？
アクターひとつひとつメッセージ待ち受けのループまわするだぜ？負荷が違いすぎるだろ

**デフォルトの名無しさん** · 2022/11/12(土) 14:36:15.84

Ponyはループで待ってんの？
普通はselectとか使うんでは？

**デフォルトの名無しさん** · 2022/11/12(土) 15:48:42.14

>>903
お前はポーリングと勘違いしてそう

**デフォルトの名無しさん** · 2022/11/13(日) 01:05:00.14

>>904
man selectして言ってる？

**デフォルトの名無しさん** · 2022/11/13(日) 04:27:18.51

https://www.theregister.com/2022/11/11/nsa_urges_orgs_to_use/
> NSA は、組織が C や C++ などのプログラミング言語から、C#、Rust、Go、Java、Ruby、Swift などのメモリセーフな代替言語に移行することを奨励するガイダンスをリリースしました。

るるる、るびぃｗｗｗｗｗ

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

いつの間にかC++とか本屋で入門書すら売られてないんだよな

**デフォルトの名無しさん** · 2022/11/13(日) 14:20:01.12

>>907
でかい本屋しか売ってないね
しかも売れてなさそう

**デフォルトの名無しさん** · 2022/11/13(日) 15:04:33.03

まあ今から最初の言語としてC/C++選ぶのはかなりレアだろうししゃーないわな

**デフォルトの名無しさん** · 2022/11/13(日) 17:21:55.25

いやいや C や C++ は人気上位言語なので
入門書が売れすぎて品不足になっているだけ

**デフォルトの名無しさん** · 2022/11/13(日) 17:58:48.98

arduinoとかで使ってるCにちょっとC++要素が入ってる言語が丁度良い感じする