Thank you for that link, it was really fascinating. The Australian government guarantees deposits in the same way, but I never realised this was also true in the US. I had assumed during the mortgage crisis that people lost their deposited money when their banks failed.
At my company we would love to use buf but can't: because of the BSR. We already pay shitloads for our VCS - we don't want to pay for another product that does the same thing. After using go and getting a taste of what life is like without third party package publishers (like npm, pypi, etc) it's hard to want to go back.
I can't agree with having a source file include the tag. It is an eternal source of merge conflicts and pain, unless you take steps to automate it. And in that case, does the file add much value anymore?
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.
In technical interviews I conduct I also include a system design challenge. I present a large scale architecture problem our company has had to solve and ask the candidate to take us through their process of designing a solution.
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.
> What strikes me the most is that this whole "event" would have hardly even registered on anyone's radar (it affected less than 10% of their traffic during early hours of the morning.
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.
This really hits home to me. I worked on a project where I encountered an almost identical situation to the one you described. I stuck my foot down, and insisted we build the objectively better solution. We did, and only much later did I realise the damage I had done to my coworker's morale.
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.
South Australia's energy grid is a very exceptional case, due to a very jarring transition to renewables. I would not expect the same level of returns in other areas.
If language features were free we'd likely have had generics for a long time now. Unfortunately generics is a trade-off: you get development speed/ease and pay for it in compile time, binary size and/or execution speed.
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.
Right, so the author going awol would be a pretty big break off that trust right?
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.
If you don't pin your deps to a commit, what's the difference between the author deleting their account (and being replaced), and the author merging an evil commit?