Yessss.
C#/.Net backends are the best. The long term stability, DevX, and the "it just works" nature of all the tooling makes it a great choice. It's also fast, which makes scaling for most applications a non-issue.
I've switched to postgres for DB from SQL server, have never looked back, would recommend.
.Net + EF Core + Vue/TS + Postgres. Redis as needed, Kafka as needed.
I can get applications built extremely quickly, and their maintenance costs are incredibly low. The backends are stable, and can hang around for 5, 10+ years without issue or problems with ecosystem churn.
You can build a library of patterns and reusable code that you can bring to new projects to get them off the ground even faster.
Would recommend.
No matter how low overhead you get, it's still node, which means it's still an actual order of magnitude behind Go & Asp.Net Core (~600k RPS raw Node, ~7mill RPS with asp.net core & go). Which means 10x the compute costs for the same outcomes.
It's not a bad thing, to be clear, but the underlying technology has issues that frameworks on top of it can't really address.
Also the meme of "yet-another-framework", which may or may not be in some state of deprecation, abandonment, or incompatibility in 5 years.
Nevermind PC games, think about how this would impact mobile games. Where you get TONS of transient installs, and very few consistent players.
You could actually go into debt by using unity, and accidentally being successful if you aren't abusively monitizing your game.
Rider is great, it's 100% worth the money.
Switched over to it this year from VS, it's so good in comparison. There's some things that aren't as nice (the CPU/memory graphs in VS are actually nice and handy). But overall, an upgrade.
VS Code honestly kind of sucks for it, there's just so many small things missing or lacking.
Check out Rider, I was honestly surprised and switched over to it after 8 years of visual studio.
If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.
Your frontend will always churn, that's the nature of the job.
It's not game changing because someone else tried to do this and failed
Kind of a weird point to try and make no?
I think you can have a well tended garden without giving up creativity.
You're not sacrificing creativity by practicing structures, considerations, and methodologies that maintain or improve the developer experience with whatever creative endeavor you're on.
The structure of your garden doesn't prevent you from playing around with new plants, it just outlines a set of patterns and expectations known to drive better outcomes.
I'm not saying that your extension of the analogy is bad I'm just disagreeing with some of the premise.
Pretty much.
For instance focusing on PR size. PR size may be a side effect of the maturity of the product, the type of work being performed, the complexity or lack thereof of the real world space their problems touch, and in the methodologies habits and practices of the team.
Just looking at PR size or really any other single dimensional KPI lead you to lose the nuance that was driving the productivity in the first place.
Honestly in my experience high productivity comes from a high level of unity in how the team thinks, approaches problems, and how diligent they are about their decisions. And isn't necessarily something that's strictly learned, it can be about getting the right people together.
That's not a licence thing, it's a privacy & security thing. Whos APIs are they using? What are their agreements with them? What leaks, what doesn't? Where is our code & context being sent to....etc
There is a lot more there that should be announced with it. Otherwise it's a hard no from security focused orgs unless they have this posted, in detail, somewhere, and it's favorable.
Edit: Looks like they just post who the providers are, and it's OpenAI. So that's gonna be a no unless we can bring our own APIs, since we have Azure GPT-3.5 & 4 access that meets opsec standards.
The great thing about languages like C# is that you really don't need to "catch up". It's incredibly stable and what you know about C#8 (Really could get away with C# 6 or earlier) is more than enough to get you through the grand majority of personal and enterprise programming needs for the next 5-10 years.
New language versions are adding features, improving existing ones, and improving on the ergonomics. Not necessarily breaking or changing anything before it.
That's one of the major selling points really, stability and longevity. Without sacrificing performance, features, or innovation.