For example, I'm a newly minted C++ programmer as of 2 weeks ago - while the language is not that easy, my biggest struggle was getting everything to compile and link, and I felt like it's in a different class of difficulty.
Another example, while node.js/Typescript is often seen as an easy language, I remember trying to set up webpack+scss+typescript+react+styled components + a zillion other made me very sympathetic towards Mr. Cobain's life choices.
And another thing - I don't get the Microsoft is evil angle - I mean they are certainly no saints, but neither is any other FAANG company.
I feel like 99% of this is the historical perspective. If you dropped a totally new developer into a pure .NET 6 codebase w/ VS2022, I strongly suspect they would have a reasonable time of it.
IMO, senior developers who stopped following tech news are the primary reason the community has to struggle with this perception today. There are shops where legacy .NET Framework 4.x solutions are being spun up today for no reason other than ignorance has taken hold.
Arguably, the marketing disaster is still primarily Microsoft's fault, but I feel the community could do better with listening and adapting too.
I wish! 2 years ago we visited one of our providers and I soon discovered their solution was being actively developed on .net 3.5 and Visual Studio 2008.
To this day I still have to install .net 3.5 on our machines that use their software (.net 3.5 isn't installed by default on Windows 10) so I know for a fact they didn't upgrade.
I think because most of the features come out of customer request >> architecture plans.
As a result, you end up with a billion different weird behind-the-scene links and requirements that didn't have to be that way and consume unnecessary cognitive load when working with it.
I’ve just about mentally broken down, unable to use the pattern matching features, among other features.
That is, blogs, Stack Overflow, code examples, etc.
Most of that is the fault of authors, but presumably you don't want a 20 year .NET veteran to be the only person capable of writing a complete "Hello World"?
As a consequence, the new developer experience feels like the bad old Java days of "Oh, you want too foo? Well, that tutorial is built using the bar framework, which is incompatible with the nubar libraries you have on your machine."
Agree with another comment here that Microsoft needs to clearly cut legacy off + rename, in order to have a future.
At the start you can just translate all the basic C constructs such as classes/structs/methods/for loops/ifs etc. to their C# version (which is extremely similar in nature).
After that you can add C# specifics such as LINQ etc, but it's not necessary to be proficient in the language.
Online snippets of anything you search for invariably just works, I've never had an issue of something being outdated.
I'd be curious to know why you feel that way? I've been doing .NET development for ~20 years (since the original beta) so it's hard for me to see it through a newcomer's eyes.
ASP.NET Core doesn't seem more complex to start with than any other web framework I've tried (most recently actix-web (Rust), Phoenix (Elixir), Django, etc.)
In .NET I find that it's incredibly powerful when you know what you're doing. But there's just so much crap to wade through that I'm just thinking "why isn't this easier?".
The abstractions that .NET throws at you to start developing with it encourages developers to write their own applications as these crazy complex mazes of abstraction too.
Why can't .NET just be simple? Hand me a request with a Stream, give me a Stream to write my response to. That's all a HTTP handler needs to be, whether it's middleware or not. But instead it's just overwhelming.
dotnet new web
then type
dotnet run
and you have a web app running.
If you'd like to edit Program.cs with notepad or w/e (the default text is below, which is incredibly simple).
var builder = WebApplication.CreateBuilder(args); var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
This is what comes to mind to me from GP's mention of crazy abstraction mazes.
For example, `AddMemoryCache() ` gives you a memory cache with the default settings - or you can change them by using the options argument. Request rewriting is really simple too, and even authentication is relatively straightforward.
I get what you mean about "crazy abstraction mazes", but thankfully over the past few years we've been trending away from the madness of ludicrous inheritance hierarchies that were sold as "clean code" and dogmatically hoovered up by junior devs (including me, once upon a time!).
I would agree that bailing on dogmatic 2000s OOP has been an improvement.
But app development isn’t a pretty place where time crunched developers are expected to carefully design complex data structures…..at all.
https://www.hanselman.com/blog/a-net-6-minimal-api-todo-exam...
In fact there is more reinventing the well in go because all the std lib is just that… a library. When you need all the fluff around parsing routes, validating objects, preventing XSRF and a multitude of common solved problems, you have to reach for third party.
I also don't agree that one is 'reaching' for anything, since as soon as you interact with the broader world of interconnected systems, most of the first-party Microsoft things just don't work. They are almost all designed for their own standards that are too different or have to be manipulated too much to be compatible with something else.
Some things don't even exist like a basic Redis client. At that point even a highly experienced Microsoft developer has no choice but to get that non-first-party library.
dotnet tries to do too much by itself and that makes it annoying to use unless you happen to be building what it wants you to build.
I suspect Microsoft wants most developers to throw their hands up and just follow the "hook your app up to our $$$ azure authentication products $$$" tutorial.
The happy path for AspNetCore could be achieved if Microsoft started the entire conversation with "Here's a request pipeline and here's how you add middleware to it". Everything else is some form of abstraction on top of that. You can learn about how to do all of this 1 afternoon if you know what to focus on.
Once you figure out how to get at HttpContext with your services available in that scope, you have the rabbit entirely cornered. Relying on Micrsoft's middleware to do everything for you is how you get trapped in their puzzle box for all eternity.
It has a excellent server (kestrel), a middleware pipeline, routing system and common dispatching patterns like pages, MVC or minimal apis.
It is excellent in every degree of abstraction. Love the basics, go for kestrel. Work with http basics go for middlewares. Want to work with request and response principles and routes go for minimal API. MVC for a bit more structure. Pages for a traditional set. And Blazor Serverside if you love state.
All of this experiences are good.
I would prefer some examples what is bad here! And spare me DI.
To be clear I have .Net experience going back to the beta frameworks in the early 2000’s and have hand held some huge products on the platform from inception to maintenance phase architecturally and infrastructure wise. It’s been a bloody rough ride and I regret every moment of it and wish I’d picked another platform bet. I’ve had the entire stack rug pulled from underneath major projects multiple times and burned months in pointless rewrites due to tech changes and obsolescence. The majority of the open source ecosystem is broken or abandonware and the commercial bits are overpriced, with poor support and barely work. It’s hell.
The only good bit has been being paid by the hour to unfuck stuff which has been profitable.
But that doesn’t give me much confidence when it comes to finding out how to fix things that go wrong.
The Microsoft documentation is garbage, the worst I have seen. But the language and framework are good.
The c# language is now like an Indian train at rush hour. Busy and dangerous. Very easy to shoot yourself in the foot if you don’t know what you’re doing. LINQ and its contract breaking promises are a fun one for example. One interface returning IEnumerable<T> and you’re in big trouble when someone assumes the data is already materialised.
If you are referring to lazy loading, awaiting calls and ToList()..ing them solves that too.
I know I will get crucified for this, but that's what happens in practice.
We're talking a lot about doing something for the environment, it could start with using "fast enough" languages.
Of course we need to find a compromise between performances and ease of use. So I wouldn't abandon .net core for Ruby or Python, but I would for something as performant (or better ofc) but friendlier to use.
Easy to make a simple endpoint for a tutorial, but after building any serious application the other language stacks end up hooking together several large packages and modules just to get the same standard functionality that ASP.NET provides.
I can admit that there are different ways of thinking and different styles for different people and teams and that .NET is a valid choice, and lots of decent software is built with it. But I've chosen to stay away.
I have done a lot of stuff in a lot of languages/frameworks, from electronics to desktop applications to websites and server stuff. Never cared that much about specific technology. It's fine if it gets stuff done is my motto, but I must admit that .NET is my go-to technology. Everything else I touch seems like a huge mess in terms of design, documentation, tools etc. I'm not saying that .NET is perfect, but at least someone spend some time on design before it's release and it has certain consistency that other projects rarely have.
FWIW, I did try to give it a shot with an open mind, but shortly after that project I decided I'm not accepting any more .NET work.
I use these languages every now and then, I just don't have the deep knowledge required to do everything effortlessly and I get frustated by things that people accepted as "the norm" on those platforms. Like the whole depencdecy stuff and node_modules blackhole in node.js, string handling in C++, weird Python syntax etc. People used to these platforms probably don't have an issue with any of this and accept it as a trade-off for some other amazing stuff on that platform that I don't know about and don't appreciate.
You can use C# .NET in a simple, non OOP way.
You can use F# in a functionaly style.
Nobody forces OOP upon you.
Can you expand on this point? What tools Microsoft provides that are the top-of-the-crop right now?
When I need to write advanced SIMD code, or consume C libraries like FreeType designed to be hostile towards FFI, I often make C++ DLLs to be consumes from C#.
Unlike Rider, Visual Studio is not just .NET IDE, it's a C++ IDE as well. The two debuggers are integrated too, it's easy to debug both C# and C++ at the same time.
90% of my use would be to open and read/write files, read from stdin and argv, regex, maybe some http requests and math no heavier than the occasional integral or limit.
About programming, most of the things you have mentioned (except integrals and limits) are in the C# standard library. Here’s a few tips.
Be sure to handle exceptions in your Main(). On Linux, I usually printing messages into `Console.Error` stream and returning a non-zero status code. Without the top-level try/catch in the main, unhandled exceptions crash the process with no information about what happened.
Set <CheckForOverflowUnderflow>true</CheckForOverflowUnderflow> compiler switch in all your *.csproj files. It causes the runtime to detect integer overflows and throw exceptions in runtime when it happens. It’s very useful to debug things (exceptions come with stack traces, if you keep the *.pdb files they will even contain source file names and line numbers), but I usually keeping the setting in release builds too, for a bit of extra safety. The performance overhead is negligible on modern computers.
About the I/O, use modern APIs, the usability’s better. For instance, when you need to read a text file line by line, call File.ReadLines() method, returns a lazily-evaluated sequence of these lines. Also, modern .NET supports spans pretty much everywhere and therefore you can read/write stack allocated buffers or unmanaged memory. Albeit depending on your use cases, stack allocated buffers might be a premature optimization.
About web request, the standard library has two HTTP clients, older WebClient, and newer HttpClient. For many use cases the functionality is equivalent, pick whichever API you like better. In both cases, I recommend their async-await APIs to make requests. The language supports async main for a few versions now.
I much appreciate the mention of catching exceptions. For my own programs I usually don't catch exceptions because I want the failure to be hard and informative. It seems that dotnet is the exception here.
Don’t abuse LINQ. It’s awesome, but I can only recommend for simple use cases. For advanced ones, too easy to screw up, and too hard to debug. When that’s the case, I’m usually writing a foreach loop instead, and/or generator methods. Also, when I do use LINQ I prefer the C# syntax like `seq.Select( x => x.something )` instead of the SQL syntax `select something from seq`. It’s a matter of taste but IMO compiler is doing too much magic with the SQL syntax.
A few years ago, .NET finally got what MS calls string interpolation. Good stuff, can recommend, I think Python has an equivalent for a decade: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
Most articles on the internets view C# as an object-oriented language. That’s only part of the story. In the typical code I’m writing, at least 50% of code is pure functions (in FP sense) in static classes. And at least 50% of non-static classes are structures (these are value types, an array or List<> of them will keep items at sequential memory addresses, good for performance) with all the fields marked readonly, i.e. immutable types. .NET 6.0 even has record structs now, with automatic readonly.
https://fsprojects.github.io/FSharp.Data/library/CsvProvider...
So if you wait a few weeks to get full support assuming you want an IDE experience and not running everything from the console:
- if you want free (as in beer): Visual Studio Code - if you have a Jetbrains license or don't mind paying for one: Rider
DotNet and C# works fine for all of those things, but it's definitely simpler to get spun up with a Python script for the quick and dirty. DotNet really shines as things get bigger and you need to have more structure.
For huge projects, that verbosity is what makes it maintainable.
There was much mention in this thread of the docs being out of date, referring mostly to older dotnet APIs. Also, by mentioning specific use cases, I was hoping - and got - very specific and helpful recommendations.
It has tons of features missing for Windows development, debugging across .NET languages, C++, COM and WinRT.
Debugging of GPU code, parallel code, integration with mocking frameworks like Fakes, architecture modeling even for files without source available (code maps).
I know I don't.
Most people just responded by not using those APIs or recreating them.
I never felt I was lacking anything in stock Visual Studio and since my company won't pay for anything I never considered Resharper.
Fwiw I have Linux at home and trying Rider (I have used Android Studio before) I much prefer Visual Studio.
At the top right of each window pane is a popup menu that let's you change the window mode, it's that simple.
VSCode kinda works (but also creates a launch.json file somewhere).
Rider just works. If it creates something somewhere, I couldn't care less (as I couldn't care less for any other IntelliJ product which tend to just work).
Also. Obligatory rant by Casey Muratori on Visual Studio: https://www.youtube.com/watch?v=GC-0tCy4P1U
I tried to install a previous version. It started installing, and then ... just failed. With no description of what failed, and how to deal with it.
So eventually I gave up.
WHat's launch.json and where is it described? And why can't it figure stuff automatically like Rider? And why does VSCode create a separate launch.json and why can't the two share the same one?
So many questions, so few answers.
Microsoft overall has a terrible naming sense, with occasional good accidents.
Just rip off JetBrains already.
The branding is honestly trash. I feel like if C#10 and latest .NET framework were renamed to something completely different and relaunched under some new company, we wouldn't go a single day without it gracing the front page of HN.
What % of developers are missing out based on principles alone? Microsoft is certainly an oppressive monster but they arguably produce some of the best tools in town right now.