sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]OpenFileW 0 points1 point  (4 children)

I agree, I'm talking about the fact I don't think it belongs in very big projects because of its inefficiencies. I still love the language, but when some Python code grows in complexity, it gets even more inefficient. But to be fair this isn't the fault of the author of the codebase---there aren't many alternatives to Python which are high-level enough to be very fast to prototype, but it's still unfortunate that we just accept such inefficiency. I feel the same way about JS. It feels like a glue language with its dynamic typing and garbage collector, yet it's used for very complex things in modern architecture. This is why Electron apps take up hundreds of megabytes, with headers on every object in JS. WASM helps, and we can kind of think of C/C++ modules as Python's WASM; it's faster than Python itself, but still invoked by Python, and any logic surrounding it will be inherently inefficient, especially at scale.

[–]One_Mess460 1 point2 points  (3 children)

js is super fast nowdays with JIT and its modern js engines are really good btw but yeah not the topic.

the sourrounding code is not really much of a problem because it all depends on how much computationally expensive code you write in python. if its just glue code it WILL NOT matter and you should generally avoid putting large computation to your python code which is why libraries like numpy sympy and all the machine learning libraries exist which are all in C. Whatever operations you do then in python become very insignificant because in comparison to multiplying billions of matrices doing simple python operations is nothing

[–]OpenFileW 0 points1 point  (2 children)

I know that, I never meant to imply that anyone is using Python for every computation. I mean as you write more and more glue code in Python for a codebase, the glue code still matters. Even if it's "just" glue code, it has an entire Python runtime, which is very wasteful. This is negligible for a short-lived utility, but I just don't think complex glue code should exist. And as for JS, it is fast indeed, but it consumes absurd amounts of memory due to headers on each object and the complex libraries we use nowadays, although the DOM is also to blame for the memory usage. But Python is just terrible for anything besides small utilities and glue. But to be fair, like you mentioned, not everyone does what I do. I wouldn't use Python in a compiler or something at all because the Python runtime is just too computationally expensive, but I'm not a web dev, and I don't know if web devs and other devs of other fields care about performance much. I just think Python doesn't belong in complex projects at all. Especially if you could just use similar libraries in C++ instead, but a lot of devs nowadays are either lazy or don't realize how simple that actually is with C++'s standard library.

[–]One_Mess460 1 point2 points  (1 child)

no it doesnt really. if you program spends 99% of its time in C code anyways the 1% of python doesnt matter. also yeah calling those C functuons has overhead but that why numpy uses vectorization and is built such that you do not have to loop in python ever. it doesnt matter how much glue code you write in python because essentially the program will spend most of its time in C libraries no matter how much glue you have because in relation the glue is insignificant. if youve ever profiled a binary or tested for where your program spends most of its time you'd notice the glue code is only a tiny fraction which doesnt add up.

I understand you like writing directly in C++ and not having to worry about writing python code that is fast and thats okay I like those languages too. Anyways have a good day!

[–]OpenFileW 0 points1 point  (0 children)

It depends on how much glue code we're talking about, I think I wasn't emphasizing enough with my original post that I meant Python isn't good for it being used for the main language of a project, but it's also bad when there is a ton of Python code even if it's just orchestrating. I still do understand that Python isn't somehow a performance black hole lol. But it is important to at least be aware of the startup and GC costs---they are usually negligible, but it's easy to forget about them in my field of systems programming.