The Case for C# and .NET • Hacker News Board

Re: The Case for C# and .NET

#341

Post by maldev » Mon, Jul 25, 2022, 10:39 PM UTC

JamesBarney wrote: post #147

moonchrome wrote: post #108

Earlier quoted context omitted.

Have you actually tried Blazor ? Just the schism between WASM and Server and the feature matrix there, and generally shit quality of early stage Microsoft product - I wouldn't touch it with a 10 foot pole, likewise for MAUI - I've seen coworkers prototype both for some greenfield projects in last month or two and both projects gave up on it because it just isn't there yet for mainstream development. I mean .NET core…

I've tried Blazor. I built and deployed 3 apps for clients over the last 3 years while consulting and was able to deliver the projects for 33% what it would have cost to deliver them with react or angular. Clients have been very happy with the results. Then I built my own startup with it, and we have a solution that 3 devs have been working on for 2 years. I can't recommend Blazor enough. I love it. I have run into a…

Definitely agree with you. Blazor is absolutely amazing and makes development extremely fast. Makes me wonder if people commenting have even tried it.

Re: The Case for C# and .NET

#342

Post by Salgat » Mon, Jul 25, 2022, 11:37 PM UTC

tbrownaw wrote: post #27

Salgat wrote: post #10

Earlier quoted context omitted.

Not with their core languages. For example, Windows still comes bundled with the old VB6 runtimes and Microsoft still supports the language even if they no longer add features to it. I'm not really sure of any major Microsoft languages that Microsoft has just dumped, unless you count their smaller more esoteric ones. Also keep in mind that .NET Core is not only open source, but comes with complete protection from any…

> still supports the language even if they no longer add features to it This is what I assumed the parent post was referring to. Mostly because it mirrors complaints I've heard (and maybe had) about the .net gui story. WinForms -> WPF -> whatever the windows store app framework was called -> I think MAUI now?

That's hardly a fault with Microsoft though. WinForms is fundamentally flawed and far better alternatives now exist, it'd be foolish to continue investing in WinForms. You can still use WinForms and .NET Framework on Windows 11, just don't expect new features, which is okay.

Re: The Case for C# and .NET

#343

Post by nonbirithm » Tue, Jul 26, 2022, 12:47 AM UTC

ivraatiems wrote: post #99

sandreas wrote: post #18

I also think that C# and .NET are awesome. Especially latest releases dotnet 6 and upcoming 7 have a ton of new things to be even more productive. I like the fact, that you can develop command line apps, Web APIs, Desktop Apps and smartphone apps all with the same toolset, including the fact that deployment is possible on nearly every major platform for every major platform (except iOS and macOS Apps, as always only…

I've been a .NET developer professionally for seven and a half years. Rider is the way to go. Visual Studio has improved dramatically over the last decade or so, but Rider is still way ahead of it on code search/discovery, performance, and general user experience. I did a tech talk at my company where I demoed Rider vs Visual Studio 2019 performance on our bigger projects... it was embarrassing for VS. VS 2022 was su…

I'd love to use Rider on Linux or even Windows. Sadly the lack of .NET hot reload on Linux and Rider's issues with hot reload on Windows are what keep me on Visual Studio. (Rider's implementation of hot reload doesn't support assemblies loaded at runtime yet, which my application depends on).

It's sad that the time saved with Visual Studio's hot reload alone seems to outweigh the (massive) performance gains from using Rider, given that I have to restart VS from its memory leaks multiple times a day or it will slow to a crawl. Omnisharp isn't performant or reliable enough for daily use, either. The current state of .NET tooling leaves me unsatisfied.

Re: The Case for C# and .NET

#344

Post by TheRealDunkirk » Tue, Jul 26, 2022, 2:19 AM UTC

kcartlidge wrote: post #332

TheRealDunkirk wrote: post #231

Earlier quoted context omitted.

If you like the productivity, just wait till you try Rails.

> If you like the productivity, just wait till you try Rails. I like Rails (vintage, Rails 5). Unfortunately DotNet and EF combined now have virtually the same productivity but with massively better performance. Which is a shame as Ruby is a great language.

I’ve tried very hard to use EF. If you think it’s equivalent to the productivity of ActiveRecord, well… more power to you, I guess.

Re: The Case for C# and .NET

#345

Post by GiorgioG » Tue, Jul 26, 2022, 2:30 AM UTC

nonbirithm wrote: post #343

ivraatiems wrote: post #99

Earlier quoted context omitted.

I've been a .NET developer professionally for seven and a half years. Rider is the way to go. Visual Studio has improved dramatically over the last decade or so, but Rider is still way ahead of it on code search/discovery, performance, and general user experience. I did a tech talk at my company where I demoed Rider vs Visual Studio 2019 performance on our bigger projects... it was embarrassing for VS. VS 2022 was su…

I'd love to use Rider on Linux or even Windows. Sadly the lack of .NET hot reload on Linux and Rider's issues with hot reload on Windows are what keep me on Visual Studio. (Rider's implementation of hot reload doesn't support assemblies loaded at runtime yet, which my application depends on). It's sad that the time saved with Visual Studio's hot reload alone seems to outweigh the (massive) performance gains from usin…

I’m amazed hot reload works consistently enough for you to be able to use it.

Re: The Case for C# and .NET

#346

Post by jbluepolarbear » Tue, Jul 26, 2022, 2:46 AM UTC

bayindirh wrote: post #166

CyanLite4 wrote: post #88

This thread shows there is still a large amount of FUD around .NET and it’s community. Folks here still think it’s Windows-only and comparable to Java. Yet latest TechEmpower benchmarks shows .net running on Linux and being faster than Go, Python, Node, and Rust.

.NET core can run on any platform it wants, but as long as it's from Microsoft, the company as we know it, I won't even write "Hello, World!" with it. A language can't be the fastest at everything in today's mature language ecosystem. OTOH, Debian's "Programming Language Games" benchmarks shows it's on par with Java (which is not slow in any means), and not as fast as you claim [0]. In the page I shared, some C# benc…

I only looked at the binary example and it’s some of the worst C# code I’ve ever seen. It’s synchronizing every task in a loop instead of waiting for the tasks to complete like the Java example. It’s returning a result instead of using an array like the Java example. The 2 examples are not equivalent.

Re: The Case for C# and .NET

#347

Post by Rapzid » Tue, Jul 26, 2022, 4:43 AM UTC

labrador wrote: post #5

> For the front-end, JavaScript is unavoidable (for now) Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment. I've learned I can add events and event handlers to elements without ever leaving C#. Then…

Blazor WASM is promising but it really lacks some like MobX. There is a Weave based project that's sim to MobX, but hasn't gotten a ton of traction.

Then there is a Redux-like option and.. No thanks :D

Re: The Case for C# and .NET

#348

Post by noisy_boy » Tue, Jul 26, 2022, 5:10 AM UTC

kcartlidge wrote: post #333

noisy_boy wrote: post #31

My understanding is that with .NET Core, the experience of developing and running on Linux is on-par with Windows(?). However, my impression is that once it comes to building web services, ASP.NET has more "windows-specific" assumptions/moving parts - can someone knowledgeable on this correct me if I'm wrong?

- Ignore all the DotNet version names and numbers unless you're working on legacy stuff. - If you're starting from scratch all you need to know is that you should use DotNet 6+ and you'll be on the mainstream track with full cross-platform support. - Nothing is Windows-specific unless you're actually wanting to target Windows stuff specifically. - If you're doing desktop dev MAUI is the way forward, but personally I…

Thanks - I was actually more confused by the comments as I'm a total beginner to .NET (just interested to learn). This sounds like a more simple/distilled advice in my context.

Re: The Case for C# and .NET

#349

Post by pjmlp » Tue, Jul 26, 2022, 5:30 AM UTC

throw868788 wrote: post #340

pjmlp wrote: post #307

Earlier quoted context omitted.

You mean the traditional World Data Bank example that we got to see at each F# conference with little relevance for .NET shops? What I care about are the code generation libraries that get served alongside NuGet packages with attributes, e.g. the ones used by MVVM, MAUI or Blazor.

Just use a mixed solution then i.e. why not both? You're picking one thing that F# isn't great at - generated code tooling which IMO isn't in the spirit of many modern languages anyway. I don't get why some C# devs tend to be antagonistic to F#. Not suited to what you use? That's fine but that doesn't mean it isn't good for others. I've seen dev's coming from other languages to F# and thinking its brilliant that woul…

Mixing languages increases the code complexity and hiring requirements for anyone that has to touch the code.

Everyone on the project has to learn two languages, two ecosystems, because naturally F# folks either reinvent or create idiomatic wrappers for what .NET already offers, a typical side effect in guest languages.

And then there are the enterprise support teams that explicitly only give support if the issues are reproducible with C# when giving example on tickets, increasing the costs to submit support tickets.

Re: The Case for C# and .NET

#350

Post by bayesian_horse » Tue, Jul 26, 2022, 5:39 AM UTC

osigurdson wrote: post #317

toyg wrote: post #302

Earlier quoted context omitted.

They definitely see Go as direct competition, or did at various points. Some of the work that was done in Python 15 years ago is now done in Go, mostly because of its superior support for highly-parallel workloads; so Python developers have reacted and improved the parallelization story in various ways (yes, it's still not as good as it could be, but it's undoubtedly better than it was when Go took a significant bite…

I don’t see Python having a lot to offer in terms of technical merit really. Python’s strength is language ergonomics and fun factor. I hope they keep it that way.

Python often seems to be the status quo that "technical merit" has to beat. Python only slowly beats itself but then becomes the status quo again.