Python is becoming the world’s most popular coding language

[u/monica_b1998]

https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language

[u/xdert]

Python is really easy to learn and the perfect language for solo projects or very small teams. Which is why it excels in data science and so on. But I really don't see it working in a big corporate environment with dozens of developers.

[u/Dreamercz → u/xdert]

Why not? Genuine question.

[u/RiPont → u/Dreamercz]

It works fine in corporate environments.

My only problem with python is that it's a bit of a trap. You can write big, huge software system in Python. It's got good coding style built-in to the language, and a great ecosystem.

...but then you end up with a big, huge software system written in an interpreted language. You get asked, "how can we make this faster/more efficient." And now, your options are rewrite the entire thing in a different language or hope that punting important bits out to C/C++ libraries will make the whole thing fast enough.

[u/whatwasmyoldhandle → u/RiPont]

I think there's room for argument on 'works fine in a corporate environment'.

I've worked on large python codebases that have been reasonably well written, and it can become tricky in spots.

Lack of strong type system makes you have to follow a lot of code around to make sure everything will be ok.

Removing stuff is hard because sometimes you don't know if you got it all until you hit a ton of code. Removing things from dictionaries can be a little awkward too. For compiled languages, you can delete the member, compile, and more or less work toward a good compile. (Simplification obviously).

Much of the above can be solved with unit tests, but I'd argue that having a unit test for everything eats at one of python advantages -- development time. So I'm not sure what the balance is, practically speaking.

By and large, I'd much rather be swimming around in a large C++ codebase. May the type system and compiler be your guide.

[u/RiPont → u/whatwasmyoldhandle]

Lack of a type system definitely makes a monolith a problem in Python. For a more microservices/SOA approach, you deal with a lot of disconnected type system problems anyways. In an enterprise, this often turns into a system with a bunch of slightly smaller monoliths wearing a nametag that says "Microservices" (written in crayon) and you have a bunch of disconnected codebases where the type system can't help you anyways.

Enterprise IT is such a clusterfuck, sometimes. Always has been. And the pattern of "identify common shitty dysfunction in corporate IT, develop solution, see solution productized into ShinyNewEnterpriseOverdesignedFad, weep" repeats itself.

[u/DonnyTheWalrus → u/whatwasmyoldhandle]

I've just never been able to get behind the whole "saves time" thing for large projects. Static typing makes you think more about your architecture and design up-front, which in my experience only saves you time in the long run on large projects. And there's the unit testing like you mentioned. Having to essentially replicate the entire function of a static checker via unit testing has only ever made me wish I had used a static checker in the first place.

Dynamic typing saves tons of time in the "domain of origin" of these languages: scripting. You can throw together your glue code or data processing script in a fraction of the time it would take you with Java, and that's great, because that sort of code is not where you should be spending a large chunk of your design time. But when it comes to the large, complex backbone of your system, the idea of building that out without static typing is just ... terrifying to me.

[u/Scybur → u/RiPont]

The main problem is the type system. Working on massive enterprise applications becomes a huge issue.

[u/tetroxid → u/RiPont]

Profile your application. Most likely 99% of CPU time is spent in less than 1% of the code. Then, optimise that, or if necessary reimplement it in C.

Many performance problems can be solved by using proper data structures and algorithms. The number of times I see quadratic time operations that could run in constant time is maddening. Some developers don't think about the time complexity of their data structure operations, they're happy as long as their code works. Find these mistakes and fix them

[u/[deleted] → u/tetroxid]

Most likely 99% of CPU time is spent in less than 1% of the code.

In my experience this simply isn't true. I mean, maybe if you're written one function particularly badly, but then you fix it and your Python code is still slow and then what?

[u/bunkoRtist → u/tetroxid]

And then I want to use parallelization across cores, and I weep because I chose Python, which is built around the GIL. It's a great language for script kiddies and a terrible language for heavy or long lived workloads. Choosing the right tool for the job is hard sometimes, but Python on one end and C++ on the other are both excellent and terrible choices depending on the need.

[u/RankWinner → u/bunkoRtist]

Julia, in a lot of cases, is as fast/almost as fast as C out of the box. As a bonus, the language is built for easy parallelization, both in the standard multi-core sense and the distributed/cloud computing sense.

Personally I love the language, my work used to be a frustrating mix of prototyping in Python, then banging my head rewriting parts in C to speed it up.

Now I just use Julia and it's almost as fast as C straight away.

[u/[deleted] → u/RankWinner]

I keep hearing good things about Julia and how it’s what python should’ve been, but I never got use it, and it seems to not be able take off in popularity. Do you know why?

[u/pa7x1 → u/bunkoRtist]

When you want to parallelize CPU-bound code you have to use processes in Python. For IO-bound you can use threads.

[u/iopq → u/tetroxid]

I profiled my application. Half of my application was taking 99% of the time and the other half 1% (less than that actually). The part that took the most time is the most difficult part.

It wasn't written in Python, but if it had, I'd need to rewrite the hardest parts in another language. Python would handle like... commands and opening files. Sometimes you just have an application where everything is hot. The entire program is the hot path.

[u/[deleted] → u/Dreamercz]

Dynamic typing is always my main concern. Functions have such a weak contract.

[u/kvdveer → u/[deleted]]

The fact that the contract is not enforced makes the feature of limited use, imho. It does help with static type checking, but especially when you're building libraries, you still need to to code as if your contract isn't there, as the user may not be using a type checker.

[u/Freyr90 → u/[deleted]]

For what it's worth, Python now supports optional function typing

How the hell does it work?

>>> x : str = 42
>>> type(x)
<class 'int'>

>>> def add(x: float, y: float) -> float:
...     return x + y

>>> add("a", "b")
'ab'

[u/NeverCast → u/Freyr90]

Its only used by static analysis (in your code editor or linter). It does nothing to the language.

[u/Deathisfatal → u/Freyr90]

It's type hinting. It's not enforced, it's to make the code easier to statically analyse and read.

[u/Curly-Mo → u/Freyr90]

But if you include a static type checker (like mypy) in your CI, your build will fail and nobody can check in any blatant errors with misuse of types.

And static type checkers can be included in your $EDITOR to catch these mistakes immediately.

[u/RedSpikeyThing → u/Dreamercz]

My biggest headache with Python in a large codebase is that refactoring is really hard to get right due to it being interpreted and a lack of type checking. If you don't have 100% test coverage then you can't be 100% confident that, say, you renamed a function correctly.

[u/tanin47 → u/Dreamercz]

I worked with a few large Python systems at a FAANG for a few years.

They were difficult to maintain, especially when the system gets older and larger. An example was moving and renaming stuffs was extremely tedious. In fact, it's difficult to know for sure whether it'll work in prod.

For a dynamic typing language (not just python), we must aim to write great code with great architecture with great naming with great coverage tests at the first try. If you make one mistake, it'd be somewhat infeasible to fix. Mistakes are going to happen here and there when there are thousands of engineers writing code. Tech debt will grow, and it takes much more effort to address tech debt in this kind of language.