Do you think writing backend with Python feels wrong?
16 comments
Java has the advantages that it fully supports threads, I've seen JVM back ends hold up under heavy load. It is often possible and sometimes easy to get a 7.5x speedup on an 8-core machine with Java.
I write a lot of backend code using aiohttp in Python for my own side projects, it is really a blast, particularly if the code is "more than a web server", say it is listening to message queues, connected to something like Denon's HEOS API which is asynchronous, and also offering websocket endpoints.
I know some organizations with >5 coders seem to find pip is Kryptonite though.
I write a lot of backend code using aiohttp in Python for my own side projects, it is really a blast, particularly if the code is "more than a web server", say it is listening to message queues, connected to something like Denon's HEOS API which is asynchronous, and also offering websocket endpoints.
I know some organizations with >5 coders seem to find pip is Kryptonite though.
Java’s strength IMO is that the JVM is pretty reliable and performant even under heavy loads, and can be predictably tuned and optimised where that’s needed. That’s pretty compelling along with an OK language that works well at scale (lots of developers).
Aiohttp is too risky to code,and it is only good if you are only one working on that project, or you are working with good friends of yours.
Give it in a hands of bad programmer, you are fucked harder than any pornstar I have ever and yet to seen in my 21 year lifespan.
You are right about pip too, I don't know how did they achieve to come with a package manager that is worse than NPM. Such a feat.
Give it in a hands of bad programmer, you are fucked harder than any pornstar I have ever and yet to seen in my 21 year lifespan.
You are right about pip too, I don't know how did they achieve to come with a package manager that is worse than NPM. Such a feat.
pip got frog boiled into it.
Maven is a correct package manager. Maven is able to get a global view of the metadata for all of the packages that conform to the specification so it can find a correct solution for dependencies before it downloads any JARs.
Historically, Python used egg files that required you to run the setup.py (and download dev dependencies) before you knew what the dependencies of a package are. This has the real advantage of being able to change your dependency list based on your environment (say loading a GPU-enabled or platform-specific version of a dependency) but "doing the right thing" would involve doing all this work in isolated environments and doing an awful lot of work.
Thus you get the "optimistic" approach used by pip which is to start installing packages one at a time and hope for the best. There is no correct strategy to recover when it paints itself into a corner.
Almost all pypi packages are wheels now and they just introduced the ability to download just the metadata file (a few years back when I was struggling with Python packaging at a startup I did find you could accomplish the same with two or three http range requests since you can find the superblock and directory information at the end of the wheel and then fetching the metadata is easy.) If a package is only available as an egg you can do what anaconda does which is make a wheel of it for your specific configuration and stash it in your private repository.
We might see a correct system emerge out of this, but...
Python has suffered from people who think an 80% or 90% correct solution is acceptable but that's just wrong. Until ChatGPT came along nobody thought an 80 or 90% sorting algorithm is acceptable. Certainly people could decide they need or don't need certain features (for instance pyenv) but there are certain things that are either wrong or right and you can either invest a finite amount of effort into getting things right or struggle forever pushing bubbles around under the rug.
Python also needs a good answer for environmental variation. For instance there is scikit-learn and there is a version of scikit-learn compiled against Intel's MKL library. The latter package should be tagged as a substitute for the first so that somebody who wants to use it can swap it out without making any changes to the package configuration file (can't do that because you don't want to check those changes into version control.) There are some affordances for packages having optional features but these just aren't adequate to the task.
Maven is a correct package manager. Maven is able to get a global view of the metadata for all of the packages that conform to the specification so it can find a correct solution for dependencies before it downloads any JARs.
Historically, Python used egg files that required you to run the setup.py (and download dev dependencies) before you knew what the dependencies of a package are. This has the real advantage of being able to change your dependency list based on your environment (say loading a GPU-enabled or platform-specific version of a dependency) but "doing the right thing" would involve doing all this work in isolated environments and doing an awful lot of work.
Thus you get the "optimistic" approach used by pip which is to start installing packages one at a time and hope for the best. There is no correct strategy to recover when it paints itself into a corner.
Almost all pypi packages are wheels now and they just introduced the ability to download just the metadata file (a few years back when I was struggling with Python packaging at a startup I did find you could accomplish the same with two or three http range requests since you can find the superblock and directory information at the end of the wheel and then fetching the metadata is easy.) If a package is only available as an egg you can do what anaconda does which is make a wheel of it for your specific configuration and stash it in your private repository.
We might see a correct system emerge out of this, but...
Python has suffered from people who think an 80% or 90% correct solution is acceptable but that's just wrong. Until ChatGPT came along nobody thought an 80 or 90% sorting algorithm is acceptable. Certainly people could decide they need or don't need certain features (for instance pyenv) but there are certain things that are either wrong or right and you can either invest a finite amount of effort into getting things right or struggle forever pushing bubbles around under the rug.
Python also needs a good answer for environmental variation. For instance there is scikit-learn and there is a version of scikit-learn compiled against Intel's MKL library. The latter package should be tagged as a substitute for the first so that somebody who wants to use it can swap it out without making any changes to the package configuration file (can't do that because you don't want to check those changes into version control.) There are some affordances for packages having optional features but these just aren't adequate to the task.
I think as your backend grows larger you will likely begin to run into the issues that I experienced with Python through my years of writing it.
The dynamic typing eventually makes certain kinds of bugs creep into your code and it can be difficult to realise.
Code written in dynamic languages are also more difficult and time consuming to refactor than code written in a statically typed language.
The dynamic typing eventually makes certain kinds of bugs creep into your code and it can be difficult to realise.
Code written in dynamic languages are also more difficult and time consuming to refactor than code written in a statically typed language.
Yes that is right too.
Dynamic typed languages always feels like I am 6 again, with my crayons all over the place, doing random bullshit go till something sensible comes out.
Good luck finding what is wrong if a bug occurs, good luck if you will refactor it and think how can you replace it, how can you rewrite it without destroying the whole aesthetic of the code. just like my parents trying to figure out how will they renew the wall after I draw a huge chunk of random shit to the wall with my crayons.
Dynamic typed languages always feels like I am 6 again, with my crayons all over the place, doing random bullshit go till something sensible comes out.
Good luck finding what is wrong if a bug occurs, good luck if you will refactor it and think how can you replace it, how can you rewrite it without destroying the whole aesthetic of the code. just like my parents trying to figure out how will they renew the wall after I draw a huge chunk of random shit to the wall with my crayons.
If he’s using FastAPI he is essentially forced to use typing and is probably running a static type checker
Even, it's only enforced in routing functions.
Outside of it, like utility packages, MongoDB or such so, you are not enforced, go with whatever you want.
...guess what my coworkers prefer! urgh.
Outside of it, like utility packages, MongoDB or such so, you are not enforced, go with whatever you want.
...guess what my coworkers prefer! urgh.
True, absolutely, but if you add type hints before you refactor, it isn't too bad.
Not before the refactor. Type hints need to be there from beginning. I can't imagine anybody decides writing python without type hints in 2023.
Correct, but if they are there this isn't a problem, so if it's a problem I'm figuring they aren't there ...
I felt the opposite once I stopped writing backends in Python and moved to Scala, then Go.
The compiler is like an extra set of eyes attached to a brain that doesn't make mistakes. The type system in Scala especially freed up so much time and concentration allowing me to focus on implementing business logic at such a rapid pace. I couldn't go back to Python now for anything moderately complex.
The compiler is like an extra set of eyes attached to a brain that doesn't make mistakes. The type system in Scala especially freed up so much time and concentration allowing me to focus on implementing business logic at such a rapid pace. I couldn't go back to Python now for anything moderately complex.
No, I don't think so...
> Same in Flask and FastAPI. Development is so quick that I literally don't feel like coding.
Haha, isn't this good? I mean, it's not going to do hard stuff for you. It's good for the boring stuff to be fast, though?
> Same in Flask and FastAPI. Development is so quick that I literally don't feel like coding.
Haha, isn't this good? I mean, it's not going to do hard stuff for you. It's good for the boring stuff to be fast, though?
It sounds like you're just saying it's boring when an adequate library/framework is available. But I've never heard of such a library/framework that makes it THAT easy.
Either the software you're working on is simple or the projects are too small and not complex enough for you. Has nothing to do with Python.
Either the software you're working on is simple or the projects are too small and not complex enough for you. Has nothing to do with Python.
Lol this is quite funny.
Can elaborate on “yes you fucking can I don't even need to hear your question because a dude created a feature you wanted in Starlette”? Just for my amusement.
Also, if you haven’t yet tried Pydantic V2 you should give it a shot. It doesn’t work with FastAPI yet but I think your mind will be blown at how many absurdly complicated things “just work”.
Can elaborate on “yes you fucking can I don't even need to hear your question because a dude created a feature you wanted in Starlette”? Just for my amusement.
Also, if you haven’t yet tried Pydantic V2 you should give it a shot. It doesn’t work with FastAPI yet but I think your mind will be blown at how many absurdly complicated things “just work”.
Yeah I know, even smallest feature "json schema" made my jaw drop in Pydantic. Maybe we had it in V1 too, but it works so seamless now, especially too useful with MongoDB. As you said, there are so many absurdly things that I couldn't even dive in.
...I will tell my boss to use v2 on new project lol.
For the first part, dude my head is aching so hard that its at a point to kill me. I will comeback to you when I am somewhat clear-minded.
...I will tell my boss to use v2 on new project lol.
For the first part, dude my head is aching so hard that its at a point to kill me. I will comeback to you when I am somewhat clear-minded.
I tried Django, Flask, FastAPI till now, maybe there is other frameworks that is good enough, but I only had experience with "production-ready" frameworks.
And it feels... wrong? I don't know why, but it feels like something is wrong.
In Django, I barely ever feel like coding. It was just writing config files, like I didn't feel like I was coding.
Same in Flask and FastAPI. Development is so quick that I literally don't feel like coding. I mainly worked with GoLang till now, reinvented so many wheels, ventured into so many libraries, it felt "fuck yeah I am codin we are ballin".
Python seems... too easy? You barely ever reinvent wheels, you have something in your head? Some freak made it a feature of FastAPI. "hey caner, can we do th....", yes you fucking can I don't even need to hear your question because a dude created a feature you wanted in Starlette. It is madness.
Another example, you need to write lines of lines comments and markdown files for Swagger documentation in GoLang, FastAPI does that for you.
Validators? Pydantic holds your hand.
Yes, I am literally bickering about writing less code feels so wrong.
But am I the only one?
edit: I don't say fuck python and it's frameworks, I have tons of fun with it. and it pays the bills right now, so.... just a discuss and steam off post.