11 ms·

Go has the best and most consistent std library I have seen.

coldtea 11y ago
It's quite good, but e.g. Java SDK has stuff that runs circles around Go's standard library regarding breadth and maturity, especially stuff added since 1.4 (nio, etc). And some aspects of the Go SKD are horrible in practical use. Case in point, most things math related.
- krylon 11y ago
  Well, yes. But Java's standard library is also huge and full of deprecated stuff. I have not done a lot of Java programming, but when I did play around with Java, I found myself spending most of the time actually browsing through the standard library's documentation (which is, to be fair, really, really good) looking for stuff. Also, Java has a head start of nearly 15 years on Go, and the Java community is (or used to be, at least) pretty huge. Not that this invalidates your point.
  - gravypod 11y ago
    Add an extra 30 years to that. Java's designers didn't history of computer science and language development for the of sake "simplicity". (Generics, error handling, etc.)
TheDong 11y ago
Consistent standard library? It's a crapshoot what will be an interface and what will be a struct, which is one of the fundamental features of the language. Returned error values are sometimes errors.New (e.g. io.EOF) and sometimes random fmt.Errorf strings that couldn't possibly be handled (e.g. all of tls.go basically), sometimes actual structs (e.g. PathError), and sometimes panics. If you can't even get error handling right and consistent, what claim do you have to consistency? At least in java it's pretty much all exceptions. The math library, as mentioned above, is pretty darn iffy. The existence of both 'path' and 'filepath' is possibly a mistake. The 'heap' and 'list' in collections both seem like they should be similar, but 'heap' operates on a thing that fulfills its interface and list operates directly on arbitrary objects without some interface needed. Due to the lack of 'protected', the std library is littered with exported fields you shouldn't use (e.g. gob.CommonType and template.Template.*parse.Tree and so on). Sure, the library is consistent in many places because the language is so small there's little else it can do but be consistent, but the fact that it falls flat in error handling and has visible warts makes me feel that it's a very broad std library, but far less consistent than, say, Rust's (where everything returns consistent Optional error types) or Java's or Smalltalks. Sure, it's more consistent than the clusterfuck that is ruby and/or python or javascript or (heaven forbid) c/c++, but by no means is being better than any of those an achievement in this category.
- apenguin 11y ago
  Sorry, but I can't find what you're referencing with the "as mentioned above" on math; could you clarify? My biggest problem with the math library was, IIRC, everything only takes float64s, which makes dealing with any of the other number types more difficult than it should be (I shouldn't need to cast an int to a float and back in order to get the max of two numbers).
- chimeracoder 11y ago
  > Returned error values are sometimes errors.New (e.g. io.EOF) and sometimes random fmt.Errorf strings that couldn't possibly be handled (e.g. all of tls.go basically), sometimes actual structs (e.g. PathError), This is the advantage of having errors be interfaces rather than concrete values. Once you learn how to use it, it's a strength. The usage of structs that satisfy the interface (as in PathError) is clearly documented and completely predictable. If your concern is that a certain package could use a struct satisfying the interface and does not, well, one advantage of errors as interfaces is that you could propose this change without breaking the backwards compatibility guarantee. It's really important to keep in mind that errors are adopted from error values in C, which means that their idioms and usage is inspired by that rather than by exception handling. Many new Go programmers (including me, when I started) were more familiar with exception handling in higher-level languages than error handling in idiomatic C, so it does take some getting used to. > and sometimes panics. Do you have any examples of the standard library using panics to signal handle-able errors (not counting cases in which the panic is recovered at the top-level in the library and never visible to the caller)? > The math library, as mentioned above, is pretty darn iffy. The only complaint I have had about package "math" is that all operations are defined on float64s, which can be annoying, but is far better than any alternative. That's an annoyance, but it's certainly not an inconsistency in the library. Do you have any other examples of inconsistencies in the math package?
  - lclarkmichalek 11y ago
    $ curl http://golang.org/pkg/reflect/ | grep panic | wc -l 79
nevergo 11y ago
Go has the poorest std lib I've ever seen.
- andrewchambers 11y ago
  Compared with? My reference point is python,java,clojure,c,c++. Python is huge and useful but messy and inconsistent. Java is huge and doesn't compose well. Clojure is underdocmented and hardly batteries included. C and C++ can't do anything useful without a bunch of extra libraries. From what I can see, C# is like java in this regard. Go is a small incredibly useful and composable set of libraries that handles a vast amount of cases with a small amount of code.
  - okal 11y ago
    I had the same feeling about Clojure, but it mostly has to do with non-standard libs. It's forced me to rely on reading source code a lot more than I did in other languages, so I'm not entirely sure that's a mark against it. I'm curious why you think that about Python, though. Care to illustrate?
  - nevergo 11y ago
    Just poor, don't make me laugh.

It's quite good, but e.g. Java SDK has stuff that runs circles around Go's standard library regarding breadth and maturity, especially stuff added since 1.4 (nio, etc). And some aspects of the Go SKD are horrible in practical use. Case in point, most things math related.

krylon 11y ago
Well, yes. But Java's standard library is also huge and full of deprecated stuff. I have not done a lot of Java programming, but when I did play around with Java, I found myself spending most of the time actually browsing through the standard library's documentation (which is, to be fair, really, really good) looking for stuff. Also, Java has a head start of nearly 15 years on Go, and the Java community is (or used to be, at least) pretty huge. Not that this invalidates your point.
- gravypod 11y ago
  Add an extra 30 years to that. Java's designers didn't history of computer science and language development for the of sake "simplicity". (Generics, error handling, etc.)

TheDong 11y ago

Consistent standard library? It's a crapshoot what will be an interface and what will be a struct, which is one of the fundamental features of the language. Returned error values are sometimes errors.New (e.g. io.EOF) and sometimes random fmt.Errorf strings that couldn't possibly be handled (e.g. all of tls.go basically), sometimes actual structs (e.g. PathError), and sometimes panics. If you can't even get error handling right and consistent, what claim do you have to consistency? At least in java it's pretty much all exceptions. The math library, as mentioned above, is pretty darn iffy. The existence of both 'path' and 'filepath' is possibly a mistake. The 'heap' and 'list' in collections both seem like they should be similar, but 'heap' operates on a thing that fulfills its interface and list operates directly on arbitrary objects without some interface needed. Due to the lack of 'protected', the std library is littered with exported fields you shouldn't use (e.g. gob.CommonType and template.Template.*parse.Tree and so on). Sure, the library is consistent in many places because the language is so small there's little else it can do but be consistent, but the fact that it falls flat in error handling and has visible warts makes me feel that it's a very broad std library, but far less consistent than, say, Rust's (where everything returns consistent Optional error types) or Java's or Smalltalks. Sure, it's more consistent than the clusterfuck that is ruby and/or python or javascript or (heaven forbid) c/c++, but by no means is being better than any of those an achievement in this category.

apenguin 11y ago
Sorry, but I can't find what you're referencing with the "as mentioned above" on math; could you clarify? My biggest problem with the math library was, IIRC, everything only takes float64s, which makes dealing with any of the other number types more difficult than it should be (I shouldn't need to cast an int to a float and back in order to get the max of two numbers).
chimeracoder 11y ago
> Returned error values are sometimes errors.New (e.g. io.EOF) and sometimes random fmt.Errorf strings that couldn't possibly be handled (e.g. all of tls.go basically), sometimes actual structs (e.g. PathError), This is the advantage of having errors be interfaces rather than concrete values. Once you learn how to use it, it's a strength. The usage of structs that satisfy the interface (as in PathError) is clearly documented and completely predictable. If your concern is that a certain package could use a struct satisfying the interface and does not, well, one advantage of errors as interfaces is that you could propose this change without breaking the backwards compatibility guarantee. It's really important to keep in mind that errors are adopted from error values in C, which means that their idioms and usage is inspired by that rather than by exception handling. Many new Go programmers (including me, when I started) were more familiar with exception handling in higher-level languages than error handling in idiomatic C, so it does take some getting used to. > and sometimes panics. Do you have any examples of the standard library using panics to signal handle-able errors (not counting cases in which the panic is recovered at the top-level in the library and never visible to the caller)? > The math library, as mentioned above, is pretty darn iffy. The only complaint I have had about package "math" is that all operations are defined on float64s, which can be annoying, but is far better than any alternative. That's an annoyance, but it's certainly not an inconsistency in the library. Do you have any other examples of inconsistencies in the math package?
- lclarkmichalek 11y ago
  $ curl http://golang.org/pkg/reflect/ | grep panic | wc -l 79

nevergo 11y ago

Go has the poorest std lib I've ever seen.

andrewchambers 11y ago
Compared with? My reference point is python,java,clojure,c,c++. Python is huge and useful but messy and inconsistent. Java is huge and doesn't compose well. Clojure is underdocmented and hardly batteries included. C and C++ can't do anything useful without a bunch of extra libraries. From what I can see, C# is like java in this regard. Go is a small incredibly useful and composable set of libraries that handles a vast amount of cases with a small amount of code.
- okal 11y ago
  I had the same feeling about Clojure, but it mostly has to do with non-standard libs. It's forced me to rely on reading source code a lot more than I did in other languages, so I'm not entirely sure that's a mark against it. I'm curious why you think that about Python, though. Care to illustrate?
- nevergo 11y ago
  Just poor, don't make me laugh.