Live data from Hacker News

The Case for C# and .NET

chrlschn.medium.com

321–330 of 376 posts

Re: The Case for C# and .NET

#321
post #24

Earlier quoted context omitted.

Can confirm, we’re developing in Blazor now and it’s fine. Not as loosey goosey as js, but makes as much sense as any other js framework. And having such tight integration with Entity Framework makes development a breeze.

Blazor server or wasm?

Server. From an ergonomic standpoint, the development is basically identical to WASM ASFAICT. This is all internal though, so ymmv if you're developing stuff for the open Internet. I guess it depends heavily on how married your org is or isn't to c#, which we very much are. I vastly prefer this to serving up a separate UI for what we do.

Re: The Case for C# and .NET

#322

Earlier quoted context omitted.

the biggest python codebase I'm personally aware of is JP Morgan's Athena and is about ~30 million LOC. Google, Youtube and Dropbox use Python extensively etc. Python being a scripting language stopped being a correct statement probably over a decade ago.

Keep telling yourself that and it will become true.

You said about yourself:

> just my own observations (probably wrong).

I am currently in the process of learning C#. I did a deep but brief dive into every language feature in C# 10. Being proficient in Python, absolutely nothing surprised me. All the same concepts, save for a handful, exist in either language, sometimes down to the exact keyword usage. LINQ is a big differentiator in favor of C#, but modern (that is, typed) Python looks very similar to C# (C# left, Python right):

ABCs -- ABCs

Interfaces -- Protocols/ABCs

LINQ -- ??

Enumerable/Enumerator -- Iterable/Iterator

class -- class

static -- staticmethod

foreach -- for

for -- for(range(...))

try/catch -- try/except

break/continue -- break/continue

enum -- Enum

struct -- dataclass, perhaps

namespace -- automatic on the file level

out -- pass by reference

switch/case -- match/case (both do structural pattern matching)

throw -- except

typeof -- type

overloaded methods -- singledispatch (only works for a single argument sadly, no stdlib multidispatch)

inheritance (single) -- inheritance (multiple)

object -- object (root of the type hierarchy)

generics -- generics as well (via typing, runtime never cared anyway of course)

lambda -- lambda

nullability -- None (C# can have nullable reference types, Python types are not nullable, None exists as a first-class type, not a subtype of all other types; similar ergonomics but different structurally)

extension methods -- just go wild in Python (although binding methods after class definition is cumbersome)

tuples -- tuples (both can do unpacking, multiple returns etc.)

operator overloading -- operator overloading

reflection -- reflection (arguably a Python strong-point)

async/await -- async/await

decorators (exist as a pattern) -- decorators (supported on the syntax level)

?? -- top-level/first-class-citizens functions

I probably got a couple wrong, but you get the idea: apart from LINQ, nullability handling and some others, the languages are incredibly similar in their feature set on paper. This is not talking about DX etc. though.

Re: The Case for C# and .NET

#323

Earlier quoted context omitted.

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…

> was able to deliver the projects for 33% what it would have cost to deliver them with react or angular. That’s a pretty extraordinary claim. I know single stack can be more productive, but that sounds very impressive. Could you perhaps talk details of: - styling blazor (eg. Bootstrap, tailwind); is it just drop in? How do you use it, eg. Without the tailwind preprocessor npm package? - interactive front end compone…

Sorry I misspoke I meant a 33% reduction in the size of the projects. So projects that would have taken 6 weeks in React took 4 Blazor server side.

1. We just dropped in a wrapbootstrap template.

2. We wrote some javascript for interactive front end components like drag and drop or rich text editors. It was a little more work than it would have been in React but not much and everything else more than made up for it.

3. We found it wasn't particularly difficult. We'd just put JSRuntime.InvokeAsync in a C# method. Used it for things like popups and initializing some js libraries.

4. We're only using Azure App Service and Azure SQL database. Our long running functions we just run as a scheduled service on the app service. (though eventually we'll to do some refactoring when we need to scale horizontally). We're a B2B SaaS company so our revenue is quite high compared to our compute usage. By our back of the envelope calculations we won't have to add another server until we're somewhere between 5 and 15 million ARR. We think we'll need to do about 2-3 months of refactoring at that point to allow for horizontal scaling.

I wouldn't recommend Blazor-Server Side for B2C typical applications that have a low ARPU.

The big advantage in development speed is we got the functionality of a SPA but at the development cost of a classic multi-page application.

Re: The Case for C# and .NET

#324
post #319

Earlier quoted context omitted.

Yes, VS is free for individual devs, and for five users in a small business. Does it matter though? If you're too cheap to pay for developer tools, you're probably a terrible place to work at.

Why is it assumed that you're only ever professionally working on code? Do none of you work on side projects, or open source projects?

Did you read what you replied to?

It's free for individual developers, small businesses, and work on open source projects (no matter the size of the organisation).

https://visualstudio.microsoft.com/vs/pricing/

Re: The Case for C# and .NET

#325

The article mentions it, but I'll reiterate: the .NET CLR is fantastic. C# is a great language for the backend: GC'd, lots of libraries, fast runtime, and expressive enough. Do I wish it was more functional? Absolutely. But it doesn't aspire to be that. The ecosystem deserves mention. There are some high-quality libraries that work well, even if they aren't the most popular. Take objectional relational mappers, for i…

> Do I wish it was more functional? Absolutely. But it doesn't aspire to be that.

I somewhat disagree about the aspirations. Have you tried out things like switch expressions and LINQ? You can apply functional concepts almost everywhere these days. Complex state machines can be modeled using 100% functional techniques.

Re: The Case for C# and .NET

#326

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…

Was that comparison both with or without ReSharper? Were you comparing fresh installs with no plugins on both sides?

Re: The Case for C# and .NET

#327
post #51

Earlier quoted context omitted.

Sorry, but OmniSharp sucks, and this is not a controversial opinion even among Microsoft employees. I am all for the .NET experience in VS Code improving greatly from where it is with OmniSharp. This will actually help increase adoption of .NET, which, I remind you, is open source.

> Sorry, but OmniSharp sucks I agree. This appears more like an attempt to get the most value (integration of proprietary Visual Studio features that devs want) into the VSCode extension as quickly as possible. Said proprietary libraries are likely not able to be easily open sourced for a variety of possible reasons, so a closed source LSP bridge was the compromise the teams came to.

The directly related fight here is Microsoft's pylance on the Python side. pyright still exists and many of the components in pylance are still open source, but pylance itself is closed source and bundles closed source tools. (That is pylance is not just a pyright fork, but closed source LSP bridge for pyright + proprietary parts.)

It's not without controversy on the Python side as well.

At some point it simply becomes questions of stewardship and transparency: How good are they at pointing out the open source parts wrapped inside the closed source LSP bridge? What cadence do they upstream fixes to the open source parts?

So far Microsoft's stewardship on the Python side seems strong: pylance has a lot of transparent documentation of all the open source bits. There seems to be a steady upstream flow to pyright for users that prefer to stay entirely with an open source LSP. Microsoft isn't treating it like a competition to "win" and encourages users to make their own choice among the options.

Of course, Microsoft doesn't "own" Python in the same way it "owns" .NET so I can definitely understand why there's increased fear that Microsoft won't be as good of a steward with respect to this "competition" with OmniSharp simply because of .NET's past. But in .NET's past this controversy would be happening after Microsoft did all the work in building the closed source LSP replacement. The fact that we're having this discussion now in only an "architectural discussion" state says a lot already about how Microsoft's stewardship and transparency have changed today.

Re: The Case for C# and .NET

#328

Earlier quoted context omitted.

Until Microsoft can match the dev experience of writing front and backend in typescript with pnpm, I’m not touching the dotnet/nuget cli(s) with a 10-ft poll. If you want to write C# just write go

> If you want to write C# just write go I don't get this. If you want to write C#, write C#. If you want to write Go, just write Go. Go is a great language because of its simplicity and ecosystem, has lots of useful things in the standard library, has pretty good runtime performance and also compiles to static executables easily (which is especially useful for projects like Nomad). It's both a good fit for web develo…

> I don’t get this

That’s because my argument has nothing to do with the language itself but you still felt compelled to write an essay. I’m saying the modern Linux-based tooling, ecosystem, and devex of C# is inferior to so many other choices.

Re: The Case for C# and .NET

#329

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?

There's no issues with Windows specifics in /ASP\.NET( Core)?/ version >= 5.0.

There's some issues if you need to use an older version of ASP.NET and whether or not it has "Core" in the name, but after .NET 5 and ASP.NET 6 there's no longer that fork to confuse things and it's back to much simpler version numbers/checks and no longer needing to worry about the word "Core".

Re: The Case for C# and .NET

#330

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 tried writing a simple crud api with asp.net, which should parse and respond json. It was the worst development experience I ever had while writing json apis. Validation? Not existent. OpenAPI/swagger documentation generation? Not existent. Then it also tried to force me into using MVC, while acting that it is express with its middlewares. I switched back to node.js with fastify and wrote my app in an hour. I reall…

> I switched back to node.js with fastify and wrote my app in an hour.

Of course you did. You're on familiar ground.

Personally I'm also familiar with .Net and could do the same in that stack in that timeframe too. Like with many things worth doing, it requires a time investment to reach that point.

Having said that, .Net APIs support JSON request/response out of the box, validation is available on the models in seconds using a powerful set of attribute annotations, and Swagger is also built in out of the box. And API projects can seem similar to MVC ones as they use the same framework and libraries, but whilst the out of the box APIs have controllers they don't have views.

So to repeat, it's down to familiarity.

Edit: For clarity this is not a criticism. I fully understand why these things may not be obvious up front. Both the validation attributes and the Swagger URL for the default support are not obvious to the newcomer.

Post reply on HN