Add an `examples` folder with richer examples

[camdencheek]

There are a lot of use cases that aren't covered in the README. It would be nice to have a runnable "examples" folder that includes a bunch of common recipes.

[zhongdai]

I felt reading the test case code is a way of learning the examples, and they are guaranteed runnable 😄

[camdencheek]

Test cases are definitely good examples! As are example tests. What I was thinking here was more "real-world" examples and recipes. Basically, common use cases and documentation for how you would solve them, maybe with some commentary on the tradeoffs between different options. Tests are sometimes difficult to wade through to find the ones that are actually good examples of how the library should be used vs how the library should behave.

[ibilalkayy]

Hey @camdencheek What do you mean by Adding an examples folder with richer examples? I am new here and I need guidance in order to solve this issue and other ones also.

[camdencheek]

Hi @ibilalkayy, thanks for reaching out!

The goal of this task is to create a set of runnable examples of how conc might be used in practice. The README examples are nice, but they aren't runnable, so they can't be tested easily. The examples in the tests are pretty bare bones, and are not representative of real-world use cases. Ideally, these should be copy/pasteable to get people started with the library quickly.

There are other packages that do this really well that you could use as a model.

For some inspiration, you can take a look at how Sourcegraph uses conc

[ibilalkayy]

@camdencheek, I think I should understand what conc really does and then I can set runnable examples. Can you show me some use cases because just saying that conc is your toolbelt for structured concurrency in go, making common tasks easier and safer. it is not understandable for beginners.

I am sorry I jumped into the issues without using source graphs and understanding conc. If you can help me, I will be happy to send my PR to the source graph.

Thank you!

[camdencheek]

@ibilalkayy, conc is targeted at an audience who is familiar with concurrency in go. The README can't really be approachable for beginners because they are unlikely to have faced the problems that conc addresses.

Can you show me some use cases

The link I posted above shows all the places we use conc at Sourcegraph (the company I work for). I'd recommend reading through some of those examples and try to understand what they are doing, then using those same patterns as a template for building some examples that do similar things.

[shuqingzai]

Maybe add Go Playground to README.md and add more usage examples

[gaby]

Any updates on this? Some good ideas:

• Using conc to gather results from multiple net/http calls
• Monitor and process files in a directory concurrently

[ip-rw]

@camdencheek: While there seems to be a view that in use cases where you're likely to be IO bound (say, C10k problem as a client) spawning a few extra goroutines has a negligible overhead, I always seem return to simple workers fed by channels, as opposed to firing off a new, short lived, goroutine for each item to be processed. Do these funky new features come at much of a cost? Example use case might be making a lot of concurrent HTTP requests (HTTP/1.1, each to different servers, some of which may misbehave), so the majority of the time things will be in park, and waiting for the network to come back with something. This was a silly question,

Really lovely looking library, going to try it right now.

@camdencheek, I think I should understand what conc really does and then I can set runnable examples. Can you show me some use cases because just saying that conc is your toolbelt for structured concurrency in go, making common tasks easier and safer. it is not understandable for beginners.

I am sorry I jumped into the issues without using source graphs and understanding conc. If you can help me, I will be happy to send my PR to the source graph.

Premature optimization is an absolute killer, it starts out innocently enough but left unchecked it will destroy your productivity and confidence. Also fancy abstractions like this are great (and I'm surprised this slipped past me, excited use them) but not learning how things actually work under the hood is another pitfall, one that actually held me back for years.

Any updates on this? Some good ideas:

• Using conc to gather results from multiple net/http calls
• Monitor and process files in a directory concurrently

Beyond the scope of this project, this is about avoiding some of the more pernicious bugs that aren't already easy to debug and cleaner code (I suspect). You're going to be writing more or less exactly the same code.