Making life easier for newcomers to the .NET ecosystem(liamsymonds.com)
liamsymonds.com
Making life easier for newcomers to the .NET ecosystem
https://liamsymonds.com/we-need-to-have-a-talk-about-making-life-easier-for-newcomers-to-the-net-ecosystem/
235 comments
Can we all agree that .NET is just a Microsoft attempt at lock-in to their platform, and actually adds zero value to Windows or the rest of the world?
Start by changing the name. It looks like a file extension or a TLD. Using that name as a folder will make it hidden in Unix. Grepping for it, you need to escape the first character, etc. etc.
That's a trite criticism, by the same argument c++ looks like an instruction.
The name has enough history, it's better to focus on what can be done to improve the ecosystem than worry about a 20 year old name.
The name has enough history, it's better to focus on what can be done to improve the ecosystem than worry about a 20 year old name.
As a programmer who didn't start out in C# it took me many years of hearing .NET being talked about before I started realizing people actually talked about an application framework and not the second largest internet top level domain .net. It is the only technology that I had that problem with, other pieces with a strange name I just look up the strange name and see what it is, but when I saw .NET in a title I just assumed it was about the top level domain, what else could it be?
I think that absolutely matters a lot for the health of an ecosystem.
I think that absolutely matters a lot for the health of an ecosystem.
I had the same problem with Go. For years I couldn't figure out what I was doing to offend people.
My guess is that their aim was to do the same as they did with internet explorer, where many thought that the internet was internet explorer. So with .NET the aim seems to be that people would think that a web server is .NET because the naming makes it seem that way. But it failed and now we live with that confusing name.
> The Microsoft .NET strategy is a marketing plan that Microsoft followed in the early 2000s. Steve Ballmer described it as the company's "most ambitious undertaking since Internet Strategy Day in 1995".
https://en.wikipedia.org/wiki/Microsoft_.NET_strategy
> The Microsoft .NET strategy is a marketing plan that Microsoft followed in the early 2000s. Steve Ballmer described it as the company's "most ambitious undertaking since Internet Strategy Day in 1995".
https://en.wikipedia.org/wiki/Microsoft_.NET_strategy
Everyone I know is calling it dotnet anyway. The frontend for the CLI tools, the package names, the installation directory all use that name.
If you read the title of this article without knowing that .NET was a thing, then you'd likely assume it was about .net the top level domain and how to handle people who want to register a new domain. Or it could be about newcomers to the internet and they for some reason used .net as a short for internet, similar to how .com was seen as short for internet.
The same could be said for anything. If you know nothing about programming and see something about Java, you'd likely assume they're talking about coffee. Don't be ridiculous, we're talking about one of the most-used frameworks in the world here.
What use case would you be looking for the name? Do you name all your Python stuff Python? C++?
Gods, please no more name changes!!?
Microsoft has huge amounts of introductory content: https://dotnet.microsoft.com/learn/csharp
And most stuff steers you towards the `dotnet new` CLI command to get started. Which I hate, I much prefer a .sln file from the get-go but maybe that’s on me. But it’ll get you a .NET 6/C# 10 .csproj in no time.
And most stuff steers you towards the `dotnet new` CLI command to get started. Which I hate, I much prefer a .sln file from the get-go but maybe that’s on me. But it’ll get you a .NET 6/C# 10 .csproj in no time.
We seem to be going in the direction of making it as easy to start as possible, without actually understanding anything. `dotnet new` follow that, with creating a bunch of files that most beginners won't have any understanding of, instead of gently introducing you to each concept, so people understand what they are building inside-out.
`dotnet new` is not a tutorial.
Its no different than the craziness of angular or node or react. All of them follow that pattern now.
I ended up ditching visual studio and solution files though. Vscode and the dotnet cli are a good compromise and arguably more productive than trying to discern what some visual studio wizard just did to your code.
I ended up ditching visual studio and solution files though. Vscode and the dotnet cli are a good compromise and arguably more productive than trying to discern what some visual studio wizard just did to your code.
This is my largest gripe with dotnet. It seems to have been taken over by the front-end web dev types who have done so much damage elsewhere, and are on a crusade to spread their questionable practices.
The churn is getting too fast as they start to get out from under the shadow of continued compatibility with legacy 4.X dotnet. When languages move this fast, the library and tooling ecosystems cannot keep up and you lose one of the greatest advantages that C# had possessed.
The churn is getting too fast as they start to get out from under the shadow of continued compatibility with legacy 4.X dotnet. When languages move this fast, the library and tooling ecosystems cannot keep up and you lose one of the greatest advantages that C# had possessed.
^^ The sad truth. I feel a lot of optimism for .NET due to the still struggling state of cross-platform development but the obsession with front-end web dev is drawing us deeper into a rabbit hole that I think we are all just about done with. We need to be using the same language for the front end and back end. Angular/typescript with node.js for web apps. Want something else? Prove why we need to duplicate all of our data structures and business logic. C# for the UI and back end? Sure. Just make sure to conjure up the $billon of tooling and libraries that we need.
Node's dependency hell makes it a non-starter for me.
"Making it as easy to start as possible" means using IDE tooling. "dotnet new" etc. were bones thrown to Linux and Mac developers who don't have something as comprehensive as Visual Studio for .NET development.
> Linux and Mac developers who don't have something as comprehensive as Visual Studio for .NET development.
We have JetBrains Rider
We have JetBrains Rider
Jetbrians Rider is fully supported under Linux and MacOS and is way better than Visual Studio.
The dotnet cli is an acknowledgement of the fact that an IDE is only part of the tooling story. Software toolchains need to be automatable and based on properly documented formats and conventions, not stuck behind GUIs and undocumented project files like it's the 90s (or, you know, you're Apple).
The dotnet cli is an acknowledgement of the fact that an IDE is only part of the tooling story. Software toolchains need to be automatable and based on properly documented formats and conventions, not stuck behind GUIs and undocumented project files like it's the 90s (or, you know, you're Apple).
The .NET team has their reasons. Before they were bound with the hip to visual studio. That time is over and freed them to do bigger things!
I thinks it's easier to engage new people into your technology with this approach.
Once they're hooked on, they'll have to learn the details. I don't know if you're old enough, but Rails got a nice momentum with their 'Blog in 15 minutes'.
Once they're hooked on, they'll have to learn the details. I don't know if you're old enough, but Rails got a nice momentum with their 'Blog in 15 minutes'.
They are chasing the Python and JavaScript devs, optimizing for "Hello World".
From my point of view, they are chasing the wrong carrot.
From my point of view, they are chasing the wrong carrot.
I felt the same way ... But when you look in DSL experiences like SwiftUI their global/implicit usings and other SDK experiences it is actually also benefitial for other cases.
Except as soon as one does any serious project, those minimal APIs will need to be controllers, unless one loves lambda spaghetti.
And since they now optimize VS templates for hello world, that code needs to be manually written.
And since they now optimize VS templates for hello world, that code needs to be manually written.
To be straight: I also do not like the new templates. Thinking only newbies is not the right thing.
But there language features i like
But there language features i like
[deleted]
`dotnet new` gets you up and running in an editor like VSCode - my assumption is that if you're using a solution file you're using an IDE that creates it for you. You can also use `dotnet new sln` and then `dotnet sln add` to solve your sln problem. It's 3 lines, so it's a bit more typing, but it's still a pretty quick problem to solve.
> And most stuff steers you towards the `dotnet new` CLI command to get started.
The focus on CLI seems to steam from the new blood on .NET teams, long are the days of "Developers, Developers, Developers" with nice graphical tooling.
The dotnet CLI has the means for creating and maintaining solution files as well, for example:
`dotnet new sln
dotnet new console --output folder1/folder2/myapp
dotnet sln add folder1/folder2/myapp`
will result in something more like the new project experience from Visual Studio.
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-sl...
`dotnet new sln
dotnet new console --output folder1/folder2/myapp
dotnet sln add folder1/folder2/myapp`
will result in something more like the new project experience from Visual Studio.
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-sl...
This doesn't make sense. The blog seems to be annoyed at how .NET is managing to push out new features whilst still support decades of corporate code.
Their biggest gripe seems to be that Rider's default templates still have old references, and how they "might" follow a tutorial incorrectly that might not work and dishearten a new user so much they give up on the whole language, all the while overlapping the definition between ASP.NET and C# (which of course, could be improved, sure).
Their biggest gripe seems to be that Rider's default templates still have old references, and how they "might" follow a tutorial incorrectly that might not work and dishearten a new user so much they give up on the whole language, all the while overlapping the definition between ASP.NET and C# (which of course, could be improved, sure).
It's a pretty poor and very short article
Very few languages throw away syntax or features. Python 3 is one that tried, and it took almost a decade for people to switch. C++ famously clings on to old features for a long as possible. Only a tiny amount of things have ever been removed from the language such as trigraphs.
Getting productive and happy in the .NET ecosystem has a learning curve similar to that of Eve Online. There is this amazing world locked away behind a byzantine matrix of legacy bullshit. You could waste an entire month struggling with differences between legacy framework and new framework tutorials.
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.
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.
> Microsoft is certainly an oppressive monster but they arguably produce some of the best tools in town right now.
Can you expand on this point? What tools Microsoft provides that are the top-of-the-crop right now?
Can you expand on this point? What tools Microsoft provides that are the top-of-the-crop right now?
Visual Studio. Always has been. And the base class library of .net.
Did you actually try the alternatives? If we're talking about dotnet specifically, then Rider? It's miles ahead of VS in every way that I can think of. I don't personally know a single dotnet developer who kept using VS after trying out Rider for a few weeks.
I did. I tried Rider and continued to use VS when I was programming on Windows. On Linux I use Rider (though I'm mostly off. Net stuff now). Reason for using VS is because I like it's UI (like the colour scheme more) and I think there are at times issues with resolving dependency issues like nuget stuff (which is what my colleague told me who is a fulltime rider user but fires up VS rarely to resolve them). I haven't tried things like parallel stack watches, debugging dlls and remote debugging. I just liked these things the way they are in VS. Though I'd rank Rider higher than VS since it runs on Linux.
VS's windowing system is better than Rider's. I often use VS with a layout which takes up two full screens (editor on one and Tests Explorer/Solution Explorer/Output Window/Find window etc on the other). I haven't yet found a way to replicate this in Rider.
I use Rider, and often have a code editor on my main monitor, debugger at the top of my secondary monitor, and tests at the bottom of my secondary monitor - it all works great.
At the top right of each window pane is a popup menu that let's you change the window mode, it's that simple.
At the top right of each window pane is a popup menu that let's you change the window mode, it's that simple.
It depends on what you're doing; Visual Studio with ReSharper is still very good (as long as you have a beast of a machine).
Every time there is a new version of Visual Studio I try and use it for as long as possible before I give up and install ReSharper. So far VS 2022 looks like it might be good enough without it.
I'm using Visual Studio without Resharper since 2009. What did I miss? :p
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.
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.
Visual Studio with Roslynator (free, needs less resources)
> It's miles ahead of VS in every way that I can think of
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.
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.
As a Linux user, what do I need to experiment with .NET 6 to replace Python for mostly simple file processing?
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.
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.
Can’t recommend a Linux IDE. I develop quite a lot of .NET for Linux lately, but I’m using a Windows computer with visual studio 2019 to compile and debug. Only using the runtime on Linux to test things, with printf debugging when needed. Still, quite a few people on the internets, in this thread even, are saying Rider is actually good.
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.
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.
Perfect, thank you. I do love the Jetbrains IDEs professionally, but its an expensive purchase for occasional use.
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.
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.
Couple more things.
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.
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.
Depending on what kinds of files you read/write, you might want to take a look at F#'s type providers.
https://fsprojects.github.io/FSharp.Data/library/CsvProvider...
https://fsprojects.github.io/FSharp.Data/library/CsvProvider...
Right now you probably can't experiment coding with .net 6 on Linux (I'm not sure with VSCode but it didn't work for me last week with Rider so I'm still on .net 5).
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
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
You're probably better just sticking with Python if that is all you are doing.
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.
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.
Thanks. I just figured that text scripting, which I do often enough, would be a good foot in the door. I'm not looking for a better Python replacement, rather, I'm looking to get familiar with dotnet with a small project that I would be doing anyway.
Absolutely no reason. I prefer .NET over Python, but for your use case, there is no point, and .NET might be a downgrade since it's more verbose.
For huge projects, that verbosity is what makes it maintainable.
For huge projects, that verbosity is what makes it maintainable.
My mindset is to experiment and become familiar with .NET. Python is great and I can continue to use it, but I see text processing as a low barrier to entry way to get familiar with a new tech.
Downloading .NET 6, a text editor and reading docs?
Yes, of course!
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.
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.
And Rider is not just Rider, it's based on the IntelliJ platform that can also support multiple different languages, including C++, Python, Java and so on.
Miles ahead only for those that don't know how to use VS properly.
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).
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).
Those latter things (COM, WinRT) are gated behind the enterprise license, IIRC. Most people will not have cause to want them.
I know I don't.
I know I don't.
Any serious Windows developer will.
They're a sign of dated tech. Nothing modern necessarily needs them. I know how to use them and I can respect the design, but pay gating them for so long has made them irrelevant.
Not only those things aren't gated, they are the modern APIs on Windows since Longhorn, they are only irrelevant if you are stuck on Windows XP.
The developer tooling was pay gated until VS2019 or something. You needed this tooling to make use of the APIs in a reasonable way, or alternative tooling.
Most people just responded by not using those APIs or recreating them.
Most people just responded by not using those APIs or recreating them.
Some would argue VSCode is there as well. I know a lot of my coworkers swear by it.
I personally don't like it at all. I use it to write Azure Cloud Functions, but I use WebStorm for Angular/React dev, even though I am used to Visual Studio for .NET.
But its not an IDE /s
Tried Visual Studio 22 Preview. It couldn't run a debugger because "property program isn't defined". Apparently you need to specify some launch.json file god knows where, and god knows why.
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
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
Why not the stable version (2019) instead of a literal preview...
I'm on a Mac, so decided to give it a try. It's an interface overhaul, why wouldn't it be able to launch something though?
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.
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.
Visual Studio for Mac is a completely unrelated product that happens to share a name; when people say Visual Studio without any qualifiers they _probably_ don't mean the Mac version.
Microsoft overall has a terrible naming sense, with occasional good accidents.
Microsoft overall has a terrible naming sense, with occasional good accidents.
Visual Studio is Windows only. VS for Mac is an unrelated program which used to be named Xamarin Studio.
2022 launched last week along side the production .NET 6 launch
Ugly bloated eye-sore. Pardon my language.
Just rip off JetBrains already.
Just rip off JetBrains already.
I use Visual Studio on a daily basis and I abhor it. It is hard to navigate without a mouse, things are shoved in small boxes and requires a lot of clicking around. But my coworkers love it so it must be a subjective thing, right? The amount of bugs make me hesitant to ever upgrade when I get a stable version. VS 2018 is riddled with UI bugs. One of them that is annoying me is the basic functionality for undo, text no longer focuses on the latest undo chunk and you don't know how far you got.
> Getting productive and happy in the .NET ecosystem has a learning curve similar to that of Eve Online.
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.)
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.)
I can open a file in notepad and get a high performance HTTP server spun up and responding in under 10 lines with Go. With a simple single function abstraction around what can modify the incoming request and what can write to response.
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.
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.
In .net 6 you just run the command -
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();
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();
Right. I don't know if this changed significantly with 6, but my experience from previous versions have been that as soon as you start adding things like caches, authentication middleware that interacts with certain other components, or rewrite requests or responses in other ways it soon becomes a goose chase across the web and incomplete documentation.
This is what comes to mind to me from GP's mention of crazy abstraction mazes.
This is what comes to mind to me from GP's mention of crazy abstraction mazes.
A lot of this stuff was fiddly a long time back, before dotnet core, but it's all pretty sweet these days.
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!).
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!).
It does get a little complicated when you try adding in the middleware components, and it doesn't Just Work. Frequently then you end up at some GitHub readme file as the only documentation (for first-party Microsoft components) with some very brief examples, maybe with some samples that don't quite show how you'd want to do what you want to do. Then you start digging in the source code and learning how the guts of aspnet core work.
I would agree that bailing on dogmatic 2000s OOP has been an improvement.
I would agree that bailing on dogmatic 2000s OOP has been an improvement.
I think The command and observer aspects of WPF are really elegant and OOP patterns certainly have their place.
But app development isn’t a pretty place where time crunched developers are expected to carefully design complex data structures…..at all.
But app development isn’t a pretty place where time crunched developers are expected to carefully design complex data structures…..at all.
How much boilerplate and configuration does "dotnet new web" generate?
That was the entire source code. There is a project file, but it's incredibly simple and they are meant to be human consumed/edited nowadays.
.NET 6.0 minimal APIs allows you to do just that:
https://www.hanselman.com/blog/a-net-6-minimal-api-todo-exam...
https://www.hanselman.com/blog/a-net-6-minimal-api-todo-exam...
This was my observation. 50 lines of Go translate to 500 lines of .NET. All based on assumptions of what proper OOP and SOLID should be, things that I neither need nor care about when 50 lines of simple code could get me there.
Perhaps you have the old view of .NET?
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.
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 need surprisingly few 3rd party packages to build projects in Go. Most if not all of them are in the "nice to have category". Also, I've seen more then a few .NET projects now and they all had 3rd party packages installed as well. Perhaps it's possible to build without 3rd parties but how many real world projects are built this way?
You make it sound like everything has to be first party (i.e. a locked-in ecosystem).
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 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.
asp.net core is a clusterfuck of over-architecture and over-abstraction.
A lot of the asp.net core configuration nonsense can be entirely sidestepped, but the way in which you would do this is not published as a headline article or otherwise made clear to the developer.
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.
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.
[deleted]
This is so not true. It is the opposite of a clusterfuck. The old ASP.NET was a clusterfuck.
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.
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.
This. I have to support it in production among other platforms. It’s painful to reverse engineer the stack every time something goes bang which is often and usually something utterly obscure. It also has a much higher amount of hands on work required to keep the plates spinning than any other platform I’ve used.
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.
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.
You are talking about the old asp.net, not the Core one? Because I do not recognize any of this. I find asp.net core, especially 5 and 6, rather trivial to handle vs a lot of other products running in production.
Both. Core is probably 50% less painful but it does some weird stuff sometimes including GC problems and a wonderful issue we have where it just does an exit(0) intermittently.
Sounds like your developers might be doing the damage themselves. I run a lot of .NET Core/.NET 5 applications, and I've experienced none of those issues.
Quite possibly. I don’t disagree with that.
But that doesn’t give me much confidence when it comes to finding out how to fix things that go wrong.
But that doesn’t give me much confidence when it comes to finding out how to fix things that go wrong.
I just talked to a bunch of Python engineers who feel that way. They didn't have a single solid argument - what's yours? .NET is a bit verbose, but there is a clarity that comes with it.
The Microsoft documentation is garbage, the worst I have seen. But the language and framework are good.
The Microsoft documentation is garbage, the worst I have seen. But the language and framework are good.
Python is just as horrible. It’s ok for a bit of automation with system packages but the moment you end up with a venv it starts getting painful. I have seen much criminality rammed into AWS Lambda for example.
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.
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.
This isn't an excuse or an explanation, but in prod, most devs ToList() any async calls / anything using IEnumerable. They don't want to think about the nuance and have the additional methods available on the List interface out of the box. Seems to be a decent convention, since the performance diffs between IEnumerable and IList are miniscule for paginated 20-record calls that are 99% of Line-of-Business apps.
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.
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.
Ms docs, as in msdn documentation? Nothing's perfect, but actually covering almost every single class it's better than what other languages normally offer.
What would you recommend that is fast enough (ie not Ruby or Python)?
I’m hedging my bets on lots of small bits of well decoupled and well designed Go with micro frontends in JS sitting on top of Kubernetes. It sits in the niche area of being typed, quite fast, light weight, reliable, fast startup, decent tooling and concise enough to be able to build knowledge and retain it.
If all you're doing is web dev, Ruby and Python are both more than fast enough.
Imagine how much less compute capacity we would need if Ruby and Python were as fast as .net core.
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.
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.
In that case, the elephant in the room is of course Javascript ;) It can be up to 50x faster than python or ruby.
A single RDS instance and a handful of web servers can handle hundreds of millions to low billions of requests a month with last byte responses under 200-300ms.
How so? It's about as lean as it gets. It also provides so much standard functionality which is where other frameworks fall down.
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.
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 was a C# dev from 2004 to 2010. It's a nice language and .NET is (was?) quite pleasant. So I often think about switching back to a C# job. But every time I realize I gotta wade through all of this stuff it really turns me off and I still haven't fully made the leap. Maybe one of these days. I do think understanding all this legacy and getting up to speed would be worth it for me.
As a joke, I'd love to see someone create a landing page of a "new" language with some eye-catching name similar to Kotlin, except it's all C#. I could easily see that hitting the top page of HN.
Cotlin?
That reminds me of the "Mojave Experiment" where Microsoft demoed the new version of Windows and after people said they liked it they revealed that it was just the same Windows Vista that people thought they didn't like.
https://en.wikipedia.org/wiki/Mojave_Experiment
https://en.wikipedia.org/wiki/Mojave_Experiment
D♭
I landed on a team that does .NET. They're using the latest dotnetcore stuff. I've worked in various frameworks in many different languages and I can say that from my perspective, the Microsoft ecosystem is the most nihilistic, un-fun, fiddly environment I've ever had to use. The guys that always try to sell it to me never seem to have much exposure to anything else.
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 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.
What is the exact opposite then? What is "fun" these days? :) Am I boring? :)
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.
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.
Not that I need to have fun but .NET is the opposite of fun to me, in other words, painful. I'd rather not split hairs on what's right or wrong but the maximal OOP style of .NET's structure is just not for me. There's so much boilerplate that I don't need in other frameworks, and from what I've experienced, I'd need to buy in completely to the tooling and ecosystem to become productive, which means Visual Studio or similar IDE. In terms of functionality, the project I was last contributing to in .NET would have been much smaller and simpler in Go, Python or Javascript for the same set of features. I've built so many CRUD apps and APIs now that I can whip out these kinds of projects quickly with nothing more than a text editor. I just can't see any upsides for me to jump into .NET now.
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.
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.
In the end isn't the biggest difference the knowledge and experiences we have gathered over the years? I have no problem writing C# code on Raspberry Pi using terminal and simple nano editor, but I would have to google quite a bit if I was supposed to do the same stuff in Python, JavaScript or C++.
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.
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.
>the maximal OOP style of .NET's structure is just not for me
You can use C# .NET in a simple, non OOP way.
You can use F# in a functionaly style.
Nobody forces OOP upon you.
You can use C# .NET in a simple, non OOP way.
You can use F# in a functionaly style.
Nobody forces OOP upon you.
If I were working by myself on a project, I could make those choices. Unfortunately it's not the common approach to take, nor is it really the documented / recommended way.
But ".NET core" is "dead". The latest is .NET 5 or even .NET 6 (bleeding edge).
I left that team a couple of months ago but keeping all the different iterations of .NET separate is one of my gripes. The documentation is some of the worst I've ever seen and I simply have no patience for it when I have so many other tools that I can use to get the job done with less friction.
I just don't get why .NET is percieved as having a high learning curve - I mean it's probably non-trivial, but I hardly think getting into any other complex tech stack is easy.
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.
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 just don't get why .NET is percieved as having a high learning curve
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 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.
> There are shops where legacy .NET Framework 4.x solutions are being spun up today for no reason other than ignorance has taken hold.
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 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.
That's understandable - I've just very recently had the 'privilege' of fixing something in a .net 4.5 project - everything, from the tooling, the testing, the baroque xml project format felt super complex, Visual Studio-centric and a huge downgrade from what I'm used to nowadays.
Microsoft has a bizarre habit of overcomplicating every@&$1ing thing in their ecosystems.
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 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.
> There are shops where legacy .NET Framework 4.x solutions are being spun up today for no reason other than ignorance has taken hold.
I’ve just about mentally broken down, unable to use the pattern matching features, among other features.
I’ve just about mentally broken down, unable to use the pattern matching features, among other features.
I think the basic problem boils down to this: poorly (or completely lacking) version and dependency references in external documentation.
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.
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.
This isn't remotely true. Any person that has learned for example C/C++ can be productive in a week of having picked up C#.
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.
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 don't get where you're coming from: last week I upgraded a WPF .net 4.6 project (probably from 2017) to .net 6 without a glitch except of course the things I wanted to change (I moved all database calls to Dapper), while reopening a very simple Flutter project made in January this year I find a few deprecated things that needs to be corrected.
That's a weird perception - in my experience, .NET APIs have largely remained stable, at least when going back like half a decade. It's nothing compared to the node ecosystem, where yearly breaking changes are common, and looking at ta 5+ year old project, you'll see that the popular libraries for every problem used to be different.
Barrier never has been lower: downloading the SDK, creating a folder, running dotnet new console, then dotnet run. Editing Program.cs then back at dotnet run. I don't know of any language where it's as easy to get started. Also VS Code has a semi-decent support of C#.
Then you don’t know many languages.
Argument better instead of dumb personal attack. I've used/tried a bunch of languages: C, Erlang, F#, PHP, C++, Java, JavaScript, OCaml and Ruby and all had more steps to create and run an executable. Only PHP and JavaScript are simpler if and only if not using any framework.
If not knowing many programming languages is an insult to you, especially considering how many languages there are that refute your claim.. then you need to check your ego.
PHP is way more complicated because you have to deal with apache, php.ini and what not.
gcc is included in most Linux distros so you don't even need to download anything
Not sure how it can be any easier than gcc main.c && ./a.out
Not sure how it can be any easier than gcc main.c && ./a.out
To be fair, on Linux, getting started with dotnet is actually easier than other languages. The packages provided by Microsoft allows to install multiple version of dotnet side by side and then you can choose which one to use project by project. This is a big improvement compared to rust or python where you have to install and learn third party tools.
rustup is not a third-party tool. It allows you to install any number of Rust toolchains for any number of architectures side by side (be it stable or nightly).
The issue with rustup is that it's not integrated in my distro package manager, unlike the dotnet packages.
It's easier to start in Python because you don't need to run dotnet new. Same with Java, you can just run java program.java and it works.
I think the dotnet approach is definitely preferable for real projects, though. If you want to get a script done in Python then that's quick and easy, but if you need to manage dependencies, you run into the exact same pattern.
Whether it's cargo new, python -m venv ., npm init or whatever incantation Java developers use, all these toolsets are pretty much equivalent. With IDE support (Visual Studio is great, VS Code works) the entire experience becomes much better.
You can't run a quick "helloworld.cs" without creating a project, but I don't see that as a problem per se. In practice, C# isn't built for scripting so it doesn't make sense to optimise the toolchain for anything but a project approach. If you want dotnet scripts, run Powershell, that's what it's good for.
The most annoying part about dotnet is the setup, specifically ensuring that telemetry is off. Microsoft insists on an opt-out, and leaves it up to you to figure out where to put the environment variable to disable their stalking. Other projects such as Flutter have the same problem.
I think the dotnet approach is definitely preferable for real projects, though. If you want to get a script done in Python then that's quick and easy, but if you need to manage dependencies, you run into the exact same pattern.
Whether it's cargo new, python -m venv ., npm init or whatever incantation Java developers use, all these toolsets are pretty much equivalent. With IDE support (Visual Studio is great, VS Code works) the entire experience becomes much better.
You can't run a quick "helloworld.cs" without creating a project, but I don't see that as a problem per se. In practice, C# isn't built for scripting so it doesn't make sense to optimise the toolchain for anything but a project approach. If you want dotnet scripts, run Powershell, that's what it's good for.
The most annoying part about dotnet is the setup, specifically ensuring that telemetry is off. Microsoft insists on an opt-out, and leaves it up to you to figure out where to put the environment variable to disable their stalking. Other projects such as Flutter have the same problem.
> It's easier to start in Python because you don't need to run dotnet new.
Running `dotnet new` is optional, it outputs a template "hello world" program source. It's a "yeoman" kind of tool.
I can't think of any language (python or java included) that works without at least 1 line of source code present.
Running `dotnet new` is optional, it outputs a template "hello world" program source. It's a "yeoman" kind of tool.
I can't think of any language (python or java included) that works without at least 1 line of source code present.
You can just download a JDK, and gradle, and achieve the same thing for Java or Kotlin.
Having worked on .NET frameworks up to 4.5, and then vaguely following the evolution of C# since then, it certainly seems like a "new language" in many places.
The trouble is that you can still write code in the original language, e.g. don't use the elvis operator or Linq or '?.', which is what is likely to happen if you write a lot of code in other languages too - C++, Java, Kotlin, Python, Javascript. There's a common 'subset' language in all of those that's easy to carry mentally from one to another.
One thing that Intellij/Kotlin has is that if you write "old fashioned Kotlin", there are a lot of IDE inspections that can convert that "old style" code to sort-of idiomatic Kotlin.
The trouble is that you can still write code in the original language, e.g. don't use the elvis operator or Linq or '?.', which is what is likely to happen if you write a lot of code in other languages too - C++, Java, Kotlin, Python, Javascript. There's a common 'subset' language in all of those that's easy to carry mentally from one to another.
One thing that Intellij/Kotlin has is that if you write "old fashioned Kotlin", there are a lot of IDE inspections that can convert that "old style" code to sort-of idiomatic Kotlin.
One of my pet gripes of android development is finally accepting a tool upgrade to android studio, only to have it suddenly complain your coding style got deprecated and your warnings become a sea of yellow down the side.
Its infuriating. Give me that C# approach any day.
Its infuriating. Give me that C# approach any day.
Visual Studio and Rider/Resharper has that for C# too.
I know about Resharper, but I haven't fired up Visual Studio since 2015 (I think...) so I have no idea what the built-in refactorings are like these days.
VS's built-in refactoring capabilities are very resharper-like. I haven't used resharper for the last decade. There's no need (for me). Resharper's constantly crashing and/or taking up too much resources while it's doing its "solution wide analysis" in the background, causing many a crash, is not something I miss.
VS debugging is a bliss. immediate window: god sent.
Does VS crash five times per week. Yes. And it sucks every time. And do I swear upon my late father's grave I will migrate away from .net and devote the rest of my life to destroying MS? Also yes.
Then all of a sudden a critical bug is found in production that I can reproduce perfectly, locally, and fix seamlessly and I forget about my mission.
VS debugging is a bliss. immediate window: god sent.
Does VS crash five times per week. Yes. And it sucks every time. And do I swear upon my late father's grave I will migrate away from .net and devote the rest of my life to destroying MS? Also yes.
Then all of a sudden a critical bug is found in production that I can reproduce perfectly, locally, and fix seamlessly and I forget about my mission.
I remember when I picked up 2019 I found it was much better than previous versions that I used. (In terms of refactoring and other coding assistance)
I'm a newcomer, having been forced to use .NET for work. I really wanted to keep an open mind. But I really can't recommend .NET for web development to anybody. Performance is really the only benefit, and that only gets relevant if you can circumvent or take all the downsides. I really like F# as a language, but C# doesn't really do it for me.
Everything else I've seen is very far behind Django/Python and probably PHP, Ruby, Go and Java, though I have less familiarity with those. Documentation and ecosystem certainly. EF as an ORM is a disappointment. Writing REST APIs is at least five to ten times as cumbersome and a lot more annoying. And I have to struggle a lot more to find libraries and support.
And it's not just a problem of being anti-Microsoft. Microsoft is running the show and can decide virtually anything (but not everything). You have to be Ok with that, whatever that means for you and your business.
Everything else I've seen is very far behind Django/Python and probably PHP, Ruby, Go and Java, though I have less familiarity with those. Documentation and ecosystem certainly. EF as an ORM is a disappointment. Writing REST APIs is at least five to ten times as cumbersome and a lot more annoying. And I have to struggle a lot more to find libraries and support.
And it's not just a problem of being anti-Microsoft. Microsoft is running the show and can decide virtually anything (but not everything). You have to be Ok with that, whatever that means for you and your business.
This is really interesting to me. I was also forced to use .NET for work a few months ago, but coming from Python, I found that I tend to like rather than dislike most of the differences between the ecosystems.
The whole ordeal with the enterprise application structure was a hassle for me to begin with, but after some mentoring and guidance from a senior developer, it all made sense in the end, and I started to apply the same kind of structure in my Flask projects.
What is it that you found C# to be lacking in compared to what we're used to in the Python world?
The whole ordeal with the enterprise application structure was a hassle for me to begin with, but after some mentoring and guidance from a senior developer, it all made sense in the end, and I started to apply the same kind of structure in my Flask projects.
What is it that you found C# to be lacking in compared to what we're used to in the Python world?
For me Flask is obsolete. If I want a feature-rich web framework I go with Django, if I want (more) performance and simplicity, I go with FastAPI.
Comparing .NET to Flask is much easier on .NET, since it doesn't have all those Batteries included and yet doesn't reap the benefits from an async/type annotation approach like FastAPI.
Comparing .NET to Flask is much easier on .NET, since it doesn't have all those Batteries included and yet doesn't reap the benefits from an async/type annotation approach like FastAPI.
In general, I miss all the readability, conciseness, documentation, availability of third party packages...
Also Django Rest Framework makes it a lot easier to get up and started.
Also Django Rest Framework makes it a lot easier to get up and started.
Frankly, ASP.NET is just too full of magic.
I forget sometimes how bad and confusing it is because I'm still mostly using NancyFx, which has a much simpler and explicit way of defining routes.
I forget sometimes how bad and confusing it is because I'm still mostly using NancyFx, which has a much simpler and explicit way of defining routes.
Try minimal apis. Is not nancyfx archived?
It is, yes, and because everything Nancy did, ASP.NET Core can now do - it really is a vast improvement over the old ASP.NET.
There is another OSS project, Carter, that builds on the ASP.NET Core goodness, allowing you to define endpoints the same way as you did in Nancy.
There is another OSS project, Carter, that builds on the ASP.NET Core goodness, allowing you to define endpoints the same way as you did in Nancy.
> EF as an ORM is a disappointment
How come? It's one of the few things I'm really missing since switching most of my development work away from dotnet. EF Core + LINQ give you type-safe and very compact queries. I don't think there's anything similar for Hibernate, for example: there is JPA Specification API with metamodel generation. The idea is very similar, but with much more boilerplate.
How come? It's one of the few things I'm really missing since switching most of my development work away from dotnet. EF Core + LINQ give you type-safe and very compact queries. I don't think there's anything similar for Hibernate, for example: there is JPA Specification API with metamodel generation. The idea is very similar, but with much more boilerplate.
Same experience here. Used EF as code-first and structuring queries with LINQ has been a breeze. Really really enjoyed working with it.
There are three problems than an ORM should solve to some degree:
1. Type safety/refactorability
2. Composability (can I reuse my queries)
3. Expressivity (can I generate the queries I want)
Of these, EF only solves the first, which is far and away the easiest of the three.
Composability in EF is possible via expression tree splicing, however it requires such a degree of discipline and insight that I have never seen anyone do it, or even any discussion around it.
Like almost everything in the .NET ecosystem, EF makes a bunch of promises that are fantastic for hello world, but are disastrous as your project grows.
1. Type safety/refactorability
2. Composability (can I reuse my queries)
3. Expressivity (can I generate the queries I want)
Of these, EF only solves the first, which is far and away the easiest of the three.
Composability in EF is possible via expression tree splicing, however it requires such a degree of discipline and insight that I have never seen anyone do it, or even any discussion around it.
Like almost everything in the .NET ecosystem, EF makes a bunch of promises that are fantastic for hello world, but are disastrous as your project grows.
Do you have any specific examples of an ORM that ticks two (or all or three) of these?
It's a hard problem, NHibernate actually came a little bit closer with it's QueryOver API. The most glaring problem with the LINQ API is there is no way to OR two reusable conditions together because the only tool you have is Where.
To be clear you can get a long way by abusing EF's willingness to try and interpret arbitrarily complex expressions - it just provides zero tooling or guidance on how to build those expressions.
Or projections. It's possible to write a reusable projection for EF like so:
To be clear you can get a long way by abusing EF's willingness to try and interpret arbitrarily complex expressions - it just provides zero tooling or guidance on how to build those expressions.
Or projections. It's possible to write a reusable projection for EF like so:
class MyTableProjection {
public static Expression<Func<MyTable, MyTableProjection>> Expression =>
t => new MyTableProjection {
Id = t.Id,
Str = t.Str,
Flag = t.Flag
};
public int Id { get; init; }
public string Str { get; init; }
public bool Flag { get; init; }
}
dbContext.MyTable
.Where(...)
.Select(MyProjection.Expression)
.ToListAsync()
It's pretty easy using LinqKit [1]. Just PredicateBuilder.Or() [2]. If you were to try and implement PredicateBuilder yourself that requires a little more knowledge around expressions, but it's worth learning and opens up a lot more possibilities.
[1] https://github.com/scottksmith95/LINQKit [2] http://www.albahari.com/nutshell/predicatebuilder.aspx
[1] https://github.com/scottksmith95/LINQKit [2] http://www.albahari.com/nutshell/predicatebuilder.aspx
Automapper solves this. Composable projections to your DTOs/ endpoint return types. You can do some very powerful things with it. For example, in a past project I encrypted/unencrypted a property containing a secure message by defining a function to do so and setting up Automapper to automatically apply the function when mapping to/from the DTO that is sent/received by the API.
SQLalchemy is exceptionally good at all of these -- and I'm not even a power user so I don't know all the tricks.
Re: Composability
You can generate something like the WHERE clause of a query in a function and return it alone (rather than as a SELECT query) or even combine it with another WHERE.
e.g. In SA the "select" and "where" portions aren't tightly coupled.
Re: Expressivity
Right now you can easily build up ef.core queries by chaining IQueryable.Where, which is nice but you can only do that for selects and something like OR conditions are difficult to implement.
e.g. in SA you can just pass a list of predicates to the or_() function.
e.g. in SA you can build a WHERE clause and then pass the same clause to a select or a bulk operation.
Re: Composability
You can generate something like the WHERE clause of a query in a function and return it alone (rather than as a SELECT query) or even combine it with another WHERE.
e.g. In SA the "select" and "where" portions aren't tightly coupled.
Re: Expressivity
Right now you can easily build up ef.core queries by chaining IQueryable.Where, which is nice but you can only do that for selects and something like OR conditions are difficult to implement.
e.g. in SA you can just pass a list of predicates to the or_() function.
e.g. in SA you can build a WHERE clause and then pass the same clause to a select or a bulk operation.
For me, the Django ORM was always good enough, EF isn't. Lately, there is also support for type checking I think, but in general, Django is big on validating input data.
The developers have constrained themselves by refusing anything that falls outside of the scope of a strongly typed unit-of-work implementation.
This means we will probably never get: 1. Ability to pull non entity types out of the database without a whole lot of boilerplate. See the bizarre obstinacy here: https://github.com/dotnet/efcore/issues/10753
2. Any kind of bulk insert/delete/update ability. It's been a "to do" for years now.
3. Much better query composability.
Basically their response is to just use raw SQL for anything that isn't a unit-of-work feature. They're missing a lot of benefits that a ORM could provide when they say that.
The ef.core team feels like a lot of rejects that were stack ranked out to their own team. I know that is mean to say, but they iterate extremely slowly compared to teams like asp.net .core, visual studio code, c# language group, f# language group.
This means we will probably never get: 1. Ability to pull non entity types out of the database without a whole lot of boilerplate. See the bizarre obstinacy here: https://github.com/dotnet/efcore/issues/10753
2. Any kind of bulk insert/delete/update ability. It's been a "to do" for years now.
3. Much better query composability.
Basically their response is to just use raw SQL for anything that isn't a unit-of-work feature. They're missing a lot of benefits that a ORM could provide when they say that.
The ef.core team feels like a lot of rejects that were stack ranked out to their own team. I know that is mean to say, but they iterate extremely slowly compared to teams like asp.net .core, visual studio code, c# language group, f# language group.
Go really? Last I checked its impossible to write an ORM in go, didn't even have a way to do dynamic routing that I had to implement my own router using a trie. Please.
There's this.
https://gorm.io/index.html
https://gorm.io/index.html
In my opinion Go and C# scratch one itch in common: being more productive than C(++) but still very performant.
But Go has a philosophy of minimal baggage, which is quite the opposite of C#. If that means you can't build a decent ORM, maybe you either don't need an ORM or Go isn't the right fit for that project.
But Go has a philosophy of minimal baggage, which is quite the opposite of C#. If that means you can't build a decent ORM, maybe you either don't need an ORM or Go isn't the right fit for that project.
What's cumbersome? EF is really great, so i don't know what could be a disappointment.
( I'm using code first fyi)
( I'm using code first fyi)
I find myself writing at least 5-10 times as much code compared to Python/Django. With the Django ORM once you design your models you already have at least 80% of the logic for a CRUD REST API, form validation, CRUD admin interface (if you want that), and you can easily integrate all sorts of third party features for almost no effort. Migrations are a bit saner because of the App separation, data migrations are a possible.
You can achieve nearly the same thing by creating your Entities, generating migration from them with a single command, migrating your db with another one(or from code on startup) and returning them directly from Controller's method using DB Context. It's honestly not that much more work. It's far from a recommended approach though... Granted, Django Admin is pretty nice and although there are few nugets that try to achieve that I never found them as easy as in Django.
At least in the codebase I work on, I need to create an IRequest/IRequestHandler/Validator class triplet for every single endpoint, each in its own files, including all the lines with single braces and using statements for all the magic extension methods and dependency injection constructors. And often I need to add new ViewModels because the mapping doesn't work correctly.
DRF is much more convenient.
DRF is much more convenient.
That's not EF. That's typical cqrs, lol.
Here's a scaffolder as an example if you want to automate things like that: https://github.com/ArmandJ77/CQRSAndMediator-Scaffolding
Here's a scaffolder as an example if you want to automate things like that: https://github.com/ArmandJ77/CQRSAndMediator-Scaffolding
Well this is because you decided yourself to go that route. Amount of work would be the same in Django if you decided on this particular architecture there.
It doesn't change the fact that if you want to do a simple CRUD you can do it equally easy in almost every popular web framework these days, just yolo that shit into your Controller and be done with it. What you're doing is way more maintainable though, especially if you work with an actual team.
I don't think you know it very well.
You need to add the correct attributes to your class for form validation ( eg. Required / StringLength )
Then scaffold a MVC controller or an api controller ( It will add the class to your DbContext)
Then add-migration / update-database for your migration.
And it's done
You need to add the correct attributes to your class for form validation ( eg. Required / StringLength )
Then scaffold a MVC controller or an api controller ( It will add the class to your DbContext)
Then add-migration / update-database for your migration.
And it's done
Which leads us to the topic of documentation and on-boarding. And it's still a ton of more code to write, read and maintain.
? No it's not.
Autogenerated migration files that you don't need to touch and 1 class to describe the model + 1 auto inserted line in the DbContext
Autogenerated migration files that you don't need to touch and 1 class to describe the model + 1 auto inserted line in the DbContext
You can't compare Django to EF Core. Django is more like Visual Studio Lightswitch, which has been killed off.
Angular 12 and .net are nice to use imho. Make services in .net and typescript and angular front end. Perhaps a nice way to get started for web developers.
I suppose you need Entity framework and linq as well to make a full application.
I suppose you need Entity framework and linq as well to make a full application.
Is .NET still a thing?
I used it about 13 years back and it was basically a rip off of all the open source projects at the time.
Hopefully it has matured since then.
I've seen a disturbing amount of rhetoric from people at Microsoft who work on dotnet that aligns with this article. I'm not sure they have a good handle on how much enterprise code is still being written daily in "old dotnet", or if they do, they don't care. But the general sense is that legacy is lame, get with the cool kids on latest. Also we're encouraging OSS to drop support for you if you're on legacy, and we don't have a great upgrade path for you. Shades of the Great Python Split.
I don't really view the new dotnet core/5/6 platform as very stable, not when they are still releasing this often and making breaking changes.
I don't really view the new dotnet core/5/6 platform as very stable, not when they are still releasing this often and making breaking changes.
They release in the same cadence roughly. The difference is they are no longer grindlocked in Windows, VS and bad patterns.
Result: less cloud costs by better performance, capability to run on Linux, lambdas, containers and ability to stay fresh and not turn into Cobol.
I understand where you are. I also have to explain my manager ongoing costs for upgrades. Not only for .NET bit every part of the stack. Luckily we have cyber security as an ongoing excuse.
Result: less cloud costs by better performance, capability to run on Linux, lambdas, containers and ability to stay fresh and not turn into Cobol.
I understand where you are. I also have to explain my manager ongoing costs for upgrades. Not only for .NET bit every part of the stack. Luckily we have cyber security as an ongoing excuse.
Wish there was an easy tutorial for developing and deploying a web app on Linux.
This - https://github.com/EliotJones/LetsShip - hopefully gets you some of the way, it uses VS on Windows for development but I can't imagine the experience in Rider or VS Code for Linux is too disimilar. Individual steps here https://github.com/EliotJones/LetsShip/tree/main/docs/posts
I need to complete the full guide at some point but the end result is an application deployed on Linux with both a web app and independently scalable crawling services with zero downtime deployments. Hosted site here: https://pricefalcon.me/
For a simpler deployment without k3s, this guide is the one I originally followed for my trends site and should still work for .NET 6. https://www.hanselman.com/blog/publishing-an-aspnet-core-web...
I need to complete the full guide at some point but the end result is an application deployed on Linux with both a web app and independently scalable crawling services with zero downtime deployments. Hosted site here: https://pricefalcon.me/
For a simpler deployment without k3s, this guide is the one I originally followed for my trends site and should still work for .NET 6. https://www.hanselman.com/blog/publishing-an-aspnet-core-web...
[deleted]
You don't have to be under an anti-microsoft rock. If you were a VB/WinForms type person - you've been wondering where Microsoft has been going with their desktop ecosystem for AGES now.
Ahh, finally we are told, this new release of .NET solves all the issues. Except when I try to do a simple forms based app with a drag and drop designer (something supported trivially decades ago) it's a constant list of errors, unsupported notices etc.
I'm serious. What's the quickest way to drag a button onto a form that when I click it will change a label text to "hello world" with the new .net desktop platform?
Ahh, finally we are told, this new release of .NET solves all the issues. Except when I try to do a simple forms based app with a drag and drop designer (something supported trivially decades ago) it's a constant list of errors, unsupported notices etc.
I'm serious. What's the quickest way to drag a button onto a form that when I click it will change a label text to "hello world" with the new .net desktop platform?
I feel with you. The last time I tried to use Windows Forms with .NET Core was underwhelming.
What some people don't realize how huge the .NET sector is (at least here in Europe). A lot of businesses and public services are running on Windows Server and their pace is glacial. Our company is still stuck in the Windows Forms world and slowly transitioning to WPF and even though .NET Core has been around for a while it's truly hard to move old code to the new world.
And UI is not the only thing, which hinders us. WCF for example or windows only components (registry or auth-things) are hard to migrate and sometimes require a whole rewrite of some parts. It very much feels like the python 2 to python 3 migration, but the with the risk of Microsoft completely abandoning the old legacy tech in a few years (while python 2 apps could still chug along fine, if you're not in the mood of upgrading).
What some people don't realize how huge the .NET sector is (at least here in Europe). A lot of businesses and public services are running on Windows Server and their pace is glacial. Our company is still stuck in the Windows Forms world and slowly transitioning to WPF and even though .NET Core has been around for a while it's truly hard to move old code to the new world.
And UI is not the only thing, which hinders us. WCF for example or windows only components (registry or auth-things) are hard to migrate and sometimes require a whole rewrite of some parts. It very much feels like the python 2 to python 3 migration, but the with the risk of Microsoft completely abandoning the old legacy tech in a few years (while python 2 apps could still chug along fine, if you're not in the mood of upgrading).
> I feel with you. The last time I tried to use Windows Forms with .NET Core was underwhelming.
I recently opined about the UI story on HN[0] and was met with a lot of 'who cares?'
Which is really unfortunate, in the process of making .NET 'Webscale' we completely forgot about the desktop workflows that brought so many into the language in the first place.
> What some people don't realize how huge the .NET sector is (at least here in Europe).
Yeah, a lot of folks here have no idea. I've come to realize it over the years (interacting with a number of very talented European .NET devs, seeing the variety of tech from Europe/Russia) but a lot of American devs really seem to have their blinders on.
Odd to note, of all the non-Microsoft OSS libraries I knowingly pull into my app, not very many of them have a US origin or majority of contributions from the US. IDK how much of that is mindset vs contracts (i.e. difficulty perceived or real to get approval to work on or make an OSS project) but it's something I've noticed.
> And UI is not the only thing, which hinders us. WCF for example or windows only components (registry or auth-things) are hard to migrate and sometimes require a whole rewrite of some parts
The biggest problem though is that there are -footguns- in upgrading. For example, if your old Web calls were using HttpWebRequest or an abstraction over it (like RestSharp,) all of the old assumptions about it not caching like HttpClient go out the window.
IDK if you tried CoreWCF, but it's a thing. (I have never worked with WCF.) I know it's limited though. I'll admit that I understand why Microsoft made some of these decisions around killing off certain technologies. I -do- wish they would have handled the process better though.
I think one big problem overall though is the community has in many cases not really 'stepped in' to fill these gaps.
This is not to detract from the people that are -trying-. But projects like Avalonia have had a hard time building momentum.
[0] - https://news.ycombinator.com/item?id=29155173
I recently opined about the UI story on HN[0] and was met with a lot of 'who cares?'
Which is really unfortunate, in the process of making .NET 'Webscale' we completely forgot about the desktop workflows that brought so many into the language in the first place.
> What some people don't realize how huge the .NET sector is (at least here in Europe).
Yeah, a lot of folks here have no idea. I've come to realize it over the years (interacting with a number of very talented European .NET devs, seeing the variety of tech from Europe/Russia) but a lot of American devs really seem to have their blinders on.
Odd to note, of all the non-Microsoft OSS libraries I knowingly pull into my app, not very many of them have a US origin or majority of contributions from the US. IDK how much of that is mindset vs contracts (i.e. difficulty perceived or real to get approval to work on or make an OSS project) but it's something I've noticed.
> And UI is not the only thing, which hinders us. WCF for example or windows only components (registry or auth-things) are hard to migrate and sometimes require a whole rewrite of some parts
The biggest problem though is that there are -footguns- in upgrading. For example, if your old Web calls were using HttpWebRequest or an abstraction over it (like RestSharp,) all of the old assumptions about it not caching like HttpClient go out the window.
IDK if you tried CoreWCF, but it's a thing. (I have never worked with WCF.) I know it's limited though. I'll admit that I understand why Microsoft made some of these decisions around killing off certain technologies. I -do- wish they would have handled the process better though.
I think one big problem overall though is the community has in many cases not really 'stepped in' to fill these gaps.
This is not to detract from the people that are -trying-. But projects like Avalonia have had a hard time building momentum.
[0] - https://news.ycombinator.com/item?id=29155173
> But projects like Avalonia have had a hard time building momentum.
That's because they're mainly useful for people who want to make GUIs for Linux or OS X and/or use F# (with Avalonia.FuncUI).
That's because they're mainly useful for people who want to make GUIs for Linux or OS X and/or use F# (with Avalonia.FuncUI).
I am not sure why you are getting these results. The Visual Designer has worked for a solid release. I just did you what you asked in VS2019 (albeit with C#).
File/New Project. Select Winforms App for .NET Core. A new form comes up. Click to Toolbox on the left. Drag a button to the form. Double click on the button to handle the click event.
It's that simple. No errors.
File/New Project. Select Winforms App for .NET Core. A new form comes up. Click to Toolbox on the left. Drag a button to the form. Double click on the button to handle the click event.
It's that simple. No errors.
Interesting, last time I tried doing this I had problems, I will try again.
It's not my experience: last week at work I converted one of my WPF app from .net 4.6 to .net 6 without a glitch.
The only things I had to touch wasn't related to the graphic part.
But to be fair I wrote all the XAML by hand, I never build a UI with the drag and drop tools. I never manage to get the result I want with these tools.
The only things I had to touch wasn't related to the graphic part.
But to be fair I wrote all the XAML by hand, I never build a UI with the drag and drop tools. I never manage to get the result I want with these tools.
Is it that bad? I remember back in the Delphi days it were a few easy clicks.
Software development tools have been going backwards since then.
I was trying out .Net (...or was it .Net core?) the otherday just out of curiosity, thinking about migrating off of golang.
I am still not sure which I need (...or both?) but either way I managed to get neither Visual Studio nor VS Code to get any code to run or compile! I downloaded and installed both SDKs but both failed to work at all - it seems there is some invisible thing configured somewhere (Windows registry? certainly not in the hello world source I was trying to write) that points to the SDK version to use, and neither the .Net nor .Net core SDKs I downloaded appeared to be the correct ones and everything chucks up error messages about the wrong SDK or missing MSBuild (whatever that is), despite just following the tutorials to do `dotnet new`. Very frustrating.
It has certainly put me off trying .net now. I wanted to migrate off of golang for my future cross-platform work, but this has really put me off - if I cant even get a hello world to work after a clean SDK install, I can only shudder to think about what the runtime dependency hell is going to be. Real shame.
I am still not sure which I need (...or both?) but either way I managed to get neither Visual Studio nor VS Code to get any code to run or compile! I downloaded and installed both SDKs but both failed to work at all - it seems there is some invisible thing configured somewhere (Windows registry? certainly not in the hello world source I was trying to write) that points to the SDK version to use, and neither the .Net nor .Net core SDKs I downloaded appeared to be the correct ones and everything chucks up error messages about the wrong SDK or missing MSBuild (whatever that is), despite just following the tutorials to do `dotnet new`. Very frustrating.
It has certainly put me off trying .net now. I wanted to migrate off of golang for my future cross-platform work, but this has really put me off - if I cant even get a hello world to work after a clean SDK install, I can only shudder to think about what the runtime dependency hell is going to be. Real shame.
You don't use .net core anymore. You use .net 5 or the recently released .net 6. When you use dotnet new it will generate a .csproj file, in that csproj file it will specify what frameowrk you are targeting. I don't know what exactly you did but setup of dot net is super easy. I'd try uninstalling everything you tried to install, and install https://dotnet.microsoft.com/download/dotnet/6.0
Note, dotnet 6 only works on VSCode or VS2022, older versions of VS don't support it, so you'd have to drop to dotnet 5.
Note, dotnet 6 only works on VSCode or VS2022, older versions of VS don't support it, so you'd have to drop to dotnet 5.
If you're on Windows just download Visual Studio 2022, it will install everything you need.
I have one core problem with most of the critique here and in the article: show me a 20 year old framework which does better!
Python: which version again, PHP: good luck not doing a kind of injection, Java: Beans? spring? Maven? Gradle?, JavaScript: which 30 packages are currently best of breed, ...
Maybe Ruby. Rails killed all competition.
Ignoring all what I said, the .NET documentation is definitely worth to improve on the aspect of current versus past state. They should color code it :)
Python: which version again, PHP: good luck not doing a kind of injection, Java: Beans? spring? Maven? Gradle?, JavaScript: which 30 packages are currently best of breed, ...
Maybe Ruby. Rails killed all competition.
Ignoring all what I said, the .NET documentation is definitely worth to improve on the aspect of current versus past state. They should color code it :)
- Install .NET 6
- Install Visual Studio Code (you probably have it already)
- Install Ionide extension
- Create a new `.fsx` file
- Start writing code :)
This is by far the quickest way to build something simple on .NET. It doesn't even require a package manifest to pull in dependencies.
And it works on all major platforms.
- Install Visual Studio Code (you probably have it already)
- Install Ionide extension
- Create a new `.fsx` file
- Start writing code :)
This is by far the quickest way to build something simple on .NET. It doesn't even require a package manifest to pull in dependencies.
And it works on all major platforms.
F# is a really, really nice language (it's also one of the few languages that got async right with async workflows: https://fsharpforfunandprofit.com/posts/concurrency-async-an...) with which you can also evade using the XAML stuff for MVU (ELM-style) UIs.
But after the Net Foundation and hot-reload drama https://news.ycombinator.com/item?id=28779342 https://news.ycombinator.com/item?id=28897314 https://www.theverge.com/2021/10/22/22740701/microsoft-dotne... https://news.ycombinator.com/item?id=28972431 I can't really trust MS with anything open source anymore :( https://news.ycombinator.com/item?id=28968231
But after the Net Foundation and hot-reload drama https://news.ycombinator.com/item?id=28779342 https://news.ycombinator.com/item?id=28897314 https://www.theverge.com/2021/10/22/22740701/microsoft-dotne... https://news.ycombinator.com/item?id=28972431 I can't really trust MS with anything open source anymore :( https://news.ycombinator.com/item?id=28968231
yes I had some of the same sentiments as this article and F# recently: https://news.ycombinator.com/item?id=28868104
think dotnet (and especially F#) have a lot of low hanging fruit to make it more attractive to newcomers and easier to onboard.
think dotnet (and especially F#) have a lot of low hanging fruit to make it more attractive to newcomers and easier to onboard.
I have being doing dotnet for at least 7 years now. Started with Webforms being fresh out of university. I'm sad to say I agree with most criticism of dotnet ecosystem. I personally believe MS always want to be in control and that leaves no space for innovation in open source as well. It feels like suffocation at best.
MS took control of javascript community in through typescript and npm. Now most of companies want typescript guy doing frontend in react/angular. Added already one more abstraction to already complex JS ecosystem.
I have used Python recently. It felt like breath of fresh air. Plus IDE are really smooth.
I have nothing against dotnet/C# as language. Its ecosystem that tightly controlled and criticism is shot down quite literally. All important libraries in MS world are locked behind paywall unlike Python, Java, JS, ruby communities. This scene has changed in recent years, but quite it was like that before 2018. Like PDF generation, SSO libraries, tools for profiling.
Anyway I personally think that dotnet should not be once first language/entry into programming career. You will miss innovation open source ecosystem and will be behind for years than your other language peers.
Also dotnet job market has lot of issues, good paying job are required you to either maintain legacy system in SOAP/XML, webservice and what not. Not much of vibrant job market for dotnet i would say.
Apologies for rant.
MS took control of javascript community in through typescript and npm. Now most of companies want typescript guy doing frontend in react/angular. Added already one more abstraction to already complex JS ecosystem.
I have used Python recently. It felt like breath of fresh air. Plus IDE are really smooth.
I have nothing against dotnet/C# as language. Its ecosystem that tightly controlled and criticism is shot down quite literally. All important libraries in MS world are locked behind paywall unlike Python, Java, JS, ruby communities. This scene has changed in recent years, but quite it was like that before 2018. Like PDF generation, SSO libraries, tools for profiling.
Anyway I personally think that dotnet should not be once first language/entry into programming career. You will miss innovation open source ecosystem and will be behind for years than your other language peers.
Also dotnet job market has lot of issues, good paying job are required you to either maintain legacy system in SOAP/XML, webservice and what not. Not much of vibrant job market for dotnet i would say.
Apologies for rant.
One thing that would be beneficial: A version of Visual Studio strictly for .NET 6 and zero backwards compatibility with other versions of .NET. That code has to be so bloated with compatibility in mind that it's 10x bigger (and slower) than it needs to be. And no, VS Code is no substitute for VS.
I completely agree. It's time to leave the legacy of .NET Framework behind forever.
This is Microsoft we're speaking here, backward compatibility is in their canon!
Name it Visual Studio Core.
The responses to this thread are amazing. This video [0] summarizes most opinions about dotnet from outsiders.
[0] https://youtu.be/AFNujHJfMtU
[0] https://youtu.be/AFNujHJfMtU
It's really, really sad the lack of good information people have about just how amazing .NET 6 is. Microsoft needs to jettison the cruft and the legacy; .NET is bigger than just corporations now. There's a huge open-source ecosystem. Places like the C# Discord server (with 24k+ members) exist.
.NET is bigger than Microsoft in some ways. The recent kerfuffle with the .NET Foundation shows that.
Please, Microsoft: invest in marketing, especially to corporations who don't know anything about the tech stacks they use. They need help understanding why .NET 6 is so amazing and why .NET is no longer .NET Framework + ASP.NET Web Forms + IIS.
.NET is bigger than Microsoft in some ways. The recent kerfuffle with the .NET Foundation shows that.
Please, Microsoft: invest in marketing, especially to corporations who don't know anything about the tech stacks they use. They need help understanding why .NET 6 is so amazing and why .NET is no longer .NET Framework + ASP.NET Web Forms + IIS.
This whole release was very smooth with nice features and nice performance improvements. But the amount of (mostly wrong) negative articles and comments is amazing. It was not like that with .NET 5 and before. HN community grew more hostile to .NET in the last year. Do not know why. Maybe the anti Microsoft sentiment grew the last months again.
While being negative press, this article is for the most part right.
While being negative press, this article is for the most part right.
> Maybe the anti Microsoft sentiment grew the last months again.
Yes, it's this. The whole removal of the hot reload from CLI got HN in a tizzy
https://news.ycombinator.com/item?id=28968231
Yes, it's this. The whole removal of the hot reload from CLI got HN in a tizzy
https://news.ycombinator.com/item?id=28968231
> But the amount of (mostly wrong) negative articles and comments is amazing. It was not like that with .NET 5 and before.
Well, because MS didn't screw that (5.0, I don't know about Core 3, haven't been a .Net user at that time) release up. The Net devs inside of MS also didn't, well, appreciate these actions.
But what would be an example of a wrong negative article or comment about 6?
Well, because MS didn't screw that (5.0, I don't know about Core 3, haven't been a .Net user at that time) release up. The Net devs inside of MS also didn't, well, appreciate these actions.
But what would be an example of a wrong negative article or comment about 6?
No .NET Core release was a screw up. 1.x was rough but we were happy about the open source part.
Nothing on .NET 6 is a screw up. So there is no change regards .NET but the mood changed.
Sorry about the wrong articles ... I broke edit that. I was just disappointed by the commentary.
Nothing on .NET 6 is a screw up. So there is no change regards .NET but the mood changed.
Sorry about the wrong articles ... I broke edit that. I was just disappointed by the commentary.
I had years of Java experience when I joined MS and started writing C#. I found the tooling to be generally ickier, and was surprised by a few gaps in the ecosystem. For example, there is nothing (official) comparable to javadoc for C#. Documentation is compiled into XML that is consumed by IDE's, but there is no generic, human-navigable documentation artifact. C# has a dizzying number of keywords that obscure perfectly-fine object-oriented expressions. In general, I found the language to have messier abstractions and a far less-discoverable stdlib compared to Java. Visual Studio is non-negotiable for many C# projects, and I found it to be as bloated as any MS desktop app, not incredibly stable, and I swear I installed a multi-gigabyte update every time I opened it. NuGet is serviceable, but I was surprised at how inelegant dependency management was, even inside the company. Finally, it's an aesthetic thing for me -- Java feels unixy, and C# is Microsoft through-and-through.
edit: one more qualm, the Mockito equivalent for C#, NSubstitute, cannot mock a concrete class, only an interface. This meant that every C# project I encountered was littered with pointless interfaces that had a single implementation, that only existed because of NSubstitute usage in the testing. This seemed to devolve into C# devs writing an interface for damn-near everything out of habit. I'm talking about writing an interface with getters and setters for a POC#O. I still get nauseous thinking about it.
edit: turns out I have a lot to complain about on this Monday! I pray for anyone living under the tyranny of Stylecop rules, which will fail your build if you put a public static field below a private static one, but for some god-forsaken reason cannot actually fix the problem for you.
edit: one more qualm, the Mockito equivalent for C#, NSubstitute, cannot mock a concrete class, only an interface. This meant that every C# project I encountered was littered with pointless interfaces that had a single implementation, that only existed because of NSubstitute usage in the testing. This seemed to devolve into C# devs writing an interface for damn-near everything out of habit. I'm talking about writing an interface with getters and setters for a POC#O. I still get nauseous thinking about it.
edit: turns out I have a lot to complain about on this Monday! I pray for anyone living under the tyranny of Stylecop rules, which will fail your build if you put a public static field below a private static one, but for some god-forsaken reason cannot actually fix the problem for you.
> edit: one more qualm, the Mockito equivalent for C#, NSubstitute, cannot mock a concrete class, only an interface.
I've never heard of NSubstitute (that doesn't mean it's bad), but most places I've worked at typically use Moq (https://github.com/moq/moq4) which does support interfaces and classes.
I've never heard of NSubstitute (that doesn't mean it's bad), but most places I've worked at typically use Moq (https://github.com/moq/moq4) which does support interfaces and classes.
Interesting, I never ran across this at MS. The more you know! Thanks.
What would make the ecosystem better is not to tell everyone to jump like a good little puppy every time Micrsoft squirts out a new release.
I have used .Net since the pre Alpha 1.
The consulting company I worked for needed X number of consultants certified on this new platform thing so they picked a few of us and said that this .Net thing is now us, run to get certified so we can have our super triple gold star parter relationship.
My background was C and C++, Delphi, some Java for the past year.
So now I was ordered to be a .Net guy. Yay.
A couple of days ago Microsoft officially released C# 10 and .Net 6.
I like reading books, I had preordered
Pro C# 9 with .NET 5: Foundational Principles and Practices in Programming 10th ed. Edition by Andrew Troelsen
It came out May 14, 2021, which is around 6 months ago.
The new version for C# 10 and .Net 6 will be released around May in 2022 about 6 months from now.
It is not just small changes either. If you know C# 2, there is a lot of code you will not be able to understand in C# 10,9,8.
Sells books, blogs, ads, conferences, where people who have spent 4 weeks with a beta version, teach you how to be a master C# developer with C# 10.
To be a "good"/"up to date" C# developer, who does not bring in all the "old stuff" from 6 months ago you have to spend time reading blogs, downloading alpha and beta versions, and keep track of what MS promised would be in the next release and what never made it. The "oh its new, shiny, shiny, shiny".
I like to wait for a proper release before I spend any time on it.
I still have my 2nd edition of C Programming Language K&R from 1988. It is still relevant and informative in 2021. (It is also well written).
It is impossible to master a programming language and framework that is a constant moving target.
Many programming languages are able to be both useful and produktive without being stuffed with new features of keywords and convention every 12 months.
Right now, there is not a single programmer in the world who has mastered C# 9, certainly, none for C# 10.
Oh there are a lot of bloggers and fanboys who have -used- C9 maybe even C# 10, and who make $$$ writing, speaking, consulting etc. But using and mastering are two very different things.
So please, wait 5 years before the next version of the programming language is pushed. If there are crucial bits you have not been able to get right in 10 version of a programming language, taking a step back would be a great idea.
I have used .Net since the pre Alpha 1.
The consulting company I worked for needed X number of consultants certified on this new platform thing so they picked a few of us and said that this .Net thing is now us, run to get certified so we can have our super triple gold star parter relationship.
My background was C and C++, Delphi, some Java for the past year.
So now I was ordered to be a .Net guy. Yay.
A couple of days ago Microsoft officially released C# 10 and .Net 6.
I like reading books, I had preordered
Pro C# 9 with .NET 5: Foundational Principles and Practices in Programming 10th ed. Edition by Andrew Troelsen
It came out May 14, 2021, which is around 6 months ago.
The new version for C# 10 and .Net 6 will be released around May in 2022 about 6 months from now.
It is not just small changes either. If you know C# 2, there is a lot of code you will not be able to understand in C# 10,9,8.
Sells books, blogs, ads, conferences, where people who have spent 4 weeks with a beta version, teach you how to be a master C# developer with C# 10.
To be a "good"/"up to date" C# developer, who does not bring in all the "old stuff" from 6 months ago you have to spend time reading blogs, downloading alpha and beta versions, and keep track of what MS promised would be in the next release and what never made it. The "oh its new, shiny, shiny, shiny".
I like to wait for a proper release before I spend any time on it.
I still have my 2nd edition of C Programming Language K&R from 1988. It is still relevant and informative in 2021. (It is also well written).
It is impossible to master a programming language and framework that is a constant moving target.
Many programming languages are able to be both useful and produktive without being stuffed with new features of keywords and convention every 12 months.
Right now, there is not a single programmer in the world who has mastered C# 9, certainly, none for C# 10.
Oh there are a lot of bloggers and fanboys who have -used- C9 maybe even C# 10, and who make $$$ writing, speaking, consulting etc. But using and mastering are two very different things.
So please, wait 5 years before the next version of the programming language is pushed. If there are crucial bits you have not been able to get right in 10 version of a programming language, taking a step back would be a great idea.
>To those who have been living under an anti-Microsoft-news rock for the last few days
Well, it was nice of the Windows side to wait for the .NET6 launch before stealing all their headline thunder by going back to the 2001 antitrust behavior of forcing the use of Microsoft's own browser. [1]
[1] https://www.theregister.com/2021/11/11/latest_windows_11_bui...
Well, it was nice of the Windows side to wait for the .NET6 launch before stealing all their headline thunder by going back to the 2001 antitrust behavior of forcing the use of Microsoft's own browser. [1]
[1] https://www.theregister.com/2021/11/11/latest_windows_11_bui...
>For example, there is nothing (official) comparable to javadoc for C#.
I'm not too familiar with Java but DotFX is an official project that builds a static HTML website from your source code comments.
I'm not too familiar with Java but DotFX is an official project that builds a static HTML website from your source code comments.
I've been programming Windows machines on and off forever.
I've never needed .NET libraries in my code, and never have seen the point, it always breaks, and seems to add orders of magnitude of bloat.
There's no real need for it, can't the rest of you skip it as well?
I've never needed .NET libraries in my code, and never have seen the point, it always breaks, and seems to add orders of magnitude of bloat.
There's no real need for it, can't the rest of you skip it as well?