[flagged]
I know, which is the exact reason the reply states "uncharacteristically". And yet, it fails to acknowledge existing terminology and tradeoffs and just states at the end in a couple paragraphs how Goroutines shall deliver us all from evil (which could not be demonstrably further from the truth). Surely we need to expect better from one of the Dart's authors than forgetting to mention all the caveats virtual threading via stackful coroutines comes with?
And this completely ignores that Go applications end up having to reimplement .NET's task system system anyway and that Goroutines are poorly suited for "fine-grained" concurrency. Even the UX of Goroutines is bad. Want to return a value when one exits? Be sure to not screw up synchronizing and passing the data by hand. One must imagine Gophers writing all that boilerplate happy. I suppose, it's a preferred pastime to learning the internals and ceasing to post the same tired shibboleths.
https://news.ycombinator.com/item?id=41121266
Been years since I wrote Go code, until last week. Daily has become C#, python, and powershell. Took a day to fall back in and write a tool while learning a new GUI framework. Found the strengths and weaknesses of the GUI.
Personal, I find Go more pleasurable to work with than python and C#. Reality, the project requirements dictate the languages that maybe used. This is the reason why Go was chosen over the others listed and unlisted C, C++, Swift, rust, ...
Which would be a better experience with developing for iOS, Swift or C# or Go? If it was company's main solution or product, Swift, even when I will need to learn it.
>Take a transport, like an HTTP client, send two/three/n requests concurrently
That is business logic. Back end maybe embedded and this could become a DOS attack.
.NET implemented the code to manage task pools so you don't have to. N aysnc is really a set of Z handlers. With syntax sugar.
>Context propagation issues are known
Doesn't a context need to exist for two entities to communicate and no system can exist where context is not shared?
This is the adapter pattern in GoF, which in can be reduced to function g controlling the interactions between function a and b, where function a or b may act upon the agreed upon return type, callback type, or memory type. Address of the return, callback, and memory must be shared either with-in g() or a() and b() .. from CPU register up to system memory address.
>And why would anyone need to bother with explicit synchronization anway?
Dependent on business logic. Including which 3rd party libraries must be used for the solution. Software might be architecture for using Reactive objects which mimic async / await with more well defined and shared behavior. A custom managed thread maybe needed for more accurate time limits or an event loop is needed.
>sleek one-liner.
Be warned, one liners may seem useful, until they need to be debugged. There is a great difference between the two C# Reactive objects:
{
doing.Where(x => x.CanDo()).Subscribe(x => x.ExtensionDigestion());
doing.Where(x => {
if (x.Id == ID_WITH_ISSUES_OR_TESTING) {
var i = DateTime.UtcNow();
}
return x.CanDo()
}
.Subscribe(x => {
x.ExtensionDigestion();
});
}