Rust has clearly opined that they prefer a small standard library and a "choose your own libraries" vs "batteries included" approach.
If Rust included a crypto lib and a vulnerability was discovered, many fixes are backwards incompatible. Rust maintains strict backwards compatibility, which means updating the relevant crypto functions in the std lib would necessitate a major version bump. By keeping crypto outside of std, it allows the community to make backwards incompatible changes at a higher pace.
Python handles backward incompatibility changes via multi-year deprecations. I'm not familiar with Golang but a quick Google search reveals that it deals with this by using feature flags via GODEBUG. Excessive feature flag use is a bad pattern in my experience years ago, but I don't know if that's applicable here.
I prefer the trade-offs of a "choose your own lib" approach, but I understand the advantages and preferences of those who prefer a "batteries included" approach.
In general, I get your argument, but cryptography is the perfect example for something so well-specified, well-understood, and extremely widely used, that these arguments do not really apply. You are not going to have to make backwards-incompatible changes to SHA256 or Poly1305, etc. It has minimal API surface too, and is not going to be a large maintenance burden. But nearly everybody is going to need crypto at some point. It is great to have blessed and well-audited standard implementations that people can rely on, without even having to make a choice. This it is not something where you want “the community to make backwards incompatible changes at a higher pace.”.
Crypto is something any modern language should include in the stdlib, imo.
Proviso: you do cryptography in the stdlib if you have the means to do it well. Go did; Filippo Valsorda has built a whole company practice on keeping that library excellent.
Certainly, that's a better outcome than just providing bindings to OpenSSL, which is what most other languages do.
I think I agree, but I am not sure I understand what "the means to do it well" actually means. I would think of it more as a community decision: let's focus efforts on doing X well in the standard library since X is important and people shouldn't have to ask "ok, so which third party library is the best choice right now".
Let me be the first to point out that this is not an easy thing to do since it depends heavily on the community/team/maintainer dynamics. Even agreeing on the goal or scope can be really hard. But if the Rust community is as good as people say it is, that should be doable, right?
On the other hand it wouldn't have to be definitive and exhaustive. Just a safe default. Like http muxers in Go: the one that came with the standard library was fine for a lot of uses, but people generally used third party muxers. I certainly did. And then one of the most used third party ones became shaky as it was no longer being maintained (now it is again, I think). Eventually the one in Go was improved to where I'd prefer to use that since it represents a "safe default" (and I am probably not going to need whatever extra features or performance third parties can provide).
Also note that I see myself first and foremost as an _engineer_. I care less about purity in theory than what things mean in practical terms. And in practical terms I appreciate Go for having so much useful stuff in the standard library. Stuff I kind of think we should take for granted in any serious language today.
There are a few flashlights that have USB PD power bank functionality and also run on 18650 or 21700 rechargeable, replaceable Li-ion cells. I bought a Loop Gear SK05 Pro to replace Anker power banks for this use case.
As a hiring manager that visited every resume Github link because of my FOSS background, >99% of them had nothing of substance (no activity, school projects, etc).
Eh, us-east-1 is the oldest AWS region and if you get some AWS old timers talking over some beers they'll point out the legacy SPOFs that still exist in us-east-1.
> I know that concentrating knowledge / ownership at a person is not always good, but perhaps a better way to manage this is to... hire someone else who is competent or make other people more vocal.
> And yes, I don't like managers trying to shape communication patterns.
I'm a manager who shaped communication patterns (e.g. default conversations to a public channel) because we're solving different problems. By moving conversations to a public channel away from an individual, we're improving redundancy and reducing single points of failure. Our primary responsibility, which understandably garners discontent, is to prioritize the system over the needs of individuals, within reason.
There are many issues resulting from defaulting conversations in private channels or DMs that you've probably seen first-hand.
A slightly different viewpoint is that sharing in public or larger private channels allows for knowledge sharing and collaboration. Sometimes the key person is wrong because they aren't the only one working on something. I know that ego might get in people's way sometimes but other people in the team and in the organization also have valid perspectives. As a manager, its important to try and get to a best solution and that means collaboration, not a specific person's approach all the time.
The redundancy also helps the key person be able to disconnect when on vacation. If you are the sole knowledge base for some critical part of the company, might as well drag the work laptop with you every where you go.
I like this post. It has the right balance between uncomfortable reality and some humour!
All middle managers (in my experience) talk a big game about reducing/preventing key person dependencies, but on 100% of my teams, there were always multiple key person dependencies. The real issue: If you are not the key person for anything, you are the easiest to layoff (fire).
Visa, Mastercard, payment processors, banks, etc act as accountability sinks[0] for governments and political group by design. They are arbiters for moving/blocking money, not taking principled stances; there is no net neutrality equivalent for financial networks.
There's a lot of wasted discussion talking about an intentional design decision because they're arguing from consumers' perspectives, ignoring the huge benefit to political organizations (e.g. freezing Russian assets).
The EU is not a hegemonic state, but rather an economic supranational organization. France/Germany tend to be primary proponents of increased EU strategic autonomy, while Poland/Czech/Baltic states are less supportive.
Similar to recent discussions of self-hosting, it's a tradeoff of autonomy/control vs efficiency.
> The EU is not a hegemonic state, but rather an economic supranational organization. France/Germany tend to be primary proponents of increased EU strategic autonomy, while Poland/Czech/Baltic states are less supportive.
Well obviously, these states know how bad the Russians are since they were terrorised by them for decades. They'll be the first on the chopping block. And they know that Europe does not have much deterrent of its own right now so they're screwed without the US. Though this will come.
Sure, nobody is denying that. That does not contradict the argument (not mine) that perhaps people lived more secure lives under Soviet rule.
Note that I define "more secure" as in not living in fear of losing home and income. Not necessarily that their standard of living was as good as those in the West.
It depends: if you are part of the party and things are going good then yes. However, if you are from a group of people that you government has decided is trouble, then you tend to disappear in the night. Like my mother in law who says things where so safe when there was police on every corner in Spain during the dictatorship but my father in law was hiding "reds" under the floorboards as they where Jewish and being procecuted. One does not take away from the other, instead of criminals threatening you it's the government goons.
> if you are from a group of people that you government has decided is trouble, then you tend to disappear in the night.
So this really is a case of survivorship bias. Those that survived the Soviet times, remember it, not fondly, but as a more secure time. Those that didn't survive, we don't hear their accounts very much.
> my father in law was hiding "reds" under the floorboards as they where Jewish and being procecuted.
> Germany tend to be primary proponents of increased EU strategic autonomy
Germany isn't doing this as much anymore, because Germany Inc has become increasingly dependent on their investments within the US [0], especially after the triple whammy of the Biden-era IRA [1], the sanctions on Russia sparking a domestic energy crisis [2], and Chinese players outcompeting German industry in China [3].
This can be seen with Germany purchasing American weapons for Ukraine over French objections [4]
Chrome launched in an era where IE didn't stop the gazillion pop ups and crashed pretty often losing dozens of windows, before tabbed browsing and with no restore. Firefox was a resource hog due to memory fragmentation.
Google was also the company that espoused, "Do no evil" and contributed a bunch to open source. A lot has changed since then.
It's a framework to prioritize important tasks instead of falling into the agency trap, akin to prioritizing meaningful strategic tasks such as product development and tech debt instead of fighting fires.
If Rust included a crypto lib and a vulnerability was discovered, many fixes are backwards incompatible. Rust maintains strict backwards compatibility, which means updating the relevant crypto functions in the std lib would necessitate a major version bump. By keeping crypto outside of std, it allows the community to make backwards incompatible changes at a higher pace.
Python handles backward incompatibility changes via multi-year deprecations. I'm not familiar with Golang but a quick Google search reveals that it deals with this by using feature flags via GODEBUG. Excessive feature flag use is a bad pattern in my experience years ago, but I don't know if that's applicable here.
I prefer the trade-offs of a "choose your own lib" approach, but I understand the advantages and preferences of those who prefer a "batteries included" approach.