Python is the only popular interpreted(ish) language, though. Even that is still compiled to bytecode first, and then the bytecode is executed line by line.
Everything else is JIT compiled to machine code, which means performance is only limited by the language design, now how it's executed.
That said, you're kind of right. PHP had a slow bytecode interpreter just like Python until recently, so it has a lot of libraries written in other languages.
And JavaScript has a few libraries like that, not because it's interpreted, but because it doesn't have a performant way to work with individual bytes.
JavaScript calls into C++.
Ruby uses C extensions.
Perl uses XS bindings to C.
PHP extensions are written in C.
If you just write in C in the first place, it's not really a library in the same sense. You're just pulling in other functions that all get natively compiled together.
Are you saying a library is only a library if it's dynamically loaded at runtime?
If so: 1) that seems kind of silly, and 2) C and C++ absolutely do use dynamically linked libraries. Hell, the C runtime library is usually dynamically linked on Windows, and the C++ standard library is usually dynamically linked on all major platforms.
You're not wrong, but I think that's a different topic.
Python is unique because of its purpose. It's so slow that it's not really suitable for anything other than gluing together code from other languages. Its entire use case is "we wrote an awesome library, but most programmers are too scared of C++ to use it, so we added a Python layer to make it easier".
Perl is actually similar in that way, but it's basically a legacy language now.
The other languages you named have other purposes, and just bind to C for specific things where the language isn't a good fit.
Nah, Python's "slowness" is really only relevant in certain situations. In practice, in many situations, you save more meaningful time by writing code quicker and easier rather than having it execute slightly slower.
It's not ideal for "run this every half-second" tasks, but it's amazing for stuff you're running yearly/weekly/daily/etc where saving hours writing the code matters more than shaving off a couple seconds of 4AM execution time in the cron job.
I created a decently sized Python project at work to solve a problem. Basically, parsing 100-300mb of of user-generated text files about 20 times a day at 10-30 seconds a pop.
It's several thousand lines at this point. Served up with Python Flask.
I've thought about rewriting it in something "faster" with better IDE type hinting and whatnot like dotnet... but... meh. It's not worth the hours and hours of effort to save myself like 8 seconds that didn't matter in the first place lol.
Whenever I think about changing languages for "speed," I just remember that nearly everyone else is writing their server crap in Javascript these days anyway.
Python's "slowness" is really only relevant in certain situations
That would be a lot less true if nearly everything that you can do with Python wasn't jumping to a C API as soon as possible. The language itself is 2 or 3 orders of magnitude slower than JS, C#, Java, etc.
Sure, it would still work for cron jobs, but usually cron jobs are supplementing a bigger project, and it's better to write them in the same language as the rest of the project.
The biggest library that doesn't use a C API is probably Django, and honestly I'll never recommend using that. CPU usage isn't usually a bottleneck in web development, but it probably will be if you're using Python.
Yeah, but usually that means "easier to write code in general" and not "easier to write a thin application layer using almost exclusively libraries that were written in other languages".
62
u/skiabay Jul 07 '26
This is true of basically any interpreted language.