Memory usage of a toy C# server and client with 500K concurrent connections on

Re:Memory usage of a toy C# server and client with 500K conc... by k_bx on Sunday January 27, 2019 @06:51AM (#19011371)

> In C# if you're not careful your codebase gets littered with tasks everywhere, even in code that has nothing to do with concurrency originally.

This is a spot-on. The only language I know that did this all right is Haskell, where most of your code doesn't need any thinking of async operations (either runtime gets you covered, or function takes a callback as a parameter, instead of any await magic), and when you need them -- you have `async` library that gets all you need.

[ Parent | on HN ]

Re:Memory usage of a toy C# server and client with 500K conc... by platz on Sunday January 27, 2019 @12:34PM (#19012711)

a common misconception.. haskell does not "auto-async" anything.

Laziness is not Async.

You explicitly provide instructions which expressions get turned into async expressions in Haskell.

[ Parent | on HN ]

Re:Memory usage of a toy C# server and client with 500K conc... by k_bx on Monday January 28, 2019 @04:35AM (#19016195)

I never stated anything remotely close to that :) What I've meant are:

- either Haskell gives you API which is done "right", without any Async types. For example, `bracket` function

- or runtime gives you lightweight threads by default, so you can just `fork myComputation` and it'll run in a lightweight thread which "just works"

- or finally, in rare situations of interleaving different computations with complex dependencies, you just use the `async` library, which is not a special language construct but a library, which lets you "await" and all that

[ Parent | on HN ]