I was mainly thinking about how so many Rust projects advertise very loudly that they’re written in Rust. Like, they would have -rs in the name, or “in Rust” as part of their one-line description. You rarely see this kind of enthusiasms for the the language in other languages. Not a bad thing by the way! And also there’s the “rewrite it in rust” meme, where people seem to take perfectly functional projects and port them to Rust (again, not a bad thing! Strength in diversity!)
For Python I think there’s an actual point though: A lot of Python projects are user friendly wrappers for pre-compiled high-performance code. It makes sense to call something “py<SomeKnownLibrary>” to signal what the library is.
I was mainly thinking about how so many Rust projects advertise very loudly that they’re written in Rust. Like, they would have
-rsin the name, or “in Rust” as part of their one-line description. You rarely see this kind of enthusiasms for the the language in other languages. Not a bad thing by the way! And also there’s the “rewrite it in rust” meme, where people seem to take perfectly functional projects and port them to Rust (again, not a bad thing! Strength in diversity!)Yeah, no python package has “py”, JavaScript “.js” or java “java”. None at all.
For Python I think there’s an actual point though: A lot of Python projects are user friendly wrappers for pre-compiled high-performance code. It makes sense to call something “py<SomeKnownLibrary>” to signal what the library is.
Well, it’s the same in rust, that’s why I agree more with the first interpretation.
There is an existing solution in C/C++, just make some binding and call it *.rs
Both python and rust use py and rs in the same way, to signal that it’s the python/rust version of that library.
Of course, there are exceptions, but that’s what usually happens.
Check Julia then, .jl everywhere