Hacker News Reader

Comment by Gravyness | Hacker News Reader

> With so many better options for configuration languages, there’s no good reason to use JSON

I have been surprised by how silly that conclusion is, even though it's from 2018.

JSON is so bad it is on the standard library of all major languages, natively supported by php, python, nodejs, javascript, ruby and many others, unlike YAML, TOML, FADFH or whatever solution someone comes up to a problem that is essentially solved.

If you want perfection then by all means reinvent the wheel. But otherwise, don't be an edgy teen, just go with what the entire industry tells you that works.

View on HN

> JSON is so bad it is on the standard library of all major languages

This is like claiming that HTTP is a good way for people to type messages to each other, because it's in the standard library for all major languages. Existing in a standard language doesn't mean it was meant to be typed directly by humans. The lack of comments was an intentional design choice [1] to make sure its intent, a data exchange format, was understood.

1. https://news.ycombinator.com/item?id=3912149

> unlike YAML, TOML, FADFH or whatever solution

TOML and YAML are each supported by every language you listed.

https://github.com/toml-lang/toml/wiki

https://yaml.org/

They aren't supported by the standard libraries of those languages though. It is still a major advantage of JSON.

Does that matter nowadays? Unless you're writing a small script in a language with terrible dependency management like Python, you're going to have a bunch of non-standard-library dependencies, one more doesn't make much difference.

> with terrible dependency management like Python

Ah yes, because writing a requirements.txt is complicated, writing a pyproject.toml is complicated, or distributing your app with pyinstaller is complicated.

The Python ecosystem has many options that solve dependency management, this is what makes the standard evolve (like the PEP about pyproject.toml which is now a standard). This is healthy, and installing Python deps, even native has never been a problem since the wheels package have been standardized.

Can we stop with those obsolete claims that Python packaging is a mess? The package format barely changed in the last 20 years, and every solutions rely on setuptools and/or pip.

> Ah yes, because writing a requirements.txt is complicated, writing a pyproject.toml is complicated, or distributing your app with pyinstaller is complicated.

Writing it isn't complicated. Getting deterministic behaviour out of it is. (Yes, there's freeze which is better than nothing, but that doesn't help if you're actually developing a project; you can freeze your transitive dependencies, but sooner or later you'll want to upgrade something that depends on something you froze, and so then you have to unfreeze everything and hope that nothing else breaks).

> The Python ecosystem has many options that solve dependency management, this is what makes the standard evolve (like the PEP about pyproject.toml which is now a standard).

The Python ecosystem has many options because they all suck. Every few years someone writes a new one that claims to fix the problems, but they still haven't managed to catch up with where Maven was 20 years ago. (Indeed I'd argue they've actually gone backwards in some ways, e.g. including pip in newer versions of Python).

> Can we stop with those obsolete claims that Python packaging is a mess? The package format barely changed in the last 20 years, and every solutions rely on setuptools and/or pip.

The claims are not obsolete, and the fact that things have barely changed in 20 years is a big part of the problem.

> Getting deterministic behaviour out of it is.

As you said, there is `pip freeze`, but also the Pipfile.lock for pipenv and the poetry.lock for poetry.

> but sooner or later you'll want to upgrade something that depends on something you froze, and so then you have to unfreeze everything and hope that nothing else breaks

Same for Rust with its Cargo.lock, same for JS with it's package-json.lock or yarn.lock, same for everything that lets you freeze your dependencies.

EDIT: That's also what test suites and CI/CD are for.

> The Python ecosystem has many options because they all suck.

They let me write software, manage dependencies and virtualenvs, there is even pdm which supports the recent PEP for __pypackages__ (equivalent of node_modules) instead of a virtualenv.

Can you clarify how every single one of them suck?

> they still haven't managed to catch up with where Maven was 20 years ago

What does Maven do to prevent the problem of upgrading frozen dependencies?

> I'd argue they've actually gone backwards in some ways, e.g. including pip in newer versions of Python

Care to clarify?

> What does Maven do to prevent the problem of upgrading frozen dependencies?

You don't need to freeze your dependencies in the first place, because dependency resolution is deterministic. (In the case where you want to upgrade a transitive dependency without upgrading your direct dependency, you specificy it explicitly; if you want the latest available version, or the latest available version with the same minor number or whatever, you can run a command to populate your project file with that, but it's an explicit, visible operation).

> EDIT: That's also what test suites and CI/CD are for.

That's an admission that the dependency management isn't doing its job.

> Can you clarify how every single one of them suck?

My point is that the huge proliferation of options is not a sign that they're good, but rather the opposite. Ecosystems that have decent dependency management don't feel the need to write a new system every couple of years. Maybe PDM is finally the one that doesn't suck, but at some point after six or seven tries that all suck (and yet were always widely trumpeted as "python packaging is fixed now") my confidence is pretty low.

> > I'd argue they've actually gone backwards in some ways, e.g. including pip in newer versions of Python

> Care to clarify?

Sure. I want a single entry point that I can install on my system (via my package manager) and run to build any Python project, when realistically I'm going to be working with a bunch of projects that each have separate sets of dependencies and each require separate Python versions. Putting pip in the standard library means a) half my python installs have pip and half don't b) I have several different versions of pip installed at any given time. And so it entrenches the complexity where I have to have a separate tool like virtualenv for managing which Python version I'm using for each project as well as pip. (Which wouldn't be so bad if accidentally running pip for one project while your shell was in the virtualenv for another didn't fuck up that virtualenv, potentially permanently...).

In C++ you get the great https://github.com/nlohmann/json

In Rust you have the amazing serde with serde_json but at this point, you can use toml which is also based on serde. I consider serde as being standard.

In C you have the lib jason which is very good.

In Elixir, I use the compile-time configuration (config/config.exs) with environment variables for production, but that's because in the end, my Elixir system is in a Docker container, running on Kubernetes, with a ConfigMap defining the environment variables, so in the end, it's YAML (or JSON).

"Use the popular thing because it is popular."

The same industry was—substantially still is!—telling us to use XML everywhere. Let's not.

> JSON is so bad it is on the standard library of all major languages, natively supported by php, python, nodejs, javascript, ruby and many others

Pretty sure that "all" isn't correct here. Or we have different lists of major languages.

Reply on news.ycombinator.com