anton_gogolev

Care to elaborate on what would make C# a bad language?

I remember being mocked slightly when I was headbangin' and footstompin' to the soundtrack.

That’s not called “deleting old code”. This is now “breaking backwards compatibility”.

So you're not welcoming guests with Android phones? Will you be placing their mobile phones in a Faraday cage?

Or will not not be visiting anyone who has a Homepod/Echo at home?

> The Law of Leaky Abstractions is a lie; abstract airtightly

This one... Our entire computing world is a pie of terrible abstractions held together by duct-tape and billions of man-hours spent working fixing those leaks.

> ...the better your code style, guidelines, linting, infrastructure, error reporting and tests

Doesn't TypeScript kind of solves (at least partially) those issues?

Keeping track is one thing. Actually _running_ the Lernaean Hydra of an application in production is a whole another story. The amount of "housekeeping" you have to do to keep the thing afloat is astounding: cascading failures, distributing tracing, logging and diagnostics, metrics. Even operational side of things require a lot of attention. Presumably, each microservice would require at least a minimal level of admin-level tooling around it.

You can experience the same, if not worse, levels of pain and suffering with a monolithic application designed by the same Enterprise Architects.

This is some Java-level explicitness. Maybe, drop the `_seconds` suffix and replace it with something like `retry_window_after_first_call = '60s'`?

Not to undermine author’s efforts, but I feel we as an industry took a wrong turn somewhere. An entire book on what essentially is a single Git command is just insane.

> ...weird design choices (e.g. branching is bad)

What bothers you in particular?

> There's nothing wrong with having zillions of them...

There's nothing wrong until something goes wrong an now you're royally screwed. With zillion dependencies you are at a mercy of zillion maintainers, and none of them has any obligation to you. They can break backwards compatibility in patch releases, introduce subtle behavior changes, steer the project in an unexpected direction or abandon it altogether.

The whole "...we don’t want duplicated subscriber lists" is a very arbitrary requirement.

What's more, all this could have been avoided if a proper relational database structure (not even denormalized, GordonS) was there in the first place.

I've been using HJSON lately and it's been a joy.