workgroup
simple-tg-forms
| workgroup | simple-tg-forms | |
|---|---|---|
| 7 | 1 | |
| 47 | 1 | |
| - | - | |
| 0.0 | 1.9 | |
| 10 months ago | about 1 year ago | |
| Go | Go | |
| MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
workgroup
-
Gworker, the most easily configurable Generic worker pool implementation
I still think my worker pool is the best: https://github.com/carlmjohnson/workgroup
- A lot of boilerplate code when writing asynchronous code in go
- Workgroup: An easy to use concurrent task manager
-
Implementing Thread/Worker pool using Go generics
I have one that I’ve been using for a while and just updated to use Go 1.20 multierrors: https://github.com/carlmjohnson/workgroup
-
How idiomatic is this?
Read https://blog.carlmjohnson.net/post/share-memory-by-communicating/ and look at the code in https://github.com/carlmjohnson/workgroup for reference.
-
How are YOU using generics so far?
So far, just refactoring. I made a concurrency manager to simplify some stuff, and unified some pagination code. It’s like we said before generics: there are places you miss it, but not having it was never a total blocker. I think going working the x/slices x/maps packages will be the biggest time savers.
-
Go, Generics, and Concurrency
Yeah, I wrote my own generic concurrency thing, and it has two functions. There's a high level Process(nWorkers, task, manager, initial) and a lower level Start(nWorkers, task) (in chan<- Input, out <-chan Result[Input, Output]). The high level function is built off of the low level one and just queues jobs for the task workers by giving job results to the manager to see if it produces any more work. Context isn't involved in either because the idea is that the tasks should have their own internal contexts. You don't want to cancel the task runner, you want to cancel the tasks!
simple-tg-forms
-
A lot of boilerplate code when writing asynchronous code in go
Hello! I have a little go project I'm working on right now. I deploy it to google cloud functions, just because I found it fun not to have any infrastructure. But I realized soon that I want my bot to answer as fast as possible. The first thing that came to my mind is to make all functions that make database and network calls asynchronous. I found somewhere that gophers use something like this:
What are some alternatives?
warg - Declarative and Intuitive Command Line Apps with Go
next-pwa - Zero config PWA plugin for Next.js, with workbox 🧰 with appDir support
watchman - AML/CTF/KYC/OFAC Search of global watchlist and sanctions
golpo - Social network using react and express (old version of the current golpo.dedsec.life)
elegalio-template - Responsive and modern website template, made with React.
BetterMeet - An open community platform
fokus - react web app to help you become more productive :fire: and efficient with time:star2:
golang-generics-dao-example - Example using Generics with DAO
tinykv - tiny in-memory single-app kv (cache) with explicit and sliding expiration
PeopleConnect - A Social Media Web application made using the Django rest framework (for API endpoints) and reactjs where users can chat in real-time(using channels and signals), post their updates, like, comment and view other users’ posts & profiles, search users & follow-unfollow them and get notified about activities on their profile.
gworker - Easily configurable Generic worker pools for Go