Main pain points with TS have become more obvious as the team grew and the codebase resulted in a multitude of different models representing the same thing.

- Prisma model representing the things (plural because Prisma generates a ton of variants for the different read/write scenarios) going in/out of the DB

- Zod models for OpenAPI generation

- Zod models for deserialization where we have `jsonb`

- DTO models at the boundary

- Additional front-end payload models that wrap the DTOs

A developer building a simple API endpoint do to a read will often up writing a handful of models for the same entity to move it back and forth...A lot of this work simply ends up being related to the loss of runtime types requiring a lot more modeling work creating a spaghetti of Zod and types.

Lots of papercuts in day-to-day and increasingly difficult to get otherwise competent engineers onboarded.

At least I'm not under the impression that this is a Silver Bullet. Will C# make it better? We'll see!

I think the big gains come from a more mature ecosystem of things that "just work". e.g. EFC vs Prisma or Drizzle with EFC having, for example, automatic change tracking and automatic up/down migrations.

The two NPM supply chain attacks this week also highlight another issue with the ecosystem in general.

We'll see how this change goes and evolves in Motion; C# is still relatively rare for startups, but at series C, it's no longer a seed stage startup and it increasingly feels like "it's just another distributed enterprise backend" (or at least it should be).