So, someone who doesn't understands his tools blames the tools for the fact that somehow they need to keep using a language they don't like (and don't understand either, it seems).
Nothing of what he complains about is Docker's fault or even Python the language's fault.
Funnily enough, I have spend the better part of Friday trying to wrap my head around Go modules and getting a project to a state that I could run any go command in. Have I blamed Go, the language? Nope. The tooling? A little bit but mostly my own ignorance of how it works.
It would do the author good to do some soul searching and perhaps understand that not all problems are nails, where the best tool to deal with is a hammer.
I think the average Python practitioner does not know how to reliably build a Python environment. Like most languages, Python has footguns. Packages installed in a user's home directory are often visible in virtualenv or conda environment and defeat isolation. If your charsets are configured wrong, a single print() statement will crash your Python if Unicode characters are in play.
Python is being fixed at its foundations and tools like poetry will approach parity with Maven.
Python tooling is in a very sorry state in general. The language has drawbacks. What I wrote was not meant in defense of Python at all, but rather a criticism of what the author said about Docker and the fact that he expects it to fix his Python (or Ruby or Perl) woes.
He goes on to suggest that somehow these languages put the programmer closer to the OS than C, which completely ludicrous since most reference implementations of them are written in C - making the language effectively one layer above it.
I get the argument about concurrency but that's pretty much the only thing he has to offer there. Everything else is just someone who doesn't understand the tools blaming the tools themselves and wishing he was using something else.
The fact that he thinks "Docker is supposed to protect us" from dependency management issues is ludicrous.
well, it’s a rant from a junior dev. he doesn’t know what he doesn’t know. in 3 years time he’ll look back at this and cringe.
EDIT: nope. author has 10 years of java. this is the worst kind of sr dev. they think their java expertise applies to some other ecosystem (python) because well it’s all computers amirite? that python has a dependency problem doesn’t mean docker is broken! he couldn’t diagnose a problem therefore the tooling is bad. get over yourself.
10 years isn't really all that much, is it? From my experience that's around how long it takes for developers to get a big head about how much they know, but 5 years less than what it takes to learn to respect how much they actually don't know about the different aspects of the field, and the real scale of challenges that have to be solved (both the technical, and the human).
Also, not all experience is equal. Someone that's spent 10 years working on 4 or 5 different systems in totally different problem domains, written in totally different languages, and operating in totally different ecosystems is going to have a very different view of development from someone that's spent 10 years doing essentially the same thing over and over again.
This guy seems to have a very focused view of the correct approach to problems. He's familiar with the tools that linux offers (which I agree are great), but he doesn't seem to respect the scale of specialization it takes to use and maintain those tools effectively on a large scale. Also, there is no mention of the cost to rebuild existing systems in terms of developer time, the mental cost to re-train all of the developers, as well as the time to migrate and train the users.
Ironically, I remember getting into debates like this back in the mid-2000s when I was first starting to think I had it all figured out. The points I made back then were more or less the same things I see now in the article above. It's quite nostalgic, though it definitely makes me feel older than I like.
Nothing of what he complains about is Docker's fault or even Python the language's fault.
Funnily enough, I have spend the better part of Friday trying to wrap my head around Go modules and getting a project to a state that I could run any go command in. Have I blamed Go, the language? Nope. The tooling? A little bit but mostly my own ignorance of how it works.
It would do the author good to do some soul searching and perhaps understand that not all problems are nails, where the best tool to deal with is a hammer.