That misses the point. The point is for easy validation that the key was generated appropriately. Many api keys have a standard prefix for just this reason. It especially helps on documentation where the key name might be confused with the value: "your key starts with hnkey-"
I mean that's pretty common in most OSS projects just because you have free entry to the debate.
If you want to see go-uniquie highschool debate club, look at Go team attitude to fixing logging, where community proposed multiple ways of solving it, Go team rejected all of them and then made massive navel-gazing post that could be summed up "well, there is multiple proposals THAT MEANS PEOPLE ARE UNSURE ON THE ISSUE so we won't do shit"
...then removed every question related to go logging (that were common in previous ones) in their yearly survey
The work involved in maintaining a standard library is things like bug fixes. A larger standard library (or multi versions) means there's more likely to be bugs. You also have performance improvements, and when new versions of the language come out which has features to improve performance, you will most likely want to go back through and refactor some code to take advantage of it. You will also want to go through and refactor to make code easier to maintain. All of this just gets harder with a larger surface.
And the more stuff you pack into the standard library the more expertise you need on the maintenance team for all these new libraries. And you don't want a standard library that is bad, because then people won't use it. And then you're stuck with the maintenance burden of code that no one uses. It's a big commitment to add something to a standard library.
Every library is a liability especially in terms of api. There are many example where the first take on a problem within a std lib was a bad choice and required a major overhaul. Once something is in standard library it’s literally impossible to take it back without breaking the world if you don’t control api consumers
Yes, in python they break something at every release now. It's terrible. It mostly is because they remove modules from their standard library for no good reasons.
For example they've removed asyncore, their original loop-based module before the async/await syntax existed. All the software from that era needs a total rewrite. Luckily in debian for now the module is provided as a .deb package so I didn't have to do the total rewrite.
edit: as usual on ycombinator, dowvotes for saying something factually true that can be easily verified :D
The thread is about the code in the std lib being a huge amount of work because the code in the std lib needs to be kept working with new language releases.
And then you answered about downstream code breakage totally outside the std lib.
Nah, the engineering standards like that generally make everyone's job easier; the "pro" carpenter will save just as much time as the newbie, hell maybe more.
Design patents are more of "you need to build house with this exact room layout" than "the materials and ways to put them together are standarized"
The corpo-speak sounds like mostly way to communicate contentious things in nice way, everything done to not sound negative or aggresive, while knowing (or hoping) that other side gets the message.
It is awfully unproductive way to do it but I'm sure HR approves.
Do note that senior manager thinking the work is redundant also might be completely not aligned with reality. so "I think your work is redundant" is much closer to usual reality. And it's easy to be seen that as you pretty much also need to be a PR person for your own department, not just a manager, especially if department is doing necessary but not glorious tasks
This confuses the economics of open source. It's easier to contribute changes upstream than maintaining a fork. A smart business decision is using permissively licensed software that is maintained by other teams (low maintenance cost) while contributing patches upstream when the need arises (low feature cost).
Bringing a fork in-house and falling behind on maintenance is a very bad idea. The closest I've ever come to that in industry was deploying a patch before the PR was merged.
reply