4 ms·

Maybe, but I wouldn’t support support that argument by holding up Python and its HTTP situation as exemplary. The standard HTTP libraries are a nightmare, reque

Maybe, but I wouldn’t support support that argument by holding up Python and its HTTP situation as exemplary. The standard HTTP libraries are a nightmare, requests proves that Python packages can and will languish even outside of the standard library, and writing even a simple HTTP script in Python means you now need to choose between the standard HTTP libraries or tackle dependency management and multi-file deployment issues. 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. Note also that Go’s testing situation in general is much nicer than many other languages precisely because things are baked into the standard library—no need to quibble over which test framework to use or to memorize each framework’s equivalent for “run tests that match this pattern” and so on.

staticassertion 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. 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.
- 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.
damagednoob 5y ago
> I wouldn’t support support that argument by holding up Python and its HTTP situation as exemplary. I wasn't holding it up as exemplary. I was using it as an example to show how other language ecosystems have reasoned about what gets included in the stdlib. I can't think of another top20 language that ships fuzzing in the stdlib.

staticassertion 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. 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.
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.

damagednoob 5y ago

> I wouldn’t support support that argument by holding up Python and its HTTP situation as exemplary. I wasn't holding it up as exemplary. I was using it as an example to show how other language ecosystems have reasoned about what gets included in the stdlib. I can't think of another top20 language that ships fuzzing in the stdlib.