-
AspNetCoreDiagnosticScenarios
This repository has examples of broken patterns in ASP.NET Core applications
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I have the conclusion opt-in async/await is a mistake. I think high level language/runtime like c# should handle it automatically like it is a sync call but a way to opt-out should be still possible. In my career, 99% of the time my code awaited async calls. I remember one case we tried to run tasks parallel, but the client for DB(ravendb) started throwing exceptions, possible race condition.
Also, they did terrible work when it was first introduced, low level details were leaked to app surface and it was impossible to comprehend for a regular programmer what the hell is going on? Do you remember ConfigureAwait(false)?
Years later such guidance compiled: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...
> They are not equivalent. Running a function in another process incurs the overhead of copying the data to the other process (potentially over the network). In both directions.
> Moreover, there is a context switch and it's more likely the code will run on a different core if you run it async than if you run it in the same process (which is very likely but not guaranteed) to run on the same core.
Yes I agree, but the question as presented by valenterry asks us whether or not there is some existing semantic difference and not under the confines of performance (both gains or losses). Regardless what you have stated are all true.
But as an aside, and not directed towards you, Task.async/3 doesn't do anything that the developer cannot already do. Even in the tutorial for the learning Elixir, the fledgling developer is exposed to the different mechanisms that power Task.async/3, the source code [1] reflects this, although supervisors are covered much later down the line. The documentation for
> The way in which they are equivalent, is that the code that you write is identical, and the bytecode that gets run, and the existence of implicit yields is identical between the async and "sync" code.
And just to add on for those not familiar with the BIFs, receive, which is what Task.await/2 and Task.yield/2 use under the hood, yields execution. NIFs are another one.
[1] https://github.com/elixir-lang/elixir/blob/fb729784e5504f499...