3 ms·

> Python is a pain in the ass in production environments. I really dislike blanket statements like that one. Because any programming language can be a pain in

by devjab 3y ago

> Python is a pain in the ass in production environments. 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.

coldtea 3y ago
>Because any programming language can be a pain in production environments. Except one with memory safety and static builds. Like Rust can offer.
- oivey 3y ago
  I wish my bugs were mostly preventable via static typing and memory safety checks. For most ML and data work algorithm design and logic errors are the primary source of bugs. Type errors are usually the trivial things you fix in minutes.
  - coldtea 3y ago
    The topic wasn't bugs though - and nobody mentioned static typing. 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 for fewer problems 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). I understood the grandparent to mean something about how Python has issues with dependencies, and isolation, and paths, and updates, and so on. And the parent to mean that you can have deployment issues with any language. And to obviously neither to refer to design and logic errors, since the former wouldn't be singling out Python, and the latter would be saying a tautology. And neither would make sense to talk about those being an issue in production specifically.
    - oivey 3y ago
      You’re right, I misread static builds as typing. Python’s dependency management system sure does suck, although I think the problem could be solved without static builds. Overall they are a nice feature, though. 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.
MrJohz 3y ago
> 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. 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.
IshKebab 3y ago
Saying "any programming language can be a pain in production environments" is technically true but irrelevant and misleading. 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.
- devjab 3y ago
  > Python is definitely among the worst. 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.
bombela 3y ago
My experience is that python is a mess in production. Even with a full CI, tests, mypy for static typing, pinned dependencies recursively, bazel with custom rules to build those dependencies (because many python dep have undeclared deps). And of course abysmal performances. And I wouldn't dare letting juniors touch python. 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.
- canadianfella 3y ago
  [dead]
- ddorian43 3y ago
  > Rust is far from perfect. But in my opinion formed by experience, Rust is the best imperative language available right now. 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.
  - bombela 3y ago
    I understand "ecosystem/libraries" as code available for free. That a quick search online would convince most of us that it is trustworthy enough. That we hope won't require us to ever have to read, modify, and re-design the code. And if we are lucky has a state of the art abstraction for the domain it solves. So that we can get going with our task at hand as quickly and efficiently as possible. Under this light, Rust has now quite a large ecosystem of pretty good quality I would say. I have only written 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.

by devjab 3y ago

coldtea 3y ago

>Because any programming language can be a pain in production environments. Except one with memory safety and static builds. Like Rust can offer.

oivey 3y ago
I wish my bugs were mostly preventable via static typing and memory safety checks. For most ML and data work algorithm design and logic errors are the primary source of bugs. Type errors are usually the trivial things you fix in minutes.
- coldtea 3y ago
  The topic wasn't bugs though - and nobody mentioned static typing. 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 for fewer problems 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). I understood the grandparent to mean something about how Python has issues with dependencies, and isolation, and paths, and updates, and so on. And the parent to mean that you can have deployment issues with any language. And to obviously neither to refer to design and logic errors, since the former wouldn't be singling out Python, and the latter would be saying a tautology. And neither would make sense to talk about those being an issue in production specifically.
  - oivey 3y ago
    You’re right, I misread static builds as typing. Python’s dependency management system sure does suck, although I think the problem could be solved without static builds. Overall they are a nice feature, though. 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.

MrJohz 3y ago

> 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. 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.

IshKebab 3y ago

Saying "any programming language can be a pain in production environments" is technically true but irrelevant and misleading. 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.

devjab 3y ago
> Python is definitely among the worst. 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.

bombela 3y ago

My experience is that python is a mess in production. Even with a full CI, tests, mypy for static typing, pinned dependencies recursively, bazel with custom rules to build those dependencies (because many python dep have undeclared deps). And of course abysmal performances. And I wouldn't dare letting juniors touch python. 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.

canadianfella 3y ago
[dead]
ddorian43 3y ago
> Rust is far from perfect. But in my opinion formed by experience, Rust is the best imperative language available right now. 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.
- bombela 3y ago
  I understand "ecosystem/libraries" as code available for free. That a quick search online would convince most of us that it is trustworthy enough. That we hope won't require us to ever have to read, modify, and re-design the code. And if we are lucky has a state of the art abstraction for the domain it solves. So that we can get going with our task at hand as quickly and efficiently as possible. Under this light, Rust has now quite a large ecosystem of pretty good quality I would say. I have only written 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.