21–30 of 57 posts
Earlier quoted context omitted.
> In fact, unless you're wasting time, 80,000,000 averages less than 10 requests/second... Please show your math. I took 80000000 / (24 * 60 * 60) and I got 925. So you seem off by about two orders of magnitude.
Please show your math. I took 80,000,000/86400 and I got 926. So you seem to be off by about 1.
Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…
> This begs the question: you really need async in the language? Or even delegates. Or interfaces. Or LINQ. Basically you could write the same thing in C. Or assembly.
The parent isn't arguing that the new async constructs in the language don't make asynchronous programming easier.
He's questioning the need for using asynchronous programming models at all, for the common use case of ASP.NET applications.
Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…
I think async is a systems programming tool rather than an application programming tool. If you're writing a web server or a web browser, it'd be useful. But for a web application, you're already sitting on a highly scalable and robust async library called IIS so when you need a background task the easiest thing to do is to make it a RESTful API call. I find many web developers now intuitively break up their applicat…
The key question is: while said REST call is happening, what is the caller doing? Normally, he's sitting there and blocking his thread until the call finishes (i.e. consuming one thread from the connection thread pool). With async/await, the thread is released back into the thread pool until the result is ready, then it picks up where it left off.
So anything where you might want to deal with background operations that take a long time (including network / db / filesystem access, i.e. most applications that aren't pure functions) in a connection-oriented system can greatly benefit from async/await. Even if it's just a regular desktop app, it appears to be a useful mechanism for coordinating different background tasks.
Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…
I too have applications that do a lot of stuff relying of asynchronous toolsets but without much explicit asynchronicity. However, I did a simple experiment a couple weeks back - I coded one of our simple but very asynchronous programs in Go. Compared to the Python original (which uses Twisted), the Go version had 70% of the lines and was much more readable and understandable by even team mates who had never seen Go.
I believe that's the point of having async operation elegantly merged into the language.
Earlier quoted context omitted.
I think async is a systems programming tool rather than an application programming tool. If you're writing a web server or a web browser, it'd be useful. But for a web application, you're already sitting on a highly scalable and robust async library called IIS so when you need a background task the easiest thing to do is to make it a RESTful API call. I find many web developers now intuitively break up their applicat…
When you say that a background task should be made into a RESTful API call, I assume you mean that instead of spinning up a local thread to do the work you should defer it to another service. Certainly you can do that, but async/await is still relevant in that case. The key question is: while said REST call is happening, what is the caller doing? Normally, he's sitting there and blocking his thread until the call fin…
Earlier quoted context omitted.
When you say that a background task should be made into a RESTful API call, I assume you mean that instead of spinning up a local thread to do the work you should defer it to another service. Certainly you can do that, but async/await is still relevant in that case. The key question is: while said REST call is happening, what is the caller doing? Normally, he's sitting there and blocking his thread until the call fin…
Your point is a good one. Without wanting to get too deep into a design for some hypothetical system, I guess I was thinking that I'd either try and modify the current request such that it can return something to its caller (e.g. Render a web page saying "Loading..." with a setTimeout call in it). Or use .NET's HTTP request library which has a delegate callback option that lets you get on with other stuff.
Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…
A better question is how many lines of code the async feature saves, compared to the code you would write without it.
Earlier quoted context omitted.
I think async is a systems programming tool rather than an application programming tool. If you're writing a web server or a web browser, it'd be useful. But for a web application, you're already sitting on a highly scalable and robust async library called IIS so when you need a background task the easiest thing to do is to make it a RESTful API call. I find many web developers now intuitively break up their applicat…
The problem is that it's pretty useless in non-systems programming language.
It is pretty simple for that scenario and avoids the cross thread marshalling you need to do in win forms.
Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…
It's about doing more, better, and easier. async allows a pretty complicated process to be much easier to write.