I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point.
> Python’s package management sucks
Hmm, it has some weaknesses but I wouldn't really say it sucks. Going deeper ->
> Every project seems to use a different tool and it’s a massive headache. Off the top of my head there’s ...
Don't all of these use pip under the hood? I personally use the lower-level pip and virtualenv tools, but some others enjoy the convenience of poetry. That's a bit of personal preference. It's a bit more akin to an IDE choice than a feature of the language. None of conda, poetry, etc. are core Python features.
> Python’s standard library sucks
I have to disagree again, I think it is pretty well designed and minimal on purpose. The community additions of numpy, etc. are by design not part of the core language to reduce bloat.
> Python is slow
OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
> Python is huge, the python:3.9-slim Docker image is 118MB
Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.
> Python syntax sucks.
This one I can't even understand the reasoning for. The python syntax is what people love about it. I personally dislike the walrus operator, f-strings, and some of the other newer features (did they add the switch statement yet?) but those are my only gripes. And they are more pet-peeves / personal preferences than complaints.
I have to agree. I have a lot of gripes with Python, but the documentation and the standard library are generally great.
The author favors Javascript while deriding Python for its syntax, type-hints, and standard library, and favors Go while deriding a Python Docker image's size and documentation. I feel like the author must use Python in a very different way than I do for Javascript and Go to be the winners in these categories.
I do agree without reservation that package management and dependencies are horrible with Python.
I, a python dev with a decade of experience sometimes still need half a day to figure out some weird dependency venv import-path issue. This happens often.
It takes me half a day to figure out a reliable way to cross compile rust binaries for Raspberry Pis, withput ever having done this before.
There are a lot of good things about python but the dev environment sucks a lot and it is so engrained in the very substance of the language/tooling that I don't really see a path out of that other than going all Python 4.0 on it and repeating the python2/python3 schism all over again.
Python is still my goto language but it is my goto language despite the tooling, not because of it.
Python's documentation is good, but it's a departure from expectations if you're used to Javadoc-style documentation of APIs. You can get just that by providing good docstrings in your library's code or using documentation generators like Sphinx and whatnot.
Agree with the rest of your points, though, except not liking newer syntax. Newer syntax, in my experience, makes writing code less of a chore and mirrors the developer conveniences in other modern languages.
> OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
Does not being compiled really help with readability? How? After all, one can compile python to machine code, and there are C++ interpreters [1] (I have not heard any claims that using it makes C++ more readable). Then there are very readable/usable languages such as Haskell that come out of the box with both a compiler and interpreter.
To be more specific: which features does the absence of the possibility of compilation [2] enable?
> I have to disagree again, I think it is pretty well designed and minimal on purpose
Oh come on. That’s like saying “this buffet has no food selection but that’s good cause I’m on a diet”. Meaning that you like that it sucks (that’s fine).
Numpy is not the kind of thing you would include in the std lib anyway.
> OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
Fair, but I’ve spent enough time python environment/dependency hell that a lot of those gains (which are mostly cognitive) weren’t worth it for me.
The point is that every extra tool you need to work on a project is another thing you need to get installed and working. It's another thing that will rot over time. In 5 years it might be totally unusable and broken.
When I clone a project, I want to be productive with it as quickly as possible.
>> Python is huge, the python:3.9-slim Docker image is 118MB
> Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.
Caching aside, it seems that the Python slim image is built on Debian, which will usually have slightly bigger container sizes than something like Alpine, which is comparatively more lightweight/barebones:
> docker pull python:3.9-slim && docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
python 3.9-slim e2f464551004 8 days ago 125MB
> docker run --rm python:3.9-slim sh -c "cat /etc/*-release"
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
> docker pull python:3.9-alpine3.17 && docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
python 3.9-slim e2f464551004 8 days ago 125MB
python 3.9-alpine3.17 d6d1ed462b20 3 weeks ago 48.8MB
> docker run --rm python:3.9-alpine3.17 sh -c "cat /etc/*-release"
3.17.0
NAME="Alpine Linux"
Now, I'm not saying that Alpine is the perfect base distro for your container images, despite it generally being a reasonable pick (I've heard some stories about Python performance in particular, and sometimes there are package related oddities), but the distro that you choose will most definitely have an effect on what you'll ship.
Of course, caching and any additional tools that you may or may not want to include also plays a part. Personally, I just went for maximum predictability and usability, and now build most of my personal container images basing them on Ubuntu LTS, with some common CLI tools included for debugging: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo...
Just use whatever works for you, but rest assured that JDK and other stacks will typically also have some overhead to them. Python might not be the worst offender here. Something like Go with compiled binaries is still very nice, granted.
I have always had a very good experience with python documentation.
While I generally do like the python documentation, I often find that it likes to explain exactly how and why a library works in detail. This is great if you want to really learn the library and often I miss this level of detail in for example JavaScript, but if you just quickly want to find the most obvious way to do the most common thing, it can be quite annoying.
Python class syntax sucks. Other syntax is mostly nice. List comprehensions etc are great, I really wish I had those in c++. Plus, I wish I had a similarly useful standard library, repl, and package manager in c++.
The thing is, every language has serious issues, whether usability issues, documentation issues, performance issues, community issues, standard library issues, dependency issues, whatever. And for every issue, there are some people who just don't feel affected by it (or disagree that it is even an issue), and others who feel it deeply, to the point of outrage. So even if you ever get a consensus on what the issues are, there's even less of a consensus on how much they matter and what to do with them. Some people can live with certain problems and others are really distracted or bothered by them. It depends hugely on the context and environmental constraints too (can your org switch languages? when? on what terms? etc).
I think there's something deeply path dependent about how software people go through languages and fall in and out of love with them. Python was the first language I ever used professionally. It was amazing at the time compared to Java. But I haven't touched it in years now and don't especially want to. It's not that I "broke up" with it -- I just went elsewhere and it wasn't used there. You usually have to speak the local language wherever you go...
At a certain point, I think a lot of us give up on the idea of "loving" or "not loving" the language we use. They are all just tools. Some professional software people still have love affairs with their tools. That's cool I guess, but I have to say, I've written useful software in horrible languages (PHP) and I feel good about that too, and about not caring about the lovability factor (so to speak) of my professional toolkit.
I'm at a point where I think I would turn down any job offer that required me to do anything with python (even just the occasional change). I don't have the time or energy to fight with my tooling and environment that much
It's really a shame that data science, ML, and notebooks are so wrapped up in it. Otherwise we could jettison the whole thing into space
Same. I was at an AI startup that used python for everything and it was so bad. Even worse since it was AI engineers writing a lot of the main app code too.
> It's really a shame that data science, ML, and notebooks are so wrapped up in it. Otherwise we could jettison the whole thing into space
Although I personally feel Python has its place, I contribute to a project that hopes to diversify the ML/scientific computing space with a TypeScript tensor lib called Shumai: https://github.com/facebookresearch/shumai
It does, which surprised me when the author said they preferred JS over Python given the reasons they stated.
There are a lot of reasons to like or not like Python that will become evident after using it in a significant fashion. I was hoping for some of that insight, both to commiserate and celebrate the horrors and joys that I've experienced using the language and its ecosystem for some time. This article was not that.
People joke that Python programming is 'pip install solution', but it's honestly not too far from the truth. Until Go, Rust, or whatever fancy new language can match the wealth of well maintained libraries that Python has, I don't see it ever getting replaced for the quick scripting that the author talks about.
I agree, though, the urllib module that he links to it's not the best thing ever when it comes to Python, and I say that as a guy who has written Python code for a living for 17 years now. But other than that I find the standard library more than ok.
The only thing that I can agree on is the slowness, but even that is relative, as we're not all writing speed-critical code. The type annotations never took off because they were, and are, basically un-pythonic, trying to force types on Python's throat, so to speak, is definitely un-pythonic. Unfortunately the "types are a silver bullet"-hype is all too real, so there's also that.
He should have also learned to love dir()-ing stuff.
Was very surprised to see that in the article! My complaint is the Python std lib is bloated. If I could design a Python 4, it would be a subset of Python. Ie get rid of the various struct-like data structures (eg both types of named tuple) other than dataclass that have accumulated over time.
I don't fully agree with these arguments, but they all have some validity. I really felt his point on the documentation - it's great that it's reference-complete if that's what you're looking for, but it's maddening if you are coming to something to find out what it does.
I have gripes with some things in the current state of Python, package management particularly, but choosing JavaScript because Python's standard library is "barebones" doesn't really make any sense to me.
I've always found the Python standard library to have tons of useful stuff, and when I'm doing something in JS I often feel like I'm missing my toolbelt or something. Then I install a single npm package to do something simple and it winds up having 350 dependencies.
It made me wonder if I was hallucinating, so I went and checked... my `node` execurtable is 78MB. Thanks to its robust standard library, my node_modules folder is only 884 MB.
What is such low effort post doing here? I use Python way less than I used to, but this is just unfounded whining. And imagining js is better on those points... omfg.
I came here to say the same. The author clearly has only a very superficial knowledge of python (and a large distaste for it).
Throughout my studies and career I've written c, c++, java, javascript, perl, bash, python and a little bit of go.
Python for me is by far my favorite and most productive language. Expressive syntax, an unmatched wealth of useful libraries and most importantly: when I come back to code I wrote months ago I can easily read and understand it! Which can't be said of my old perl code.
I also love how python has been picking up steam lately, 3.6 - 3.11 have been splendid releases with plenty of goodies in each one.
Had to play with compiler flags to reduce trivy to a proper size (it was 300MB with default flags), and that was only the binary, without any containers.
And the dependency story is hardly any better than Python.
I'm all for people finding better programming languages and explaining why they're better for them… But without that context, without any context, this feels like they're scraping the barrel to make a point to somebody with no discernable reason why.
Python has plenty of issues, but it's still great for a huge pile of use-cases.
I've built a career on Python and Django. Even as my frontend work migrates into thick assemblies of javascript, I can't imagine using anything else for the backend for complex systems, but who knows what the next 20 years holds.
Sure. If you've done nothing significant with the language then a breakup is easy. Easy come, easy go.
If you've spent years, or even decades, building a portfolio with Python then the breakup is going to be much harder, just like in human relationships. Some things will make sense to leave in Python until end-of-life. Other things will be worthwhile to migrate to Go. Of course your new greenfield projects can start off using Go.
Just know this - you're going to go through this again in another 10-15 years, if not sooner. I've been writing software now for 40 years, that's just the way it goes.
And I'm not entirely sure it would be good idea for general purpose language. Knowing the history servers. Which likely will anyway have some critical design or security issue at one and probably many points in their life.
It's rich that the author unfavorably compares python's docs to go's. Go's documentation is barely more than API auto-doc level documentation: and many if not most of the open source projects using it have followed suit. It's some of the worst documentation out there, in my opinion.
I've been recommending Python to the occasional aspirational young programmer. Is it already passé? What would you recommend instead for a starter language? Looking for beginner-friendliness, widespread use, and longevity.
edit: to be clear, I hope this won't devolve into a language flamewar. I'm sincerely interested in other devs' opinions, and hoping that either Python is still a good recommendation (which seems to be the consensus so far) or that there's a better alternative.
No, it isn't passe, this developer just has some personal gripes with it that can range from understandable to "you'd complain if we did it any other way" with regard to their question about why type annotations were implemented the way they were.
I hate a lot of things about python because I've been using it for almost 20 years, and I know its innards, its history and its trajectory. I want to love Nim or Julia or Typescript, but they just aren't doing it for me. But you can't hate a language as deeply as I do without loving it as long as I have. I don't think this article, or my own opinions, are representative of the community.
I have, for the life of me, never understood the 'beginner friendly' argument for python.
Java, PHP or JavaScript for 'widespread use and longevity'. None of these are going anywhere, and I think you'd find more resources for beginners to advanced users for those 3. Yes, of course there's others - everyone has their faves. And Python will continue to kick around as well, but I've just never understood the 'beginner friendly' bit.
In my experience PowerShell fits well as a toe-dipping language.
It allows to solve the menial tasks someone with no programmng experience usually needs to solve, can interact with HTTP/REST-like APIs, sometimes has the modules for a popular solutions, is object oriented, lax on the indentation *smirk*.
Python is syntactically simple but that doesn't necessarily make it a good choice for beginners. I've seen students spend hours wrestling the interpreter over whitespace issues.
I agree with some of the sentiment here, but at the end of the day i’m not sure i’d be able to make a clean cut like OP suggests.
Python is used in so many places that’s it’s part of the lingua franca of programming. I’ve worked at multiple ruby shops over the last few years and pythons still been there in force for data applications.
I much prefer other languages (Ruby, Kotlin), but at the end of the day i need to be comfortable with the language that will be spoken for years to come.
I'm getting stuck into Go at the moment and thoroughly enjoying it, but can it really fill the same niche as Python as the article suggests? (Sincere question.) Doesn't the absence of an out-of-the-box REPL hinder quick scripting? As I say, I'm new to Go so would love to hear about people's experience using it in this context.
I use go and python pretty heavily, and I probably write twice the amount of functionality and three times the number of bugs in python in a day as go in a day. I take that to mean that they're good at different things, and therefore probably aren't quite as interchangable as the author makes them out to be.
I don't disagree with any of his points, actually, and agree with almost all of them. The standard library has some holes - though I think that's true everywhere. I don't know that eg Ruby or java don't have holes either.
I do think the packaging Story in python is nuts. Why does gem just work for Ruby but python's story is such a disaster? Though imo my modern advice is "just use poetry and ignore everything else".
Pythons main draw for me is some combination of:
Type hinting is good enough. It has a big escape hatch to be able to do C stuff if you need to. Numpy. The language is still straightforward enough that beginners can approach it and the experienced can wax reasonably eloquent with it. And it's pervasive.
So when I sit here and I'm like "ugh I need a thing to sit here and hit an api and dump it to a file every day in a cron job, and I don't want to spend a whole day writing this". I go for python. And while go and java and rust etc would be just fine, I still end up taking longer than I'd like.
Somehow python is just the shortest, sanest route to just getting a small to medium sized doodad out the door and running reliably in a small footprint of time without needing to remember boilerplate (java) or think way lower level than I'd like to (go/rust). Python just lets me do it with low cognitive overhead. Sometimes while I'm half-listening to a meeting I'm in!
Honestly my biggest gripe with python is it's really hard to tell early enough when your program is on a trajectory to be too big for python. And I don't mean from a perf perspective or anything, I just mean when it goes from being "easy python" to "oops it's spaghetti now." There's a tipping point and I think even seasoned people end up well past it by the time they pause and rub their eyes and think "ugh I wish this were in java."
> I do think the packaging Story in python is nuts.
That is one of my three big gripes with Python. The other two are the horrible way the 2 to 3 transition was managed and the GIL.
But none of those has driven me to switch to another language, nor do I expect it to. Go seems to be this author's alternative of choice; perhaps if my one goal in life was to write a production network backend without using any dependencies, I might agree, but it isn't, and having done some work with Go I find it gets in my way much more than Python does. I have the same problem with other languages.
For me the greatest pain point with Python is that you are never sure about what any line of code does, because basically everything can be redefined.
It might not be a big issue in a small script, but as soon as you get a biggish codebase, with mixins or magical utilities written a couple of years ago by a developer who in the meantime left, it takes hours just to track the control flow in the mess of patched methods, dunder stuff calling nested supers, etc.
To say nothing of big frameworks like DRF. There isn't even an agreed-on way to mark methods that are overridden from a base class.
Plus, simply changing the order of imports can violently change the semantics of the exact same code.
A fetish for hidden magic, state everywhere, and basically global coupling of code vastly override the supposedly simple syntax: it might be easy to read, but it is impossible to understand, locally.
I do not understand the incentive structure that would lead anyone to believe such a low effort blog post brings anything to anyone. The points raised are very standard, have reasons and counterpoints, and finally just invoking Go and JS without any details is so meh...
Don't forget how much of a pain packaging apps for end users is. There are helpful tools out there for it, but nothing that comes close to the ease of Go's default static builds that I have found.
> the ease of Go's default static builds that I have found
Seconded.
These are examples [1] of the scripts that I use on Linux, MacOS, and Windows for producing cross-platform builds. Run the one for the platform you're on, and it will produce stand-alone builds for all the targets (Linux, Windows, MacOS Intel, and MacOS ARM). And the builds are small enough that in many cases for simple tools I commit them straight into the repo for easier usage.
Python's lambda sums up everything that sucks in Python. It's a crippled, half-assed implementation of something which is considered a basic requirement for any programming language aiming for mainstream adoption. Even Java 8 did a better job after realising it wasn't too late in the day. Python's virtualenv requirement is also another admission of failure, IMHO.
I want to break up with Python, too. The one-size-fits-all philosophy that runs through the language from end to end leaves me feeling like I'm typing with three fingers. Sometimes its Right Way really is okay or even right, but sometimes I'd really, really, rather use something else. I worry about a generation of programmers for whom this is the first, main, and possibly only thing they've learned. I worry about them being brain damaged.
But where would I go? I clicked through hoping to find a good suggestion, and found none.
Python has become the lingua franca of programming, in many contexts, in many fields. You don't have a choice. You have to be able to read it, if you want to read what people are doing. You have to be able to write it, if you want people to read your stuff. It's where the libraries are. It's where stuff is happening. For better or for worse, Python won.
Even if I don't care about any of that, I really don't know where to go.
I really loved perl. I loved the powerful expression and conciseness. I miss it. But perl 5 is old, and it shows -- a lot of good ideas have come along in the last couple decades, and a lot of things that seemed like good ideas at the time really haven't worked out. A decade or so ago, I was excited about perl 6, but it doesn't seem to have worked out.
I don't like python. But I don't know what to replace it with. Javascript and Ruby seem like the serious options to me, and it's hard to take the one seriously, and the other is so niche that that itself feels like a serious drawback. I want a general purpose scripting language that can do small scripts well (Messes allowed! Shortcuts encouraged! Power in a small space!) and grow to large projects well (Thoughtful object system! Good package management! Good support for alternative paradigms!)
That question can't be answered without knowing what kind of programs you're writing. You got a lot of options if you're thinking about websites/apis, almost none if it's machine learning and basically everything is better if you're thinking about GUI applications.
If you try to please everyone you end up without personality. Python has plenty of flaws but it feels also as a very distinct way of solving a vast range of problems. But its longevity will depend on how well its community can address legitimate complaints (which do not require it become all things to all people)
If you chose JavaScript over Python for backend scripting, sounds like you want to hurt yourself.
If JavaScript is your goto language, then ok. But, otherwise, Python is the most used language for writing backend scripts, so it's pretty good at this, but also there's a lot of material online.
I have just started getting into python as I'm experimenting with pytorch and after a lot of googling I'm still trying to figure out how to use conda properly. Could anyone point me to the best way to manage python environments and packages?
I don't think there is a "best" way, in my biased opinion package management for Python is terrible. It works for trivial cases but if you do anything serious it will get unmanageable fast.
Everyone will tell you of the "best" (i.e. their favorite) way to handle packages and dependencies. Usually mixed with some sandbox framework. Everything will be broken in some way: nonstandard, convoluted, too slow, cannot handle corner cases, or just way too difficult to understand. Even those labeled "for humans". Everyone will agree the situation is a mess "except for this one way that works": never trust that way, it doesn't really work past trivial cases.
Of course this is just my experience. But I feel after years of battling with Python and trying different things, I've earned the right to say this.
It encourages to set up project specific definitions which are saved in the local pyproject.toml file. Keeping everything local and project specific, including the env definition, turns out to be a fantastic boon to reproducibility and sanity of mind.
Use mamba instead of conda to install your packages, and always use the conda-forge channel. mamba is essentially a drop-in replacement. I have always found conda to be horribly slow for installing packages. For environments:
- `conda env create|list|remove` commands to manage them
- `conda activate <env name>` to enter your environment
- `conda deactivate` to return to your base environment
If you want to use a conda environment in jupyter, you must install ipykernel and create a kernel definition for your environment:
(Lots of the other advice here—mamba excepted, and that might be a good choice—is good for python in general but potentially will cause problems if you are otherwise using anaconda.)
Pyenv for Python versions and/or environments, Poetry for package management and/or environments, and pip if you end up needing it for package management.
The article mentions using JavaScript in place of Python. I use JavaScript a lot for browser stuff but can JavaScript be used for the random command-line scripts that I implement in Python? (Genuine question, not rhetorical.)
Node is an interpreter just like Python, gives access to OS features like sockets, file systems and processes, so yes, you can.
However I’d rather not if you value your sanity and want to use typescript, because then you introduce packages and compilers and the whole npm ecosystem which makes building C++ look easy and sane.
I use Node.js/TypeScript for all my scripting needs. Together with pm2 which can auto-generate a systemd service if it needs to run as a service on boot. Coming back to a strongly typed project / script is actually really beneficial to refactor or extend.
Last time I argued, like the TFA does, that Python's typing system is both too complex for casual users and useless for power users ("it doesn't do anything" is about right), and that this makes it hard to evangelize its use to other devs who aren't sold on type systems ("but this doesn't do anything!"), I got into a 30-level nesting flame war with some HN regular who just wouldn't let go.
So that's still my line of thought, but I'm already regretting typing this on HN.
Yeah, I think I agree with you. I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library. I guess typing is more of an afterthought than a priority for most dynamic language developers so it doesn't get much love.
Personally, I’ve been pretty happy with python, I think it works wonderfully as a glue language (like bash); I.E: you shouldn’t write a lot of it, you should use it for plumbing. Its fantastic for that.
> my friend made a write up before about the inadequecies of python
To be honest, this seems like even less of a balanced criticism than the article this overall discussion is based on. A more balanced summary of the valid points might be: "Python has issues that you will probably trip over in certain kinds of applications". Which is true of every language.
> I think it works wonderfully as a glue language
It also works very well as an application language, just not for all types of applications. Which, again, is true of every language.
Every language that's been around long enough has issues. Python has its own of course, and the ones the OP listed are real. But none of them are show-stoppers or as big a deal as to stop coding in Python.
Here is my take on what the OP is actually trying to say: "I don't want to code in Python any more (because there are newer cooler languages like Go?) and here is my list of reasons for rationalizing my rather irrational decision"
Agree with syntax and slow, the others not so much.
But my bigger reason for avoiding Python when I can is I just think the days of dynamic languages are behind us. Which is to say, we are past the tipping point where the ergonomics of adding typing are less costly than the benefits, and that applies even for short scripting use cases (in part because so many short scripts grow their way into real production code that needs to be maintained).
I went down the rabbit hole of adding type hints but at the end of the rabbit hole it was a lot of work and the value realised was still only 50% of that from having a real type system. Vast numbers of type errors still not getting caught in my editor, autocompletion stymied at shallow points where the type system gets lost, and as the weight of the project grows the tools like MyPy getting slower and slower as they have to process massive amounts of the dependency tree just to infer the type of the single line you are typing.
These days even for short scripts I am preferring to write them in languages like Groovy which get me all the benefits of Python from the dynamic language point of view but built on a foundation of a real type system which means I have a pathway to grow the code into full static typing using any of the JVM languages if I want / need to. And it also largely solves the problem with performance.
This was awfully generic. Not necessarily wrong, but certainly not a meaningful blow against python that's going to show anyone the light and give them tangible thoughts about using another tool. (Especially given the breath of what python is used for. Does it suck at everything?) What are we supposed to get out of this?
I'm not sure go should be compared to python as they are designed for very different things. Go is more fairly compared against modern c++ or rust in my mind. Python is not designed to be lightweight or fast (although it has been consistently improving with each release) but favors expressability and run time flexibility instead.
This is garbage. It typifies a kind a drive-by rant disguised as a rational opinion that is basically insulting to the intelligence of everyone, regardless of language preference. The level of narcissism and pettiness is high, and the level of rational discourse is low. Entitled spewing of garbage.
> Python’s documentation sucks
Dead giveaway. Well, it doesn't suck. It's pretty great, pretty comprehensive. OH... Wait, ot isn't formatted with a index pane. that's why it sucks. The author probably has problems with the font-kerning too.
> Every project seems to use a different tool and it’s a massive headache
Um, no. Everything really uses pip. I don't even really like pip, but everyone uses it so I use it. You know why? Because it's never, ever a pain in anything at all. It just works.
> Python’s standard library sucks
What? is this satire?
> Python is huge
This has got to be satire. Author prefers "go". Nothing wrong with go, but nothing wrong with Python either.
> Python syntax sucks.
Nuts! this guys is legit insane. The only really controversial thing is the whitespace-indent vs. delimited thing. Guess what? I really dislike the indentation scheme. You could have a reasonable debate over that relatively unique syntax scheme. But the entire syntax as a whole is cleverly regular, predictable and tidy.
> Python is slow
Well, as the author said, "Python has been my go-to language for a quick bit of scripting". Slow is a perfectly acceptable trade-off there. And you could certainly come up with a different set of trades that also make sense. To say "SUCKS" implies it's just stupid and sub-optimal everywhere; a lose-lose-lose-lose. Which it isn't.
> It’s like everything under the kitchen sink has been jammed in.
I though you said that the standard library "sucked"; is there too much sink or too little? "let that sink in"
The author seems to be infatuated with javascript and go (at the moment), but neither is really in the same niche as python. That doesn't make any of those other choices "suck".
Larry Ellison and his company and products suck. Software patent trolls suck. Python does not "suck" because you like other things at the moment.
There is no reason to start a new project in python IMO. Existing ones should be deprecated.
the packaging ecosystem alone is enough to make anyone mad. I maintained a production system in python for a few years a while back and code refactoring was extremely painful.
Oh yeah, "every language has issues", or "if you just invest a little effort you'll get it", sure. But those languages that I use don't prevent me from installing a CLI tool and have me fighting with its half-witted package manager to do so. And they don't (or they very rarely do) mandate me to learn idiosyncrasies so I can do basic activities.
The only thing that keeps Python alive and well is the fact that many people don't know anything else -- and never will know anything else -- and that's one of the reasons it's widely taught in universities. The AI/ML stuff can be replaced with its underlying C/C++/Rust libraries in a week so that's not an argument in Python's favor at all.
I wish people stopped pretending Python is OK. It very much is not. It's a collective delusion kept alive by network effects.
agolio|3 years ago
I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point.
> Python’s package management sucks
Hmm, it has some weaknesses but I wouldn't really say it sucks. Going deeper ->
> Every project seems to use a different tool and it’s a massive headache. Off the top of my head there’s ...
Don't all of these use pip under the hood? I personally use the lower-level pip and virtualenv tools, but some others enjoy the convenience of poetry. That's a bit of personal preference. It's a bit more akin to an IDE choice than a feature of the language. None of conda, poetry, etc. are core Python features.
> Python’s standard library sucks
I have to disagree again, I think it is pretty well designed and minimal on purpose. The community additions of numpy, etc. are by design not part of the core language to reduce bloat.
> Python is slow
OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
> Python is huge, the python:3.9-slim Docker image is 118MB
Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.
> Python syntax sucks.
This one I can't even understand the reasoning for. The python syntax is what people love about it. I personally dislike the walrus operator, f-strings, and some of the other newer features (did they add the switch statement yet?) but those are my only gripes. And they are more pet-peeves / personal preferences than complaints.
lynndotpy|3 years ago
The author favors Javascript while deriding Python for its syntax, type-hints, and standard library, and favors Go while deriding a Python Docker image's size and documentation. I feel like the author must use Python in a very different way than I do for Javascript and Go to be the winners in these categories.
I do agree without reservation that package management and dependencies are horrible with Python.
atoav|3 years ago
It takes me half a day to figure out a reliable way to cross compile rust binaries for Raspberry Pis, withput ever having done this before.
There are a lot of good things about python but the dev environment sucks a lot and it is so engrained in the very substance of the language/tooling that I don't really see a path out of that other than going all Python 4.0 on it and repeating the python2/python3 schism all over again.
Python is still my goto language but it is my goto language despite the tooling, not because of it.
heavyset_go|3 years ago
Agree with the rest of your points, though, except not liking newer syntax. Newer syntax, in my experience, makes writing code less of a chore and mirrors the developer conveniences in other modern languages.
nhchris|3 years ago
Does not being compiled really help with readability? How? After all, one can compile python to machine code, and there are C++ interpreters [1] (I have not heard any claims that using it makes C++ more readable). Then there are very readable/usable languages such as Haskell that come out of the box with both a compiler and interpreter.
To be more specific: which features does the absence of the possibility of compilation [2] enable?
[1] https://root.cern/cling/
[2] Since interpretation and compilation are not mutually-exclusive for a language.
devmunchies|3 years ago
> I have to disagree again, I think it is pretty well designed and minimal on purpose
Oh come on. That’s like saying “this buffet has no food selection but that’s good cause I’m on a diet”. Meaning that you like that it sucks (that’s fine).
Numpy is not the kind of thing you would include in the std lib anyway.
> OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
Fair, but I’ve spent enough time python environment/dependency hell that a lot of those gains (which are mostly cognitive) weren’t worth it for me.
c7DJTLrn|3 years ago
The point is that every extra tool you need to work on a project is another thing you need to get installed and working. It's another thing that will rot over time. In 5 years it might be totally unusable and broken.
When I clone a project, I want to be productive with it as quickly as possible.
KronisLV|3 years ago
> Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.
Caching aside, it seems that the Python slim image is built on Debian, which will usually have slightly bigger container sizes than something like Alpine, which is comparatively more lightweight/barebones:
Now, I'm not saying that Alpine is the perfect base distro for your container images, despite it generally being a reasonable pick (I've heard some stories about Python performance in particular, and sometimes there are package related oddities), but the distro that you choose will most definitely have an effect on what you'll ship.Of course, caching and any additional tools that you may or may not want to include also plays a part. Personally, I just went for maximum predictability and usability, and now build most of my personal container images basing them on Ubuntu LTS, with some common CLI tools included for debugging: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo...
Just use whatever works for you, but rest assured that JDK and other stacks will typically also have some overhead to them. Python might not be the worst offender here. Something like Go with compiled binaries is still very nice, granted.
dagw|3 years ago
While I generally do like the python documentation, I often find that it likes to explain exactly how and why a library works in detail. This is great if you want to really learn the library and often I miss this level of detail in for example JavaScript, but if you just quickly want to find the most obvious way to do the most common thing, it can be quite annoying.
unknown|3 years ago
[deleted]
ant6n|3 years ago
decasia|3 years ago
I think there's something deeply path dependent about how software people go through languages and fall in and out of love with them. Python was the first language I ever used professionally. It was amazing at the time compared to Java. But I haven't touched it in years now and don't especially want to. It's not that I "broke up" with it -- I just went elsewhere and it wasn't used there. You usually have to speak the local language wherever you go...
At a certain point, I think a lot of us give up on the idea of "loving" or "not loving" the language we use. They are all just tools. Some professional software people still have love affairs with their tools. That's cool I guess, but I have to say, I've written useful software in horrible languages (PHP) and I feel good about that too, and about not caring about the lovability factor (so to speak) of my professional toolkit.
brundolf|3 years ago
It's really a shame that data science, ML, and notebooks are so wrapped up in it. Otherwise we could jettison the whole thing into space
devmunchies|3 years ago
brrrrrm|3 years ago
Although I personally feel Python has its place, I contribute to a project that hopes to diversify the ML/scientific computing space with a TypeScript tensor lib called Shumai: https://github.com/facebookresearch/shumai
joromero|3 years ago
> Documentation
JavaScript wins here thanks to MDN, but it's not the official documentation.
> Package Management
I agree that Python's package management has its issues, but JS is insane in this regard
> Standard Library
JavaScript's standard library is definitely smaller than Python's
> Slow
This is clearly a win for JS
> Size
When comparing the slim official Python docker image with the equivalent NodeJS image, Python wins in size
> Syntax
This is the most subjective point. I prefer Python's syntax because it's less noisy, but JavaScript's syntax is more consistent.
Regarding type annotations they don't do anything at runtime, but they are extremely useful for IDEs.
heavyset_go|3 years ago
There are a lot of reasons to like or not like Python that will become evident after using it in a significant fashion. I was hoping for some of that insight, both to commiserate and celebrate the horrors and joys that I've experienced using the language and its ecosystem for some time. This article was not that.
zeroCalories|3 years ago
c7DJTLrn|3 years ago
maxerickson|3 years ago
paganel|3 years ago
I agree, though, the urllib module that he links to it's not the best thing ever when it comes to Python, and I say that as a guy who has written Python code for a living for 17 years now. But other than that I find the standard library more than ok.
The only thing that I can agree on is the slowness, but even that is relative, as we're not all writing speed-critical code. The type annotations never took off because they were, and are, basically un-pythonic, trying to force types on Python's throat, so to speak, is definitely un-pythonic. Unfortunately the "types are a silver bullet"-hype is all too real, so there's also that.
He should have also learned to love dir()-ing stuff.
the__alchemist|3 years ago
anigbrowl|3 years ago
63|3 years ago
samuell|3 years ago
macNchz|3 years ago
I've always found the Python standard library to have tons of useful stuff, and when I'm doing something in JS I often feel like I'm missing my toolbelt or something. Then I install a single npm package to do something simple and it winds up having 350 dependencies.
cldellow|3 years ago
- Python is too big
- Python's standard library is too small
- therefore, you should use JavaScript
It made me wonder if I was hallucinating, so I went and checked... my `node` execurtable is 78MB. Thanks to its robust standard library, my node_modules folder is only 884 MB.
iainctduncan|3 years ago
jgb1984|3 years ago
Throughout my studies and career I've written c, c++, java, javascript, perl, bash, python and a little bit of go. Python for me is by far my favorite and most productive language. Expressive syntax, an unmatched wealth of useful libraries and most importantly: when I come back to code I wrote months ago I can easily read and understand it! Which can't be said of my old perl code.
I also love how python has been picking up steam lately, 3.6 - 3.11 have been splendid releases with plenty of goodies in each one.
cedws|3 years ago
pjmlp|3 years ago
Still smaller than most Go binaries.
Had to play with compiler flags to reduce trivy to a proper size (it was 300MB with default flags), and that was only the binary, without any containers.
And the dependency story is hardly any better than Python.
oliwarner|3 years ago
Python has plenty of issues, but it's still great for a huge pile of use-cases.
I've built a career on Python and Django. Even as my frontend work migrates into thick assemblies of javascript, I can't imagine using anything else for the backend for complex systems, but who knows what the next 20 years holds.
taylodl|3 years ago
If you've spent years, or even decades, building a portfolio with Python then the breakup is going to be much harder, just like in human relationships. Some things will make sense to leave in Python until end-of-life. Other things will be worthwhile to migrate to Go. Of course your new greenfield projects can start off using Go.
Just know this - you're going to go through this again in another 10-15 years, if not sooner. I've been writing software now for 40 years, that's just the way it goes.
onatrain|3 years ago
> my go-to language for a quick bit of scripting where another language might feel too heavy duty
So this article is not from someone who has used Python full time professionally...
iamjk|3 years ago
Maybe for production ready microservices, but I've always thought Python's std lib was pretty expansive.
Ekaros|3 years ago
sidlls|3 years ago
Ekaros|3 years ago
thaumaturgy|3 years ago
edit: to be clear, I hope this won't devolve into a language flamewar. I'm sincerely interested in other devs' opinions, and hoping that either Python is still a good recommendation (which seems to be the consensus so far) or that there's a better alternative.
heavyset_go|3 years ago
simonw|3 years ago
klyrs|3 years ago
323|3 years ago
mgkimsal|3 years ago
Java, PHP or JavaScript for 'widespread use and longevity'. None of these are going anywhere, and I think you'd find more resources for beginners to advanced users for those 3. Yes, of course there's others - everyone has their faves. And Python will continue to kick around as well, but I've just never understood the 'beginner friendly' bit.
justsomehnguy|3 years ago
It allows to solve the menial tasks someone with no programmng experience usually needs to solve, can interact with HTTP/REST-like APIs, sometimes has the modules for a popular solutions, is object oriented, lax on the indentation *smirk*.
c7DJTLrn|3 years ago
pjmlp|3 years ago
Ekaros|3 years ago
And after they learn those and have few fights. They might be ready to research what to choose for next project.
wpnx|3 years ago
Python is used in so many places that’s it’s part of the lingua franca of programming. I’ve worked at multiple ruby shops over the last few years and pythons still been there in force for data applications.
I much prefer other languages (Ruby, Kotlin), but at the end of the day i need to be comfortable with the language that will be spoken for years to come.
Lyngbakr|3 years ago
debatem1|3 years ago
c7DJTLrn|3 years ago
atomicnumber3|3 years ago
I do think the packaging Story in python is nuts. Why does gem just work for Ruby but python's story is such a disaster? Though imo my modern advice is "just use poetry and ignore everything else".
Pythons main draw for me is some combination of:
Type hinting is good enough. It has a big escape hatch to be able to do C stuff if you need to. Numpy. The language is still straightforward enough that beginners can approach it and the experienced can wax reasonably eloquent with it. And it's pervasive.
So when I sit here and I'm like "ugh I need a thing to sit here and hit an api and dump it to a file every day in a cron job, and I don't want to spend a whole day writing this". I go for python. And while go and java and rust etc would be just fine, I still end up taking longer than I'd like.
Somehow python is just the shortest, sanest route to just getting a small to medium sized doodad out the door and running reliably in a small footprint of time without needing to remember boilerplate (java) or think way lower level than I'd like to (go/rust). Python just lets me do it with low cognitive overhead. Sometimes while I'm half-listening to a meeting I'm in!
Honestly my biggest gripe with python is it's really hard to tell early enough when your program is on a trajectory to be too big for python. And I don't mean from a perf perspective or anything, I just mean when it goes from being "easy python" to "oops it's spaghetti now." There's a tipping point and I think even seasoned people end up well past it by the time they pause and rub their eyes and think "ugh I wish this were in java."
dragonwriter|3 years ago
Ruby has been actively stripping the stdlib, moving libraries to default and bundled gems.
pdonis|3 years ago
That is one of my three big gripes with Python. The other two are the horrible way the 2 to 3 transition was managed and the GIL.
But none of those has driven me to switch to another language, nor do I expect it to. Go seems to be this author's alternative of choice; perhaps if my one goal in life was to write a production network backend without using any dependencies, I might agree, but it isn't, and having done some work with Go I find it gets in my way much more than Python does. I have the same problem with other languages.
haaryball|3 years ago
It might not be a big issue in a small script, but as soon as you get a biggish codebase, with mixins or magical utilities written a couple of years ago by a developer who in the meantime left, it takes hours just to track the control flow in the mess of patched methods, dunder stuff calling nested supers, etc.
To say nothing of big frameworks like DRF. There isn't even an agreed-on way to mark methods that are overridden from a base class.
Plus, simply changing the order of imports can violently change the semantics of the exact same code.
A fetish for hidden magic, state everywhere, and basically global coupling of code vastly override the supposedly simple syntax: it might be easy to read, but it is impossible to understand, locally.
pjmlp|3 years ago
But only those without any means of indirect calls via function pointers or reflection.
polotics|3 years ago
beardog|3 years ago
kcartlidge|3 years ago
Seconded.
These are examples [1] of the scripts that I use on Linux, MacOS, and Windows for producing cross-platform builds. Run the one for the platform you're on, and it will produce stand-alone builds for all the targets (Linux, Windows, MacOS Intel, and MacOS ARM). And the builds are small enough that in many cases for simple tools I commit them straight into the repo for easier usage.
[1] https://github.com/kcartlidge/ng/tree/main/src/scripts
cutler|3 years ago
Dove|3 years ago
But where would I go? I clicked through hoping to find a good suggestion, and found none.
Python has become the lingua franca of programming, in many contexts, in many fields. You don't have a choice. You have to be able to read it, if you want to read what people are doing. You have to be able to write it, if you want people to read your stuff. It's where the libraries are. It's where stuff is happening. For better or for worse, Python won.
Even if I don't care about any of that, I really don't know where to go.
I really loved perl. I loved the powerful expression and conciseness. I miss it. But perl 5 is old, and it shows -- a lot of good ideas have come along in the last couple decades, and a lot of things that seemed like good ideas at the time really haven't worked out. A decade or so ago, I was excited about perl 6, but it doesn't seem to have worked out.
I don't like python. But I don't know what to replace it with. Javascript and Ruby seem like the serious options to me, and it's hard to take the one seriously, and the other is so niche that that itself feels like a serious drawback. I want a general purpose scripting language that can do small scripts well (Messes allowed! Shortcuts encouraged! Power in a small space!) and grow to large projects well (Thoughtful object system! Good package management! Good support for alternative paradigms!)
I just can't figure out what that would be.
411111111111111|3 years ago
college_physics|3 years ago
kissgyorgy|3 years ago
samuell|3 years ago
https://devdocs.io
It does excellent fuzzy search-as-you-type, and is typically a pinned tab in my browser most of the time.
BenGosub|3 years ago
If JavaScript is your goto language, then ok. But, otherwise, Python is the most used language for writing backend scripts, so it's pretty good at this, but also there's a lot of material online.
rihegher|3 years ago
the_af|3 years ago
Everyone will tell you of the "best" (i.e. their favorite) way to handle packages and dependencies. Usually mixed with some sandbox framework. Everything will be broken in some way: nonstandard, convoluted, too slow, cannot handle corner cases, or just way too difficult to understand. Even those labeled "for humans". Everyone will agree the situation is a mess "except for this one way that works": never trust that way, it doesn't really work past trivial cases.
Of course this is just my experience. But I feel after years of battling with Python and trying different things, I've earned the right to say this.
samuell|3 years ago
https://python-poetry.org/
It encourages to set up project specific definitions which are saved in the local pyproject.toml file. Keeping everything local and project specific, including the env definition, turns out to be a fantastic boon to reproducibility and sanity of mind.
blindstitch|3 years ago
- `conda env create|list|remove` commands to manage them
- `conda activate <env name>` to enter your environment
- `conda deactivate` to return to your base environment
If you want to use a conda environment in jupyter, you must install ipykernel and create a kernel definition for your environment:
In practice I have found anacondas environment management and usage to be pretty seamless.Frotag|3 years ago
---
1. Create a virtual environment named venv
2. Activate it. (In vscode, Ctrl+P > Select: Python Interpreter)3. Define and install dependencies
(or just "pip install ___")shadycuz|3 years ago
dragonwriter|3 years ago
https://docs.conda.io/projects/conda/en/latest/user-guide/ta...
(Lots of the other advice here—mamba excepted, and that might be a good choice—is good for python in general but potentially will cause problems if you are otherwise using anaconda.)
emptysongglass|3 years ago
[1] https://pdm.fming.dev/latest/usage/pep582/
heavyset_go|3 years ago
brrrrrm|3 years ago
- reference counted objects with predictable scoped destruction. this keeps the maintenance of huge resources quite simple and memory usage steady
- operator overloading (infix, like +/*-)
I really wish other languages (like JS/Go) had this stuff.
kens|3 years ago
baq|3 years ago
However I’d rather not if you value your sanity and want to use typescript, because then you introduce packages and compilers and the whole npm ecosystem which makes building C++ look easy and sane.
brnewd|3 years ago
Atlas22|3 years ago
unknown|3 years ago
[deleted]
fndex|3 years ago
the_af|3 years ago
So that's still my line of thought, but I'm already regretting typing this on HN.
Atlas22|3 years ago
ianandrich|3 years ago
molly0|3 years ago
dijit|3 years ago
Personally, I’ve been pretty happy with python, I think it works wonderfully as a glue language (like bash); I.E: you shouldn’t write a lot of it, you should use it for plumbing. Its fantastic for that.
pdonis|3 years ago
To be honest, this seems like even less of a balanced criticism than the article this overall discussion is based on. A more balanced summary of the valid points might be: "Python has issues that you will probably trip over in certain kinds of applications". Which is true of every language.
> I think it works wonderfully as a glue language
It also works very well as an application language, just not for all types of applications. Which, again, is true of every language.
emrah|3 years ago
Here is my take on what the OP is actually trying to say: "I don't want to code in Python any more (because there are newer cooler languages like Go?) and here is my list of reasons for rationalizing my rather irrational decision"
th3o6a1d|3 years ago
Atlas22|3 years ago
zmmmmm|3 years ago
But my bigger reason for avoiding Python when I can is I just think the days of dynamic languages are behind us. Which is to say, we are past the tipping point where the ergonomics of adding typing are less costly than the benefits, and that applies even for short scripting use cases (in part because so many short scripts grow their way into real production code that needs to be maintained).
I went down the rabbit hole of adding type hints but at the end of the rabbit hole it was a lot of work and the value realised was still only 50% of that from having a real type system. Vast numbers of type errors still not getting caught in my editor, autocompletion stymied at shallow points where the type system gets lost, and as the weight of the project grows the tools like MyPy getting slower and slower as they have to process massive amounts of the dependency tree just to infer the type of the single line you are typing.
These days even for short scripts I am preferring to write them in languages like Groovy which get me all the benefits of Python from the dynamic language point of view but built on a foundation of a real type system which means I have a pathway to grow the code into full static typing using any of the JVM languages if I want / need to. And it also largely solves the problem with performance.
version_five|3 years ago
igtztorrero|3 years ago
Go is the way to better backend, CPU and memory optimized.
I read an article that Dropbox save thousands just by change from Python to Go.
It's difficult, especially handling shared variables in go routines, but it's worth it.
Atlas22|3 years ago
theLiminator|3 years ago
Everyone loves to hate it, but you gotta use it.
I disagree about the documentation/syntax/std lib gripes, but everything else is a pretty reasonable issue.
323|3 years ago
> ...
> Python sucks. I mean the syntax itself.
So author notices that syntax sucks afters years of usage?
smitty1e|3 years ago
It would be swell if rationalizing the packaging story were a priority for 3.12.
Euphorbium|3 years ago
zhenyakovalyov|3 years ago
fargle|3 years ago
> Python’s documentation sucks
Dead giveaway. Well, it doesn't suck. It's pretty great, pretty comprehensive. OH... Wait, ot isn't formatted with a index pane. that's why it sucks. The author probably has problems with the font-kerning too.
> Every project seems to use a different tool and it’s a massive headache
Um, no. Everything really uses pip. I don't even really like pip, but everyone uses it so I use it. You know why? Because it's never, ever a pain in anything at all. It just works.
> Python’s standard library sucks
What? is this satire?
> Python is huge
This has got to be satire. Author prefers "go". Nothing wrong with go, but nothing wrong with Python either.
> Python syntax sucks.
Nuts! this guys is legit insane. The only really controversial thing is the whitespace-indent vs. delimited thing. Guess what? I really dislike the indentation scheme. You could have a reasonable debate over that relatively unique syntax scheme. But the entire syntax as a whole is cleverly regular, predictable and tidy.
> Python is slow
Well, as the author said, "Python has been my go-to language for a quick bit of scripting". Slow is a perfectly acceptable trade-off there. And you could certainly come up with a different set of trades that also make sense. To say "SUCKS" implies it's just stupid and sub-optimal everywhere; a lose-lose-lose-lose. Which it isn't.
> It’s like everything under the kitchen sink has been jammed in.
I though you said that the standard library "sucked"; is there too much sink or too little? "let that sink in"
The author seems to be infatuated with javascript and go (at the moment), but neither is really in the same niche as python. That doesn't make any of those other choices "suck".
Larry Ellison and his company and products suck. Software patent trolls suck. Python does not "suck" because you like other things at the moment.
sigmonsays|3 years ago
the packaging ecosystem alone is enough to make anyone mad. I maintained a production system in python for a few years a while back and code refactoring was extremely painful.
I hope I'll never touch python again.
Atlas22|3 years ago
northisup|3 years ago
mgaunard|3 years ago
Python remains the most popular programming language worldwide.
isitmadeofglass|3 years ago
[deleted]
primeblue|3 years ago
[deleted]
pdimitar|3 years ago
The only thing that keeps Python alive and well is the fact that many people don't know anything else -- and never will know anything else -- and that's one of the reasons it's widely taught in universities. The AI/ML stuff can be replaced with its underlying C/C++/Rust libraries in a week so that's not an argument in Python's favor at all.
I wish people stopped pretending Python is OK. It very much is not. It's a collective delusion kept alive by network effects.
baq|3 years ago