3 ms·

This is interesting. Go seems to have the complete opposite stance. The stdlib are some of the most useful and well written packages you can use in the Go ecosy

by icxa 7y ago

This is interesting. Go seems to have the complete opposite stance. The stdlib are some of the most useful and well written packages you can use in the Go ecosystem, and then you have the "extended" standard lib which isn't 100% in the language yet, and even further sometimes concepts from useful community packages make it into the std lib. As to why this is the case, I think maybe this is enabled by Go's backward's compatibility focus and encouragement to upgrade early and often, and the community's focus to utilize small interfaces sometimes from the stdlib itself, like io.Reader and io.Writer, or http.Handler. Added to that w.r.t. using the latest and greatest, most Go users frequently are using the latest version of Go even in production (per the go experience surveys). I am sure it also helps that Google pays people to develop, maintain, and improve the stdlib.

rbanffy 7y ago
This approach is useful for a while, but once something is in a stdlib, its interface is frozen forever.
- icxa 7y ago
  (I am trying to tie the two concepts together from your reply, so I am not saying this to come off as combative but understand your objection) - What would you define as a while? I think Go has done well with it, given that it is almost 10 years old now at this point, and in reality, was in development internally at Google years before that. - Do you feel like an interface being frozen forever is particularly a bad thing in of itself? What if the interface does a really good job describing the thing, whatever it may be? For example, Go's io.Reader/io.Writer interfaces. I agree sometimes an interface being frozen is bad, but for example when Go standardized the context package, it simply added "Context" to the existing functions that now take a context (e.g. in the database/sql package, you have the old, Exec, Query, QueryRow functions, and after 1.8 you have ExecContext, QueryContext, QueryRowContext, which some people may view as a reason to have method overloading, but I view as adding better clarity.
  - DougBTX 7y ago
    The way to answer your two questions is to combine them, the definition of “a while” depends on how good a job the interface does. If the interface is really good, then it can last a really long time (perhaps as long as the language lasts). I read some discussion the other day about some ways in which the Any type in Rust isn’t as flexible as it could be, since it is frozen the only way to improve it would be to introduce a new name, such as Unknown. Similarly in C# along with adding async support, the standard library added async versions of many methods, eg Read now also has a ReadAsync partner. It does seem that having multiple names for basically the same thing adds a small but tolerable level of overhead to a language. At least if as much as possible is moved out, then projects can choose to only use the latest versions, and live in a world as if past versions never existed.
  - jerf 7y ago
    Go was and is by design a "boring" language. The core designers didn't have much trouble looking at decades of prior art and getting it mostly right. Rust libraries should be expected to take a few tries to get right, especially earlier in its lifecycle. There's more possibilities and less experience in the language. You can see a similar effect in Haskell, which has iterated many basic bits of functionality many times over.
pornel 7y ago
No doubt Go's stdlib is useful, and there's plenty of things it got right. However, it's not immune to making some mistakes and having to freeze them forever. The more functionality you add, the harder it gets to get it perfect on the first (and only) try. Search for "deprecated site:https://golang.org/pkg/" https://golang.org/pkg/" finds various issues ranging from cosmetic mistakes to entire packages being deprecated. CompressedSize uint32 // Deprecated: Use CompressedSize64 instead. CompressedSize64 uint64 // Go 1.1 // Deprecated: HeaderMap exists for historical compatibility // and should not be used. Requirements may change over time, so even getting something perfect now is not a guarantee it will last (e.g. pre-UTF-8 languages froze byte-oriented or UCS-2 strings, even though these were good decisions at the time). Sometimes improvements are not worth the cost of deprecation and replacement, so things are just left as they are. For example, an HTTP interface designed for request-response HTTP/1 works for stream-oriented HTTP/2, but support for push, prioritization and custom frames is bolted on. Packet-oriented HTTP/3 will add even more stuff that will have to be retrofitted somehow to the old model. Libraries can come and go, but std can't just throw away an old interface and start over.

by icxa 7y ago

rbanffy 7y ago

This approach is useful for a while, but once something is in a stdlib, its interface is frozen forever.

icxa 7y ago
(I am trying to tie the two concepts together from your reply, so I am not saying this to come off as combative but understand your objection) - What would you define as a while? I think Go has done well with it, given that it is almost 10 years old now at this point, and in reality, was in development internally at Google years before that. - Do you feel like an interface being frozen forever is particularly a bad thing in of itself? What if the interface does a really good job describing the thing, whatever it may be? For example, Go's io.Reader/io.Writer interfaces. I agree sometimes an interface being frozen is bad, but for example when Go standardized the context package, it simply added "Context" to the existing functions that now take a context (e.g. in the database/sql package, you have the old, Exec, Query, QueryRow functions, and after 1.8 you have ExecContext, QueryContext, QueryRowContext, which some people may view as a reason to have method overloading, but I view as adding better clarity.
- DougBTX 7y ago
  The way to answer your two questions is to combine them, the definition of “a while” depends on how good a job the interface does. If the interface is really good, then it can last a really long time (perhaps as long as the language lasts). I read some discussion the other day about some ways in which the Any type in Rust isn’t as flexible as it could be, since it is frozen the only way to improve it would be to introduce a new name, such as Unknown. Similarly in C# along with adding async support, the standard library added async versions of many methods, eg Read now also has a ReadAsync partner. It does seem that having multiple names for basically the same thing adds a small but tolerable level of overhead to a language. At least if as much as possible is moved out, then projects can choose to only use the latest versions, and live in a world as if past versions never existed.
- jerf 7y ago
  Go was and is by design a "boring" language. The core designers didn't have much trouble looking at decades of prior art and getting it mostly right. Rust libraries should be expected to take a few tries to get right, especially earlier in its lifecycle. There's more possibilities and less experience in the language. You can see a similar effect in Haskell, which has iterated many basic bits of functionality many times over.

pornel 7y ago

No doubt Go's stdlib is useful, and there's plenty of things it got right. However, it's not immune to making some mistakes and having to freeze them forever. The more functionality you add, the harder it gets to get it perfect on the first (and only) try. Search for "deprecated site:https://golang.org/pkg/" https://golang.org/pkg/" finds various issues ranging from cosmetic mistakes to entire packages being deprecated. CompressedSize uint32 // Deprecated: Use CompressedSize64 instead. CompressedSize64 uint64 // Go 1.1 // Deprecated: HeaderMap exists for historical compatibility // and should not be used. Requirements may change over time, so even getting something perfect now is not a guarantee it will last (e.g. pre-UTF-8 languages froze byte-oriented or UCS-2 strings, even though these were good decisions at the time). Sometimes improvements are not worth the cost of deprecation and replacement, so things are just left as they are. For example, an HTTP interface designed for request-response HTTP/1 works for stream-oriented HTTP/2, but support for push, prioritization and custom frames is bolted on. Packet-oriented HTTP/3 will add even more stuff that will have to be retrofitted somehow to the old model. Libraries can come and go, but std can't just throw away an old interface and start over.