Why? Native code is costly: machine code generally has a much bigger footprint than interpreter bytecode. In some cases, interpreted code can be faster due to cache effects and reduced IO load making it faster to be smaller.
Speed is relative. Does every piece of code need to be as performant as possible? No. I would argue that, in most cases, speed of development is far more important than speed of execution. This is, of course, not true for things like drivers or statistical analysis.
Writing a web application? Speed isn't that important as the whole process is i/o bound anyways.
Writing a machine learning algorithm? Depends.
Web scraping? I/O bound, speed not really important.
Image processing? Speed matters at least a little bit.
Writing networking glue for distributed systems? Speed probably doesn't matter.
It's all relative. If it needs to be fast, it needs to be fast. Most things don't really need to be fast. For the things that don't need to be fast, why build them with C/C++/Rust/Go when you could spend half the time building them in Python/Ruby/js/etc?
PyPy isn't an interpreter, you are just validating my assertion about JIT/AOT compilers.
I usually ignore it when talking about Python, because that is what the community does, by gathering around CPython.
> For the things that don't need to be fast, why build them with C/C++/Rust/Go when you could spend half the time building them in Python/Ruby/js/etc?
Because one can use languages like OCaml, Haskell, Lisp, Scheme, Racket, F#, C#,... thus having both the productivity of a REPL environment and the execution speed of native code.
>PyPy isn't an interpreter, you are just validating my assertion about JIT/AOT compilers.
I thought we were talking about Python implementations exclusively. My mistake.
>OCaml
I have no experience with OCaml, so I won't make any comments regarding it's efficacy.'
>Haskell
Well thought out language. I like the purity, but it's too academic for real world use outside of scientific computing. FP isn't for everyone, and my personally belief regarding it is that it is better used as a tool alongside other paradigms than all by itself as the only paradigm.
>Lisp
Lisp is useful for a lot of things. It's also not very popular for new projects as far as I've seen. There are also a ton of different versions, so I don't know if "Lisp" is really a good descriptor.
>Scheme
As far as I know Scheme is the defacto teaching language for most compSci programs.Or, at least it was for a long time. Once again, FP is not for everyone. A lot of people also dislike Lisp style syntax, myself included.
>Racket
Same issues as Scheme.
>F#
F# is a fantastic language. There's not really a whole heck of a lot to complain about other than the .NET implications. The only detriment relative to Python is F#'s much smaller ecosystem and community.
>C#
Once again, some people just don't like .NET stuff. A lot of people also see static typing to be a detriment in many use cases.
Relative to Python, these languages also share several other problems when it comes to real world application: lack of competent developers, stagnating ecosystems, lack of third party libraries, ecosystem lock in, and cross-platform comparability issues. In the case of languages like Haskell, they could even be considered "esoteric".
I'll give you that many of these languages are more "pure" or "logical" than Python. I'll even give you that most of them are designed much better than Python. None of that changes the fact that Python is overall easier to read, easier to learn, easier to write, has a better ecosystem, is platform and file system agnostic, has a very non-restrictive license, and is, overall, very pleasant to work with.
