My personal experience with go modules and versioning has been really positive. In that ecosystem - you only define your major version in the mod file and rely on the VCS for everything else.

> We will ensure that D1 costs less and performs better than comparable centralized solutions.

Excellent candidates are not the same as the ones who arrive at a similar solution to ours. The best candidates are able to ask important questions about the requirements, and when asked can provide rationale for choosing specific components, as well as other potential options they considered.

More often than not this kind of question is assessing your process, not the outcome you produce.

It wasn't just CloudFlare who were affected. And the time of day is completely irrelevant, I live in Australia and was affected by this during evening peak time. Some very popular services (eg: discord) were completely knocked offline.

I think you're underestimating the impact of this event.

Looking back, I completely regret it. If I had my time again, I would stop after explaining the alternate solution. The time we would have had to spend fixing the problems with the original approach would have been worth it.

I've heard this repeated a lot, but I'm really only just starting to understand: Often the best leaders speak up less, rather than more.

This seems to be slowly changing, but Go was designed to be a solution to Google problems - python being slow but some c++ applications taking literal hours to compile. Keeping that perspective in mind makes it easier to understand why Go maintainers have not accepted an implementation of generics into the language yet.

What about the author having their github account compromised? I agree that GitHub account names should not be released so quickly, but if you're seriously worried about that possibility then I'd think it's also wise to be worried about the possibility of upstream being compromised in other ways.