It's weird that you did not find this video https://www.youtube.com/watch?v=9hDvWVJtljE

Anton is doing an incredible job with his tests at such level, even antirez commented about his performance findings and have informed the dev team to provide possible fixes in Redis 8.

so this gives a good reason between valkey and redis, but what about dragonfly? some benchmarks show crazy advantage over Redis (and I assume valkey too)

switched to Dragonfly and can confirm that the throughput makes a noticeable difference to the user experience

As much as I love watching theprimeagen during leisure time, personally I think he loses control out of sheer enthusiasm and instead of teaching you, which is his original intention, he just shows off with fast typing, shouting like a goofball, and bounces up and down like hyper-caffeinated person which distracts me, let alone to take him seriously.

Just watch this video https://www.youtube.com/watch?v=FknTw9bJsXM which is such an important topic, yet I have very hard time following...I prefer the format of pluralsight and the old lynda.com style of teaching.

one thing to keep in mind is the video you linked is the _walkthrough_ of the course, the actual course itself is probably what you're looking for, because it moves at a much more reasonable pace

Sorry, I couldn't resist; I had to take my chance to comment to this masterpiece in issues, lol!

Bram died 2 years ago (already(!!!), time flies!), so it's not so recently...

Also the community does an incredible job and it's quite active with further development and improvements, especially in improving the Vim9 script engine among many things they work on.

If you don't believe me, just see for yourself https://github.com/vim/vim/commits/master/

Personally I wished they had it backported to previous versions too, because it's rather convenient!

What is quite sad is that we cannot add it ourselves as it's so simple of what they have done:

    func (wg *WaitGroup) Go(f func()) {
        wg.Add(1)
        go func() {
            defer wg.Done()
           f()
        }()
    }

You can just use golang.org/x/sync/errgroup instead, which has always provided this style of use.

errgroup also has other niceties like error propagation, context cancellation, and concurrency limiting.

Context cancellation is not always desirable. I personally have been bitten multiple times by the default behavior of errgroup.

You have to explicitly propagate the group's context if you want it to cancel. You can just not do that if you don't want - there certainly are cases for that.

But if you’re looking at the package API, there is no alternative constructor for Group, which makes it seem as if the most common default is to construct a Group using WithContext. Also, 2/3 of the examples use WithContext.

My recommendation would be to have a NewGroup function or equivalent that returns an empty group to surface it as an alternative to WithContext.

> My recommendation would be to have a NewGroup function or equivalent that returns an empty group

That goes against common practices in Golang, articulated in the second paragraph of https://go.dev/doc/effective_go#allocation_new among many other places.

Also the errgroup documentation specifically says "A zero Group is valid, has no limit on the number of active goroutines, and does not cancel on error." And, as you noted, one of the examples doesn't use WithContext.

That’s one of my Go pet peeves - zero/default structs are sometimes valid and sometimes not, and the only way to know is to dig into the docs. I prefer the API to speak for itself, ideally enforced by the language/compiler.

errgroup cancels the whole task if even one subtask fails however. That is not desirable always.

It does not, which is easy to verify from the source. Every func passed in is always run (with the exception of TryGo which is explicitly "maybe").

At best, using the optional, higher-effort errgroup.WithContext will cancel the context but still run all of your funcs. If you don't want that for one of the funcs, or some component of them, just don't use the context.

If the context cancellation is undesirable, you just choose not to use WithContext, as the sibling comment mentions.

You could also just make your subtask function return nil always, if you just want to get the automatic bookkeeping call pattern (like WaitGroup.Go from Golang 1.25), plus optional concurrency limiting.

Also note, even if a subtask function returns an error, the errgroup Wait blocking semantics are identical to those of a WaitGroup. Wait will return the first error when it returns, but it doesn't unblock early on first error.

They basically don't backport anything for Go, but the quid pro quo for that is that the backwards compatibility is pretty strong so upgrades should be safe. I have seen one serious issue from it, but still it's the language I'm the most confident to do an upgrade and expect things to Just Work afterwards.

You can wrap WaitGroup if you really want to.

Can you provide an example please?

something like this would do it:

  package main
  
  import (
    "sync"
    "time"
  )
  
  type WaitGroup struct {
    sync.WaitGroup
  }
  
  func (wg *WaitGroup) Go(fn func()) {
    wg.Add(1)
    go func() {
      defer wg.Done()
      fn()
    }()
  }
  
  func main() {
    var wg WaitGroup
    wg.Go(func() { time.Sleep(1 * time.Second) })
    wg.Wait()
  }

This is really amazing, thank you so much!

It's called struct embedding, there an article about it in Go by Example if you're interested: https://gobyexample.com/struct-embedding

Thank you @listeria, today I learned about struct embedding lol!

I rediscover this about once a year and am always so happy when I do.

"STEVEN, YOUUUU FAYYYLEEAH" - Steven He's dad

Any chance to test your local development with Bun? This is their latest improvement and I can't wait to test it as soon as they release it! https://bun.com/blog/how-we-made-postMessage-string-500x-fas...

Jens Gustedt's Modern C https://gustedt.gitlabpages.inria.fr/modern-c/

I hope you do know there's a C3 language for a number of years already https://github.com/c3lang/c3c/

It's really sad to see people with an expressiveness problem not being able to perform in an interview, so that they can work in different companies gaining professional experience, and on the other hand to see some guys mocking the system in order to be recruited by different companies and with great success.