A bit late but I can comment to be informative. > I'd need to see evidence, it's hard to believe .NET can offer anything more performant than say Vert.x or Mic

A bit late but I can comment to be informative. > I'd need to see evidence, it's hard to believe .NET can offer anything more performant than say Vert.x or Micronaut :-) Benchmarking is interesting because it depends on your case, and the tricks used in the benchmark. Techempower has proxy benchmark at https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r20&hw=... for just the web layer which shows aspcore quite high. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fsharpcore-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I note it isn't as good with DB queries (DB framework) than Vert.x which gives points to Scala for db like APIs but there's tricks there too. Benchmark Game seems to have F# compare well with Java and OcAML (low level non-idiomatic code there I'm sure too). Been meaning to try Vert.x. - Futures/async/await are ubiquitous in Scala I need to look into this more but using them in the past it seems very library based (map/foreach/for comprehensions/flatMap/etc) whereas the .NET implementations tend to be like co-routines (state machine) that are compile time constructs with associated perf benefits. It adds a lot to performance; you want the async primitive to be as cheap especially if doing them in hot loops - .NET articles are full of Task/Async patterns and their benchmarks and optimizations to Tasks are constantly ongoing. > - Scala has value types Not in a way that I use them I guess. https://docs.scala-lang.org/overviews/core/value-classes.html https://docs.scala-lang.org/overviews/core/value-classes.htm... shows quite a few limitations. They may be overcome with Project Valhalla? but it isn't there yet - its a JVM limitation not a Scala one. They seem to be extremely limiting compared to .NET types where you can compose things together (more than one value, etc). I use this for math ALL the time avoiding any GC events at all - there's a lot of cases for quick stack allocated values that can cross function boundaries. I've worked on the JVM - its possible but much harder with uglier code. .NET seems to have many more ways to avoid "boxing" than the JVM when the JIT doesn't catch it. Especially with generic methods (unless inlined). Basic tuples, ValueTasks (like futures) and such all use this construct at times. - JVM has plenty low level performance tricks Sure it does. I'm liking the new things in .NET Core like Span making it "safe" to do them vs Unsafe and interop. Re-using memory (slicing parts of strings without cloning chars), etc in a safe manner is a simple example but there are others. > Scala is plenty close to the JVM Plenty of its abstractions however however require allocations and objects (e.g. implicits everywhere) - futures being one. IMO maybe its just me but it is easier to reason about F# performance. An example in F# would be that many allocations are only allowed explicitly (e.g. math conversions) - it actively discourages implicit behaviour for simplicity I feel. e.g. Auto-Boxing in erased generics has caused perf problems in some JVM programs I used to work on. Both platforms are capable and have their own pitfalls of course. - self-packaged bundle' capabilities .NET Core feature.