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.
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.
It depends what you're comparing them against. Python's style of documentation - for the language itself and for many of the popular libraries that follow the same style - is mostly reference material and often incomplete. It's very lacking in examples of usage. It almost completely ignores types. It often doesn't appear in search engine results for relevant keywords leading to spending several minutes brute force searching the official docs site to find something that should have been a 10 second search. Perhaps the most obvious comparison is with the JavaScript/TypeScript world, which has embraced both types and different kinds of documentation and as a result gives a much better developer experience in those areas today.
The standard library in Python is strange because it has a lot of content but much of that content just isn't very good. Entire packages in the standard library are largely ignored in favour of some de facto standard package from PyPI that does the same job much better. Some of the packages for working with different protocols and file formats are useful in the right circumstances but they're so slow that they're not suitable for many applications and again you end up pulling in a better alternative. Meanwhile common data structures and algorithms that you might look for in any modern language's toolbox are scarce to non-existent and the ones that do exist don't always compose easily.
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.
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.
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?
[2] Since interpretation and compilation are not mutually-exclusive for a language.
There is also tools such as Cython and numba (JIT) which use various techniques to compile Python code btw. But I am generally in favour of switching to a high performance language or writing in C++ and then importing in Python at that point, personal preference again...
Interesting to read about cling, will have to play around with that.
> 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.
If I could add one thing to the python standard library it would be unify the python std lib array and the numpy array and make many of the most common and useful numpy array methods available in the std lib.
I ported a golang (non concurrent) program that was 3 files and lots of intermediate procedures over custom types (synchronized maps)
it thing fit beautifully in a one page python script, very readable. bonus: concurrency (threadpool over queues). the only libs were click and rich but not relevant to the design
and the fact that it's repl-able you can quickly navigate in the stdlib.
ps: python docs are not amazing but they have a low signal/noise/confusion ratio. if one wants to suffer go "read" the javadoc, with it's empty package descriptions, extreme redudancy of autogenerated get/set * polymorphic methods. Or to stay in the python world, django docs. They're abysmally non technical.. it's full on guess fest to infer the relationships between classes and dataflow. Superb.
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.
> 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"
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.
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.
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.
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
> 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.
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.
Easy examples I use every day: ML and Quantum Computing libraries.
There is a depth to the Python ecosystem that can't be matched anywhere else.
Honestly, I'm sure I will get a ton of flack for this, but I really dislike Python. I use it every day and have for years and not only has it failed to grow on me (like most languages do), I've learned to dislike it more with each year. That said, I'm locked in. Outside of Python the libraries available are abandoned research projects or hobby tools, at least when it comes to my areas of focus.
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.
I think the reason it (and the http modules in general) has never been improved is that even when Python was young, there were better third party packages out there, but no single one of them ever got to the point where the Python devs would consider making it part of the standard library. Particularly when it comes to servers, there have always been multiple third party frameworks with significant market share. For clients, we might be getting to the point where the requests library is common enough to be a candidate for the standard library.
My personal recommendation is to use typing and mypy in all new code, coming from somebody who was celebrating new-style classes in 2.2.
I don’t think that’s true; I think that type annotations have been seeing significant gains in usage in Python in recent years.
[0] https://peps.python.org/pep-0594/ that
python3
import some_module
dir(some_module)
ipython3
import some_module
some_module?
# or
some_module??
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.
- 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.
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.
I wouldn't make assumptions like that. I've worked with production Python codebases. In fact, until recently I was working as a DevOps Engineer in a hedge fund building much bigger, more complex systems than a typical CRUD backend. I worked hands on with some of the Python repositories and it was extremely painful simply because of the nature of Python.
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.
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.
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.
> 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...
Maybe for production ready microservices, but I've always thought Python's std lib was pretty expansive.
Having a big standard library can be great, especially for things and designs that have been settled years ago, but inclusion into the standard library means iterating upon those modules will receive pushback from maintainers looking out for consumers of the standard library who need it to remain stable for potentially decades.
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.
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.
PHP was not designed at all. It took a decade to make it more than a template processor. The biggest, by far, selling point was ease of deployment: ftp and done. Good if you want to display something in a browser. Learning programming, not so much.
Javascript is starting to become a sane language with ES6. It’s an accident of history that became an industry standard due to sheer power of will of browser companies. Tooling complexity in its ecosystem rivals, if not exceeds, that of C++. Recommending js s as a language to learn programming on has been until last couple of years irresponsible.
Python was designed to be beginner friendly, it was the next iteration of other beginner-friendly languages that had some academic research done about, you guessed it, beginner friendliness. It is not an accident it’s recommended for newbies! Due to that and a decade of 1) numpy for biological computing 2) django/flask for web services it’s ubiquitous in two very loosely connected domains, giving birth to jupyter and tensor libraries, and here we are. Turns out a batteries-included standard library makes packaging not a priority for too long.
Also, being interpreted, you don't need much (or really any other than the interpreter itself) tooling to start playing around with it. This is true, of course, for lots of other languages.
I think also the fact that people do use it for real solutions makes it more appealing to recommend than a "toy" language like Logo or BASIC. (Mentally, I see BASIC as separate than VB. And yes, I am sure some people will comment that real solutions are built in BASIC, but I am sure these days Python dwarfs those in count by a factor of 100, at least.)
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*.
Ugh. Sorry, I've not really got anything constructive (destructive?) to say in support of that other than (a) in practical terms it isn't a transferrable skill beyond Windows, (b) the Naming-Conventions-OfThings is both awful and verbose, and (c) I've never had a use case where more than a handful (at most) of my fellow devs would be happy to work with it in the future.
YMMV and I appreciate this is very much a personal opinion.
And after they learn those and have few fights. They might be ready to research what to choose for next project.
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 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."
Ruby has been actively stripping the stdlib, moving libraries to default and bundled gems.
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.
In this regard, I find it interesting that the following is currently on the HN front page:
https://news.ycombinator.com/item?id=34179426
TL/DR: Go's network sockets set TCP_NODELAY by default, which is, the article argues, a very bad idea.
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.
But only those without any means of indirect calls via function pointers or reflection.
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.
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.
I suppose I have been assuming that the best policy is to do as the Romans for a long time now. Windows apps are C++ (or is it C# now?) because that's how things are over there. Android is Java, or Scala if you must -- at any rate, you hardly get to pick. Iphone requires learning Objective C. Jquery for frontend, or whatever the cool kids are doing; PHP on the back is good enough for most of the web, and it's good enough for you. And as you say, in ML, Python is not optional.
And as I think about it, I've been using specialized languages in specialized contexts for a long time. It seems the knowing the underlying language is only ever part of the problem -- you have to learn the specialized language for what you're doing, whether it's GL for graphics or your web framework's way of doing things, or MFC or .NET, or . . .
Yeah. Small tools for specific purposes, and follow the local ecosystem. Things have been going that way, and it's probably a good answer.
When in Rome, then. I like that answer. Thanks.
It does excellent fuzzy search-as-you-type, and is typically a pinned tab in my browser most of the time.
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.
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.
- `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:
conda activate <env name>
mamba install -c conda-forge ipykernel
ipython kernel install --user --name <env name>
---
1. Create a virtual environment named venv
cd $PROJECT_FOLDER
python -m venv venv
source ./venv/bin/activate3. Define and install dependencies
nano requirements.txt
pip install -r requirements.txthttps://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.)
- 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.
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.
So that's still my line of thought, but I'm already regretting typing this on HN.
There are multiple python language servers, but if you mean the Microsoft one, well, that just incorporates one of the best of the Python static typecheckers (Microsoft’s pyright)
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.
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.
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"
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.
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.
Go was pretty expressly aimed at the spot where, at the time, Python was seen as too inefficient but C++ was seen as too much complexity.
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.
> ...
> Python sucks. I mean the syntax itself.
So author notices that syntax sucks afters years of usage?
It would be swell if rationalizing the packaging story were a priority for 3.12.
> 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.
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.
Python remains the most popular programming language worldwide.
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.