So true. There’s this funny line in one of Paul Graham’s essays where he says something like “making the wrong technology decision can doom your business - like choosing Windows in the 90s” I got such a kick out of that because I worked for CyberTrader in the 90s; we built our whole platform around Windows and wiped the floor with our competitors. We ended up the top day trading company in the US and were acquired by Charles Schwab for just shy of $500m. But at the time, you pit Windows NT with IOCP against anything else and it was game over in the low latency trading space.
Reading the old NT debugging blogs and Raymond Chan’s stuff was very eye-opening. Microsoft has incredibly talented engineers ready to help Solve Problems, not just toss you the source code and wish you luck.
That does not happen, even with the beta grade Linux version on Arch (as I run it)
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.
I'm only 50 and been messing around with them for about 40 years.
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.
Same freezing problem, company issued laptop 100mbit internet connection. Same feedback from hundreds of people. Half a gigabyte RAM or more even when Teams inactive. Other softwares have solved this problem so I will agree with the opinion that Teams team should put their act together. I will postpone prioritizing Teams ips to the routers.
It might depending on platform. On my windows laptop, I can videoconference without GPU accelleration. Windows 10 has an impressive software fallback for gpu rendering (WARP), they could be using that.
Agree if your computer resources are being utilized over 70 percent teams becomes a nightmare. They could have written it in c++ in the same amount of time and had that thing running smoothly.
> Rewriting it in C++ to magically solve problems. Good job, engineer.
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.
Hmm when I compare the two in terms of CPU / Memory usage and speed, Teams is one of the worst performing electron apps on my system, and VS Code one of the best. I don't think this is just network related (and I have a 600/600 connection anyway).
Either way, even if this was the reason it would prove that Electron is not a good fit for an app like this.
The issue with teams is performance. Teams is a relatively simple application. C++ is extremely common and well known, would have been a better tool for the job. That’s called engineering when you actually care about the quality of the product.
This still holds for C# and the .NET ecosystem today, especially amongst SV startups. If only they knew how much faster and better they could be building instead of avoiding it for ideological reasons.
"I don't trust, based on their past behaviour, that these people will pick a path that is consistent with mine" is a perfectly rational reason based on ideology.
Ok, so what path is interfering with the ability to build faster and better exactly?
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.
Only since 2016, and it wasn't really usable until a couple of years ago. Most third-party .Net libraries still assume you're in a Windows world. The reality is that .Net is very competitive in terms of development speed if you deploy on Windows; elsewhere you'll likely have to figure out stuff and suffer from being on a second-class platform.
IMHO selling .Net to unix devs is a bit like trying to sell icecream in Siberia.
> The reality is that .Net is very competitive in terms of development speed if you deploy on Windows; elsewhere you'll likely have to figure out stuff and suffer from being on a second-class platform.
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.
This fear is unfounded, the primary value proposition of .NET (FKA .NET Core) is that it's a high-performance cross-platform runtime that has first-class support for Linux.
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.
Azure runs more Linux than Windows, including its own services. Linux and mobile are first-class platforms. Everything is compatible unless you specifically use Windows-only APIs. Do you have any examples of 3rd-party libraries that aren't supported?
.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.
SQL Server isn't part of .NET, and no different than using any other proprietary database. I'm not sure what you mean by 3rd-parties but .NET works with all the major open-source projects so you're not missing anything.
Funny enough in 'founders at work' it sheds light on the early days of paypal. It seems to point towards one of the reasons Elon got fired as CEO of Paypal is because the broader team disagreed with Elon about whether to build around windows or linux and Elon argued that there was more tooling in windows at the time.
I worked on a big distributed system with C# and windows servers. Was rock solid I miss it so much. I'm not drowning in Java/Spring/Linux app its such a horrible mess, security is the worst nightmare but even stuff like NFS is regularly breaks. Windows was great.
Well, things have a tendency to come full-circle again. Maybe with the cloud offerings, we'll realize that open-source isn't so great and go back to more proprietary offerings.
C# is basically the same thing from a VM perspective, an interpreted bytecoded high-level language, but tied to windows. You can write architecture astronaut shit in C# just as much as Java.
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# is basically the same thing from a VM perspective, an interpreted bytecoded high-level language, but tied to windows.
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.
The branding has been churned like crazy. As far as I can tell, the first .NET version that officially supported (almost?) the complete API on Linux was released last month, so we’d have to sign up for being an early adopter.
"the complete API" is a bit of a misnomer, since there have been new APIs and runtime capabilities that aren't available to the Windows-only, older runtime (The .NET Framework). This has been the case since at least .NET Core 2.1 but has continued ever since.
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 basically the same thing from a VM perspective, an interpreted bytecoded high-level language, but tied to windows
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.
Agreed C# and Java are virtually identical. However the cultuer is completely different. The plethora of libraries to me ends up being a handicap. We have had a bunch of different Java developers on our project and each one does things differently so we end up with a huge mess. I didn't see such problems in C# world where maybe we just had better devs that concentrated on clean models instead of incorporating fashionable libraries and other moving parts.
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.
