4 ms·

Odd, I find the standard library very full-fledged and useful, including the strings package. I've almost never needed to reverse a string, except in interviews

Odd, I find the standard library very full-fledged and useful, including the strings package. I've almost never needed to reverse a string, except in interviews. :-) The stdlib has a full (and good) HTTP server with HTTP/2 and TLS support, HTML templating, excellent I/O support, compression, even image encoding/decoding and drawing. That said, the container types are pretty sparse, but that may change a bit now that generics are here. What, apart from string reverse, do you miss for real projects?

sam0x17 4y ago
The fact that it's a bunch of top level functions also makes me think of PHP from the early 00s, only I was able to do more with things then tbh. Just feels super archaic.
sam0x17 4y ago
The main thing that irked me though is I had to spend a whole day doing a simple "take this complex object and use it as a hash key" in an idiomatic way other than just cheating and using the stringified version of the object as the key.
TheDong 4y ago
Not that person, but I'll call out a few issues I've had with the go stdlib: First, it has a lot of useless packages you typically wouldn't use, like "log" and "flag" (which work, but are way worse than third party alternatives like logrus and pflag), but also like "syscall" (as it says 'deprecated, use 'golang.org/x/sys' instead), "image/draw" (nope, you wanted 'golang.org/x/image/draw' usually), "path" for working with paths (you wanted "filepath"), "net/rpc" and "rpc/jsonrpc", "plugin" (almost always a bad idea), a chunk of "strings" (use "golang.org/x/text" for proper unicode support) and so on. Some of those are marked deprecated, most of them are not, and are just waiting for someone to accidentally use them. That's issues I have with the stdlib and not stuff I'm missing though... Though I guess I really do miss a good logging library, or at least interface for external packages to implement so I can plug in logging libraries without rewriting the world. One thing I do find missing frequently is a reasonable set type with the ability to do things like basic set operations (intersect, diff, etc). I constantly have to write ad-hoc for loops in go to do set operations, and it's verbose, non-obvious what the code does, and easy to get wrong. But honestly, the main thing I'm missing isn't actually a package, but more about error handling for the stdlib as a whole, which is more a language issue. I really wish I could know what possible errors stdlib functions returned without, fairly often, having to read huge chunks of stdlib code to determine that. Perhaps 40% of the stdlib documents the error type it returns in a message (like 'os.Chdir' always returns '*os.PathError'), but for the rest, good luck. Want to figure out what errors you might have to check for 'tar.Writer.Close()'? Well, the docs says "returns an error", the interface is "error", you have to read hundreds of lines of code to figure out the possible concrete types it could be. Maybe 15% of the time, you end up having to string-match on error messages because the error var or type is unexported.
- morelisp 4y ago
  > interface for external packages to implement so I can plug in logging libraries without rewriting the world. Well, it's structural, so you don't need other packages to implement an interface rather you need them to accept an interface. That also makes it clear it's a bigger ask - you're not asking a dependency "please also do X" but instead asking "please never need to more than Y". > Want to figure out what errors you might have to check for 'tar.Writer.Close()'? Well, the docs says "returns an error", the interface is "error", you have to read hundreds of lines of code to figure out the possible concrete types it could be. The concrete types it could be are unbounded, because `tar.Writer` wraps arbitrary `io.Writer`s. If you need multi-pathed error handling (usually people don't and are just making it out of habit!), worry about what things can do, not what they are.
  - TheDong 4y ago
    > If you need multi-pathed error handling (usually people don't and are just making it out of habit!), worry about what things can do, not what they are. When I'm looking at an error, it's typically for one of two reasons: 1. To set a correct status code, such as http 5xx (internal server error, our disk flaked) or a 4xx (user error, you gave us invalid input). 2. To provide a better error message, such as to localize it into an error string. If you're building CLI tools for yourself, sure, every error is fatal and you can read english so you don't need either of those. For most go projects, both of those are relevant concerns for a large number of error paths. Go's type-system does not help you at all. Speaking of... > Well, it's structural, so you don't need other packages to implement an interface rather you need them to accept an interface. That also makes it clear it's a bigger ask - you're not asking a dependency "please also do X" but instead asking "please never need to more than Y". Yup. That is a big problem. That's the root of the error problem too, where every package returns the stdlib error interface, which is a tiny subset of what you usually want.
    - morelisp 4y ago
      > To set a correct status code, such as http 5xx (internal server error, our disk flaked) or a 4xx (user error, you gave us invalid input). For this it's simple to wrap them at return site in something that offers `HTTPStatus() int` and check for implementing that interface, not any concrete types, in your handler. Also, those error paths should be dangerously hard to mix in the first place, you shouldn't be letting invalid input anywhere near the disk to begin with. Re. logging interfaces, I think you've missed the point. You want everyone to accept narrow interfaces so you can use the logger you want. You also want everyone to return wide error interfaces so you can categorize the entire universe of possible errors as you want. In the end this isn't a technical problem, it's an "I want everyone to cater for my use case" problem.

sam0x17 4y ago

The fact that it's a bunch of top level functions also makes me think of PHP from the early 00s, only I was able to do more with things then tbh. Just feels super archaic.

sam0x17 4y ago

The main thing that irked me though is I had to spend a whole day doing a simple "take this complex object and use it as a hash key" in an idiomatic way other than just cheating and using the stringified version of the object as the key.

TheDong 4y ago

Not that person, but I'll call out a few issues I've had with the go stdlib: First, it has a lot of useless packages you typically wouldn't use, like "log" and "flag" (which work, but are way worse than third party alternatives like logrus and pflag), but also like "syscall" (as it says 'deprecated, use 'golang.org/x/sys' instead), "image/draw" (nope, you wanted 'golang.org/x/image/draw' usually), "path" for working with paths (you wanted "filepath"), "net/rpc" and "rpc/jsonrpc", "plugin" (almost always a bad idea), a chunk of "strings" (use "golang.org/x/text" for proper unicode support) and so on. Some of those are marked deprecated, most of them are not, and are just waiting for someone to accidentally use them. That's issues I have with the stdlib and not stuff I'm missing though... Though I guess I really do miss a good logging library, or at least interface for external packages to implement so I can plug in logging libraries without rewriting the world. One thing I do find missing frequently is a reasonable set type with the ability to do things like basic set operations (intersect, diff, etc). I constantly have to write ad-hoc for loops in go to do set operations, and it's verbose, non-obvious what the code does, and easy to get wrong. But honestly, the main thing I'm missing isn't actually a package, but more about error handling for the stdlib as a whole, which is more a language issue. I really wish I could know what possible errors stdlib functions returned without, fairly often, having to read huge chunks of stdlib code to determine that. Perhaps 40% of the stdlib documents the error type it returns in a message (like 'os.Chdir' always returns '*os.PathError'), but for the rest, good luck. Want to figure out what errors you might have to check for 'tar.Writer.Close()'? Well, the docs says "returns an error", the interface is "error", you have to read hundreds of lines of code to figure out the possible concrete types it could be. Maybe 15% of the time, you end up having to string-match on error messages because the error var or type is unexported.

morelisp 4y ago
> interface for external packages to implement so I can plug in logging libraries without rewriting the world. Well, it's structural, so you don't need other packages to implement an interface rather you need them to accept an interface. That also makes it clear it's a bigger ask - you're not asking a dependency "please also do X" but instead asking "please never need to more than Y". > Want to figure out what errors you might have to check for 'tar.Writer.Close()'? Well, the docs says "returns an error", the interface is "error", you have to read hundreds of lines of code to figure out the possible concrete types it could be. The concrete types it could be are unbounded, because `tar.Writer` wraps arbitrary `io.Writer`s. If you need multi-pathed error handling (usually people don't and are just making it out of habit!), worry about what things can do, not what they are.
- TheDong 4y ago
  > If you need multi-pathed error handling (usually people don't and are just making it out of habit!), worry about what things can do, not what they are. When I'm looking at an error, it's typically for one of two reasons: 1. To set a correct status code, such as http 5xx (internal server error, our disk flaked) or a 4xx (user error, you gave us invalid input). 2. To provide a better error message, such as to localize it into an error string. If you're building CLI tools for yourself, sure, every error is fatal and you can read english so you don't need either of those. For most go projects, both of those are relevant concerns for a large number of error paths. Go's type-system does not help you at all. Speaking of... > Well, it's structural, so you don't need other packages to implement an interface rather you need them to accept an interface. That also makes it clear it's a bigger ask - you're not asking a dependency "please also do X" but instead asking "please never need to more than Y". Yup. That is a big problem. That's the root of the error problem too, where every package returns the stdlib error interface, which is a tiny subset of what you usually want.
  - morelisp 4y ago
    > To set a correct status code, such as http 5xx (internal server error, our disk flaked) or a 4xx (user error, you gave us invalid input). For this it's simple to wrap them at return site in something that offers `HTTPStatus() int` and check for implementing that interface, not any concrete types, in your handler. Also, those error paths should be dangerously hard to mix in the first place, you shouldn't be letting invalid input anywhere near the disk to begin with. Re. logging interfaces, I think you've missed the point. You want everyone to accept narrow interfaces so you can use the logger you want. You also want everyone to return wide error interfaces so you can categorize the entire universe of possible errors as you want. In the end this isn't a technical problem, it's an "I want everyone to cater for my use case" problem.