Description
Author background
I'm a senior Go developer and have been using Go in production since v1.2, currently for autonomous vehicle development at Einride. Other languages I use are Rust, C, JS/TS, Python etc.
Related proposals
Found a few related proposals/issues around handling goroutines:
This proposal should not affect error handling nor generics.
Proposal
The proposal in itself is quiet simple; to return the goroutine ID when calling go:
id := go f()However, this change should open up for some useful tooling around goroutines, namely external control (kill/suspend etc) and hopefully the possibility of Erlang-like supervision trees. Using the returned ID is optional.
An example of a third party package that tries to address this is Suture.
I don't know much about the implementation details of goroutines apart from the high-level descriptions in early blog posts by the language authors, so I don't know how feasible this change is.
This change would not affect existing code bases much as no assignments were previously possible when calling go, and should keep the backwards compatibility guarantees of the language nicely.
In addition to this proposal, and if accepted/interesting, another proposal on useful utility functions should be made.
Costs
This change would not make using goroutines any harder, but would add some complexity in that new concepts may need to be learned; that goroutine IDs are a first class concept in comparison to the more debug/internal concept it is today. The tooling cost of this change could be quiet substantial as go is such a core concept in the language and it would basically affect all common tools. In addition there is a small runtime cost that I can predict, supposedly one register for the returned ID (but again, I don't know the implementation details).
I have not yet prototyped this more than in the psuedo-code above.