4 ms·

The “powerful standard library” to my experience is a myth that holds no water. Even trivial projects use external packages to handle trivial things like an HTT

by atmosx 6y ago

The “powerful standard library” to my experience is a myth that holds no water. Even trivial projects use external packages to handle trivial things like an HTTP server or logging. No project I saw, however small, uses just the standard library.

frou_dh 6y ago
Well objective data on this is out there if anyone can be bothered trawling through it: https://github.com/search?o=asc&p=4&q=language%3Ago&s=stars&type=Repositories https://github.com/search?o=asc&p=4&q=language%3Ago&s=stars&...
- atmosx 6y ago
  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.
lowmagnet 6y ago
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.
bad_op3rator 6y ago
It's always a good idea to end up with fewer dependencies
jen20 6y ago
I've written dozens of Go programs which use only the standard library - including very large ones. However, there are two primary areas where it is deficient (necessitating pulling additional packages) to my mind: - Logging - a lack of ability to do structured logging is the main downside here. - The `syscall` replacements - almost inevitably for larger projects it's necessary to pull in the x/sys/unix or x/sys/windows since package `syscall` was frozen. The lack of "wrapped" errors also used to be an issue, but this has mostly been resolved with the new "%w" formatting directive to `fmt.Errorf`.
- atmosx 6y ago
  I'm not saying that it is not possible I'm saying that it's not happening to the extend that would make that argument true. If 10% of the golang projects were based on stdlib, then I'd buy that argument, but I expect that number for be a lot smaller.

by atmosx 6y ago

frou_dh 6y ago

Well objective data on this is out there if anyone can be bothered trawling through it: https://github.com/search?o=asc&p=4&q=language%3Ago&s=stars&type=Repositories https://github.com/search?o=asc&p=4&q=language%3Ago&s=stars&...

atmosx 6y ago
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.

lowmagnet 6y ago

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.

bad_op3rator 6y ago

It's always a good idea to end up with fewer dependencies

jen20 6y ago

I've written dozens of Go programs which use only the standard library - including very large ones. However, there are two primary areas where it is deficient (necessitating pulling additional packages) to my mind: - Logging - a lack of ability to do structured logging is the main downside here. - The `syscall` replacements - almost inevitably for larger projects it's necessary to pull in the x/sys/unix or x/sys/windows since package `syscall` was frozen. The lack of "wrapped" errors also used to be an issue, but this has mostly been resolved with the new "%w" formatting directive to `fmt.Errorf`.

atmosx 6y ago
I'm not saying that it is not possible I'm saying that it's not happening to the extend that would make that argument true. If 10% of the golang projects were based on stdlib, then I'd buy that argument, but I expect that number for be a lot smaller.