You may have a rubbish internet connection. If you are using a VPN with a slow internet connection, investigate a split tunnel. Teams traffic involves only three IP ranges so it is easy to split out and route direct to shave a fair bit of latency.
Other issues will require more investigation but they are local to you.
My point was that even on a precariously supported platform (my Arch Linux computers), the software works fine - ie as proscribed. MS Teams is used by a vast number of people and has a habit of working OK for them.
Sometimes it really is a specific person’s issue, and sometimes there are a lot of them so it can look like a vendor issue.
Of course, sometimes it is a vendor issue.
There is a percent range where it is difficult to differentiate. Made worse by a large user base.
e.g. "Slack has lost connection... We'll try to reconnect in 30 seconds"
Well it's a lot easier to make an app perform well in C++ than electron.
They should at least have for the VS Code team to help. That's one of the best performing Electron apps, it's strange MS never adopted those practices company wide.
Either way, even if this was the reason it would prove that Electron is not a good fit for an app like this.
The three heroes of ethics, ideal working conditions and examples of behaviour towards the society in general.
Looking at their current behavior from open-source to VSCode to .NET 5 shows that it's a more compelling choice today than ever before. This is actually rational.
The only reason most startups use open source ecosystems is economics.
IMHO selling .Net to unix devs is a bit like trying to sell icecream in Siberia.
That's nowhere near reality, .NET 5 (FKA .NET Core) has flawless first-class support for Linux, the whole deployment experience is even better on Linux since you have access to the entire Linux tools + ecosystem. Which I've been deploying to for years, I still develop on Windows but only ever deploy our .NET (Core) Apps to Linux (since the same App runs flawlessly on Windows + Linux).
The Windows-only .NET Framework (excl Mono) is now considered legacy, it's continually supported but all new development + features are being invested in the .NET 5+ cross-platform runtime which is now what ".NET" refers to.
Not that Electron is appealing either but I get the draw fully.
It's been designed to be "cloud-ready" from the start where it's adopted a high-performance core with a leaner, modular runtime that supports side-by-side installations since Microsoft wants it to run well in the Cloud of which all cloud providers (inc. Azure) predominantly deploy to Linux VMs, whose trend will continue to dominate.
You can view the supported Linux distributions on their installation page which includes Linux binaries for x64, Arm32 + Arm64 including package managers for its supported Linux distributions (Alpine,CentOS,Debian,Fedora,openSUSE,RHEL,SLES,Ubuntu) [1]. As well as maintaining multiple Docker configurations for popular Distros [2].
With Linux now being a supported platform means if you have run into an issue you can report it where their full-time resources will resolve it. The old days of using .NET to push Windows is gone, the future is the cloud and Azure doesn't care if you run Linux or Windows VMs, it's all the same to them, they're still collecting rent for usage of their servers by the hour.
.NET Core (now .NET 5) has changed the entire ecosystem and has been production-ready for years, and is even making cutting-edge advancements like Blazor which offers the first real alternative to Javascript on the frontend. The reality is that .NET is a top choice for both development speed and application performance across all platforms today.
The nice thing about Java is the deployment and management tooling. It's cross-platform and mature. C# is not nearly as good in this respect, although with the open-source it is finally free to move with that.
C#/.NET hasn't been tied to windows for a number of years now. .NET Core/.NET 5 is cross-platform and great to work with. All of our CI/CD runs on Linux agents too.
There are several APIs in the older runtime that are intentionally not brought forward, and what I believe you're referring to is this announcement: https://github.com/dotnet/announcements/issues/130
The remaining APIs are (mostly) AppDomains, Remoting, Web Forms, WCF server, and Windows Workflow, most of which is either an acknowledged "this was the wrong way to do it so we won't bring it forward" (e.g., Remoting) or tied to Windows anyways (e.g., WCF).
C# is not tied to Windows, some new features in the latest C# 9.0 doesn't even support running on the Windows-only classic .NET Framework.
All new .NET development + C# features is being invested into .NET 5+ (FKA .NET Core), i.e. the high-performance cross-platform runtime.
> The nice thing about Java is the deployment and management tooling. It's cross-platform and mature. C# is not nearly as good in this respect, although with the open-source it is finally free to move with that.
Citation needed, I deploy my .NET 5 Apps with Linux tools, either rsync, Docker as well as AWS ECS. All clean + simple, only requires a single command to publish your App ready for distribution, that you can either rsync across or include it in the runtime image of your Docker build.
Tried to publish a Java package last week and the whole experience was a shit show, by far the worst experience of all languages where the recommendation to publish a package is to push it to bintray first, make it available to jCenter than sync it to Maven, where you need to get manual approval to include it in jCenter then you need to create yet another account/credentials with a 3rd Party which requires a manual request via a damn Jira ticket. Then each package manager has different requirements as to what a package needs, I could publish it to bintray but couldn't get it to jCenter without uploading a POM which new Kotlin projects aren't created with, then MavenCentral requires a stricter POM and Java Docs but there's no standard way to publish to a repository as bintray needs their own non-compatible task, so now I have duplicated generated POM's in my gradle build to satisfy different repositories, for bintray I needed to hook into their bintrayUpload task and generate the POM just just before it uploaded the package which I needed to decompile its sources to find out where exactly the POM file needs to be written to, no examples of which existed for Kotlin build.gradle.kts scripts that new Kotlin projects are created with. Then there's the case that every build.gradle example uses configuration that is already deprecated and Java/gradle seems to be the only one requiring uploading binary .jar's with your source projects.
Every other language has a single repository you can publish to that you don't need to jump hoops to get, published using standard tools, simple, clean, straight-forward & well documented.
Something C# never was, given that it always JITs before execution and AOT compilation to dynamic libraries has been available since version 1.0 via NGEN.
Plus lots of additional AOT alternatives like Windows 8.x Bartok compiler, .NET Native and CoreRT.
This on top of third party offerings like Mono AOT or IL2CPP, and the research compilers from Singularity and Midori projects.
Whereas for Java, while AOT has been available since around 2000, it has been for the most part only available on commercial JDKs, and free beer AOT only came with the release of GraalVM community, the addition of J/Rockit JIT caches into OpenJDK, and IBM releasing OpenJ9 as FOSS as well.
Abstracted far enough, everything is basically the same thing.
How so, I had nothing but issues when trying to deploy cross-platform Java because of the Java ecosystem itself being bad compared to C# or Golang where you just compile stuff and run it.