Swift is definitely something I'd like to explore more, but like Rust, it has few production-ready dependencies available. Kotlin or other Java derivatives on the other hand probably have too many -- if your code is written in Java, I've no idea if it will work great in Kubernetes or if it will expect OSGi or if it's a giant monolith. Which is to say, modern practices can make the JVM a surprisingly practical choice, but most software isn't really all that optimized -- slow and bloated legacy dependencies are both a problem in Java as in Node.js...
C# meanwhile can be efficient, but rarely is. And it has toolchain issues due to VS not being open source, and a very small ecosystem of dependencies, plus a history full of corporate rewrites of core functionality. It has a bright future, but its reliance on msbuild and Visual Studio limit it compared to Java. I'd like to suggest C++ but I've spent years learning it and find the complexity overwhelming in side projects. In practice, I think C++ is only appropriate for full-time projects with lots of engineers to validate correctness, etc. The exception I'd make is tiny C++ modules as glue code between languages, or to other existing C code.
The ecosystem is definitely growing in the last 5 years too since open source has been embraced by MS and the community.
The major rewrite of .NET -> .NET Core and then now renaming it back to .NET again is good in that it's a much better framework now, bad in that it's turning out like Python 2 vs Python 3. Huge projects just can't upgrade, so old .NET Framework stuff is sticking around longer than it should.
They're undoing the split between Core and .NET Framework by suggesting that they'll ship both within .NET 5 using shims or implementations of drop-in replacements for .NET Framework code to use. Imagine if after dropping Python 2 support there was a mode that scanned for Python 2 code and enabled it again, on a file-by-file basis, to work with newer Unicode strings using some kind of translation layer in the runtime. That's kind of what's happening here, I think, but maybe more lightweight than suggested. Legacy .NET Framework code still deprecated, but interoperability libraries will ship as part of the runtime or SDK, will have some amount of shims available. I haven't followed the details closely enough to say more than this, though. I last looked into it a few months ago.
>net5.0
>net5.0-windows
>net5.0_something
So you can use "pure" "net5.0" on Linux and generally cross-platform software meanwhile still be able to use old .NET FrameworkX winforms/wpf on "net5.0-windows".
While Java is generally slow, that's more the fault of Java developers and their FooDangleProviderModuleBuilderBuilderFactories. Due to runtime optimization Java can be nearly as performant as non-GC languages. In principle there are even scenarios where it can exceed the performance of any ahead of time compiled language.
There are idiomatic ways to avoid the GC in Go, and people do that in tiny places, but few people build ground-up that way, because it’s not the kind of program Go asks you to write.