Hacker News Reader

Comment by lucidone | Hacker News Reader

I used .NET Core for a backend API relatively recently (3.1) with no background in .NET prior (mostly javascript/typescript, php, and ruby). I found it incredibly productive and to be an enjoyable developer experience. Entity framework is one of the best ORMs I've ever worked with. Solutions and projects took some getting used to but I like it in retrospect. I now use IntelliJ products as a consequence of having used Rider for that project (developing on a mac) and enjoying the experience. C# as a language is now one of my favourites. I find it hard to convince colleagues and peers to give it a chance (mostly ruby and javascript devs) which is a shame.

View on HN

Extremely similar background here, similar feelings after working with .NET / modern C#. I even, semi- subconsciously perhaps, wanted to dislike it -- because I thought it was MS-ish, and ASP-ish. But really, it's a first class citizen and especially so the last few years as it's become very fast & received a ton of cross-platform support.

Once over the [quite low IMO] initial 'hurdle', it's easily amongst the most productive & best-supported "platforms" I've ever worked within.

> "incredibly productive"

That's the best summary of the .NET stack, unfortunately it requires first-hand experience to figure it out.

Same goes for Elixir and Scala, it's mostly because from an outside-in view it really hasn't changed much (when 'looking' at the language and framework in question). Technical changes are relatively easy, cultural changes.. not so much.

It depends what your trying to do and anything worth using has some learning curve. Hardly something I would say is a downside of .net

In rails I can drop into console and play with APIs in repl. What’s the .net equivalent?

.NET languages have REPLs too.

Oh, so you can do things like User.where(name: “Bill”).pluck &:id

In the repl?

I have no experience with .net and it looks like these repls are new

I think at least some of the REPLs came about with the new compiler architecture, yes. That isn't exactly new anymore, but new compared to the overall age of .NET.

It’s intriguing, thanks

Some time ago I had the misfortune to direct a C#/ASP.net web project, and that project turned out to be the first web project where the backend was singnificantly later than the frontend. Even though the backend had 2 senior developers and the frontend only 1 junior developer doing React.

Since then I am not able to take seriously the saying of .net to be "incredibly productive".

This comment could benefit from development. For example: how do you know .NET was the cause? Anecadata can be useful in aggregate, but not with such sparse details.

What do you mean by direct? Were you doing the coding? And the backend was larger in what way? And is that a problem? And was the frontend a SPA? Was asp.net just used to make a JSON API?

What were the actual issues and what would've made it more productive? That's much more useful for discussion here.

I initially directed (as organise stories, unblock people, do some devops & code review), but eventually I had to jump into the backend, because, as the most senior developer, I'm expected to jump into whatever part is having trouble.

The backend had to receive events from a webhook and accumulate statistics on those events, then serve these statistics via REST API

Frontend was plain old React reaching the REST API.

Issues:

* The database (MS SQL Server, as recommended by Microsoft) would randomly lock up for days. Bear in mind this was a 1GB of RAM (the minimum amount that Microsoft accepts as enough to run a SQL Server instance) RDS serving around 600 MB of data.

* The introduction of the Repository Pattern (as recommended by the ASP.net documentation) introduced a lot of complexity (including incompleted/non-defined operations) that slowed down significantly the development.

* LINQ supports interleaving DB operations with not-db operations, quickly becoming a O(n^m) footguns. If you make `row => row.x > 5` a method, LINQ will happily download all the rows and run the comparison in program instead of in the DB. Bear in mind I can't construct these footguns with django ORM, or make them typecheck with any Haskell data access framework.

* The test runner UI would pretend no tests existed if the code didn't compile for any reason. Trying to debug something by running a specific failing test? If you miss a semicolon now you have to go find your test again.

* The logger would log the message and the affected class in different lines. Do you want to grep for an error? You better know the obscure grep syntax for "previous line". Want to change the logging format? Good luck finding the code that adds the newline in order to find how to influence it. If you ask the IDE to find the implementation of the logging function it will show you the interface, nothing more.

* You better not do some type of async stuff in LINQ, because the system is going to spawn a process for each entry, obliterating your production instance by creating thousands of processes, using a bunch of MB for each process.

There were more issues, I didn't make an exhaustive list of them because, you know, I don't need to make exhaustive lists of malfunctions and bad design ideas for other programming languages.

Based on this anecdote, it sounds like the team had little or no .net experience and your seniors probably don't deserve the title.

Curiously, I haven't had these problems in Python/cherrypy/django/flask, Haskell/snap/yesod, NodeJS/express/nextjs, so, maybe it's something beyond lack of .net experience.

Your experience mirrors mine, both early (circa 2005) and more recently.

Footguns are common.

I am not sure where the .NET community coalesces (python and similar tend to hit up IRC).

The ability to find and get answers on stack overflow is pretty impressive, although that might not be the “community” your looking for. I’ve had decent direct engagements with them framework dev tends on GitHub before as well.

To add on to community -- it's more than that as well, it's the zeitgeist. In the scientific computing world, if something has hit NumFocus' portfolio then it's active, maintained, accessible, and (IMO) can consider adding into a tech stack. Similar for Apache for general FLOSS projects.

I don't understand the dotnet's extension ecosystem -- how to find quality sourcing, etc. Going from an established project into dotnet SDK makes sense. But searching GitHub for useful dotnet frameworks -- stars are probably misleading here?

There's been lots of bad decisions along the way for .net, but In its current state (.net Core 6) I can't really see any of your problems happening. Although what strikes me most is your first point. Running SQL server on 1gb and complaining that it didn't work well isn't really wise. Maybe this happened on the early years of .net Core or even on FF?

I'm following what says at the official Microsoft documentation.

https://docs.microsoft.com/en-us/sql/sql-server/install/hard...

Am I unwise for following the official Microsoft documentation for a Microsoft product?

Yes, I'm unwise for following it. I shouldn't have accepted the project because it required Microsoft technology. That would be wise.

The documentation you linked to clearly states that they recommend 4GB of memory and more for larger databases. While it CAN run on 1GB of memory, it is also therefore NOT recommended. You chose to go the route of the unrecommended.

Also, just sounds like you hate Microsoft, and are looking for (poor) excuses to continue your hatred.

We were using the Express edition, and I don't think a database needs 4GB of RAM for serving 600MB of data in a glorified CRUD and filter application that receives 1 update every 2 seconds, and serves a bunch of queries every 5 minutes. An unoptimized Sqlite can do that easily without the crazy memory.

That makes more sense, sorry for the confusion. I don't think your expectation is unrealistic. I haven't run into anything like what you experienced, but my exposure to express under tight memory constraints isn't something I dabble in.

Did you perhaps use dynamically generated queries, instead of stored procedures? Or do a join onto either table x or table y?

The dynamic queries are compiled on first run, with a query plan optimized to the size of data - that's really unlikely to be the performance issue.

Was the server running Windows? Windows doesn't perform really well in 1G of RAM, especially if you're running GUI Windows and not Windows Server Core. Then running SQL server on top of that, well that 1G RAM probably IS the performance issue. A good rule of thumb is Window takes 3G, and your programs go on top of that.

There were clearly other issues from what the OP described though, and to use LINQ you do have to have a good clear mental model of the runtime actions that it give you. It's a power tool, and can let someone experienced develop very fast, or let someone inexperienced cut their fingers off equally fast!

To provide an answer to OP, about following MS recommendations .. the reality is that not all MS advice is good advice, and also that with so many versions not all of their documentation is up to date. However it seems your team did draw the short straw! Mostly their documentation is very good for product and API level documentation, not as good for architectural documentation.

In my experience the biggest problem with C#/.NET tooling is the lack of too many open source 3rd party alternatives.

In the .Net world, if MS released a certain library, that would become the de facto choice for nearly everyone in the ecosystem. Competing with the MS options was almost impossible.

So even if the MS choice had a lot of flaws, it would remain predominant.

Which meant that as long as the MS option was good enough, you wouldn’t see too many alternatives unless they were an order of magnitude better.

And a large reason for this was the closed source nature of .NET.

In the open source world, even if the primary vendor option is great, but it has only a single minor issue, someone will invariably fork it and fix the minor issue. Which puts competitive pressure on the primary vendor to incorporate that fox, or if they’re unable to, see a lot of people migrate to the competing, slightly better offering, which is easy to do since it’s basically the same product with that 1 slightly better fix.

In practice the original vendor almost certainly incorporates the Fox, especially since it’s so easy to do as someone else has already written the code for it.

So IMO the problem with the .NET/C# ecosystem used to be it’s closed source nature, which led to very little competitive pressure for improving tools and libraries, unlike all the primarily open source alternatives you mention.

> In the .Net world, if MS released a certain library, that would become the de facto choice for nearly everyone in the ecosystem. Competing with the MS options was almost impossible.

While I get your point, I personally prefer it this way. Whatever Microsoft will put out will at least be “ok”, regularly bug fixed and supported for ever and ever.

I prefer to having an ok default and just rolling with it.

And having a default library for everything is great since you don't have to learn countless libraries doing the same thing and you can understand code written by others with ease.

But this is a tacit agreement in the .NET world. It's not only about libraries written by Microsoft. When sensible libraries such as Automapper or Newtonsoft JSON appear, everybody defaults to them.

And there are alternatives. But the core libraries are a safer bet for long term maintainability, and they get invested into to survive long term.

A big thing that people often don't understand about .NET is it has the perspective of being all things to all people.

One example of this is that it gives first class support for supporting living extensible systems for long durations like decades which is often not really the case for other stacks. Hence the prevalence for approved long term supported libraries typically with first party backing from MS.

Another aspect of this all things to all people is that it has lower level closer to the metal performance features that people only used to high level stacks often mention they don't see the need for (although they don't say it like that!).

Another aspect is you can do pretty much any kind of application in it, from web to native to high performance games or latency sensitive systems (with some special techniques) to well almost anything. The ability to access low level performance while still having high level general ergonomic APIs is critical to this.

For the benefit of others who might get the wrong idea, async/await definitely doesn’t spawn processes and in almost all cases not even extra threads.

Pretty sure he was employing “Task.Run” which is… nearly always the wrong thing but does appear in a lot of the early examples.

Was this the first time using .NET for most of your devs?

> LINQ supports interleaving DB operations with not-db operations

This hasn't been the case since EF Core 3.0, it will throw an exception if something can't be translated to prevent this problem. Prior to this (EF Core 2.2), a warning would be spat out if an in-memory operation occurs. Due to this, I assume this project was a number of years ago.

> The logger would log the message and the affected class in different lines.

The default logging format is unfortunate, although it can be made a single line in .NET 5 onwards. This issue would've been easily solved by using Serilog, swapping out the built-in logging with a few lines of code. I don't know the last time I encountered a .NET dev that wasn't at least aware of Serilog as an alternative.

Good to know for me who used EF5.

Keep in mind I've never done ASP.NET (only desktop development):

The old C# stuff is indeed crusty, intermixed with hot nonsense from the Balmer days.

Latest Framework version is I'd say OK, nothing to write home about, newer stuff is much better (.net 5, 6).

I do think MS SQL Server is a bit, well, bad. But don't worry, irrelevant to the C# stuff - I used to use java servlets to query mssql, while it was better performing than mysql, I wouldn't pick it again.

The anecdote about the React frontend bit is interesting, but ultimately depends on what the UI was doing. JS is certainly good to bang out some quick UI, but if it was shell for the backend, I'd say your app was either mis-designed or just naturally backend heavy.

Again, haven't used (not in web dev right now), but Blazor exists for doing C# web UI, instead of complaining that the backend was bad/hard a better comparison would be between Blazor and React.

Or you could switch architectures and do a non-component-based web UI - faster to put together a mashup of JS junk but it doesn't necessarily perform as well as doing a web client old-style - simple request response works for a lot of use-cases, its not as flashy, but it is fast.

The (Generic) Repository Patterns are some of the most anti-patterns created and goes fully agains't DRY and SOLID, it's like whole generations of developers are just on the same cargo and have never worked with a database( or datasource) having more than 1 table.

So it looks great for a blog post, for a linkedin thought leader article, but when actually used, you end up duplicating the same shit over and over and over unless you use extension methods. But then why having the damn Repo patterns with the basic methods in the first place?

These patterns are just awful and don't solve anything, abstraction of the DB? You don't need that pattern for that.

Agreed. Fortunately the main documentation now shows that this is an anti pattern since EF dbcontext is already a repository pattern and implements unit-of-work semantics.

I wanted to say exactly this.

Well, please explain to me how can I switch the app from using Postgres to Redis or Cassandra with ease if I am not using something like a repository pattern?

It's true, EF abstracts the database away by not requiring you to write SQL but EF is only usable with some SQL databases.

So, having another abstraction layer might not be a bad idea.

Yup, because we devs switch databases every week. That's the real reason why all projects are late: we are so busy switching databases all the time we don't have time for writing code!

dotnet add package EfCore.Cassandra.

Then in startup.cs or program.cs, add this to your services: optionsBuilder.UseCassandra("Contact Points=127.0.0.1;", opt => { opt.MigrationsHistoryTable(HistoryRepository.DefaultTableName, "<schema name>"); });

See more here: https://efcorecassandra.readthedocs.io/en/latest/intro/getti...

Well, that's a new one. I didn't know there's an EF provider for Cassandra. Thanks for the update. :)

> "switch the app from using Postgres to Redis or Cassandra with ease"

You can't. There is no such thing as switching databases "with ease" for any serious application.

Postgres, Redis and Cassandra are all very different databases and it doesn't make sense to switch between them; unless your app is small and still experimental so the changes are trivial, or so large that it's a major project with very specific needs that requires far more work than a repository would solve.

But if you really want to, Entity Framework already has multiple providers including non-relational databases like Cassandra. Anyone can write a provider and there are many 3rd-party libraries for whatever data source you want.

> "having another abstraction layer might not be a bad idea."

It's a terrible idea. It's such an exceedingly rare situation that you're wasting a lot of upfront work for something that'll never be used.

Also .NET has a fantastic data system with LINQ which is built around `IQueryable` and provides powerful query modeling that can be incrementally and dynamically changed before its pushed down to the datasource. It's what makes EF so good and why repository patterns cause so many problems by breaking this interface for no productive reason. You can also use extension methods on the `DbContext` to extract complex queries or large operations to a single method.

Now all that being said, there are times where you can have an abstraction/interface to your data sources if they're very complex or spread across multiple databases or have other processing needs. But at that point you actually need it, instead of just doing it as a "pattern".

Your last point is not how threading or async works in .NET. It’s a single process that has a thread pool that runs async Tasks. The rest of the comment indicates that the team didn’t have much or any experience with .NET.

I’m sure there are issues with learning curve but the ecosystem is very capable (the corollary to being very productive) but you need to know how to properly use it.

It also indicates the ego of the "best" senior dev who leaps in to save the day is quite large, and not very well correlated with ability and experience with the stack.

We also tried hiring. After checking 100+ resumes, and interviewing the best 10 candidates, we hired the best we could find, who turned out to be average.

My ego is not unfounded, I have had to do this successfully in other projects, but I can only do it if both the tools, the codebase and the framework allow me to do it

I would say it sounds unfounded to me. You "jumped" in to a different language, different database, different framework, and you landed up making junior level mistakes.

Your explanations of what went wrong show clearly that you still don't have a grasp of how async/await works. So you don't understand the concept, which is now common across a number of languages including javascript (which you claim to know) and python (which you claim to know), dart, and scala.

Based on your technical knowledge of languages you claim to know, I would say you are closer to a junior developer.

You seriously want me to tell you how async, promises, callbacks, coroutines, closures+continuations, call/cc, and copies of the stack are actually points of view in the same concept?

If I'm a junior, 99% of the professional programmers out there are simply not programmers at all.

His ad hominem was uncalled for. To be completely fair though, your list of grievances (some of which are fully valid) intersect strongly with things most people encounter in their first 6 months of working with the framework.

I feel you on the hiring bit, there's such a glut of resume padders, bullhockey purveyors, enterprise leftovers in .Net it's hard to find good people (especially in the US). If you put feelers out to any recruiting firm you'll receive a who's who of people no one will hire. There's also not much of a community to speak of compared to other platforms (what community there is is spread out across numerous platforms or centered around MS, github) so there's not really anywhere you can post your jobs and expect a positive result.

The hiring thing is maybe a bit of a chicken and egg situation, as there's clear prejudice against .NET in many hackernews posters and low amount of job ads on who's hiring. I've read threads here of a number of people who switched stacks because of this issue, even though as it becoming apparent .NET is a perfectly cromulent stack!

To anyone trying to hire heavy lifting .NET expertise, I am now looking for an interesting fully remote role!

I've been using .NET since V1 and Delphi before that so I have deep exposure to getting things done with this stack and would prefer to work with it compared to most others. I've also worked commercially with about 10 languages so fairly polyglot, just find C# very powerful with a focus on GTD.

You don't have any contact information in your profile :)

I would like you to explain how "You better not do some type of async stuff in LINQ, because the system is going to spawn a process for each entry, obliterating your production instance by creating thousands of processes, using a bunch of MB for each process." translates into how using async spawns processes. Not tasks, not threads, but processes.

All that sounds like poor app design.

Microsoft doesn't force you to use SQL Server. I used Postgres and Redis for a quite big microservice based app.

Repository isn't mandatory, however is nice to separate the business logic from the details of the data store or database. Using a repository shouldn't be a a problem unless you are doing it wrong. I've seen enough of poor repository pattern implementation. I would question the skills of the developers here.

LINQ was not used properly if you had mixed IEnumerable and IQueryable based queries. It's not frameworks fault here, I'm afraid.

The system is not spawning threads for async requests, it's just creating Tasks which cost very little since they aren't physical threads. Think of goroutines, not threads.

All the things you mention seem to be due to lack of experience. I am not sure how using another platform would have yield better results, skill sets remaining the same.

It's not a problem if you try a new language, platform or framework as long as you don't just churn out code assembling method calls based on name (. NET makes this very easy because of intellisense) and examples found on Stack Overflow. As long as you understand what the code does, you are fine.

So the problem is that I'm using Microsoft's recommendations (Sql Server, repository pattern, LINQ) for a Microsoft product, and the difference between an inexperienced team and an experienced team is that the experienced team knows what list of recommendations coming from Microsoft are actually the ones you should follow in order to bypass most of the footguns.

I think I'm going to go with frameworks that have the actual best reccomendations baked in, instead of the frameworks that recommend footguns.

>I think I'm going to go with frameworks that have the actual best reccomendations baked in, instead of the frameworks that recommend footguns.

For every good framework, regardless of platform and language, there is going to be a learning curve. That's because flexibility and extensibility add complexity.

Only a trivial framework with limited use cases would not allow you to make mistakes. I take it you never used C or C+=, because there's a footgun waiting for you at every keystroke. :)

It’s interesting to look at this from the perspective of an experienced .NET developer, because you’re not wrong:

* SQL Server can be incredibly fast with good access patterns, but the rest suggests you didn’t have those. * Yeah, the repository pattern is garbage. I prefer just define the operations you need and use Dapper. * I know some on here are wild about Entity Framework, but personally I’d rather write the SQL myself. You need a good mental model of what’s going on under the hood or what you’ve described happens. * Honestly never used the default test runner because it seems pretty bad. NCrunch, however, is incredible and doesn’t suffer from this. * I don’t think I’ve ever worked anywhere that used the default logging implementation and yes, that format is weird. (You can, however, step into the logging code if you want.) * Depends on what you’re doing, but yeah 10,000,000 Task.Runs is not going to perform well. But I’m not sure the equivalent code works well anywhere except possibly BEAM.

So whilst none of these things cause me problems on a day-to-day basis, I can 100% see how inexperienced devs could drive straight into that tar pit.

Like you, I also wish HN would preserve newlines or keep asterisks as bullet points on newlines! :D

FML...

> LINQ supports interleaving DB operations with not-db operations, quickly becoming a O(n^m) footguns.

This is no longer the case since EF Core 3.0. Only top level projection can contain expressions that aren’t translatable to SQL.

> You better not do some type of async stuff in LINQ, because the system is going to spawn a process for each entry…

I wonder exactly what you ran into. This is not an accurate description of how EF Core’s async support works. Not even if you replace the word “process” with the word “thread”.

Usually in these situations I switch the junior developer to the back end which often increases velocity by 20%. Then let one of the senior devs take a brief vacation since they can be having issues at home. Usually by the time they are back, everything flows smoothly, velocity doubles and clients are pleased. I believe this approach can be tweaked to work even when the back end is done in .NET.

Funny how differently the grandparent's anecdotic but positive comment and this anecdotic but negative comment are treated.

For one thing, the negative comment appears to be claiming that the backend being more complex than the front end is a very strong indicator that the backend tooling was worse, and that in a web project, everything else equal, the front end should always take longer than the back end.

The entire premise is dubious, and even if the premise is correct, blaming it on the framework without any other evidence seems like a stretch.

Aye, I noticed this too and I’ve never written a line of production C# in my life.

On the projects I’ve worked on recently, the backend often ended up far more complex than the frontend, taking up more time to build and maintain.

This is natural. The backends were responsible for interfacing with other systems, like databases, 3rd party APIs and message queues, for example.

The frontends, on the other hand, generally interfaced with only one system: the backend.

Am I arguing that the frontend is never more complex and time consuming than the backend? Not at all.

But I don’t think you can blame the backend stack and tooling for the resultant imbalance of complexity between the two systems.

Because the issues described downstream are bordering on ridiculous and betray lack of knowledge of how to use the ecosystem rather than a problem with the stack itself.

I commissioned a house. The guy who did the paint job finished faster than the two guys who laid the bricks and did everything else. It clearly means that the bricks are of poor quality, I will never buy the same bricks again.

I commisioned another house. I have been building houses for the last 5 years. During these years I have seen that the bricklayers tend to take around 20% less time than the painters, furniture-installers and decorators. Somehow, in this project, with bricks provided by BigCorp the bricklayers are significantly late, and are delaying the whole project. It doesn't clearly mean anything other than I'm not willing to risk another late house by using again the bricks from BigCorp

Do you mean net for desktop applications or asp net?

Both. Definitely one of the best options for (windows) desktop apps.

And asp.net is fantastic for webapps, especially now that Blazor has become so capable.

The upcoming MAUI framework is also encouraging and should make cross platform native UI development much nicer.

Can you comment on how Blazor has become capable? It seems like a cool tech, but when I tried the wasm runtime about 6 months back it was still quite slow. I would like to use it for web app development but speed still seems to be holding it back.

In typical MS tradition, there is a naming issue. Blazor can mean client-side (via WASM) or server-side.

I can see why this is named this way, considering both variants share a lot in common, aside from some platform specific considerations (parallelism, and file system, etc.) moving from one platform to other is fairly simple. In fact back when Blazor WASM didn't provide decent stack trace on a browser console, I was doing development on Blazor Server and then ported it over to WASM.

Still, it is not Angular level slow while being easier to use.

While your gut may be telling you that, no actual data bears that out as a reality. Exhibit A: a set of benchmarks with actual rationale and cited sources: https://www.diva-portal.org/smash/get/diva2:1578257/FULLTEXT...

From an objective standpoint it's not a valid comparison. Blazor still has a number of fundamental deficiencies in regards to how it interfaces with the DOM event model via its messaging abstraction. You can't create a symmetrical set of tests without dropping concerns Blazor can't accomplish without custom JS, or limiting the scope of comparisons to what Blazor can do.

Do you mean speed in development or performance? .NET 6 has made major improvements on both fronts.

The best answer I have is the recent Blazor presentation from Steve Sanderson (the original author) from NDC Oslo conference on 2/21/2022: https://www.youtube.com/watch?v=Rn8psTi8FBk

It's 1 hour and will explain in far more detail exactly how good it is, from hot-reload (which is massive), importing other packages (including native Rust or C source like SQLite), unified server/wasm APIs, prerendering/hydration improvements, EF Core wasm, and even integration with existing JS react/vue components.

It is still quite slow, especially at first load due to its comparatively massive payload size. Server-side depends entirely on the connection speed of the interfaces and hardware involved, and will always be necessarily verbose.

The other mode of Blazor, server side, is where Blazor really shines. Performance is very fast on the client, and it's a much simpler experience for development that traditional SPA while having a very similar programming model. It's simpler partly because of the cohesive much simplified stack, and partly because for most simple one client apps you don't need to create a server API with all the extra work and issues that brings vs having your server side data in process.

Blazor WASM is still unfortunately slow on load, however the recent Steve Sanderson video on Blazor in .NET 6 showed impressive client runtime performance once loaded, by doing virtualized UI access to in process Sqlite for a truly native client performance much better than the current gen SPAs and getting back to how good software used to be, literally instant scrolling over tens of thousands of records.

But Blazor server is really excellent, recommend it.

Are there any demos or samples of MAUI? Last I checked it was in a very early stage and I couldn't find anything

Yes, it's rapidly developing and they have preview releases every few weeks. Most recent intro videos:

- https://www.youtube.com/watch?v=LUlbO5MjPjU - https://www.youtube.com/watch?v=HMYpAw2sl58

The main repo has links to all of the announcement posts for every preview milestone release which goes into far more detail: https://github.com/dotnet/maui

I'd say that Asp.Net Core is a totally different from original Asp.Net. It is architected and implemented so well I still am amazed sometimes after working with it for a couple of years now.

I am returning to Java ( Spring Boot, Spring Cloud and IntellJ ) after a long period with C# and .NET core. What a step backward it is! Really the .NET platform is leaps and bounds better than anything offered by Java today (at least when speaking about Spring).

.NET and C# as a platform are evolving extremely fast compared to many other runtimes and languages. In fact, it's kind of been converging with JavaScript and TypeScript. I have a small repo here that highlights this: https://github.com/CharlieDigital/js-ts-csharp

If you stopped working with .NET and C# around version 4, the language itself has transformed.

Local functions, pattern matching, records, and more!

And to be fair, it was always ahead of Java as a language. Reified generics in 2005, LINQ in 2008, Async, language servers etc etc.

If you can, you can give a try to Quarkus, while the doc is not up to the level of Spring, in term of ergonomics, configuration, hot reload, test containers, this is closer to what .NET does, by example annotations are optional and are resolved at compilation not at the execution.

>Entity framework is one of the best ORMs

Yes, I think it is the best ORM in terms of productivity, but it is very, very slow. This is usually not a concern for internal enterprise applications that only have a few people using them at a time though. I guess the other issue is just an issue with ORMs in general - you lose a lot of the in-built features of your sql database, which as projects progress, can ultimately result in you writing the same amount of code as if you didn't use the ORM.

You also can't switch programming languages without rewriting the entire database section. Personally, I stopped using ORMs altogether because I find that they make easy things a little easier, and hard things harder, which isn't a very good value proposition overall. They don't really save me time anymore.

EF Core is not slow at all, especially if you disable change tracking, which you don't want in many cases anyway.

No it is definitely very slow. Stackoverflow did a test once, and switched to their light-weight ORM. The thing is, you mention disabling change tracking, and then there are things like having to make sure you aren't accessing a field that is outside of the included fields to prevent multiple queries, etc, etc. When I write SQL, I just write it once, and then it lives forever going very fast. When I look back on the projects written in EF/Linq, they are still going year after year, still using up lots of resources. I could have just written them in SQL. Maybe it would have taken an hour more over the entire project (internal enterprise thing), but it would still be running to this day, quickly and efficiently.

With ORMs I tend to write things with their native syntax, and then if necessary go back and speed up critical sections with SQL; it's not an either/or situation.

That was a long time ago. I believe it was based on EF and not on EF core. Is there any up to date benchmark that you are aware of? BTW I used both Dapper and EF for consumer based web applications with a mild load. Dapper is a nightmare to use compared to EF. Dapper was chosen by the customer architect as mandatory because probably of the same benchmark that you are referring to. The result has been that we had to write tons and tons of code to cover things that come out of the box in EF such as 1 to many relationships. Also every change in the schema forced us to review the full persistence layer to evaluate the impacts. I would reccomend Dapper only for websites dominated by SELECT queries on databases with simple DB schemas and only when some millisecond more make a difference. This wasn't absolutely the case for our application ( complicated DB schema and 5 ms vs 30ms spent in the ORM doesn't make any difference at all) while probably IT IS StackOverflow case. There is no such a thing as something slow or fast in absolute terms: it all depends on the context and as software engineers and even more architects we are called to judge with our brains everything in context rather than rely on a blog post written by somebody else.

>Stackoverflow did a test once

That was long time ago and EF improved a lot since then.

But it can be slow if used improperly. But hand written SQL can be slow too if not carefully crafted.

Any SQL query can be slow, especially if you have a large database and/or use a lot of Foreign Keys within your database.

Sometimes small changes in fragmentation, statistics or data composition will trigger a different queryplan which will affect your query immensely.

Good monitoring and a DBA nearby would be your best bets to overcome this. The point is that using a relational database is not a trivial thing once the database becomes large. Until then its relatively simple.

I don't think its a common opinion that its very slow. It builds queries and executes them very quickly compared to most.

It does have a built in footgun where for some structures it defaults to invisibly lazy loading sub-collections, you can (almost certainly should) disable that and specifically tell it to populate that data in the first query using Include() or any of the other projection mechanisms. Is it possible you had that?

Lazy loading has been disabled by default since EF Core came out.

The most comprehensive benchmarks to track are the TechEmpower benchmarks as they are open source so you can see what each framework is doing: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...

The benchmarks model simple, but real world scenarios. It has breakdowns by EF, Dapper (the StackOverflow "micro-ORM"), MySQL, PG, and raw ADO.NET.

It should be noted that EF and EF Core are not the same thing; EF Core is more or less a full rewrite: https://docs.microsoft.com/en-us/ef/efcore-and-ef6/

Recent benchmarks have EF Core catching up to Dapper. You can read more about Microsoft's focus on performance for EF Core here: https://devblogs.microsoft.com/dotnet/announcing-entity-fram...

As others have noted, that's very outdated information.

The other thing is that for all ORMS, for the small amount of queries where it really matters, you should drop down to hand-written SQL anyway if the juice is worth the squeeeeze!

I left .NET around 10 years ago, and have yet to be as productive in any other ecosystem.

JavaScript is productive once you stop listening to all the high level abstracts and complications. Vanilla JavaScript is beautiful and highly productive. Right up there with c# for server side ops.

There does seem to be some cultural inertia from the gap between when people made all the new frameworks and extensions to make JavaScript keep up with the advance of the web and when JavaScript got most of that functionality built in. CSS has the same issue where people don't realize it does most of what frameworks were made for originally like grids and changes based on medium/resolution/etc.

I think it's the curse of web development. It's so hard to keep up with all the brand new technology changes, so once you know the basics well enough you rarely take much time to look back at them. And Googling "how to create a grid" feels kind of redundant if you've already found a reasonable effective way to do it.

All these new features are nice, but not all users are using the latest browsers, so we have to keep falling back on these frameworks

The only scenarios I can think of where someone hasn't been on an auto-updating browser for 10+ years is embedded systems and locked down intranets where no one expects the latest and greatest, and people in circumstances where a minimal page not top-heavy with scripts and frameworks is best.

Have you ever worked for a bank?

As someone who has only written Node/TypeScript and C# backends in the last 10 years, I couldn't disagree more.

Node has so few "batteries included" that you spend a ridiculous amount of time searching npm.

That's especially bad because Node's ecosystem is a graveyard. There are 3-10 libraries for everything, and (if you're lucky) one will be well-tested and maintained. And even then, you're very rarely going to find something that's also: 1) maintained by more than one person, 2) used in production by well-funded developers, and 3) able to keep up with their Github bug reports.

In some cases, I have to try 2-3 libraries before picking one and often switch to another one later.

.NET, on the other hand, has a great ecosystem, batteries included, and (if needed) usually a commercial library for the really important stuff. It's just a far more stable and serious ecosystem in general.

Vanilla Javascript is productive until you reach a certain size of the project. After that the bugs will kill you. You will lose more time hunting bugs then writing code.

And that is not Javascript's fault because it was never intended to be anything else that a small script language to interact with DOM in a web page and add a bit of interactivity to HTML.

Me too I had Java envy, but now I realize a choice of 20 different frameworks doesn't make anything easier.

Well, for plain old websites Ruby on Rails I think is on par with ASP.NET MVC.

For Web API maybe Go is a reasonable contender if you put up with the boiler plate and verbosity.

As for mobile apps, I didn't encounter anything as productive as Xamarin while being reasonably multiplatform.

I didn't do desktop apps since ages but I remember QT and Embarcadero's C++ builder as being quite productive.

But one platform to do it all? There isn't other. Javascript is today used everywhere but I wouldn't quite qualify it as productive or performant. And countless frameworks and libraries competing with each other kind of makes it a mess.

Agreed, the versatility, as a mostly first class language across domains is awesome!

On the RoR comparison, while coding speed is similar, Blazor is an advancement, and then the runtime perf of .Net 6 vs RoR means having less servers, less cost, and less scaling challenges!

Techempower round 20 has ASP.NET at 309,458, compared to RoR at 8,260. That is 37 TIMES faster for .NET. Think of that as 37 times as much AWS bill for your RoR startup ..

https://www.techempower.com/benchmarks/

Interesting! I’ve recently made a switch from C# to TypeScript and I’ve found prisma to be such a relief from working with entity framework.

Not that entity is bad in any way, it’s just not as productive. Which is sort of how I have it with most of the journey into TypeScript. It’s just a really great environment especially in Azure Function apps, and a massive cadeau to Microsoft for making the node in docker such a first class citizen in their Azure environment!

In many ways I feel like TypeScript is a mix of the best of Python and C# and that’s just wonderful, for me.

But writing things like Odata APIs in .Net sure has some benefits from the massive work Microsoft has done with the .net and C# environment since moving core into the main .net or however you describe it.

So now I’m not sure where I am going with this, I’m probably just very appreciative of the work Microsoft has done for us enterprise developers in non-tech enterprise in the past few years.

Prisma's query syntax feels quite verbose to construct and reminds me of CAML from my SharePoint days (except JSON vs XML).

It's also lacking support for a lot of data types on PG.

It's crazy that EF Core has providers for everything from SQL Server to CosmosDB to Google Spanner to in memory DBs.

LINQ and expression trees are probably one of the best features of .NET.

> Entity framework is one of the best ORMs I've ever worked with.

It is good, but it's just better to learn TSQL/SQL Server if you are on a windows stack. Shouldn't use it as a crutch especially if you working on the back-end side. Entity framework was created to make data access easier for the front-end people.

Entity Framework owes a lot to nhibernate - but linq is the best thing that ever happened in ORM world.

Maybe full on EF/EFCore is better, but I know with basic Linq to Sql I often needed to check the generated SQL because sometimes it was non-intuitive how to get it to generate the simplest form possible (my biggest example was to do a 3 part join I had to list the tables backwards from the way I expected, doing the other way lead to a weird bunch of subselects, though note this is also in Framework so maybe they simply fixed the SQL compiler in Core).

I’ve been working with efcore lately and it has so far almost always produced what I’d expect, at least for my arbitrarily complex joins and left joins, both join calls and Include calls (and include simplifies a ridiculous amount of cases)

They also removed the intermixing between server logic and db logic, which greatly reduces nonsense occurring

LINQ is very hard to debug, especially depending on the provider. With anything remotely complicated it becomes write-once (like Perl :p)

I'm using ASP.Net Core for a couple personal projects for the first time, and it's pretty decent. I'm using nginx as a proxy, and I'm able to develop and test everything on Windows, and publish directly to a Linux test server. I have a lot to learn, especially for handling some web requests at a lower level, but I've been pretty impressed so far.

Check out YARP - Yet Another Reverse Proxy

Edit: thanks :)

YARP :)

Interesting, thanks

I recently used kestrel as a public facing server and it feels goods.

I'm not against it, I just happened to also need lots of nginx functionality...but a cursory glance does suggest YARP provides at least most of what I need.

Can you explain this a bit? I'm trying to figure out what the appeal is of YARP, so far the only thing that makes sense is the load balancing.

The big appeal for me is that with YARP you are treating your proxy as code that you write yourself.

YARP gives you all of the building blocks you need to build a simple proxy just as easily as a highly complex one.

I stopped trying to convince others, once they saw the productivity and solid apps we were shipping they cloned our repos and are now .net devs.

Push they’re buttons all the time calling them Microsoft fanboys… that will get them going. Secretly they like it.

Interesting. I’m a rails developer, and to me one of the core strength of rails is active record (altho some might disagree). How would you compare it with rails active record, and which part do you say it’s much better?

Btw, I know this is superfluous and very shallow, but for some reason, I can’t get over the C# syntax because of how enterprisey it is. I much prefer ruby, but I guess it’s a matter of preferences and taste

What the hell does enterprisey even mean .

Enterprisey usually means high-overhead, tuned to require many developers to achieve what would be done by one on a less enterprisey system.

This quality is attractive to managers who benefit by increased headcount, and prefer to have their "reports" or "resources" less generally capable, and more easily replaced or shuffled. Total cost is much higher, but individuals' salaries are lower, which makes managers look good.

Java and .Net are both very enterprisey platforms.

> high-overhead

You understand that all the things done in Java and .NET’s “enterprisy” way can be done is most languages right?

This is a programmer problem not a programming language one. Today you have to write less in C# than GoLang, to do the same tasks. Does that mean GoLang is enterprisey now, just because you have to write more?

Not "just because". Go is exactly as enterprisey as Java and C#, and for exactly all the same reasons.

And, it is not a programmer problem. It is a management problem. None of them would exist without management demand for minimally-productive languages.

What a weird hill to die on. I have a hard time believing “management” woke up one day and said: “how can we make the most minimally productive language”.

Tell me about this secret non “enterprisey” stack you are using.

Management does not make languages. They use what exists that satisfies their need for large head count. Sun and Microsoft were happy to provide it for them.

Again tell me what you think is not enterprisey then. I would like to open my mind to it.

i really liked the way ROM worked in ruby before i switched away from rails. I never got a chance to give it a good try.

ahem Have you considered F#, which could hardly be accused of being enterprisey?

Latest techempower benchmarks show ASP.NET Core being 37 TIMES as fast at runtime as RoR.

Think of that as 37 times as much AWS bill for your projects in RoR.. what were you saying about the syntax ¯\_(ツ)_/¯

Reply on news.ycombinator.com