I don't really get this argument/issue he's raising. Yes, important person in the OSS community, but this feels like a hit piece.
What's the core of the issue? That you should consider going and looking at the code before you decide to use it. Isn't this a good thing? In fact, I started committing back to some projects because I read the code, and decided I wanted something in addition or minor change. This encourages community IMO.
The examples of Python seem really strange too, because I've found Python to have horribly divergent implementations with severe faults if you choose one over another. Rust is a smaller and younger ecosystem, but I haven't really had that problem yet. I do find myself researching my dependencies more, but shouldn't we all be doing that anyway? I'll pick something that it looks like is actively developed over something that hasn't had a commit in years.
Point, Rust hasn't hurt me in terms of dependencies yet in the same way that I have been in other languages. Now, I know I will be burned by a dependency in the future, I can guarantee it, but I also know that the openness and helpfulness of the community will mean that fixing it will be easy and encouraged.
> That you should consider going and looking at the code before you decide to use it. Isn't this a good thing?
No, its not. There are many problems with it, including wasted time
and fragmentation. First, "looking at the code" means you need to spend time on discovering, than assessing 50 existing libraries, each of them half-baked and broken in some ways. Had one of them been blessed by inclusion in stdlib, 90% of people would not spend a second on any decisions and just use that one. Multiply that by all libraries you depend on and it comes to sizeable amount of time. Whatever you choose however, may be abandoned a week later, so you will be responsible for maintaining it. Also once you learn one of those, you'll work on next project that have chosen another so your knowledge and util functions need to be redone.
This is entirely pointless madness. Having rich stdlib (or some other way of enforcing unification) is really a good thing, and not having it causes a lot of problems.
> I do find myself researching my dependencies more, but shouldn't we all be doing that anyway?
No, we should not. We should have one way put in front of us and be certain that it works well for
common usecases, will have long term support and everyone else is most likely to use it too.
An extreme example of that is C/C++, where nearly every major library comes with its own string implementation.
What's the core of the issue? That you should consider going and looking at the code before you decide to use it. Isn't this a good thing? In fact, I started committing back to some projects because I read the code, and decided I wanted something in addition or minor change. This encourages community IMO.
The examples of Python seem really strange too, because I've found Python to have horribly divergent implementations with severe faults if you choose one over another. Rust is a smaller and younger ecosystem, but I haven't really had that problem yet. I do find myself researching my dependencies more, but shouldn't we all be doing that anyway? I'll pick something that it looks like is actively developed over something that hasn't had a commit in years.
Point, Rust hasn't hurt me in terms of dependencies yet in the same way that I have been in other languages. Now, I know I will be burned by a dependency in the future, I can guarantee it, but I also know that the openness and helpfulness of the community will mean that fixing it will be easy and encouraged.
Disclaimer: I love Rust.