"Dependency hygiene trumps code reuse.
Example:
The (low-level) net package has own itoa to avoid dependency on the big formatted I/O package."
...now, if this kind of attitude stays in the core dev land I don't really care about it. But when I'll consider Go as an alternative for a large project, 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 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" that requires the first one, and have the "net" package only require "basic formatted I/O" (or maybe even make "basic formatted I/O" something like part of the language "built ins" or smth - I don't know Go so I don't know the Go terms for this)?
> 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.
> It would easy, but then you're cluttering your library to make implementing the std lib easier
yeah, but the "advanced formatted I/O" package can include all the function from the "basic" one (i.e. act as if it contains all the functions and structs from both of them) and be the only package 90% of regular language users know about, and if happened to need to write some low level code that only needed the "basic/low-level formatted I/O" I would just import that ...it just seems 100x more "sane" to do it this way
"Dependency hygiene trumps code reuse. Example: The (low-level) net package has own itoa to avoid dependency on the big formatted I/O package."
...now, if this kind of attitude stays in the core dev land I don't really care about it. But when I'll consider Go as an alternative for a large project, 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 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" that requires the first one, and have the "net" package only require "basic formatted I/O" (or maybe even make "basic formatted I/O" something like part of the language "built ins" or smth - I don't know Go so I don't know the Go terms for this)?