I really dislike blanket statements like that one. Because any programming language can be a pain in production environments. One of the disadvantages of Python is also one of it's advantages. Because it's much easier to end up with a terrible production environment when you use "chaos" languages like Python or JavaScript, the tooling to avoid the pain points is so mature. With those in place Python becomes great in production.
Yes it'll require your organization to take some serious CI culture decisions and also enforce them. The thing is, however, while you can get a long way without doing that with some programming languages, you're frankly always going to want them by the time you reach enterprise size. So it's just so much easier if you get it done right away, and you will, if you're serious about using Python.
I'd argue that if it's a pain to work in your production environments then the issue is not the technology but the process.
Except one with memory safety and static builds. Like Rust can offer.
The grandparent said "Python is a pain in the ass in production environments".
And the parent said: "any programming language can be a pain in production environments".
My point was how Rust is better for backend services in production, as it wont have memory bugs (which have long plagued backend services and have resulted in many exploits), and it also offers static builds (so deployment can be dead easy, and wont be having the kind of environment issues some languages have).
In the aspect of "design and logic errors", Rust would be like most other languages people actually use for backends, so that's not a factor pro or against.
I think the memory management element is a little dubious, though. Torch’s memory management, for example, is fairly safe, and it internally has its own allocator. A Rust version (I think) that implemented the same would have to rely on unsafe blocks, and would likely have many of the same potential pitfalls as Torch. Time spent satisfying Rust’s borrow checker is likely lost productivity compared to just relying on Python’s reference counting and garbage collection. That productivity could be better spent on making the product better with new features and fixes of algorithmic mistakes.
Could you describe what you mean, as in what that tooling is? Having done some funky deployments in Python before, I've never been very impressed by the ecosystem and tooling.
It implies that all programming languages are equally painful in production, but that obviously isn't the case.
Python is definitely among the worst. Easily the worst among popular languages. It's closely followed by C++. Go and Rust are faaar nicer. Totally different league.
I don't think that is true at all.
Django would frankly be an excellent choice for most web apps and if you're into microservice architecture then frameworks like pantherpy are almost as great as Java's Quarkus. That being said, we do try to limit our Python use to be exclusively for the BI/AI/ML part of our business and that's solely because that's the language those people work with in my area of the world.
This is mainly for pragmatic reasons. We use Typescript for most things because it's nice to have a language that's shared between the front and backend of things when you work in the small teams that are non-tech Enterprise. Then when we need efficiency we use C (and Rust more and more because it protects us from ourselves), when we do embedded it's C and when we need something like Odata or whatever .NET(y) it's C#.
I think Go is nice to write and terrible to work with. Not so much because of the language but because you're going to be writing basically all your libraries from scratch, or alternatively, putting massive maintenance efforts into the ones you consume. Which to be fair, isn't that different from using Typescript, but as long as the frontend of enterprise apps is as it is you're going to be working with Typescript whether you like it or not.
Rust is far from perfect. But in my opinion formed by experience, Rust is the best imperative language available right now.
Note that I have both written software in Python and built a whole devxp stack that includes Python. I wrote the first version of Docker in Python for what is worth, and at my last job; over many years; I built and maintained the polyglot dev experience for 150 devs.
But what about along with the ecosystem/libraries. Would you say in total Java might be better (assuming webdev)? Especially with the Loom project where you don't have to do "async" syntax.
Under this light, Rust has now quite a large ecosystem of pretty good quality I would say.
I have only wrote small thread safe system level libraries in Java. But I sure noticed that javac did not have a borrow checker ;)
For webdev I had no problem with Rust async or not. But my definition of webdev is reduced to a web server that calls out to a database or another service.
This is where having a non-Python PL, such as Rust, can make a huge difference for both ease of production deployment/maintenance as well as having truely efficient production inference.
> Like, really.
Trust me, bro?
> Yeah, but the goal of this isn’t “use this instead of Python to hack up a model”
This was never said.
> You know, those hugging face guys kindaaaaa do know what they’re talking about.
This was never challenged.
> Python is a pain in the ass in production environments.
This is "I don't like python", but phrased adversarially.
Language flamewars suck. Some people don't like certain languages in certain contexts. I see Rust's syntax (having written a small to medium amount of Rust) and feel pretty confident I wouldn't task my data science team with writing or maintaining Rust codebases. We can squabble over "But eventually you'll get it", but ultimately that's more of a priorities comment than a language feature.
But it is an incredible pain in the ass in production environments.
Environment drift is something that _always_ seems to happen, no matter how diligent people are about using venvs or dependency managers or w/e.
One of favorites was when we did a dependency upgrade (something that required a change to Click) we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code.
Recently we had mypy stop checking one of our internal packages because of a Dockerfile refactoring. The package could still be found at runtime but the type information just wasn't found by mypy. We didn't notice it until we started getting errors at runtime, which made the fix a lot more difficult to diagnose.
There's always someone saying "you're using it wrong" or "you're doing something worng", even if you follow the guides and howtos to get started.
For a language which states "There should be one -- and preferably only one -- obvious way to do it" as part of its guiding principles, that there is no single one way to use it right in production -- let alone an obvious one -- that makes it, simply, a "pain in the ass".
Unlikely. If you are using pre-commit to run black then the version being used lives outside your venv and hence not subject to dependencies you are using. Poetry should also be outside your venv.
And, again, if something that was configured wrong this goes back to how managing Python is a pain in the ass. I should be able to dedicate my brain power to the problems I need to solve, not what things need to be in my venv and what things need to be outside of it.
But I'm curious what the nature of a black upgrade being forced on you. Like a manager or stakeholder had an edict stating everyone must upgrade to 23.x?
I feel like your reply is demonstrating this comment perfectly. You could be perfectly correct, but their point still stands that _they_ had a horrible experience that shouldn't have been so difficult. If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up.
> If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up.
This has never happened for any technology ever. People misconfigure things all the time. Even hardened technologies get used incorrectly very frequently. It's just the reality of our industry. Which is why I say, all of this is just a proxy for "I didn't like my experience with Python", which is fine! But also in no way condemning of the technology.
"I find it hard to maintain Python in production environments", but worded adversarially.
> One of favorites was when we did a dependency upgrade (something that required a change to Click) we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code.
This is literally just a misconfigured set of tools then.
> There's always someone saying "you're using it wrong" or "you're doing something worng", even if you follow the guides and howtos to get started.
This is true of all languages and frameworks. There are people _in this comment section_ insisting those that have had negative Rust experiences must simply be doing it wrong. This is more a comment on our industry than any individual technology.
> For a language which states "There should be one -- and preferably only one -- obvious way to do it"
Yes, this has always been a bold faced lie from the Python community. Marketing speak is marketing speak.
> that there is no single one way to use it right in production -- let alone an obvious one -- that makes it, simply, a "pain in the ass".
It's as much a pain in the ass as literally every piece of technology, as the above statement is true for every technology and framework that exists.
I acknowledge that you don't like it. That's great! But again, language flamewars suck, and suggesting that something is bad because you've individually had a bad experience is pretty silly. Lots of people successfully deploy and maintain python applications of various sizes without referring to the process as "a pain in the ass".
>> This was never said.
Quotes don't have to used solely to indicate somebody explicitly said something.
…it’s:
> And simply removing Python from production workloads. Python can really add overhead in more complex workflows and the GIL is a notorious source of headaches.
You know, those hugging face guys kindaaaaa do know what they’re talking about.
Like, really.
Python is a pain in the ass in production environments.