I don't disagree with your overall point but in the world of high-end watches Rolex watches _are_ mass produced and leverage economies of scale. I think the latest estimates are around 800,000 watches produced per year by Rolex.
To be more exact, what you want is not a slow password hashing algorithm. What you want is an algorithm that is as efficient for the defender as it is for the attacker. The key is that you do not want an attacker to be able to abuse custom hardware or distributed compute in order to gain an efficiency advantage.
It's a nice sentiment but that's how you end up with abandoned, low quality projects that no one uses. Or even worse - abandoned, low quality projects that half the Internet relies on.
What incentives would a someone have to invest a considerable amount of time in releasing and maintaining an open source project if they can't even use that to promote themselves?
You can be perfectly competitive without playing arena or buying packs. I haven't paid a cent for the past 2 years and can play all the competitive decks I want in every meta. Blizzard has been very good with bumping up the rewards you get from playing normally.
His point is absolutely not applicable. Rust is a _very_ new language. The community will eventually converge on specific crates for specific purposes in time.
> This isn’t a question that comes up so often with respect to (say) Python because Python has an effective form of curation – blessing things into the standard library, at which point their alternatives generally disappear. In effect, Python modules are quality-filtered on the taste of the BDFL and the devteam.
I love Python but this statement is absolutely coming from someone who does not write Python on a regular basis. Many stdlib modules are greatly outclassed by third-party alternatives - urllib2 vs requests, datetime vs arrow just to name a few - to the point where no one actually uses the stdlib modules in production.
Yes they can, they'll just have to commit resources to keeping up with kernel changes instead of having it done for them upstream. You can't have your cake and eat it as well.
In my experience a lot of the problems with automatically converting existing Python 2 code to Python 3 code is that the Python 2 code usually makes fundamentally broken assumptions when it comes to unicode and bytes.