それはNodeのようなランタイムのことを指しているようですが、ここで言っているのはTS言語自体のコンパイラです。

> TypeScriptコードがもはやTypeScriptで書かれなくなると、チームがTypeScriptを直接使わなくなり、長期的には開発体験に影響する可能性がある。

いわゆる「ドッグフーディング」ですね。自分たちが作ったものを自分たちで使うことです。でも、言語の場合は少し悩ましいですね。

とはいえ、最新技術(?)を導入しようとすると JUnit4 が足かせになることがしばしばあるので、個人的には JUnit5 へ移行してほしいというささやかな願いがあります。
https://docs.gradle.com/develocity/test-distribution/

junit-vintage-engine を使えば大きな修正なしに junit4 のテストを junit5 で動かすことはできますが、オーバーヘッドがかなり大きいです。（おおよそ 20% ほど遅くなります）

たまたまAndroidアプリのビルドエンジニアとして落ち着いた立場の人間として意見を残すなら……

> ビルド : gradle

非常に大規模だったり複雑だったりしても、gradle を使うべきです……（遠い目）
非常に大規模または複雑なプロジェクトで gradle のビルド性能を改善するために、以下のプロジェクトが進められているので、大きなプロジェクトで gradle を使用中なら、早め早めにマイグレーションの準備をしておくとよいです。

• https://docs.gradle.org/current/userguide/configuration_cache.html
• https://docs.gradle.org/current/userguide/isolated_projects.html

> モジュール構成 : feature ごとに分離

個人的には、アーキテクチャレイヤーをあえてビルドシステムに露出させる理由はないと思っています。
私が管理しているアプリでは、feature-api / feature-impl というモジュールをビルドシステムに露出させるようにしています。

• feature-app :
  • データモデル、または他のモジュールと連携する interface
• feature-impl:
  • feature の実際の実装

このように構成すると、feature-impl のコード変更が feature-api を参照する他のモジュールに影響を与えないため（依存性の分離）、incremental build や build cache hit rate の向上に大いに役立ちます。

> 単体テスト - junit 4

これは Google の決定が大きな役割を果たしたように思います。

• https://issuetracker.google.com/issues/127100532
• Android Platform の場合、JUnit3（のように見える JUnit4）、Android ビルドツールのテストフレームワークは JUnit4 ベースで動作しており、JUnit5 に移行するつもりはないと Google が明言しています。
  しかし、最近リリースされた screenshot testing plugin は JUnit5 ベースです.

Clubhouseっぽいですね。私もちょうどそれを思い浮かべました。

最近は回数や時間を制限するサービスがまた流行っているようですが、少し前に流行った、名前は正確に思い出せないものの放送っぽく話すアプリみたいに、一瞬で話題になってすぐしぼんでしまうのではないかと思います。

わあ、一族の栄光ですね

その時間帯にだけトラフィックがものすごく集中しそうなので、効率的な処理が必要になりそうですね。

後になると、既存のTypeScriptコードベースの管理がおろそかになってしまわないか心配ですね。

C# 言語の開発が止まったわけではありませんが、C# を使ったフレームワークが放置されているように感じることがあまりにも多いです

テストしてみていますが、何というか総合ギフトセットのような感じです。

似たような文章が繰り返されますが、人間の欲は尽きず、同じ失敗を繰り返してしまいますね

• 最高の成果を出すチームを作るには、85%の努力だけを求めなさい
• プロダクト開発を台無しにする6つの思い込み

コンピュータのCPUロードが100%なのは正常ではありませんが、
人間の業務負荷が100%なのは、もっと頑張るべきだ……という結論になってしまうのですから

うーん……余談ですが、ここ数年の間に、スタートアップの多くはFlutterを採用する一方で、METAやOpenAIのような大企業はネイティブに向かうという奇妙な現象が見られていますね……

そうですね、でも .NET 開発者の方々の気持ちも理解できます……

うれしいニュースです！ 不思議なことに、MSのTypeScript言語は予想に反して本当に意外な（？）選択をたくさんしているようです。MSにとってはほぼ最初のオープンソースプロジェクトでもあり、JSを置き換えようとしていたGoogleのDartと違ってJSを補完しようとした選択もとても賢明に感じられましたし、今回のネイティブ移植言語についても自社言語がいくつもあるはずなのにGoogleのGoを選んだ点も驚きです。

.NETとRustの開発者たちがかなり怒っていますね

Brother、サードパーティ製プリンター用インクカートリッジを使えないように強制するファームウェアアップデート

あれ、Deno 側ですでに Rust ベースのツールチェーンを作ったものがあったはずですが……いきなり Go なんですか？

再帰で構成されたジェネリック型を使うとき、遅くなってしまって次善策を使った経験があります。10倍なら、こういう部分も改善できるのではと期待しています。

「なぜGoなのか」という議論スレッド、面白いですね。

https://github.com/microsoft/typescript-go/discussions/411

考えるべきことも多いですね…