Python's success is partly because it is easy to do things. It has a huge market share. Combining the speed advantage of one programming language, with another seems like a great idea.
Is it really going to be faster? In the benchmark they cited in the README [0], they are in 10th place among Python frameworks. This is not a real-life benchmark, as it merely expects a hardcoded response. In fact, Robyn’s 10th place is thanks to a feature designed for benchmarks like this, i.e. marking responses as constant [1]. Three more frameworks beat Robyn if you disable this benchmark optimization.
Can't speak for Robyn since that is competing in an already aggressively competitive landscape (webserving). Whereas introduction of RUFF/UV by astral has been exceptional.
The problem with all this combining is that it's making apps less portable. Like I want to make apps that work on desktop+mobile with flet[0], but now I have to specifically seek out more "traditional" alternate packages and hope they stayed in reasonable feature parity with these Rustified Frankensteins. Not a fan at all.
Correct me if I'm wrong, but the way you use "traditional", basically means "written in C", right? I certainly can sympathize with your point about the frustration of compatibility issues in your narrow usecase (though I don't agree that it should affect what options we have), but connecting to the original commenter's point, it's really common for libraries in python to be wrappers for things written in other languages.
The use case isn't that narrow though. Just the flet project has 12.5k GH stars (which I would say represents significant adoption), and I'll wager there are other projects out there running in random environments that have Python support but bringing in Rust will be a serious pain. It's degrading the ecosystem IMO. The only other language I'm aware of that has significant library wrapping is Fortran, and those libraries have on par or better alternatives in C as well as are now essentially legacy.
