4 ms·

I think that the idea itself sounds grand. No doubt there'll be some implementation hurdles, but it all makes sense. But: > godep already uses JSON, as do Go

by wtbob 12y ago

I think that the idea itself sounds grand. No doubt there'll be some implementation hurdles, but it all makes sense. But: > godep already uses JSON, as do Go tools themselves (e.g. “go list -json fmt”), so we’ll probably want something like godep’s JSON format… Seriously, the only things good about JSON (and it is good) are that it's so widely supported and that it has a clean representation of maps/dicts/hashes/whatever-you-call-them. Take a look at the two lines of text config in the article, vice the twelve lines of JSON. What's wrong with nice, clean formats line text lines, s-expressions, even .ini? JSON is better than XML, but that's damning with faint praise.

nemo1618 12y ago
agreed, I think INI-style (specifically https://code.google.com/p/gcfg https://code.google.com/p/gcfg) is a better choice for simple config files. That said, they might be anticipating more complex configs in the future.
- Zikes 12y ago
  TOML seems to be a popular INI successor, however the idea around suggesting JSON (or native Go) is that it can be easily parsed with standard libraries.
  - NateDad 12y ago
    Obvious solution is to add toml to the std lib. :) only half joking. Toml rules.
    - Zikes 12y ago
      I wouldn't be surprised if that happened, it seems like a good fit. Is there a standard or RFC?
rtpg 12y ago
I'd say JSON is more on the level of s-expression than an ini file. JSON objects are extremely regular (your thing's either an object or a literal), more-so than your standard 2-level ini file. Plus there's a lot of stuff. Sure, JSON might be a bit more verbose for the "Hello World" scenario, but in mid-range sizes, it's still pretty clear (compared to the verbosity of XML) and doesn't require custom tooling to deal with (like ini files). There are some formats with less braces (replaced with indents and with less key stuff) that are (I think) isomorphic to JSON that would be nicer to use for everyone involved, though.
lmm 12y ago
s-expressions are unreadable for most people. .ini can't represent complex structures or even simple ones like lists or maps. Things like YAML exist but aren't better than JSON by enough to justify a proliferation of formats. JSON everywhere would be a win.

by wtbob 12y ago

nemo1618 12y ago

agreed, I think INI-style (specifically https://code.google.com/p/gcfg https://code.google.com/p/gcfg) is a better choice for simple config files. That said, they might be anticipating more complex configs in the future.

Zikes 12y ago
TOML seems to be a popular INI successor, however the idea around suggesting JSON (or native Go) is that it can be easily parsed with standard libraries.
- NateDad 12y ago
  Obvious solution is to add toml to the std lib. :) only half joking. Toml rules.
  - Zikes 12y ago
    I wouldn't be surprised if that happened, it seems like a good fit. Is there a standard or RFC?

rtpg 12y ago

I'd say JSON is more on the level of s-expression than an ini file. JSON objects are extremely regular (your thing's either an object or a literal), more-so than your standard 2-level ini file. Plus there's a lot of stuff. Sure, JSON might be a bit more verbose for the "Hello World" scenario, but in mid-range sizes, it's still pretty clear (compared to the verbosity of XML) and doesn't require custom tooling to deal with (like ini files). There are some formats with less braces (replaced with indents and with less key stuff) that are (I think) isomorphic to JSON that would be nicer to use for everyone involved, though.

lmm 12y ago

s-expressions are unreadable for most people. .ini can't represent complex structures or even simple ones like lists or maps. Things like YAML exist but aren't better than JSON by enough to justify a proliferation of formats. JSON everywhere would be a win.