AspNetCoreDiagnosticScenarios VS hamt

This one is a pretty decent guide - https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md

The C# (mostly applicat community has e.g. https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md written by one of the Asp.Net architects. I found this in this lovely thread https://news.ycombinator.com/item?id=36785691 which expresses my views/confusion more clearly than I can express.

No it doesn't, hence why there are best practices guidelines written by the .NET architects, and there was a research project to add Go/Java co-routines as well.

https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...

https://twitter.com/davidfowl/status/1532880744732758018?lan...

https://github.com/dotnet/runtimelab/issues/2057

https://github.com/dotnet/runtimelab/issues/2398

They don't work just fine in C#, there is a reason why one of ASP.NET architects has written a guide of best practices.

https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...

Many that praise async/await in C#, kind of forget it took about 10 years to spread across all the layer of the language and runtime, since it was done via IL rewriting, it caused several issues with F# async tasks, due to the age of the ecosystem plenty of code isn't async/await friendly and needs to be wrapped into Task.Run() or similar.

There is a best practices guideline from one of the ASP.NET architects, https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...

During last year they researched adding Go/Java's approach to .NET, but now it is too late. See the ASP.NET Q&A session at BUILD 2023.

The best guidance I have found was from here: AsyncGuidance.md

To expand upon this thought, here is the AsyncGuidance doc[1] on why not to use .Result to get the return value of a completed Task in C#.

To make this simple they introduced async Main[2] a few years ago.

[1]: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...

Async Guidance

This isn't a very good explanation. The wikipedia article isn't great either. I like this description:

https://github.com/mkirchner/hamt#persistent-hash-array-mapp...

The name does tell you quite a bit about what these are:

* Hash - rather than directly using the keys to navigate the structure, the keys are hashed, and the hashes are used for navigation. This turns potentially long, poorly-distributed keys into short, well-distributed keys. However, that does mean you have to compute a hash on every access, and have to deal with hash collisions. The mkirchner implementation above calls collisions "hash exhaustion", and deals with them using some generational hashing scheme. I think i'd fall back to collision lists until that was conclusively proven to be too slow.

* Trie - the tree is navigated by indexing nodes using chunks of the (hash of the) key, rather than comparing the keys in the node

* Array mapped - sparse nodes are compressed, using a bitmap to indicate which logical slots are occupied, and then only storing those. The bitmaps live in the parent node, rather than the node itself, i think? Presumably helps with fetching.

A HAMT contains a lot of small nodes. If every entry is a bitmap plus a pointer, then it's two words, and if we use five-bit chunks, then each node can be up to 32 entries, but i would imagine the majority are small, so a typical node might be 64 bytes. I worry that doing a malloc for each one would end up with a lot of overhead. Are HAMTs often implemented with some more custom memory management? Can you allocate a big block and then carve it up?

Could you do a slightly relaxed HAMT where nodes are not always fully compact, but sized to the smallest suitable power of two entries? That might let you use some sort of buddy allocation scheme. It would also let you insert and delete without having to reallocate the node. Although i suppose you can already do that by mapping a few empty slots.