Agree over the java part. But Python is still orders of magnitude more productive, being it because of the ecosystem, available libraries, frameworks, or almost any other metric. The only advantage over python is performance, and maybe static typing depending on your taste.
Go more than makes up for this in the deployment aspect, since deploying Python in 2020 (Python 2, Python 3, conda, pip, venv, system interpreter, poetry, etc.) is still a mess.
- installs an entire package manager, which may or may not conflict with system tools or a different package manager,
- assumes pyenv will build Python against the system libraries without additional flags (it won't if you're running Big Sur, you'll need zlib from Homebrew),
- assumes you are on macOS, and does not attempt to work on Windows or Linux, or account for the idea that someone might not want to deploy a program using Docker.
Which makes rolling back a bad push really interesting. Give me a append only repo with my static binaries that my compute nodes deploy from. I even went to the trouble to put Python into RPMs for this.
pip is broken in no many aspects, between pip and pip3, things installed in your home folder vs /var, "binary" entries that don't exist after installing a tool, cryptics stack traces because of missing libs / not compatible for your platform ( native build ) ect ...
Why do we need virtual env in 2020?
It's one of the worse "modern" language to build, even Java / NodeJS are better.
It may be more productive if you are the sole consumer of your code. If you need to ship code to be run by third parties Python tends to result in overly complex and tedious setup process. One shouldn't ignore that users of Python applications often have to pay the price.
Go makes arbitrarily large codebases feasible. I find Python to be exponentially more painful as codebase size increases. For personal projects this is fine, but for industrial use cases Go has a significant competitive advantage.
For me, this is the consequence of a reasonable static type system. Without generics and the current error handling story, it almost feels like Go makes large codebases necessary in the projects I've used it, compared to other statically typed languages such as Kotlin, Java, Rust, and C#.
Go 2 on the other hand looks like it will solve this problem, and I eagerly await its release.
In my codebase at work there are a few cases where code is (poorly duplicated) that would benefit from a proper generic solution. But I don’t expect go2 to significantly reduce our codebase size, even if we replaced the aforementioned components.
I agree that some form of static typing is critical to scale a codebase, or an ecosystem. Let’s also not forget the importance of a packaging system with robust version management. Go modules and proxy.golang.org are also critical to Go’s success at (code) scale.
> Agree over the java part. But Python is still orders of magnitude more productive, being it because of the ecosystem, available libraries, frameworks, or almost any other metric.
Not the OP, but i would have guessed that the (subjective) axes of "being better" are uncontroversial - by which I mean prepend "there are many who value that" in front of each:
- a GC that can has relatively smart defaults without having to tweak a ton of parameters
- don't have to ship a vm
- concurrency baked in from the start
- simpler language
- doesn't try to square everything into the OO paradigm