3 ms·

As a primarily frontend engineer who has "spent plenty of time in the Python mines", I feel exactly the same way. Oh my god, Python is a horrific mishmash of de

by johnfn 2y ago

As a primarily frontend engineer who has "spent plenty of time in the Python mines", I feel exactly the same way. Oh my god, Python is a horrific mishmash of deprecated and impossible-to-upgrade libraries and dependencies. Honestly, I think it's significantly worse than the frontend - at least with the frontend, the scope of the damage is limited by TypeScript and the language limiting you to doing relatively sane things. In Python, you can do LITERALLY EVERYTHING, which leads to library authors doing LITERALLY EVERYTHING. Want to change how modules are imported? Go for it! Want to make a metaclass and break all assumptions about how a class operates? Have fun! Think your static typing will help you? Good luck - you can't even do trivial things like `Partial<T>` or statically assert that two objects have the same type. All this kvetching about libraries changing makes me laugh. The Python 2 -> 3 transition was so horrific that the last place that I worked at had a 100M Python monolith with no plans of EVER upgrading to 3. SqlAlchemy 1 -> 2 is an 8 step migration that requires a TOTAL rewrite, and if you break anything, YOUR SITE GOES DOWN. And then people complain because React optionally added hooks or something! The weird thing is that the internet is full of posts about "The Frontend Treadmill", but no one ever seems to gripe about the converse.

sethammons 2y ago
I am back at a python shop and (again) pushing, successfully, Go. Python is molasses for teams for all the reasons you state and more.
- wruza 2y ago
  What does “molasses” mean here? Search says it’s “slow”, but that makes little sense.
  - sethammons 2y ago
    that's exactly what I mean. At the three python shops I've been at, teams reach across boundaries and add abstractions. This gets something out fast at first, but as the organization grows, if you are not diligent, the code organically grows and the ability to ship new things becomes increasingly tied to how other things are implemented. What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about. A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not. Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.
sfn42 2y ago
Well I've never worked much with python aside from using it for some math and ML classes in uni, but it's always been pretty close to JS near the bottom of my mental system programming language tier list. If you want to throw together some quick thing or toy project or whatever sure, knock yourself out. But I'll honestly never respect people who write large "serious" applications using Python or JS for their backend. There are lots of great languages you can use for a backend. Java, C#, Go, lots of stuff. Js and python are the kind of languages you choose when you either don't know any other language or you don't know that they're ass. The only good excuse to use JS is that your code needs to run in a browser. The only good excuse to use python is that you're just making a tiny little toy thing. Or you're doing data science stuff/ML, in any case you're not creating a large complex application. And you certainly don't care much about performance. People invest so much time and money into creating more JS libraries and frameworks and stuff when what we should really be investing time and money into is creating an actually good language for the web. JS is the epitome of sunk cost fallacy. "But TS" no. TS is just JS with a bunch of overly complicated type bullshit you have to deal with. It is a better dev experience than JS so I do use it, but it's less a cure and more a band aid over the huge, gaping and pus-dripping wound that is JS.
- edwinjm 2y ago
  JavaScript is perfectly capable to run on the backend. Many people/companies do it with great satisfaction.
  - sfn42 2y ago
    Yeah I'm aware that it works. I'm just saying it's a bad choice. It's slower than most other languages, the language itself is just plain bad, the standard library is poor, npm isn't great, there's really just no good reason to use it other than "our devs don't know anything else".

by johnfn 2y ago

sethammons 2y ago

I am back at a python shop and (again) pushing, successfully, Go. Python is molasses for teams for all the reasons you state and more.

wruza 2y ago
What does “molasses” mean here? Search says it’s “slow”, but that makes little sense.
- sethammons 2y ago
  that's exactly what I mean. At the three python shops I've been at, teams reach across boundaries and add abstractions. This gets something out fast at first, but as the organization grows, if you are not diligent, the code organically grows and the ability to ship new things becomes increasingly tied to how other things are implemented. What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about. A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not. Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.

sfn42 2y ago

Well I've never worked much with python aside from using it for some math and ML classes in uni, but it's always been pretty close to JS near the bottom of my mental system programming language tier list. If you want to throw together some quick thing or toy project or whatever sure, knock yourself out. But I'll honestly never respect people who write large "serious" applications using Python or JS for their backend. There are lots of great languages you can use for a backend. Java, C#, Go, lots of stuff. Js and python are the kind of languages you choose when you either don't know any other language or you don't know that they're ass. The only good excuse to use JS is that your code needs to run in a browser. The only good excuse to use python is that you're just making a tiny little toy thing. Or you're doing data science stuff/ML, in any case you're not creating a large complex application. And you certainly don't care much about performance. People invest so much time and money into creating more JS libraries and frameworks and stuff when what we should really be investing time and money into is creating an actually good language for the web. JS is the epitome of sunk cost fallacy. "But TS" no. TS is just JS with a bunch of overly complicated type bullshit you have to deal with. It is a better dev experience than JS so I do use it, but it's less a cure and more a band aid over the huge, gaping and pus-dripping wound that is JS.

edwinjm 2y ago
JavaScript is perfectly capable to run on the backend. Many people/companies do it with great satisfaction.
- sfn42 2y ago
  Yeah I'm aware that it works. I'm just saying it's a bad choice. It's slower than most other languages, the language itself is just plain bad, the standard library is poor, npm isn't great, there's really just no good reason to use it other than "our devs don't know anything else".