TypeScript part4

**デフォルトの名無しさん** · 2022/06/30(木) 12:31:53.04

5chだと読みづらいからts playgroundなりcode sandboxなりに書いて欲しい

**デフォルトの名無しさん** · 2022/06/30(木) 12:53:38.41

>>165　です。
すみません。かなり省略して、改行も削除しました。
伝えたかったのは、以下です。
https://tsplay.dev/WJyrDm

**デフォルトの名無しさん** · 2022/08/26(金) 00:55:54.58

Recordとmapped typesの使い分け方が分かりません
Record<Key, Value>と{ [key: Key]: Value }ってinterchangeableな気がするんですが、
どっちかにしかできないことがあったりするんですか？

**デフォルトの名無しさん** · 2022/08/26(金) 08:07:49.83

mapped の方が柔軟

type X = { age: number, name: string }

これは Record では定義できないだろう

**デフォルトの名無しさん** · 2022/08/26(金) 08:46:09.94

Recordはキーがいくつかの既知の値のみに限られる場合に使う
{ [key: Key]: Value }だとキーが何でも入っちゃうでしょ

**174** · 2022/08/26(金) 10:07:43.28

限られるというより、必ず既知のキーを持っていることが保証されるというべきか
record.knownKey のような既知のキーによるアクセスがタイプセーフになり、コード補完も効く

**デフォルトの名無しさん** · 2022/08/26(金) 10:18:44.77

微妙にインデックス型とmapped typeがごっちゃになってて話をややこしくしてる気がする

**デフォルトの名無しさん** · 2022/08/26(金) 22:54:52.76

>>173
それはただのオブジェクト型だと思うが

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

もしかしてTypeScriptってC#で良いのでは？
静的型付け言語だしオブジェクト指向だし作った人も一緒

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

C#でいいならわざわざ同じ人が新言語作らないだろ
ヘルスバーグはMS内では神みたいな扱いらしいから、自分で意味ないと思ってる仕事なんかやらないよ

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

TypeScriptが解決してる問題をC#が全て解決出来るか考えてみれば？

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

>>180
できてるじゃん

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

or型というのかunion型というのか忘れたけど、C#にはなくない？
type a = b | c

(C#にもこの機能欲しい）

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

JavaScriptに静的型付けの恩恵を与えるために作られたのがTypeScript
C#でそれは出来ないでしょ

**.NET MAUI HighScool** · 2022/11/03(木) 12:26:39.11

>>183
C#が静的型付けじゃん

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

C#ではJavaScriptに静的型付けの恩恵を与えられないでしょ

**.NET MAUI HighScool** · 2022/11/03(木) 12:39:42.87

>>185
なんで？

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

>>186
君はC#がJavaScriptに静的型付けの恩恵を与えられると思ってるの？

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

>>182
これについてはTypeScriptが便利というよりは、JSのやり方に合わせるために必要となっているものだと思う
C#では型が条件によってコロコロ変わるような設計は普通しないから、nullabilityさえ指定できれば多くの場合十分

**.NET MAUI HighScool** · 2022/11/03(木) 13:04:33.62

>>187
いや別にJavaScript使う必要なくね？

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

>>189
それは論点のすり替えでしょ

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

代数的データ型は静的型付け言語にもあるよ。
最近のC#でも出来るけど記述量が多い。F#なら比較的楽に書けるけど。

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

typescriptが実行時型安全まで保証してくれたらもう他の言語いらんのよな
REST APIというかJSONとの相性もマックスバリューだし
世にはびこっている型なし糞言語を全て地獄に葬り去ってほしい

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

>>191
union typesは静的型において一般的な直和型とはかなり違ってて癖が強い
値が型持ってないからね

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

>>193
まあそれはそうか。型ガードベースだもんね。
別に型が一致してなかったとしてもメンバさえ合ってれば雑代入しても問題ないし。

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

>>192
型をバリデーションライブラリから生成すると捗るよ

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

>>195
おっ　zodmanか？

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

interface/classからjsonschemaを生成して、それを型ガード関数で使うってのが鉄板。

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

>>196
すまねぇsuperstructなんだ。すまねぇ。

>>197
AJVはコードサイズデカくね？

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

コードサイズは気にしたことがないがスキーマ手書きは面倒臭いからやだなあ。

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

RestAPIの型チェックはio-tsっていうライブラリつかってバリデーションしてるな。
実行時コストがあるけど、自分は業務アプリがメインなんで変な結果で次に進まない方が大事。

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

>>199
ZodとかSuperstructとかはtypeで型書くのとほぼ同じくらいの手間でバリデーションと型が生成されるからすげー楽だよ。

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

うーん、俺はやっぱりTypescriptで書いた型そのまま使える方が楽だわ。

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

HighScool君は納得して帰ったのか

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

superstruct と zod ならどっちがええのんか？

**.NET MAUI HighSchool** · 2022/12/16(金) 16:55:41.78

C#だとvar型でも何ら問題無いと思われてるのにTypeScriptのanyはなんでTwitterでネタにされるんでしょうか？
私もあまりvar型使いませんが公式とかvar型使いまくってるしTypeScriptでany使っても何ら問題なさそうなのですが…

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

コーディング時にvarは右辺で型が決まるけどanyは決まらないからかな

**.NET MAUI HighSchool** · 2022/12/16(金) 18:26:46.45

>>206
決まらないんですか？
ではvar型ではなくdynamic型と言うことなのですかね

**デフォルトの名無しさん** · 2022/12/16(金) 21:33:55.14

そもそもvarは正確には型じゃないだろ

**デフォルトの名無しさん** · 2022/12/16(金) 21:58:06.83

var型はないな

型の堅牢性などを享受するためにTypeScriptを使用しているはずなのに、anyを持ち出せばそれが途端に失われるから絶対に使わない方がいい
そして確かにanyはdynamicに近いものと考えて良い

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

TypeScriptに対する理解が浅いのはともかくC#の理解もそんな程度だったのかこのコテ

**.NET MAUI HighSchool** · 2022/12/17(土) 00:18:30.36

>>208
型推論型だろ
>>210
何いってんだこいつ？

**.NET MAUI HighSchool** · 2022/12/17(土) 00:22:25.11

dynamic型は次の値を入れたらその型に変わる
例えば
dynamic x="おはよう"
dynamic x=123
でも大丈夫なわけ
anyは型の再代入ができないって見たけど？これdynamic型なの？

**デフォルトの名無しさん** · 2022/12/17(土) 00:38:58.67

>>178程度の理解のヤツに何を説明しても無駄よ

**デフォルトの名無しさん** · 2022/12/17(土) 00:50:14.95

>>212
流石にこれは触っちゃいけないレベル

**デフォルトの名無しさん** · 2022/12/17(土) 00:55:05.65

anyはまさにJavaScriptの元々の変数の扱い様そのもの。

**.NET MAUI HighSchool** · 2022/12/17(土) 01:46:39.51

>>213
TypeScriptはC#以下だったってわけか
理解

**デフォルトの名無しさん** · 2022/12/17(土) 01:54:57.82

目的が違うんだよ。C#ではTypeScriptのようなことは出来ない。
良い意味でも悪い意味でもJavaScriptのスーパーセットかつトランスパイラである必要があるんだから。
ただTypeScriptが将来C#でやってることを概ね肩代わりすることは可能だったりはするんだけどね.netライブラリをそのまま動かすように改変していくことも障害は少ない。

**デフォルトの名無しさん** · 2022/12/17(土) 02:13:01.40

そいつにかまうなよ
あちこちの言語やフレームワークスレに乗り込んでは意味不明な喧嘩売って
C#マンセーMAUIマンセーしてるだけの荒らし

**デフォルトの名無しさん** · 2022/12/17(土) 03:00:17.54

再代入と型は関係ないだろ
見た感じC#も満足に使えてないじゃん

**.NET MAUI HighSchool** · 2022/12/17(土) 04:20:14.04

>>219
どこが？
dynamic型知ってる？

**デフォルトの名無しさん** · 2022/12/17(土) 08:49:17.76

>>211
まぁ初心者なら便宜的に型だって覚えときゃいいよ

>>212
型の再代入って何？
値の再代入とは違うの？

**.NET MAUI HighSchool** · 2022/12/17(土) 11:38:05.95

>>221
値は型があってたら普通は再代入はできる
ただ型があってなかったらできない
dynamic型は型があってなくても再代入できる

**デフォルトの名無しさん** · 2022/12/17(土) 12:01:06.61

>>222
それをC#では型の再代入って呼ぶの？

TypeScriptでは変数をletで宣言すれば値を再代入できる
変数がany型ならどんな型の値でも代入できる
変数をconstで宣言すれば型が同じであろうと再代入できない
>>219の言ってるのはそういうこと

**.NET MAUI HighSchool** · 2022/12/17(土) 12:25:09.54

>>223
そういう決まった名前無いけどdynamic型は型を変えれるからそう言ってる

**.NET MAUI HighSchool** · 2022/12/17(土) 12:25:55.57

つまりletがvarでanyがdynamicってことか

**デフォルトの名無しさん** · 2022/12/17(土) 12:32:09.45

ここでもバカ晒してるのかよw

**.NET MAUI HighSchool** · 2022/12/17(土) 12:38:11.73

>>226
何いってんだこいつ？

**デフォルトの名無しさん** · 2022/12/17(土) 12:56:35.19

>>225
説明の仕方が悪かったか

C#の
dynamic x = "abc";
x = 123; //OK
に相当するのは
let x:any = "abc";
x = 123; //OK

var y = "abc";
y = "def"; //OK
y = 123; //NG
に相当するのは
let y = "abc"
y = "def"; //OK
y = 123; //NG

変数の型を推論に任せるときは型指定を省略する

**.NET MAUI HighSchool** · 2022/12/17(土) 14:07:48.19

>>228
なるほど理解したサンクス

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

なんでぽまいらはC#の話をしているんだ？

**.NET MAUI HighSchool** · 2022/12/17(土) 18:58:14.82

anyはネタにされるけどvarはネタにされないなと思ってさ
まぁ勘違いだったんだけどね

**デフォルトの名無しさん** · 2022/12/17(土) 19:14:45.81

なぜanyがネタにされたり忌み嫌われたりするのかはその機能だけ見ても分からんだろうね
言語特有の背景を理解してこそ
https://qiita.com/uhyo/items/aae57ba0734e36ee846a

**デフォルトの名無しさん** · 2022/12/17(土) 20:38:09.95

any無しはJSONの扱いが面倒臭過ぎるんだよなあ
必要に応じて型のランタイムチェックを入れてキャストできる機能さえあれば格段に便利になるんだが

**デフォルトの名無しさん** · 2022/12/17(土) 20:55:50.21

ユーザー定義型ガードで足りると思うが

**デフォルトの名無しさん** · 2022/12/21(水) 14:23:05.41

JSONだろうがanyを許すな。Zodとか使うのだ

**デフォルトの名無しさん** · 2023/01/03(火) 23:03:14.80

pythonを書いていると型縛りが馬鹿らしくなる

**デフォルトの名無しさん** · 2023/01/03(火) 23:51:28.97

JavaScriptを書いていると型縛りが馬鹿らしくなる
みんながそう思ってたらTypeScriptは生まれてこなかっただろうね

**デフォルトの名無しさん** · 2023/01/04(水) 00:03:33.25

型なんて要らねーとか言ってるのは、ほぼ1人でコーディングしてる奴
まぁ、実際1人でなら要らないかも知れない
これが複数人でコーディングする事になると、他人が実装した関数にどんなデータを渡していいか全然分からない
その為にTypeScriptがある

**デフォルトの名無しさん** · 2023/01/04(水) 00:08:02.09

型がない方が縛りプレイだろ

**デフォルトの名無しさん** · 2023/01/04(水) 00:44:19.33

JavaScriptは引数の数すらチェックされない上に暗黙の変換にundefined/null/NaNと昔はブロックスコープもなくてバグの温床てんこ盛りだったからやろ

intとかStringとかのベーシックな型を書きまくつてるコードを見ると欠陥言語だなと思う

**デフォルトの名無しさん** · 2023/01/04(水) 09:28:28.37

>>239
縛り方を間違うと死ぬからな

**デフォルトの名無しさん** · 2023/01/04(水) 10:15:30.84

Flow「…」

**デフォルトの名無しさん** · 2023/01/04(水) 11:23:06.77

パラメタ名・変数名で型がわかるようにしとけば大概は済む
引数の個数をテキトウに呼ぶ奴がいたら、それはそんな作り方する方がおかしい

**デフォルトの名無しさん** · 2023/01/04(水) 11:53:32.34

そういう開発者にのしかかる煩わしさを軽減するのが型の役目だろうに

**デフォルトの名無しさん** · 2023/01/04(水) 16:13:02.47

コーディングルールの運用で型限定するのも
コンパイラにまかせて型限定するのも
少なくとも js に限って言えば前者の方が手間は少ない

**デフォルトの名無しさん** · 2023/01/04(水) 16:35:42.97

本気で言ってるのか・・・？

**デフォルトの名無しさん** · 2023/01/04(水) 16:38:46.50

>パラメタ名・変数名で型がわかるようにしとけば大概は済む

よく事故るのは受け渡すオブジェクトのメンバーの有無だったりするけどそれには無力だな。

**デフォルトの名無しさん** · 2023/01/04(水) 16:48:19.89

大概、おおむねって話よ
よほど便利だろうから、こういう言語が生れたのだろうし全否定するわけではない
あと、処理系が変数の型を把握できても、しかるべき名前でないと、開発者に分かりにくい場合がある
自作でもこれなんだっけ？紛らわしいなって、結局名前弄ったり、名前って大事

**デフォルトの名無しさん** · 2023/01/04(水) 16:56:26.80

型付けはあった方が良いけど、肝心の成果物がしょーもないことは多々あるな
最近まで参画していたアプリはすげー健康なブスだった

**デフォルトの名無しさん** · 2023/01/04(水) 17:01:25.31

開発途中で型の変更が必要になったとき安全に漏れなく修正できるメリットとかは無視できないんだけど
今までそういう経験がなかったんだろうか

**デフォルトの名無しさん** · 2023/01/04(水) 17:46:37.74

そういうのはどのみち影響しそうな箇所を全部見て確認しなきゃいけないから、値に型があることはそれほど重要じゃないと思う
それよりも代入により生じる依存関係を静的に追跡可能であることが重要で、その点では型があることで飛躍的に静的解析の精度が上がる
ただ、そのためには静的解析しやすい作りになっていることが大前提だ
動的型畑の人って概してオブジェクトと連想配列の区別が曖昧で、静的型に馴染んだ人からすると信じられないような型安全もクソもないコード書くからな
それを根本的に改めないなら型なんて大して役に立たん

**デフォルトの名無しさん** · 2023/01/04(水) 18:22:26.69

>そういうのはどのみち影響しそうな箇所を全部見て確認しなきゃいけないから、値に型があることはそれほど重要じゃないと思う
その影響しそうな箇所の把握に型があるのとないのでは大きく正確性や効率に差が出てくるでしょって話

**デフォルトの名無しさん** · 2023/01/04(水) 22:43:59.04

まぁRubyやPHP出身の低能にそもそも型書かせるのが難しいという意見には同意
根本的に教養・学が足りないから、どうしようもない
もはや言語仕様で救えないレベルの話である

**デフォルトの名無しさん** · 2023/01/04(水) 22:52:50.06

動的型畑の奴が一概にバカとは思わないが、オブジェクトの全プロパティ舐めて値を書き換えたりするコードが突如出現したりして面食らう
根本的に思考回路が我々とは違うのだなと感じる

**デフォルトの名無しさん** · 2023/01/04(水) 23:21:22.18

ｸｽｸｽ

**デフォルトの名無しさん** · 2023/01/05(木) 10:41:34.55

>240
>暗黙の変換

これが諸悪の根源

**デフォルトの名無しさん** · 2023/01/05(木) 21:34:07.80

JavaScriptは信用できない、JavaScriptは危険。

だからJavaScriptを撲滅しようとした時代があったんだよな。

JavaScriptそのものは書くものではなくて、使うものに変化した。

**デフォルトの名無しさん** · 2023/01/05(木) 22:57:13.13

JSを半端に知ってるやつこそそう言うけど、地雷がたくさん埋まってる以外は悪い言語じゃない。TypeScriptも今となっては薄いラッパーに過ぎないし

**デフォルトの名無しさん** · 2023/01/05(木) 23:01:32.86

何作るかによるな
んで、Typescriptでしょーもないもの作ってる奴はかなり多い

**デフォルトの名無しさん** · 2023/01/06(金) 00:04:22.96

動的型付けでしょーもないもの作ってる奴の方が圧倒的に多い事実

**デフォルトの名無しさん** · 2023/01/06(金) 16:55:41.96

jsもperlも卒業しろよ

**デフォルトの名無しさん** · 2023/01/07(土) 02:08:56.86

TSも卒業してrust書け

**デフォルトの名無しさん** · 2023/01/07(土) 14:15:02.15

ビルドが遅いからヤダ

**デフォルトの名無しさん** · 2023/02/02(木) 13:12:52.48

(　　)y-~~ (　 >)y-~~(　>-)y-~~( >-< )y-~~ ｳﾏｽｷﾞﾙ・・

**デフォルトの名無しさん** · 2023/02/27(月) 18:54:27.47

男卒業してTSしろ

**デフォルトの名無しさん** · 2023/03/12(日) 13:16:33.47

return this.#instance!;
https://github.com/denoland/showcase_chat/blob/970c56fbb229f00805c0f3b0adde6f4232446a3e/helpers/loader.ts#L36

! って何なんや？

**デフォルトの名無しさん** · 2023/03/12(日) 13:55:58.57

nullとかundefinedじゃねーよって意味

**デフォルトの名無しさん** · 2023/03/12(日) 21:52:14.15

undefinedっていらなくない？
全部nullと同等にしてほしいわ

**デフォルトの名無しさん** · 2023/03/12(日) 23:18:21.71

>>267
助かった
記号はググりずらくて困ってたわ

**デフォルトの名無しさん** · 2023/03/12(日) 23:38:13.62

>>269
次また困ったら解読アシスタントに貼り付けるといいよ
https://typescriptbook.jp/code-reading-assistant#eJzT11d43DgZjFa_WL74xaq1jxtnPm7qfty0-XHznsfNnY-bJj1tXfq0a_bjxumPG5c9bux_3LjgcePUx40tXEWpJaVFeQolGZnFesqZecUliXnJqYrWAJnzL3Q

**デフォルトの名無しさん** · 2023/07/30(日) 19:53:15.24

しーん

**デフォルトの名無しさん** · 2023/09/26(火) 00:05:26.71

しーん２

**デフォルトの名無しさん** · 2023/10/08(日) 11:41:26.71

しーん３

**デフォルトの名無しさん** · 2023/11/11(土) 14:20:03.22

TypeScript が作られた由来に関連しての事ですが
JavaScript と CSSは
直感的ではなく地雷陥穽満載の言語だと思い
苦痛を感じているのですが

Web開発が根本的にもっと簡単に楽になる事は
近い将来ありえますでしょうか。
ブラウザ自体とDOM操作が
JavaScriptでしか実行できない事は
永遠に続くのでしょうか。

**デフォルトの名無しさん** · 2023/11/11(土) 15:40:50.74

あなたの信仰しだいです。

**デフォルトの名無しさん** · 2023/11/18(土) 08:35:06.80

>>274
WebAssembly

**デフォルトの名無しさん** · 2023/11/18(土) 23:58:12.41

strictNullChecksを有効にするとこのコードがエラーになる

const foo: { bar: string } | null = { bar: 'bar' };
if (false) if (foo !== null) console.log(foo.bar); // error TS18047: 'foo' is possibly 'null'.

falseを!trueに変えるとエラーにならない

if (!true) if (foo !== null) console.log(foo.bar);

どういうこっちゃ

**デフォルトの名無しさん** · 2023/11/19(日) 01:01:24.80

>>0277 以前から未解決の課題です
ttps://github.com/microsoft/TypeScript/issues/26914

**デフォルトの名無しさん** · 2023/11/19(日) 01:58:05.77

>>278
ほんとだ・・・到達できないコードでは文脈を無視してタイプチェックするのか・・・

const foo: string | null = 'foo';
// return;
// throw new Error();
console.log(foo.charAt(0)); // error TS18047: 'foo' is possibly 'null'.

returnかthrowのコメントを外すとエラーになる
if (foo !== null)を追加してもエラーは回避できない

**デフォルトの名無しさん** · 2023/11/19(日) 11:55:13.54

興味深い挙動だね
https://i.imgur.com/ZxUFyxD.png

そもそも到達不能コードがあること自体が問題なわけでこれがエラーになっても実害はないだろうけど
returnやthrowを仮置きしたいときにエラーを出したくないなら
if (!!true) return;
if (!!true) throw new Error();
とかするのがいいのかねぇ

**デフォルトの名無しさん** · 2023/12/25(月) 19:47:27.10

最近はフレームワークが全部準備してくれるから書き心地の良さだけを享受できてたけど
久々に自分でゼロから環境作ろうとすると設定の混沌っぷりに絶望するな
たぶんハローワールドするまでの作業が一番苦しいのはTypeScriptだと思う

**デフォルトの名無しさん** · 2023/12/26(火) 14:57:07.76

javascript に変換してくれる
javascript をベースとしない言語を作ってくれればいいのに
何で Typescript はjavascript のだめな部分を採用するかなあ

**デフォルトの名無しさん** · 2023/12/26(火) 16:19:36.04

Dart「」

**デフォルトの名無しさん** · 2023/12/26(火) 17:24:43.39

腐るほどあるぞ
https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS

**デフォルトの名無しさん** · 2023/12/27(水) 16:09:42.74

VSCode, node.js, webpack, babel で、TypeScript も出来る

Ruby on Rails 7 から、CDN から直接インポートするように変わった。
脱webpack/node.js で、esbuild へ変わった

**デフォルトの名無しさん** · 2023/12/29(金) 20:15:59.53

Nodeのサポート3年って期間自体は普通なんだが、JSのまま使うことって無くなってるから実質TS関連が安定するまでは捨て期間なんだよな
安定版で作り始めてリリースする頃にはもう期限切れ間近ってことが多くて体感のサポート期間がめっちゃ短く感じる

**デフォルトの名無しさん** · 2023/12/29(金) 20:35:12.47

TS関連が安定するまでってなんのこと？

**デフォルトの名無しさん** · 2024/01/03(水) 11:12:40.45

>>286
基本的にNodeのバージョンとTSのバージョンは独立だろう
何の話をしてるのかわからん

**デフォルトの名無しさん** · 2024/03/17(日) 02:05:57.85

TSがネイティブで動くブラウザを
MSは試験的に開発提供したら良いと思う。
TS-Edgeとかの名前で。
CDNから<script src="hoge.ts">を
読み込むだけで動く仕様。

**デフォルトの名無しさん** · 2024/03/17(日) 10:14:57.42

あんまり意味ない気がするな。
開発時のTAT改善なら今プロポーザル出してるType Annoatationsでも十分だろうし。

**デフォルトの名無しさん** · 2024/03/27(水) 17:56:25.12

型引数Tがnullを取るかどうかを判定する関数
function isNullable<T>(): boolean
みたいなのを作ろうとあれこれ調べてたけど
よく考えたら実行時に型情報持たないから無理な話よね
別のアプローチを考えねば

**デフォルトの名無しさん** · 2024/06/21(金) 21:41:16.33

>>252
イマイチピンとこない、参考までに教えてほしい

**デフォルトの名無しさん** · 2024/06/27(木) 12:10:53.54

>>292
ある式の型を変更したときの要修正箇所を洗い出す方法は、一般には
1. 代入によって生じる依存関係のツリーを作る
2. ツリーの中で修正の必要な箇所を特定する
となるだろう
で1については251の言ってるように静的型であれば最適解析によって高い精度で比較的容易に作成可能だ。
2は静的型なら型の不整合によるエラーは検出できるから、完全ではないにしろ作業は多少楽にはなるだろうな。

**デフォルトの名無しさん** · 2025/03/12(水) 23:21:23.37

マイクロソフト、プログラミング言語「TypeScript」の処理を10倍高速にすることに成功 [478973293]
https://hayabusa9.5ch.net/test/read.cgi/news/1741787027/

**デフォルトの名無しさん** · 2025/03/12(水) 23:29:30.94

>>294
いつものガセタイトルな記事だった
当然TypeScriptが速くなるわけがない
コンパイルももちろん遅いので他の言語でコンパイルするようにしたら速くなったという当たり前の記事だった

**デフォルトの名無しさん** · 2025/03/13(木) 00:40:12.20

Bun使おう
使ってる？みんな

**デフォルトの名無しさん** · 2025/03/13(木) 00:59:18.10

なに？bunて

**デフォルトの名無しさん** · 2025/03/13(木) 01:38:08.11

goはwasm化したときに遅いらしいから不安
早くなる余地はあるのかな
↓は簡単なコードをブラウザで解析した例らしい

https://x.com/sanxiaozhizi/status/1899628334516175236

**デフォルトの名無しさん** · 2025/03/13(木) 08:34:30.29

>>297
node.jsの代わりになるようなやつ
TypeScriptをJavaScriptに変換せずそのまま実行できる
あとnpm, jest, webpackなんかと同じ機能もBunに統合されてるので、Bunだけ入れればjestとかのほかのパッケージをインストールしなくてよい

高速性がウリ（Node.jsの何倍も速い）、らしい

難点としては2022年に生まれたばかりだからまだ安定性とか将来性が不安
リファレンスがまだまだ少ない
サードパーティパッケージは基本npmと同じものをインストールできるが動かないものもある、
などなど
気になってはいるけど業務で使うのはまだちょっと怖い

**デフォルトの名無しさん** · 2025/03/13(木) 09:04:37.99

なるほど、ありがとう
JavaScriptに変換しなくて良いのは動作が速そうだな

**デフォルトの名無しさん** · 2025/03/13(木) 09:12:41.76

>>300
そもそもトランスパイルが不要なことに加えて、低レベル言語で開発してるから動作そのものも速いらしい

**デフォルトの名無しさん** · 2025/03/13(木) 09:28:47.05

1.0になってからはbun使ってるな

**デフォルトの名無しさん** · 2025/03/13(木) 15:54:43.29

ブン？バン？

**デフォルトの名無しさん** · 2025/03/13(木) 17:48:17.33

公式の動画でバンって言ってる

**デフォルトの名無しさん** · 2025/03/16(日) 11:33:35.29

TypeScriptの動的バリデーション何使ってる？
ずっとzod使ってたけどTypiaとかArkTypeとか良さそうなのがたくさんあることに気づいた
とにかくどれもzodよりずっと速そう
ただしネット上に情報が少ない

**デフォルトの名無しさん** · 2025/03/16(日) 20:28:49.17

というわけでArkTypeを使ってみた
いいやんこれ
俺zodよりこっちがいい

**デフォルトの名無しさん** · 2025/03/17(月) 10:22:00.72

>>303
プリンバンバンボン

**デフォルトの名無しさん** · 2025/03/27(木) 07:47:43.49

なぜ世界中でトップクラスに使われているTypeScriptのスレがこんなに過疎なのか？

**デフォルトの名無しさん** · 2025/03/27(木) 07:54:51.37

わからん
小ネタとか知りたいけど

**デフォルトの名無しさん** · 2025/03/27(木) 12:48:15.21

>>308
おっさんはTypeScriptを使っていないということだよ

**デフォルトの名無しさん** · 2025/03/27(木) 13:51:00.07

TypeScriptをつかって若さを取り戻そう

**デフォルトの名無しさん** · 2025/03/28(金) 10:36:36.14

おっさんはJavaとかCOBOLとかCばっかりだからな

TypeScriptとかGoとかRustとか使っただけで、おっさんからアレコレ言われるだろ？
最近Linux Kernel Mailing Listでも、某ドライバでRustを使っただけで、main streamを汚すなとか、言われて拒否されとったやんｗ

**デフォルトの名無しさん** · 2025/03/28(金) 10:39:51.79

TypeScriptをGoやRustと同列に語るなよw
あれだけは無いわ

**デフォルトの名無しさん** · 2025/03/28(金) 14:31:04.68

ドライバでRustを使う事が何故問題か理解出来ないZが使う言語がTypeScript

**デフォルトの名無しさん** · 2025/03/28(金) 14:57:23.31

Nvidia Driver Written in Rust Could Arrive With Linux Kernel 6.15
https://news.itsfoss.com/nova-gpu-driver-linux/

**デフォルトの名無しさん** · 2025/03/28(金) 21:53:46.54

TypeScript使ってるけどJavaScriptにトランスパイルするのがめんどくさすぎる
tsconfigのわけわからんこと

**デフォルトの名無しさん** · 2025/03/29(土) 17:35:18.54

たしかにtsconfigだけで連載記事が成立しそう

**デフォルトの名無しさん** · 2025/03/29(土) 17:40:47.83

いさぎよく中間コードを吐き出せよ
なに中途半端にJavaスクリプトコード出してんだよw

**デフォルトの名無しさん** · 2025/03/29(土) 17:57:42.05

tsconfigみたいな設定はaiにまかせてるな

**デフォルトの名無しさん** · 2025/03/30(日) 10:03:12.64

>>315
知らんが、ググッた感じではこれだろ
https://zenn.dev/aliomer/articles/da8f2f082516aa

ちな、nouveauなんてゴミ使ってるのは一部の狂信者だけで、普通の人は普通にプロプライエタリ使うでしょ

**デフォルトの名無しさん** · 2025/03/30(日) 10:50:20.73

Linuxの親分がついに公式介入してRust化が前進することになったのか

>>320
＞Linusはさらに、HellwigおよびRustに敵意を持つ他の古参メンテナーに明確な選択肢を示しました。
＞この発言は近年のRustとLinuxの衝突に決着をつけました。
＞C言語を守る保守派とRustを推進する革新派の間には数多くの対立が存在してきましたが、
＞LinusがRust for Linuxプロジェクトを直接支持するために初めて公式に介入した重要な転換点でもありました。

**デフォルトの名無しさん** · 2025/03/30(日) 11:54:04.05

>>321
そう思えるのはお前も信者だからだろ

結局のところRust信者はポリコレ過ぎる
これも「政治的に」Linusにチクって解決しようとしたところ、ブチ切れられただけ
記事の話が全部本当だとして総合的に推定すると、
Rustから叩く為のラッパ的な物を用意しようとしたところ政治闘争となり、両者辞任の痛み分け、
カーネル自体のコードには今後ともRustは無し、という所ではないかと
これは「支持」ではなく「容認」だろうよ

ただまあ、何でそんな物が『カーネル側に』必要なのか技術的に疑問ではあるがな
RustからCのAPIを叩けないなんて事はあり得ないだろうし、仮にそうだとしても、API変換をRust側でやればよかっただけの話
俺はHellwigの方が正しいと思う。まあLinus案も落とし所としてはありなだろうけど
(というかLinusはこの辺が断然上手い)

Rust信者は、技術的理由ではなく、非Rust話者を排除する為にRustを使う
TypeScriptにも似たような奴はいると思うけど

**デフォルトの名無しさん** · 2025/03/30(日) 12:02:36.30

>>322
その記事にも書かれてるように、
LinusがRustを支持したため、
Rust反対派のHellwigが敗北して担当を降りて、
Rust APIがLinuxに採り入れたみたいよ

まるでJavaScriptにおいてTypeScript反対派が敗北して、
次々とTypeScriptが採り入れられいってメインストリームとなった状況を彷彿とさせますね

**デフォルトの名無しさん** · 2025/03/30(日) 12:36:22.04

話題をギリギリTypeScriptに絡めてて草

**デフォルトの名無しさん** · 2025/03/30(日) 13:12:43.62

TypeScriptには信頼性をアピールすることでPHPとRubyという2大動的型糞を抹殺しJSファミリーをフルスタックWeb開発言語の頂点にまで押し上げた、
更にはVSCodeで実績を示しクロスプラットフォームデスクトップアプリ分野でも覇権を取ったという実績があるから非難のしようがない
全方位の既存勢力にマウントし散らかしてるRustさんと一緒にしてはいけない

**デフォルトの名無しさん** · 2025/03/30(日) 13:56:11.13

中身なんかどうでもいいから手早くアプリ出来上がってくれってな勢力が大多数なんだよなぁ

**デフォルトの名無しさん** · 2025/03/30(日) 14:30:47.12

サーバーサイドはJavaScriptやPythonのライブラリをC/C++でなく楽なRustで書くケースが増えてるね
フロントエンドもWebAssemblyをRustで書くのが主流になった

**デフォルトの名無しさん** · 2025/03/30(日) 15:23:36.04

ウェブアセンブリ勉強したい

**デフォルトの名無しさん** · 2025/03/30(日) 17:19:46.06

Rustはバックエンドでも一番速いからTypeScriptとRustの二つを覚えればWeb関連は最強

**デフォルトの名無しさん** · 2025/03/30(日) 22:51:31.77

>>326
ほんまそれ
どの業界で何をやろうとも、それだけだな

**デフォルトの名無しさん** · 2025/04/02(水) 00:12:34.04

ほえー…もうフロントはwasmが主流になってたのか…

**デフォルトの名無しさん** · 2025/04/11(金) 18:51:02.99

tsconfigのmoduleとmoduleResolution、いつか綺麗になることはあるのか？
ていうかもう全部ESMでよくないか？

**デフォルトの名無しさん** · 2025/04/12(土) 14:51:21.70

よくない。
まだ "bundler" は必要。

**デフォルトの名無しさん** · 2025/04/12(土) 16:59:28.80

>>331
主流はまだJS/TS
フロントでWASMは個人的には微妙だと思う
特にRustはビルド遅いし、UIのサイズや見た目を調整するだけでも再ビルドが必要になるものはフロントと相性悪いと思う

**デフォルトの名無しさん** · 2025/04/12(土) 20:23:17.33

>>334
UIはTypeScript、複雑なロジックだけRustやね

**デフォルトの名無しさん** · 2025/04/12(土) 20:50:15.66

>>335
Rustは高パフォーマンスが必要な時だけじゃない？
主目的が「複雑なロジックを扱う」だけだとRustは採用しづらいと思う
表現力に拘りたいだけならScalaでもいいわけだし

**デフォルトの名無しさん** · 2025/04/12(土) 21:16:27.29

サイズがデカくなるScalaを使うメリットが全くわからない
Wasm by Rustはメリットがはっきりしているけど

**デフォルトの名無しさん** · 2025/04/12(土) 21:30:23.80

>>336
はいおっしゃるとおりです

**デフォルトの名無しさん** · 2025/04/12(土) 22:35:51.54

>>337
すまんサーバーサイドの話
Scalaも最近はそんな人気はないし微妙ではあるけど

Rustはパフォーマンスが必要な分野ならとても有力な選択肢だけど、そういう要求が無いのであれば素直にGCのある言語を使った方が無難だろうというのが自分の意見
Rustの関数型っぽい部分 (型による表現力の高さ) は強みではあるけど、あくまで副次的なもので、それ目的にRustを採用すると書き辛さの方が目立つと思う
今どきだとメモリ管理が必要な言語を経験してない開発者もそれなりにいるし、所有権やライフタイムまわりで苦戦すると思う

**デフォルトの名無しさん** · 2025/04/12(土) 23:27:20.11

>>339
苦戦するのは慣れるまでの間だけだよ
コツをつかんでしまえば大丈夫
そして引き換えに得るものが非常に大きいね

**デフォルトの名無しさん** · 2025/04/13(日) 07:29:44.21

>>339
メモリ周りで苦戦するのはただの馬鹿
きちんと理解してる奴はRustすら要らん、実際Cでリークしてないだろ
俺はRustはこのまま死んでどうぞ、と思っている

**デフォルトの名無しさん** · 2025/04/13(日) 07:36:00.46

>>341
C/C++は未だに問題出まくってセキュリティ脆弱性にも繋がっている
そのため様々なものが次々とRust化へ進んでいる
ここ5chが使っているCDN CloudflareもRust製へと置き換わった

**デフォルトの名無しさん** · 2025/04/13(日) 07:46:48.45

こっちでやれ
https://itest.5ch.net/mevius/test/read.cgi/tech/1701997063/

**デフォルトの名無しさん** · 2025/04/13(日) 08:05:12.79

>>342
そう思うならお前はRust使えばいい

>>343
Rustの連中とは話が通じないのでどうでもいい、というか、そもそも好きな言語使って、廃れたら滅びるでいいだけの話
C++も同様に糞だし、Cもやる気が無さ過ぎて糞だ
JSが蔓延るのも分かる

**デフォルトの名無しさん** · 2025/04/13(日) 08:21:04.68

というかね、Rust信者は一神教であり、
Rust＝全知全能の神であり、それ以外の神の存在を『一切認めない』、なんだな
だから多神教な俺からしたら馬鹿げてて、どうやっても平行線だし、時間の無駄でしかない

なんでRust信者がそうなるのかはよく分からんが

**デフォルトの名無しさん** · 2025/04/13(日) 09:29:16.46

ガイジが多すぎる

**デフォルトの名無しさん** · 2025/04/13(日) 10:09:09.85

外字鹿以内

**デフォルトの名無しさん** · 2025/04/13(日) 10:19:03.37

>>341
ほんそれ
Cで充分だったんだ

**デフォルトの名無しさん** · 2025/04/13(日) 10:20:06.61

>>342
その割にfirefoxはいまだに糞のまま

**デフォルトの名無しさん** · 2025/04/13(日) 12:19:34.58

なんか、とんでもなく盛り上がっていて、ワロタｗ
みんな、くすぶっているんやなー

個人的には、RustよりもPHPのほうがさっさと滅んでほしいわｗ

**デフォルトの名無しさん** · 2025/04/13(日) 15:23:04.70

PHPは滅ばないよ、だってあれ便利だし
ほぼ静的＋一部動的なサイトを作るときに、PHP以上の物がない
ぶっちぎりの糞言語だったが、何だかんだで改善してきてるし
(というか、プログラミング言語として捉えるから不満なのであって、Apache上で動くDSLだと考えれば凄く納得出来るし素晴らしく有用)

そういえばJSも滅べ滅べと言われていたけど、言ってる奴等が滅んだな
TSもある意味AltJSで滅べ勢だったが、何となく背乗りしてる感がある

**デフォルトの名無しさん** · 2025/04/13(日) 22:02:26.52

>>349
Firefoxのメイン部分はC++のままで進展がないんだよな
Chromeは既に少しずつRust化を進めているから期待

**デフォルトの名無しさん** · 2025/04/13(日) 22:05:07.20

盛り上がっていると思ったらTypeScriptの話題じゃなかった悲しみ

**デフォルトの名無しさん** · 2025/04/14(月) 18:14:36.17

>>351
php→goへのリライト案件は増えてますけど、
相変わらず求人は多めですね

**デフォルトの名無しさん** · 2025/04/14(月) 20:45:54.18

>>354
PHPは非プログラマ、というかデザイナでも行ける簡単さだからな
そして広報が主な目的のサイト、つまりデザイナの方が主役な状況では最有力な選択肢になる

問題は動作速度と、ユーザー間が完全に分離してる事だが、（この為、例えばチャットサイトとかはPHPではかなり無理)
逆に言えばこれが問題にならない局面では今後とも使われ続けるだろうし、
そもそもPHPを殺しにかかってる言語がない

Rust信者の凶暴性は、世界を一時的にであれ統一したCを殺しにかかってる事にある
TypeScript等その他の言語は、そもそもCの領域を侵そうとしてないから、最初から最低限二人の神＝C/C++と自言語は認めてる
ここら辺が根本的に違う
ただRustはプログラミング言語としては筋が悪い
ただしCでは往年の先輩層が厚すぎて絶対にイキれないので、

・とにかくイキりたい若年層

には刺さる
また、昨今のOSSで開発する際、伽藍とバザールの通り、どうしても「コミットを受け入れるかrejectするか？」という問題が回避出来ず、
従来型(伽藍的アプローチ)の場合は「内容を見て判断する」わけだが、これはどうしてもある程度主観的に見えてしまう
単純に言えば、rejectされたコミッタは絶対に納得しない
この点、Rustは少なくともメモリリークに関してはコンパイルが通ればわりと大丈夫らしいので、

・コミットは基本的に全部受け入れる(＝コンパイルが通ればおｋ）

という基準で管理する作戦であれば、昨今のOSSの状況とは合致する
(Cでこれをやるとまともに動くかどうかすら怪しいが、Rustなら少なくともある程度は行ける)
だからこの作戦でイキりたい馬鹿共の承認欲求を糧にしてガンガン進行すれば現在の情勢には向いてる

ただ、Rustの連中がこれをやってるとは思えないし、
α世代にとっては、今Rustでイキり倒してる馬鹿共は邪魔なだけなので、多分また新しい言語が出てきてそいつらはそっちに飛びつく
だからあと10年で化けられなければRustはこのまま死ぬと思ってるし、俺はこれを望んでる

**デフォルトの名無しさん** · 2025/04/14(月) 20:57:42.36

>>355
今月もWindowsからChromeに至るまで大量のセキュリティ脆弱性アナウンスが出た現実を見よう
C/C++は完全に詰んでる
もちろんWindowsもChromeも少しずつRustに置き換えていってる
コードが巨大だから置き換えに時間はかかるがこの流れが止まることはない

**デフォルトの名無しさん** · 2025/04/14(月) 20:59:14.42

>>353
ほんまそれな

**デフォルトの名無しさん** · 2025/04/14(月) 21:01:37.23

ちょっと話題振るけどフロントエンドのフレームワークといえば今はReact？
Vueはもう死に体？

**デフォルトの名無しさん** · 2025/04/15(火) 00:19:13.44

現状はReactが一番強い
Vueも死んではいないけど、他の選択肢 (SvelteとかSolidとか) も出てきてて埋もれがち
例えば今からフロントを学ぼうという人がどれか一つを最初に始めるなら、おそらくReactが選択肢としては一番良いと思う

**デフォルトの名無しさん** · 2025/04/15(火) 22:08:26.65

Effective TypeScript 第2版出たよ
買ったよ

**デフォルトの名無しさん** · 2025/04/16(水) 10:15:10.36

こんなスクリプト言語スクリプトなんか使える奴はあたまおかしいよな

**デフォルトの名無しさん** · 2025/04/17(木) 10:27:18.15

褒められた？

**デフォルトの名無しさん** · 2025/04/17(木) 14:54:48.83

蛇腹御用達言語

**デフォルトの名無しさん** · 2025/04/17(木) 16:00:08.01

【AI】OpenAIが「GPT 4.1」のAPIを公開、100万トークン対応と実用性能で飛躍的進化を遂げた次世代AIモデル [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1744724723/

上記のリンク先のコメントを読んでもまだ医者の威厳を保てるのか？

**デフォルトの名無しさん** · 2025/04/17(木) 19:42:09.87

エキスパートシステム取り入れて無い医者とかいまどきまだ居るの？

**デフォルトの名無しさん** · 2025/04/18(金) 12:33:39.43

マルチンコにレスする香具師は荒らし

**デフォルトの名無しさん** · 2025/04/19(土) 04:04:51.48

【2025年最新】自然な声の音声読み上げソフト5選！AI技術で ...
https://ondoku3.com/ja/post/natural-voice-software/
※無料で５０００文字まで音声合成エンジンで読み上げ可能
※音声合成エンジンは人間の声のサンプルから声質が作成されている

「Grok」が過去の会話を覚え続けるようになった--ChatGPTに追従　オフにする方法は？
2025年04月18日 05時20
http://japan.cnet.com/article/35231959/
>>「ChatGPT」やGoogleの「Gemini」も同様の記憶機能を導入している。これらのサービスも、長期的な会話履歴を保持し、ユーザーに合わせた回答が可能となっている。
※GrokはChatGPTで規制されていることも返答するようになっている

統合失調症の幻聴で半分人間半分AIと申されていた
統合失調症の幻聴で宇宙人とも話されていたのでかなり昔からできていたと思われる
※対象者【統合失調症】の考えに対しては何を考えているかは対象者【統合失調症】に聞いてみないことには意味不明⒮

**デフォルトの名無しさん** · 2025/04/23(水) 22:58:30.47

Bunの速度検証をネットで見て回ってるけどNodeと大差なさそう
それなら枯れたNode使い続けるわな

**デフォルトの名無しさん** · 2025/05/12(月) 19:47:42.38

誰も書き込まない
どうやら誰もTypeScriptを使っていないようだ