4 ms·

If you want an opposing opinion, check out Python. I haven't seen anyone use urllib in the stdlib in like a decade. Putting things like that in the stdlib make

If you want an opposing opinion, check out Python. I haven't seen anyone use urllib in the stdlib in like a decade. Putting things like that in the stdlib makes them subject to the same API stability constraints as stuff like the threading API. They tend to ossify and get abandoned when a 3rd party lib makes a faster, or better, or just more convenient API. Go has a fair bit of this. I haven't touched the stdlib logger in forever. The HTTP server side is kinda meh, the client side is okay but not fantastic. I am a fan of Go's experimental packages. I kind of wish things could live there permanently as "things the core devs believe are a good implementation, but don't want to bind stability guarantees to the language".

traceroute66 3y ago
> If you want an opposing opinion, check out Python. I would argue that Go is a fair comparison, Python is not. Python is just a mess of a language, dependency hell etc. > Go has a fair bit of this. I haven't touched the stdlib logger in forever. You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib.
- everforward 3y ago
  > You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib. I do, it's just twice as slow as the old stdlib logger, which was already twice as slow as 3rd party loggers, and it makes like 8x as many allocs as zap. If I were going to change my logger, it would be to zerolog, not slog. > Python is just a mess of a language, dependency hell etc. We're talking about stdlib though, which are the only packages dependency hell doesn't apply to. > I would argue that Go is a fair comparison, Python is not. Go is the youngest of the major languages, making it one of the worst place to check if you want to see how packages age in the stdlib. Look at a language that's actually old if you want to see the kind of problems old apps face. It also has a weird place, language-wise, because its developed by Google who has an unusual amount of influence over developer patterns. Other languages have to follow devs to where they are, Go can kind of lead the way via Google.

traceroute66 3y ago

> If you want an opposing opinion, check out Python. I would argue that Go is a fair comparison, Python is not. Python is just a mess of a language, dependency hell etc. > Go has a fair bit of this. I haven't touched the stdlib logger in forever. You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib.

everforward 3y ago
> You do realise Go has log/slog in stdlib now ? So structured logging is now in stdlib. I do, it's just twice as slow as the old stdlib logger, which was already twice as slow as 3rd party loggers, and it makes like 8x as many allocs as zap. If I were going to change my logger, it would be to zerolog, not slog. > Python is just a mess of a language, dependency hell etc. We're talking about stdlib though, which are the only packages dependency hell doesn't apply to. > I would argue that Go is a fair comparison, Python is not. Go is the youngest of the major languages, making it one of the worst place to check if you want to see how packages age in the stdlib. Look at a language that's actually old if you want to see the kind of problems old apps face. It also has a weird place, language-wise, because its developed by Google who has an unusual amount of influence over developer patterns. Other languages have to follow devs to where they are, Go can kind of lead the way via Google.