7 ms·
The future is very bright for .NET. It has the right raison d'etre - .NET is part of the growth story for Nadella-Microsoft. They already have you programming
by _acco 6y ago
The future is very bright for .NET. It has the right raison d'etre - .NET is part of the growth story for Nadella-Microsoft.
They already have you programming in their editors (VS/Code) and pushing to their VCS (Github). They're even teaching you the C# type system with TypeScript :) If they can just convince you to use their stack, Azure will win you over from AWS every time.
As a result, I really wanted to adopt .NET earlier this year. But they have some work to do to make the ecosystem approachable to newcomers.
One of the core issues feels so... trite. But experiencing it, I realized how real it really was:
The Names. Microsoft has created a Ninja Warrior obstacle course of proper nouns.
It is comical. It is worthy of parody.
.NET, the CLR, and their relation to C# and F#. ASP.NET, ASP.NET MVC, ASP.NET Web Api, Blazor vs Razor, .NET Core vs .NET Framework vs .NET Standard.
I think I could draw the lines between all those with about 50% accuracy. And I read like 3 books on .NET before diving in.
It's bad off the top when you're trying to figure out which way is up in the ecosystem. It goes from bad to worse when you're looking through docs and Stack Overflow answers.
It was almost never immediately clear if a document I was looking at on Microsoft's own website applied to me or not. That is a cardinal sin of technical documentation.
Ultimately, this meant that .NET Core Web API (or whatever I was using) felt poorly documented.
I'd find myself looking at docs that mention .NET Web API - but I can't remember if that rolls up to .NET Core or Framework -- or both? Am I using MVC? Is Web API a subset of MVC? No clue.
It's definitely a hard problem. Here's to hoping that now that everything is unified, they can work on paving clearer roads into their ecosystem.
- FridgeSeal 6y ago> Azure will win you over from AWS every time. Going to have to disagree here. That might be the case if Azure was not literally a tire-fire. I have been using Azure for work and it's the most frustrating, inconsistent, often-broken, confusing and stress-inducing cloud service that my teammates and I have ever been subjected to. It left such a bad taste that I am quite certain I would flat-out refuse to use it again in the future, or work somewhere that uses it. Take my advice: just don't use it. It's not worth it. Use AWS, use GCP, use Digital Ocean. Use some random cloud provider. Just don't use Azure.
- flamtap 6y agoWow! Hot take. What Azure services were you using?
- FridgeSeal 6y agoFront door, firewalls, LB’s, AKS, Azure Functions, Azure Disk (in AKS), scale sets and file-share storage accounts. All of it was painful. There docs were lacking or sent you in circles. The documentation for their firewall product is three-quarters known issues and errors. Azure functions were painful to run locally, good forbid you’re not using Windows. Azure would take ages to attach a node on K8’s. Like, over an hour. It consistently had issues moving Azure disks between nodes in K8s: “can’t mount disk, attached to another host” in comparison AWS will speedily and happily re-attach an EBS disk to a new machine. Permissions were opaque and distributed across the whole interface. It silently deprecated keys underneath us, broke a number of services (couldn’t write to attached disks in K8s, couldn’t move them), didn’t inform us that this happened, we only figured it out by trawling through GitHub issues. Storage Account explorer application breaks/stops consistently. “Alert but permit” mode on firewalls doesn’t do what it’s supposed to: it will permit, but totally fails to alert you. Scale sets operate weirdly, I didn’t personally deal with this too much, but my teammates had consistent issues with strange caching issues and more or less machines being spun up than should have. Until we fixed it, every Azure PoP was health-checking our web app 2-3 times a minute: our logs and servers were being flooded with literally thousands of pointless requests. If you have an AKS cluster with n machines currently in it, with a minimum and maximum of (n, m) machines, and you want to say, increase the minimum number, you cannot: it will refuse and tell you “the minimum number of nodes must include the current number”, so rather than just automatically adding a new node (a la AWS, and I presume GCP), you have to force the cluster to scale up to the new number of machines by throwing workload at it, then make the change. AWS has a single Python package called “Boto3”, from which you can do pretty much everything. Microsoft in their infinite wisdom has a separate Python package for every service, and sometimes subset of service. Do you know whether you need the package for Storage Accounts, File Share, Share Accounts, Object Store or whatever else they had? Also, authenticating against these was a pain: sometimes you need a key provided by the service (let’s hope your permissions let you see that), sometimes you need to generate a service principal for your app (unless there is already one? In which case it’s listed in the UI, but nowhere you’ll find it, and certainly not under “service principals”, and you probably won’t have the permissions to see the information you need anyways) and then sometimes you need both! Azure let us spin up a K8s cluster on a version of 1.18, but then didn’t let us scale the cluster a few weeks later, because apparently that version just didn’t exist, so we should either use 1.17, or update to a newer version of 1.18, but you can’t skip point-releases, so you’re going to have to update everything in your cluster before you can have another node.
- recursive 6y agoThe type system in typescript is a lot more advanced than the one available in C#.
- layoric 6y agoInterested in what you mean by 'lot more advanced'? The optional nature of the typing can be very useful for the web for sure. From my experience that same flexibility means you can't do as much reflection at runtime as in .NET but I have been for the most part away from typescript for last couple of years, so be interested in any resources around this subject.
- recursive 6y ago* Structural types rather than nominal * Type unions and intersections * Type guards * `keyof` operator * String and number literal types See https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... for more. There are a lot of utility types in the standard library that could not be expressed in C# as well. Reflection is very different. It kind of still exists, but in a very different way.
- seanmcdirmid 6y agoIt isn’t really more advanced as it is different. What typescript achieves with structural typing it loses in terms of good error messages and the encapsulation benefits of nominal typing. I’ve gotten used to typescript, but I still enjoy using C#. Some things I really miss in C# (limited operator overloading) that will never come to typescript (not because of the type system, but because of javascript source compatibility).
- WorldMaker 6y agoSome things like conditional types and string template literal types start to get way out into abstract type land that is certainly more advanced than C#'s type system. Typescript is inching closer and closer to the Haskell-ish land of turing complete type systems where the type system itself is nearly it's own meta-programming language with each version. (A recent example was the "SQL engine" written using string template literal types to type safe "query" an in-memory database. That's quite more advanced than anything C# is capable of, albeit a strange hack and unlikely to be specifically something useful in production anytime soon, though still built out of things that make Typescript useful to some JS projects.)
- henrikschroder 6y agoMicrosoft has always, always been awful at naming things, and all the intermediate steps in this unification have all been terribly named. However, this unification removes all the intermediates, which means they can simplify the naming as well. Let's hope they can stick to it...
- kqr 6y agoYeah, this is a big problem. I wanted to understand the differences between just C#, F#, .NET Standard, .NET Framework, and .NET Core, and it took a somewhat long article[1] just to figure that out! [1]: .NET on Non-Windows Platforms, a Brief History. https://two-wrongs.com/dotnet-on-non-windows-platforms-brief-historic-summary.html https://two-wrongs.com/dotnet-on-non-windows-platforms-brief...
- ripley12 6y ago...and if you’re creating a new class library today, you also need to understand how UWP and .NET 5 fit into the picture! I’m not complaining too much, they are intentionally addressing this fragmentation, but it’s a real mess for newcomers.