I don't see any useful info there, do you mind translating that for me as it would be interesting to know what % of golang projects uses only the stdlib.
I'm not sure I understand correctly but I'm assuming that this:
> Having such a large standard library to me smells like you can't build one as nice as that with the language.
means that you're implying that the Go stdlib is written in non-Go because Go would not be expressive enough. If so, that's a wrong assertion. The entire Go toolchain is Go, including the compiler, runtime and stdlib. If you happen to have Go installed, you can find the stdlib at /usr/lib/go/src.
There’s an ongoing debate among go dev if the stdlib is enough or not to perform « real world » work (which isn‘t the case in other languages). This article is from someone who think it’s not. That’s interesting.
Packages like this are where I find the debate between idiomatic Go usage and general use cases difficult to side on. I would err on the idiomatic side by using stdlib flag.
A lot of people are saying to read the stdlib, but the stdlib has a lot of objectively bad code in it. Some of it is necessary due to the nature of a standard library - you have extra concerns about dependencies to ensure people don't have to include the entire stdlib in every binary. Some of it is stuff they hacked together when they were still designing the language, and that initial code still works fine so no need to update it.
I think the source code for pkg.go.dev is actually a treasure trove of good ideas and design patterns, especially if you are trying to make a small to mdedium sized web app (which, lets be real, is almost all web apps anyone will ever make). https://github.com/golang/pkgsite
I’ve seen it happen before because the stdlib actually directly just makes POSIX syscalls for a lot of things by default instead of using the native Go implementations and so you’re implicitly reliant on C code
They wanted to help get the language off the ground. Without the stdlib at launch, I don't think Go would have been nearly as well received. I feel like it's one of the key pieces people first coming to the language like.
The golang.com/x/ packages seems to be handling extending the stdlib at this point.
I think the confusion is caused by the notion of a separate library that is also “stdlib” - which is the version that comes with the official distribution.
This comment is the first time I realised it was not intended to be a drop-in replacement for the Go standard library (in a musl - glibc kind of relationship).
I've written several services in my line of work where I was able to stick completely within the standard libraries. Half of my personal go projects likewise use the stdlib only. One of the projects that doesn't conform could do with a little coaxing, I only use afero for test convenience of creating a virtual fs. I'm likely to remove it in a future update.
And make the standard library unmagical? One of the things I've always disliked about Go is how stdlib provides magic facilities unavailable to user code.
reply