  |
はてなキーワード:TypeScriptとは
身体を壊して先日ちょっと入院していたのだが、病院内ではWiFiが提供されていたので、消灯時間外の日常生活アクセスはそれのお世話になっていた。消灯時間は夜9時から朝6時までだ。
事前に「入院生活にそぐわないサイトには接続できません」という告知が為されていたので、覚悟の上で使ったのだが、Webアプリ開発者としての業務に必要なサイトとかも禁止されていたので、ここにメモしておく。
通信が禁止されていると思われるサイトに接続すると、ブラウザ側ではタイムアウトのエラーとして表示される。もちろん、それなりに待たされる。ブラウザの開発ツールの様子を見るに、おそらくTCP handshake に失敗していそう。
正常に接続できるサイトの様子を見た範囲では、HTTPS接続の証明書改ざんは行われていないようだったことから、HTTPSの暗号を解読してどうのこうの、という処理をしていない可能性が非常に高い。つまり、通信制限は接続先ドメインまたはIPアドレスによる判断で実施している可能性が高い。
また、中間的なサイトも存在する。通常2秒以内で表示できるようなサイトの表示に10秒(体感)かかるところがある。稀にタイムアウトする。
謎なのは、通信が禁止されていそうなサイトでも「待たされた挙句、つながることが非常に稀にある」ということと、curl等ではすんなりと接続できることである。
DNS設定と一緒にproxy設定が落ちてきているのであればこの挙動も理解できるのだが、手元のOSのネットワーク設定にはproxy情報が何も出てこない。ちょっとよくわからない。
もしもDNSに対するAレコード(AAAAも？）問い合わせに対してニセモノを返すという仕組みで通信制限しているのだとしたら、「非常に稀につながる」挙動にはならないはずなので、透過型proxyによって頑張っているのではないかと想像するところである。
なお、消灯時間中は全てのリクエストがタイムアウトになる。消灯時間開始直前にHTTP Request を送出して、応答が来る頃には消灯時間に入っている場合にはどういう挙動をするのか、というテストをやる暇は無かった。ｽﾏｿ
業務で使う全部のサイトを検証できた訳じゃなくてゴメンね。結局のところ仕事は携帯回線でやっちゃったから。
| ドメイン | サイトの概要 | 接続の様子 |
|---|---|---|
| hatelabo.jp | はてなの実験的サービス置き場 | すんなり |
| anond.hatelabo.jp | 増田 | 禁止 |
| ??????.hatenablog.jp | はてなブログのドメインの一つ、そして増田の中の人のブログ | 遅い |
| console.aws.amazon.com | AWSの管理コンソール | 禁止 |
| www.amazon.co.jp | ショッピング | めちゃくちゃ遅いけどつながる |
| www.amazon.com | ショッピング | めちゃくちゃ遅いけどつながる |
| ja.wikipedia.org | 百科事典 | 禁止 |
| www.php.net | プログラミング言語PHP | 禁止 |
| www.typescriptlang.org | プログラミング言語TypeScript | すんなり |
| stackoverflow.com | プログラミング質問サイト(英語) | すんなり |
| qiita.com | プログラミング質問サイト(日本語) | 禁止 |
| packagist.org | PHPのパッケージ管理 | 遅い(通常通り？ｗ) |
| www.npmjs.com | JSのパッケージ管理 | すんなり |
なお、自分のドメインのサブドメインに禁止ドメインを入れたようなもの、例えばanond.hatelabo.jp.example.com のようなドメインに対する接続可否は検証していない（面倒だったｗ）
サーバ目線で見えるclientIP をwhois等で調べると、某F社さんだった。AWS管理コンソールへの接続を禁止するあたり「あっ…！」と思ったり…ｗ
TypeScriptの書き直しでC#を使わなかった理由でもあるように最近はOOPは流行らないしあまり使われないね
ゲームエンジンとかでも新しいのはOOPじゃなくしたとかなかったけ
https://xn--pckua2a7gp15o89zb.com/
| 技術 | 1月3日 | 3月12日 |
| rails | 22,891 | 27,570 |
| node.js | 12,829 | 16,178 |
| Django | 13,348 | 17,054 |
| Flask | 1,589 | 1,907 |
| FastAPI | 1,210 | 1,509 |
| Laravel | 26,879 | 32,624 |
| spring | 16,380 | 23,965 |
| spring boot | 5,110 | 7,002 |
| React | 49,465 | 65,273 |
| Next.js | 7,382 | 10,288 |
| Vue | 34,322 | 45,354 |
| 言語 | 1月3日 | 3月12日 |
| Ruby | 61,479 | 94,975 |
| Python | 98,527 | 179,183 |
| PHP | 92,129 | 142,628 |
| JAVA | 124,840 | 232,585 |
| Javascript | 99,212 | 237,094 |
| Typescript | 65,828 | 91,348 |
| Rust | 3,807 | 21,921 |
| Go | 48,000 | 183,352 |
今の時代どこもJavaScript(TypeScript)がWebページで動いてるんやで
ReactやVueが主流やね
コンニチハ、オイソギデスカ
非常に良くない生成AIビックウェーブが来ちゃったんで憂鬱な皆さんこんにちは。
生産性が上がるとか効率が良くなるとか宮仕え（みやづかえ）だと、福音どころか地獄ですよね。
ぼちぼち日経新聞がAIエージェント導入で他社に差をつけようみたいな記事を書く頃だと思うので、備えましょう。
まずいつも通り前提からな。
ここまでは前提な。
DeNAがさ、既存事業３０００人の従業員を半分で回すようにするって目標立てたじゃん。つまり、１５００人の業務負荷は倍になるのよね。
倍になったら普通は回らないところ、生成AI使えば倍でも回るでしょ？って言われてるわけだよね。
アレが非難されずに、素晴らしいとか、（諦め半分で）まあそうなるよねって言われてるのが全てなんだけどさ、シンドイよね。
生成AIで業務効率化されてハッピー、毎日定時で何なら毎週金曜日はカジュアルフライデーで飲みながら仕事だ〜、とはならないんだよ株式会社は特に。
経歴詐称して潜り込むってウッソだろというホワイトなみなさんは、パワポ作るとかペアプロするとか輪読会するとか適宜置き換えてください。
新規にプロジェクトに入った時に、なんか資料もねえし、コードをぼちぼち読みながら、急ぎでもクリティカルでも無い部分を書いてレビューしてもらって修正してマージして、
みたいな作業が消えます。この辺もう既に出来るから生成AIで。
というか、すでにこのへん置き換えて楽してるやついるだろ。そうそこのお前。
今までも、華麗なる経歴とやらの人物が作り上げていったコードを保守運営する時に相当キッツイことになってた人は多いでしょう。
ほら、新規事業でも何でも、とりあえず動いて売り上げ立てた人が偉いのはその通りなんだけど、それを直すのは大変なのよね。実運用の時には大抵転職してて居ないし。
でもさ、まあ言うても立ち上げの時期に技術的負債とか考える余裕もなく速度重視でゴリゴリ作った人の立場になってみると、まあ仕方がなかっただろうな、と感情移入もできる。
これが、スーツが「動くものは作っておいたから簡単だよね？」とかAIの作ったクソコードの山をギークに渡すようになるんだぜ。腹立つことにハンパに動くやつを。
今までも「AWSでポチポチしたらすぐでしょ？」とか言うクソスーツは居たけど、実際に手を動かしてモノ作ってくるスーツは概ねまともだっただろ？
金払えば使えるようになったから。身も蓋もないけど。
あえて言えば、簡単にお試しできるようになった、と言うところが本質的な部分です。
以前からChatGPT4とかAmazon BedRockとか使ってた人ならわかると思うんだけど、別に今までもできたんだよね。
ただ、全自動で回せるパッケージングとしての品質がそれなりに高いので、お試しのハードルがぐっと下がった。
これ、APIと簡単なスクリプトで以前から自動化できてたんだよね。（やってたやつは俺以外にも割といると思う）
決まったフォーマットで出力してもらって、そっから切り出して実行して、出たエラーをもう一回入れて修正して、動くようになったら止める。
出来上がったコードとそれまでの途中経過を全部まとめて入れて、最初から出来上がったコードにするためのプロンプト考えてってところまでをワンショット。
あとは、出てきたコードとプロンプトを眺めて良さそうなら採用する。この繰り返しでめっちゃ楽出来てた。（壊れたらDocker建て直せば良いし）
これを、そう言うスクリプト書いて整備して良い感じにGitで管理してたお手製のツールを大手が良い感じに作り上げてきちゃった感じ。あーあ。
特に速度は分かりやすく効率に影響するので、自営業とかプレイングマネージャとかは、今導入しても元がとれるだろうね。
じゃあ、なんでCline（とそれに類似するツール群）に全部賭けない方が良いかというと、まだ過渡期の技術だから。
ツールのオペレーションに全振りして、大手が改良版出しちゃってオペレーターとしての職が無くなった経験、あるでしょ？
今Clineで不満に感じてることとか、プロンプト調整しなきゃなあみたいなところ、全部自動化できるでしょ。
一年保たないと思うよ。
そりゃあ人間雇ったら高えのはわかるけど、単一障害点は怖いぜ。
みんな、生成AIのAPIが逆鞘だろうことはわかってるよね？急に明日から10倍に値上げされて耐えられますか？
今、OpenAPIのたけえのだってたかだか３万ぽっちだけど、あれに毎月３０万円だせって言われて耐えられる？９０万なら？SLAも怪しいのに？
そう言う時、「じゃあやめて人間雇えば良いじゃん」って言った時に、話聞いてくれる相手がいて欲しいよね？不義理しないでおこう。
同じように、新人はちゃんと育てるべきなんだけど、多分聞いちゃくれないから、そう言うところはドンヅマったら転職しよう。
（経営側にいる人間は、安易にAIエージェント＋中堅に頼った場合、中堅がその会社の急所になるのは抑えておこうね。引き抜かれて崩壊する組織は脆弱だよ）
IBMが訴えられてるよね。アレ、AIエージェントあったら回避できてた？
俺は無理だと思う。
試験導入しますね、と言ってガンガン使ってコストをあげましょう。予算が尽きるまで使えば概ねそこまでです。
また、AIエージェントを導入しつつ、動作を確認したり、自社のどこに活用できるのか見ておくのはとても役に立ちます。
具体的に言うと、ググったコマンドを片っ端から試すような新人が入ってくると思ってください。
その新人は、概ね１０００行以下のコードなら即レスしてきます。変えるなと言った箇所もたまに結果を出すために変えたりします。
そして、その新人相手の知見はおそらくそんなに長くは持ちません。何故なら我々が不満に思う箇所は改善されてお出しされるからです。
そのため、Cline(やそれに類似するツール）の知見を貯めよう！なるほどこんなプロンプトを与えてやれば良いのか！みたいな試行錯誤はやめた方が無難です。
今後も解決されないであろう部分を切り分けるのに留めましょう。
超具体的に言うと、AWSのコマンドを片っ端から試されたりすると、すげえ課金されるやつ、あるよね。でもそれちゃんとポリシーで制限できるよね。
人間相手に常識で縛ってたことを、ポリシーで縛るようにちゃんとしておこうね、ミスったコードで高速にIaCお試しされるとすげえことになるよ。
（なりました）
仕様検討にはo1 pro modeが（推論が強いから）、コーディングはClaude 3.5 Sonnetが（コーディングに万能に強いから）、コードのデバッグはo3-mini-highが（コードの解析に強いから）という時代から、Claude 3.7 SonnetのAPIセットしたClineで全部お任せして試行錯誤した方が結果的に効率が良くなってます。
今はPythonやTypeScriptのように、基本的に大量にコードが存在して生成AIを開発する側が良く使うコードの性能が高くなっています。
（ただ、相当にマイナーな言語であっても、別に学習に支障があるとは思えません。おそらく単に優先順位の問題です）
「AIコーディングについてのレポートをあげて、稟議を通すための理由もつけておくように」みたいな指示は、ChatGPTのDeepResarchに振って、上がってきたレポートをそれっぽく書いておけば良いです。
なお、ChatGPT４.5があんまり性能が出てないと聞いてがっかりしている人に朗報ですが、4oから4.5に変わったことで、相当に性能は上がっています。
具体的に言うと、「クソみたいな上司からムカつく指示が来てどうにも収まらないんだけど、以下の内容を相手が納得するように書き直してくれない？」みたいなのに、すごい親身になってそれっぽい感じに書き直してくれます。人間力は多分俺より上です。
TypeScriptベースのフルスタックフレームワークが増えてきたね。
フロントエンドもバックエンドもTypeScript実装できてとっても嬉しいね。
しかし、バックエンドとフロントエンドと密結合な事実はとても怖いんだ。
フロントエンドの成長速度はとても早い。
React がデファクトになりつつあるが、 Reactベースのフレームワークは群雄割拠だ。
むしろ、 React を排する新しい技術も出てくるくらいの戦国時代なんだ。
フレームワークを選定時、各言語でも多くて3つ程度に絞られるのではないか。
成熟しつつあるバックエンドと成長中のフロントエンドを一緒のライブラリで運用すること。とても怖い。
特にTypeScript はフロントエンドを祖に持つので、フロントエンドの事情がフレームワークの開発ロードマップの意思決定に強い影響を与える。
フロントエンドに破壊的変更が加わった時、バックエンド側にも影響を与える。
他フレームワークにおけるフロントエンドの実装について、あのRuby on Rails ですらバージョン上がるごとにフロントエンドに破壊的な変更が入る。
まぁView の取り扱いの黒魔術は魔境だから極力触りたくないが、バックエンドの側面のみを切り出したAPIモードであれば爆速の開発体験とテスト機構により信頼性が高い。
それなら、フロントエンドとバックエンドを別々に管理にしたい。
いや俺は、TypeScript のアプリケーションが嫌いなのかもしれない。
フォルダ設計も、テスト機能の整備も、ORMの設定も、最初から設定する必要があるから。面倒なんだ。
どうせTypeScriptアプリケーションの設計は設計者の自己満足になる。
そして、設計者は運用の責任を全うせずいなくなる。ドキュメントすら残さない。
それなら、規約で縛るフレームワークの方が、後任がキャッチアップしやすい。
設計者が知識を普及もしくはドキュメントを整備して知識の移転に心を砕いてくれれば、設計方針を汲み取りやすいのだが、そうしてる設計者はいるのだろうか。
後任のために、せめてものドキュメンテーションを心がける。
Adobe FlashBuilder使ってた頃とかの方が、今より色々楽しかった気もする…😟
haXeでミニゲーム作ったりしてた時期もあったけど、ActionScriptって、初期の単純な仕様だったJavaみたいにシンプルなんで、
TypeScriptで書くときも似たように書いちゃうけど、C++もBetter Cっぽく書いたりしちゃうし、
新しい機能とか仕様とかめんどくさいんだよね、同じこと書けるなら古い仕様で書いてしまう…😟
ジョブズにFlash潰されたのは悔しいけど、JavaScriptで十分というか、Flash軽く凌駕する世界になったよなぁ
そういえば、Webアプリのビジュアルな機能をFlashにするか、まだWebブラウザに標準実装されてないCanvasにするかで争ったことがあって、
自分はFlash推しで、Flash本当に死んでからCanvas移行すればいいんでは？（その頃はThree.jsなんてないし、そんなの夢のまた夢の時代なんで）
上司にFlashなら3Dバリバリ使えますよ、って言ったんだけど、却下されたんだよね…😟
でも、Canvasで2D実装した方が、現状でもまだ動いてるし、上司とCanvas推しした人の判断は正しかった、俺は間違ってたんだな…
流体シミュちゃんと書き上げてないなぁ、粒子法とか…😟
カプコンだったか、ドラゴンが吐く炎とかに流体シミュしてたり、レイトレでQuake2動かしたデモも流体シミュもしてた気がするし、
リアルな透明水彩を実現するのにもいる、まぁ、Painterみたいな簡易的なものが現実解なのかもしれないけど、もう時代が違うだろうし、
いずれにせよ、流体シミュはなんか決着つけたいよなぁ
そういえば、マインクラフトとか、マインクラフトも影響を受けたであろうドワーフフォートレスとかヒントにして、セルオートマトンの流体で水圧とか浮力とか実現させたりして遊んだな
JavaScriptだかTypeScriptだかで書いたけど、どこやったかな…😟
できれば、なんかゲームにしたかったんだけど、要はよくある砂遊びのやつ、砂とか水とか溶岩とかマウスでドバドバ降らしたりするやつと同じではあるけど、
ChatGPT 4o
この文章の主張は、「バグを減らすために for 文を避け、map や filter を使うべきだ」というものだが、これは一面的な見方とも言える。
確かに、関数型プログラミングの恩恵を受ける場面は多く、副作用を減らし、データの不変性を維持することでバグを減らせる。しかし、for 文が全て悪いわけではなく、状況によっては適切な選択肢になる場合もある。
また、「How だとか What だとかどうでもいい」という主張には疑問が残る。アーキテクチャや設計方針を軽視しすぎると、長期的な保守性や拡張性に問題が生じる可能性があるため、バランスが重要だ。
Claude3.0
総括:
この記事は実践的な観点から重要な指摘をしていますが、やや極端な主張も含んでいます。プログラミングパラダイムや技術の選択は、以下の要素を総合的に判断して行うべきです：
Gemini2.0
for文よりもmapやfilterなどの高階関数を使う方がバグが減るという記事の主張には概ね賛成です。ただし、for文が完全に不要というわけではなく、オブジェクト指向でもカプセル化を用いてデータの書き換えを制御できます。TypeScriptは型のチェックだけでなく、Classを用いたオブジェクト指向プログラミングも可能です。
3AIにだいたい共通している主張
・関数型言語の目的の一つにバグを減らすというものがあるというのは同意
・letを使わない（厳密には副作用の排除）はバグを減らす効果がある
・悪いのはfor文ではなく副作用だが、可変な変数が必ずしも悪いとは限らない
・TypeScriptの型チェックを使うとバグが減る
https://gakuzzzz.github.io/slides/for_loop_to_higher_order_functions/#1
これはオブジェクト指向でも同じでみんな「バグを減らすため」にいろんなパラダイムに挑戦してる
それ以外のHowだとかWhatだとかオブジェクトで世界を表すだとかどうでもいい
for文よりmapとかfilterの方がなぜバグが少ないか、というと「余計な操作が入りにくいから」
特にletで宣言してるような書き換え可能な変数っていうのはバグの温床
例でも挙がってるようなProductのpriceの書き換えでもfor文にするとどこかにletな変数を置かないといけない
そんでletな変数っていうのはうっかり消してしまったりうっかり書き換えてしまっても気付くことができない
だからconstで固めて何かしらのリスト処理をするときはmapなりfilterなりを使ってconstに固め直す（か、そのまま使う）
逆に言うとそういう処理がないならfor文使っても全然構わない
この書き換え不可能な変数を作るっていうのはCだとかC++だとかJavaだとかの頃からずーっと一緒でとにかく固めておきたい変数はfinal宣言して書き換えさせない
そうしないと、めちゃくちゃ分かりづらいバグが混入して無意味に1週間とか過ごすことになる
Product.priceを直接書き換えるのはいいの？っていう疑問があるかもしれないが
「そこまでせんでも致命的にはならん」
っていう感じで型のチェックだけするのがTypeScript
とにかくプログラミングに関する規則でHowだとかWhatだとかそういうフワフワしたこと言い出したら要注意
たぶん大学とかでフワフワしたプログラミングだけしてて碌なプロダクト作ったことない
Permalink |記事への反応(14) | 22:55
今までのキャリアで後悔があるとするなら、CやC++での開発に業務で関わらなかったことである。
現在ミドルウェアでシェアがあるものはCやC++で書かれてるのもが多いように思う。未だに新しく出るものを見てもそのようなものがある。
一般的にインターネットのサービス開発においては、LL系やGoやTypeScriptなどで開発されるので、Cなどで開発する機会は今やほぼ無いはずであり、私も通ってこなかった。
しかしGitHubで著名なDBやKVSを見るとCで書かれていたりして、コードリーディングが捗らなく歯痒い思いをするのである。
さらに昨今パブリッククラウドを使った開発がよくあるだろうが、難しいことは大体API越しに隠蔽してくれているのである。
そしてパブリッククラウドの事業者は、その難しいことを実現するのに、前述のミドルウェアをホストしたり、拡張したり、時には自前で作るわけであるが、そこでもCなどは出てくるのであろう。多分。
OS開発やチップ開発みたいに、同じインターネット業界でも、パブリッククラウド、ミドルウェア、CDN事業者などは一種のレイヤーというか違う業界になってると思う。
要はそこに1エンジニアとして見たときに、C言語などが一種の参入障壁になってると思ってて、平凡なWebエンジニアには近いようで遠い世界に見えるのである。
そして、うまく表現出来ないが、特にパブリッククラウドの上に乗っていると、エンジニアとして相対的に価値が下がっていくような感覚に苛まれる。
APIを叩くだけで楽だが、その向こうには難しいアルゴリズムやオンプレのサーバーがあるわけで、そういう知識はどんどん向こう側に蓄積されていくのである。
とはいえ、それで顧客に価値が届いて事業が成立するのであれば、それはそれで構わない。
とりとめのない内容ではあるし、生成AIやLLMの進歩により、このような悩みが杞憂になる可能性もあるが、あと30年どうやって生き延びていけばいいか悩んでいる。
月30万ぐらいのであれば未経験でも雇ってもらえるんじゃない？
※一番下に追記あり
社内政治的に言えば負け組に属するし昇給に期待できないのとメンタル面の複合的な理由で頑張り切れなくて成果も出ずモチベーションが下がってる。
今後のベースアップも望み薄な状況になったので給与同水準で今後頑張れそうなところに入りてぇなぁ。
現状と同水準の年収500万、それ以上もらえるのならうれしい。
完全リモートワーク。出向などはなし。
Web系といえばWeb系。Androidアプリ開発もやってたけど今はWebの運用保守まわり。
就職して10年くらい流れに身を任せてなぁなぁに過ごしてきたので何も身についてる気がしない。
以下のスキルもだいたいが腰をいれてやろうと思えばできる、なレベル。
・まぁわかる
k8s,Java(SpringBoot),PHP(5.3くらいまでの話)
Kotlinは読めはするけど書くのはなかなか厳しめ。
趣味レベルでReactとかを使ったフロントエンドのやつをgithubに上がってるやつみて修正したりとかはしたことあるけど
・いまだにわからん
身から出た錆ではあるがいやほんとどうすりゃいいのか。
転職エージェントとかでもこんな微妙なのとマッチングしてくれそうなとこなさそうだしなぁ。
モダンな言語をチョットデキルくらいまではやりこんだりしてから転職市場に飛び込んだ方がいいかね。
まったくプランが見えない。
甘えが過ぎるかもしれないけど、必要あらば答えるので厳しくでもよいのでお願いします。
気になったコメントやブコメがあったのでこれだけは答えようと思う
これは理由にも書いた通り以下にかかっていて
大き目プロジェクトに入ったら超絶ブラック進行すぎて燃え尽きて仕事ができなくなり一番下に落ちている
全然エンジニアと違う部署に行ったりとかしたけど成果出せずまたエンジニア業務に戻った
スキルセットにあるk8sやSpringBootも保守で必要になるから触ったりしたけど成果はまちまちで昇給は数回しかない
なので仕事に向き合えてない自分が嫌で、向き合えてない分周りの評価も低いし
引く手あまたどころか引く手は存在するのだろうかというのが今
定年まで会社にしがみつく予定だったけど上もぎっちり詰まってるしもう厳しいかもってなって増田に書いたところ。
まぁ書いたうえであーだこーだなコメントやブコメ見て自己分析も省みることができたので
EKSやGKE、AKSくらいは一通り触れるようになっておこうかなとは思った。
転職エージェントさっさとやれもその通りなのでなんも使ったことないけどとりあえずやってみようかな。
Permalink |記事への反応(24) | 19:14
投稿者の特定を防ぐための方法（LLMによる個性の除去など）が考えられるが、使用ツールや手法によっては逆に投稿者が限定される可能性がある
投稿者の特定を防ぐための方法（LLMによる個性の除去など）が考えられるが、使用ツールや手法によっては逆に投稿者が限定される可能性がある
医者だったら医師免許持ち歩いているか？とか手袋のサイズは？とか聞くけど、合コンしてるときにサポートエンジニアが開発している開発するエンジニアと偽ってくることがあるので、見分け方を教える。
日本語とか英語とか答えてくるやつがいたらそいつは偽。RustとかTypeScriptが好きというレスポンスがあれば真。
これで好きなタイプ（顔の好み）とか答えてきたら偽。never型（タイプ）とかunknown型というレスポンスがあれば真。
型があったところで型が一致するか、変数が存在するかくらいしかチェックはされないぞ
結果、実行したら予期しない値が帰ってきたり実行時にエラーが起きたりする
コンパイル通ってればだいたいは動くし、作ったときに動作確認もしてるから大丈夫、というなら動的型付けの言語でも動作確認はしてるから大丈夫だろ
動的型付け言語の方が得意だと言ってるくらいに使い慣れてる人なら実行時エラーもそんな多くない
その程度のゆるさでエラーが起きたら対応すればいいやくらいのところなら別に静的型付け言語である必要もない
ちゃんとテストコードを書く環境で、テスト通してるからという場合でも、それも動的言語だってテストして通ってるわけで同じこと
結局型の有無はプロダクション環境のバグの多さに関係ないし、どっちが好きかって話でしか無い
型システムが優秀で実行時エラーがほぼ発生しないのを売りにしてるくらいの言語なら多少利点はあるけど、TypeScriptみたいな無理やり型をつけた中途半端で実行時エラーが簡単に起こせるような言語ではメリットもほぼない
