Hacker News Reader

Comment by pmb | Hacker News Reader

They tried to make a better C++ and accidentally made a better Java and a better Python.

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.

Only a mess if you use python 2, conda, etc... What’s difficult about this?

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in...)" curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/maste... | python - brew install pyenv // update shell with pyenv pointer pyenv install 3.9.0 pyenv global 3.9.0 poetry init poetry config virtualenvs.in-project true --local poetry install

For deployment, Docker python3:alpine, install poetry, copy over pyproject.toml and install

> What’s difficult about this?

Well, for starters, that particular multi-liner:

- 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.

Plus, it does so non-reproducibly and downloads random binaries from the internet.

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.

>Go makes arbitrarily large codebases feasible

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.

How many years of Java experience do have?

I’d be really interested in hearing more about the ‘better Java’ point, if you have the time.

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

> a GC that can has relatively smart defaults without having to tweak a ton of parameters

Depends on the JVM being used

> don't have to ship a vm

You get to ship a runtime instead.

Which Java also allows since around 2000, given how long commercial AOT compilers do exist for Java.

> simpler language

Java 1.0 was also Go simple, and just like Go does nowadays, full of code generation tools to work around that simplicity.

> doesn't try to square everything into the OO paradigm

Interfaces are part of OOP, introduced by Objective-C protocols.

> Depends on the JVM being used

Is picking a jvm not tweaking a parameter?

Just like picking Go, gccgo, TinyGo, TamaGo or whatever might come down the line.

Nobody really does that.

They do, otherwise they wouldn't exist.

Reply on news.ycombinator.com