4 ms·

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

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

linkdd 4y ago
In C++ you get the great https://github.com/nlohmann/json 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).
valbaca 4y ago
> 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://github.com/toml-lang/toml/wiki https://yaml.org/ https://yaml.org/
- hillcrestenigma 4y ago
  They aren't supported by the standard libraries of those languages though. It is still a major advantage of JSON.
  - lmm 4y ago
    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.
    - linkdd 4y ago
      > 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.
      - lmm 4y ago
        > 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.
        linkdd 4y ago
        > 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?
nomel 4y ago
> 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 https://news.ycombinator.com/item?id=3912149
tikhonj 4y ago
"Use the popular thing because it is popular." The same industry was—substantially still is!—telling us to use XML everywhere. Let's not.
rascul 4y ago
> 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.

linkdd 4y ago

In C++ you get the great https://github.com/nlohmann/json 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).

valbaca 4y ago

> 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://github.com/toml-lang/toml/wiki https://yaml.org/ https://yaml.org/

hillcrestenigma 4y ago
They aren't supported by the standard libraries of those languages though. It is still a major advantage of JSON.
- lmm 4y ago
  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.
  - linkdd 4y ago
    > 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.
    - lmm 4y ago
      > 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.
      - linkdd 4y ago
        > 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?

nomel 4y ago

> 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 https://news.ycombinator.com/item?id=3912149

tikhonj 4y ago

"Use the popular thing because it is popular." The same industry was—substantially still is!—telling us to use XML everywhere. Let's not.

rascul 4y ago

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