5 ms·

The fact that requests has "languished" (not sure how tbh) doesn't really change the fact that the Python stdlib is a bit of a hilarious disaster from afar. Ton

The fact that requests has "languished" (not sure how tbh) doesn't really change the fact that the Python stdlib is a bit of a hilarious disaster from afar. Tons of cases of "that shouldn't be in std" where libraries have quirky, locked in behaviors, or an entire major breaking release with decades of work to migrate has to be made to clean up the mistakes. Python should be a case study in the many ways not to build a language. > By contrast Go ships with a high quality standard HTTP library that has lasted a decade and no “requests” equivalent has risen up to challenge it. Yeah this also means that you need to update your compiler when there's a vulnerability instead of just a single point release in a library. This happens with some frequency. The parent poster is right, in my opinion.

cube2222 5y ago
> Yeah this also means that you need to update your compiler when there's a vulnerability instead of just a single point release in a library. Has updating the Go compiler actually been an issue for you in the past? To me, with Go's stability, it's never been more disruptive than updating a library in practice, so I don't see much of a difference.
- staticassertion 5y ago
  I don't know that I'd hate it if I were a go dev, it would just be a bit annoying for a number of reasons. For one thing I update libraries all the time so it's a very fast, simple, well worn operation. Updating the compiler is a bit more of a chore and I'm going to worry a bit more about the impact (since it's global to all code vs local to one package). For another, I would want to make sure I had tooling that could tell me "is this library in use by service X". I don't know Go's story there, but I would hope it's trivial to do so for a library but I suspect if it's part of the standard library that may be trickier. If not, nbd. It's a bad smell to me, but if I were a Go developer it wouldn't break me. Perhaps ironically, until this native fuzzing package, upgrading the compiler if you had fuzz tests would be one case where things would likely break.
  - throwaway894345 5y ago
    > Updating the compiler is a bit more of a chore and I'm going to worry a bit more about the impact (since it's global to all code vs local to one package). This is indeed a chore in other languages. In Go, the compiler is trivially installed. Typically this just means bumping the version in your Dockerfile and “gvm use $newVersion —default”. > For another, I would want to make sure I had tooling that could tell me "is this library in use by service X". I don't know Go's story there, but I would hope it's trivial to do so for a library but I suspect if it's part of the standard library that may be trickier. If not, nbd. This is supported out of the box by Go’s tooling. `go mod graph` is what you’re looking for.
    - staticassertion 5y ago
      > This is indeed a chore in other languages. In Go, the compiler is trivially installed. Typically this just means bumping the version in your Dockerfile and “gvm use $newVersion —default”. The issue isn't with installing the new compiler, that's trivial in our use case as well (for Rust at least, Python's a disaster, but I accept that). The issue is ensuring compatibility, ensuring no new bugs are introduced, etc. It's just a much heavier change to your produced binary vs changing a package. > This is supported out of the box by Go’s tooling. `go mod graph` is what you’re looking for. Cool, thanks.
- TheDong 5y ago
  > Has updating the Go compiler actually been an issue for you in the past? To me, with Go's stability, it's never been more disruptive than updating a library in practice I've run into issues with several go version updates. Off the top of my head, all of the following caused breakages: 1. go 1.4 making directories named 'internal' special and un-importable. Cross-package imports that used to work no longer would compile with a compiler error. 2. go 1.9 adding monotonic clock readings in a breaking way, i.e. this program changed output from 1.8 to 1.9: https://go.dev/play/p/Mi6cGCPd0rS https://go.dev/play/p/Mi6cGCPd0rS (I know it looks contrived, but I'm not digging up the actual code that broke) 3. The change of the http.Server default to serving http2 instead of http/1.1 broke stuff. Of course it did. How can that possibly _not_ break stuff? 4. The changes in 'GO111MODULE' defaults broke many imports which had either malformed or incorrect go.mod files. This one was quite painful for the whole ecosystem. 5. go1.17 switched to silently truncating a lot of query strings. Of course that broke stuff, how could it not? https://go.dev/play/p/azODBvkb-zK https://go.dev/play/p/azODBvkb-zK Those are all intentional breaking changes which were not fixed upstream (i.e. are "working as intended"). The unintentional breaking changes, from changing error messages to cause string-based error detection to fail (because so many stdlib errors aren't exported so you have to do string matching), to just plain dumb bugs in the stdlib.... those are vastly more common. Those usually do get fixed in point releases. Take a gander at those release notes, many of the issues highlighted in those changelogs come from pain people hit during upgrades. I think the majority of go version upgrades have had some amount of pain, and most of them have been far more disruptive than updating a well-built library. I would much rather update just my fuzz-testing library in a commit, and be confident that it's only used in tests so CI is good enough to validate it, than have to update that and my http package and my tls package and my os package all at once and have to look for bugs _everywhere_.
  - cube2222 5y ago
    I admit I wasn't bit by these changes and had a much better experience overall. Thank you for the long write-up. However, I think you only mentioned changes in major releases, whereas in this scenario (vulnerability fix) a minor release would suffice (the parent mentioned updating to a point release of a library). Did you also have issues with minor releases?
- rat9988 5y ago
  It is for me, I can't just go build in the new version. So i'm keeping the software with the old compiler.
throwaway894345 5y ago
> The fact that requests has "languished" (not sure how tbh) doesn't really change the fact that the Python stdlib is a bit of a hilarious disaster from afar. Agreed that the Python stdlib is a disaster, but my point was that the OP contradicts himself by arguing that stability guarantees hold the standard library back while pointing to requests which itself hasn’t made many/any intrepid breaking changes or even sensible non-breaking changes a la async support. Note that “stability is bad” is the OP’s point of view and not mine. > Tons of cases of "that shouldn't be in std" where libraries have quirky, locked in behaviors, or an entire major breaking release with decades of work to migrate has to be made to clean up the mistakes. But the parent pointed to the requests library which is not in the stdlib. Note also that Go has been around for a decade and has needed no such major migration initiative. > Yeah this also means that you need to update your compiler when there's a vulnerability instead of just a single point release in a library. This happens with some frequency. The frequency is very low and updating the compiler is minimally risky due to Go’s strong compatibility guarantees (precisely the kind of stability the parent opposes). This is a much lesser problem than dependency management in Python (I have 15 years of experience in Python and 10 in Go).
- makapuf 5y ago
  Note that Python was already almost two decades when v3 got out and is now three decades old.
  - throwaway894345 5y ago
    Python 2 was not 2 decades old, and anyway the writing was on the wall many years before Python 3 was released (these things don’t happen over night after all).
SEJeff 5y ago
Just look at the implementation of namedtuple. It is an utter abomination from an implementation perspective. I’d take a junior developer who sent a code review with that out back and politely beat some sense into them.

cube2222 5y ago

> Yeah this also means that you need to update your compiler when there's a vulnerability instead of just a single point release in a library. Has updating the Go compiler actually been an issue for you in the past? To me, with Go's stability, it's never been more disruptive than updating a library in practice, so I don't see much of a difference.

staticassertion 5y ago
I don't know that I'd hate it if I were a go dev, it would just be a bit annoying for a number of reasons. For one thing I update libraries all the time so it's a very fast, simple, well worn operation. Updating the compiler is a bit more of a chore and I'm going to worry a bit more about the impact (since it's global to all code vs local to one package). For another, I would want to make sure I had tooling that could tell me "is this library in use by service X". I don't know Go's story there, but I would hope it's trivial to do so for a library but I suspect if it's part of the standard library that may be trickier. If not, nbd. It's a bad smell to me, but if I were a Go developer it wouldn't break me. Perhaps ironically, until this native fuzzing package, upgrading the compiler if you had fuzz tests would be one case where things would likely break.
- throwaway894345 5y ago
  > Updating the compiler is a bit more of a chore and I'm going to worry a bit more about the impact (since it's global to all code vs local to one package). This is indeed a chore in other languages. In Go, the compiler is trivially installed. Typically this just means bumping the version in your Dockerfile and “gvm use $newVersion —default”. > For another, I would want to make sure I had tooling that could tell me "is this library in use by service X". I don't know Go's story there, but I would hope it's trivial to do so for a library but I suspect if it's part of the standard library that may be trickier. If not, nbd. This is supported out of the box by Go’s tooling. `go mod graph` is what you’re looking for.
  - staticassertion 5y ago
    > This is indeed a chore in other languages. In Go, the compiler is trivially installed. Typically this just means bumping the version in your Dockerfile and “gvm use $newVersion —default”. The issue isn't with installing the new compiler, that's trivial in our use case as well (for Rust at least, Python's a disaster, but I accept that). The issue is ensuring compatibility, ensuring no new bugs are introduced, etc. It's just a much heavier change to your produced binary vs changing a package. > This is supported out of the box by Go’s tooling. `go mod graph` is what you’re looking for. Cool, thanks.
TheDong 5y ago
> Has updating the Go compiler actually been an issue for you in the past? To me, with Go's stability, it's never been more disruptive than updating a library in practice I've run into issues with several go version updates. Off the top of my head, all of the following caused breakages: 1. go 1.4 making directories named 'internal' special and un-importable. Cross-package imports that used to work no longer would compile with a compiler error. 2. go 1.9 adding monotonic clock readings in a breaking way, i.e. this program changed output from 1.8 to 1.9: https://go.dev/play/p/Mi6cGCPd0rS https://go.dev/play/p/Mi6cGCPd0rS (I know it looks contrived, but I'm not digging up the actual code that broke) 3. The change of the http.Server default to serving http2 instead of http/1.1 broke stuff. Of course it did. How can that possibly _not_ break stuff? 4. The changes in 'GO111MODULE' defaults broke many imports which had either malformed or incorrect go.mod files. This one was quite painful for the whole ecosystem. 5. go1.17 switched to silently truncating a lot of query strings. Of course that broke stuff, how could it not? https://go.dev/play/p/azODBvkb-zK https://go.dev/play/p/azODBvkb-zK Those are all intentional breaking changes which were not fixed upstream (i.e. are "working as intended"). The unintentional breaking changes, from changing error messages to cause string-based error detection to fail (because so many stdlib errors aren't exported so you have to do string matching), to just plain dumb bugs in the stdlib.... those are vastly more common. Those usually do get fixed in point releases. Take a gander at those release notes, many of the issues highlighted in those changelogs come from pain people hit during upgrades. I think the majority of go version upgrades have had some amount of pain, and most of them have been far more disruptive than updating a well-built library. I would much rather update just my fuzz-testing library in a commit, and be confident that it's only used in tests so CI is good enough to validate it, than have to update that and my http package and my tls package and my os package all at once and have to look for bugs _everywhere_.
- cube2222 5y ago
  I admit I wasn't bit by these changes and had a much better experience overall. Thank you for the long write-up. However, I think you only mentioned changes in major releases, whereas in this scenario (vulnerability fix) a minor release would suffice (the parent mentioned updating to a point release of a library). Did you also have issues with minor releases?
rat9988 5y ago
It is for me, I can't just go build in the new version. So i'm keeping the software with the old compiler.

throwaway894345 5y ago

> The fact that requests has "languished" (not sure how tbh) doesn't really change the fact that the Python stdlib is a bit of a hilarious disaster from afar. Agreed that the Python stdlib is a disaster, but my point was that the OP contradicts himself by arguing that stability guarantees hold the standard library back while pointing to requests which itself hasn’t made many/any intrepid breaking changes or even sensible non-breaking changes a la async support. Note that “stability is bad” is the OP’s point of view and not mine. > Tons of cases of "that shouldn't be in std" where libraries have quirky, locked in behaviors, or an entire major breaking release with decades of work to migrate has to be made to clean up the mistakes. But the parent pointed to the requests library which is not in the stdlib. Note also that Go has been around for a decade and has needed no such major migration initiative. > Yeah this also means that you need to update your compiler when there's a vulnerability instead of just a single point release in a library. This happens with some frequency. The frequency is very low and updating the compiler is minimally risky due to Go’s strong compatibility guarantees (precisely the kind of stability the parent opposes). This is a much lesser problem than dependency management in Python (I have 15 years of experience in Python and 10 in Go).

makapuf 5y ago
Note that Python was already almost two decades when v3 got out and is now three decades old.
- throwaway894345 5y ago
  Python 2 was not 2 decades old, and anyway the writing was on the wall many years before Python 3 was released (these things don’t happen over night after all).

SEJeff 5y ago

Just look at the implementation of namedtuple. It is an utter abomination from an implementation perspective. I’d take a junior developer who sent a code review with that out back and politely beat some sense into them.