> I'll start worrying if people adopt the "it's OK to reinvent some wheels" philosophy when they start building higher level frameworks in Go... I certainly do

> I'll start worrying if people adopt the "it's OK to reinvent some wheels" philosophy when they start building higher level frameworks in Go... I certainly don't have this philosophy, and I don't know thats its a thing amongst Go programmers. I think its just a standard library thing. > I mean, how hard can it be to split the "big formatted I/O package" into a "basic formatted I/O" package and an "advanced formatted I/O package" It would easy, but then you're cluttering your library to make implementing the std lib easier, rather than making the lives of people using the std lib easier. > or maybe even make "basic formatted I/O" something like part of the language "built ins" Things that are in the language built-ins would need to go in the spec, and would need to be implemented by two separate compiler suites. The authors seem to be doing their best to keep the core as small as possible. Having libraries written in Go is cleaner, reusable across compilers, and give newcomers a place to read idiomatic Go.