5 ms·

I will never understand why this has been included in the standard library instead of as a standalone library available for download. Now it's locked to the Go

I will never understand why this has been included in the standard library instead of as a standalone library available for download. Now it's locked to the Go release cycle and have the potential to languish because of backward compatibility concerns. The decision to include it is perplexing when other language ecosystems have chosen to keep this kind of functionality out of the standard lib, e.g. requests in python[1]. To quote Kenneth Reitz: "...the standard library is where a library goes to die." [1] https://github.com/psf/requests/issues/2424 https://github.com/psf/requests/issues/2424

dainiusse 5y ago
I think it is great in general. OTOH - nobody prohibits to use any third party library whoever wants to. Third party libraries also die like - https://github.com/go-check/check https://github.com/go-check/check
Scaevolus 5y ago
Python had an 18 month release cycle for most of its life (now 12 month), while Go has a 6 month release cycle. Many Python devs use the OS packaged Python versions, while Go devs tend to use the latest release. Integrating this in the stdlib means that more people will use basic fuzzing functionality. There's nothing preventing third party fuzzers from continuing to develop.
smasher164 5y ago
The Go fuzzing tool takes advantage of compiler instrumentation. It can also work with built-in Go types, in comparison to traditional fuzzing tools that just work with bytes. Additionally, integrating it into the testing tool allows it to be as easy to write as a unit test. This can help provide a batteries-included fuzzing experience.
- staticassertion 5y ago
  This is just a work around for: a) A lack of strong typing b) A custom compiler toolchain llvm already has instrumentation/ coverage support and generics make it easy to work with higher level constructs than bytes, although you generally do want to just work with bytes when fuzzing imo. The language is weak, therefor the language has to add more and more batteries-included because extending it is purposefully difficult.
  - masklinn 5y ago
    > This is just a work around for: > [...] > llvm already has instrumentation/ coverage support I mean, that supports the idea of having fuzzing support in whatever core you have.
    - staticassertion 5y ago
      My point is that between Go's custom compiler backend and inexpressive typing there's much more need to build things like this in directly vs what other languages can do by just using llvm/gcc. Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves, although that won't have the same issue with inexpressive types.
      - aleksi 5y ago
        > Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves Go uses LLVM’s ThreadSanitizer since 1.1.
        staticassertion 5y ago
        I don't think that really addresses my point, it just shows that they did the work for one sanitizer already.
  - smasher164 5y ago
    > llvm already has instrumentation The Go toolchain actually supports emitting instrumentation for LLVM's libFuzzer with -gcflags=all=-d=libfuzzer. > therefor the language has to add more Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain.
    - staticassertion 5y ago
      > The Go toolchain actually supports emitting instrumentation for LLVM's libFuzzer with -gcflags=all=-d=libfuzzer. Sweet, that's a smart approach. > Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain. I don't care either because I don't write Go, so just the fact that it's supported is nice for me since it encourages this in languages I do care about. But if I were a go developer I might care a lot about how my language evolves, what's built in, what's a library, what the capabilities are, what tools I can integrate with, etc. It sounds like they've done a pretty good job with regards to this implementation though, happy to see it.
- morelisp 5y ago
  > The Go fuzzing tool takes advantage of compiler instrumentation. This is the main benefit. I've been using go-fuzz for years and compiler upgrades (especially any changes related to modules/GOROOT/GOPATH) was a pain because it always behaved slightly differently. > It can also work with built-in Go types, in comparison to traditional fuzzing tools that just work with bytes. This could have been done just as efficiently without upstream integration.
throwaway894345 5y ago
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
masklinn 5y ago
FWIW older design documents have (some) reasoning for integrating fuzzing natively: - https://docs.google.com/document/d/1N-12_6YBPpF9o4_Zys_E_ZQndmD06wQVAM_0y9nZUIE/pub https://docs.google.com/document/d/1N-12_6YBPpF9o4_Zys_E_ZQn... - https://go.googlesource.com/proposal/+/master/design/draft-fuzzing.md https://go.googlesource.com/proposal/+/master/design/draft-f... One of the original proposals (https://docs.google.com/document/u/1/d/1zXR-TFL3BfnceEAWytV8bnzB2Tfp6EPFinWVJ5V4QC8/pub https://docs.google.com/document/u/1/d/1zXR-TFL3BfnceEAWytV8...) further explains why, by apparently go-fuzz maintainers team (per issue 329[0] none of them seems in any way broken-hearted about the idea of deprecating go-fuzz eventually): > go-fuzz suffers from several problems: > - It breaks multiple times per Go release because it's tied to the way go build works, std lib package structure and dependencies, etc. It broke due to internal packages (multiple times), vendoring (multiple times), changed dependencies in std lib, etc. > - It tries to do compiler work regarding coverage instrumentation without compiler help. This leads to build breakages on corner case code; poor performance; suboptimal quality of coverage instrumentation (missed edges). > - Considerable difficulty in integrating it into other build systems and non-standard contexts as it uses source pre-processing. > Goal of this proposal is to make fuzzing as easy to use as unit testing. [0] https://github.com/dvyukov/go-fuzz/issues/329 https://github.com/dvyukov/go-fuzz/issues/329
cube2222 5y ago
Seems fairly standard for Go. You mentioned requests - the Go net/http library is widely used, even though it's in the standard library. It didn't languish, it didn't die. The interfaces are also used in most 3rd party libraries and work well. Moreover, Go's quality standard library is often cited as one of its main strengths. Thus, the inclusion of fuzzing in the stdlib isn't surprising to me. Not saying the other way around would be bad. It's just not surprising, and I don't think it's a bad choice, looking at Go historically.
- pjmlp 5y ago
  You mean the quality of using strings as errors? https://go.dev/blog/go1.13-errors https://go.dev/blog/go1.13-errors
deleted 5y ago
[deleted]
pjmlp 5y ago
Counterpoint, the standard library is available everywhere the language toolchain exists, external dependencies are hit and miss.
_koko_22_p 5y ago
Just because the standard lib of language A is bad doesn't mean every standard lib must be bad. A great standard lib is one of the best things that can happen to a language. The advantages are huge when it comes to maintaining a project. It's just that it's really hard to create and maintain a standard lib properly. The Go team makes once again a remarkable good job here. Other languages might not have the resources or expertice to extend and maintain the language and standard lib as well as they do. Some people argue that there's something inherently bad having a great standard lib, which is of course not true. These arguements seems mainly an excuse for the thin standard lib of their favorite language ...

dainiusse 5y ago

I think it is great in general. OTOH - nobody prohibits to use any third party library whoever wants to. Third party libraries also die like - https://github.com/go-check/check https://github.com/go-check/check

Scaevolus 5y ago

Python had an 18 month release cycle for most of its life (now 12 month), while Go has a 6 month release cycle. Many Python devs use the OS packaged Python versions, while Go devs tend to use the latest release. Integrating this in the stdlib means that more people will use basic fuzzing functionality. There's nothing preventing third party fuzzers from continuing to develop.

smasher164 5y ago

The Go fuzzing tool takes advantage of compiler instrumentation. It can also work with built-in Go types, in comparison to traditional fuzzing tools that just work with bytes. Additionally, integrating it into the testing tool allows it to be as easy to write as a unit test. This can help provide a batteries-included fuzzing experience.

staticassertion 5y ago
This is just a work around for: a) A lack of strong typing b) A custom compiler toolchain llvm already has instrumentation/ coverage support and generics make it easy to work with higher level constructs than bytes, although you generally do want to just work with bytes when fuzzing imo. The language is weak, therefor the language has to add more and more batteries-included because extending it is purposefully difficult.
- masklinn 5y ago
  > This is just a work around for: > [...] > llvm already has instrumentation/ coverage support I mean, that supports the idea of having fuzzing support in whatever core you have.
  - staticassertion 5y ago
    My point is that between Go's custom compiler backend and inexpressive typing there's much more need to build things like this in directly vs what other languages can do by just using llvm/gcc. Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves, although that won't have the same issue with inexpressive types.
    - aleksi 5y ago
      > Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves Go uses LLVM’s ThreadSanitizer since 1.1.
      - staticassertion 5y ago
        I don't think that really addresses my point, it just shows that they did the work for one sanitizer already.
- smasher164 5y ago
  > llvm already has instrumentation The Go toolchain actually supports emitting instrumentation for LLVM's libFuzzer with -gcflags=all=-d=libfuzzer. > therefor the language has to add more Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain.
  - staticassertion 5y ago
    > The Go toolchain actually supports emitting instrumentation for LLVM's libFuzzer with -gcflags=all=-d=libfuzzer. Sweet, that's a smart approach. > Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain. I don't care either because I don't write Go, so just the fact that it's supported is nice for me since it encourages this in languages I do care about. But if I were a go developer I might care a lot about how my language evolves, what's built in, what's a library, what the capabilities are, what tools I can integrate with, etc. It sounds like they've done a pretty good job with regards to this implementation though, happy to see it.
morelisp 5y ago
> The Go fuzzing tool takes advantage of compiler instrumentation. This is the main benefit. I've been using go-fuzz for years and compiler upgrades (especially any changes related to modules/GOROOT/GOPATH) was a pain because it always behaved slightly differently. > It can also work with built-in Go types, in comparison to traditional fuzzing tools that just work with bytes. This could have been done just as efficiently without upstream integration.

throwaway894345 5y ago

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

masklinn 5y ago

FWIW older design documents have (some) reasoning for integrating fuzzing natively: - https://docs.google.com/document/d/1N-12_6YBPpF9o4_Zys_E_ZQndmD06wQVAM_0y9nZUIE/pub https://docs.google.com/document/d/1N-12_6YBPpF9o4_Zys_E_ZQn... - https://go.googlesource.com/proposal/+/master/design/draft-fuzzing.md https://go.googlesource.com/proposal/+/master/design/draft-f... One of the original proposals (https://docs.google.com/document/u/1/d/1zXR-TFL3BfnceEAWytV8bnzB2Tfp6EPFinWVJ5V4QC8/pub https://docs.google.com/document/u/1/d/1zXR-TFL3BfnceEAWytV8...) further explains why, by apparently go-fuzz maintainers team (per issue 329[0] none of them seems in any way broken-hearted about the idea of deprecating go-fuzz eventually): > go-fuzz suffers from several problems: > - It breaks multiple times per Go release because it's tied to the way go build works, std lib package structure and dependencies, etc. It broke due to internal packages (multiple times), vendoring (multiple times), changed dependencies in std lib, etc. > - It tries to do compiler work regarding coverage instrumentation without compiler help. This leads to build breakages on corner case code; poor performance; suboptimal quality of coverage instrumentation (missed edges). > - Considerable difficulty in integrating it into other build systems and non-standard contexts as it uses source pre-processing. > Goal of this proposal is to make fuzzing as easy to use as unit testing. [0] https://github.com/dvyukov/go-fuzz/issues/329 https://github.com/dvyukov/go-fuzz/issues/329

cube2222 5y ago

Seems fairly standard for Go. You mentioned requests - the Go net/http library is widely used, even though it's in the standard library. It didn't languish, it didn't die. The interfaces are also used in most 3rd party libraries and work well. Moreover, Go's quality standard library is often cited as one of its main strengths. Thus, the inclusion of fuzzing in the stdlib isn't surprising to me. Not saying the other way around would be bad. It's just not surprising, and I don't think it's a bad choice, looking at Go historically.

pjmlp 5y ago
You mean the quality of using strings as errors? https://go.dev/blog/go1.13-errors https://go.dev/blog/go1.13-errors

deleted 5y ago

[deleted]

pjmlp 5y ago

Counterpoint, the standard library is available everywhere the language toolchain exists, external dependencies are hit and miss.

_koko_22_p 5y ago

Just because the standard lib of language A is bad doesn't mean every standard lib must be bad. A great standard lib is one of the best things that can happen to a language. The advantages are huge when it comes to maintaining a project. It's just that it's really hard to create and maintain a standard lib properly. The Go team makes once again a remarkable good job here. Other languages might not have the resources or expertice to extend and maintain the language and standard lib as well as they do. Some people argue that there's something inherently bad having a great standard lib, which is of course not true. These arguements seems mainly an excuse for the thin standard lib of their favorite language ...