Repository navigation
Add an examples folder with richer examples #80
Description
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.
Reacted by Lucareful, prizrak2033, William, overbeck, Tanel Lebedev and Théo Crevon
Reacted by tsingson, CharlesCheung996, overbeck and Théo Crevon
Activity
[-]Add a runnable `examples` folder[/-]zhongdai commentedon Feb 21, 2023
I felt reading the test case code is a way of learning the examples, and they are guaranteed runnable 😄
camdencheek commentedon Feb 24, 2023
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 commentedon Feb 25, 2023
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 commentedon Feb 26, 2023
Hi @ibilalkayy, thanks for reaching out!
The goal of this task is to create a set of runnable examples of how
concmight 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
concibilalkayy commentedon Feb 26, 2023
@camdencheek, I think I should understand what
concreally does and then I can set runnable examples. Can you show me some use cases because just saying thatconcis 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 commentedon Feb 27, 2023
@ibilalkayy,
concis 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 thatconcaddresses.The link I posted above shows all the places we use
concat 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 commentedon Apr 26, 2023
Maybe add Go Playground to README.md and add more usage examples
gaby commentedon May 26, 2023
Any updates on this? Some good ideas:
ip-rw commentedon Jan 13, 2024
@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.
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.
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.