Good advice that I keep trying to adopt myself, but I have to confess a large personal bias for languages that I like, even if it keeps me from certain classes of problem (I like Ruby, though).

What did you move onto for those next things you started building?

There are a ton of reasons it's not the best idea. This flies in the face of a lot of _better_ ideas.

Keeping changesets small so that it's easier to debug when something goes wrong? Blown out of the water by deploying everything at once.

Bringing every service up at once is a great way to create the coldest version of your entire product.

Requiring a monodeployment turns canarying or A/B testing entire classes of changes into a blocking rollout where any other feature work has to move at the pace of the slowest change.

> When you roll back an individual service your entire system is no longer in a valid state. It's in an interim state of repair.

The gold standard is that each version of your service can work with each other version of your service, because in The Real World your service will spend time in those states.

> Monodeploy should be the gold standard, and individual deploys and roll backs are reserved for emergencies.

No, because if it's still possible to mix versions in your services, then a monodeploy doesn't actually solve any issues.

I actually am a big fan of fewer services and deploying bigger artifacts, but if you have multiple services, you have to act like you have multiple services.

Deploying your service graph as one atomic unit is not a given, and not necessarily even the best idea - you need to be able to roll back an individual service unless you have very small changes between versions, which means that even if they were rolled out atomically, you still run the risk of mixed versions sets.

There are definitely benefits to this approach. My coworkers do fall into the trap of assuming that all the services will be deployed simultaneously, which is not something you can really guarantee (especially if you have to roll one of them back at some point), so the monorepo approach gives them confidence in some breaking changes that it shouldn't (like adding a new required field).

It never felt like Nim, Pony, or Crystal were ever that popular that a diminished hype cycle registered as something thematic to me (not that I really intend to disagree with your perspective here).

Wasteful unit tests that assert your types are right don't have much value if there is a proper type system.

> It's called ratting yourself out.

Quit being childish.

And your suggestion that people who like static types "don't know how to write unit tests" is further bad faith.

Perhaps it's dynamic typing programmers who don't know how to write sound programs? Except I'm not making that claim, because I'm giving you all some benefit of the doubt, a degree of respect you are not giving others.