181–186 of 186 posts
Earlier quoted context omitted.
Serverless computing is dominated by node, go, and python. .NET just doesn't startup fast enough.
Good point, I didn't think about that.
Earlier quoted context omitted.
Good point, I didn't think about that.
.NET is competing against any language which is not exactly driver level (like c/c++/rust). Every other app model they compete. Even OS Scripting they cover with PowerShell (which is not c# but it is .NET).
So much content and the `ConfigureAwait` portion, which is the BIGGEST gotcha in the whole shebang in my opinion, is not filled out?! Especially for Xamarin, you need to understand and use ConfigureAwait to properly bounce between UI / background threads.
Is there a rule as to which methods are best made async and which not? Or, once you start using async would it be best to make ALL methods async? Many methods could be either sync or async. But if you make a method that doesn't strictly need to be async async you give yourself the option of later making it actually return its result after a delay, say reading its answer from the web or asynchronously from disk. Where…
The would say that asynchronous methods are mostly about orchestration and side-effects and non-asynchronous ones about computations. If your computation code reach out to fetch data or trigger side-effects I’d take that as a sign of it being badly factored. Try to push the async parts up the stack to an orchestration layer, and keep the computation code “pure”
So I'm not sure if it's always clear what should be the perfect factoring.
Is there a rule as to which methods are best made async and which not? Or, once you start using async would it be best to make ALL methods async? Many methods could be either sync or async. But if you make a method that doesn't strictly need to be async async you give yourself the option of later making it actually return its result after a delay, say reading its answer from the web or asynchronously from disk. Where…
I recently had to make a change that converted a few functions to be async. It was certainly annoying to propagate that back in all the signatures, but the biggest issues came with having code that was designed under the assumption that the code would be synchronous. It was difficult to rework the code in ways that would avoid issues with things like the fact that if I use a member variable, call one of these functio…
Part of the issue is that 'sync' is the default. I wonder if it would be better the other way. Because sync is the default it is easy to "simply" write sync methods in cases where async might be a better choice, and, that decisions is often hard to reverse later.
I'm working with JavaScript but I assume the issues and questions are similar as with c#.
I think the question could be rephrased as "When should I NOT use async methods?"