Yes, but it is still a dependency. By which I mean the software won't run if you don't supply the necessary thing at resolution time (which is possibly quite late: well into runtime, if you are on a system with lazy linking). Go (and some other languages, like OCaml) enforces that such dependencies form a DAG: C++ does not.
I don't think this has much to do with compilation speed though.
I'm not saying that isn't true for some things. I don't think its true here given that this is a nice narrowly scoped library that does a single thing and has well defined semantics.
Adding a cgo dependency is generally something that isn't done lightly by teams. Having a port to go instead of a wrapper around go would be much more likely to see widespread adoption.
Go standard library is absolutely littered with these kinds of tweaks. Not necessarily bad, but it does make an integration with non-standard library less satisfactory because such special casing is not scalable. Still within the expectation though.
Seconded. Unlike Node/Ruby/most other modern languages, Go devs actively avoid including dependencies if at all possible.
And contrary to rumour, this is not because Go's dependency management sucks. It's more about the pursuit of simplicity, and avoidance of magic.
You can write pretty much anything using just the standard library (and some of the official packages, like the crypto ones). As the parent said, it's good practice to go as far as possible with just the stdlib.
Not really. Go doesn't use shared libraries (yet), so you're only really recompiling the end binaries.
If you're using Go, you should already have the infrastructure to do this. Everything we have gets rebuilt for each go release anyway, so this is no different, just a little more immediate.
No, by default Go programs and the whole Go toolchain has no C dependencies. The whole Go toolchain is implemented in Go and it doesn't like into any C libraries. Go links against libc only if you either use CGO or a package which has C dependencies, but I am not sure whether there is any package left in the standard distribution, that does.
Go the language lets the Go the standard library play with things that nothing else can. If you can't implement it yourself, is it really a library and not just part of the language runtime?
Anything that relies on system libraries. This works fine for most Go apps, but can have unexpected results if you don't compile the app correctly to use Go networking and what not.
Plus given Go's focus on external dependencies, a common task like reading commandline parameters can (and should) be done with a library that solved that problem for you already - don't reinvent the wheel, and such.
No, the stack switch overhead is trivial. As explain in my other comment, Go does system calls in order not to have any dependencies on target libraries.
That's what your quote says. However, what it also says is that functionality is only available for Go versions, and therefore Go standard library versions. It is not functionality available around third-party libraries that are developed independently of the Go release cycle.
reply