Hacker News Reader

Comment by manigandham | Hacker News Reader

.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

View on HN

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.

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.

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.

> 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.

> 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.

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.

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.

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.

> 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.

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.

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.

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.

> MAUI is the "new hotness"

Wait, I thought that Blazor Desktop was the "new hotness" this week?

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 :)

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

What?! This wasn’t even on the list!

Here we go again...

This is why people just stick with winforms.

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...

>WPF is the latest Windows-only

No it isn't. WinRT, UWP and WinUI are all later than WPF.

This is probably more of a Windows problem than a .NET/C# problem, but it's a very real problem.

> 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.

> 0.9X developer

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.

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.

Getting the job done is an important aspect of a toolchain.

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.

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 :)

> 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".

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).

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.

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.

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#.

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?

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.

>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.

    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).

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

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.

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.

  # 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

Or did you have issues with the IDE?

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.

> 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.

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.

> 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.

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.

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.

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.

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

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.

> 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.

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.

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.

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.

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.

Reply on news.ycombinator.com