You don't need official Go support for JSON5. Same for templating. The templating library in the standard library isn't anything special, it's just in the standard library. If you don't like it, go get one of the dozens of others on offer.

I think there's a number of language communities you can "grow up" in that teach you that things in the standard library are faster than anything else and have had more attention paid to them than anything else, like Python or Perl, because those languages are slow, and things going into the standard library have generally been converted to C. I think that because I look in my own brain and find that idea knocking about even though nobody ever said it to me directly. But that's not true in the compiled languages, of which Go is one. The vast majority of the Go standard library is written in Go. The vast majority of that vast majority isn't even written in complicated Go, it's just in Go that any Go programmer who has run through a good tutorial can read, it's not like a lot of standard libraries that are fast because they are written impenetrably. (Although the standard library may have subtle performance optimizations because it chooses this way of writing it in Go rather than that way, it's still almost entirely straightforward, comprehensible code.)

If you want JSON5 or a different template library, go get or write one. The Go encoding/json or text/template don't use any special access or have any magical compiler callouts you can't access in a library or anything else; if you grab JSON5 library (if such a thing exists), you've got as much support for it as JSON or text/template.

It's even often good that it's not in the standard library. I've been using the YAML support a lot lately. The biggest Go YAML library is on major version 3, and both of the jumps from 1 to 2 and 2 to 3 were huge, and would have been significantly inhibited if v1 was in the standard library and the backwards compatibility promise applied. v1 definitely resembles encoding/json, but that's missing a lot of things for YAML. If Go "supported YAML" by having v1 in the standard library, everybody would be complaining that it didn't support it well, and by contrast, asking anyone to jump straight to the v3 interface would be an insanely tall ask to do on the first try without any experimentation in the mean time. And I'm not even 100% sure there won't be a v4.

I disagree with this stance.

To me, the community take on "stdlib vs libraries" is a cyclical thing; we're coming out of a cycle led by JavaScript/NPM, where everything is a library due in no small part to how HORRIBLE JS/NodeJS's standard library is. Go back further, and you run into the Python/Java world which had far more comprehensive stdlibs, and today Go's (and to a lesser degree, Rust's) rising popularity is bringing back more feature-complete stdlibs.

So, it changes. And its alright for different languages to have different stances on how comprehensive their stdlibs should be. Go is absolutely an example of a language that wants tons of stuff in its stdlib; but its also a language which despises change, and thus we got a very awesome stdlib at v1, and limited improvements to it over the years.

I don't feel the "YAML changes a lot" argument is valid. It does; but if an app needs YAML, they can choose to use the stdlib, or a library, and they'll have to keep up regardless.

Putting it in the stdlib has tons of advantages. First: it increases the scope of parties affected by any breaking change, which naturally forces more deliberate thought into the change's necessity and quality. Second: it reduces the number of "things" code consumers need to update; from the go version itself & the YAML library & consuming code, to just the go version & consuming code (this has network productivity effects in only having to source one "breaking changes" changelog for your hit list on what needs updated). Third: it reduces multivariate dependency-dependency issues (eg YAMLv2 requires Go1.14, but we're on Go 1.13, so first we have to upgrade to Go1.14, then we can upgrade to YAMLv2). Fourth: it reduces the number of attack surfaces which security professionals need to monitor (all eyes on the stdlib implementation, versus N community implementations, strength in numbers). Fifth, less about YAML, but: stdlib encourages what I call the "net/http.Request effect"; if I want to write a library that does stuff with http requests, its nearly impossible to do that in a framework-agnostic way in JavaScript, because express does things differently than hapi etc; but in Go, everything is net/http.Request. So even if the stdlib doesn't have everything one needs, plugging in libraries to solve it is easier because everyone is using the same interfaces/structures.

Obviously not everything can be in stdlib, so it comes down to the question: what belongs there. And in my opinion, every language is too conservative (except maybe Python, which strikes a strong balance). Many language teams will say "we're not including X because X isn't an ISO standard, or because its still changing, or because we're not sure on the implementation". These are all arguments out of cowardice and fear of asserting an opinion. Language designers have developed a deep, deep fear of opinions; because they believe, maybe correctly, that one of their opinions will be bad, and it will hurt adoption. The issue is; having no opinion just hurts productivity, and people will also move from your language toward more productive ones (see: Go's rise in popularity, versus JS's dependency issues).

My point isn't really an argument about what does and does not need to be in the standard library, as much fun as that may be to argue about. My point is really in that first sentence: "You don't need official Go support for JSON5."

Whether the Go team agrees with you or not about any particular library, you do not need to wait around. The standard library does not get any particular special access, with the exception of a couple of very special packages (unsafe, reflect). Things outside of the standard library can have all the properties you're talking about being good, and they're available now, without needing to get an entire language team to sign off on it.