.NET for Beginners (2020)(dusted.codes)
dusted.codes
.NET for Beginners (2020)
https://dusted.codes/dotnet-for-beginners
191 comments
Okay, where do you start in Learning C#? What do I have to install? What should I install?
Even those are complex questions with a few answers. I started with C# two decades ago with the command line compiler and a very large book. There was really only a single option, and since I didn't have MSDN access, no beta VS for me.
Today, I would suggest that a developer start with .Net 5 and VS Code, with the extension installed. Walking through the `dotnet` CLI. Unfortunately, getting started like that is convoluted with two decades of information/tutorials etc that will not directly apply, or be difficult to walk through.
For that matter, having followed .Net Core from the initial versions, it's been somewhat painful. Figuring out how to migrate/update web applications hasn't been anthing resembling transparent or consistent, and some things are just plain difficult to figure out along the way. There is a crap ton of secondary knowledge you need to be able to do a lot of things that are just easier in other platforms/languages.
Add support for an Authorize header with an RSA signed JWT token to your API.. go ahead... in Node, it took me a couple hours... with .Net Core having well over a decade of experience with C#, it took me the better part of 2 weeks to get things working the way I wanted to. All the tutorials were for older interfaces/apis etc. It was just ugly to say the least.
Hell, if MS would just standardize on keywork formats for thinggs... #dotnetcore3 or similar so that search terms via google could give you more relevant results... that just doesn't happen.
Don't get me wrong, I really appreciate C#, and .Net ... .Net Core itself had me working with .Net again with interest after years of migrating solutions towards options that are easier to write, containerize and scale.
I'm still more inclined to reach for Node or for that matter, to push for Go or Rust, at least it's a consideration again.
But it is anything but something easy to get started with, or for that matter, upgrade projects with. Python 2 to 3 was a cleaner migration option.
Even those are complex questions with a few answers. I started with C# two decades ago with the command line compiler and a very large book. There was really only a single option, and since I didn't have MSDN access, no beta VS for me.
Today, I would suggest that a developer start with .Net 5 and VS Code, with the extension installed. Walking through the `dotnet` CLI. Unfortunately, getting started like that is convoluted with two decades of information/tutorials etc that will not directly apply, or be difficult to walk through.
For that matter, having followed .Net Core from the initial versions, it's been somewhat painful. Figuring out how to migrate/update web applications hasn't been anthing resembling transparent or consistent, and some things are just plain difficult to figure out along the way. There is a crap ton of secondary knowledge you need to be able to do a lot of things that are just easier in other platforms/languages.
Add support for an Authorize header with an RSA signed JWT token to your API.. go ahead... in Node, it took me a couple hours... with .Net Core having well over a decade of experience with C#, it took me the better part of 2 weeks to get things working the way I wanted to. All the tutorials were for older interfaces/apis etc. It was just ugly to say the least.
Hell, if MS would just standardize on keywork formats for thinggs... #dotnetcore3 or similar so that search terms via google could give you more relevant results... that just doesn't happen.
Don't get me wrong, I really appreciate C#, and .Net ... .Net Core itself had me working with .Net again with interest after years of migrating solutions towards options that are easier to write, containerize and scale.
I'm still more inclined to reach for Node or for that matter, to push for Go or Rust, at least it's a consideration again.
But it is anything but something easy to get started with, or for that matter, upgrade projects with. Python 2 to 3 was a cleaner migration option.
> Okay, where do you start in Learning C#? What do I have to install? What should I install?
Visual Studio Community Edition 2019.
Done.
edit: I would encourage using regular .Net, not .Net Core until they've reached a certain threshold.
Visual Studio Community Edition 2019.
Done.
edit: I would encourage using regular .Net, not .Net Core until they've reached a certain threshold.
I would consider .Net 5 that threshold... there's no more Core, fyi. As for VS Community, if someone is getting started in C#, I'd suggest VS Code and learning the CLI tool before jumping in on the IDE bandwagon if only to learn the platform better in getting started.
> I'd suggest VS Code and learning the CLI tool before jumping in on the IDE bandwagon if only to learn the platform better in getting started.
I absolutely hate most CLI tools and C#'s is no exception. I'm happy to say that I have never, in any of my time developing, been in a situation where I absolutely had to use one for C#. It's made me very happy.
.csproj's and .sln files are such a better design pattern for project management than raw folders that I wouldn't torment someone by requiring them to learn that alternative model when any good C# IDE will do all of that for them.
Same with Java.
If you want to require someone to learn everything CLI, then they should probably be learning a different language, to start.
In a similar tone, if I was teaching someone Python, I would start them with running `python` and then just ... typing commands. I wouldn't teach them if __name__ == __main__ until later on. Same reason. Unnecessary complexity for the kind of work they're doing.
When you start wanting to configure CI on Jenkins (not TFS, because TFS handles all this for you, too), then the command line has any value for C#, imo.
I absolutely hate most CLI tools and C#'s is no exception. I'm happy to say that I have never, in any of my time developing, been in a situation where I absolutely had to use one for C#. It's made me very happy.
.csproj's and .sln files are such a better design pattern for project management than raw folders that I wouldn't torment someone by requiring them to learn that alternative model when any good C# IDE will do all of that for them.
Same with Java.
If you want to require someone to learn everything CLI, then they should probably be learning a different language, to start.
In a similar tone, if I was teaching someone Python, I would start them with running `python` and then just ... typing commands. I wouldn't teach them if __name__ == __main__ until later on. Same reason. Unnecessary complexity for the kind of work they're doing.
When you start wanting to configure CI on Jenkins (not TFS, because TFS handles all this for you, too), then the command line has any value for C#, imo.
And if you're targeting Docker deployments on Linux? Or have developers on Linux or MacOS laptops?
Sure doesn't sound like beginner C# questions at this point, eh?
If you're experienced with other languages, you are... Also, there are plenty of beginners with Macbooks.
Is it bad that I would steer someone away from learning C# if they're on a MacBook, unless they're learning Unity? And then I would recommend what Unity recommends.
Depends on why they would be learning C#
I do most of what I do with C# in WSL with VS Code (WSL Remote) ... because that's where I do most of my Programming. Where I work, pushing towards most of what we write to be able to deploy/operate in Linux/Docker environments. Doesn't make C# less of a language for the teams that have over a decade of experience with C#, but it is a mindset shift.
The bigger issues I have are with the framework and that it's very difficult to search for working paradigms as framework apis and interfaces have dramatically changed in a lot of areas the past few years. I like the dotnet cli better than what was before it... that said, it's still got a lot of rough edges.
And getting started, especially when you are experienced in other platforms, isn't always easy... even experience from .Net framework to newer runtimes has been painful in the past.
I do most of what I do with C# in WSL with VS Code (WSL Remote) ... because that's where I do most of my Programming. Where I work, pushing towards most of what we write to be able to deploy/operate in Linux/Docker environments. Doesn't make C# less of a language for the teams that have over a decade of experience with C#, but it is a mindset shift.
The bigger issues I have are with the framework and that it's very difficult to search for working paradigms as framework apis and interfaces have dramatically changed in a lot of areas the past few years. I like the dotnet cli better than what was before it... that said, it's still got a lot of rough edges.
And getting started, especially when you are experienced in other platforms, isn't always easy... even experience from .Net framework to newer runtimes has been painful in the past.
Per the last versions of .net vs .net core that I worked with (4.....6.2(?) and .net core who even knows), I definitely agree with the frustrations.
That's a major reason why, when I answered the top question, I was responding in a way to reference a new developer. I don't think they should be required to think of all of that hell, so I just wanted to point them to a particular library and to just live with it until they're asking the hard questions and have to move to something more complicated. For beginner-beginners, that shouldn't happen for a while.
Someone higher up said that this post should have been titled something like .NET for Professional Beginners, developers that already have a lot of experience and are wanting to develop a single, specific, advanced usecase, or a use case where they are required to work with .net core, it was like that.
I ran into something similar at my present job, trying to set up a webserver in Kotlin. It reminds me a lot of the woes I have with .net core with the numerous, almost adjacent, but not quite in the same package gradle packages.
At this point, I'm not sure there's very many batteries fully included languages left. C# was kinda the last bastion of it. Elsewhere someone, maybe you?, referenced PHP, but even that isn't batteries included. The only batteries included are the ones that PHP is good at, webservices.
Python is all about packages, and it just went through async hell, where the syntax for async changed over and over again over each version, so Google searching, as you mentioned struggling with in other threads, can be painful there, as well.
Ruby requires you to learn Rails (which isn't Ruby! it's written in Ruby but not part of the base framework!)
...
I guess Go is probably the closest to general purpose with its default framework.
That's a major reason why, when I answered the top question, I was responding in a way to reference a new developer. I don't think they should be required to think of all of that hell, so I just wanted to point them to a particular library and to just live with it until they're asking the hard questions and have to move to something more complicated. For beginner-beginners, that shouldn't happen for a while.
Someone higher up said that this post should have been titled something like .NET for Professional Beginners, developers that already have a lot of experience and are wanting to develop a single, specific, advanced usecase, or a use case where they are required to work with .net core, it was like that.
I ran into something similar at my present job, trying to set up a webserver in Kotlin. It reminds me a lot of the woes I have with .net core with the numerous, almost adjacent, but not quite in the same package gradle packages.
At this point, I'm not sure there's very many batteries fully included languages left. C# was kinda the last bastion of it. Elsewhere someone, maybe you?, referenced PHP, but even that isn't batteries included. The only batteries included are the ones that PHP is good at, webservices.
Python is all about packages, and it just went through async hell, where the syntax for async changed over and over again over each version, so Google searching, as you mentioned struggling with in other threads, can be painful there, as well.
Ruby requires you to learn Rails (which isn't Ruby! it's written in Ruby but not part of the base framework!)
...
I guess Go is probably the closest to general purpose with its default framework.
I'm relatively familiar with .Net (been using it since late 2001), that said, it's changed dramatically, more so in the past 3 years than nearly a decade before that. The changes between Framework 4.x to Core 1, 2, 3 have been somewhat dramatic and painful trying to keep one application current (that needed portability, including rpi). Hopefully the move to .Net 5 will be less painful.
I'm mostly playing devils advocate as it's not been a smooth transition and the best way to do many things has changed since some things are in the box, that didn't used to be, but still rough around some edges.
Many libraries and patters for web api projects are a bit different, better but different.
I'm mostly playing devils advocate as it's not been a smooth transition and the best way to do many things has changed since some things are in the box, that didn't used to be, but still rough around some edges.
Many libraries and patters for web api projects are a bit different, better but different.
I'm sorry but it definitely does, there are plenty of developers using Linux coming from language set (a,b,c) trying to pick up language 'c'. I would consider myself a beginner for language 'd'.
I was specifically thinking about the Docker part of the question when it was asked.
I certainly wouldn't encourage the first thing someone does when writing C# be "create an application that will run in a Docker container". Running locally and getting one's feet under them seems like a better first step.
It is valid, though, that the Linux development experience for C# is worse overall. If you're using Linux, though, your options are greatly reduced, though, so life becomes easier. You're either developing for Mono or .Net Core.
As I wouldn't recommend developing in C# for a Linux developer, in general, though, but that is my bias against .Net Core speaking out.
If someone's a Unity Developer on Linux, I would recommend MonoDevelop or whatever Unity's recommended IDE and pipeline are.
I certainly wouldn't encourage the first thing someone does when writing C# be "create an application that will run in a Docker container". Running locally and getting one's feet under them seems like a better first step.
It is valid, though, that the Linux development experience for C# is worse overall. If you're using Linux, though, your options are greatly reduced, though, so life becomes easier. You're either developing for Mono or .Net Core.
As I wouldn't recommend developing in C# for a Linux developer, in general, though, but that is my bias against .Net Core speaking out.
If someone's a Unity Developer on Linux, I would recommend MonoDevelop or whatever Unity's recommended IDE and pipeline are.
Also... "I don't see an option to create a web project." or "Where's the project to start a video game" ... There's lots of bundle options in the VS installer that someone may not understand, and if you install the kitchen sink, you may well fill a 256-512gb ssd.
Or... I'm running a Mac.
Or... I'm running a Mac.
[deleted]
VS for Mac is becoming an actual native app in the upcoming VS 2022, so progress is at least being made there!
There is no "regular .NET" anymore.
It's just .NET 5, a cross-platform framework that is the next version of .NET Core taking over as the single framework.
It's just .NET 5, a cross-platform framework that is the next version of .NET Core taking over as the single framework.
> I would encourage using regular .Net, not .Net Core until they've reached a certain threshold
This is terrible advice. .NET Framework has so many gotchas in its dependency management and binding redirect hell, not to mention ASP.NET 4.x is full of hidden "magic" and serious usability problems.
Anyone starting a new project should be on .NET 5/Core, and that's been true since the Core 2.x releases. Also, the generic hosting model[0] is a productivity game changer and gives you a complete batteries-included experience no matter the project type.
[0] https://docs.microsoft.com/en-us/dotnet/core/extensions/gene...
This is terrible advice. .NET Framework has so many gotchas in its dependency management and binding redirect hell, not to mention ASP.NET 4.x is full of hidden "magic" and serious usability problems.
Anyone starting a new project should be on .NET 5/Core, and that's been true since the Core 2.x releases. Also, the generic hosting model[0] is a productivity game changer and gives you a complete batteries-included experience no matter the project type.
[0] https://docs.microsoft.com/en-us/dotnet/core/extensions/gene...
woah, I was a pretty expert C#/.NET developer until about 5 years ago, when I switched to Python and C++ for my dayjob. I've not kept up with the ecosystem since then. .NET Core was sort of in its infancy, and we were debating moving over at the point when I left that company, so I've never used Core.
but ...I can barely read that page and understand what's going on!
This is something I did notice with the c# codebases I worked on; you could date them to the month based on whatever "hot shit" patterns were used by each project. I thought this was normal for every language, but since working on large codebases in other languages, I've found that it's mostly a C# thing (Java has a bit of that too).
But man, it's insane how much the language and the ecosystem has changed in 5 years.
but ...I can barely read that page and understand what's going on!
This is something I did notice with the c# codebases I worked on; you could date them to the month based on whatever "hot shit" patterns were used by each project. I thought this was normal for every language, but since working on large codebases in other languages, I've found that it's mostly a C# thing (Java has a bit of that too).
But man, it's insane how much the language and the ecosystem has changed in 5 years.
Have you tried the dotnet site: https://dotnet.microsoft.com/
It explains everything, including how to get started for every scenario, and answers to every question in all of your comments here.
It explains everything, including how to get started for every scenario, and answers to every question in all of your comments here.
If the argument being made is ".NET isn't a language", and the response is "okay, then how do I install C#?" Linking the dotnet website probably doesn't advance the idea that C# and .NET aren't tied together.
How do you install Java? First thing you'd do is download the JDK. Is the JDK a language? No, it's not.
That's a fact, not an argument. And who said that C# and .NET aren't tied together? You install the runtime/SDK to get started with the overall environment, similar to many other programming stacks.
Books. I don’t understand this recent move to videos/blog posts. They are pretty much terrible as a base for a new language/platform, and often say incorrect informations.
A not too old (~2-3 years) book on the topic will explain everything in an easy to digest way, and it is much more likely that the author actually knows what he/she talks about.
A not too old (~2-3 years) book on the topic will explain everything in an easy to digest way, and it is much more likely that the author actually knows what he/she talks about.
> How can I learn C++ and llvm"
Rather "C++ and Qt" or "C++ and Boost".
Rather "C++ and Qt" or "C++ and Boost".
"C++ and Qt" would be more analogous to "C# and WPF". .Net to C# is perhaps more like JVM to Java.
no. CLR would be the JVM equivalent.
.net would be like the OpenJDK
.net would be like the OpenJDK
don't try to make solid analogies for nebulous ill defined terms like .NET!
I know you're making a joke, but the article says:
> In particular questions around the differences between .NET, .NET Core, Mono, Xamarin, and the relation between C#, F#, VB.NET and what a target framework or a runtime is add very little to almost no benefit to one's initial learning experience.
So, I assume they primarily mean the particular set of libraries being used
> In particular questions around the differences between .NET, .NET Core, Mono, Xamarin, and the relation between C#, F#, VB.NET and what a target framework or a runtime is add very little to almost no benefit to one's initial learning experience.
So, I assume they primarily mean the particular set of libraries being used
[deleted]
Qt is like Boost and .Net a general purpose framework; it is also very useful on the server side or with command line applications. Qt Widgets is only one of many modules. Btw. you seem to mix up .Net with the virtual execution system (VES) and its common intermediate language (CIL). Have a look at the standard (ISO 23271) part I; you can download it for free from https://standards.iso.org/ittf/PubliclyAvailableStandards/c0.... There is an additional technical report for the framework (ISO 23272), which can be downloaded from https://standards.iso.org/ittf/PubliclyAvailableStandards/c0....
> But no, you don't have to learn any of those things, you can just start learning C#.
The problem for a beginner (on any language or platform) is you have to know what you don't need to know. You get overwhelmed with terminology just in the "create new project" dialog. Most of it is not relevant for a beginner, but as a beginner you don't even know what is relevant and what is irrelevant.
The problem for a beginner (on any language or platform) is you have to know what you don't need to know. You get overwhelmed with terminology just in the "create new project" dialog. Most of it is not relevant for a beginner, but as a beginner you don't even know what is relevant and what is irrelevant.
Like other design-by committee projects C# has considerable sprawl. As a result, it's overwhelming and confusing for brand new programmers to start writing hobby projects in.
But C# is beginner friendly in that it's easy for inexperienced programmers to contribute business value to existing codebases. The everything-in-one ecosystem (IDE + autocomplete + database + deployment + source control + package management) removes many sharp edges that experienced programmers are used to working around and take for granted in other languages. I've known smart high school kids with limited programming experience become productive C# developers in weeks, and that doesn't happen the same for e.g. Java.
But C# is beginner friendly in that it's easy for inexperienced programmers to contribute business value to existing codebases. The everything-in-one ecosystem (IDE + autocomplete + database + deployment + source control + package management) removes many sharp edges that experienced programmers are used to working around and take for granted in other languages. I've known smart high school kids with limited programming experience become productive C# developers in weeks, and that doesn't happen the same for e.g. Java.
I will agree and disagree... a lot of things around the edges really do change between versions of .Net .. while C# is pretty progressive, the .Net framework does have some rough edges if you're either inexperienced, or have tended to hold on to a version for too long and now need to jump ahead a version or two.
The evolution of .Net Core (now just .Net 5) has been interesting and at times very painful.
The evolution of .Net Core (now just .Net 5) has been interesting and at times very painful.
The evolution of .Net standard, core, and framework has been mind boggling and difficult.
I’ve lost track, and I don’t even know how to keep tabs on this any more.
Too much information.
I envy the greenfield developers who can start with .Net Core or .Net 5.
I’ve lost track, and I don’t even know how to keep tabs on this any more.
Too much information.
I envy the greenfield developers who can start with .Net Core or .Net 5.
For those that care, Framework is the old original .NET for Windows; Core is the new multiplatform .NET; Standard was an, ahem, standard, for writing code that would work under both Framework and Core.
Since the release of .NET 5 "unifies" Framework & Core (for some value of n), there is no longer a need for Framework, Core, nor a unifying Standard.
Since the release of .NET 5 "unifies" Framework & Core (for some value of n), there is no longer a need for Framework, Core, nor a unifying Standard.
The sprawl isn't just confusing for new programmers. Several years ago I was writing C# professionally, would always appreciate the new features that came with each new version of C#.
Recently I was reviewing the code of a library written in C# 9 and couldn't make head or tails of it. Half the code was using features that didn't exist a couple of years ago, enabling the author to use patterns which were not possible without those features.
Recently I was reviewing the code of a library written in C# 9 and couldn't make head or tails of it. Half the code was using features that didn't exist a couple of years ago, enabling the author to use patterns which were not possible without those features.
The last few years C# has had a massive adoption of functional paradigms. This is great for programmers as you can use OO or functional styles where they fit best. This definitely sucks for newer developers as functional concepts are often harder to grasp or less commonly taught, but are now necessary to understand in modern C#.
> Like other design-by committee projects C# has considerable sprawl.
Despite having gained some weight over the years, I still wouldn't call Anders Hejlsberg a committee.
Despite having gained some weight over the years, I still wouldn't call Anders Hejlsberg a committee.
I didn't read the whole article, just scanned it. But I'm surprised he chose Golang as a low-cognition entry barrier language. As a developer on Windows (relevant since we're talking about .NET), setting up Go was a pain in the ass. Making sure that my PATH variables were set up correctly and all that jazz, and then I'd run into issue after issue with packages and paths.
I don't know what it is about golang, but man, it's hard unless you just start up a WSL and install it on there.
I don't know what it is about golang, but man, it's hard unless you just start up a WSL and install it on there.
having never worked with Go on Windows, was that recently? With modules, you can just pick a new directory of your choice, `go mod init` and you are ready to start work. As for packages and paths, it is just URLs.
Same here. Package management was non existent at the time, not sure how it is now.
There are pointers without pointer arithmetic, I really don't know why they are there. If you already know programming you will be fine with go, but if it's the first language someone learns I think they'll go catatonic when they are exposed to real pointers, dealing with shared memory, package management, generics, etc. because its going to be hard unlearning ways used in go.
On the plus side go is small and very performanent.
There are pointers without pointer arithmetic, I really don't know why they are there. If you already know programming you will be fine with go, but if it's the first language someone learns I think they'll go catatonic when they are exposed to real pointers, dealing with shared memory, package management, generics, etc. because its going to be hard unlearning ways used in go.
On the plus side go is small and very performanent.
> There are pointers without pointer arithmetic, I really don't know why they are there.
Because you need some way to distinguish between having a sequence of bytes in the middle of another sequence of bytes and having the former sequence of bytes somewhere else, at least in languages that allows both for any data type. For example, Java doesn't suffer from this since everything is pointers implicitly. And C# doesn't either because every type belongs to one of two kinds, the first kind corresponding to the former of the two cases above and the second kind corresponding to the latter. But Go doesn't have this luxury (intentionally, for the same reason as C does it).
Because you need some way to distinguish between having a sequence of bytes in the middle of another sequence of bytes and having the former sequence of bytes somewhere else, at least in languages that allows both for any data type. For example, Java doesn't suffer from this since everything is pointers implicitly. And C# doesn't either because every type belongs to one of two kinds, the first kind corresponding to the former of the two cases above and the second kind corresponding to the latter. But Go doesn't have this luxury (intentionally, for the same reason as C does it).
>Making sure that my PATH variables were set up correctly
This is a pretty common issue to run into with developer tooling on Windows, regardless of the language.
It would be nice if the go installer added its install dir to the PATH automatically like some tools do. But so much dev tooling on Windows does not you will need to know how to edit your PATH eventually.
This is a pretty common issue to run into with developer tooling on Windows, regardless of the language.
It would be nice if the go installer added its install dir to the PATH automatically like some tools do. But so much dev tooling on Windows does not you will need to know how to edit your PATH eventually.
> setting up Go was a pain in the ass. Making sure that my PATH variables were set up correctly and all that jazz, and then I'd run into issue after issue with packages and paths.
When was this? Within the last two years? When Go was transitioning from the original GOPATH style setup to modules, I had a ton of issues like this. So many, that I kept my Go version on an earlier build so I didn't have to deal with it.
These days, thankfully, all those issues are taken care of. I've mostly switched to cross compiling from WSL(2), but compiling on Windows has been fine for a number of versions now.
When was this? Within the last two years? When Go was transitioning from the original GOPATH style setup to modules, I had a ton of issues like this. So many, that I kept my Go version on an earlier build so I didn't have to deal with it.
These days, thankfully, all those issues are taken care of. I've mostly switched to cross compiling from WSL(2), but compiling on Windows has been fine for a number of versions now.
>Making sure that my PATH variables were set up correctly
Honestly, what's so technical about adding:
Honestly, what's so technical about adding:
export PATH=/usr/local/go/bin:$PATH
mkdir myapp && cd myapp && go mod init myapp
> Honestly, what's so technical about adding [...] to your ~/.bashrc ?
Oh boy, you don't tutor many beginners in programming do you?
Oh boy, you don't tutor many beginners in programming do you?
I’m sure it will run well on Windows, as the poster asked..
The professionals in this field (programmers) are something of a different breed. I can't tell you how many time I've come across something I've been needing so badly to learn and it's put right in front of my nose explained in detail by people i look up to, just here to say thanks for the in depth article. great material.
The complaint around all the different concurrent iterations of .NET rings true to me.
It used to be that you only needed "current version of .net" and then you just ran forward with all of the standard libaries and Visual Studio handled all of that for you and it was wonderful.
Now you need to work with .NET Core and download a bunch of disjoint nuget packages to make everything work; and, then you download a specific nuget package and it requires updating all your other nuget packages, on to forever.
I was tasked with transitioning some of a former company's .net 4.something code to .net core, to see if we could do it, and the transition was a shock to the system, for sure.
In the past, I could choose when to engage with Nuget and which packages to work with. When I went to .net core, it seemed like anything complex that I wanted to do required yet another package - in my case, anything related to running a webserver.
Working with .net definitely became more complicated post .net core.
edit: for clarity and enjoying the downvotes.
I'm a seasoned .net developer and used it from 2009 until 2018-2019 for desktop applications and webservices. I've used nuget packages plenty for a variety of things, including Akka.net.
It used to be that you only needed "current version of .net" and then you just ran forward with all of the standard libaries and Visual Studio handled all of that for you and it was wonderful.
Now you need to work with .NET Core and download a bunch of disjoint nuget packages to make everything work; and, then you download a specific nuget package and it requires updating all your other nuget packages, on to forever.
I was tasked with transitioning some of a former company's .net 4.something code to .net core, to see if we could do it, and the transition was a shock to the system, for sure.
In the past, I could choose when to engage with Nuget and which packages to work with. When I went to .net core, it seemed like anything complex that I wanted to do required yet another package - in my case, anything related to running a webserver.
Working with .net definitely became more complicated post .net core.
edit: for clarity and enjoying the downvotes.
I'm a seasoned .net developer and used it from 2009 until 2018-2019 for desktop applications and webservices. I've used nuget packages plenty for a variety of things, including Akka.net.
I think a lot of the newer options are much easier... the greater flexibility of detaching most libraries from the base runtime has been useful for advancing the platform as a whole.
That said, I do feel the pain, the interface changes for binding web applications are very different, and if you relied on "Enterprise" libraries harder still. I'd rather do things the "new" way, but it's more the differences that make it harder.
Harder still, is when trying to google how to do X with .Net Core 3 or similar... Now that it's .Net 5, at least that should make some stuff easier, until 6 comes out at the end of the year, but that's more evolutionary. Getting search results that no longer apply is a pain. It's far less the C# language as it is the platform libraries themselves and the breaking evolution through .Net Core. I think TFA has a point that renaming .Net to something else instead of .Net Core or .Net 5 may have been a good idea.
Of course, now it's Azure * instead of a couple decades ago it was * .Net (anyone remember Office .Net, Windows .Net etc in early dev/beta marketing?)
That said, I do feel the pain, the interface changes for binding web applications are very different, and if you relied on "Enterprise" libraries harder still. I'd rather do things the "new" way, but it's more the differences that make it harder.
Harder still, is when trying to google how to do X with .Net Core 3 or similar... Now that it's .Net 5, at least that should make some stuff easier, until 6 comes out at the end of the year, but that's more evolutionary. Getting search results that no longer apply is a pain. It's far less the C# language as it is the platform libraries themselves and the breaking evolution through .Net Core. I think TFA has a point that renaming .Net to something else instead of .Net Core or .Net 5 may have been a good idea.
Of course, now it's Azure * instead of a couple decades ago it was * .Net (anyone remember Office .Net, Windows .Net etc in early dev/beta marketing?)
It got a lot better in .NET Core three when they stopped using Nuget packages for the core framework works. Now building and updating apps based on just the core frameworks no longer installs and restores Nuget packages. This makes it faster, simpler, and takes less space on disk.
You probably still will have more Nuget packages in your ASP.NET Core project than a classic .NET Framework project would.
Details about the new system: https://github.com/dotnet/designs/blob/main/accepted/2019/ta...
You probably still will have more Nuget packages in your ASP.NET Core project than a classic .NET Framework project would.
Details about the new system: https://github.com/dotnet/designs/blob/main/accepted/2019/ta...
I'm really glad they stopped that. Adding, I think it was Owin (part of the .net core framework), and then being required to update to a new version of the ... collections api? it's been a while, clearly, was one of my "... seriously?" moments when working with migrating to .net core last.
The author comes from the beginners perspective but it sucks for veterans too.
How many transitions have you done? As a long time dotnet developer I feel like there’s been constant transitioning and back and forth.
It isn’t simple to transition either. As you have to wait for all your dependencies to transition, there are usually many different solutions to update, there are breaking changes and bugs to deal with and on top of it there’s the constant moving target to be up to date. It’s definitely made it painful to use dotnet.
How many transitions have you done? As a long time dotnet developer I feel like there’s been constant transitioning and back and forth.
It isn’t simple to transition either. As you have to wait for all your dependencies to transition, there are usually many different solutions to update, there are breaking changes and bugs to deal with and on top of it there’s the constant moving target to be up to date. It’s definitely made it painful to use dotnet.
If you want to get anything done with C you learn the stdlib. With python you need to learn the package system. With C# you have to learn .NET. I don't see that it is that much more complicated. Python also has problems with shared code versioning. Modern PHP still suffers from carrying old crufty PHP code along
The issue he's stating is deciding which ".net"
doesnt matter they are 99% the same, in the same way java versions coming out dont require you to relearn java or the java core libs
C# was never intended to run everywhere. It was a Java clone for Windows. Now msft wants to make it run everywhere. There's going to be some confusion in the transition.
You couldn't be more mistaken... C# and .Net (CLR) were absolutely written/meant to be portable. Mono was pretty well adapted from early on at a core level, though it didn't support all the options. If it weren't for MS patent stance and some FUD early on, it might have gained more adoption in the Linux space.
One of the reasons I chose to learn C# a couple decades ago over Java was the fact that interop was so much cleaner than JNI.
One of the reasons I chose to learn C# a couple decades ago over Java was the fact that interop was so much cleaner than JNI.
Mono was created by Miguel de Icaza, a Mexican (Now Mexican-American) programmer. Microsoft had nothing to do with it. Novell purchased it. Eventually Microsoft warmed up to it. Miguel de Icaza now works at Microsoft.
Mono was an implementation of the CLI ... the "Design" of the language, and CLI were absolutely designed to be cross-platform.
You've gone from saying "C# and .Net (CLR) were absolutely written/meant to be portable" to "CLI was absolutely designed to be cross-platform." I feel you are not arguing in the spirit of my assertion that "C# was never intended to run everywhere" Sure, it was designed cross-platform so it would run on Dos/Windows ME and Windows NT.
CLR was designed to be cross platform from the beginning. Sorry for mistyping in the response.
The fact that Microsoft mgt never ran/supported that prior to Satya and .Net Core had nothing to do with the platform and language design.
The fact that Microsoft mgt never ran/supported that prior to Satya and .Net Core had nothing to do with the platform and language design.
This is an IDE right here:
https://www.monodevelop.com/
>Eventually Microsoft warmed up to it.
Only after Microsoft's Linux patent racket involving Suse, who Icaza worked for, branded them as the enemies of open source which became inconvenient once they realised the writing was on the wall for anyone who did not support open source.
Only after Microsoft's Linux patent racket involving Suse, who Icaza worked for, branded them as the enemies of open source which became inconvenient once they realised the writing was on the wall for anyone who did not support open source.
[deleted]
I'd like to see some data around the central claim. Is C# really that hard for beginners? I watch a lot of beginners on twitch (for several years now) start with C# and almost zero idea about programming. They all seem do pretty well, whether they are learning unity, winforms, web dev. They don't even stop and wonder any of the issues discussed in the article, they simply make the project type they want in visual studio and start learning the guts of programming. The issues discussed seem more of a problem with evolving your software over time, especially the framework -> core/.net 5+ transition. I'm not sure that really impacts beginners other than a few caught in the storm who needed to upgrade their software to a different version (given most would just stick to whatever they started with). The evolution of the C# language itself has caused fractures in recommendations on how you program in C# but then stabilize pretty quick. We've been through it quite a few times in the C# world, and if you are learning in a transition period, yeah, some tutorials are going to say one thing, and others another thing, but most beginners seem pretty ok with the idea that there is an "old" way and a "new" way. But like I said, I'd like to see actual data on the beginner learning experience rather than anecdotal accounts as there's always going to be people who find it hard and those who find it easy.
I don't think C# is hard for beginners. I monitor the Git repository of our Infrastructure Team and they develop small tools in C#.NET really easily. None of them would claim to be programmers or have any formal training as such. The tools they make are simple but sophisticated in what they accomplish and interact with.
The article makes a good point but 90% of is irrelevant to a beginner. Open Visual Studio, pick your project type, and start coding.
The article makes a good point but 90% of is irrelevant to a beginner. Open Visual Studio, pick your project type, and start coding.
The biggest issue I had picking up C# over the last year (and still have) is figuring out the MS ecosystem. There’s three different frameworks for everything, all of which are either incomplete or to be deprecated.
Windows-only desktop app is the latest to confound me, let alone cross platform.
The .NET variants confused the hell out of me for the longest time until I just sat on Wikipedia and read the whole damn history, because every variant and version seems to be in play simultaneously
Windows-only desktop app is the latest to confound me, let alone cross platform.
The .NET variants confused the hell out of me for the longest time until I just sat on Wikipedia and read the whole damn history, because every variant and version seems to be in play simultaneously
The thing about .NET is that while it is confusing at the moment, and the naming isn't great, it's not a bunch of truly different technology. Microsoft is replacing their legacy Windows-only framework with a new cross platform framework with the end-goal being nearly fully backwards compatible. There is slightly more to it than that but that's the basic gist of it.
Heck, they've even brought over Winforms -- that technology is over 19 years old! So I honestly think using the term deprecated is too strong. They've done the right thing and continued to maintain multiple branches .NET until the newest version is fully finished and can reasonably replace the old one.
As I said in another comment, the framework you choose doesn't even matter that much. You're unlikely to even a notice a difference and changing from one to another is often as easily as selecting it from a drop-down (or editing a file) and recompiling.
Heck, they've even brought over Winforms -- that technology is over 19 years old! So I honestly think using the term deprecated is too strong. They've done the right thing and continued to maintain multiple branches .NET until the newest version is fully finished and can reasonably replace the old one.
As I said in another comment, the framework you choose doesn't even matter that much. You're unlikely to even a notice a difference and changing from one to another is often as easily as selecting it from a drop-down (or editing a file) and recompiling.
The main issue I've had is that everything is supported, but it's very difficult to find out what the current "best practice" is. E.g. I can use winforms (because backwards compatibility with MS reigns supreme), but it's replaced by WPF and UWP (which also have various limitations, like UWP is windows 10 only), which themselves are replaced by MAUI as the modern system (which isn't ready).
So the framework to pick for a new application is... I don't know. Ideally the answer would be UWP with some kind of automated fallback for older windows, but its not. [0]
This windows UI confusion (3 different gui systems in play, when iterating over system settings) seems like a direct result of this framework confusion
[0] Apparently Win7 is still like 30% of the market, so it's hardly ignorable. https://www.digitaltrends.com/computing/windows-7-end-of-sup...
So the framework to pick for a new application is... I don't know. Ideally the answer would be UWP with some kind of automated fallback for older windows, but its not. [0]
This windows UI confusion (3 different gui systems in play, when iterating over system settings) seems like a direct result of this framework confusion
[0] Apparently Win7 is still like 30% of the market, so it's hardly ignorable. https://www.digitaltrends.com/computing/windows-7-end-of-sup...
> So the framework to pick for a new application is... I don't know.
You just described all UI the frameworks, what replaces what, and what the limitations are! Microsoft also lays that out here: https://docs.microsoft.com/en-us/windows/apps/desktop/choose...
I've answered this question for myself: WPF. It's neither bleeding edge nor is it obsolete.
You can complain about the current state of things but I don't think there's any argument that Microsoft is doing the wrong thing here. They're iterating on their platform, making improvements, and supporting existing technology.
You just described all UI the frameworks, what replaces what, and what the limitations are! Microsoft also lays that out here: https://docs.microsoft.com/en-us/windows/apps/desktop/choose...
I've answered this question for myself: WPF. It's neither bleeding edge nor is it obsolete.
You can complain about the current state of things but I don't think there's any argument that Microsoft is doing the wrong thing here. They're iterating on their platform, making improvements, and supporting existing technology.
>You just described all UI the frameworks, what replaces what, and what the limitations are! Microsoft also lays that out here
The problem is that all options lack some core fundamental expected feature. From that chart, WinForms lack High DPI awareness and customizable UI (tbh I'm not sure what customizable means here -- that custom controls/views are difficult or just skinning is difficult?), WPF also lacks High DPI and UWP lacks fallbacks (and a bunch of basic OS features like direct file access? I don't know why that's the case).
The differences between them aren't even trade-offs, so much as randomly incomplete. Granted, I haven't spent any time whatsoever trying workarounds -- maybe it's simple enough (WPF is clearly the least problematic, if DPI scaling can be worked around without much trouble). I've just been looking at the charts like that, and my ultimate answer is "???"
>You can complain about the current state of things but I don't think there's any argument that Microsoft is doing the wrong thing here
I think there is; Microsoft runs the .net ecosystem as its steward -- it intentionally creates, markets and governs pretty much every major framework and components that exists. For better or worse, the state of .net ecosystem is owned by Microsoft -- unlike say, rust, golang, python, c++, ruby, etc where the language maintainers are mostly divorced from the language ecosystem, and make no real say in the matter beyond broad recommendation of community-run frameworks (python is a little different, being batteries-included, but it's also well-known that stdlib is where libraries go to die; no one recommends python stdlib as best-in-class of anything). .NET is of course a non-closed ecosystem, and the community does contribute quite significantly, but nonetheless, if it's first-class it's almost always MS.
The current state of affairs is essentially a result of bad ownership; the high rate of churn in the javascript ecosystem can be blamed on the JS communities. The high rate of churn in the MS ecosystem can be blamed on MS. They've constructed a complex environment with unclear recommendations and continuous deprecation (fine, they're never actually deprecated because MS policy on backwards compatibility is second to none, but its "legacy"), a terribly confused naming convention and wide swath of overlapping technologies.
Don't get me wrong, MS does cool work, but they've made quite a mess, and it's quite clearly a result of constantly changing vision of how the .NET ecosystem should look like -- in combination with new projects seemingly forgetting MS's stance on backwards compatibility (nothing is ever just superseded; there must be an upgrade path or you will end up maintaining both forever [Unity has the same fundamental misunderstanding of their feature development]).
If there are going to be 4 UI frameworks, they should be competing on different models, APIs and mindsets (eg MVC vs MVVC vs MVU -- it's absurd that they're competing on core fundamental features instead). Although on the web-side of things, I think this is actually the case for .NET -- blazor vs MVC5 represent entirely different ways of approaching the problem. But AFAICT winforms vs UWP are really, from the programmer's perspective, the same thing. The underlying technology support changes (but in that case, you would ideally have the options be functionally complete).
Anyways as I said I've only been looking at it for the last year but that's my interpretation thus far -- the only way to understand the .NET ecosystem is to understand all the paths MS has taken, untaken, and re-routed. because their actual messaging and vision (as it connects to what they've implemented) is quite confused
The problem is that all options lack some core fundamental expected feature. From that chart, WinForms lack High DPI awareness and customizable UI (tbh I'm not sure what customizable means here -- that custom controls/views are difficult or just skinning is difficult?), WPF also lacks High DPI and UWP lacks fallbacks (and a bunch of basic OS features like direct file access? I don't know why that's the case).
The differences between them aren't even trade-offs, so much as randomly incomplete. Granted, I haven't spent any time whatsoever trying workarounds -- maybe it's simple enough (WPF is clearly the least problematic, if DPI scaling can be worked around without much trouble). I've just been looking at the charts like that, and my ultimate answer is "???"
>You can complain about the current state of things but I don't think there's any argument that Microsoft is doing the wrong thing here
I think there is; Microsoft runs the .net ecosystem as its steward -- it intentionally creates, markets and governs pretty much every major framework and components that exists. For better or worse, the state of .net ecosystem is owned by Microsoft -- unlike say, rust, golang, python, c++, ruby, etc where the language maintainers are mostly divorced from the language ecosystem, and make no real say in the matter beyond broad recommendation of community-run frameworks (python is a little different, being batteries-included, but it's also well-known that stdlib is where libraries go to die; no one recommends python stdlib as best-in-class of anything). .NET is of course a non-closed ecosystem, and the community does contribute quite significantly, but nonetheless, if it's first-class it's almost always MS.
The current state of affairs is essentially a result of bad ownership; the high rate of churn in the javascript ecosystem can be blamed on the JS communities. The high rate of churn in the MS ecosystem can be blamed on MS. They've constructed a complex environment with unclear recommendations and continuous deprecation (fine, they're never actually deprecated because MS policy on backwards compatibility is second to none, but its "legacy"), a terribly confused naming convention and wide swath of overlapping technologies.
Don't get me wrong, MS does cool work, but they've made quite a mess, and it's quite clearly a result of constantly changing vision of how the .NET ecosystem should look like -- in combination with new projects seemingly forgetting MS's stance on backwards compatibility (nothing is ever just superseded; there must be an upgrade path or you will end up maintaining both forever [Unity has the same fundamental misunderstanding of their feature development]).
If there are going to be 4 UI frameworks, they should be competing on different models, APIs and mindsets (eg MVC vs MVVC vs MVU -- it's absurd that they're competing on core fundamental features instead). Although on the web-side of things, I think this is actually the case for .NET -- blazor vs MVC5 represent entirely different ways of approaching the problem. But AFAICT winforms vs UWP are really, from the programmer's perspective, the same thing. The underlying technology support changes (but in that case, you would ideally have the options be functionally complete).
Anyways as I said I've only been looking at it for the last year but that's my interpretation thus far -- the only way to understand the .NET ecosystem is to understand all the paths MS has taken, untaken, and re-routed. because their actual messaging and vision (as it connects to what they've implemented) is quite confused
> WPF also lacks High DPI
WPF is system-DPI aware but it's not aware of per-monitor DPI as that feature didn't exist at all when WPF was conceived. I guess these days Microsoft doesn't consider that good enough to be called High DPI aware.
> I've just been looking at the charts like that, and my ultimate answer is "???"
I don't know -- I guess find it much less difficult than picking a web framework. The problem is that GUI frameworks (in any platform) are a complex mix of trade-offs. .NET and Windows is not the unique in this regard.
> The high rate of churn in the MS ecosystem can be blamed on MS.
I'm not sure you can call frameworks that have been around for multiple-decades a high rate of churn. The problems that Microsoft have is no different any of other platforms you've discussed. Yes, it's one organization but the problems are all the same. New developments require new framework but developers have lots of existing code. The fact that Winforms still exists is the same reason jQuery still exists.
Microsoft wanted everyone to move over to UWP -- this is kind of exactly what you're suggesting -- but developers just weren't interested. So they had to go back and take a more broad approach. But UWP is/was supposed to be the future.
> it's quite clearly a result of constantly changing vision of how the .NET ecosystem should look like
Not just the .NET ecosystem but the broader software industry as well. Many of the changes that Microsoft is making to .NET relate to changes made in mobile and on the web. As the world changes, .NET changes, and thus Microsoft maybe adds a new GUI framework to fit that world. Without that sort of change, we'd all still be using Winforms.
But I don't disagree. Microsoft has been in a long transition period to .NET core and they're finally started to come out the other side. With that done, there will be renewed effort to bring everything else together as well. I suspect in another couple of years this mess will be a lot more cleaned up. But I expect, unlike with other platforms, that most of my code written today will still work with whatever Microsoft comes up with in the future.
WPF is system-DPI aware but it's not aware of per-monitor DPI as that feature didn't exist at all when WPF was conceived. I guess these days Microsoft doesn't consider that good enough to be called High DPI aware.
> I've just been looking at the charts like that, and my ultimate answer is "???"
I don't know -- I guess find it much less difficult than picking a web framework. The problem is that GUI frameworks (in any platform) are a complex mix of trade-offs. .NET and Windows is not the unique in this regard.
> The high rate of churn in the MS ecosystem can be blamed on MS.
I'm not sure you can call frameworks that have been around for multiple-decades a high rate of churn. The problems that Microsoft have is no different any of other platforms you've discussed. Yes, it's one organization but the problems are all the same. New developments require new framework but developers have lots of existing code. The fact that Winforms still exists is the same reason jQuery still exists.
Microsoft wanted everyone to move over to UWP -- this is kind of exactly what you're suggesting -- but developers just weren't interested. So they had to go back and take a more broad approach. But UWP is/was supposed to be the future.
> it's quite clearly a result of constantly changing vision of how the .NET ecosystem should look like
Not just the .NET ecosystem but the broader software industry as well. Many of the changes that Microsoft is making to .NET relate to changes made in mobile and on the web. As the world changes, .NET changes, and thus Microsoft maybe adds a new GUI framework to fit that world. Without that sort of change, we'd all still be using Winforms.
But I don't disagree. Microsoft has been in a long transition period to .NET core and they're finally started to come out the other side. With that done, there will be renewed effort to bring everything else together as well. I suspect in another couple of years this mess will be a lot more cleaned up. But I expect, unlike with other platforms, that most of my code written today will still work with whatever Microsoft comes up with in the future.
> Is C# really that hard for beginners?.
No data but from a lot of anecdotal experience I don't believe so - quite3e opposite.
I've never seen beginners (interns generally) or non-C# programmers (adept at other languages) come up to speed and start meaningfully contributing to projects on any other language other than C#.
With other languages (I've worked with) this just isn't true. I've never seen anyone but the most prodigious pick up C++, Java, JavaScript as quickly in professional contexts.
IMO C# is such an easy on-boarding languages that when hiring into C# teams it's not even a factor considering a candidates particular language experience.
As much as this is due to the language and well-organized libraries I think the tooling is just as much to thank. The dev experience in VS with a copy of ReSharper installed is unparalleled in software engineering.
No data but from a lot of anecdotal experience I don't believe so - quite3e opposite.
I've never seen beginners (interns generally) or non-C# programmers (adept at other languages) come up to speed and start meaningfully contributing to projects on any other language other than C#.
With other languages (I've worked with) this just isn't true. I've never seen anyone but the most prodigious pick up C++, Java, JavaScript as quickly in professional contexts.
IMO C# is such an easy on-boarding languages that when hiring into C# teams it's not even a factor considering a candidates particular language experience.
As much as this is due to the language and well-organized libraries I think the tooling is just as much to thank. The dev experience in VS with a copy of ReSharper installed is unparalleled in software engineering.
It’s been a long time, but having been a student working on a .NET project with no C# background, I’d say that for me it had less to do with the language than the discoverability of language features through Visual Studio.
> The dev experience in VS with a copy of ReSharper installed is unparalleled in software engineering.
It's pretty great until you tried out Rider :D, okay it's more or less the same as Resharper.
I'm not a Java developer, but i suppose IntelliJ will give you quite a similar development experience as Resharper/Rider?
It's pretty great until you tried out Rider :D, okay it's more or less the same as Resharper.
I'm not a Java developer, but i suppose IntelliJ will give you quite a similar development experience as Resharper/Rider?
For beginners, Java is pretty much C# with uppercase types, so I have a hard time believing one is easier than the other.
: They don't even stop and wonder any of the issues discussed in the article, they simply make the project type they want in visual studio and start learning the guts of programming.
As someone who did exactly this 25 years ago with VB, I really feel bad for new developers who don't have this nice experience and instead need to wrangle with half broken tools.
As someone who did exactly this 25 years ago with VB, I really feel bad for new developers who don't have this nice experience and instead need to wrangle with half broken tools.
My undergrad Info Systems degree switched from teaching Programming I and II in C++ and Java to C# and Java recently. I think the reason was market relevance? Either way [coming from a very hacky python background] it taught me the core concepts well. I continue to enjoy C# after graduating but have not touched Java since
C# itself isn't hard, but the ecosystem is. I have been writing code for years and wanted to take a look at dotnet not that long ago. There are no tutorials on how to make something that is not also a tutorial on visual studio. I want to learn how to make a webapp or whatever in C#.NET, learn the paradigms, classes, and functions that I need to do that. I'll go look into Visual Studio after I understand the basics to make things easier, but I shouldn't need that as the price of admission. The author addresses this with a comment about goland. But the point is that any other language, the beginner material is about "here's a main.go text file that starts a web server..." and not "click some buttons in one specific IDE and magic happens". I can use emacs, vi, or VScode to write C, go, rust, python, javascript, etc... just about everything. But not C#.
You don't need Visual Studio for C#, I write all C# and F# in VS Code with official MS extension, you can use the dotnet CLI to do everything (install packages, build tasks, etc, just like cargo/npm/etc).
The experience is surprisingly good.
If you want to create and build + run a .NET web API, you just do:
"dotnet new webapi"
>cd into the directory
"dotnet run"
The experience is surprisingly good.
If you want to create and build + run a .NET web API, you just do:
"dotnet new webapi"
>cd into the directory
"dotnet run"
Just a note that this isn't true anymore. All the official C# tutorials default to VSCode + dotnet CLI. The Web framework tutorials also let you switch instructions depending on what editor you're using.
When I imagine starting to learn C# right now, I think I would need to:
- install the newest Visual Studio with default config
- create a new console app project
- start writing code in the template's main function
Granted, I have to know whether I want to create the console app in .Net Core 3.1 or .Net 5 or whatever, but I imagine I can find the answer to that pretty quickly and move on. Usually the answer will be "the newest version you have installed".
Any language feature I want to play with is just one automatic import tip away, and most of the features I would explore as a total novice don't even need that.
The complexity of various Nuget packages, ASP.Net versions, older versions of .Net only arrives once you need to uplift older projects, maintain libraries to be used across different framework versions etc. Those are tasks for a more experienced developer, for a good reason, and I believe this is true for any technology stack.
EDIT: formatting
- install the newest Visual Studio with default config
- create a new console app project
- start writing code in the template's main function
Granted, I have to know whether I want to create the console app in .Net Core 3.1 or .Net 5 or whatever, but I imagine I can find the answer to that pretty quickly and move on. Usually the answer will be "the newest version you have installed".
Any language feature I want to play with is just one automatic import tip away, and most of the features I would explore as a total novice don't even need that.
The complexity of various Nuget packages, ASP.Net versions, older versions of .Net only arrives once you need to uplift older projects, maintain libraries to be used across different framework versions etc. Those are tasks for a more experienced developer, for a good reason, and I believe this is true for any technology stack.
EDIT: formatting
Those assumptions on what you would need to get started are actually outdated. C#/.NET are updated often. No need for Visual Studio or even Windows; you can get started faster with VSCode + .NET Core.
And you don't even need a main function anymore; you can just start writing code at the top level in a blank file without any class.
And you don't even need a main function anymore; you can just start writing code at the top level in a blank file without any class.
I agree with all of the above. I love C# as a language having used it in Unity in the past.
I wanted to try to a server backend with it, but I was lost as to which framework to use (ASP.net / .NET Core / .Net 5) so I ended up choosing neither.
Which is a shame, because I really really like the language
I wanted to try to a server backend with it, but I was lost as to which framework to use (ASP.net / .NET Core / .Net 5) so I ended up choosing neither.
Which is a shame, because I really really like the language
The framework you choose doesn't even matter that much. You're unlikely to even a notice a difference and changing from one to another is often as easily as selecting it from a drop-down (or editing a file) and recompiling.
Yes, you can get into situations where something you're doing needs one or the other but it's very rare.
Yes, you can get into situations where something you're doing needs one or the other but it's very rare.
I'm sure you're right, but as a beginner in a new programming language there is a real fear of "choosing the wrong thing"
You know that it will not matter that much, because you're familiar enough with all three. A beginner doesn't have that information.
Think about it like this: Is it better for beginners to have such a 'non-choice'? Or is it better for them to be presented 1 maybe 2 options and say pick from these 2 these are the differences?
You know that it will not matter that much, because you're familiar enough with all three. A beginner doesn't have that information.
Think about it like this: Is it better for beginners to have such a 'non-choice'? Or is it better for them to be presented 1 maybe 2 options and say pick from these 2 these are the differences?
If you start a project in the IDE (or even the command line) there is already a default selected for you. Whatever that default is, would be fine. I don't think there's a single .NET tutorial out there that has you explicitly select the framework.
The problem is you're informed enough to ask the question! If you had no idea about the different frameworks you wouldn't have a problem.
The problem is you're informed enough to ask the question! If you had no idea about the different frameworks you wouldn't have a problem.
> I wanted to try to a server backend with it, but I was lost as to which framework to use (ASP.net / .NET Core / .Net 5) so I ended up choosing neither.
The new C# tutorials have solved a lot of this issue just by completely skipping over the legacy parts of .NET (.NET Framework & ASP.NET) and using the CLI to create a new project.
You install .NET 5 (for context, it's just a newer version of .NET Core with the naming realigned), and then write `dotnet new webapi` which will create a new ASP.NET Core API project.
The new C# tutorials have solved a lot of this issue just by completely skipping over the legacy parts of .NET (.NET Framework & ASP.NET) and using the CLI to create a new project.
You install .NET 5 (for context, it's just a newer version of .NET Core with the naming realigned), and then write `dotnet new webapi` which will create a new ASP.NET Core API project.
I appreciate the reply, and I will try that.
However this sentence made me inadvertently laugh, because it captures every bit of confusion I had.
> You install .NET 5 (for context, it's just a newer version of .NET Core with the naming realigned), and then write `dotnet new webapi` which will create a new ASP.NET Core API project.
However this sentence made me inadvertently laugh, because it captures every bit of confusion I had.
> You install .NET 5 (for context, it's just a newer version of .NET Core with the naming realigned), and then write `dotnet new webapi` which will create a new ASP.NET Core API project.
> However this sentence made me inadvertently laugh, because it captures every bit of confusion I had
Haha, for further context, .NET 5 is the SDK + runtime. ASP.NET Core is the default Web framework that includes a ton of out of the box functionality.
I'd highly recommend taking a read of https://docs.microsoft.com/en-us/aspnet/core/introduction-to..., which links to the relevant tutorials for your scenario.
Haha, for further context, .NET 5 is the SDK + runtime. ASP.NET Core is the default Web framework that includes a ton of out of the box functionality.
I'd highly recommend taking a read of https://docs.microsoft.com/en-us/aspnet/core/introduction-to..., which links to the relevant tutorials for your scenario.
That's clears up a lot actually! Thx
Just install newest .NET 5 and type `dotnet new mvc` or `dotnet new webapi`
.NET definitely has a messy past but someone arriving today probably has the easiest time ever getting started because so much has changed to become a single streamlined product. All these opinions are weighed down by the very history that beginners don't have.
The expansive standard library, web/desktop/mobile/gaming output, Visual Studio (Code) IDEs, fantastic in-depth guides and documentation [1], dev evangelists like Scott Hanselman [2], and constant stream of content from MS team and community [3] makes it not only easy to get started but also continue until you're an expert.
I find it strange to complain about a 12 year old stackoverflow answer when other environments like nodejs are a nightmare once you get past the toy project stage. Anyone can write a simple tutorial for a to-do app, but it's how well you can grow that to a real complex system that determines how well-designed and productive an environment really is. And I've yet to find anything better.
1. https://dotnet.microsoft.com/ 2. https://www.hanselman.com/ 3. https://dotnet.microsoft.com/platform/community
The expansive standard library, web/desktop/mobile/gaming output, Visual Studio (Code) IDEs, fantastic in-depth guides and documentation [1], dev evangelists like Scott Hanselman [2], and constant stream of content from MS team and community [3] makes it not only easy to get started but also continue until you're an expert.
I find it strange to complain about a 12 year old stackoverflow answer when other environments like nodejs are a nightmare once you get past the toy project stage. Anyone can write a simple tutorial for a to-do app, but it's how well you can grow that to a real complex system that determines how well-designed and productive an environment really is. And I've yet to find anything better.
1. https://dotnet.microsoft.com/ 2. https://www.hanselman.com/ 3. https://dotnet.microsoft.com/platform/community
I'm currently trying to write a windows app and coming from web development (Python/Django and React) it is bewildering.
Part of the problem is with web development, complicated as it is, the tutorials at least get you to a complete, working example. The windows tutorials seem to be very piecemeal where you start with a mostly complete app and fill in a couple things, but never get the whole picture.
And like in your first link, click on "Desktop". Ok, I want to make a desktop app. Now there are four options WPF, WinForms, UWP and Xamarin. Ok...Why are there four options? What are the differences? Are one or more of them about to be deprecated? What do I need to consider in order to choose one over the others?
I could go on. The windows developer website did point to some helpful C# tutorials and the language is actually pretty nice to work with, but figuring out how to do basic things like -- how do I store state in the application, has been very confusing.
Part of the problem is with web development, complicated as it is, the tutorials at least get you to a complete, working example. The windows tutorials seem to be very piecemeal where you start with a mostly complete app and fill in a couple things, but never get the whole picture.
And like in your first link, click on "Desktop". Ok, I want to make a desktop app. Now there are four options WPF, WinForms, UWP and Xamarin. Ok...Why are there four options? What are the differences? Are one or more of them about to be deprecated? What do I need to consider in order to choose one over the others?
I could go on. The windows developer website did point to some helpful C# tutorials and the language is actually pretty nice to work with, but figuring out how to do basic things like -- how do I store state in the application, has been very confusing.
> Are one or more of them about to be deprecated?
All of them are.
Not officially, of course, but practically speaking all of them are dead-ends.
MAUI is the "new hotness", which means that it'll only become obvious that it is also a dead end in about a year and a half.
I wish I was joking.
All of them are.
Not officially, of course, but practically speaking all of them are dead-ends.
MAUI is the "new hotness", which means that it'll only become obvious that it is also a dead end in about a year and a half.
I wish I was joking.
At least until last year, I think the community used mostly winforms if it is for Windows operating system. MS is not too happy about that.
Winforms is easy to use and understand, everything is pretty much there and I can get started with no issues. WPF,on the other hand,is a clusterfuck, not even sure who managed to come up with it.
There are a lot of great ideas in WPF, but sadly the implementation of those ideas is really, really clunky.
If you're experienced with WPF you can build very complex applications quickly, but the learning curve is very steep. There's also a million gotchas when it comes to performance, and when things go wrong, they go wrong bad, and you end up spending many hours trying to figure out why you're getting a stack overflow exception :)
WinForms is a joy, though, and making custom GDI+ components is easy. I just wish they made WinForms 2, called it DotNetForms, made it cross-platform and high-DPI aware.
If you're experienced with WPF you can build very complex applications quickly, but the learning curve is very steep. There's also a million gotchas when it comes to performance, and when things go wrong, they go wrong bad, and you end up spending many hours trying to figure out why you're getting a stack overflow exception :)
WinForms is a joy, though, and making custom GDI+ components is easy. I just wish they made WinForms 2, called it DotNetForms, made it cross-platform and high-DPI aware.
Seriously. Microsoft is one of the few companies with enough historical successes that teams can have "not invented here"isms about first party products.
Maybe start with why people are still using a 19 year old UI framework.
Maybe start with why people are still using a 19 year old UI framework.
Because winforms is an incredibly easy and solid technology. It's a joy to work with.
CPU rendering should not be a thing in 2021
When WPF was first released, toy applications would make both my CPU and GPU fan spin up to gas turbine levels.
Now only WPF applications that try to show more than a dozen controls at a time make the GPU fan spin up, a huge improvement. I suppose this explains the new "flat" style with huge amounts of white space. It's not about elegance, or style -- it's the only way to keep fan speeds tolerable.
Now only WPF applications that try to show more than a dozen controls at a time make the GPU fan spin up, a huge improvement. I suppose this explains the new "flat" style with huge amounts of white space. It's not about elegance, or style -- it's the only way to keep fan speeds tolerable.
CPU rendering is an implementation detail for the majority of WinForms. Unless you're running the paint component command yourself, that could be offloaded elsewhere.
It is an implementation detail, but we are talking about a concrete framework with one implementation, not an open spec API. And as far as I know it visibly flickers on any window that has like more than 3 input forms.
CPU GUI rendering was reasonably fast for Win32 apps on Pentium III. Modern CPU many times faster and I expect GUI rendering to use negligible fraction of CPU resources. Why this is not the case? Display resolution nowadays is higher, but the difference in pixel numbers is smaller than difference in CPU performance.
Older graphics were much more simpler, like draw a line here and here, where you have to iterate through like 400px per line of a window border.
Also, smaller resolution.
CPUs are fast, and rendering could be multithreaded, but 4-16 very fast cores will still be slower than the very very wide SIMD of GPUs that can simultaneously operate on many many pixels. GPUs can also change to a different “lane” to compute while it waits on IO like some graphics. You also got gradients, transparency and the like, so you basically always have to do a full pass over every pixel, so on the order of 1000*1000 pixels. So GUI rendering definitely doesn’t use negligible CPU resources. It is the canonical example for a task that can be parallelized, so it only makes sense to do so.
CPUs are fast, and rendering could be multithreaded, but 4-16 very fast cores will still be slower than the very very wide SIMD of GPUs that can simultaneously operate on many many pixels. GPUs can also change to a different “lane” to compute while it waits on IO like some graphics. You also got gradients, transparency and the like, so you basically always have to do a full pass over every pixel, so on the order of 1000*1000 pixels. So GUI rendering definitely doesn’t use negligible CPU resources. It is the canonical example for a task that can be parallelized, so it only makes sense to do so.
> smaller resolution
In early 2000s I've used a PC with 800x600px CRT monitor and one of early Intel Celerons. My memory is fuzzy, but at best it was cheapest Coppermine Celeron (more likely Mendocino). Nowadays I use notebook with Intel Core i5 2540M (quite old) and the biggest display I use has 2560x1440 pixels (much newer than notebook).
Now I have at most (2560x1440)/(800x600) ~ 8 times more pixels. I didn't find numbers from the same benchmark for Coppermine and i5 2540M, but I expect 2540M to be at least 10 times faster than slowest Coppermine.
So I think modern CPU are fast enough to render GUI at least as fast as 15-20 years ago. GPU of course can do this much faster, cannot argue with this.
> You also got gradients, transparency and the like
I wonder if users really want this or we have it for other reasons (like developers want to show-off and companies want to sell new OS/App). For me the peak GUI was around Windows 2000 - most of what come next was not really an improvement for me. I'm not representative (and mostly use i3 WM, not Windows), but the fact that Widnows XP was used well beyond official support ended and many users around the world still use Windows 7 tells that many users don't really want to follow the latest GUI trends, but instead they are forced to.
In early 2000s I've used a PC with 800x600px CRT monitor and one of early Intel Celerons. My memory is fuzzy, but at best it was cheapest Coppermine Celeron (more likely Mendocino). Nowadays I use notebook with Intel Core i5 2540M (quite old) and the biggest display I use has 2560x1440 pixels (much newer than notebook).
Now I have at most (2560x1440)/(800x600) ~ 8 times more pixels. I didn't find numbers from the same benchmark for Coppermine and i5 2540M, but I expect 2540M to be at least 10 times faster than slowest Coppermine.
So I think modern CPU are fast enough to render GUI at least as fast as 15-20 years ago. GPU of course can do this much faster, cannot argue with this.
> You also got gradients, transparency and the like
I wonder if users really want this or we have it for other reasons (like developers want to show-off and companies want to sell new OS/App). For me the peak GUI was around Windows 2000 - most of what come next was not really an improvement for me. I'm not representative (and mostly use i3 WM, not Windows), but the fact that Widnows XP was used well beyond official support ended and many users around the world still use Windows 7 tells that many users don't really want to follow the latest GUI trends, but instead they are forced to.
Well, drawing GUIs one pixel (okay with SIMD 4-8) at a time on a CPU core is still way too big of an overkill, especially that for display it usually gets through a GPU, so it gets written to memory and then copied over vs being generated into video memory itself. A CPU core is way too expensive for these “easy” calculation, like paint it black.
And I’m not sure about the dates, but iGPUs have been around for quite some time now. Also, Windows 7 (I think the change happened at Vista) most definitely uses a compositor, so there is no CPU rendering at that level.
And I’m not sure about the dates, but iGPUs have been around for quite some time now. Also, Windows 7 (I think the change happened at Vista) most definitely uses a compositor, so there is no CPU rendering at that level.
[deleted]
I can confirm that. If you don't know exactly what you are doing, don't build a desktop application. Build a web application, you are safe and protected there.
I'm sad to say I agree, because building apps with WinForms and WPF is incredibly fast and enjoyable. Using the RAD approach to application design makes it super easy to stick together working, *useful* software very quickly, that doesn't have to look terrible.
I miss the days of writing desktop software, it was nice :)
I miss the days of writing desktop software, it was nice :)
See, I'm an old and crusty person because if I'm writing some internal tooling for a company and I could use C# and we're in Windows, WinForms is the obvious answer. I never liked WPF and WinForms was drag and drop and crazy easy, so I would just use it. It's not like it's actually going away, Microsoft doesn't fully deprecate anything that could be used by any of their enterprise customers and I'm sure looooots of them use WinForms.
> MAUI is the "new hotness"
Wait, I thought that Blazor Desktop was the "new hotness" this week?
Wait, I thought that Blazor Desktop was the "new hotness" this week?
Here we go again...
This is why people just stick with winforms.
This is why people just stick with winforms.
> MAUI
What?! This wasn’t even on the list!
What?! This wasn’t even on the list!
> Now there are four options WPF, WinForms, UWP and Xamarin. Ok...Why are there four options? What are the differences? Are one or more of them about to be deprecated?
You're most likely best of picking WinForms. It's old school, but it seems like it's going to be the one Microsoft will have the hardest time killing.
WPF, UWP and Xamarin fine frameworks, but for the 0.9X developer who just want a window, with a few input and some buttons, you can't beat WinForms in ease of use.
My reasoning is that most of the developers who saw WPF and jumped on that, are the same who will more easily jump to UWP, and from there to what ever comes next. The WinForms developer aren't moving.
You're most likely best of picking WinForms. It's old school, but it seems like it's going to be the one Microsoft will have the hardest time killing.
WPF, UWP and Xamarin fine frameworks, but for the 0.9X developer who just want a window, with a few input and some buttons, you can't beat WinForms in ease of use.
My reasoning is that most of the developers who saw WPF and jumped on that, are the same who will more easily jump to UWP, and from there to what ever comes next. The WinForms developer aren't moving.
VS + WinForms is like the Playschool Windows GUI development kit.
That sounds like talking it down, but I'm not actually.
Good for things like the sales guy wants something that pulls data out of a company database and sticks it in a excel file. And wants it tomorrow.
That sounds like talking it down, but I'm not actually.
Good for things like the sales guy wants something that pulls data out of a company database and sticks it in a excel file. And wants it tomorrow.
As a casual programmer, I've used WinForms successfully to write both trivial and somewhat complex GUI tools. I've never been able to use WPF to write anything useful, I just couldn't scrape together the patience required to adapt to it.
Getting the job done is an important aspect of a toolchain.
> 0.9X developer
That's pretty fantastic. Stealing this!
That's pretty fantastic. Stealing this!
Meh, everybody is a 0.9X developer in many areas outside of their specialty. I'm a data engineer who specializes in security. I only need to generate a GUI or CRUD webapp once in a blue moon. So a stack that makes sane choices for me and holds my hand a bit is greatly appreciated.
I have the opposite problem. On a PC, you can always store data, the graphics display exactly how you want, the feedback is instant, and you always know the state of things. You don't ever get disconnected from the user, nor have more than one at a time.
My favorite platform is Lazarus/Free Pascal. The documentation is a bit sketchy, but the IDE and the applications it outputs seem solid. I'd prefer Delphi, but they priced themselves out of my world 20 years ago.
My favorite platform is Lazarus/Free Pascal. The documentation is a bit sketchy, but the IDE and the applications it outputs seem solid. I'd prefer Delphi, but they priced themselves out of my world 20 years ago.
Wow. I knew Delphi was priced high, but I just went and looked...$1600 + $400 a year every year thereafter.
And they have a community edition...but if you make $5k or more as a consultant, -even if it's not using Delphi-, you can't use it.
And they have a community edition...but if you make $5k or more as a consultant, -even if it's not using Delphi-, you can't use it.
> how do I store state in the application
I can’t speak for all of the challenges you might be dealing with, but this one in particular seems like something specific to native development. You have a wealth of options, and at the same time because of that fact there is are fewer defaults compared to web dev and you have to do more work to make the decision. Personally I default to two options unless performance requires otherwise: SQLite or JSON stored in files.
I can’t speak for all of the challenges you might be dealing with, but this one in particular seems like something specific to native development. You have a wealth of options, and at the same time because of that fact there is are fewer defaults compared to web dev and you have to do more work to make the decision. Personally I default to two options unless performance requires otherwise: SQLite or JSON stored in files.
Desktop UI is very different from web, and most languages have multiple choices. WPF is the latest Windows-only, Windows Forms is legacy (from Windows XP era), Xamarin is cross-platform. These is in the descriptions on the page, or you can click on the documentation and follow the breadcrumbs to the main topic for the Desktop Guide: https://docs.microsoft.com/en-us/dotnet/desktop/?view=netdes...
However you can just use Electron if you want to reuse web UI skills on desktop (although HN hates that). Likewise you can solve the state problem the same as a web backend. Use an external database, or a local database, write to a file, just keep it in memory, or use any of the OS-specific options. I recommend starting with EntityFramework (an ORM) and using the Sqlite provider: https://docs.microsoft.com/en-us/ef/core/get-started/overvie...
However you can just use Electron if you want to reuse web UI skills on desktop (although HN hates that). Likewise you can solve the state problem the same as a web backend. Use an external database, or a local database, write to a file, just keep it in memory, or use any of the OS-specific options. I recommend starting with EntityFramework (an ORM) and using the Sqlite provider: https://docs.microsoft.com/en-us/ef/core/get-started/overvie...
>WPF is the latest Windows-only
No it isn't. WinRT, UWP and WinUI are all later than WPF.
No it isn't. WinRT, UWP and WinUI are all later than WPF.
Native UI development is a mess. On any platform. It's super complicated.
You will always be unhappy with any choice of UI framework, on any platform :)
You will always be unhappy with any choice of UI framework, on any platform :)
This is probably more of a Windows problem than a .NET/C# problem, but it's a very real problem.
I've tried to get started with F# on Mac twice, once a few months ago, and 18 months before that. Could not get it working. When the official getting started guides don't work, that is a very bad sign. I will be staying away.
That's weird. I just tried the minimal example on alpine, and it works right out of the box.
Installing .NET 5 should be easy on macOS as they even provide an installer.
Installing .NET 5 should be easy on macOS as they even provide an installer.
# Start fresh alpine
docker run -it alpine
# install tools and .NET 5.0
apk update && apk add wget bash vim icu-libs krb5-libs libgcc libintl libssl1.1 libstdc++ zlib
wget https://download.visualstudio.microsoft.com/download/pr/21fdb75c-4eb5-476d-a8b8-1d096e4b7b14/c1f853410a58713cf5a56518ceeb87e8/dotnet-sdk-5.0.202-linux-musl-x64.tar.gz
mkdir -p $HOME/dotnet && tar zxf dotnet-sdk-5.0.202-linux-musl-x64.tar.gz -C $HOME/dotnet
export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet
# create f# project
mkdir my-fsharp-demo && cd my-fsharp-demo
dotnet new console -lang f#
# run project, it will show "Hello world from F#"
dotnet run
It's regrettable, but F# has never seen anything like the kind of support C# and VB.NET have. It was and remains something of a "hobby" product, albeit one that sees lots of use in some specialized industries.
Although F#-the-language is top-notch, the surrounding bits - editor experience, documentation, libraries, tooling - just don't get the investment they need to be on par with the sibling languages.
What I mean to say is, don't judge .NET just by your experience with F#. C# is the happy path.
Although F#-the-language is top-notch, the surrounding bits - editor experience, documentation, libraries, tooling - just don't get the investment they need to be on par with the sibling languages.
What I mean to say is, don't judge .NET just by your experience with F#. C# is the happy path.
When people talk about .NET, they're mostly always talking about C#.
Sure, there's a bunch of other languages that run on the CLR - but for the most part, the broadest, most well tested, path is doing stuff in C#.
Sure, there's a bunch of other languages that run on the CLR - but for the most part, the broadest, most well tested, path is doing stuff in C#.
What was the error?
Also like the others say, F# on dotnet is like Groovy for the JVM. It's nowhere near the popularity. Any reason you didn't try C# instead?
Also like the others say, F# on dotnet is like Groovy for the JVM. It's nowhere near the popularity. Any reason you didn't try C# instead?
It seems like you understand the story for both of them. Any reason why F# is not a valid starting point language on Mac?
Because it's a community language. Microsoft doesn't officially support it fully. So you have 20-30 or however many volunteer devs (probably fewer) working on it in their spare time.
If you're just getting used to the platform, you're shooting yourself in the foot by going with niche setups. Try C# first to figure out your way around the platform and then branch out, not the other way around.
If you're just getting used to the platform, you're shooting yourself in the foot by going with niche setups. Try C# first to figure out your way around the platform and then branch out, not the other way around.
>Microsoft doesn't officially support it fully.
Nonsense all you have to do is install the dotnet sdk and run a single line in your terminal.
Nonsense all you have to do is install the dotnet sdk and run a single line in your terminal.
dotnet new console -lang "F#" -o "project"Yeah, it's also included in VS classic, if you want to get super fancy. Does it get the same level of support as C#? Hardly. Do bugs get fixed as fast? Maybe.
I think there was a Microsoft article that summed it up nicely: there are millions of C# developers (ergo the focus), tens of thousands if not low hundreds of thousands of VB.Net developers (ergo the life support) and maybe hundreds or low thousands of F# developers (ergo the fact that Microsoft offers some integration points but expects the already small community to develop and polish the actual implementation).
It took F# several years to fully get supported on .NET Core (type providers and such). I know, because I was watching the Github issue for it for at least 2 years).
I think there was a Microsoft article that summed it up nicely: there are millions of C# developers (ergo the focus), tens of thousands if not low hundreds of thousands of VB.Net developers (ergo the life support) and maybe hundreds or low thousands of F# developers (ergo the fact that Microsoft offers some integration points but expects the already small community to develop and polish the actual implementation).
It took F# several years to fully get supported on .NET Core (type providers and such). I know, because I was watching the Github issue for it for at least 2 years).
It is. The OP was likely confused with a tool or had a specialized use case tied to Windows that they're not communicating. All the official guides for getting started work. Using specialized tools or components meant for Windows development (e.g., Type Providers not ported to support .NET Core)on a different OS may not work so well.
It's valid, just clunky to get going the first time. F# dev team is only ~7 people at MS, the rest is community supported projects and github issues. So while F# devs measure in the 10,000s, C# devs measure in the 100,000s
Gave it a serious go but it still lives inside the Windows + Visual Studio bubble.
Trying to use .NET on Linux with Visual Studio Code is pain: .NET developers expect you to learn APIs through intellisense and don't publish API docs, Windows tutorials assume you're running Visual Studio, and a lot of MS's own API docs are bewildering with .NET jargon that you won't understand.
Trying to use .NET on Linux with Visual Studio Code is pain: .NET developers expect you to learn APIs through intellisense and don't publish API docs, Windows tutorials assume you're running Visual Studio, and a lot of MS's own API docs are bewildering with .NET jargon that you won't understand.
For a typed language completion like Intellisense is a very important tool for any developer. There is limited completion support available in VS Code. If you want a proper IDE for .NET on Linux, try out JetBrains Rider. It is not free, but great.
I don't understand what you dislike about the API documentation Microsoft provides with .NET, it's not always perfect, but I would say it has nearly 100% coverage: https://docs.microsoft.com/en-us/dotnet/api/
And because .NET used to be Windows only there are a lot of Windows tutorials. But you can anyway skip them, as they mostly describe the old .NET 4.x. Find newer .NET Core tutorials. Even if they provide you screenshots of Visual Studio on Windows, you can do all of it with any text editor. Some scaffolding you maybe need to do on the command line.
I don't understand what you dislike about the API documentation Microsoft provides with .NET, it's not always perfect, but I would say it has nearly 100% coverage: https://docs.microsoft.com/en-us/dotnet/api/
And because .NET used to be Windows only there are a lot of Windows tutorials. But you can anyway skip them, as they mostly describe the old .NET 4.x. Find newer .NET Core tutorials. Even if they provide you screenshots of Visual Studio on Windows, you can do all of it with any text editor. Some scaffolding you maybe need to do on the command line.
You exactly understand and confirm my point - outside of the bubble Windows/VS bubble, it's not a super nice developer experience. If you want to work hard to make it work: you can, but... why go out of your way?
And I haven't said anything about building GUIs here yet, which is another world of pain on .NET.
And I haven't said anything about building GUIs here yet, which is another world of pain on .NET.
> Gave it a serious go but it still lives inside the Windows + Visual Studio bubble.
I work in a small shop and most of the developers use Visual Studio with Linux or a Mac. Most of the developers that don't bother with anything outside of Windows won't be open sourcing their libs or documenting their stuff anyways.
This may have been true back in 2016/7 when .NET Core first turned up but it just isn't true anymore.
> Trying to use .NET on Linux with Visual Studio Code is pain: .NET developers expect you to learn APIs through intellisense and don't publish API docs,
I've used VS Code for small projects fine on my Mac. However I can see it being a pain on larger projects and you will need a large IDE. However the same could be said for a large Java project.
> Windows tutorials assume you're running Visual Studio, and a lot of MS's own API docs are bewildering with .NET jargon that you won't understand.
I don't want to sound like a dick, but yes the Windows tutorials will expect you to use Visual Studio as that is the IDE that primary IDE of people using Windows.
As for complaints about jargon. As a C# developer that now transitioning to Python. The Python docs having lot of Python Jargon you won't understand (at first). Every language has its own jargon.
I work in a small shop and most of the developers use Visual Studio with Linux or a Mac. Most of the developers that don't bother with anything outside of Windows won't be open sourcing their libs or documenting their stuff anyways.
This may have been true back in 2016/7 when .NET Core first turned up but it just isn't true anymore.
> Trying to use .NET on Linux with Visual Studio Code is pain: .NET developers expect you to learn APIs through intellisense and don't publish API docs,
I've used VS Code for small projects fine on my Mac. However I can see it being a pain on larger projects and you will need a large IDE. However the same could be said for a large Java project.
> Windows tutorials assume you're running Visual Studio, and a lot of MS's own API docs are bewildering with .NET jargon that you won't understand.
I don't want to sound like a dick, but yes the Windows tutorials will expect you to use Visual Studio as that is the IDE that primary IDE of people using Windows.
As for complaints about jargon. As a C# developer that now transitioning to Python. The Python docs having lot of Python Jargon you won't understand (at first). Every language has its own jargon.
Java projects publish Javadoc which is good - you can sit down and understand an API. It's not the same story on .NET.
> Windows tutorials will expect you to use Visual Studio as that is the IDE that primary IDE of people using Windows.
Yep, hence the bubble. Python doesn't have this problem, for example.
> Windows tutorials will expect you to use Visual Studio as that is the IDE that primary IDE of people using Windows.
Yep, hence the bubble. Python doesn't have this problem, for example.
> Java projects publish Javadoc which is good - you can sit down and understand an API. It's not the same story on .NET.
Almost all the projects I use with .NET have sufficient docs on their sites. MSDN has the full docs on their site. If there are specific projects that are a problem that are outside of that. Well that is a problem with their project, go and complain to them.
> Yep, hence the bubble. Python doesn't have this problem, for example.
Yes Python does have similar problems. A lot of time people assume you are using a *nix machine and if you aren't then you normally have to faff with some work around. Go has the same problem a lot of things just don't work properly on Windows (at the least the last time I bothered). The same is true with Java, Go, Ruby etc.
As for the tutorials. I've just gone on the ASP.NET site and there is a tutorial for Windows, Linux and MacOS in the tabs on the site.
Almost all the projects I use with .NET have sufficient docs on their sites. MSDN has the full docs on their site. If there are specific projects that are a problem that are outside of that. Well that is a problem with their project, go and complain to them.
> Yep, hence the bubble. Python doesn't have this problem, for example.
Yes Python does have similar problems. A lot of time people assume you are using a *nix machine and if you aren't then you normally have to faff with some work around. Go has the same problem a lot of things just don't work properly on Windows (at the least the last time I bothered). The same is true with Java, Go, Ruby etc.
As for the tutorials. I've just gone on the ASP.NET site and there is a tutorial for Windows, Linux and MacOS in the tabs on the site.
I've been a .NET developer since 2003, I've been on Linux exclusively for the last 2 years.
.NET on Linux with Jetbrains Rider, is a far better experience than Windows and Visual Studio.
VSCode isn't worth looking at for .NET Development.
.NET on Linux with Jetbrains Rider, is a far better experience than Windows and Visual Studio.
VSCode isn't worth looking at for .NET Development.
I jumped into .NET w/o any background while running Linux - it's not a pleasant experience when you lack the heavy Windows+VS background you've had. Perhaps Jetbrains Rider is better, but at this point you know all the ins and outs of the platforms - a beginner lack that.
The experience of picking up a new IDE, language, framework, flow, etc, is no different regardless of it being .NET or anything else. There's a learning curve.
My point is not that experience is easy or hard, just that when comparing the two side by side, the experience of being a .NET developer on linux is good, and I would argue with jetbrains rider, is better than being on Windows with Visual Studio.
My point is not that experience is easy or hard, just that when comparing the two side by side, the experience of being a .NET developer on linux is good, and I would argue with jetbrains rider, is better than being on Windows with Visual Studio.
Sorry, I don't buy it - tried it for 4 years and that's just not the case. It was stumbling block to be on Linux and without Visual Studio with every tutorial or instructions. I think you have it easy since you know the ecosystem so well - and coming over from Windows, you know what alternatives to look for.
For me, even simple things like getting C# aliases working was a pain. I would not recommend a Linux developer to be picking up C# to do cross-platform development anytime soon. The only nice benefit I've seen is the amount of batteries included with .NET - but that's a solvable problem in other languages.
For me, even simple things like getting C# aliases working was a pain. I would not recommend a Linux developer to be picking up C# to do cross-platform development anytime soon. The only nice benefit I've seen is the amount of batteries included with .NET - but that's a solvable problem in other languages.
> tried it for 4 years and that's just not the case.
So just fired up a VM with a clean install of Ubuntu.
No VSCode, No Rider.
> wget https://packages.microsoft.com/config/ubuntu/20.10/packages-... -O packages-microsoft-prod.deb
> sudo dpkg -i packages-microsoft-prod.deb
> sudo apt update && sudo apt install apt-transport-https dotnet-sdk-5.0 -y
> mkdir test
> cd test
> dotnet new console --output sample1
> dotnet run --project sample1
This is all on the MS Docs website for getting started.
So I'm really not sure what part you find difficult. Getting hello world is no more difficult than me getting hello world working for golang, nodejs, python.
> For me, even simple things like getting C# aliases working was a pain.
Aliases for what?!?
EDIT: Simplified the commands cos I can't format in comments.
So just fired up a VM with a clean install of Ubuntu.
No VSCode, No Rider.
> wget https://packages.microsoft.com/config/ubuntu/20.10/packages-... -O packages-microsoft-prod.deb
> sudo dpkg -i packages-microsoft-prod.deb
> sudo apt update && sudo apt install apt-transport-https dotnet-sdk-5.0 -y
> mkdir test
> cd test
> dotnet new console --output sample1
> dotnet run --project sample1
This is all on the MS Docs website for getting started.
So I'm really not sure what part you find difficult. Getting hello world is no more difficult than me getting hello world working for golang, nodejs, python.
> For me, even simple things like getting C# aliases working was a pain.
Aliases for what?!?
EDIT: Simplified the commands cos I can't format in comments.
Yeah, of course, now try to build a real world application with it.
Aliases: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe.... Support for those was only added in the last year or so to the dotnet/nuget/roslyn/whatever it is needed things to make it work. Microsoft's own documentation only documents how to use it for Visual Studio: too bad if you're using another IDE or the command line like you did above.
Aliases: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe.... Support for those was only added in the last year or so to the dotnet/nuget/roslyn/whatever it is needed things to make it work. Microsoft's own documentation only documents how to use it for Visual Studio: too bad if you're using another IDE or the command line like you did above.
Using aliases have existed for like ever. So I guess you’re trying to use extern aliases which are super rare to ever need so still don’t know what you’re struggling with.
In terms of building a real world application. What are you struggling with? The code is no different regardless of IDE you use. VSCode, Visual Studio, and Rider all have a debugger and can step through code.
Right now it sounds like you’re just trying to make .net sound bad.
In terms of building a real world application. What are you struggling with? The code is no different regardless of IDE you use. VSCode, Visual Studio, and Rider all have a debugger and can step through code.
Right now it sounds like you’re just trying to make .net sound bad.
Okay, what other programming languages did you master before? What is so much easier?
I suppose you mean using-aliases for types/namespaces? This is a C# language concept, not a very complicated one, and totally independent of the operating system
I suppose you mean using-aliases for types/namespaces? This is a C# language concept, not a very complicated one, and totally independent of the operating system
It's not complicated, but the .NET tooling on Linux did not understand it :) that's what my point is all about. For the best .NET experience, use Visual Studio on Windows. If you're not on those two, the tooling experience is not going to be particularly pleasant - nor the documentation.
My advice after having tried it seriously - .NET does work crossplatform, I've seen it, but you need to be a Windows dev to tap into that. Would not recommend a mac/linux dev who's looking to do cross-platform work to pick .NET as the foundation.
My advice after having tried it seriously - .NET does work crossplatform, I've seen it, but you need to be a Windows dev to tap into that. Would not recommend a mac/linux dev who's looking to do cross-platform work to pick .NET as the foundation.
> a single streamlined product.
Problem is, the past will remain with us in every book, code example or stackoverflow answer. As a beginner you need to understand the difference between .net framework and .net core because any blog post or tutorial will reference one or the other. Now people start calling it .net 5 or .net 6 instead of core, but you have to understand that this is incompatible with ".net framework" or ".net 4".
Problem is, the past will remain with us in every book, code example or stackoverflow answer. As a beginner you need to understand the difference between .net framework and .net core because any blog post or tutorial will reference one or the other. Now people start calling it .net 5 or .net 6 instead of core, but you have to understand that this is incompatible with ".net framework" or ".net 4".
This is a problem for every language stack. .NET has been around for 20 years, there's no way to have the rest of the web constantly update everything. The official documentation helps by being very thorough and gets you pretty far without needing other research.
> because any blog post or tutorial will reference one or the other
Or neither, if it was written before Core (in which case it's Framework).
Or neither, if it was written before Core (in which case it's Framework).
I found the article fairly accurate, being a .NET developer now for upwards of 15 years, but perhaps the title is misleading.
I would have titled it, "Beginning .NET for Professionals."
Most of the concerns outlined in the article are really only relevant to professionals, or serious hobbyists. If you're truly a beginner most of those points are not concerns, at least until much later.
If you want to learn .NET, download Visual Studio Community Edition, fire up a console application, and tinker. Starting with C# is probably a good idea.
I did this with my sons, before there was a Community Edition, when they were about 11 and 8 - truly beginners. They had little problem getting going, writing small little programs to find primes or the lowest common denominator for a number. We didn't even cover OOP really, and the standard library only minimally.
So it can be done, even today after .NET has exploded. It's just hard for us pros who now have to confront that enormity.
I would have titled it, "Beginning .NET for Professionals."
Most of the concerns outlined in the article are really only relevant to professionals, or serious hobbyists. If you're truly a beginner most of those points are not concerns, at least until much later.
If you want to learn .NET, download Visual Studio Community Edition, fire up a console application, and tinker. Starting with C# is probably a good idea.
I did this with my sons, before there was a Community Edition, when they were about 11 and 8 - truly beginners. They had little problem getting going, writing small little programs to find primes or the lowest common denominator for a number. We didn't even cover OOP really, and the standard library only minimally.
So it can be done, even today after .NET has exploded. It's just hard for us pros who now have to confront that enormity.
Anecdotally when I've had to show developers how to start with .NET Core the problem isn't the SDK (install dot.net at the website) or which template to use (i.e. just tell them to pick that one) its C#. This is especially true if they come from a JS, Python or Go background. I say this as someone who does doesn't mind C# and thinks its pretty capable once the learning curve has passed.
At one stage I had a JS developer just try the F# template instead and the difference was stark. Explained to them Async F# - Promise JS, Module F# - Module JS, showed them a unit test example and they were writing production code in two weeks to a month. It made me realise that over the years there is a lot of knowledge I just take for granted that many beginners just don't have especially now when there are much friendlier languages for beginners. Things like dependency injection, how it resolves based on types, and which framework to use and why, mocking framework choice (vs simple stub functions), can only mock interfaces and why, the class structure and how you should group functions into appropriate classes, abstract classes vs interface default methods, LINQ vs OO style coding, nullability annotations all over the place, OO design patterns, the need for Resharper or equivalent unless you can write C# syntax from scratch, the list goes on and on. With most C# apps there is a lot of knowledge assumed and baked in which can be daunting for a newcomer. C# is not alone here I understand that - the same thing can be said for other languages too. But it has made it harder than it needs to be especially when it is actually a good platform but C# scares many developers away especially as it adds more and more features on top.
Litmus test for a language to me: Does it need an IDE and tooling to be productive in? The more tooling it needs the more complex IMO the underlying language is in syntax and complexity. Complicated refactoring tools? If so its probably too complex for a beginner especially now that the language space has quite a bit of competition. As an example watching a developer do this in a previous role in F# you just create a new file and cut and paste the functions around; in C# the dev's I've had usually resort to Resharper and a full blown IDE to extract variables/methods, do code generation, and basic refactorings unless they want a lot of manual work.
At one stage I had a JS developer just try the F# template instead and the difference was stark. Explained to them Async F# - Promise JS, Module F# - Module JS, showed them a unit test example and they were writing production code in two weeks to a month. It made me realise that over the years there is a lot of knowledge I just take for granted that many beginners just don't have especially now when there are much friendlier languages for beginners. Things like dependency injection, how it resolves based on types, and which framework to use and why, mocking framework choice (vs simple stub functions), can only mock interfaces and why, the class structure and how you should group functions into appropriate classes, abstract classes vs interface default methods, LINQ vs OO style coding, nullability annotations all over the place, OO design patterns, the need for Resharper or equivalent unless you can write C# syntax from scratch, the list goes on and on. With most C# apps there is a lot of knowledge assumed and baked in which can be daunting for a newcomer. C# is not alone here I understand that - the same thing can be said for other languages too. But it has made it harder than it needs to be especially when it is actually a good platform but C# scares many developers away especially as it adds more and more features on top.
Litmus test for a language to me: Does it need an IDE and tooling to be productive in? The more tooling it needs the more complex IMO the underlying language is in syntax and complexity. Complicated refactoring tools? If so its probably too complex for a beginner especially now that the language space has quite a bit of competition. As an example watching a developer do this in a previous role in F# you just create a new file and cut and paste the functions around; in C# the dev's I've had usually resort to Resharper and a full blown IDE to extract variables/methods, do code generation, and basic refactorings unless they want a lot of manual work.
I think your comparison is not fair. Maybe your vision of beginner C# is just much much higher than on F#?
Like, dependency injection, mocking and the like are not at all beginner concepts, and are not made particularly easier with more modern languages.
Like, dependency injection, mocking and the like are not at all beginner concepts, and are not made particularly easier with more modern languages.
I'm just stating the experience I had, and the observations I encountered in that job that formed that opinion. To clarify I'm talking about a beginner that needs to be productive quite quickly to earn their paycheck so their code has to somewhat scale to a medium sized solution and get accepted by a senior dev in a PR process. If they aren't beginner concepts as you state why are they in most "Getting Started" templates and their use is mandatory? As an example many of the common app types use a DI framework straight away following its own standard (e.g. ASP.NET, Spectre.Console, etc) and while an experienced person picks this up quickly someone new to the language from what I've seen struggles. These are concepts I had to explain to a beginner I had to mentor at the time pretty quickly.
Most F# code bases I've seen that make it to prod don't use frameworks for those concepts even as they scale; basic functional patterns seem to scale up to reasonable sized solutions. If they do use mocking/di/etc its only to make the code more C# consumable at the edge for some other C# framework they are required to use. I'm not talking about toy projects here. My point was more that at some point with C# you will need to learn these things quite quickly even for basic use cases or find yourself writing clunky boilerplate (which most new developers will default to - the you don't know what you don't know problem). However with some other languages you may never need to until much later in the learning cycle - I was working for a very successful large business that built the whole stack without ever using some of these things. If you want to encourage people onto your platform these are some of the people you need to win.
IMO It just seemed the standard to get nice code that was prod ready in F#, even JS or Go, doesn't require as much learning's as a C# app. It's not just a C# problem mind you but from what I've experienced first hand it has scared developers away.
Most F# code bases I've seen that make it to prod don't use frameworks for those concepts even as they scale; basic functional patterns seem to scale up to reasonable sized solutions. If they do use mocking/di/etc its only to make the code more C# consumable at the edge for some other C# framework they are required to use. I'm not talking about toy projects here. My point was more that at some point with C# you will need to learn these things quite quickly even for basic use cases or find yourself writing clunky boilerplate (which most new developers will default to - the you don't know what you don't know problem). However with some other languages you may never need to until much later in the learning cycle - I was working for a very successful large business that built the whole stack without ever using some of these things. If you want to encourage people onto your platform these are some of the people you need to win.
IMO It just seemed the standard to get nice code that was prod ready in F#, even JS or Go, doesn't require as much learning's as a C# app. It's not just a C# problem mind you but from what I've experienced first hand it has scared developers away.
But that’s a problem with a specific framework, not C#. It’s true that some frameworks are quite hard to avoid using, but you could just as well create a lean vanilla project (which I gather the F# one was closer to), and you can choose not to use DI. I doubt F# would be all that much more expressive than C#, that you could not recreate whatever you did there.
From what I've experienced code based frameworks are often used because the language itself doesn't handle that case well on its own. In the case of F#, JS, etc, using DI again as an example, partial completion/currying once you get your head around it means that quite often programs are just chained one line factories (similar to the one line you used to register your singleton/instance in a DI framework so no more code bloat). As a bonus you learn something that is multi applicable, not just for DI and doesn't bring in any more "magic" or runtime errors if a registration is missing because the compiler catches it. Everything is just functions/modules which means mocking is a breeze too, refactoring is easier, etc.
This is my own personal experience here mentoring dev's in both technologies, especially when they come from different backgrounds. YMMV.
This is my own personal experience here mentoring dev's in both technologies, especially when they come from different backgrounds. YMMV.
.NET carries a lot of baggage, but .NET Core is absolutely awesome. I would really encourage everyone to give it a try. I have personally used Blazor and its really good. Not to mention building WebAPIs with ASP.NET Core and EntityFrameworkCore.
Most of your dev needs will be met by .NET Core.
Most of your dev needs will be met by .NET Core.
It's not called .NET Core any longer. Another naming switcheroo that people have to get familiar with.
Oh wow did this title ever bury the lede, but what a great article. As a long time C# programmer very familiar with the .NET stack I definitely share and sympathize with many of the OP’s frustrations. I’ve been working in this world since .NET Framework 1.0 betas and I can’t keep track of all the developments. It’s exhausting.
Aside from hobby projects I’ve basically not given much thought to .NET Core because it’s such a moving target - and it’s a shame. In so many ways it’s far superior to the moribund .NET Framework - especially in terms of speed and memory use.
But there’s also many places in Core where there’s parity lacking with Framework, and migrating code can be a confusing and confounding experience. This is a place where things needed to be easy and they aren’t - and it doesn’t help that it’s so hard to figure out the difference between .NET Framework/Core/Standard/5 with UWP, WinRT, etc further confusing things.
Back in 2004 Joel Spolsky wrote the great article “How Microsoft Lost the API War” (https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...) and now some 17 years later it feels like little has changed. Some of the technology stacks may be different now but the frustrations are largely the same. It’s still the “MSDN Magazine camp” (or whatever today’s named equivalent would be) versus the “Raymond Chen camp”.
Aside from hobby projects I’ve basically not given much thought to .NET Core because it’s such a moving target - and it’s a shame. In so many ways it’s far superior to the moribund .NET Framework - especially in terms of speed and memory use.
But there’s also many places in Core where there’s parity lacking with Framework, and migrating code can be a confusing and confounding experience. This is a place where things needed to be easy and they aren’t - and it doesn’t help that it’s so hard to figure out the difference between .NET Framework/Core/Standard/5 with UWP, WinRT, etc further confusing things.
Back in 2004 Joel Spolsky wrote the great article “How Microsoft Lost the API War” (https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...) and now some 17 years later it feels like little has changed. Some of the technology stacks may be different now but the frustrations are largely the same. It’s still the “MSDN Magazine camp” (or whatever today’s named equivalent would be) versus the “Raymond Chen camp”.
Read the whole article nodding my head at all the valid criticisms of .NET, but towards the end I began to wonder: when are the arguments in favour of .NET coming? And finally, at the very end, this paragraph appeared:
" .NET is a great technology for experienced developers who grew up with the platform as it matured, but I'm not sure if I'd still enjoy learning it today as much as I did in 2008. Whilst the complexity allows me to charge great fees to clients for writing software in .NET, I'd probably not recommend it to a friend who wants to learn how to code or I wouldn't use it for building my own startup from the grounds up. "
Is it really the case that the only argument for using .NET is that you can earn a lot of money by working as a .NET consultant? From my own experience I always assumed that it was, but I would love to learn about some actual benefits that .NET has over competing platforms.
" .NET is a great technology for experienced developers who grew up with the platform as it matured, but I'm not sure if I'd still enjoy learning it today as much as I did in 2008. Whilst the complexity allows me to charge great fees to clients for writing software in .NET, I'd probably not recommend it to a friend who wants to learn how to code or I wouldn't use it for building my own startup from the grounds up. "
Is it really the case that the only argument for using .NET is that you can earn a lot of money by working as a .NET consultant? From my own experience I always assumed that it was, but I would love to learn about some actual benefits that .NET has over competing platforms.
I can share some insight here. I got into .NET (Core) by virtue of joining a company that used it, after previously focusing mostly on Python and JavaScript (with a self-taught background in C going back to childhood prior to that).
Initially I had the same tribalism that a lot of people seem to have towards .NET, for whatever reason. Eventually though, my conclusions:
- .NET Core is pretty reasonable. Platform agnostic, easy to work with, decent command-line tooling, and doesn't force you into an IDE vertical unless you want to. - C# can be a nice language for certain types of business applications. I think it has a lot of the good modeling properties that once made Java the de-facto language for enterprise development, without some of the verbosity and other drawbacks (though maybe Java has changed too since I last looked at it :) ). It plays very nicely with Domain Driven Design and event sourcing, both of which are patterns that I find valudable on large-scale systems for managing business transactions.
Overall TLDR: I probably wouldn't use .NET if I started a company tomorrow, but when I start coding non-trivially sized things in Python I sometimes miss elements of what .NET/C# brings (particularly interfaces, which obviously also exist in other languages).
Initially I had the same tribalism that a lot of people seem to have towards .NET, for whatever reason. Eventually though, my conclusions:
- .NET Core is pretty reasonable. Platform agnostic, easy to work with, decent command-line tooling, and doesn't force you into an IDE vertical unless you want to. - C# can be a nice language for certain types of business applications. I think it has a lot of the good modeling properties that once made Java the de-facto language for enterprise development, without some of the verbosity and other drawbacks (though maybe Java has changed too since I last looked at it :) ). It plays very nicely with Domain Driven Design and event sourcing, both of which are patterns that I find valudable on large-scale systems for managing business transactions.
Overall TLDR: I probably wouldn't use .NET if I started a company tomorrow, but when I start coding non-trivially sized things in Python I sometimes miss elements of what .NET/C# brings (particularly interfaces, which obviously also exist in other languages).
- Platform agnostic
- Decent command-line tooling
- Doesn't force you into an IDE vertical unless you want to
I'm not saying that the points above aren't true exactly, but surely they are less true for .NET than they are for just about any other mainstream development stack?
- Decent command-line tooling
- Doesn't force you into an IDE vertical unless you want to
I'm not saying that the points above aren't true exactly, but surely they are less true for .NET than they are for just about any other mainstream development stack?
Yeah, lol - I guess I mean that they were "considerably more true than I expected them to be, based on my previous prejudices about .NET"
Before I was forced to try it, if you had asked me whether having a "normal" development experience using .NET was possible I would have said "no way". After being forced to do it I was pleasantly surprised to see that it didn't feel particularly different to most other compiled languages that I've used. YMMV.
Before I was forced to try it, if you had asked me whether having a "normal" development experience using .NET was possible I would have said "no way". After being forced to do it I was pleasantly surprised to see that it didn't feel particularly different to most other compiled languages that I've used. YMMV.
Interesting- thanks for sharing!
There’s no doubt this a very truthful and in-depth review of .NET, but it leans a bit too negative for my beliefs.
I think if you just start with .NET Core and learn basic console programming, the rest will come easily enough.
I think if you just start with .NET Core and learn basic console programming, the rest will come easily enough.
Microsoft is just so bad at naming things. ".net framework" means versions of .net before version 5. Version 5 is of course also .net and it is a framework, but apparently it is not ".net framework", since this term refers to the versions up to 4.x.
Take "Enterprise Framework" (EF) and "EF Core". These are two independent ORM frameworks. From the names you would probably expect either that "EF Core" was the core of EF or that EF Core was a version of EF which ran on ".Net Core" (the previous name for .net 5). Neither is true - the frameworks are independent and both run on both .net 4.x and .net core/5. Apparently "core" just means "new incompatible version".
And how about ".net standard"? .Net Standard 2.0 was the standard API which was available with both .net 4.x and .net core/5. But from .net Standard 2.1, it was not compatible with .net framework anymore, which meant it wasn't standard anymore.
The actual technologies like C#, the BCL and EF Core are great, don't get me wrong, but the naming is so confusing.
Take "Enterprise Framework" (EF) and "EF Core". These are two independent ORM frameworks. From the names you would probably expect either that "EF Core" was the core of EF or that EF Core was a version of EF which ran on ".Net Core" (the previous name for .net 5). Neither is true - the frameworks are independent and both run on both .net 4.x and .net core/5. Apparently "core" just means "new incompatible version".
And how about ".net standard"? .Net Standard 2.0 was the standard API which was available with both .net 4.x and .net core/5. But from .net Standard 2.1, it was not compatible with .net framework anymore, which meant it wasn't standard anymore.
The actual technologies like C#, the BCL and EF Core are great, don't get me wrong, but the naming is so confusing.
The EF Core thing might make a little more sense with some context. It originally started out only compatible with .NET Core (which was the successor to .NET Framework)
Eventually Microsoft came to the conclusion that doing .NET Framework to .NET Core migration in tandem with an EF6 to EF Core migration would be a huge undertaking for legacy projects. So as of EF Core 2.1 they added support for .NET Framework 4.7.2+ so people could migrate that first, then move to .NET Core. Therefore you end up with the weirdness that it was .NET Core only, then eventually it wasn’t, despite being called EF Core.
As for Standard.. can’t help but agree, it was a bit of a mess unless you really understood what it meant for API compatibility. But with .NET 5.0, Standard is pretty much gone for new code. See https://devblogs.microsoft.com/dotnet/the-future-of-net-stan.... So I think Microsoft is slowly learning and fixing up some mistakes made in the “Core” era
Eventually Microsoft came to the conclusion that doing .NET Framework to .NET Core migration in tandem with an EF6 to EF Core migration would be a huge undertaking for legacy projects. So as of EF Core 2.1 they added support for .NET Framework 4.7.2+ so people could migrate that first, then move to .NET Core. Therefore you end up with the weirdness that it was .NET Core only, then eventually it wasn’t, despite being called EF Core.
As for Standard.. can’t help but agree, it was a bit of a mess unless you really understood what it meant for API compatibility. But with .NET 5.0, Standard is pretty much gone for new code. See https://devblogs.microsoft.com/dotnet/the-future-of-net-stan.... So I think Microsoft is slowly learning and fixing up some mistakes made in the “Core” era
I guess the whole .net core mess made sense in the beginning, it just got out of hand.
As I understand it, core was conceived as an experimental alternative runtime which made it possible to run asp.net on non-windows platforms. It was not initially planned to be the replacement for full .net framework, so it didn't need to be fully backwards-compatible with the regular framework, which saved them some effort in the beginning. When the strategy changed to make core the next version of .net, the incompatibilites was so entrenched it was too late to solve, so we ended up with this enormous mess.
As I understand it, core was conceived as an experimental alternative runtime which made it possible to run asp.net on non-windows platforms. It was not initially planned to be the replacement for full .net framework, so it didn't need to be fully backwards-compatible with the regular framework, which saved them some effort in the beginning. When the strategy changed to make core the next version of .net, the incompatibilites was so entrenched it was too late to solve, so we ended up with this enormous mess.
I'm getting into F# and I couldn't agree more.
I'm still a little lost on how asp.net runs in a Linux container.
I'm still a little lost on how asp.net runs in a Linux container.
Definitely a frustration for those of us having done .Net for 20 years. Even the naming frustrates me. Every time they seem to create a new "one name to rule them all", it only lasts a short while until a new one comes along net framework, .net core, .net standard .net 5 and apparently now .net 6.
As the OP said, the overarching problem is probably trying to be all things to all people and pretending that all of those things are .Net. It also produces a sadly common attitude now of "we won't fix that in dotnet core 3, upgrade to .net 5" as-if that is even a possibility for many existing apps.
One idea that comes from way back in the day was having an IDE that you could set to beginner, intermediate and advanced so that when you start out, you only see a subset of things. You can then get more confident in the basics before seeing more options and windows.
Another idea I liked was removing older features so that you don't keep getting bigger and bigger.
As the OP said, the overarching problem is probably trying to be all things to all people and pretending that all of those things are .Net. It also produces a sadly common attitude now of "we won't fix that in dotnet core 3, upgrade to .net 5" as-if that is even a possibility for many existing apps.
One idea that comes from way back in the day was having an IDE that you could set to beginner, intermediate and advanced so that when you start out, you only see a subset of things. You can then get more confident in the basics before seeing more options and windows.
Another idea I liked was removing older features so that you don't keep getting bigger and bigger.
Yes. Naming is the worst. Oh, I have dotnet how do I make a webpage. Nah, you need also asp dot net. Or asp core .net, but this wont run on .net anymore but only on core .net..... headache...
Microsoft seem to have trouble naming things.
Xbox One X, Xbox One S, Xbox series X, Xbox series S.
And also: Is Outlook the same as Office365? Is Outlook the new Live? Did Hotmail turn into Live? Am I the only confused by all of this?
Xbox One X, Xbox One S, Xbox series X, Xbox series S.
And also: Is Outlook the same as Office365? Is Outlook the new Live? Did Hotmail turn into Live? Am I the only confused by all of this?
I can not agree more with this post.
After being a C# developer for 5 years, I can not think of a worst language to learn that C#.
The ecosystem is dead just check the latest startups from YC, how many are using C#? How many startups nowadays are using C#?
Currently there are better options than C# or .NET. You want simplicity, you have Go. You can create an API server so simple and easy to understand. You want a full framework, you have Rails. Rails give you everything so easy to be productive and start shipping. Just run gem install device and you have authentification. You need to storage files, images, etc., just a simple tag on your model and really to go.
Currently there are better options than C# or .NET. You want simplicity, you have Go. You can create an API server so simple and easy to understand. You want a full framework, you have Rails. Rails give you everything so easy to be productive and start shipping. Just run gem install device and you have authentification. You need to storage files, images, etc., just a simple tag on your model and really to go.
> After being a C# developer for 5 years, I can not think of a worse language to learn that C#. The ecosystem is dead just check the latest startups from YC, how many are using C#? How many startups nowadays are using C#?
You're late to the party, and your comment is a bit funny. C# was <<never>> a startup language :-) It was always an enterprise language, meant to fight Java.
If anything, C# is moving towards startups with the introduction of .NET Core and of the cross platform IDEs (VS for MacOS, VS Code + plugins, Rider).
You're late to the party, and your comment is a bit funny. C# was <<never>> a startup language :-) It was always an enterprise language, meant to fight Java.
If anything, C# is moving towards startups with the introduction of .NET Core and of the cross platform IDEs (VS for MacOS, VS Code + plugins, Rider).
How is Go easy? It is a much less expressive language than Java or C# and is more verbose. It’s C with GC and good concurrency.
I never understood the hype around it.
I never understood the hype around it.
Complicated stuff will always be complicated.
The .NET ecosystem is huge, there are a lot of different frameworks associated to any kind of problem. Xamarin for mobile; EF 6, EF Core, ADO.NET for databases, and so on.
But as a beginner you shouldn't try to understand it all, right from the beginning. Just start somewehre.
It's like saying: "Biking is too complicated, there are so many different kind of bikes, who should know what to buy!" Just get the first best bike / framework (e.g. console app, or asp.net core) somebody recommends you and go with that until you know better. After a while you will understand the difference between a mountain bike and a downhill bike, or between EF 6 and EF Core.
The .NET ecosystem is huge, there are a lot of different frameworks associated to any kind of problem. Xamarin for mobile; EF 6, EF Core, ADO.NET for databases, and so on.
But as a beginner you shouldn't try to understand it all, right from the beginning. Just start somewehre.
It's like saying: "Biking is too complicated, there are so many different kind of bikes, who should know what to buy!" Just get the first best bike / framework (e.g. console app, or asp.net core) somebody recommends you and go with that until you know better. After a while you will understand the difference between a mountain bike and a downhill bike, or between EF 6 and EF Core.
I recently tried to take a look at dotnet core since I heard it can compile and run on linux. Every tutorial I looked at for building a webapp started with "download visual studio and click these buttons..." which would result in a "mostly complete" program that it would go on to fill in some variables to. Literally every other language tutorial starts with a simple empty file and fills in functions with descriptions of what's going on and builds up understanding. When I want to learn how to make a webapp in .NET, I want to learn to make a webapp in .NET/C#, not how to install and click buttons in Visual Studio.
Check out https://dotnet.microsoft.com/learn/aspnet/hello-world-tutori... which is a hello world without VS.
Then: "Just think about the upcoming release of .NET 5 and how it will invalidate most of the lessons taught just a few months ago .... the wider .NET community has failed in making .NET a more beginner friendly language"
.NET isn't a language! It is, I will agree, absurd that Microsoft way back when decided to give the totality of the infrastructure around their language a name at all, let alone one as confusing as .NET, but that is all it is. A name applied to sometimes the compiler/runtime/core libraries or all of the above.
Unfortunately this has led to people wandering into forums asking "how can I learn C# and .NET?" nobody ever wanders into a forum asking "How can I learn C++ and llvm"?