I think people are missing the main point. The real issue with Rust is that it is a designed language which is really tuned and optimized for a specific use case. And for that specific usage, it is really, really good. But even so, it requires a lot more up-front work, due to the limitations and restrictions it imposes.
But it is NOT a good general purpose language. And, maybe to be putting words into the author's mouth, that is their main beef. That every seems to be pushing "Rust All Things" even when it makes no sense, and even if there are much better alternatives available.
So for such comments as "so what about compile time", the issue is that for some, compile time _is a concern_. If it isn't for you, great. But you just can't discount what are valid concerns for others.
People seem to forget that languages are _tools_, and as such, have different sweet-spot use-cases.
There are some wheels, for example, 'lxml' that bundle in their binary possibly incompatible external libraries, or older libraries than what you would like. This can cause library conflicts.
It helps, that's for sure. But this sort of knowledge should not exist in the environment in any case. It should be part of the canonical package list, and not hidden away elsewhere. The whole idea of a dependency manager should be a centralized and consistent way to install everything you need and not be dependent on what values may or may not exist as a env-var.
This has the same issue as so many package managers for Python, namely, it doesn't provide a way for --no-binary to remain sticky.
There are times when you do NOT want the wheel version to be installed (which is what --no-binary implements in pip), but so many package managers including uv don't provide that core, basic functionality. At least for those that do use pip behind the scenes, like pipenv, one can still use the PIP_NO_BINARY environment variable to ensure this.
It cannot be stressed enough how _vital_ these scripts were to making the WWW an actual functional technical resource; These scripts were a key, if not the key, in growing the actual interactive web, showing the potential of CGI, and in guiding the evolution of web2.0 and beyond.
Its value and place in history can't be overstated.
"You should never worry about betraying your workplace because given the chance, your workplace will definitely betray you. Loyalty to individuals. Relationships. That's what makes the world go round."
But it is that exact kind of unknown which makes most people and entities avoid those licenses in the 1st place. If the goal is to significantly limit the distribution and reach, I guess it makes sense, but if the goal is to have people actually use it (and therefore hopefully contribute to it), then those licenses and the projects that use them are actively avoided.
The entire work can be licensed under GPL, but those parts that were MIT remain, individually, still under MIT. MIT specifically and explicitly allows for 'sublicense'ing
How a license which conflicts with the OSD can "clearly (be) an open source license in the full spirit and original intent of open source" is beyond me.