suture VS conc

This one is highly specialized, but I'm a huge fan of Suture for managing long lived goroutines.

In English, your phrasing doesn't come off as a play on words/a reference to the name, so much as it describes a feature of the library. The expectation is, with the description you've given it, the library would handle some form of resilience in service management. I half expected the library to be similar to Suture.

It does not give you a way to reliably track arbitrary goroutines that "this" goroutine (for whatever that may be) wants to track, the way an Erlang process can just "link" to anything it is capable of naming the PID for.

However, you can construct a reliable mechanism where one goroutine can start another and know whether or not the one it started has failed by using the available primitives, as I did in https://github.com/thejerf/suture . It's an easier problem since there's no cluster and no network that can get in the way. I've also done the exercise for the network case: https://pkg.go.dev/github.com/thejerf/reign#Address.OnCloseN... but that only functions within the network defined by that library because, again, it just isn't arbitrarily possible.

(I suppose it's relevant to some of my other comments to point out that I've also implemented basically Erlang-style concurrency in Go, with network, but as a relatively idiomatic translation rather than a blind one.)

If you also want Supervisor-like behavior, take a look at suture.

For context, I've been working with similar interfaces for many years through suture.

I wrote suture for idiomatically-ported supervisor trees (that is, the ways they differ are deliberately chosen, not accidents), and reign for Go-native cluster-like support. I use suture in almost everything I write. Reign is used on production services but I don't generally use it because I think modern stacks have better options with modern message busses, but it can be useful for porting.

I think the distinction between expected and unexpected errors can easily fall through the cracks and writing code in a way that an unexpected error doesn’t break everything is quite powerful.

Golang makes it easy to ignore errors that can be ignored and defer/recover provide a way to implement a way to “let it fail”

There’s even an implementation of supervisor trees for Go [0] :)

[0] https://github.com/thejerf/suture

(If you'd like something lighter weight, suture is a supervisor library without a whole lot of other stuff. If you want that other stuff, by all means, go to town.)

This is the primary reason almost every program I write ends up using suture. The restarting is nice when it works, but Go code is often reasonably robust. (Not 100%, but reasonably.) But it's a nice organization principle.

It's a pity Go didn't have structured concurrency: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

There's a library for it: https://github.com/sourcegraph/conc

But this goes to one of the things I've been kind of banging on about languages, which is that if it's not in the language, or at least the standard library right at the beginning, sometimes it almost might as well not exist. Sometimes a new language can be valuable, even if it has no "new" language features, just to get a chance to reboot the standard library it has and push for patterns that older languages are theoretically capable of, but they just don't play well with any of the libraries in the language. Having it as a much-later 3rd party library just isn't good enough.

(In fact if I ever saw a new language start up and that was basically its pitch, I'd be very intrigued; it would show a lot of maturity in the language designer.)

What are possible use cases for this tool? Why would I want to find out the total runtime of all videos in a directory?

Also, you might wanna limit concurrency[0] instead of spawning many ffprobe instances at the ~same time.

[0]: https://github.com/sourcegraph/conc

In another note, ChatGPT suggests this shell command to do the same thing. It doesn't process files in parallel though.

    find . -name "*.mp4" -print0 | \

While virtual threads will be stable in Java 21, Structured Concurrency is still a preview feature. You probably won't see it in production anytime soon.

Preview features require a special flag when compiling and running them, and they won't run on newer versions of the JVM. I don't expect to see StructuredTaskScope in common production use before the next LTS version is out.

But it doesn't mean you cannot have structured concurrency before that. Even in language that mostly enforce Structured Concurrency like Kotlin, it's still a library feature. Even the original blog post which formulated this concept, described a library that implemented structured concurrency for Python[1]. You can pretty easily implement structured concurrency yourself by creating your own implementation of StructuredTaskScope, if you need it right now. You can even structured concurrency in C#[2] or Go[3].

[1] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

[2] https://github.com/StephenCleary/StructuredConcurrency

[3] https://github.com/sourcegraph/conc

I'm also a fan of Conc for managing various different concurrency patterns -- don't create manual worker pools for locally distributed tasks if you can use Conc, etc.

How does this compare to conc?

I will probably be using more conc too now. Lots of great primitives for dealing with multiple functions returning the same types or errors etc.

You want a fast asynchronous development use a library I recommend https://github.com/sourcegraph/conc

A struct{} channel is the way standard way to implement this - yes. I don't think we're saying anything different? Here's a good implementation I used recently: https://github.com/sourcegraph/conc/blob/main/pool/pool.go