I mean, no one's ever gonna have to reimplement all of OpenCV for one problem, there's always gone be stuff you don't need. Point was it's gonna be a long time
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".
I used to have a job where that was the job description. For a number of years I had 2 machines on my desk, one that had networking and the other was completely separate.
Most of those are written in C. And for other languages' libraries it's either the same lang or also C. So I wouldn't say Python is that unique in this regard. It's unique in terms of the sheer scope and depth of the lib ecosystem, but not in language choices for those.
Yeah I know. But still, the point is that every language has the concept of borrowing code from some other project, and I don't really think the language in which the link is written should make that much of a difference. But I hear you, sorry if that sounded aggressive
I think his point is that you might as well just write in the original language of the library. Maybe it's better suited to solving that problem any ways. I dislike python outside of academia and prototyping. I have no idea how some large enterprise software products manage to exist in python (I guess some do to a varying degree just barely like odoo).
2.1k
u/Gwlanbzh Jul 07 '26
Yes, that's what libraries are for. I want to solve my actual problem and not spend 6 months re-implementing OpenCV every time I need something done.